Mega Projects

Articles
By Steve Messenger | 6 May 2015

I find the concept “Mega Project” confusing. What is it supposed to mean? 

Large? – In scope? In time?  In resource?

Complex?

Business transformation? 

All of the above?

In fact I don't believe in mega projects.  Some are business transformations, which are actually programmes consisting of a series of projects and enablement activities.  Others are simply large projects that can be decomposed into manageable increments.  Like most things in life it depends on the way you tackle them.

Let’s examine the two cases in turn. 

Business Transformations

Agile Programme Structure GraphicBusiness Transformations normally move an organisation from one organisational state (where it is now) to a new state (where it wants to be) and deliver benefits, or value to the organisation.  Such transformations often involve many aspects of the organisation and will normally require changes to business processes, organisational hierarchies, business architectures and culture as well as introducing new technology and systems.  They can take years to get to the final, desired state.

So how can Agile help with this? 

The trick is to examine the programme sufficiently at the start to understand how we can deliver value incrementally – moving the organisation closer to its ultimate goal in small steps.  This not only provides benefit early but allows us to learn from the experience so far, and from the feedback of those parts already enabled. 

“Step” is a relative term here as each step will involve a number of projects and activities and the resources and skills required between steps may be vastly different.  Taking a stepwise approach also allows us to change course as, inevitably, things change around us and what we thought when we set out becomes outdated or invalid.  We can also stop if we’ve done enough or if it no longer makes sense to continue.  Project and activity teams can then be empowered to deliver their part of the transformation, although the structure allows both agile and more traditional approaches to delivery.

All of this is explained very well in the DSDM Agile Programme Management guidance.

 “Large Projects”

DSDM Team Model GraphicSo what if our mega project is not a Business Transformation but merely something that will take a lot of time and / or resource?

Using an Agile Project Management approach can really help us here.  We start by understanding the problem enough (and no more) to be able to determine subsets that can be delivered separately, often in parallel and potentially by separate teams. 

Once delivered, we can almost forget about them and move forward with the next piece.  “Delivered” is a subjective term as we may not always be able to deliver into the live organisation (although this is the preferred option as the organisation can start to get benefit from the project) but at least we know everyone is happy with what has been done.  This approach also allows us to understand inter-dependencies between teams and to build team and project role structures than span the whole project and do not require constant “stand ups” at different levels.  We can then let the teams determine how to deliver their part of the project, but within the constraints of inter-dependencies and the wider project architecture and goals.  Often, taking this approach will actually demonstrate that the step-wise approach is faster than trying to do too much at once with a large number of separate teams.

The DSDM Agile Project Framework describes this process very well.

So when tackling so-called mega projects, I always refer to Einstein

Everything should be made as simple as possible, but not simpler

Published: Project Manager Today May 2015 issue