For decades, a certain model of IT delivery has quietly dominated enterprise contracts: the manpower model. Bodies on seats, hours logged, tickets closed, headcount reported. It looks like service. It gets invoiced like service. But it rarely behaves like service — because nobody actually owns the outcome.

We recently worked with an MSP caught firmly in this trap. On paper, they had a full IT operating model: infrastructure teams, network engineers, end user computing support, a cybersecurity function. In practice, they had a collection of resource pools reacting to whatever landed in the queue that day. Obsolescence crept upward year on year. Improvement initiatives existed mostly as slide decks. Nobody could tell you, with a straight face, what "good" looked like across the estate — because nobody had ever quantified it.

Three years later, that same organisation had cut obsolescence by more than 60%, materially improved programme delivery, seen a double-digit jump in the number of KPIs turning green across a 60-metric scorecard, and — perhaps the least measurable but most telling change — had teams who were visibly more engaged in their work. Not because more people were hired. Not because budgets ballooned. Because the model of delivery changed.

This is the story of that transformation, and a practical blueprint for any IT organisation looking to make the same shift: from manpower provider to true service provider.

The Manpower Trap

It's worth naming the pattern precisely, because it's so common it becomes invisible. In a manpower-led delivery model, the commercial relationship is built around effort, not outcome. Success is measured in FTEs deployed, SLA response times, and tickets resolved within target. All useful operational hygiene — but none of it tells you whether the estate is getting healthier, whether risk is going down, or whether the organisation is actually moving forward.

Under this model, a few things happen almost automatically:

• Ownership diffuses. If everyone is responsible for "keeping the lights on," nobody is accountable for the roadmap. Improvement work competes with incident work and, unsurprisingly, incident work always wins.

• Obsolescence accumulates silently. Ageing infrastructure, unsupported network kit, legacy end user devices, and cybersecurity debt don't show up in a ticket queue. They show up in a breach, an outage, or a failed audit — usually years after the warning signs were first visible.

• Improvement becomes a project, not a practice. Because there's no standing mechanism to prioritise and track improvement work, it gets bundled into occasional transformation programmes rather than being a continuous discipline.

• Teams lose motivation. Skilled engineers who joined to build and improve systems find themselves permanently fighting fires. Over time, the best people either disengage or leave.

Our client had all four symptoms. The diagnostic work wasn't complicated — it just required someone to finally ask the estate a direct question: what do we actually own, and how healthy is it?

Step One: Defining the Product Groups

The first structural move was deceptively simple — stop thinking about the IT estate as an undifferentiated pool of "IT support" and start thinking about it as a set of distinct products, each with its own lifecycle, risk profile, and improvement agenda.

The estate was segmented into four core groups:

• Infrastructure — servers, storage, compute, data centre and cloud platforms

• Network — connectivity, WAN/LAN, firewalls, and the physical and virtual backbone

• End User Computing (EUC) — devices, desktop builds, collaboration tools, the technology employees touch every day

• Cybersecurity — controls, monitoring, vulnerability management, and compliance posture

This wasn't a cosmetic re-labelling exercise. Each group became a genuine product line with its own boundary, its own health metrics, and — critically — its own owner. That last point mattered more than anything else in the whole transformation.

Step Two: Quantifying the Service

You cannot improve what you have not measured, and you cannot prioritise improvement work if you don't know how far behind you actually are. So before any roadmap was built, each product group went through a rigorous quantification exercise.

This meant building an honest, current-state baseline for each product: what assets exist, what condition they're in, what's in support, what's out of support, what's approaching end-of-life, and what the known risk exposure looks like. It also meant defining, for the first time, what "healthy" actually meant for each product — a target obsolescence threshold, a target patch compliance level, a target device refresh cycle.

This is the step most transformations skip, because it's unglamorous. There's no ribbon-cutting moment for an asset inventory. But it's the step that turns "we think things are a bit old" into "38% of network hardware is beyond end-of-vendor-support, concentrated in these three regions, carrying this specific risk profile." That kind of precision is what makes a roadmap fundable and defensible, rather than aspirational.

Step Three: Identifying the Gaps

With a quantified baseline in place, gap analysis became a straightforward, almost mechanical exercise rather than a debate. For each product group, the difference between current state and target state was documented, sized, and — crucially — translated into business language. Not "40 switches are past end-of-life," but "40 switches past end-of-life represent a material outage and security risk to three revenue-generating sites, with an estimated remediation cost and timeline."

This translation step is where a lot of technical improvement work dies in normal organisations — it stays in engineering language and never makes it into a form that a business sponsor can prioritise against commercial investment. Getting the gap analysis into business terms was what let the next phase actually work.

Step Four: Product Owners, Not Just Team Leads

Perhaps the single biggest cultural shift in this transformation was the introduction of dedicated Product Owners for each of the four groups — Infrastructure, Network, End User Computing, and Cybersecurity.

This is a subtly different role from a traditional team lead or delivery manager. A Product Owner in this model was explicitly accountable for two things: the obsolescence position of their product, and the improvement roadmap that would bring it into a healthy state. They weren't measured on ticket volumes or SLA percentages alone — they were measured on whether their product was getting better, month over month, quarter over quarter.

