capability.ai

Show where your programme is short of hours, and put it on one page for the person who decides

The plan asks for hours from the people who will keep the change running. This test shows whose hours, how many and in which weeks.

Those hours are what the Transformation Capability Management standard calls ‘capacity’: the time an organisation can give to change, as distinct from skill.

The test takes about 2 hours of your own time, and 3 short questions to the people who do the work and their managers. You need the programme plan, the resource plan and the date each supplier’s contract ends. If you do not hold those dates, ask the programme office.

Start with your own workstream. The test works the same way on a whole programme.

Sort every line of work into hours that leave and hours that stay

Steps 6, 7 and 10 each put one short question to someone else. Send all 3 on the same day and give people 3 working days. If no answer comes, the step says what to write. So after 3 working days no step waits on anyone.

  1. List the work on the plan between now and go-live.

    Use the plan’s summary lines, not its tasks. Aim for 10 to 20 lines for one workstream.

    Done when: every summary line for your workstream, from now to go-live, is on your list.

  2. Add the work that starts at go-live and runs for 3 months after.

    The plan may stop at go-live. Support, fixes and training for new joiners start there.

    Done when: your list runs 3 months past go-live.

  3. Write who does each line: the integrator, a contractor or your own people.

    Where more than one firm or team does a line, split it so that each line has one.

    Done when: every line has a firm or a name against it. Where nobody is named, write ‘nobody yet’.

  4. Mark each line ‘leaves’ or ‘stays’.

    A line leaves if a supplier does it, because the supplier’s hours end with the contract. The integrator’s build team leaving is the plan, and that work ends with them. A line stays if your own people do it. A ‘nobody yet’ line stays too, until somebody is named.

    Done when: every line carries one of the 2 words.

  5. Move to ‘stays’ every ‘leaves’ line whose work carries on after the contract ends.

    The checks on each trial data load are an example. Somebody must run them after the contractor has gone.

    Done when: the work on every ‘leaves’ line ends with its contract. Every line you moved shows the date it changes hands and who takes it, or ‘nobody yet’.

  6. Write the hours a week each ‘stays’ line needs.

    Start with the resource plan. Where it has no figure, ask whoever does the work today: “How many hours a week does this take?”

    Done when: every ‘stays’ line has a figure. If no answer comes, or there is nobody to ask, write your own estimate and mark it ‘not confirmed’.

  7. Ask each person’s manager which of their usual work has stopped or moved.

    This is the hard step, because the resource plan does not answer it. It shows who is booked, and not whether anything came off their desk. One short message does it: “Which of [name]’s usual work has stopped or moved since the programme started? How many hours a week is that?”

    You cannot make a manager reply, and the test does not need you to.

    Done when: every name has a figure for hours released a week. If nothing came off their desk, the figure is 0. If no answer comes, count 0 and mark it ‘not confirmed’.

  8. Take the hours released from the hours needed, line by line.

    Where 2 people share a line, add their released hours together. Where one person is on 2 lines, split theirs between the lines.

    Done when: every ‘stays’ line has one figure, the hours a week it is short. A line above 0 is a short line. A ‘nobody yet’ line is short by all its hours. Every ‘not confirmed’ mark stays beside its figure.

  9. Mark the worst weeks for each short line.

    The worst weeks are where a milestone, such as user testing, falls on a busy time in the day job, such as year-end.

    Done when: you can name the worst weeks by date.

  10. Split the hours on each short line into decisions and repetitive work.

    Ask whoever does the work: “How many of your hours a week on this need your judgement, and how many are repetitive work?” Repetitive work is comparing documents, preparing evidence packs and writing first drafts. Send the question for every ‘stays’ line, because you do not yet know which lines are short.

    Done when: every short line shows how many of its hours are repetitive work. If no answer comes, or there is nobody to ask, write your own estimate and mark it ‘not confirmed’.

One illustrative programme comes out 42 hours a week short

This illustrative programme is replacing a finance system and goes live in 20 weeks. Its list has 12 lines.

