From Managing Tickets to Managing Value: My ITIL Journey Through Enterprise IT Operations

# ITIL

# Career Success

How two decades in IT shaped my understanding of ITIL, from fixing technical issues to creating lasting business value.

October 13, 2026

Binoy Mathews Pandipurath

From Managing Tickets to Managing Value: My ITIL Journey Through Enterprise IT Operations

When I started my career in IT more than two decades ago, my definition of a good day was fairly simple.

Systems were up. The network was stable. Users were able to work. And the ticket queue was under control.

If something failed, we fixed it. If a user reported an issue, we resolved it. If a server went down, getting it back online was success.

At that stage of my career, I was naturally much closer to the technology. I was interested in networks, servers, infrastructure, troubleshooting and finding the root cause of technical problems.

Over the years, my responsibilities moved from technical support and infrastructure into IT service management, enterprise IT operations, governance, resilience and transformation.

Something else changed along the way: my understanding of ITIL.

Today, I look at service management quite differently from how I did earlier in my career.

For me, ITIL is no longer primarily about managing tickets or implementing processes. It is increasingly about understanding value—who we are creating it for, what outcome they are trying to achieve, what could prevent that outcome, and how people, technology and partners need to work together to make it happen.

That change did not happen because I read a particular book or completed a particular certification.

Most of it came from experience.

Fixing the technology is not always restoring the service

I remember a time when I would have considered bringing a failed server back online as a successful resolution.

Technically, that might be correct.

But experience eventually taught me to ask a different question:

Has the service actually been restored for the customer?

A server can be running while the application remains unavailable. A network link can be operational while users are still unable to complete a transaction. Every infrastructure monitoring dashboard can be green while the customer continues to experience a problem.

This sounds obvious when written down.

In practice, however, the distinction changes the way IT teams operate.

We stop looking only at individual technology components and start looking at the service that those components collectively enable.

That was probably one of the earliest and most important shifts in my own ITIL journey—from thinking primarily about technology availability to thinking about service outcomes.

A documented process is not necessarily a working capability

As my responsibilities expanded, I became more involved in Incident, Major Incident, Problem, Change, Service Request, Service Level, Asset and Configuration Management.

And I learned another lesson.

Writing a process is relatively easy. Making it work consistently across an organization is much harder.

I have seen very good process documents fail to produce equally good outcomes.

Sometimes ownership was unclear. Sometimes teams continued to work in silos. Sometimes the process was implemented because an audit required it. And occasionally, following the process itself became more important than understanding why the process existed.

Service Level Management is a good example.

An SLA can be green while the customer experience is red.

We may technically achieve a response or resolution target and still have an unhappy customer because the service did not support the business outcome they needed.

That does not mean SLAs are unimportant. Far from it. It means the SLA needs to represent something meaningful.

The same applies to Change Enablement.

If a low-risk, repeatable change and a high-risk production change go through exactly the same level of assessment and approval, we may be following a process, but are we really managing risk effectively?

These experiences gradually changed the question I ask when reviewing any service management practice.

Instead of asking:

“Are we following the process?”

I increasingly ask:

“What outcome is this process helping us achieve?”

That small change in question can lead to a very different conversation.

The CMDB taught me that service management is a team sport

Configuration Management gave me another lesson that has stayed with me.

A CMDB can initially appear to be a technology project.

Select a tool. Discover the configuration items. Populate the database. Establish relationships. Create dashboards.

Done.

Except, of course, it is rarely that simple.

Infrastructure teams know the servers. Network teams know the connectivity. Application teams understand application dependencies. Security teams maintain their own information. Cloud teams, business teams and external suppliers may each hold another part of the picture.

No single team necessarily understands the complete service.

This means that creating useful configuration information is not primarily a database problem.

It is an ownership and collaboration problem.

Who owns the information?

Who validates it?

Who updates it when something changes?

And perhaps most importantly, does everyone understand why keeping that information accurate matters?

I have come to believe that a technically complete CMDB that people do not trust is not a successful CMDB.

Tools can discover components and store relationships. But people, governance and shared accountability are what make that information valuable.

It reinforced something that became increasingly obvious throughout my career:

Service management is a team sport.

When the deadline cannot move

One environment that significantly shaped my thinking was working in IT service management supporting technology operations associated with the FIFA World Cup Qatar 2022.

Major global events introduce a very different operational reality.

A match is not going to be postponed because IT needs another week to prepare.

The date and time are fixed.

That changes the meaning of operational readiness.

Incident Management cannot simply be a document stored somewhere. Escalation paths have to work. Technical teams need to know who is responsible for what. Suppliers need to understand their obligations. Communication channels need to be clear. Changes need to be carefully assessed.

And when something goes wrong, there is very little time to debate who owns the problem.

This environment reinforced the importance of rehearsals, readiness assessments, operational acceptance, monitoring, escalation and Major Incident Management.

But one of the biggest lessons I took from that experience was actually very simple:

