Governance and Decision-Making

Governance Should Help the Project Decide

A project can have weekly status calls, a steering committee and a detailed dashboard while its most important decisions remain unresolved.

The same integration question appears in three meetings. A business owner assumes the architect has approved a process change. The delivery team continues work because nobody has explicitly said to stop. Weeks later, the project discovers that discussion was mistaken for authorization.

Governance exists to prevent that gap between conversation and accountable action.

Chapter 8 established delivery readiness. Chapter 9 defined the team and its responsibilities. This chapter explains how that team makes decisions, escalates constraints and protects the business outcome throughout the implementation.

Good governance gives people a clear route to act within their authority and a dependable way to resolve matters beyond it. Its value is visible in the quality and timeliness of decisions.

The examples, thresholds and decision records in this chapter are fictional illustrations to adapt to the project's approved authority model.

10.1 Begin with the Business Outcome

Governance should keep the implementation connected to the reason the organization approved it.

A steering committee needs to understand whether the project is still capable of delivering the intended operating outcome, not only whether tasks are progressing against a schedule.

Review People, Process, Data and Technology together. A technically complete release may still lack trained users, approved operating procedures or trusted opening data.

Connect governance to the business case and benefit ownership established earlier in the book. When scope is reduced or a deployment is deferred, assess the effect on expected outcomes as well as cost and timing.

For example, removing a warehouse interface may preserve a date while reintroducing manual work that undermines the original investment case. That is a business decision requiring visibility at the appropriate level.

The governance model should help leaders understand such trade-offs before they become irreversible commitments.

10.2 Separate Governance from Delivery Management

Delivery management coordinates activities, resources, dependencies and progress. Governance establishes the authority, boundaries and oversight within which that work proceeds.

The two must connect. A project manager may resequence tasks within an approved plan, while a material change to a contractual milestone requires a different authority.

Avoid asking the steering committee to allocate every consultant's daily work. Equally, do not allow a delivery meeting to approve a significant reduction in business scope merely because it is convenient.

Define what the team can decide locally and what it must refer upward or across to another accountable role.

Effective oversight asks for evidence and tests assumptions. It does not need to take over every conversation with the customer or every workstream decision.

The result should be a team that can act confidently within agreed boundaries, with leadership focused on the decisions that genuinely require its involvement.

10.3 Establish Decision Rights Before Disagreement

For each recurring decision type, identify who prepares the recommendation, who must be consulted, who approves and who implements the outcome.

The RACI model from Chapter 9 supports this work, but decision rights need enough detail to distinguish different approvals. Business process approval, architectural endorsement, funding authorization and deployment authorization are not interchangeable.

Record any limits, delegated authority and required concurrence. Some decisions need several distinct approvals, such as business acceptance followed by an authorized production release decision.

Define a deputy arrangement for absence. A delegate should know the scope and limits of the authority transferred to them.

Do not infer approval from seniority, attendance or confidence in a meeting. The decision must come from the role authorized for that subject under the agreed model.

10.4 Use the Smallest Set of Forums That Works

A forum needs a clear purpose, decision scope, participants and expected output. Its existence should make a recurring delivery problem easier to resolve.

A workstream review can resolve local questions. An integrated delivery review can address cross-workstream dependencies. A design authority can assess solution consistency. A change authority can approve changes within its mandate. A steering committee can resolve strategic trade-offs.

These functions do not necessarily require five separate meetings. A smaller project may combine forums while preserving the distinction between decision types and authorities.

For every decision-making forum, define the chair, required attendance or quorum, substitute arrangements and the route for time-critical decisions between meetings.

A meeting without the authorized approver may still prepare a recommendation. It should not record that recommendation as an approved decision.

Periodically remove duplicated reporting and forums that no longer serve a useful purpose. Governance should remain proportionate as the implementation changes.

10.5 Set Tolerances and Escalation Triggers

Delegation works when the team understands the limits within which it can act.

Agree tolerances for relevant dimensions such as schedule, cost, scope, quality, benefits and risk. Identify both numerical triggers and events that require review regardless of size.

An illustrative project might allow the project manager to resequence work within a workstream if no approved milestone, cost baseline or acceptance criterion changes. A forecast delay of more than five working days to a critical milestone might require sponsor escalation.

Those examples are local policy choices, not industry rules. The actual limits must reflect the contract, business exposure and authority delegated to the project.

Include event-based triggers such as a material security concern, a critical business-control failure or loss of a key dependency. A small financial impact does not make every decision low-risk.

Assess cumulative effects. Several small changes can collectively exceed an agreed tolerance even if each request falls below a review threshold.

The purpose of a trigger is to prompt a timely decision, not simply change a dashboard color.

