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.
--Mark
hershey@vaultus.com PS How lucky ofr me that this is the hot forum this week, and that we have experts like Martin Fowler involved!
