What You Need to Know about Project Management E-Book

Fergus O'Connell

• Herausgeber: John Wiley & Sons
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 234

Veröffentlichungsjahr: 2012

Beschreibung

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.

Leseprobe

Table of Contents

Cover

What You Need to Know

Title page

Copyright page

DEDICATION

INTRODUCTION

CHAPTER 1: GOAL SETTING

THE BIG PROBLEM IN PROJECT MANAGEMENT

THE MAGIC LINE

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

2. YOU MUST CONTROL CHANGES TO THE GOAL

CHANGE CONTROL – ANOTHER WAY TO LOOK AT IT

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

THE DEFINITION OF A SUCCESSFUL PROJECT?

SMART GOALS

GOAL SETTING GIVES YOU THE MOTIVATION TO DO THE PROJECT

WHEN TO CONSIDER SOMETHING A PROJECT

CHAPTER 2: ESTIMATING

NOW THAT YOU HAVE A GOAL, YOU HAVE TO HAVE A PLAN

HOW TO PREDICT THE FUTURE

DURATION AND WORK

THE BUDGET

ASSUMPTIONS

GANTT CHARTS

SOME USEFUL APPROXIMATIONS

CRITICAL PATH

HOW MUCH PROJECT MANAGEMENT DOES THE PROJECT NEED?

PROJECT MANAGEMENT METHODOLOGIES

PROJECT MANAGEMENT TOOLS

CHAPTER 3: SUPPLY AND DEMAND

PROJECT MANAGEMENT IS A PROBLEM IN SUPPLY AND DEMAND

1. EVERY JOB MUST HAVE SOMEBODY TO DO IT

2. AVAILABILITY – THE SILENT KILLER OF PROJECTS

DANCE CARDS

3. PLAYING TO THE STRENGTHS (AND NOT PLAYING TO THE WEAKNESSES!) OF THE TEAM

WHAT YOU’VE ACHIEVED

CHAPTER 4: MANAGING RISK

CONTINGENCY AND RISK ANALYSIS

CONTINGENCY – WHY YOU NEED IT

CONTINGENCY – HIDDEN VS. EXPLICIT/HOW MUCH AND HOW

CONTINGENCY USING WHAT THE PROJECT IS DELIVERING

CONTINGENCY USING ‘WHEN’

RISK ANALYSIS

ASSESSING A PROJECT IN FIVE MINUTES

MEASURING THE PSI

INTERPRETING PSI SCORES

CHAPTER 5: MANAGING EXPECTATIONS

MAKING COMMITMENTS TO STAKEHOLDERS

COMING UP WITH OPTIONS

NEGOTIATION USING THE FACTS

IMPOSSIBLE MISSIONS AND HOW TO DEAL WITH THEM

WHAT HAPPENS WHEN YOU SAY YES TO IMPOSSIBLE MISSIONS

SHORTENING PROJECTS

CHAPTER 6: TRACKING AND STATUS REPORTING

USING THE PLAN AS INSTRUMENTATION TO DRIVE THE PROJECT

MANAGING PEOPLE

USING DIFFERENT MANAGEMENT STYLES

DEALING WITH PROBLEM PEOPLE/SITUATIONS

THE PROJECT MANAGER’S DAILY ROUTINE

HOW YOU NEED TO DO IT – STATUS REPORTING

PROJECT POST-MORTEMS

THE DIRTY DOZEN – THE TWELVE MOST COMMON REASONS WHY PROJECTS FAIL

RESCUING PROJECTS THAT HAVE GOTTEN INTO TROUBLE

CHAPTER 7: RUNNING MULTIPLE PROJECTS

THE IMMUTABLE LAWS OF PROJECT MANAGEMENT

PRIORITISING

DEFINING MULTIPLE PROJECTS

THE ISSUES WHEN RUNNING MULTIPLE PROJECTS

CAREERS IN PROJECT MANAGEMENT

WHAT MAKES A GOOD PROJECT MANAGER?

CHAPTER 8: HAVING A LIFE

WHY IT’S OKAY TO HAVE A LIFE

WHY BETTER TIME MANAGEMENT IS NOT THE ANSWER

EXTREME TIME MANAGEMENT

THE SECRET TO HAVING A LIFE – THE THREE FILTERS

ACKNOWLEDGEMENTS

Index

This is the stuff you’ve always been embarrassed to ask about the world of modern business.

The What You Need to Know … books can get you up to speed on a core business subject fast. Whether it’s for a new job, a new responsibility, or a meeting with someone you need to impress, these books will give you what you need to get by as someone who knows what they’re talking about.

Each book contains:

What It’s all About – a summary of key pointsWho You Need to Know – the basics about the key playersWho Said It – quotes from key figuresHow You Need to Do it – key steps to put your new-found knowledge into practiceWhat You Need to Read – books and online resources if you want to deepen your knowledgeIf You Only Remember One Thing – a one-liner of the most important information

You might also want to know:

What You Need to Know about BusinessWhat You Need to Know about EconomicsWhat You Need to Know about StrategyWhat You Need to Know about LeadershipWhat You Need to Know about Marketing

This edition first published 2011

© 2011 Fergus O’Connell

Registered office

Capstone Publishing Ltd. (A Wiley Company), The Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ, United Kingdom

For details of our global editorial offices, for customer services and for information about how to apply for permission to reuse the copyright material in this book please see our website at www.wiley.com.

The right of the author to be identified as the author of this work has been asserted in accordance with the Copyright, Designs and Patents Act 1988.

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, except as permitted by the UK Copyright, Designs and Patents Act 1988, without the prior permission of the publisher.

Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books.

