The top myths about PRINCE2® and agile methods

This is just one of many misconceptions about PRINCE2, while “myths” also affect the agile world. As the new PRINCE2 Agile guidance becomes available, it’s worth addressing some of those myths.

1. “PRINCE2 is document-driven and bureaucratic.”

This is not the case; it gives you the information to communicate throughout the entire project and reports in document format are not necessary in every context. Some Project Managers implementing PRINCE2 are completing template documents without knowing why, when the goal should be to discuss, collaborate and pass on the key project information.

Often, documentation created contains neither the project objectives nor a realistic project plan whereas shorter, bullet-pointed work can give just enough clarity to the project. The principle of tailoring and focusing on results is more important than internal requests to provide “all the documentation”.

2. “The focus of PRINCE2 is the triple constraint.”

Should we deliver a project that stays within time, cost, scope and quality or deliver something the business can use and that makes the customer happy?

Yes, you have to be mindful of the constraints, but you have to challenge them. Doing so will help the business open its eyes and recognize which constraints are more or less important. Always keep one thing in mind: in the end a solution which solves the business problem must be delivered.

3. “PRINCE2 is command and control.”

No! Project Managers should be asking teams to deliver work packages in whatever way the team feels is right. More traditional Project Managers are getting too immersed in detailed estimates as project boards want accurate estimates from the start for complex projects. This is unrealistic, we need to consider our planning horizon, in other words how far into the future can we plan and be accurate.

Here, the concept of tolerances is crucial: the project boards give flexibility to tackle unforeseen issues allowing them to manage their constraints. Project boards need to be educated about that, otherwise expectations towards the project team are too high.

1. “Agile = scrum.”

Agile is not scrum! Scrum is great for certain things but is not the same as agile project management; it’s a product development method, not a project management, framework.

It works best with mature products for which new features are released periodically; however, doing something like moving from a Java to a .Net product is just too big for scrum. Previously, I was encouraged to use scrum as a project management framework; but it lacked important elements, for example how to involve other stakeholders and maintain a business case.

The training I’ve provided for Scrum Masters has usually ended with them being convinced that PRINCE2 could help them with everything outside of product development such as setting up clear project governance.

2. “There’s no need for Project Managers in agile – the team will do everything!”

This tends to play out differently than they think! For example, if change requests require other resources, budget, and time for the release, this isn’t something the team en masse can decide, nor does it have the authority.

Without Project Managers they are stuck: how do they involve all stakeholders and communicate with the entire business? How do they involve and inform unions? The proposed change(s) often fail without a Project Manager.

3. “There’s no architecture required.”

One of the first agile projects I was involved with didn’t get off the ground. The problem: no real concept of the solution. However, once the key architect in the company provided the team with a vision for the technical solution, it was up and running in six months.

You cannot head into the solution just based on agile and without the basic architecture in place. Doing that will inevitably mean having to re-factor way too many core and complex things.

There’s been an over-confidence in agile circles about the ability to re-factor and make changes during the development of the solution; it takes too much re-work and is unlikely to meet the objective of the solution. With no architecture, agile cannot be relied upon as that one silver bullet.

PRINCE2 Agile goes a long way to cancel out each approach’s misconceptions about the other and is, in my view, something every Project Manager should do.

The PRINCE2 framework is very strong but, equally, Project Managers should dare to open up their minds and add agile techniques into the framework through the tailoring principle. If it’s not clear how something in PRINCE2 would work for a project, then they can turn to agile principles. Likewise, agile practitioners can introduce PRINCE2 to their approach.

And what you end up with, in PRINCE2 Agile, is a machine gun filled with silver bullets.

For more information, see our PRINCE2 Agile section.

Have you used both PRINCE2 and agile methods when managing projects? Do Stephen Deneir's experiences as related in this blog relate to your own findings? Please tell us your thoughts about this post or how you have used PRINCE2 and agile in your professional life.