Project Management Book

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.

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 realise 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 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, 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.

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 realise 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 programme? Probably you would. Ideally, every project in a company (throughout for "company" read "public sector organisation" 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.

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.


...please click here for next page

Privacy Policy and Cookies