Several PRINCE2 Issues

In a LinkedIn discussion about my paper about PRINCE2 and the Waterfall approach I received the following response that I would like to discuss here.

There are a few problems with this response in terms of basic PRINCE2 understanding. Let’s break it up into the different components.

One person in charge?

First of all, there should be One Person in charge, according to this reaction. Obviously, there is something like that. PRINCE2 in fact has two different owner roles. The Executive is the owner of the Business Case and in that way accountable for the entire investment. Not just during the project, but also for the whole lifecycle of the products. In fact, the “Whole Life approach” is the reason for the Principle of Continuous Justification, as described in the Business Case Theme. This is also explained in a paper on this website.

On the other hand, there is (are) the owner of the developed product(s): the Senior User(s). This role is accountable for the realisation of benefits (a part of the Business Case) and therefor accountable for the (definition of the) quality of those products. The benefits are realized (mostly) after the project, so also here is taken care of the “whole lifecycle” aspect.

In a relatively simple project, the roles of Executive and Senior User can and maybe should be combined.

Phases, Phase-Managers and subsequent hand-overs?

“PRINCE (…) mixes product-development methodology with project-management methodology”?

No, not at all. As stated in the reaction the writer assumed that the PRINCE2 stages are technical stages as in a product-development methodology. This not the case, as the PRINCE2-Waterfall paper already explained. PRINCE2 discusses Management Stages and does not “mix product-development methodology with project-management methodology”. In fact, the assumption is that the approach is suitable for project of any type, which a development method could never be. In teams under a Team Manager different products can be developed using the product-development approach suitable for that team and the product that will be developed in that team.

A further indication of this argument is the name of the Team Manager’s process: Managing Product Delivery.

The role of Team Manager is an optional role. If the project is relatively small and simple, there may not be a Team Manager with the Project Manager managing the team directly.

Phase-Managers and hand-overs?

Phase-Managers do not exist. There is only the Project Manager, managing every Management Stage of the project. So there also will not be a hand-over between Management Stages.

Apart from what was already explained before, there may be only two Management Stages: Initiation and one stage in which the work is done. Obviously, the work can be organized in several stages, whatever the project demands. That is a control- and risk-based decision.

Adopting the classic "engineering approach" to the process with a "product-based" (rather than "phase-based") WBS?

Not sure what this part of the reaction indicates. One of the PRINCE2 principles is a focus on products, not on work. So PRINCE2 is Product Based which is completely different to Worked Based (WBS).

Every professional worker involved should be responsible for his work until all products are de-commissioned?

I cannot see how this is practically possible. Products could be decommissioned years after their development. How could an individual be responsible for his work for all this time? But maybe that was not what the meaning of the statement.

In reality project-people (developers) and maintenance -people are very different and come from very different cultures. That is why ITIL-trainers usually make very poor PRINCE2-trainers and real PRINCE2-trainers are not interested at all to become ITIL-trainers.

Project-people are looking forward and want to achieve change. Maintenance-people look at the status-quo and at the past and look for stability.

In general, Project-people do not like Maintenance-people because they are bureaucratic, procedural and rigid. Mainly because of ITIL-trainer poorly delivering PRINCE2, the approach has its bureaucratic reputation. This is often called PINO: PRINCE In Name Only.

On the other hand, Maintenance-people do not like Project-People. They are seen as chaotic, unreliable and not following the procedures.

Another aspect of this discussion is that PRINCE2 is a Customer’s approach. This is why there is an emphasis on the Business Case and why the Business Executive is ultimately accountable. Traditionally in the Supplier’s approach however, many people still believe that the success of a project is determined by its delivery, so at the end of a project. This is often a main reason why technical project managers (Suppliers!), mainly IT-specialists, usually also make poor PRINCE2 specialists/trainers. In PRINCE2 terms they are at the most Team Managers and do not really understand the relevance of the Business Case, the Executive and the focus on Products. They are often another source of PINO. In another paper of this website, this issue is discussed.

So, there are different cultures at work here. That should always be taken seriously.

Hand-over from the project for service and maintenance?

The answer to this question was already partly described in my paper about PRINCE2 and SLA’s. Later in the 2009 version, PRINCE2 also discussed another part of this issue.

In general, there are two possibilities:

  1. The organisation represented by the Senior Supplier will also be responsible for maintenance and technical support after the project.
    In this case one of the products the project will deliver should be a contract often called a Service Level Agreement (SLA).
    This situation was described in my paper about PRINCE2 and SLA’s.
  2. In case an organisation not supplying to the project will take the responsibility for maintenance and (technical) support after the project, this organisation should be represented in the project by a Senior User. The project should in this situation deliver products to prepare and support hand-over to this organisation and their Senior User should be made responsible for the definition of the required quality and acceptance of those products.
    This situation is roughly described in the 2009 version of PRINCE2.

Whatever the situation is, PRINCE2 describes that at project closure there should be confirmation that support is in place.

Other question or issues?

Does this respond to all issues in the LinkedIn reaction? Please let me know and leave a reaction to this post. Thank you!

About the author

Specialist in effective change.

APMG accredited MSP™ and PRINCE2® trainer.

comments powered by Disqus