Every organisation will have something that appears to be straightforward but somehow they make a mess of it! And what is more frustrating is that it is easy to articulate the problem yet the solution is far more complex.

Often these seemingly straightforward issues have the characteristic of being an event that may be anticipated generally; but each specific instance, each triggering, has nuances.

We think we know what happens to ripples when a pebble lands in a pond. But the ripples are influenced by other waves so they may never reach the shore as intended.

Waterfall and ripples on the surface

In organisations these triggers result in activities rippling out to different teams and systems. The triggered event is only complete when all those ripples have reached their destination and been absorbed. Unless they reflect, which results in more complexity.

Enough of the analogies. How about a real world example with real people?

At The University of Edinburgh we have recently been through a major procurement of an integrated core system that will better address many but not all our staff lifecycle events. When staff start, leave or move internally, it very easy to articulate the trigger: “James has just started” or “James has moved to a new job with another team”. However the ripples from that articulated trigger, the workflows are many and complex. The central ones may be largely automated, but the more local ones may not be. They may rely on knowledge written done. And the people who know where that is documented may have moved or retired.

So if James moves to another team, there are Human Resources and Payroll processes to check, but additionally there are group memberships to be reviewed to ensure the permissions to do the new role are added and more importantly permissions that were only needed for the old role are removed. This could be as simple as ensuring a key for the bicycle shed is handed back!

If not done as a result of a trigger, incidents are more likely to occur. There may not be enough keys for the new person wishing to use the bicycle shed.

The incidents occur because the communication is poor, the accountability is unclear and tracking is not done.

So what else might fall into this class of triggers that are easy to articulate but may result in inadequate process. Here is a list of some triggers collated over time that have exhibited incidents because the ripples were not fully understood.

• Internal staff moves
• Office moves
• Addition or removal of network ranges
• Server commissioning/decommissioning

The key point here is that these all events that can be anticipated. In theory they may templated.

Can ITIL Service Management processes help? Indubitably.

These are examples of processes that may be templated within Change Management, triggering trackable Change Activities to the appropriate teams. These teams can decide if some thing needs to occur, but they must acknowledge the trigger. They are accountable if they decide to do nothing.

Different service management tools will provide functionalities to do this. At Edinburgh we are using UniDesk (which provides a version of TOPdesk for Universities and Colleges).

On of the examples above, the addition or removal of a network range, has proven particularly thorny in the past. We have recently collated some of the triggered activities into a Change Template such that with next occurrence, the workflows may be better distributed and monitored for completion

In the screen shot of the tool, once the trigger has been authorised and verified, a series of activity tasks are assigned to different teams. Most of these may occur in parallel. Finally, there may be a local set of activities.

Change Template for Adding (or Removing) Network Address Ranges

Over the time triggered activities can be modified, retired or added even though the trigger still exists. So we generalise the processes arising from the trigger and delegate the details to appropriate specialist teams, yet still hold them accountable for responding appropriately. In the example shown, each of the teams were willing to come on board with this process. And by doing so, at a stroke, complicated things can now be actioned and tracked when something easy to say is requested.

(Copyright 2012 James Jarvis)

(2020 Copyright The University of Edinburgh)

Easier said than done… the curse of “triggers” / ITIL Tattle by blogadmin is licensed under a Creative Commons Attribution CC BY 3.0