What You Need to Know about Project Management

Fergus O'Connell

• Publisher: Capstone
• Year: 2012
• Print ISBN: 9780857081315
• eBook ISBN: 9780857081605
• Edition: 1
• Topic: Business
• Subtopic: Project Management
• Index: Business

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.

CHAPTER 1

GOAL SETTING

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.

WHO SAID IT

“If one does not know to which port one is sailing, no wind is favourable.”

– Seneca

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:

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

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:

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

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

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

Table of contents

• Cover
• What You Need to Know
• Title page
• Copyright page
• DEDICATION
• INTRODUCTION
• CHAPTER 1: GOAL SETTING
• CHAPTER 2: ESTIMATING
• CHAPTER 3: SUPPLY AND DEMAND
• CHAPTER 4: MANAGING RISK
• CHAPTER 5: MANAGING EXPECTATIONS
• CHAPTER 6: TRACKING AND STATUS REPORTING
• CHAPTER 7: RUNNING MULTIPLE PROJECTS
• CHAPTER 8: HAVING A LIFE
• ACKNOWLEDGEMENTS
• Index