In this essay
A program toolkit should help a team make and carry out a decision. If a dependency map does not show who needs to provide what, or a status report hides a change to the forecast, the document exists without doing its job.
This guide is an index of practical records. The examples are illustrative, not records from a personal project. Choose the detail and review frequency needed for the work rather than creating every template at the start.
Start with six connected records
| Record | Question it should answer | Minimum useful content |
|---|---|---|
| Program charter | What change are we coordinating? | Outcome, sponsor, scope, constraints, authority and initial benefit owners |
| Integrated plan | What must happen, in what order? | Accepted outputs, dependencies, owners, capacity and current forecast |
| RAID register | What could change the plan or is already blocking it? | Type, consequence, owner, action, decision date and escalation trigger |
| Decision log | What was agreed and why? | Options, evidence, approver, conditions, effective date and affected records |
| Change record | What does a proposed change alter? | Scope, cost, timing, risk, benefits, alternatives and approval |
| Status report | What needs attention now? | Accepted progress, forecast variance, major exposure and decisions needed |
These records should link. A dependency issue may trigger a change request, a sponsor decision and a new plan version. Requiring someone to retype the same facts into separate systems increases the chance of inconsistent reporting.
Choose a delivery approach and review points
PMI's Agile Practice Guide covers lifecycle selection and combinations of approaches. Governance and iterative work can coexist. Define the evidence required for material decisions and let teams use suitable delivery practices inside those boundaries.
The hybrid delivery guide explains that distinction. Avoid labeling every regulatory activity “capital” or describing a fixed set of gates as mandatory PMBOK practice.
A completed dependency record
Suppose a partner certificate is needed before end-to-end payout tests can start. This is an invented scenario.
| Field | Illustrative entry |
|---|---|
| ID | DEP-07 |
| Providing owner | Partner integration contact |
| Receiving owner | Internal integration lead |
| Output | Certificate, working test environment and agreed response fixtures |
| Acceptance | Receiving lead completes connectivity check and validates agreed test cases |
| Required date | Working day 8 of the test period |
| Latest useful decision date | Working day 6, before the remaining test window becomes infeasible |
| Current evidence | Partner confirms environment; certificate not yet supplied |
| Action | Obtain written certificate date and confirm environment access |
| Trigger | If the certificate date remains unconfirmed at the decision point, ask sponsor to choose scope/date options |
This shows the difference between noting a dependency and managing one. It does not claim the internal lead controls the partner's delivery date.
Change control: show the impact before changing the baseline
APM's change-control explanation describes evaluation and approval of changes to an agreed baseline. In practice, compare options before editing the commitment, then communicate the authorized decision.
Here is a completed illustrative record. Amounts and dates are invented.
| Field | CR-03: partner status changes |
|---|---|
| Baseline | Version 1: limited launch in week 10, $100,000 delivery budget |
| Request | Partner introduces an additional pending state and replaces one callback field |
| Evidence | Updated partner contract and fixtures reviewed by integration lead |
| Scope | Mapping, API response, reconciliation exception and support instructions change |
| Cost | Estimated $8,000 extra implementation/testing; finance to confirm charging |
| Timing | Full scope moves forecast to week 11; an unchanged week-10 release would omit the affected method |
| Risk | Incorrect mapping could present an unresolved payment as failed |
| Benefit | Full-method benefit starts later under the week-11 option; reduced scope reaches fewer merchants |
| Options | A: move full release to week 11; B: keep week 10 with approved reduced scope; C: hold the affected integration |
| Decision | Sponsor approves A after product, engineering, operations and control-owner review |
| Baseline update | Version 2: week 11 and $108,000; version 1 retained for variance history |
| Follow-through | Update merchant communication, test plan, forecast, training and benefit-review dates |
A current forecast can change before the sponsor approves a baseline change. Report both truthfully. If a required control has not been accepted, a schedule decision alone cannot waive it.
Use meetings for the decisions they can make
Workstream reviews handle dependencies and emerging issues. Sponsor reviews handle decisions outside delegated authority. A benefits review asks whether the operating change is producing the intended result. Choose the frequency and attendees based on urgency and exposure; a decision that cannot wait needs an out-of-cycle route.
Send a concise pre-read with the decision, options, evidence, recommendation and latest useful decision date. Record acceptance, rejection, deferral or a request for specific missing evidence. The RAID and steering guide provides a populated sponsor paper.
Include money, people and the receiving business
The plan should connect to the budget and capacity forecast. An approval task is not feasible if the reviewer is assigned elsewhere. A handover is not ready if support funding ends with the implementation budget.
Use a business case and benefits register for investment assumptions, and the transition record for operating acceptance. A delivery milestone and a benefit measure are different records linked by the change people will make.
Choose tools that preserve the links
An existing task tracker, document system and small structured register may be enough. Preserve versions, approvals and access rights. A portfolio view should reuse team information where possible, rather than demand a duplicate board.
Check whether a workstream lead can locate the current decision and update its evidence. Then check whether the sponsor can see the consequence without opening every engineering task. Those tests are more useful than a universal prescription for a particular tool or a fixed number of artifacts.
FAQ
Do all programs need all six records as separate documents? No. Small initiatives can combine them. Keep the decisions and history identifiable even when the format is lightweight.
How often should the steering committee meet? Agree a cadence and urgent route based on decision lead times. Do not let a scheduled meeting become the reason a time-critical decision waits.
Who owns benefits after closure? Named business owners under the agreed sponsor governance. The program lead coordinates the transfer and any agreed post-launch review period.
Closing thought and further reading
A practical program toolkit with completed dependency and change records, explicit baselines and useful sponsor decisions.
Ideas that continue the thread.
View all essays
Need help applying this to your business?
Explore practical support for payment operations, product decisions, program delivery and AI automation, grounded in the challenges behind this essay.