Last week, again the same remark I hear soooo often… “There are too many products we have to create according to PRINCE2®. It’s not agile at all. We don’t have time for all of that. We have to manage the project!”.

I do hear and understand this call of so many project managers. But why would PRINCE2® not be agile? Or their teacher did not well explain the concepts of PRINCE2®, or the students didn’t understand the teacher, or for those that didn’t had a teacher, they probably misinterpreted some concepts, or ...

Now, how can I convince project managers that PRINCE2® is agile?

I’m often part of teams in Information Technology (IT), and in these contexts there is quite often the reference to the Agile Manifesto. So why not have a look at it and see if there is a relation we can make with PRINCE2®. Note that the Agile Manifesto is talking about software but for this purpose I will attempt to replace software by products in general and see what we can make of it…

The manifesto in fact is called Manifesto for Agile Software Development. It is available at http://agilemanifesto.org/. The manifesto states the following:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Note the last two lines: the items on the right also contain value…! Some of the persons I’ve spoken tend to forget that part and just drop the right part of the principles…

One by one now:

Individuals and interactions over processes and tools

PRINCE2® indeed contains seven processes: Starting up a Project, Directing a Project, Initiating a Project, Controlling a Stage, Managing Product Delivery, Managing a Stage Boundary, and Closing a Project. In its latest version it also refers to a number of tools and techniques such as investment appraisal techniques, MoSCoW as prioritization technique, a quality review technique, etc.

Concerning the tools and techniques, the PRINCE2® guide clearly states as “What PRINCE2® does not provide”: detailed techniques; it does not reference the use of any tool. Meaning the references to any techniques are for information. We are not obliged to apply each single technique mentioned in the PRINCE2® guide.

About processes, the manual states that “All process activities need to be done”… Correct we have to perform all process activities… But the manual also states that the method must be tailored, a principle stating that there is the correct amount of planning, control, governance, and use of the processes and themes to suit the context of the project.
Individuals and interactions are also considered as very important in PRINCE2®: an entire theme is discussing the what it calls “essential elements of a project’s success”: an effective project management team structure and strategy for communication at the beginning of the project, and maintaining these throughout the project’s life.

A communication management strategy sounds very formal, but isn’t it important that the correct persons are involved at the correct moments in a project? And that we think about who and when that is, and how the communication can best be done? PRINCE2® is not saying that you need a document of 25 pages… It only asks for thinking and agreeing about the stakeholders and how the communication can best be done. And if this is in a daily stand-up meeting, well this is great.

Working software over comprehensive documentation – sorry working products over comprehensive documentation.

PRINCE2® distinguishes two types of products: management products, for being able to manage the project well, and specialist products, which relate to the final product that must be developed.

About the specialist aspects: this is out of scope for PRINCE2®. If you don’t need a functional analysis document for your context/organization, then don’t create one. If you don’t need an architecture overview, then don’t created one.

The management products receive more attention in the PRINCE2® guidance. All activities in the different processes state what is expected as input and as output. Each of these has a good description in the appendices of the guidance. For each of these management products, a purpose, composition, derivation, format and presentation, and quality criteria are provided. Twenty-six (26) management products are described like this; twenty-six! And I say PRINCE2® is agile…

Of course I do, because I tend to apply the tailoring principle pretty often. It’s not saying literally I need 26 documents. In fact PRINCE2® is asking that the information exists in one or another way. Tailoring the management product can mean that we merge certain products (e.g. have all mentioned registers in one Excel file with a column indicating the type – risk, issue, lesson, …), that we have some information only on a whiteboard (please take a picture now and then, you never know who passed by for cleaning the room… and your whiteboard…).

Now specifically about the products (in the agile manifesto “software”), PRINCE2® has an important principle: “Focus On Products”. In summary it says to focus on the definition, delivery, and in particular their quality requirements.

Combining this with the role description of the project manager which states that “the project manager’s prime responsibility is to ensure that the project produces the required products within the specified tolerances”, I feel that working products as mentioned in the agile manifesto are considered pretty important…

Customer collaboration over contract negotiation

PRINCE2® does not talk a lot about contracts. Only when interacting with external teams there is the concept of Work Packages that can take different formats according the required tailoring to make it fit for the project’s context. In some cases the contract negotiation will be more important than in other projects. That’s what tailoring is for: make PRINCE2® fit for purpose.

Customer collaboration receives more attention in the PRINCE2® manual. As part of the theme “Organization”, stakeholder engagement is mentioned as the process of identifying and communicating effectively with those people or groups who have an interest or influence in the project’s outcome. The manual continues by stating that stakeholder engagement “is essential to the project’s success”.

Responding to change over following a plan

Agreed, when people hear PRINCE2®, “plan” is almost a synonym. Not really. There is much more to project management than following a plan. One of these aspects is … guess what … change…

Planning helps the project management team to think ahead. It focusses on detailing the products that are needed for the project (also see ”Working Products over …” above). It’s also about having a global view on a timeline. I’m not talking here that it is crystal clear that a specific person will do a specific task on a specific date. It could be, but only at the very very detailed level of a Team Plan which is only created when the team will almost start doing the work, not months ahead. A typical project plan according to PRINCE2® communicates when specific products, or functionalities, will become available.

The plan provides a baseline to which we can compare progress. Again, the composition and level of detail of the plan can be tailored to your context. And it is important to remember that a deviation from the plan is not necessarily a bad thing for PRINCE2®!

That is why a theme “Change” exists. It describes how project management acts upon issues which have a potential impact on the project. It is nowhere stated that a PRINCE2® project manager should not accept changes. It only asks for thinking about how to deal with changes, any type of change (scope, cost, time,etc.). The PRINCE2® clearly states in the manual that change is inevitable during the life of a project, and that therefore every project needs a systematic approach to managing changes. A change budget can be used giving the project manager some freedom in accepting changes himself. Or maybe the project manager has to go to a change authority – which can be 1 person – your product owner maybe? Or there is no change budget set aside or change authority appointed for the project, which means that as a project manager you go ask for budget/time/resources to the project board for analyzing the impact and if the change is approved to implement it.

 

The manifesto also contains twelve principles. It would take us too long to go over all the 12 principles as we did in the previous paragraphs. But if you read through these principles with the above in mind, and asking the correct questions, I’m sure you will understand that also for these 12 principles, PRINCE2® is not an obstacle but can be implemented in a way that all 12 of the agile principles can be satisfied.

My conclusion after all of this is that PRINCE2® is agile, it are only the implementations in projects that are not agile. But we cannot blame the method itself for that.

PRINCE2® offers all means to strongly value “Individuals and interactions” while also valuing “processes and tools” sufficiently.
PRINCE2® offers all means to strongly value “Working software (products)” while also valuing “documentation” sufficiently.
PRINCE2® offers all means to strongly value “Customer collaboration” while also valuing “contract negotiation” sufficiently.
PRINCE2® offers all means to strongly value “Responding to change” while also valuing “a plan” sufficiently.

So in the near future, if you think or feel that PRINCE2® is not agile, or someone says something similar to you, then think twice … Why would someone say that…???

PRINCE2® is a Registered Trade Mark of the Cabinet Office

Agenda

What others say about us...

“Having worked with Steven on implementation of CMMi and Prince2, I recommend him as a skilled trainer, coach and process designer on project management and software development processes.”

Eric Vermoesen