Making Good Software

A blog by Alberto G (Alberto Gutierrez)

Written by Alberto Gutierrez

October 10th, 2009 at 7:07 am

How to determine the cost and schedule of a software project? The mythical BPUF (Big planning upfront)

with 8 comments

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)

TriangleA 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.

Continuous planning

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.

In conclusion

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.

8 Responses to 'How to determine the cost and schedule of a software project? The mythical BPUF (Big planning upfront)'

Subscribe to comments with RSS or TrackBack to 'How to determine the cost and schedule of a software project? The mythical BPUF (Big planning upfront)'.

  1. […] This post was mentioned on Twitter by Tomaž Muraus. Tomaž Muraus said: How to determine the cost and schedule of a software project? The mythical BPUF (Big planning upfront) http://bit.ly/4eMB7h […]

  2. Your talk is perfect, and I totally agree however, in PMP(theoretically only of course) they just plan everything ahead!

    The cost and the time which always make this model not valid, and sometimes the customer himself demands this!

    Do you prefer some kind of approach convincing the client about this new approach!

    Amr Gawish

    13 Oct 09 at 3:02 am

  3. This is a well known dichotomy in all fields of design and engineering: there is an initial business requirement to estimate cost and time so that resources can be committed to the project, and a technical requirement to complete the project before the actual costs and time are known.

    Somehow the civil engineers, mechanical engineers, architects, graphics designers, TV advertisement creators, film makers, and others all manage to solve this problem on a regular basis. The “software engineers” (actually: developers who haven’t got engineering skills) just keep whining.

    So how do the engineers do it? They model, they experiment, they compare to completed projects of similar scope and function, they investigate risks, and through all of this they plan.

    Three tips for managing fixed term/price contracts:

    – All design activity is intolerant to change late in the process. Cosmetic details can be altered, structure cannot be. On a fixed term/price contract it is essential that specification changes are disallowed past a certain point.

    – Good engineering is tolerant, within limits. The foundations of a house or building should accommodate the addition of another floor; a bridge shouldn’t collapse under overloaded trucks. Knowing the potential future of a product (after the current contract or phase) determines the level of abstraction needed in the core/foundation.

    – Non-software engineers study materials science, which allows them to pick the appropriate material for a scenario. Software engineers need to be familiar with their “materials” – components, frameworks, storage systems, languages & libraries – and what the limits and tolerances of those materials are.

    Twylite

    15 Oct 09 at 6:46 am

  4. Alberto, you are not the only one that think in that way.

    I suppose most of you guys know Robert C. Martin. So have a look to this article:

    http://www.objectmentor.com/resources/articles/Continuous_Care.pdf

    It’s worth skimming it!!

    Surprisingly, this article was written in February 2002

    Gustavo Adolfo Martinez Risque

    17 Oct 09 at 8:24 am

  5. […] Traducido de How to determine the cost and schedule of a software project? The mythical BPUF (Big planning upfron…. […]

  6. In response to Twylite: “Somehow the civil engineers, mechanical engineers, architects, graphics designers, TV advertisement creators, film makers, and others all manage to solve this problem on a regular basis.”

    Really? How often do you hear of civil engineering projects, movies and other large projects overrun budget and/or schedule? Frequently if not invariably.

    It doesn’t invalidate the rest of your post, but iterative planning and development takes away much risk from the process. Estimates given up front should always carry big caveats, and as long as you deliver product regularly to clients this can be managed.

    Rob

    22 Dec 09 at 3:49 pm

  7. […] de : How to determine the cost and schedule of a software project? The mythical BPUF (Big planning upfron…. Posted in Calidad de Software Tags: calidad, calidad de software, desarrollo, proyecto, […]

  8. […] to fix it: For starters, is important to understand that accurate estimations in software development for non trivial solutions are impossible, we can only guess. Also remember that is very likely that you will find so many things which you […]

Leave a Reply