(A.30) Project Plan: A description of the project’s intended achievements versus time which is oriented towards communicating with the (B.1) Project Board. The (A.30) Project Plan is a mandatory element of PRINCE2®.
	(A.35) Stage Plan: A description of the project’s intended actions versus time and resourcing that will lead to the achievements in the (A.30) Project Plan. The (A.35) Stage Plan is oriented towards the (B.5) Project Manager’s needs for day-to-day control.

The (A.35) Stage Plan is described by PRINCE2® as required meaning that it may be within the (A.30) Project Plan. The (A.35) Stage Plan will be a separate document if the (B.1) Project Board’s needs for overview and the (B.5) Project Manager’s need for detail clash. The stage plan will also be a separate document

A. 30 Project Plan “A mandatory plan [created from the outline in the Project Brief at IP2 and updated in SB2/ CP3] …[showing] how and when a project’s objectives are to be achieved, … the major products, activities and resources” “It provides the Business Case with planned project costs [& timescales] and it identifies the management stages and other major control points” It is used by the Project Board as a baseline against which to monitor project progress and cost stage by stage Incorporated into the A27 PID Contingency plans for how any risks that materialise will be dealt with Composition Plan description: textual, brief description of plan scope, all assumptions upon which the plan stands, all prerequisites that must be in place from project start to end for project success, all external dependencies Project-level Tolerances, change budget and contingency plans explaining how impacts of materialised risks will be managed Product Breakdown Structure & linked Product descriptions, Product Flow Diagrams & linked activity network Resultant graphical or other representation of schedule, financial budget/ cash-flows, tables of resourcing requirements Gantt or bar chart with identified management stages Requested/Assigned specific resources

if the project needs to run across multiple stages that cannot yet be planned in detail[2].

A. 35 Stage Plan (or Exception or other detailed Plan) Baseline description of activities, reporting points and resources required to: Create the stage’s products conformant to quality controls described in the Product Descriptions Provide management resource to review the Issue Log Ensure day-to-day progress control (within tolerances) of the products that satisfy the objectives of a stage Created in SB1 by extending the detail from the A30 Project Plan to a level of detail sufficient to detect deviations in a timely manner Created using organisational standards Contents consistent with and supports achievement of the Project Plan within constraints of Budget/ Resource/ Schedule Believable in the eyes of the Team Members Tracked in CS2 based on information from A3 Checkpoint Reports, CS5 Status reviews and CS7 corrective actions Every version is held in the E.2 Stage File Composition Description of the plan’s Scope, Approach, External Dependencies*, Tolerances, Assumptions**, Risk Assessment and Resource Constraints Stage Quality Plan: IE quality control methods, timing and resources for each quality test used for major product PBS & PFD, Activities, Critical Path Analysis (& identification of activity float) plus budget & cash-flows Prerequisites*** that must remain in place throughout the stage Regime for monitoring controls and reporting

The stage plan includes tasks that are derived from the quality checking requirements documented in (A.22) Product Descriptions during PL2. The sub-set of the stage plan’s scheduled, resourced tasks that are quality oriented activities (linked to the (A.32) Quality Log) is called the Stage Quality Plan (SQP): it is not a separate document. Unlike the (A.31) Project Quality Plan which is actually a policy or strategy documents the SQP is a schedule of tasks.