When I joined the projects department of Shell Mex and BP, I was given a manual titled ‘Policy Guide.’ Naturally on the first project I was responsible for, I followed the policy religiously. Nevertheless, I was called into my boss's office and rapped over the knuckles and told: “For heaven's sake use your imagination – it's only a guide.” Sometime later, on a major project, I had the vehicle maintenance facilities for road tankers redesigned. However, this had consequences for all the other similar projects that were being carried out at the same time. Not surprisingly I was called into the boss's office again, who banged the table and stated firmly “That's the policy!” I have always thought that this was brilliant. The skill of project management is deciding when to follow policy and when to do things differently. Consequently, this book is a policy guide. It may be good policy to follow the theoretical reasoning that is included, but the checklists will provide a guide to a practical approach.

This book is designed to help project managers achieve success. Its purpose is, to make project management ‘boring.’ The thesis is that if your project is exciting, then it is in trouble. The book should help experienced project managers as well as those with less experience. Nevertheless, I shall never forget the one occasion (and the only one!) during my career as a practicing project manager when, to my surprise, I found that I had nothing to do. So, I decided to read the company project management manual. I was taken aback when I discovered something I had not thought about and which deserved investigation. I heaved a sigh of relief at my good luck, when the actions I took as a result prevented a project debacle. I trust that this book will provide the reader with some similar luck. Yet, there is no such thing as luck in project management. Luck comes from preparation and planning.

This is a guide to a broad spectrum of basic principles. Nevertheless, project managers also need to be conversant with today's rapidly changing technologies, particularly the information technologies. However, it is a failure to understand and conform to the basic principles that still cause projects to have problems. The knowledge required of a project manager is more than they can possibly know or know how to deliver on their own, and in any case we all make mistakes. Consequently, a checklist provides a system whereby the project manager can be confident that a valid process is being followed. This then enables them to be innovative in their approach to the project with the development of plans or resolution of problems.

I am aware that some people have difficulty with checklists. When the original loose‐leaf paper organizers were all the rage, there was a sense of having somehow failed if you were not a dedicated user. Consequently, the book format has been chosen to provide people resistant to lists with many areas where the issues have expanded explanations. I am one of those who do not find using lists a natural process. On too many occasions, I would ask Gwyneth, my wife, to fax me some document to a remote part of the country because I had forgotten to take it with me. As a consequence, my son Guy has consistently given me a hard time, and rightly so, for not using a checklist when travelling on an assignment.

Apart from the early sections of Part I and Part II, which are of a more conventional book nature, the remaining structure is a pick‐and‐mix checklist format to enable the reader to select a flexible approach to those elements that they need. The first sections in Part I deal with some basic characteristics of projects and project management because the better these characteristics are understood, the more effective the management process will be. However, it is difficult to separate projects and project management. For example: the scope is very much part of a project, but it is a project management function to define the scope. One could say it is an objective of project management to complete the scope. Nevertheless, I have tried to separate them.

The book is intended to be highly practical and is based on experience. ‘Experience is a truer guide than the words of others.’ However, to be truly effective, a project manager needs to be aware of the theory behind the issues concerned. Knowledge of the theory makes the subject interesting by observing how the theory works in practice. It also enables the reader to modify the advice given to suit different circumstances. Further, one can never be sure of people's level of expertise or what they know. For these reasons, brief elements of theory are included in the initial paragraphs of the various sections. It is designed to be as generic as possible and does not promulgate any particular method of working. Additionally, it must be remembered that the principles of project management are the same for all projects.

Rather than just produce a list of what activities need to be performed, the book also offers some advice on how tasks should be carried out. The challenge has been to cover all the essential elements needed by a project manager, in as concise a manner as possible, without compromising the issues under examination.

I hope that the reader can be like one of my MSc students who made sure that, regardless of how he felt or what he knew, he took away at least one grain of sand from every session, lecture, or assignment. He validated his knowledge, acquired a technique, or borrowed an experience. The result was that at the end of the course, he had a big pile of sand, and I would like to think that as a direct result, he went on to lead one of the major contractors.

The book is written primarily from the perspective of the project manager of the organization performing the work – the contractor. The term client is used to define the organization requesting the work. Accordingly, I have tried not to forget that a contractor performs the client role for their subcontractors and suppliers. In the text, substitute ‘management approval’ for ‘client approval,’ for different contract situations.

There is no set format to the individual sections. Each section varies according to the requirements of the topic. A few issues may appear in more than one list due to the structure of the lists. Some are more process‐oriented, whereas others are more subject‐focused. For example, ‘obtain a project cost code’ is part of the project launch process, but it is also part of the subject of project control. This emphasizes the importance of the issues concerned and ensures that they do not get overlooked. Where the same issue is discussed in a different context, a cross reference is provided.

Everything is described in a manual format on the basis that any computerised electronic system will still need to replicate a manual process. This book does not address the software that is available in the marketplace.

For completeness I have included a list of abbreviations in use within the project management world. Nevertheless, I trust that the terms I have used are self‐evident in their own context. I have avoided academic debate over the meaning of terms, and where I have used terms that are different from a norm, I have explained my reasons. For example, the Association for Project Management (APM) has specific definitions for projects, programmes, and portfolios, some of which one might wish to express differently. I could, for example, explain the term programme in two ways: firstly, to describe large projects such as the Olympics, Crossrail, or the space shuttle programme; and secondly, describing a smaller portfolio of miscellaneous business projects in an organization or an equipment maintenance programme. However, these explanations might not conform to the specifics of the APM definitions. Nevertheless, the important thing is that, in summary, the APM states ‘the concept of projects, programmes and portfolios should be thought of as just points on a gradual scale of managing effort to deliver objectives.’ Good, it is still project management!