Step 4 marks 9 of them ‘leaves’. The integrator or one contractor does all 9, from the build to the fixes after go-live. Step 5 moves 2 of the 9 across. The contractor checks each trial data load, and that contract ends in week 8. The integrator fixes defects after go-live, and its support ends in week 24. Both jobs carry on, and nobody takes either yet. So 5 lines stay. The plan puts 46 hours a week on 4 people’s desks, plus 8 on a line of work nobody holds yet: 54 hours needed. Their managers can account for 12 hours of usual work coming off, so the programme is 42 hours a week short.

Line that staysWhose hoursNeeded a weekOf which repetitiveReleased a weekShort a week
Sign off the process designsFinancial controller1020, not confirmed10
Clean the supplier recordsAccounts payable lead12848
Write and run the user tests2 management accountants248816
Check each trial data load, from week 8Nobody yet8408
Total, week 8 to go-live54221242
Fix defects, from week 24Nobody yet124012
Illustrative figures, made up for this example: for each line that stays, the hours a week needed, released and still short.Each line that stays has a bar, and so does the total. Each bar shows the hours a week needed, split into hours released and still short.Released a weekShort a weekSign off the process designs0, not confirmed + 10 = 10Clean the supplier records4 + 8 = 12Write and run the user tests8 + 16 = 24Check each trial data load, from week 80 + 8 = 8Total, week 8 to go-live12 + 42 = 54Fix defects, from week 240 + 12 = 12
Illustrative Illustrative figures, made up for this example: for each line that stays, the hours a week needed, released and still short.Source: the illustrative programme in the table above, from this guide, version 1.0, published 19 October 2026.

From week 8 to go-live the programme is short of 42 hours a week. That is more than one full-time person at 40 hours a week. The worst weeks are 12 to 16, when user testing falls on year-end.

One manager did not answer in time. So the financial controller’s release is counted as 0 and marked ‘not confirmed’, and 10 of the 42 hours depend on it.

Nobody here lacks the skill, and nobody has done anything wrong. The plan put 46 hours a week on 4 people’s desks, plus 8 on a line of work nobody holds yet: 54 hours needed. Their managers can account for 12 hours of usual work coming off, so the programme is 42 hours a week short.

LineWho does itLeaves or staysNeeded a weekReleased a weekShort a week
Configure the finance systemThe integratorleaves
Build the interfaces to the other systemsThe integratorleaves
Build the reportsThe integratorleaves
Set up user roles and accessThe integratorleaves
Run each trial data load, to week 8The contractorleaves
Train the first users before go-liveThe integratorleaves
Run the go-live cutoverThe integratorleaves
Sign off the process designsFinancial controllerstays100, not confirmed10
Clean the supplier recordsAccounts payable leadstays1248
Write and run the user tests2 management accountantsstays24816
Check each trial data load, from week 8Nobody yetstays808
Fix defects, from week 24Nobody yetstays12012
Illustrative

Propose an owner for each line that changes hands, and show how each short line could be filled

For each line that changes hands, propose the person in the organisation’s own team who takes it. Ask for them to work beside whoever does the work now, from now, and not from the last week of the contract. That is how what the programme learns stays with your team.

What stays is the record of the decisions, the evidence behind them and the way the work is done. The next programme starts from that record, not from nothing.

Enough hours let your team run the change and keep it running. What the team learns becomes the skill the next change starts with. And a change that starts from that record reinvents less and buys in fewer hours, so over time it can need less money.

A short line can be filled 3 ways. For each way your programme could use, show the hours it would give and whether those hours leave or stay.

  • Release the hours. Day-job work comes off the person: it stops, or it moves to somebody named. Those hours stay. Release suits decisions, which are your own people’s to make. Name the work that would come off. A sponsor can act on ‘the monthly report moves to a named colleague’. ‘Free up some time’ releases nothing.
  • Hire the hours. A contractor, or more of the integrator’s time, does the work. Those hours leave when the contract ends. Hiring suits work that ends, and not work that carries on. Name who takes the work on the day the contract ends.
  • Give the repetitive work to AI agents. An AI agent is software set up to do one defined task, such as comparing 2 versions of a document. On a short line it does work your people have no hours for. Your people direct the agents and make every decision. Whether those hours leave or stay depends on what the supplier leaves behind. Name what stays. Ask any supplier of agents one question: “When your contract ends, what stays with my team?” Until you have asked, write ‘not asked yet’.

