• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Quanifying Risk

Posts: 6049
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Does anyone have any suggestions of how to quantify risk, both estimated and impacted?
Let me give you an example. We recently had to revise our schedule based on some marketing feedback (we need to push back our release date in order to put in more features). All the engineers said the new schedule was possible, but risky, because it was pretty tight. None of us could say exactly how risky.
Right now, we just spent 2 weeks making API changes, cleaning them up. That was also a tight schedule, and the final deadline for them was the date of a build. Needless to say many of us expect there to still be some bugs in the build (fortunately, not a release build), because we were short on time before hand. We're doing another build next week, by which point the bugs should be fixed. We're also moving. They claim is we lose a day. I'm too cynical to believe if we pack up Thursday night, come Monday morning everything will work fine. We also have to do a demo next Tuesday for some potential partners.
Each and every one of these tasks is risky by themselves, as in, may take more time than we have budgeted. It is not clear how much one effects the other, although I know from experience that they do. It's not as simple as, well, if item A is 1 day late, and item B depends on item A, item B is also 1 day late, because things like the demo are "fixed deadline", there's not even any issue of post cleanup.
How do people quantify risk? If I say task A takes 4 days, I could assign a number, like we've got a 70% of doing it in 4 days. But what are the estimates of doing it in 4.5, 5, or 6 days? Should I even list that, and if so how? How does the risk in item A relate to the risk in item B, as explained above? (Seems a little like error bars; and I remeber what a pain it was doing even simply caclulations with error bars.)
Once we do miss a deadline, how do we mark that? How do we mark when the loss has been negated because the length of it's impact has passed (e.g. after the demo, demo issues no longer matter)?

I'm looking for a lightweight process (maybe even just back of the envelope) for this. The project managers are using MS Project; although, again, I'd be happy even if I could spend 5 minutes to show them the risk on a whiteboard, at a macro level.
For the record, we're not normally this bad. I think a whole bunch of changes led to this point we didn't realize how much they would interact with each other until we got here. we all said risk here, risk there, but never put all that risk together. That's what I want to do going forward.

PS How lucky ofr me that this is the hot forum this week, and that we have experts like Martin Fowler involved!
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can get some of the answers by reading this paper. http://ftp.cs.umd.edu/users/sharip/mswe607/risks.htm
Or if you're feeling really masochistic look up the Risk Management articles by "Barry Boehm". Much of this stuff is quite subjective unless a base of historical data is available.
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm not sure that it works well to post risks in terms of days to fix - many of the tougher risks are almost impossible to quantify that way. I like the idea of the top ten risks list (see McConnel's Rapid Development) - choose your biggest risks and rank them. Make sure you revisit the list weekly.
However it sounds like your problem is more about tasks than risks. In which case you need to estimate how long it should take to finish each task, figure out how much time you've got left, and if they don't add up figure out what needs to be deferred.
author of:
Refactoring : Improving the Design of Existing Code
UML Distilled, Second Edition: A Brief Guide to the Standard Object Modeling Language
Analysis Patterns : Reusable Object Models
Planning Extreme Programming
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here is an article illustrating how to prioritize risks that you may be able to get some ideas from.
Or we might never have existed at all. Freaky. So we should cherish everything. Even this tiny ad:
Thread Boost feature
    Bookmark Topic Watch Topic
  • New Topic