Skip to main content
Polymath DigitalStart with one workflow

PerspectivesPaper 07

Pricing the Internal Time a Transformation Costs

The business case prices the platform and the integrator. It never prices your own people.

Open any approved transformation case. Licences, integrator fees, infrastructure, contingency, each with a quoted price because each arrives as an invoice from outside the building. The line that is missing is the one the programme depends on: the working weeks of the people who run the processes being rebuilt.

Their time is not free. It is unpriced, which is worse. An input costed at zero cannot be allocated, scheduled or traded off. It can only be requested, and the request lands on people whose day job has deadlines that do not move.

What actually happened

Polymath’s founder ran workforce planning, transformation and the programme office for a consumer packaged goods business of roughly $2–3 billion in revenue that had gone public on the TSX. Payroll ran across approximately 21 countries and Workday integrations reached more than 20 offices. The portfolio was his, and so were the people who had to keep pay, benefits and hiring running while the team rebuilt parts of them. There was no bench and no budget to hire one.

Two pieces of work from that period are why he holds this view, and both were delivered against that constraint. In the first the team landed the largest benefits offering in the company’s history — about $6 million of incremental benefit value — inside 60 days. Nobody chose 60 days. Carrier renewal dates, enrolment windows and payroll cut-offs chose it, and none of them move.

The people who could make the design decisions were the benefits owner, the country payroll leads whose calendars the change would land in, and the systems administrator who would carry it into the platform and out to the providers. Every one of them was running enrolment that same month. Their cost already sat in payroll, so nothing in the plan had anywhere to record how much of them the work required.

So the function costed them in weeks instead. What the group would not get from those people during those 60 days was named before the work started, by him, rather than discovered afterwards by them. That is the reason the date held.

The second was a global reward and recognition model, built with no incremental budget at all and worth roughly $5 million in organizational value, with a custom recognition application to carry it. No budget meant no external capacity — not less of it, none. So the model was designed once and propagated across the offices rather than negotiated market by market, and the build sat in the weeks after enrolment closed rather than beside it. The order of the work was the resource plan, because it was the only resourcing instrument available. Neither number came from more capacity. Both came from deciding, before the work started, what the same people would stop doing.

A client engaging Polymath gets that trade priced at the start — which weeks, from which named people, given up for what — instead of reconstructed from a backlog eighteen months later.

Why it happens

The missing line is not an oversight, and that matters before anyone tries to fix it. A business case is a request for money, and money is what the enterprise controls at the moment of approval. Salaried internal time has already been committed: payroll runs whether the person spends Thursday on the programme or in their function. No invoice, no purchase order, no approval event. The case is honest by the standard it is judged against.

The first consequence is that an input priced at zero is never scheduled. Everything else in the programme has a quantity and a rate, which is what converts into a claim on a calendar. Internal time has neither, so it never becomes an allocation. It becomes a stream of requests, each individually reasonable.

The second consequence is that those requests land on a person holding two obligations that fail differently. The payroll run has a date, and missing it produces an unpaid employee, a late filing, an audit finding. A design session slips to next week and produces nothing visible at all. Faced with both, a competent person protects the obligation that fails in public.

Nobody consciously chooses the day job over the programme. The day job has a deadline with a witness, and that settles it.

The third consequence decides outcomes, and it is easy to miss because attendance holds up. They come to the session. What gets rationed is preparation: the exception they would have raised with a day to think, the check of whether the process survives quarter-end, the second look at a mapping accepted because nine minutes remained. The deliverable is produced. It is thinner, and thinness has no field on a status report.

So the programme reports green, correctly. Status measures whether artifacts were completed against dates, and they were. What was traded away surfaces much later, when the process meets a case it was never told about.

There is a fourth consequence nobody bills for. Capacity taken this way is not replenished when the programme closes. A budget line ends; a function that spent eighteen months of its slack on design workshops does not get those months back. It emerges with older documentation, cross-training that never happened and a longer backlog, and no artifact records any of it.

The strongest objection

The strongest case against this: our teams flex, they always have, and pricing internal time formalizes something that works.

Flex is real and it is an asset. A capable function absorbs a quarter of extra load, and that is how good teams handle a year-end, an audit or an upgrade. If your programme runs one quarter, stop reading here.

Flex is drawn from slack, and slack has a size. It is the part of the week that would otherwise go to improvement, documentation, cross-training and thinking about the work. That is invisible while it is being skipped and expensive once it has been skipped for eighteen months. Flex absorbs spikes; an eighteen-month programme is not a spike, and treating it as one spends the reserve without anyone deciding to.

The second objection is stronger: we backfilled the seats. Some do, and it helps. But backfill covers the transactional part of a job, because that is the part that can be handed over in a fortnight. What the programme needs is the part that cannot: which exceptions are genuine, which approval is ceremonial, why a rule exists at all. So the incumbent stays in both jobs while a new person runs the routine slowly, and you pay for two people and get one and a bit.

The method

