“When you finish a project with an unrealistic deadline, your reward is another project with another unrealistic deadline.” Meridian Health Plan CIO Tom Lauzon made that observation at the Progress Exchange conference I attended last week, and it’s definitely worth bearing in mind.
Deadline picture from Shutterstock
While it’s easy for IT projects to run past deadline, sometimes the time scale proposed for a project simply isn’t realistic. If you agree to that anyway and work yourself into the ground to make that happen, chances are you’ll see more of the same. If it can’t be done, explain why — and explain early.
Comments
6 responses to “Why You Shouldn’t Always Meet The Deadline”
All estimates should be doubled, because most people give optimistic estimates and because there are always going to be unforeseen things which will cause delays and increase the costs. But don’t tell anyone you are doubling the estimates. Then add contingency on top, for good measure.
Definitely, it gives you the extra time should you need it and makes you look like a superstar if you end up delivering before the due date.
Long term though, it makes you look poor at resourcing and scheduling your time. If you work in a commercially/cost sensitive environment adding too much time and cost buffer could cost you the project entirely.
Yeah I was actually thinking that after I commented, if it was in a competitive market trying to win a project I wouldnt have a chance. Lucky project management isnt my day job!
A good project plan should detail timelines and highlight risks and the consequences should those risks eventuate, the consequences should detail the time/cost/quality impacts of those risks appearing. Often an unrealistic timeframe simply needs more cost applied to achieve.
The project stakeholders if they signed off on a project knowing all this should be able to decide if they wish to sacrifice a requirement or throw more resources to achieve it. On this front project documentation and communication is very important.
It’s useful to make the sponsor aware if it isn’t feasible to add people late in a project.
This is usually the case in IT projects. And that’s usually a surprise to sponsors.