Introduction

Organizations require working project delivery frameworks to manage their projects of varied complexity, type and size. They want fast delivery of useful business products, whilst also recognizing the need for control, especially over costs, scope, quality and benefit potential. So speed on the one hand, a solution in the other, and governance balanced precariously on the nose! Is this possible?

Yes, to answer my own question, it is possible. Project methods like PRINCE2® have evolved into flexible and tailorable solutions, and agile ways of developing products have matured to provide us with exciting new and flexible options, including useful techniques like stand ups, velocity measurements of team efficiencies, and timeboxing.

Surly we can find ways of adopting the best of both waterfall, and iterative project management approaches.

This is not about being fanatic about either approach, it’s about finding the right practice for certain situations by taking the best of both in a way that makes sense. Die-hard proponents of agile or traditional project methods may feel that this is a dilution of the pure; I’m saying that there is some really good stuff in both areas, so let’s use it for the right, appropriate situations.

The “As is” state of project management

I think we have made considerable progress in maturing our project management capabilities, in the last five years many organizations have implemented “right practice” project methods that are applied quite consistently, are frequently updated and improved. They have backed up their methods with skills development programmes. The take up of PRINCE2 has been instrumental in contributing to this continuous and maturing improvement in the delivery of change, along with the release and take up of tried and tested approaches to Portfolio and Programme management.

If we look at a basic 1 to 5 maturity scale, I expect we will find a rough average position for portfolio management at around 2, programme management at 1.5, and project management at 2, with many organizations moving closer to 3 in project management.

But in spite of our improving capabilities in project management, we still do not deliver the varied types of projects with any consistency.

To understand this dilemma (of getting better, but, well, still not meeting our expectations) we have to look at the product (any product) development process, where results are rarely predictable.  Business change projects are not the performance of a routine set of tasks with a pre-determined outcome; they are empirical rather than defined, and require a level of innovative rather than just ‘process step’ thinking.

Our lessons show this, and Jim Highsmith, an Agile founder, observed that the failure to differentiate between highly uncertain (innovative) and highly certain (defined) project environments causes confusion when measuring project performance.

Let me give you an example from a few years ago, when life and projects were so much simpler;

Building a pyramid 4400 years ago was a simple affair; the scope was something like; a four sided, broad based pointy top shape, 150m tall, hidden front door, some chambers, passages and a booby trap every 30 metres.

The DEFINED scope lead to a simple resource and time based solution, i.e. 2,000,000 blocks x 100,000 slaves = 8 years and the associated cost. So scope, time and cost could be used at the measures, and such were the foundations of future project management laid.

But now we have our empirical projects; inevitably difficult to define accurately at the outset and subject to considerable change throughout their duration. But budget holders still need to be able to control timescale, cost and return on investment and need a framework for project management which will enable them to achieve this. PRINCE2 steps up to the plate here, and contrary to some common thinking, it can drive development in a slick, non bureaucratic way, the trick is in the tailoring, given that it does take considerable experience to do this well.

If only we had more easily adoptable techniques that could deal with the product development work in a more agile way. Let’s see what agile can provide us with.

The “As is” state of Agile project management

Agile approaches have evolved since the mid-1990s as part of a reaction against ‘heavyweight’ methods, perceived to be typified by use of the waterfall model of development. Initially targeted at IT system development, some agile approaches have evolved to address the development of any product.

An Agile method generally promotes incremental development and delivery, including the iterative development of the specifications.

At the extreme end of the scale we have agile approaches that are totally emergent, with very little work done up front, described as No DUF (No Design up Front), a waterfall project method would be “Predictive” with BDUF (Big Design Up-Front), and in the middle, EDUF (Enough Design Up-Front). I know, more acronyms! They do roll of the tongue though.

There seem to be some myths about agile approaches, for example; Agile is a silver bullet solution, with no:

• documentation
• commitment
• plan
• up-front design
• PM, TL or BA
• processes, we just scrum.

