Project Delivery · Project Control Methods
Project Control Principles and Governance
Project-control principles are durable decision rules. They prevent a method from becoming a collection of disconnected templates and ceremonies. This guide explains seven mutually reinforcing principles and shows how to turn them into observable governance behaviours, escalation rules and evidence requirements across the project lifecycle.
Executive summary
What this guide enables
Project-control principles are durable decision rules. They prevent a method from becoming a collection of disconnected templates and ceremonies. This guide explains seven mutually reinforcing principles and shows how to turn them into observable governance behaviours, escalation rules and evidence requirements across the project lifecycle.
Learning outcomes
- Apply seven governance principles as observable behaviours rather than slogans.
- Diagnose principle failures in plans, decisions and delivery records.
- Design stage and exception governance that preserves delegated authority.
- Use product focus and learning to improve decision quality throughout delivery.
Control guidance
Why principles matter
A control framework cannot prescribe every response to every project condition. Projects vary in scale, urgency, commercial model, technology, regulation and uncertainty. Principles provide a stable foundation when the detailed procedure must change. They guide judgement, allow a project to be tailored without losing its control logic and give assurance reviewers a way to distinguish genuine adaptation from the quiet removal of accountability.
The principles work as a system. Product focus makes scope and quality measurable. Stages create points at which justification can be reassessed. Tolerances make delegation possible within each stage. Defined roles identify who can decide. Learning improves the assumptions behind those decisions. Tailoring keeps the whole arrangement proportionate. Weakness in one principle usually degrades the others, so a review should examine the pattern rather than checking isolated labels.
A principle is effective only when it can be observed. A project does not demonstrate continued justification merely because it has a document called a business case; decision records must show that viability was reconsidered as conditions changed. It does not demonstrate management by exception merely because tolerances appear in a plan; forecasts must trigger escalation before authority is exceeded.
Control guidance
Principle 1: maintain continued justification
A project must have a valid reason to start, and that reason must remain valid. Justification considers not only expected benefits but also cost, timescale, dis-benefits, risk, affordability and the consequences of doing nothing. Even work required by law, policy or safety needs a defensible delivery option and value-for-money reasoning; the mandate may remove the option of doing nothing, but it does not remove the need to choose a viable approach.
Responsibility for the justification belongs with the accountable business decision-maker, supported by the project manager's forecasts and analysis. The project manager should not become the sole owner of the reason for investment, because this would blur the boundary between managing delivery and representing business value. The justification is developed at startup, strengthened during initiation, reviewed at stage boundaries and tested whenever a major issue, risk or change affects viability.
A changed business case does not automatically require closure. Assumptions, forecasts and benefits may evolve while the project remains worthwhile. The decisive condition is whether the revised case remains desirable, viable and achievable within the decision-maker's authority. If justification disappears, the project should not continue merely because money has already been spent.
| Control question | Evidence to inspect | Decision or response |
|---|---|---|
| Is there a valid reason to continue? | Current costs, benefits, dis-benefits, risk, schedule, affordability and strategic alignment | Continue, reshape, pause or close |
| Are benefits owned and measurable? | Benefit profiles, measurement method, baseline, owner and review dates | Confirm ownership, improve measures or revise the case |
| Have options changed? | Issue, risk, market, policy, operational and technical evidence | Re-evaluate preferred option and opportunity cost |
Control guidance
Principles 2 and 3: learn and assign accountability
Learning begins before planning. The team should seek relevant experience from earlier projects, operations, suppliers and specialists, then identify which lessons apply to the current context. During delivery, lessons are captured when evidence is fresh, not saved for a final workshop. Useful lessons describe the condition, action, result and recommendation. They should influence plans, quality methods, risk responses, work packages and governance rather than sitting in a passive log.
Defined roles and responsibilities create a temporary organisation around three interests: the business interest that protects value and funding, the user interest that defines need and realises benefits, and the supplier interest that confirms feasibility and creates the products. These interests may be represented by several people, but each required accountability must be unambiguous. The governing body collectively directs; the project manager manages day-to-day within delegated boundaries; delivery leads accept and execute authorised work.
Role design must avoid conflicts. The person accountable for overall business value should not also act as the day-to-day project manager. Assurance must retain enough independence from the manager and delivery work it reviews. A role may be combined on a small project only when the resulting person has the capacity, authority and absence of conflict needed to perform every responsibility visibly.
| Interest or level | Primary concern | Key decisions | Evidence expected |
|---|---|---|---|
| Business | Value, affordability and strategic fit | Start, continue, fund, stop | Business case and benefit evidence |
| User | Need, usability, acceptance and benefit realisation | Requirements, acceptance, operational readiness | Product criteria, acceptance and adoption measures |
| Supplier | Feasibility, resources and technical integrity | Delivery approach and product completion | Plans, estimates, quality and technical records |
| Project manager | Integrated day-to-day control | Authorise work, correct, report and escalate | Stage forecast, registers, work packages and reports |
| Assurance | Independent confidence in value, user and supplier perspectives | Advise and challenge | Review findings and follow-up evidence |
Control guidance
Principles 4 and 5: manage by stages and exception
Management stages limit commitment to a horizon that can be planned with useful confidence. At the end of each stage, the governing body reviews what was delivered, how the stage performed, what has changed, whether the project remains justified and whether the next-stage plan is credible. Authority is then renewed for the next interval. This creates a sequence of investment decisions rather than one irreversible approval at the beginning.
Management by exception makes that staged governance efficient. Each level delegates authority through tolerances for time, cost, quality, scope, benefits and risk. As long as the forecast remains within those boundaries, the delegated manager acts without seeking higher approval for routine decisions. When a breach is forecast, the manager raises an exception with impact, options and a recommendation. The higher authority may accept a revised plan, change tolerance, alter scope, pause or stop.
The forecast trigger is essential. Waiting for an actual breach removes decision time and can turn a manageable deviation into a failure. Equally, escalating every minor variance destroys delegation. A tolerance must be measurable, aligned with the higher-level tolerance and supported by a reporting rhythm capable of detecting a threatened breach early enough to act.
Escalate when forecast outcome lies outside authorised tolerance - not merely when actual variance is visible.The impact analysis should cover all six performance dimensions and state when the decision is required.
Control guidance
Principle 6: focus on products
A product is an output that can be described in advance, created, tested and accepted. Product focus begins by defining the final project product, including purpose, composition, derivation, acceptance criteria, acceptable quality tolerances, acceptance method and acceptance responsibilities. The final product is then decomposed into component products, each with a description of its quality criteria, method, responsibility and records.
This approach reduces activity-driven ambiguity. Instead of asking whether a team is busy or a task is ninety per cent complete, control asks which agreed product exists, whether it satisfies its criteria, what evidence supports approval and which dependency it releases. Activities, resources and schedules are planned after the products and their sequence are understood. Changes can then be assessed against a visible baseline rather than a vague list of intentions.
Product focus also protects benefits. An output is not automatically an outcome, and an outcome is not automatically a benefit. The product must be used to change behaviour or capability; that outcome must produce a measurable improvement perceived as advantageous by the investing organisation. Governance should trace this chain explicitly and avoid declaring success at technical completion alone.
| Level | Definition | Control emphasis | Completion evidence |
|---|---|---|---|
| Output | The delivered specialist product | Scope, quality and acceptance | Approved product and records |
| Outcome | The change enabled when the product is used | Transition, adoption and operating behaviour | Operational performance or adoption evidence |
| Benefit | A measurable improvement arising from the outcome | Value ownership and measurement | Comparison with baseline over an agreed period |
| Dis-benefit | A measurable negative consequence accepted as part of the change | Transparency and trade-off | Tracked impact and approved tolerance |
Control guidance
Principle 7: tailor to the project
Tailoring adapts processes, roles, records, terminology and controls to the project's context while preserving the purpose of the method. It considers scale, duration, uncertainty, delivery approach, organisational policy, capability, supplier interfaces, geographic distribution and commercial obligations. Tailoring should make control clearer and more effective, not merely reduce the number of documents.
The project manager normally proposes the tailoring approach in consultation with the governing body, assurance and relevant organisational authorities. It should be documented in the initiation baseline so all parties understand how decisions, reporting, quality, change, risk and records will operate. Contracts and mandatory corporate procedures constrain tailoring and must be reconciled early; a project method cannot silently override legal, regulatory, safety or commercial obligations.
A light project might combine the brief, plan, approaches and justification into one controlled document, use short decision records and hold fewer formal roles. A complex project might split assurance, use multiple delivery teams, create more frequent controls and preserve separate configuration, quality, risk and commercial records. Both can satisfy the same principles if evidence and accountability remain intact.
Tailoring justification
- Every required control purpose has an owner and evidence route
- Combined roles do not create unresolved conflicts of interest
- Combined documents retain clear baselines, ownership and update triggers
- Reporting frequency matches uncertainty and decision lead time
- Supplier and contract interfaces align with project controls
- Assurance can challenge management and delivery independently
- Terminology is understood by users and decision-makers
- The approach can be changed when project conditions change
Control guidance
Diagnosing governance failures
| Control area | Weak practice | Working practice | Strong practice |
|---|---|---|---|
| Justification | Approval is treated as permanent | Business case reviewed at formal gates | Value is reassessed at gates and when material conditions change |
| Learning | Lessons are a closure formality | Lessons are recorded during delivery | Lessons are sought early, applied and transferred into organisational practice |
| Roles | Job titles substitute for accountability | Responsibilities are documented | Decision rights, conflicts, capacity and assurance independence are tested |
| Stages | One plan and one approval cover the whole project | Stages and gate reviews exist | Stage length follows uncertainty, investment exposure and decision value |
| Exception | All decisions escalate or breaches are hidden | Tolerances are documented | Forecast-led escalation enables fast local management and timely senior decisions |
| Products | Progress is expressed mainly as activity | Deliverables and criteria are defined | Product evidence drives planning, acceptance, change and benefits traceability |
| Tailoring | Controls are copied or removed without reasoning | Some adjustments are documented | Control purposes are preserved and adaptation is reviewed as conditions change |
Control guidance
Governance review checklist
Before approving a stage
- The current business justification remains valid and affordable
- Benefits, dis-benefits and operational impacts have accountable owners
- Stage products, quality criteria and acceptance responsibilities are clear
- Risks and issues are within appetite or explicitly accepted
- Stage and work-package tolerances align with project authority
- Required resources and supplier commitments are credible
- Relevant lessons have changed the plan or controls where appropriate
- Tailoring decisions remain suitable and compliant with external obligations
Can a project satisfy six principles and omit one?
No. The principles reinforce one another. Omitting justification, accountability, stages, exception, product focus, learning or tailoring produces a materially different and weaker control system.
Is a stage the same as a technical phase?
Not necessarily. A stage is a management commitment interval. Technical phases may overlap or cross several management stages.
Who owns the business justification?
The accountable business representative owns it. The project manager maintains forecasts and supports analysis but should not replace business accountability.
Does tailoring mean informal management?
No. Tailoring can reduce formality, but responsibilities, evidence, decision boundaries and protection of baselines must remain explicit.