Designations used by companies to distinguish their products are often claimed as trademarks. All brand names and product names used in this book are trade names, service marks, trademarks or registered trademarks of their respective owners. The publisher is not associated with any product or vendor mentioned in this book. This publication is designed to provide accurate and authoritative information in regard to the subject matter covered. It is sold on the understanding that the publisher is not engaged in rendering professional services. If professional advice or other expert assistance is required, the services of a competent professional should be sought.

Library of Congress Cataloguing-in-Publication Data

9780857081315 (paperback), 9780857081469 (ebook),

9780857081605 (epub), 9780857081612 (emobi)

A catalogue record for this book is available from the British Library.

For Davida Irene Hulse

INTRODUCTION

This book will be of immense value to you if any of the following six situations apply to you:

One. You’re new to project management. It will tell you exactly what you have to do to plan, execute and bring a project to a successful conclusion.

Two. Your boss has just called you into his office, handed you a pile of stuff and told you that you’re going to be leading the Poison Chalice project. Oh, and by the way, it’s got to be done by the end of year, and the budget’s already been fixed and you can’t hire any more people. This book will tell you what to do (and what not to do) next. It will you show that – depending on what your next move is – you could actually consign the project to disaster there and then.

Three. You’re tired of fire fighting/late hours/nasty surprises and would like to find a better way to get your work done.

Four. You’ve ever been handed what appears to be (or definitely is) an impossible project.

Five. You’re an experienced project manager. The book is a full-bodied refresher and checklist of the key things required to make a project successful. It will remind you of these key things, some of which you may have either forgotten or not realised the full significance of.

And finally – six – have you ever had this happen to you? Somebody comes running in to you and says, ‘This should only take an hour or two’ and two years later you’re still working on it. If you have then this book is for you.

The book covers everything you need to know about project management in eight chapters called:

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.

The first six chapters take you through everything you need to know to run a project from start to finish. They can (and should) be read sequentially as they take you, step-by-step, through what you need to do. Once you have these six chapters under your belt, Chapter 7 builds on that knowledge by telling you how to run more than one project at the same time. Finally, there seems to be a view in the world that project managers are people who should just work all the hours God sends to get projects done. Chapter 8 shows you how you can be a successful project manager and still have a life.

Each chapter has a number of common elements. The guts of each chapter explain exactly what you have to do and why you have to do it. Then there are some other dead useful things:

What It’s All About – A quick summary at the start of each chapter listing the key messages that will be covered.Who You Need to Know – Key figures you need to know in project management. These will either be people who have shaped the discipline of project management or are/were great project managers from whom you can learn.Who Said It – Quotes from famous figures to remind, inspire and amuse you.How to Do It – Key practical tips for using the knowledge in each chapter. These boxes will describe the tools and techniques that you need to use and give examples of their use.What You Need to Read – Suggestions of 3-5 key sources for further readingIf You Only Remember One Thing – Lines summing up the contents of each chapter at the end of each chapter.

Since the book is going to spend a lot of time talking about projects, perhaps this is a good place to define what a project is. There are also a couple of related terms – ‘programme’ and ‘programme management’ – which need to be referred to as well.

The Project Management Institute’s (PMI’s) Project Management Body of Knowledge (PMBOK)– give definitions of the words ‘project’ and ‘project management’. You don’t need to worry too much about these here. These definitions lay great stress on the fact that a project is different from business-as-usual type things like doing the end of month accounts or processing customer requests.

But it’s been my experience that anything can be a project. Large or small, with a cast of thousands or just you, in work or outside of it – anything can be treated as a project and the things covered in this book can be successfully applied to it. In your project management travels, you’ll also come across the phrase ‘programme management’. What’s a programme? It’s just a big project or you can also think of it as a group of related projects being done together. Programme management, then, is the management of such a beast.

So:

Anything can be a project.A task is just a small project. A project is just a big task.A programme is just a series of projects. For example, the 2012 Olympic Games is a programme. However, the 2012 Games is also just a big project – or indeed, a big task.

Project management, then, is making your project happen. It’s the planning (and, in particular, the estimating) of the project and then, the execution of the plan to bring the project to a successful conclusion. Thus, project management can be applied to anything.

While this definition may sound loose to you, it has the huge advantage that the skills you’re going to learn in this book are widely applicable to a vast (in fact, infinite) range of problems and situations.

Good project management is less about how to draw a Gantt Chart or wondering what ‘Critical Path’ means, and more about behaviour. There are certain behaviours that lead to good project management and certain behaviours that are guaranteed to drive you onto the rocks. This book tells you what those good behaviours are. But – more importantly – it will motivate you into adopting these good behaviours.

Behaviour change is hard. You know it yourself. If you’ve ever tried to give up smoking, go on a diet, take up running or whatever – it’s tough. It’s tough and it’s easy to slide back into your old ways. For nearly twenty years I have been teaching courses (www.etpint.com) on how to adopt these good behaviours. This book incorporates everything I have learned during that time.

If you do the things that this book describes then:

All your projects will work out successfully.Your projects will get done as quickly and as cheaply as possible.Your projects will get done with far less fire fighting and unpleasant surprises, thereby saving and freeing up much valuable time.You will be able to make commitments on project budgets and delivery dates with maximum confidence – and deliver on these commitments.You will build a track record of consistent project delivery.You’ll be able to have a life.

If all of this appeals to you then turn the page and let’s get started.

CHAPTER 1

GOAL SETTING

WHAT IT’S ALL ABOUT

The big problem in project managementThe magic line – what to say when you get handed a project and what not to saySetting a clear goal.Controlling changes to the goalMaximising the win-conditions of the stakeholdersThe definition of a successful projectThe way to set SMART goalsWhen 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 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.

WHO SAID IT

“Begin with the end in mind.”

– Stephen Covey

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.