Such magic! I’m afraid that all of the above are required, with many fundamentals shared with our more standard approach to project management. The differences of both predictive and convergent approaches will however give us the solution to successful delivery of empirical projects.

Some of the various Agile methods you may be familiar with are:

• Adaptive Software Development (ASD)
• Scrum
• Extreme Programming (XP)
• Crystal
• Feature Driven Development (FDD)
• Dynamic Systems Development Method (DSDM Atern).

I favour the Dynamic Systems Development Method, it’s convergent, and comprises of Agile best practices brought together in a clear and customisable delivery framework. DSDM defines roles at the governance level as well as team level, and includes both user and technical roles. It is a scalable approach to different types and sizes of project.

The fundamental idea behind DSDM is that instead of fixing the amount of functionality in a product, and then adjusting time and resources to reach that functionality, it is better to fix time and resources, and then adjust the amount of functionality accordingly, always with a business value focus.

The rationale for alignment

PRINCE2 is essentially a decision and process based waterfall approach that has matured over the years to become a common standard for projects in 150 countries and over 21,000 organizations. It is particularly strong on project management and project governance, all within a well structured framework with sensible management information flows. It is designed to be tailored, and this is important if we want to bring in additional ‘agility’ style techniques.

DSDM is an agile, iterative and incremental project management framework for business centred change that focuses on team collaboration, stakeholder engagement with early delivery of product, at the agreed cost.

A DSDM project is always on time, this could be the manta of the enthusiasts.

There are similarities between PRINCE2 and DSDM. Both are product and business case focused, have clear roles, appropriate controls, both break planning into increments and address quality. Both point out that planning the detail beyond the foreseeable future is a waste of time and creates a false sense of achievability (DSDM actually says “further than the next few weeks”).

The ease of integrating these two approaches will come from their similarities, the benefits in combining them will come from their differences, or the additions if you like, from adding DSDM to PRINCE2.

How? Or the new “to be”

A summary of some of the key things we should be doing when combining a traditional approach like PRINCE2 with DSDM:

1. Use PRINCE2’s guidance on the hand-over of work to teams, including work packages, and empower the team leaders and their teams to work together to achieve a (incremental) solution.
2. Apply DSDM’s prioritisation approach, accept that the project may de-scope lower-priority features in order to deliver on time and within budget.  Line this up with PRINCE2’s tolerance control for scope, and quality, with no tolerance for cost and time.
3. Discourage the production of a fully-detailed specification of requirements at the project start, rather define high level Product Breakdown Structures and Product Descriptions, with further detail at stage boundaries.
4. Align stages to DSDM plans for incremental delivery of product throughout the project.  The project is “chunked” into small deliverables, managed by small teams, within short timeboxes. Timeboxes can be work packages, grouped into an incremental delivery per stage.
5. Use Project Assurance, but with a light touch, to allow the teams to be self-organising and empowered
6. Get the governance structure right, it is an imperative that the business are very committed to the agile approach, and totally involved.
7. Use the DSDM Project Manager role, with guidance from the PRINCE2 role definition
8. Use the DSDM team roles for those working on the creation, procurement and deployment of the product
9. Augment PRINCE2’s Managing Product Delivery process with the DSDM lifecycle to ensure a prototyping approach, and the incremental DSDM approach to implementation
10. Use DSDM agile techniques for facilitated workshops, stand ups and measures (EVA, Velocity)

Conclusion

Where on time delivery is often more important than having 100% of the functionality and where you may have a team of engineers or developers who exist in a collaborative environment, and could quite easily work in a more flexible, face to face manner to solve complex problems.  DSDM delivers.

Where organizations must demonstrate that they are controlling their projects effectively and giving best value for money, due for example to contractual or cultural issues, PRINCE2 performs.

Since both of these needs often run concurrently, the use of PRINCE2 for its control and DSDM for its agility is a powerful combination, giving you choices on how to run different types of project. So on some occasions you need to run projects with very strong governance.

References

Dorothy Tudor
Keith Richards