Dead on Arrival Deadlines
If you’ve done even a small amount of project management for a web development project you have probably been responsible for and have issued a number of deadlines. Deadlines make sense, they feel right, there’s just something about them that says “productivity”. You can make a deadline for some aspect of your project and it feels like you did something, you set a goal, you drew a line in the sand; I’m going to need to take a break after taking about it. Unfortunately, deadlines are as easy to ignore as they are to make, they are usually one directional in nature and they are a poor measure of productivity, accomplishment and satisfaction.
Purpose of Deadlines
Deadlines usually serve as a method in which to shift responsibility from one person to another. As a stakeholder in a project I can shift my responsibility of launching my project on such and such date to my hired development team. As a manager I can shift my responsibility of getting the project completed and delivered to the customer to my development team. As a developer I can find ways to shift my responsibility of completing the deadline back to the manager or client in the form of “I need…”. No one ever wants to own a deadline, they just want someone else to accept the responsibility for it’s failure and receive the accolades when it’s successful.
Responsibility Shift
During the deadline assignment process, do you find yourself using a lot of four letter words ? Every deadline is usually “easy” and “can’t” be that bad. You usually hear these type of phrases at the “responsibility shift” point in the deadline life cycle. When the project manager is shifting the responsibility to the developer they’ve got their rose colored glasses on and their attitude seems to be one of hope, relaxation, ponies, rainbows and lollipops.
- Well that shouldn’t be too hard
- There isn’t too much complexity here
- I can’t imagine this is too difficult
- That won’t take long
Not Really Deadline Deadlines
My favorite type of deadlines are the ones that nobody pays attention to from the get go. You’d think that everyone in a professional environment would be wise enough not to bother with making and pretending to adhere to deadlines that all parties agree are impossible to meet. However, this seems to be one of the favorite uses of deadlines, all going back to the feel good nature of saying you’ll get something done at a certain point in time.
Imagine this scenario:
Your client wants something done in a week that would normally take two weeks, you agree but charge them more money due to the “rush” nature of this particular job. Your development team warns that it is unlikely that you will be done on schedule, however you proceed anyway. Two days go by and now the client is relaxing their own requirements. They thought they were ready for the responsibility shift, but they were missing some content and didn’t quite have the final design in place. Now responsibility has shifted back to them and they’re forced to meet their own unrealistic deadline. Of course, they know this isn’t possible so they relax the deadline and get back to you a few days later. At this point you’re not taking the deadline seriously, so it gets pushed back a bit more.
Had a realistic deadline been put in place from the start, one that gave everyone time to get their ducks in a row, the project would have been completed in the same amount of time, the developers would not have been overworked, the client wouldn’t have had to scramble to get the content together and end product wouldn’t have been so rushed.
Improving Deadlines
- Consult the people who are doing the work required to make the deadline attainable (usually the developers)
- Make sure you’re not taking ownership of something you don’t have a good amount of control over
- Don’t use the four letter words describe above
- Speak up when you hear a deadline that’s probably going to fail
- Fight the urge to appease people by agreeing to deadlines that can’t be met
