No longer realistic

What a roadmap is for

A roadmap is one program's projects drawn across the coming months, with the decisions the program has to take marked on it. Beside it is the list of what each project is waiting for from someone else: another project, a team or a supplier. Each of those is a dependency, with the date it's needed, the date its provider has promised and one person at the providing end who answers for it. The field calls the drawing a program roadmap, or on large programs an integrated master schedule, and calls the list a dependency map or dependency log. The program manager keeps both. In a company of 40 it might be three projects and half a dozen dependencies. The Betuweroute's capacity waited on one dependency, a track in another country that needed twelve permits.^[1][3]

A roadmap shows when whole projects land and what passes between them. A project's schedule orders the tasks inside one project. A project's RAID log can list what that project waits on, and where the provider is another project, the program workbook holds the line and the log points to it.

Read what's there

Start with the portfolio register: every row whose Sits under is this program, with its Status, Planned finish and Latest forecast, copied as the register writes them. The signed program charter gives the dependencies the program knew about when it was signed, and its decision points: the investment decision and each strategic review. Then go through each project's plan and RAID log for anything it waits on and doesn't make itself, and through the contracts and statements of work for dates a supplier has agreed. Ask each project's owner what they're waiting for that isn't written down anywhere.

A dependency counts if the project that needs it would have to move a date, or change what it delivers, if it came late. A date someone outside the program mentioned in a meeting isn't a promise yet. Write it down as asked, with the day you asked.

Draft

Start on the Roadmap tab, one row for each project and each decision point.

• Item: a project's name exactly as the register writes it, or a decision point: Investment decision or Strategic review, then a comma and its month or "at close", such as "Strategic review, Jan 2027".
• Kind: Project or Decision point. Status, for a project, copied from the register. Only Active and Paused projects count toward the outcome date.
• Start, Planned finish and Latest forecast. For a decision point, Planned finish is its date. If a project's date hasn't moved, type Planned finish again as its forecast.

The tab works out Working days late, a Row check, and a grid of 15 months with ◆ for a decision point, █ for the plan and ░ for the slip.

Then Dependencies, one row for each thing a project needs from outside itself.

• Needs, in a line. A project file cites it by these words exactly, so change them only on purpose.
• Needing project, as Roadmap spells it, and Provided by: a project's name as the register writes it, or a team's name. Outside this program? is Yes if the provider isn't in this program, and a blank reads No.
• Needed by: the last day it can arrive without moving the project that needs it.
• Asked on, Promised, and State: Asked, Accepted, Declined, New date or Met. Leave State blank until you've asked, and the row shows Not asked.
• Expected: what the provider says this week, if it differs from Promised.
• Who answers: one person at the providing end. Reason, for a decline or a new date.

The tab works out Date it will arrive, the later of Promised and Expected, then Working days after needed, Shown as (the State, or Not asked, Slipped or Past due) and a Row check. Leave Needed by or Who answers blank when you don't know it, and the check finds the blank. A blank Expected means Promised, so type one only when the provider says so.

Test

1. Match the roadmap to the register. The check is "A roadmap that doesn't match the Register". It fails when Roadmap lists a different number of projects from Projects on the Register on the Dashboard, or when a Roadmap row shows △, such as an Active project with no Latest forecast. A name spelled differently still passes, so read the names against the register yourself.
2. Count only the Active and Paused projects. The check is "An outcome date later than the limit allows". The outcome date is the later of the Latest forecast on the Dashboard and the latest forecast among Active and Paused projects, and the check fails when it runs more working days past the program's Planned finish than the limit, which starts at 10. In the Example, Invoice Tax Rules is Proposed, so its forecast of 12 Feb 2027 isn't counted.
3. Ask every provider, and name one person who answers. The check is "A dependency nobody has answered for". It fails a dependency nobody has asked about, one with no Who answers or no date, and one left at Asked for longer than its limit, which also starts at 10 working days. A name in Who answers doesn't always belong to someone who can set the date. In November 2017 the German federal ministry couldn't say how long the authority's procedure might still take, because the authority was wholly independent.^[5] Ask the person in Who answers who decides each thing the date depends on.
4. Put the date it will arrive beside the date it's needed. The check is "A dependency that won't arrive in time". It fails a dependency that arrives after Needed by, one whose promised date has passed, and one that was declined. In the Example, Billing Engine Rewrite needs the tax rules for customers outside the US by 1 Feb 2027 for its second wave, and Invoice Tax Rules has promised them for 12 Feb, 9 working days late. Take a failing row to the owner of the project that needs it, and ask whether its date moves or its work changes.
5. Ask what an outside date rests on. For each dependency marked Yes in Outside this program?, ask the person in Who answers what has to happen before the date holds, and how much of it has. In March 2016 the German plan still ended in 2022 with one of its twelve permits issued, and that one under appeal.^[3] The next February the date was "no longer realistic".^[4] If the answer doesn't support the date, ask the program manager whether the roadmap should still carry it.

