11.1 Starting Up a Project (SU) Process & The Project Brief

Starting Up a Project (SU) Process & The Project Brief in PRINCE2 7

Practitioner Core Mandate: In enterprise and public sector environments, organizations frequently suffer from "initiation inertia"—committing substantial capital, executive attention, and team resources to elaborate detailed plans for initiatives that were flawed, commercially unviable, or strategically misaligned from the outset. PRINCE2 7 prevents this systemic waste through the pre-project process: Starting Up a Project (SU). SU functions as an unyielding pre-project filter, answering the essential question: "Do we have a worthwhile and viable project?" before the organization commits funds to formal project initiation.

---

1. Purpose, Objectives & Pre-Project Lifecycle Placement

The Starting Up a Project (SU) process occupies a unique position in the PRINCE2 architecture. It is not a management stage, nor does it represent the start of the project lifecycle. Instead, it is an exploratory, pre-project process executed before the formal project begins.

                     THE PRE-PROJECT GATEWAY IN PRINCE2 7

   PRE-PROJECT DOMAIN                     FORMAL PROJECT LIFECYCLE
   (business layer / customer)                 (Initiation Stage ──► Delivery Stages ──► Closure)

   ┌────────────────────┐
   │  PROJECT MANDATE                                       │
   │ (Trigger from Org)                                     │
   └─────────┬──────────┘
             │
             ▼
   ┌────────────────────────────────────────────────────────┐
   │           STARTING UP A PROJECT (SU) PROCESS           │
   │                                                        │
   │ • Appoint Project Executive & PM     • Capture Lessons │
   │ • Design & Appoint PMT       • Outline Business Case   │
   │ • Select Approach & Brief    • Plan Initiation Stage   │
   └─────────────────────────┬──────────────────────────────┘
                             │
                             ▼
                 [Request to Authorize Initiation]
                             │
                             ▼
   ┌────────────────────────────────────────────────────────┐
   │          DIRECTING A PROJECT: AUTHORIZE INITIATION     │ ◄── [FIRST FORMAL GATE]
   │          (Project Board reviews Brief & Stage Plan)    │
   └─────────────────────────┬──────────────────────────────┘
                             │  Approved
                             ▼
   ┌────────────────────────────────────────────────────────┐
   │       INITIATING A PROJECT (IP) PROCESS (Stage 1)      │
   └────────────────────────────────────────────────────────┘

The Fundamental Question

SU exists to answer one core question: "Do we have a worthwhile and viable project?"

• Worthwhile: Do the anticipated business benefits justify the estimated costs, operational disruptions, and risk exposure?
• Viable: Is the project technically and organizationally achievable given available technology, market conditions, resources, and corporate constraints?

If the answer to either question is "No," the initiative must be abandoned immediately—before committing significant funding. In this regard, terminating an unviable proposal during SU is a triumphant success of governance, saving the organization from costly, slow-motion project failure.

The Pre-Project Trigger: The Project Mandate

Nothing happens in PRINCE2 without an authorized trigger. The SU process is triggered by the receipt of a Project Mandate provided by an external authority: The business layer, Programme Management, or the Customer.

• The Project Mandate can take many forms: a brief email, a commercial Request for Proposal (RFP), an invitation to tender (ITT), a strategic portfolio mandate, or a regulatory directive.
• The Mandate may contain substantial detail or be as brief as a single sentence. Regardless of its format, the Mandate rarely provides sufficient structure to justify committing delivery capital.
• SU takes this raw mandate, interrogates its premises, refines its scope, and packages it into a structured, validated management product: the Project Brief.

Why SU Must Be Kept Brief

A classic pitfall tested heavily on the Practitioner exam is "initiation creep"—allowing SU to expand into a full-scale planning exercise.

• SU must be kept as short as possible: It is an initial triage mechanism, not a detailed planning stage.
• Detailed strategy formulation (Risk Management Approach, Quality Management Approach, Change Control, Communication Management Approach), complete Work Package definitions, and full project scheduling belong strictly in the Initiating a Project (IP) process.
• Conducting excessive work in SU wastes organizational overhead on an initiative that the Project Board might refuse to authorize.
• Funding for SU comes from corporate pre-project overhead or bid budgets, not from a project budget, because no project budget exists until the Project Board authorizes initiation.

