Getting Agile & PRINCE2 to play along

Erwin van der Koogh bio photo By Erwin van der Koogh Comment

So you are working in or with an organisation that is using PRINCE2 to manage projects and would prefer to use something more lightweight and agile? This post is for you. Most people assume they are polar opposites, but in fact they can work together fairly well.
I have used the techniques described below to drive significant changes in very large financial organisations. So it might work for you too.

But first a disclaimer: Organisations where PRINCE2 is in heavy use tend to like things like control, efficiency and predictability. PRINCE stands for PRojects IN Controlled Environments. Not necessarily the best attitude for an truly agile environment.
Changing those mindsets is not going to be easy. In fact it is probably going to be hard and take a lot of energy. You are also most likely not going turn it into an agile organisation like Github or Spotify, certainly not in the short term. But that said, you can certainly improve the effectiveness of the organisation and have a dramatic impact on the lives of the people working there.You might also find that Prince2 actually helps you think through big organisation realities like stakeholders, risk, business cases and management, which not many agile methodologies do.

Your mission, should you choose to accept it, is to work with instead of against process owners to introduce more agility in the process.

The Problem

Prince2 has a reputation for being a bloated, bureaucratic project methodology more interested in status updates than in achieving outcomes. This is only partially deserved. As we will see later Prince2 is quite flexible to adapt, but most organisations choose not to use it. It shares some of those problems with RUP (Rational Unified Process) in that you are supposed to adapt it to your organisation and project, but most organisations use everything for every project.
I have seen Project Delivery Frameworks with almost 200 different types of templates; a large portion of which were mandatory for all projects.

The Approach

Step 1: Find allies

You are probably not going to change this by yourself. Find as many project managers that are up for something different and if possible someone in what they probably call the PMO (Project Management Office).

Step 2: Getting to the Why

This is one of the most important steps. Why do they use Prince2? Their answers will almost certainly contain ‘reduce risk’ and ‘control’, but possibly others as well. This is extremely important. Whatever you do to sell any changes you want to make has to address these issues. Which is great, because most agile methodologies are perfectly suited to deal with them.

Step 3: Remind them Prince2 is adaptable

And more importantly, should be adapted. Not many organisations do that though. They have defined the way to do projects and have probably supported that with half pre filled templates. Your first job is to convince them that those templates are just to help the average project, but that we can always change the process to the needs of the project.

There are two ways in which Prince2 is adaptable. The first one is Embedding. This is changing it to suit the organisation you are in. Let’s forget about this for now. But there is also Tailoring, adapting the process to suit your particular project. Is it a large project with tight deadlines and many stakeholders, or a small project with clearly defined outcomes?

Step 4: Start with a PID

First step is to find a project to try out a different way of working. Ideally we have a fairly safe to fail project. Not so much because we are expecting to fail, but because it is an easier sell. It also makes it less likely the project will fail for reasons outside of our control.

Now the important thing to do is to start with the Project Initiation Document. One of the things you do here is describe the process you are going to be using during the rest of the project. The important thing to remember here is use their jargon, not whatever flavour of agile you are proposing.

PRINCE2 Delivery Model

Here are some tips:

Stage

A project is divided up in multiple stages. Now most waterfall projects define a stage as the next step in a waterfall. So the first stage is analysis, then development, then testing etc.. Instead there is nothing stopping you from defining your stage as an iteration or a sprint. A week or two worth of work.

Manage Stage Boundaries

How do you manage stage boundaries? By showing what we have done to stakeholders, evaluate how we have worked over the past stage and prepare for the next. Sound familiar?

Update the Business Case

Also part of managing of a stage boundary is updating the business case. Bring that updated business case to the Project Steer Group whenever you send in a status report. It should reflect everything we finished & learned so far. Now most projects will never update their business case, even though they are supposed to. So get them used to not only seeing what has been done, but also what is still ahead and how that has changed with the new information we learned during the project.

Maybe we can show the work that is left to do as a big ordered list..

This is where you need a project manager that doesn’t do watermelon reporting: Red on the inside, green on the outside.

Step 5: Slim down the upfront Business Case

In traditional Prince2 projects a lot of time was probably spend on those initial business cases that were hardly ever changed. Now that you got them used to changing business cases it is time to get them to slim down the business case phase.

There are a couple of important items you will want to change:

Less precision, more accuracy

When we encounter precision it is very easy for us humans to confuse it with accuracy. If someone says it will take 38.5 days we have more confidence in it than when someone says it till take about 40 days. The underlying data for both could be exactly the same.

It is much more beneficial to stay more high level overall and focus much more on the risky areas. Dan North calls it Deliberate Discovery.

Work with ranges

When writing a business case we are working with estimates. Estimates of both the benefits and the costs. It is hard for some people to grasp, but those are guesses. So work with ranges and possibly a confidence level. Don’t say it will take 3 months to do the project, but between 2 to 5 months. Some people will push back and insist they need more precision. But if the difference between deciding to do a project is a few months it is likely an indication the project isn’t worth doing in the first place.

Keep it updated

As mentioned above, keep updating those business cases over the course of the project. It will get more detailed over the course of the project.

Step 6: Embed it

Once you have done a few projects it is time to take it to the next level and embed it into the organisation. Takes all of the learnings you had in your projects and write that up. Don’t fall into the trap to define a lot of the how to do things.

Voila

Congratulations, you have just made a huge first step to making your organisation more agile. Next areas of focus can either be getting rid of projects altogether and go for continuous flow or integrating your IT organisations more into the business areas.