Tag Archives: tailoring

PRINCE2 Best Practices

Best practices for PRINCE2 are called, confusingly, Principles. There are seven PRINCE2 principles and you can see how they fit into the structure of PRINCE2 in this diagram.


The best practices (or principles) are given below.

Continued business justification There should always be a business reason to start the project in the and this justification should continue throughout the project lifecycle.

Learn from experience.  Because projects are transient, it is vital that they take advantages of lessons from previous experience. These lessons are therefore explicitly recorded and implemented during each the project.  At project closure, any lessons learned are documented and stored for future projects.

Defined roles and responsibilities. Its is important that the right people are involved and know what is expected of them.  This engages all stakeholders (business, user and supplier) within the project.

Manage by stages.  Every project is planned, monitored and controlled on a stage by stage basis.  These management stages provide senior management with control points, while having the high-level plan split down into detailed stage plans. A PRINCE2 project has at least two management stages: an initiation stage and a delivery stage. Larger projects may need to use as many stages as required.

Manage by exception. PRINCE2 sets tolerances at the directing, managing, and delivering levels.  As long as forecasts are within these tolerances then each level can continue.  The moment a tolerance is forecast to be exceeded, the details and options for recovery must be escalated to the next level for resolution via an exception report.

Focus on products.  This enables an explicit understanding of the products/deliverables that need to be produced along with their quality criteria.  Because of this focus a PRINCE2 project clearly defines the scope of a project and provides the basis for planning and estimation.

Tailor to suit the project environment.  As has already been mentioned, PRINCE2 is tailored to suit the projects environment, size, complexity, importance, capability and risk.  A major document within PRINCE2 is the Project Initiation Documentation or PID. Part of the PID specifies how the method is to be tailored for any project. In my experience most tailoring in practice is for small projects – see my posts on PRINCE2 for small projects (< 1 person month) and PRINCE2 for medium projects (1-2 person months).

See also PRINCE2 processes, and PRINCE2 themes.

Small projects with PRINCE2

One of the core principles of PRINCE2 is to amend the methodology appropriate to the project requirements. In my experience this almost always means cutting it down for small, short jobs.

In the past I have advised teams and individuals a number of times on how this might look. I thought it would be worth thinking a little more formally how this works for small projects. For our purposes, lets call a small project one < 1 person-month.


Lets start with what makes a managed project as opposed to simply coding. In my very simplistic way (I’m big on simplicity) it’s just this. We need to know:

  • What we intend to deliver
  • How we intend to produce it
  • Who needs to know about it
  • What might go wrong.

Of course each of these is complex and involves lots of different areas (build, test, change management just in the producing part for example), but it seems to me that if you know those things you have a project.

So lets look at those areas and the artefacts we might need for each using three types of small project

1. A simple one person, less than one week job – maybe a POC

2. A one person, two/three week job – the kind of work you might be asked to do as a low priority, when you have time thing – perhaps an simple extension to an existing system or a simple online information system from a DB with no transformation

3. A two person two week job. Something significant but still not a major project. Perhaps a simple audit enhancement to a reporting system.

So the artefacts we need for these three levels might look like this.


And that’s it. Simple (I hope) but covers most of the bases. Obviously there will be areas missed, but they simply represent risks. What we want is to have a level of project management which is appropriate to the actual size of the project and the potential downside if things should go wrong.

Medium sized projects with PRINCE2

For projects around 1-2 person months you need some, but not all, of the PRINCE2 artifacts. Whenever I have specified planning requirements for medium sized projects such as this I focus on the below.

At this level, planning becomes key. There are two major deliverables from the project planning process – the PID and the work plan.

The Project Initiation Document

The Project Initiation Document or PID is the primary deliverable from the specification process and describes all aspects of the project at a high level. Even for a medium sized project time spent on the PID pays dividends later. Even a cut down PID should contain information such as:

  • Project overview – Why is the project taking place? What are the business drivers?
  • Objectives – What will be accomplished by the project?
  • Scope – What deliverables will be created? What major features will be implemented?
  • Organization – Who is the sponsor? Who is on the project team? What other stakeholders are there?

So far this is a 3-4 page document. In addition you should have an excel spreadsheet containing

  • Assumptions and Risks – What events are you taking for granted and what do you think might go wrong? What is the probability of occurence and the impact (H/M/L is fine). What mitigation steps can you take and who is responsible for tracking the risk.

The Workplan

Create a workplan, including milestones, tasks and named resources. If appropriate use MS Project, otherwise Excel.



Once the project has been planned, execution of the work can begin.

Monitor the schedule weekly or twice-weekly.

Identify activities that have been completed during the previous time period and update the workplan to show that they are finished. See if the project will be completed within the original parameters. If not, look for ways to accelerate these activities to get you back on track and inform stakeholders ASAP. A small slippage on a medium sized project is highly visible and can cause issues out of all proportion to the project size.

Look for warning signs

These could include

  • Activities that should be completed are still being worked on.
  • Reliance on unscheduled overtime to hit deadlines
  • Team morale starts to decline
  • QA and testing activities starts to be cut back from the original schedule.

If these occur, put together a plan to ensure that the project stays on track. If you cannot successfully manage through the problems, raise an issue through project management support.

Watch for scope change requests and scope creep

After the basics of managing the schedule, managing scope is the most important activity required to control a project. Many project failures are not caused by problems with estimating or team skillsets, but by the project team working on deliverables that were not part of the original requirements. Even if you have good scope management procedures in place, watch for scope creep.

Most of us know to invoke scope change management procedures if we are asked to add a major new function or a major new deliverable to their project. However, sometimes we do not recognize the small scope changes that get added over time. Scope creep is a term used to define a series of small scope changes that are made to the project without scope change management procedures being used. With scope creep, a series of small changes, none of which appear to affect the project individually, can accumulate to have a significant overall impact on the project.

Assess risks throughout the project

Once the project begins, periodically perform an updated risk assessment to determine if other risks have surfaced that need to be managed.

Resolve issues when they arise

All projects will have issues that need to be dealt with and resolved. If possible deal with these immediately before you get swamped. At a minimum track them via an actions or issues list at every team or stakeholder meeting.


There are always complexities dealing with technology and integration, even in small and medium sized projects. Project management involves dealing with unanticipated events no matter how large or small the project is. These practices will not prevent that, but they might at least make the environment they take place in more stable and manageable.