Chapter 1

Success in Project Management

In This Chapter

Understanding what makes a project a project

Seeing what's involved in project management

Coming to grips with the Project Manager's role

Knowing what it takes to be a successful Project Manager

Organisations are constantly changing, and ever faster, as they adapt to new market conditions, new financial conditions, new business practices, new legal requirements and new technology. Then there is work to be done such as to upgrade or move premises, install new facilities, carry out major maintenance, improve manufacturing processes and re-brand commercial products. A lot of that work is carried out with projects, and as a result businesses are increasingly driven to find individuals who can excel in this project-oriented environment.

Taking on a Project

Because you're reading this book, the chances are that you've been asked to manage a project for the first time or that you're already involved in projects and are looking to see whether you can find easier and better ways of doing things. If the project is indeed your first one, that's a challenge and may well give you the chance to excel in something you haven't done before; for many, managing a project even opens a door to a new career. The really good news here, whether you're completely new or have some experience, is that project management has been around for a very long time. In that time, Project Managers have come up with highly effective strategies and a range of very practical techniques. You can benefit from all that experience, and this book takes you through what you need to know.

So, hang on tight - you're going to need an effective set of skills and techniques to steer your projects to successful completion. This chapter gets you off to a great start by showing you what projects and project management really are and by helping you separate projects from non-project assignments. The chapter also offers some insight on why projects succeed or fail and starts to get you into the project management mindset.

Avoiding the Pitfalls

By following a sound approach to the project, you automatically avoid many of the pitfalls that continue to contribute to, or cause, project failure on a mind-boggling scale. You may ask why, if good ways of doing things are out there, people ignore them and then have their projects fail. Good question. People make the same project mistakes repeatedly, and they're largely avoidable. You may have come across the joke by comedian Tommy Cooper:

I went to the doctor and said 'Every time I do this, it hurts.' The doctor said, 'Well, don't do it then.'

A national public project run in the UK to create a database of offenders for use by the Prison Service, Probation Service and others attracted heavy criticism for poor management. The National Audit Office, which checks up on government departments, investigated and reported that the project was delayed by three years, and the budget was double the original, but the scope had been radically cut back. Edward Leigh MP, chairman of the powerful Public Accounts Committee in Parliament at the time, described the scheme as a 'spectacular failure' and 'a master-class in sloppy project management'.

The following list takes a quick look at the main causes of project failure. The list makes for depressing reading but gives a good background against which to contrast successful project management and the approach in this book.

• Lack of clear objectives: Nobody's really sure what the project is about, much less are people agreed on it.
• Lack of risk management: Things go wrong that someone could easily have foreseen and then controlled to some degree or even prevented.
• No senior management 'buy in': Senior managers were never convinced and so never supported the project, leading to problems such as lack of resource. Neither did those managers exercise effective management supervision (good project governance) as they routinely do in their other areas of responsibility.
• Poor planning: Actually, that's being kind, because often the problem is that no planning was done at all. It's not surprising, then, when things run out of control because nobody knows where the project should be at this point anyway.
• No clear progress milestones: The lack of milestones means nobody sees when things are off track, and problems go unnoticed for a long time.
• Understated scope: The scope and the Project Plan are superficial and understate both what the project needs to deliver and the resource needed to deliver it. The additional work that is necessary then takes the project out of control, causing delay to the original schedule and overspending against the original budget.
• Poor communications: Many projects fail because of communication breakdown, which can stem from unclear roles and responsibilities and from poor senior management attitudes, such as not wanting to hear bad news.
• Unrealistic resource levels: It just isn't possible to do a project of the required scope with such a small amount of resource - staff, money or both.
• Unrealistic timescales: The project just can't deliver by the required time, so it's doomed to failure.
• No change control: People add in things bit by bit - scope creep. Then it slowly dawns on everyone that the project's now grown so big that it can't be delivered within the fixed budget or by the set deadline.

That's ten reasons for failure, but you can probably think of a few more. The interesting thing about these problems is that avoiding them is, for the most part, actually not that difficult.

Deciding whether It's a Project

Before you start to think too deeply about how to set up the project, the first thing to do is check whether it really is one.

You can think about three things to decide if a job is a project:

• Is it a one-off job or something that's ongoing? If the job is ongoing, like taking customer orders, then it's business as usual, not a project.
• Does the job justify project controls? Project management means incurring some overheads, but some jobs are so small or straightforward that they just don't justify that degree of control.
• This last one may sound a little weird, and it certainly doesn't fit with the formal definitions; it's the question, 'Do you want to handle the job as a project?' You may choose to deal with a block of work as a project, but I wouldn't - sometimes you have a choice.

Grasping the four control areas

Projects, large or small, involve the following areas of control:

• Scope: What the project will deliver
• Time: When the project will deliver
• Quality: So often forgotten, but an essential dimension
• Resource: Necessary amounts of staff time, funds and other resources such as equipment and accommodation that the project needs

You need to balance these areas for each project, and you can see immediately why so many projects get into difficulties. You look at a project, think about the four control factors and say to yourself, 'They want that scope, to that quality level, with just that resource and by then? They've got to be joking!' Strangely, organisational managers often commit projects to failure by insisting on unachievable deadlines or unrealistic resources. What's even more strange is that those same managers are then surprised and even angry when the projects inevitably get into difficulties and fail.

Getting the balance right in the early part of the project when you do the main scoping and planning is, obviously enough, essential. Jerry Madden of NASA, the American space agency, produced a great document called 'One Hundred Rules for NASA Project Managers'. Rule 15 is:

The seeds of problems are laid down early. Initial planning is the most vital part of a project. The review of most failed projects or project problems indicate the disasters were well planned to happen from the start.

It's also useful to think about the four areas of control when dealing with change in the project. Chapter 13 includes a 'four dog' model to help you think about the interaction. Although many other considerations may affect a project's performance, the four components are the basis of a project's definition for the following reasons:

• The only reason a project is run is in order to produce the results specified in its scope.
• The project's end date is often an essential part of defining what constitutes success.
• The quality requirement is a vital part of the balance and may be the most important element. What's the point of delivering an unusable heap of garbage on time and within budget?
• The availability of resources can affect which products the project can produce and the timescale in which it can produce them.

Quality can be a very important factor, and is sometimes the most important, so do think about it carefully. A project to build and install a new air traffic control system for the south of the UK was...