ITML: a funny interpretation of ITIL® framework

I recently got a certification in ITIL® v4 Foundation (ref https://www.axelos.com/best-practice-solutions/itil). ITIL® is an acronym for Information Technology Infrastructure Library. During the preparation course, I realized that the real ICT world sometimes is quite different from what technical literature suggests. But I also realized that mistakes and bad habits follow a schema that repeats over years ad companies.

So, I decided to picture a funny schema which moves on parallel tracks to what ITIL® suggests and gives a funny view of best NOT to do practices.

I defined my model as “Information Technology Mistakes Library”.

What is ITML

ITML is a library of worst practices that no companies want to see, but often appear and need to be managed. This library pictures common guidance which lead to loss of performances and time wasting to people involved, sometimes increasing sales on pharmaceutical calming substances :).

This is obviously a joke exercise, but I bet many people will identify real life scenes of their professional experience.

Key Concept Definitions

ITML relies on some simple key definitions.

Customers: a person who doesn’t know what he wants, but wants it.

Users: a person who claims, even if he doesn’t need the service.

Sponsors: who pay.

Service Provider: an organization who takes money to do what could be done without spending money.

Service Offerings: a catalogue of everything without anything listed.

Service Relationship: relation between two or more people being fan of the same soccer club.

Output: an intangible deliverable composed of something that, in the best case, will be delivered at half. It needs to be compliant with two main truths:

Fit for excuse: it must be impossible to complete, in order to have always a justification
Fit to reschedule: it must be much complex as possible, so that it could never be pretended to be accomplished

Cost: the amount of money that will be consumed always a long time before the project finish

Risk: something intangible that will never be considered at the start, but will ever appear before the end

The PBS (Pass the Buck System)

For ITML to properly represent what should NOT be done, it needs to picture the reality as a System. It represents the INPUTS (opportunity and/or demand) to this system, and expected OUTPUTS (Questions which are not answering to the input but are generating more confusion and time wasting).

Passing the Buck System

The ITML PBS is composed from the following elements:

One Principle: NOT DO – Simple recommendation that will ever assure responsibilities avoiding

Holistic Governance – The way to avoid to take responsibility, just by complaining someone else as needed

Question Dispatching System – A set of interconnected ways to perform actions in order to assure that responsibilities are in charge to other people

Best Excuses Practices – Set of professional answers designed for every task/activity to avoid doing it

Never Improve (if works) – A recurring organizational goal ensuring that the hope of eternity could occur

These elements are going to be deeply developed in next editions of ITML, but everyone could already identify this system in its real life.

Question Dispatching System

The central and most important element of PBS is, of course, the Question Dispatching System. It helps to identify an operational model able to fit every demand request and elaborate the expected output.

The six main Question Dispatching activities are:

Wait: The purpose of wait is the expectation that someone will do the mistake of answer before the demand could escalate to higher levels

Never Improve (if works): the purpose of the Never Improve activity is to assure that no errors could be blamed to people not changing things

Engage: The purpose of engage activity is making it known to most people as possible the risks of acting

Ask: The purpose of Ask activity is to ensure that change decisions could be routed to someone else

Obtain, don’t Build: The purpose of Obtain activity is to assure that service components issues could be claimed to someone else

Move Responsibilities: The purpose of Move Responsibilities activity is to ensure that services faults and issues responsibilities are switched to other people.