Yesterday I mentioned about facing the deadline with not completed custom project. I thought that’s subject for longer story so I decided to extend it a bit.
If deadline is coming soon and you suddenly realize you won’t manage to provide complete solution, that probably means you’d made some mistakes during scheduling and/or controlling work. There are two main possibilities either you have on time some functions completed (tested, ready to implement), or you have none of functions fully completed but work is more advanced (e.g. code is complete but not tested). You should have known it quite early either way.
Let’s go little earlier then. There is some point on your schedule when you can be quite sure that there will be set-back at the end. If happens usually in development phase, when code complete milestone is coming (and you haven’t even started developing one third of functions) or in stabilization phase, when ready to deploy milestone is coming (and half of you functionalities haven’t even passed basic test).
On this stage it’s usually almost impossible to find additional resources… er… developers/testers/analytics. Or rather it is possible, but they won’t be productive, unless they adopt technology, learn project constraints and become friendly with the code. What more – your current team has to teach them risking more set-backs. This kind of investment can be (and should be) done, but in longer perspective. Throwing just more men into the project when things go wrong doesn’t work.
Another constraint you have under your control is time. The easiest way is to set another deadline. So where’s the problem? Problem is that time isn’t always under your control. What more usually it isn’t. It’s the customer who set deadlines. They can agree to move deadlines, but don’t have to.
If neither resources nor deadline are constrains you can change, there’s only one more left. Functionality. Cut it. Do it as early as it seems reasonable. In the worst case you throw away almost complete functions (90% complete often means 0% ready). In the best case – you don’t even start developing a function investing whole time to finish others. There is a bunch of middle possibilities of course.
Unfortunately function range is constraint you also don’t fully control. The customer can request all of them (hey, they paid for it). However there’s a place for negotiation – we can do this and that on time, or everything a “bit later”. From customer’s perspective things can look completely different depending on their own deadlines. If they have to face similar dilemma as you, they can change number of critical features, priority of bugs etc. If the time is not the main priority for customer – go back to “change the deadline” point.
Percentage of successful missions impossible in real life is much lower than in movies. Actually it’s close to zero.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
