M6.1 — Project Controls Strategy & Governance

M6.1 — Project Controls Strategy & Governance

1. Practical outcome

The learner should be able to design and operate a proportionate project-controls strategy: define what decisions the project needs, identify the information and controls that support them, assign ownership and authority, establish an integrated operating cycle, set escalation rules and verify that the arrangements work in practice. The output is a usable controls plan with clear interfaces, rather than a document that lists every possible technique.

Modules 1–5 explain how to establish and analyse scope, data, schedule, cost, risk and performance. M6.1 determines how those disciplines work together, who may decide what, when evidence is required and how weak controls are corrected. It must distinguish the responsibility to produce information from the authority to approve scope, expenditure, contractual instructions or a baseline change.

Ask: “Which decision must be made, who has the authority, what evidence must reach them, and what happens if the evidence or decision is late?”

2. Core concepts

Start with project context and decisions

Controls should reflect the project's objectives, lifecycle, delivery model, uncertainty and consequences of failure. A small repetitive package may need simple quantity, cost and exception records. A fixed-opening project with multiple suppliers may need integrated readiness dependencies, supplier evidence, frequent look-ahead reviews and rapid escalation. More reporting is useful only when it supports a decision or preserves a necessary control.

Identify the commitments that governance must protect. For the Reference Project these include operational readiness for a fixed public opening and the authorised 50.0m CU budget. Completion of installation is an intermediate condition; it does not establish that users can safely and effectively occupy the centre. Controls should include testing, configuration, training, handover and operational acceptance.

Strategy, controls plan and operating procedures

The strategy explains what matters and why the chosen controls are proportionate. The controls plan specifies roles, structures, sources, cut-offs, baseline rules, information products, review cadence, tolerances, change and assurance arrangements. Procedures provide the detailed sequence for recurring activities such as closing a cost period or implementing an approved change.

Keep these layers connected. A strategy that promises integrated forecasts needs compatible scope and calendars, agreed cut-offs, named cost and schedule owners and an assumption-reconciliation step. A procedure that requires approval needs an identified authority and a route when that person is unavailable. Templates and software permissions should reflect these rules.

Maintain an applicability record identifying each adopted external requirement, its edition, scope and status as mandatory or advisory. Map it to the project’s controls and accountable owner. Record justified tailoring and unresolved differences; local approval cannot waive a binding external obligation. This gives reviewers a concrete basis for assessing compatibility rather than relying on a general claim of alignment.

Accountability and authority are different

A package owner is responsible for the credibility of remaining work and its forecast. A planner may calculate the resulting dates; a cost engineer may reconcile incurred cost and ETC; a risk practitioner may assess uncertainty. The project-controls manager integrates and challenges their outputs. The project decision-maker remains accountable for the chosen response within delegated authority.

Do not assume that a responsibility matrix grants authority. Define who can accept technical work, authorise project expenditure, issue a contractual instruction, approve a change, draw contingency and release a revised baseline. These may be different people. Record deputies, limits, conditions and escalation routes, and check them against the actual project mandate and contract arrangements.

Decision tolerances and escalation triggers

A tolerance defines a permitted range or delegated boundary for a specified decision. A trigger identifies when review or escalation is required. Define the reference, measure, time horizon and recipient: for example, a forecast that threatens the fixed opening is escalated immediately to the Project Director. A generic statement such as “escalate when red” is insufficient if the meaning of red is undefined.

Include exceptions that override numerical tolerances. New functional scope, an unaccepted critical configuration, unavailable inspection capacity or a missed decision deadline may need escalation even when aggregate cost appears acceptable. Do not allow a green average to cancel a mandatory acceptance gate. Quantitative limits are project-specific; the learning example is not a universal approval policy.

One integrated control cycle

A working cycle moves from evidence collection to validation, reconciliation, analysis, decision and follow-through. Establish who provides each source, when it is cut off, who checks it and which meeting or decision it supports. A monthly report should not combine one supplier's current progress with another supplier's previous-period cost without identifying the mismatch.

Different horizons can coexist. Monthly cost close supports consolidated reporting; weekly acceptance and access reviews support operational decisions; immediate exception reporting protects urgent commitments. These products should share definitions and preserve their respective dates, rather than forcing every decision to wait for the monthly cycle.

Systems and interfaces must support the controls

