I recently attended a training session entitled “Understanding PRINCE2® Lite” and it gave me a lot to think about. This post summarises my main learning outcomes. If you’ve used PRINCE2 Lite, I’d like to hear from you! Tell me about your experience in the comments.
PRINCE, PRINCE2 and PRINCE2 Lite
PRINCE2 stands for PRojects IN Controlled Environments and it is a “process-based method for effective project management” (see full info on the PRINCE2 website). The original PRINCE was developed by the UK Government as a tool for project management, and it draws on best practice – so you may find that you are already doing many of the key activities that are part of the model. PRINCE2 is a more recent version of the original system. PRINCE is a registered trade mark of the Cabinet Office, and the PRINCE2 method is in the public domain, offering non-proprietorial best practice guidance on project management. PRINCE2 Lite is a scaled-down version of PRINCE2, but retains all the main features.
Phew! So what are the main elements of PRINCE2 Lite? Let’s begin with a definition of a project:
“A management environment that is creates for the purpose of delivering one or more business products according to a specified business case”
Key features of a project
- A finite and defined lifecycle with a clear start and end
- Defined and measurable business products (deliverables, outcomes)
- A corresponding set of activities to create (and quality check) the business products
- A defined pool of resources e.g. people, cash, equipment
- An organisational structure, with defined responsibilities, to direct and manage the project
- Has associated risks
Making the business case for your project
- What are the reasons for undertaking the project?
- Show the options you have considered, and benchmark them against doing/changing nothing
- Give details of the costs, timescales and risks
- State the potential benefits in measurable terms
- Explain how and when the benefits will be realised
- Examine the drawbacks and disbenefits – include the projects costs, and cost the benefits to produce a cost-benefit analysis
A project is not a PRINCE2 project unless the following are demonstrated
- Business justification – why are we doing this? If you were to ask any member of the team to give an elevator pitch for the project, they should be able to do so
- Learn from experience – team debriefs allow everyone to learn from each other’s experiences
- Focus on products
- Manage by exception (controlled delegation) – setting tolerances for timescales, cost and quality gives the delegated manager some flexibility and then only if they are in exception (outside the agreed tolerances) do they need to refer it up
- Manage by stages – break the project down
- Roles and responsibilities are clearly defined
- Tailor to suit the environment – take into account local practice
When does an activity or task become a project?
This will always be decided locally, according to the circumstances of your organisation.
Examples of criteria for identifying a project
- Financial budget level
- Number of staff involved
- Number of person-hours
- Involves risk to reputation?
- Capital expenditure?
- Political capital?
It’s important to have a clear distinction between projects and other tasks, to avoid excessive bureaucracy for activities which are not true projects.
The Project Board should use the stage boundaries to ensure commitment to one phase at a time – a bit like in mountaineering, maintain three points of contact and only move to the next when ready. Before moving on, check that the project is still viable, that it is aligned with the objectives, that the organisation still wants to commit resource/expenditure to the project and that the plan for the next stage is feasible. This avoids supertanker syndrome, in which a project gathers momentum but is very difficult to stop or redirect when circumstances change.
This triggers the beginning of the process model above. The mandate should identify the Executive, Project Manager and other stakeholders; and should include the background, project definition, governance and key stakeholders, budget source and customer quality expectations/acceptance criteria.
Define the quality expectations and refine these into acceptance criteria. These can be turned into service level agreements once the project is complete. Once the project is complete, the deliverables become “business as usual” for the relevant team or department.
It’s important that everyone agrees what the quality expectations are, in order to avoid this problem:
The minimum number of people required to run the project is two: one to do the directing and the other to manage and deliver it. These roles may be further subdivided in a larger team.
Direction and delegation are passed down; and information, issues and risks are referred up.
Formula for estimating
Worst case + (Most likely x 4) + (Best case)
This equation was mentioned in the course of the session – I don’t know if it works or not, but it might be fun to test it out by predicting how many tins of tomatoes I need to buy the next time I’m grocery shopping.
When budgeting time or money for a project, set a range for each value rather than a specific target. For example: allowing 8-10 days, or £1,000-£1,100. This allows the project manager some scope to adapt and means that they only have to refer the issue up if they are in exception (operating outside of the agreed tolerance).
What are the risks? What is the likelihood of them occurring? Should they occur, what would be their impact on the project? What can we do to prevent or correct them?
Don’t forget to include positive risks!
Effective risk analysis involves identifying risks, their probability and impact, and determining how to prevent, reduce, accept, or transfer them (e.g. insurance, outsourcing) – or a contingency plan. Risk management is planning for the action that should be taken if required: responsibilities for actions, monitoring and controlling the plan to ensure that it happens. At the start of a project, arrange a Risk Workshop – to be facilitated by the Project Manager, and involving all key stakeholders.
A significant element of risk management is communication planning. Consider the sender, the message, the medium, the receiver and feedback when planning communications relating to your project.
Keeping any project on track involves planning, monitoring and controls. At the start of the project, agree the control methods that will be used, frequency, responsibilities and the information required at each control point.
This will lead to highlight reporting – regular progress reports from the Project Manager to the Project Board. These reports should include:
- Project status – red, amber or green
- Executive summary
- Progress against milestones (looking backwards and forwards)
- Deliverables for the next period
For this purpose, email is ideal – formal enough, but accessible and fast.
Bringing the project to a close
Have the objectives been met, all products/deliverables been completed and accepted by the customer? Once these matters have been addressed, carry out a post-project review. The post-project review assesses the achievement of the benefits as claimed in the business plan, and a summary of lessons learned from all members of the project team. Leaving a record of lessons learned from the process will help you reflect on what you’ve learned as well as well as contributing to your organisation’s knowledge bank.