---

2. The Eight Activities of Starting Up a Project

PRINCE2 7 table 13.1 defines eight activities in SU (sections 13.4.1 to 13.4.8). The 6th Edition compressed these into six by bundling the project approach with the project brief and by treating the initiation request as an implicit hand-off; Version 7 separates them, and the syllabus tests the activities, inputs, and outputs directly. While described sequentially, in practice they iterate dynamically as information emerges.

┌─────────────────────────────────────────────────────────────────────────────┐
│                     THE 8 ACTIVITIES OF STARTING UP (SU)                    │
├─────────────────────────────────────────────────────────────────────────────┤
│ 13.4.1 APPOINT THE PROJECT EXECUTIVE AND PROJECT MANAGER                    │
│    • The business reviews the mandate, then appoints the project executive. │
│    • The project executive appoints the project manager.                    │
│    • Output: the project manager creates the DAILY LOG.                     │
├─────────────────────────────────────────────────────────────────────────────┤
│ 13.4.2 ASSESS PREVIOUS LESSONS                                              │
│    • Interrogate previous lessons reports, audits, and industry data.       │
│    • Output: LESSONS LOG created inside the project log.                    │
├─────────────────────────────────────────────────────────────────────────────┤
│ 13.4.3 PREPARE THE OUTLINE BUSINESS CASE                                    │
│    • Project executive drafts the justification with project manager help.  │
│    • Outputs: OUTLINE BUSINESS CASE and PROJECT PRODUCT DESCRIPTION.        │
├─────────────────────────────────────────────────────────────────────────────┤
│ 13.4.4 APPOINT THE PROJECT MANAGEMENT TEAM                                  │
│    • Cover business, user, and supplier interests across the four layers.   │
│    • Appoint senior user(s), senior supplier(s), assurance, and support.    │
├─────────────────────────────────────────────────────────────────────────────┤
│ 13.4.5 SELECT THE PROJECT APPROACH                                          │
│    • Evaluate delivery options: in-house, bespoke, off-the-shelf, agile.    │
│    • Consider the commercial and delivery context and prior lessons.        │
├─────────────────────────────────────────────────────────────────────────────┤
│ 13.4.6 ASSEMBLE THE PROJECT BRIEF                                           │
│    • Synthesize definition, approach, outline business case, PMT structure. │
│    • Output: PROJECT BRIEF created.                                         │
├─────────────────────────────────────────────────────────────────────────────┤
│ 13.4.7 PLAN THE INITIATION STAGE                                            │
│    • Output: STAGE PLAN created for the initiation stage.                   │
│    • Quantifies time, cost, resources, and risks required to execute IP.    │
├─────────────────────────────────────────────────────────────────────────────┤
│ 13.4.8 REQUEST PROJECT INITIATION                                           │
│    • Output: PROJECT INITIATION REQUEST, which triggers Directing a         │
│      Project so the project board can authorize initiation.                 │
└─────────────────────────────────────────────────────────────────────────────┘

[!EXAM WATCHPOINT: SU ACTIVITY NAMES CHANGED IN VERSION 7] 'Capture previous lessons' is now assess previous lessons; 'design and appoint the project management team' is now appoint the project management team; 'select the project approach and assemble the project brief' has been split into two activities; and request project initiation is now an explicit eighth activity. Distractors built on the 6th Edition names are common.

Activity 1: Appoint the Project Executive and the Project Manager

Every project requires clear leadership from its earliest inception. PRINCE2 mandates a strict appointment hierarchy:

