The 12 Pillars

The 12 Pillars

Whether you use Agile, Waterfall, Spiral, PRINCE2 or something else, there are certain unchanging things that you have to take account if your project is to succeed.

Over the next 12 weeks I’m going to write about these things – there are twelve of them. This week, we talk about the first one:

  1. We can’t deliver clouds, we can only deliver boxes.

It’s probably true to say that every project starts out as a cloud. ‘Wouldn’t it be great if there was a tunnel under the sea that connected England with France,’ for example.

But eventually, for such a project to succeed, this cloud has to be replaced by a box. ‘It’s going to be a certain type of tunnel, for this kind of traffic, follow this particular route, be of these dimensions, made of these materials and so on and so on.

Boxes and clouds. It sounds like the kind of thing you might teach to four-year olds in kindergarten. It seems so completely obvious. So nobody could possibly get this one wrong, could they? Well, maybe a four-year-old could be forgiven, but certainly no educated, intelligent adult.

Hmmm. Ever hear of Brexit?

We project managers can’t deliver clouds, we can only deliver boxes. It’s the first principle of project success.

2. Things will change over the project’s lifetime.

In my project management work I constantly hear people complaining about how someone – typically, a boss / customer / stakeholder – ‘changed the goalposts’ during the project.

Come on people, be serious!

Of course things are going to change over the life of the project – for all sorts of reasons. People change their minds. They come up with a better idea. They find out something they didn’t or couldn’t have known before. There’s some new technology. Whatever.

The question is not whether you think this is ‘fair’ or not. The fact is it’s going to happen anyway – whether you like it or not. The real question is – what are you going to do about it?

Happily, this problem has a simple solution.

There are only ever three courses of action open to you when changes occur on your project:

  1. Say, ‘Hey, that’s a big change’ – meaning that some aspect of the plan is going to have to change. This could mean changes to the scope, the delivery date, the cost / resourcing, the quality or any combination of these.
  2. Use the contingency in your plan to deal with the change. This assumes that you were smart enough to put contingency in in the first place and you didn’t let some idiot take it out when the project was being negotiated / agreed.
  3. Suck it up. Work more – nights, weekends. Spend more of your own money on the project.

On a healthy project, all three options are used. This is a project with proper change control.

On an unhealthy project only option #3 is used. If you ever worked on such a project the thing you’ll probably remember is that it wasn’t much fun.

Thins will change over the life of the project – better get used to it!

3. We need to maximise the win-conditions of the stakeholders

What is a ‘successful project’ anyway? Hits the deadline? Comes in within the budget? Meets the requirements of the stakeholders?

If you want it in two words, a successful project is ‘happy stakeholders’. You tell them what they’re going to get from the project – and that’s what they get.

So the first steps towards happy stakeholders are to:

  1. Find out what’s going to make them happy.
  2. Don’t assume that you know.
  3. Don’t assume it’s the same for every stakeholder.
  4. Get it in writing.

When I teach The Twelve Pillars of Successful Projects – 2 Day Workshop, almost the first thing I do is to ask the participants what they hope to get from the Workshop. The question I actually ask is ‘What would be the best possible outcome from the Workshop from your point of view’. To give it its fancy name – ‘what are your win-conditions?’

When I get the answers back, what’s remarkable is how different the win-conditions are. This is on a tiny 2-day project that’s very tightly defined [very ‘boxy’ – see Pillar #1].

If win-conditions could be that different on a tiny project, that I’ve done many, many times before, that’s very tightly defined, imagine how different they can be on a big project, that you’ve never done before, that isn’t so tightly defined?

And one final point. Finding out near the end of a project that your win-conditions aren’t going to be met, when all along you thought they were – well, that’s not gonna get you happy stakeholders.

4. The devil is in the detail

There’s an exercise we do on The 12 Pillars of Successful Projects – 2 Day Workshop, where we ask attendees to estimate a simple task.

The scenario is this: There is a list of tasks that have to be done to complete a project. One of those tasks is to review a document. So the exercise is to “give a time estimate for the task, ‘Review document’”.

Before you read on maybe you’d like to write down an answer yourself?

On a good day we’ll get answers ranging from 30 minutes to a week – a factor of 80 between the highest and lowest (assuming a 40-hour week). On a bad day? Well, I’ve seen factors of 1,440!

What this exercise highlights is the #1 problem in project management – namely, that planning and executing a project requires us to make a prediction and then have that prediction come true. None of us can actually do this. If we could we’d be down at the race track or spending out nights in casinos or buying lottery tickets.

At the heart of this problem of making a prediction is the ability to estimate correctly.

And at the heart of that problem is detail.

On The 12 Pillars of Successful Projects – 2 Day Workshop, and if you just want to get the project done successfully, we show the correct level of detail you have to get to.

We then go on to show the additional detail required if you want to shorten your project / shorten time to market. (The extra work involved here can produce some remarkable results in terms of shortening.)