Initiating a Project Process in PRINCE2 2017

Executive summary

Purpose and value of initiation

Initiating a Project establishes solid foundations so the organisation understands the work needed to deliver the project’s products before committing to significant spend. The supplied material presents this early period as the point of greatest management leverage: major decisions can still be changed relatively cheaply because the project has not yet committed large resources.

The aim is common understanding. Stakeholders should know why the project is being done, expected benefits and dis-benefits, associated risks, scope and products, delivery approach, timing and cost, decision roles, quality approach, baseline control, risk/change control, progress controls, communication needs and how the method has been tailored.

Initiation is therefore not merely document production. The documents are evidence that the required questions have been answered and that management can make an informed authorisation decision.

Activity 1 — agree tailoring requirements

The source places tailoring first. Before the team builds detailed management products, it decides how the method will fit the project’s environment, scale, risk, delivery approach, organisational standards and existing systems.

Tailoring can affect terminology, role combinations, report formats, management-product integration and the formality of processes. It should not remove the seven principles or compromise the purposes and objectives of required processes and themes.

Agreeing tailoring early prevents inconsistent implementation—for example, one team using a corporate risk tool while another maintains a disconnected spreadsheet, or a Project Board expecting monthly reports while the Project Manager assumes weekly governance. Tailoring decisions should be visible in the PID so future participants understand how the method is being applied.

Activity 2 — prepare the four management approaches

The source identifies four approaches prepared during initiation: Risk Management, Change Control, Quality Management and Communication Management. The Communication Management Approach follows the others because communication requirements should reflect how quality, risk, issue and control information will be managed.

These approaches should integrate with organisational systems where possible. Their value is not the number of pages; it is that project participants can apply a consistent control method. A small project may describe all four succinctly inside the PID or linked tools, while a complex project may require detailed procedures.

Activity 3 — set up project controls

Project controls translate governance into operating rules. Define management-stage boundaries, reporting frequency, tolerances, decision events, issue/risk escalation, Work Package interfaces and the mechanisms for keeping baselines current.

The controls should reflect risk and capability. High-risk work may justify short stages, frequent checkpoints or stronger assurance. Stable work with experienced teams may use lighter reporting. The principle is proportionate control, not maximum paperwork.

Controls must also establish who receives information. A Team Manager needs Work Package constraints and reporting expectations. The Project Manager needs accurate progress, risk, issue and quality information. The Project Board needs concise visibility and decision triggers. The commissioning authority needs project-level exceptions and other agreed information.

Activity 4 — create the Project Plan

The Project Plan provides the high-level delivery baseline for the entire project. It identifies the main products, management stages, indicative timing, costs, resources and major dependencies. Product-based planning is used so the schedule is anchored to defined outputs.

The plan should be realistic enough to support the detailed Business Case. This is why the source sequences Project Plan creation before final refinement of the Business Case: credible cost, timing and resource estimates are needed to judge whether the project remains desirable, viable and achievable.

The first delivery Stage Plan is also prepared during the initiation-stage boundary activity so that the Board can see both the whole-project direction and the detailed next commitment before authorising delivery.

Activity 5 — refine the Business Case

The outline Business Case from start-up is developed using the better information produced during initiation. Refine costs, timescales, benefits, dis-benefits, risks and the relationship between project outputs, operational outcomes and measurable benefits.

The Executive remains accountable for the Business Case. The Project Manager can develop and maintain it, but ownership of the investment justification should not drift into an administrative role. User representatives should confirm benefit assumptions and operational impacts; supplier representatives should challenge feasibility and cost assumptions.

The Business Case and Project Plan should be internally consistent. If the plan says delivery will take longer or cost more than the case assumes, the project is not ready for authorisation. The same applies if benefits depend on operational changes that have no owner or funding.

Benefits Management Approach

Initiation also establishes how benefits will be measured and reviewed. The Benefits Management Approach identifies expected benefits and owners, measurement methods, baselines, review timing and responsibilities. Some reviews can occur during the project, while others may take place after closure when products have been in operational use long enough to create outcomes.

This protects the distinction between output delivery and benefit realisation. The project can be successful at delivering an accepted product yet still require post-project management to confirm whether the intended benefits occurred. The source assigns accountability for post-project benefit reviews outside the temporary project team as appropriate.

Where dis-benefits are expected—negative consequences accepted as part of the change—they should also be visible rather than hidden from the justification.

Activity 6 — assemble the PID

The PID is the integrated baseline assembled from initiation work. It provides the Project Board with the information needed to decide whether the project should proceed and becomes the reference point for ongoing management. It is not just one narrative document; it may be a collection or index of controlled management products in different systems.

The source includes project definition, Project Plan, detailed Business Case, management approaches, project controls, management-team structure/roles and tailoring information among the elements that form this baseline. Consistency is more important than format. The plan, case, roles and controls should tell one coherent story.

Before submitting the PID for authorisation, run an integration review: confirm every key product has an owner and acceptance path; all significant risks have management; the Stage Plan fits project tolerances; communication covers decision-makers; and the Business Case remains credible.

Initiation readiness review

Before requesting project authorisation, perform a readiness review across the initiation outputs. Trace the Project Product Description into the Project Plan and acceptance approach. Confirm the Business Case uses the same cost, timing and risk assumptions as the plan. Confirm benefit owners understand their responsibilities. Check that management approaches are executable by the people and systems named in them.

Then test authority and control. The Stage Plan should fit within the proposed project and stage tolerances. Reporting frequencies should be realistic. Issue and risk escalation routes should reach people who can decide. Role-holders should have accepted their responsibilities. External dependencies should have owners and assumptions rather than appearing as unexplained milestones.

Finally, identify residual uncertainty. Initiation is not expected to eliminate all risk; it should make uncertainty visible and manageable. A project is ready for authorisation when decision-makers can understand the proposed investment, delivery path, control system and remaining exposure well enough to make a reasoned commitment—not when every future detail has been predicted.

Practical verification checklist

• Agree tailoring before detailed management products are built.
• Prepare risk, change control, quality and communication management approaches.
• Define stage structure, tolerances, reports, decision events and escalation routes.
• Create a product-based high-level Project Plan.
• Refine the Business Case using realistic plan and risk information.
• Define benefit ownership, measurement, baselines and review timing.
• Assemble a coherent PID or controlled equivalent, not disconnected documents.
• Check consistency between Business Case, Project Plan, Stage Plan and management approaches.
• Obtain explicit Project Board authorisation before significant delivery commitment.

Common mistakes to avoid

• Treating initiation as paperwork rather than decision preparation.
• Copying generic management approaches that nobody will follow.
• Creating the detailed Business Case before realistic project planning information exists.
• Leaving benefit measurement until closure.
• Assuming the PID must be one physical document rather than an integrated controlled baseline.
• Beginning full delivery because initiation work is nearly finished but not yet authorised.

Related KEVOS handbook pages