Programme Planning Standards: The Rules of the Game
Studies consistently show that organisations with mature project management practices achieve better delivery outcomes than those with ad hoc approaches. Yet one of the simplest disciplines is often overlooked—agreeing a common Programme Planning Standard (PPS) before delivery begins.
Imagine if the World Cup 2026 had no agreed rules. Every team across the world brought its own goalposts, every referee used a different rulebook, VAR was working from a Polaroid, and nobody knew who was keeping the official score. It would descend into chaos even before kick-offs! Complex programmes are no different. Programme Planning Standards are the rules of the game. They establish a common way of planning, reporting and governing projects so that everyone is working from the same playbook—not debating whose version of the schedule is correct.
The world's leading project management frameworks all reinforce this principle. While the PMI views the project plan as an integrated management system, APM promotes planning as a continuous and collaborative governance activity, and PRINCE2 emphasises controlled delivery through defined plans, roles, stages and tolerances. In practice, a good Programme Planning Standard should answer the question that too often becomes an argument: Who owns the plan? Where is the single source of truth? How is version control managed? Which templates and milestones are mandatory? How are RAID logs linked to the schedule? By agreeing on these standards up front, organisations spend less time debating the data and more time delivering successful outcomes.
So many times in my career, I've been parachuted into complex, multimillion-GBP programmes without the basics. Eager to ensure programme success, and to save my own sanity, I’ve created numerous planning standards. So, to save you from failure, and to improve your job searches and longevity, I’m sharing with you some of the key points:
- Programme Plan Ownership
Every programme should define who is accountable for the master schedule. Is it the Programme Planner, the PMO, the Workstream Leads, the Programme Director or the Project Managers? More importantly, who can update it, who approves changes, and who signs off the baseline? One schedule with multiple owners quickly becomes nobody's responsibility.
- Activity Naming Conventions
A schedule should read like a professional document, not someone's doodling notebook. Agree on conventions for activity names to ensure they are consistent and meaningful. For example, start activities with verbs such as Develop, Review, Approve, Install or Commission. Avoid vague descriptions like "Work Package 3" or "Testing Stuff". Consistent naming improves reporting, searching and stakeholder understanding.
- Work Breakdown Structure (WBS) Standards
The WBS should follow a common hierarchy across every project. For example:
- Level 1 – Programme
- Level 2 – Project
- Level 3 – Stage
- Level 4 – Deliverable
- Level 5 – Work Package
- Coding Dictionaries
A coding dictionary defines the metadata applied to every activity. Typical coding fields include:
- Project
- Contract or NEC Package
- Supplier
- Discipline (Civil, Mechanical, Electrical, Digital)
- Geographic Location
- Business Unit
- Stage Gate
- Responsible Organisation
- Workstream
- Funding Source
- Milestone Libraries
Rather than allowing every project to invent its own milestones, create a standard library. Examples include:
- Business Case Approved
- Funding Approved
- Design Complete
- Procurement Awarded
- Factory Acceptance Test
- Site Acceptance Test
- Operational Readiness
- Go-Live
- Practical Completion
- Benefits Realisation Review
- RAID Integration and Dashboards
Risks, Assumptions, Issues, Dependencies and Actions should not live in isolation. Every critical programme risk should link to the activities it could impact. Key external dependencies—such as planning consent, regulatory approvals or supplier deliverables—should be represented in the schedule, ensuring that the programme reflects reality rather than optimism.
- Version Control
Every schedule should have one approved master version with clear naming and storage conventions. For example:
- Baseline 1.0
- Forecast 2.3
- Monthly Update – June 2026
The standard should define where schedules are stored, who can edit them, how revisions are recorded, and how archived versions are retained for audit purposes. If your team is asking, "Which version are we using?", the standard isn't working.
- Baseline Governance
A baseline is a commitment—not a moving target. Planning standards should define:
- when a baseline is established,
- who approves it,
- when re-baselining is permitted,
- how variances are measured, and
- how changes are documented through formal governance.
- Without these rules, programme performance becomes impossible to measure objectively.
- Reporting Cadence and Process
Everyone should know when progress is reported and when data is frozen. A typical cycle might be:
- Monday: Project updates submitted
- Tuesday: Planner quality checks
- Wednesday: Critical Path and schedule analysis
- Thursday: Programme dashboard published
- Friday: Programme Board review
A consistent reporting rhythm builds confidence in the information being presented.
- Quality Assurance Checks
Before any schedule is reported, it should pass a series of health checks. These might include:
- Missing predecessors or successors
- Excessive constraints
- Negative float
- Out-of-sequence progress
- Excessive lags and leads
- Activities without resources (where required)
- Invalid calendars
- Critical Path integrity
- High-float anomalies
- Duplicate activity IDs
A schedule should meet agreed quality thresholds before it reaches senior stakeholders.
Just like the FIFA World Cup, Programme Planning Standards only work when everyone agrees to play by the same rules. They cannot be written in isolation by the planner or the PMO; they should be developed collaboratively with Project Managers, Programme Managers, Sponsors, Project Controls, commercial teams and key suppliers. Once agreed, they need to be communicated, embedded into templates, governance, reporting cycles and assurance processes, and consistently applied throughout the programme lifecycle. The result isn't more bureaucracy—it's greater trust, better decisions and fewer surprises.
After all, nobody questions the offside rule halfway through a World Cup final. The rules were agreed before kick-off. The same should be true Planetof every major programme to ensure benefit realisation, meet deadlines, and sustain ongoing success.