Can PRINCE2 project management and Agile complement each other?

Is PRINCE2 and iterative development (such as big 'A' Agile) friend or foe?

 

As a rule, opinions are generally polarised between those who have been sold Agile as the panacea that will inoculate projects from failure or those dismissing it as a dogmatic fad that is a recipe for chaos, cost overrun, flaky products and subsequent failure. You may have a positive view of Agile benefits but this agility, without more robust governance, may be a bridge too far for decision-makers accountable for funding.

When evaluating a project approach, consider the benefits of the middle path - nobody need be right or wrong, why can't we all just get along!

To start, think about the responsive and continuous improvement benefits of Agile coupled with the governance, greater predictability of scope, schedule and cost and risk management that are part of full scale project management? What gaps would exist in the rigour of your approach, and what problems exist with picking a winner if you try to go only one way or another?

My answer to the question whether project management and Agile development methodology could be complementary approaches is an emphatic yes. Having worked with a range of hybrid and purist project approaches, what is clear is nothing is perfect and the application and implementation of each dependent upon some key principles.

To many stakeholders, a project may appear to have more safeguards in place when using only PRINCE2 than only Agile. Agile specialises in reacting to change, PRINCE2 however has preventative measures as well as flexibility. Agile-only may be fine in incubator scenarios with a high risk appetite and fewer implications if the project fails or may not need to go past proof of concept. Besides the approach you choose yourself, if you have been using a software development vendor then there is every likelihood that your project has been leveraging a flavour of big ‘A’ or small ‘a’ agile or iterative practices for the deliverables already.

Agile is not, nor tries to be, project management in the sense PRINCE2 methodology does. As such there is no conflict in maintaining the controls, such as organisational risk management approaches, that the PM, PMO or other process owners wish to deploy whilst doing Agile delivery. It may come as a surprise if you are not familiar with PRINCE2 or assume it is a full waterfall approach, but it allows complete freedom for the way work packages are completed. There is only the need for sufficient acceptance or quality criteria to be available when the work package assigned for suppliers to build the product fit-for-purpose which sounds more than a bit like test driven development.

What is a very real selling point for using Agile within structured project management is that the Agile sprint and release cycle (often 2 and 6 week intervals respectively) provides neat boundaries for delivering encapsulated functionality,and consequently you have ready made work package milestones at consistent 6 week intervals. With experienced Agile teams, your work package milestones come complete with frequent 2 week checkpoints, and the team delivering the work already works with a discipline that instills this structured behaviour.  

 
So what are the benefits of a hybrid process. Firstly, it’s definitely true Agile enables your project to get moving faster and cheaper than a waterfall approach, but the key issue here with our blog subject and this notion is that project management equals waterfall. PRINCE2 does not state that all requirements must be identified and documented in detail before execution commences, just enough is known to describe the product breakdown (scope) delivery to meet your constraints to the required level of quality. Similarly the quality plan to manage acceptance criteria is described upfront, but not the quality of the PBS. (you can read further thoughts about developing your own hybrid process here). 

You don’t need to look too far to see the benefits and application of Agile practices. In large corporations or small or mid-size companies, stand-ups physical and virtual (or flavours thereof) are now a highly valued practice. Story and/or task cards can be found in non-Agile value management and project environments and collaborative work practices centered around the empowered self organising team is rapidly taking over from the hierarchical management pyramid (whilst not initiated by Agile are a key tenet of the practice). Best of all, Agile instills an ethos of continuous improvement and provides the mechanisms for acting on change through retrospectives. That everyone in the team is capable of identifying and initiating change should be one of the greatest motivators for a PM to embrace Agile philosophy. 

Probably the greatest issue with Agile is the emphasis on just in time (JIT) progress through discovery and a lack of direct emphasis on the business case. JIT is great in reducing waste through effort and documentation that may end up being unnecessary, but advance planning can also save exponential effort and a balance of the two delivers predictability and an efficient outcome. Value and benefits tend to be more granular, which is perfect for a development methodology but not sufficient for a project which requires constant review and or update of the business case to ensure that the solution provides the long term forecast benefits to be realised. The concept of failing early and cheaply is fine if it’s due to issues with the original concept or validity of the problem being solved, and not poor planning or thinking.

Between the benefits, there are also some core pillars of the purist Agile manifesto I strongly disagree with.Firstly, unless the change is a relatively small enhancement piece of work, I believe do document and contract. Have the business enunciate clear expectations the project and delivery team will be committing to, and make this contract with your sponsor via signed-off documentation and then set about making good the outcomes those on the project are being paid to deliver. This protects the project as much as the customer so it is clear when the project has realised its goals and helps prevent scope creep. Documentation does not have to mean hefty wads of text, but it must be fit-for-purpose for downstream consumers responsible and accountable for approving business decisions, designs, and operate, support and maintain the product. 

Similarly, all projects have the option to change course at any time should the internal or external environment change -  changes that do not exceed tolerances (and therefore the business case) can be made quickly by the PM and having both sides of the equation go through at least some form of change control process an impact assessment encourages the requester to stop and think and often has the benefit of filtering the more whimsical wants rather than needs. Outside tolerances the Project Board review and approval process does not have to be lengthy, but the larger the project the additional oversight of senior business representatives is well justified. 

The structured thinking required to elicit, agree and document at least some of the work at a high level, conceding Agile themes and epics also fulfill this, helps with contextualising the approach and the degree to which the project will solve the business problem. Iterative, RAD or Agile approaches have delivered indisputable benefits to business, PMO and PM domains, saving time by preventing documenting in too much detail or too far out for artefacts that will invariably become partially redundant across all but the smallest projects. These efficiencies extend beyond the obvious example of reducing, or removing the need for, full upfront requirements specification. Agility has allowed PM's and teams to seize the moment and act on momentum.  

For PM's new to agility, investigate those components on the critical path with the greatest variance between the upper and lower ‘guestimations’ or estimations of lowest confidence, until you can make a meaningful enough estimation and then accommodate the worst case into your planning. Don’t wait to know everything before starting, but be able to explain why, and what safeguards you have put in place, so your stakeholders are happy with the approach and confident proceeding. 

At the end of the day it’s about outcomes, quality and most of all customer satisfaction and if you see a hybrid approach being the greatest chance of protecting the business investment, I hope this article assists your endeavours.