These days I don’t think much about risks and instead think a lot about a more general idea: uncertainty. This is an illustration to suggest why that is valuable. I hope in the future to write in more detail about this shift in thinking, but for the moment I’ll demonstrate by example.
Before I discovered Agile my projects were typically troubled—generally successful, but very stressful and always difficult. Being a responsible project manager I always had a risk register with risk weightings, costed impacts, and a mitigation strategy for each risk. The risks I listed were things like “database not sufficiently performant” or “hardware does not arrive on time”. The mitigation strategies, unfortunately, were not too helpful. There were things like “monitor database performance” or “order hardware in good time”. Good sense, but nothing original. In fact, they were tantamount to “Nik will do his job properly”. The suggested actions were nothing I wouldn’t normally do, so the risk register didn’t feel very useful.
Fortunately (or not) that didn’t matter, because the things that caused the trouble were generally of a different nature altogether. They were typically around the client changing their mind, things taking longer than expected, last minute design changes, and so on. Nothing that appeared on the risk register, and nothing I’d consider specific risks. I generally considered this part of the cut and thrust of project management life. It certainly kept things interesting.
After I discovered and implemented Agile things got a whole lot better for my projects and for the people who wanted the things from the projects. Why did Agile make a difference? Because it dealt with the uncertainty that was fundamental to the main activity: technology development. This is complicated, usually involves integrating things which no-one has integrated before, and building things which people aren’t all 100% clear about.
By picking out individual risks from the work in front of me I’d failed to see the uncertainty of the work itself. Or to put it another way: I failed to see the wood for the trees. By changing working practices specifically to accommodate the uncertainties of the work I had dealt with the vast majority of potential problems.
I now see picking out individual risks as a distraction. Looking for uncertainty, and changing processes accordingly, is much more fruitful.
If you want to read more on this kind of thing then I will recommend (again) the website Working In Uncertainty, by Matthew Leitch.
niksilver.com 