Technique (Tech) Tools
RITO
Risks Issues Threats Opportunities
I'm sure you are aware of the meaning of these words in the context of an organisation, but for the sake of completeness I'll summarise:
- A risk is a event that might happen. Crucially there is a probability that it may or may not happen and, should it happen, there would be a consequence to the organisation. The most important thing about identifying a risk is to develop mitigation actions to reduce the probability that the event will happen and then reduce consequence if it does. For example, you consider one person on your team of particular importance for a project to complete successfully. The risk is they leave your organisation before the end of the project. The mitigation action is to discuss with them how they are feeling about their role to see if any improvements can be made, and possibly to offer them a bonus based on project completion. In parallel start a search within your network to identify a possible replacement for this employee, and make sure that all project documentation and records are up to date.
- An issue may be described as a risk that has happened. You are now living with the consequences, and have to take action to deal with and shut down the issue. Continuing with our example, imagine the employee, despite the offer of a bonus, has decided to leave your organisation. Because you engaged in risk mitigation actions, you have identified a candidate who could take over that role. It will take a while for that person to get up to speed, but you are confident that the project documentation is up to date, so that really should help.
- A threat is similar in nature to a risk but is perhaps broader and more generic. When taking on a significant change project within an organisation, the classic threat is that the change project will overwhelm the staff who are trying to do their jobs and now have to work on the change project as well. An analysis of that threat would tell you that for the change project to be successful you have to create a new organisational structure. You want your best people moved into project roles and then their positions back-filled by temporary or contract staff to ensure the organisation keeps functioning.
- An opportunity can bring huge benefits to an organisation if you know how to spot them and actively look for them. Typically this is the one area that is neglected because everybody is worried about bad things happening. Spotting a really good opportunity can redefine and re-invigorate an organisation. One of the most famous opportunities has to be the iPhone. Nokia had a phone with apps long before Apple. Apple had a computer tablet type thing with apps in the form of Newton. But it was only when Apple saw the opportunity to combine a computer based phone, with third party developers, with an app store and control distribution and revenue that the idea became real. That was a great opportunity observed and then executed, and fortunes made.
The technique is to analyse your situation and simply make a RITO list complete with mitigation actions - and then follow through on those actions. Thinking about our Cellar Door example:
- A risk is that our lack of experience in implementing systems like a CRM means we get taken for a ride by a supplier, we get something that is very complicated to operate and it costs us a fortune. Our mitigation action has to be to get hold of somebody we trust who is really going to help us.
- The issue we have is that the customer card index is very valuable to us but a real pain to use and keep up to date. Perhaps a way of dealing with this is to transfer data to a spreadsheet bit by bit as we access the data. We do it carefully and over time, putting new customers directly into the spreadsheet. Then, when we do decide on the CRM, at least we will have electronic data to migrate.
- The threat is that we are winemakers, sommeliers, chefs and waiters - not IT project people - and we still have a business to run. We can't do those jobs and get involved in a big project.
- The opportunity though is huge. If we can use the CRM to get real insights into what type of customer is buying which types of wine we could significantly improve our sales strategies and translate that into greater revenues.
Ishikawa
Ishikawa diagrams (also called fishbone diagrams, herringbone diagrams, cause-and-effect diagrams, or Fishikawa) are causal diagrams invented by Kaoru Ishikawa that show the causes of a specific event.
Typically a risk, issue, threat or opportunity is not brought about by a single circumstance. Usually a combination of factors has to occur to create the risk, issue, threat or opportunity. The Ishikawa diagram can be used as a tool to help deconstruct these things with the aim of revealing true or common causes. For example, three parts of an organisation - say finance, logistics and customer service - suddenly all experience issues which are quite different in nature. An Ishikawa diagram for each issue may reveal, for example, that they all stem from the fact that a major supplier has changed their ordering and invoicing system.
When developing an Ishikawa diagram it can be helpful to use another technique called 5 Whys. You start with a premise and ask Why? five times. By the fifth Why? you have usually found the root problem. For example:
- Why were the solid rocket boosters on the Space Shuttle the size they were? Well, they had to provide the right amount of lift, but also they were transported by train to the launch pad.
- Why was being transported by train significant? Well, the strength of some bridges and the size of some rail tunnels constrained the weight and dimensions of the boosters.
- Why were rail tunnels built the size they were? Well, building tunnels is expensive so they couldn't just be huge. They built them to fit the trains of the time.
- Why were the trains that size? Well, trains were kind of based on the horse drawn carriages they were replacing. Initially at least they were similar in terms of width to those carriages.
- Why were carriages the size they were? Well, they built them to be the width of the two horses that pulled the carriage.
- Seriously, you're telling me the dimensions of a rocket booster is determined by the width of a horse's arse? Well ...
An example of an Ishikawa diagram examining issues with a release of software that did not go well.
Prioritisation grid
The Prioritisation grid comes from Richard Bolles best selling book “What color is your parachute”. It is a great device for deriving a prioritised list of up to ten items. It works simply by allowing the user to compare all the possible pair combinations of items and then derive a score. The item with the highest score is the highest priority.
The prioritisation grid is used to compare items such as issues and threats to help a group determine which they believe to be the most significant and therefore which should be addressed first. It is also helpful with risks in situations where risks score equally in terms of probability and consequence.
With our Cellar Door example, all our analysis hopefully will have resulted in some kind of feature list, a list of features and functions that we really want our CRM to deliver. At that point we could use a prioritisation grid to order those features by importance to the Cellar Door. That gives us a great insight into what we want which is very valuable should we start talking to CRM suppliers.
An example of a completed prioritisation grid examining a person's working environment preferences.