Close this search box.

A Series of Symbiotic Events (2nd)

Many of the problems with Event Management can be tracked back to the planning stage

Event the Second: The Plan

In the first “event” of this series I discussed “The Party” – I started there to establish that the satisfaction of your IT customer is dependent on the way you handle the many types of ‘events’ that support the ‘Main Event’ enjoyed (hopefully) by your customer: the enablement of what they need to do for themselves or their customers.

Everyone wants their “main event” to be a success. But for any big event (or a business) to deliver the kind of experience those attending it hope for, there has to be a plan behind it to ensure it goes as hoped for, and to account for responses for all the smaller events that occur while it is running.

Yes, I know – the need for a plan is not a revelation for ITSM folks. After all, most any person in the business world has encountered the Shewhart/Deming/PDCA etc. cycle at some point. Most everything follows it or is somehow based on it. Plus there is all that stuff in ITIL Service Strategy and Service Design (and more)! Everyone knows you have to have a plan! Right? Well…

If it’s so obvious….

Despite the availability of all this knowledge and wisdom, the failure of many business agendas (projects, goals, etc.) continues to be traced to conditions that were not planned for. Though we all generally acknowledge that most everything should start with some kind of planning, it’s an activity I have called out before as something a majority of us are simply not that good at. This of course does not stop us from throwing parties, but it is the major difference between “It was okay” and “Man, that was epic!”

In fact, many businesses still handle event management at the ‘it was okay’ level (if that). There of course are numerous reasons, covered in ITIL and other guidance, which often distill into one distinct driver: it is not easy to administer effective event management at levels above this. It takes work, and involves continuous adjustment based on activities and data in other process areas ending with ‘management’, such as (to name a few), Service Level, Capacity, Availability, Configuration, Operations, Incident, Problem, etc.

It also takes resources and yes, funding – both of which are very difficult to obtain when you are trying to sell the idea that by planning things out you can make everything work better, but can’t prove it until you can do it – but Six Sigma, Project Management, ITIL and others all offer guidance for that too.

So what’s the real problem?

There is more than enough good direction available out there already about the need for a plan. I believe the real problem isn’t that people don’t create a plan (even though that does happen – go figure), but that the plan they create does not consider and account for the right relationships. Let’s consider a simple goal many people have every day: driving to work.

For many, the plan for this goal looks similar to this:


(Click on image to enlarge)

Yup, it is very basic; this is pretty much the ‘no real plan handle as incident management’ event plan – and it is more common than anyone wants to admit. And please don’t compare it to “putting out fires”. Firemen have plans for that – good ones, that involve plenty of extensive training and skill – so let’s not insult them.

Then we have the ‘common things accounted for’ version:


(Click on image to enlarge)

The equivalent can be widely found in business, with some things, such as capacity or availability being considered. Better, but again, pretty dependent on Incident management for anything not called out.

But if you are an IT provider (for example), you really want your plans to look more like this:


(Click on image to enlarge)

A few things to note: First, remember I told you this was an example of a simple goal. Second (and the quicker of you may have already noticed), there is actually more than one plan represented here (and I did not diagram quite a few more things that also could have been accounted for). All of the represented things have further details we could include, and there are more variations…well, you get the idea. Now extend this concept to account for everything that enables your customer to do everything they need to do that depends on everything you do, and try not to pass out. It may seem unmanageable!

One piece at a time…

But really, it isn’t. It just requires you to take the time to map it all out, hopefully with plenty of help, to prepare for the event relationships that will keep your customer happy. That makes it demanding, but not impossible.

The thing to remember is this: There is no plan that actually is only one plan. There are always other factors, conditions and influences that need a plan of their own. Your task in preparing for the kind of widely expanded view I present of event management is to identify the plan for those things, and how the plans act on each other. This is how you build the end to end ‘lifecycle’ ITIL espouses. By understanding that ‘end to end’ is in fact a series of events (and plans) that have symbiotic effects, you have a basis to begin preparing an event management ‘road map’.

Of course, one common challenge in preparing for event management is the fact that in most every case, the party is already in full swing by the time anyone realizes they should be doing event management. This of course makes most efforts one of improvement rather than true preparation. This actually tends to be an advantage of sorts, since it allows you to measure what is really occurring as opposed to speculating.

With this in mind, to begin, go to the party (yes, LEAN folks, go to the genba). Observe your customer’s business. Know how it works. Before you can understand what it will take to deliver what you need to, you must understand what they actually require from you to enable them to succeed. Always remember to plan starting from the customer back, not from you to the customer. Your customer views the world from their end (their business and their customers) – not from yours. Make sure you plan that way!

Next time we meet, I will, as promised, provide more detail regarding the variations on the interactions that make up the operation of event management in Event the Third: One Hand Washes the Other. Hope to see you there!


Light green canvas Freshworks and Device 42 logos with a friendly robot reflecting the news: Freshwork acquires Device42.
Hands typing on a laptop with digital icons, representing "What is Enterprise Service Management."

Explore our topics