The Project Lifecycle

One of the leading lights in project management thinking, Professor Peter Morris, once observed that “The life cycle is the only thing that uniquely distinguishes projects from non-projects”¹. In some quarters of the project management community the idea of a life cycle has become something of a bête noire. It is often treated as synonymous with the use of the so called ‘waterfall’ approach to project management, which simply demonstrates a misunderstanding of what project management actually is.

Let’s start by considering the fundamental principles of the simplest of project (and programme) lifecycles.

Most organisations have more ideas for projects than the resources they have to deliver them. That’s good – it means the organisation is innovative and progressive rather than complacent and stagnant. The trick is to identify the best ideas that can be effectively delivered with the resources available. Initial weeding out of ideas may well be done at portfolio level but the essence of a good start to the project life cycle is to assess the value of a project in one or two initial phases of the life cycle.

Before describing these two phases (or whether they should be combined), I just need to talk about ‘agility’. All projects need to be managed with agility – the crucial question is ‘how much agility is appropriate?’. The answer to this question is primarily focused on two characteristics of the project: ‘predictability’ and ‘cost of change’.

Predictability is about how well we can design the objectives of the project at the start. If we are building a bridge of known span with a known weight-carrying capacity then this is highly predictable. We have the knowledge to fully design this output before we start to build (deliver) it. It is also worth noting that the cost of change is very high once work has started. If the foundations and pillars have been built, you can’t suddenly decide that you want it to carry heavy good trains instead of just pedestrians.

In contrast if we are developing an App, we know the top level customer problems that we want it to address but anticipating exactly how our potential customers will want their problems solved is much harder to predict. We cannot define the finished product up front and will need to develop iteratively, while constantly working with customer representatives to see whether what we have delivered is what they want. This context has the added advantage of having a much lower cost of change than the bridge. Component features are much less interdependent that the components of a bridge. They can be added, removed or changed independently, provided the underlying architecture was designed with this flexibility in mind.

So how does this relate to the life cycle?

Where predictability is high we don’t need so much agility, where predictability is low (or perhaps simply less desirable) we need high levels of agility. In the ‘lower agility’ environment, design work is focused on the first two phases of the cycle. In the ‘higher agility’ environment, design is also spread throughout the delivery phase.

Designing a bridge is an expensive piece of work in its own right so it makes sense to do this in two stages. A ‘quick look’ may produce outline designs (e.g. should it be a suspension bridge or a cable stayed bridge?) and will also plan the ‘detailed look’ so that whoever is providing the funding knows what they have to commit to for completing the detailed design in the next phase.

A lot of the design work of an App will be done during the delivery phase so the first two phases may be combined. It’s still necessary to do some outline scope management to judge whether the whole project is likely to be affordable, fits the organisation’s strategy and is within its appetite for risk, but all that can be done in a combined initial phase.

A key component of a lifecycle is decision gates between phases. These are simply there to avid the “I’ve started so I’ll finish” attitude that has led to so many doomed projects not being terminated as soon as their non-viability becomes apparent. A gated lifecycle is another thing much hated by those who see it as a barrier to high levels of agility. It is no barrier. It’s simply an escape route to avoid a poorly conceived project and no level of agility can save such an endeavour.

The incorrect assumption is that gates can only exist when the focus is on up-front design. That is simply not the case. The criteria that are used to review the project at each gate should be consistent with the level of agility being applied.

Finally, another defining character of a project is that is uses a temporary team that will be disbanded when the objectives have been met and handed over to the customer. This is done in the ‘close’ phase.

Once again, some people who work in contexts where high agility is appropriate advocate #noprojects² and argue that everything should be a ‘product’. That’s fine, if you want to only have ‘products’ where the team that starts the work is permanent and will carry on developing it until it is decommissioned or ‘sunsetted’, that’s fine. You gain is some ways and lose in others. Just because you don’t want to manage a piece of work as a project doesn’t mean projects shouldn’t exist. In fact the development aspect of product management contains mostly the same concepts as project management (risk management, stakeholder management, planning etc.) – it just chooses to apply them in a business as usual context that doesn’t have the governance based on the project life cycle.

So I think Professor Morris was right. It is the life cycle that fundamentally separates projects and programmes from business as usual.