Choose structures and information flows before configuring software. Scope and responsibility should map across WBS, schedule activities, cost codes, risk links, changes and reporting. Define authoritative sources, controlled interfaces, validation rules and access permissions. A dashboard is a presentation layer; it does not become the authoritative budget because it displays a number.

Specify how corrections and versions are handled. Retain source evidence, previous forecasts, approved baselines and decision records. Identify access restrictions and retention requirements with relevant organisational owners. Test what happens when a key contributor is absent or a system interface fails: a manual fallback still needs ownership, reconciliation and subsequent controlled recovery.

Independence and useful challenge

People who produce controls need to explain and defend them. Reviewers need enough independence and access to challenge assumptions, unsupported adjustments and missing evidence. Independence can be proportionate: peer checks for routine calculations, another discipline's challenge of interfaces and separate assurance for high-consequence decisions.

Assurance does not transfer delivery accountability to the reviewer. Nor should the project-controls function become a substitute for management decisions. It should make uncertainty and consequences visible, escalate through agreed routes and retain evidence of advice and decisions. M6.4 develops how to test the controls and close findings.

3. Step-by-step method

1. Establish the project context. Identify objectives, fixed commitments, delivery model, lifecycle stage, major uncertainty, stakeholder obligations and consequences of failure.

2. Map the decisions. List recurring and exceptional decisions, their horizons and the latest useful decision dates. Include scope, resources, readiness, budget, contingency, commercial instructions and baseline release.

3. Define the evidence for each decision. Specify the required scope, schedule, cost, risk, progress and acceptance information, its maturity and known limitations.

4. Assign owners and decision rights. Separate production, validation, technical acceptance, integration, expenditure approval, contract authority and assurance. Confirm delegations and deputies.

5. Establish common structures. Agree WBS/CBS, responsibility mappings, milestones, calendars, coding, progress rules, versions and authoritative sources with the M1 disciplines.

6. Define the baseline and forecast rules. State what is approved, how it is preserved, who owns current forecasts and how changes and corrections are distinguished.

7. Design the operating cycle. Set cut-offs, submissions, reconciliations, reviews, report releases and action follow-up. Include weekly and immediate exception routes where required.

8. Set tolerances and escalation rules. Name the reference, limit, recipient and deadline; define qualitative overrides and the route for decisions outside delegated authority.

9. Configure systems and interfaces. Align permissions, validation, reporting and retention with the agreed operating model; test transfer failures and fallback arrangements.

10. Plan assurance. Identify high-consequence outputs, review criteria, independent challenge, evidence requirements and how findings are assigned and closed.

11. Issue and rehearse the controls plan. Walk a realistic issue through evidence, analysis, authority, decision, implementation and verification. Fix unclear hand-offs before relying on them.

12. Review effectiveness. Examine missed decisions, recurring data defects, forecast contradictions and overdue actions. Adapt proportionately as the project moves towards testing and opening, preserving the reasons for changes to the controls themselves.

4. Worked Reference Project example — Community & Learning Centre

Context — govern the Module 5 recovery decision

At the controlled Month 16 teaching snapshot, 64 of 100 Technology acceptance points are accepted against 80 planned. M5.4 compares constrained delivery at EAC 49.470m CU and readiness two working days after opening with a conditional recovery case at 49.510m CU and readiness eight working days before opening. The gross recovery intervention is 0.120m CU; the 0.040m CU scenario difference is not the expenditure authority requested.

These remain illustrative forecasts. Recovery requires secured access, inspection capacity and credible acceptance output. The historical 88% opening confidence from M4.3 is under review, rather than a current assurance statement. The fixed opening and 50.0m CU authorisation are unchanged.

Step A — establish explicit teaching decision rights

For this scenario, the project mandate delegates approval of the defined 0.120m CU recovery intervention to the Project Director within existing scope and budget. A separate commercial authority issues the supplier instruction after scope, price and conditions are checked. New functional requirements, changes to the fixed opening or requests to increase the project cap go to the Project Board. These are stated teaching assumptions to be verified on a real project.

The controls manager cannot approve recovery merely by changing an EAC. The Director cannot assume a forecast report is the contractual instruction. The package owner must confirm access and output assumptions, and the operations owner must confirm what counts as accepted readiness.

Step B — connect evidence to decision timing

The booking deadline is before the next weekly review and before the next monthly Board pack. The controls plan therefore requires an exception brief to the Director while the decision can still affect the outcome. Waiting for the routine Board meeting would defeat the authorised delegation.

