PRINCE2 Foundation Module 2 - Starting Up a Project and initiating a Project
The Starting Up a Project process checks that we have a viable and worthwhile project. The Initiating a Project process establishes solid foundations for the project so that the enabling organization understands the work to be done to deliver the project’s products:
The 7 Processes may be considered as a set of "Toolkits" to be used WHEN needed.
Some processes are normally only used only once during a project:
- Starting Up a Project
- Initiating a Project
- Closing a Project
Other processes are used on a regular basis WHEN needed:
- Controlling a Stage
- Managing Product Delivery
- Managing a Stage Boundary
One process is used continuously from the beginning of the project until the close of the project:
- Directing a Project
Each process contains a set of activities and recommended actions.
PRINCE2 Process Sequence
I am often asked how one PRINCE2 Process “speaks” to another. My following summary will give you a new insight to each PRINCE2 Process, and how they work together:
It would be helpful if you thought of a PRINCE2 process as “Toolkits” or “Toolboxes” Each Process is used when they are needed – some once per project, some re-used several times, and one, Directing a Project, is used continuously after the completion of the starting up a project process.
Here is how the seven processes would be used in a (say), a three stage PRINCE2 project…
Note how some processes are used many times, and the differences between the Initiation Stage (creating and approving the Project Initiation Documentation) and the delivery stages (creating and approving the specialist products).
Also, that the Closing a Project process is used once within the last delivery stage, and is NOT in a stage of its own.
An Overview of the Seven PRINCE2 Processes
There are many drivers in an organization that may cause the need for change, and hence the instigation of a PRINCE2 project.
These drivers may include a new idea, a customer request, new business objectives, or the need to respond to competitive pressures, changes in legislation, the final report of a feasibility study, or even a recommendation or audit output.
Therefore, the trigger for PRINCE2 could be just about anything and in any form. This trigger is called the Project Mandate, and may take the form of a verbal instruction, the minutes from a meeting, or a direct request from senior management.
Starting Up a Project Process
The Executive of the Project Board is appointed who in turn will normally appoint or recommend the Project Manager. At this point, the Project Manager will create the Daily Log, which is usually in the form of a diary.
It is used throughout the project to capture any informal issues or risks, and for the Project Manager to use to note any information that may not be captured elsewhere (such as a ‘to-do’ list)
The rest of the management team are also appointed – the Senior User role, Senior Supplier role, and Project Assurance (if separate individuals).
The information in the project mandate will almost certainly need to be further refined and this uses the PRINCE2 process Starting Up a Project to carry this out along with other activities.
The project mandate will be further refined into the Project Brief plus the creation of a Stage Plan for the Initiation stage. The Project Brief contains the Outline Business Case, the project approach and the Project Product Description.
The Project Board will now review these two key documents and make a decision on whether or not to formally start the project.
Their thinking will be “do we have a viable and worthwhile project?”
Directing a Project
This is used continually throughout the project by the Project Board, and its purpose here is to use the activity ‘authorize initiation’ activity.
Initiating a Project
If a decision by the Project Board has been made to proceed further, then this is the trigger to start the Initiation stage, where the project brief will be further refined and expanded to become the Project Initiation Documentation (PID).
The project will now be planned in detail after the various Approach documents within the PID have been determined. These are:
- The Risk Management Approach
- The Quality Management Approach
- The Change Management Approach
- The Communication Management Approach
Appropriate Project Board and project management level controls are defined, including how funding for the project is to be obtained.
The outline Business Case contained within the Project Brief is now further refined to become the detailed Business Case as part of the PID.
The initiation stage is completed once all of the information is assembled within the Project Initiation Documentation which will now need to be reviewed by the Project Board to decide whether or not to authorize the project, and to proceed into the next stage (the first delivery stage).
Also during the Initiation stage, the Managing a Stage Boundary process is used to prepare for the End Stage Assessment, including the creation of the second stage plan.
Directing a Project
This is used continually throughout the project by the Project Board, and its purpose here is to use the ‘authorize the project’ activity. It does this by approving the PID and the next Stage Plan.
The activity ‘authorizing a stage or exception plan’ within the PRINCE2 process Directing a Project is used to approve or otherwise the second Stage Plan.
Once the PID is signed off, then all remaining stages (there may only be one), need to be authorized, and the Project Board will have delegated day-to-day control to the Project Manager for each remaining stage, one at a time.
Controlling a Stage
The Project Manager will assign work to the Team Manager/Specialist team) via Work Packages and will want to ensure that their progress is in line with the approved stage plan, and that the stage forecast remains within the projects performance targets and agreed tolerances.
To assist in progress control, the Project Manager will use a set of project records (the Daily Log, Lessons Log, Issue, Risk, and Quality Registers, and Configuration Item Records).
The Project Manager will keep the Project Board informed of progress via regular Highlight Reports.
Managing Product Delivery
This is used by the Team Managers and specialists team members to execute their assigned Work Packages, keeping the Project Manager informed of progress with regular Checkpoint Reports.
This is the process where the specialist products are created, and as such will normally spend most of the project budget!
Managing a Stage Boundary
At the end of each management stage the Project Manager will use the PRINCE2 process Managing a Stage Boundary process to create the next Stage Plan, update the Project Plan and Business Case, and assess the aggregated set of risks including any current issues.
This information will be presented to the Project Board in the form of an End Stage Report, where they will need to decide what to do next.
The final delivery stage (there can be as many as the project needs, but must have a minimum of one delivery stage), is different in that although specialist products will have been created, when the final products are approved, the Project Manager will use the PRINCE2 process Closing a Project process to prepare for controlled shutdown.
Closing a Project
The evidence from this process is used by the Project Board to authorize project closure.
The main deliverables are:
- Hand over the project products
- Benefits Management Approach
- End Project Report
- Lessons Report
Use this diagram to help visualize the way that the PRINCE2 processes map onto the typical stages of a PRINCE2 project:
PRINCE2 kicks off with the project “trigger” from Corporate or programme management – the Project Mandate.
- The Starting Up a Project (SU), and Initiating a Project (IP) PRINCE2 process are both “in series” – the Management Products of each being taken to the Project Board for approval (Authorizing initiation and Authorizing a project).
- The PRINCE2 process Managing Product Delivery, is used, along with the PID, to create the 2nd Stage Plan and End Stage Report containing the updated versions of the Project Plan, Business Case, and Risk Register.
- These Management Products are presented to the Project Board Authorizing a project), to agree that the whole project, in principle, should be agreed, and that it is sensible to invest in the 2nd Stage Plan (in the activity Authorizing a Stage or Exception Plan).
- From there on, the “Engine Room” of PRINCE2 takes over – ONE anticlockwise revolution per Stage…SB is used the prepare for the End Stage Assessment (ESA), Directing a Project process is used to approve the Stage Plan, Sets Tolerance, and sets the frequency of each Highlight Report….
- The PRINCE2 process Controlling a Stage (CS) authorizes Work Packages (WP), the Specialist Team then agrees them (all happens in Managing Product Delivery – MP)
- The Specialist Team creates the Products, carries out the Quality Checks/Quality Reviews, issues Checkpoint Reports on WP progress – and eventually completes the Work Package then advising the Project Manager, who needs to agree the Work Package
- The Project Manager “Manages by Exception”, issuing regular Highlight Reports and this continues until the last Work Package in the Stage is completed.
- This “triggers” the Project Manager to use PRINCE2 process Managing Stage Boundary (SB), create the Next Stage Plan, update the relevant documents, and present the information to the Project Board at an End Stage Assessment (ESA)
- Then the whole cycle repeats… In PRINCE2, all plans are documents, and the Plans Theme and the product-based planning technique is used whenever a Project Plan, Stage Plan, optional Team Plan, and Exception Plan (if needed), are required
Whenever the Stage/Project is forecast to exceed Tolerance, the Project Manager enters it in the Issue Register, and raises an Exception Report to bring the matter to the attention of the Project Board (along with options to recover/minimize the situation)
The Project Board then makes a decision to ask for a plan on a particular option or order a premature close.
If the Project Board wants an Exception Plan, the Project Manager will use Managing s Stage Boundary to create it, and then update the remaining documents just like an End Stage Assessment.
BUT, the meeting to agree/or not, an Exception Plan is called an Exception Assessment (EXA).
Once approved, the Exception Plan replaces the original Stage Plan that would have not completed within Tolerances, and the Project Manager authorizes new/modified Work Packages against the new Stage Plan
Starting up a project (SU)
This process is the pre-project preparation process, consisting of a high-level analysis of the project. It is also where the project management team are designed and appointed.
The purpose of the Starting Up a Project process is to ensure that the prerequisites for the process Initiating a Project are in place by answering the question: do we have a viable and worthwhile project?
The information gathered and created in this process is put before the project board, and is the point where they meet for the first time, so that they can make a decision whether or not to start the project.
They should agree that the project makes sense to do, and if so, agreed to invest in the Initiation stage for the creation of the Project Initiation Documentation.
Consider how the Starting Up a Project supports the seven PRINCE2 Principles:
- Continued business justification. By creation of the Outline Business Case
- Learn from experience. Met by capturing previous lessons on the Lessons Log.
- Defined roles and responsibilities. By designing and appointing the project management team and defining their roles and responsibilities
- Manage by stages. By creating the Initiation Stage Plan for the next stage in support of the decision to proceed or not
- Manage by exception. Tolerances will be set for the Initiation Stage Plan so that the first PRINCE2 stage will use MBE
- Focus on products. Used for the creation of the Project Product Description plus the management products within SU. The Initiation Stage Plan will use the PRINCE2 technique of product-based planning
- Tailor to suit the project environment. The Project Approach is designed taking into consideration the entire project environment
The Project Mandate, issued by corporate or programme management, triggers the Starting Up a Project process, and ensures that a business requirement exists via the creation of the Outline Business Case.
The Project Mandate is issued by the responsible authority for commissioning projects – usually corporate or programme management (the new project MAY form part of a programme, in which case the programme may also provide the Project Brief).
During the Starting Up a Project process, the Project Mandate is refined to develop the Project Brief. In the next process, Initiating a Project (which takes place in the Initiation Stage), the Project Brief is further refined to become the Project Initiation Documentation (PID).
The preparation of the Outline Business Case, and the assembling of the Project Brief are normally done in parallel due to the supporting information held in each. The Project Manager, members of the Project Board and other stakeholders will all liaise and contribute to these two documents.
The term Project Mandate can refer to any appropriate information to trigger the project. It could consist of a set of minutes from a high level meeting, a request for a proposal ore even the final recommending report from a feasibility study.
Here are the activities that occur within the Starting Up a Project process:
The Project Mandate may recommend an individual who should fill the Project Board Executive role, and the first activity will appoint the Executive who represents the interests of the business stakeholders. The Project Manager is also appointed to manage the project on a day-to-day basis.
A number of lessons may have been learned from other sources, possibly even external to the organization, and these lessons could be about any aspect, good or bad, concerning the application of methods, applications, processes, tools, etc.
These lessons will influence all of the management products being created in the Starting Up a Project process, and should be recorded in the newly-created Lessons Log. The Project Manager is responsible for setting up the Lesson Log and entering information.
The Outline Business Case (likely to be a high-level view at this time), is created by the Executive to prove there is sufficient business justification, and the project approach is selected (how the project will deliver the end product). The decision to proceed or not, is made in the Directing a Project process.
Design and appoint the project management team activity. The Project Management Team consists of the Executive, Senior User, Senior Supplier roles on the Project Board plus their Project Assurance responsibilities. Also The Project Manager and other roles such as Team Managers and Project Support are required. These roles will now need to be appointed.
SU provides management products that provide basic information such that the Project Board can make an informed choice whether or not to invest in the initiation stage and the creation of the Project Initiation Document.
The Project Manager produces the Daily Log, the project management team role descriptions, and the team structure. The Executive appoints the team.
The Daily Log is created which is used as the project managers “diary”, and it is also used to capture any issues and known risks.
Select the project approach and assemble the Project Brief. This activity (along with the Initiation Stage Plan), provides the key management products to decide whether or not to proceed to the Initiation Stage.
The Project Manager produces the Project approach, additional roles descriptions, the Project Brief, the Initiation Stage Plan and the Daily Log.
The Project Board reviews all the management documents, and the Executive approves them.
The Project Brief is used to provide a full and firm foundation for the initiation of the project.
The Project Brief document will contain key information captured from the other activities here in the Starting Up a Project process and consists of:
- Project Definition (terms of reference)
- Outline Business Case
- Project Product Description
- Project approach
- Project management team structure
- Role descriptions
- References
The project approach defines the choice used to deliver the business option selected from the Business Case taking the project environment into consideration.. Examples of project approach options are:
- Are any of the products to be created using a third party?
- What are the knowledge, skills and experience sets of in-house resources?
- Will the solution be a new product or a modification of an existing product?
- Will the solution be based on ‘off-the-shelf’ product(s) or custom designed?
The purpose of the Project Product description is to define what the project must deliver in order to gain acceptance. In other words it describes the purpose of the project’s product and who will use it. It is created containing the customer’s quality expectations and acceptance criteria.
As an example, suppose the end product of your project is a Help Desk facility for your organization. The Project Product Description would define the Help Desk Facility.
But the Help Desk facility consists of lower level products, such as trained staff, maybe a website, the equipment and system probably involving hardware and software, and so on. These lower level products would need Product Descriptions created as part of the PRINCE2 technique of product based planning.
SU creates the Initiation Stage Plan which covers the time and resources for the creation of the Project Initiation Documentation undertaken in the Initiation stage, and the time and resources to prepare and plan for the second (the first delivery) stage.
Initiating a Project (IP)
This process is used during the first stage - the Initiation Stage, and assembles the Project Initiation Documentation (PID). IP establishes solid project foundations, clarifies the reasons, benefits, risks and scope, and enables the organization to understand the work to be done to deliver the project’s products.
The purpose of the Initiating a Project process is to establish solid foundations for the project, so that the enabling organization understands the work to be done to deliver the project’s products before committing to a significant spend.
The trigger is the Authority to initiate the project from the Project Board using the Directing a Project process.
Initiating a Project context. It enables the Project Board, via the Directing a Project process to decide whether or not the project is sufficiently aligned with Corporate, Programme Management or Customer objectives to authorize its continuation.
The main objective here is that all parties must be clear on what the project is to deliver, why it is needed, how the outcome is to be achieved and who are responsible, so that a genuine commitment can be made. Hence, the main product that is assembled is the Project Initiation Documentation.
The purpose of the PID is to define the project, in order to form the basis for its management and an assessment of its overall success. In addition the PID gives the direction and scope of the project, and forms the ‘contract’ between the Project Manager and the Project Board.
It ensures the project has a sound basis prior to asking the Project Board to making a commitment, it acts as a base document against which to asses project progress and provides a single source of project reference.
Consider how the Initiating a Project supports the seven PRINCE2 Principles:
- Continued business justification. By refinement of the Business Case
- Learn from experience. By capturing lessons from the Lessons Log and using these as an input for all the management products that are assembled within the PID.
- Defined roles and responsibilities. By virtue of creating the management products that are used within the PID, the roles and responsibilities from the Starting Up a Project process are refined and possible expanded.
- Manage by stages. By creating the Next Stage Plan for the next stage in support of the decision to proceed or not. Also by agreeing the number and timing of the future stages within the Project Plan.
- Manage by exception. Tolerances were set for the Initiation Stage and the Project Manager will use these to manage the initiation stage.
- Focus on products. Management products within the PID are created and the PRINCE2 product-based planning technique is used for Project Plan and Stage Plan creation.
- Tailor to suit the project environment. The Project Approach was designed taking into consideration the entire project environment, and this will be used here as a key input to all management products.
The Risk, Quality, Change and Communication Approach Documents
These are the ‘how-to’ documents, and, based on the project approach will define how each Approach is to be applied to this particular project. Since it will have a bearing on all the strategies, the Communication Management Approach document should be completed last.
The Project Brief will be a key input when creating these documents.
The Project Manager will be responsible for creating all management product documents with input and review from Project Assurance, while the Project Board is responsible for approving them.
Set up the project controls. The Project Manager is responsible with input and review from Project Assurance, and these can be seen as Project Board level controls and Project Manager level controls. They will include aspects such as management stages (number and timing), communication aspects, and tolerances, mechanisms for issues, changes, and exception escalation.
Create the Project Plan. The Project Manager is responsible with input and review from Project Assurance.
Refine the Business Case. The Project Manager is responsible with input and review from Project Assurance. As with all products, the Project Board will approve them, with the Executive being particularly interested in the Business Case, since they own it.
Also, in this activity, the Benefits Management Approach is created, and although the Project Manager may create it, the Senior User role is ultimately responsible to corporate or programme management for the ultimate realization of all the Business Case derived business benefits.
Assemble the Project Initiation Documentation. The Project Manager is responsible with input and review from Project Assurance. The Project Board will approve it. It is worth noting that the PID may not be a single document, but instead a collection of related documents.
This information will be presented to the project board, who meet for the second time to authorize the project. The second Stage Plan is also created (using the Managing a Stage Boundary process).
It is not until the second (delivery) stage that any specialist products are created. Both the PID and the second Stage Plan are approved or otherwise, in the Directing a Project process.
The PID sets out WHAT the project is intended to achieve, WHY it is needed, HOW the outcome is to be achieved WHEN activities are to happen, and what (WHO) people's responsibilities are.
It contains a suite of management products sufficient for the level of control needed by the Project Board. The Senior User is responsible for identifying the expected benefits within the Business Case, and the Project Manager creates the Benefits Management Approach – used to define how and when measurement of the benefits will be achieved.
The project is split into a number of management stages; the first stage is called the Initiation Stage.
The minimum number of stages is two. A stage is defined as partitions of the project with management decision points, and at the end of each stage, the Project Board must approve the next stage plan including the resources required before authorizing the Project Manager to control and manage that stage.
Once the PID is signed off by the Project Board, it is now owned by them and encourages their commitment. The PID will be used as a "baseline" against which to monitor and manage control and report throughout the project.
Parts of the PID will be updated at the end of each stage to reflect the latest progress and understanding. It is important that the PID contains a viable Business Case demonstrating that the benefits to be realized are worth the time, effort, cost and risks.
The objectives of the PRINCE2 process Initiating a Project are to:
- Agree whether or not there is sufficient justification to proceed with the project
- Establish a stable management basis on which to proceed
- Document and confirm that an acceptable Business Case exists for the project
- Ensure a firm and accepted Foundation to the project prior to commencement of the work
- Agree to the commitment of resources for the first stage of the project
- Enable and encourage the Project Board to take ownership of the project
- Provide the baseline for the decision-making processes required during the project’s life
- Ensure that the investment of time and effort required by the project is made wisely, taking account of the risks to the project
Key Inputs to the Initiating a Project process
You will need to know how the following key documents inputs are used in Initiating a Project:
Daily Log. This is used to review any risks and issues associated with the Risk and Configuration Management Approach documents.
Lessons Log. This is used to seek lessons to be applied to the Risk, Quality, Change, and Communication Management Approach documents.
Project Brief. This is reviewed to understand if any corporate or programme management strategies, standards or practices need to be applied to the Risk, Quality, Change, and Communication Management Approach documents.
Project Product Description. This is reviewed for the Quality Management Approach document, to understand the customer’s quality expectations and to check that the acceptance criteria are sufficiently defined. It is also used to determine whether it needs to be updated (possible acceptance criteria?) because of planning done in creating the Project Plan. Outline Business Case. This is updated in the activity Refine the Business Case to reflect the estimated time and costs as defined by the Project Plan plus the aggregated risks from the Risk Register.