Fast Projects - New from Fergus O'Connell
this book is for people running projects large and small, in work / outside or work, involving a cast of thousands or just one person.

The biggest project that the methods in this book have been applied to is the Special Olympics World Games 2003, the world's biggest sporting event that year and widely regarded as an outstandingly successful project.

Projects that take longer than expected have become pretty much a cliché in the modern world. Hardly a day goes by that we don't read or hear about some project somewhere that has been delayed or missed its deadline - sometimes repeatedly. Governments, companies large and small, organisations in the public and private sector, individuals - nobody seems immune from this terrible condition.

And what a pity! Because it doesn't have to be like this.

• It is possible to run projects that don't run over
• It is possible to get these projects done with the least amount of work possible - far less than would have been involved had the project run over
• And it is even possible to deliberately shorten projects.

In short, it is possible to run fast projects - projects that don't run over, can often come in early and never require huge amounts of effort to keep them on the straight and narrow.

You don't have to have a title like Project Manager, Project Leader, Team Leader to do this (or to benefit from this book). The book is for anybody working in any industry or sector where they have been handed an undertaking and told to make a success of it.

If you want your project to: Come in on time or early; and Be done as painlessly as possible,
then this book is for you.

Here's how the book is organised. There are twelve chapters. The first eight show you how to plan and execute any project. They take you from the moment when the project is handed to you through to doing a post-mortem on a completed project. These chapters are structured as follows:

• There's a section at the beginning which cuts to the chase and describes, as succinctly as possible, the basic idea of the chapter and exactly what you have to do on your project.
• Then a number of sections follow which give a bit more background to the basic idea. You can read them or not as you wish.
• Each chapter ends with a section that extends the basic idea. The purpose of this extension is to show you how can significantly shorten your project. If you are trying to get your project done in the shortest possible time then you will need to read this.

Chapters 9 through 12 give you some additional tools to help you deal with projects using the least amount of time possible. Specifically, these tools are:

• How to assess a project in five minutes (Chapter 9).
• Hot to scope and plan a project in a day. (The technique is described in chapter 10 and an actual scoping and planning session is described in chapter 11.)
• A checklist of the principle reasons why project fail (chapter 12).

The book is quite prescriptive. Rather than saying 'you could try this, or here is a bunch of ways to do that', it attempts to provide as foolproof a recipe as possible. As a result, while there may be a number of ways to do particular things, this book will, in general, say 'do it this way'.

Finally, this book is for people running projects large and small, in work / outside or work, involving a cast of thousands or just one person. The biggest project that the methods in this book have been applied to is the Special Olympics World Games 2003, the world's biggest sporting event that year and widely regarded as an outstandingly successful project.

If you want to build up a track record of outstanding success on projects then this book will take you step-by-step through doing exactly that.

Sample Chapter - Chapter One: Say "We'll Take A Look At It."

Don't agree to something that's impossible

If you want to run a fast project then the first thing that you definitely don't want to do is to commit to something - a deadline, a budget, a target - that is completely impossible. The lesson of this first chapter is very simple. Don't agree to anything until you've had a chance to look at it.

Projects are dangerous things

Your boss calls you into his office, gathers up the pile of stuff and says, 'Congratulations, you're going to be leading the poison chalice project, and I'm sure it'll be a career-enhancing move for all of us. Oh, and by the way, we don't know much about this project, but it has to be done by this date, you'll have to do it with the team you've got and the budget is fixed.'

Project Management is the hardest job in the world. This is because you get asked to make a prediction of the future and then make that prediction come true. Now, if you - or any of us - could actually do that you wouldn't be here. You certainly wouldn't be reading this book. Instead, you'd be down at the race track or at the casino or buying lottery tickets. But instead you make predictions of the future for a living and try to make those predictions come true.

If all of that wasn't bad enough, you also get asked to make these predictions in a very strange way. Imagine your car was acting up and you took it to the garage and you said to the mechanic, 'I don't know what's wrong with my car, but I'd like you to fix it in the next half hour and it better only cost fifty euros / pounds /dollars.'

You can't really imagine such a dialogue happening. Yet, in a lot of sectors and industries and organisations such conversations are routine. Somebody says, 'Here's the project. We don't know much about it, but it's got to be done by this date, for this budget, with these resources'. And often everyone just says, 'Ok'.

The project 'missile'

The handing over of the project, as described above, is a dangerous moment. It's such a dangerous moment that it's like having a missile fired at you. There are two types of missile - the ballistic missile and the cruise missile. The ballistic missile is launched and you pick it up on your radar screen. The ballistic missile is the explicit handing over of the project as described in the opening paragraph.

