"Buying Back" risk

In the September 2005 issue of the Communications of the ACM, Philip Armour touches on a method to keep two plans: the work-to plan, and the commit-to plan. He says that if an organization chooses not to intentionally manage the risk due to uncertainty, that either the customer (through lack of quality) or the development team (through overtime) ultimately pays for the risk as it materializes into problems and issues. I would like to add that the third possible payee is the organization itself, through missed commitments.

I've worked in environments where we had a buffer, but not quite the way he describes. Most places I've worked felt that the buffer would be spent because with lack of pressure, people will work less hard; therefore you will still miss your dates and you will produce less output. However, Mr. Armour talks about a way to consciously manage the buffer which I think alleviates such concerns.

When the initial plan is built, the team puts together a "Management Risk Reserve". If you have metrics from your history, you might be able to do this in a way that scales with the complexity of the project in a very meaningful way. In exchange for regular attention to this reserve by management, the team agrees to try to work to the "work-to" plan, which contains all the things that the team knows they need to do. As work progresses, some risk is reduced, and other risk is realized. It's a short article and not particularly operational, but you can imagine doing this quantitatively on the risk reduction as well as the realization of new work that must be done.

I contend that this is totally doable within an iterative/agile environment. Most organizations still have a long term commitment they want to manage to. Agile development helps you quantify the risk better.