Skip to content
Service Delivery Community

My contribution to the ITIL Manifesto #ITILManifesto

Hi mates, this is my contribution to the ITIL Manifesto initiative (your comments are welcome!):

Service Proactivity (Delivery) over Service Reactivity (Support)
Customer Experience over Only Reaching SLA
Agile Change Delivery over Traditional Change Management (delaying improvements)
Cross-Technology “Service Teams” over Technology-based Teams

Proactive Service Management over Reactive Service Management

Many organizations implemented ITIL when it was in its version 2. All of them started with Service Support processes implementation and most of them did very little in the Service Delivery area. This was a poor ITIL implementation, because the “Service” that customers expect every day is about Service Delivery, not in getting solved unnecesary Incidents, Service Requests and Changes for fixing Problems.

Customer Experience over Only Reaching SLA

Many IT Organizations and Service Providers are more focussed on reaching SLA than working on delivering a great Custmer Experience. Remember: by using SLA (the tool) we expect to deliver a great Customer Experience (the goal). If any time you need to choose, please choose providing a great Customer Experience (example: don’t reject something urgent or critical for your Customer, and then write a great note in your ticketing tool and close it on time!)

Agile Change Delivery over Traditional Change Management (Delaying Improvements)

Agile Project Management methods are based on Incremental Deliverables. So, this means for ITSM the need of managing tons of new Changes, more Incidents, and with less project Documentation. So, we can’t manage them the same way we did in waterfall projects. The good news is that this also means a better Service, because we are responding better to business change needs. So, we need to transform our traditional ITSM Change Management bureaucracy into an Agile Change Delivery.

Cross-Technology Service Teams over Technology-based Teams

Traditional ITSM Teams have been organized around technologies. Many times for “getting things done” a standard Service Requests needs to go across 3 or more teams for being completed. This is because they are technology teams, but not “Service Teams”. This is not efficient, neither Agile. Big companies classify professionals into technologies and experience, and then they apply an standard hour fee on them. They do this for replacing them as standard pieces in a supply chain of “services”, but in fact this results into a poor and ineficient Services delivery. Every person is unique, not a technology robot. Cross-technology service teams are more Agile and Efficient. In ITSM, People Matter!