1. The business (commissioning layer) reviews the project mandate and appoints the project executive: the business checks its understanding of the mandate and clarifies ambiguities first, then identifies, selects, and appoints the project executive — the single individual with ultimate accountability for project success and commercial business justification.
2. The project executive appoints the project manager: the project executive identifies, selects, and appoints the project manager, who manages the pre-project work and day-to-day delivery, and who then creates the daily log as the first repository for project information.

                  APPOINTMENT HIERARCHY IN STARTING UP

   ┌────────────────────────────────────────────────────────┐
   │   THE BUSINESS (commissioning / business layer)        │
   └───────────────────────────┬────────────────────────────┘
                               │ Appoints
                               ▼
   ┌────────────────────────────────────────────────────────┐
   │             PROJECT EXECUTIVE (Appointed)              │
   │         • Ultimate business justification owner        │
   │         • Secures project funding                      │
   └───────────────────────────┬────────────────────────────┘
                               │ Appoints
                               ▼
   ┌────────────────────────────────────────────────────────┐
   │                PROJECT MANAGER (Appointed)             │
   │         • Runs Starting Up pre-project activities      │
   │         • Produces Initiation Stage Plan               │
   └────────────────────────────────────────────────────────┘

[!CRITICAL EXAM RULE] The Appointment Chain: The project manager never appoints the project executive, and the project manager cannot appoint themselves. The business layer must appoint the project executive first, because someone must hold commercial responsibility before project resources are mobilized. In PRINCE2 7 the commissioning layer is called the business layer, not 'the business layer'.

Activity 2: Assess Previous Lessons

PRINCE2 operationalizes the core principle "Learn from experience" from the very first moments of SU:

• Before committing plans to paper, the Project Manager and Project Executive must actively research previous projects within the organization and across the wider industry.
• They consult historical Lessons Reports, post-project evaluations, risk registers, and experienced colleagues to identify past mistakes to avoid and proven techniques to adopt.
• The Project Manager creates and initializes the lessons log (a component of the project log) during this activity. The Lessons Log captures relevant historical insights immediately and remains an active repository for new lessons discovered throughout the project lifecycle.

Activity 4 (13.4.4): Appoint the Project Management Team

Projects fail when key stakeholder interests are omitted from governance. In this activity, the project executive and project manager settle the structure of the project management team:

• The Three Project Stakeholder Groups: the team structure must represent business (project executive), user (senior user), and supplier (senior supplier).
• Project Assurance Allocation: Assurance roles (Business Assurance, User Assurance, Supplier Assurance) are defined to provide independent monitoring on behalf of the Board.
• Project Support & Team Managers: Requirements for dedicated administrative support (Project Support) and specialist delivery leadership (Team Managers) are evaluated.
• Role Descriptions: Formal role descriptions are drafted, detailing responsibilities, delegated authority limits, and reporting lines. Role candidates are identified, approached, and formally appointed by the Project Executive.

Activity 3 (13.4.3): Prepare the Outline Business Case

Without business justification, a project is merely an expensive hobby. The project executive leads the preparation of the outline business case, supported by the project manager, and the project product description is created in the same activity:

• The Outline Business Case draws upon the Project Mandate and preliminary market/technical research.
• It documents the preliminary business rationale, strategic alignment, estimated capital expenditure, projected operational savings or revenue (benefits), anticipated negative side-effects (dis-benefits), and primary business risks.
• It establishes the initial baseline for the principle "Continued Business Justification". In later processes (Initiating a Project), this outline will be developed into the fully articulated, detailed Business Case.

Activities 5 and 6 (13.4.5 and 13.4.6): Select the Project Approach, then Assemble the Project Brief

How will the project deliver its products? PRINCE2 7 separates these into two activities: select the project approach (13.4.5) and assemble the project brief (13.4.6), which produces the project brief as its output.

1. Selecting the Project Approach (13.4.5):

The Project Executive and Project Manager evaluate viable delivery mechanisms, considering:

• Source of Solution: Will deliverables be developed in-house, procured off-the-shelf (COTS), outsourced to a bespoke vendor, or delivered via a joint venture?
• Delivery Methodology: Will the project use predictive sequential staging (waterfall), iterative/incremental delivery (agile), or a hybrid blend?
• Operational & Maintenance Strategy: Will ongoing support be absorbed by existing operations, handled by an external managed service provider, or decommissioned after a finite lifecycle?
• Sustainability Strategy: What environmental, carbon-reduction, and social sustainability requirements must govern procurement, manufacturing, and operational life?

