Standard Operating Procedure: PRINCE2 Project Plan Development

Introduction

This Standard Operating Procedure (SOP) outlines the mandatory process for creating a Project Plan using the PRINCE2 (PRojects IN Controlled Environments) methodology. The Project Plan serves as the primary baseline for the project’s scope, cost, time, and quality. By adhering to this structure, Project Managers ensure that the plan is viable, manageable, and aligned with the corporate business case, providing a clear roadmap for stakeholders to track progress and maintain control throughout the project lifecycle.

Step-by-Step Project Plan Checklist

Phase 1: Preparation and Alignment

• Review the Project Brief: Ensure a thorough understanding of the project mandate and the Business Case.
• Consult Stakeholders: Identify all key stakeholders and confirm their requirements for the project output.
• Define the Approach: Establish the delivery method (e.g., Waterfall or Agile/PRINCE2 hybrid) and confirm the Project Approach.
• Identify Product Requirements: Define the end-product and ensure it meets the Quality Criteria set by the user.

Phase 2: Product Breakdown and Estimation

• Create a Product Breakdown Structure (PBS): Decompose the final product into its constituent parts to ensure full scope coverage.
• Create a Product Flow Diagram (PFD): Map the sequence in which the products must be developed and delivered.
• Define Activity Sequences: Identify the specific tasks required to create the products listed in the PBS.
• Estimate Resources and Effort: Assign required resources and estimate the duration and effort for each work package.

Phase 3: Scheduling and Resource Allocation

• Develop the Project Schedule: Input dependencies and estimates into a scheduling tool (e.g., Gantt chart) to determine the critical path.
• Resource Levelling: Adjust the schedule to resolve resource contention and ensure no team member is over-allocated.
• Incorporate Contingencies: Add time and budget buffers for identified Risks (avoid padding schedules without logic).

Phase 4: Governance and Review

• Establish Control Framework: Define reporting cadences (Highlight Reports, Stage Reports) and tolerance levels for time/cost.
• Identify Quality Control: Document the quality inspection processes for every major product.
• Formal Review: Present the draft Project Plan to the Project Board for approval and sign-off.
• Baseline the Plan: Once approved, save the plan as the performance baseline for future comparison.

Pro Tips & Pitfalls

Pro Tips

• Focus on Products, Not Tasks: PRINCE2 is "product-based." Always start by defining the final output before worrying about the "how."
• Use Management Stages: Break large projects into manageable stages to ensure the Project Board can make "Go/No-Go" decisions at key intervals.
• Keep it Living: Treat the Project Plan as a dynamic document. If the project drifts from the baseline, update the plan immediately via a formal Change Request.

Pitfalls

• Ignoring Tolerances: Failing to set clear tolerances for cost and time leads to micromanagement by the board or lack of control by the manager.
• Underestimating Risk: Many managers focus only on task duration and forget that risks (e.g., supply chain delays) will inevitably disrupt the timeline.
• Lack of User Involvement: Developing a plan in isolation without consulting the end-users often leads to a product that fails to meet business needs.

Frequently Asked Questions

Q1: How does a Project Plan differ from a Stage Plan in PRINCE2? A: The Project Plan covers the entire project lifecycle at a high level, whereas a Stage Plan provides a granular, day-to-day focus on the current management stage. You should always have one active Project Plan and one active Stage Plan.

Q2: What should I do if the project exceeds its set tolerance levels? A: If a project is forecasted to exceed the agreed-upon tolerances for time, cost, or scope, you must initiate an "Exception Report" to the Project Board, outlining the impact and potential recovery options.

Q3: Is the Project Plan the same as the Business Case? A: No. The Business Case justifies why the project is being done (the ROI), while the Project Plan explains how the project will be delivered (the logistics and resources). The Project Plan must always support the delivery of the benefits identified in the Business Case.