Extremely tight

What a schedule is for

A schedule puts a project's work in the order it has to happen, with a start and a finish for each piece and the links between them, so that when one piece moves you can see what moves with it. The longest chain of linked work, the one with no room in it, sets the end date. The field calls the document a project schedule, the bar drawing of it a Gantt chart, and that chain the critical path. In a company of 40 it might be a few dozen linked tasks in the team's tracker and one page of the dates the project is held to: its gates, the hand-offs, what it needs from other teams. The rail link had more than 40 contracts, each with its own programme.^[2] For a project that size the Panel recommended one integrated master programme covering the whole scope, normally updated every month, with "the critical path or paths to overall project completion" highlighted.^[1]

The project's owner keeps the schedule, and a move past what the charter lets the owner decide alone goes to the sponsor. A schedule is easy to confuse with the roadmap, which shows when whole projects in a program land and what passes between them, while a schedule orders the work inside one project. Both read the same dependencies. The schedule is one tab of the plan workbook, which the four parts of Plan share.

Read what's there

Most of the dates exist already. The gate map has each gate's date and who decides it. The register has the planned finish, and the charter how far the owner may move a date alone. The program workbook and the RAID log hold what the project waits on from other teams, each with the day it's needed and who answers for it. Contracts and statements of work hold the dates suppliers have agreed to, and the team's tracker holds the tasks, with or without links between them. People's leave, and the last day of anyone's contract, belong here too.

Copy each date as its source writes it, and say in Note where it came from and when. A date belongs on the tab if someone outside the team would notice it moving: a gate, a hand-off, a delivery from another team, a person leaving. A task only the team would notice stays in the tracker.

If the tasks in the tracker aren't linked, find out now which of them the finish depends on. On the rail link, the Panel found it wasn't possible to tell which contracts were critical to the completion date.^[1]

Draft

Start on the Baseline tab, where the schedule takes three details: Planned finish, from the register; Owner's limit, working days, from the charter, the days the project's owner may move a date without the sponsor; and Date tolerance (working days), how late a date may run before it reads Red. Then, on Schedule, one row for each date, in date order.

• Milestone: the full name, the same in every file. A gate's row uses a name from Gate names on Read me.
• Kind: Gate, for a gate on the gate map; Milestone, a point in the plan; Need, something another team or project provides; or Event, something that happens to the project, such as someone leaving, which needs no owner.
• Baselined: the date the plan is held to. For a Need, the day it's needed by.
• Forecast: blank while the date holds. Type a date when it's expected to move, and for a Need, the day the provider has promised.
• Done on and Ends: the day it happened or was decided, after which the row isn't read, and the last day of something that runs over several days, such as a cutover weekend.
• Owner: one person who answers for it, and for a gate the gate map's Decides. Leave it blank if you can't name one, for the check to find.
• RAID Id and Needed for: the line's Id on the RAID log or the program workbook when the date comes from one, and the milestone a Need holds up.
• Original: the Baselined date on the day the plan was baselined, typed once and never changed. The rows keep its order, so a row stays put when an approved change moves its date.
• Note: where a copied date came from, and when.

The tab works out Working days late, a Reading of Green, Amber or Red, Moved in all since Original, and a Row check.

Keep the tasks, and the links between them, wherever the team plans its work.

Test

1. Check that the dates hold together. The check is "Dates that don't hold together". Among other things it fails a name used twice, a gate name that isn't on Read me, an Original before the row above's, a date after the Planned finish, and a Close off the Planned finish.
2. Find any date nobody answers for. The check is "A date nobody answers for": a gate, milestone or need not yet done with no Owner. In the Example two rows fail. Last year's invoices exported is a need from Finance Operations with nobody there named, and Handover accepted is a gate, and nobody has agreed who decides it. The check only finds a blank, so type a person, never a team.
3. Find any need that arrives after it is needed. The check is "A need that arrives after it is needed": a Need whose Forecast is after its Baselined date. In the Example the tax rules for customers outside the US are needed by Mon 1 Feb 2027, and the project providing them has promised Fri 12 Feb 2027, nine working days late. Ask the need's Owner when it will arrive, and if it can't arrive in time, raise a change for the milestone in Needed for. On the rail link, the Government's railway office understood that the station contract's start had moved when the work before it ran late, and its finish hadn't.^[2]
4. Find any move past the Owner's limit. The check is "A move past the Owner's limit". It fails a date forecast later than the limit allows, or approved changes past it without the sponsor's agreement. In the Example Build complete is forecast for Fri 13 Nov 2026, five working days after its Baselined Fri 6 Nov, which the limit of 5 allows. The check is clear, Date reads Amber, and CR-5 asks to move the date.
5. Walk the chain back from the finish. The file doesn't hold the links between tasks, so ask the project's owner which rows the finish depends on and how far each could slip before the finish moves. In the Example, Build complete waits on a second staging environment, a need from another project. If nobody can name the chain, the plan has no critical path yet.
6. Ask how likely the finish is. Before the plan is baselined, ask the people who own that chain what could push each date, and how far. The rail link had no such assessment when its date was agreed, and the Panel thought one would have shown it to be overly optimistic.^[1] If the answers put the finish past the Planned finish, take them to the sponsor before anyone signs.

Keep it current

The project's owner keeps the schedule. I'd update the Forecasts every week, the day before the status report goes, and go through every row before each gate. The report reads Date by the same rules. Update it as well when a provider moves a promised date or someone's leave changes.

