CHAPTER 1 - INTRODUCTION AND PRINCIPLES

"The first 90% of a project takes 90% of the time; the last 10% takes the other 90%."

 Simplicity and humour may not be the first things that spring to mind when you think of
project management. However, we will try to keep it simple and even have the occasional go
at humour in this project management book.

This short first chapter sets out some principles and introduces themes that will be
expanded upon later.

 What is a project? Definitions abound but usually boil down to something like this: a project
is a one-off, temporary activity with a clear start and a clear end (though some projects
never seem to end); it has full or part-time resources clearly assigned to it; it has a
temporary management hierarchy that takes precedence over the company hierarchy; and it
sets out to deliver something: an IT system, a new product or whatever.

 Given the following four characteristics of projects:

Finite time.

People assigned.

Clear roles and responsibilities.

Things to deliver.

 Have you ever had this feeling about a project?

not enough time

too few people

people not sure what they should be doing

too much to do

 What causes this feeling of sometimes overwhelming pressure? In its widest sense, a lack
of planning, People drift into projects without properly defining or planning them then one
third of the way through they begin to realize what it's really all about and the panic starts.
Sometimes the end date is thrust upon them arbitrarily, but sometimes project managers
voluntarily commit themselves to dates, costs and deliverables without troubling to define
and plan the project properly, which is lunacy.
 You'll never remove the pressure altogether, in fact that's not even desirable: a bit of
pressure is good for the soul and gets the adrenaline flowing. But getting the pressure to a
sensible, containable level is the aim of many of the techniques we will cover in this project
management book. Such that when you make a commitment you at least have a fighting
chance of achieving it.

 Another popular definition of a project is: the way change is achieved. Left to their own
devices many things gradually improve, but to bring about significant change, say to a
business process, a project is needed. However, to this definition we would add the word
predictable: projects are a way of bringing about predictable change. That is, at the
beginning of a project we should be able to predict cost, end date, deliverables and even
something about the quality.

 What helps make a project predictable? Clear scope, clear roles, clear plans, clear control
mechanisms, and clear reporting structures... in other words good project management. But
here is a question for you: if you take the total cost of a project expressed, say, in man
hours, what percentage should be spent on planning, controlling, reporting, etc. - i.e. project
management? Five, ten, fifteen, twenty percent?

 The answer is: it depends. Imagine a simple project being done by a few experts who've
done many similar projects before. They may need hardly any control - perhaps only 5% of
the total cost will go on managing the project. But by contrast imagine a large, complex
project spread across many locations, staffed largely by novices who only spend part of their
time on the project. A huge panoply of control may be needed to keep everything on track -
perhaps even 35% of the project's total cost might be spent simply managing it. Project
Management Book Copyright M Harding Roberts 2006 2007 2008

 Suppose we conclude for a specific project it will be appropriate to spend 15% of the project
budget on project management. But the sponsor says "cut out all that bureaucracy and
reduce the project cost by 15%!” How would we respond?

 Do we have a choice between a project costing 100 with project management and a project
