Über die Autorin bzw. den Autor

Fergus O’Connell is the founder of ETP (etpint.com), one of the world’s leading programme and project management companies, and his experience covers projects around the world.

Von der hinteren Coverseite

What You Need to Know About Project Management

Project Management is all about getting things done without spending too much or taking too long. But when you start hearing things like man-days, PSOs and stakeholders, it just makes it difficult to understand.

So what do you really need to know about project management?

Find out:

• Why setting clear goals matters
• How to estimate absolutely everything.
• How to get things back on track after they've gone wrong
• How to track big projects
• Why work/life balance matters when you're running a big project

This clear and simple approach will mean you'll never panic when faced with a big project again.

Read More in the Want You Need to Know Series and Get to Speed on the Essentials... Fast.

Auszug. © Genehmigter Nachdruck. Alle Rechte vorbehalten.

What You Need to Know about Project Management

John Wiley & Sons

Chapter One

WHAT IT'S ALL ABOUT

* The big problem in project management

* The magic line – what to say when you get handed a project and what not to say

* Setting a clear goal.

* Controlling changes to the goal

* Maximising the win-conditions of the stakeholders

* The definition of a successful project

* The way to set SMART goals

* When to consider something a project

THE BIG PROBLEM IN PROJECT MANAGEMENT

Why is it that so many projects that we see, read about or get involved in, go wrong? In my experience, the number one reason for this is that they were never actually possible in the first place. You see, project management is actually the most difficult job in the world. This is because in project management, we get asked to make a prediction of the future (a plan) and then make the prediction come true (execute the plan). If you could actually do that each time, you probably wouldn't be reading this book. Indeed I probably wouldn't have written it. Instead I'd be spending my time at the race track or in casinos or buying lottery tickets – if I could predict the future and have it come true.

If that wasn't bad enough, we often get asked to make these predictions in a very strange way. Imagine if your car was acting up. You take it to the garage and say: 'I don't know what's wrong with my car, but I need you to fix it in the next half hour and I'll give you fifty pounds/ euros/dollars for it.' It would be a strange thing to say. But imagine the mechanic in the garage simply responded with 'sure'. That would surely be much stranger. And half an hour later, as you drive your car out of the forecourt having given him the fifty pounds, you'd be wondering what he'd done to your car and whether he had, in fact, done anything. Of course, we couldn't imagine such a silly scenario in a garage.

However, in a lot of the projects that we get handed, such conversations are almost routine. Somebody says, 'Here's the project. I don't know much about it. But it's got to be done by this date for this budget. You can't hire any more people and good luck with that.'

It's important to realise that when you're given a project, you're actually given two things. There is the project itself, for example the 2012 Olympic Games, and then there are the constraints. Constraints are things like:

* it has to be done by a certain date;

* or within a certain budget;

* or with certain resources;

* or the scope of the project has already been decided;

* or some combination of these.

If you try to deal with the project and the constraints together, you're potentially going to get yourself into a lot of trouble. Because as you think about the project, you think about all the stuff you're going to have to do and all the time that's going to take. But the constraints are telling you that you're not going to be given that time. And you're probably thinking that you are going to need four, five, possibly six people to do this project. Other constraints are telling you that you'll lucky to get a man and a dog to work on it.

This book will talk about the reasons why projects fail. As I've already said, the number one reason that they fail is that they were never actually possible in the first place. Somebody said, 'Here's the project and here are the constraints' and everybody said, 'Sure'. So the first thing you need to know when you get handed a project is the Magic Line.

THE MAGIC LINE

When somebody hands you a project, the last thing on earth you should say is 'sure'. Instead you need to say, 'I'll take a look at it.' Somebody comes running in to you and says here it is and they need an answer right now. You say, 'I'll take a look at it'. Somebody's at a meeting, jumping up and down, banging the table and saying, 'I need to know now'. You say, 'I'll take a look at it. Let's take a time out so that I can do that.' Somebody says, 'The greatest of all bosses needs an answer by four o'clock today.' You say, 'I'm going to have to take a look at it.'

It's the only reasonable and sensible answer when you're given a project.

And in a million other normal trades, industries and professions, this is exactly what happens. Because when you do take your car to the garage and say, 'I don't know what's wrong with my car ...', they don't say 'sure'. They say, 'I'll take a look at it.' And the guy does exactly that. He lifts the bonnet or pokes around under the car and then tells you what's possible and what's not possible. You may be waving your 50 euros but if they say to you, 'Listen mate, you've got three choices. You can get a reconditioned engine, you can get a new engine, or you can go and talk to sales about a new car', then you have some decisions to make.

This idea of an examination first to bring up the options, followed by a plan of action is standard in most normal trades, industries and professions. It's the right thing to do. It's also the right thing to do on projects.

