RRR, The Triple-R

The first thing I don’t often get to do is create wireframes to facilitate requirements elicitation and process mapping. My love of visual design has expanded to a nearly absurd level over the past 3 years and I now find that there is little that gives me more fulfillment than using visual representations to flesh out requirements.

Second to wireframes is facilitating requirements elicitation sessions (using those previously mentioned wireframes). One of the ‘trick’s I’ve started doing is to intentionally provide my users with 'broken’ wireframes. I give them something that has blatant holes to force them to say, “No, you’ve got that wrong! Take a piece from the first iteration, add in a part from the second one and slap them all on the layout of the third!” It is truly amazing how your stakeholders will figure out their own requirements just by being able to pick out your (unknowingly) 'bad designs’.

That’s all good, you say, but what is this 'Triple R’ thing in the title that you’re not talking about. One of the things that makes the program I’m talking about so big is that there are many ways in which we could go about accomplishing the exact same goal. Different people within the organization, myself included, have our preferred methods. We all have sound reasons for why we think our path is the right one, most of which completely differ from anyone else’s logic. Before we can get on with the work, we need to figure out what pieces of work we will do, in what order and with what technology stack.

In a meeting earlier this week, a subset team outlined 6 different alternatives that could be used to reach the same eventual goal. After we 'named’ the different paths, we began to put together a list of items we need to create in order to provide a recommendation to senior management on what roadmap we’ll be following to reach the goals we’ve been given.

We started with a list of Pros and Cons. We talked timelines, both for implementation of the first phase and project completion. Budgetary concerns were raised. Business and technical acumen was discussed. At the end, we had a list of areas that needed to be covered in our presentation, but as I looked at the list, I felt like something was missing. That’s when it hit me, we were missing Risk.

Each of the six options we had outlined were risky. If you put them all on a scale of 0-100, all of them were 80+. What we’re doing is risky and there is no way for it to be anything else. Given that the scope of the program will touch nearly everything in our organization, it will simply be a risky venture.

Yes, there are ways to minimize or shift away the risk. We create plans, we build contingencies and eventually we just have to accept some level of risk as being a part of the game. What concerned me is two things: what was the type of risk in each of the solutions and what are the risks that are not shared by all the options.

We know all about the different types of risk: business, technical, regulatory, financial; the list goes on and on. Each of those six solutions had different types of risk, but I wanted to know what type of risk, and the degree of risk, that is specific to one or more, but not all, of the options. Knowing this information allows us to boost the signal to noise ratio; helping our executive team focus on the actual risks within the solutions and not get stuck on the risks they can’t change.

As I looked at each of the solutions, they really fell into a couple different types of risk. Some of the solutions were built on technology that has been proven out, so its technical risk is lower. Other solutions follow a build-in-pieces methodology and thus provide a significantly lower organization change risk. Some of the solutions rely, to a greater extent, on 3rd party software licenses and thus, pose a greater financial risk.

With the risk profile so high for each of the options, its important to not only find the types of risk, but to understand that risk is relative. That brings us to the 3 R’s, or what I ended up calling the Relative Risk Rating. My suggestion to the group was to not try and minimize the risk rating on any of the options, but given them a rating in relation to each of the other options. Given that each of the options likely had an 80+ total rating, I was suggesting ratings such as High, Higher and Highest, with details next to those ratings about which groups in the organization would bear the largest risk burdens.

The team liked the idea and we’re going to give it a try. We’re just now started putting together the format, so we don’t have a final look and feel for it all, but I can’t wait to see what the team comes up with and how it ends up influencing the final decision.

What are some ways you have used to explain risk to your sponsors? Would the Triple-R work for your organization? Let us know in the comments!