About this series: This is Part 1 of the ITIL in Practice series — four posts drawn from real implementations across three organisations over nearly two decades. Most writing about ITIL is theoretical. This series isn’t. Each post covers what I actually built, what worked, what didn’t, and what I’d do differently. I hold ITIL Expert certifications in both V3 and V4. The framework matters less than knowing how and when to apply it — and that only comes from doing it in real environments with real constraints. Part 1 starts at Tyco.
I took the role of Global Director of Technical Support at Tyco — a global security and fire protection company — knowing it was going to be a significant challenge. What I didn’t fully appreciate until I was in it was just how much had to be built from scratch.
160 engineers. Eight offices across three continents — Toronto, Montreal, Fishers Indiana, London, Echt in the Netherlands, Corropoli in Italy, Pune, and Shanghai. A follow-the-sun coverage model running 24 hours across five days, with on-call coverage bridging the two-hour gap. And when I sat down to understand how we were actually measuring performance, the answer was essentially: we weren’t. Not in any consistent, meaningful way.
There were no standardised scorecards. No shared definition of what a good resolution looked like. No formal process for classifying and escalating incidents — which meant every office was handling the same types of problems differently, and nobody had a clear picture of whether we were getting better or worse. The knowledge benchmark score for the team, when we finally found a way to measure it, came in at 67%. That number told me everything I needed to know about where to start.
Why Incident Management has to come first.
When you walk into a support operation that lacks structure, the temptation is to do everything at once. Fix the metrics. Improve the training. Introduce new tools. Redesign the escalation paths. All of those things needed to happen at Tyco eventually. But doing them simultaneously, without a foundation, is how you create noise rather than improvement.
ITIL’s discipline of Incident Management gave me the foundation. Incident Management is not complicated in principle: a structured, consistent way of logging, classifying, escalating, and resolving issues — so that every problem that enters the system gets handled the same way regardless of which office picks it up, which engineer happens to be on shift, or how severe the customer’s reaction is.
That consistency is worth more than it sounds, especially in a global team. Without it, you have eight offices developing eight slightly different interpretations of how to handle a P2. You have institutional knowledge that lives in people’s heads rather than in documented processes. You have senior engineers resolving complex issues in ways that nobody else can replicate, because the resolution path was never captured. And when those engineers move on — as they inevitably do — the knowledge leaves with them.
The first step at Tyco was creating a reporting role within the organisation. Before anything else could improve, we needed visibility. Working with my regional managers, we designed scorecards that made sense for the actual work — a deliberate mix of quantity and quality metrics, because I wanted to make it clear from the outset that the number of calls handled mattered less than whether customers were getting the right answer the first time. That principle shaped every KPI we put in place.
The Exacq acquisition — ITIL as a change management tool.
About two years into my time at Tyco, the company acquired Exacq Technologies — a video security manufacturer based in Fishers, Indiana. The acquisition brought a significant support team into the Tyco structure, along with a customer base that had specific expectations about how their products were supported.
Then the restructuring happened. Manufacturing moved to our Toronto facility. Much of the senior staff in Fishers, including a significant portion of the support team, departed in the transition. The institutional knowledge that made Exacq support work — the product-specific expertise, the escalation relationships, the resolution paths for the most common issues — left with the people who’d built it.
What we had was an Incident Management process. That mattered more than I expected. Because we had a consistent way of classifying and routing issues, we could identify quickly where the gaps were — which ticket types were taking longest to resolve, which escalations were failing, where the knowledge had walked out the door. Without that visibility, you’re working from instinct. With it, you can build a plan.
We took two immediate actions. First, we accelerated training for the Montreal office, which also supported video products and had capacity to absorb a portion of the Fishers volume. We didn’t have shared phone systems between the two sites, but we set up time-based overflow routing so that customers weren’t waiting through long queues during peak hours. Second, we identified former Exacq support staff who had moved into manufacturing roles in the Toronto facility and pulled them back into a temporary escalation function — people who had the product knowledge and were willing to apply it in a support context while we rebuilt the team’s capability from the ground up. Customer satisfaction improved by close to 20% over the period following the acquisition. Not because the situation was easy, but because we had a process that gave us somewhere to put the information we were gathering every day.
Problem Management and the Six Sigma connection.
Incident Management restores service. Problem Management prevents recurrence. Those are different jobs, and keeping them separate is one of the most important structural decisions in any ITIL implementation. At Tyco, I was running both simultaneously — and it was during this period that I first understood how well ITIL and Six Sigma work together when applied in the same environment.
Six Sigma was being rolled out at Tyco at the same time I was embedding ITIL processes. On the surface these look like separate programmes — one is a quality methodology, the other is a service management framework. In practice, they reinforced each other in a way I hadn’t anticipated.
The connection is Root Cause Analysis. ITIL Problem Management requires RCA — you need to understand why the incident happened, not just that it happened. But ITIL doesn’t tell you how to do RCA. It tells you that you need to do it. Six Sigma does tell you how: the 5 Whys, the Fishbone diagram, the DMAIC framework that gives you a systematic way to move from problem definition through to sustained corrective action.
When we applied Six Sigma’s analytical rigour to ITIL’s Problem Management process, the quality of our RCAs improved dramatically. We stopped producing post-mortems that described what happened and started producing ones that explained why — and more importantly, ones that identified the specific changes needed to prevent recurrence, with owners assigned and timelines attached. That distinction — between an RCA that describes and an RCA that drives corrective action — is the difference between a ceremonial document and a management tool.
Building the Quality function — and what it actually produced.
About two years into the Tyco role, I established a dedicated Quality team. Not a QA function in the traditional sense — a team whose specific job was to listen to customer calls, score the engineers against defined competency criteria, and use that data to identify both individual coaching needs and systemic gaps that training needed to address.
The first benchmark score from that team: 67% in Knowledge. That’s the number that tells you the state of the operation before the Quality function had anything to measure against. Over the following two years, we drove that score to a sustained 96% — not a single measurement that peaked and dropped, but a consistent performance level that the team maintained quarter after quarter.
That improvement didn’t come from a single intervention. It came from having a feedback loop that didn’t exist before. The Quality team would score calls. The scores would surface patterns — specific product areas where knowledge was thin, specific question types that agents consistently handled poorly, specific customer scenarios that the training hadn’t prepared people for. Those patterns fed directly into the training programme, which had been rebuilt around the same tiered structure I was using for skills-based routing. An agent who was weak in a specific area got targeted development in that area, not generic retraining.
This is what ITIL Continual Service Improvement looks like in practice when it’s working: a feedback loop from real customer interactions that drives specific, targeted improvement in the team’s capability. It’s also what the Control phase of Six Sigma is designed to sustain — the mechanisms that ensure the improvement you’ve achieved doesn’t erode when attention moves elsewhere.
What I’d do differently now.
The sequencing at Tyco was right — Incident Management first, then Problem Management, then Quality, then Continual Improvement. But I’d move faster in the first 90 days to get the measurement infrastructure in place. The period between arriving and having the first meaningful scorecard data was longer than it needed to be, and that delay meant several months of decisions made on instinct rather than data.
I’d also be more explicit, earlier, about the connection between ITIL and whatever quality or improvement framework was running alongside it. At Tyco, the Six Sigma and ITIL programmes ran somewhat in parallel, and the integration between them — RCA as the methodological bridge — happened organically rather than by design. Designing that integration from the start would have produced the benefit faster.
Both of those lessons informed what I did at the next organisation. Which is where the story gets to Change Management — and the CAB process that nobody wanted until they saw what it prevented.
Hutch Morzaria is a Director-level CX and Support Leadership professional with 19 years of experience building global support organizations across SaaS, Fintech, and enterprise technology. He has hired dozens of support and CX leaders across his career and holds ITIL Expert certification across V3 and V4.
