PRINCE2 Starting Up A Project Process

The PRINCE2 Starting Up A Project Process

The first process to be triggered within PRINCE2 is the Starting Up A Project process. A project can be standalone or part of a programme, in which case a project may be triggered from either those within a programme, here called programme management, or by appropriate senior management within an organization, here called corporate management.

A PRINCE2 project is therefore triggered by either of the above by issuing a Project Mandate.  This document should contain as a minimum, the name of the prospective project board executive and the reasons for the need of the project.  As such it may only be and verbal instruction or possibly an e-mail.  At the other extreme it could be the final report from a feasibility study.  Whichever, it must contain sufficient information provided by an appropriate authority level, in order to trigger the first PRINCE2 process.

The first process is called Starting Up a Project and uses the initials SU.  This occurs pre-project, and is used as a solid foundation prior to the first stage in a PRINCE2 project.  Developing detailed plans can consume a lot of resource, and since many projects should not even be started in the first place, it makes sense for SU to be used as a ‘filter’ – both to prevent poorly conceived projects from starting in the first place, and to establish an understanding of the goals and objectives of the project.  In particular, to ensure that there are good business reasons to proceed with the project.

The Project Management Team needs to be designed and appointed, and guidance can be found within the PRINCE2 Organization Theme. One of the first activities is to appoint the Executive of the Project Board and the Project Manager; the Executive will now design and appoint the remaining roles within the Project Board including who will fill the Senior User and Senior Supplier roles, and how Project Assurance is to be handled. The project manager will design and appoint any other supporting roles that will be needed such as project support, configuration management and the optional Team Manager role.

There are two main management products that are an output from this process, the Project Brief and a plan for the Initiation Stage.

The Project Brief contains the outline Business Case with sufficient information to justify carrying out the initiation stage, creating the Project Product Description which includes aspects such as the customer’s quality expectations and acceptance criteria for the end product of the project. 

The Project Brief also contains the Project Approach management document.  This lays out the approach used by the project to deliver the end product, for example, basing the design on an existing product or developing an entirely new design, or whether or not resources used for the project will be provided internally or by the use of third parties.

The Project Brief can be seen as a refinement of the Project Mandate, and in a similar way the Project Brief will be refined further within the initiation stage to become the Project Initiation Documentation (PID).

One important principle of PRINCE2 is that of manage by exception.  The purpose of this is to set tolerance levels at the directing, managing, and delivering management levels within a project.  Tolerance is defined as limit within which a particular level may manage without the need to escalate to the next level above. 

There are six objectives against which tolerances may be set: time, cost, quality, scope, risk, and benefits.  If any of these tolerances are forecast to be exceeded, then an Exception Plan must be raised which if approved would replace the existing plan that would have no longer completed within tolerance.

Corporate or Programme management have the authority to set project level tolerances, the Project Board have authority to set stage level tolerances, and optionally, the Project Manager may set tolerances around a particular Work Package.

One of the PRINCE2 principles is learning from experience.  For this reason the Lessons Log is created and filled with any lessons that can be learned from appropriate individuals and previous similar projects.  The project manager would be expected to proactively collect such data.  The Lessons Log will be updated and used throughout the project, in particular as a source of information to create the optional Lessons Report at the end of each stage, and the Lessons Report that is created as part of the Closing a Project process.  In this way, lessons can be passed on to future similar projects.

The Daily Log is also created by the project manager, and is used as a ‘diary’ by the project manager for the remainder of the project.  But here in SU, it is also used to capture any risks and issues that need to be managed prior to the formal start of the project.

To proceed any further, the newly formed project board will need to make a decision whether or not it is worth investing in the creation of the PID.  In particular how much work effort and resources are needed in the initiation stage.  In this way, poorly conceived projects can be nipped in the bud before any further effort is wasted upon them.  By the same token, the information contained within the Project Brief and the initiation Stage Plan will give the project board sufficient information to make an informed choice.

The Starting Up a Project process culminates with the project manager requesting that the project board consider authorizing the initiation stage.  This uses the first activity ‘authorizing initiation’ within the directing a project (DP) process.  The project board may decide not to proceed any further.  However let’s assume that in this instance they agree based on the evidence above to invest in the initiation stage, then this will become the formal start of the project, and corporate/programme management will be informed that the project is initiated.