Posted by: communicationcloud | October 18, 2009

Taming the uncertainty in your projects

We recently had a visitor at Red Gate. Tim Lister – a software development project expert – came to help us review the way we operate, and also delivered a set of talks about different aspects of software project management.

In one of the talks, Tim covered the often-undervalued skill of estimating. Tim advises taking estimation seriously, and not allowing it to be something that’s done once at the start of a project and then never revisited as the project develops; instead, estimates should be honed as the project progresses and new knowledge emerges.

One of his main points was that what often happens with estimating is that people who know what they’re talking about spend time coming up with realistic estimates … only to be told by their managers that the estimates are wrong (wrong = not the answer that management wanted to hear). This obviously counts as “not taking estimation seriously”. A familiar situation to all, I’m sure, but still pleasing to hear it acknowledged out loud, in public.

Understanding uncertainty

Another of the reasons that estimation is difficult is because of the range and scale of project uncertainties. Tim had a nice analogy that neatly captured the 2 main types of project uncertainty, based on the idea of a project as a way of travelling from one place to another.

1. Uncertainty about the journey

Sometimes in a project, you know where you’re trying to get to, but you don’t know how you’re going to get there. This seems particularly relevant to software development, where a lot of the complexity of the project centres around working out what needs to happen to implement a set of features – what technologies, architecture or algorithms will be needed.

2. Uncertainty about the destination

Other times, you can be pretty sure of the steps and actions you’ll need to take, but you have no idea what the end-result will need to be like. I’ve found this is often the case with technical communication projects – particularly ones which are part of a software development project. As a technical author, you know early on in a project that you’ll need to analyse tasks, understand functionality, and work out what users need to know about … but you have no idea what you’ll actually be writing about until very late in the project (often way too late!).

The role of uncertainty in project estimates

Uncertainty is an accepted – and necessary – part of a project,and is almost always the site of the main project risks. The type and scale of uncertainty will change during the life of a project, and different aspects of the project will have different types of uncertainty (e.g. software development vs. technical authoring). Estimates can reflect this uncertainty, and adapt as the uncertainty changes, and by understanding your uncertainty, you can also get a better feeling for the likely accuracy of your estimates.

Where the project has uncertainty of both destination and journey, though, alarm bells should be ringing. It’s a sign of seriously high risk. Projects like this do go ahead, though; in fact I bet everyone’s had an experience of one at some point!



  1. In order to create estimates with any reliability, you have to have some kind of records or recorded metrics of previous projects to base them on. If the doc team doesn’t keep some kind of records of how long different sizes of projects have taken to complete (with some measure of how complete or incomplete the project/ product being documented was when documentation started, they will not have anything to base an estimate (with appropriate qualifying fudge factors) on for future projects. the records should also record the revisions to early estimaes, and the reason for revision.

    • Good point, Margaret: estimation doesn’t need to start fresh with each project; we can develop initial estimates through a combination of skill and knowledge about previous experience, and then update as our experience grows.

      Unfortunately, in many of the projects I work on the “uncertainty about the destination” is so great that it’s not possible at the outset to work out what is an equivalent project to use as the basis of our estimates. As a result we end up setting out nearly “blind” – with very rough estimates – and can only draw on our previous experience as the project begins to take shape. This doesn’t need to be a problem, though, as long as everyone recognises the likely inaccuracy of these initial estimates.

      I think that’s where Tim Lister’s insistence that you keep revisiting and updating estimates comes in: you can only tame the uncertainty by looking it straight in the eyes, repeatedly, and seeing it for just what it is. Pretending that estimates about timescales or delivery dates are fact is a sure way to create an out of control project, that’s no fun for anyone to work on!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


%d bloggers like this: