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.)

5. There must be one leader.

Wondering what your roles and responsibilities are as a project manager? Look no further than this https://www.youtube.com/watch?v=ZxVCrIMPQXI.

6. It’s all about supply and demand.

Like many things in life, project management can be thought of as a problem in Supply and Demand.

Demand is the work to be done. Supply is the people to do that work.

Let’s say you’ve estimated your project to be 100 person-days (PD). Thus, Demand = 100 PD. For your project to succeed, an equivalent number of PD has to be available to do that work. Supply = 100 PD. The two numbers have to be the same. Simple as that.

Except …

… for two things:

The Demand tends to go up – for example, because stakeholders ask for extra things, or maybe assumed they were getting more things, or maybe you underestimated the Demand.

And then you get the worst of both worlds because as the Demand tends to go up, the Supply tends to go down – because, you never quite get the resources you expected / were promised, or somebody was on our project part-time when you thought they’d be full-time, or they were meant to start this week but they’re tied up in another project, or whatever.

If these two number go out of balance your project will start to drift.

If they stay out of balance your project will crash and burn.

So … do you know what these two numbers are on your project?

6. It’s [still] all about supply and demand.

In last week’s post I talked about the idea of Demand and Supply in a project management context. Demand was the amount of work to be done on your project, Supply was the people who were going to do that work.

A key consideration when trying to calculate Supply is people’s availability. Availability is related to multitasking. Obviously, the more multitasking someone does, the less they are available.

Multitasking is not just bad for productivity – it’s catastrophic, as the following simple example shows.

Say there’s a 10 person-day [PD] job to be done. Somebody is available to do it and they’re full time – 5 days per week [dpw], The job will take two weeks. Now, suppose that same person is only available 1 dpw because they’re multitasking. Now the job will take at least ten weeks. And this is not allowing for the effect of ‘put down pick up’ which will increase this ten weeks even further.

There’s a better way than multitasking i.e. where a pool of people is spread across, and works on a series of projects / activities. We’ll talk about that in a future post.

But for today, if you want to know your (or someone else’s) real availability download and try out our Availability Calculator https://lnkd.in/e5hywT4a

I hope it doesn’t depress you for the rest of the day!

7. If things can go wrong they probably will.

Repeat after me:

• Unexpected stuff happens on projects.
• Most of it is bad unexpected stuff.
• Sometimes, I get a lucky break.
• But – mostly – it’s bad unexpected stuff.

This is why you need to:

1. Have Contingency [aka a buffer] in the plan, because we know bad things are going to happen; and
2. Do Risk Management – to try and stop some of those bad things from happening.

8. It’s possible to deal with impossible projects and irrational stakeholders

Here’s the scenario: Your plan says that the project is impossible but the project stakeholders keep insisting on it anyway.

What do you do?

This subject is a bit too large to be dealt with in a short post – you can find the full story here https://fastprojects.org/the-twelve-pillars-of-successful-projects-2-day-workshop/ – but two things need to be said.

First, no matter who you’re dealing with – how important, senior, more experienced, whether you’re in a sales situation or not – you can get a result that solves the stakeholders’ business problem, but also solves your problem as a project manager i.e. that the project has some chance of success as opposed to a project that never had any chance of success.

Second, this is all down to you, the project manager, and your behaviour. You may argue to the contrary – that it’s the culture of the organisation or the personalities of the people you’re dealing with or that you have no choice, or whatever …

But you’d be wrong.

This is entirely in your hands.

And it’s not ‘learning to say “no”’ or ‘pushing back’.

It’s called ‘negotiation using the facts.’ You’ll find it here: https://fastprojects.org/the-twelve-pillars-of-successful-projects-2-day-workshop/.

9. But you’ve got to use an appropriate leadership style.

These two pages are taken from my book, Leadership Lessons from the Race to the South Pole: Why Amundsen Lived and Scott Died .

10. Know what’s going on.

Here https://www.amazon.co.uk/Project-Management-Book-successful-projects/dp/1912555042/ref=asap_bc?ie=UTF8 and on this https://fastprojects.org/the-twelve-pillars-of-successful-projects-2-day-workshop/ we tell you how to track your project, and to do so with the least amount of effort – an idea that we call ‘The Lazy Project Manager’.

But a related question is how often should you track your project and update the plan?

You’ll find the answer here.

Daily? You could. If the project is short and massively important to the organisation then you’d better do it every day. You need to spend those days wisely.

But what if you’re overloaded – have too much to do and not enough time to do it? Ok, so do it every other day – Monday, Wednesday, Friday.

Or twice a week – Monday and Thursday mornings.

Or once a week.

Obviously, the less often you do it is good, in terms of use of your time, but bad because your early-warning system is getting wider and wider. Tracking Daily, means that it’s at most 24 hours before you pick up there’s a problem. Doing it once a week could mean something drifting for a week before you start to deal with it.

But, better than any of these is that it depends. It depends on things like:

• The duration of the project – short or long.
• The criticality of the project – – massively important or nice to have / who cares kind of project.
• The team working on the project – a bunch of grizzled veterans or a team of rookies or something in between.
• Whether you have good luck or bad luck on the project.
• Etc.

So, here’s the answer to the ‘’how often’ question:

For the first few weeks, if you could do it daily, that would be really good. If you’ve ever worked on a well-run project, one of the things you’ll remember is a sense of calm / order / routine. Tracking the project every day is a good way of establishing that sense of calm / order / routine. The team know that they’re in good hands with you – that you know what you’re doing. (Especially good if you haven’t worked with them before.) But they also know that you’re like a strict referee – if something happens, you’re on to it like a shot.

Once the team got used to that tight discipline, you could relax it a bit – maybe go to every second day or twice a week.

If things got a bit sloppy, you could tighten it up again i.e. track it more often.

If you ran into some bad luck you could go back to daily. If you ran into some good luck you might leave things as they are. Then, when you’re entering the closing stages, when you’re literally running out of time, you might go back to doing it daily again.

11. Tell people what’s going on.

A project was meant to finish on September 21 of a particular year, and it actually finished on November 29 of that same year. Simple question – was it:

• A success.
• A failure.
• Don’t know?

Decide for yourself before you read on.

The answer, of course, is that we don’t know. The two-month difference could have been:

• The result of a series of changes to the scope of the project, agreed with the stakeholders – Success.
• A slip – Failure.

We don’t know. There’s not enough information. There’s no history of how we got to be where we are.

And it’s this history of how we got to be where we are that tends to be missing from almost every status report I’ve ever seen.

With no history, somebody looks at these two bald dates and – pretty much always – assumes the worst. There’s been a slip!

This is particularly true on long projects or projects where there is a change of personnel on the stakeholder / customer side.

So:

1 As I’ve said in numerous other places many times before – send out a status report once a week. Friday afternoon is a good time.

2 Be sure to include a change history in the report – here’s how the end date [and budget and effort, if you’re tracking these] have changed over the life of the project. It’ll keep you safe from marauding stakeholders and customers.

12. Do it better next time.

Read all about it here.