Project Management in Practice

Beyond the alphabet soup of PRINCE2, MSP, MoP, PMBOK, ITIL, Agile

Is agile and PRINCE2 compatible?

My project management experience is in the field of software development. I deal daily with developers that espouse the value of agile development methodologies. Having come from a development background myself, I am skeptical about all that is said about agile. In saying that, I do see some benefits – especially the first principle of continuous and incremental delivery of software. However, a question arises … is PRINCE2 compatible with such methodologies, and vice versa.

For subsequent post on use of Agile and PRINCE2 together refer to this.

Let us quickly review the highlights of the agile manifesto

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

Now let us consider the realities of bespoke software development. The project cycle starts with your organization given a set of requirements from a client and you having to provide an estimate to deliver to the requirements. As soon as you commit to a fixed price, scope and duration, there is effectively no room for agile. Depending on feedback, you cannot adjust the behaviour of the application – you will likely blow price, scope or duration – most likely all of them.

In PRINCE2, there is emphasis on the business case being continually evaluated to ensure the outcome is still desirable. PRINCE2 is also very process oriented – as evidenced by the 7 processes. It cannot therefore accept the first principle of agile development. There must be a process that states the requirements and any changes to the baselines and their impact. This can then be evaluated by the project board to evaluate whether the project is still desirable.

Working software over comprehensive documentation is a dangerous prospect in my opinion. Whenever there is squeeze on project time, documentation is usually the first casualty. This may produce working software at the time; however, it adds untold grief once it has been delivered. Anyone maintaining the system, whether it be your support team, the client’s IT team, or a third party will come to regret it. While I never enjoyed documentation as a developer, I learned to live with it as a necessity of quality work.

Responding to change is often trumpeted as a major gain of agile approach. Self organizing teams are put forward as a strong productivity source and one that can do away with a traditional project manager. These however do not take into account the inter-relationships between the projects, ability to analyze the impact of the changes to baseline, ability to hand over to an IT organization from project to Business As Usual (BAU).

One striking similarity between agile and PRINCE2 is how both treat the planning horizon. Both recognize that you can only plan so far in advance. Agile approaches do it by planning sprint content, PRINCE2 does it by planning by the stages. In that respect, there is some compatibility between the two. I see great value in utilizing some of the agile principles during the development phase of the project. Once I as a project manager assign the work package to the development team leader, if they use agile techniques to deliver within their tolerance levels, who am I to object?

PRINCE2 makes a distinction between the management products of a project and the specialized ones. Development of software here is a specialized product and therefore not specifically included in PRINCE2. Beyond the delivery stage of the project, I do not see agile meeting the requirements and expectations of executives and management to contract development services for a fixed fee.

In comparison, ITIL is probably more aligned to agile approach – especially during service operation stage. Once software is delivered into BAU, there is a continuous requirement to keep it running in an optimal mode, include additional functionality or evolve with the changing requirements of the organization. A programme of work can be created with continuous service improvement goals.

Tailoring is what makes or breaks your PRINCE2 project. Make sure you tailor it to suit your requirements. Pick from agile methodologies what you want and in which stages. Do not get locked into a specific one. When used, go more by the principles of agile manifesto, rather than a prescribed, particular method.