Once you've said, 'I'll take a look at it', it means that you can park the constraints while you try to understand what the project is all about. The first thing you have to do then is to figure out the goal of the project. There's nothing too surprising about that. There are three issues that you must address here and they're all big project killers if you don't get them right.

1. THE GOAL OF THE PROJECT MUST BE CLEAR AND NOT VAGUE

You must put a sort of boundary around the project. You then clarify that the things within the boundary are part of the project while the things outside the boundary are not. You may have heard of 'in scope' (within the boundary) and 'out of scope' (outside the boundary).

So:

* In scope: The project will do these things. It will bring these benefits. It will have these features. It will deliver these deliverables.

* Out of scope: The project will not do these things. They are parts of other projects or initiatives or systems. They're not part of your thing.

If you succeed in fixing this boundary, think of it like this – a box:

[ILLUSTRATION OMITTED]

If you fail to fix this boundary then it would be drawn like this – a cloud:

[ILLUSTRATION OMITTED]

The problem with projects whose goal is 'cloudy' is that they can't finish. They can't finish because they don't know what 'finish' is. With the clear (boxed) goal, it's almost like the items within the box form a checklist. When all of these things are done, then the project is done. With the cloud we can't say that and then what will happen is the following.

This is what the team will deliver:

[ILLUSTRATION OMITTED]

But the boss will say, 'This is what I was expecting.'

[ILLUSTRATION OMITTED]

And the customer will say, 'I thought we were getting this.'

[ILLUSTRATION OMITTED]

And the resulting gaps in expectations will cause a lot of unhappiness to a lot of people.

We don't have to look too far to find projects where this has been a problem. There was the movie Waterworld which had an initial budget of $100 million and ended up costing twice that. This was a film where they were rewriting the script (the definition of the goal of the project) while they were shooting the film. Or take the London Stock Exchange's (in)famous TAURUS project which has become a classic case study in project failure.

TAURUS (Transfer and Automated Registration of Uncertificated Stock) was an IT project at the LSE designed to result in paperless trading and computerised shareholding. The main aim of Taurus was to reduce costs and the time taken to process share transactions. The project was started in the mid 1980's and was finally scrapped in 1993 at a cost of about 800 million. The main reason for its failure was that the scope (goal) of the project was never fixed and so continued to expand over the life of the project.

After the project was cancelled and the recriminations began, one simple statement – from amongst a plethora issued by the Stock Exchange – told the story. 'We were testing parts of the system, while other parts hadn't been designed or built' [my italics]. A cloudy goal? You said it.

So, your goal has to be clear, not vague. We have to have boxes, not clouds.

2. YOU MUST CONTROL CHANGES TO THE GOAL

Let's say you succeed in boxing off your goal and then you start the project. What happens then? Well, what happens then is that changes start happening. Here's something they should have told you about but they didn't. Here's something you should have seen but you missed it. Here's a change in say, the business or the regulatory climate – something, for example, that your competitors have done that you're going to have to respond to.

And there's no problem with any of this – after all, the rate of change in the 21st century has become a cliché so we're going to have to get used to this – provided you control the changes that occur. You can't let them happen in an uncontrolled sort of way.

Because here's the next big mistake that project managers make. They assume that because they've committed to a plan/budget/schedule/deadline/resourcing for a certain project scope, i.e. a certain set of things in the box, these must remain unchanged even if scope changes. Here's a simple example to show that this is ridiculous.

Let's say that the project you're asked to do is to 'make a container for water'. After some discussions with the customer, you understand that what they want is a glass – cylindrical, made of glass, a certain height, diameter, etc. Okay, you start the project. Now it turns out, once the project gets rolling that that wasn't really what the customer wanted. They wanted a jug. A jug is also a container for water. But it's a more complicated piece of engineering than a glass. The plan/budget/schedule/ deadline/resourcing to make a jug is not the plan/ budget/schedule/deadline/resourcing to make a glass. And if you're not convinced of that, a swimming pool is also a container for water. The plan for a glass is not the plan for a swimming pool! But many project managers fall into the trap of thinking that since they committed to certain targets for the glass, they must deliver the swimming pool to the same targets. If you think of the glass and the swimming pool you can see how ridiculous this is.

So then we have to ask the question, 'How could project managers be so stupid?' 'How could usually intelligent and educated people do something so dumb?' The answer lies in the expression, 'the customer is always right'. And yes, the customer is always right. The people for whom we're doing the project can change their minds in any way they want. But every time they change their minds, there's a price associated with that. There's a price in terms of time, money, resources – and controlling the changes means that we tell them the price. Some prices may be trivial – maybe they want the glass two millimetres wider in diameter and we can say, 'yep, no problem.' But some prices aren't trivial. The price of 'we don't want a glass, we want a swimming pool' is not trivial. We have to tell them the change in price.

