Whilst there’s plenty of books written to help people understand PRINCE2, or to help prepare people for sitting the PRINCE2 examinations, there’s far too few which focus on how to apply PRINCE2 in real life.That’s why this book by Alan Ferguson is a welcome guide for any project manager utilizing PRINCE2 on their projects.
Integrating PRINCE2® builds upon the one part of the PRINCE2 manual (Managing Successful Projects with PRINCE2®) which is often overlooked, but is perhaps the most important chapter of all, namely, chapter 19 “Tailoring PRINCE2 to the project environment”.
This chapter discusses two things. Firstly, tailoring PRINCE2 which means adapting PRINCE2 to meet the needs of a specific project environment based upon the scale, complexity and risk of a project. Secondly, the chapter touches on embedding PRINCE2 which means how an organization adopts PRINCE2 to enable it to work alongside existing business processes.
Integrating PRINCE2® is a relatively short and easy to read book and is slim and light enough to easily slip into a small bag on the way to the office. That’s a welcome relief when too many books on project management seem to take pride in their ability to act as a door stopper at the same time as a reference book.
Chapter 1: Introduction
The book is divided into 4 chapters and has 2 appendices. Chapter 1 deals with a few definitions and describes what the book has to offer for different users ranging from project and team managers, project board members, programme and portfolio managers, directors and support staff, all the way through to centre of excellence staff.
Chapter 2: Tailoring PRINCE2
Chapter 2 focuses on tailoring PRINCE2. As I said above, tailoring is what the project management team does to apply PRINCE2 to suit the needs of their project. The PRINCE2 manual suggests that because the principles of PRINCE2 are universal that they cannot be tailored. In his book, the author takes a different view which I think is the right thing to do. His suggestion describes the choices a PRINCE2 champion (the person driving the embedding of PRINCE2 within an organization) faces.
On the one hand, they could use PRINCE2 on a project with no consideration given to the local culture. With this approach, the author argues there would be “cultural risks”. For example in an organization which has had a negative previous experience of a quality management initiative there might be resistance to using the PRINCE2 term “quality”.
On the other hand, they could do nothing which would disturb the existing culture. However he argues this would lead to project risks. For example, if the PRINCE2 word “quality” is not used and the usual approach to testing proves to be inadequate, it might be difficult to put in place a more rigorous quality management environment. It is, he argues, the task of the PRINCE2 champion to balance these risks. In other words, he suggest being pragmatic in the use of PRINCE2. That in itself is consistent with one of the principles of PRINCE2 which is to “tailor to the project environment”. If you find yourself in a situation where it is culturally inappropriate to apply a principle, then the principle may need to be compromised in order to avoid a culture clash.
Chapter 2 then goes on to discuss modifying the PRINCE2 themes. Practical and sensible advice is given for each theme. For example, in the Organization theme, the author describes the concept of having a project board which directs the project. On large projects with many stakeholders, this is likely to consist of several people, yet on small projects often will consist of only one person. The project manager manages the project day to day and reports to the project board. On many small in-house projects, the project manager often performs a team manager role and project support role too. So, at a minimum, PRINCE2 recommends there are at least 2 individuals taking part in the project management team.
The author raises the important question then about what should happen when the project is so small that a single individual can both direct and manage the project at the same time. This would tend to go against the PRINCE2 “management by exception” principle whereby the Project Board delegates the day to day management to the project manager, thereby saving themselves a lot of time and effort on the project. The answer, as the author quite rightly points out is that such a tiny project consisting of one person is not in fact a project, but a simple task.
I especially liked the author’s recommendation for tailoring the PRINCE2 Plans theme. PRINCE2 has a reputation (unfairly in my view) of being overly bureaucratic and concerned with documentation for documentation’s sake. The author takes the view that when developing plans it’s always better to put less effort into a plan and revise it frequently, rather than putting a lot of effort into a plan at the start. As the military say “no plan survives first contact with the enemy”, and therefore any plan will only show you how far from reality things actually are.
That’s not to say however, that plans aren’t required. They are, if only to help you understand how you are going to achieve something, how you will spend your money and what resources will be required.
Chapter 2 then goes on to discuss the tailoring of the PRINCE2 processes. He argues that a common problem with the processes is that practitioners often see them from an ‘all or nothing’ viewpoint. Either they are applied in their entirety because they are seen as mandatory, or they are dropped because they are seen as cumbersome, precisely because they were followed in full earlier. The author argues, rightly in my opinion, that a better approach is to ask how long a PRINCE2 process or activity may take, based upon experience. It might be the case that a single action takes minutes, an activity less than an hour and a process takes hours rather than days. Understanding the processes from this standpoint means they are far more likely to be adopted by practitioners than would otherwise be the case.
I also liked the description of how to start up a small project. On a small single ‘delivery’ stage project lasting a few months, combining both the Starting up a Project and Initiating a Project processes should last no more than one week. Starting up a Project might be no more than a meeting between the project manager and the executive followed by the project manager making notes to form the Project Brief. Planning the initiation stage might just be a matter of organizing a planning workshop. A further half day planning workshop might be all that is necessary for Initiating a Project. If the project board attend the planning workshop, approval could be gained there and then. Otherwise, the project manager would need to document the outputs of the meeting and send to the project board for approval. On such a project, there probably isn’t any need for a formal authorization of the initiation stage.
On such a single ‘delivery’ stage project there will be no need to perform the Managing a Stage Boundary process. The project board, if it has attended the planning workshop will not need to authorize a Stage or Exception Plan. It will only need to give ad hoc direction and authorize project closure.
If the project manager is also acting as the team manager then the activities of Managing Product Delivery will merge into those of Controlling a Stage. If the project manager is located physically close to the project board members then some of the activities of Controlling a Stage such as reporting highlights, escalating issues and risks, and requesting advice are simply a matter of a conversation at nearby desks.
When closing such a project, products might be handed over to another member of the project team, there might be few lessons to learn and therefore recommending project closure simply becomes another conversation.
Another topic covered in chapter 2 is that of scaling down the PRINCE2 management products by making them less formal, for example by using modern technology based tools such as instant messaging or mobile phones to record notes in a meeting. Tools not often associated with project management such as flipcharts or whiteboards can act as a Quality Register located in the office where the team are based.
The other way of scaling down management products is by combining them together. The author gives good examples of how and why combining some of the management products together can be extremely valuable, especially on smaller projects. Starting from a list of 26 different management products, the author manages to combine them together into a much more manageable and realistic 10 management products. So much for PRINCE2 being seen as bureaucratic!
The rest of chapter 2 covers the problems a project team may face when using PRINCE2 terminology in the face of business as usual language which might use different terms than PRINCE2 for many common items. The author explores some of the difficulties which practitioners face in such situations and offers some sensible recommendations to assist them.
Chapter 3: Embedding PRINCE2
Chapter 3 is all about embedding PRINCE2. It starts with a useful summary of 2 different models for organizational change. Firstly, the ‘machine model’, a top-down approach whereby a plan is developed by senior management and executed by staff who comply in order to achieve a reward. Secondly a ‘cognitive (thinking) model’, which pays attention to the motives of staff and leaders, and requires explanation if it is to succeed. For readers unfamiliar with change management, this is an interesting and concise read to say the least.
This chapter also provides a brief summary of other change delivery practices from AXELOS including programme management (MSP®), portfolio management (MoP®), portfolio, programme and project offices (P3O®) and value management (MoV®).
Perhaps the most interesting part of this chapter for me was the discussion about how to overcome familiar barriers to embedding PRINCE2. Such barriers include the often quoted objections that “PRINCE2 is too bureaucratic”, “PRINCE2 is only suitable for IT projects”, or “our project management practice is good enough already”. The author provides many well-though out and sensible approaches for helping a PRINCE2 champion overcome such objections.
It is during this part of the book where the author’s real world experience shines through. The author discusses the subject not in an abstract, theoretical way, but by using some excellent real world examples which the reader can easily relate to.
Most of the rest of chapter 3 discusses maturity models, and the Portfolio, Programme and Project Management Maturity Model (P3M3®) in particular. Maturity models have a long history in the software industry but more recently have gained more popularity across a range of industries. P3M3 builds upon such models and is a useful tool to enable organizations to understand their level of ‘maturity’ in terms of their portfolio, programme and project management capability.
The 5 level maturity models provides an organization with an awareness of which areas to focus improvements upon. Moving to a higher level of maturity results in more predictable and repeatable results from projects. Organizations can perform a ‘maturity audit’ to establish the level at which the organization sits, and this becomes the starting point to plan improvements in its project management capability. Again, the author provides a wealth of great advice on how to use P3M3 to assist PRINCE2 champions to lead and drive forward the embedding of PRINCE2 within their organizations. In addition the author discusses 2 other strategies for improvement in addition to the maturity-led one.
Chapter 4: PRINCE2 integrated for a small, medium and large project
It’s this chapter which most readers, myself included, will probably find the most value. It describes how to tailor PRINCE2 for 3 different scales of project. Since the majority of readers of this book are likely to have attended PRINCE2 training, they will know that their course in all likelihood didn’t spend much time on how to tailor PRINCE2. This is usually because of the time constraints on such courses and the overwhelming need to prepare people for sitting the PRINCE2 exams.
For those readers who have to use PRINCE2 at work, this chapter is invaluable. It looks firstly at NormalCo which is a fictional medium sized business. Most of its work is business as usual, but with some projects. It has several offices, all of which are located in the same country. Its projects do not have separate budgets and staff record the time they spend on projects. Most of the resources on projects are internal. The author shows how both the PRINCE2 themes and processes can be applied without tailoring on NormalCo’s projects. Since NormalCo reflects a fairly common type of business, this is one which many readers will be familiar with.
The second type of project which is discussed is one run by Radical! This is a small company run by 2 directors. They employ a few admin staff who all work in the same office. They sometimes employ other companies to provide services. Radical! often runs several small projects simultaneously and the pace is frenetic, often lasting less than 3 months. The author shows how a very lightweight implementation of PRINCE2 is sufficient to enable the organization to successfully deliver such projects with minimal overheads.
The third type of project are large, complex ones, managed by a multinational organization called Integration International. Its projects are typically delivered with 3rd party suppliers. The organization is fairly mature in its project and programme management capabilities and has a centre of excellence to provide assistance to project and programme managers. Here the author discusses how PRINCE2 is aligned with other change deliver practices and how it is embedded as part of a programme of change.
Appendices
There are 2 appendices in the book. One contains a very brief summary of PRINCE2. At only 6 pages long, it’s not detailed enough to provide a decent overview of PRINCE2. Since I cannot imagine anyone reading this book who is not already familiar with PRINCE2 I think this section is unnecessary. The second appendix however is useful because it contains a few entries which define some of the terminology used in the book such as PRINCE2 Champion and scaling up and down.
Summary
All in all, despite my one small criticism about the appendix, I have one other criticism as well and that is that there aren’t enough examples. Whilst the examples given are all well thought out and are extremely valuable to PRINCE2 champions, I think readers would benefit from some further detail. I realize that by doing so, the book would face the risk of becoming one of those typical heavyweight project management tomes which I mentioned at the start of this article.
One of the beauties of the book is that it is small, slim and light. So perhaps the publishers got the balance just about right. Having a book which can be easily read on the train home and yet also provide a lot of useful insights and understanding is a rarity these days.
Overall though I thoroughly recommend this book to anyone with an interest in tailoring or embedding PRINCE2. The understanding required to assist such tasks will be aided enormously by this book. No PRINCE2 champion therefore should be without this book.
MoV® is a Registered Trade Mark of AXELOS Limited
MoP® is a Registered Trade Mark of AXELOS Limited
MSP® is a Registered Trade Mark of AXELOS Limited
P3M3® is a Registered Trade Mark of AXELOS Limited
P3O® is a Registered Trade Mark of AXELOS Limited
PRINCE® is a Registered Trade Mark of AXELOS Limited
Published by the Stationary Office (TSO) in 2014. ISBN:9780113314416.