13 responses to “Is agile and PRINCE2 compatible?

  1. Daniel Elroi March 29, 2011 at 9:39 am

    Methodical comparison, thanks. I would find this article more useful, however, if terms like PRINCE2, ITIL, BAU were defined (by link is fine). Not being a Porject Management Professional myself, I found myself a little lost on occasion.

    Other than that I found this to be a severe condemnation of Agile Development, but not being familiar with PRINCE2 and ITIL, I would have to defer an opinion, especially given than in my world, clients rarely come with a ready-made set of specific requirements.

    • Shoaib Ahmed March 29, 2011 at 10:35 am

      Appreciate your comments Daniel. I disagree slightly about the article being condemnation of agile development. I approached the topic from a PRINCE2 perspective and one where the contracting model is still a fixed for for a project of fixed deliverables – how agile can you really get? My view is you take parts of the manifesto, not all.

      A more agile development is also a valid approach for a product development team or as I point out, one that has a continuous service improvement mandate through adopting an ITIL methodology. I take your point about explaining the terms more. I’ll add some links.

  2. Pingback: How do I forecast resource requirements in Project Server? « Project Management and PRINCE2 in Practice

  3. Pingback: How do I forecast resource requirements in Project Server? » GeoBLOGtastic

  4. Pingback: PRINCE2, ITIL, Agile … can I have the best of all? « Project Management and PRINCE2 in Practice

  5. Pingback: Can you manage all projects through PRINCE2 or Agile? « Project Management and PRINCE2 in Practice

  6. Steve Ash July 25, 2012 at 1:02 am

    I find the article to be absolute balderdash!

    it is a typical opinion of someone who thinks that everything in the Prince2 manual is mandatory and gospel!

    Prince 2 is meant to be configured; the specific practices are there as a ‘ if you don’t have anything in place at the moment, try this’.

    There are 3 toleances in Prince2 – time cost and quality (ie requirements). If you wish to get into a commercial arrangement where time, cost and requirements are all fixed, then you run the biggest risk I know of failure – Prince2 says nothing about fixed anything and by purporting that it does, you do a disservice to Prince2, yourself and your organisation!

    • Shoaib Ahmed July 25, 2012 at 10:32 am

      Take a deep breath Steve. I have not suggested Prince2 has everything fixed. In fact, as you point out Prince2 works on tolerances. 6 not 3 – cost, time-scale, quality, scope, risk and benefits. This goes very well for the organisation that is the running the project.

      If you read carefully, the fixed I’m talking about is the scenario of a supplier entering into a service contract with the customer on the basis of a set of given requirements. Opinions evolve over time. Have a read of some of my other posts on customising Prince2 to include ITIL and agile practices.

      Prince2 is a project management framework, Agile is a product development framework. They are complementary, not a substitute.

      • Alexandre Cuva December 1, 2012 at 6:10 am

        I nearly agree with Steve, but let be more constructive :

        By the way Agile is not a product development framework, Agile define how we should consider when building a product. Example Scrum practice is Product Management practice.

        Agile Manifesto never said there are no Process & Tools, he only said the left side is more important than the right side. So the first value Collaboration & Communication vs Process & Tool. Scrum has process too.

        You said “In PRINCE2, there is emphasis on the business case being continually evaluated to ensure the outcome is still desirable”, so I have a bad news for you Agile said the same in the 1st to 3rd principle. Agile doesn’t define who make the decision, but we prefer that is a decision between the customer and the team. Normally the Project Board is made with customers, sponsor…

        You said “Working software over comprehensive documentation is a dangerous prospect in my opinion”. Sorry again, but we didn’t said don’t do documentation, we said do only documentation that it is updated. In your example, if the documentation is not updated with the last update, it will be really no use to anyone. If we look in the eXtreme Programming (XP) practice, the developer write code documentation, while designing the application. It is another reason why TDD is good, he document the code.

        Your argument about the Request of Change have nothing to do with Agile, If you think your current process work and accept changes, then keep it. But we recommend to inspect and adapt continuously.

        Then the rest of the article is your opinion, but in my opinion, RFP Agile project are great, the customer have more control in what it is delivered. You should read more about subject like “Money for nothing”, who explain how to use agile with fixed price.

        If you want more insight about using Scrum with Prince2, I recommend read the white paper about Hermes and Scrum ( – sorry there are no english translation), Hermes is free Project Management framework used in Luxembourg and Switzerland. Otherwise look how AUP work, in my opinion is the Agile practice the nearest to Prince2.

        As said already, even if Agile was made first for development project, it is not anymore true. Scrum practice is used in different sector for different product like (Marketing, Mechanic, Concept, Electric component, Bio medical…)


      • Shoaib Ahmed December 1, 2012 at 5:20 pm

        Thanks Alexandre. Good points you make. Agree entirely, in right environments Agile methods work really well. Challenges I have sometime is with procurement methods in some organisations make it really hard to implement effectively.

  7. Randall Erickson January 3, 2013 at 9:21 pm

    ere must be a process that states the requirements and any changes to the baselines and their impact. This can then be evaluated by the project board to evaluate whether the project is still desirable.

  8. Pingback: Web Seminar Recap: Agile Certifications Options Primer | The ASPE SDLC Blog

  9. Budesh Rai October 27, 2013 at 9:03 pm

    This is very much unclear to me, you have mentioned the projects commence with your organisation giving you a set of requirements…but isn’t there any method or techniques to analyse requirements under PRINCE2 method….if there is please explain it to me or forward me the links…thanks

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: