What makes projects succeed? Success on a project only needs three ingredients
- a clear vision and business case for feedback from sponsors and stakeholders,
- tests, serving as an executable specification for feedback from the system as it grows, and
- people ready to act upon that feedback.
How much I like a process or methodology or not, depends on the way it
- does not stand in the way of these principles,
- encourages those principles, or
- ensures that the feedback actually takes place.
I appraised PRINCE2 using these criteria to explain which are the features that make me “love” this method.
Clear focus on business and investment
The business case is the central point PRINCE2 is built around and upon. It captures a product vision in numbers, so that costs and benefits, chances and risks are clear to see and serve as guiding point of all decisions. I call a business case good if it accomplishes two purposes:
- It mitigates fear. The main reason projects fail is people, and the main reason people fail in projects is fear. Fear to make a decision that needs to be made, fear to do the wrong thing although you think it’s the best, or fear to make a mistake and not doing anything to avoid it. A good business case names costs and risks, sets tolerances for errors and learning. Within these tolerances, people are encouraged to make decisions.
- It leaves the details to the people who are doing the work. A good business case is simple. A good business case is short enough that everyone involved in the project actually takes the time to read it. As the business case sets limits of and directions for the project, every person on the project should know all its details to make the best possible decision. Every task on a project should be done by a person who knows exactly for what purpose he or she is doing it and what value that task is expected to produce.
Billions each year are spent on products or product features that are hardly ever used. Projects are continued based on contracts that were negotiated on assumptions long proven wrong. Far too often, the reaction to bad value for money is more money. End-to-end feedback limits the amount of money a project can cost while working in the wrong direction.
Feedback needs to happen on many levels:
- The sponsor needs to get feedback on money spent and value delivered.
- The project manager needs feedback on products or product increments ready for delivery.
- Team members need feedback on the quality of their products and the way they work together.
PRINCE2 ensures this happening through feedback cycles on multiple levels. The sponsor gets feedback at the end of every management phase, the full board (user and supplier representatives, other stakeholders) gives input and guidance for the further development of the product. The project manager gets feedback while defining work packages with the team and receiving product increments when those are finished. The team gets feedback on quality from quality assurance guided by acceptance criteria in the product descriptions. Note that there is no part where it says, “first build, then test afterwards”. It’s perfectly acceptable within PRINCE2 to integrate quality into your work processes as you see fit, a test-first approach would be my preferred way of doing it.
The whole team gives and gets feedback on how they work with lessons learned, though I would wish for a more explicit integration into the periodic processes. I see little value in capturing lessons learned at the end of a project. But, it’s never forbidden to do more than the process asks for!
Another feedback mechanism built into PRINCE2 that I appreciate because it is so very pragmatic is the raising of issues. Issues can be all sorts of things: ideas, concerns, change requests, impediments, bugs… They are treated in a consistent manner and kept at the attention of the project manager, who tracks, resolves or escalates them. Escalation is called for if an issue can not be handled within the agreed tolerances.
Respect for specialists
PRINCE2 does not define technical roles. You are free to organise the team as you see fit, and it is perfectly acceptable if the team organises itself. PRINCE2 defines how to capture what is to be delivered: a growing, continuously more detailed product breakdown structure. That way, you can easily manage the situation where you don’t exactly know in detail what the project will be expected to deliver in the end. A situation that is normal for every interesting project, in my experience. Project manager and team repeatedly agree upon how much will be delivered on a certain date. How you control the actual work and how you actually work, is entirely upon you to decide.
A note on formalism
PRINCE2 can be applied in a project without writing a single document. Surprised? The PRINCE2 manual gives such a vast amount of templates that this fact is easily overlooked. The project (or the organisation) defines the level of formalism and documentation needed. That can lead to a very pragmatic process. I value direct, face-to-face conversation much higher than written (and quickly outdated) documentation. Nevertheless, certain aspects like size of the project, criticality of the system built or organisational culture can lead to certain expectations regarding documentation. Use it wisely.
The perfection game is a small process to gather feedback and improvement suggestions, part of the
core protocols. You’ll easily get the rules from the outcome:
I give PRINCE2 as a project management methodology 7 out of 10 points.
I like about PRINCE2
- that it ensures feedback to sponsors and stakeholders through the business case.
- how the business case gives detailed guidance for decisions made during the project.
- that it encourages incremental learning and building product with a product breakdown structure.
- the way it gives the specialists the responsibility for how the work is done.
- how it motivates a joined agreement between project manager and team on the amount of product built in a management phase in a work package.
- that it gets users, sponsor and supplier at a table to make joint decisions.
- that it embraces change through the definition of tolerances for all important aspects of planning.
- how acceptance criteria are captured in every product description, but that it is flexible on the details of how quality is assured.
To give it 10 points out of 10, I would add
- time boxes, so that management phases are split into iterations of equal duration (or that management phases are of equal length).
- an explicit rule that the outcome of every management phase has to be a potentially shippable product increment.
- the amplification of the lessons learned concept into regular retrospectives of the team.
- state more firmly in the PRINCE2 manual that all the given document templates are but examples of how things can be done. And that PRINCE2™ can be used successfully without a single written document.
My personal view on PRINCE2
You won’t find these arguments in a book on PRINCE2. If you do, tell me about it! From what I gathered over the years from people who had taken Foundation or Practicioner courses, chances are you weren’t told these things in a course, either. If you did, put me in touch with your trainer, I’d be interested to share experiences.
My view of PRINCE2 has been shaped during some ten years of practical application of the method in the field, in a variety of organisations and corporations. I had a multitude of discussions with practicioners about how to use it correctly, what the key benefits were, and where to keep the focus during an implementation. Plus, I compared PRINCE2 to a number of other models I used in practice over the years, namely the German V-Modell and Scrum. I extracted for myself the key distinctions and similarities that ensure the practical, successful application of those models.
This may interest you too:
How does PRINCE2 work?