2. The Project Product Description (PPD), created in 13.4.3:

The project manager drafts the project product description, which represents the overarching quality contract between the user and supplier communities. PRINCE2 7 calls its headline quality content the user's quality expectations (the 6th Edition said 'customer's'). It specifies:

• User's Quality Expectations: High-level, prioritized attributes the final deliverable must possess.
• Acceptance Criteria: Specific, measurable, and testable conditions the final product must satisfy before operational handover.
• Project-Level Quality Tolerances: Acceptable variances in deliverable performance (e.g., system response time 1.5s ± 0.3s).

3. Assembling the Project Brief (13.4.6):

The Project Manager consolidates these components into the Project Brief:

┌─────────────────────────────────────────────────────────────────────────────┐
│                      ANATOMY OF THE PROJECT BRIEF                           │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. PROJECT DEFINITION                                                       │
│    • Background, objectives, project scope, exclusions, and constraints.    │
├─────────────────────────────────────────────────────────────────────────────┤
│ 2. OUTLINE BUSINESS CASE                                                    │
│    • Rationale, preliminary costs, expected benefits, and primary risks.    │
├─────────────────────────────────────────────────────────────────────────────┤
│ 3. PROJECT PRODUCT DESCRIPTION (PPD)                                        │
│    • User's quality expectations, acceptance criteria, quality tolerances.  │
├─────────────────────────────────────────────────────────────────────────────┤
│ 4. PROJECT APPROACH                                                         │
│    • Delivery strategy: bespoke vs COTS, in-house vs outsource, agile/hybrid│
├─────────────────────────────────────────────────────────────────────────────┤
│ 5. PROJECT MANAGEMENT TEAM STRUCTURE & ROLE DESCRIPTIONS                    │
│    • Governance chart and agreed responsibilities for Board and PM roles.   │
└─────────────────────────────────────────────────────────────────────────────┘

Activity 7 (13.4.7): Plan the Initiation Stage

To enter the formal project lifecycle, the organization must understand what resources, time, and money will be spent defining the project. The Project Manager produces the Initiation Stage Plan:

• The Initiation Stage Plan details the work required during the Initiating a Project (IP) process.
• It schedules the creation of the Project Initiation Documentation (PID), development of the project strategies (Risk, Quality, Issue, Communication, Change), establishment of project registers, and creation of the comprehensive Project Plan.
• It defines the exact stage budget, resource requirements, milestone dates, and stage tolerances for the initiation stage.

Once the Initiation Stage Plan and Project Brief are assembled, the Project Manager formally requests the Project Board to authorize initiation, concluding the Starting Up a Project process.

---

Activity 8 (13.4.8): Request Project Initiation

The 6th Edition let SU end once the brief and initiation stage plan existed. PRINCE2 7 makes the hand-off an explicit activity with its own output:

• The project manager submits a project initiation request to the project board.
• That request is the trigger for the Directing a Project activity authorize initiation (14.4.1), where the board reviews the project brief, outline business case, project product description, and initiation stage plan.
• Nothing in the initiation stage may be funded or started until the board responds with an initiation notice and the trigger project initiation authorized.
• Exam trap: an option describing the project manager moving straight from SU into producing the PID is wrong. SU outputs a request; the board's authorization is what starts the initiation stage.

3. Product Evolution: Mandate vs. Project Brief vs. PID

Understanding the maturity and governance progression of management products across the pre-project and initiation boundaries is essential for the Practitioner exam:

---

4. Deep-Dive: The Project Product Description (PPD)

The Project Product Description (PPD) is created in SU by the Project Manager and approved by the Project Board when authorizing initiation. It is a critical management product that establishes project scope and quality boundaries.

