When standard Project Management life-cycles are surprising

A few years ago, I created a project management software package called TrioProject. The package was quite good, but it had a major flaw. It used a Gate process approach, which was good. But it standardised the Gate processes… and to my great surprise, that proved to be a weakness. The standardised life-cycle was the flaw.

It came as a surprise to me, because I've been working on project management standards for decades. It was clear to me that, to improve project management, you need standards. But you have to standardise the right thing. If you over-standardise life-cycles, you are in trouble. I was in trouble.

I'm not the only person to make this mistake. Often, when I talk to PMOs, I discover that they've made the same mistake. I learn that they have a standard life-cycle such as 

• Charter
• Initiate
• Build
• Test
• Deliver and Deploy
• Close

So let's unravel this problem. Where did I go wrong?

A mixture of good and bad ideas

My first good idea was to use a Gate process. The Project is structured as a series of Stages, each separated by a Gate. This is a proven way of working. It splits the project into manageable chunks of work (stages). It allows the project board to control progress (gates).

My second good idea was to standardise the process. In this way, all projects follow the same path. This standardisation enables repetition, which is the basis for continuous improvement.

The flaw - my bad idea - was to over-standardise the process. Every project is different. So a standard life-cycle is overkill. It's a bad idea. The diversity of projects is enormous. In reality, many projects cannot and should not follow a standard process.

When standards become a problem not a solution.

Once you start down the wrong path, standards become a problem not the solution. If every project has to use a standard process then people hit problems:

• The process doesn't fit the project (square peg in a round hole)
• The project manager applies the process blindly, without enough thought

Some companies address these problems by multiplying the number of standards.

• One company used different life-cycles for different sized projects (small, medium, large).
• A building company used 3 standard processes, for construction, renovation and maintenance projects.

But multiple standards only complicate the problem, they don't solve the problem.

Faced with these problems, other companies give up on standard life-cycles.

How to ensure that standards are good news

The answer is not to reject standardisation. Standardisation is the foundation of continuous improvement and better project management.

But standardisation must recognise that each project is different:

• Yes, it's a good idea is to use a Gate process.
• Yes, it's a good idea to standardise the OVERALL process
• BUT it's vital to understand that each project is DIFFERENT

The way to achieve this is to use project design. For each project, the delivery must be designed, not standardised.

Delivery needs to be designed (not standardised)

Each project is different, and each project needs to be designed.

Project design is an early project activity which works out how to deliver the project. The project team works out how many stages are needed, and what those stages are.

That's the big challenge: every project must deliver differently.

During project design, the project team analyses project delivery and structures it appropriately. They understand their unique challenge, and design their unique solution.

So that's the source of the flaw in TrioProject. It was a mistake to over-standardise project delivery. You cannot decide in advance. Delivery should be DESIGNED and NOT STANDARDISED.

A sandwich of standardisation

The resulting standard project management life-cycle is a sandwich

• standardise the early parts of the project
• design delivery (recognising that each project is different)
• standardise the final parts of the project

This still provides the basis for a repeatable life-cycle. It allows for enough standardisation to enable continuous improvement.

Read my recent book to find out more about Project Design; and learn how to design your next project.

Traps to avoid

Before we finish, here is a reminder of the traps to avoid:

• don't standardise the number of delivery stages (for example 3 delivery stages)
• don't standardise the names of delivery stages (for example analysis, build, deployment)

A small project might need only one delivery stage. A larger project might need five delivery stages. A second large project might need five completely different delivery stages.

Build the Project Factory

To sum up, we standardise project management to give a basis of repetition. Standards provide the foundation for continuous improvement and for building a project factory.

But we also recognise that each project is different. We need to reconcile standards and flexibility.

In a forthcoming blog, I'll say more about the Project Factory. Watch this space.