Creating PRINCE2 Plans
This planning activity will typically run in parallel with the other planning steps, as risks may be identified at any point in the creation of revision of a plan.
Each resource and activity, and all the planning information, should be examined for its potential risk content.
All identified risks should be entered into the risk register, or the daily log
Off to the plan has been produced, it should still be considered draft until the risks inherent in the plan have been identified and assessed, and the plan possibly modified.
Examples of planning risks
- Omission of plans at the appropriate management levels
- Lots of resources joining a project at the same time can slow progress and cause communication issues. Plotting an S-curve for the resource profile over time, can identify this and steep curves should be avoided.
- The plan includes are named resources, causing the product if itty of the actual resource to differ from the estimated product of a tea in the plan
- The plan contains a high proportion of external dependencies
- The plan uses untested suppliers or is dependent on new technologies
- There’s a high proportion of activities on the critical path and a delay to any one of them will delay the plan
- The plan does not allow for sufficient management decision points such as management stage boundaries
- There’s not much float in the plan – a planning tool can help identify this
- Many products are to be completed at the same time
- The plan is time bound by fiscal boundaries or by calendar boundaries
- The schedule shows that many parts running closely in parallel with the critical part are likely to become critical themselves if there is a minor slip
Plans for projects within a programme
Any specific standards that the project planners should work two will be described in the program’s monitoring and control strategy
The programme may have dedicated planners that can help the project manager prepare and maintain the project plan and stage plans
The programme dependency network will detail which of the project’s deliverables are being used by other projects within the programme, and any such dependencies to or from the project should be incorporated into the project plans
The number and length of management stages will be influenced by the program Plan. It may be desirable or necessary to align stage reviews to programme milestones, for example at the end of a tranche.
The programme may even define a set of standard management stages with which all projects within the programme comply.
Plans when using an agile approach
Product based planning can be applied very easily two agile delivery and it is important to plan around the requirements being delivered.
Many agile techniques and concepts exist in this area. They focus on how much can be delivered over fixed period via a sprint or a Timebox, and often appear in an informal low tech visible format such as a simple list or backlog.
When agile is being used, a common approach would consist of:
- A management stage for the starting up a project process, producing the vision and product roadmap
- A management stage for the initiating a project process, producing the product backlog
- A series of delivery management stages containing releases of (groups of) requirements or features
- The first two management stages could be combined
Plans from a supplier perspective
When tailoring the plans theme for a customer/supplier situation it must be clear through the contract, how the plans are to be produced and what rights of inspection and audit the customer has.
A supplier’s plan should have sufficient activities and/or milestones for the customer’s project manager to maintain their plans
Plans need to include procurement related milestones such as purchase orders and milestone payments aligned with each management stage
Both the customer’s and supplier’s plans may be confidential to the other party as they may contain other information sources dependencies to or from other client projects, subcontractor costs, etc.
It is therefore beneficial to prepare none confidential versions of the plan that can be shared, omitting private information
Techniques: prioritization, estimation and scheduling
The MoSCoW prioritization technique
Project seldom have the money, time or resources to deliver everything wanted by the business, users or suppliers, even if delivery of everything has a business justification.
This means that are most projects acceptance criteria and quality criteria need to be prioritized, with the project attempting to deliver as much as is possible and for which there is a business justification.
In the absence of any other approach, PRINCE2 recommends the use of a technique called MoSCoW as a general prioritize a shun technique – it stands for:
- Must have
- Should have
- Could have
- Won’t have
Only those things identified as ‘Must have’ are guaranteed to be delivered by a project.
MoSCoW can be used in a range of prioritization contexts, such as prioritizing issues and changes.
In the context of acceptance criteria and quality criteria the following definitions apply:
Must have. The acceptance criteria or quality criteria defined what is essential and critical to the business justification of the project. This would include failing to meet a legal or regulatory requirement.
If the business justification for the project is viable without the criteria, even if it would involve undesirable work arounds, then the criteria are not ‘must haves’
Should have. The acceptance for quality criteria define what is important, but not critical, to the business justification of the project. Their absence would tear really weakens the business justification.
Could have. The acceptance for quality criteria define what is useful, but not critical, to the business justification of the project. The absence does not weaken the business justification.
In practical terms, the distinction between should have and could have can be difficult to make and is often determined by:
A level of impact on the business justification. For example, a criterion might be considered ‘should as’ if it has greater than 1% impact on benefits
An assessment of the actual or perceived impact of not having satisfy the requirement. For example, a ‘no manual workarounds’ restriction might be the difference between should have and could have.
Wont have. The acceptance criteria or quality criteria defined what has been considered, but will not be delivered. Even though it might appear strange to record what is not going to be delivered by a project, doing so is often powerful as if formalizes an agreement to not deliver something.
This acts as a reminder that something has been consciously considered and can avoid the requirements being reintroduced later.
MoSCoW can be used for other types of prioritization, such as prioritizing changes, by adapting the criteria as necessary.
When MoSCoW is used in this way, the criteria for ‘must have’, ‘should have’ and ‘could have’ should always be based on the impact on business justification, in line with PRINCE2’s continued business justification principle.
The MoSCoW technique can also help to define scope tolerances, thereby supporting the manage by exception principle.
PRINCE2 Scheduling techniques
Examples of presentation formats for the schedule
Gantt charts
A Gantt chart is a graphical representation of the duration of tasks against the progression of time and allows the project manager to:
- Assess how long a plan should take
- Lay out the order in which tasks need to be carried out
- Manage the dependencies between tasks
- See what should have been achieved at a certain point in time
- See how remedial action may bring the plan back on course
Critical path diagram
A critical part diagram highlights those tasks which cannot be delayed without causing the plan to be delayed, and those tasks that can be delayed without affecting the end date of the plan. It helps with monitoring and communication.
Spreadsheets
It is possible to create a list of tasks ‘down’ the spreadsheet and the timeline ‘across’ it, then covering the sales to represent with the tasks will occur in the timeline, and progress to date periods
For simple projects where the timeline is unlikely to change, this may be adequate.
For larger complex projects, the timeline may change frequently meaning that the project manager may spend significant time changing the schedule while neglecting the day-to-day tasks required to manage the project.
Product checklist
A product checklist is a list of the major products of a plan, plus key dates in their delivery.
Pass Your PRINCE2 Practitioner Exam At First Try HERE!
This course is DEPRECATED
The old PRINCE2 6th Edition Foundation and Practitioner syllabus was upgraded in 2024. Check out the brand NEW PRINCE2 7th Edition Masterclass, covering all the current syllabus, training material and online exam benefits HERE
Your Route To PRINCE2 6th Edition Practitioner
Study PRINCE2 6 Foundation and Practitioner Exams with our famous on-line course with streaming HD Video Lessons, study guides and mock exams. In the last fifteen years we have had 6,000+ Academy students successfully transform their careers as PRINCE2 Practitioners.
