13
Introduction to processes
This chapter covers:
•PRINCE2 as a process-based method
•the PRINCE2 journey
•the seven PRINCE2 processes in an overall model
•a key to the process and activity models
•the structure of the process chapters
•tailoring the processes
13 Introduction to processes
PRINCE2 is a process-based approach for project management. A process is a structured set of activities designed to accomplish a specific objective. It takes one or more defined inputs and turns them into defined outputs.
There are seven processes in PRINCE2, which provide the set of activities required to direct, manage and deliver a project successfully.
Figure 13.1 shows how each process is used throughout a project’s lifecycle. The lifecycle shown has three management stages: an initiation stage, subsequent stage(s), and the final stage. Note that on a simple project, there may only be two stages: an initiation stage and one delivery stage (the final stage).
The project board sets direction and makes key decisions throughout the life of the project. The project board’s activities are covered by the directing a project process (see Chapter 15), which runs from pre-project through to, and including, the final management stage.
In the beginning, someone has an idea or a need. The trigger for the project may come from new business objectives, responding to competitive pressures, changes in legislation or a recommendation in a report or an audit. In PRINCE2, this trigger is called a project mandate. The project mandate is provided by the commissioning organization (corporate, programme management or the customer) and can vary in form from a verbal instruction to a well-defined and justified project definition.
Prior to the activity to scope the project fully, it is important to verify that the project is worthwhile and viable. Such activities are covered by the starting up a project process (see Chapter 14), which culminates in the production of a project brief and a stage plan for project initiation.
The project board reviews the project brief and decides whether to initiate the project, and states the levels of authority to be delegated to the project manager for the initiation stage.
When a decision has been made to go ahead with the project, it needs to be planned at an appropriate level of detail. Funding needs to be obtained and appropriate controls should be defined to ensure that the project proceeds in accordance with the wishes of those people paying for the project and those who will make use of what the project delivers. The planning, establishment of the project management approaches and controls, development of a robust business case and a means of reviewing benefits are covered by the initiating a project process (see Chapter 16). Also, during the initiation stage, the managing a stage boundary process (see Chapter 19) is used to plan the next management stage in detail.
The initiation stage culminates in the production of the PID, which is reviewed by the project board to decide whether to authorize the project. As the contents of the PID are likely to change throughout the project (under change control), this version of the PID is preserved as input for later performance reviews.
The project board delegates day-to-day control to the project manager management stage by management stage. The project manager needs to assign work to be done, ensure that the outputs of such work (products) meet relevant specifications, and gain suitable approval where appropriate. At this point, products may be transitioned into operational use by corporate, programme management or the customer.
The project manager also needs to ensure that progress is in line with the approved plan and that the forecasts for the project’s performance targets are within agreed tolerances. The project manager ensures that a set of project records are maintained to assist with progress control. The project manager informs the project board of progress through regular highlight reports. The activities to control each management stage are covered by the controlling a stage process (see Chapter 17).
In the managing product delivery process (see Chapter 18), the team manager(s) or team members execute assigned work packages (that will deliver one or more products) and keep the project manager appraised of progress via checkpoint reports.
Towards the end of each management stage, the project manager requests permission to proceed to the next management stage by reporting how the management stage performed, providing an update to the business case and planning the next management stage in detail. The project manager provides the information needed by the project board in order for it to assess the continuing viability of the project and to make a decision to authorize the next management stage. At all times, the project board must ensure that the project remains aligned with the strategy of corporate, programme management or the customer. The activities to manage each management stage boundary are covered in the managing a stage boundary process (see Chapter 19).
As a project is a temporary undertaking, towards the end of the final management stage (when the project manager has gained approval for the project product) it is time to start the closing a project process. The project board needs to be satisfied that the recipients of the project product are in a position to own and use it on an ongoing basis. Should this be the case, the product can be transitioned into operational use and the project can close. The project documentation should be tidied up and archived, the project should be assessed for performance against its original plan and the resources assigned to the project need to be released. Closure activities include planning post-project benefits reviews to take place for those benefits that can only be assessed after the product has been in use (and therefore after the project has closed). The activities to decommission a project are covered by the closing a project process (see Chapter 20).
The project is typically contributing towards the benefits defined by corporate, programme management or the customer. Even though some of these benefits may be realized during the project, it is likely that many or all of the benefits will be realized post-project. Corporate, programme management or the customer therefore needs to be satisfied that the project has contributed towards benefits realization, and is therefore likely to hold one or more post-project benefits reviews. The reviews will be signposted in the project’s benefits management approach. If the project is part of a programme, then the post-project benefits reviews need to be covered by the programme’s benefits management activities.
A post-project benefits review will focus on:
•confirming that the planned benefits have been achieved
•identifying which planned benefits have not been achieved and agreeing a follow-up action plan
•identifying any unexpected benefits that have been achieved and any dis-benefits that resulted
•providing lessons for future projects.
13.2 The PRINCE2 process model
The PRINCE2 process model is shown in Figure 13.2.
The processes are aligned with the management levels of corporate, programme management or the customer, directing, managing and delivering. The triggers between the processes are shown.
Note 1: At the end of the initiation stage, the initiating a project process is used to request project board approval to deliver the project (with the submission of the PID), and in parallel the managing a stage boundary process is used to request project board approval of the stage plan for the second management stage.
Note 2: The closure activities are planned and approved as part of the stage approval for the final stage, therefore the closing a project process takes place in the final stage.
Figure 13.2 PRINCE2 process model
13.3 Structure of the process chapters
Each process within PRINCE2 is described using the following structure and format:
•Purpose Describes the reason for the process.
•Objective Describes the specific objectives to be achieved by the process.
•Context Puts each process in context with the other processes and activities going on within the project and from corporate, programme management or the customer.
•Activities Each PRINCE2 process comprises a set of activities, which may be run in series or in parallel. PRINCE2 activities comprise a set of recommended actions designed to achieve a particular result. The relationship between processes, activities and actions is shown in Figure 13.3.
•Tailoring guidelines Describes the approaches that can be used to tailor a process.
A diagram is provided for each activity showing the inputs and outputs, including those products that are created or updated by that activity. The recommended actions to be taken to achieve the objectives of the activity are described. A key to the symbols used in the process and activity diagrams is shown in Figure 13.4.
Each activity is concluded by a table showing the responsibilities (P, R or A) for each product created or updated during the activity, as illustrated in Table 13.1. Note that management products created during one process may be approved in another (e.g. a stage plan is created in the managing a stage boundary process but is approved in the directing a project process). However, the complete set of responsibilities is shown, and those covered by another process are shown in parentheses, as in (P), (R) or (A).
Table 13.1 An example of a table of responsibilities
Key: P (producer) – responsible for product’s production; R (reviewer) – ideally independent of production; A (approver) – confirms approval. Note that ‘Corporate/programme/customer’ means corporate or programme management, or the customer.
PRINCE2 requires that project management processes are as simple as possible and that they reflect the needs of the project. There may be some activities, however, especially relating to governance which may need to be prescriptive. This happens especially where they interface to a higher-level organization’s process, such as for procurement or finance (e.g. when allocating funds at the start of a new stage).
Tailoring enables flexibility in how the processes should be followed. This may range from being rigid and prescriptive, to allowing the project management team a large degree of freedom as to how they undertake an activity and the format of the products. Processes can be tailored ‘up’ or ‘down’ (i.e. additional detailed documentation and discipline can be introduced for high-risk projects, whereas concise bullet-point presentations and more informal processes may be adequate for low-risk projects).
A tailored PRINCE2 process should reflect any tailoring of the roles, products, themes (as implemented through management approaches, procedures and controls) and terminology. As terminology can be tailored, so can the names of the processes.
Usually, all processes remain relevant even for simple projects; what changes is the way in which they are undertaken, the activities and the degree of formality. Informality, with the right mindset, does not necessarily mean less rigour.
Key message
Tailoring allows the PRINCE2 process model to be adapted, revising the processes, activities, their sequencing and how the role responsibilities are allocated, provided that:
•the PRINCE2 principles are upheld
•the purpose and objectives of the process are not compromised.
Each PRINCE2 process chapter contains a section suggesting different tailoring options for implementing the process in practice. The general points for consideration are:
•amending the PRINCE2 process model to reflect the organization’s project management method or alternative ways of working
•adopting methods or ways of working required by the commissioning organization (corporate, programme management or the customer)
•combining some activities which fulfil related purposes, to simplify the process
•splitting some activities into smaller parts for clarity or to re-assign different roles to the activities
•changing which role is responsible for the activity
•combining, splitting or amending management products
•increasing the granularity of the process model, to include more detailed activities, where needed.
PRINCE2 does not prescribe the format in which a process is documented or published; processes on a web site or in documents are just as valid. If using documents, however, ensure that they are subject to change control so that users know which version is current.
Tip
PRINCE2 defines the project management processes, not the delivery approach related to creating each specialist product. Consider showing how these processes relate in a project lifecycle view.