The Language of Risk

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.

About these ads

About theitriskmanager

A IT programme manager specialising in delivering trading and risk management systems in Investment Banks. I achieve this by focusing on risk rather than cost. A focus on costs can lead to increased costs. View all posts by theitriskmanager

8 responses to “The Language of Risk

  • Bob Marshall (@flowchainsensei)

    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

  • lisacrispin

    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.

  • Vasco Duarte

    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.

  • Yves Hanoulle (@YvesHanoulle)

    yes. For me agile has always been about better ways to deal with change. And risk management is about dealing with change.

  • Steve

    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.

  • The Language of Risk at Mark Needham

    [...] 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 [...]

  • Flavius Stef

    This is such a great post! Rephrasing the question the way you describe is definitely a tool to be used.

  • The Language of Risk « The IT Risk Manager | Kapil | Scratch Pad | Java | Architecture | Design | Open Source

    [...] The Language of Risk « The IT Risk Manager. (function() { var po = document.createElement('script'); po.type = 'text/javascript'; [...]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 48 other followers

%d bloggers like this: