One of the things that blows my mind most about software is the deadline. The problem is that often what you are trying to do when you start isn’t what you end up doing. Sometimes that is even on purpose. Software is soft and when it starts working, our minds expand and so does the project. Of course, it isn’t all good news; sometimes things might look simple for simple cases and just be impossible for everything else. Sometimes close enough, just isn’t good enough; when that happens, deadlines go out the window.
The question is, how do you say how long it will take you to do something when you don’t know what you are going to do? Maybe that isn’t the important question, maybe the deadline is more important. Maybe the real question is when do you need it by?
For me, there are some further questions, most of them come down to why do you need it by then? There might be answers like this:
- If we don’t have a system that is reporting our errors and complies with the MPASS15 legislation by midnight on the 13th March 2016 then we will be fined 10 million dollars.
- We need to have clients able to access our movies on their iPhones by the end of the year, or we will see people move to other networks
The first is a “hard” deadline with a very tangible and measureable cost for failure at an absolutely fixed date. Quite often this type of deadline would be associated with a legal change. The second type is a much vaguer proposition. In terms of the project mission statement, the second example is not good, far too vague. However, it might be the case that it is much more important that the software is brilliant. In the “legal” example, we might get by with a bare bones system that complies but does no better. If we do that for our clients, that might not be good enough and they might leave anyway.
I’ve started looking at it in this way: Delighted Vs. Disappointed and that means:
- What would the date be to make you surprised and delighted that the project was done? What would early completion allow you to do? It has to be better than “because I want it done by then”; tell me something like “that means we will be able to include the results in the next quarterly report”
- What would the date be to make you disappointed? What are you going to have to change if the work isn’t done? What real risks are you now exposed that should have been removed? Are we going to have a lost opportunity cost? Or real financial costs like maintaining an old system?
Of course, delighted and disappointed expands into all areas, not just the timeframe and helps us to set limits and expectations.
In many cases, we can make a “best guess” about a project that will be 80% accurate, 80% of the time and that is important as probably, our project is just a piece in a bigger puzzle. Doing the sums on those puzzles is the higher mathematics of management, and estimated project data is often all we have.
But, to allow your stakeholders to get confidence in you, you have to understand their motivations and that means asking why.
[Originally published in 2012]