One of the interesting situations that occurs when we play the risk acceptance game at large organisations, is how we are able to find out exactly who is making business and technical decisions.
Initially, when a ‘Risk Accepted’ request is made, what tends to happen is that the risk is pushed up the management chain, where each player pushes to their boss to accept risk. After all, what is at stake is who will take responsibility for that risk, and in some cases, who might be fired for it.
Eventually there is a moment when a senior director (or even the CTO) resists accepting the risk and pushes it down. What he is saying at that moment in time, is that the decision to accept that particular risk, has to be made by someone else, who has been delegated (officially or implicitly) that responsibility.
In some cases this can now go all the way down to the actual developer/team doing the coding. Paradoxically, usually the developer didn’t realised until that moment, that he is one that is actually deciding how and when to fix it (or not).
Developers often hold a huge amount of power, but they just don’t know it.
Playing the risk acceptance game, and identifying who is deciding on risk, is a way of empowering the actual decision-maker. Once the person realises their role and power, they can make sure they have realistic time-scales to fix the issue accordingly, and when required, make the case for more time, more resources, or even a more defined role as a decision-maker.
This exercise is very important because, until you discover who clicks on the ‘Accept Risk’ button, there is little knowledge about who (if anybody at all) is making important decisions.
Risk issues can only be on one of two moving paths: ‘Fixing path’ and ‘Risk Acceptance path’. Since deciding not to act on a particular issue is a decision in itself, the Risk workflow makes sure that issues don’t ‘disappear’ in informal conversions, emails or documents.
This is also a good example why Pollution is a better analogy than Technical Debt. Features that are pushed with un-realistic deadlines or bad briefs will create a higher number of Risk tickets (i.e. pollution) which will have to be accepted by the business owners (who agreed on the development brief and time-scales)
(from Jira RISK Workflow book)