We run six steps, in this order. The first makes the rest possible, which is why we do not start anywhere else.

  1. We put internal time in the business case, with a quantity and a rate. We cost working weeks, by name, the way you would cost a contractor. That is the only way the number becomes something your executive committee can argue with. The trade-off we accept: the case gets more expensive and some cases stop clearing the hurdle. Skip it and the programme begins with a resource plan describing only the people who send invoices.
  2. We name individuals, not functions. A case promising that operations will provide half a full-time equivalent has allocated nobody, so we write the names. The trade-off we accept: naming makes the constraint personal, and we usually find the same three names on four programmes. Skip it and every programme assumes it has the person the other three also assumed it had.
  3. We decide what stops, before the programme starts. For each named person we state in writing what they will not do while they are on this: a deferred improvement, a slower service level, a report that pauses. We treat redeployment as the decision; a communications plan is not. The trade-off we accept: one of your leaders must accept a visible reduction in their own function’s output and defend it. Skip it and that person makes the choice alone, at speed, in favour of whatever is shouting loudest.
  4. We sequence to where capacity is, not to where the appetite is. We order the work by which operating team can carry the load next, then we design once and propagate rather than reopening the same decision in every country. The trade-off we accept: the module your executive team wants first is often not the one that can be built first. Skip it and two workstreams arrive at the same team in the same quarter.
  5. We backfill the routine, never the judgment. We buy back the transactional load so the incumbent can spend scarce hours on design decisions. The trade-off we accept: the org chart says the person has moved to the programme while in practice they still answer the hard questions in their old job. Skip it and you have paid to replace the part that could be written down and lost the part that could not.
  6. We review consumed capacity beside spend, every month. Your steering committee already reviews budget, so we add one line: hours each named person actually gave, reported by them rather than by their manager. The trade-off we accept: people under-report overload at first, so the early numbers are wrong in a predictable direction. Skip it and the first accurate reading arrives as a resignation or a control failure.

We do not need a resource management system or a new programme discipline for any of this. It requires one costed column in the business case and a leader willing to defend it. We treat that as the substance of change management: not communication and training, but which named people are released, from what, and in what order. In Hire-to-Retire we find the constraint unusually sharp, because whoever knows how absence, pay or enrolment actually works in a country is the person running it that week. Sequencing is what lets us spend that person once instead of three times.

Evidence and measures

Who a transformation quietly depends on, what they put down, and when the enterprise finds out:

ROLE THE PLAN DEPENDS ONWHAT THEY STOP DOING TO DELIVER ITWHEN THAT SURFACES
Multi-country payroll leadLocal control checks and calendar maintenanceAt the first statutory filing after go-live
Benefits ownerProvider reconciliation and renewal preparationAt renewal, as a price nobody negotiated
Systems administratorAccess reviews and configuration documentationAt the next audit, as a finding
Shared services team leadCross-training and written back-up proceduresThe first absence during a peak week
End-to-end process ownerManager coaching and exception handlingAs escalations the service desk cannot close
Manager releasing the expertDay-to-day supervision of their own teamAs a backlog that never clears after go-live

Five measures worth tracking over ninety days. None requires a new system:

— Hours the named internal contributors actually gave the programme last month, collected from them rather than from their managers.

— People appearing on more than one programme’s critical path this quarter. The count is usually higher than the sponsor expects.

— Queue age in the functions supplying those people: how long the oldest open item has waited, not how many were closed.

— Items on the agreed “not this year” list that were quietly done anyway, and who did them.

— Proportion of design sessions attended by the person who owns the process rather than a delegate sent in their place.

If those five move, the programme is resourced. If only the spend line moved, you funded the software and borrowed the rest.

How Polymath solves this

We start with arithmetic, not a diagnosis of culture. We convert the Hire-to-Retire work already in flight into named internal weeks — which individuals have to sit in which design decisions, for how long — and set that against what those same people already owe the payroll, enrolment and reporting calendar. The gap is usually a quarter of work with nobody free to do it, and seeing it is the first honest scope conversation the programme has had. We run this as Change Management, and what we deliver is a costed resource position rather than a communications plan.

We supply the capability rather than recommend it, and we do it from inside the programme calendar you already run. Our operators have run these processes, so we take the process design, configuration and integration, and your scarce people — the benefits owner, the country payroll leads, the systems administrator — spend their hours only on what nobody else can answer: which exceptions are genuine, which approval is ceremonial, why a country rule exists. Your team works in the same sessions and holds the design at the end.

What compounds is a measured price for internal time. Once you know what a design decision costs in named weeks, we scope the next programme against a number rather than an assumption, deferral is decided by your executive committee instead of by an overloaded specialist on a Thursday, and the people trained on the first module carry the second without buying capacity again. By the third programme your executive committee is arguing about a quantity and a rate rather than about whether internal time has a price at all.

What it costs to do nothing

The cost is booked in the wrong place, which is why it is rarely argued with. The programme closes on budget and is declared a success. The function it borrowed from carries the backlog, the deferred controls work and the overtime for three quarters, on a P&L with no reference back to the decision that caused it.

The second cost is the option you no longer hold. An enterprise that has run two consecutive unpriced programmes has a lower absorption threshold than one that has run none, and it discovers this when an acquisition or a system incident arrives without asking permission.

The third is people. Those who carry an unpriced programme are, by definition, the ones who could not refuse, and they tend to leave after it succeeds rather than during it. The turnover is booked against the function a year later, with no line back to the programme that spent them.

A transformation that cannot afford its own people’s time has not been funded. It has merely been started. Pricing that time is the arithmetic we start with.

Start here

Start with one workflow.

Choose one process that crosses three or more functions. We map it end to end with you, and mark every place the same problem gets solved twice.