4.2 Core Workflows and Decision Points

4.2 Starting Up and Initiating

Starting up a Project (SU) is triggered by the project mandate from corporate, programme, or customer management. * SU is deliberately lightweight; it prevents wasted effort by filtering out non-viable projects before money is spent on full planning. Its six activities are: appoint the Executive and Project Manager; capture previous lessons; design and appoint the project management team; prepare the outline Business Case; select the project approach and assemble the Project Brief; and plan the initiation stage.

SU produces the Project Brief, the outline Business Case, the Project Product Description, and the initiation stage plan. Its output is a request to initiate a project, which is sent to the Project Board via Directing a Project.

Initiating a Project (IP) runs only after the board authorizes initiation. Its purpose is to establish solid foundations, giving everyone a shared understanding of the work before committing major spend. IP creates the management approaches (risk, quality, change control, and communication management), sets up project controls, creates the Project Plan, refines the detailed Business Case, and assembles everything into the Project Initiation Documentation (PID). The PID is the project's defining baseline — the contract between the Project Manager and the Project Board.

IP also requests the next stage's plan (often via SB) so the board can authorize both the project and the first delivery stage together.

Controlling a Stage and Managing Product Delivery

Controlling a Stage (CS) is the Project Manager's day-to-day engine, running once per delivery stage. Its eight activities are: authorize a Work Package; review Work Package status; receive completed Work Packages; review the management stage status; report highlights; capture and examine issues and risks; escalate issues and risks; and take corrective action. CS produces Work Packages (handed to teams), regular Highlight Reports (to the board at an agreed frequency), Issue Reports, and — when forecasts show a stage tolerance will be breached — an Exception Report.

Corrective action is taken within tolerance; only a forecast breach is escalated.

Managing Product Delivery (MP) is the Team Manager's process and the only process not led by the Project Manager. It controls the link between Project Manager and Team Manager. Its three activities are: accept a Work Package; execute a Work Package; and deliver a Work Package. The Team Manager produces the specialist products and reports progress to the Project Manager via Checkpoint Reports at the agreed frequency.

CS and MP form a loop: CS authorizes a Work Package, MP delivers it back with Checkpoint Reports, and CS receives and reviews it.

Stage Boundaries, Closure, and the Flow

Managing a Stage Boundary (SB) runs near the end of every stage except the last, and also whenever an Exception Plan is requested. Its purpose is to give the board enough information to review the current stage and approve the next. SB's activities include: plan the next stage; update the Project Plan; update the (detailed) Business Case; report stage end; and produce an Exception Plan if required. SB produces the End Stage Report and the next Stage Plan (or an Exception Plan), and updates the PID, Business Case, and Benefits Management Approach. These flow to DP for the authorize-a-stage decision.

Closing a Project (CP) runs in the final stage (or early if the board directs premature closure). Its purpose is to provide a fixed point confirming objectives are met and the product is accepted. CP activities: prepare planned closure; hand over products; evaluate the project; and recommend project closure. CP produces the End Project Report, a final Lessons Report, follow-on action recommendations, and a Benefits Management Approach for post-project benefit reviews. It feeds DP's authorize-closure decision.

Trigger flow (memorize this chain)

1. Project mandate → SU
2. SU → request to initiate → DP → authority to initiate → IP
3. IP → request to deliver the project (PID) → DP → authority to deliver → CS
4. CS ⇄ MP (Work Package out, Checkpoint Reports back)
5. Stage nearing end → SB → End Stage Report → DP → authority for next stage → CS (repeat)
6. Final stage → CP → End Project Report → DP → authority to close

Directing a Project Across the Lifecycle

It is worth isolating Directing a Project (DP) because it is the process candidates most often misplace. DP is not a phase — it is a set of five board decisions sprinkled across the whole lifecycle. Its activities are: authorize initiation (after SU), authorize the project (after IP, approving the PID), authorize a Stage or Exception Plan (after each SB), give ad hoc direction (whenever the board responds to a Highlight Report, Exception Report, or external event), and authorize project closure (after CP).

The board produces no plans, Work Packages, or reports of its own; it consumes the Project Manager's products and issues authority in return.

Why the order is fixed

The process order is not arbitrary — it enforces continued business justification. SU asks the cheap question first ('is this worth initiating?') before anyone funds detailed planning. IP then builds the baseline so the board can make an informed go decision. Each delivery stage is authorized only after SB confirms the previous stage delivered and the Business Case still holds. CP provides the clean stop. If you ever see an answer that lets the project skip a gate — for example, starting delivery without the board authorizing the project — it contradicts the model and is a distractor.