Last week I had an enjoyable chat with Janet Gregory about risk management. We were discussing how risk management is not one thing, rather it is an attitude or approach. The conversation reminded me why I started this blog.
Earlier this year the system I worked on was subject to a methodology audit. I spent several hours working with the auditor to explain the approach we were taking. At the end of the conversation the auditor said they wanted to use a kanban system to manage their audit process.
Why did the auditor like what I said? Because I explained everything we did in terms of risk. When they asked for a “process”, I explained the risk the process was meant to address. I then explained how our different process addressed the risk more effectively.
A couple of examples.
“Do you have stakeholder sign-off on your requirements to ensure they all agree on the priorities?”
reframed in risk terms as:
“How do we address the risk that we might be building the wrong thing?”
and we addressed as follows:
“Every week we present the status of the list of projects we are working on to the steering committee. The longest we can work on the wrong thing for is one week.”
“Where is your functional spec.”
reframed in risk terms as:
“How do we avoid the risk of building the wrong functionality?”
“We have a two page functional spec. Any more and the stakeholders will not read it. We also have a whole bunch of examples that the stakesholders have verified as correct, and a mock up in Excel so they have an idea of what it will look like. The key is to get quality feedback from the stakeholders rather than get a signature that means nothing. A signed off spec. sort of transfers responsibility from IT to the business for getting the requirements right… but not really. IT will get the blame if it does not work, even if they have it all signed in stone.”
For the fifty or so process audit points we went through each one doing the same kind of thing. Step one, agree the risk the process step is meant to address. Step two, explain how our team addressed it.
The language is important because it helps you think about the problem in the right way.
From my experience, middle and senior IT management respond well to this way of thinking, as do the business investors.
The IT Risk Manager 
December 12th, 2011 at 5:15 pm
Another nice post, Mr Matts.
Congruent with the risk-based agile approach I originated in ’94 and evolved since then, not least during the time of Familiar (and since).
You can see an (old) document describing this at: http://www.fallingblossoms.com/opinion/content?id=1008
I fully agree that characterising aspects of “process” (an ugly word – which I find myself using less and less, nowadays) as risk mitigations pays dividends, both when considering how to improve, as well as when speaking with less-technical folks.
– Bob
December 12th, 2011 at 5:34 pm
This is a really great perspective, really a different way to think. Thank you!
I totally agree on the meaninglessness of “sign off” on “specs”. I worked on a big waterfall project back in the 80s where the customer signed off on a two-inch-thick spec document. It turned out that the specs for the most critical area of the system were a bunch of blank pages. Our manager hadn’t had time to write any of it down, but he assured us it was all in his head. Obviously, the customer didn’t bother to open the document at all.
December 14th, 2011 at 9:33 am
great description of what you have that is missing from most processes as implemented: why certain components of a process exist and why we should either follow or change the process.
The reframing of the questions that you did is brilliant, and can also be used to.challenge particular parts of a process and constantly improve it.
This is also also congruent with my view of the role of process in Agile environments.
December 14th, 2011 at 9:38 am
yes. For me agile has always been about better ways to deal with change. And risk management is about dealing with change.
December 16th, 2011 at 3:18 pm
Thanks for providing the examples – I’ll use those and link to them from my own blog.
I heard Jeff Sutherland say this summer: “Scrum (agile) IS risk management” and I agree. This is one topics I like to have a conversation about when talking to PMs who are learning about agile. Agile helps address:
– Schedule and Estimate risks
– Risk of building the wrong thing
– Architecture risks
– Risk & Issue identification
– Scope risks
– People risks
– Quality risks
– Project cancellation risks
– etc.
December 30th, 2011 at 3:43 am
[…] few weeks ago Chris Matts wrote an interesting blog post ‘the language of risk‘ in which he describes an approach he used to explain the processes his team uses to an […]
January 4th, 2012 at 8:28 am
This is such a great post! Rephrasing the question the way you describe is definitely a tool to be used.
January 13th, 2012 at 6:22 am
[…] The Language of Risk « The IT Risk Manager. (function() { var po = document.createElement('script'); po.type = 'text/javascript'; […]
February 21st, 2015 at 11:53 am
[…] on the role of the IT Project Manager (They are there to manage risk funnily enough). We ran an exercise where each group would pick a process point, and identify the risk it was meant to mitigate. Then they could suggest an alternative process to manage the risk. One group picked […]