Specialist in effective change.
Accredited MSP™ and PRINCE2® trainer.
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.
The problem with PRINCE (if it is a problem) is that it mixes product-development methodology with project-management methodology.
It strongly emphasizes Phase-Managers and Hand-overs.
IF you organise a project by "phases", this is fine - but the real question should be: "Is this the best way to organise a project?" - even for a product-development project.
A truly modern approach is to take a "whole-life approach" to product-development. This means that there is ONE PERSON in charge - call him "Project Manager", call him "Programme Manager", call him what you like. And EVERY PROFESSIONAL worker involved should be RESPONSIBLE for his work until all products are de-commissioned.
This means adopting the classic "engineering approach" to the process with a "product-based" (rather than "phase-based") WBS with all that implies.
There are a few problems with this response in terms of basic PRINCE2 understanding. Let’s break it up into the different components.
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.
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 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.
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).
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 was.
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.
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:
Whatever the situation is, PRINCE2 describes that at project closure there should be confirmation that support is in place.
Does this respond to all issues in the LinkedIn reaction? Please let me know and leave a reaction to this post. Thank you!
Ben u als Opdrachtgever verantwoordelijk voor een project?
Bent u opdrachtgever? Vertegenwoordigt u belanghebbenden van een project? Dan is de Workshop Opdrachtgevers voor u een belangrijke bron van informatie. U kunt hier ideeën opdoen hoe u uw rol beter en effectiever kunt invullen.
Would you like to get in touch? Contact me and I will answer your questions, discuss your issues or help you in different ways as soon as I can.