┌─────────────────────────────────────────────────────────────────────────────┐
│               ANATOMY OF THE PROJECT PRODUCT DESCRIPTION (PPD)              │
├─────────────────────────────────────────────────────────────────────────────┤
│ • TITLE & PURPOSE: Formal name and why the total product is required.       │
│ • COMPOSITION: Major assemblies, modules, and sub-systems included.         │
│ • DERIVATION: Source products, legacy databases, or prerequisite materials. │
│ • DEVELOPMENT SKILLS: Specialist technical competencies required to build.  │
│ • USER'S QUALITY EXPECTATIONS: Broad quality standards, prioritized         │
│   attributes (e.g., reliability, speed, sustainability, user-experience).   │
│ • ACCEPTANCE CRITERIA: Explicit, measurable checklist of operational        │
│   performance requirements that MUST be satisfied for handover.             │
│ • PROJECT QUALITY TOLERANCES: Permissible variances in performance targets. │
│ • ACCEPTANCE METHOD: How criteria will be verified (testing, audit, trial). │
│ • ACCEPTANCE RESPONSIBILITIES: Designated roles authorized to sign off.     │
└─────────────────────────────────────────────────────────────────────────────┘

User's Quality Expectations vs. Acceptance Criteria

A vital distinction on the Practitioner exam:

• User's Quality Expectations: High-level, subjective statements of desired quality (e.g., "The online booking portal must be lightning-fast, intuitive for elderly citizens, and highly secure"). These should be prioritized using MoSCoW (Must have, Should have, Could have, Won't have for now).
• Acceptance Criteria: Precise, quantifiable metrics derived from those expectations (e.g., "Page render time under 1.2 seconds at 10,000 concurrent users; WCAG 2.1 AA accessibility compliance; zero critical vulnerabilities on penetration test"). Acceptance criteria are baselined and form the contractual basis for final project acceptance.

---

5. Tailoring Starting Up a Project to Context

PRINCE2 7 mandates that every process must be tailored to suit the project's scale, complexity, commercial setting, and delivery methodology.

Tailoring for Agile Environments

In an agile delivery context:

• SU is kept extremely rapid—often executed in a matter of days or a one-week sprint.
• The Project Brief focuses on product vision, high-level user personas, architectural spikes, and epic-level backlog themes rather than rigid functional specifications.
• The Project Approach outlines the agile framework to be used (e.g., Scrum, Kanban, SAFe), sprint cadences, definition of done, and automated testing strategies.
• The Initiation Stage Plan schedules the agile scoping workshops, backlog grooming, and environment setup required during IP.

Tailoring for Small or Simple Projects

For minor internal initiatives:

• SU activities can be collapsed into a single scoping workshop between the Project Executive and Project Manager.
• The Project Mandate may be an email or informal briefing.
• The Project Brief can be a streamlined 2-page document or slide presentation combining the Outline Business Case, scope, and approach.
• Roles can be combined: The Project Executive may absorb the Senior User role, and the Project Manager may provide Project Support.

Tailoring for Commercial Customer/Supplier Environments

When an external supplier delivers the project for a client:

• The Project Mandate is often a formal Request for Proposal (RFP) or commercial tender.
• The Senior Supplier may not be formally appointed to the Project Management Team until contract award during or after the initiation stage.
• The Project Approach must align with formal procurement rules, intellectual property ownership agreements, and contractual liability constraints.

---

6. Practical Scenario Evaluations

Scenario A: The Over-Initiation Trap in Pre-Project

A public health authority receives a project mandate to implement an automated medical records system. The appointed Project Manager spends four months drafting comprehensive 50-page strategies for Risk Management, Quality Assurance, and Change Control, as well as a fully resourced 3-year Microsoft Project schedule, before submitting anything to the Project Executive for review.

Practitioner Evaluation:

• Governance Violation: The Project Manager has violated the fundamental purpose of Starting Up a Project. SU is meant to be a rapid, low-cost viability filter. By authoring detailed strategy documents and full delivery schedules before initiation is even authorized, the PM has incurred massive unapproved expenditure.
• Commercial Risk: If the Project Board subsequently determines that the initiative is unviable or politically misaligned, four months of overhead expenditure is completely wasted.
• Correct PRINCE2 Action: The PM must restrict SU to producing the Outline Business Case, Project Product Description, Project Approach, Project Brief, and the Initiation Stage Plan. Detailed strategies and long-term project plans belong exclusively in Initiating a Project (IP).

Scenario B: The Project Executive Appointed by the Project Manager

