PRINCE2 - Initiating a Project (IP) part 3
of the Cabinet Office under delegated authority from the Controller of HMSO.
Planning a Project (IP2)
Fundamental principles
The timescale and resource needs of the project must be established before the commitment of expenditure. The information will be in the Project Plan and is needed so that the Business Case can be evaluated and the Project Board can control the project.
Context
This sub-process uses the common Planning (PL) process to produce the Project Plan.
It will include the implications of the Project Quality Plan from the sub-process Planning Quality (IP1) and Defining Project Approach (SU5).
Process description
The objectives are:
- Understand at a high level the totality of the work that is about to be undertaken by:
- Identifying and, where possible, defining the major products of the project
- Identifying the major activities to be performed to deliver the products
- Assessing the major risks of the project and putting in place countermeasures, as highlighted in the component Management of Risk.
- Estimating the effort needed
- Identifying what timescales are achievable, given the project constraints and any key milestones
- Identifying the overall resource requirements and costs
- Identify the decision and review points for the project, and any implications on these from the Project Approach. Based on these decide on where the management stages should be; see the component Controls
- Use the Planning (PL) process to produce the Project Plan
The Project Approach will affect many aspects of the project, for example:
- What testing can be done
- The type and amount of development to be done
The planning standards need to be decided.
- Tools and techniques
- Content and presentation of plans
- Adoption or otherwise of corporate or departmental standards
This sub-process is basically a planning process and the detailed steps are explained in the component Planning (PL).
Change budget
How many change requests to the objective or specification will be submitted during the project?
You must consider this as they will take up resource to process them.
If it is likely that a number will arise the Project Manager should discuss with the Project Board the need for a change budget.
Otherwise the Executive will have to continuously go to the Project Board for an increase in the budget.
Contingency budget
At this point any risks (threats or opportunities) to the project will be known and analysed as part of the process Analysing Risks (PL6).
If the risks are such that contingency plans have been prepared the Project Manager should go to the Project Board for a contingency budget.
This would be needed should the risks occur.
Responsibilities
The Project Manager is responsible and assisted by Project Support and other members of the project management team and guided by those with Project Assurance responsibilities.
| Management information | Usage | Explanation |
|---|---|---|
| Project Approach | Input | This explains what methods will be used to carry out the work of the project and provides a key input into the Planning (PL) process. |
| Project Brief | Input | This document contains the base information about the project. It is the information that this process used as the primary start point or the Planning (PL) process. |
| Project Quality Plan | Input | This product is needed because the work carried out, and the time and resources needed to conduct the work will be influenced by the quality required and the quality standards and methods to be adopted. |
| Risk Log | Update | Risks identified in the log may affect the Project Plan. Conversely the Project Plan may create new risks or modify existing ones. |
| Project Plan | Output | This is the ultimate product from the sub-process and its production is the prime reason for carrying out the sub-process. |
These are given in tabular form in the file ‘IP2 planning a project.doc’ in the product package.
Key criteria
- Does the Project Plan show the appropriate balance between being comprehensive and complete, and being sufficiently concise to be understandable?
- Are all the relevant parts of the Project Brief reflected in the Project Plan?
- Is the level of detail in the Project Plan appropriate for the project, bearing in mind:
- The duration of the project
- The levels of certainty or otherwise concerning the project’s final product(s)
- The complexity of the project, for example, the number of dependencies compared with the number of products, the number of departments or groups involved
- The corporate and business risks involved?
- Is the Project Plan supported by the other elements of the Project Initiation Document? Also, is it in sufficient detail to support development of the Project Initiation Document?
- Is the Project Plan in a state suitable to support the decisions to be made in 'Authorising a Project (DP2)'
- In the Project Plan concise enough to be of practical use for the members of the Project Board?
- Is the Project Plan consistent with corporate and / or programme plans?
Make sure the Project Brief is understood.
The final Project Plan may initially exist in draft form with a detailed next Stage Plan.
When the latter is built, the knowledge gained will allow the Project Plan to be updated.
You will need to assess the risk scenario of the Project Plan itself.
When part of a programme there may be a need to consider interaction with the project.
That is:
- Periodic audit to ensure reconciliation
- Programme briefings
Managing Successful Projects with PRINCE2 - 2005 edition
Managing successful Projects with PRINCE2 – 2009 edition
Directing Projects with PRINCE2.
plus:
The Complete Project Management package.
And much more besides - at a fantastic price.