Ask about 3 things by name: the agents, the software they run on and the record of your team’s decisions. The record holds what your people decide on the exceptions, such as which test failure can wait until after go-live. Keep it, and their judgement stays with your team.

Hiring and AI agents both need budget, which is your sponsor’s to find. That is why they go on the page as choices.

Put the result on one page for the person who decides

The page has 6 parts. Write roles for suppliers and never a firm’s name: ‘the integrator’, ‘a contractor’. The case is about hours, not firms.

[Programme]: where the hours are short, as at [date]

  1. The finding. Between [date] and [date], [number] lines of work are [number] hours a week short. Of those hours, [number] rest on [number] of the organisation’s own people and [number] have nobody yet. Within that total, [number] hours depend on a figure marked ‘not confirmed’.
  2. What was counted. [Number] lines of work, from the plan dated [date], up to 3 months after go-live.
  3. The hours that leave. [Number] lines are done by the integrator and contractors and end with their contracts, as planned. [Number] more carry on after a contract ends. For each of those: the date it changes hands, and who takes it, or ‘nobody yet’.
  4. The hours that stay. The table from steps 6 to 10: each line, whose hours, and the hours needed, repetitive, released and short, with every ‘not confirmed’ mark. Then the worst weeks, and what falls in them.
  5. How the gap can be filled. For each way the programme could use: the hours it would give, and whether they leave or stay. Release: the day-job work that would come off. Hire: who takes the work when the contract ends. AI agents: what the supplier says stays with the team when its contract ends, or ‘not asked yet’.
  6. The decision asked for. [One decision], by [date].

Here is the illustrative programme’s page.

Illustrative finance system programme: where the hours are short, 20 weeks before go-live

  1. The finding. Between week 8 and go-live in week 20, 4 lines of work are 42 hours a week short. Of those hours, 34 rest on 4 of the organisation’s own people and 8 have nobody yet. Within that total, 10 hours depend on a figure marked ‘not confirmed’.
  2. What was counted. The plan’s 12 lines of work, up to 3 months after go-live.
  3. The hours that leave. The integrator and one contractor do 7 lines that end with their contracts, as planned. Another 2 carry on after a contract ends. Checking each trial data load changes hands in week 8, and fixing defects in week 24. Both are ‘nobody yet’.
  4. The hours that stay. The table above, with its one ‘not confirmed’ mark. The worst weeks are 12 to 16, when user testing falls on year-end.
  5. How the gap can be filled. Release: 16 hours a week, if the 2 management accountants’ monthly reporting moves to named colleagues. Those hours stay. Hire: 8 hours a week, if the contractor stays to go-live for the data load checks. Those hours leave in week 20, when that work ends. AI agents: 22 of the 54 hours a week are repetitive work. What a supplier would leave with the team is ‘not asked yet’.
  6. The decision asked for. Take 16 more hours a week of usual work off the 2 management accountants, by week 12, when user testing starts.

Do steps 1 to 5 today, and start step 6 from the resource plan. Send your questions before you leave. When the answers are in, or 3 working days have passed, steps 8 to 10 take about half an hour. Then fill in the page. Start on a Monday and it is ready on the Friday. Take it to your sponsor, or hand it to your client: one decision, with the hours behind it.

By Pippa

This guide comes from the publisher’s own research and development, published so that others can refer to it.

Version 1.0, published 23 October 2026

Transformation Capability Management is a proposed standard, custodied by BusinessGPS, which wrote its first draft. BusinessGPS publishes capability.ai, and sells only on businessgps.ai.

From the publisher

The publisher’s tools and services for putting this into practice on a live programme are at businessgps.ai.