The weekly delivery review uses accepted points, first-attempt quality, access and configuration readiness. Monthly cost close uses reconciled actuals, accruals and ETC. The integration review checks whether the schedule and cost price the same recovery plan and whether uncertainty has been updated. Each product shows its own cut-off and any subsequent event.

Step C — define overrides and action ownership

An unaccepted critical configuration prevents the package being reported as ready even if overall accepted percentage increases. Failure to secure the inspection slot by the booking deadline triggers immediate escalation. A forecast past opening also triggers escalation regardless of the fact that deterministic EAC remains below 50.0m CU.

The delivery manager owns resource and access implementation; the systems lead owns configuration approval; the planner owns the remaining network; the cost lead owns the ETC bridge; the risk lead owns the revised uncertainty assessment. The Director owns the decision. The controls manager tracks the evidence and raises contradictions rather than silently replacing each owner's judgement.

Step D — rehearse the control cycle

The team walks the proposed intervention through submission, commercial checks, approval, instruction, bookings, implementation evidence and outcome review. A gap emerges: the proposed inspection booking has no named deputy during the delivery manager's absence. The controls plan assigns a deputy and an escalation deadline. This is a control improvement with a concrete consequence, rather than an extra report field.

At the later review described in M5.5, two recovery weeks accept eight and nine points. Acceptance rises to 81; 19 remain over two weeks, requiring 9.5 per week. Completed administrative actions therefore do not prove recovery. The governance response is to challenge the remaining rate and readiness path, update the forecast and obtain any further decision before capacity options expire.

5. Interpretation and professional judgement

Proportionality follows consequences

The controls plan need not give every work package identical detail. Apply additional evidence and review to interfaces that can prevent opening, while preserving consistent aggregate definitions. Reduced reporting effort can be sensible; removing acceptance evidence from a critical readiness gate is a different decision with a different consequence.

Delegation must be usable

A decision right that is never exercised before the opportunity closes is ineffective. Check deputy arrangements, escalation timing and whether the decision-maker receives a concise, supported request. Conversely, a fast decision still needs appropriate authority, evidence and a retained record. Urgency changes the route and cadence; it does not invent a delegation.

Judge effectiveness by what happens

A full dashboard, a well-attended meeting or timely submission is evidence of activity. Look also for decisions made before deadlines, corrected data, reconciled forecasts and observed action effects. Recurring problems may indicate that an interface or incentive is wrong, rather than that another reminder is needed.

6. Practice diagnostic

Use this table to challenge the quality of the approach or deliverable. The rows consolidate the most important recurring red flags and checks; they are prompts for professional judgement rather than a substitute for the method above.

7. Try-it-yourself practical exercise

Prepare a concise controls-plan extract for the Reference Project at Month 16.

·       1. Identify six decisions needed before opening and state their latest useful decision points.

·       2. Map evidence production, checking, acceptance, expenditure approval and commercial instruction for the recovery intervention.

·       3. Define the weekly, monthly and immediate exception cycle without concealing different cut-offs.

·       4. Write three numerical or time-based triggers and two qualitative overrides, including their recipients and deadlines.

·       5. Describe how you would handle the absence of the inspection-booking owner.

·       6. Explain what the later 81-point acceptance result requires governance to do next.

·       7. Identify one report field you would remove and explain which decision or necessary control remains supported.

What good performance looks like

The plan asks for authority over the gross 0.120m CU intervention, sends the urgent decision to the delegated Director, keeps contract instruction separate and protects technical acceptance. It treats the 9.5-points-per-week requirement as a new evidence challenge, not as automatic success. Controls are proportionate but every important hand-off has an owner and a route when it fails.

Final challenge: “Could another competent team operate these controls tomorrow, including an urgent exception, without guessing who decides?”

8. Bridge to capability

The How-to teaches how project controls operate as one proportionate system. At APPLIED and above, capability assessment should test whether the practitioner can establish or operate realistic arrangements and explain how evidence reaches an authorised decision. Roles, cut-offs, delegations, interfaces and verified action records should demonstrate that the control cycle works. Supporting work products are illustrative and should be assessed with the practitioner’s reasoning. Sample learning questions illustrate the judgement at each recognition level; they are discussion prompts rather than validated assessment items.

Learning question: Do you understand how project controls should operate together?

Capability question for APPLIED and above: Can you demonstrate a workable control cycle that supports timely, authorised and defensible decisions?