A municipal council approves an urban renewal initiative. An ambitious senior engineer begins drafting the Project Brief and assigns a department director to act as the Project Executive on the Project Management Team organigram. The engineer then submits the Project Brief to the Director for approval.

Practitioner Evaluation:

• Governance Violation: The chain of accountability is completely inverted. A Project Manager cannot appoint their own Project Executive. In PRINCE2, the Project Executive represents business ownership and must be appointed by the business layer.
• Correct PRINCE2 Action: the business layer must formally appoint the Project Executive. Once appointed, the Project Executive formally appoints the Project Manager. Only then can the PM proceed with designing the remainder of the team under the Project Executive's direction.

Scenario C: Bypassing the Lessons Log

During SU for a cloud infrastructure migration, the Project Manager bypasses the 'Capture previous lessons' activity, noting in the Daily Log: 'Our delivery team consists of seasoned certified architects who do not need to read old project files.' In Stage 2, the project suffers a catastrophic three-week outage because an obscure firewall port configuration was overlooked—an identical defect that had caused a failure on an internal migration project 14 months earlier.

Practitioner Evaluation:

• Governance Violation: The PM violated the core principle of Learn from experience. PRINCE2 requires capturing lessons from past projects into the Lessons Log at the outset of SU, regardless of the team's perceived expertise.
• Impact: Failure to review historical Lessons Reports resulted in the exact repetition of a known technical failure, causing severe schedule and financial penalties.

---

7. Responsibilities in SU: The RACI Chart and Practice Application

Syllabus criterion 4.1.1(b) tests table 13.2, the RACI chart for starting up a project, and 4.1.1(c) tests table 13.3, how each practice is applied in the process. Both are examinable in matching form.

Table 13.2 — RACI for starting up a project

¹ business related · ² user related · ³ supplier related

R = Responsible (does the work) · A = Accountable (answerable for the outcome; only ever one role) · C = Consulted (two-way) · I = Informed (one-way). Blank means the role has no assigned part in that activity.

What the chart tells you

• The business layer is only Accountable twice — for appointing the project executive and for appointing the project management team. Everywhere else it is consulted or absent. An option that has the business layer approving the project brief is describing the next process, not SU.
• The project executive is Accountable for six of the eight activities and is also Responsible for two of them: appointing the project manager, and preparing the outline business case alongside the project manager.
• The project manager is Responsible for six activities but Accountable for none. In SU, the project manager does the work and the project executive answers for it.
• Project assurance is barely involved in SU because the project board is not yet fully formed; where it appears it is user-related.

How the practices are applied in SU (table 13.3)

The business case practice produces the outline business case; the organizing practice designs and appoints the project management team and captures role descriptions; the plans practice produces the project product description and the initiation stage plan; the risk and issues practices start the daily log, which doubles as the repository for early risks and issues until the registers exist; and the progress practice sets the controls that the initiation stage will run under. The quality practice contributes the user's quality expectations and acceptance criteria to the project product description.

---

8. Practitioner Exam Pitfalls & Governance Traps

• Trap 1: Believing SU is the First Management Stage: SU is a pre-project process, not a stage. Stage 1 is always the Initiation Stage, executed through the Initiating a Project (IP) process.
• Trap 2: Creating Management Approaches in SU: Any exam option suggesting that the Risk Management Approach, Quality Management Approach, or Communication Management Approach is baselined in SU is incorrect. These strategies are developed in IP.
• Trap 3: Approving the Project Brief Within SU: The Project Manager and Project Executive assemble the Project Brief in SU, but it is not approved in SU. Approval occurs in the Directing a Project (DP) process under the activity Authorize initiation.
• Trap 4: Project Executive Authorizing Initiation Alone: While the Project Executive has ultimate decision authority, authorizing initiation is an activity of the Project Board (Business, User, and Supplier interests collectively), executed within Directing a Project.
• Trap 5: Confusing the Lessons Log with the Lessons Report: The Lessons Log is created in SU by the PM to record lessons learned throughout the project; the Lessons Report is authored at stage boundaries and project closure to communicate lessons to others.