But there is also the cruise missile - the sneaky one. It gets launched somewhere and suddenly - out of nowhere, it seems - it lands in your lap. Here's an example of a cruise missile. You're at a meeting, say, and somebody asks you, 'How long do you think that would take?' If you're not careful, you'll think up an answer. And if you're not really, really careful, you could end up opening your mouth and making a commitment.

Whether the missile is ballistic or cruise, it's dangerous because it carries a warhead. But in our line of business - project management - the missile carries a particularly dangerous kind of warhead called the binary warhead. A binary warhead contains two things which separately are pretty innocent but mix them together and they're deadly.

In our case, these two things are:

• The request itself - 'will you do the poison-chalice project?' is an example of a request
• Something that is often referred to as the 'constraints' or - my own preferred term - 'the baggage'.

The baggage is the idea that even though they've asked you the question, 'How long will that take?' they already know the answer:

• The project must be finished by a certain date Date baggage
  
  And / or
  
  
• It must be done for a certain budget Budget baggage
  
  And / or
  
  
• It must be done with certain resourcing Resource baggage.

'Defusing' the warhead

If you try to deal with the request and the constraints together, I hope you can see that potentially you could end up in a lot of trouble. Because, on the one hand, as you think about the date, you think about all the things you'll have to do and all of the time that those things will consume. Meanwhile the baggage is telling you that you're not going to get the time.

And you're thinking that you're going to need three highly skilled specialists for a certain part of your project. The baggage is telling you that you'll be lucky to get a man and a dog!

And, in almost every case, the baggage has a tendency to win the argument. As a result you can end up committing to doing that are

• Difficult to do
• Impossible to do
• Well beyond impossible (if such a place exists).

It has to be said that the #1 reason why projects fail is that they were never actually possible in the first place. Somebody said, 'Here's the project. It has to be done by this date or for this budget', and everybody just said, 'Ok'.

So if you're going to run your projects successfully, the first thing you have to do is to stop this behaviour. From now on, when a project is handed to you, you're not going to just say, 'Ok'. Instead you're going to do what the mechanic or the plumber or the doctor or the truck driver or the assistant in the clothes shop or any one of a million other 'normal' professions does, when asked to address a problem. They say, 'We'll take a look at it.' In other words they'll do an examination, come up with a diagnosis and then tell you what's possible and what's not.

In all likelihood, the powers-that-be may be looking for action to break out straight away. Once you walk out of your boss's office, he may want to see meetings and brainstorming sessions and teleconferences and documents being written and people doing stuff and all the other paraphernalia of a live project.

It doesn't matter.

All you can say at this stage is, 'We'll take a look at it.' All you commit to is that you're going to look at the problem and see what's possible and what's not. And with that you walk out carrying the pile of stuff and turn your attention to chapter 2.

Summary

"We'll take a look at it."
Whether it's a large, cast-of-thousands project or a seemingly modest request, the rule is always the same - don't agree until you've had a chance to look at it. OK, there may be things that you've done many times before and you know precisely how long they will take and how much work is involved; but for anything else, get the time to examine it and understand it.

The method for examining it and understanding it is described in chapters 2-7. Once you've read through these chapters and you understand what you have to do, you will find the following.

For small things, you'll be able to figure them out (almost literally) on the back of an envelope; for large things you will have to write a detailed plan. Using the techniques described, I think you will be pleasantly surprised at how much of a plan you can build in a short space of time. On our courses we generally give people 2-3 hours and in that time, they end up building plans for large and complex projects. In building these plans they uncover so many things about the project. These are things which, if they hadn't been uncovered, would have turned into surprises and so-called 'firefighting' further down the line.

The payback for the time spent doing this early planning is huge. The payback is all the time you save by not having to fire fight things. I think you'll agree that it wouldn't take much of a fire fight to blow away 2-3 hours of your time.

So:

You're at a meeting and somebody is pushing for 'a date'. Ask for a time-out - ten minutes, half an hour, a couple of hours, depending on the scale of the project - so that you can come up with a reasoned answer to their question.

Somebody comes running in saying that the need an answer by four o'clock today as to whether something can be done or not. Insist on the time you need to apply chapters 2-7 and do your analysis of the project.

Somebody says, 'This is a very small thing - could I just get you to do it now?' Don't be suckered. How many 'very small things' have you seen turn into very big things?

Somebody says, 'We don't have time to plan - just go do it.' Your response should always be, 'We'll take a look at it'.

If you only took one idea away from this book, let it be this idea. if you stopped reading now, then provided this was what you did then you would have picked up something really, really useful.