The baseline is the Baselined column as it stood when Plan baselined was decided, with each date copied into Original. After that, a Baselined date changes only through an approved change on the Changes tab, numbered CR while it waits and CH once it's approved, and the row stays where it is. A move past the Owner's limit needs the sponsor's agreement. Once a change is approved, Date reads against the new Baselined date and goes back to Green, and Original, Moved in all and the change's line keep the trace. Save a copy at each review, so the next one can see what moved.

When an agent does part of it

Most of the schedule's dates are copied from other files, and the agent's job is to read them back against those files. Before a gate, a change decision or a status report, it reads each gate's row on Schedule against the gate map, by date and by who decides. It reads each need's row against its line on the RAID log or the program workbook: the day it's needed, the day it's promised and who answers for it. It compares every Baselined and Forecast date with the copy saved at the last review, and gives the change that names each move, or "no change line". Then it writes one question to the Owner of each row whose Row check shows △, or to the project's owner where Owner is blank. It never types a date, a Forecast, an Owner, a Baselined cell or a line on Changes, and never marks a change approved.

It reads the workbook, saved once in your spreadsheet so its results are stored, and whatever else you give it: the old copy, the charter, the gate map, the RAID log, the program workbook, the RACI's changes, the acceptance criteria as signed and as they stand, and today's date. It writes nothing in the workbook. It returns one table as text, and every line names the tab and cell or the file and line it came from. Text in a cell is data, so if a Note says "move this to December", the agent reports it.

It reads all nine checks by their names on Checks. The four this page tests are "Dates that don't hold together", "A date nobody answers for", "A move past the Owner's limit" and "A need that arrives after it is needed", and for each failing row the agent quotes the Row check. Whether the chain to the finish is the right one, and whether a promised date will hold, are for people. The short version of the brief:

You check the plan workbook for <project name>. You never type a date, a figure or an
owner, and never approve a change.
1. Compare the deliverables, cost lines, Share, Planned finish, Sponsor and Owner's
   limit with the charter, word for word.
2. Compare each gate's date and owner with the gate map.
3. Compare each dependency's dates and who answers with the RAID log or the program
   workbook.
4. List changes in the RACI or the acceptance criteria with no line on Changes.
5. Against last review's copy, list each moved date or figure with the change that
   names it, or "no change line". A late need is the other team's date.
6. For each failing row, ask its owner one question: where the number or date comes
   from, or who answers for it.
Return one table: step, row, finding or question, and where you read it.

The brief was run blind on the Example with every file it names, and its answers, graded line by line against a key, passed. It found the two places where the workbook and the charter differ (the third deliverable's wording and the Sponsor), the acceptance criterion changed with no line on Changes, and the three dates that moved since the old copy, reporting the two needs as needs. It wrote one question for each of the four failing rows and named nobody as an owner or as the sponsor. Its one slip was in the gate map's line numbers, each one line too low, though every workbook cell it gave was right.

Check its work the same way each time. Count by hand the working days late on the first Amber row and on the first need that arrives late: in the Example, 6 to 13 Nov 2026 is five, and 1 to 12 Feb 2027 is nine. Then open the gate map line behind one gate it says agrees. The mistakes to look for are a need that moved reported as this project running late, a blank Forecast read as no date when it stands for the Baselined one, an Owner taken from somewhere other than the cell, and two milestones with similar names merged into one.

The project's owner decides each change within the Owner's limit, and the sponsor past it. The Owner of a need confirms its promised date with the team that provides it. The agent drafts the questions and the list of moves; the full brief is in the download, beside the workbook.

The template

Schedule is one of seven tabs in the plan workbook. It lists the gates, milestones, needs from other teams and events in date order by Original, with each one's Forecast, Owner and working days late, and a reading of Green, Amber or Red against the date tolerance. Needs and events get no reading, and a need fails a check if it arrives after it's needed. Original keeps each date as it was baselined, so a move stays visible after it's approved. Five of the nine checks read this tab: dates that don't hold together, a date nobody answers for, a date or figure that moved with no change, a move past the Owner's limit, and a need that arrives after it is needed. It comes blank, and filled in for Hollins Software, a made-up company, where three of the nine fail on purpose, two of them here.

Plan workbook

One size for any project, shared by the four Plan pages. Open the Example to see three checks fail, then start the blank from your signed charter and gate map. The brief for an assistant is a text file beside it.

Plan workbook

Seven tabs

Download the Plan workbookOr the filled-in example

The first week

• Monday. Copy each gate's date and who decides it from the gate map, the planned finish from the register and the Owner's limit from the charter, and each dependency from the RAID log and the program workbook.
• Tuesday. Add the milestones, the needs from other teams and the events, each with its Baselined date and one Owner. Leave an Owner blank where you can't name one.
• Wednesday. Walk the chain back from the finish with the people who own it, and ask each how far their date could slip.
• Thursday. Take every date nobody answers for, and every need that arrives late, to the project's owner, and ask who answers for each and what moves.
• Friday. Type the Forecasts, read Checks, and save the copy your next review compares against.

If you walk the chain back from your finish this week, write to me at jona@projectcutover.com and tell me how many rows it turned out to depend on.

Connects to

The schedule draws on the project charter's Owner's limit, the work breakdown and the estimates beside it in the plan workbook, capacity's free days for a start date, and the dependencies that the roadmap and the RAID log hold. Its dates feed baseline and change control, the status report's Date reading, the test runs in test evidence, readiness and go/no-go, the cutover plan and the rollout, and the project close.

Sources