costing 85 without it? We do not. The choice is between a project costing 100 with project
management and one costing an awful lot more than that without it. (And without the
controls in place we'd probably never know how much more!)

 In other words project management is an investment: it results in the project costing less
than it would otherwise cost. If you don't believe that it could be because your project suffers
 unnecessary bureaucracy masquerading as project management. One of the many skills of
the project manager is knowing almost instinctively how much control to bring to bear, so
that small projects are not smothered by unnecessary red tape yet enough control is applied
to large projects to keep them on the straight and narrow. Some project management
methodologies seem to militate against this essential flexibility. But we will air our prejudices
on the subject of methodologies later.

 Suppose you are asked to manage a project which on closer inspection you realize consists
of 5 sub-projects:

 business process re-engineering

 IT software development

 Hardware installation

 User training

 Implementation and roll out

 And you discover that each of the 5 groups involved has a different way of running their
projects and they each use different project management terminology. Would you have a
problem in running the program? Probably you would. Ideally, every project in a company
(throughout for "company" read "public sector organization" or whatever is appropriate for
you) would use the same project management approach and terminology.

 This could be achieved by buying a PM methodology and imposing it, as is, on all projects.
An alternative might be to have rules and guidelines which are attuned to the needs of your
company. And notice: rules and guidelines, not standards. With a big book of standards it's
not always clear what's mandatory and what's optional and people tend to apply all of it just
in case.

 What would be in the rules, what would be in the guidelines? The rules need be no more
than 16 pages of A6 (that's very small, shirt pocket sized) which, as far as any experienced
project manager is concerned, state the obvious. For example, one of the rules might be:
before each project stage begins risks must be formally assessed and significant risks
presented to sponsor. Now if you're thinking: "well of course we do that!" you've probably
been there, seen it, done it and got the project management T-shirt. But maybe you're
thinking: "that makes sense, but I'm not sure we ever tell the sponsor about the risks...".
 Either way, read on. We include a sample set of project management rules in the appendix
of this project management book.

 Whereas rules are mandatory and enforceable, guidelines are optional and, a bit like a
restaurant menu, offer a list of things from which you can choose: forms, procedures,
checklists, etc.

 Though, faced with your first large project would you know which things to select? Quite
possibly not, which is why it might be a good idea for the project manager to state what
controls he intends to apply to his project and then have someone independent - we'll call
them Project Support - review what's intended. Project Support might conclude: "you've got
far too much bureaucracy intended...” Or they might say: "you've got nothing like enough
control planned...” Or with luck they'll say: "that looks about right". If one of the first two,
Project Support would help you devise a more appropriate set of controls for your project -
which is why we call them Project Support rather than Project Assurance or (ugh!) Project
Audit.

 PROCESS VS PROJECT

 In many companies there are, at the extremes, people who are process-oriented and those
who are project-oriented. For example, walk into any bank and watch what happens there.
Someone comes in to pay a bill. The clerk performs the task which takes maybe 30
seconds. Each task the clerk will do during the day will be triggered by an external stimulus
"please can I pay this bill?" and each task they do during the day will be independent of
every other task they will do. People who grow up in these process-based or operational
cultures develop a management style appropriate for this reactive kind of work, which boils
down to Just Do It and do it now and do it quickly. You may have heard this approach
referred to as JFDI.

 However, people who grow up in construction companies have a different experience. When
they joined as a young bricklayer they laid bricks in accordance to the project plan - the
customer does not ring up and say: "now lay brick number 735"! Work is not triggered by
external stimuli but by the project plan. For executives in construction the imperative isn't so
much to answer the phone within three rings but to get the housing estate built in the
scheduled 3 years. These guys know all about planning.
 The trouble is, trying to do projects in inherently process-based environments can lead to a
clash of cultures which can cause many problems, though the cause of these problems
often goes unrecognized. Have you ever approached a senior business manager and said:
"I need two of your people to work full time on this project for the next month to define in
detail the business requirements that the new system will satisfy when we deliver it in eight
months time." And received the reply: "You must be joking! I've got a business to run here, I
can't afford to have two of my people taken off their job for a month. Come back in six
months, maybe we'll be able to tell you then what we'd like the new system to do."

 Sometimes people who have never been involved in a project have no idea why it's
important to define requirements so far in advance of delivery. They are not being awkward
or bloody minded, they just don't understand. You've tripped over a project vs process
cultural issue.

 If you ask IT people who have experience of large projects what helps projects succeed they
will tend to answer: "Planning, planning, planning and more planning." But a process-based
manager's reaction to this can be: "No! I manage two hundred people on the business side
of my company. We don't feel the need for all this planning nonsense; we just get on with the
work and do it. In fact it seems to me that planning is just an irritating, initial delaying tactic
used by the IT department to avoid ever doing any real work." Now there's a culture clash
for you.

 However, you will find that if you take the trouble to explain to senior process-oriented
managers what projects are all about, they are intelligent people, they will readily
understand and will conclude that obviously projects have to be planned, business
resources properly assigned, requirements defined at the outset, etc. But all too often
nobody explains and the culture clashes persist.

 In a pure process-based company the company hierarchy is primarily designed to manage

those at the bottom who actually do the work of running the business (Fig 1): Project
Management Book Copyright M Harding Roberts 2006 2007 2008
 Figure 1: Process-Based Company Organization
 In the extreme you join the company, say, as an order-taker and there you stay along with
19 other order-takers taking orders for 30 years. Your line manager manages his 20 order-
takers and that's the limit of his horizon. We exaggerate to make the point.

 However, in a pure project-based company things are different (see Fig 2). A resource pool
of 50 engineers report to their line manager, 50 IT staff report to another line manager, 50
financial experts to another, and 25 project managers to another line manager. And they all
sit around doing absolutely nothing; just sit twiddling their thumbs all day. Until, that is, a
project comes along. Then a project manager is appointed. He selects 2 sub-project
managers, 6 engineers, 8 IT staff and 3 accountants and fits them all into a one-off
management hierarchy for the project. At the end of the project they all return to their
respective line managers and sit and wait for the next project to come along.

Figure 2: Project Based Company Organization

 In practice most companies are hybrids: some of a line manager's staff are doing work for
him - their "proper job" - while others are rented out full time or part time to project
managers. The line manager now has to be a task manager for those doing work for him, a
career manager for those on projects and he also must manage the inherent conflict
between servicing the day to day business and investing in the future.

 In a hybrid company you could join, say, as an accountant: "Welcome," your boss says. "For
your first three months you'll be working not for me but for this project manager." Three
months later you return to your boss who then assigns you to another project for six months.
In fact you could spend your whole career hopping from project to project and never actually
do any work at all for your boss. (Though some would say this wasn't a totally unknown
phenomenon even before projects...)

 Which skill set tends to be in shortest supply in these hybrid companies? Is it accountants,
engineers, programmers? No. Project managers. People who can manage projects in
process-based cultures are worth their weight in gold. Many if not most projects in process-
based companies are managed by people who do not see themselves first and foremost as
project managers: "I'm an actuary managing this product development and development of
the IT system that will support it." Yet these people are expected to perform well as project
managers and overcome the cultural project inhibitors that are often a feature of process-
based companies - lack of empowerment of the project manager being just one example.

 In some companies being assigned to a project is to be cast out into the wilderness - a vote
of no-confidence from your manager, a career-limiting move and possibly a prelude to
redundancy. And yet those left handling the day to day business see those assigned to a
project as being "off on a jolly", escaping the pressures of the real world.

 In other companies’ top management have established a more project-friendly ethos:

"Projects determine our future. I want our best people assigned to projects. I want good
project work rewarded with promotion. Indeed, henceforth, I will not appoint anyone to a
senior management position unless they have managed at least one significant project." We
will see how this state of grace might be achieved.

 If you ask people what factors cause problems in projects these are the sort of things they
will say:

 Undefined scope
 Unclear objectives
  Unclear roles and responsibilities
 Vague requirements
 Lack of leadership from sponsor
 Lack of user involvement
 Inadequate planning
 Scope creep
 Uncontrolled change
 Inadequate monitoring and reporting
 Team know it's impossible but management believe it will be done
 Ignoring reality, wishful thinking
 Inadequate communication

 It is surprisingly rare for people to say that IT technology causes project failure or major
difficulties. It is usually project management - or a lack of it - that causes the grief.

 There was a touching belief a few years ago that if only one could write down every step a
project must tread, then project managers could simply follow the process and out the other
end would pop a successful project. Huge methodologies were spawned, money was made.
But it isn't like that.

 If you wanted to become a plumber you'd learn how to use each of the 50 tools in the
plumber's toolkit. On your first, simple job you might only use 2 of them, but knowing which 2
and how to use them to best effect is obviously key. On a large plumbing job you might even
use half the tools in your toolkit, but you'll never find any job on which you'll need to use
every tool in the box.

 The same with project managers: it's all about being equipped with tools for managing risks,
defining scope, planning and scheduling, resolving conflict, etc and then using these tools
appropriately if and when needed. You cannot manage projects by rote.

"Successful project management is all about spotting the projects that will
succeed and shouting 'mine' and for the rest ducking and shouting 'yours'."