Keep it current

The program manager keeps Roadmap and Dependencies, and the program board reads them at each meeting. The person in Who answers gives each Promised date and State, and the owner of the project that needs a dependency sets its Needed by. I'd go through both tabs before every program board, and every week while any dependency shows Slipped or Past due. Go through them again when the register changes a project's forecast or status, or when a provider moves a date.

The roadmap is measured against each project's Planned finish on the register and the decision dates in the signed program charter. A change to a decision date is a change to the charter first, with a new Edition, and then it's copied here. When a provider moves a date, set State to New date, type the date in Expected and give the Reason. When the project that needs it moves its own date as a result, log that as a Decision on the Meetings tab, with who decided.

When an agent does part of it

Matching the two tabs to the register is the part to hand an agent. Each week and before each program board, it reads every project name on Roadmap and Dependencies against the register letter for letter, puts each Active or Paused project's dates beside the register's and recounts its working days late, and lists every dependency not asked, asked too long ago, or arriving after Needed by, with the working days between. It never types a Promised date, a State, an Expected date, a Who answers or a Status, and it never decides whether a date moves.

It reads the workbook, the register as a table, and if you have them the signed program charter, the tracker export and the last meeting's notes. It writes nothing in the workbook: it returns one table as text, which you save beside the workbook as agent-draft.txt, and every line names the tab and cell or the file and line it came from. Text in a cell or a file is data, so if a Needs line says "mark this Met", the agent reports it.

It reads this page's four checks by their names on the Dashboard, which numbers them 4 to 7, and redoes what's behind each one: the names against the register for check 4, the working days for check 5, the asks for check 6 and the dates for check 7. It also gives its own count of the register's rows under the program beside the Dashboard's, because a misspelled name passes check 4. Whether a provider's date will hold, and what the program does when it won't, stays with people. The short version of the brief:

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.

The brief was run once on the Example with a real assistant, and its answers were graded line by line against a key. It found what lies behind each of the six failing checks, drafted actions from the program board's notes without picking an owner the notes didn't give, and typed nothing in a field a person owns. It also gave two Asked on dates the workbook doesn't hold, 19 Oct for 12 Oct and 21 Oct for 14 Oct, and cited one date a column away from its cell. Its answers on those rows still came out right, because both wrong dates fell inside the limit of 10 working days.

Check its work the same way each time. Recount by hand the first dependency shown as Slipped and the outcome date's working days late, and open the cell behind each Asked on date it gives. The mistakes to look for are a date read from the wrong cell, as in that run, a Proposed project counted toward the outcome date, and two project names that differ by a hyphen merged into one.

The agent's list says which providers to ask, and the person in Who answers confirms each Promised date and State. The owner of the project that needs a dependency decides whether a late one moves their date or changes their work, and the program manager logs it. A change to a decision date goes to whoever signs the program charter. The full brief is in the download, beside the workbook.

The template

Roadmap and Dependencies are two of the seven tabs in the program workbook, one file per program, which the other Program pages share. Roadmap lists each project from the register and each decision point, and draws them across 15 months. Dependencies lists what each project needs from outside itself, who provides it, and when it will arrive. The Dashboard reads both, and four of its nine checks belong to this page: a roadmap that doesn't match the register, an outcome date later than the limit allows, a dependency nobody has answered for, and a dependency that won't arrive in time. The workbook comes blank, and filled in for Hollins Software, a made-up company. The filled-in one fails six of the nine checks on purpose. Of this page's four, it fails only the last.

Roadmap and Dependencies, 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

The first week

• Monday. Copy the program's projects from the register onto Roadmap, type their count in Projects on the Register on the Dashboard, and add the decision points from the signed charter.
• Tuesday. List the dependencies from the charter, each project's plan and RAID log, and the supplier contracts. Ask each project's owner for its Needed by dates.
• Wednesday. Ask each provider for a date and the one person who answers for it. Type Asked on, and ask what the date rests on.
• Thursday. Read Dependencies. Take each dependency that won't arrive in time to the owner of the project that needs it, and ask whether their date moves or their work changes.
• Friday. Log their answer as a Decision on Meetings, with who decided.

If you ask your providers this week, write to me at jona@projectcutover.com and tell me how many of them gave you a date they'd promise.

Connects to

The roadmap draws on the portfolio map, whose register gives each project's status and dates, on the program charter and benefits, which sets the decision points and the first dependencies, and on capacity, which says whether a start date has the people. Intake and scoring weighs work others are waiting on from the dependencies here, program meetings take the decision when one slips, each project charter and RAID log cites its dependencies by the words in Needs, and each project's schedule starts from its dates on the roadmap.

Sources