10.6 Prepare a Decision Brief People Can Use

A decision brief should explain the question, why it matters now, the options and the recommendation.

Include the required decision date and what happens if it is missed. Link the question to the relevant requirement, issue, risk or change request.

Describe the implications across scope, schedule, effort, cost, quality, business readiness and ongoing support. Distinguish known facts from estimates and assumptions.

Present realistic alternatives. An option that cannot satisfy a mandatory requirement should not appear equally viable merely to create a three-column comparison.

Explain the recommendation and its conditions. The decision-maker should understand what they are approving and which uncertainties remain.

For a complex matter, a short summary can link to technical evidence. Sending a large design document without a clear question transfers the work of framing the decision to the approver and often delays the response.

10.7 Work Through a Decision Example

Consider a fictional distributor whose carrier interface is not ready for integrated testing. The implementation team needs a decision before the test window closes.

The baseline requires automated shipment confirmation. The third-party provider forecasts a two-week delay. The team considers three options.

The recommendation depends on business evidence. A controlled interim process is viable only if transaction volumes can be handled, reconciliation is reliable, the necessary operational owners agree and relevant controls are satisfied.

Suppose the operations owner confirms capacity for a bounded period, but the finance owner cannot accept the proposed reconciliation evidence. The governance decision should address that unresolved condition rather than approve the workaround in broad terms.

The final decision might defer the affected location while allowing an independent location to proceed. Its record should state the approved boundary, dependencies, implementation owner and effect on benefits and milestones.

The example illustrates a central principle: governance evaluates the complete operating consequence of a choice, not just its effect on the go-live date.

10.8 Keep a Decision Log Separate from an Action List

An action describes work to be done. A decision records a choice made by an authorized person or body.

“Confirm the interface approach” is an action. “Use the agreed standard interface for release one, with the extension deferred to a separately authorized release” is a decision.

A useful decision log records the identifier, question, approved outcome, approver, date, rationale, conditions and links to affected scope, design or plan records.

Do not mark implementation complete merely because the decision is approved. Track the resulting actions and verify that the affected teams have applied it.

If later evidence changes the decision, create a traceable revision or a superseding record. Preserve the earlier rationale so that the team can understand why the original choice was reasonable at the time.

A decision log should help someone joining the project understand the solution's history without relying on private conversations.

10.9 Escalate with a Decision Request

Escalation should identify the constraint, its business effect, the work already attempted and the help or decision required.

“The customer has not responded” is usually too vague. A stronger escalation identifies the outstanding approval, its accountable role, the date needed, the affected activity and the available recovery options.

Use the agreed route and inform the people responsible for the issue. Escalation should not become a surprise campaign against another team.

Escalate early enough to preserve choices. If a required decision will miss a dependency date, waiting until the milestone has failed reduces leadership's ability to intervene.

Where the first escalation does not resolve the matter, follow the next agreed level and update the impact. An escalation is not complete simply because an email was sent.

The tone should remain factual and respectful. The objective is to restore decision-making and delivery, not to assign blame through a wider distribution list.

10.10 Connect RAID Reviews to Decisions

As established in Chapter 8, this book uses RAID for Risks, Assumptions, Issues and Dependencies. Actions and decisions sit alongside those records.

A risk review should determine whether the response remains adequate and whether further authority is needed. An issue review should examine resolution progress and the consequences of delay.

An assumption needs evidence or a validation action. A dependency needs a responsible owner, a required date and an assessment of its effect on the plan.

Avoid reading every register row aloud. Focus the forum on new information, overdue commitments, changed exposure and items requiring decisions.

If a risk materializes, reflect the resulting issue and preserve the link. If an assumption proves false, assess the effect on design, estimate and scope rather than merely changing its status.

Accepting a risk is also a decision. Identify who is authorized to accept the exposure, what controls remain and when the acceptance must be reviewed.

10.11 Govern Changes Without Blocking Useful Learning

Discovery, testing and operational feedback will reveal new information. Governance should allow the project to respond while keeping the approved baseline visible.

Follow the change-control approach defined in the SOW. Assess the request against existing commitments before determining whether it is a new requirement, a defect, clarification or another type of work.

The assessment should include affected processes, architecture, data, testing, training, effort, schedule and commercial treatment. A seemingly small screen change can alter downstream reporting or user guidance.

Approval should identify the version of the assessed change, the authorized scope and any funding or schedule conditions. “Approved in principle” should not be interpreted as unlimited authorization to build.

Keep architectural endorsement distinct from commercial approval. A sound design may still require additional authorization before delivery begins.

