Information Technology Dark Side

Struggles of a Self-Taught Coder

Information Technology Dark Side header image 2

Estimating Project Risk

February 25th, 2008 · 2 Comments

Most risk management approaches work something like this:
1) Keep a list of risks
2) Estimate the likelihood the risk will occur (call it X)
3) Estimate the cost the risk will create if it occurs (call it Y)
4) X times Y is supposed to tell you something useful – it might be the amount of contingency you need for the risk, or something like that.
5) When the risks you anticipated happen, they become issues
6) When the risks you didn’t anticipate happen, you become a former project manager

I don’t really find this stuff useful on my projects. I’m not sure there’s any scientific research supporting the effectiveness of this approach, but I’d be surprised if there was any. Of all the “professions” project management seems to be one of the most easily infiltrated by anecdote and myth – I think the discipline of software project management is still so young that not many practitioners have begun questioning it’s foundations. The earth is still flat for IT project management, sadly. There are those who know the earth is round, like Johanna Rothman and the Poppendieck’s, but they aren’t enough to stop the massive institutional brainwashing of young project managers into phased development (aka waterfall).

But I digress. Here’s an alternative way to evaluate project risk that I think is much more useful.

Project risk grows exponentially with the smallest unit of time in which you can regularly deliver valuable working software.

If I didn’t lose you with my completely random outburst in the second paragraph, I probably lost you with the exponential stuff. Here’s what I mean:

If you can deliver valuable working software every two months (start-to-finish) then your overall project risk is pretty low. Why? Because every two months you get to re-adjust, re-plan, and re-prioritize with the people who care about your project, and any mistakes can be fixed in two months or less.

Projects requiring six months to deliver valuable working software should automatically be considered medium to high risk of outright failure.
Sometimes, the delivery of valuable working software takes longer, say six months or so of work. This sucks, but it happens. This is a lot higher risk, a lot more than three times as risky. I’d suggest it’s about ten times as risky. You are ten times as likely to fail at a six month effort than a two month effort. Risk of bad stuff grows exponentially the longer you are exposed to them. Here’s an example, albeit a bit morbid: What are the odds one of your team members will collapse and die tomorrow? Pretty slim, I hope. But, what are the odds that one of your team members will die, quit, get re-assigned, get sick, or go on maternity leave in the next six months? Much higher.

Long odds for long deliveries
Projects that invest twelve months or more before there is a return have extremely high failure rates. I believe they are at least 100 times more likely to fail than projects that can deliver valuable working software in two-month units. These projects should be considered extremely high risk. I have always managed to stay away from projects that have twelve months between start and delivery, and I thank my lucky stars for that.

Long projects don’t have to have long delivery cycles
I just finished an eighteen month project that had a multi-million dollar budget, but not once did I start an iteration that lasted more than two or three months. We never attempted to build anything we couldn’t do in two or three months, and we always had a pretty small team. Sometimes we had multiple small things working on parallel threads, but they always delivered valuable software that worked in a short time frame. It was a weird feeling last month when we shipped the last release and realized we were done. It was like we had moved a mountain, one pebble at a time, and we didn’t really see the mountain had moved until the last pebble was gone. It didn’t feel like we’d just moved a mountain – more like we’d just had a reasonably nice stretch of work, busy but not buried, challenged but not hopeless. It felt good.

Control the delivery cycle and you have controlled the risk
Creative people with decent technical backgrounds and an interest in the needs of their business partners can find ways to divide projects into smaller feature sets that can be delivered in two months. And, if you can manage to structure your project in two month chunks, you have just dramatically reduced the overall risk of your project and created a project structure that is more easily adapted to the potentially changing needs of your biz partners. It also reduces the tendency of team members to create unnecessary work or to argue to long about anything – urgency is something you can feel on two month projects.

You might think I’m full of crap. Go ahead and tell me so, I don’t care. But try it. Now. Don’t wait for your twelve month project to go eleven months without shipping jack to give something like this a shot. What can it hurt you to try it? It’s not like you’re going to look like an idiot for delivering something quickly, and what if it really can reduce the risk of your project by a factor of 100? It’s not like you were planning on shipping anything in month three anyway…


If you enjoyed this post, make sure you subscribe to my RSS feed!
Stumble it!

Tags: Project Management

2 responses so far ↓

  • 1 takacsot // Jun 15, 2009 at 12:01 pm


    "Control the delivery cycle and you have controlled the risk "

    This is so true!

  • 2 Pdf SE // Aug 7, 2010 at 8:32 am

    This is a very interesting article. When you have business you have to assess risks but usually it is very subjective. But I like your system very much, especially “Project risk grows exponentially with the smallest unit of time in which you can regularly deliver valuable working software.” I’m sure soon it will be one of the rules in estimating project risks.

Leave a Comment