I’ve just invented a new acronym (yeah, yeah, I know, like the world NEEDED another acronym, right?!): DFPS (Deadline First, Plan Second).
Deadline First, Plan Second describes the all-too-common phenomenon of project deadlines being set before any of the planning and estimating has been done. We’ve all been involved in or heard of such a project — the kind precipitated by a big announcement that The Next Big Thing (TM) will be delivered by March 1. Post announcement, a team is pulled together tasked with actually making it happen.
This throws many good project management practices straight out the window. It doesn’t matter if you do a proper plan, involve the team in estimating and figure out that the project will REALLY take 9 months instead of 5. The announcement has already been made — pointing out that it’s unrealistic is only going to get you accused of not being a team player. Alternatively, your management may view it as a crafty way of getting more money or people. So you may go in trying to convince them that it’s not going to happen and come out with twice the money, but you’re still signed up to an impossible deadline.
The good news? People who pull deadlines out of the air often don’t really understand the intricacies and complexities of your project. Duh, right? If they understood, they wouldn’t be setting impossible deadlines! Although this may sound like I’m just hammering home bad news, there is a flip side to this coin. If the deadlines are arbitrarily set, they are quite unlikely to have a detailed understanding of the scope of the project.
Reality is that you can probably negotiate your way through on all the other project variables – cost, quality & scope – you just need to accept that someone high up has nailed their future to a deadline and so now that is set in stone. So long as there’s a big “we did it” announcement on March 1, the definition of “it” is probably fairly fluid.
My advice? If you blatantly need more money or people, go the “it’s impossible” route at first. Get some extra resource thrown at you. Then, very helpfully, start preparing plans of what actually IS achievable for a Mar 1 go-live. Aim low at first — your project board or management team are going to be horrified at how little you’re saying can be done, so they’ll want to argue you up to more stuff. But be very aware of where your limits lie. Plan to under-promise and over-deliver. Give them something that works, but doesn’t sing, dance & play the ukulele. By then they may well realise they don’t need all the singing and dancing anyway!
PS If you’ve been keen to find a way to introduce a new approach, like Scrum then a DFPS situation might be just the leverage you need. Worth a try!
Given a DFPS project, the only sensible thing to do is to prioritise the requirements into must-haves, should-haves, and could-haves. In other words if the time is fixed, then the requirements or the quality needs to change. Of course there could still be the problem that there are too many must-haves to fit, and it is still very difficult to persuade a stakeholder that although they might not get all the should-haves and may not get any of the could-haves, it would still be a successful project.
Tend to agree with this. With major releases some stuff does not need to be completely finished and finalised (agreeing with what Richard said) and they can be implemented at a later release.
In saying all that however, it is best to try and get as much as possible done before the main release.
Agree with the commenters above. There is nothing wrong with a deadline first approach… as long as scope is treated as a variable.
The idea that any project can be successful if it is just given a long enough schedule is just as harmful as the idea that any project can be successful if it is just given enough resources.
We need deadlines and budgets to set boundaries. We can then determine how much scope we can acheive within those bounds.
I think the idea of internal and external “release dates” for the deadlines is an important nuance that gets missed. If marketing publishes externally your deadline and feature list before discussing it with the dev team, you’re screwed. But if marketing says we need a release by Sept 30 (the internal deadline) and mgmt says you have these five folks to do it, you can then come back and talk about which lower priority features will not ship. This may end up adjusting the budget and external deadline eventually- or not.
An oldie but a goodie:
“Why is there never time to do it properly, but always time to do it over?”