How to determine the cost and schedule of a software project? The mythical BPUF (Big planning upfront)
How to determine the cost and schedule of a software project is one of the most important questions around software development. My opinion probably is going to be polemic, but here it is. It is impossible to determine what the cost and schedule of a software development is going to be.
Why is it impossible? (The Iron triangle)
A very good and well known analogy to help me explain it, is the iron triangle analogy which recently Mike Cohn has refined with his one handed clock. What these theories say is that in a software project (and basically in any project), assuming that the quality remains static (projects should always aim to have high quality), there are other three variable elements: Schedule (how fast you want to deliver the solution), Budget (how cheap you want your product to be) and Features (how many cool stuff you want your application to perform). What is really interesting is that these three variables depend on each other so that is impossible to give more priority to one of them without taking it from the others.
What makes it impossible to determine the cost and schedule, is that it is impossible to fully know the scope of the Features of the application upfront, no matter how much analysis, and requirements gathering you perform (yeah, I know I am going to get a lot of hate for saying this…), so how can you calculate the other two sides of the triangle? Even when the cost is fixed, or the schedule is fixed it is impossible to calculate the other vertex of the triangle.
For the sake of the argument, let’s suppose that I’m wrong and you actually can determine the Features of the application up front, so you will have to estimate then, I suppose we all will agree that an estimation at the end is just expressing a probability, when we say “it will be finish in a month”, we mean something like “there is a 80% chance that I will finish this in a month”, and when you chain probabilities, the probability of being right in all them drops exponentially meaning that even if you know all the features the combined probability of being right in all their estimations is ridiculously low.
The solution for this problem is to change the mindset and look at planning not as a one off big activity performed at the beginning of the project, but as continuous activity performed through its hole life, the more you have developed the application, the more you will be able to refine your previous plans.
There’s a vicious circle, a software development won’t get approved until is cost and schedule is estimated, but they can’t be determined because you will only know the real scope of the features by the time you start developing them, anyway, that shouldn’t stop you from starting the project and creating initial estimates and refine them as long as you keep developing the product. Be aware than trying to create an initial planning, and using it as a contract, will seriously affect all the parties involved, the customer won’t probably be able to specify any change during the development, and the development team will have to work under high pressure to meet the deadlines, at the end the final product won’t be what the customer was expecting and its quality will be poor.