Operational resilience is built before the incident, not during it.

When a major incident occurs, the quality of the response often reflects decisions made weeks or months earlier.

Architecture.

Monitoring.

Documentation.

Supplier arrangements.

Escalation models.

Training.

Rehearsals.

And, perhaps above all, relationships between teams.

A Major Incident Manager can coordinate the response, but cannot suddenly create collaboration between teams that have never learned to work together.

Governance should enable decisions, not bureaucracy

As I moved further into IT leadership and enterprise operations, governance became a larger part of my responsibilities.

Governance is essential. But I have also learned that there is a fine line between control and bureaucracy.

Change Management can become a calendar of approval meetings.

Service reviews can become presentations full of green indicators.

Risk registers can become documents that are carefully maintained but rarely influence decisions.

In those situations, governance may exist—but its value becomes questionable.

One question I now find useful is:

“What decision will this information help us make?”

If a KPI does not help us understand performance or make a decision, why are we measuring it?

If an approval does not reduce risk or improve accountability, why is it required?

If a report does not lead to discussion or action, who are we producing it for?

Good governance should create clarity around accountability, risk, performance and decision-making.

It should help people make better decisions—not simply create more approvals.

Automation does not fix a bad process

This has become even more relevant as organizations adopt automation, AIOps and AI.

There is understandable excitement about what these technologies can do for IT operations.

I share that excitement.

But experience also makes me cautious about one thing:

Automating an ineffective process does not make it effective. It may simply allow us to perform the wrong activity faster.

Before automating a workflow, we still need to understand why the workflow exists, what outcome it supports, where the risk sits and what should happen when the automation cannot make the decision.

Technology changes rapidly.

The need for clear ownership, governance and service thinking does not disappear with it.

If anything, it becomes more important.

From provider and customer to value co-creation

Perhaps the biggest evolution in my understanding of ITIL has been around value co-creation.

Earlier in my career, it was easy to think about IT as the provider and the business as the customer.

The relationship looked relatively straightforward.

IT provides. The customer consumes.

Real-world experience tells a different story.

IT cannot establish meaningful service levels without understanding what the business actually needs.

A CMDB cannot remain accurate without multiple teams contributing to it.

A major incident cannot be managed effectively without technical teams, service owners, suppliers and business stakeholders working together.

And transformation rarely succeeds when it is treated as something IT is doing to the business rather than with the business.

Value is therefore not simply delivered from one side to another.

It is created through interactions between people, technology, processes, partners and consumers.

Many problems that initially appear to be technology problems eventually turn out to be something else entirely:

An ownership problem.

A communication problem.

A collaboration problem.

Or simply a different understanding of what “good” looks like.

Why the evolution of ITIL matters to me

My own professional journey has taken me through different generations of ITIL—from the process-oriented thinking many of us first encountered, through ITIL 4 and, more recently, ITIL Version 5.

Having recently had the opportunity to engage closely with ITIL Version 5, I found its direction particularly relevant to what I have experienced in practice.

The stronger connection between products, services, experience and transformation reflects something I believe many practitioners gradually discover through experience.

We cannot optimize each of these independently and expect sustainable value to emerge automatically.

A technically excellent product that creates a poor experience is unlikely to be considered successful by the consumer.

A well-designed service that does not support the required business outcome has limited value.

And transformation cannot simply mean implementing new technology.

Transformation requires changes in capabilities, behaviours, operating models and sometimes the way an organization thinks about value itself.

For me, this is where ITIL's continuing evolution becomes important.

The technology landscape I started my career with looks very different from today's world of cloud services, complex supplier ecosystems, automation, AI and digitally enabled products.

Service management has had to evolve with it.

And practitioners have to evolve as well.

The biggest change may have been in me

After more than two decades in IT, perhaps the biggest change has not been in ITIL itself.

It has been in the way I understand it.

I started my career thinking primarily about technology.

Then I learned to think about processes.

Later, I learned to think about services.

Today, I find myself thinking much more about products, experience, outcomes, relationships, transformation and value.

That does not mean technology, processes or practices have become less important.

It means I now see them as parts of a much bigger picture.

I have also learned that there is rarely a perfect ITIL implementation.

Every organization has different customers, different risks, different cultures, different technologies and different levels of maturity.

The objective, therefore, should not be to make the organization look like an ITIL textbook.

The objective is to take the guidance, understand the context and use it intelligently to create better outcomes.

Perhaps that is the most important lesson ITIL has taught me.

Don't implement ITIL for the sake of implementing ITIL. Use it to help people, products, services and organizations create and protect value.

My own journey has therefore been one from managing technology, to managing services, to understanding value.

And after more than 20 years, I still consider that journey very much a work in progress.

I would be interested to hear from fellow members of the PeopleCert Community:

How has your understanding of ITIL changed during your career? Was there a particular incident, project, transformation—or even a failure—that made you look at service management differently?

Where conversation, connection, and real-world practices come together.