The illusion of predictability in planning

I spoke with a friend yesterday who works in a project where the project manager has several projects to take care of. My friend’s project was recently given a fairly tight deadline and the project manager wanted to have an estimate of when the work is finished.

While I do understand the desire to know how long things take to do, I have a hard time understanding why people (like project managers) don’t realize that it’s impossible. No matter how much time you devote to analyzing the “requirements”, the estimate is bound to be uncertain.

Firstly, what is regarded as requirements are extremely poor. I read some figures on requirements specifications in XP Applied – I can’t remember them, but they were about the correctness (lots of errors) and coverage (about half of the desired functionality, if I remember correctly) of requirements specifications. So estimates based on requirements specs will be unpredictable.

Secondly, changes to the “requirements” come from lots of directions, like when you ask the customer about something not stated clearly in the requirements, he or she realizes that it was something different that he/she wanted. Or, the world changes and some feature is now more important than others. Or the requirements were misunderstood by the developers. So estimates will have to be refined during the course of the work.

Lastly, you never know what will happen in the future: people get sick, or quit, or need to work on other things, too. You might run into unforeseen troubles that require much more work than expected. So if you map the estimates to calendar time, the result will be unpredictable.

My friend’s project manager was given a date when the system must be deployed, so the estimate will be “as much time as there is between now and then” – that is, it will be a matter of regulating the scope since the date is fixed. The question is: How much can we produce during this period? and the answer can’t be anything but unpredictable. So what do you do?

One of the things my friend’s team has to do before the deadline, is to implement functionality that affects a larger part of the system, and for which there is no design yet. Estimating this inevitably would yield in a unpredictable figure, since the team doesn’t have a solution yet. There are two options in this situation, of which only one is good, in my opinion.

The bad option is to sit down in a conference room, bring a laptop with the source code and discuss the solution by the whiteboard. After a couple of days, the team is in a better position to give an estimate (which will still be unpredictable, though) and can start working on the implementation.

The good option is to start working on the implementation, perhaps after giving a very rough estimate multiplied by a factor of 2 or 3 (expressed in ideal time), and continuously refining that estimate. The project manager will still have an unpredictable estimate, but there will be progress and the estimate will be less and less unpredictable as the team does its work.

The bad option is bad because it doesn’t accomplish anything the good option doesn’t, and it results only in a unpredictable estimate – while the good option results in an unpredictable estimate as well as written code.

Everyone involved in software development must realize that continuing to do planning this way, acting as if accurate estimates is possible, will cause trouble and frustration and bad working conditions. Also, the responsibilities in planning must be balanced between programmers and customers – today, the programmers have to take care of too much: prioritizing, tracking progress, making decisions; things that should be the responsibility of project managers.

The above was posted to my personal weblog on May 29, 2002. My name is Peter Lindberg and I am a thirtysomething software developer and dad living in Stockholm, Sweden. Here, you’ll find posts in English and Swedish about whatever happens to interest me for the moment.


Related posts:

Posted around the same time:

The seven most recent posts:

  1. Tesugen Replaced (October 7)
  2. My Year of MacBook Troubles (May 16)
  3. Tesugen Turns Five (March 21)
  4. Gustaf Nordenskiöld om keramik kontra kläddesign (December 10, 2006)
  5. Se till att ha två buffertar för oförutsedda utgifter (October 30, 2006)
  6. Bra tips för den som vill börja fondspara (October 7, 2006)
  7. Light-Hearted Parenting Tips (September 16, 2006)