For urgent work, use a predefined exception route with bounded authority and a durable record. Review the resulting impact promptly instead of treating urgency as permission to bypass the baseline permanently.

10.12 Make Steering Committees Decision Forums

A steering committee should focus on business outcomes, material exposure, cross-organizational constraints and decisions beyond delegated delivery authority.

Provide the pre-read early enough for participants to understand the questions. Lead with the decisions required, the recommendation and the consequence of delay.

The status section should distinguish the approved baseline, current forecast and reasons for material variance. Identify what has changed since the previous report.

A useful discussion asks whether the recovery plan is credible, whether the business can provide the required capacity and whether a proposed trade-off preserves the investment's purpose.

Avoid filling the meeting with workstream detail that the delivery team can resolve. Equally, do not hide unresolved matters behind a summary that says everything is under control.

Close with the exact decisions, accountable owners and dates. Check that the record reflects what was authorized, including conditions and any matters explicitly deferred.

10.13 Report Status with Evidence and a Clear Cutoff

Status reporting should support decisions through consistent definitions and current evidence.

Agree the reporting cutoff and distinguish it from the meeting date. If a report reflects Wednesday evening and a material issue emerges Thursday morning, present the change explicitly rather than silently rewriting the earlier position.

Use defined red, amber and green criteria if the project uses RAG reporting. Explain the reason, impact and response alongside the color.

A milestone can remain green only if the evidence supports the agreed meaning of green. Completing many low-risk tasks does not offset an unresolved prerequisite on the critical delivery path.

Keep reporting formats stable enough to support comparison. Change the format when it improves a decision or meets a real governance need, and communicate the revised definition.

Separate confidence from certainty. A forecast supported by assumptions should show which assumptions matter and when they will be tested.

10.14 Use Stage Gates to Review Readiness

A stage gate examines whether the project has sufficient evidence to proceed into the next authorized activity or stage.

The evidence differs by transition. Design readiness may require resolved process decisions and reviewed architecture. Testing readiness may require a controlled build, usable test data and prepared scenarios. Go-live readiness requires business and operational evidence as well as technical completion.

Agree the criteria and approvers before the gate. A readiness review should not become the first occasion on which the team learns what completion means.

Possible decisions include proceed, proceed within explicit conditions or hold the affected work. Conditional approval needs boundaries, owners, dates and a clear statement of the risk accepted.

Do not average away a critical failure. High overall completion cannot compensate for an unresolved control that makes the next activity unsafe or invalid.

A gate records judgment against evidence. It does not eliminate the need for monitoring after approval.

10.15 Provide an Urgent Decision Route

Some decisions cannot wait for the next scheduled committee. Production incidents, security concerns or a threatened cutover dependency may require an immediate response.

Define who can convene the relevant people, what temporary actions are permitted and which authorities must be involved. Use the organization's incident and security processes where applicable.

Separate containment from permanent change. A temporary restriction or workaround may reduce immediate exposure while the team assesses the longer-term solution.

Record the facts available at the time, the authorizing role, the action boundary and the review or expiry point. Communicate the decision to affected operational and delivery owners.

After the event, reconcile the decision with the project baseline and review whether additional testing, approvals or follow-up work are needed.

Urgent governance should be quicker because its route is prepared, rather than because accountability has disappeared.

10.16 Check Whether Governance Is Working

Review governance through its effect on delivery. Are decisions made before they block work? Do teams understand their delegated authority? Are approved decisions reflected in the solution and plan?

Useful indicators include overdue decisions, time from a complete decision brief to an authorized response, repeated reopening of decisions and actions that remain incomplete after approval.

Interpret the measures carefully. A decision reopened because of new evidence is different from one reopened because the original approver lacked authority. A fast decision with poor analysis is not a success.

Sample recent records. Can the team identify who approved them, why and what happened next? Can affected workstreams explain the outcome consistently?

If governance is slowing the project, examine duplicated forums, excessive consultation, missing delegates or weak decision preparation. Removing controls without understanding the cause may create a different problem.

Adjust the model with the relevant owners and explain the change to the team.

10.17 The Delivery Leader's View

A delivery leader creates an environment in which accountability supports progress.

They ask whether the question is clear, whether the right people have been consulted and whether the decision-maker has enough evidence to act. They also recognize when further analysis is useful and when it merely postpones a difficult choice.

They protect delegated authority so that capable teams can perform their work. They bring material business consequences to the sponsor without disguising them as technical detail.

They ensure that a decision reaches implementation, verification and communication. An approval left in meeting minutes has not yet changed the delivery outcome.

The next chapter, Project Planning and Delivery Control, connects these decisions to the integrated plan, baselines, forecasts and corrective actions that keep implementation work under control.