Starting Up a Project Process in PRINCE2 2017

Executive summary

Purpose: test the idea before initiation

Starting Up a Project exists to answer whether there is a worthwhile and viable project. At this point the organisation may possess little more than a project mandate. That is rarely enough for a Project Board to authorise an Initiation Stage responsibly, so the process creates a minimum package of information and accountability.

The source repeatedly emphasises that start-up should be brief. Its purpose is not to build the full Project Initiation Documentation or detailed plans. It is a filter. A small amount of structured thinking can prevent the organisation from spending significantly on an idea with no credible justification, unclear ownership or no workable initiation plan.

Good start-up also reduces later re-planning and exceptions because assumptions, role gaps and approach choices are challenged before teams become heavily committed. The balance is important: too little work creates a weak initiation; too much work effectively initiates the project without formal authority.

The project mandate and commissioning interface

The process begins with a mandate from corporate or programme management or the customer—described here more generally as the commissioning authority. The source notes that a mandate could take forms such as a feasibility output, request for proposal or terms of reference. Its form is flexible; its function is to trigger consideration of the project.

The mandate should provide enough information to identify the Executive or enable that appointment. It is then refined into the Project Brief. This is a crucial transformation: the mandate expresses the initial need or instruction; the brief consolidates the early project definition and gives the Project Board a stronger basis for deciding whether initiation should proceed.

If a mandate is vague, the start-up process should make the uncertainty visible rather than inventing certainty. Assumptions can be recorded, missing information can be planned for during initiation and the Board can decide whether the uncertainty is acceptable.

Activity 1 — appoint the Executive and Project Manager

The source starts with appointment of the Executive and Project Manager because start-up needs both business accountability and management capacity. The Executive represents the business interest and owns the justification. The Project Manager organises the work required to build the Project Brief and plan initiation.

Role descriptions should be explicit. The Executive helps define the Project Manager role and confirms the appointment. The commissioning authority confirms the Executive and the wider appointments according to the source responsibility model.

Early appointment does not require a large permanent team. The project can add or refine roles as understanding improves. What matters is that the start-up work is not performed by an unaccountable group with no clear authority to make recommendations.

Activity 2 — capture previous lessons

Before designing the project from scratch, identify useful experience from earlier projects, operations or related initiatives. The Project Manager creates the Lessons Log and the Executive reviews it. The learning may concern estimates, suppliers, technologies, stakeholder engagement, governance or common causes of failure.

This activity gives practical effect to the learn-from-experience principle from the first management process. Lessons should be translated into decisions. If a previous project suffered because a key user group was engaged late, the start-up output should change stakeholder or team design—not merely record the lesson as historical text.

When no directly comparable project exists, the team can still capture assumptions and relevant organisational experience. The source does not require a complex lessons exercise; it requires that prior knowledge is actively sought and used.

Activity 3 — design and appoint the project management team

The start-up team establishes a project-management structure that represents business, user and supplier interests. It defines role descriptions and identifies who will perform the Project Board, Project Manager, Team Manager, assurance and support responsibilities as needed.

The structure should fit the project’s scale and context. A small project may combine compatible roles; a complex supplier environment may need several Senior User or Senior Supplier representatives and clearer assurance interfaces. Tailoring should not eliminate accountability or create conflicts that undermine independent assurance.

The aim at this point is enough clarity to initiate the project. Roles can be refined in the PID, but decision ownership should not remain ambiguous.

Activity 4 — prepare the outline Business Case

The outline Business Case asks whether there is enough justification to spend time and money on initiation. It should connect the need or opportunity with expected outcomes, benefits, costs, timescales and major risks at the level of information currently available.

This is not the detailed Business Case developed during Initiating a Project. Estimates may be ranges and assumptions may remain. However, the justification should be plausible enough to make initiation a rational investment. If the early case is clearly weak, continued business justification supports stopping before more resources are committed.

Senior User and supplier perspectives can challenge benefit assumptions and deliverability. The Project Manager assists with the document, while the Executive remains accountable for the justification.

Activity 5 — select project approach and assemble the Project Brief

The project approach describes how the solution is expected to be delivered—for example whether products will be built internally or sourced, whether existing assets will be reused and what broad lifecycle or delivery method will apply. Selecting an approach early allows the initiation work to focus on a realistic solution path.

The Project Brief assembles the early definition. The supplied material identifies the project approach, outline Business Case, project-management team structure, role descriptions and Project Product Description among its contents, together with other relevant references.

The Project Product Description is especially valuable because it turns the vague mandate into a statement of the overall output, customer quality expectations and early acceptance basis. This helps prevent the Board from authorising initiation without a shared view of what the project is expected to deliver.

Activity 6 — plan the Initiation Stage

The final activity plans the work needed to initiate the project properly. The Initiation Stage Plan should identify the products and activities needed to create the detailed Business Case, Project Plan, management approaches, controls, PID and next Stage Plan.

This is the first detailed management-stage plan, and the source notes that it is created before the overall Project Plan. That sequence is logical: the organisation first plans the work required to understand the project in enough detail to create a credible whole-project baseline.

The Project Board then uses Directing a Project to decide whether to authorise this initiation work. Authorisation does not yet mean unconditional approval of the full project. It means the idea has passed the start-up filter and merits investment in detailed definition.

Start-up exit test

Before asking the Project Board to authorise initiation, conduct a short exit test. Confirm the Project Brief describes a coherent product and approach, the outline Business Case gives a credible reason to invest in initiation, key roles are filled, relevant lessons have influenced the design and the Initiation Stage Plan is achievable within the authority being requested.

Also list the major uncertainties deliberately left for initiation. Start-up is allowed to be brief, so not every question must be answered. The important point is to distinguish known gaps from accidental omissions. If a supplier strategy, detailed acceptance criterion or regulatory approach will be developed during initiation, state that clearly and include the work in the Initiation Stage Plan.

The Board can then make a transparent choice: reject the idea, request additional start-up work, or authorise initiation with a clear understanding of what remains to be established. This protects the organisation from both extremes—launching an undefined project and spending so long in pre-project analysis that initiation effectively occurs without governance.

Practical verification checklist

• Confirm a valid commissioning mandate or equivalent trigger exists.
• Appoint an Executive and Project Manager with clear role descriptions.
• Capture and apply relevant previous lessons.
• Design a team structure representing business, user and supplier interests.
• Prepare an outline Business Case sufficient to justify initiation.
• Create a Project Product Description and select a credible project approach.
• Assemble a concise Project Brief for the Board decision.
• Prepare a detailed Initiation Stage Plan.
• Keep start-up proportionate and avoid doing unauthorised full initiation work.

Common mistakes to avoid

• Treating a mandate as sufficient authority for full delivery.
• Producing a full PID during start-up instead of keeping the process brief.
• Appointing a Project Manager without an accountable Executive/business owner.
• Ignoring previous lessons because the project is considered unique.
• Building an outline Business Case with detailed false precision rather than honest assumptions.
• Starting major specialist delivery before initiation is formally authorised.

Related KEVOS handbook pages