A tour of PRINCE2 Principles - Tailor to suit the environment (7)

Like Snow White, the PRINCE2 Project Management methodology is built around 7 helpers :-) There are 7 guiding Principles, 7 Project Management Themes leading to 7 Processes. In a series of posts,  I want to take you through the 7 PRINCE2 Principles, my views on them aiding Project success and relate these to other posts on the Better Sheepdog site. Let me finish with Principle 7 - Tailor to suit the environment.

Principle 7 - Tailor to suit the environment

You need to realise that PRINCE2 was written for the UK Government. With deference to my colleagues working in government, sometimes they focus too much on the elegance of the process to the detriment of the outcome :-)

So my advice is always to look to tailor the methodology in line with this principle such as: 

• cutting out some of the excessive process elements
• adapting to the scale of project and the culture of the organisation
• possibly changing some of the terminology?

Using an analogy, think of PRINCE2 as a tool-box for Project Managers in a similar vein to, say, a plumber has a tool-box. You wouldn't expect a plumber to use every tool in his/her box just because they are there, there is a level of adapting to the job at hand even though there are tools which are used on every job - the monkey wrench and especially the invoicing tool :-)

Excessive process points?

Here are some examples of PRINCE2 processes that I have tailored as they seem a bit "over the top" to me:

• Change Management - I never log an Issue first before then logging the Request for Change. I have a much simpler approach which I detailed in this post.
• 99 times out of 100 the "Starting up" and "Initiation" processes become one process - Initiation!
• While some of the Management Products proposed are good in the principles behind them (and it is worth agreeing the subject matter as necessary), I have rarely produced a lot of them. Let me walk through these one by one:

1. Acceptance Criteria - not a separate Product, include within the Project Definition
2. Business Case - yes, plan to produce this - see this post and Principle 1
3. Checkpoint Report - replace with Team meetings or "One to One" meetings with key team leads in the majority of cases. It may be useful for third parties or where a piece of work has been defined as a Work Package
4. Communications Plan - yes and no! It isn't a separate Product but the spirit is included in a Stakeholder Map you should produce - see this post
5. Configuration Item Record - most of the content proposed goes into a Product I produced called a Quality Plan, see this post
6. Configuration Management Plan - rarely documented unless something new is being defined - see this post
7. Daily Log - I walk everywhere with my A4 ring bound pad titled my "Day Book". I use it for time management and logging meetings and thoughts
8. End Project Report - yes, this is your exit route to say the Project is complete although I normally call it the Project Closure Report - see this post
9. End Stage Report - I have rarely produced (I remember doing so for a Government client!). This information I tend to share with the Project Board & Sponsor through a Project Board Pack - see this post
10. Exception Report - I hope this isn't needed! But if you hit problems, communicate early and not via a report or email!! You may then to produce a revised plan, I prefer to call it a Recovery Plan than Exception Report, again making PRINCE2 a little more understandable to the non expert
11. Follow-on Action Recommendations - I have never produced a separate Product although the detail should be covered in the Project Closure Report, see above
12. Highlight Report - yes, this is one to produce, I suggest weekly. Again I tend to call it a Status Report - see this post
13. Issue Log - yes, although normally part of a combined RAID Log - see this post
14. Lessons Learnt Log - I have never created such a Log but I do have a simple text file on my desktop which I can jot thoughts
15. Lessons Learnt Report - yes, either separately or as a section in your Project Closure Report - see this post
16. Off Specification - I have never produced as part of Issue Management. Each Product should go through a quality assurance process and then be baselined. That doesn't mean that there aren't residual problems but these should be minimised.
17. Post Project Review Plan - The spirit of this Product is what I call the Benefit Realisation Plan (again I prefer my title, it says more about the purpose) - see this post
18. Product Breakdown Structure - I have rarely produced this although it could be useful in some circumstances and the principle of Product based planning (see Principle 6) is an excellent one - see this post
19. Product Check-list - I like to produce this in Excel with a few other columns to form what I call a Product Quality Plan - see this post
20. Product Description - a good idea but in 80% of cases you can achieve the aims in a better way I feel. For 20% of cases it may be worth doing as described by PRINCE2 - see this post
21. Product Flow Diagram - this can be useful sometimes when you haven't "been there & done the Project execution before" - see this post
22. Project Approach - this should form part of the Project Definition
23. Project Brief - the only time I have seen as a separate Product is in Government clients. I include the content in the Project Definition
24. Project Initiation Document - yes, very useful, the contract between the Project Owner and the Project Team. But I call it the Project Definition
25. Project Mandate - I can never recall being handed one of these! I've afraid, life is not normally that straight forward and sometimes you need to go and seek the all important Owner of the Project, who I call the Sponsor - see this post
26. Project Plan - quite useful, we will have one of those! - see this post
27. Project Quality Plan - a section in the Project Initiation Document above
28. Quality Log - I can't say I have ever had one of these although as I have said I am very keen on a Product Quality Plan - see this post
29. Request for Change - in most Projects I will accept an RFC by an email to me explaining sufficient detail. On some Projects it is worth having a form to make the requester think a bit - see this post
30. Risk Log - yes, although normally part of a combined RAID Log - see this post
31. Stage Plan - in rare occasions I have produced a separate Stage Plan, often I choose to have as a section in the Project Definition which is refreshed when moving from one Stage to another
32. Work Package - this can be useful, especially when dealing with off site third parties - see this post

Adapting to the scale of project and organisational culture

The management of the Project using PRINCE2 is a necessary evil but should be scaled to the size of the Project. If the technical effort of the project is 100 man days you don't really want to be spending 300 days effort on the management!

Some organisations love reams of paperwork, some seem to use little documentation. One of the key documents it is always worth having is the Project Definition (PID). In some organisations these are sizeable Word documents but for smaller projects or "anti-document" organisations, I have a PowerPoint template with the "essence of the definition" and nothing more. This is quicker to produce and more easily digested by stakeholders.

In terms of ownership, for a major project with a big investment or critical outcomes, a good well formed Project Board with various participants is useful to govern ensuring good stakeholder representation. But for many organisations or smaller projects, a single Sponsor is quite sufficient.

Changes of terminology

It may seem strange for me to suggest changes of terminology as one of the benefits of a methodology is a standard set of terms. However, in my experience, many of the people involved in Projects aren't steeped in PRINCE2 terminology and so there are a few examples of where I change things to (I hope) aid understanding:

• the Owner of the Project in PRINCE2 is called the Project Executive. I prefer to use the term Sponsor as I feel it better reflects the role and is easier to understand
• the key "contract" between the Sponsor and the Project team which defines the Project is called the Project Initiation Document by PRINCE2. I prefer the term Project Definition as once again I believe it better describes the Product
• some of the other PRINCE2 Management Products I give different names, see above

Beware of too much terminology and always be prepared to explain concepts to people rather than just quote PRINCE2 terms all the time. I went into this further in a post about helping the Sponsor in particular.

Other PRINCE2 Principles

The other PRINCE2 Principles are:

1. Business Justification - continuously throughout the Project execution
2. Learn from Experience - from previous Projects
3. Defined Roles and Responsibilities - so there is clear understanding of who is responsible for what
4. Manage by Stages - breaking down the Project execution into manageable chunks with gate reviews to move from one to the next
5. Manage by Exception - once plans are in place with the owner, no news is good news
6. Focus on Products - a focus on what is being produced rather than activities is beneficial
7. Tailor to suit the environment - this one!