So when changes occur on the project, as they invariably will, you have to know what to do. You'll be able to deal with some changes yourself, without bothering the people for whom you're doing the project. But for some changes you'll absolutely have to go back to these people. You need to make the right choices here. You need to know when to do one and when to do the other.

CHANGE CONTROL – ANOTHER WAY TO LOOK AT IT

If a change occurs on your project – it can be a small change like 'Charlie's gone sick for the day' or a big change like 'we don't want a glass, we want a swimming pool' – then there are three (and only three) ways you can deal with that change:

Big change

The first is you can say that this is a big change. The fancy term is a 'change to the project's terms of reference' or a 'change control event'. Some changes are like that, where what we are now being asked to do is significantly different from what we were originally doing.

Use contingency

Now, of course, lots of changes are not big changes. They're little slip-ups. Because Charlie does go sick for the day, the server goes down, a supplier lets us down, or something simple turns out to be complicated – the thousand little things that are sent to try us. For these we need to have contingency in the plan. It's perhaps worth remembering the following. Think of it as the Project Manager's Prayer. It goes like this:

    'Unexpected stuff happens on projects.
    Most of it is bad unexpected stuff.
    Sometimes I get a lucky break,
    But mostly, it is bad unexpected stuff.
    For this I need to have contingency in the plan.'

You do! You need to have contingency in your plan.

'Suck it up'

Finally then, if something is a big change, you might not have the guts to say that to the people for whom you're doing the project. And if there's no contingency in the plan, either because you never put it in, or you did, but then some genius took it out, then there's only one other possible way of dealing with changes. To put it bluntly – that is to suck it up! Suck it up means work nights, work weekends, bring work home with you, tell your significant others that you won't be home tonight or you can't take your holidays during the project and so on.

Let's be clear. There is nothing intrinsically wrong with sucking it up. If you accept the basic idea that project management is about predicting the future, then there may be times when you do have to suck it up – to hit a deadline, meet a milestone, solve a customer problem. No problem with that. But if sucking it up is the only thing you do when changes occur then that's a huge problem.

On a healthy project there may be times when you shout, 'Big change!', there may be times when you have to use your contingency, and then there may be times when you have to suck it up. No problem with that. That's a healthy project. An unhealthy project is where every change is dealt with by sucking it up. Most of us have experienced such projects. They're not fun.

3. YOU MUST MAXIMISE THE WIN-CONDITIONS OF THE STAKEHOLDERS

You've boxed off your goal. You now know that you must control changes, i.e. make the right choice from the three possibilities when changes occur. The third and final thing you must do when goal setting is to maximise the win-conditions of the stakeholders. It may sound like a terrible piece of management waffle, but it's actually a useful phrase.

The stakeholders are the people with a stake in the project. More specifically, they are the individuals or groups of people affected by the project. Individuals can be stakeholders – Fergus is a stakeholder, for example or Ellen is a stakeholder – or a group of people can be a stakeholder. For example, all of your organisation's customers could be a stakeholder or the body that regulates your industry could be a stakeholder. Generally speaking, some stakeholders are more important than others. You might, for example, see your boss as being a more important stakeholder than a supplier.

We tend to think of the obvious stakeholders – me, my team, my boss, the customer. But if we throw the net a bit wider, think a bit more carefully, we can come up with other stakeholders. There may be people in other departments of our organisation or people in other organisations. The test is – are they affected by the project? If they are in any way, whether positively or negatively, then they are a stakeholder in the project.

One particular stakeholder that you may come across is the one known as the 'project sponsor' – a term that is particularly popular in the UK. The project sponsor is generally a fairly senior person in the organisation who (a) sees a need for the project and (b) is responsible to the business for the success of it. In almost all cases, the project sponsor is not the project manager.

Also it's worth mentioning that there is no correlation between the size of the project and the number of stakeholders. Small projects can have a large number of stakeholders or vice versa. It just varies.

Each stakeholder then, has win-conditions. Win-conditions are what that particular stakeholder would regard as a successful outcome to the project. In general, different stakeholders have different win-conditions. Often win-conditions can be pulling in opposite directions. For example, if I'm the boss who has given the troops the impossible deadline, then maybe one of my win-conditions is that the troops hit the deadline. If, on the other hand, I'm a team member who has been working burnout hours for the last twelve months, then maybe my win-condition is that I just want to work a forty-hour week. Also since some stakeholders are more important than others, we will tend to treat some win-conditions as being more important than others.

(Continues...)

Excerpted from What You Need to Know about Project Managementby Fergus O'Connell Copyright © 2011 by John Wiley & Sons, Ltd. Excerpted by permission of John Wiley & Sons. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.