At the same time

What a program is

A program is a group of projects run together because they serve one goal, with one person who answers for the benefits they're meant to bring. GovS 002, the UK government's standard for project delivery, calls it a "temporary, flexible organisation" that oversees a set of projects and related work "to deliver outcomes and benefits related to a set of strategic objectives".^[2] It can run in tranches, each built around a step change in what's delivered and the benefit that follows. It ends when the people who run things afterwards have taken over tracking its benefits, with its open risks, issues and actions.^[2]

In a company of 40 a program might be two or three projects for one goal, run by one person for a year. What the program is for, and how anyone will know it worked, goes in its program charter.

Who runs it

GovS 002 asks for two named people on every program.^[2] The senior responsible owner (most companies say sponsor) owns the business case. They answer for the program meeting its objectives, delivering its outcomes and realising its benefits, to the level above, which the standard calls the sponsoring body. The program manager answers to the senior responsible owner for setting up how the program is run and for running it day to day.

The standard expects both to have support, from what most people call a program office or PMO, which can run the processes, the analysis and parts of the governance for them.^[2] HBL had none. In a company of 40 the sponsor is often the CTO, and the program manager also runs one of the projects. The program office is an hour a week someone spends keeping the program's workbook up to date.

What it decides

A program decides how its projects fit together: the order they run in and what each needs from the others and by when. When a milestone is under threat, it trades time, cost and benefits against each other. The Auditor-General said one integrated plan for HBL, showing the critical paths and dependencies, would have helped with those decisions.^[1]

It works inside limits set from above. GovS 002 asks for tolerances on cost, benefits and schedule within which a manager needn't escalate, and the sponsoring body decides anything beyond the senior responsible owner's authority.^[2] The portfolio starts the program. Each tranche ends in a Strategic review, chaired by the sponsor, which can continue, adjust or stop the program within the portfolio's limits. The review goes to portfolio steering, which authorises the next tranche, a decision GovS 002 names.^[2] A project's gates are decided by the people its gate map names, with the program manager consulted.

What the program board reads

GovS 002 asks for reports that are "factual and realistic": progress to date, whether the work is likely to finish to plan, the risks and issues, and the decisions or direction needed.^[2] Each benefit should have an owner who forecasts and tracks it, and the plan should define the dependencies between projects.^[2]

From HBL's program, I'd build the page like this:

• Read each benefit from its numbers. Each benefit sits with its owner, target and forecast, and its reading (On track, Amber or Red) is worked out from the forecast. While a figure is missing it reads Not read.
• Show each saving net of what it costs to run. Beside every money benefit goes what's left in a year once its running costs are taken off.
• Put every dependency on one list, worst first. What each project needs, who provides it, when it's needed and when it will arrive, with one person who answers for it.
• Take the outcome date from the projects. The program's date is the later of the forecast someone typed and the latest forecast of any Active or Paused project, so a typed date can't hide a late project.
• Name who reads the benefits after the program closes. A benefit whose target date falls after the finish needs someone to take it.

Test the dashboard before the program board reads it

1. What is each project waiting on? The check "A dependency that won't arrive in time" fails a dependency that arrives after Needed by, one that's past due and one that was declined. HBL's procurement service went live without the finance system it was meant to work with.^[1]
2. Has anyone asked? "A dependency nobody has answered for" fails one nobody has asked about, one with no one in Who answers or no date, and one still marked Asked more than ten working days after it was asked. At HBL, the auditor traced poor information flow to the missing program office.^[1]
3. Is the outcome date the projects' date? "An outcome date later than the limit allows" fails when the outcome date runs more than ten working days past Planned finish. If Planned finish has moved since the last board, ask the program manager who agreed it. HBL's board heard "running to plan" in October 2013 about a plan that had already been revised.^[1]
4. Is every saving net? "A saving not shown net of what it costs to run" fails a money benefit with no line on Costs. HBL's early start at one board ran up costs its business case hadn't budgeted for.^[1]
5. Where did each figure come from? "A benefit that can't be read, or is overdue" catches a missing baseline or a review date that has passed. It can't tell where a forecast came from, so ask each benefit's owner.

When an agent does part of it

Hand an agent the workbook and the Register each week and before each program board. It checks each project name on Roadmap and Dependencies against the Register, letter for letter, which finds what "A roadmap that doesn't match the Register" can't: one project spelled two ways. It recounts each Active or Paused project's working days late, lists each benefit's blanks and where it differs from the signed charter, picks out every dependency not asked, waiting too long or arriving late, and drafts the last meeting's actions with one owner and a date.

Save the workbook once first, so its results are stored, and add the charter, the tracker export and the notes if you have them. It writes nothing in the workbook, and each line it returns names the tab and cell, or the file and line, it read. It redoes the counts behind the nine checks and leaves two to a person, "A benefit read after close, with nobody to take it" and "A saving not shown net of what it costs to run", because someone has to name the owner or find the cost.

You keep the program workbook for <program name>. You draft and check. People decide.
You never type a Baseline, Target, Forecast, Promised date, State, Owner, Chair, Sponsor
or Status, and you never mark an action Done.
1. Names: list each Roadmap and Dependencies project not spelled as the Register
   spells it.
2. Dates: recount each Active or Paused project's working days late. A Proposed project
   is "Proposed, not counted".
3. Benefits: list the blanks, compare with the charter, and flag for a person a target
   after the finish with nobody to take it, or a money benefit with no cost line.
4. Dependencies: list each one not asked, waiting too long, or arriving after Needed by.
5. Meetings: draft actions from the notes with one owner and a date, or "not stated".
6. Due soon: reviews in the next 14 days, asks past the limit, overdue actions.
Return one table: step, item, what you found, and the tab and cell you read it from.

In a test of the full brief on the Example, with its Register, charter and board notes, an assistant found every planted fault and filled no field a person owns. It also misread two Asked on dates, and its answers came out right only because both wrong dates fell inside the limit. So check the cells as well as the answers: recount one Asked dependency from its Asked on date, rework one benefit's shortfall, and check one drafted action against the notes. Also look for a Proposed project counted in the outcome date, and an owner picked where the notes name two.

The program manager keeps the workbook and takes the Dashboard to the board, and each benefit's owner types its reads and Forecast.

The dashboard

The program workbook has seven tabs: Read me, Dashboard, Benefits, Costs, Roadmap, Dependencies and Meetings. On the Dashboard you type the program as the Register has it, and limits you can change; everything under them is worked out. One line gives the program's colour, how many of the nine checks fail and the next decision point. Then come the first eight benefits, the dependencies worst first, and the checks, each saying in a sentence what's wrong. They look for a benefit that can't be read, isn't net or has nobody to take it after close, a roadmap that doesn't match the Register, a late outcome date, a dependency unanswered or late, a forum without a chair or limits, and a stuck action. The workbook comes blank and filled in for Hollins Software, a made-up company, and the filled-in one fails six of its nine checks on purpose.

The Dashboard, in the program workbook

One workbook per program, in one size: open the Example to see six of its nine checks fail, then start on the blank. The brief for an assistant is a text file beside it.

Program workbook

Seven tabs

Download the Program workbookOr the filled-in example

Its parts

• Program charter and benefits What the program is meant to deliver, and how anyone will know it did once the projects have closed. Answers: what is this program for, and how will we know it worked?
• Roadmap and dependencies When each project lands, and which ones are waiting on another. Answers: what's waiting on what?
• Program meetings The meetings a program holds, and what each one is allowed to decide. Answers: where does this get decided?

Sources