An IT Service Manager within an emergency services organisation once asked me the following question:
“Our primary objective is to save lives and as a Service Manager within the organisation what I do appears to be far removed from this.
How do I, or can I relate my performance measures to this objective?”
This is a common problem. How to relate what I do to the objective of the organisation?
Ideally the organisations mission and objective should be set first and cascaded down through the organisation. Each objective set for each division, department, team and person within the organisation should relate back to the overall objective and be visible to every person within the organisation. In this way, everyone can see how their performance relates to the objective of the organisation and can be measured against it.
However, more often than not, this does not happen and individuals and teams set their own objectives in order to be able to measure performance but they do not relate to the organisational objective, as this has not been communicated effectively. It is then difficult for individuals to understand their contribution to the overall objective of the organisation.
As a Service Management consultant I often hear IT staff stating that their role is, for example, “to fix the network”. I then ask why and the reply is “because it is broken” and then I ask why again and the response is “because the Service Desk sent me an Incident”……and so on and so on. The questioning can continue for a long while before we get to the point where the individual states that they are fixing the network because there is customer who wants to buy a tin of beans from their local supermarket! They understand that the organisation is in the food retail business, but they don’t relate their role to the overall organisational objective.
So, how can we overcome this? How can we relate our role in the organisation to the overall objective?
One method I have used is to utilise some of the techniques used within Problem Management. I have done this with various IT teams to help them understand their role and it has the impact of them understanding their importance and the vital role they have to play. It also helps staff understand the consequences of not doing a good job and the impacts that it can have.
One such technique is Cause and Effect Analysis.
A Cause-and-Effect Diagram (also known as a “Fishbone Diagram”) is a graphical technique for grouping people’s ideas about the causes of a problem.
The cause & effect diagram is the brainchild of Kaoru Ishikawa, who pioneered quality management processes in the Kawasaki ship-yards and in the process, became one of the founding fathers of modern management.
In the question it is stated that the objective of the organisation is to save lives. So find an instance where the objective failed and use the Cause and Effect diagram to determine the causes of the problem.
Using a Cause-and-Effect Diagram forces the team to consider the complexity of the problem and to take an objective look at all the contributing factors. It helps the team to determine both the primary and the secondary causes of a problem and is helpful for organising the ideas generated from a brainstorming session.
It is used after the causes have been grouped by relationships (for example, by using a Causal Table).
A Causal Table, also known as the Why-Because Technique, allows the team to analyse the root cause(s) of a problem. As well as being an important step in constructing a Cause-and Effect diagram. It can also be used on its own to help analyse a problem.
Create a table (see example below):
Conduct two brainstorming sessions with the team to find out the team’s ideas about the causes of a problem:
The first time, the team brainstorms the evident or immediate causes of the problem (the why). List these under “Why” in the chart.
The second time, the team analyses each immediate cause by considering the question “Why is this a Problem? Because….” Write in the answers under “Because” in the table. This step will help the team determine the root causes. End the analysis when you reach causes over which you have no control.
|Why did the patient die?||Because they were allergic to the drugs administered|
|Why didn’t the doctor know they were allergic?||Because the doctor did not have access to the patients records|
|Why didn’t they have access to the records?||Because service 302 exceeded its capacity threshold|
|Why did server 302 exceed its capacity threshold?||Because the workload has increased|
|Why did the workload increase?||Because the media department was moved to East Building and they now connect to server 302 which placed additional workload on server 302|
|Why was server 302 capacity not considered as part of the move?||Because physical moves are not a part of the Change Management process|
In the above example, the root cause was due to the lack of procedure to check the capacity requirements when departments are relocated. If additional capacity is added to server 302, this will not stop this type of problem from recurring as it is the process that is at the root cause.
Now, illustrate graphically the causes grouped by relationships by using the Cause-and-Effect Diagram where:
- The problem under investigation is described in a box at the head of the diagram.
- A long spine with an arrow pointing towards the head forms the backbone of the “fish.” The direction of the arrow indicates that the items that feed into the spine might cause the problem described in the head.
- A few large bones feed into the spine. These large bones represent the main categories of potential causes of the problem. Again, the arrows represent the direction of the action; the items on the larger bones are thought to cause the problem in the head.
The categories you use are up to you to decide. In an IT environment a suggestion is:
- Processes / procedures
- Organisation / Environment
The smaller bones represent deeper causes of the larger bones they are attached to. Each bone is a link in a Cause-and-Effect chain that leads from the deepest causes to the targeted problem. The following diagram is a fishbone template.
The following is an example of a completed template.
Once the fishbone is complete, you are well on your way to understanding the root causes of the problem.
It can then be seen what the contribution of IT was to that problem – the technology, the people, the processes and the organisation. In this way, staff can see how they contributed to the failure of the organisations objective and how they can resolve the situation to ensure that they now contribute to the achievement of the organisations objective.
MACANTA can help you link your objectives to organisational goals with our Strategy Generation service.
Karen Ferris is a Director of Macanta Consulting and can be contacted at Karen.Ferris@macanta.com.au