Measuring Risk with TRAMS

I’ll let you into a secret. I think trams are pretty cool. I wouldn’t go so far as to say I’m a tramspotter (do they even exist?) but I do quite like them as a mode of transport. In short, trams are pretty smart!

Okay, so what has this got to do with risks? One of the things people sometimes forget is that it doesn’t really matter whether an initiative, project, programme, or whatever you want to call it is Agile or Waterfall, one still has to deal with risks.

The process normally starts with people sat round a table discussing the risks they can foresee in delivering Le nouvel objet brillant with each person racking their brains to come up with everything that could go wrong and proffering it as a risk. Risks are then scored according to some matrix of probability (a.k.a. likelihood), impact, and, in many places, proximity (i.e. how far away from becoming an issue is this risk). Everyone nods earnestly and at some point a risk map is produced. So, what’s the issue ?

Well for one – and one that I’ll posit is familiar to many – many of these risks seem all to familiar as they appear on risk list after risk list. Here’s a few I can think of that I come across quite constantly:

There aren’t enough resource to get the work done on time (either in a specific team or across the initiative as a whole);
We don’t have enough environments;
The user might not sign-off on time;
etc….

But are these risks? Of course, arguably they are at one level but, in fact, they’re not project specific, they’re what I call BAU risks – risks generic to all initiatives, projects, etc. If they’re not specific to the project, one could ask why bother recording them? Indeed, I prefer to be bolder and assert that there is no reason to.

The Flow framework looks to continually remove redundant work out of the system, via the Improvement Kata. If work doesn’t add value, it isn’t neutral, it’s negative. This is for two reasons: the first is entropy; the second is that time spent on what may appear to be neutral activities is actually time that could be spent doing work to add value.

What, then, to do?

Let’s start by defining what a risk is… Hang on… No… Actually, let’s start by defining what a risk isn’t. One thing it isn’t is an issue. This is important to understand. An issue is a risk that has materialised – the thing that you were trying to prevent has happened. Now, you’re not taking actions (tasks – a for of work) to mitigate, instead the goal is to ameliorate the impact; impact already being felt and which may take you away from the real of tame or wicked problems and into critical problems. At this stage your risk should be closed and marked as “materialised” or whatever synonym occurs to your way of thinking.

Okay, so back to what a risk is: A risk is a goal!

What!!! Has the author taken leave of their senses? We’re trying to avoid risks from materialising, not achieve them! I’m done! Whoever wrote this post is stark raving mad – I’m off to think about those crazy times when we could sit in a room together and discuss risks sensibly.

Is that what just went through your head? If so, I encourage you to crawl further along the droseraceae leaf and read on…

A goal, of course, is something we want to achieve. A risk, on the other hand, can be expressed as something we do not want to achieve – where goals matter, risks antimatter; they are the antithesis of a goal. Or, put elsewise: a Risk is the expression of a goal we do not want to achieve.

One of the best ways to think about, and define, goals is by use of SMART Goals. This is where the goal is only really a goal if it is Specific, Measurable, Achievable, Realistic, and Time-bound. This is where TRAMS come in to play. The more astute reader will, of course, have noticed that TRAMS is nothing more than a emordnilap of SMART, sorry a palindrome. For risks, however, we do want to change the meaning of the letters in some cases and this spelling reversal is useful to guide us as to why. Here then is the definition for TRAMS:

Timeliness – if the risk can be quantified in terms of a date when it might materialise into an issue, then it’s not a risk at all. It could be many other things – a complaint that we don’t have enough resource, for instance – but it isn’t a risk.

Realistic – the risk should be realistic. There is, of course, a risk that a meteor smashes into your datacentre but I wouldn’t bother recording it – it belongs with the risk of the sun exploding. Yeah, it can happen but it isn’t realistic to think it might during the lifetime of your implementation work.

Accepted – If you’re the only one who can see the risk, you may have to work harder to get it accepted or accept that it’s not a risk.

Mitigateable – Okay, I’m pretty sure that’s not the right way to conjugate the word mitigate but if you cannot mitigate a risk it isn’t a risk, it’s an issue or a constraint.

Specific – The risk must be specific to the initiative. If it relates to more than one project it might be an enterprise risk or it might just be a general recognition of the cost of doing business. Regardless, burning cycles on it goes against the Flow principles – even if you’re not using Flow, it is possible to recognise when doing something detracts from delivery rather than increases it – and that, of course, increases risk, which is exactly what we want to avoid.

Next time you get involved in a Risk Review, take TRAMS – your destination will be fewer, more focussed, risks that leave more time to do value-adding work.

Leave a Reply Cancel reply