What makes Best Practice better?

My thoughts on the update to PRINCE2

PRINCE2 has recently been updated so I thought I would give anyone interested my thoughts about the update.

Whilst reading the latest version I was reminded of the man who taught me how to train the method, he was the lead trainer at a company I worked for, they were called Remarc, Phil Stephenson Payne quit his job because he was so annoyed by the update. Did I quit after reading this update? Answer later.

PRINCE2 never tried to deal with the people side of project management, this was because leadership very much depends upon the culture of each organisation and therefore couldn’t be described in a way that would apply to every project everywhere.

PRINCE2 now provides guidance on people and leadership. To be honest I used to try to help the people I trained to understand this reality. Project managers need to lead teams and not manage them because they rarely have any real authority over them, despite what the structure looks like.

PRINCE2 has always tried to be very clear that projects were about creating something tangible and that the main focus of project management was to get that thing built within time, cost, quality, scope, risk and benefit constraints.

PRINCE2 now assumes that the things the project produces need to be used so has included a little help with business changes too. In practice project managers always needed to do this despite the method assuming someone else would do this for us.

PRINCE2 previously defined 26 documents for each and every project, some considered this to be excessive, but it had a place for everything and everything could be found in its place. This is important, particularly in regulated environments, however in these 26 documents nothing was repeated, unless there was a specific reason why it needed to be.

There’s now only 15 documents per project. More efficient? Well that’s quite subjective because it used to have a risk register, issue register, quality register, lessons log and daily log. Now there’s only one project log, but it includes risks, issues, quality, lessons, informal information (still called a Daily Log) and a product log. (Isn’t that more? Yes!)

In the previous version there were five management approaches to create too, one describing how we should manage risk, one for managing quality, another for change control, yet another for managing communication, and finally how to manage benefits.

They are all still there but change control is now called issue management and there’s a new one for change management, which is different from change control, there’s also one for sustainability; the delivery methods used and another for the management of information and data. That’s now nine approaches.

A quick glance at Appendix A gives the impression that the number of documents is reduced, but it is just as comprehensive and has in fact increased in number, they have however simplified the content of most of them, presumably because most project managers didn’t create them anyway.

There’s still seven of everything, seven principles underpinning each project, seven processes to follow and the seven themes are now called seven practices. All of these are now put into the project’s context, usually via a customer supplier relationship but not always. This context was introduced in previous versions but not as explicitly as the new edition.

Each of the seven practices, like the previously described themes, are still referenced and described, but the new edition doesn’t attempt to replicate any techniques that could be found elsewhere.

Work breakdown structures have been added to the Organising Practice, whilst Product Based Planning is still at the heart of the Plans Practice.

There is a change that surprised me, the Change theme has now been changed to become the Issues Practice. As the practice describes how to deal with issues that seems appropriate.

The previous edition had three types of issue, all negative, now there’s five and one is positive.

The Progress practice now includes the Demming cycle of plan do check act. I really do not understand why, the latest MSP (Programme Management) also fixates on this.

One point I do not like, relates to the Quality Practice, the previous versions suggested that the project manager captures the Customer’s Quality Expectations, these were essential because these affected just about everything, they are still needed, but are now called the User Quality Expectations. Which sounds more positive, the Customer or User?

However the most significant change to the themes relates to the Business Case which now includes the need to include any sustainability targets. The business case is the ideal place for this because if the project is not sustainable then neither is the business case.

The processes are very similar to the previous version. The names are all the same and it flows in exactly the same way, however there are some small differences that should be noted. The main one being that several processes have a new activity, whenever the project manager needs to gain some authorisation from the project board. The activity prepares for this, which should help everyone involved understand what they are actually supposed to do.

Lots of the process activities have been simplified in particular during initiating a project where there’s one activity for creating all the, now nine, management approaches mentioned above. This, however, means that the project manager will need to arrange the order themselves because previously the order was suggested.

There’s one other change that has happened which does puzzle me and that’s the removal of the Change Authority role, it has gone from the project management team structure but is still mentioned in the Issues practice.

I didn’t quit.

Let’s see what the marketplace thinks about the best practice getting better.

For more information see prince2.com