This single change did more to fix the ownership diffusion problem than any process document could. When obsolescence has a name attached to it — not a team, a name — it stops being an abstract organisational failing and becomes a tracked, personal accountability. Product Owners began behaving less like operational managers and more like internal product managers: building a backlog, defending investment cases, negotiating priority, and reporting progress against a roadmap they were genuinely accountable for.

It's worth being honest that this shift is uncomfortable for some individuals and organisations. Not everyone who is excellent at running day-to-day operations is naturally suited to owning a forward-looking roadmap and making the business case for investment. Part of the transformation involved coaching, and in some cases reshuffling, to get the right people into these roles — people who could hold both the technical detail and the commercial conversation.

Step Five: Kanban Backlogs, Prioritised at the Business Level

With Product Owners in place and gaps quantified, the next step was giving the improvement work a visible, living home — rather than letting it sit in spreadsheets and steering committee decks that nobody opened between meetings.

Each product group built a Kanban-style backlog: every piece of improvement work — obsolescence remediation, capability upgrades, security hardening, automation initiatives — captured as a discrete, sized, trackable item. Work moved through clear stages (backlog, prioritised, in progress, done), giving both the Product Owner and the wider business a real-time view of what was happening and what was next.

The critical design decision here was who prioritised the backlog. It wasn't left purely to IT. Prioritisation happened at a business level, with business stakeholders weighing in on which improvements mattered most given commercial priorities, risk appetite, and upcoming initiatives. A network refresh that unblocked a major site expansion might jump the queue over a lower-risk infrastructure upgrade, even if the infrastructure item had been "in the queue longer." This is uncomfortable for some technical teams to accept at first, because it can feel like discipline is being sacrificed to politics. In practice, the opposite happened: because prioritisation was transparent, structured, and grounded in the quantified gap data, business stakeholders trusted the process — and technical teams got faster, clearer decisions instead of ambiguous, competing demands.

This also had a secondary benefit that's easy to underestimate: visibility. For the first time, senior stakeholders could look at a single board and see, across all four product groups, exactly what was being worked on, what had been delivered, and what obsolescence and risk reduction was actually being achieved. Improvement stopped being invisible background labour and became a visible, celebrated stream of delivery in its own right.

The Results

Three years into this model, the numbers told a clear story:

• Obsolescence reduced by over 60% across the combined estate — a material, quantifiable de-risking of infrastructure, network, EUC, and cybersecurity assets that had previously been ageing largely unmanaged.

• Programme delivery improved measurably. With clear ownership, sized backlogs, and business-aligned prioritisation, initiatives that had previously stalled in ambiguity moved through to completion far more reliably.

• More than 10% of additional KPIs turned green, out of a scorecard of 60 metrics spanning availability, security posture, service quality, and delivery performance — a meaningful shift in the overall health of the operating model, not just an isolated pocket of improvement.

• Team motivation visibly improved. Engineers who had spent years exclusively fighting fires were now building things, owning outcomes, and seeing the tangible results of their work reflected on a board and in a scorecard. Retention and engagement both benefited, even though this was never the primary target of the transformation.

• Customer satisfaction improved. Customer had better visibility of the services they were paying for, the business risk reduction, improvements achieved, and value that the teams were delivering. Overall the customers were happier with the changes since it gave them an ability to prioritise the initiatives that the Product Groups were working on.

None of these outcomes came from a single big-bang change. They came from the compounding effect of clear ownership, honest measurement, and a disciplined, business-aligned mechanism for deciding what to work on next.

What This Means for Other IT Organisations

The specifics of this transformation — four product groups, a 60-metric scorecard, a three-year timeline — are particular to this client. But the underlying pattern is broadly applicable to any IT organisation still operating, consciously or not, as a manpower provider rather than a true service provider.

A few principles travel well beyond this specific case:

Segment before you improve. You cannot manage what you haven't defined. Breaking a sprawling estate into distinct, ownable product groups is what makes everything downstream possible.

Quantify relentlessly, even when it's unglamorous. A gap you can't size is a gap you can't fund. Precise, business-translated baselines are the currency that turns technical debt into an investable roadmap.

Give obsolescence a name. Diffuse accountability produces diffuse results. A Product Owner model — with real accountability for the health trajectory of a product, not just its day-to-day operation — changes behaviour in a way that policy alone never will.

Make improvement visible and continuous. A Kanban backlog isn't just a task-tracking tool; it's a statement that improvement work is a permanent discipline, not an occasional project. Visibility drives accountability, and accountability drives delivery.

Let the business prioritise, not just IT. Improvement work that's prioritised purely on technical logic often loses the argument for investment. Improvement work that's prioritised transparently, with business stakeholders in the room, earns trust and funding in equal measure.

Closing Thought

The shift from manpower provider to true service provider isn't really a technology transformation. The infrastructure, network, EUC, and cybersecurity work in this story is real and necessary — but the actual transformation happened in accountability, measurement, and prioritisation. It happened when "we manage IT" became "we own the health of these four products, we know exactly how healthy they are, and we have a transparent, business-backed plan to make them healthier."

That's a model any IT organisation can adopt — not by hiring more people, but by finally deciding who owns what, measuring it honestly, and giving the business a real seat at the prioritisation table

InfinityX Digital

Your value co-creators!

Start a conversation

London, UK — remote across Europe

(C) 2026 InfinityX Digital-LTD - Your value co-creators

Home-Work-Who we are-Services-Contact