CS - Controlling A Stage

The purpose of the Controlling a Stage process is to assign work to be done, monitor such work, deal with issues, report progress to the Project Board, and take corrective actions to ensure that the stage remains within tolerance.

Compliance

Yes

- There is evidence that the project complies to the criteria

- There is no evidence that the project complies to the criteria

N/A

- This criteria does not apply via the use of tailoring or other justifiable reasons

Quality

Red

- The is no evidence or the evidence does not comply with the PRINCE2® methodology

Amber

- The evidence is reasonable, but could benefit from significant improvement to comply fully with PRINCE2®

Green

- The evidence complies fully with PRINCE2®

N/A

- This criteria does not apply via the use of tailoring or other justifiable reasons

SU IP PL SB CS MP DP CP Report
Controlling A Stage (CS)
Project Name:
Maturity Model Rating For This Phase
Level 1 - Initial • Methodology is not being adopted • Uncontrolled Level 2 - Managed • Very Low adoption of methodology • Very low level of control Level 3 - Defined • Low adoption of methodology • Low level of control Level 4 - Quality • Good adoption of methodology • Good level of control Level 5 - Optimised • Full adoption of methodology • Under full control
Phase Analysis


	Criteria Question	Compliance	Quality
Authorising Work Package
	Has authorisation to proceed been given from the project board?
	Have work packages been documented?
	Have product descriptions been updated and used to create work packages?
	Have configuration item records been updated?
	Have the issue and risk logs been updated?
	Have the major products of a plan and key dates of their delivery been updated (Product Check list)?
	Has the quality log been updated?
	Has the stage/exception plan been updated?
Assessing Progress
	Are there checkpoint meetings?
	Are the checkpoint meetings in the project plan?
	Are checkpoint meetings documented?
	Are risk, issue, quality logs and stage plans updated?
Capturing Project Issues
	Are project issues recorded?
	Are all significant Issues recorded?
Examining Project Issues
	Are key issues used to update the lessons learned log?
	Are the risks that caused issues recorded in the risk log?
Reviewing Stage Status
	When there was a plan deviation was it identified in the controlling a stage process?
	Where there was a tolerance threat was it identified in the controlling a stage process?
	Is stage status reflected in highlight reports?
	Has the impact of any new or revised risks been undertaken (on the Business Case, Stage Plan or the Project Plan)?
Reporting Highlights
	Are highlight reports produced?
	Do they reflect checkpoint reports over the reporting period?
	Do they reflect plan deviations and tolerance threats?
	Have highlight reports been reviewed by the project board?
	Have reports been sent to other stakeholders identified in the communications plan?
	Do highlight reports meet PRINCE2® standards?
Taking Corrective Action
	Has the project board been approached for advice?
	Has the project board given advise on taking corrective action?
	Has the issue log been kept up to date?
Escalating Project Issues
	Have exception reports been issued to the project board?
	Have exception reports been approved by the project board?
	Have exception plans been requested by the project board?
	Has advise been sought from the project board before submission of exception plans?
	Have exception plans been sent to the board?
Receiving Completed Work Package
	Have work package status been reported?
	Are quality log entries completed for the work package?
	Have acceptance been documented from product recipients?
	Have configuration item record for delivered products been updated to completed?