Overview of the PMBOK® Guide: Short Cuts for PMP® Certification

Overview of the PMBOK1 Guide . ´ Conchuír Deasuń O Overview of the PMBOK1 Guide Short Cuts for PMP1 Certificatio...

Author: Deasún Ó Conchúir

266 downloads 2336 Views 3MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Overview of the PMBOK1 Guide

.

´ Conchuír Deasuń O

Overview of the PMBOK1 Guide Short Cuts for PMP1 Certification

´ Conchuír Dr. Deasuń O Scatterwork GmbH Postfach 26 8593 Kesswil Switzerland [email protected] www.scatterwork.com

ISBN 978-3-642-11187-7 e-ISBN 978-3-642-11188-4 DOI 10.1007/978-3-642-11188-4 Springer Heidelberg Dordrecht London New York The terms PMI, PMBOK, PMP and CAPM are registered trademarks of the Project Management Institute. Other trademarks are acknowledged in the text. Library of Congress Control Number: 2010923169 # Springer-Verlag Berlin Heidelberg 2010 This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilm or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer. Violations are liable to prosecution under the German Copyright Law. The use of general descriptive names, registered names, trademarks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. Cover design: WMXDesign GmbH, Heidelberg, Germany Printed on acid-free paper Springer is part of Springer Science+Business Media (www.springer.com)

Tiomnaı´m an leabhar seo do Shiobhań, an te´ a thug cuairt rialta orm agus me´ in ´ısle brı´.

.

Introduction

This book is the product of a long professional journey. At the beginning of my career, I lived and worked in a state of 3 million inhabitants which had only just joined the (now) European Union as joint seventh member, the first new member after the founding six. Even at that time, the country was the fourth oldest continuous democracy in Europe, after Switzerland, Britain and Sweden. The telephone directory for the entire country was in one single book. Most business communications were by telex, a two-way teletypewriter using telephone lines. Direct international telephone dialing was only available from about half a dozen towns and the minimum return journey time to the neighboring country was 2 days, even by air. I was working as an Electronics Engineer in the design and manufacture of telephone transmission equipment, which links telephone exchanges together. Everything we did resulted in some deliverable. Although the deliverables sometimes did not meet requirements, the “lessons learned” were good! We had virtually no experience from previous generations to draw on and about 80% of my age group emigrated to Boston, New York and further afield around the globe. Today we would describe our method of work as Project Management, although neither this term nor the description “IT” was in use at that time. One anecdote gives a feel of the environment. Our chief engineer went to Yugoslavia to purchase some telecommunication filter designs, which we then manufactured. The problem came when we needed to adjust the filters and discovered that the design information had not been purchased. We had to repeat the laborious design work, using a programmable calculator which had just become available. At about the time I graduated from university, the Project Management Institute (PMI1) was founded. Since then, it has grown to over 400,000 members and credential holders.

vii

viii

Introduction

When my professional path crossed that of the PMI1, it was immediately clear to me that they were documenting what we had lived. The importance of building on previous experience in a controlled way, based on processes, and the importance of “lessons learned” made a lot of sense to me. Ireland got me started in project management and I am glad to share this experience with you.

Special Features l l

l

l l

Compact and readable introduction to the PMBOK1 Guide. Essential topics explained in more detail and clarified with real world examples, for faster understanding. References fully aligned with PMBOK1 Guide, for direct cross-reference to all language versions. Includes extensive Index of Flash Card Terms for self-study. Also suitable for beginners, who want a quick overview of the Project Management discipline.

Who Should Read This Book This unique book shortens and interprets over 500 pages of the PMBOK1 Guide, 4th Edition into a compact readable form. It is particularly useful for candidates for the PMP1 and CAPM1 examinations. It is also suitable for everyone who wants a general introduction to best practice in Project Management, as described in this world leading Project Management standard. The author’s extensive experience of Project Management has provided him with a large toolkit of lessons learned. Many of these are included to put the PMBOK1 concepts into a real world framework. By understanding the structure and principles, PMP1 candidates can save substantially on the 150 exam preparation hours, that PMI1 Switzerland Chapter estimates are needed using self-study alone. The PMBOK1 Guide is published in about a dozen languages. Nevertheless, English terminology is frequently used in multi-cultural teams and across national boundaries, which includes most projects in global companies. In addition, the abbreviations and acronyms make study more difficult for PMP1 and CAPM1 examination candidates. A clear writing style and detailed cross-references make this book suitable as a companion to all language versions of the PMBOK1 Guide, including English. These features make it particularly suitable for exam candidates who are not native English speakers.

Introduction

ix

How to Use This Book The main purpose of this book is to make it easier for PMP1 and CAPM1 candidates to understand the PMBOK1 Guide and to pass the exam. Most of what you need to know is in these pages and you will discover the rest by working through the Flash Card Terms at the end of every chapter. The suggested way of using this book is explained in much greater detail in the section 13.4.2 Learning Phase in the final chapter. Based on the 80/20 Principle, I have made a conscious compromise in favor of simplicity, rather than trying to cover every possible point. I hope that after reading this book you will find the PMBOK1 Guide easier to interpret for any details not covered here. Chapters 1–3 can be read as a unit for a complete overview of the PMBOK1 Guide. This means that there is some intentional duplication between these three chapters and the rest of the book. The rest of the book is designed for use with direct reference to any language version of the PMBOK1 Guide, either hard copy or electronic. You should open your copy now and keep it available while you read. Chapters 4–12 (the nine Knowledge Areas) should be first studied in the order in which they are presented. This is because the process Input and Output descriptions are not repeated, even though many process Outputs in the PMBOK1 Guide are also Inputs for other processes. As you read, prepare Flash Cards for yourself, based on the Flash Card Terms listed in each chapter. This is a very powerful learning technique because the mere act of writing reinforces memory. Nearly every item in these lists is to be found in the PMBOK1 Guide. Check what they mean and write this information on the back of the cards, in a language of your choice. You can then ask your colleagues or partner to select random cards and use them to challenge you to repeat what you have learned. Sometimes it helps to look at the Inputs and Outputs of a process first, before studying the Tools & Techniques. This is because the Outputs give us an idea of what the process is about, particularly if the Tools & Techniques are complex. Nevertheless the order “Inputs, Tools & Techniques, Outputs” is retained in this book to simplify reference to the PMBOK1 Guide. Chapter 13 Preparing for the PMP1 Examination can be studied at any stage. When you have read this book completely, you may find it useful to repeat the study of the Knowledge Areas in more detail and with a closer reading of the PMBOK1 Guide in any order. If you are a PMI1 member, you should download your free copy of the PMBOK1 Guide and keep it open while reading. You can even download two versions, for example in your own language and English. For copyright protection reasons, these versions cannot however be printed. Non-members can also purchase these electronic versions from the PMI1 at www.pmi.org.

x

Introduction

The .pdf versions are much easier to search than hard copies, but note that the page numbers of the printed document and of the .pdf are different. This is because of the introductory sections before the point where the main numbering begins. Also note that the non-English versions of the PMBOK1 Guide include the English terms in the glossary, and these terms can be found easily by searching the pdf versions. This provides you with a simple built-in translation function. In this book, figure numbers (which have a hyphen after the chapter number) and table numbers refer to diagrams in the PMBOK1 Guide. Section numbers also refer to the same source. This avoids frequent repetition of the title “PMBOK1 Guide”. There is a list of Tables and Figures after the Table of Contents in the PMBOK1 Guide which may help you find these items quickly. The page numbering is not the same for each language version because some languages (e.g. German) need more space for the same content compared with English. This is well known in the software localization industry. Watch for these signs in the text, which highlight important points: Process Inputs

Tools and Techniques

Process Outputs

Essential topics explained in more detail, Exam Tips or other important points.

Analogy: Examples from everyday life to illustrate the process, based on building a family house.

Pitfalls: Dangers related with the actions described in the analogy. What each of the 42 processes does is restated in a couple of lines in the Exam Aids section at the end of each chapter. You can find more formal wordings in the PMBOK1 Guide at the beginning of each of the Chaps. 4–12, which describe the Knowledge Areas. The PMBOK1 Guide capitalizes only the first word of, for example, Input and Output names. Nevertheless in this book, all indexed terms are Capitalized in Italic Script and are nearly all (except for the first and last chapters) to be found in the PMBOK1 Guide. Otherwise capitalization is used when it is judged to help the readability.

Introduction

xi

Anecdotes to illustrate the topics are highlighted and all are based on real world experience. If your time is limited, you can skip these sections without loss of continuity. Because project management processes can be used at various levels, including Phase, Sub-project, Program etc., we will not repeat this list every time. The reader should remember that the process can be applied in this way. For simplicity: American spelling is used throughout, references to masculine include the feminine and the word “Project” is sometimes omitted. The reader is addressed in the role of Project Manager. If you are not yet a project manager, just assume that someday soon you will be!

Thanks and Acknowledgements While the interpretations and any errors are mine, this book benefits greatly from the very generous support of several PMI1 colleagues, all of whom hold the PMP1 credential. I would like to thank each of the following very sincerely for detailed proofreading and feedback of various sections. The fact that they have global project management experience, speak half a dozen different native languages and live in as many countries has resulted in several insights, suggestions and corrections which have greatly enhanced the final result. l l l l l l l l l l l l l l l

Johan Berteloot Karsten Brandt Jeremy Cottino Beat Dietziker Christian Do¨hring Olivier Gut Kai Halbach Martina Heck Sunil Khurdi Ju¨rgen Lackinger Erhard Marro Martin Nabel Justyna Rudnicka Claudio Schait James Wilkie

I am also particularly indebted to the following PMP1 colleagues for additional specific contributions: l

Billy Grierson of BASF (www.basf.com) for specialist Input and advice in connection with the chapter on Quality Management.

xii l

l

l

l

l

Introduction

Andres Maurer of prod @g (www.prod.ch) for contributing the Analogies and Pitfalls, as well as carrying out a very thorough proofread. Serge Schiltz, for a beginning-to-end detailed review, with particular regard to alignment with the PMBOK1 Guide, readability and language. Anthony Tilke for very extensive proof-reading, language checking and advice on American terminology. Jens A. Wessels for contributing significant material to the chapter on Preparing for the PMP1 Examination. The team for the final proofread was Cor Duijndam, Isabelle Jaggi-McCoy and Sasˇa Lazarevic´.

Contact with colleagues in the PMI1 Switzerland Chapter was facilitated greatly by Bernard Roduit and Martin Ha¨rri, while Volker Gottwald played a similar role in the PMI1 Chapter in Frankfurt, Germany. Without their assistance, it would not have been possible to engage such extensive contributions from the PMP1 community. The original suggestion for the book was made by Michael Bursik of Springer Verlag who participated in one of my PMP1 preparation courses. He introduced me to Christian Rauscher, Editor, Business/Economics also of Springer Verlag, who has nursed the book into existence by his active and very welcome support. To kick-start the writing phase, I spent some time at the Hotel Frohe Aussicht in Schwende, Switzerland, where Arno and Silvie Inauen plied me constantly with food, drink and internet access, while I either typed furiously or took a pause to gaze at the beautiful mountains. I wish them well for the fourth generation at this family hotel. I want to thank one more person for her immense support, Erika Wu¨st of Scatterwork GmbH, who has encouraged and supported the project throughout. Much of the content reflects the insights of PMP1 candidates, who I have had the pleasure of training in many countries. I would like to thank them for their contributions. I would also like to thank everybody who has worked with me over the years in my roles as Project Manager, Consultant, Educator and Trainer for their Inputs. I am sure that they will be pleased that their experience is also made available to you through these pages. ´ Conchuír Deasuń O BSc PhD CEng FIET FIEI PMP Zu¨rich, 10 October 2009

Contents

1

Introducing Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Why Project Management? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 What Is a Project? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 What Is Project Management? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Global Project Management Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.1 PMBOK1 Guide (www.pmi.org) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.2 IPMA (www.ipma.ch) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.3 PRINCE2 (www.prince2.com) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.4 Selecting a Project Management Standard . . . . . . . . . . . . . . . . . . 1.5 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 3 6 7 9 10 10 11 11

2

Understanding the PMBOK1 Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 What the PMBOK1 Guide Is . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 The Format of the PMBOK1 Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Overview of Chapter 1: Introduction . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Overview of Chapter 2: Project Life Cycle and Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Overview of Chapter 3: Project Management Processes for a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Exam Aids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13 13 15 15

Process Groups and Knowledge Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 What Are Process Groups? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Overview of the Five Process Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Initiating Process Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Planning Process Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3 Executing Process Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.4 Monitoring and Controlling Process Group . . . . . . . . . . . . . . . . . 3.2.5 Closing Process Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 What Are Knowledge Areas? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Overview of the Nine Knowledge Areas . . . . . . . . . . . . . . . . . . . . . . . . . . .

23 23 25 25 26 27 27 28 29 29

3

17 20 22

xiii

xiv

Contents

3.4.1 Project Integration Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 Project Scope Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.3 Project Time Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.4 Project Cost Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.5 Project Quality Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.6 Project Human Resource Management . . . . . . . . . . . . . . . . . . . . . 3.4.7 Project Communications Management . . . . . . . . . . . . . . . . . . . . . . 3.4.8 Project Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.9 Project Procurement Management . . . . . . . . . . . . . . . . . . . . . . . . . . Exam Aids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30 30 31 32 32 33 34 34 35 36

4

Integration Management Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Develop Project Charter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Develop Project Management Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Direct and Manage Project Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Monitor and Control Project Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Perform Integrated Change Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 Close Project or Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7 Exam Aids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39 40 44 48 52 53 55 57

5

Scope Management Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Collect Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Define Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Create WBS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 What is Not in the WBS Does Not Get Done? . . . . . . . . . . . . . 5.4 Verify Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5 Control Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6 Exam Aids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59 60 66 68 70 70 72 73

6

Time Management Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 Define Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Sequence Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Estimate Activity Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 Estimate Activity Durations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5 Develop Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6 Control Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.7 Exam Aids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

75 76 79 82 85 87 90 92

7

Cost Management Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 7.1 Estimate Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 7.2 Determine Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 7.3 Control Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 7.3.1 EVM Cost Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

3.5

Contents

xv

7.4

7.3.2 EVM Schedule Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 7.3.3 EVM Formulas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Exam Aids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

8

Quality Management Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1 Plan Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Perform Quality Assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3 Perform Quality Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4 Exam Aids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

113 116 123 124 126

9

Human Resource Management Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1 Develop Human Resource Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2 Acquire Project Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3 Develop Project Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.4 Manage Project Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.5 Exam Aids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

129 130 133 136 141 144

10

Communications Management Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1 Identify Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 Plan Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3 Distribute Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4 Manage Stakeholder Expectations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.5 Report Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.6 Exam Aids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

147 149 150 154 155 157 159

11

Risk Management Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Plan Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Identify Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Perform Qualitative Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.4 Perform Quantitative Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.5 Plan Risk Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.6 Monitor and Control Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.7 Exam Aids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

161 165 167 169 171 174 177 178

12

Procurement Management Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.1 Plan Procurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.2 Conduct Procurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.3 Administer Procurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4 Close Procurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.5 Exam Aids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

181 183 189 192 193 194

13

Preparing for the PMP1 Examination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.1 Professional and Social Responsibility . . . . . . . . . . . . . . . . . . . . . . . . . . 13.1.1 PMI1 Code of Ethics and Professional Conduct . . . . . . . 13.2 Language Aids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

197 197 198 199

xvi

Contents

13.3

13.4

13.5 13.6

Exam Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.3.1 PERT and Standard Deviation . . . . . . . . . . . . . . . . . . . . . . . . . . 13.3.2 EVM Formulas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.3.3 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.3.4 Project Process Groups and Knowledge Areas Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Preparing for the PMP1 Examination . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.4.1 Plan Your Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.4.2 Learning Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.4.3 Health . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.4.4 Examination Day . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Final Word . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

199 199 200 200 200 200 201 201 203 203 205 205

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

Chapter 1

Introducing Project Management

Chapter Summary This chapter examines: l

l

l l

Before investing a lot of personal and company time in studying the PMBOK® Guide, it is worth asking: “Why Project Management?”. Projects can be very expensive undertakings, because of both the resources they use and other opportunities which might have used the resources better. We ask the questions: “What is a Project?” and “When are project management techniques worth using?” While projects are unique, project management is a process. Over the last half century, some project management standards which have global acceptance have emerged. Three of the best known are described briefly.

1.1

Why Project Management?

Project management is a complex subject so it is important to remind ourselves why we are studying it. We start therefore with a true story (highlighted below) about a project that cost about 100 million by the time it was Terminated.1 This means that it was abandoned without achieving its objectives and it reminds us what can go wrong. Once upon a time (as all good children’s stories begin) there was a very important project. It was so important that the advisors convinced this global company, with headquarters in Europe, to start implementing it immediately. After about 12 million Euro had been spent, the team thought it would be a

1 Terms which are Capitalized in Italic Script are the basis for the Index. Most of them (except in chapters 1 and 13) are in the PMBOK® Guide and are provided as Flash Card Terms at end of each chapter.

´ Conchuír, Overview of the PMBOK® Guide, D. O DOI 10.1007/978-3-642-11188-4_1, # Springer-Verlag Berlin Heidelberg 2010

1

2

1 Introducing Project Management

good idea to develop a specification. To do this a project team was put together and there was a large international kick-off meeting, which lasted a few days. Everybody had a very good time! After some development work, the users in North America were contacted to help with the testing. An enterprising manager there then suggested that the project should be executed near to the users, to improve communication with them. He said that he was available to take over the management of the development work and would also be happy with a development manager’s salary. It is possible that this is why he suggested transferring the project to his location. Instead of transferring the project team from Europe to North America, it was disbanded. Except for the European based project manager, the work was passed to a completely new implementation team in North America. The new team grew to over fifty people and worked hard for about two years. They found it difficult to make good progress because of the poorly defined decision making processes. There was a senior North American manager, but he was not invited onto the project steering committee because his line staff were not directly involved. His organization did however provide office space for the project team. After every project review meeting, he asked what was happening. Sometimes he did not agree with the decisions so he contacted his long time senior colleague in Europe to get support for changes. This colleague then sent out new instructions, which often reached the team weeks after their original decision. This meant that some work done in the meantime was wasted. Because the development manager had such a big team, he earned a really good salary. During this time the company headquarters in Europe bought a competitor and their managers became new project stakeholders. This was because they were expected to use the output of the project. Even so they were not convinced and said that they would not use it. This made the company re-think the project and send in their auditors. They found out that the value of the deliverable minus the cost of development was nearly zero. The project was then terminated and the project manager was fired, although he was paid his salary for some months without having to come to work. The total project cost was about 100 m. If you are a Project Manager, then I expect you will have a lot of suggestions about how this project could have been more successful. Here are some Lessons Learned: l

l

The project objectives and specification should be authorized, before the development starts. The business case should be checked again during the project, to make sure that it is still valid.

1.2 What Is a Project? l

l

l

l

3

How the Project’s Product will be tested and who will do it should be included in the plan. There should be continuity during the execution to get the best use of the team’s experience. Executing a project which is out of control takes resources away from other projects. These other projects may be able to use the resources better. People issues are just as important as technical issues, but often not fully considered. For me, the biggest lessons learned are about stakeholders:

l

l

l

l

All Stakeholders should be identified and entered into a Stakeholder Register at the beginning of the project. Of course, company shareholders are also stakeholders and should be represented in some way, usually through senior managers. The Steering Committee should be formed from among the stakeholders according to their responsibilities and influence on the project. If significant or influential stakeholders are excluded or forgotten, they can make it very difficult for the Project Team. The formation of the steering committee should be reviewed regularly in case there are any changes, either in personnel or roles. The project objectives should then be included in the Project Charter and authorized by the steering committee before any significant development takes place.

Reports of projects like this one, which really happened, remind us why we are interested in Project Management. We want to manage successful and profitable projects for our organizations. All projects require investments in time, resources and money and successful projects make these investments worthwhile. The organization must decide which projects will make the most impact, then the Project Manager is charged with delivering the selected project as well as possible. Bad project management increases the risk of uncontrolled costs. These can be caused by wasting not only money but also equipment, materials, effort, time, etc. As project manager you are an important stakeholder. A successful project will improve your reputation and support your career path. If it fails to meet expectations then you can find yourself in a worse position than if you had not accepted the management of the project. For these reasons, at least, it makes sense to use project management techniques.

1.2

What Is a Project?

This is a book is about Project Management so we must start by asking some basic questions: l l

What is a project? What is project management?

4


These are important questions; we need to agree on what we are talking about and when to use project management methods. Projects are important but not everything in life is a project! There are many definitions of a project, which can usually be summarized like this: 1. 2. 3. 4.

A project delivers a result, often a product or service. There are limited amounts of time and money to do the project. A project usually involves a number of people. A project happens only once and is unique.

Let’s look at each of these points and see what they tell us. First, and most important: a project delivers a Result. This is given to the project client and is called the Project’s Product. It is based on a number of Deliverables. Examples include: l l

l

l

Something that you can touch, such as a house which has been built (product). Everything that is needed for a factory to make a new product, such as a new model of mobile telephone. This includes specifications, drawings, licenses, tools, working machines that are ready for use, etc. (process). Everything needed for a company to offer a new service, such as a new type of insurance for company vehicles (service). Proof that something has happened, like a Certificate of Airworthiness for a new airliner, which proves that the airplane has been checked thoroughly and may be taken into service. In business (and particularly in product development) a certificate is a very common type of project deliverable.

We can sometimes understand something better by describing what is excluded. A project is not: l l l

A document or procedure that management makes us use. A quality system, although setting up a quality system can be a project. Operational Work which follows similar methods over an extended period of time, such as manufacturing.

Second, a project has Limits of Time and Money. This is a practical limit. If there were no limits of time or money, we could just keep working, making a little progress at a time and spending money as it became available. Many traditional businesses grew like this and a householder who enjoys gardening also works like this. In any case, applying project management methods to such activities is not worthwhile. Of course projects are implemented in the expectation of getting a satisfactory payback or Return on Investment, ROI compared with other ways of investing the money. However, the project manager’s responsibility is to deliver the project within the authorized costs. The Project’s Product is then handed over to the client or business, which is then responsible for achieving the ROI according to the Business Case. For business projects, there are always limits of time and money and companies try to make as much profit as possible. To do this they need to select the projects

1.2 What Is a Project?

5

with the biggest payback, and then make sure that they deliver on time and within budget. Even very rich companies will not give a project manager unlimited time and money. Each project is in competition with other possible uses of resources and should be the best way to use them; otherwise it should be stopped and replaced by a project which does make the best use of resources. The project Sponsor also needs to be able to change the project during implementation, because something internally or in the outside world may have changed. For example, a new competing product may have been introduced. This happened to many mobile telephone manufacturers when the iPhone was launched. It is also possible that some risk has become reality, such as changed currency exchange rates, making the result no longer profitable in the target market. Imagine that you have a project to redecorate the kitchen and modernize the water pipes. If you are unlucky, the workers might tell you every week that it will cost more and take longer than planned. In this case it might have been better not to start. I know a couple who bought a house with a fine view. They planned to extend and modernize it for their growing family. They agreed the plans with the architect and moved into temporary accommodation so that the building work could start. The architect then said that there was a mistake in the cost estimates, which should have been 40% more. The couple were not happy but finally settled for a more modest extension. Third, a project Involves a Number of People. It is possible to have a “oneperson project”, but then most of the advantages of project management are not relevant. What do you think of the situation where a single person coordinates a lot of external resources and places contracts for work? If the people who are contracted must coordinate with each other, then project management methods are useful. An architect who manages several different trades to modernize a hotel is managing a project, even if he is the only one physically in the office. An office worker who is responsible for purchasing business supplies (paper, photocopier toner, colored pens etc.) is probably not managing a project. Of course it is possible to use the title “project” even though time and money are not important. For example a hobby artist may take a long time to complete a painting, while the cost of the materials is not significant. We will only use the word “project” for more activities which require significant resources. Fourth, a project Happens Only Once; it is unique; it is a once-off activity. Every detail which is happening for the first time takes time and effort to plan. The more a project differs from previous work, the more details need to be planned. A significant part of the project effort must be given to the planning. Just think how many years go into preparing a space shuttle flight which lasts only a few days. The time and effort for planning compared with the execution is very high.

6


Companies often have repeat orders for different versions of the same product but the details of place, people and timing will be different. For example, a manufacturer of trains will have different details for each order, such as: number of carriages, power of the locomotive, type of brakes, internal and external colors, language of the signs etc. There will also be differences in delivery time and location, cost of materials, members of the delivery team etc. which will need to be planned. This type of work is best managed as a project. From Sect. 1.2 of the PMBOK® Guide, the definition of a project is: “a temporary endeavor undertaken to create a unique product, service or result”. l l l

Temporary means that it does not last forever. Endeavor means an effort or undertaking. Unique means that there is only one endeavor just like this. It is once-off.

1.3

What Is Project Management?

Now that we have the definition of a project, our next step is to see what is meant by Project Management. This uses our experience of previous projects to make the current project more successful. We talk about “not reinventing the wheel”. This means that project managers should learn from others. Repeating mistakes is an expensive way of learning but learning from others is cheap, for us at least! Applying other people’s experience is a clever way of getting things done with minimum cost. This is true of project management. Some project managers think that because their project is “unique”, they must do everything as if nobody had done something similar before. This is a mistake because the way we do a project is much the same for any type of project. Do you think that the following steps can be used by different projects? 1. Deciding why you are doing the project and finding out what your limits and requirements are. 2. Planning who does what and when they will do it. 3. Actually doing the project. 4. Checking that everything is complete as planned. 5. Clearing up and making sure that everything is finished. If you have already studied the PMBOK® Guide of the PMI®, then you should recognize these five steps as the Process Groups: 1. 2. 3. 4. 5.

Initiating Planning Executing {= doing, implementing, carrying out} Monitoring & Controlling Closing.

1.4 Global Project Management Standards

7

If this is a good way of doing projects, then we can use it for planning the installation of a new production machine in a factory. Afterwards we can transfer the experience to next year’s project, for example, to introduce a new product range. We can also use this experience for sub-projects and complete programs of projects. Applying this approach to every project helps us to benefit from previous experience. Even better, we can use the experience of others to speed up or accelerate the improvements. While the details of each project are different, the experience about how decisions were made or how risks were kept in control can be transferred from one project to the other. Even if the project really is unique, we can still benefit from previous experience. We are not interested in whether every unique event can be described as a project, but we are interested in practical guidelines about when to use Project Management methods. l

We use Project Management for unique undertakings with limited resources and involving many people. The use of Project Management is not recommended if:

l l l l l

There are no clear Deliverables or they are not defined precisely, or There is unlimited time or money, or There are very few people involved who must coordinate with each other, or What must be done is exactly the same in all details as before, or If the process is described so completely that we must just follow the instructions.

Experience can be transferred from one project to another by using Project Management Processes, which capture the best ways of working. This also leads to the important conclusion that Project Management is a process, even though the individual projects are unique. This is the basis for the entire PMBOK® Guide. Understand this and you have made a very important step towards your PMP® accreditation.

1.4

Global Project Management Standards

This idea of using previous experience makes sense and this is how civilization has evolved for thousands of years. One of the first animals to be domesticated was the dog. It can run faster than man; hunting with dogs was more successful, with less effort required, than without them. The same thing happens today. Managers are always trying to be more successful with less effort! As time went on, the use of dogs spread, eventually worldwide, nevertheless how dogs are trained varies from one place to another. Sheepdogs used by farmers are trained to keep all the sheep together, while guide dogs for the blind are trained to be very calm and sure. Project management also varies from one place to another.

8


In the middle of the twentieth century, companies usually developed their own rules for project management. I once worked for a big old engineering firm which had a large book of project management rules. For example, all engineering drawings were microfilmed and then stored in salt mines in two different continents. This was to secure the information in case of nuclear attack. Each company location had limited daily contact with others, certainly compared with today’s standards. When e-mail became available, the entire factory had only one e-mail address which was operated by the receptionist. Unfortunately one week she was ill and nobody knew the password. When she returned we found out that she used her own name as the password!

The result of the type of environment in the example was that project management procedures were based mainly on internal experience. Although different in detail, they were similar in style to project management procedures in other companies. This is like dog training methods, where the details are different in various places. In such environments, the sharing of experience and incorporation in the procedures was limited. It was very difficult to get agreement to change anything. Experience from outside the company only filtered in very slowly. This approach resulted in each big company having its own procedures and guidelines for project management. This made life difficult for the small supplier companies. Although the bigger companies had the luxury of being able to demand that their rules be used, the smaller supplier companies had different rules for each customer. It is demanding for a big company to have only one set of procedures to work with, but it is very difficult for a small company to meet different procedures for each customer. This extra load in comparison with capacity meant that something had to suffer; the quality, cost, delivery times or profitability. Anyone who has traveled the world will know the difficulties caused by different standards for electricity plugs. Simple items like hair dryers will not work. Either the plug will not fit in the socket or the voltage is different, or both! Much of Europe uses an electricity plug type that was used by a company which was active in electrical installation between the first and second world wars. Even now there are non-electrical differences in the physical shape of a plug, so that a Swiss 2 pin plug will fit in a German socket, but the Swiss 3 pin plug cannot be used outside that country. In India electrification was established under the British Empire. As a result the plugs were at the time the same as those used in Britain – but not the same as those used in Britain today!

1.4 Global Project Management Standards

9

Just imagine the difficulty of working on virtually any international project without some process standardization! The problem of different standards actually became more acute as the telecommunications improved. The PMBOK® Guide provides, for example, common language, which is also in the Glossary. As mentioned already, the index of the book you are reading consists mainly of terminology from this source. The civil (non-military) Critical Path Method, CPM first used at Du Pont and the military Program Evaluation & Review Technique, PERT of the US Navy, both emerged in 1958. They documented an early form of the schedule network which is still in use today. The idea of Project Management as a specialized discipline started around this time and several interest groups began to form, again each one different depending on the background and experiences of the participants. By the beginning of the twenty-first century, several groups and organizations with international interests in Project Management had formed. Some of these published methodologies give specific instructions about how to manage a project. An example of this is the HERMES, which must be used by all organizations working for the Swiss Federal Administration. The purpose here is not to carry out a detailed comparison of these various offerings. Whether they are comparable or not, organizations which wish to improve their project management practice may assess and compare these various approaches. Neither is it the intention to describe the history of these developments, but to select three that have the largest number of followers globally. It is possible to interpret the figures in different ways, but the conclusion is the same: three of the most significant offerings in this area are published by: l

l

l

Project Management Institute, PMI®, established in the USA in 1969. The standard is called PMBOK® Guide, which stands for “Project Management Body of Knowledge”. The International Project Management Association, IPMA. This association was founded in 1965 and has developed into an international network for project management associations. The OGC (Office of Government Commerce) of the British government is the holder of the registered trade mark: PRINCE2®. This was first published in 1989 as Prince: Projects in Controlled Environments.

These organizations and their contributions to project management standards are now described in a little more detail.

1.4.1

PMBOK® Guide (www.pmi.org)

The PMI® was founded in 1969 in the USA and has developed into a global professional organization with over four hundred thousand members and credential

10


holders. It publishes a range of standards related to project and program management, including the PMBOK® Guide, the subject of this book. This guide describes established methods and practices of project management and is an American National Standards Institute (ANSI) approved standard. The PMBOK® Guide was originally released in printed form in 1983 as a Project Management Quarterly Special Report entitled Ethics, Standards and Accreditation. Since then it has been revised a number of times and it is now in its 4th edition, on which the book you are reading is based. It is also available in about a dozen languages, including German, Korean and Chinese.

1.4.2

IPMA (www.ipma.ch)

The IPMA is another leading global professional project management organization. It also acts as an umbrella organization for more than forty national project management associations. The IPMA has a four level certification system based on the Competence Baseline (ICB). This in turn refers to their IPMA Eye of Competence. This includes three broad areas of project management competences: l l l

Behavioural [note the English spelling, not American] Technical Contextual

The IPMA has certified over 100,000 project managers globally in the last decade.

1.4.3

PRINCE2 (www.prince2.com)

The history of PRINCE® has its roots in the software development requirements of the British Government. Just like everywhere else, computing was progressively applied to the administration of government. Anyone in contact with this sector will know that most development is managed as unique projects. These projects must meet the requirements by producing the deliverables, while working within limits of time and money. It was natural that a standard would emerge with the aim of reducing the overall IT (information technology) costs for the British government, which owns the copyright of this methodology. In this it is sometimes much more specific than the other two standards mentioned, which could be better described as frameworks. An interesting feature was the emphasis on Assuring Progress from three perspectives: Business, Technical and User. These concepts are not in the current version. We have already noted that experience in one domain can be transferred to another. A further development was to revise the PRINCE® standard to apply it to

1.5 Index

11

projects in general and not just to IT. This new version is called PRINCE2® and was revised again in 2009. PRINCE2® also has a certification path that aligns with the IPMA. The current version is more flexible than the earlier versions even though it still shows its IT origins.

1.4.4

Selecting a Project Management Standard

The selection of a project management standard by a company is an important decision. It can influence processes, documentation, training and other operational areas over a long time. Each organization or company must make its own decision, which may or may not reference a published standard. It may also be influenced by factors such as: l l l l l l

Is one of the standards more common in our region, country or continent? Which standards are used by our competitors? Which standard is easiest to implement, in view of our existing quality system? Is any standard particularly suited to our industrial or commercial branch? How available is documentation and training in our language? etc.

At the time of writing there is no global standard, although the International Standards Organization, ISO is working on ISO/WD 21500 Project management – Guide to project management which is due for publication in 2012. All of the significant project management organizations are contributing to this new standard. The published standards all have similarities, the same way that different makes of cars look much the same. Which standard an organization selects for implementation is an important management decision, which is outside the scope of this book. Although there are no right and wrong decisions, it is important that the company adheres to the selected project management methodologies and implements them consistently. From now on, this book relates to the PMBOK® Guide only.

1.5

Index

Assuring Progress Business Case Closing Critical Path Method, CPM Deliverable Executing Initiating International Project Management Association, IPMA International Standards Organization, ISO

IPMA Competence Baseline IPMA Eye of Competence ISO/WD 21500 Lessons Learned Monitoring & Controlling Operational Work Planning PMP PRINCE PRINCE2

12 Process Groups Program Evaluation & Review Technique Project Charter Project Management Project Management Institute, PMI Project Management Processes Project Manager Project Team

1 Introducing Project Management Project’s Product Return on Investment, ROI Sponsor Stakeholder Stakeholder Register Steering Committee Terminate

Chapter 2

Understanding the PMBOK® Guide


l

l

l

l

l

The PMBOK® Guide is a guide rather than a methodology and the difference is explored. This section also summarizes some important points which should be remembered when applying the PMBOK® Guide. The four section structure of the PMBOK® Guide is described and the reader learns how to navigate this large book. Chapter 1 of the PMBOK® Guide introduces project management and places it in the context of program and portfolio management. It is based on the experience of a large number of project managers globally and is therefore very practical. The different types of Project Management Office are mentioned. Chapter 2 of the PMBOK® Guide focuses more on the organization which executes the project and manages it through the project life cycle. When a project is finished, the team disbands. Chapter 3 of the PMBOK® Guide goes into more detail about the central theme; projects, although unique, are best implemented by using standardized processes. As experience increases the processes can be improved, to the benefit of future projects. Chapters 4–12 describe the nine Knowledge Areas and are followed by some useful appendices.

2.1

What the PMBOK® Guide Is

In this chapter we narrow our focus from all the possible project management standards to one: the PMBOK® Guide. In its own words: “This standard is a guide rather than a methodology.” (See Sect. 1.1 of the PMBOK® Guide.)1 Figure and table references with hyphens are to the PMBOK® Guide.

1


13

14

2 Understanding the PMBOK® Guide

What is the difference between a Guide and a Methodology? Simply stated, a methodology tells you exactly what to do, with specific methods and terminology. This is like a recipe for baking a cake, which tells you the exact amount of ingredients needed, which temperature to use and how long to bake. It details how to prepare the ingredients, so that what you cook is just like what is in the photograph. On the other hand, a Guide suggests what to do. This is what we expect from the title of the PMBOK® Guide. Guides are less specific than methodologies in telling you how to do something, in this case how to manage projects. The following points should help you understand the PMBOK® Guide: l

l

l

l

l

It is a complete reference model of project management, based on 42 processes, drawn from global experience in many sectors. As a result it is generic and is for general use in all types of projects and in different branches. It is a guide which “summarizes.....good practices on most projects most of the time” (see the introduction to Chap. 1 of the PMBOK® Guide). It does NOT give detailed instructions, nor does it mean that you have to use ALL of the processes ALL the time. The Project Manager together with the team should decide what and how much to apply in a particular situation (see the Introduction to Chap. 3 of the PMBOK® Guide). Its application is not uniform in all situations, but specific to each project. It is self-consistent and complete. If you read it from beginning to end, you will find that it is integrated and the internal references match. It combines the experience of thousands of project managers in different sectors around the world, so it is very practical. It is not “theoretical”. It does not replace your company processes but provides standard language and environment for them. This makes a unified approach to project management possible among all organizations which use it.

The PMBOK® Guide has been revised several times and each time it has become more mature. During the preparation of the 4th edition, much effort was made to improve consistency, both internally and with regard to the other standards of the Project Management Institute. The PMI® has also developed so-called Extensions to the PMBOK® Guide for particular sectors. These describe in more detail the processes for specific sectors, such as the Construction Industry or (American) Government. Again they are guides and this makes them more generally applicable than a methodology which tells you exactly what to do. In summary: l l

l

The PMBOK® Guide describes projects in a unified way with standard vocabulary. It is based on Project Processes, which is a successful model for project management. The project manager and team must decide how and how much to apply these processes in each project according to the situation.

2.2 The Format of the PMBOK® Guide

2.2

15

The Format of the PMBOK® Guide

Now we are ready to actually look at the PMBOK® Guide and understand its structure. To use a dictionary in alphabet-based languages, it helps to know the order of the letters. In the same way, the background ideas we have discussed help us to interpret the PMBOK® Guide. This is a good time to open your copy, so that you can refer to it in connection with the notes below. The basic structure of the PMBOK® Guide is four parts (sections) which use Latin numbers: Table 2.1 The sections of the PMBOK® Guide Title Contents Section I (¼1) The Project Management An introduction to project management, life Chapters 1 & 2 Framework cycles and organization. Section II (¼2) Chapter 3

The Standard for Project Management of a Project

Section III (¼3) Chapters 4–12

The Project Management Knowledge Areas

Section IV (¼4)

Appendices

2.2.1

This section is THE STANDARD – understanding this makes it easier to pass the PMP® examination. It describes the project from the viewpoint of Process Groups and defines when certain activities or processes have to be executed. Descriptions of each of the 42 processes, which are discussed in Chap. 4–12, covering nine Knowledge Areas. Think of it as similar to a dictionary; a list of descriptions in formal language. Being familiar with the details of these 42 processes is essential for passing the PMP® examination. Changes to and the history of the PMBOK® Guide, as well as a useful Glossary of Terminology. There is also some material not specifically related to any of the main content, such as a section on Interpersonal Skills.

Overview of Chapter 1: Introduction

The introduction to the PMBOK® Guide covers much of what we have already described about the purpose of the standard, what a project is and what project management is. It also states that the standard focuses only on Projects, although it interacts with other important aspects of organizational work such as: l

Operations Management, which is repetitive in contrast with Projects which in principle are unique. Of course the main work of many organizations is the implementation of projects and they are often similar to each other. Under these

16

l

l


circumstances, the dividing line between projects and processes is not absolute. The better the processes, the less detail project managers must plan for each individual project. Program Management: management of groups of related projects. An example program is given at the end of Sect. 1.4.2 of the PMBOK® Guide: A new communications satellite system with projects for design of the satellite and of the ground stations, construction, integration and launch. Portfolio Management: management of projects or programs which are “grouped together ...to meet strategic business objectives” (See Sect. 1.4.1 of the PMBOK® Guide). One way to think of this is that all projects, or programs, funded from one high level budget form a portfolio. An example is that all the Asian projects of a company can form a Portfolio, whether or not they are related to each other technically or commercially.

Projects are one way of implementing strategic organization decisions. Several measures may be identified which will develop the organization in the selected direction. These measures can then be implemented as projects. Of course projects should be designed so that they also target program and portfolio objectives, as well as project level objectives. Projects need to keep all the data they generate under control. This includes what activities are assigned, the contact details of all people involved, when purchases were paid etc. The organization or function that looks after the administration of the project is called the Project Management Office, the PMO. Depending on the organization, there may be a PMO which has a project management role. For example, a PMO can employ project managers who manage projects for other departments. The PMO may also have a role supervising projects and ensuring Compliance, managing project resources, coaching project managers and maintaining organizational project management standards etc. The detailed project information is stored in the Project Management Information System, PMIS. For any but the smallest projects, the PMO is responsible for maintaining this data. This chapter also describes the role of the Project Manager, whose job it is to achieve the project objectives. The project manager is responsible for everything. Especially when the organization has less developed process and project management maturity, the project manager must ensure that proper project processes and organization are established. In extreme situations, the Project Management Maturity in the organization is so low that the project manager must set up all the structure and define the processes himself. Unfortunately this often leads to the overloading of the Project Manager while the sponsor has unrealistic expectations; a dangerous combination. In situations like this, it may help the project manager to refer stakeholders to the independent authority of the PMBOK® Guide. Finally there is a reference to Enterprise Environmental Factors, in other words all the background issues which could affect the project. The list provided in Sect. 1.8 of the PMBOK® Guide is very complete. In practice even more stressful


17

situations than those described there can occur. For example, the last project manager has just been fired and the expectations of management towards the new project manager are particularly high.

2.2.2

Overview of Chapter 2: Project Life Cycle and Organization

This chapter focuses more on the projects themselves, starting with the Project Life Cycle. This is the term for all the phases of a project, starting when the ideas are being collected, through the planning, executing and closing. Figure 2-1 shows in effect the level of activity at different stages. There is a view that the start can take much longer than in the graph, but the important point is that the level of activity varies and finally reduces to zero. A similar shape is used if the amount of money spent per month is shown, the so called Burn Rate, by analogy with the use of fuel by a rocket. The Project Life Cycle must not be confused with the Product Life Cycle. For example the project life cycle corresponds to the development of a new product, such as a new model of a car. Then the car will go into production and may be made for years or even decades. Finally there may be a period when only spare parts are produced while no new cars are made. After this the product life cycle is finished. Clearly the project life cycle forms only part of the product life cycle. Stakeholders are the people who have an interest in the positive or negative effects of the project. They can be inside or outside the organization (See Sect. 2.3 of the PMBOK® Guide). It is extremely important for project managers to find out who the stakeholders are, because their attitudes have a big influence on the success of a project. The potential influence of stakeholders reduces as the project progresses because the project becomes more concrete and there is less that they can change. This is shown in Fig. 2-2. On the other hand, the cost of project changes increases with time. It is easy to make changes on paper before plans have been fixed, but much more difficult and expensive later on when the project is being executed. One of the most important stakeholders is the Sponsor. The PMBOK® Guide uses this term for the person who is responsible for assigning resources to or controlling the budget for a project. When this is shared by a number of people, we can talk of Sponsorship instead of a single Sponsor. The term Sponsor is preferred to Owner, Originator etc. that are sometimes used. The concept of phases is widely known and used wherever project management is used. A Project Phase is a section of a project in which specific major deliverables are delivered. In principle, phases are completed one after the other. This allows the stakeholders, in particular the sponsor and project manager, to review the situation before moving on to the next phase. This review usually includes: l l

A report about the progress of the project Detailed plans for the next phase

18 l l l


The high-level plan for all remaining phases Assumptions, which may of course have changed etc.

When everything is agreed, the project is authorized to continue to the next phase. This is an example that also defines how the project is controlled. This is called Project Governance. It is sometimes said: “Choose the right project, then execute the right project right, or correctly.” Choosing the right project is a governance issue. Doing it right is a project management issue. The project execution may be divided into several phases. For example the design and construction of a ship could be divided into the following phases: l l l l l

l

Design the ship Build a model and test its performance Build the ship Fit (add in the equipment, furniture etc.) Commission (check that the engines and navigation equipment are in working order etc.) Handover to owner (final acceptance checks).

These are phases because they happen one after the other and each finishes with deliverables. Working in phases reduces the risk that the project will either not deliver or deliver something which is not needed because the environment has changed. To see why this is so, imagine an experienced project manager who convinces management that everything is under control. All he needs is 12 months and $10 million to implement his project. We can summarize the situation for the project manager like this:

Give me $10 million and a year to deliver the project – just let me do it.

Of course $10 million is a lot of money and a year is a long time. Anything can happen during this time, for example the exchange rate changes, a stock market crisis, an earthquake etc. It is risky to plan long and expensive phases, not because the project manager is not good but because circumstances may change. The project manager can reduce the risks by dividing the project into shorter, less expensive and less risky phases. Setting Milestones along the way, in particular for the end of each phase, is much less risky. We now tell the project manager: You have 4 weeks and $50,000 to plan the project, then you must come back with the updated plan for review before going further.


19

Dividing the project into shorter, less costly phases reduces the project risks significantly. A project is an investment and the sooner it is delivered, the quicker the payback. How much this matters is particularly important in Product Development. The company which gets to the market first with a new product can charge high prices and pay back the development costs, until the competition catches up. Being late can mean lost potential income or even going out of business. Depending on the sector and type of project, a phase can begin before the previous one is finished. This can increase the overall benefit, even if there is some rework and extra costs. Starting a phase before the last one is finished is a business decision. In such cases, the risks can be reduced by extensive communication between the various participants. Long ago, before e-mail and mobile phones, project phases were often carried out with very little communication with other parts of the organization. In this environment it made sense to complete one phase totally before starting the next. Depending on the industry this may or may not be possible. A new car design is checked thoroughly before it is put into production because the tooling costs are very high. A building should not be built until the design is complete and checked. In other sectors such as software development, overlapping the phases is much more common or even essential because it can actually reduce the overall Risk. The Organizational Environment has a big influence on projects. Much depends on the organization, such as how managers use their power, channels of communication, formality or informality etc. It is easy to see that the practice in a railway, a hospital and a software company are totally different. This affects how resources are allocated and decisions are made, how much power the project manager has and many other details of project management. The technological environment is also relevant. For example the approach to the requirements identification in software development is different from that in an engineering company which builds bridges and highways. As well as being influenced by organizational style, a project is very strongly influenced by the structure of the organization. For example, in a functional organization, line managers are powerful compared to project managers; projects will find it more difficult to get priority for resources. At the other extreme in projectized organizations, the organization structure matches the projects, which get priority as a result. Figures 2-7–2-11 show a progression from Functional to Projectized Organization types. The next section introduces a term which we will find often: Organizational Process Assets. This name emphasizes that the Processes of an organization are also assets. They take time and money to develop and contain the know-how of the organization, whether documented or not. These assets are the processes that allow the organization to deliver projects and may include for example:


20 l

l l l

Procedures and guidelines which explain how particular processes should be used Templates Procedures for managing changes: Change Control Procedures Corporate Know-How and experience from previous projects, such as risks, costs etc. as contained in databases, files and archives.

2.2.3

Overview of Chapter 3: Project Management Processes for a Project

This part of the PMBOK® Guide represents the project management standard. It expands the description of projects based on processes, as well as showing how these processes are related to each other. Let us go back and look at the idea of project processes in more detail. In any project, the manager must use the resources and interactions to achieve the goals. However: l

l

Projects are unique, non-repetitive, once-off activities. This means that we cannot expect everything to go to plan, because some things are being done for the first time. When something does not go to plan, it often costs more money or delays to bring the project back on track.

It is not easy to control project costs, because nearly everything that does not go according to plan affects costs. This is especially challenging for project-based businesses. They cannot survive if project costs are consistently higher than planned. In the long term, these unplanned costs could threaten the viability of the business case. To reduce negative effects, we can learn from previous similar projects. This results in more accurate and reliable project plans. This experience is incorporated in the project processes, which can be used repeatedly for different types of project. New experience can be used to continually improve the processes, making sure that it has a long term effect. Even when projects are completely new, we can still apply some earlier project experience since they often follow similar patterns. For example, we know that it works better to use phases. We can design our new projects in phases, even if everything else about the project is new. This will make it less likely to fail because we are using previous experience. Some people object to this and may say: Our business is different from all others so we cannot learn from them – we have to do it our own way.


21

We answer: Yes, of course the technology, methods, business etc. are special or unique. That is true of all projects. You can however use general project methods and so benefit from the experience of others.

We apply previous experience by using Project Management Processes. If we use the same method to divide a project into phases every time, this is a process. A Process is repetitive, just like Operational Work. Although projects are unique, we can manage projects by using processes because this makes them much more likely to be successful. This approach is central to the PMBOK® Guide description of project management. At the highest level the project processes do not depend on technology. For example “identifying who the stakeholders are” is human activity, not a technical task. The PMBOK® Guide details this top level of project management but also refers in outline to lower level technical processes, which each organization must then develop in detail for itself. It makes sense to align these company-specific practices with the higher level PMBOK® Guide processes, because this gives a standard basis for communicating and cooperating with other companies, suppliers and organizations. Speaking the same “project language” reduces the chances of costly mistakes. As an example, a company implementing the PMBOK® Guide could reword its processes so that they refer uniformly to “Sponsor”, instead of owner, originator, etc. There are other advantages, for example we can benefit from a pool of experience when recruiting project staff – new recruits do not have to learn absolutely everything from the beginning if they are already familiar with the PMBOK® Guide. Before global standards for project management existed, each company had to develop its own standard and train everybody, including suppliers. The benefit from external experience was generally limited. Another way that processes are sometimes described is “learning from the mistakes of others”. It is clever to see where others have learned and to copy them. This can be very attractive for businesses, because others pay and we benefit! This is what the PMBOK® Guide does; it brings together project management experience from various industries so that we can use it. It is not “unusable theory”; it is “usable practice”. To summarize some important conclusions: l l

l

l

Projects are unique, once-off efforts. Projects are best managed by applying the same (or similar) processes to each one, in order to exploit the learning effect. At the highest level, these processes are generic to all project management and are not specific to a particular line of business or technology. We can always profit from the experience of others.


22 l

l

Some of the process details at higher levels and everything at lower levels will usually be specific to a particular organization. They will reflect the particular environment and technology. There are strong advantages, particularly in a global economy, of using a standard scheme for project processes. The PMBOK® Guide is such a scheme. The PMBOK® Guide processes all have the following features:

l

l

l

Inputs: items that must be available to the process so that the Tools & Techniques can be applied. Tools & Techniques: Methods of working. This is much broader than just IT Tools and Techniques. For example the use of Phases is a technique, but it may be implemented without any supporting IT. Outputs: items that are delivered by a process. Note that the Outputs of a process are very often the Inputs of other processes.

l

l

Chapter 3 of the PMBOK® Guide describes how the 42 processes interact and fit together. Chapters 4–12 take one Knowledge Area at a time and describe the relevant processes.

2.3

Exam Aids

Flash Card Terms Burn Rate Change Control Procedures Compliance Construction Industry Enterprise Environmental Factors Extensions Functional Organization Government Guide Inputs Methodology Milestones Operational Work Operations Management Organizational Environment Organizational Process Assets Outputs Portfolio Management Process Groups Product Development

Product Life Cycle Program Management Project Governance Project Life Cycle Project Management Information System, PMIS Project Management Institute, PMI Project Management Maturity Project Management Office, PMO Project Management Processes Project Manager Project Phase Project Processes Projectized Organization Risk Sponsor Stakeholders Tools & Techniques

Chapter 3

Process Groups and Knowledge Areas


l l l

l

Each of the 42 Project Processes is grouped in Table 3-1 according to two dimensions: Process Groups: when the processes are typically used (columns). Knowledge Areas: why they are used (rows). There are five Process Groups, such as Planning and Executing. Process activity is not restricted to the timing suggested by the Process Group titles. Note that the titles are similar to typical phase names; however Phases and Process Groups are different concepts and the distinction is explained. There are nine Knowledge Areas. They include topics such as Cost Management, Time Management and Quality.

3.1

What Are Process Groups?

We now take a closer look at how project management is mapped into 42 reference processes and summarized in Table 3-1 of the PMBOK® Guide. The five column titles are the Process Groups and the nine row titles are the Knowledge Areas. Each process is in one Process Group (when it is typically used) and one Knowledge Area (why it is used). Each process is described in detail in Chaps. 4–12, with Inputs, Tools and Techniques and Outputs. We look first at the Process Groups, which are called: 1. 2. 3. 4. 5.

Initiating Planning Executing Monitoring and Controlling Closing


23

24

3 Process Groups and Knowledge Areas

Processes used mostly at the beginning of a project are in the Initiating Process Group. Processes used mostly during planning are in the Planning Process Group and so on. This is just like taking Lego® blocks and sorting them by color into different storage boxes. Figure 3-2 shows a graph for each of the process groups and when they are usually active. The distribution of processes among the process groups is worth examining: l

l

Most knowledge areas have processes in both Planning and Monitoring & Controlling process groups. This is what we expect: we monitor and control what was planned. Both Initiating and Closing have only two processes each. This reflects the fact that the work involved is limited, at least in comparison with the big effort of planning and execution.

Are process groups and phases the same thing? No, see Sect. 2.1.3, PMBOK® Guide. Even so, the names of the process groups sound like typical phase names, while they are used in a completely different way. The differences between Process Groups and Phases are: l

l

Phases are, as we have seen, stages of a project that are usually executed one after another. At the end of each phase the Sponsor (or the business) expects to get particular deliverables, the chance to influence the direction and to decide if the project continues. Process Groups are groups of processes, each of which can be used at any appropriate stage in the project life cycle, not just when suggested by the process group name.

Take, for example, the Identify Stakeholders process in the initiating process group. Although this process is mostly used at the start of a project, it can be reactivated again later if something changes. This is different from Phases, which are executed consecutively. Imagine now that a project stakeholder is promoted to a new job during the project. The replacement person may have different priorities and this can affect the project. When this happens the process Identify Stakeholders must be reactivated, even though it is normally associated with the beginning, the Initiating. The new stakeholder may even be uninterested in the project, which increases the risks. One way of thinking of a process is like a sleeping dog. Its job is to bark if somebody comes to the house, otherwise it seems to be asleep. As long as nobody comes, it is inactive; it does nothing except watch. When something happens or somebody comes, it starts barking. A process always has a trigger (Inputs) and produces something (outputs). Remember that because of the iterative nature of the PMBOK® Guide description, the processes and process groups can be applied at any level, such as subproject or phase, and not just at project level and this is another difference between a process group and a phase. For example, a project to build a new airplane could have a sub-project to build the wings. A sub-project also needs to identify stakeholders and they may also

3.2 Overview of the Five Process Groups

25

change during the execution. In the same way Planning is required for the sub-project, as it is for the project itself. A Process may also be used at a higher level. A program (group of projects with related objectives) also needs initiating and closing. Program Management is a large topic in its own right, for which the PMI® publishes The Standard for Program Management, which is consistent with the PMBOK® Guide. We are now ready to look at each of these Process Groups in detail.

3.2 3.2.1

Overview of the Five Process Groups Initiating Process Group

Initiating involves defining and authorizing a new project or phase. Do we know that we have understood correctly what the sponsor and other stakeholders want? Are we sure that the expectations are realistic, for example regarding delivery time or costs? Unless a project manager makes sure that what the sponsor expects and what will be delivered are the same, the project will be in difficulties right from the start. To avoid a false start, this can only be addressed systematically by processes to clarify these issues, which are applied before the detailed planning begins. If the expectations do not match, we must get agreement to change the deliverables, constraints or other parameters, such as What? When? Who? How much? Alternatively we can try to change the expectations. Project initiating has not always been emphasized. Many project managers report that planning or even execution starts as soon as management delegates a project. This is as if a gun is fired using the sequence “ready, fire, aim” instead of “ready, aim, fire”. During Initiating (remember this is a process group – we do it every time we start a new project, phase, work package, sub-project etc.) we find out or decide: l l l l l l

who is interested in the project (stakeholders) what they want whether it is realistic what the risks are that even this early are visible assign the project manager or responsible person establish the envelope or limits of the time and money budgets, etc.

In particular the very existence of the project is confirmed. In businesses which execute one project contract after another (such as construction companies) it is usually easy to see when a project starts because a contract is signed. On the other hand internal development projects often take much longer to crystallize and start. For example, a service company deciding to move office may take a year or two before it becomes a project. The ideas are discussed slowly and it is often not easy to see when exactly the project begins.

26


This is relevant because possible team members will often not be allowed by their operational or line managers to do project work until the project has been authorized. The operational business requires maximum effort and this cannot be diverted informally into other (project) work, particularly if this causes missed deadlines for non-project work. Based on my experience, Initiating is one of the areas of project management where there is most room for improvement.

3.2.2

Planning Process Group

Planning involves working out in detail how to implement a project (or phase, subproject... etc.). During planning we try to “balance the competing project constraints” of “scope, quality, schedule, budget, resources and risk” (Sect. 1.3, PMBOK® Guide). The processes in this process group can be active throughout the project, particularly if something significant changes, after the main planning has been completed. Less mature project management organizations sometimes think of the Project Plan as a schedule, a time plan or a bar chart, also called Gantt Chart after the person who invented it. The schedule is only a part of a full project plan. The other elements are developed by applying the 20 processes of this process group, resulting in plans for Time Management, Cost Management, Human Resource Management, Quality Management etc. Several of the Knowledge Areas refer to Management Plans, of which the first is from the Develop Project Management Plan process. These plans emphasise how a particular area is to be planned and managed, as distinct from how it is executed. For example, the Quality Management Plan describes how the issue of quality is to be managed. The actual implementation of quality management is covered by two other processes (see Chap. 8). Project planning is both an iterative and a proactive process. This means that some details are fixed during the initiating and details of the plan are worked out on this basis. This in turn uncovers more detail which affects yet more details etc. Sometimes new limits or constraints emerge which conflict with the existing plan. In this case, we need to iterate, until the overall plan is stable and realistic. It is very important, but sometimes overlooked, to plan how and when major decisions will be made. It could also be argued that this belongs to initiating. Good decision-making with the full support of the stakeholders contributes to project success. The stakeholders usually include senior managers who are very busy people. To make sure that they are available when needed, it makes sense to plan the dates of the decision-making meetings, such as phase closure. This ensures that they can participate to support the project manager. These meetings are called by different names such as Phase Exit, Milestone, Phase Gates, Decision Gates etc. These milestones can also be linked to

3.2 Overview of the Five Process Groups

27

authorization of payment for specific deliverables. This is one area where the terminology is not standardized across industry.

3.2.3

Executing Process Group

Executing also has several common alternative names, including Implementation and Realization. What it means is simple enough: doing the core work of the project and delivering the deliverables. Executing is usually the part of a project (subproject etc.) where most of the money and resources are spent. Initiating, Planning, Monitoring & Controlling and Closing (the other four process groups) also use resources, but the largest share is usually used for Executing. The Executing Process Group does not have as many processes as you might expect. This is because much of the execution activity is in the technology or business processes of the company, not in generic PMBOK® Guide processes.

3.2.4

Monitoring and Controlling Process Group

This Process Group is active from the beginning to the end of the project, and particularly during the Executing. It concerns the tracking, regulating and monitoring of the project work. Change Management is also important, because adjustments will always arise, either in reaction to changed circumstances or to clarify what the project should deliver. Taking Corrective Action to take account of unplanned changes is also included. Project Reporting is also included. This is often not liked by project managers who say “I only have enough time to do the project – I do not have the time to write big reports about it”. It is necessary to inform the sponsor and stakeholders regularly about the project progress. The scope of the PMBOK® Guide is limited to Project Management and excludes Program Management, although they are related to each other. The Program Manager reads the project manager’s reports with interest, and this makes it easier to support the project. If there are conflicts, for example with another project which wants to use some special equipment at the same time, the Program Manager has enough information to decide the priorities. Without regular reporting the Program Manager is blind and this makes it much harder for him to support the project manager. There are ten processes in this group, corresponding to the planning processes in all knowledge areas, except Human Resource Management. The reason for this exception is that the team performance evaluation is continuous, being done in the Executing Process Group. A few words about the process group name: the word monitoring is passive; it means looking to see what is happening. Controlling is more active; doing

28


something about what we see: steering. In some languages (such as German and French) the words related to “control” mean what in English is called “monitoring”. In order to cover both aspects, this process group is called Monitoring and Controlling in English.

3.2.5

Closing Process Group

Closing finalizes formally all activities of every project, phase, sub-project and even process. This includes, for example, proper archiving of all documentation and the release of the project team to work on other assignments. One of the most important parts of closing is the last chance to review how well the processes worked. The experience gained provides feedback to improve them. This is an essential feature of the PMBOK® Guide process model for project management, as it results in Continuous Improvement. This helps ensure that next time we can repeat whatever worked well, while avoiding what did not work well. A colleague once said to me that the trick is not so much “getting excellent results using only gifted people” but “getting excellent results with excellent processes and normal people!” After all, taken together, the project team is “average”. The processes are developed and improved step by step based on experience. When they are first written down there will probably be quite a lot of detail which is good, but not perfect. As time goes by, the processes are gradually improved. Applying these processes can give even better project results than those which are achievable otherwise, even by the experts who wrote the processes. They consolidate the experience of different generations. This is normal. Like Initiating, the idea of formally closing a project was not very much emphasized previously. This is now regarded as a lost opportunity, because without formal closing processes: l l

We miss the opportunity to learn We risk making the same mistakes next time.

Although this is time consuming, the knowledge gained during closing will increase business efficiency. Even so, closing is often forgotten in the rush to start the next project. One example I saw in a research laboratory resulted in the experimental note books not being archived. Sometime later, when it was decided that the earlier results would be interesting after all, nobody could find the note books. Six months’ work had to be repeated, not to mention the business costs of being later to market.

3.4 Overview of the Nine Knowledge Areas

29

In my experience, Closing is another area of project management where there is often room for improvement.

3.3

What Are Knowledge Areas?

Now we move on to the Knowledge Areas. We saw above how the 42 project management processes can be grouped into five Process Groups. Now we sort them again, this time into the nine Knowledge Areas, covering all of project management. They are in Chaps. 4–12, the same numbering as used in this book: l l l l l l l l l

Project Integration Management Project Scope Management Project Time Management Project Cost Management Project Quality Management Project Human Resource Management Project Communications Management Project Risk Management Project Procurement Management

This classification is very comprehensive and is based on the experience of thousands of project managers. Even so, it is possible that future editions will adjust this list. For example, we could propose a knowledge area for Project Legal Management. Legal issues include contracts of employment, contract termination for providers and intellectual property management etc., even though these topics are mentioned in the nine Knowledge Areas. If you want to suggest changes, you could volunteer to work on one of the PMI® committees, which revise the standard every 3 years or so.

3.4

Overview of the Nine Knowledge Areas

We will now review the main points of each Knowledge Area, so that when we read the standard in more detail, they will make sense for us. Each of the Knowledge Areas is described at the beginning of the corresponding chapter in the PMBOK® Guide, followed by details about the processes. For each process there is a general introduction, then three sections: l l l

Inputs Tools and Techniques Outputs

You should be able to select a Process from Table 3-1 and then find it in the Chaps. 4–12. When you have found it, look for the sections on Inputs, Tools and Techniques and Outputs.

30


3.4.1

Project Integration Management

Integration Management means making sure that every process and project management activity is identified, defined, combined and coordinated within the Process Groups. It helps us to ensure that the project is treated as a whole, rather than as a collection of independent actions. It is a strength of the PMBOK® Guide, which was not emphasized as much in previous times. The project manager is responsible for making the project deliver according to its charter, and also for making sure that everything is integrated. A project manager cannot know everything there is to know, so he depends on the project team and processes to be aware of what is happening. One example relating to integration management which I saw was the installation of mobile telephone exchanges in central Asia by a team of European engineers. The team was completely self-contained, bringing with them all possible tools and information, to save time if something needed to be repaired. The project manager even negotiated the lodgings for his team. Sometimes he had to make changes when problems occurred, either between the team members or the team and the host, to ensure smooth working of the project. The processes described in Project Integration Management are not original, but by grouping them together, the PMBOK® Guide is emphasizing the importance of integration.

3.4.2

Project Scope Management The concept of Scope means “what is in the project” and, by extension “what is not in the project”. This can relate to

l l

Either the Project’s Product; what the project delivers. Or what work needs to be done to complete the project.

Managing scope can be difficult because it is not always visible, unlike delays and costs, which are usually watched carefully by management. As a result there is a tendency to ask for scope increases, while expecting them to be delivered without an increase of resources. The approach is to agree on the scope with the stakeholders, then deliver only what is agreed. Anything more is called Gold-Plating. Why not deliver a bit more than what we agreed, to “surprise and delight” the project customer? Such thinking is widespread in service management, on the assumption that the customer appreciates a little extra and hopefully comes back again. The PMBOK® Guide has a different way of thinking. A project is achieved by getting a very fine balance between all the elements such as deliverables, cost,


31

delivery time, risk etc. Delivering a little more could effect the risks significantly, without client agreement. In the same way reducing the resources without changing the scope is not recommended:

As a result of cost cutting, a project sponsor once told the project manager that his budget was cut by 10%. He asked where the scope should be reduced, to be told: “I am sure you are such a good project manager that you can accept this change without affecting anything else”.

It is better to deliver what was agreed than to change some detail, such as risk, without agreement of the stakeholders. The PMBOK® Guide addresses these issues by including the Project Scope Management knowledge area.

3.4.3

Project Time Management

Project time management is probably the one knowledge area which everyone would think of, if they were writing the PMBOK® Guide. Why is this? In the older editions, there was a concept of triple constraint: projects are limited by conflicting demands of time, money and scope. Somebody once said: “You can have it good, cheap or quick. Which two of these do you want?” Although the triple constraint has now been replaced by the idea of balancing the demands of several knowledge areas, it is useful for us here. We have already discussed scope above and let us assume that it has been fixed. In other words, what the project includes and excludes has been agreed. This leaves us with two other parameters of the triple constraint: time and cost. Usually in business, money cannot be spent without authority. For example the production manager of a factory may be installing some new equipment. It would be unusual for him to be able to purchase it without the signature of his manager. This is a good system because it means that the production manager will benefit from the involvement of his manager, who will ask hard questions based on his experience before signing. Time, on the other hand, can be spent without authority. I once worked in a company where long coffee breaks were normal. Nobody seemed to need permission – it just happened. Even if we were told to take shorter breaks, we could still have taken the usual long ones. If management demanded an explanation we would excuse ourselves and probably do the same the next day.

32


In general: it is easier to use time without permission than to use more money without permission. Of course everything is important, but if one project parameter is given priority, it is very often time. Some project managers even take the view that they do not need to emphasize cost management because it will “automatically” be watched by the finance community. Project Time Management includes all the scheduling tools that project managers use, such as bar (or Gantt) charts, schedule networks, time estimation etc.

3.4.4

Project Cost Management

This knowledge area has no surprises: project costs must be carefully planned and controlled. It is one area of project management for which there is, almost certainly, an existing method in every organization, whether it is project-driven or not. Despite this, we should not think of the PMBOK® Guide processes as replacing existing ones, but as providing a standard point of reference. In simple terms, the project team estimates the costs, then gets them approved in the budgeting process. Finally the costs are controlled with reference to the approved budget costs. Costs are particularly demanding to manage because they can be affected by any project change.

3.4.5

Project Quality Management

Readers who have been introduced to the principles of quality management will recognize nearly everything in this Knowledge Area. The message here is that quality should be built into the way we do projects, but of course this is true for all business processes. Quality Management applies (see the introduction to Chap. 8 of the PMBOK® Guide) to both l l

The management of the project. The Project’s Product, the outcome of the project. The highlighted example illustrates the first of these two topics. The project manager had a small team. He told them that there would be a weekly meeting, every Monday afternoon. The first week everyone was present. The second week the project manager knew he was going to arrive late and telephoned ahead to ask the meeting to start without him. The third week he said he could not attend and delegated the meeting chair to one of his team. Unfortunately he did not brief this person about everything and in any case the manager did not want to delegate. The fourth week the manager did not come to the meeting and just told the team that he was “unavoidably engaged”...


33

Is this a high quality of Project Management? Probably not. Even so the Quality Management Knowledge Area gives a feeling (to me at least) that it is mostly about the quality of the product of the project. Looking back in time from a western perspective, quality was “discovered” relatively recently. The quality of Japanese cars, for example, was and continues to be competitive compared with some names that are maybe better not mentioned. The Quality Management Knowledge Area reminds us that “quality is planned, designed and built in and not inspected in”. This means that quality is not achieved by making the product, then inspecting the parts to find that they do not meet the quality standards. I once worked in a computer factory which made standard models. As the orders came in from different countries which needed different keyboard layouts, the manufactured items were taken apart and then re-assembled with the right keyboard. It is hard to find the value-add of this process and I hope that such practices have long since gone! In spite of this, there are processes where substandard parts are sold more cheaply (or sometimes, even more expensively!). An example is the manufacture of computer chips, where the good parts are sold with a different name from cheaper parts with lower performance.

3.4.6

Project Human Resource Management

It is refreshing that Human Resources attract the status of a knowledge area in the PMBOK® Guide, because this is not so for all project management standards. After all, some other important areas are hardly mentioned (for example Intellectual Property Protection, which although mentioned a few times, is not given the prominence of Human Resources). Even so, some will argue that human beings cannot be forced into processes. While there may be some sympathy for this point of view, consider the highlighted recruitment situation. A large company established a new project for which special skills were needed. To bring them into the company it was decided to advertise externally and appoint new staff. This was done using the recruitment process: Describe the position, authorize the post, advertise, short list the applicants, interview a chosen few, offer the position to the best candidate, tell the other applicants that they have not been chosen. This is surely a process in the area of Human Resources.

34


There is one more related topic which is in the PMP® examination but not covered by a Knowledge Area. It is Professional and Ethical Behavior and is introduced in Chap. 13. Of course, how ethics are interpreted is not universal; what is totally unacceptable in one country is normal in another. An example that relates to this topic is that all member countries of the European Union are required to abolish the death penalty, while it is accepted as normal in the USA. Perception of what is ethical also varies over time, as is illustrated in the report about expenses for politicians. During 2009 there was a series of resignations from the British Parliament, following the discovery that some politicians had claimed expenses for dubious purposes. One for example claimed for hiring sex videos for her husband. Despite all the discussion in the press, many of those whose careers came to an unexpectedly early end claimed that they acted according to the rules. This may be true, but the perception of what is ethical in the eyes of the public was definitely different from that of the politicians.

3.4.7

Project Communications Management

Successful projects depend not only on execution of activities but also on timely and accurate sharing of information. This Knowledge Area addresses effective communication among those involved in the project, from stakeholders to internal project interests at different levels and with different views. Project Communications Management “includes the processes required to ensure timely and appropriate generation, collection, distribution, storage, retrieval and ultimate disposition of project information”. It emphasizes communication with stakeholders, who can be difficult to reach, either because of where they are or because they are busy managers, whose time is at a premium. When the earliest versions of the PMBOK® Guide were written over a quarter of a century ago the global village did not exist. In those days, communication was rarely planned. Meetings, telephone calls and conferences, minutes of minutes, e-mails, faxes, database reports and so on just happened. Whether or not this was effective was often not considered. The message here is that Communication needs to be systematically planned, just like any other project area, partly because good communication is in any case essential. It is also because of the diversity and geographical distribution of those involved in projects.

3.4.8

Project Risk Management

Risk Management means taking measures to reduce the chances and impact of negative events. Risk Management also means taking measures to improve the


35

chances and impact of positive events. The negative part of this agrees with the instinctive description of risk which many people have. The measures taken depend on the type and size of the project. It is also necessary to define who is responsible for risk management. In my experience, Risk Management (together with Initiating and Closing) is yet another area of project management where there is most frequently room for improvement. I have seen project charters for complex research projects which have a section listing possible risks and then....nothing! No action, no responsibilities, no process... Why is this? Maybe risk is often managed badly because it is invisible, intangible or too theoretical for inclusion in the high priority topics of the (obsolete) triple constraint: Scope, Time and Cost. One of the examples above reported a situation where a project sponsor demanded cost cuts and an earlier delivery than planned. Such demands without changing some boundary condition or resource increase the risk of not delivering. Only the promise has changed, not the reality. Of course in many industry sectors, risk is very significant and must be managed systematically. Examples include the insurance industry (“Pay us and we will take responsibility for your risks”) and petrochemicals, where there are high explosion risks. Describing the Risk Management processes is challenging. They must be valid both for small and large projects. A project manager and two team members completing a project in 3 weeks might be considered to be small. Launching several satellites for the GPS navigation system can be considered to be large. The processes separate the identification of possible risks, selecting the ones of most concern and deciding what to do about it (Risk Response) into several steps. This is to emphasize completeness and avoid overlooking a risk. If a risk occurs unexpectedly, it will always cost time and money to resolve.

3.4.9

Project Procurement Management

Procurement here means getting either products or services from outside the organization. The type of relationship is different from that with people in our own organization. We have informal daily contact with colleagues and can always ask questions, discuss developments etc. When products or services are purchased from an outside organization, the interface is different. For example, exactly how the reporting is done and how often must be defined in advance. It is not a good idea to telephone several times a week to find out about progress. It depends on the organization where the limits of “our organization” are. External companies are certainly outside our organization. People in our department are naturally in our organization.

36


A research laboratory in Europe sent a product to its colleagues in Japan for testing. The interface between the two laboratories was managed best by using the methods of Procurement Management, even though they were in the same company. A project manager is responsible for making sure that the project delivers and can make life easier by procuring sections of the project. Larger projects (such as building railways) are not possible without procurement. Procurement is where most of the project budget can be spent and this is one of the reasons that there is a Knowledge Area for it. The logic of this knowledge area is similar to most of the others: it starts with planning and then describes executing, monitoring and controlling. It is the only knowledge area which has its own closing process (see Table 3-1). Procurement is also an area that has particularly high contact with back office areas such as legal, accounting and human resources. Very often these areas are strongly operations-oriented and think less in project terms than the project manager, with deliverables and deadlines. This adds to the challenges.

3.5

Exam Aids

Process Groups l l l l l

Initiating Planning Executing Monitoring and Controlling Closing

Knowledge Areas l l l l l l l l l

Project Integration Management Project Scope Management Project Time Management Project Cost Management Project Quality Management Project Human Resource Management Project Communications Management Project Risk Management Project Procurement Management

3.5 Exam Aids

37

Flash Card Terms Change Management Closing Closing Process Group Communications Management Continuous Improvement Corrective Action Cost Management Decision Gates Develop Project Management Plan Executing Executing Process Group Gantt Chart Gold-Plating Human Resource Management Identify Stakeholders Initiating Initiating Process Group Inputs Integration Management Intellectual Property Management Knowledge Areas Milestone

Monitoring and Controlling Monitoring and Controlling Process Group Outputs Phase Exit Phase Gates Phases Planning Planning Process Group Process Groups Procurement Management Project Integration Management Project Processes Project Reporting Project’s Product Quality Management Quality Management Plan Risk Management Risk Response Scope Management Sponsor Time Management Tools and Techniques

Chapter 4

Integration Management Processes


l

l

l

l

A project is successful when it meets the expectations of the stakeholders. This means that the project manager must manage the project so that it delivers a coherent result. The Integration Management Knowledge Area groups together processes for making sure that everything in the project is integrated. The Project Charter gives the Project Manager the authority to lead the project and also describes the expectations of the sponsor, both for what the project will deliver and the constraints within which it will do so. The charter does not detail how the work will be done, as this is developed in response to the charter. The Project Management Plan is a plan about how the project will be managed. This is distinct from a project plan, which describes the actual work to be done. Changes will always happen and the Integrated Change Control Process allows this to be managed in a structured way. Closure is important as a signal to everybody that the project life cycle has ended. The closure processes also include Lessons Learned. Closure processes can also be applied to phases, sub-projects and programs.

Project Integration Management Integration Management is the very center of project management. The project manager is responsible for making sure that the project is successful and this depends on everything being integrated and brought together. This means that he must have a full understanding of all the knowledge areas and how they interact with the project. As this is the first process to be described, it is a good time to remind ourselves that the PMBOK® Guide models project management, using a complete set of 42 processes. They are not intended to replace ours but to act as a guide for their design and terminology, especially in international environments. ´ Conchuír, Overview of the PMBOK® Guide, D. O DOI 10.1007/978-3-642-11188-4_4, # Springer-Verlag Berlin Heidelberg 2010

39

40

4 Integration Management Processes

We should also remember that these processes can be applied at various levels within the project. For example they can be applied to the entire project, to a single phase or to a work package. In addition, the processes are applied iteratively, in other words the outputs are developed and then checked against the Inputs. This usually means making some adjustments. For example, when planning, we may need to iterate several times before everything fits and everybody can agree to all the details of the plan.

4.1

Develop Project Charter Analogy: After considering many factors like prices, house styles, personal wishes etc., a family (sponsor) commissions a project manager to help them build their dream-house. Pitfalls: Statement of work too vague or incomplete, business case inadequate or non-existent, insufficient authority for project manager.

The Project Charter is the document which formally authorizes the existence of the project (see the Glossary of the PMBOK® Guide). This sounds simple but is very important as it gives authority to the project and the project manager. In matrix organizations, the project team members do not always do what the project manager expects, or at least not when it is expected. This is a very human matter, because the project team members have their own line managers, usually located in the same place (“co-located”). When some demand arises, it is only natural that the line manager will ask the person to divert from their project to some other “urgent” operational work. The project manager is out of communication and does not see this happening. He cannot ensure that the team members fulfill the project commitments and this means that the project work often gets left aside in favor of daily work. How can we make sure that the project commitments are kept? Much of the answer depends on authority. If the project manager is seen to have more authority than the local manager, then the project work is less likely to be delayed. Matrix Organizations where the authority of the project manager is high are called Strong Matrix. There is an even stronger variant where the project organization is under the line management of the project manager. This is called a Projectized Organization (see Sect. 2.4.2 PMBOK® Guide). The personal authority of managers is communicated by signs. These signs vary from place to place and country to country. They can also be more or less subtle, depending on local culture. Besides obvious signs such as budget authority, examples which I have heard of include: l l

Having private offices instead of cubicles. Having signs on the door or organization chart saying “manager”.

4.1 Develop Project Charter l l l l l l l l l l l

41

Having corner desks in open plan offices. Having chairs with higher backs than other employees. Having a different color of carpet in the corridor. Wearing ties and suits. Having secretaries. Having car park spaces nearer to the building entrance. Having wider car park spaces. Having bigger cars or cars with bigger engines. Having a separate restaurant or canteen. Speaking with accents from the country of the head office. Others listen when he or she talks.

These signs of authority play a subconscious role when the project team member is “asked” by local management to divert from the project to “something urgent”. How many of these signs of authority does a project manager actually have? Often none at all! This makes it even more difficult for the project manager to get team members to work on the project, unless he is also a line manager. This issue is addressed in the PMBOK® Guide by having a Project Charter. This is the document that states that the project exists and it confirms the authority of the project manager. It compensates in some ways for the fact that the project manager may have few visible signs of authority. Armed with the charter, the project manager can open discussions with participants and arrange when (not if) they will meet. The charter gives real authority, particularly if properly compiled with extensive contact and acceptance (“buy-in”) from those concerned. Of course other factors also contribute to the acceptance, such as the leadership skills of the project manager. This is where the Develop Project Charter process comes into effect. A project manager who works in a less mature project management environment may have difficulties in communicating what a charter is and why it is needed. On the other hand, if the company has established a process where each project is expected to start with a charter, then the authority of the project manager is strengthened. Of course, projects are often managed by line managers, who already have these signs of authority and this strengthens the project. However the other line managers are also most likely to have strong authority. From a project point of view, there is a Weak Matrix organization, which means that the line manager controls the budget and the project manager has limited authority. This is not so good for projects. A question often asked is: “Who writes the charter?” The answer is that it is less important who writes it than on whose authority it is issued. We are back to authority. It is however a good idea for the (potential) project manager to write it, simply in order to be able to influence what it emphasizes and what it contains. The Sponsor, who is often a senior manager, usually gives the authority but is often not near enough to the detail about how the project should interact with technology, environment, people etc. The project manager should therefore welcome a chance to write this document.

42


The sponsor is a very important Stakeholder. Who the other stakeholders are or how they should be brought into the project is not always initially clear. I know a village that decided to build a windmill to generate electricity. People who live some distance further up the hill find this affects their view of the valley below. These people are stakeholders, because they are directly affected by the project. In this case, they feel that they should not be excluded from the project. Among the stakeholders we expect to find are: l l l l l l

l l

The Sponsor Customers and users The Project Manager, who represents the interests of the Project Team Other project managers who may be in competition for resources Portfolio and Program Managers Functional and Operations Managers, particularly those whose staff execute the project The Project Management Office Suppliers, neighbors, city administrations etc. who have to live with the results of the project

Let us now look in more detail at the Develop Project Charter process in the PMBOK® Guide. Like all processes it is described in term of Inputs, Tools and Techniques and Outputs. The first Input is the Statement of Work, SOW. Different sectors and companies have different names for this and it says WHAT the project should deliver: l l l l l

Not WHO? Not HOW? Not WHEN? Not WHY? Not HOW MUCH?

It focuses solely on the deliverables of the project which, together, add up to the Project’s Product. The details of the SOW should also reflect the business need. If there is no business need, there is no project. Even the biggest of businesses do not have unlimited resources and those that are committed to projects are in competition with other possible projects. A project’s product must therefore meet the customer’s acceptance criteria. These criteria are based on business needs. The next Input is the Business Case, the document which shows why this project is worth doing. For example, a business case may say that the installation of a robot for painting cars on a production line will reduce costs and make the work faster. Notice that the project manager is not responsible for the exploitation of the project’s product. This is the responsibility of the business. Continuing the example

4.1 Develop Project Charter

43

above, when the project manager has installed the robots according to plan, the Production Manager takes over responsibility for actually achieving the promised benefit. It is also possible that although the project manager delivers according to plan, the benefits expected by using the Project Product will not be achieved. The project manager should be critical before being confirmed in the role to avoid accepting a project that, although technically successful, does not lead ultimately to business success. The project manager has better things to do. If the project is being carried out for an external customer, then the Contract is an Input to the project charter. Actually, such projects are relatively easy to start as nobody wants to turn business away. It is much more difficult to get clarity for an internal project. The next Input is called Enterprise Environmental Factors. This is the first time we hear of this term, but we will often find it again in other processes. It means everything about the company (enterprise, organization) that could be relevant, for example: l

l

Government and legislation. These can even be the reason why the project is being considered. Local factors should also be included, for example markets, customers and competitors. There may be other relevant factors, for example if the previous project manager was fired. In this situation the sponsor may have unrealistically high expectations of the new project manager.

Another Input which we meet for the first time is Organizational Process Assets. This means: l

Processes or know-how of the company. These are assets because they have been built up over time and have cost money and effort to develop.

These assets can be formal and either documented or built into machines, processes or computer programs. However they can also be informal or undocumented. This may increase the risks that they will be lost, for example if somebody with a key skill leaves the company. The description now moves on to the only Tool and Technique in this process: Expert Judgment. The PMBOK® Guide lists where these experts may be found, including the people who do the work, whether or not they have high positions in the organization. I once visited a factory making radiators for heating buildings. It was located near the Atlantic Coast in the far north west of Ireland. The radiators were getting damaged in transit and various experts were asked to find out what the problem was. Eventually it was discovered that the packaging was not good enough to protect the radiators on the road journey. In those days the roads were really not good and it was the delivery lorry driver who identified the problem. Luckily they were clever enough to include this experienced person in their investigations, even though few would have called him an “expert”!

44


Expert Judgment is in some ways similar to Common Sense, because both recognize the experience of the person in deciding what to do. We are now ready to look at the output of this process and find that it is very simple: it is the authorized Project Charter, which gives the go-ahead to the project manager so that he can begin with the planning. It includes some important information: l

l

l

The deliverables which the sponsor and other stakeholders expect from the project. The boundary conditions for the project. These could be legal, budget, time etc. but also issues such as defining the supplier for a critical part. The authority for the project manager. This allows him to focus on doing the project work without having to divert into getting others to show interest or be available. The sponsor is responsible for ensuring that the authority of the project manager is understood.

How the charter (and other project documents) are signed-off (authorized) depends on the environment. The old fashioned way of doing it was to get everyone to sign in ink, but this is difficult in global projects. A more modern way is to use a document management system which controls the versions of all project documents. A simple way is however to produce a .pdf version of the agreed document and to circulate it by e-mail, with each person confirming acceptance in a return e-mail. This is then archived by the project manager or the Project Management Office, PMO, if there is one. Do not underestimate either the complexity or the importance of having an agreed project charter before making serious progress on the Project Management Plan. The charter is not the plan but the ground rules for the project, why it is being done and what will be delivered. This is a “black box” approach – you can see what goes in and what comes out, but what happens inside is not visible. It is the project manager’s job to develop the plan for execution (who will do what, when etc.) based on the requirements of the charter.

4.2

Develop Project Management Plan Analogy: After being commissioned, the project manager starts planning how to build the house. This becomes the blueprint for the whole building process. Pitfalls: Wrong planning technique, inconsistent planning.

From a process viewpoint, developing the project charter is simple: all we have to do is collect the background information and produce a single document. We now move on to the Project Management Plan, the plan which defines how

4.2 Develop Project Management Plan

45

the project will be managed. It provides a framework for coordination of all the subsidiary plans. The larger the project, the more important this becomes. Note again that it is not the implementation plan. This process is more complex than the previous one, as the data flow in Fig. 4-5 shows. Surely this is to be expected because the project management plan really is the centerpiece of any project. It takes interaction with a lot of people and their agreement (“buy-in”) is a major result of this work – it is not simply a side effect. A close study of the diagram is highly recommended. l

l

Everything inside the gray box belongs directly to this process as well as the dark dotted lines (“inter-knowledge area relationships”, meaning relationships within the knowledge area). Everything else refers to processes, Inputs and Outputs which are to be found in other knowledge areas (“extra-knowledge area relationships”, or outside the knowledge area).

The basic Inputs are in the top left hand corner of the diagram. The Charter is an expected Input but so are the outputs of other processes, such as from 6.5 Develop Schedule. The draft schedule is fed back to the planning process to be checked for consistency, as will be described later. It would be unusual for a stable plan to emerge without iteration. Enterprise Environmental Factors appear again. Although this term can be applied to many different details, the ones of interest here are those that directly affect the plan. We take a project to upgrade production machinery in a factory as an example. When production can be stopped to install the new equipment depends on the environmental factors that surround the production process. The production manager may demand that the work be done at weekends, while the project team may say that this is not possible. In the same way, the Input Organizational Process Assets has already been mentioned. Here it is interpreted in relation to processes, formal or informal, that affect the plan. One of these assets may be the plan from similar past projects and can be revised for the new project. This can be a very efficient way of learning from previous experience and requires that the plan is archived where it can be found. If elements of a project are very similar each time, then a template can be useful. For example a company that builds trains will use the same brake system for several different contracts. In this case the template can be used over and over again. When however projects are not very similar to previous ones, the effort developing templates may not be worthwhile. Templates tell the user what to do but projects are unique; requiring the project team to do “exactly like the last time” may not be a good idea. The project manager must judge each situation individually. In our globalized environment these environmental factors may also include culture. For example, do all project locations have the same days for the weekend? Team members may be expected to work during weekends or holidays just because the distant project manager “did not realize” when important pauses are taken by the team.

46


In Basel, Switzerland, there is a carnival which starts a few days after the beginning of Lent, the 40 day period before Easter. Everybody in the region knows that little work gets done during this period, regardless of the schedule, even in the large global companies. Another factor is how people can be employed and, if need be, dismissed. In Belgium some long term employees have the protection of 12 months’ notice. This results in some people who are nearing retirement being called “crocodiles” – they don’t move until you push them and then they bite! In Spain an employee can give 2 weeks’ notice and leave. In Switzerland any employee can be given notice of dismissal, without the employer having to give a reason. I even heard of a case in China where an employee went for lunch, where he got a better job offer. He sent his manager a text message with his mobile telephone to say that he was not coming back. The Tools and Techniques section of the process is simple: Expert Judgment. Judgment is required to l l l l l

Set up a process that suits the current project (sub-project, phase ....) Work out all the details for the plan Work out what skills and which resources are needed Define configuration management Set up the change control processes

If you are preparing for an examination, you will be pleased to see that, even so early in our review, there is a lot of repetition. This reduces the amount you have to learn. For example, the terms Enterprise Environmental Factors and Organizational Process Assets have both been mentioned in the first two processes. Whose project processes should be implemented? If this is an internal project and it uses existing company processes, then the project manager has less to worry about. If the project involves external suppliers who have their own processes, there has to be an analysis on how to integrate these processes with the internal ones. This is a situation where the use of a standard as overall framework such as the PMBOK® Guide really helps. When the project manager talks about Initiating, Project Charter, Closing etc. at least everybody means the same thing. Two well established telecommunication companies combined forces to provide mobile phone networks. It is reported that, at first, the new partners heard the same terminology from their new colleagues. It took them some time to realize that they did not always mean the same thing. Using a standard helps in such situations.

4.2 Develop Project Management Plan

47

Now we consider what is meant by Resources. This means everything from equipment to money to skilled staff etc. It can be helpful to think of everything which is in limited supply when planning resources for a project. It is unlikely that office paper supplies need to be planned for a commercial project – the business just buys this regularly. Resources which are in really tight supply should always be identified. Human Resources are of course often the most important project resource, particularly in knowledge work. There is a tendency to talk simply of “resources” meaning “staff” and this is sometimes reflected in examination questions. A company was replacing its internal telephone switchboard. The access to the network to make the changeover was a resource and the sponsor required continuous service. This was physically impossible. The project manager suggested thinking of access to the switchboard as a critical resource and negotiated a limited time window, during which the new equipment was installed. The agreed two hours of access to the switchboard was then planned into the schedule. Working out what skills are needed is essential but not always easy. Unless a project has the right skill mix it cannot hope to deliver properly. This will be mentioned again under the processes for human resource management. Configuration Management is also mentioned here for the first time. This concerns the composition of a project, its documentation and data. An important part of project management is the identification of the requirements, then their implementation. Any project will therefore have different versions of documentation at different stages, reflecting the concept of Progressive Elaboration (Sect. 1.3 of the PMBOK® Guide), the idea that the understanding of the project increases as the work progresses. It is simply not possible to have a full picture at the very beginning. Configuration Management is therefore needed to manage the various versions of data and project documentation. Finally, under Tools and Techniques, Integrated Change Control is introduced. This is closely related to Configuration Management and means that decisions to make changes must be made in an organized manner. In principle, there is at any given time just ONE version of the project charter and plan which is agreed upon. Any significant change can only be made by consulting with the stakeholders and checking out the implications. Sometimes a change request is not accepted as the described incident illustrates. As a young project manager I worked with a company which made instrumentation. For years this had always been painted gray. One year the CEO (manager of the company) went to an exhibition where instrumentation similar to ours from other providers was on display. It was green so on his return, my manager told me to change the product configuration and specify green paint.

48


A few days later the manufacturing manager came to me and told me that I had made a big mistake. Why? Because we had six months’ supply of gray paint which could not be used and it would take 11 weeks to get green paint. What went wrong? Clearly I had accepted a “request” from a senior manager as an “order” and implemented the change without any process. In those days we did not have a process called “Change Control” but if we had, it would have made it easier for me to avoid making a change under pressure from management. We now move to the process output: the Project Management Plan. This brings together all the lower level plans to form an integrated whole (remember – we are discussing Project Integration Management). The PMBOK® Guide has a very complete list of possible contents of the Project Management Plan in Sect. 4.2.3. In organizations which are less mature in Project Management, the Project Plan often just means the schedule or bar chart, also called Gantt Chart after the originator. This is a mistake. We need a plan for every one of the nine Knowledge Areas: Risk Management Plan, Scope Management Plan etc. If a particular part of the plan is not documented, this can be quite acceptable provided that an informed decision has been made. If the detail was just overlooked, then it will become a problem. An example is an urgent project, led by an experienced project manager. Under these circumstances it can be justifiable not to have, for example, a written risk management plan. But you can be certain that this will be compensated for by the experience of the project manager. We are now ready to move within Integration Management from the planning to the executing process group (across the page of Table 3-1 of the PMBOK® Guide).

4.3

Direct and Manage Project Execution Analogy: Once the house design and building planning is finished, the project manager has to ensure that the actual building activities are carried out properly. Pitfalls: Micromanagement, losing the overview, unexpected events.

The process result describes what everybody who has participated in a project knows: the actual work of the project is done, deliverables are completed, progress is tracked and adjustments made according to the situation. This is done while ensuring that the other eight Knowledge Areas are fully integrated at the same time.

4.3 Direct and Manage Project Execution

49

Clearly “if you do not know where you are going, you will not get there”: this process only makes sense if there is an agreed, achievable and stable project plan. If there are changes, they must be agreed upon using Integrated Change Control. In mature project management environments, this is the norm. In less mature environments, management may react sensitively to both external and internal pressures and demand changes. This is all right if proper change control is applied, because the impact of a change is carefully considered before a decision is made. I once participated in the IT support for the establishment of a new website for listeners of a radio station in Brussels, Belgium. It was not clear at the beginning how many people would register and therefore how much memory was needed. The change control meetings took place once a day. If the change control process is weak or absent, then accepting such demands is not helpful. Every change then generates yet more changes as details are discovered. It also results either in delays or increased costs or both. A look at the data flow for the Direct and Manage Project Execution process (Fig. 4-7) emphasizes this view. The Inputs included the Project Management Plan (what we planned to do) and Approved Change Requests. The current plan consists of the combination of the agreed plan and the approved changes. The other Inputs are (nothing unexpected): l l

Enterprise Environmental Factors Organizational Process Assets

Notice however that the contents listed under these headings are not the same for every process where they are mentioned. One bullet point under Enterprise Environmental Factors which is worth emphasizing is Stakeholder Risk Tolerances. In some situations, this can arise as follows: “the manager does not think we will deliver on time and is very anxious about it”. This means that he thinks there is a risk that his expectations will not be met. Whether something is felt to be risky or not depends on the person and their attitude to risk, as well as the actual situation. There is a more detailed discussion about the subjective nature of risk perception in Chap. 11 “Risk Management Processes”. This process gives relatively little guidance on the Tools and Techniques, putting them under the headings of: l l

Expert Judgment Project Management Information System, PMIS.

50


Under Expert Judgment we find that expertise may be accessed from the project team and from: l

l l

l

Other parts of the organization. Often somebody who was project manager of a similar project has been promoted to other work but their experience is still valid. Even if they are not responsible for this work now, they can be encouraged or even flattered to review the project. It does not matter where a good idea comes from and you could be pleased that you asked such a person. Consultants. Stakeholders, such as sponsors and customers, either of the project or the end-users of the Project’s Product. For example our project might be to install some production equipment in a factory which will make something. The customer of this “something” may also have useful comments. Associations: professional, technical, sectoral etc. We could add research consortia, universities and similar organizations.

The other Tool and Technique is the Project Management Information System, PMIS. This means the various tools which collect the data about project progress, cost, quality etc. so that informed decisions can be made. Normally this means some type of database which can be viewed electronically. In small projects with high stress situations, this data may be in the head of the project manager only. The use of messaging and chat-type interfaces increasingly means that the data can be updated using the mobile telephone interface wherever the project team member is. In spite of this, the PMIS may not involve IT systems at all and may be implemented with only pencil and paper. The point is that project information should be treated as a valuable item, so that it is available to support project reporting and decision making at all times. There is a long list of outputs from the Direct and Manage Project Execution process, of which the Deliverables is the first. Depending on the level at which this knowledge area is being applied, the deliverables concerned may or may not also be project deliverables. The next output of this process is Work Performance Information, in other words information about how the project is progressing. Information about Deliverable Status (which is related to scope), Schedule and Costs is emphasized. This is the old “triple constraint” coming back. Of course, all other information about performance is still needed but these constraint factors tend to be the elements which attract the most attention. The next output is Change Requests, not Changes. The thinking of the PMBOK® Guide is that the project manager may request (ask for, suggest) changes but may not decide on making these changes alone. This applies to changes that would result in not meeting elements of the requirements of the Project Charter. The project manager should of course always be given room to maneuver, otherwise it would be impossible to manage the project.

4.3 Direct and Manage Project Execution

51

Except for small changes, the decisions to accept or refuse changes are made by the Change Control Board, CCB and not by the project manager. This makes life easier for the project manager who knows that if changes have been accepted, their impacts have been assessed, estimated and allowed for. There are three types of change request: l l

l

Corrective Action: work to bring the project back in line with the plan. Preventive Action (the spelling Preventative is also common): actions to avoid some problem or risk that appears. Defect Repair: if some deliverable has defects, a decision may be needed whether to repair or replace. In either case, work or costs will occur that vary from the authorized plan.

Change requests may also emerge due to Progressive Elaboration: new ideas and approaches may only be noticed as the project progresses. The project manager should not just implement all good ideas without having them go through the Change Control Process first. The next category of outputs is Project Management Plan Updates. Anything can change and affect the plan over time. More detailed information will become available, for example which day and time a machine will be delivered. This should be updated in the plan at an appropriate level. Updates to the plan should not be used “to rewrite history”. It is easy to change the plan to make it look as if it has been met, for example by changing a delivery date! This is not recommended. For a start it takes time and energy from the project manager. I once visited a small factory where the manager complained that he spent every weekend updating the project plan. He got very frustrated, complaining that his employees changed it all the time, starting at the beginning of each working week! Such a process also means that the original plan is lost (at least from view) and the real deviations are not noticed. This means that we do not learn from experience. This is a pity because experience is expensive and should be used as much as possible. The final category of process outputs is Project Document Updates. This can be anything relevant, whether the cost of a service or the mobile telephone number of a supplier. This information (which is kept in the Project Management Information System, PMIS) contains so much detail that the only realistic way to keep it in control is to update it continually. Unless this is done consistently the project will get out of control. For smaller projects the project manager himself can do this but in larger projects it would be impossible without a Project Management Office, PMO (see Sect. 2.3, PMBOK® Guide).

52


4.4

Monitor and Control Project Work Analogy: During the construction, the project manager has to ensure that the building activities are progressing as scheduled and that changes to the original plan are properly implemented. Pitfalls: Changes not properly controlled or not controlled at all, inappropriate intervals between controls, variances not detected or detected too late.

Monitoring and Controlling is a very intensive process. It takes place throughout the project and is most active during Executing. Although the project manager is ultimately responsible, he depends on the “eyes and ears” of the team, as well as the proper implementation of the processes, to make sure that information is captured and acted on. This knowledge area, Project Integration Management, interacts with every single project process in all knowledge areas. This applies particularly to this process: Monitor and Control Project Work. The Inputs are: l l l l

The Project Management Plan Performance Reports Enterprise Environmental Factors Organizational Process Assets.

It is getting easier! We are familiar with the last two Inputs, which we must interpret in a way that is relevant for monitoring and controlling. Among the Environmental Factors we find the Company Work Authorization System. In a well organized project, this ensures that project work packages are executed in a controlled way. Particularly when the implications are big, we have to ensure proper closure before starting new work, otherwise resources (time, money) will be wasted. Even worse, this diversion of resources can often result in delays to some other work packages which are critical. The message is: do the work that is formally authorized. One of the Process Assets is the company’s financial control procedures. Very often these are based on an operational view of the world. After all, companies usually flourish as a result of continuously delivering what they are good at. This is quite different from a project approach. Even so, projects must be able to fit within this reporting environment. The need for the Project Management Plan is no surprise, nor the need for Performance Reports, which communicate the progress of the project. These include Forecasts and Issues. Forecasts report when we expect future work will be finished, what it will cost etc. This means that the project manager must use informed judgment, based both on status information and experience. Issues can be described as “risks that have happened”. This is when something has occurred which does or could cause a problem, to which we need to react. Projects will never be totally predictable and issues will always arise. The project manager must consider them as they occur and channel them into the management

4.5 Perform Integrated Change Control

53

process. If their impact is small, action can be taken but if the impact is large, the proposals will have to be forwarded to the Change Control Board for a decision. The Tools and Techniques of this process are already familiar to us: Expert Judgment, which is carried out by the project manager and project team working together. The outputs are also familiar: l l l

Change Requests Project Management Plan Updates Project Document Updates.

These are the same as three of the five outputs of the Direct and Manage Project Execution Process, which simplifies matters for anyone doing the PMP® examination.

4.5

Perform Integrated Change Control

Analogy: During the construction, there will be unforeseen circumstances. For example, the ground could be too soft and has to be firmed up for the foundations, or the sponsor decides to make changes such as marble floors instead of carpet. The project manager has to handle these while ensuring that the budget and schedule are both under control. Pitfalls: Improper assessment of impact of the change, baselines not updated, insufficient coordination in implementing the changes. Integrated Change Control is relatively simple and based on the following principles: l

l

l

After the project plan has been finalized, any (significant) changes must only be allowed if authorized by the Change Control Board, CCB. Changes can occur in scope, schedule, resources, budget etc. If a change request is accepted, then all details of the project plan must be updated and all those affected must be informed. It may be difficult to get agreement from the affected stakeholders, but if not achieved, there will be complaints! The combination of the last agreed project plan (also called the Baseline Plan) and the new authorized changes result in the current plan, which everyone should now use for the project.

None of the Inputs needs to be described because we have already seen them all. Three of them are outputs from previous processes: Project Management Plan, Work Performance Information and Change Requests. The remaining two, Enterprise Environmental Factors and Organizational Process Assets, were discussed as Inputs of the previous process.

54


Expert Judgment as a Tool and Technique is familiar to us. We go to the CCB (change control board) meetings bringing the recommendations of experts, whether we should or should not accept a proposed change. But who are the members of the Change Control Board? In most businesses it does not make sense to have separate committees and meetings for different topics. There are usually many projects taking place at the same time and they may share a single CCB. The members should be chosen by the fact that they are close enough to the work to make the best decisions. This could mean that senior technical people should also be on the CCB. Management is often not close enough to the detailed work to be able to make good decisions at this level. The members of the CCB are therefore often senior technical people, whose competence is respected. The members of the CCB must have authority that is endorsed by the business. This was already discussed as an important reason for having a project charter. This is also helpful to the project manager, as he can draw on their expertise instead of having to work on his own as a “lone ranger” or “cowboy”. This style does not suit modern project management. The working of the CCB depends on local practice, but it always includes elements of the following: l

l

l

l

l

l l

Logging or recording of the change requests in the Change Log. This is a database and could be as simple as a spreadsheet. Assessment of the impact of accepting or rejecting the change. This work requires resource (usually the time of an expert) which should not be diverted from the project implementation; otherwise one problem will cause another. When the CCB meets, the requests for which an impact assessment is available will be reviewed. Decisions will be made either to accept or reject the requests. It can also happen that a request is sent back into the queue so that more information about the impact can be collected. Accepted changes will then require detailed changes in the project plan. When this is ready it must also be communicated systematically to everybody affected. Finally when a change has been completed, the request is closed. Rejected change requests must also be communicated and closed; otherwise those affected will think that it is still waiting for a decision. Non-communication is not good for project team morale!

The process outputs include the familiar Project Management Plan Updates and Project Document Updates. The only new item is Change Request Status Updates, in other words, information about the status of the various active change requests. This process is in the Monitoring and Controlling Process Group, for which status reports and change requests are typical outputs. Each time accepted changes are updated into the current plans, a new baseline is generated. Some project managers may try not to change the baseline plans, to

4.6 Close Project or Phase

55

avoid a feeling that original planning was not good. This is not realistic as major events can always occur, such as a fire at the factory of a supplier, with resulting changes to the schedule. When this occurs, the changes should only apply to the current plan. Changing a baseline that has already been completed is similar to “rewriting history” and would hide the learning experience. Actual historical data should not be changed.

4.6

Close Project or Phase Analogy: Once the construction of an element (e.g., the garage) or the whole house is completed, the work has to be approved and the activities officially closed. Pitfalls: Improper or premature closure can result in extra work and costs.

This is the final process in the Integration Management Knowledge Area. Its title reminds us that all of the processes can be used at various levels, whether for the entire project, for a phase, sub-project etc. It is the only process title of the 42 which emphasizes this point. Closing should not need much time or money, at least compared with the rest of the project. It is a reminder to tidy up before proceeding and also to learn from the experience. This is the key to process improvement, so that they mature as time goes on. Closing also includes archiving, which can be a legal requirement. This learning from experience is a major pillar of the PMBOK® Guide approach and means that the experience from one project is passed on to the next. Closing is always a “learning opportunity” and therefore particularly important if a project has been prematurely terminated. This means that the project was closed before the planned finish because either something went wrong or the circumstances had changed significantly. Situations such as these provide a particularly good chance to learn a lot! This approach is similar to aircraft accident investigations which are carried out, even when information about what happened is very hard to get. In the long term, everyone benefits from learning from the past. Although some of the closing activities can take place before the actual end of the project, Closing should be finalized when everything has been finished. For example, if all the deliverables of a project have been delivered, then it is time to stop. It is reported that projects are sometimes not closed properly because: l l l l l

Closing is not nearly as exciting as starting the next project. No resource is reserved for closing. There is no time because another new project is waiting. It is not worth the effort or is boring work. The project manager and team fear that they will be left without employment.

56


Somebody once described projects that are “forgotten but not gone” as “the living dead”. This is a real problem because it is impossible to estimate delivery times and resources accurately against a background of projects whose status is unsure. It should be simple: when the deliverables have been delivered, the project should be closed. A better approach is to make a conscious decision that a project has finished. After this, user queries are treated as new requests, which must queue up with other work and compete for available resources. It is best to think of Closing as an investment in learning and insurance against future problems rather than as a burden to be avoided. To decide if a project has been completed clearly requires the Project Management Plan as an Input and, once again, Organizational Process Assets. The detail is different but the basic idea is the same as before: Project closure guidelines and processes are “process assets”. The only Input which is new to us is Accepted Deliverables. This means that whoever takes over and uses the deliverables must confirm their acceptance. This is a sign that the project (phase etc...) is ready for Closing. Expert Judgment is again the only Tool and Technique. Which experts are involved may be different from previous phases but the idea is already familiar to us. The first output is the Project’s Product. If this is a phase closure then the product can be a major part of the whole project’s product. The message is that the deliverables are released, either at the end of a phase or a project. The other output is Organizational Process Assets Updates. For once we will give this a bit more attention, even though it follows the pattern we have already seen. This is because during Closing we have the last opportunity to capture the Lessons Learned, distribute and archive them for the benefit of future projects. The elements of these updates are: l l l

Project Files. Project or Phase Closure Documents. Historical Information.

Let us look at each of these in turn. Project Files will have been produced during the project but they must really be put in order at the time of Closing. This means sorting, collecting and archiving etc. Despite the advances of IT, there will still probably be physical items to file, such as hard copy signed documents and authorizations, test samples, catalogs, publicity etc. These should be kept together, at least in filing boxes or folders, including an index so that they can be quickly retrieved if needed in future. The documents should be kept in a defined place, so that they can be found if needed again. If the project was terminated ahead of the original plan, then it is even more important to keep the closure documents.

4.7 Exam Aids

57

Alternatively electronic archives can also be used. For easy access, it may make sense to put the documents on a CD and store it with the physical items. If a search tool (such as Google) is used, then it may not be necessary to spend time preparing a complete index, because material can be found more quickly if needed. It is also important to check that nothing has been overlooked. Closing documents are often the basis for releasing substantial amounts of money, so they must be auditable. This means that they can be reviewed and understood by an independent auditor, which is only possible if the documents are properly filed. The criteria for closing should be easy to find and interpret, if necessary. Lessons Learned is also a key output, not just the learning but making sure that the lessons feedback among those who are in a position to do something about it. This is called Historical Information. For example if a project was executed under heavy pressure resulting in numerous staff resignations, then the future solution should also involve policy makers in HR departments, and not be the sole responsibility of the project manager. The project manager should make an active effort to pass on this learning experience. There are many ways of distributing the lessons learned and making sure they get to the right people. Some possible ways of achieving this include: l

l

Leverage from the authority of the project sponsor at the closing meeting. Distribute the findings (lessons learned and recommendations) on behalf of the steering committee, not only on the authority of the project manager. Sponsors often have political presence, allowing them to make sure that the recommendations are acted on by senior management. Make it easier for the sponsor by providing a Closing Report, which can then be endorsed by the steering committee.

Whatever you do, make sure that the lessons are not just hidden or forgotten (“shelved”, that is “put on a shelf and forgotten about”).

4.7

Exam Aids

Process Summaries 4.1 Develop Project Charter: Authorizes the establishment of the project and documents the key expectations. 4.2 Develop Project Management Plan: Defines the actions needed to develop and coordinate all subsidiary plans. 4.3 Direct and Manage Project Execution: Implements the project in order to meet its objectives. 4.4 Monitor and Control Project Work: Checks and adjusts the work to ensure that the objectives are met.

58


4.5 Perform Integrated Change Control: Manages the evaluation and implementation of requests for change to any authorized feature of the project. 4.6 Close Project or Phase: Ensures systematic completion of the project or phase and identification of lessons learned.

Flash Card Terms Accepted Deliverables Approved Change Requests Business Case Change Control Board, CCB Change Control Process Change Log Change Request Status Updates Change Requests Close Project or Phase Closing Company Work Authorization System Configuration Management Contract Corrective Action Defect Repair Deliverable Status Deliverables Develop Project Charter Develop Project Management Plan Direct and Manage Project Execution Enterprise Environmental Factors Expert Judgment Forecasts Gantt Chart Historical Information Human Resources Integrated Change Control Integration Management Issues Lessons Learned

Monitor and Control Project Work Monitoring and Controlling Process Group Organizational Process Assets Organizational Process Assets Updates Perform Integrated Change Control Performance Reports Preventive Action Progressive Elaboration Project Charter Project Document Updates Project Files Project Integration Management Project Management Information System, PMIS Project Management Office, PMO Project Management Plan Project Management Plan Updates Project or Phase Closure Documents Project’s Product Projectized Organization Resources Sponsor Stakeholder Stakeholder Risk Tolerances Statement of Work, SOW Strong Matrix The Project Management Plan Weak Matrix Work Performance Information

Chapter 5

Scope Management Processes


l

l

l

l

The management of the project scope. The scope affects the time needed, the costs and the resources so it has a major impact on the planning and execution. This in turn affects the relationship between Expectations and Deliverables. Scope Management is therefore a key project management skill and is vital to the success of the project. All the details of the project requirements may not be clear when the charter is agreed. The project manager is therefore responsible for getting clear requirements and having them endorsed by the sponsor and stakeholders. The process is called Collect Requirements. Based on the validated requirements, the process Define Scope describes what is in and what is not in the project. This is then used to prepare a graphical version of the scope referred to as the Work Breakdown Structure, WBS. When the execution is complete, the deliverables must be checked against the Scope Statement, the WBS and the Approved Change Requests. This is called Verify Scope and confirms formal agreement between the Project Team and the Project Customer that the promised scope has been met. If the project is for an external customer and concerns a complete deliverable, this can also be used to authorize payment. Control Scope is the process which continually checks the project scope against the agreed Scope Baseline.

Project Scope Management Project Scope Management means making sure that what is in the project is delivered and what is outside the project does not use the resources assigned to the current project. This means that the project team should always have a clear idea ´ Conchuír, Overview of the PMBOK® Guide, D. O DOI 10.1007/978-3-642-11188-4_5, # Springer-Verlag Berlin Heidelberg 2010

59

60

5 Scope Management Processes

of what is in the project. It is really important that the expectations and project deliverables match, making it easier to focus on project commitments. Project Scope Management is vital to the success of the project as it tells the customer what he is really getting. If the customer has an unclear idea of what he wants, the project manager must work with him to further refine the requirements. Only then can the project be executed. The project is completed when the scope is fulfilled. One way of looking at project management is like navigating a kayak or canoe down the rapids of a fast moving river. The objective is to find a way between all the obstacles without using force while making your way. The world outside the project has its own priorities, so if your project hinders their goals, objections will be raised. It is better to visualize and communicate each issue (such as scope, cost and schedule) with an appropriate tool. This helps to focus discussions and negotiations on one issue at a time and therefore leads to better decisions. Scope Management is one topic which can benefit significantly from this approach.

5.1

Collect Requirements Analogy: The customer wants to build a house for his family (high-level requirement). The project manager’s next task is to help the customer specify in more detail what he wants, i.e., how many bedrooms, bathrooms, etc. Pitfalls: Forgetting requirements or defining unrealistic ones.

The first step of Project Scope Management is to clarify the requirements so that the project we plan is the project which is required. The project manager is responsible for taking the lead on this and we will actually see much more detail in the Tools and Techniques than in the Integration Management Knowledge Area. The title of this process may make it sound as if we can collect the requirements in the same way we collect the groceries from the supermarket. In reality, the sponsor and other project customers may not have worked out what they really want in great detail. This means that the project manager and his team must manage the requirements collection process so that everybody is clear about them. This is an active process. The starting points (Inputs) for this process are the Project Charter and the Stakeholder Register. We are already familiar with the Charter and it is clear that this includes a high level statement of what the project should deliver as well as some conditions about how this is to be done. To collect the project requirements we also need to know who to talk to. This sounds trivial but it is often not. People who are not invited to participate in a project can make trouble so it is better to take the time to identify and invite them.

5.1 Collect Requirements

61

The Stakeholder Register helps by listing all the project stakeholders, whether inside or outside the organization. It is an Output from the Identify Stakeholders process in the Communications Management Knowledge Area (Chap. 10). There is a particularly long list of Tools and Techniques that includes items that some people might not qualify as “tools,” such as Interviews. Let us remember that the word Tools includes methods of working, whether physical or not. In particular, note that Tools is not restricted to IT tools. The project manager must assess the environment and select appropriate methods. In Japan for example, the subordinates assume the opinion of their superiors in public. This means that it would be better to use questionnaires or observation instead of workshops. Interviews as a tool means structured and recorded interviews. Who did you speak to? What background information did you give them? Why did you select them to give an opinion? What did they say to closed questions (only one short answer possible) and open questions (for example: “what do you think about the objectives of this project?”). Interviews take a lot of time for the interviewer, but from the point of view of the interviewee, the time spent is efficient and private. This means that it is a particularly good tool for getting Inputs from busy senior managers. It was often said that we have two ears and one mouth so that we can listen twice as much as we talk. This is very relevant in interviews. Off-hand comments can warn the project manager of topics, work packages or issues that would otherwise be overlooked or forgotten. The use of web meetings to interview Subject Matter Experts offers great possibilities. Maybe the person who can contribute is far away on another continent or in another time zone and can only be brought in this way. This can also save a lot of time compared with the traditional way of personal visits, although some of the nuances may not be captured. A further reason for using web meetings is that it can prevent interruptions. We are all familiar with the situation where we are talking to someone who gets distracted by an incoming phone call. A web meeting can be a better way to get undivided attention than a face to face meeting. Often the person who works far away also has another manager and may not be willing to spend time being interviewed for your project. In these situations, the sponsor can use the power of his position to get access to the right people. Focus Groups are in many ways similar to structured Interviews. They bring experts together to exchange ideas as well as capture and document their expectations and attitudes. A Focus Group requires a good moderator to lead the event and this person must be accepted as competent by the group. This is not a job for the youngest and member newest of the project team!

62


Facilitated Workshops can also be held to define product requirements. Like interviews, they should be properly documented with information about the method used and the participants. They have several advantages: l l

l

l

l

Use less time than a series of interviews. It is easier to sense where consensus (or agreement) exists compared with oneon-one meetings, because many interested people are brought together. The ideas of one person may stimulate others, bringing up new ideas for discussion that would otherwise be missed. The results of previous Interviews and Focus Groups can be brought to such meetings to generate further insights and understandings. Acceptance (or buy-in) is achieved much more easily if the stakeholders are invited to give their opinion. This is true for all parts of project management.

Depending on your industry sector, you may be familiar with specific techniques and tools used for collecting requirements such as: l l l

Quality Function Deployment, QFD for product development. Joint Application Development, JAD for software development. RequisitePro® and ClearQuest®, tools from IBM for supporting software requirements engineering and development processes.

From an examination point of view, it is probably enough to be familiar with these titles. Group Creativity Techniques puts a name on several conceptual tools, most of which will be familiar to anyone in modern business. Brainstorming is widely known and, when focused, can produce good results. It is not an excuse for a totally unstructured discussion: it should focus on a defined topic such as “what are the requirement of the user interface for the new production control system?” The meeting organization, who participates, etc. must be documented. Traditionally, the results are collected on flip charts, which can be photographed and included in the electronic documentation. One very effective way of brainstorming is to distribute Post-it® notes and ask the participants to write down their ideas, one per note. These are then collected on a flip chart or even on the window or wall. This allows everyone to work at the same time and can be very fast. I was consulting on an international project where a new work package was being started. This could have been documented privately and then passed to the project management for feedback. The disadvantage would have been too little acceptance. The core project team was at the end of a planning meeting and 10 minutes were left before some of the participants had to take taxis to the airport. Using Post-it® notes, 40 or 50 ideas were collected in less than 5 minutes and documented after the meeting finished. Because they all participated in the brainstorming, the result of this process was accepted by the core team without question.


63

Finally Brainstorming is particularly suited for involving everybody related to a project. It gives them a way to bring in their experience and to influence the project. When properly done, it can really help the project team spirit. The Nominal Group Technique can also be used as an extension to the Brainstorming process to move forward from lots of proposals to a prioritized short list. It was invented in the days before Post-it® notes, web meetings and e-mail. Today there are plenty of internet based voting tools, but the basic idea is still valid. Be sure to know about it as it might be in the PMP® examination. The Delphi Technique also comes from the era long before e-mail but is still very usable. The name comes from the Oracle of Delphi, the spiritual advisor. An experienced moderator asks a well thought out question to a group of selected experts. The answers are kept confidential and are combined by the moderator, ideally in such a way that you cannot tell who said what. The combined answer is then circulated for further comments and refinements. This reduces the possibility that the group’s final opinion is dominated by an influential or referred expert. This technique allows experts to speak freely and minimize the effect of (real or perceived) pressure from management or other stakeholders. Even so, I have seen situations where it was easy to tell who said what by the choice of words and style. It can also be used in other project situations that require consensus, such as identifying risks. The Delphi Technique suits e-mail particularly well, because you can use it to get opinions from a broad selection of experts. Mind Maps are another structured tool which can be used to identify requirements. They start from a central point and spread out like branches, dividing and subdividing for each new idea. This is a strongly visual manner of communicating how requirements are grouped and sub-grouped. Mind maps are a good way of combining ideas from brainstorming and getting all the information on one page. The Affinity Diagram technique takes the brainstorm Outputs a step further, grouping them according to their features. For example, if the requirement suggestions are examined, it may be possible to group them by usability, speed of operation, ease of maintenance and interface language. The Post-it® notes are then grouped on a flip chart according to these categories and a line drawn around each group. In answer to the question “have we forgotten anything?”, it can emerge that one category has been overlooked. This can then be added and further, more specific suggestions requested under this heading. Next we look at group decision making techniques: l l l l

Unanimity, in other words, everybody agrees. Majority. Plurality, in other words the largest group decides, even if there is no majority. Dictatorship.

Very often the requirements of the stakeholders will conflict with each other and the project manager has to find an acceptable resolution.

64


This looks like a lesson in political science. Note that dictatorship is not a good way to run a project except in extreme circumstances. A dominant stakeholder can force certain concerns, while ignoring the fine details of the situation. When these details finally show up, they will still have to be resolved. Finding consensus requires strong leadership skills from the project manager. Depending on the issues, the decision making technique may vary. For example, safety or regulatory decisions must be unanimous while strategic decisions need only a majority. The next Tool is Questionnaires and Surveys. If useful responses are to be expected, real skill is required to formulate and manage the environment. “Paper never refused ink” is a well known saying, which means that we can put down any answer we like. Even if the answers are collected using a computerized survey which also checks the data for plausibility, it is still possible for respondents to fool the system by providing dummy answers. Even so these are useful techniques if both quick collection and analysis of data is required. Software that manages both the posing of questions and the analysis of results is available in the internet. The Tool and Technique Observations is used to ensure that elements are all right and to sense when they are not. Although the PMBOK® Guide talks about Job Shadowing where external observers watch how the job is done, this can be restricted by law in some circumstances, for example in Germany. The final item in this long list of Tools and Techniques for collecting requirements is the use of Prototypes. Requirements can usually be obtained from stakeholders by showing them something similar (tangible) to the final version of the Project’s Product, or even a mock-up. If they can understand what they see, you can be sure they will tell you what they do not like. If this process is repeated it can lead to very useful feedback for finalizing the product. This is useful where the stakeholders have limited relevant experience. The capacity to visualize the deliverables varies from person to person and there is a danger of emphasizing personal interpretations, at the expense of broader professional experience. With all these Tools and Techniques available, we should be able to select which ones are relevant to our project and use them to generate the process Outputs which are: l l l

Requirements Documentation Requirements Management Plan Requirements Traceability Matrix.

The quality of the Requirements Documentation is important. It must be crystal clear at the end of the project that the requirements have been met. If this is not so, it can lead to arguments and the delay of final payments, leaving everybody unsatisfied. Careful wording is not just for show; it is in itself a requirement. The requirement must be testable and accepted by the steering committee or whoever is responsible for the major project decisions.


65

Often, requirements are based on the business processes. Indeed, in the case of Business Process Re-engineering the process may itself be part of the requirements. Business Processes often interact with the requirements and, if so, should also be documented. The requirements can be nested in a hierarchy, for example corresponding to system, subsystem and unit. The establishment of requirements should be documented so that the reader sees answers to all significant questions which may come to mind. As well as the characteristics already mentioned, the checklist includes: l l l l l

l

l

Which business needs drive a particular requirement? Functional requirements: the capabilities of the project’s product. Nonfunctional requirements such as standards compliance, maintainability, etc. Quality requirements and constraints. Acceptance Criteria. It should be absolutely clear what status corresponds to completion. Impact on the various parts of the organization of which the project is a part, for example sales training. Assumptions. Decision making (for example, the collection of requirements) depends very strongly on the assumptions. This is very easy to ignore, either because the constraints are considered to be obvious, or because cultural differences are not properly considered. I once worked for a computer company which lent me one of their products for use on a University project. One day there was an audit from the head office and I sensed unease as I walked to my car and put one of their computers in the trunk. I had assumed it was acceptable to walk in and out with a company product, but it seems that the auditors did not share this (cultural) assumption!

The Requirements Management Plan is also a process Output. It is usually easier to define the rules by which decisions will be made before a live situation presents itself. Even if the requirements remain stable throughout the project, how they have to be tracked and reported needs to be worked out and documented. In reality, the details of the requirements will probably change. This means that you need to decide how changes will be assessed, prioritized and agreed. In a company which is mature in project management, these matters will usually be decided on and documented. Even then they must be communicated to suppliers and contractors. The final element of this process is the Requirements Traceability Matrix. At the simplest level, this is a table of all requirements showing how each one arose, which part of the business needs it, how each one affects product design, etc. This level of detail requires consideration of many points and reduces the risk of forgetting something important. It also makes it possible to reopen a discussion if difficulties arise later, for which a compromise or trade-off is needed.

66


5.2

Define Scope

Analogy: Once we have identified what type of house the customer wants, it is time to prioritize. For example, a tennis court is a nice to have, but the weather is too rainy and the garden size is limited. So the tennis court is left out. Pitfalls: Scope is too narrow or too broad. With the project requirements available, the focus can now move to the definition of scope. Although all the requirements should appear in the draft scope, changes due to Progressive Elaboration may add to or even reduce the requirements by the time the plan stabilizes. The key is to develop agreed, workable scope, otherwise it will surely lead to dissatisfaction. The Inputs for this process are all familiar to us and are just listed here: l l l

Project Charter Requirements Documentation Organizational Process Assets. The Tools and Techniques are:

l l l l

Expert Judgment Product Analysis Alternatives Identification Facilitated Workshops.

The first and last of this list of Tools and Techniques require no comment but the other two do need some explanation: Product Analysis is relevant for physical items, so tools such as systems analysis and value engineering can be used here. The relevant tools are applied to the description of the project’s product to provide a systematic and different view of the scope. This provides a cross check and may identify items in scope which would not otherwise be identified. Alternatives Identification gets a very short mention in the PMBOK® Guide but is one of the important trade secrets of project managers, not only in the context of defining scope. Let me describe it this way: Project implementation is like a voyage of discovery from the original sponsor’s request until the end of the project. At the beginning, only some information is available and little is known about how the requirements interact with the project capability. At each step as the project progresses (Progressive Elaboration), we need a range of options to choose from in order to move forward. Should this project be carried out in this place or that? Who should be the project manager? What technology should be used to implement the product? How much should it cost? How long should it take? etc.

5.2 Define Scope

67

It always makes sense to ask the question: “What possible solutions are there to the current challenge or problem?” A choice of only one option at each step is effectively no choice. Asking this question may stimulate another and generate a range of options, from which the best alternative can be developed. We are much more likely to be successful if we have a good choice of options to select from. Working out different scenarios gives us a broader view as well as helping understand and prioritize the requirements. An example is the case of an IT project manager who was told that he would have to develop a tracking system for a pharmaceutical product manufactured by his company. One constraint was the deadline, the date by which the system had to be operational because of a new European Union requirement. The project manager was already using all available resources and was unsure how to respond to the new demand. After asking the question “how many ways could this project be executed” he identified the following possible approaches: l

l

l

Implement the new project when the other projects allow. This would not meet the date requirement. Implement the new project now and delay the existing ones. This would not satisfy the stakeholders of the original projects. Then the less obvious solution: Implement the new requirement using manual administration for a period, then implement using IT methods later. On examination it was discovered that the legal requirement did not specify IT methods.

The project manager offered these options to the sponsor, who selected one option. Knowing that the Alternatives Identification has been carried out gives a better selection and a better decision. In the event, the second option was selected. Because this was achieved by identification of alternatives, a better decision was possible. An important result is that the Project Scope Statement defines the project deliverables and the work needed to produce them. Also, once the scope is fixed, updates may be required of other project documents to reflect this decision. The Outputs of the Define Scope process are: l l

Project Scope Statement Project Document Updates.

The first of these is exactly what you would expect from a process of this name. This can include items such as the Product Scope Description, which defines what is in the project’s product. This is closely related to the Project Deliverables and Acceptance Criteria. Scope can be clarified by stating what is not included: Project Exclusions. This allows us to emphasize the project boundary, particularly in situations where the stakeholders assume that a particular deliverable is obvious (to them), but not

68


documented. If a particular exclusion is not agreed upon, then the project manager will need additional resources to implement it. A simple example is training for a new IT application. The two deliverables are the application itself and training. Maybe the developer thinks that the scope includes the application only, but the customer assumes that the training is included. This has to be clarified and documenting Project Exclusions highlights what is out of scope. The Project Document Updates Output is a reminder to check items that might have been affected during the process such as: l l

Stakeholder Register Requirements Traceability Matrix.

5.3

Create WBS Analogy: Once the customer knows how the house should look like, the project manager now has to define the Work Packages that are needed to build this house. Pitfalls: Work packages are defined at too high (difficult to monitor) or too low level (high tracking effort). Work packages may also be missing, inadequately defined or without dependency information.

We now move our focus to one more of the powerful concepts in the PMBOK® Guide, the WBS which is a very useful visual tool for managing scope. WBS stands for Work Breakdown Structure: a structure which breaks the work down into smaller elements. All three words are important. This is a graphical way of showing the complete scope of the project. You can see example WBS diagrams in Figs. 5-8 and 5-9 of the PMBOK® Guide. There are several ways of dividing the work, including: l

By Major Deliverable (see Fig. 5-10). This is very useful for checking completeness as everything in the scope should be in the WBS. The WBS is very visual and can be explained easily to the various stakeholders by the project manager. One major project with activities in over a dozen countries on which I consulted produced a WBS at my suggestion. The project manager was highly embarrassed (but thankful!) to find out that he had totally overlooked one of the major project deliverables. After that the WBS was enforced as a required tool for the remainder of the project.

l

By Phase (for example Fig. 5-9). For simple but not necessarily small projects, the WBS by phase can be used as a simple tracking tool and to communicate progress visually to management. By using this version, gaps in the project scope are less likely to be noticed.

5.3 Create WBS l

69

By Department, showing which department will deliver each element. This does not have either of the main advantages of the two methods above (completeness or tracking) and can lead to “silo” thinking, where each department only worries about its own part. This would go against the concept of Project Integration Management. A variation of this theme is to divide the WBS according to the geography of where the work will be done, while also identifying work packages that are outsourced to external contractors. All of the process Inputs are already familiar to us:

l l l

Project Scope Statement Requirements Documentation Organizational Process Assets.

The first step when creating a WBS is to decide whether to do it by major deliverable, phase, etc. and how many levels are appropriate. A spectacular example (as it appeared to outside observers) of a WBS which was not optimal was the one used by Airbus to develop the A380 airplane, which can carry over 800 passengers in some versions. In Fig. 5-10 there is an example where an Air Vehicle (airplane) is broken down into airframe, engine, etc. For the A380 the WBS was effectively divided into elements based on which country would do the work: Britain, Germany and France. When the first prototypes were ready for fitting out, it was discovered that the internal wiring did not fit. The reason was that different tools were used in Germany and France to design this part of the aircraft. Simple though this matter was, it eventually resulted in a delay of over a year. This caused order cancellations, which in turn resulted in some factories having to be sold off or closed. Naturally each country wanted the closures to be elsewhere. At the same time and in the lead up to the global economic crisis, the euro (the currency of both France and Germany) rose in value against the US dollar, resulting in higher costs and more cancelations. To solve the disagreement, the President of France invited the Chancellor of Germany to visit him at the A380 assembly location in Toulouse, France, to negotiate a change of work assignments. A better design of the WBS might have avoided the need to escalate to head of state level. This is not to say that such a WBS or other mixed forms cannot work, but be warned! The only Tool and Technique for producing a WBS is called Decomposition. This means the breaking down of the entire scope of the project into smaller and smaller packages. The complete WBS should contain placeholders for absolutely every item of work in the project.

70


5.3.1

What is Not in the WBS Does Not Get Done?

Some thought is required to decide how many levels the WBS should have. There is a general opinion that the WBS belongs to the Project Manager. This means that the number of levels should be as deep as the project manager needs in order to understand what is happening, but not deeper. Often, the Organizational Process Assets can provide useful templates such as WBS or other documents from similar past projects. If more detail is needed, it is recommended to assign the work concerned as a sub-project and require the manager of the sub-project to also use a WBS. However it is done, the lowest level of breakdown is called a Work Package, even if they are at different depths on different branches. To see why this makes sense, notice that except for the lowest level, all boxes are only headers but do not represent actual work. Work Packages are important because they are the basis for estimating cost and durations as well as for assigning project work. When the WBS has been generated, it is usual to add systematic numbering for reference. Related to the WBS are Control Accounts for assigning and tracking costs. Typically they consolidate the costs of several work packages. As well as the WBS itself, there is another process Output called the WBS Dictionary. It contains more information about each work package, such as what technology will be used, which organization is responsible for delivering it, resources required, acceptance criteria, accounting codes, etc. (see Sect. 5.3.3 of the PMBOK® Guide for a full list). The next Output is the Scope Baseline consisting of: l

l l

Scope Statement, which is a part of the Project management plan and is a text version of the scope description WBS WBS Dictionary.

The final Output is Project Document Updates. Because Progressive Elaboration applies, we can expect to identify new details, methods of executing the project and new insights while creating the WBS. These ideas are captured in the Project Document Updates.

5.4

Verify Scope

Analogy: Once the kitchen is finished, the customer checks whether the kitchen as a whole conforms to his requirements. For example, he can check if he can cook in this kitchen. He does not need to check whether the water faucets work, as it is assumed that the deliverables have been validated beforehand by the plumber. Pitfalls: Verifying deliverables that have dependencies on other unverified deliverables.

5.4 Verify Scope

71

It is clear that this process describes the checking and validation of scope. What is not clear from the title is that it is concerned with scope verification after the deliverables have been shown to the project customer, so that they can be reviewed and formally accepted. Several related deliverables may also be grouped for verification, particularly when a work package has been completed. Validated Deliverables should have been formally checked by the project organization, before asking the customer to Verify Scope. There are other stages in the overall process where scope is verified. For example during scope definition, when we verify that the scope covers everything the project should deliver. Even so, such activity is not covered by the Verify Scope Process. A significant difference between Perform Quality Control and Verify Scope processes are their objectives. The customer verifies scope so that the deliverables can be accepted. When this involves a change of ownership then this process can authorize payment. For example, consider a machine company which delivers and commissions (checks the correct operation of) an automated assembly machine and also provides a testing certificate. When this is accepted by the customer, the scope has been verified and the payment is authorized. Even if payments are not made, for example between phases of a companyinternal project, the emphasis is on customer acceptance for that deliverable. The Inputs provide the information needed to carry out this check. They are: l l l l l

Project Management Plan Work Performance Information Requirements Documentation Requirements Traceability Matrix Validated Deliverables.

The first four together describe what we expect to get. The last one is interesting because we often think of deliverables as physical items that are “delivered”. However here the process Input is a combination of the “thing” and the status of validation. The only Tool and Technique is Inspection, in other words, doing whatever is needed to verify that the scope has actually been covered. Other terminology for this work includes product reviews, audits and walkthrough. This last one means that we step systematically through all the detail, making it easier to verify it properly. The Outputs are: l

Accepted Deliverables: as already discussed under Validated Deliverables these are a combination of the physical item being delivered, together with documentary confirmation of the Acceptance (sign-off).

72 l

l


Change Requests: the process could result in new information or even user requirements, as a result of which possible changes may arise. Project Document Updates for whatever reason (changes, errors, etc.) need to be documented.

5.5

Control Scope

Analogy: During the building of the house, the sponsor may change his mind and want to have certain elements built differently, or contractors may find that certain extra work may be required. All the changes have to be checked whether they fit in the original house design and hence their influence on budget and time. Pitfalls: Scope Creep, e.g. The customer wants a winter garden even though that was not originally specified; Gold-plating e.g. delivering unsolicited extras like silk curtains that the customer neither wants nor needs. The last process under the Scope Management Knowledge Area is concerned with watching the project scope to make sure that the agreed scope is actually delivered. Remember that if significant changes are needed, they must be sent as Change Requests to the Change Control Board. The decisions cannot be made by the Project Manager alone. Control Scope is clearly in the Monitoring and Controlling Process Group and can take place from the beginning of Planning to the end of Closing. Four of the Inputs need no comment: l l l l

Project Management Plan Requirements Documentation Requirements Traceability Matrix Organizational Process Assets.

The final Input is Work Performance Information, the reports about what work has started, finished and how much remains to be done. This may be given as a percentage complete or an estimate of how much time is needed to finish. These Inputs are the only Tool and Technique used in Variance Analysis, which means tracking how much the scope is different from the current plan. This is the combination of the original plan, together with any approved changes. It also involves deciding whether corrective action is needed. If there are Approved Change Requests, they should be checked to see if scope baseline should be updated. Typically, the processes in the Monitoring and Control Process Group have several Outputs relating to documentation, corrections, updates and the like. The Outputs of the Control Scope process are:

5.6 Exam Aids l l

l

l l

73

Work Performance Measurements Organizational Process Assets Updates: This is the first time updating them has been mentioned, which can arise due to changes made. Change Requests: can include requests for defect repair, corrective actions, change of scope and also new ideas. Project Management Plan Updates Project Document Updates.

As these Outputs have been touched upon in earlier chapters, we complete our review of the Scope Management Knowledge Area.

5.6

Exam Aids

Process Summaries 5.1 Collect Requirements: Ensures that the stakeholders’ requirements have been defined and documented. 5.2 Define Scope: Describes in detail both the project and its product. 5.3 Create WBS: Divides the project into Work Packages, so that it can be assigned for execution. 5.4 Verify Scope: Checks and confirms that the deliverables are accepted by the customer. 5.5 Control Scope: Monitors the project for adherence to the scope and manages scope changes.

Flash Card Terms Acceptance Criteria Accepted Deliverables Affinity Diagram Alternatives Identification Approved Change Requests Assumptions Brainstorming Change Requests Collect Requirements Control Accounts Control Scope Create WBS Decomposition Define Scope Deliverables Delphi Technique

Expectations Expert Judgment Facilitated Workshops Focus Groups Group Creativity Techniques Identify Stakeholders Inspection Interviews Job Shadowing Joint Application Development, JAD Mind Maps Nominal Group Technique Observations Organizational Process Assets Organizational Process Assets Updates Perform Quality Control

74 Product Analysis Product Scope Description Project Charter Project Document Updates Project Exclusions Project Management Plan Project Management Plan Updates Project Scope Management Project Scope Statement Prototypes Quality Function Deployment, QFD Questionnaires and Surveys Requirements Documentation Requirements Management Plan

5 Scope Management Processes Requirements Traceability Matrix Scope Baseline Scope Creep Scope Statement Stakeholder Register Subject Matter Experts Validated Deliverables Variance Analysis Verify Scope WBS Dictionary Work Breakdown Structure, WBS Work Package Work Performance Information Work Performance Measurements

Chapter 6

Time Management Processes


l

l

l

l

l

Time Management is one of the most important knowledge areas. It depends strongly on what the individual activities are and how long they take to execute. Define Activities is a distinct step, separate from the other related planning activities such as duration estimation. The purpose is to make sure that all activities are identified. In the Sequence Activities process, the dependencies between activities are identified. Doing so may lead to identifying new details and activities that were not visible earlier. These details may even result in changes to the scope statement. Independently, the resources needed for each activity are estimated using the Estimate Activity Resources process. In the same way we can Estimate Activity Durations without considering the dependencies. With the Outputs from these processes, we can now Develop (the) Schedule. This is then checked against the project constraints, after which adjustments can be made before the schedule is finalized. The agreed version of the schedule is called the Schedule Baseline. The process to Control (the) Schedule is applied with reference to the Schedule Baseline.

Project Time Management Project Time Management is familiar to everybody in project management. The Stakeholders are very interested in which deliverables are being delivered and when. This big interest in the timing of deliverables is quite normal. Those who get the Project’s Product are waiting to use it as soon as possible. For example, when a new ´ Conchuír, Overview of the PMBOK® Guide, D. O DOI 10.1007/978-3-642-11188-4_6, # Springer-Verlag Berlin Heidelberg 2010

75

76

6 Time Management Processes

product developed in a laboratory becomes ready for production, the marketing and sales departments also activate preparations to promote the new product. In general, anybody who depends on getting the project deliverables can only plan properly if the delivery dates are estimated accurately. It is not good enough to say that “because research is not predictable, we cannot accurately say when we will be able to deliver”. The product development manager must find ways of making the time estimates more accurate. By applying these special methods in the time management processes, the customer expectations can be better met. As experience grows, the processes can be continually improved to the benefit of future projects. The simplest project time management tool is a Milestone List, showing when each stage is to be completed. The Gantt Chart, or bar chart, is also widely used because the results of any planning process can be presented in this format. There is a lot more to project management than just time management. It also includes management of scope, quality, risk and indeed all of the nine Knowledge Areas. In spite of this, Project Time Management always has (together with cost management) a high priority. Under Project Time Management, there are six processes, five of which are in the Planning Process Group and one in Monitoring and Controlling (Table 3-1). In reality, they are applied iteratively so that as one process is developed, the Outputs are fed back as Inputs into the other processes. If this Knowledge Area appears too detailed or complicated, remember these points: l

l

The sequence of the first five processes is clear and easy to understand, making it also easy to communicate. The time management planning processes can be simplified, particularly for small projects. Each project detail is developed and then checked against other project details that everything is still consistent.

6.1

Define Activities Analogy: Once each Work Package has been defined (e.g. the bathroom), the underlying activities have to be defined (tiling, plumbing, electrical wiring, sink installation etc.). Pitfalls: Forgetting activities, wrong milestones, forgetting placeholders for activities that will be defined in more detail later (Rolling Wave Planning).

To start, we first have to identify each Activity that has to be carried out, and then base the time estimates on these components of work. This allows us to communicate with the stakeholders objectively, and this in turn helps to manage their expectations. Remember that a project is unsuccessful if it does not meet expectations, so everything that helps to ensure a good understanding of what to expect is helpful.

6.1 Define Activities

77

The clever part of this process is to focus only on what the activities are. Do not yet spend time on analyzing who does what, linkages between activities etc. These important details are defined later. Why does it make sense to keep these topics apart for separate consideration? Here are at least two very good reasons: l

l

We stay focussed on ensuring that ALL activities are included. Unless we make quite sure that all activities are included, our estimates of delivery time will usually be too optimistic. In other words, we will deliver too late. We can expect either to annoy stakeholders or to have to work long hours to meet the deadline. Name the activity appropriately. The choice of activity names has a big impact on our understanding of what has to be done. A very good way of doing this in Indo-European languages (including English of course) is to describe the activities as a verb followed by a noun. For example: The activity to “Test the module” is in this format. When the person responsible says they have completed the activity, we can ask: Did you “test the module”? Everyone understands what is expected.

If we had called the activity “Module Test” instead, then it is not at all as clear what is meant. Here are some possible interpretations: l l l l l l

Test the module, or Check that a module test exists, or Set up the module test, or Test and communicate results for the module, or Authorize the module test, or Accept the module test results, etc.

It can be even worse when we have one understanding of a task and a stakeholder has a completely different interpretation. In this case, the deliverable will not meet the customer’s expectation and this leads to potentially difficult conflicts. For example, we may think that the activity is only to “test the module” but the stakeholder expects the activity to “test the module and document, resolve any problems (outside working hours in your own time) and then forward the results to the factory manager”. What two people expect is usually not the same. The solution is to focus on Define Activities as an independent process as well as to make quite sure that everybody has the same understanding and to document this very carefully. This “verb, noun” structure is so important that its consistent application was one of the main improvements made by the Project Management Institute for the 4th edition of the PMBOK® Guide. By now we should immediately recognize the two following Process Inputs: Enterprise Environmental Factors and Organizational Process Assets. Of course the details should be related to this situation. For example, “environmental factors” here refers to what is relevant to the project (or phase, sub-project, etc.). Whether the company was taken over and the company head office moved to another country is probably not relevant for a sub-project planning to upgrade some production machinery.

78


The Process Input to note is the Scope Baseline, which is an Output of Process 5.3: Create WBS. This means that the project scope has to be agreed upon before we can start to identify the activities. In other words: “agree what the major work packages are before you define the activities.” This point is worth emphasizing because experience shows that many project managers start with the detailed planning without also checking the scope. As this is iterative, the order is not as important as the end result. Listing activities without checking scope with the stakeholders is a mistake. When these Inputs are available, we can move on to the Tools and Techniques, of which the first is Decomposition. We have already seen this in the context of creating the WBS, however the difference here lies in the level of detail. It means “break everything down into smaller elements”. For small projects, the activities could be equivalent to work packages. The next item in the Tools and Techniques is called Rolling Wave Planning. This is instinctive to all project managers and is given a formal name in the PMBOK® Guide. It means that details are added progressively to the project plan, depending on the stage which the project has reached. For example, during Planning we will put a lot of effort into identifying the design activities. At this stage we do not yet need to work out the details of Closure, such as what time the final project celebration party will start. That is simply far too detailed during the early project phase. Sometimes even the project core activities cannot be completely planned at the beginning. In cases like this, the planning becomes an ongoing iterative process. An advantage of Rolling Wave Planning is to separate the details needed now from discussions which can be held later. All project managers have far too much to do already and diverting into unnecessary detail slows the whole project down. It also increases the project risks because getting into such detail takes management time from other important issues. The next Tool and Technique is the use of Templates. This is usually a good way to simplify project planning, because it exploits, or leverages, previous experience and reduces the planning effort needed for the current project. If each project is very different, it may not be worthwhile to document the templates formally. Instead we can use the planning documents from an earlier project as templates. They can then be modified and validated for the new project. The interactive discussion that this requires is also a very good way of building up team spirit. This approach requires much less effort than formally archiving templates that have been developed until they are “perfect”, for example by the Project Management Office, PMO (if one exists). This is useful only when many projects are similar and the templates can be reused. Because we are discussing Define (the) Activities, these templates will probably include checklists of details that we do not want to forget, as well as standard milestones and other information.

6.2 Sequence Activities

79

The last Tool and Technique is well known to us by now and concerns the use of Expert Judgment. As always, this has two elements: l l

The Expert The Judgment.

Next, we consider the Process Outputs which include, of course, an Activity List. The important characteristic of this list includes comprehensiveness, or completeness. This means that every activity (at an appropriate level of detail) is included. Each activity also has a unique identifier (for example a unique number) to simplify cross reference and should contain enough detail about what is included (“scope”) so that the project team understands what needs to be done. A good way of developing the Activity List is to use creative techniques, such as Brainstorming, Mind Mapping etc. and then to go back through it in detail to include the “verb, noun” format previously mentioned. The next Output is called Activity Attributes which means the features or detail about the activities. Examples of Activity Attributes can include: who will do the work, where the work will be done, what quality standards are relevant, expected delivery dates etc. Very often, the attributes are recorded in a table or spreadsheet together with the Activity List. These can be documented using Project Management tools such as Microsoft Project or Lotus Notes. Even so, the project manager must make sure personally that the descriptions are properly written. The Activity List and Activity Attributes are just parts of a list. They can be sorted into groups and this can be useful in helping us find out if something important has been left out or forgotten. It is better not to spend time on the order or sequence at this stage because this diverts from the main purpose of making sure that the list is complete. Some thought about the sequence can help us make sure nothing has been overlooked or forgotten, but it is better to leave out this detail until we carry out the next process (Sequence Activities). One more Output is needed and this is the Milestone List. Milestones are “instants in time” when something important in the project happens. We can think of Milestones as a link between the project deliverables and dates that are important to the stakeholders. Of course the project team members are also project stakeholders themselves, because if they cannot deliver on time, they may find that their reputation is damaged.

6.2

Sequence Activities Analogy: Once the activities have been defined, the next step is to define their order. For example, a wall cannot be painted until the wall itself has been built. Pitfalls: Forgetting dependencies, wrong calculation of leads and lags.

80


Using the complete list of activities together with enough detail about each one, we are now ready to work out the relationships between them. All the Process Inputs come from the Outputs of other processes, so we do not need to repeat the discussion about any of them here. They are: l l l l l

Activity List Activity Attributes Milestone List Project Scope Statement Organizational Process Assets.

The sequencing process sorts the various activities into the order in which they will be implemented. This method applies well in structured project situations. For example, a new car model is manufactured only after the prototype has been tested and the design information has been transferred to the factory. The extra costs of not following the sequence would be simply too high. This approach is the basis of the first Tool and Technique, the Precedence Diagramming Method, PDM. This diagram shows “which activity precedes (or comes before) another activity”. Other names used for this diagram are Schedule Network and PERT diagram. In the example of Fig. 6-7, each box represents an Activity from the Activity List. The arrows show the order or sequence of the activities. There are theoretically four possible combinations for the arrows, or relationships, depending on when an activity may start or finish. For example, a Finish-to-Start, FS relationship means that an activity may only start when the previous one is finished. Another type of relationship is Start-to-Start, SS, where an activity may start when the previous one has started, but is not necessarily finished. These four relationships are presented in the standard and you need to know them for the PMP® examination. However, in the real world the most commonly used is the FS relationship; the SF combination is rare. Like all planning activities, this process is interactive and can be very effective using flip charts and Post-it® notes, white boards or web meetings. Of course you can then record this information in a table, such as in Microsoft Project. Even though the project implementation process defines the PDM, in practice project managers do not always follow this rigid sequence. This is because several major trends have taken place since PDM was first introduced by the US Navy in the 1950s under the title PERT Method. These trends include: l

l

For Iterative project methods. As is the case for software development, describing activities sequentially is appropriate only at the higher levels of the WBS (Work Breakdown Structure). Typically in the IT business, some product development is done first and the results are shown to the users. Their feedback is then used to improve the design. Clearly it is not possible to build a bridge using cycles like this. The global competition today demands shorter and shorter project life cycle times. Often we have to start on a work package even if everything is not entirely

6.2 Sequence Activities

l

81

ready. In earlier times, it was possible to have an account at the local garage and pay car repairs every 6 months. Such a relaxed view about the time value of money (interest) is unusual in the western world today. Communications have improved hugely. In the 1950s there were no mobile phones, no messengers, no chat, no e-mail, no fax, no text messaging, no social networks etc. As mentioned earlier, I worked once in a factory which had only one e-mail address for the entire business. Today this is unimaginable. The limited communication possibilities of earlier times resulted in an emphasis on completing everything in a work package before sending the results onwards (often somewhere else) and allowing the next work package to start. If an activity is started before the completion of preceding activities then this constitutes Fast Tracking and should only take place after an explicit decision to do so.

Previous editions of the PMBOK® Guide also described another method called the Arrow Diagramming Method (ADM), where the arrows represent the activities and the circles (or boxes) represent the milestones. This is mentioned here in case you find this form of Schedule Network in some publications. It looks similar to PDM but it is not exactly the same in detail. PDM has a number of advantages and has therefore completely replaced the ADM, both from the 4th edition of the PMBOK® Guide and in practice. For the PMP® examination you can safely ignore ADM. The next Tool and Technique is called Dependency Determination and this is related to the relationships which we have just discussed. There are three categories of dependency: l

l

l

Mandatory Dependencies, which we must meet. An example is the requirement to install new factory equipment during a weekend when we can do it without a loss of production. Discretionary Dependencies, where we have some discretion or choice whether they should be taken into account. They may be considered to represent good practice. External Dependencies. Here the word external means “outside the project”, whether within the organization or not. An example is the introduction date for a new legal requirement. Generally we cannot negotiate external dependencies but must work with them.

The next information to be added to the Schedule Network is Leads and Lags. This means identifying an additional time buffer that can be used to maintain the completion date. In this context, Lead (pronounced “leed”, not “led”) means that an activity starts earlier. For example if we are cooking the dinner and start to tidy up before finishing the cooking, the activity “tidy up kitchen” has a lead over the activity “cook the dinner”.

82


A Lag is the opposite, a delay. An example is when some material must be packed and then posted to the customer, who will need to use it right away. The Activity “pack the material” is followed by a lag (delay), i.e. the time needed by the postal service to deliver the material. The next activity “use the material” can start after both the end of the first activity and the lag or (delay). The last Tool and Technique for this process is Schedule Network Templates. A template is based on previous experience and can be particularly useful in project situations where similar work is repeated. For example, a schedule network for the fitting out of a building with electricity, heating and telephone lines can only be done when the structure has been built. However, the schedule network is nearly the same for every floor, so it can be copied and adjusted. Notice that the Schedule Network is not only independent of the work, but also that the basic version does not show the timing. This means that the schedule networks for two similar sub-projects will look the same, even if the detailed dates when they are carried out are not the same. We are now ready to talk about the Outputs of the Sequence Activities process. Naturally the main Output is the sequence, usually documented as a Schedule Network Diagram or a table with the same information. The development of the Schedule Network can be really interactive and is an ideal opportunity for teambuilding. I prefer to do this with paper and Post-it® notes and then transfer the results into an electronic format, such as Microsoft Project or other project management software. Another useful way of sharing the information, particularly during the discussions, is to take a photograph with your mobile telephone and send this to everyone for comment. This has the disadvantage of not being easy to edit but the advantage of allowing distant experts to give their comments and feedback. As the process of sequencing the activities is very interactive, this helps us to identify the details of the schedule which need to be adjusted. The closer we look at the details, the more we see exactly how the project should progress. This means that changes are to be expected and they should be documented in Project Document Updates, for example new tasks that were not identified earlier, business and technical risks or how an activity is to be done.

6.3

Estimate Activity Resources Analogy: The next step is to determine which resources installing a sink will require, e.g. how many plumbers, number of pipes etc. Pitfalls: Wrong estimate, double-booking of resource.

When the schedule network has stabilized, we are ready to work out what resources (people, equipment, facilities, etc.) are needed for each activity. If the people and other resources are to be available when needed, then these estimates have to be as accurate as possible.

6.3 Estimate Activity Resources

83

Most of the Inputs have already been described and will not be discussed further: l l l l

Activity List. Activity Attributes. This may include who will do each activity. Enterprise Environmental Factors. Organizational Process Assets.

There is also a new Input: Resource Calendars. This means a calendar showing the availability of each significant human and equipment resource. For example, in a project to upgrade production equipment in a factory, the calendar for the resource “access to the production line” will show when the factory is not active (such as public holidays). In other words, when the installation can take place without interrupting the factory production. Another example of a “significant resource” would be “access to electron microscope” in a laboratory (unless there are so many that they do not need to be reserved – possible but unlikely). On the other hand, if a resource is freely available then it is not necessary to provide a calendar. In Switzerland nearly all trains run at least once per hour. This means that if you miss the train (because you met a friend at the station and went for a beer) you just get the next train. Access to trains for normal usage does not need to be put in the resource calendar. Notice that although the word Resource includes both people (“human resources”) and things (equipment, facilities, etc.); it is often used (unintentionally) only for “people”. Remember this if there is an exam question referring to “Resources”. The calendars for individual people should be as realistic as possible. For example most experience suggests that even a “full time” project team member will be lucky to reach 70% time efficiency, due to holidays, training days, illness, administration, etc. This number is reduced further if the person works, for example, 4 days per week or is assigned to other work, such as another project. Unless this is taken into account, all estimates will be wrong and deadlines will not be met. The resource calendars should recognize important dates such as public holidays and also personal absence, like summer holidays, weddings, absence for training courses, military service, festivals, etc. Whether this detail is open to all or disguised is a cultural matter that varies from country to country. Even so it should not be ignored because the absence of a key person can affect a project badly. Public holidays vary from place to place. For example, in Scotland the two biggest cities, Edinburgh and Glasgow, have different holidays and neither is the same as in neighboring England. In Germany, the public holidays also vary depending on the “Land” (region). And of course, the days of the

84


weekend are not universal but depend both on tradition and law. For example, in Algeria the weekend used to be on Thursdays and Fridays but this was changed by law to Friday and Saturday several years ago. Whether it makes sense to capture all this data is another question. It can quickly get very complicated if all personal, resource, local, national and international calendars are recorded. In principle it is alright to record this detail, but in practice it means a lot of data must be maintained. As always, it is a matter of judgment for the project manager. Except for Expert Judgment, we need to look at each Tool and Technique in turn. The first one is Alternatives Analysis, which reminds us not to take the first available resources, but to look for different ways of meeting the demand. The next Tool and Technique is Published Estimating Data. By cross-checking our estimates with publically available data, we can decide if our estimates are reasonable. For example, if all our competitors offer an 8 week delivery for customizing products similar to ours, then an internal estimate of 17 weeks is different enough for us to ask “Why?” and “Can we improve our performance?” Bottom-Up Estimating is a Tool and Technique which refers to the WBS (work breakdown structure). To estimate what resources are needed, we take each work package one by one and estimate the cost and people required. Adding up the results from all of the work packages (which are shown at the bottom of the WBS) gives an overall project estimate. Often bottom-up estimates are prepared by the project team while analogous estimates are given by management based on previous experience. The resolution can be done using negotiation. If one feature is emphasized, such as delivery date, then there must be flexibility in some other area. If “nothing” is flexible, the result is that the risks and costs will increase or the quality will decrease. Project Management Software is also mentioned as a Tool and Technique. Microsoft Project comes to mind as a very well known application which can be used for documenting the activities, sequences, resources required, etc. It will also print out a Schedule Network. Lotus Notes is another very widely used application. Nevertheless having an application to capture the data does not solve all project management issues. Now we can turn to the Outputs of the Estimate Activity Resources process. Naturally the first Output is the Activity Resource Requirements. This includes enough detail of the attributes (characteristics, features) of each resource so that we know what or who to look for, as well as answers to “when?” and “how much?” There will also, naturally, be some Project Document Updates. The last Output is a Resource Breakdown Structure. This is a very similar idea to the Work Breakdown Structure, but based on the major resource categories

6.4 Estimate Activity Durations

85

(for example: people and equipment). An example is starting at the top with Internal and External Resources, then breaking each of these into more specific groups of resources (remember: both people and facilities, etc.).

6.4

Estimate Activity Durations Analogy: After the resources have been defined, the duration for installing the sink etc. is estimated. Pitfalls: Too optimistic estimate, inappropriate basis for analogous estimation, parametric estimation with too few parameters.

An accurate picture of when the activities will take place is needed so that everybody can make their own plans. Note that “accurate” does not mean the same thing as “as quick as possible”. Imagine, for example, that you must stay at home to allow the washing machine repair person to come in. Which would you prefer: l

l

An optimistic estimate of the arrival time? You take time off work and have to wait at home some hours until he actually arrives. An accurate (but later) estimate of arrival time? You come home just before the repair person arrives.

It is often better to have slower but more accurate estimates than fast but unreliable schedule estimates. This makes the planning for others both easier and cheaper. Luckily, we do not need to discuss any of the Inputs here because we have already seen all of them: l l l l l l l

Activity List Activity Attributes Activity Resource Requirements Resource Calendars Project Scope Statement Enterprise Environmental Factors Organizational Process Assets.

The Tools and Techniques, except for Expert Judgment, require more description. Two methods of estimating are mentioned: Analogous and Parametric, both of which can be used either for duration or cost estimates. Analogous Estimating means that we estimate by comparing with (by analogy with) another previous project. If our project involves building 20 mobile telephone antennas and we know that last year there was a similar project to build ten antennas, then the first rough time estimate would double that of last year’s program.

86


This is an analogous estimate and allows us to make a rough (“order of magnitude”) estimate of how long the project (sub-project, phase, etc.) will take. This must then be reconciled, or fitted to, the result of the Bottom-Up Estimating. Parametric Estimating is based on previous averages, or parameters. It is useful, for example, for preparing cost estimates when bidding (offering, quoting) for service jobs, such as painting a house. Here the basis for the cost estimate can be the surface area of a wall in square meters. The business will have built up experience over the years, based on an average of all projects, so the estimates will be more accurate. It is not, however, worth doing a detailed estimate until the order has been confirmed since an analogous estimate is too rough. Also at this stage before a contract is confirmed, it is not worth the effort to go into the fine project details. In terms of accuracy, Parametric Estimates come between Analogous Estimates and Bottom-Up Estimates. There is usually a compromise, or trade off, between the amount of work put into an estimate and the accuracy. All estimating methods rely on previous experience. Ideally, the estimate is documented and commented, making the figures very transparent. A good, but less analytic alternative is to base estimates on the experience of various experts, in particular the project manager. Another way to get more realistic estimates is to calculate Three Point Estimates, based on a weighted average of the Optimistic (best case), Pessimistic (worst case) and so-called “Most Likely” estimates. This evens out the error margin of only one estimate but also requires more time to collect the data. One way of doing this is called the PERT estimate. You need to know the formulas for this and Standard Deviation, s both of which are given here. Why they are like this is explained in Chap. 8 about Project Quality Management. For now just accept them: PERT ¼

Optimistic Estimate þ Pessimistic Estimate þ ð4Estimate of Most LikelyÞ 6

Standard Deviation s ¼

Pessimistic Estimate Optimistic Estimate 6

There is also a parameter called Task Variance, which is calculated by squaring the standard deviation ( = s2). The first formula above can be used to estimate durations or costs. In practice the PERT average will be skewed to the more pessimistic side. The final way of making estimates is Reserve Analysis. This means that we already automatically build a reserve or buffer into our estimates (of time or money). In Calgary, Canada, it gets very cold in winter, down to minus 40 C and bus passengers would be in great danger of literally freezing to death if the buses did not arrive on time. The timetable is planned with plenty of reserve, so that the buses can arrive within a couple of seconds of the schedule.

6.5 Develop Schedule

87

Reserve Analysis takes this idea further. Instead of just having a single reserve, the amount is divided up into a number of elements. Contingency means keeping reserve available in case things go wrong. If there is no contingency then the risk of not being able to complete the project is higher. Another element in a building project could be, for example, a reserve of time in case of bad weather. We can improve the accuracy of the estimates by breaking down (¼ analyzing) the reserves into elements. Estimating the reserve required for each element separately leads to more accurate overall estimate than having a single reserve. Finally, the Outputs are also what we would expect from an Estimate Activity Durations process: Activity Duration Estimates and, as usual, Project Document Updates.

6.5

Develop Schedule Analogy: Once all the activity durations and their sequence have been determined, they are used to derive the building schedule for the house. Pitfalls: Critical path wrongly identified, resource leveling neglected, schedule compression is too optimistic, leads and lags are ignored.

The previous processes in this Knowledge Area can be executed in any order that the situation demands and their Outputs are now combined to produce the Schedule. This tells us when every activity should take place. We note each of the following Inputs to this process, all of which we recognize from other chapters: l l l l l l l l l

Activity List Activity Attributes Project Schedule Network Diagrams Activity Resource Requirements Resource Calendars Activity Duration Estimates Project Scope Statement Enterprise Environmental Factors Organizational Process Assets.

We now turn to the Tools and Techniques for the Develop Schedule process, the first of which is Schedule Network Analysis. This means analyzing the schedule network which we spoke about before. It may include other techniques such as the Critical Path Method, CPM. It identifies which sequence (“path”) of activities is responsible for defining the duration of the project. Not all activities are “critical” in this sense because they may take less time than other activities that take place in parallel.

88


This method is often explained in great detail, together with calculating forward and backward passes. The advantage of this approach is that it always works. Unless the network is very complex, it may be easier to identify the critical path by inspection or manual calculation. The leads and lags as well as Finish-to-Start (etc.) relationships should also be allowed for. If you are studying for the PMP® examination, then it is best to calculate the schedule network by hand at first, only moving on to the mathematical method when you understand what is a critical path. A method called Critical Chain is also mentioned. This considers both the sequence of activities and the availability of critical resources when defining the project duration. Waiting activities are added for less important resources, so that the critical ones can always work at full capacity. A simple analogy to the buffering in the Critical Chain method is the line of patients waiting to visit the doctor as seen in many countries. By including a waiting activity, the critical resource (the doctor’s time) is fully used and down time is a minimum. This means that the doctor is active (and earning!) all the time. When the schedule has been worked out and the resources assigned, it makes sense to check whether the resources are available or overloaded. If overloaded, then adjustments need to be made so that the plan is realistic for each resource. If not, then the project team can become discouraged and therefore reduce the chances of project success. Using a graph of Resource Loading shows how much of their time each resource is expected to work. When the load for each resource (or group of resources) is adjusted to even out the demand, this is called Resource Leveling. It is tempting to think that leveling can be done automatically, but the functionality of many project management tools is too simple. It is often better to implement Resource Leveling manually. Another analysis method which can be used is called What-If Scenario Analysis. This complicated name describes something simple: various possible combinations of duration, assignment, etc. are proposed and the schedule network calculated for each combination. For example, “What if activity 3 takes 7 days?”, “What if the materials arrive a week late?” etc. There is a method which carries out a large number of such calculations using many different combinations of activity duration estimates. The results are graphed and show what the likely (but impossible!) spread of delivery dates would be if the project were carried out many times. This statistical method is called the Monte Carlo Analysis and is described more fully in Chap. 11. For the PMP® examination it is usually enough to be aware of this method and its purpose. It is not likely that you will be required to know how to use it for the exam, but according to the rules of chance you may be unlucky! The next Tools and Techniques are Applying Leads and Lags, which we have already discussed, and Schedule Compression. This is a nice way of saying “deliver

6.5 Develop Schedule

89

faster”. This technique is a favorite in business, either because something in the outside world has changed or because delays during the execution make a late delivery likely. Depending on how the project was planned in the first place, it may or may not be physically possible to find ways to go faster. If they can be found, it is always at the expense of something else: overloading resources, increasing risks or changing the comparative priorities among several projects. Two Schedule Compression methods described are: l

l

Crashing: adjusting the schedule in such a way that the maximum time benefit is achieved with the minimum extra cost. Extra speed always costs something. Fast Tracking: here the emphasis is on increasing the number of activities taking place in parallel but without spending more money. This will have the sideeffect of increasing risk.

We now look at the last Tool and Technique: Scheduling Tool. In any business project the amount of detail is high. Although pencil and paper methods may be useful to begin the documentation and get agreement of the team and stakeholders, it makes sense to maintain these documents electronically. The Scheduling Tool will capture the activity, sequence data, etc. and use them to calculate the schedule network. The Outputs are easy to describe, the first of which is the Project Schedule. It is the plan which tells us the start and end dates for each activity and milestone. A very common form for the schedule is the Gantt Chart which emphasizes dates. It is possible to include the dependencies between the activities on this chart, but this may overload it if the dependencies are too complex. The activities in the Gantt Chart can include additional detail such as: l l l l l l l l

Who is responsible for each task How long each task should take When they should start When they should finish When the work actually started When the work actually finished The linkages between the various task etc.

Because there is so much information, it may be better to use a WBS and a Schedule Network during planning, and then use the Bar Chart mainly for communicating the schedule. If the Bar Chart is used as the only planning tool, there is a danger that the discussion would go in too many directions, resulting in the project scope being overlooked. The Schedule Baseline is a particular version of the schedule which has been authorized for implementation. The important attribute or characteristic is the agreement on which this version is based, not the format.

90


A minimum form is the Milestone Schedule (Figure 6-14), which only shows when deliverables should be ready. This can be useful for communicating with management but is unlikely to be detailed enough for the project team. The schedule can also be documented as a Schedule Network, based on the PDM, accompanied by additional Schedule Data which is also a process Output. The Schedule Baseline is the authorized version of this. The final Output is Project Document Updates, which may occur in different areas, such as: l l

l l

What resources are needed? Activity attributes, that is something that tells us about each activity, such as who is responsible, the cost estimate etc. Calendar Risk Register. This means the central database for the project in which risks are identified and measures (actions) to minimize or avoid these risks are recorded. This is discussed in more detail in Chap. 11 about Risk Management.

6.6

Control Schedule Analogy: The project manager must regularly control that the reported work on the bathroom is proceeding according to schedule. Pitfalls: Effects of changes and variances not properly assessed, project documentation not updated.

After the long description above about the scheduling processes, we can now review the one process for Control Schedule which is, of course, in the Monitoring and Controlling Process Group. When we look at the list of Inputs, Tools and Techniques and Outputs, the first thing we notice is how many there are. This is typical of the processes in the Monitoring and Controlling Process Group because there are several Outputs requesting changes, updating the project etc. The purpose of this process is simple enough: to check that the project is being implemented as planned (monitoring) and acting to resolve problems (controlling). We compare the actual schedule situation with the plan and act according to what we find. What makes it difficult is the number of different things that can cause change. This is why this process has so many Tools and Techniques. Control Schedule is a bit like driving a car down the country road. The aim is to stay between the hedges! Actually there are a lot of controls such as speed, gears and steering wheel, which is challenging for a learner. Eventually it all blends together and we think that driving is easy.

6.6 Control Schedule

91

Project management is a bit like this, except that there are many, many parameters and most of them are not immediately visible. This makes it more like flying an airplane on instruments than driving a car. Three of the Inputs are already familiar to us: l l l

Project Management Plan Project Schedule Organizational Process Assets.

The final one is clear from the title: Work Performance Information. This means what it says: information about the progress being made, what activities have started and what activities have finished. Other background information may also be important, for example an activity is late because the person responsible for it was ill. The first Tool and Technique is Performance Reviews which measures performance and allows comparison with the plan. It is possible that some activity is behind schedule but not on the critical path. Although this will not affect the project delivery directly, it may affect the availability of resources. As well as tracking the progress, the Float (also called Slack) should also be monitored. If this decreases, the margin of safety is smaller and this is a warning sign. If the number becomes negative, there is no more room to maneuver and indicates that the project cannot be delivered on time without Corrective Action. Total Float and Free Float refer to the effect on delays of using up the float. The Scheduling Tool is where we put the data about the actual progress of the project. It will be a version of the various tools we used to plan the project, such as Gantt Chart and Schedule Network. The difference is that during planning we were looking for a single agreed reference version of the plan while here we are updating it continually. Clearly it would be easier using an electronic tool than pencil and paper methods. The remaining Tools and Techniques are described in Sect. 6.5. Finally we review the Outputs, which are also easily described: l

l

l

l

Work Performance Measurements refer, for example, to if and when an activity started, when it finishes etc. Of particular importance are the Schedule Variance, SV and Schedule Performance Index, SPI which represent the time progress of the project compared with the plan. Rather than describe these formulas here, we will cover them in the Project Cost Management Knowledge Area, where the related parameters of Cost Variance, CV and Cost Performance Index, CPI are also discussed. Organizational Process Assets Updates refers to the adjustments to the processes, based on the experience of the project. Project Management Plan Updates and Project Document Updates are to be expected, also based on project experience. Change Requests arising from how the project proceeds.

92

6.7


Exam Aids

Process Summaries 6.1 Define Activities: Generates a list of all actions which must be carried out for the project to deliver. 6.2 Sequence Activities: Determines the best order of implementation for the project actions. 6.3 Estimate Activity Resources: Identifies which resources and how much of each is needed by the project. 6.4 Estimate Activity Durations: Assesses how long each activity should take to implement, based on the proposed resources. 6.5 Develop Schedule: Brings together the Outputs of the previous procedures in a consolidated time plan. 6.6 Control Schedule: Acts on differences between the time plan and the actual project progress, so that the project finishes on time, recognizing managed changes to the baseline.

Flash Card Terms Activity Activity Attributes Activity Duration Estimates Activity List Activity Resource Requirements Alternatives Analysis Analogous Estimating Applying Leads and Lags Bar Chart Bottom-Up Estimating Brainstorming Change Requests Control Schedule Corrective Action Cost Performance Index, CPI Cost Variance, CV Crashing Critical Chain Critical Path Method, CPM Decomposition Define Activities Dependency Determination Develop Schedule Discretionary Dependencies Enterprise Environmental Factors Estimate Activity Durations

Estimate Activity Resources Expert Judgment External Dependencies Fast Tracking Finish-to-Start, FS Float Free Float Gantt Chart Leads and Lags Mandatory Dependencies Milestone List Milestone Schedule Mind Mapping Monte Carlo Analysis Organizational Process Assets Organizational Process Assets Updates Parametric Estimating Performance Reviews PERT Precedence Diagramming Method, PDM Project Document Updates Project Management Office, PMO Project Management Plan Project Management Plan Updates Project Management Software Project Schedule

6.7 Exam Aids Project Schedule Network Diagrams Project Scope Statement Project’s Product Published Estimating Data Reserve Analysis Resource Breakdown Structure Resource Calendars Resource Leveling Resource Loading Risk Register Rolling Wave Planning Schedule Baseline Schedule Compression Schedule Data Schedule Network Schedule Network Analysis Schedule Network Diagram

93 Schedule Network Templates Schedule Performance Index, SPI Schedule Variance, SV Scheduling Tool Scope Baseline Sequence Activities Slack Standard Deviation, Start-to-Start, SS Templates Three Point Estimates Time Management Total Float What-if Scenario Analysis Work Performance Information Work Performance Measurements

Chapter 7

Cost Management Processes


l

l

In most environments, Project Cost Management is usually as important as Project Time Management. It is however very difficult to keep costs within the budget because they depend both on prices and durations, both of which can vary considerably during Project Execution. Project Cost Management makes a clear distinction between the process to Estimate Costs (as seen by the project manager) and, Determine Budget (the assignment of costs). Estimate and Budget have different significance and should be aligned with each other by negotiation. Control Costs is achieved with reference to the Cost Baseline. The PMBOK® Guide promotes the use of Earned Value Management, EVM. This means that PMP® candidates must understand the important EVM formulas.

Project Cost Management Project Cost Management is something that every project manager is familiar with. Compared with all other project management Knowledge Areas, the importance given to Cost Management is always high. Why is this? Are all the other areas starting with Scope Management, through Time Management to Risk and Quality Management not also important? After years of project management experience, I offer the following interpretation: l

l

To spend money authorization is needed. You cannot spend money you do not have. Everything else can be done without authorization. You can be late, you can have poor quality, you can have high risks, etc., all without having to ask permission!


95

96

7 Cost Management Processes

Every company exists to make money, so there are systems in place to watch over this important part of the enterprise. The refusal of a payment authorization often means that a project cannot proceed. In organizations with a high level of project management maturity, the control of other parameters is also very tight, but the money is always well controlled. This can be of mixed benefit to projects. Business finance control is usually run on a monthly and yearly cycle. This means that the consolidated financial reporting does not always match project requirements. There are only three processes, two in the Planning Process Group and one in the Monitoring and Controlling Process Group. The approach is simple: the costs are estimated, then aggregated and finally a budget is approved to pay for them. During execution, the costs are controlled.

7.1

Estimate Costs Analogy: Once the duration and resource needed to install a sink has been identified, the next step is to determine how much installing this sink will cost (cost of plumbers, sink). Pitfalls: Forgetting indirect costs, not documenting the basis of estimates.

It is clear that project costs must be estimated before execution can start. This is because an explicit decision has to be made whether investing in the selected project is the best way of using the organization’s capital. Every project is also in competition with every other project for funds and resources. The accuracy of the estimates at the beginning of the project will not be as good as later on, when more detailed information becomes available. This is Progressive Elaboration in relation to cost management. It is also clear that project costs depend heavily on other areas, such as Scope and Time Management. Accurate project cost estimates depend on an accurate and agreed upon plan explaining how the project will be carried out. This is not an easy task. Factors that influence costs include, but are not limited to: l l l l l l

The way the project is designed What technical approach it used Whether the work is done internally or outsourced (“make or buy”) How many people are involved What they cost and how this varies depending on where they live and What the materials cost etc. are.

Even after all the estimates have been determined, they can still be affected by unexpected price changes due to the weather, exchange rate changes, politics, strikes, disasters etc. In addition, if a project does not deliver on time, even more money will have to be spent to complete the remaining work.

7.1 Estimate Costs

97

The first Input to the process is the Scope Baseline, in other words, the agreed project scope. Project scope is the first item that will influence costs and any change in scope will most likely affect the costs. The scope simply must be controlled if the cost is to be controlled. We now see another reason why starting a project by going straight into the planning without initiating is unlikely to work well. The format of the Scope Baseline includes the Scope Statement (which is a text), the WBS (Work Breakdown Structure) and the WBS Dictionary, all items that have already been discussed. The next Input is the Project Schedule. This has a big influence on the costs in several ways, for example: l l l l

l l l l l

How long will the team be active (and costing money)? Which skill levels will be used? How accurate is the schedule? Overruns will result in increased costs. What are the duration estimates for each activity and how accurate are they? If any tasks take longer than planned, then their costs will rise. What will the material costs be when the project is implemented? What happens if we do not get good prices for supplies? What cost should be added for interest and other fees? How stable are exchange rates? Do any costs have seasonal variations?

Some of these matters are also relevant to the next Input, the Human Resource Plan. This plan tells us who we need, what skill levels, where and when. We also need to know the total cost of staff for each grade, including social costs. This is usually done anonymously to protect privacy, but often results in reduced cost estimate accuracy. For many projects, the most significant costs are staff-related, so this is an important Input. Many companies (often in manufacturing, financial services etc.) treat staff costs as overheads and do not explicitly include them in the project costs. This means that these costs are paid by the business, together with those for buildings and facilities costs, IT installations and other business items. Other types of companies (such as consultancy) charge these costs directly to each job. When making the Business Case for a project, estimates of the overhead costs that are related to the project should be included. Whether these costs are tracked during implementation depends on the practice within the organization. The process Inputs Enterprise Environmental Factors and Organizational Process Assets are familiar. They must be interpreted in the context of cost management. For example, existing accounting processes cannot be ignored and replaced by other internal project methods. But if you want to collect information which the system does not generate, then the best approach may be to do it yourself. The Enterprise Environmental Factors should include the economic situation, employment statistics (which affects the availability of skills) and other external factors. One of these which the project manager cannot influence is global exchange

98


rates. If a project is authorized at a given exchange rate and sudden currency changes make the project no longer worthwhile, then any decision to stop should be made by the Sponsor and other Stakeholders. Although the project manager cannot compensate for issues totally outside his control (unless given special resources such as contingency reserves), he is responsible to report the situation. This is one reason why reporting is such an important topic and this is mentioned in more detail in Chap. 10, Communications Management Processes. The last process Input is the Risk Register, to be discussed further under Project Risk Management in Chap. 11. This process has a particularly large number of Tools and Techniques. You will be glad to note that several are the same as or similar to the tools previously used for the Estimate Activity Durations process. We start with the Tools and Techniques which are similar to those used for duration estimates, but applied to costs: l l l l l l

Expert Judgment Analogous Estimating Parametric Estimating Bottom-Up Estimating Three-Point Estimates and Reserve Analysis.

Project Management Estimating Software is also a Tool and Technique. Remember, however, that all estimates depend on experience (or history) and the tool can only help keep the data up to date and maybe also do some statistical analysis. Of course, this is useful, but it is not a magic way to generate estimates. The results should always be checked for plausibility. The remaining Tools and Techniques are Cost of Quality (which is discussed in Chap. 8, Project Quality Management) and Vendor Bid Analysis. What does this last Tool and Technique mean? Vendor means supplier or seller. Remember that vending machines are familiar in public places for selling chocolate and soft drinks. Bid is another word for Offer or Quotation. In other words, Vendor Bid Analysis means looking at (analyzing) the offers for implementing a particular part of the project. For example, we want to test some material and we ask three laboratories to submit their bids (quote or offer their prices). By looking at the responses of the various vendors, we can compare the costs, even if we are not expert in this type of work. Some warnings: l

l l

l

The suppliers may have joined up (in a cartel) to fix the prices or have a monopoly. Sometimes this is done elegantly, for example, in many countries by lawyers. Maybe the prices are high because the supplier does not really want the work, for whatever reason. Maybe the prices are low because perhaps the supplier uses black market labor.

7.2 Determine Budget

99

With this method, we can effectively delegate the cost estimating to the suppliers and must only be aware of possible errors. If this technique is used, we should have cost estimates that are as accurate as the situation allows. There is also enough information for others to have confidence in the estimates. Activity Cost Estimates is the first Output of the Estimate Costs process. Often there is an element which is fixed, for example, equipment purchases which are based on firm offers. On the other hand the staff costs (in particular consultants – I know because I am a consultant) depend on how long the work takes to do. If these cost estimates are to be close to the final cost, active monitoring and control is essential. All stakeholders want to be sure that this difficult area is always under control. This means that they want to be able to cross-check the way that the cost estimates were made. The process Output that allows them (or you) to do this is called Basis of Estimates. This includes not only the cost estimate but also the process by which they were made, as well as assumptions and constraints. If different assumptions are made, then different costs will be estimated. For example, if we assume that an activity will be done by our own staff but they are actually neither skilled enough nor available, then the estimated costs will be wrong. This example shows why this background information is as important as the actual cost estimate figures. The cost estimating process, indeed all project planning processes, often results in finding detailed changes that have to be added to the documentation. The Project Document Updates are therefore, not surprisingly, included in the list of process Outputs.

7.2

Determine Budget Analogy: When all costs of the activities have been determined, they are combined to give the complete budget for building the house. Pitfalls: Cost synergies not identified, no reconciliation with funding limitations. The process by which the cost estimates are aligned with the source of funds is called Determine Budget. It has the following familiar Inputs:

l l l l l l

Activity Cost Estimates Basis of Estimates Scope Baseline Project Schedule Resource Calendars and Organizational Process Assets.

100


The only Input which is new to us is Contracts for services or products that are needed for the project. Usually cost estimates are collected when the activities are indentified. We start the Tools and Techniques with Cost Aggregation. This simply means combining the costs of the work packages from the WBS to get a cost estimate for the whole project. We have already seen that cost estimates are the results of the project manager’s professional estimate of what the project will cost, based on the authorized scope. This may be more or less expensive than what was initially expected. If the available budget is less than the cost estimates, then we need to identify what can be reduced. There are many parameters which can be changed, such as scope, skill levels, availability, constraints and so on. This is acceptable, provided the revised cost estimates and budget still match. It is not advisable to just promise to work faster or harder as a way of meeting the budget. In fact it can have negative results, such as making the project team lose their motivation. An important point is to achieve alignment by adjusting how the project is to be implemented and not by forcing unrealistic estimates. If the project specification and its parameters cannot be changed even though the budget is less than the cost estimates, then the result is a risky compromise. The risk that the project will not meet expectations or finish on time will become much higher. To reduce the potential impact of risks, a reserve amount can be added to the cost baseline. When everything is agreed upon, the Cost Estimates plus Reserve will equal the Budget Amount. Reserve Analysis is another Tool and Technique that breaks down the reserves into different elements, so that better estimates can be made. The elements are: Management Reserves, which are used if unexpected problems arise and Contingency Reserves, an amount of money related to the actual project situation, which is set aside for identified risks. Two more Tools and Techniques are Expert Judgment, which has been mentioned a number of times, and Historical Relationships. A simple example is the cost of constructing an office block, based on the cost per square meter of recent comparable contracts. These relationships are used for calculating cost estimates mathematically. The final Tool and Technique is Funding Limit Reconciliation. This means checking the funding required against when the money can be made available. For example, the company may be expecting a large payment from some other work, which will make it possible to implement a particular work package. If the funding limits are exceeded, a typical solution is to delay part of the work until the funds become available. The Outputs are straightforward. The Cost Performance Baseline combines what funds will be made available with the timing information about when they will be made available. This is an important element of the Earned Value technique, which is discussed later in this chapter.

7.3 Control Costs

101

The Project Funding Requirements, on the other hand, detail the funding amounts which will be required over time. These amounts include any reserves and should be reconciled with the funding limits. Finally the Project Document Updates are a natural Output of a process such as this. This will note new data (cost performance baseline, etc.), together with other areas where details have been finalized, such as risks.

7.3

Control Costs Analogy: The project manager must regularly control that the money spent for construction is according to budget. Pitfalls: Effects of changes and variances not properly assessed, project documentation not updated, neglecting budget forecasts.

In this section we first consider generic cost control. This is based on the cost estimates and authorized budget. Next we examine the Tools and Techniques used to generate these Outputs, with particular emphasis on Earned Value Management, EVM. This is one topic with which exam candidates should be very familiar. Finally, we examine the Outputs. This process interacts with several related topics including: l l l l

Making sure that no uncontrolled changes are made Understanding why the actual costs and the planned baseline are different Keeping good contact with stakeholders about cost developments and Modifying the project if costs are going outside the budget. The Inputs do not have to be described here, because we have seen them all before:

l l l l

Project Management Plan Project Funding Requirements Work Performance Information Organizational Process Assets.

Now we move into the Tools and Techniques of the Control Costs process which actually consolidates most of what we have done so far in project management. The key Tool and Technique which is used to control cost is called Earned Value Management, EVM. Its purpose is to ensure that value and expenditure stay approximately the same during the project execution. Early users included the US Department of Defense. Their interest was (and still is) to ensure that the project expenditure is in line with the value of the deliverables. This is very relevant for expensive projects running over several years, where the deliverables become available only towards the end. Until the deliverables are actually delivered, the

102


entire investment is always at risk because something might happen to prevent the project completing. Actually, Expenditure and Value are different, as the example highlighted below illustrates. Expenditure is what we have spent, in other words, the actual costs. If we are good project managers, this will be as planned, but in the real world there are problems such as: l l

l

Price changes that happened after making the estimates. Extra costs because the work was not completed on time. The project team had to keep working, resulting in unplanned costs. Extra costs for deliveries. Maybe some material would cause expensive delays if not available, so we pay a courier to collect this material.

Value is what something is worth. Economics books will remind us that the way to prove value is for somebody to buy something. All the issues such as availability and quality etc. are finally incorporated in the price. The value is the amount of money you get when something is sold. A builder gets a contract from a family who already has some land to build a house. The family agrees to make stage payments: 20% of the cost when the foundations are built, another 40% when the roof has been built, and so on. Unfortunately for the family, the builder goes bankrupt before the house is finished. The house lies partially completed for some time. It is damaged by the weather and passers-by who remove some of the unused material, because they think the house has been abandoned. As time toes by, the value decreases although the expenditure is unchanged. What can the family do? Here are two options: 1. Get another builder to take over and finish the house. 2. Sell the partially built house and start again somewhere else. Now consider the scenario of the family whose situation is highlighted and start with option 1. If they get another builder, they will have to pay him with the money which has not been spent. If however the first builder was not very good at cost control, he will have spent more money than the partially finished house is worth. In other words the Value will not be the same as the Expenditure. In this case the new builder will probably offer a price to finish which is more than the money left. Maybe option 2 would be better? If the family tries to sell the partially build house, do you think the money they have already spent is of interest to the new buyer, if there is one? Will the new buyer be interested in compensating the family for bad cost control? A half built house is like (indeed, it IS) an incomplete project. But what is the market demand for half built houses? The Value of a half built house (the amount of

7.3 Control Costs

103

money somebody will pay for it) is probably going to be much less than the Expenditure. The family is going to make a loss and then will not have enough money to build another house. All projects are like this. During the project and before the deliverables are handed over to the project customer, the Work in Progress is like the half built house. Its Value is likely to be less than the Expenditure. This is not very comforting for the project sponsor, who has to provide the budget. In general, the market for half completed projects is not good. This means that until a project is finished, or at least some usable work packages have been completed, the company’s investment in the project is at risk. This brings up two issues: 1. Can we phase our projects in such a way that the value is delivered as early as possible? This would be much better than getting it all at the very end. How to do this depends on the particular project. The example about building a supermarket suggests that it makes sense for project managers to see what value can be generated early. 2. Can we somehow track the value of a project without selling it (as the economists would tell us) to check the real value? This is the thinking behind Earned Value Management, EVM. This is such an important topic that some extra sections are dedicated to it below. A project manager in England was responsible for building a large supermarket, which would also sell cheap petrol to attract shoppers. The plan for the petrol station included the usual small shop for soft drinks, newspapers etc. The original plan was to build the supermarket and open it, a big project phase; then to build the petrol station, a small project phase. As most of the time and value was in the supermarket, this meant getting the value towards the end of the overall project. What they actually did was simply to reverse the phases. The petrol station was built first and customers started coming. They also got familiar with the main supermarket because a selection of the products was also sold in the small shop. Then they built the supermarket. By the time it opened, they already had a steady stream of customers who knew where it was and were familiar with the products. As this process is in the Monitoring and Controlling Process Group, we expect several Outputs. Figure 7-7 confirms this point. The first Output is Work Performance Measurements, which are derived using EVM. Here we will just define what they are and describe how to calculate them

104


later. Until then, just remember the names and do not worry about how we derive them: For cost tracking: l

l

Cost Variance, CV: This terminology comes from accounting practice and means how different the costs are (how much they vary) from the plan. Cost Performance Index, CPI: This is a normalized indicator of cost performance. Normalization means that the scale of values expected is the same for all projects. For schedule tracking:

l

l

Schedule Variance, SV: This terminology also comes from accounting practice and means how different the schedule progress is from the plan. Schedule Performance Index, SPI: This is a normalized indicator of schedule performance. As before, normalization means that the scale of values expected is the same for all projects.

Now for the surprising part: The SPI and SV are calculated from COST data! This is actually very practical as all companies have a system for tracking costs, otherwise they would go out of business. How exactly we do this is shown later in this chapter. The advantage of this approach is that progress can be summarized in just two parameters, CPI and SPI. This level of detail is just right for program managers and those who may be stakeholders in several projects at once. If these numbers indicate a problem, then they can always be investigated in more detail. The next Output is Budget Forecasts. This is something new, because until now all Outputs have been reports of something which had already happened. To have a chance of controlling costs, we must also look into the future using our existing experience. If trouble is approaching, stakeholders will want to know about it before it happens. In particular, our estimate (now) of what we think the total costs will be (when the project is finished) is called Estimate at Completion, EAC. The name does not say that the estimate is a cost estimate; you just have to remember this. All of the other Outputs are similar to ones we have already seen and understood: l l

Change Requests Updates to: l Organizational Process Assets l Project Management Plan and l Project Documents.

This is to be expected: when we see how the project is progressing, there will always be differences between the plans and what actually happens. We have to keep the objectives fixed and adjust the work to get there. Just rewriting the plan to compensate for what has happened is a bit like trying to change history. In one sense, project management is a statistical discipline. We can estimate statistically whether some activities can be completed earlier or at lower cost than

7.3 Control Costs

105

planned. Other activities may even take longer or cost more. The trick is to keep the overall project within its constraints of time and money in particular, as well all the other constraints of quality, scope, risk, etc.

7.3.1

EVM Cost Control

With this background, we are ready to see how to use Earned Value Management, EVM to calculate the CPI and SPI indices. The background is described in the highlighted story. I have been assigned as project manager by my wife, the project sponsor, to build a garden fence. She tells me to use 20 high quality wooden posts, and that she will give me a budget of 20 for each post. All the other costs are too small to be counted (for example the wires between the posts) or my labor (which is free of charge). As project manager, I point out that I am only free for this heavy work during weekends, provided that there is no rain or snow and that I am not too tired. I expect to mount 3 posts per week, including buying the materials, digging and making a concrete foot for each post. Each week the project sponsor (my wife) comes into the garden to check progress. What information does she look for? My wife reckons with 20 per post for 20 posts, a total of 400. In other words, if she sees 3 posts fully mounted, she says they are worth 60, whatever they actually cost. Recall the half built house in the example above and the relationship between what was spent and the value. What actually happens the first weekend is that some material gets damaged, which I have to replace out of the project budget. I also spend some of the materials budget on beer, when I meet a friend at the building materials supplier. I actually mount 3 posts and spend 90. To control costs, we now need to introduce a new parameter to relate costs to the Value of the work that has actually been done. Unfortunately, without selling my partially built fence (to my neighbor?), there is no accurate way to estimate value. Anyway, I am a busy project manager and do not have time for all this reporting, so my wife will just have to accept that I spent 90. She does not accept this! She decides to see how much spending she has planned, in this case 60, and decides that this is good enough to use as a substitute for an estimate of value. It is not the value, but a convenient substitute. If I were charging for my time, she would include these costs as well with the (substitute for an) estimate of value. She has read about “Earned Value Management” and knows that this estimate is called Earned Value, EV. This is a budget amount related to when it should have been spent, but the method calls it “value”.

106


According to my wife’s plan, 3 completed posts should have cost 3 20 ¼ 60. Earned Value, EV ¼ 60 Actual Cost, AC ¼ 90 Cost Variance, CV ¼ EV AC; in this case 60 90 ¼ 30. This is over the budget plan for the first week. (notice the minus sign, which means “problem”). I am in trouble. The sponsor must interpret the CV value to know what it means because a 30 amount for one project might be significant, but for a bigger project it would be less important. It is not immediately obvious to her. My wife actually sponsors several other projects, including having me paint the kitchen and build a garage. She would like an easier way to interpret CV. Now instead of using a minus sign (), she turns it into a division sign (), just by adding two dots! EV AC ¼ 60= 90 ¼ 0:67 My wife calls this Cost Performance Index, CPI. This number (0.67) is less than 1 (one) and tells us that I am over budget, that: my costs are higher than planned. Here is the clever bit: CPI is 1 (one) for ANY project which is on track for costs. My wife does not need to interpret this figure. She knows without thinking that a CPI of 0.67 is “bad news”. In the same way a CPI of 0.84 for painting the kitchen is “bad news” and a CPI of 1.24 is “good news” for building the garage. This makes it is easy for the project sponsor (my wife): 1 is OK; less than 1 is “bad news”, greater than 1 is “good news” regarding costs for ANY project. Now she has the costs under control. All she has to do is draw up a simple table with the amounts I should have spent by the end of each week ( 60 the first week, 120 the second week etc.). Then she uses her spreadsheet to calculate the CV and CPI (she is too busy to do the calculation by hand), then every CPI over 1.0 has the costs in control. By the 5th week the table looks like this (Table 7.1).

Table 7.1 Cost performance index Week Number of Earned Value (EV) completed up to this time (based posts on the number of completed posts) ( ) 1 3 60 2 6 120 3 9 180 4 9 180 5

12

240

Actual Cost CV = (AC) up to EV AC this time ( ) ( )

CPI = Cost under EV/AC control?

90 140 190 230

30 20 10 50

0.67 0.86 0.95 0.75

250

10

0.96

No No Nearly OK No, bad week Costs nearly on target

7.3 Control Costs

7.3.2

107

EVM Schedule Control

My wife is naturally delighted that she has found such a simple way to control the project costs. She now takes this a bit further as she would like to apply a similar method to control the schedule progress. She compares EV (as a substitute for the value estimate of the work that has been done) with an estimate of the value that was planned for completion by each inspection day. She calls this Planned Value, PV. To estimate the PV, she makes the same assumption as before: The approved budget ( 20 per post) is a good way of linking value and schedule (when it should be achieved). Now here is another clever bit: IF {the real value of the completed work} IS EQUAL TO {the budget for the work that was planned to be completed now (the PV)} THEN the work is on schedule. Note that we have obtained an indication of schedule, a time parameter, even though this is derived using amounts of money. She calls the relationship Schedule Performance Index, SPI and, by analogy with CPI, this is calculated as follows: SPI ¼ EV PV We notice that for ANY project, if SPI ¼ 1.0, then the progress is on track (whatever the costs). In the same way, greater than 1 is “good news” and less than 1 is “bad news” regarding schedule. Just for good measure and symmetry, my wife develops a fourth relationship which she calls Schedule Variance, SV: SV ¼ EV PV Again she is using MONEY amounts to track SCHEDULE or TIME progress. Let us look at Table 7.2 (on the next page) which now shows PV (Note: the first three columns are the same as before).

7.3.3

EVM Formulas

Here are all four formulas in the order we worked them out. 1. CV ¼ EV – AC 2. CPI ¼ EV AC

108


3. SPI ¼ EV PV 4. SV ¼ EV – PV Remember that EV is the first item in all four formulas. I recommend that you make quite sure that you understand first what each of these parameters represents. Now close the book and use the logic above to write down and work out the four formulas. If you can do this you will save yourself hours of learning on one of the topics that nearly always appears in the PMP® examination. Figure 7-9 is a typical graph showing the three parameters based on the tables we used above. Note Budget at Completion, BAC in this diagram. This is just the total budget amount. Another parameter used is Variance at Completion, VAC. Although the title does not say so, it refers to costs and to how much the current Estimate (of costs) at Completion, EAC differs from the Budget at Completion, BAC: VAC ¼ BAC EAC In other words, “by how much do you think you will be over or under budget at the end of the project?” There are other items that you need to know. However if you can get these four formulas right, you will be able to understand the others without too much difficulty. As this book is an overview, we will not discuss them in detail here. Now we move on to the other Tools and Techniques of the Control Costs process which are: l l l l l

Forecasting To-Complete Performance Index, TCPI Performance Reviews Variance Analysis Project Management Software.

Table 7.2 Schedule performance index Week Number of Earned value EV up to completed this time (based on the posts number of completed posts) ( )

Planned value PV (budget of what should have been completed) ( )

1 2 3 4

3 6 9 9

60 120 180 180

5

12

240

SPI

Schedule under control?

60 120 180 240

SV (schedule variance, in money) ( ) 0 0 0 60

1.00 1.00 1.00 0.75

300

60

0.80

Yes Yes Yes No, bad week Catching up

7.3 Control Costs

109

One method for Forecasting is to calculate Estimate [of cost] at Completion, EAC, which was mentioned above. At any given time in the project execution, the EAC is simply: Everything we have spent until now (Actual Costs, AC) + our Estimate [of the remaining costs] to Complete the project, ETC. If we expect things to proceed as they have been going, then we can use the CPI to estimate the EAC: EAC ¼ BAC CPI because CPI ¼ EV AC, using today’s estimate for EV and AC at the end of the project. If some costs have changed dramatically, then we need to do a bottom-up review of all the costs to estimate ETC and add this to AC. These abbreviations can make it difficult initially to understand EVM. To make it harder, previous editions of the PMBOK® Guide (and other PM books) used different abbreviations. Maybe they express more accurately what each of the parameters represents: l l l

BCWS – budgeted cost of work scheduled (PV) BCWP – budgeted cost of work performed (EV) ACWP – actual cost of work performed (AC)

When you understand the four parameters above (CV, CPI, SPI, SV), you can then learn the other parameters by interpreting the text of this section of the PMBOK® Guide and adding the other parameters progressively to a graph, like the one in Fig. 7-9. To-Complete Performance Index, TCPI is the next Tool and Technique. This is: ðcost of theÞ Work Remaining Funds Remaining and is a measure of how cost efficient we must be to finish. As a formula it is: ðBAC EVÞ ðBAC ACÞ: Of course, if a project has poor cost performance earlier on, then this needs to get dramatically better towards the end of the project to complete on time and within budget. However if nothing changes, except the demands of management, then the chances of the TCPI improving dramatically are near zero. In other words, unless the costs are in control from very early on, it is IMPOSSIBLE to catch up, unless changes to the project constraints are agreed. This is called “re-planning”. The Tool and Technique called Performance Reviews is cost and schedule control applied to the individual work packages. Remember that everything in the PMBOK® Guide applies at multiple levels: project, sub-project, phase, program, etc.

110


The associated Trend Analysis (looking at the performance graphs and estimating what is going to happen) is familiar to anyone with a technical or business background. The Tool and Technique called Variance Analysis means, as the name says, analyzing the variances of any parameter from the planned value. The purpose is to identify whether the project is deviating from the limits we have set in the project management plan. If the deviation is outside the limits, we need to find out what is the cause and what to do to bring the project back on track. Finally Project Management Software can indeed be used. A common experience is that if EVM is supported by a company, then it will also be included in the normal financial reports and control. If not, and you wish to use it, then spreadsheets can be used. This brings us to the end of this very important Tool and Technique in the PMBOK® Guide description of project management. If you work your way through what is written above and can understand it, then you have one less challenge on the way to getting the PMP® accreditation.

7.4

Exam Aids

Process Summaries 7.1 Estimate Costs: Identifies how much money is needed to execute the project. 7.2 Determine Budget: Reconciles the estimates with the source and amount of budget. 7.3 Control Costs: Ensures that the project meets the cost constraints, as authorized in the project plan and adjusted by managed change.

Flash Card Terms Activity Cost Estimates Actual Cost, AC Analogous Estimating Basis of Estimates Bottom-Up Estimating Budget at Completion, BAC Budget Forecasts Business Case Change Requests Contingency Reserves Contracts Control Costs Cost Aggregation

Cost Baseline Cost Management Cost of Quality Cost Performance Baseline Cost Performance Index, CPI Cost Variance, CV Determine Budget Earned Value Management, EVM Earned Value, EV Enterprise Environmental Factors Estimate Activity Durations Estimate at Completion, EAC Estimate Costs

7.4 Exam Aids Estimate to Complete, ETC Expenditure Expert Judgment Forecasting Funding Limit Reconciliation Historical Relationships Human Resource Plan Knowledge Areas Management Reserves Organizational Process Assets Parametric Estimating Performance Reviews Planned Value, PV Project Cost Management Project Document Updates Project Funding Requirements Project Management Estimating Software Project Management Plan

111 Project Management Software Project Schedule Reserve Analysis Resource Calendars Risk Register Schedule Performance Index, SPI Schedule Variance, SV Scope Baseline Three-Point Estimates To-Complete Performance Index, TCPI Trend Analysis Value Variance Analysis Variance at Completion, VAC Vendor Bid Analysis Work in Progress Work Performance Information Work Performance Measurements

Chapter 8

Quality Management Processes


l

l

l

Attention to Quality Management is as important in Project Management as in any other business area. This refers to several definitions of quality and selects the approach based on “the degree to which a set of inherent characteristics fulfill requirements”, or Fitness for Use. Management of quality is then described using three processes. Plan Quality addresses the approach to quality for the current project. For example, if the company processes already emphasize quality, then there will be relatively little need to specifically make a reference to this in the project plan. Control Charts are introduced by means of a worked example. Perform Quality Assurance means making sure that a quality system is used. An example is the scheduling of maintenance and calibration checks because this makes it possible to make accurate measurements. This process is seen mainly as a management responsibility. The final process described is Perform Quality Control. In contrast to quality assurance, this is regarded as more of a technical task than a management responsibility. This section is where Pareto Diagrams, Histograms, Cause and Effect Diagrams and other analysis and communication techniques are referred to.

Project Quality Management In all the phases of project implementation from initiating to closure, it is assumed that good quality will always be delivered. This knowledge area addresses this important topic, with a big emphasis on the quality of the Project’s Product. The quality of project management is also covered by this knowledge area and addressed mainly by applying the various quality techniques such as Six Sigma,


113

114

8 Quality Management Processes

Total Quality Management etc., rather than directly by the three processes of the knowledge area. Quality is defined differently by different authors. The PMBOK® Guide uses the concept that good quality is achieved when the requirements are completely satisfied. This means that the project manager is responsible for identifying, together with the project customers (sponsor, stakeholders), the requirements and then delivering only that. Delivering more than agreed is seen as not good. The reason is that it diverts resources, however moderate, from delivering what was agreed. This may be just enough to cause the non-delivery of something that is expected. Some sections of the PMBOK® Guide are universal and some vary depending on legal and social environments. This section on quality lies between these two extremes. This is also true for Procurement, where contractual issues are directly affected by both practice and the legal environment. This knowledge area is presented as three processes, one in each of the Process Groups Planning, Executing and Monitoring and Controlling (see Table 3-1). They relate to each other as follows: l

l

l

Plan Quality does just what it says. Like anything else in life, if there is no plan to implement, it will not happen. Perform Quality Assurance. This is seen as a management responsibility and means making sure that the quality processes are being properly implemented. Instrument calibration is an example, because it requires management authority to establish such a program. Perform Quality Control is seen as a technical responsibility, actually carrying out the measurements, recording parameters and recommending changes if needed.

As background to the process descriptions, some quality concepts are described here: l l

Customer Satisfaction, based on Fitness for Use and managing expectations. Prevention as opposed to Inspection, in other words, you do not achieve quality merely by eliminating the sub-standard products from the customer delivery.

The story goes that a boy bought a dozen (12) apples in a bag from the lady at the street market in Dublin. He counted the apples and found that he had only eleven. When he went back to complain, the lady said “Sure, one apple was rotten so I threw it out for you”.

l

Continuous Improvement, in the sense of making relatively small improvements all the time. Building up a big list of improvements for implementation every couple of years is comparatively less effective. This philosophy (Kaizen) was brought to the western world by Japanese car manufacturers.

8 Quality Management Processes l

l

l

l

115

Management Responsibility for quality, because they control the resources required for implementing the quality system. Cost of Quality: the costs of everything that is done to achieve quality as well as the costs caused by poor quality. This includes not just the cost of inspection but also, for example, of calibration or training for the quality team, product returns, warranty claims etc. Grade is a product categorization. For example, photocopier paper is available in two weights, 80 g/m and 100 g/m. These are two grades. The heavier paper (informally we might call this “better” paper) may cause the photocopier to jam or block. In this case it is not “high quality photocopier paper” because it does not meet the requirements for working in a photocopier. The definitions of Accuracy and Precision are not the same. Accuracy relates to how close data is to a target value, while Precision relates to repeatability. For example, imagine you are lost in the mountains waiting to be rescued after an accident. You know that the rescue service listens for SOS messages exactly at the beginning of each hour. Unfortunately your radio battery is weak and you can only transmit one more message. You have two cheap watches: l

l

One watch tells the right time to within an average of 5 s. It is accurate. However it varies randomly between five minutes fast and five minutes slow. The other watch is five minutes fast, to within 5 s. It is precise.

Which watch is more useful? Of course, we see that we need both Accuracy and Precision. All knowledge areas must be fully integrated with all the other knowledge areas and this is particularly true of Quality Management. The highlighted scenario reminds us of what can go wrong if this is not done. Many of our readers will be familiar with Heathrow Airport, London, which is among the busiest in the world. It is on the western edge of London and you can get there by underground railway (metro). Until the 1960s, the line did not go all the way and passengers had to get a bus for the last few kilometers. When the railway was extended to the airport, there were two major work packages: building the trains and building the tunnels, including track and signaling. Unfortunately the trains that were built did not fit in the tunnels! What went wrong? From a technical point of view, it appears that the old tunnels in central London had tight curves and sharp slopes leading up to the stations. These slopes had been built in the nineteenth century to help the brakes, which were not as good as they are now. The problem was that the new trains had longer carriages than the old trains, because they allowed

116


additional baggage space for the elegant airline passengers. These longer carriages got stuck in the tight curves and sharp slopes! From a quality viewpoint, each of the main work packages, which were delivered by different contractors, was not sufficiently integrated with the other. Each delivered its own product, but not a working railway. Simply stated, the deliverables did not meet the requirements, which is the definition of quality.

8.1

Plan Quality

Analogy: The project manager must ensure that the house is built to high quality, so he states that the plumbing should be laid and insulated according to the national building standards. In addition, the hot water should be at least 70 C and flow with a pressure of 1.2 bar. Pitfalls: Incomplete checklists and inadequate metrics, improper quality standards. According to a familiar pattern, the first process to be described concerns planning. Without this, quality will simply not be achieved. The implementation of quality impacts all knowledge areas. Examples include: l

l

l

Quality planning requires some resource and some budget. It is often said that quality is free, in other words, that the investment in quality pays for itself. Even so, quality will not be achieved without funds, so this has an impact on the cost management knowledge area. This is just like the cost of insurance. Figure 8-4 lists various elements of the Cost of Quality. The quality plan will be implemented using various activities. These are just as central to the project as any other project activities, so they have to be explicitly added to the schedule network of the project. Here we see an interaction with the time management. The Outputs of quality control will often generate changes that have to be made to the way the project is executed. This relates to continuous improvement and change management.

As we might expect for a Knowledge Area that puts everything into three processes, they tend to be a bit more complex than others. In order to Plan Quality, the following Inputs are listed: l

l

Scope Baseline. We must know what is in the scope statement and the WBS to be able to manage quality. Cost Performance Baseline. Remember that the word “baseline” means that it has been formally approved.

8.1 Plan Quality

117

All the other Inputs should now be recognized by us without further comment: l l l l l

Stakeholder Register Schedule Baseline Risk Register Enterprise Environmental Factors Organizational Process Assets.

Now we examine the more complex part of the process, the Tools and Techniques. This section is very much like a general introduction to Quality at a level expected for the PMP® examination. If you have already had training or education in quality, you will probably recognize most of it. The importance of the Cost-Benefit Analysis is to help decide where to strike the balance between quality measures and their cost. In theory, “infinite” quality can be achieved at “infinite” cost but this is not very realistic in most commercial situations. It is better to find out (analyze) which quality can be achieved and at what cost. A decision about which measures to apply is then made based on this information. At the time of writing, the third largest European airline was Ryanair, a socalled low budget carrier. They will take you from one airport to the next. No transfers, no free meals, no seat reservations, etc. Some passengers have conceptions based on airline practice some decades ago, when flying was an exclusive activity. You may or may not like it, but from a quality viewpoint this airline has made very firm decisions about what service quality it offers and what it charges. The Tool and Technique Cost of Quality has already been mentioned. In earlier times, quality was less prominent in many companies. The idea of bringing all the quality related costs into one budget and then managing it like any other budget was, at that time, revolutionary. The next Tool and Technique Control Charts is an analytical tool. I will explain this using an example which is based on the fence building project (see example in Chap. 7, Cost Management Processes). Of course, I want to get the wooden posts as cheaply as possible so I go to an old sawmill out of town. The saws are worn out and the people working there do not have any quality training. I want posts that are 2 m long but the sawing process is not accurate. Out of interest, I take 100 of the posts, measure their length accurately and plot this on a graph. When I have enough samples, the graph becomes smooth and follows a bell shaped curve (see Fig. 8-1 in this text, which is called Normal Distribution of Post Lengths). The bell has a mean (average) of around 2 m and the measurements happen to fall mostly within 4.5 cm of this length. This is called the Capability of the post making process, using the saws as they are and the woodcutters with little training.

118


Fig. 8.1 Normal Distribution of Post Lengths

The question is “What high and low limits of length do we expect?” If I take the longest and the shortest of the sample of 100, I could be unlucky. Maybe particular circumstances applied and the sample is not representative. For example, maybe the very long post was the last one to be cut on the last working day before the weekend. At that time the wood cutter was probably not thinking about the work. So we might get a result like this: “The posts are 2 m 5 cm long”, however this would not be reliable because of the exceptions. An alternative approach is to take the reference length of 2 m. We could then measure the amount by which each post is longer or shorter than 2 m, then take an average of these variations: “the posts are 2 m 0.5 mm long”. Why 0.5 mm (or whatever small number we get)? Because the longer and shorter post lengths would average out near zero. This is not very useful to us. The problem is that the positive and negative differences cancel each other out. To avoid this issue, we can take these variances and square them (multiply the figures by themselves). This will always give us a positive result, because squares are always positive. We can now take the average of these squared values (a measure of how different the length is from the 2 m target). Finally we take the square root of this average to compensate for the initial squaring. The result is a number that tells us what the spread of post lengths is. This is called Standard Deviation and is represented by the Greek letter sigma s, which is the Greek small s. Strictly speaking, we would get an accurate standard deviation only if we used an infinite number of samples, but the difference is too minor to be important for this use. We now have no problem with the rogue measurements as they will not strongly affect the result.

8.1 Plan Quality

119

This sequence is now repeated as a formula, which is mathematical shorthand for describing the same operations: Standard Deviation s sffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffi Pnumber of posts ðactual length of each post average length of postsÞ2 1 ffi number of posts It turns out that the bell shape spread of post lengths first mentioned above occurs in a variety of similar situations and that the shape is well defined. For example, you can look up the values of the curve parameters in a reference book under the title Normal Distribution. It is symmetric, which means that the shape is the same on each side of the mean. Of particular interest, if we take the mean (in our case 2 m) and then three times s longer and three times s shorter than this length (a total width of 6s), then more than 99% of all post lengths will fall within this range. For example: if we calculate standard deviation based on our measurements and get s ¼ 1.5 cm, then nearly 100% (actually 99.7%) of the posts will be between 1.955 m and 2.045 m long, or 2 m 3s. Another way of writing these limits is 2 m 4.5 cm. The 4.5 cm arises because this is three times the standard deviation. This situation is shown in Fig. 8-1 in this text, which shows the Normal Distribution of the post lengths. What is the significance of this? It says that the capability of our saw mill is to produce posts between 1.955 m and 2.045 m to a probability of over 99%. This is based on experimental evidence. We have not “forced” the system in any way, but merely measured what it can produce. The probability of getting a given result is given by the normalized area under the curve (that is, adjusted so that the total value is 1.00). Nearly 100% (actually 99.7%) of area is under the curve between the mean and 3s. Alternatively, if we take the area within 2s each side of the mean, about 95.5% of the area under the curve (¼ probability) falls between these limits. About 68% of the area falls within s of the mean. Assuming that we have been appointed as sawmill quality manager, we will now measure the length of each and every post that is made. What would you think if one was 1.997 m long? This sounds OK. Or 2.023 m long? OK again, because both measurements are between 1.995 m and 2.045 m. Such variations are said to vary according to chance, or Common Cause, as it is called. But what if a post was cut at 1.900 m long? What would you think? Well you know from experience that the posts are nearly always between 1.955 m and 2.045 m long, which is what the complete process is capable of delivering.

120


The length limits we expect from experience are summarized by the formula: 2 m 3s < Post length < 2 m þ 3s Note that this is mathematical shorthand for what we found out by carrying out 100 measurements. It is not some theoretical law which we are given. It just looks like higher mathematics. The three measures (2 m, 2 m þ 3s and 2 m 3s) are called the Mean, Upper Control Limit, UCL and Lower Control Limit, LCL. We are now able to step outside the current subject to refer back to the PERT and standard deviation estimates mentioned (but not explained) under Project Time Management in Chap. 6. If we look at the graph of Normal Distribution of Post Lengths (as in Fig. 8-1 above), it seems reasonable to interpret an Optimistic Estimate (of duration, cost or whatever) as the point on the left hand side of the curve where the graph comes close to zero on the x axis. This is the point which we have already called LCL. In the same way, we can assume that the UCL is close to the Pessimistic Estimate. These two points are 6s apart, so we can estimate the value of s by taking the distance between them and dividing by 6: (Estimate of) Standard Deviation s ¼ (Pessimistic Estimate – Optimistic Estimate)/6. The PERT (estimate of duration) mirrors this by taking six elements (Optimistic Estimate, Pessimistic Estimate plus four times the Most Likely Estimate) and dividing them also by 6 to get a weighted average.

Now imagine turning our diagram showing normal distribution 90 anticlockwise, the LCL will be at the bottom and UCL at the top, with the mean in the middle. By extending these points with horizontal lines to the right we finally get a Control Chart. This is shown in Fig. 8-6 (of the PMBOK® Guide) – you must just imagine the normal distribution to the left. It allows us to chart the values of length for each post. So what do we think about this post which is 1.900 m long? l

l

Either we are really unlucky. For example, this is one of those posts made just before the weekend when the operators were tired or careless. In other words, this is just bad luck but to be expected occasionally. This is called Common Cause. Or (and this is much more likely) something specific in the process has changed. The saw blade? The machine alignment? A new untrained operator? Something specific: a Special Cause as it is called (also called Assignable Cause).

We need to investigate what is the cause. As I am lazy, I prefer to look first at the more likely option. This is the second one above.

8.1 Plan Quality

121

Unfortunately the operators find this all very boring, so we define some simple guidelines for them. These rules tell them when there is probably a Special Cause. The rules are: “Tell me if you see any of these...” l

l

l

A post which is longer or shorter than the range expected; more than 3s meters from the target. Convert this into centimeters and tell them that the limits they must report. In this case, we ask the operator to tell us when the post lengths fall outside 4.5 cm of the 2 m target. Such a situation is called Out of Control. If the post length is within these limits, the production system is In Control. Seven posts in a row get progressively longer or shorter. Or they are all on one side of the centre line: “Rule of Seven”. A sequence like this is odd because we know from experience that the lengths of 7 posts that are cut one after the other should be randomly distributed. The probability that 7 posts in a row are too long or too short is very low. Consecutive measurements are constantly at the same value. We expect them to vary, so maybe the length measuring tool has stuck at a particular value.

In summary, we tell the operators to tell us if the lengths do not randomly fall between the UCL and LCL, that is between 3s of the target length. If either the lengths fall outside these limits or the measures do not seem to be random, then we ask the operator to tell us. The “Rule of Seven” and similar guidelines (above) summarize what the operator must look for. These control charts (like in Fig. 8-6) also have two more lines: the USL and LSL, which means Upper Specification Limit, USL and Lower Specification Limit, LSL. Specification limits are what the user wants; the control limits are what he gets! I can specify any length that suits me and this may or may not be within the limits 3s which the system can deliver. l

l

l

If the length variation I can accept (my specification) is wider than these limits, then virtually 100% of the posts will be acceptable to me. This makes life easy. If my specification is narrower than 3s, then one way of getting posts within specification is to select the good ones. This means that some out of specification posts will be left over. As mentioned before, this is how low power computer chips are manufactured. The good ones are selected and the others are sold cheaply with a different name. Another way of getting what I want is to improve the system capability. For example, installing a precision saw or better train the operators, etc. I would now expect a measurement of the length of 100 posts to give me a smaller value for s, standard deviation, and post lengths which fall within closer limits.

We now move away from the sawmill and look at the next Tool and Technique of the Plan Quality process: Benchmarking. Long ago standards of length were cut into wooden benches in public places, which is where the word comes from. For us it means comparing what we are doing with other people doing similar things. Examples are previous projects in our

122


company or similar projects in other companies. If we find big differences, it should set us thinking to find out “Why are we different?” The next process Tool and Technique, Design of Experiments, is a statistical technique used to identify the sources of variations in performance. As an example, assume that car spring failures occur between 100,000 km and 150,000 km. Design of Experiments could be used to show that, e.g., the main cause of this variation is changes in the annealing temperature when manufacturing the springs. Alternatively, changes in the metal composition could also have a significant effect. The spring manufacturer designs an experiment to monitor these variables, so identifying the cause of failure. The results can then be used to change the manufacturing process and improve the performance of the springs. Which measures to implement is an important question because they affect cost: heavier springs cost more. The results of the experiment help decide “How much quality do we want to pay for?” In the sawmill example above, we could check quality by measuring the length of every single post cut. This should not be needed when we know the value of 3s. The question is “Can we check only some of the posts and still notice if something goes wrong?” How often we need to take a sample is determined by Statistical Sampling, another Tool and Technique of the Plan Quality process. Another Tool and Technique is the use of Flowcharting (Fig. 8-7), which is familiar to many. We can use it as a systematic way of looking at different parts of a process and so finding issues that we might otherwise overlook. Tool and Technique Proprietary Quality Management Methodologies refers to other quality techniques, such as Six Sigma, Quality Function Deployment, QFD and so on. It recognizes the contribution of these proprietary methods, without going into detail about them. The final Tool and Technique is Additional Quality Planning Tools. It refers to some well know techniques such as Brainstorming and Force Field Analysis. Most of these techniques were evolved before the days of Post-it® notes or web meetings and some are a bit outdated. Even so, they may occur in exam questions. They are described in Chaps. 5 and 11. Now we turn our attention to the process Outputs of which the main one is Quality Management Plan. This is part of the Project Management Plan. Here we have to recall the difference between a management plan and an execution plan. The Quality Management Plan refers to how we are going to manage the quality within the project. This includes the strategy (in this case quality strategy), responsibilities and documentation standards etc. As always, how formal or informal this is should be is an explicit decision of the project manager, and not something arrived at by chance. Quality Metrics is an important Output. It documents the actual measurement values we expect to get after performing quality control. Quality Checklists are also an Output of this process and a very powerful tool, although they do not seem to be very appealing or interesting. A checklist is a

8.2 Perform Quality Assurance

123

systemic way to check a particular domain or field. No checklist is perfect but if we keep updating it when we find problems, our experience will become more valuable to future generations of users. A very dramatic example of a checklist is the Surgical Safety Checklist of the WHO (World Health Organization). This internationally standardized list requires a surgeon to check, for example, how many needles have been used in an operation, so that none are left inside the patient. It also includes details such as checking the patient’s name. This has resulted in substantial reductions in both complications and deaths after surgery. A sad high profile case occurred in Zurich, Switzerland, where a woman undergoing a heart transplant received a transfusion of the wrong blood group and died. Tragically, a checklist procedure was not used to check the blood group.

The next Output is the Process Improvement Plan which identifies which processes need to be audited and the targets to achieve. Returning to the heart transplant case, a possible process improvement could be to require two people to check and document the blood group of the patient before the operation and confirm with each other before a new transfusion is made during the operation. The final Output is Project Document Updates, which is already familiar to us. It is to be expected because as we check the quality issues in our project, we are very likely to find details that have to be changed and documented.

8.2

Perform Quality Assurance

Analogy: The project manager observes the installation of plumbing to see whether the plumbers are maintaining the standards. He saw that the plumbers were walking up and down to get more pipes and suggests that they maintain a small depot next to the bathroom. Pitfalls: Supposed improvements have the opposite effects, auditor not qualified enough. The last process gave us a Quality Management Plan and this next process implements it. Quality Assurance (using the PMBOK® Guide terminology – your organization may use different words for this) is making sure that the quality system works properly. This process is in the Executing Process Group. Note that it is possible to have a good quality system that produces bad products. Remember the example of the boy and the dozen apples at the beginning of this chapter.

124


We have seen nearly all the Inputs already and their descriptions are not repeated here: l l l

Project Management Plan Quality Metrics Work Performance Information.

The last Input is Quality Control Measurements, which is an Output of the next process, Perform Quality Control. In simple words it means “take the measurements”. The Tools and Techniques are new to us. The first one has the wordy title of Plan Quality and Perform Quality Control Tools and Techniques. What it means is simple: use the other two quality processes. The second Tool and Technique is another of these things that looks simple but is actually very profound, like Checklists. It is Quality Audits. An audit is a check in which the person doing it has the authority to ask any questions. The authority is the important part. From a quality viewpoint it is very powerful because the auditors may look at the issue from a completely different viewpoint compared with the rest of the team. Audits can discover aspects that would otherwise be missed. It is a really valuable way of ensuring that the quality assurance and control are good. Of course, it is difficult to get acceptance if the auditors appear to be the “quality police”. So for best results, the company should have an open culture that allows critical viewpoints. The last Tool and Technique is Process Analysis. The way of using this in quality management is very similar to the use of flow charts. Reviewing the entire project systematically against the process results will help identify questions and improvements. The Outputs are all adjustments to various project items addressing quality: l l

l l

Organizational Process Assets Updates Change Requests. Remember that the project manager alone does not have authority to make significant changes. Project Management Plan Updates and Project Document Updates.

8.3

Perform Quality Control

Analogy: The project manager tests the temperature of the bathroom’s hot water supply regularly. Since it was not consistently over 70 C, he traced the plumbing back and found that a pump in the cellar was not working properly. Pitfalls: Wrong sampling population, improper measurement, forgetting to validate changes and their side-effects.

8.3 Perform Quality Control

125

This is where the quality plans and assurance process actually deliver results. A few simple terms which we need to know in this area are: l

l

l

Prevention, for example of quality problems, and Inspection, to see if there are any problems. Attribute Sampling, for example, selecting which eggs which are “brown” and which are “white” in an egg checking station. On the other hand Variables Sampling means measuring the length of our fence posts (from the previous example). Tolerances, which indicate if results will be accepted, provided that they lie within the Control Limits. The process Inputs all come from processes which have been discussed earlier (see Fig. 8-11) and therefore do not need to be repeated:

l l l l l

l l

Project Management Plan Quality Metrics Quality Checklists Work Performance Measurements Approved Change Requests. We need to know what has been approved to know what to control. Deliverables, so that they can be assessed for quality and Organizational Process Assets. We now move on to consider the Tools and Techniques. We have already discussed three of them:

l l l

Control Charts Statistical Sampling Flowcharting.

Most of the other Tools and Techniques are familiar to anyone who has studied quality techniques. Some of them are both easy and have a big impact, such as Quality Checklists. The first one is Cause and Effect Diagrams which can be used as a structured brainstorm for collecting causes of quality problems. They make visible the possible causes for a particular problem. The basic diagram is in Fig. 8-12 and one which has been developed to discuss a particular problem (hotel reservation error) is in Fig. 8-13. The benefit of such a chart is the understanding of how things influence each other. Originally they were used in factories where the “workers” were expected “to do, not to think”. In this environment it was very difficult to get genuine discussion. Histograms are vertical bar charts and can be used to communicate quality control results. There is an example in Fig. 8-14, to reiterate what a histogram is. The next Tool and Technique is named after an Italian economist, Vilfredo Pareto, who noticed that land ownership was not evenly spread in the Italian population (this is still true nearly everywhere over a century later). The analysis named after him identifies and ranks what (quality) issues exist. In other words they

126


are put in decreasing order of importance using histograms. This method makes it easy to pick out the few problems that are causing most of the issues and to focus on resolving them first. The Pareto Diagram (Fig. 8-15) also shows the cumulative effect of the problems, using the right hand scale. The next Tool and Technique, the Run Chart is like a control chart but without the limits, just the actual measurements. This makes it easy to spot trends. The Scatter Diagram (Fig. 8-16) shows various measurements and plots them according to two parameters. This makes it easy to detect visually if there is a relationship between them. The next Tool and Technique is Inspection. There are different ways of structuring this, such as audits or peer reviews. A peer is someone of similar status (for example, brothers are peers) and this means carrying out a review with the help of others from your working environment. We finish the entire review of Project Quality Management with the last Tool and Technique: Approved Change Requests Review. Because one of the Inputs is Approved Change Requests, this confirms that they have been correctly implemented. This process is in the Monitoring and Controlling Process Group, so several Outputs are expected: l

l

l

Quality Control Measurements. This is the main Output of this Perform Quality Control process. Validated Changes. Whatever has been changed needs to be checked before being sent on for whatever the next step is. Validated Deliverables. This is Output confirms that the deliverables have passed the check.

There are also the various update-type Outputs that we expect and which do not need further explanation here: l l l l

Organizational Process Assets Updates Change Requests Project Management Plan Updates Project Document Updates.

8.4

Exam Aids

Process Summaries 8.1 Plan Quality: Determines how quality will be achieved and which standards will apply. 8.2 Perform Quality Assurance: Ensures that the methods for achieving quality are applied correctly and that the quality systems function correctly. 8.3 Perform Quality Control: Manages deviations from the agreed quality plan, based on measuring, observing and documenting the Outputs of the project quality activities.

8.4 Exam Aids

127

Flash Card Terms Accuracy Additional Quality Planning Tools Approved Change Requests Approved Change Requests Review Assignable Cause Attribute Sampling Benchmarking Brainstorming Capability Cause and Effect Diagrams Change Requests Common Cause Continuous Improvement Control Charts Control Limits Cost of Quality Cost Performance Baseline Cost-Benefit Analysis Customer Satisfaction Deliverables Design of Experiments Enterprise Environmental Factors Fitness for Use Flowcharting Grade Histograms In Control Inspection Lower Control Limit, LCL Lower Specification Limit, LSL Management Responsibility Mean Normal Distribution Organizational Process Assets Organizational Process Assets Updates Out of Control Pareto Diagram Perform Quality Assurance Perform Quality Control

Plan Quality Plan Quality and Perform Quality Control Tools and Techniques Precision Prevention Process Analysis Process Improvement Plan Project Document Updates Project Management Plan Project Management Plan Updates Project Quality Management Project’s Product Proprietary Quality Management Methodologies Quality Assurance Quality Audits Quality Checklists Quality Control Measurements Quality Management Plan Quality Metrics Risk Register Run Chart Rule of Seven Scatter Diagram Schedule Baseline Scope Baseline Special Cause Stakeholder Register Standard Deviation, Statistical Sampling Tolerances Upper Control Limit, UCL Upper Specification Limit, USL Validated Changes Validated Deliverables Variables Sampling Work Performance Information Work Performance Measurements

Chapter 9

Human Resource Management Processes


l

l

l

Human Resource Management must be addressed to ensure successful Project Management. It starts with planning, proceeds to team acquisition, developing the team into an effective working group, then managing the team, where the actual work is done. The Develop Human Resource Plan process reminds us to start from the competence needs of the project. We then identify the best way to bring the people with these competence and skills into our project. The next stage is to assign the staff to the project, using a process called Acquire Project Team. Either traditional methods or virtual teams can be used. Either way, role definitions are very important. It is easier to find consensus and execute the project smoothly when participants understand and act their assigned roles, such as Project Manager or Sponsor. The last process, Manage Project Team, is presented in terms of people management, since it is the team that actually does the project work. Active team management is necessary, to set objectives, maintain morale and sometimes resolve conflicts.

Project Human Resource Management It is clear that project success depends totally on the motivation and competence of the people involved. It therefore makes good sense to build human resource management into our project, where it is essential, just like other more technical aspects. I once had a colleague who described projects as “human eco-systems with some added technical activities”. This is almost the opposite of what many people think: technical activities with some added people.


129

130

9 Human Resource Management Processes

To succeed, a project must have the people issues under control; this also applies to general management. This knowledge area provides a simple structure of four processes for addressing HR matters in projects. The structure is as follows: 1. Develop Human Resource Plan: We develop a plan of how the people are going to be selected and brought into the project, based on the project requirements. 2. Acquire Project Team: This means finding out where the people with the necessary skills can be found and recruiting them. 3. Develop Project Team: Once they have been recruited, we have to take conscious measures to help the team form. Teams do not just happen. 4. Manage Project Team: We then manage the team, including conflict resolution, which is unavoidable in project situations because different stakeholders often have conflicting demands. Despite this presentation of HR management as a set of processes, it is not a oneoff activity but is continuous. For instance, at the beginning of a project there are usually less people involved than later, and also having different skills from those who will later execute the project. In addition, there are workload variations throughout the project. This is a challenge because it is crucial for the project success to get the right people at the right time. With the wrong resources, it is almost impossible to be successful.

9.1

Develop Human Resource Plan Analogy: Once the project manager has determined what resources are needed to install a sink, he has to define the required skills and experience that the plumber should have. Pitfalls: Roles and responsibilities not properly defined, organizational hierarchy too broad or too narrow.

It is logical that the skills required by a project are determined directly by the detailed work description and timing of the project plan. The project manager is naturally responsible for making sure that the project team members have the right combination of skills, availability and assignments. If people with the necessary skills are not easily available, then sourcing will become a time-consuming task. Typically in matrix organizations, the HR team are responsible for recruitment and the line managers of the project team members are responsible for authorizing holidays, salary levels etc. The project manager is then responsible only for the work done on the project. There is a recent trend towards “Total Project Managers”, meaning that the project manager also takes responsibility for HR issues. Actually this has always been necessary.

9.1 Develop Human Resource Plan

131

Long ago I had an engineer in my project team who had a problem with his knee, following a sports injury. If project review meetings were called for a day when he had to go to the hospital for a check-up, he used to get very upset. This was very understandable, as it is simply not possible to separate the people from the project issues. The Inputs of this process have all been described already. They should be interpreted in the context of HR planning: l

l

l

Activity Resource Requirements, as this tells us what skills we need to implement the project. Enterprise Environmental Factors, particularly those relating to people issues. A common example is a headcount limit. This means that the number of fixed employees is limited and will affect what contractual arrangements are permitted. Organizational Process Assets. Here the process assets include those relevant to people, whether documented or not. I once started a new project job to find a big bunch of flowers on my desk. That was a standard process for newcomers, but was not documented.

There are three Tools and Techniques. The Organization Charts and Position Descriptions are normal HR tools and applied here to the project environment. In other words, we develop an organization chart for the project, regardless of usual affiliation of the team members. A project organization can sometimes have inadequate presence and visibility among those outside the team. In this respect, clear project HR documentation can help support communication with other groups. This is critical so that the line managers of the project team members understand the plans and support them actively. One format that can be particularly good in project situations where work is shared between departments or individuals is the Responsibility Assignment Matrix, RAM (Fig. 9-5). This maps the responsibilities against the people. Remember that the description of project management can be used at different levels, for example the RAM can be used to show which department will take responsibility for each work package, alternatively it can show who in a team will work on which activity. A particular feature of the RAM is that the link between an assignment and the activity is more detailed than merely an asterisk or a tick mark. The basic version uses the following four categories of assignment: l

l

R ¼ Responsible: this is used to assign responsibility for an activity to a particular person or organization. A ¼ Accountable: this category is used to ensure that accountability is clear. For example, the person accountable for a task could be the line manager of the person responsible.

132 l

l


C ¼ Consult: this records that a particular person will be consulted, asked for their opinion and Input in connection with an activity. I ¼ Inform: this is like Consult, but less obligating. In general, stakeholders impacted by the project, either positively or negatively, may appreciate timely information.

The reason for using a RAM with RACI Format is that it increases the chances of project success. For example, if the person mentioned as Responsible is unavailable, for whatever reason, then the person who is Accountable can act and take steps to resolve the situation. Nominating someone to consult is a commitment to tap into experience and again will improve the chance of project success. Even the discussion to fill out the RAM can result in better clarity and improve acceptance. Networking as a Tool and Technique is well known for individuals who wish to contact others with similar or complimentary interests. Professional organizations often have an important networking function, for example the PMI® itself. In this context, networking is recommended for use within the company or professional environment. Where companies have tens of thousands of employees, there is often somebody who is looking for new challenges that your new project might provide. Similarly there may be potential supporters for your project, if you could only find them. It is usually agreed that networking must be a continuous effort and that the payback is seldom immediate. If you, for example, want to network within the company as a way of finding possible staff for your project, then you need to start networking actively well before you seek concrete results. The last Tool and Technique is Organizational Theory. Being aware of how organizations work can save a lot of time and energy during recruitment. Movement of staff into your project can be facilitated or hindered by a variety of reasons, whether based on business or personal motivation. In addition, familiarity with how organizations work should be applied when defining the project structures. Projects can succeed or fail because of the organization, regardless of the energy and motivation of the project team. There is only one Output: the Human Resource Plan. This will include matters such as Roles and Responsibilities, Project Organization Charts, Staffing Management Plan etc. This plan should identify where the people will generally come from, where they are going to work (both geographically and organizationally) and what happens to them when the project is finished. Sometimes, in operations-oriented companies, nobody wants to join a project. This is because when they finish a project it may be difficult to get back into operations. I have seen extreme situations, including one where the project manager never got back into operational work and had to leave the company. In these cases, personal competence and experience are not enough to save successful project managers from losing their job.

9.2 Acquire Project Team

133

Specifically, the plan should consider topics such as authority, competence, suitability and responsibilities for the planned project team. Later we will look for people to match this profile, based on the required role profiles. It is also a good idea to think in terms of achieving an appropriate skill balance among the members of the steering committee, although project managers do not usually have much freedom to influence this. A supportive sponsor can, however, make a big difference here. Some stakeholders may be more or less supportive than you might wish, for whatever reason. Similarly, they may not automatically bring a balance of competences and availability needed for the project. The Staffing Management Plan will explain where we plan to get the people from. Are they existing employees? Are they in another part of the organization? Will we have to take on new staff from outside? Of course the project manager should work closely with the HR department of the company and provide the project viewpoint. When the skilled staff are actually needed is also important, otherwise we might get the right people at the wrong time. A Resource Calendar or at least a graphical summary (Fig. 9-6) makes this visible. Related to this is the Release Plan, in other words, the plan for project staff to leave the project at the appropriate time. Just stopping the project and abandoning the team would not be a good technique. Unless the assigned staff are fully up to date on the project, their training needs have to be identified and addressed. This will include issues such as the project business case, Enterprise Environmental Factors, project objectives, the current status and so on. They may also need technical training, either about recently completed work packages or tools they will need to use. You may also have to work out how they are going to be paid and if any bonuses will be payable, for example if the staff are moving internationally. If the employment conditions are different from those in other similar departments, this may create an HR issue, which should not be overlooked. When the HR plan is consistent, clear and complete, then it must be authorized. If the plan includes staff from other departments, then their managers become stakeholders and should be represented appropriately in the steering committee (or equivalent) to facilitate acceptance, or buy-in.

9.2

Acquire Project Team Analogy: The next step is to find the right plumbers that fit the role description. Pitfalls: Underestimating resource availability, acquisition started too late.

Acquire is another word for “get”. From the project manager’s point of view, this means doing whatever is needed to move the people into the project organization. This may also involve physical moving of desk, office or even country. Until the people are formally in the project, they will be pulled in other directions by the

134


demands of their normal work. If the necessary people are not brought into the team at the right time, the project will not be able to meet the expectations of the stakeholders. In summary, we use the plan with any available assets, in the context of the enterprise environment, to get the people we need. At this stage we should be familiar with the idea that all process Inputs come either from another process or the environment. The Inputs (Fig. 9-7) have all been discussed previously in this book. A bit of reflection will confirm that all these are relevant. They are: l l l

Project Management Plan Enterprise Environmental Factors and Organizational Process Assets.

The Tools and Techniques provide guidelines for how to recruit the team. This is particularly useful for project managers who have limited general management experience, as it provides a structure with which to work. Pre-Assignment means that you are been told that you must work with a particular person. This can be because their particular skills are required by the project or because of their strong links with the sponsor. In this case, the project manager may have a difficult time, if the assigned person does not have the skills required. Do not forget that projects are not exclusively technical but also depend on human relationships. I have a colleague who spent several years in a senior banking position. He estimates that 25% of the management effort is spent just on defending positions in the corporate jungle! Pre-assignment does have the advantage that you do not have to go and look for someone. This saves your time. If the person also has the skills you need (including the ability to work in your team) then this is also a bonus! Negotiation is the next Tool and Technique. In this context, it means negotiating with your organization to get the people you want. The more information you have, the better your chances are of negotiating a good deal. This is why documenting the project in a structured way provides a very good basis for negotiation. This can both support the discussions and help manage expectations. Actually, negotiation is an extremely important general management skill for project managers and not restricted to acquiring staff. Many details of a project can be open to negotiation: technical standards, project strategy, assigned staff and office location, not to mention delivery dates, prices and many other details. It is a good complement to Project Management skills.

9.2 Acquire Project Team

135

I once had a project team in Ireland and needed the skills of a particular colleague in the USA. He said he would have to think about it, because it would involve being away from home for a month. Apparently his wife was not keen on this. My manager then came into the negotiations and said that if that was the problem, then the colleague’s wife should accompany him with the costs paid for by the company. The hotel did not cost anything extra because there was a room rate, so the only additional cost was for her fare. We still talk about that wonderful “working holiday” decades later. And this negotiation solved the project skill requirements problem. The next Tool and Technique is called Acquisition, meaning “appoint new staff from outside the company”. This tends to be much slower than the other methods and is determined by company recruitment procedures. The next Tool and Technique, Virtual Teams, can be used in association with any of the acquisition methods. You can pre-assign, negotiate or acquire staff who will either sit in the same office as the rest of the team, or somewhere else. If everybody is located in different places, then we talk of a Virtual Team. This is the norm in the IT industry and is also becoming more widely used in other sectors. It is however quite difficult to start a virtual team without anyone ever meeting the others. The reason is that a key requirement is Trust, which can only be built up over time. Of course, this also applies to traditional teams, but it is even more critical in Virtual Teams. They also require higher coordination and communications skills, and everybody needs to be more aware of cultural differences. Despite this Virtual Teams have some really big advantages, which are becoming more widely accepted: l

l l

l

l

l

l

There is a much wider choice of staff for a particular skill compared with only local recruitment. This is a strategic advantage and is one reason for it being included in the PMBOK® Guide. It can be much faster than traditional recruitment methods. The people concerned bring the skills and networks of their environment with them, possibly from a completely different part of the world. The work itself can be done faster, by taking advantage of time zone differences. For example, an item (document, software module etc.) can be produced in Asia and then sent for evaluation to America during the night in Asia. The virtual team members do not have to travel by car or fly to work. This saves time for the person, organization and project, as well as the costs and emissions of travel. The work schedule is more flexible, allowing the team to collect their children from school, go to the doctor etc. Companies are finding that they have to offer working flexibility to be competitive for young skilled people who have grown up with the internet.

136


If Virtual Teamwork is so good, why is it not more common? Researchers in this area point to the large number of issues to be resolved, both social and technological. It will naturally take some time before all of the main problems have been addressed. Traditionally, managers like to see who is working for them. However the benefits have been shown on average to exceed the costs, even at the current state of development of virtual teamwork processes. I predict that the next edition of PMBOK® Guide will give Virtual Teamwork much greater prominence. The result of the process is that the project team is formed. This is confirmed by the delivery of the Outputs: Project Staff Assignments say who is going to take which role, or job. This is where the individual is assigned to a specific job. This must be clearly communicated, maybe with a project announcement or an updated project organization chart, otherwise the project team will find themselves still expected to fulfill their old role. Resource Calendars are the second Output, meaning that we collect information about the individual availability. This is essential not only to be able to plan the work, but also for teambuilding. Of course “resources” also includes physical resources, but this chapter focuses mainly on Human Resources. They show when each person is available to work on the project. These calendars cannot be finalized without negotiation, because many details about personal holiday plans, house moving, weddings, pregnancy etc. are likely not to be generally known to the project manager. Project managers who ignore these issues are inviting trouble! As always, the detailed planning is likely to have identified the need for more project plan changes, and these are consolidated in the last Output, the Project Management Plan Updates.

9.3

Develop Project Team Analogy: Once the project team members are identified, the project manager has to ensure that the plumbers, the masons, the electricians etc. work harmoniously with each other. Pitfalls: Neglecting team building activities, no or too few ground rules defined, forgetting to recognize and reward workers, neglecting cultural and interpersonal issues.

Assisted by this next process, we will now introduce the people into the project and form them into a team or teams. This is much like army recruitment. The recruits do not know each other at first but have to learn fast to work together. This section is not a comprehensive guide; it is more of a pointer since it would be impossible to mention everything related to this area in a few pages. Most of the

9.3 Develop Project Team

137

content is not new, but because people are people, what applied decades ago is still valid today. Teamwork has a very high priority these days. By definition, a project needs a team to achieve what individuals could not do alone, so we must be able to work in teams. In my experience, this is not an issue as most people like to work in contact with others. Indeed there are people who go to work for this reason and their priority is not to earn a salary, but to socialize. The process description is very supportive of multi-location, multi-cultural, multi-talented teams. General experience also supports this attitude. The Inputs for this team formation process are not complex. The only one that needs some explanation is: l

Project Staff Assignments. This simply communicates who is assigned to each role, both to the person concerned and to others who should know. The other Inputs are already familiar to us:

l l

Project Management Plan. Resource Calendars.

The Tools and Techniques are mainly a collection of team motivation tools. This is an area in which business fashions vary over time and place. The practice may be different in different countries, but this is what you need to know for the PMP® examination: l l l l l l

Interpersonal Skills Training Team-building Activities Ground Rules Co-location Recognition and Rewards.

Let us take them one at a time. Interpersonal Skills are certainly essential for a project manager. Often the person who is successful technically is promoted to project manager, but they often still need support and development in this area. Such people sometimes avoid the issue by getting deeply involved in the technical work. The result is then the question “who is managing the project?” Time cannot be used twice and if none is spent on people issues, the project will not be successful. The term “soft skill” is also used: communicative, sensitive, analytic, clear, influential etc., as well as skills like being able to negotiate and understand the underlying technical issues. This is a lot of management theory in one Tool and Technique. It is best to use it as a reminder. Training, when properly applied, can be a real tool for developing the project team. It involves sharing know-how in a structured way. Even the preparation itself will help you clear your thoughts and improve the project. All projects have background information which must be shared. Doing this in a training format for

138


all the team together can be a really effective way of building relationships. It should be non-contentious and allow people to get to know each other. Training has the biggest impact when it is carried out just when the participants need the knowledge. If too early, they will find the content less relevant and it takes time from other important activities. If too late, then their work is harder because the required knowledge and information was not available when needed. The next Tool and Technique is called Team-Building Activities. This is a reminder to include a team building objective in your team culture. Bringing the team together for intensive planning activities is such a team-building activity. So too is a brief net meeting, where each person uploads a photograph and tells the others about their background and work. This does not require much extra effort and it is a good way to support team interaction. Good team dynamic and interaction are simply essential for project success. This Tool and Technique also recognizes off-site events in a non-work environment which will also help the team bind together. One type of event that has become fashionable is open air activities such as rope bridge building, treasure hunts etc., like the games we enjoyed as young boy scouts. These events vary by culture and geography. In England many working teams go to the pub for a drink at the beginning of the weekend, before travelling home. In Switzerland drinking white wine while looking across a lake at the mountains is not unknown. For virtual teams, team-building activities are also possible but much harder. I heard of one company that uses virtual teams which held a “cultural day out”. Each person went to a concert, museum or other interesting event on the same day, possibly with a friend or partner. As the team members were in several locations globally, each went somewhere near home, but without live contact with the others. Then next day, they had a net meeting to share their photographs and experiences. If you think the case described is far-fetched and futuristic, then think of what it would have been like a hundred years ago if somebody told you: “With this thing you can sit at home and talk to somebody without being in the same place. You can work with colleagues, even if you cannot see them”. Very futuristic then, very real now – with a telephone! Of the many models in the area of teambuilding, there is a reference to Tuckman’s Team Development Model which describes five stages of team formation: l

Forming, Storming, Norming, Performing and Adjourning.

9.3 Develop Project Team

139

These are not everyday words and may have been chosen because they rhyme (in English). But the message is that no team ever goes from “hello!” to perfect harmony in one step. It takes time for people to get to know each other’s objectives, style and limits. The time and space for doing this must be allowed for in the project start up schedule. This can be made both friendly and faster by the outdoor events mentioned above. Agreeing on the team’s Ground Rules is also useful. In traditional situations where the team is in one place, sharing the same company, culture, language and country, then a lot of this happens informally. Global teams in particular need to (but often do not) consciously work out and document their ground rules. It is best to describe what people may do (for example take a pause after lunch) rather than why (for example to pray). One example of a ground rule is “how fast can I expect an answer to an e-mail?” I worked on one project with partners in Europe, Asia and America. Some of the Europeans expected a reply to e-mails within 24 hours; otherwise they assume that their partners had nothing to say. The Japanese however said that they needed a week to reply in a foreign language (English). Telephone conferences at 5 p.m. on Friday evenings for European branches of American companies are another example. The request from head office to talk “just before the weekend” is familiar, although the weekend has already started in Europe. Europeans do the same with partners in Asia. Co-location means that all members of the team are in the same place or location. As a Tool and Technique it suggests that teamwork is better among teams that share the same “territory”. An office with some signs of life supports a team spirit, for example photographs, notices, coffee cups, piles of documents or flowers. Spontaneous communication is always better when the team members can contact each other easily, for example when they are in one location. It is well known that separation even by short distances reduces communication very considerably. An example is that people on different floors of a building have little informal contact, even if one floor is immediately above the other. Without communication a project cannot work. Another project which I worked on had activities in several countries. One of the people I needed to contact never replied to e-mails. When I next met him (face to face) we discussed this. He said that the problem was that we did not take our coffee break in the same room, not even the same country. As he got a couple of hundred e-mails a day, my messages were often overlooked. The solution was to send each other an SMS, a text message that we needed to talk. He would then call me. This worked.

140


These days, however, co-location has become in some ways less important because so much communication goes through mobile phones, instant message, chat, voicemail etc. In my experience, as long as the team members know each other personally, it is not necessary to be physically together all the time. It is reported that Sun Microsystems has a “work anywhere” (virtual teamwork) program. In the early days, many managers were refusing employees to the option to work at home, in spite of a policy allowing it. The manager responsible for the program then said that any manager who refused must justify his decision. Most managers then gave permission to work at home freely immediately after this change was applied. The last Tool and Technique in this section is Recognition and Rewards, which means “salary, pay” as well as related items such as bonuses, working conditions and formal recognition. This is another topic which there are many books about and which depends on culture. In England it is common for managers to get a company owned car. The size of the engine is the measure of personal importance. You may not have a car with an engine bigger than that of your manager! Long ago I had a colleague whose company paid half the cost of the car to managers. He created unease because instead of getting a small but good European or Asian car, he bought a really cheap Russian one. This did not match the image which his manager expected! How individuals respond to “rewards” depends on their personal situation. There was a long running railway strike in Germany because the engine drivers did not get enough money. One example was those who drive the first trains every day. They must have a car and pay for fuel to get to work (because they cannot come by train!). They did not feel very motivated by having to pay for these themselves. Employees should only be paid for doing what is beneficial. For example, somebody may refuse to come to a meeting because “he always goes home early on Wednesdays”, although this is not in his employment contract. If his manager does not contest this, then the employee is effectively being rewarded for his bad behavior because he has been allowed to do what he wants. The same sort of thing can happen with bonuses, when not fairly shared. In situations like this, other team members will sense discrimination and team performance will suffer.

9.4 Manage Project Team

141

The most significant Output is Team Performance Assessments. This means that, in some way, we need to have a “measure” or feel for how the team is performing. Signs of this include: l

l l l l

The project does what is expected. Note: even if the expectations changed during the project. Good collaboration and communication. Low staff turnover. Creativity in finding ways to meet the project objectives. The learning from the project feeds back into the organization.

In contrast, dysfunctional teams do not work together properly, are not cohesive and do not deliver. They occur when, for example, project team members concentrate on defined objectives and neglect interpersonal issues. Signs of dysfunctional teams include: l l l l l

Low project performance. Inefficiency, arguments, poor communication. Silent opposition, “game playing”, cliques. Significant unexplained staff turnover. Poor support from sponsor.

There is also the usual Output of Enterprise Environmental Factors Updates. In this case this includes updates of personnel training records and similar administration.

9.4

Manage Project Team Analogy: During work, the project manager has to ensure that everyone is doing their job properly. He must ensure that the plumbers and the painters etc. are working together without conflicts. Pitfalls: Workers talking their way out of poor performance, mobbing, potential conflicts not identified or badly handled.

We now assume that the team has been formed and has reached some level of cohesion and efficiency. This final process focuses on maintaining the team so that they can carry out the project. This is closely related to general management and requires all the usual skills, such as communication, problem solving, negotiation and in particular Conflict Management. All projects will experience some conflict and the Project Manager needs to be prepared for this. Conflict in projects is unavoidable because there are no guarantees that the demands of the various stakeholders will be compatible. It is the project manager’s responsibility to check if all the constraints can be met and to suggest solutions if they cannot. Each stakeholder wants, of course, what is best for him- or herself, which is not always the same thing as what is best for the overall project.

142


Throughout this chapter, the processes are “softer” than the more technical processes, but they are still very good reminders. The Manage Project Team process (Fig. 9-11) is in this category. The Inputs include Performance Reports, telling us what the status of the project is compared with the baseline plan and the forecasts. These reports cover all relevant areas such as schedule and cost, of course, but also scope and quality control, risk updates etc. For the technical PMBOK® Guide processes, this information is used to decide what adjustments to the project plan are needed. In this process, they are used to help identify if the team is making the planned progress and as a background for reviewing the performance of individuals. In some countries what is allowed is defined by law. All the other Inputs are familiar: l l l l

Project Staff Assignments Project Management Plan Team Performance Assessments Organizational Process Assets. The Tools and Techniques are also simple to describe, although there are some interesting points to note.

Observation and Conversation is always a good management method. You never know what you will really get to see! One version of this is called MBWA, management by walking around, which challenges the idea that managers just sit in offices. This style has several advantages including: l

l l

The employee is on his territory when the manager comes, making it easier to communicate topics that might get hidden. The manager sees all sorts of details about what is really happening. If the manager decides an employee has said enough, he can simply walk away. This is difficult to do from your own work location!

I suspect that managers who like MBWA are subconsciously less supportive of virtual Teamworking, because this method is then not usable. Project Performance Appraisals as a Tool and Technique means the familiar, often dreaded personal appraisals, applied in the context of projects. Actually, this is also an opportunity for the individuals concerned, since their contribution to the project may otherwise not be recognized or documented. If this is not done, there is a danger that the project team member will not get the recognition they deserve at the annual appraisal. Conflict Management has been mentioned already. How active this needs to be depends on the culture. For example, both Japan and Switzerland put a lot of emphasis on consensus. In Switzerland there is no official opposition to the government, because all main political groupings are represented in government. This

9.4 Manage Project Team

143

is called the Concordance System. When one politician said he wanted to be in the opposition, all the other political parties told him to stop playing around and to help everybody find consensus! This approach is reflected in the workplace. A number of techniques for conflict resolution are described, depending on whether the parties are concerned more for themselves or for others. l l

Compromise is not optimal, because it implies accepting an imperfect solution. Forcing is not very effective either, because there is a winner and a loser. I have never forgotten the incident years ago where a manager asked me for a report “before the end of the week”. I had no time available to do this at short notice, so worked in the evenings to meet the demand. When I handed over the report I asked why it was urgent for that day. I was told that the manager was going on holiday that day and wanted to be sure this information was on his desk (doing nothing) while he was away. Forcing did not make me a happy employee!

One of the best ways of problem solving is to collect all relevant information from all the people involved and share it. Solutions can then be worked out that meet everybody’s constraints or at least a compromise can be looked for. The next Tool and Technique is an Issue Log, which is a list or database of Issues or situations that require resolution. The status and the person responsible for each issue are also noted. Simply writing an issue down communicates that it has been recognized. This is what happens at airports to people whose luggage has been lost. Taking down details of the flight, the color of the luggage etc. is an unspoken message to the passenger that the search for his luggage is beginning. Interpersonal Skills are also listed as a Tool and Technique. Leadership, Influencing and decision making are particularly highlighted. These general management skills are discussed elsewhere in this book. How decisions are made, Effective Decision Making, is the last Tool and Technique in this section and is another general secret of Project Management. It is a good partner for Alternatives Analysis. Good decisions are taken based on Inputs from all the team and using objectivity to select the best option. Sensitivity to human issues is also required. There is an area of development called Collaboration Science, where tools providing processes for decision making are emerging. To give an idea of how different methods of decision making are possible, we need only to look at the different processes used in different countries for electing governments and presidents.

144


In France the presidential elections are held in two phases, with the two candidates obtaining the best votes in the first round facing each other for the final vote a week after the first one. In Ireland, all presidential candidates are listed on one ballot sheet. The voter shows his preference using numbers: 1 for the preferred candidate, 2 for the next and so on. If the person with the number one preference is not selected, the ballot paper is passed to the second choice and the votes are recounted. This process is continued until there is a winner, without a second ballot being needed later. The point is that the processes for decision making can be very different, some are better than others. Based on the experience, the processes can be progressively improved. Whatever the project, it is advisable to follow a decision-making process that takes into account the personal skills of the team members while keeping the project risk minimized. The real Output, a high performance team is not listed as such. What is listed here are several types of update, all of which we have seen before. For this reason, we will not repeat the descriptions here: l l l l

Enterprise Environmental Factors Updates Organizational Process Assets Updates Change Requests Project Management Plan Updates.

9.5

Exam Aids

Process Summaries 9.1 Develop Human Resource Plan: Identifies and agrees how the project human resources will be made available, so that those assigned can deliver the project. 9.2 Acquire Project Team: Implements whatever actions are needed to select and bring staff into the project. 9.3 Develop Project Team: Develops the staff into a coherent motivated team, who have both the competence and skills required. 9.4 Manage Project Team: Manages the team actively, including conflicts which may arise, so that the team can achieve the project objectives.

9.5 Exam Aids

145

Flash Card Terms Acquire Project Team Acquisition Activity Resource Requirements Alternatives Analysis Change Requests Co-location Conflict Management Develop Human Resource Plan Develop Project Team Effective Decision Making Enterprise Environmental Factors Enterprise Environmental Factors Updates Ground Rules Human Resource Management Human Resource Plan Interpersonal Skills Issue Log Manage Project Team Negotiation Networking Observation and Conversation

Organization Charts and Position Descriptions Organizational Process Assets Organizational Process Assets Updates Organizational Theory Performance Reports Pre-Assignment Project Management Plan Project Management Plan Updates Project Performance Appraisals Project Staff Assignments RACI Format Recognition and Rewards Release Plan Resource Calendar Responsibility Assignment Matrix, RAM Staffing Management Plan Team Performance Assessments Team-Building Activities Training Tuckman’s Team Development Model Virtual Teams

Chapter 10

Communications Management Processes


l

l

l

l

l

Projects depend heavily on sharing of information, not only for execution but also for decision making, problem solving and conflict resolution. From a management viewpoint, regular status and forecasts are also essential. This is because projects interact with so many business areas that their status must be both known and relatively predictable. The focus of the five communications processes described is reporting. A major target group for project communications is the stakeholders within your organization, such as senior management, line managers of the project team and those who receive the Project Product. As they play a very important role in projects, it is important to identify them systematically and to find out what they need to know. This is called a Stakeholder Analysis. When the purpose of the various communications requirements is known, the Plan Communications process can be implemented. This takes account of all the necessary details such as format, timing, language etc. The Distribute (the) Information process is seen as an operational task. This is different from Report Performance, which is more concerned with the actual message being communicated. Manage Stakeholder Expectations presumes that the project manager will provide the method and structure for this process. The Change Log and Issue Log are useful tools because they focus the discussion on topics where senior management can really support the project. The Report Performance process is concerned with the process of obtaining the performance information, as well as analyzing and formatting it.


147

148

10 Communications Management Processes

Project Communications Management Good communication, in the sense of being accurate, is absolutely essential for project management. Projects cannot be carried out completely by individuals acting alone. This means that they must communicate for several different purposes, for example: l l l l l l l l l l

Requirement Specification Planning Problem Solving Progress Reporting Teambuilding Decision Making Information Collection Consensus Building Negotiating etc.

Each of these types of communication needs different structures, contents and methods. This can become more complex for virtual teams. Despite this variety of communication needs, the processes of this Knowledge Area emphasize formal communication, which is mainly covered by reporting. Of course, reporting is essential, even though no project manager finds it interesting in itself. A project exists because it was established by the sponsoring organization, which also often provides the resources such as people, equipment, facilities, money etc. If something happens that affects the relative priority of your project, then this information must be made available so that good decisions can be made. Take the situation where a project wants to use a laboratory which is also needed by another project at the same time. The solution lies in the comparative importance and urgency of the two projects. Such a situation cannot be resolved optimally unless both projects communicate their status continuously to the organization that funded them. In addition, the sponsor who provided the budget is entitled to know what is happening in the project. Reporting confirms (hopefully!) that the budget of time and resources (including people) dedicated to your project are delivering the expected solution. Project reporting cannot be avoided. Therefore it is not surprising that reporting to management is emphasized strongly under the heading of Project Communication Management. The five processes separate the preparation of content (a management task) from the actual communication and distribution (a task for operational staff). They are spread across all Process Groups except Closing (Table 3-1). Let us look at each one in turn. Two very thorough checklists for communications are given in the PMBOK® Guide (see introduction to Chap. 10). One is for dimensions such as internal/ external, formal/ informal etc. and the other is for skills such as Active Listening,

10.1 Identify Stakeholders

149

Questioning and Negotiating etc. These checklists can be revised by project managers to make them more relevant to their own project situation.

10.1

Identify Stakeholders Analogy: An important task is to identify all the stakeholders and determine how best to deal with them. This includes the neighbors, building authorities, utility companies and other relevant institutions. Pitfalls: Forgetting stakeholders, wrong approach to manage stakeholders.

Identify Stakeholders is the process of examining who is affected by the project, what do they need to know and how they want this information to be delivered to them. This is not as trivial as it might seem, as the example shows. I once worked for a mobile telephone company during the construction of their network. Every neighborhood objected to having antennas in their area, mainly because of “electro-smog” or “aesthetics”. The legal objections slowed down the program by several months and affected the profits badly. This meant that a competing network had to be used (and paid for) until all the antennas were operational. One resident lived in an apartment block which had an antenna on the roof. She complained of headaches and illness because of the radiation, despite the fact that the antenna was not switched on. In order to moderate the communications with these interest groups, a charismatic engineer was put on television, to say that there really was no problem. In addition, the roll-out manager was fired. The actual problem was that those who lived near the antennas had not been identified in advance as stakeholders. This meant that their information needs were not considered. If the Identify Stakeholders process had been applied, the various residents’ groups would have been identified earlier as stakeholders and, hopefully, a more proactive plan would have been prepared. The Inputs and Outputs of this process are in Fig. 10-2. Except for Procurement Documents all the Inputs are known to us and will not be discussed again: l l l

Project Charter Enterprise Environmental Factors Organizational Process Assets.

Procurement Documents is also a process Input and relates to products or services which we obtain externally. This is potentially a significant part of project management and so Procurement has its own Knowledge Area. Procurement is

150


relevant for communication because suppliers are stakeholders. They will be named in the procurement documents. Remember that stakeholders includes everybody who is interested in (either for or against) the project, whether they are inside or outside our organization. The Tools and Techniques are Expert Judgment, which we have discussed previously, and Stakeholder Analysis. The first step of this includes making sure that all stakeholders have been identified. We can use the same techniques like those used in Project Time Management for identifying all project activities; brainstorming, Post-it® notes, Delphi Method etc. The emphasis here is on completeness: some people were overlooked when building the mobile phone network mentioned above. The second step is to identify what their power and interests are. Maybe some stakeholder is potentially an ally of yours. Or maybe an operational manager finds that your project threatens his interests and will work behind the scenes to obstruct you. This information can be collected and displayed on a grid, like that in Fig. 10-4. The third step is to work out how these stakeholders will act in different scenarios and to develop ways of leveraging from them. Ignore stakeholders at your own risk. The main Output is the Stakeholder Management Strategy. As you would expect, this is for making sure that the stakeholder communication is under control. It requires focused and creative thinking. For example, it includes how much we should involve the stakeholders. This is particularly true for the sponsor but also other high profile senior supporters. The Stakeholder Register is also an Output. It contains a list of everybody who has something to win or lose through the success of the project. It should also include assessments of their: l

l

Positive or negative interest. This indicates how they are likely to interact with the project. Power and influence, indicating how much they can help or hinder the project.

The Project Manager must continuously leverage from the positive views of stakeholders and try to reduce the impact of negative views. To do this, he must be aware of and use the influence of stakeholders.

10.2

Plan Communications Analogy: The next step is to determine what, how, when and by whom the neighbors of the new house will be informed. Pitfalls: Wrong communication method, information made available too early or too late.

10.2 Plan Communications

151

This process is concerned mainly with working out how to package and send the information. Different levels of management require different levels of detail. In addition, different managers have different styles of communication and are unhappy if the style does not suit their preferences. Some of them have great influence and need special treatment. Take the sponsor, for example. Without the active support of the sponsor, a project will not have anyone to defend its case against higher levels of management. The sponsor should always be in very close touch with the project manager. The sponsor is always a senior person and therefore likely to be very busy. You should ask about his personal preferences when deciding how to communicate. Some options include: l l l l

A daily e-mail summary Informal coffee meeting once a week Access to a database and Telephone calls during the weekend. The Inputs to the process are all familiar to us and need not be described again:

l l l l

Stakeholder Register Stakeholder Management Strategy Enterprise Environmental Factors Organizational Process Assets.

The first Tool and Technique of the process is the Communication Requirements Analysis. There is nothing unusual here, just a good understanding of who needs the information. The analysis should recognize the value of each type of information, as this may affect what resources are applied to communicating it. This analysis generally uses available information such as organization charts, stakeholder requirements etc. There is a little formula which sometimes appears in the PMP® examination, concerning how many communication paths can exist between a given number of individuals. If for example, there are three stakeholders, there are three possible one-to-one communications paths. If there are n stakeholders, there is a choice of n people for the first partner of each communication path. As a result, there is a choice of one person less (n1) for the second person. By multiplying these two items together we expect to get the number of paths: n ðn 1Þ There is one more point to think about. This does not consider that each path is being counted in both directions. This means that the formula should be divided by 2: Number of communication paths ¼ n ðn 1Þ 2

152


This allows us to calculate the number of possible communication paths among a group of n people. It may be easier to remember the logic than the formula. So what does this mean? With 6 people there are 15 communications paths. This means that meetings with six people have a lot more potential cross-talk than a meeting with three people. We do not need to take this literally, but it does suggest that if, for example, there are more than about five people in a project steering committee, it will be very difficult to get agreement. This happens if everybody insists on saying everything they want to say. Actually this seems to be one area where a virtual team does better. The reason is that with web meeting technology, it is possible to turn each person’s microphone on and off. By having only one person talk at a time and by using e-mail for all except the most important comments, it is possible to control meetings with much bigger groups. Another project I worked on had a weekly telephone meeting each Friday at midday, supported by slides sent out the day before. The deadline for the minutes was the close of business on Fridays. The deadline for changes to the minutes was the close of business on Mondays. In this way a team of 15 (which has 105 potential one-to-one communication paths) was able to communicate effectively. The next Tool and Technique is Communication Technology. The important point here is to consider how the information will actually travel. For example, you may have a project database which the sponsor can read, but that busy person does not want to have to select and interpret information. Maybe a weekly .pdf summary is better. This format is particularly good for global projects because it adjusts automatically for different paper sizes. But will this be generated automatically or by somebody in the Project Management Office? Will it be sent by e-mail as an attachment or placed in a shared drive on the network? There is the story about the visitor to the tiny island of Barra in the Outer Hebrides, which is in the Atlantic Ocean nearly 150 km from the mainland of Scotland. He went to buy a newspaper and was asked if he wanted that day’s or the previous day’s edition. When he said that he wanted that day’s paper, he was told to come back the following day. Apparently more communication planning was needed than he had expected. Communication Models are also described as a Tool and Technique, supported by Fig. 10-8. The significant point is that any communication starts out in the mind of a person (“sender”) and is often distorted or altered before it is interpreted in the mind of the receiver. Examples of causes of distortion are:

10.2 Plan Communications l l l

153

Physical noise on a poor telephone line. Wrong words (when speaking a foreign language), and The receiver is tired and does not listen carefully. The result is that the message is not understood as intended. You may remember the children’s game where they stand in a row and a message is whispered to the first child. Each then whispers the message to the next and when the message arrives at the last child, it has always been changed.

A situation like that in the example is not useful for projects (or for Fire Brigade, Military etc.). One possible solution is to ask the receiver to repeat the message back. If the sender gets the same message back as he sent, then communication is accurate. This works not only for speech or written text but also for body language. Here again, care should be taken in multicultural situations. To me, a European, a sideways shake of the head means “no”. There is a gesture used in India which looks similar to me but means “yes”. Just think of the possibilities for misunderstandings! Communication Methods are also described as interactive, push (where the message is sent anyway, like an e-mail) or pull (like a website which only appears if you look for it). The Output Project Document Updates requires no explanation here. The main Output, the Communications Management Plan, however, does. Remember that a Management Plan is not the operational project plan but the plan for the management. Formally planning the communications has a big advantage: it allows you to involve representatives of all work packages and make sure that the details are reasonable for everybody. Without the discussion to generate the communications management plan, many issues may not even be mentioned. In a globalized environment, we should not assume that the preferences are the same everywhere. Two examples relating to local preferences from my experience are highlighted: I was working on a project in Vienna, Austria which also included team members from the same company in Hungary, whose border is only 40 km away. On Fridays, work usually finished at lunch time in Austria but at 6 p.m. in Hungary. This led to different expectations within the team about availability on Friday afternoons for this particular project. In Spain the daytime meal is taken about 3 p.m. and this affects the times of business meetings. This is described by saying that it is as if there were a 2 hour time zone difference from the neighboring country, France. Both countries are in the same time zone.

154


By documenting the Communications Management Plan, you can then bring it forward for discussion and inclusion in the overall project plan. Possible elements include: l l l l l l l l l l l

Why the information is needed. Who should get it. How often. Document formats, for example for meeting minutes (record). What technology will be used, for example e-mail or web site? Communication Tools, such as net meetings, telephone conferences. Accessibility of information, databases etc. Language(s) to be used. Meeting times and reaction times, for example for replies. Which days are taken as weekend in each project location. etc. As for all plans, they should be authorized formally before implementation.

10.3

Distribute Information Analogy: The project manager prepares a leaflet informing the neighbor about the planned work. It warns the neighbors when the electricity will be cut so that the house can be attached to the grid. Pitfalls: Wrong communication medium, message context not suited to stakeholders (too technical etc.).

The focus now changes to the actual distribution of information to the stakeholders and this is mainly related to communicating the reports. The diversity of human experience challenges a project manager, who (probably unconsciously) assumes that his or her cultural norms apply for all project locations. Even if project team members appear to accept the project manager’s approach, they may talk unfavorably about it privately. It is a cliche´, but true, that the communications environment in projects has changed greatly in recent years. This is not only because of e-mail and internet, but also because younger generations have grown up with improved connectivity. Figure 10-9 shows the process. The Inputs have already been described and are here just listed as a reminder: l l l

Project Management Plan Performance Reports Organizational Process Assets.

10.4 Manage Stakeholder Expectations

155

Only two Tools and Techniques are described: l

Communication Methods such as meetings, (tele-) conferences etc. The emphasis here is on allowing the receiver (stakeholder) to clarify what they are told, in order to check that the communication is accurate. An example I heard of that relates to communication methods was about the chief executive of a US company’s subsidiary in the Netherlands. When telephoned he used to say “I do not understand because the line is not very good. Please fax me that information”. He actually understood very well, but used this trick to give himself some time to think before replying.

l

Information Distribution Tools such as e-mail, conferencing tools, hard copies, databases etc. Issues such as style and print size play a role because opticians say that people over 45 years old cannot focus on close items. Nearly everyone needs to wear glasses to read. I knew an HR Manager in a toy factory where I sometimes worked. When given a report to read, he used to say “yes, I see your report but tell me in summary what is in it”. The reason was that he did not want to wear glasses (because of vanity) and could not read the report.

There is one single Output: Organizational Process Assets Updates. In particular, the Stakeholder Notifications are updated, for example when an issue has been resolved, project reports have been sent, records have been completed etc. As part of the Closing (not necessarily just at the end of the project), the lessons learned are also documented, circulated and updated. In summary, this process is concerned mainly with the transmission of project information and is seen as an operational task.

10.4

Manage Stakeholder Expectations Analogy: The local environment agency has defined a lower CO2 emission for the central heating. The project manager makes a change and orders a different heater with cleaner emissions. Pitfalls: Ignoring stakeholders, not implementing mandatory changes.

This is an interesting process because it says that the project manager is responsible for keeping in contact with the stakeholders. Naturally this includes

156


busy senior managers within the same company or organization as the project. They may prefer to be given solutions rather than problems and not be very receptive to some suggested changes. Stakeholders are people with feelings and the way the project is managed should also recognise this human element. The perception that the project is under control can be helped by proactive regular communication and clarification, with the support of the project sponsor. This results in a two-way process which addresses concerns and supports active management of stakeholder expectations. A successful project always meets the expectations of the stakeholders, even if the expectations evolved during the project. As project managers, we can do this either by delivering what they expect or by helping them change their expectations. From Fig. 10-11, the following Inputs have already been described and are not repeated here: l l l l

Stakeholder Register Stakeholder Management Strategy Project Management Plan Organizational Process Assets.

The new items are the Issue Log and Change Log. An Issue is a concern which is directly relevant to the project now. It is a problem or risk which has happened and which we must resolve. Maintaining an Issue Log can be a positive way of acknowledging the Inputs of stakeholders. For example, we are waiting for a delivery of materials to complete a prototype and the supplier company has a fire at the factory. They tell us that the delivery will be delayed by 8 weeks. This would almost certainly result in our stakeholders’ expectations not being met. The first step is to describe the issue and write it down clearly in the Issue Log, often using a spreadsheet or database. The first step in meeting expectations is to agree at least on the description of the problem. We also have to evaluate the issue and classify the importance (it has a big impact) and urgency (how quickly it must be addressed, if at all). I once had a manager who, when several things were not working well, used to say “Let the fires burn. We cannot put them all out”. It is much easier to have a regular objective discussion with a stakeholder about the Issue Log, than to send the bad news in a message. The danger is that “the messenger (you, the project manager!) is attacked because they do not like the message”! The Change Log is a record of changes compared with the plan that have happened or have been implemented. It makes discussion easier if they are all listed in one place and kept up to date.

10.5 Report Performance

157

The Tools and Techniques mention topics which we have already discussed. They are neither new, nor is their use restricted to projects: l

l

l

Communication Methods, for example frequent meeting over coffee for regular informal communication of progress. Interpersonal Skills, such as active listening, problem solving etc. There is a useful Appendix G in the PMBOK® Guide which discusses these matters. Management Skills, such as negotiating and presentation skills. The Outputs have also been discussed already and are:

l l l l

Organizational Process Assets Updates Change Requests Project Management Plan Updates Project Document Updates.

These Outputs result from the discussions with the stakeholders. It is worth making sure that the sponsor in particular remains a strong ally. This not only gives you political support in high places but also easier acceptance of difficult messages. To recapitulate, we meet expectations either by completing the delivery or by changing the expectations!

10.5

Report Performance Analogy: The project manager compares the work progress with the building plan. He makes status and forecast reports. Pitfalls: Falsifying actual performance (hiding problems), adjusting forecasts to fit budget and schedule.

This last process in the Communications Management Knowledge Area is about reporting the actual project performance to the stakeholders. This means collecting, filtering and re-presenting the information. This applies both to status and forecasts of a wide range of project topics such as schedule progress, unfinished work, issues or even resignations of key people etc. The key point is to select and format the information to be suitable for the particular sponsor or group of stakeholders. When this is done well, they will understand the project better and this usually results in better management of expectations. A consolidated weekly or monthly report is key to driving projects. These can be used with stakeholders to support a common understanding of the progress, issues, risks and next steps etc.

158


Luckily we recognize all the Inputs in Fig. 10-13 from previous processes: l l l l l

Project Management Plan Work Performance Information Work Performance Measurements Budget Forecasts Organizational Process Assets. Next we look at the Tools and Techniques which are:

l

l l l

Variance Analysis, previously discussed in connection with the Control Costs process. Forecasting Methods. Communication Methods, mentioned several times in this Knowledge Area. Reporting Systems.

The technique called Forecasting Methods is a mix between extrapolation of historical data and applying our experience. If we take data over a long time from a particular supplier and find that specification changes result in us paying 30% more than the original contract prices, then we can add 30% to the quoted price to estimate the total cost. We can also use our judgment and experience based on other factors. All the methods used by stock market traders will be familiar here: linear regression, moving averages etc., adjusted by feelings, hunches, and experience of the environment. Enterprise collaboration tools, such as Microsoft SharePoint, are very effective in reducing multiple communication channels. This is especially true for projects which are executed across large companies or between various locations. By coordinating the set up of SharePoint and Microsoft Project, both the plans and reports can be in one place. A relatively new development in business is the widespread use of chat in company networks. This is not to say that the technology did not exist previously, but that it was sometimes intentionally turned off by management. Communicating by chat has considerable advantages (and some disadvantages) compared with telephone: l l

l

l

You can have several sessions running in parallel. The text is automatically available for archiving. This can also be an advantage in certain legal situations. It can be used where too much talking is not welcome, for example in open plan offices. It is useful for language learners who are not sure about pronunciation. I once ran a workshop in English with Spanish and Polish participants. They could understand me but they could not understand each other.

10.6 Exam Aids

159

The last Tool and Technique is called Reporting Systems. These are software tools which select, consolidate and present the information from one or several sources. Today such tools can combine data from complex databases and present the results in different formats, such as on hard copy or for viewing with a browser. The point is to remember the importance of close communication with stakeholders so that their expectations stay close to what the project can actually deliver. The Outputs of the Report Performance process include, of course, Performance Reports. The formats for various report elements such as Bar Charts, Histograms etc. are also described. The content may also include Earned Value Analysis, Forecasts, Risks and similar systematic data. The essential point is that the combination of content, format, frequency, delivery method, style etc. should be accepted by the particular stakeholder. This is why report formats should be discussed and agreed as part of initial project planning. Figure 10-15 gives one example of a report in table format. The other two Outputs are similar to those of many other processes and so are merely named here: l l

Organizational Process Assets Updates Change Requests.

10.6

Exam Aids

Process Summaries 10.1 Identify Stakeholders: Lists organizations and individuals that have an interest in the success or failure of the project, whether they are inside or outside the organization. 10.2 Plan Communications: Identifies and details how to implement the necessary communications with the various project stakeholders. 10.3 Distribute Information: Obtains and delivers the information to the Stakeholders according to the plan. The emphasis is on the transmission methods. 10.4 Manage Stakeholder Expectations: Works actively with the stakeholders and leverages from their resources to resolve issues and achieve the project objectives. 10.5 Report Performance: Collects and delivers information to stakeholders about project progress and projections. The emphasis is on communication and interpretation.

160


Flash Card Terms Budget Forecasts Change Log Change Requests Communication Methods Communication Models Communication Requirement Analysis Communication Technology Communications Management Plan Delphi Method Distribute Information Enterprise Environmental Factors Expert Judgment Forecasting Methods Identify Stakeholders Information Distribution Tools Interpersonal Skills Issue Log Manage Stakeholder Expectations Management Skills Organizational Process Assets

Organizational Process Assets Updates Performance Reports Plan Communications Procurement Documents Project Charter Project Communications Management Project Document Updates Project Management Plan Project Management Plan Updates Report Performance Reporting Systems Stakeholder Analysis Stakeholder Management Strategy Stakeholder Notifications Stakeholder Register Variance Analysis Work Performance Information Work Performance Measurements

Chapter 11

Risk Management Processes


l

l

l

Project Risk Management covers all project types, including the very largest. Because of this, the processes are comparatively complex and should be simplified for smaller, less risky projects. Risk Management is different from other knowledge areas because it is partially subjective, depending on individual attitudes to uncertainty. The first process Plan Risk Management covers issues such as responsibilities for risk management. The project manager is responsible for ensuring that the risk management processes function properly. In order to make sure that no significant risk is overlooked, the next process is simply Identify (the) Risks. These risks will then be assessed, first by using Perform Qualitative Risk Analysis, then Perform Quantitative Risk Analysis. The resulting risk ranking list is used to identify the Plan Risk Responses. The final process to be described is Monitor and Control Risks.

Project Risk Management Risks are uncertainties which could affect a project in future. If the situation has already happened, then it has become an Issue for the Issue Log. The PMBOK® Guide uses the convention that Risks can be both positive and negative. Many readers will find this surprising, since risks are often thought of as something negative to be avoided. This approach does, however, make sense as Risk Management is constantly looking out for things that can affect the project in the future. Of course we may also have good luck instead of only bad. The processes can be applied to everything from a small 2 week project with three people right up to sending a man to the moon. Nevertheless the extensive processes do not need to be applied to every project. This is because the general ´ Conchuír, Overview of the PMBOK® Guide, D. O DOI 10.1007/978-3-642-11188-4_11, # Springer-Verlag Berlin Heidelberg 2010

161

162

11 Risk Management Processes

guideline (in Chap. 3 of the PMBOK® Guide) that the project manager must decide how much or little to formalize a process is particularly relevant for risk management. The remainder of this introductory section presents some personal observations about project risk management, which many PMP® candidates have found to be helpful. It is however not in the PMBOK® Guide and can be skipped without loss of continuity. The key points in this section are summarized first and then explained below: 1. Risk Management must be documented and communicated. 2. Risk Tolerance is individual, so major project risk management decisions should be made by the stakeholders collectively. The project manager must make sure that risk information is collected and communicated clearly to the Steering Committee so that informed Risk Management Decisions can be made. It is not possible for the project manager to manage risks alone. This is quite different from planning or quality, which can be done alone. 3. In situations where there is reluctance by stakeholders to get engaged, communicate facts about the impact and take small steps at a time. 4. The Project Manager is responsible for ensuring that the team is aware of the risks and impacts, as well as for doing everything reasonable to minimize the risks. The project manager is responsible for the risk management process, not the risk itself. We now look at the background to these observations.

Risks Must be Documented Everything about managing risk processes depends heavily on communication. It is neither possible to have agreement on what a risk is, nor to find suitable responses, unless the risks are documented. In addition, if the risk processes are not documented, then there is no basis on which to build when learning from experience. An example of this occurred in southern Germany. The flat roof of a sports hall collapsed one winter because of the weight of snow lying on it. Several children were killed. During the investigation, satisfactory risk documentation could not be identified, making it more difficult to implement measures to avoid such situations in future. In particular, negative risks that turn into issues are often very challenging. However, they are also an opportunity for learning, so future projects can run more smoothly. This is why so much emphasis is put on finding the flight recorder or


163

“black box” after air crashes: so that the situation can be examined in detail and hopefully avoided in future. Communication about project risk should be open and honest. Risk should also be managed proactively. Sometimes, project managers hide the risks from specific stakeholders and this, in turn, escalates the risks. Merely knowing about a risk can help reduce the effects. For example, you are rushing to the airport to catch a flight when you get a text message from the airline that the flight is delayed. The (perceived) risk of arriving late is reduced, just by having up-to-date information.

Risk Tolerance is Individual Much of project management is very objective. This means that we try to avoid personal interpretations and deal with hard reality. Risk Tolerance indicates how much risk a company or person is prepared to accept. Appetite for risk depends both on the project environment and personal attitudes to life. This is well illustrated by two questions which banks often ask first, before advising a client about private investments. The questions are: 1. How old are you? 2. What is your attitude to risk? The first question is used to get an overall view of the likely potential attitude to risk. The older you are, the less you can afford to lose your capital or pension fund. Younger people can lose everything and have a lifetime to catch up. Older people have less time to catch up! The second question is used to modify the assessment of risk tolerance according to your personal preferences. Let us transfer this to the project situation. The members of the steering committee will each have individual views about what is risky. These may or may not be in line with the attitude to risk which the company holds. A project manager who polls stakeholders individually to get agreement on risks will then get conflicting demands which cannot all be satisfied. A solution is to make sure that significant project risk decisions are made by the steering committee as a whole. This means that the project manager must provide the information and support the decision making process. Of course he will also constantly monitor and control risks and act on smaller ones himself, based on his experience and that of his team. It would be a mistake to make a major project decision alone. The exceptions are in times of stress and threat, such as in wartime, but this is not the normal usual environment for a business project.

164


Small Steps With Factual Information Facilitate Involvement Imagine a project situation where management is reluctant to take responsibilities for risks, for whatever reason. You try to engage them, but get comments such as: l l

“I do not care if you have to work hard; you just must finish on time”. “It is not my business if some of the materials were lost/ damaged/ stolen. I still hold you accountable for delivery of the project”.

Risk management is invisible and in some situations, the stakeholders may try to avoid taking responsibility for the risks. To encourage interaction, try to communicate as follows: l

l

With facts, including impact: “If we do not act now, the key engineer will leave the company and the project will finish 10 weeks late”. In small steps: “Here are the risks we have identified and what it will cost if they happen. We need to discuss how we manage these risks”.

Risk Is Owned by Whoever Accepts It Imagine that I decide to buy a car. At the car dealer, I am offered two options: one is new from a reputable manufacturer; the other is a used car without guarantee. I select the second cheaper option. If faults appear some weeks later, I cannot expect the car dealer to fix them without payment, because with the decision I also took the accompanying risk. A parallel scenario in a business project occurs when you plan everything carefully and start the project. Sometime later there is a problem with a prototype and you, as project manager, believe you will be 6 weeks late due to circumstances which you cannot control. Your manager and project sponsor do not want to lose the customer so decide: l l

Not to tell the customer that there is a problem To tell you (the project manager) to deliver in the original planned time without extra resources or change in constraints.

Who accepted the risk? If you communicated (using WBS etc.) that the change in scope requires some compromise and this was ignored, then the person who decided neither to tell the customer nor to give you extra resources must take responsibility for the risk. On the other hand, if you, as project manager, did not stand up and communicate the risks (or did not make yourself understood), then you become responsible. When the problem eventually becomes visible, you will find that you cannot deliver what is expected.

11.1 Plan Risk Management

165

We are now ready to look at the processes described. The fact that there are six of them aligns with the 3rd guideline above. All of the processes, except the last one, are in the Planning Process Group. This means that they are associated with the planning mentality, not that they are in an early phase called planning, then forgotten. In fact Risk Management already begins during Initiating and has to be constantly replanned until the project is closed. In some ways these processes reflect the Quality Management processes. They also require additional details to be included in the project plan. However, some actions taken to optimize the effects of (positive or negative) risks may have side effects by creating new risks. This means that the project risk management is iterative: the details are added and reviewed until the entire plan is stable.

11.1

Plan Risk Management Analogy: The project manager sits down with the experts to determine how to deal with the risks of building the house. Pitfalls: Risk management plan not suitable (too complex, too simple, etc.). The first process is naturally Plan Risk Management, which requires detailed background information about the whole project. The first four Inputs come from other processes and do not need to be described again:

l l l l

Project Scope Statement Cost Management Plan Schedule Management Plan Communications Management Plan. The remaining Inputs are by now also familiar:

l l

Enterprise Environmental Factors Organizational Process Assets, including Risk Categories. This is another one of those simple ideas that can have a big impact. Identifying the categories provides a basis for more thorough risk identification (the next process). It also helps identify who to consult. For example, if we identify a category “HR Risks”, then a brainstorm with the HR Manager may suggest risk areas that might otherwise be overlooked.

One way of starting this process is to take the Risk Breakdown Structure in Fig. 11-4 and develop it further to suit our circumstances. There is just one Tool and Technique: Planning Meetings and Analysis. This high level description permits a broad range of planning approaches, depending on the circumstances of the project. This process reminds us that the risk management planning must be thought through first, in order to form a basis for our approach to risk.

166


It is important to select the participants with the appropriate competence and authority for these risk planning meetings. Besides the project manager, it can make sense to involve selected stakeholders to ensure a link to those who will ultimately approve the Risk Management Plan. It is one area of project management where the stakeholders should take a partially operational role, since they are involved in the risk decision making. Both technical and business experts should participate, not necessarily only people with senior job titles. Possible questions to consider include: l l

l l l

l

l

How will the risk processes be managed? How will they be documented? How will access to this documentation be managed? Who will take responsibility in the project team for risk matters? How formal or informal should the risk management be? Are business risks (for example, key person leaves) and technical risks (for example prototype needs more testing than planned) to be treated together? How often should the risks be reviewed? New risks are always possible, so it is important to review the risk environment from time to time. What budget is there for managing risks? It is not possible to implement actions to address risks without funds. If no budget is available, then the chances of completing the project are reduced. It is like travelling on holiday with just enough money to get home – if something unexpected happens, we are stuck. All risks have two independent parameters:

l

l

Probability: How likely is a risk? Nearly certain? Possible? Most unlikely? Probabilities are measured on a scale from zero (impossible) to one (practically certain to happen). Impact: What is the damage or benefit if the risk happens? Remember that risk covers both negative and positive situations. The impact can be estimated, for example, in weeks of delay or percentage of orders lost. However the universal unit of measurement is money; even though estimating impact in cost terms is not always easy, or even possible.

It should be emphasized that these two parameters are independent of each other. For example, it may be unlikely (low probability) that we crash our new car, but the impact (cost) could be high. Figure 11-5 shows possible scales for categorizing impact. In view of the comments at the beginning of this chapter, the Risk Management Plan should document the attitudes and tolerances to risk of the various stakeholders. It also states what formats will be used for reporting and tracking risk. There is a single Output: the Risk Management Plan. This contains basic decisions on how we are going to manage the risks, for example how detailed our documentation will be.

11.2 Identify Risks

11.2

167

Identify Risks Analogy: Once it is agreed on how risks will be managed, the project manager reviews the documentation. Based on his experience and that of the experts, he defines a list of risks that could potentially occur. Pitfalls: Forgetting risks.

Very often risk management begins with the process of identifying risks, which can be applied even during initiating. This is consistent with the PMBOK® Guide approach, even though there are no risk processes in the Initiating Process Group. This is because the standard does not try to document every possible linkage, but expects the reader to look for them. Risks are recorded in the Risk Register, which is the only Output of this process. This must be kept up to date, as risks can occur at any time, from initiating to closing. Overlooking risks can be very expensive. An unfortunate example concerned the roof of a new airport terminal building at the Charles de Gaulle Airport in Paris, which collapsed and killed several passengers. The roof was made of concrete and a section slipped, apparently due to small movements of the supporting surfaces. This risk should have been identified and addressed during the design phase, before the building work started. As a risk can occur in any part of the project, we need as much information about the project as possible. This is why there are 11 Inputs, all of them familiar to us, which makes it unnecessary to describe them in great detail here: l l

l l

l

l l

l l

Risk Management Plan Activity Cost Estimates. Of course, we may introduce extra activities in response to the risks and these will add to the costs Activity Duration Estimates Scope Baseline. The WBS represents the scope graphically. It can be used as a structured checklist to help us look systematically for risks Stakeholder Register. The experience of these people should be used to crosscheck our risk register. If they find something we overlooked, then we should welcome their help. Cost Management Plan Schedule Management Plan. Risks can occur because the schedule is too ambitious. Quality Management Plan Project Documents

168 l l


Enterprise Environmental Factors, with regard to risk and attitudes to risk. Organizational Process Assets, in particular experience of Risk Management.

Because we must be thorough and complete when identifying risks, we use several Tools and Techniques, of which Expert Judgment is familiar to us. Now we will look at each of the others. Documentation Reviews are a very good way of finding out what risks might happen, since a lot can be derived from the specifications. Not only is the consistency important but also the documentation quality. If it is not good, this may indicate that the management style is not very thorough, hiding other risks. The emphasis of this process is completeness, so using several Information Gathering Techniques can increase the chances of finding all important risks. These tools can be used for many project management tasks. The following were described in connection with Scope Management in Chap. 5: l l l

Brainstorming Delphi Technique Interviewing.

Another technique to help identify risks is Root Cause Analysis. It involves looking at problems, with particular emphasis on finding out their real cause. It is possible that one area is causing a large proportion of risks. The next Tool and Technique is Checklist Analysis. We have already discussed how powerful checklists are, as they help us be thorough as well as utilizing past experience. Assumptions Analysis, like much of risk management, is not very visible. When making decisions, we often have to use assumptions, either consciously or unconsciously. It makes sense to document them, so that they can be discussed and analyzed later. In doing so, we may identify other risks arising from different assumptions. For example, a manager may assume that part of the project for developing a new IT system will also include training. The development team may assume that this is neither necessary nor is it their responsibility. These differences in assumptions will later lead to problems. Assumptions Analysis can help identify situations such as this. Diagramming Techniques is the very general title of the next Tool and Technique. Possibly the best known of those mentioned is the Fishbone Diagram, which is used to discuss and document Causes and Effects. It is also called after its originator: Ishikawa. The SWOT Analysis can be described as a structured brainstorming method, focusing on: l l

Strengths and Weaknesses, for internal issues. Opportunities and Threats, for external issues.

This can be done on the project, the company or even work package level. The result should give a better understanding of the risks that we should consider (Remember: both positive and negative).

11.3 Perform Qualitative Risk Analysis

169

An example where all the risks were not addressed was the building of ETR 610 Cisalpino trains for use between Switzerland and Italy. These were intended to replace an earlier model, which had a reputation for unreliability. These trains failed to get approval to start service at the end of 2008 as scheduled. The problem was that the trains were too heavy for use at the planned high speed on curves in the Gotthard Tunnel through the Alps. This arose because the design included equipment to meet all of the following requirements: l 250 km/h travel on high speed stretches in Italy. l Tilting technology for travelling at high speed in Swiss mountain tunnels. l Different electricity standards in the two countries. When a train is too heavy there is a danger of derailment or track damage, if it travels too fast in a curve. A risk analysis showed that: l The project was too complex. l Priorities in the Italian and Swiss railway companies were not the same, for example regarding whether or not to keep back-up trains on live standby in case of delays. l There were different business cultures in the two countries. Eventually, it was decided that the company could not provide a reliable train service between the two countries and was closed in 2009. Risks must be correctly described; otherwise the Risk Response may not address the right risk. The descriptions of all the risks are recorded in a Risk Register, the only Output, which can be a database or spreadsheet. This risk register will be refined step by step by applying the other processes.

11.3

Perform Qualitative Risk Analysis Analogy: The project manager has identified that rain will potentially delay construction, so he now determines the probability of rain during the building phase and its impact on painting and masonry work. Pitfalls: Underestimating risks, wrong basis for risk judgment.

This process delivers a ranked or ordered list of the most important risks, as well as estimates of their probability. This saves us time and effort as we can then devote our analysis effort to the more important risks in the next process. Risk decision making must be a group activity, because this must be done interactively with appropriate participants. You will recognize all the Inputs of this process:

170 l l l l


Risk Register Risk Management Plan Project Scope Statement Organizational Process Assets. Among the Tools and Techniques, Risk Categorization and Expert Judgment have been described previously. Let us now review the others.

Risk Probability and Impact Assessment means estimating the probability and impact for each risk. The results of this can be transferred to a Probability and Impact Matrix, such as that in Fig. 11-10. Notice that this figure has numeric values for each probability and impact combination, which relates more to the Quantitative Analysis in the next process. Each risk is assessed for probability and impact, using categorizations such as High, Medium and Low. Other scales can be developed if appropriate; for example “less than a week”, “up to a month” and “longer than a month” for the impact of risks that cause delays. Which areas of this chart are considered to represent high risk is a reflection of the company attitude to risk. This should be agreed before moving on to the next step. One very good way of combining the identification and assessment of risks in one step is to ask the stakeholders to write down as many risks as they can think of, one Post-it® note per risk and to stick them on a Probability vs. Impact Matrix on a flip chart. This is a dynamic process, so doing it slowly or without bringing everybody together will give a far less useful result. The notes are then sorted, combined and re-positioned on the matrix as the result of intense discussion by all present. This exactly meets our preference for team decision making. How useful the probability and impact estimates are depends on the data quality. This is why the next Tool and Technique Risk Data Quality Assessment is used. I was working on one project where the risks were not very well managed. To track the risks, each work package manager was asked to send in his list of risks weekly. There was no cross-checking so the lists were not very complete. For example, one key manager had applied for another job and left the project, but he did not mention this risk in his reports. Although the PMBOK® Guide uses a double matrix both for threats and opportunities, in my personal experience, project teams tend to focus more on threats. Opportunities are more likely to be followed by business staff than project staff. One benefit of Risk Categorization has already been mentioned, that is to help focus on particular areas. Maybe similar causes can be assigned to similar categories and this helps us be more thorough. One way to get a more complete picture of the risks is to categorize them according to urgency. One approach suggests not responding to less urgent risks,

11.4 Perform Quantitative Risk Analysis

171

so that effort can be spent on the more urgent risks. Which risks are more urgent is identified using a Risk Urgency Assessment. All of these Tools and Techniques enable us to prepare the process Output: the Risk Register Updates, in particular the revised impact and probability of the risks. There are also some other less central details which can also be noted in the risk register, such as: l l

l

Risks for which we need more information. Low priority risks. These are still documented and kept on a watch list in case they become significant again. If the risks occur, we also need the document to recheck our original thinking. Trends. For example, we may notice that exchange rates are changing and could affect our project, even to the point of cancellation.

11.4

Perform Quantitative Risk Analysis Analogy: Once the project manager has discovered that rain might make the concrete dry a week later; he calculates how much this delay will cost. Pitfalls: Underestimating costs, forgetting indirect costs.

This process is similar to the previous one, except the emphasis here is on numerical or quantitative estimates of risk impact. One way to think of this is that with limited effort, the Qualitative Analysis (the last section) gives us a short list of important risks to consider, plus a list of risks to watch, sometimes called a watch list. The process in this section, which takes more effort, is then applied to the results of the qualitative analysis. This reduces wasted detailed effort on risks that are relatively unimportant. We will not repeat the descriptions of the Inputs which we recognize as Outputs of other processes. They contain numeric, quantitative data and are: l l

Cost Management Plan Schedule Management Plan. Nor will we repeat the description of the Tool and Technique which is in both processes: Expert Judgment. We now need to consider the two remaining Tools and Techniques:

l l

Data Gathering and Representation Techniques Quantitative Risk Analysis and Modeling Techniques.

The Data Gathering and Representation Techniques are also relevant in Quality Management.

172


Interviewing was also discussed under the process Identify Risks and the approach is the same: find out who we should talk to, plan what to ask them, meet and discuss, then document and analyze the results. An example of a quantitative application is the estimation of durations using the Three-Point Method (optimistic, pessimistic, most likely). Some years ago in Waterford, Ireland, the main bridge over the River Suir was being replaced. The bridge span was brought up the river on the high tide to make the installation easier. Unfortunately it fell into the river. The team had to wait another month (which was the pessimistic estimate) for the next spring (high) tide to install the span. The experience of the person being interviewed can be used to review the duration estimates. This should improve the data quality and also the validity of the Risk Analysis. A possible table format to use when interviewing about cost estimates is shown in Fig. 11-13. Under Quality Management we already discussed the Normal Distribution. It can also be used here to portray the probabilities of different project durations. In reality, this is not always the most appropriate representation. Many of us will suspect that the chances of bad luck are greater than those of good luck in project management. Informally, this is called Murphy’s Law: what can go wrong, will go wrong. This term is NOT in the PMP® examination! An example why the distribution of duration estimates is not symmetric could be a project has been planned for the shortest possible duration. There may be little possibility for improving the plan but there are many ways in which something can go wrong. The so-called Beta and Triangular distributions are shown in Fig. 11-14. They are both asymmetric, that is not symmetric, or having different shapes on each side of the mean. These can be used instead of the normal distribution to represent risk probabilities. I was flying from Ireland to Switzerland when there was a record rain storm. The train to Dublin, Ireland, was derailed so we had to go by bus. The bus, however, had to drive around the flooded region and arrived much later than the train timetable. I missed the airplane and had to pay both for a new ticket and for overnight costs in a hotel. What was the sensitivity of my total journey cost to the arrival time in Dublin? Actually it is very high. For the optimistic estimate, I would have arrived in time for the flight and would not have had extra hotel costs. The pessimistic estimate of the total journey cost would also cover a new ticket and a hotel stay. The optimistic and pessimistic risk probabilities were not symmetric.

11.4 Perform Quantitative Risk Analysis

173

The other Tool and Technique has a long name: Quantitative Risk Analysis and Modeling Techniques. Three corresponding techniques are described: Sensitivity Analysis means working out how sensitively one result depends on another. Expected Monetary Value, EMV analysis applies probability to the cost of the risks. Taking the travel example above, if the probability of missing the flight is 15% and the cost of missing the flight was 600, then expected monetary value is: 15% of 600 ¼ 90: This is not 90 cash in the bank, but a reserve based on the combination of the probability and impact of a risk. Of course some risks are positive: I may get a delivery of project materials cheaper than I expected so the EMV is then in our favor. We can then add up all these positive and negative money values, giving an overall expected value of all the risks for the project. It is then sensible to include this total amount for risks in the budget. In practice, it is unlikely that we will need this exact amount, but it is less risky than having no budget. This idea is applied to circumstances where there is a chain of possible outcomes (for example, the bus arrives on time or late), each with an expected money value. By displaying the expected values of the entire project on a chart, it can help decide which project option is cheaper. This description is called a Decision Tree, because it displays the results of various possible decisions on a tree-like diagram. Figure 11-15 shows an example. The last technique here is Modeling and Simulation. The decision tree shows the expected values for one combination of the parameters. If a project is really expensive, then more thorough estimates are needed. For example, building a new railway, we need an accurate estimate of when the trains will be full, depending on various different designs of track, signaling and stations. We may have usable data from other projects but it is more likely that we will need to model the traffic and corresponding costs. One way to do this is to take the decision tree and calculate the expected costs of the project for one possible combination of decisions. The simulation software then repeats the calculation for hundreds of other possible combinations. For each one, the overall project cost is graphed on a histogram from which we can see what the optimistic and pessimistic estimates are, as well as the shape of the distribution. The various combinations are generated so that they are statistically random. Because of this, the method is called Monte Carlo, which is known for casinos and where the winnings are also statistically random. An example of where this is used is the locating of mobile telephone antennas. The various costs of different options are analyzed, based on their coverage area. One location may give good coverage to a nearby town but also result in poor coverage in the mountain valley in the region, so an extra antenna will be required.

174


The Outputs of both this and the previous process have the same name: Risk Register Updates. Naturally the detail of the updates is different but the idea is the same: improve the quality of the information and record it.

11.5

Plan Risk Responses Analogy: The project manager then works out contingency plans; one for wet weather when the concrete takes a week longer to dry, the other for very hot weather when the concrete dries faster than planned. Pitfalls: Not defining risk owner, wrong risk strategy. Risk Responses are the specific steps specified in response to the risk analysis of the previous processes. The Inputs are the Risk Register and the Risk Management Plan. Since they are already familiar, they are not described again in detail here. The Tools and Techniques include Expert Judgment, which uses three categories of Risk Response:

l l l

Strategies for Negative Risks or Threats Strategies for Positive Risks or Opportunities Contingent Response Strategies.

This last category means the pre-planned strategies we will use if the risk actually happens. Another way of saying this is that the response is already available in reserve if the risk occurs. EMV (expected monetary value) is tradedoff against immediate expenditure. For example: IF l l l

The train is derailed And if the replacement bus is diverted and arrives late And I miss the flight THEN

l l

I will use my credit card to pay for a hotel and new flight ticket And claim the money from the insurance.

If the risk does not occur, I do nothing. My contingent response strategy is to bring my credit card with me to pay for the hotel and new ticket. In calculating the EMV, the cost of the insurance and the value of my lost time should also be included. Because risks can be either negative or positive, the remaining Tools and Techniques have two sets of approach.

11.5 Plan Risk Responses

175

Strategies for Negative Risks will reduce the expected monetary value (EMV) of significant risks, by addressing either the probability, or the impact (or both): l

l

l

Accept: This is not “just doing nothing” but “deciding not to act and documenting the reasons”. Avoid: For example, I do not want to be involved in an air crash, so I decide to travel by train. Here we need to add significant new activities and resources to the project plan, remembering that they may generate even more new risks. For example, I decide to travel by train to Moscow but it takes 3 days from where I live. This means that my overnight costs will increase and there is a risk that the travel budget will be overspent. Mitigate: This word means reduce: either the impact or probability. For example I could reduce the risk of missing the plane by taking an earlier train to the airport. Low-cost airlines only fly you from one place to another; no transfers, but the tickets are cheap. Sometimes the transfer airport is so busy with the security check that you risk missing an on-going connection. Some people minimize the EMV in this situation by booking two onward flights at different times, then only using one ticket. This is cheaper than missing the flight, getting a new ticket and staying overnight at the hotel.

l

Transfer: Give the risk ownership to someone else. Classic examples of transferring the ownership of risk are insurance, guarantees and similar contract methods. If my new camera fails in the first year, the cost of repair is paid for by the manufacturer. This does not change the risk of failure but reduces the EMV for the buyer, so making it more attractive to buy this brand.

These four methods are reflected by four Strategies for Positive Risks or opportunities, which increase the EMV: l l

l

l

Accept: the issues here are the same as above. Enhance: this is the opposite of mitigate and means “make the risk more likely or increase the value”. Share: this is the opposite of transfer because it means bringing others in so that together the positive result is easier to achieve. An example from business is the sale of company shares, so that the risk is spread. Exploit: the opposite of avoid. Instead of making sure something does not happen, we do everything to make sure that it does happen! One way of selecting risk responses is to categorize them as follows:

l

High risk, high impact: Add the risk responses to the project plan.

176 l l


At least medium impact and probability: prepare Contingent Risk Strategies. Low impact and/or probability: Keep on a watch list in case circumstances change and they become more significant.

The Risk Responses consist of activities which affect the cost and time estimates, and therefore other project risks. This means that we should recheck the entire project plan and risk catalog again after adding the risk responses. This cycle is repeated until the plan is consistent and stable. Risk Responses can themselves have side effects that create new risks! These are called secondary risks. An example of this occurred in the building of the Concorde supersonic airliner, for which planning by France and Britain began in 1956. Unfortunately it was found that the engines were not as fuel efficient as planned. This meant that larger fuel tanks were needed. To compensate for the extra weight, fewer passenger seats were possible. This meant that the passenger fares had to be higher. Unfortunately this reduced the market and the orders from other countries either never came in or were cancelled. Eventually the airplane was a technical success but a business failure as only 20 were built. The Outputs include: l l l

Risk Register Updates Project Management Plan Updates Project Document Updates.

We already recognize these Outputs and the only one needing to be explained here is: Risk-Related Contract Decisions. To understand why contracts are relevant, consider an example project to build an office block. There is a risk that the site will be disturbed at night so it is natural to close it up at night and appoint a security company. If something important goes wrong during the night, for example flooding due to heavy rain, the project management team needs to know it immediately. It is therefore written into the contract that the night guard must notify a contact person immediately if a risk occurs. This is a contract decision which came from a risk-related issue. Many other examples are possible, particularly in the area of insurance, which is a contract to transfer responsibility for risk impacts.

11.6 Monitor and Control Risks

11.6

177

Monitor and Control Risks Analogy: The weather forecast predicts storms during the building period, so the project manager has to revise his risk assessment of the concrete drying. Pitfalls: Changes are not properly assessed for risk, changes in risks not identified. This process is a natural closure to this knowledge area. The Inputs have all been described earlier and are listed here for reference:

l l l l

Risk Register Project Management Plan Work Performance Information Performance Reports. There are several Tools and Techniques, which are now described:

l

l

l

l

l

l

Risk Reassessment: Anything about risks can change during a project, for example a probability can change or a new risk can appear. The reassessment should be carried out with the same thoroughness as the original risk analysis. It should also be scheduled to ensure that it happens. Risk Audits: We already discussed the power of audits in connection with Quality Management in Chap. 8. They are a particularly important feature of Risk Management. They are even a legal requirement in the European Union for identifying Health and Safety risks in the workplace. Remember again the important features: independence of the auditors and documentation of the results. Variance and Trend Analysis: These methods were also discussed earlier under Quality Management. Here, this means looking into the feature and estimating whether a risk is more or less likely to occur based on the baseline and our experience up till now. Technical Performance Measurement: Another topic that was discussed under Quality Management, again with a view to the effect on risks. This is illustrated by the technical performance of the Concorde aircraft engines, as described in the previous section. These needed more fuel than expected and this affected the business risks. Reserve Analysis: This method for analyzing the reserves of time, money etc. was already mentioned under Cost Management. Here we want to compare the resource reserves, or buffer, with what is actually happening. If the reserves are becoming increasingly small, then the risks to completion of the project are increasing and we may need to take action. Status Meetings: This means meetings that specifically review the entire risk situation should be scheduled regularly. If this is not done, then risk management is in danger of being forgotten.

178


As this process is in the Monitoring and Controlling Process Group, we expect several Outputs. These are mostly updates, change requests and the like which arise during the execution of the project. Again, they should already be familiar and are merely listed here: l l l l l

Risk Register Updates Organizational Process Assets Updates Change Requests Project Management Plan Updates Project Document Updates.

11.7

Exam Aids

Process Summaries 11.1 Plan Risk Management: Determines how project risks are to be managed. 11.2 Identify Risks: Explores the various aspects of the project in depth to find out what risks are possible and documents them concisely. 11.3 Perform Qualitative Risk Analysis: Estimates the probability and impact of each risk identified and produces a ranking for further analysis. 11.4 Perform Quantitative Risk Analysis: Carries out a more precise assessment of the potential impact of the higher priority risks. 11.5 Plan Risk Responses: Generates and selects options to optimize the potential effect of selected risks, whether positive or negative, to the benefit of the project. 11.6 Monitor and Control Risks: Maintains a watch on existing and new risks, while implementing the risk responses to ensure that the project achieves its maximum potential.

Flash Card Terms Accept Activity Cost Estimates Activity Duration Estimates Assumptions Analysis Avoid Brainstorming Change Requests Checklist Analysis Contingent Response Strategies Cost Management Plan Data Gathering and Representation Techniques

Decision Tree Delphi Technique Diagramming Techniques Documentation Reviews Enhance Enterprise Environmental Factors Expected Monetary Value, EMV Expert Judgment Exploit Fishbone Diagram Identify Risks Impact

11.7 Exam Aids Information Gathering Techniques Interviewing Ishikawa Issue Log Mitigate Modeling and Simulation Monitor and Control Risks Normal Distribution Organizational Process Assets Organizational Process Assets Updates Perform Qualitative Risk Analysis Perform Quantitative Risk Analysis Performance Reports Plan Risk Management Plan Risk Responses Planning Meetings and Analysis Planning Process Group Probability Project Document Updates Project Documents Project Management Plan Project Management Plan Updates Project Risk Management Project Scope Statement Quality Management Plan Quantitative Risk Analysis and Modeling Techniques Reserve Analysis Risk Audits Risk Breakdown Structure

179 Risk Categories Risk Categorization Risk Data Quality Assessment Risk Management Risk Management Plan Risk Probability and Impact Assessment Risk Reassessment Risk Register Risk Register Updates Risk Response Risk Tolerance Risk Urgency Assessment Risk-Related Contract Decisions Root Cause Analysis Schedule Management Plan Scope Baseline Sensitivity Analysis Share Stakeholder Register Status Meetings Steering Committee Strategies for Negative Risks Strategies for Positive Risks SWOT Analysis Technical Performance Measurement Three-Point Method Transfer Trends Variance and Trend Analysis Work Performance Information

Chapter 12

Procurement Management Processes


l

l

l

l

Procurement is an important way of implementing projects and subprojects. It is usually associated with costs, which can be very large and have a big influence on the schedule. For these reasons, it must be done efficiently. Procurement requires a different type of relationship than that within a project team. The first process is Plan Procurements, where the decision is taken whether certain parts of a project will be implemented internally or externally: the Make or Buy Decision. The process of communicating requirements, getting offers, selecting providers and signing contracts is called Conduct Procurements. The selection criteria must be defined before seeking offers. Administer Procurements is the process which monitors the contract itself, such as payments and review meetings. The actual work is covered by other processes. This is the only knowledge area, except Project Integration Management, which has a procedure in the Closing Process.

Project Procurement Management Analogy: Normally you need external contractors to help build a house. You have to hire plumbers, painters etc. and ensure that they do a proper job within budget and schedule. Pitfalls: Bad procurement has negative effects on quality, budget and schedule. Procurement is that part of project management where we get products or services from outside the project team. The word “get” includes various methods ´ Conchuír, Overview of the PMBOK® Guide, D. O DOI 10.1007/978-3-642-11188-4_12, # Springer-Verlag Berlin Heidelberg 2010

181

182

12 Procurement Management Processes

such as buying, renting etc. It is always managed by a contract, is subject to change control and requires administration. Procurement is important for project managers as their job is to achieve the project objectives with whatever resources they can find. It is often (but not always) necessary to use outside services to do this. This can also be done within the same company. The arrangements between different units or departments can be managed by service level agreements, which are similar in many ways to procurement contracts. This knowledge area uses abbreviations and symbols freely, which can make learning particularly demanding. In addition, this knowledge area naturally reflects the American legal environment, both in the PMBOK® Guide itself and the examinations. In the USA, the basic principles of law are based on a model which was inherited from British practice. This is also true in countries such as Australia and India. On the other hand, in countries such as France, the legal principles were and are strongly influenced by Napoleón Bonaparte in the early nineteenth century. Other countries where Napoleón’s influence is still felt today include Belgium and Switzerland. Large projects are rarely possible without extensive use of procurement, so it is an essential part of project management. The sums of money involved, liability issues and the contract methods used are sufficiently different from the management of internal work packages that it deserves its own knowledge area. It is therefore not surprising that it is the only Knowledge Area except Integration Management to have its own closing process. Of all the knowledge areas, the procurement management processes have the largest number of Inputs; 11 for Plan Procurements. Deciding whether procurement is necessary and defining the deliverables to be procured means collecting large amounts of background information. For a contract to be valid, there must be the product or service supplied in one direction and the “consideration” in the other. This special word means that the seller gets something of value, usually money. Contract payment by barter is also possible. During the cold war, Ireland’s main airport for the Atlantic Crossing at Shannon was a refueling location for the Soviet airline Aeroflot, en route from Moscow to South America. At that time, the Soviets had limited hard currency so they paid their landing fees in fuel. As a result, about 20% of the Irish national fuel stock at the time came from the Soviet Union. Procurement contracts do not just specify what is to be delivered. They also specify items such as how often communication will take place and what the payment procedures are. Except for very small contracts, they will almost certainly

12.1 Plan Procurements

183

be negotiated by a procurement organization which has experience at getting good prices and conditions. These resources support the project manager in executing procurement. With competent management, procurement can also reduce risks as the suppliers are usually experts in their field. For example, imagine that you are moving house and that you have a heavy piano. By procuring services from moving experts, you get the following advantages: l l

l

Allows you to plan dates reliably. Reduces the danger of damage to the walls, piano and your own back due to the weight of the piano. Costs less than hiring a van, taking time off work and repairing any potential damage.

Even in organizations where there is a tradition of doing everything internally, the potential advantages of procurement are still significant. For bigger contracts there may be several relationship levels with the supplier, from CEO level downwards. For example, the CEOs will meet each other from time to time to evaluate the cooperation. Senior managers on both sides will then meet to agree on priorities. Within this framework, those responsible for delivering (on one side) and receiving (on the other side) will have close relationships. These various roles working together will help reduce project risks.

12.1

Plan Procurements

Analogy: After careful consideration, you decide to engage an external company to do the plumbing. You have to decide how to find the right plumbers and what the right contract type (fixed price, time and material, etc.) is. Pitfalls: Incomplete or inadequate Statement of Work (SOW), wrong decision criterion, underestimated risks or risks for which there is no Risk Response. Procurement management starts naturally with planning. External sourcing by procurement may or may not be the right way forward and this needs to be clarified before starting procurement. For example, a company may decide to do confidential work internally, even though it would be cheaper, but less private, to outsource it. The planning also covers issues such as when the product or service is needed, what type of organization they would like to contract etc. The use of procurement will also have a major effect on the schedule. Let us start by looking at the Inputs, nearly all of which are familiar to us: l l

Scope Baseline: Scope statement and WBS Requirements Documentation

184 l l l l l l


Risk Register Risk-Related Contract Decisions Activity Resource Requirements Project Schedule Activity Cost Estimates Cost Performance Baseline.

The titles of the next two Inputs are familiar, but need to be interpreted in the context of procurement: l

l

Enterprise Environmental Factors, such as availability of suitable suppliers in the marketplace. Organizational Process Assets, with particular reference to procurement processes and practice. The one Input which is new to us and needs to be explained is:

l

Teaming Agreements.

This is a general name which covers a variety of legal forms, such as partnerships and joint ventures. For big ventures (relative to the capabilities of the participating companies), forming teams is a good way of being able to address bigger opportunities. This is an example of Sharing, as described in the chapter on Risk Management. Such agreements affect not only schedule, cost and risk but also issues such as roles and whose practices will be used. All this takes effort to work out and must therefore be part of the procurement planning. This can be strongly supported by a competent design of the WBS. Now we are ready to look at the Tools and Techniques, of which the Make or Buy Analysis is the first. This is the decision whether to source products or services within or outside the project team. There are many parameters which can influence this decision, although cost is a major factor. We might think that external procurement would always cost more, but a closer examination shows that this is not necessarily true: l

l

l

l

Reliability: The providers are normally experts in their field. This means that they can be expected to be very efficient both in their methods and in their costs. The result can be even cheaper than the cost of doing it ourselves. Opportunity Cost means “what does it cost me to do one thing instead of another.” It might be cheaper to provide a particular deliverable internally, but the people are then unavailable for other (maybe more profitable) work. This alternative work may have a higher value. This is why senior mangers delegate to assistants. In their position, their work has a big impact, so their impact will be reduced if they do not delegate. Quality: In the example mentioned above, the moving company which has all the equipment is less likely to damage heavy furniture, such as a piano. Availability or Production Capacity: It is possible that we do not have the free capacity to provide the deliverable internally. It is also possible that an external company has so much capacity that they offer it at a low price.

12.1 Plan Procurements l

185

Confidentiality: When work goes outside the team, the confidentiality can be at risk. This can have legal and commercial consequences, for example for patent applications. In such cases it can be safer to do the work internally.

Expert Judgment is the next Tool and Technique and certainly needed in Procurement. This is why it is often a company requirement that procurement may only be carried out by a single department specializing in this activity. However, as project managers, we are still ultimately responsible for making sure that the procurement department staff understand the requirements. The next Tool and Technique considers different contract types. Before looking at them, we will review why different contract types matter. After we have done that, we will look at the actual types and their abbreviations, which you will need to know for the PMP® examination. Imagine that you are a house painter and you offer to paint somebody’s living room. You tell the customer: l

“I want to make it as cheap as possible for you. You will pay me for the paint I buy and then I will charge you 40 an hour for my labor.”

If the customer agrees, he probably hopes to get a cheap job, because your 40 an hour is cheaper than other offers. But who takes the risk? l

l

l

If you finish early you get paid and also have more time left over to make more money on the next job. If you finish late you get paid anyway and it costs the customer more. To avoid this he may spend some time on site supervising your work. And Time is Money. The customer always pays for the paint, so you never lose here.

In summary, you as the seller have no risk. You can only win! A lot of professionals work like this with so-called Time and Material, T&M contracts. Businesses where this is common include lawyers, repair services, house painters etc. An example concerned the family, who built the concrete foundations of their new house in Switzerland. They also imported the wooden frame from Que´bec, Canada, to reduce costs. The contract also included a Time and Materials element, under which the carpenters from the suppliers would also assemble the wooden frame. The carpenters took a month longer than planned, which the customer had to pay for because of the T&M contract. It was said that the carpenters enjoyed the trip to a country where their own language (French) was spoken and regarded the work as paid holidays. . . Does a T&M contract ever make sense for the buyer? It can when: l l l

The work is small and not very well defined. When the supplier is reliable and well known to the project team. The customer is prepared to spend some time supervising the work.

186


Another type of contract exists if the customer says: l

“No, I will pay you one total amount, which I will pay at the end when the work is completed.”

Who takes the risk of delivering without getting paid? In this case it is the seller. The buyer may wait until the end and ask for small additions without paying for them. This puts the seller under pressure if he needs the money. The buyer also takes a risk that the seller may cut corners to keep his costs low. The seller takes the risk of non-payment, because he will still earn a satisfactory amount, even if his costs are higher than expected due to unforeseen events. The buyer is happy because he does not need to find the time to supervise the work. This is done using the payments. This is a Firm Fixed Price, FFP contract and is similar to the way you pay in restaurants. These two extremes show that you can change who takes the risk by changing the contract type. This is really the point to notice in connection with the next several contract types. It is therefore important to select the contract types according to the uncertainty or risk you are willing to accept. There are different ways of changing the risk: l

l

l

The buyer pays part of the cost when some stage of the work is completed (stage payments). There is a limit above which the seller assumes (takes over) any additional risks. The amount of money at which this takes place is called the “point of assumption.” The seller gets a fixed price as well as a proportion, say 20%, of cost savings, achieved by managing the project costs well. This can work the other way too, as a penalty. Penalties can be payable for late deliveries or problems with the work delivered.

Elements of the different types of contracts can be combined, but keep in mind that in some regions, certain types of contract may be illegal. This is one more reason to involve experts from dedicated procurement departments during contract negotiation with external providers. In ascending order of risk for the buyer, the contract types described in Sect. 12.1.2 include: l l

FFP: Firm Fixed Price. FPIF: Fixed Price Incentive Fee. The incentive is a bonus paid to the supplier depending on meeting targets of time, cost etc. It is often a fixed percentage of the cost saving or over-run. A project manager builds shopping centers in Ireland and his customers usually have a grand opening around a public holiday. These dates are selected because the maximum number of shoppers is free to go shopping. The sponsors are happy to pay a bonus for meeting this date.

12.1 Plan Procurements l

l

187

FP-EPA: Fixed Price with Economic Price Adjustment. This suits long term contracts when the cost assumptions are expected to change. For example there is inflation or currency exchange rate fluctuation. These contracts allow a realignment of costs after a predefined period. CPFF, CPIF, and CPAF: These are yet more contract types. I suggest that during the first reading you focus on understanding the overall procurement approach. You can then study these additional contract types later. They are: – CPFF is Cost Plus Fixed Fee. The fee is for finishing the work and is not related to performance. – CPIF is Cost Plus Incentive Fee. Costs are paid as well as a fee that depends on performance. – CPAF is Cost Plus Award Fee. The fee awarded depends on how well the buyer thinks the seller has performed.

Having considered the Tools and Techniques, we now move to the Outputs. The first one is, of course, the Procurement Management Plan. The more procurement practice is well defined in your organization, the less detail you needed in the procurement plan. Points to consider might include the following: l l

l

l

What sort of contracts should be used? How much can the project management team do themselves before involving the procurement organization? Risks: for example, how stable are the suggested supplier companies? Going bankrupt during a contract causes major problems. Whether procurement activities will be combined with other projects, for example to get better prices.

Here, we meet the expression Make or Buy Decision. This means “should we produce the deliverable within the project team or get it from somewhere else?” This terminology is used irrespective of whether the deliverable is a product or service. This is an important decision, because without it no procurement takes place. This means that the planning should include objective rules about when to “make” and when to “buy.” Even when there is no preference for source selection, the deciding factors should be determined before deciding who will do the work. These are called the Source Selection Criteria and are an Output of this process. Unless properly managed, procurement can sometimes be influenced quite strongly by personal issues. For example, not wanting to use products from somewhere else is called “NIH” – which means “not invented here.” This means that managers prefer to “reinvent the wheel” instead of procuring products and services. The reasons can be personal and not related to the strict business need, for example to extend influence, increase status and maybe even an increase in salary. In another scenario, the manager wants to give the work to his brother or a politician who owns a supplier company. Often, purchasing decisions are made

188


based on relationships or preexisting contacts. This can be legitimate for business relationships, but only if they are transparent. Conflicts of interests may be so large that they become criminally relevant. Some years ago the Informatics Department of a Swiss university needed to replace a computer system. The purchasing manager, however, procured the system through a company that he owned. Because this company received commissions from the hardware supplier, he benefited directly from the actions in the name of his employer. He was later sentenced to 3 months in jail. The WTO (World Trade Organization) “deals with the rules of trade between nations at a global or near-global level”. Public institutions have a higher transparency requirement for acquisitions and usually use procurement processes that conform to the WTO standards. It is legitimate to have a preferred suppliers list based on previous evaluation of the potential suppliers. Suppliers may provide special conditions for bulk orders or have a special service for preferred customers. As long as the relation is transparent and within the law, there is no problem. The PMI® Code of Ethics and Professional Conduct (see Chap. 13 of this book) stipulates that the Project Manager must avoid any conflict of interests, or, if unavoidable, maintain transparency. Source Selection Criteria means the criteria to be used to select suppliers. They may include: technical competence, business approach, time in business, certifications, risk, Intellectual Property (IP) rights etc. Even the interest of the supplier can be a factor because if they do not really want the work, they may not do a very good job. This can happen if a supplier is overloaded or wants to focus on another area. If there are Teaming Agreements, then different formats will be available for the SOW. The selected format must be stated in the plan. It should also give enough detail about the expected deliverables that potential suppliers can decide if they can or want to make an offer (bid). Although timing can be included, the emphasis is on the content. The SOW must be written in very clear style, otherwise there is a risk of not getting what was intended. It is recommended that the SOW should completely cover one or more Work Packages, but never a partial Work Package. The Output Procurement Documents from this process is a dossier that is used to inform and invite offers from potential suppliers, or bidders. The words “tender” and “quotation” are also common variations of “offer.” In the interests of fairness, this dossier should be complete, readable and made available to all bidders under identical conditions. The level of detail depends on the level of risk: “as little as possible; as much as necessary.”

12.2 Conduct Procurements

189

Candidates around the world sitting for the PMP® examination need to remember several abbreviations in this section for different types of communication with suppliers, especially those common in US practice. For example: l

l

l

l

Request for Information, RFI; asking interested companies to tell us about themselves and their interest, without providing full offer documentation. Invitation for Bid, IFB, in other words a sign to bidders that we would like to receive an offer. Request for Proposal, RFP implies that we would like the supplier to suggest how to address the task. They may have special expertise or equipment which we would like them to present. Request for Quotation, RFQ implies that we are mainly interested in the price, for example of commodities.

This terminology is not absolutely fixed and there are more abbreviations later. The last Output is any Change Requests to the project management plan that arise while detailing the products and services to be procured.

12.2

Conduct Procurements Analogy: To select the right plumber, you have to get the necessary background information, e.g., calling up references and comparing prices. Once selected, you have to work out a contract with the chosen plumber. Pitfalls: Wrong proposal process (e.g., public contracts have to be WTO conform), wrongly weighted selection criterion (focus on costs instead of quality), taking unfair advantage during negotiations.

After procurement planning has been completed, we can move to the next step. For much of the PMBOK® Guide, the order of use of the processes is flexible and iterative. Here it is not. The documents are the tool which you use to tell bidders or suppliers what you expect them to include in their offer. To be fair, they must all get the same information. For public contracts, this is usually a legal requirement too. Procurement is potentially a detailed process, so we expect several Inputs to give as full a picture as possible: l l l l

Project Management Plan Procurement Documents Source Selection Criteria Qualified Seller List. This often comes from the procurement department, although the project team may be able to influence which suppliers are considered for selection.

190 l

l l l

l


Seller Proposals. These are the offers in response to the Procurement Documents. For transparency reasons these should be received under identical conditions for all bidders. Project Documents Make or Buy Decisions, together with the reasons for making or buying. Teaming Agreements. Each partner may have their own guidelines for procurement. Organizational Process Assets, with particular reference to procurement, of course.

Next we review the Tools and Techniques. A basic principle of procurement is transparency, so that every bidder has an equal chance to bid and win the contract. One way of supporting this is to organize Bidder Conferences. These events allow suppliers to check their understanding of what is requested. Of course, suppliers also like to see who else is bidding. As a result, they may be careful not to communicate their position or interest publicly. A variation of this is to ask for questions in writing and return the consolidated answers to all bidders, without saying which supplier asked which question. This is less transparent for the suppliers as they do not know who the competition is, but is nevertheless quite common. Even if the questioning is done in public, it is important to make sure that everybody hears both the questions and the answers, not just the answers. This means that the moderator of the event may need to repeat questions, if the speaker was not easy to hear. The Proposal Evaluation Techniques define how the proposals will be evaluated. A spectacular example of Proposal Evaluation Techniques was the bid processing in the auction for third generation UK mobile telephone operators’ licenses in the 1990s. Each round of bids was planned to take less than an hour. Bidders could pass (refuse to bid) three times before falling out of the process. The amount of all the bids and offers was published on the internet. The auction was extremely successful and raised £22.5 billion. In comparison, previous similar auctions in the USA raised less than 1% of the expected amount, apparently because of collusion between bidders. This dramatic comparison highlights the importance of using effective procurement processes. Independent Estimates can also be used to check the plausibility of offers. A mobile telephone network supplier tendered an installation project, for which one supplier’s quotation seemed to be far too cheap. It turned out that this company was using black market labor and uninsured vehicles.

12.2 Conduct Procurements

191

Expert Judgment is, as always, worth applying when contracting the procurements. Advertising, for example, in publications which potential bidders are likely to read, is also a useful Tool and Technique. This allows new suppliers to get involved and also increases the pressure on existing suppliers who think that they have the market to themselves. Competition is great for getting the best deal. Similarly, searching the internet for possible products and providers helps make good procurement decisions. Of course all these Tools and Techniques support the purpose of the Procurement Negotiations. Negotiation has already been mentioned in Chap. 9 as a key skill for project managers. In Procurement it can make all the difference to success. Finally, we examine the Outputs, of which the Selected Sellers is clearly the main one. It is based on the Source Selection Criteria. The Procurement Contract Award is the finalized contract for successful bidders. There may be several contracts, either because different parts are to be supplied by different bidders or because the contract is shared by several suppliers. This reduces the dependency on one supplier if something goes wrong. At some stage during the process, the unsuccessful bidders will be informed and the successful sellers will negotiate draft contracts, which will be forwarded for approval by the sponsors. A contract is mutually binding: both sides are required to respect what is agreed and defined. The level of detail depends on the situation, but it can include a wide variety of clauses such as: l l l l l l l l l l

SOW. Costs. Phasing of payments. Who the contact people are on each side. The project manager. How the parties will communicate. Where the deliveries will take place. The criteria for accepting the deliverables. Follow up support and guarantee conditions. Change control processes.

Resource Calendars are also a deliverable. They document when important resources (key people, access to the project delivery site, expensive equipment etc.) will be available. Change Requests may be the result of contractual negotiations and they are therefore a process Output. Their acceptance depends on the Change Control Board, CCB. The last two Outputs are the Project Management Plan Updates and the Project Document Updates, which are familiar to us, so are not described here.

192

12.3


Administer Procurements Analogy: Once the plumber has started work, the foreman and customer have to check the state of work regularly and approve partial payments when milestones (e.g., kitchen sink installed) are reached. Pitfalls: Performance reporting frequency not suitable (too often – too much administrative work, too few – problems discovered too late), approving payment even though milestones not completed.

The description of the procurement procedures is in some ways similar to those for Human Resource Management. For example, the actual work is monitored and controlled by the other processes. The Administer Procurements process focuses more on the framework within which the work is done, for example on briefing meetings and payments. As before, there are several Inputs, all of which are familiar to us and do not need to be described again. They are: l l l l l l

Procurement Documents Project Management Plan Contract, that is the contract for the procurement Performance Reports Approved Change Requests Work Performance Information. The Tools and Techniques which generate these Outputs are:

l

l

l

l

l

Contract Change Control System: this may not be the same as the in-house system because more than one company is involved in procurement, each with its own processes. Procurement Performance Reviews, in other words a way of finding out what the supplier is achieving. This can be a meeting but also such items as on-site audits, inspections of deliverables etc. Inspections and Audits, Performance Reporting: integrated with the reviews mentioned above. Payment Systems: the supplier will naturally wish to get paid on time and so there must be transparent ways of authorizing and tracking payments. Few things annoy suppliers more than a feeling that they are not getting good treatment in this area. Claims Administration: a claim occurs when there is no agreement to whether a change has actually been implemented or when there is a dispute about the compensation for a change. An example may be that an activity took more time to complete and the supplier billed a larger invoice than originally estimated. Review of such situations should be handled by a separate process, so that everyone feels that they are treated fairly.

12.4 Close Procurements l

193

Records Management System: details, such as who keeps the documents and where, who has access to what and similar, need to be defined. This can also become unexpectedly important if legal questions arise later. Good document management is not a luxury – it is essential. The Outputs match our expectations for a process in the Monitoring and Controlling process group and include:

l

l

l

l

Procurement Documentation of all sorts. Although a small project managed by an experienced project manager can be done with little documentation, procurement must be documented, partly because it takes place in the context of a legal contract. Organizational Process Assets Updates, particularly of processes that relate to the procurement or its deliverables such as: – Correspondence – Payment schedules and request for payment – Seller performance evaluation documentation. This can be used to adjust rankings on preferred supplier lists to the benefit of future projects. They can also be used to calculate bonuses or even to expel a poor supplier. Change Requests. Be sure to distinguish between changes due to unforeseen circumstances (material damaged during transport, for example) and Changes of Mind by the client. Both should be evaluated through the Change Control Process but changes of mind should be invoiced and paid for by the people who change their mind! Project Management Plan Updates.

12.4

Close Procurements Analogy: Once the plumbing is completed and passed inspection, an acceptance certificate is signed and the last payment approved. Pitfalls: Closing the contract despite open issues, claims etc., not archiving all relevant documents.

This process is special – it is the only closure process which is not in the Integration Management Knowledge Area. Project managers know that orderly closure often gets lost in the excitement of the next challenge. This means that we miss an opportunity to capture the learning and tidy up, so that other projects can get the maximum benefit from the experience of the current project. This process is a reminder to close projects in an orderly way. As we are coming to the end of the book and much has already been described, so the description here is not complicated. The Inputs are: l l

Project Management Plan Procurement Documentation

194


The Tools and Techniques also include one item that is recognized from before: Records Management System. The other two Tools and Techniques are: l

l

Procurement Audits: because procurements can involve large sums of money and more than one company, audits of how procurements were handled help keep everyone honest. Negotiated Settlements: these allow outstanding issues to be resolved as it is in nobody’s interest to proceed without all sides being satisfied. After all, you will probably be working with the same suppliers or customers again. Using this Tool and Technique helps to make sure that no unfinished business causes problems for future working relationships. For the last time, the Outputs include:

l l

Organizational Process Assets Updates Closed Procurements.

This second Output simply asks: “have the procurements been closed?” If the project manager is already involved in the next exciting project, the responsibility for this Output can become unclear. The terms for completion should be clearly stated in the contract, so that closing the project is as simple as noting that all the deliverables have been delivered. In particular, the Deliverable Acceptance should be absolutely clear and in writing. This allows the supplier to invoice the remaining amount while the project team still exists and is able to resolve any issues without too much trouble. Lessons Learned Documentation should be prepared and consolidated with other documents from the entire project. It is reasonable to prepare this in association with the suppliers and also to make sure that any recommendations are actually implemented.

12.5

Exam Aids

Process Summaries 12.1 Plan Procurements: Decides the approach to be taken for the purchase of services and product to achieve the project objectives. Finds out who could supply the purchases. 12.2 Conduct Procurements: Shares information with potential suppliers, reviews their proposals and contracts those selected. 12.3 Administer Procurements: Manages the interactions between the purchaser and supplier. Checks the contract performance and makes whatever changes are needed to meet the project objectives. 12.4 Close Procurements: Ensures that all procurement activities are closed, to the satisfaction of both contracting parties.

12.5 Exam Aids

195

Flash Card Terms Activity Cost Estimates Activity Resource Requirements Administer Procurements Advertising Approved Change Requests Bidder Conferences Change Control Board, CCB Change Requests Claims Administration Close Procurements Close Project or Phase Closed Procurements Conduct Procurements Confidentiality Contract Contract Change Control System Cost Plus Award Fee, CPAF Cost Plus Fixed Fee, CPFF Cost Plus Incentive Fee, CPIF Deliverable Acceptance Enterprise Environmental Factors Expert Judgment Firm Fixed Price, FFP Fixed Price Incentive Fee, FPIF Fixed Price with Economic Price Adjustment, FP-EPA Inspections and Audits Invitation for Bid, IFB Lessons Learned Documentation Make or Buy Analysis Make or Buy Decisions Negotiated Settlements Opportunity Cost Organizational Process Assets Organizational Process Assets Updates Payment Systems

Performance Reporting Performance Reports Plan Procurements Procurement Audits Procurement Contract Award Procurement Documentation Procurement Documents Procurement Management Plan Procurement Negotiations Procurement Performance Reviews Project Document Updates Project Documents Project Management Plan Project Management Plan Updates Project Procurement Management Project Schedule Proposal Evaluation Techniques Qualified Seller List Records Management System Request for Information, RFI Request for Proposal, RFP Request for Quotation, RFQ Requirements Documentation Resource Calendars Risk Register Risk Response Risk-Related Contract Decisions Scope Baseline Selected Sellers Seller Proposals Sharing Source Selection Criteria Statement of Work, SOW Teaming Agreements Time and Material, T&M Work Performance Information

Chapter 13

Preparing for the PMP® Examination


l

l

l

Success in any examination depends on good preparation and the PMP® Exam is no exception and this chapter contains Hints and Tips for passing successfully. There is one PMP® examination topic which is not covered in the PMBOK® Guide: Professional and Social Responsibility. It is defined by the Project Management Institute Code of Ethics and Professional Conduct, which is introduced here. The PMP® examination is administered in English; however Language Aids are available for some widely spoken languages and are described in this chapter. This section details how to use this book. Some study, health and examination day issues are also mentioned, based on feedback from PMP® candidates.

13.1

Professional and Social Responsibility

In the rest of this book we have studied various project management techniques. Here we look more at the behavior of the people who manage projects. The PMI® is a professional organization and must therefore distance itself from members who do not act professionally. It addresses this issue in a way which is very similar to that of many organizations. There is a six page document called the Project Management Institute Code of Ethics and Professional Conduct which as a PMP® applicant you must sign. In addition 9% of the marks in the PMP® examination are given for questions based on this document. This Code of Ethics applies to all PMI® members and also to nonmembers who hold PMI® accreditations. You can download the current version as a .pdf document from the page of the PMI® website which describes the PMP® credential.


197

13 Preparing for the PMP® Examination

198

13.1.1 PMI® Code of Ethics and Professional Conduct The Code of Ethics consists of five chapters and an appendix: l

l

Chapter 1 covers Vision and Applicability. This means the Objectives of the Code of Ethics and to whom it applies. Chapters 2–5 cover the actual professional conduct expected of us: 1. 2. 3. 4.

l

Responsibility Respect Fairness Honesty.

The Appendix describes the history of the Code of Ethics, as well as including a glossary. Each of Chaps. 2–5 is divided into:

l

l

Aspirational Standards. This means standards which we should aspire to, in other words, which we should try to meet. Mandatory Standards. This means standards which we must meet, such as rules, regulations, laws, etc. This means that we are responsible for finding out what the rules are in the country or location where we are working.

The code must be very carefully worded, because it is used by professionals around the world. Everybody must understand exactly the same thing, so the style of language is similar to legal documents. Although unavoidable, this can make it difficult to read. In spite of this, if you are already working in a professional environment you will not find much new to learn. The advice for answering the Professional and Social Responsibility questions of the PMP® examination is: l l

l

Print, read and study the .pdf document. For each question, identify what is professional and honest. Let this guide your answers. If not sure, ask yourself: “What would be the right answer in an American context?”

Despite all the efforts to internationalize this document, genuine differences in interpretations do exist in different cultures. The interpretations can also be influenced by recent scandals, such as the Enron affair. An example of interpretation differences is shown by the following two situations which I experienced: In many countries, eating a meal together is a very important part of a business relationship. At a European Union project proposal meeting in Turin, Italy, the local members invited the others to a superb lunch. Although the proposal could not be finished that day as planned, the resulting team spirit supported the return from all over Europe a week later to finish the work. On the other hand, all gifts of more than 10 had to be reported in a US company operating in Europe. This meant that if a supplier invited a project manager to join him for a burger at lunchtime, this had to be reported.

13.3 Exam Reference

13.2

199

Language Aids

The purpose of the book you are now reading is to simplify preparation for the PMP® examination. Although it is administered in English, Language Aids for the examination are available in a number of widely spoken languages. This means that the questions are in English, but you also get a translation. At the time of writing the Examination Language Aids available are: Arabic, Brazilian Portuguese, Chinese (traditional and simplified), French, German, Hebrew, Italian, Japanese, Korean, Russian and Spanish. If you want these language aids, make sure that you communicate this in your application form and also be sure to check their current format (e.g through your national PMI® chapter) in case it has changed. When using these language aids, it helps to know the terminology in both your own language and in English. This also applies to international projects. If, for example, you work in a French speaking environment, you may hear the terminology of the PMBOK® Guide in French. Because no standard has displaced all others, you may hear other terminology variations for concepts similar to those in the PMBOK® Guide.

13.3

Exam Reference

This section contains important references for PMP® and CAPM® candidates.

13.3.1 PERT and Standard Deviation Note that in these formulas, the sign ffi (approximately equal to) is used. A more rigorous analysis gives different results in some places, but the difference is not significant for the usage presented in this book. PERTðestimate of mean durationÞ ¼

Optimistic Estimate þ Pessimistic Estimate þ ð4 Estimate of Most LikelyÞ 6

Standard Deviation sðestimateÞ Pessimistic Estimate Optimistic Estimate ffi 6 sffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffi Pnumber of sample ðactual measurement average measurementÞ2 1 ffi number of samples Task Variance ¼ s2


200

Area under the Normal Distribution Curve (total area under curve ¼ 1). Mean s: 68.3% Mean 2s: 95.5% Mean 3s: 99.7%

13.3.2 EVM Formulas 1. 2. 3. 4. 5. 6.

Cost Variance CV ¼ EV AC Cost Performance Index CPI ¼ EV AC Schedule Performance Index SPI ¼ EV PV Schedule Variance SV ¼ EV PV Estimate to Complete ETC ¼ EAC AC Estimate at Completion (assuming future progress is expected to be similar to actual progress) EAC ¼ BAC CPI

1. Variance at Completion VAC ¼ BAC EAC 2. To-Complete Performance Index TCPI ¼ ( BAC–EV) (BAC–AC) If BAC cannot be met, then TCPI is based on a new EAC estimate: TCPI ¼ ( BAC–EV) (EAC–AC)

13.3.3 Communication Number of communication paths ¼ n (n 1) 2

13.3.4 Project Process Groups and Knowledge Areas Mapping Table 3-1 of the PMBOK® Guide contains all 42 processes, 5 Process Groups and 9 Knowledge Areas.

13.4

Preparing for the PMP® Examination

Congratulations on taking this examination! While the preparation itself will of course help you to understand project management better, this section covers advice on getting ready for the examination.

13.4 Preparing for the PMP® Examination

201

13.4.1 Plan Your Study l

l

l

l

l

l

l

l

The PMP® requires a lot of study. The Swiss chapter of the PMI® estimates an average, based on self-study alone, of 150 hours. This is 10% of a working year in many countries and cannot be done without taking the time from something else. It takes most candidates at least 6 months to fit this time into their busy schedule. Establish a project for yourself called “PMP® Preparation”, develop realistic milestones and add them to your calendar. Include milestones for “application for the examination complete”, “authorization to take examination received” and “examination date confirmed”. You can set additional milestones for finishing the first round of study for each Knowledge Area. Decide exactly when you will do the examination, based on the available dates and the logistics of getting to the examination center. Add this date to your milestone plan. Plan some free time for studying immediately before the examination. If your employers value the PMP®, then they will understand that getting it takes a lot of effort, from which they benefit. Ask for free study time for up to a week before the examination. Doing your normal work 4 days in a row and the examination on the fifth day of the week is usually unsuccessful. Add your study time to your normal calendar, for example, 1 hour per day during the working week and 2 hours per day at the weekend. Other factors may possibly need more time, such as studying in a language different from your own native language. Tell your stakeholders (partner, family, friends, manager, etc.) that you are doing this important project and that you will need their support. Strengthen your motivation by reminding your stakeholders of the benefits to you, when you are successful. Allow enough time after the examination to repeat it, in case you are unlucky and need to. Possible reasons include: you or your partner is ill, travel difficulties, unplanned demands at work etc. Check the details in your application documentation about how often you can repeat the examination and your last possible date. At the time of writing, candidates are allowed up to three attempts within a 1 year period. Make sure that your plan has enough space for a second attempt at the examination, if needed. You will then be less stressed if you need to use it. When your plan is ready, print it out and discuss it with your stakeholders. Is it realistic? Have you forgotten something? Maybe there is a big project you have to work for during the study period. It is important to check that your plan is both realistic and complete.

13.4.2 Learning Phase l

Read this Book first. Start your learning phase by reading the first three chapters only, to give you an overview of the whole area of study. Then read Chaps. 4–12, which mirror the PMBOK® Guide in shorter format. As you

202

l

l

l

l

l

l

l

l


read, refer to the figures in the PMBOK® Guide. When you have finished, repeat the topics, by going into more detail using the PMBOK® Guide directly. Make your own Flash Cards as you study. Flash Cards are a well known way of helping you remember facts. You can buy them or download from the internet, but you learn much more if you do it yourself. Get index cards, about the size of playing cards. On one side write the keywords from the lists of Flash Card Terms at the end of the chapters of this book. Make sure, in particular, that you include all the Process Inputs, Outputs and Tools and Techniques on your flash cards. Write your description of the keyword on the other side of the card. Your colleague can then show you the keyword side of the cards randomly. You must then explain the meaning of the keyword. Sometimes having a partner or friend who just listens to you can help, even if they do not understand the topic! The examination often uses a lot of words directly from standard, but the exam day is not a good time to see them for the first time! You should learn the following by heart: – The names of all Process Groups, Knowledge Areas and Processes. – The ITTO’s (Inputs, Tools and Techniques and Outputs) of all the processes. – All formulas and be able to write them down. The sections on EVM, Procurement and Quality are particularly full of abbreviations and symbols. In addition, Procurement reflects business practice in the USA, which may not be the same where you work. The suggested learning strategy for these sections is as follows: On the first reading of this book, try to understand the principles. Then cover the same material with direct reference to the PMBOK® Guide and the abbreviations. Finally you should study the remaining material, which is outlined in this book and more fully covered in the PMBOK® Guide. Use Different Learning Materials. One advantage of the PMP® examination is that there is plenty of support material available such as books and training. For example there are podcasts which you can download from the internet and listen to on your laptop computer or MP3 player during travel and waiting time. If you do not understand something from one source, do not spend too much time on it. Change to a different source for the same topic. If you decide to participate in an examination preparation course, make sure that you get the right one for you, with a trainer who has a good record of success. It is recommended to do such a course towards the end of your study phase, even the week immediately before the examination. Join a PMP® Study Group. If other colleagues are also studying for PMP®, then set up a chat room or study group and agree that you can ask each other for help. Your local PMI® chapter organization may also be able to help you contact others who are studying at the same time. You can also look for PMP® support groups in the internet. Simulate the exam as much as possible. Find and work through suitable questions, for example from the internet. There are also a number of simulators on the market, which present you questions randomly, in a way similar to the real

13.4 Preparing for the PMP® Examination

l

203

examination. Most of them have a feature that allows you to mark questions for review, just like the real examination. This saves you time, as you can focus on those answers which need more time, without re-reading answers which you are sure about. When using exam simulators, record both your marks and how long it took you. Do not panic if you get a low score the first time. If you get progressively better, you are on the right path. Your aim is to pass the examination comfortably, so change to a different topic and use your time where it is needed, if you get consistently good scores in a particular Knowledge Area.

13.4.3 Health Preparing for and passing the PMP® examination is physically and psychologically demanding. Part of your preparation plan should therefore also take care of some health issues. l

l

l

l

l

l

Plan your Sport and Relaxation. Sport is a good way to relax and scheduling this in, both while studying and before the examination can help your personal balance. Eat Properly. Eat proper meals, particularly just before the examination. Avoiding too much coffee and stimulants will also help. Sleep Well. Go to bed when you are tired. Do something relaxing before going to bed at the end of each day, such as listening to music. Protect your Eyes. The PMP® examination is usually done on a computer. As it takes 4 hours and consists of 200 questions, most applicants find it physically demanding. In particular, it can be hard on the eyes. If you have eye problems, bring eye drops with you. If you usually use contact lenses but find them not good for hours of screen work, get prescription glasses. Today the cheapest glasses are really cheap, compared with having to repeat the examination! Bring Earplugs to the examination. You will probably be in a room with other candidates doing other examinations. This can be very distracting and earplugs can make it easier to concentrate. Bring water and fruit for short breaks during the examination.

13.4.4 Examination Day l

l

Work out how to travel to the examination. I recommend arriving the evening before to avoid potential stress and problems on the day of the exam, particularly if you have a morning examination schedule. If your partner can join you and go for a relaxing meal or to a movie, so much the better. Arrive on time. Wake up early and plan to arrive up to an hour before the scheduled start time. If you cannot attend because of extenuating circumstances

204

l

l

l

l

l

l

l

l


(medical emergency, illness in the immediate family, etc.), you must contact the PMI customer Care within 72 hours to be considered for being excused from recording a “no-show” and its consequences. Bring the required Identification. Current rules are that you must bring two items although there are reports that a passport would be accepted in Europe. The examination center is responsible for verifying who you are, but they are not PMP® experts. Make it easy for yourself by following the instructions exactly. The environment is closely controlled to prevent cheating and support the value of the qualification. You cannot bring anything into the exam room but will be given a pencil, some paper and a very simple calculator. A wrist watch may be allowed, but a mobile telephone will not. Listen carefully to the short introduction about how to use the computer and the questions. As soon as the clock starts counting down, note the time. Use the first minutes to write down your memorized formulas on the paper. Read the questions carefully. Some participants report that the early questions can be very long. If you do not understand a question, mark it for a second reading and move on to the easier ones. Questions in the format “What should you do?” often mean “What should you do next ?” In the same way, the Procurement questions usually assume that the reader is the purchaser. See if one of the answers is clearly wrong and eliminate it. Answer every question. A blank scores zero. If you are not quite sure about which alternative answer is correct, remembering the American origins of the PMBOK® Guide may give you a hint. Finally, remember that the Body of Knowledge covers anything and everything in the field of Project Management, not just what is in the PMBOK® Guide. Do not get confused by unexpected features and questions. Use the time well. You can do the entire examination in half the time allowed. Most people will however get a better result by using the time to review their answers carefully. Each time you pass through, you should get more certain of your answers. Set yourself milestones, so that you can check if you are on track or if you need to speed up. It can help to pass through the questions several times, doing the easier questions first. Use the marker and filter function, which saves you time when re-reading. Do not get nervous about other people leaving the room (early), thinking that they are faster. They might have quit or be doing another exam. Check carefully before recording your answers. The examination is not finalized until you deliver the results, which is done using a special screen at the end. Take a calm look at where you stand before doing this, as there is no way to recall if you make a mistake. Collect your result. If you are doing the examination on screen (as most people do), you will get an immediate print out. Take it and leave the building, hopefully for a well earned celebration. Even if you are unlucky (but I hope not!), you will still have planned time for another chance.

13.6 Index

13.5

205

Final Word

We have introduced the PMBOK® Guide as if landing in a helicopter. First we saw projects from a distance and identified the idea of learning from experience, captured by processes. Then we came down a bit and looked at different project management standards. We then selected the PMBOK® Guide standard and landed on Table 3-1, which lists all 42 processes. These are detailed in Chaps. 4–12. Finally we looked at some less demanding but important topics related to doing the examination here in Chap. 13. Remember that this book is designed to be read together with a copy of the PMBOK® Guide in your hand. It now remains to wish you success in your examination. Just remember that for the PMI®, your examination application is a process, but for you it is a project!

13.6

Index

Aspirational Standards Cost Performance Index, CPI Cost Variance, CV Eat Properly Estimate at Completion, EAC Estimate to Complete, ETC Examination Day Fairness Flash Cards Health Honesty Join a PMP Study Group Language Aids

Mandatory Standards PMI Code of Ethics and Professional Conduct Professional and Social Responsibility Protect your Eyes Respect Responsibility Schedule Performance Index, SPI Schedule Variance, SV Sleep Well Sport and Relaxation To-Complete Performance Index, TCPI Use Different Learning Materials Variance at Completion, VAC

Index

A Accept, 175 Acceptance Criteria, 65, 67 Accepted Deliverables, 56, 71 Accuracy, 115 Acquire Project Team, 129, 130, 133 Acquisition, 135 Activity, 76 Activity Attributes, 79, 80, 83, 85, 87 Activity Cost Estimates, 99, 167, 184 Activity Duration Estimates, 87, 167 Activity List, 79, 80, 83, 85, 87 Activity Resource Requirements, 84, 85, 87, 131, 184 Actual Cost, AC, 106 Additional Quality Planning Tools, 122 Administer Procurements, 181, 192 Advertising, 191 Affinity Diagram, 63 Alternatives Analysis, 84, 143 Alternatives Identification, 66 Analogous Estimating, 85, 98 Applying Leads and Lags, 88 Approved Change Requests, 49, 59, 72, 125, 192 Approved Change Requests Review, 126 Aspirational Standards, 198 Assignable Cause, 120 Assumptions, 65 Assumptions Analysis, 168 Assuring Progress, 10 Attribute Sampling, 125 Avoid, 175

B Bar Chart, 89 Basis of Estimates, 99 Benchmarking, 122 Bidder Conferences, 190 Bottom-Up Estimating, 84, 86, 98 Brainstorming, 62, 79, 122, 168 Budget at Completion, BAC, 108 Budget Forecasts, 104, 158 Burn Rate, 17 Business Case, 4, 42, 97

C Capability, 118 Cause and Effect Diagrams, 113, 125 Change Control Board, CCB, 51, 53, 191 Change Control Procedures, 20 Change Control Process, 51 Change Log, 54, 147, 156 Change Management, 27 Change Requests, 50, 53, 72, 91, 104, 124, 126, 144, 157, 159, 178, 189, 193 Change Request Status Updates, 54 Checklist Analysis, 168 Claims Administration, 192 Closed Procurements, 194 Close Procurements, 181, 193 Close Project or Phase, 55, 181 Closing, 7, 23, 55 Closing Process Group, 28 Collect Requirements, 59, 60 Co-location, 137, 139

207

208

Common Cause, 119, 121 Communication Methods, 155, 157, 158 Communication Models, 152 Communication Requirement Analysis, 151 Communications Management, 34 Communications Management Plan, 153 Communication Technology, 152 Company Work Authorization System, 52 Compliance, 16 Conduct Procurements, 181, 189 Confidentiality, 185 Configuration Management, 47 Conflict Management, 142 Construction Industry, 14 Contingency Reserves, 100 Contingent Response Strategies, 174 Continuous Improvement, 28, 114 Contract, 43, 192 Contract Change Control System, 192 Contracts, 100 Control Accounts, 70 Control Charts, 113, 117, 125 Control Costs, 95, 101, 108 Control Limits, 125 Control Schedule, 75, 90 Control Scope, 59, 72 Corrective Action, 27, 51, 91 Cost Aggregation, 100 Cost Baseline, 95 Cost-Benefit Analysis, 117 Cost Management, 26, 32, 95 Cost Management Plan, 165, 167, 171 Cost of Quality, 98, 115, 117 Cost Performance Baseline, 100, 116 Cost Performance Index, CPI, 91, 104, 106, 200 Cost Plus Award Fee, CPAF, 187 Cost Plus Fixed Fee, CPFF, 187 Cost Plus Incentive Fee, CPIF, 187 Cost Variance, CV, 91, 104, 106, 200 Crashing, 89 Create WBS, 68 Critical Chain, 88 Critical Path Method, CPM, 9, 87 Customer Satisfaction, 114

Index

D Data Gathering and Representation Techniques, 172 Decision Gates, 26 Decision Tree, 173 Decomposition, 69, 78 Defect Repair, 51 Define Activities, 75, 76 Define Scope, 59, 66 Deliverable, 4, 7, 50, 59, 125 Deliverable Acceptance, 194 Deliverable Status, 50 Delphi Method, 150 Delphi Technique, 63, 168 Dependency Determination, 81 Design of Experiments, 122 Determine Budget, 95, 99 Develop Human Resource Plan, 129, 130 Develop Project Charter, 40, 41 Develop Project Management Plan, 26, 44 Develop Project Team, 130, 136 Develop schedule, 75, 87 Diagramming Techniques, 168 Direct and Manage Project Execution, 48 Discretionary Dependencies, 81 Distribute Information, 147, 154 Documentation Reviews, 168

E Earned Value, EV, 105, 106 Earned Value Management, EVM, 95, 101, 103, 105 Eat Properly, 203 Effective Decision Making, 143 Enhance, 175 Enterprise Environmental Factors, 16, 43, 45, 46, 49, 52, 53, 77, 83, 85, 87, 97, 117, 131, 134, 149, 151, 165, 168, 184 Enterprise Environmental Factors Updates, 141, 144 Estimate Activity Durations, 75, 85, 98 Estimate Activity Resources, 75, 82, 84 Estimate at Completion, EAC, 104, 108, 109, 200 Estimate Costs, 3, 95 Estimate to Complete, ETC, 109, 200 Examination Day, 203 Executing, 6, 23

Index

Executing Process Group, 27 Expectations, 59 Expected Monetary Value, EMV, 173 Expenditure, 102 Expert Judgment, 43, 46, 50, 54, 56, 66, 79, 84, 98, 100, 150, 168, 170, 172, 174, 185, 191 Exploit, 175 Extensions, 14 External Dependencies, 81

F Facilitated Workshops, 62, 66 Fairness, 198 Fast Tracking, 81, 89 Finish-to-Start, FS, 80 Firm Fixed Price, FFP, 186 Fishbone Diagram, 168 Fitness for Use, 113, 114 Fixed Price Incentive Fee, FPIF, 186 Fixed Price with Economic Price Adjustment, FP-EPA, 187 Flash Cards, 202 Float, 91 Flowcharting, 122, 125 Focus Groups, 61 Forecasting, 108, 109 Forecasting Methods, 158 Forecasts, 52 Free Float, 91 Funding Limit Reconciliation, 100

G Gantt Chart, 26, 48, 76, 89 Gold Plating, 30 Government, 14 Grade, 115 Ground Rules, 137, 139 Group Creativity Techniques, 62 Guide, 14

H Health, 203 Histograms, 113, 125 Historical Information, 56 Historical Relationships, 100

209

Honesty, 198 Human Resource Management, 26, 27, 33, 129 Human Resource Plan, 97, 132 Human Resources, 47

I Identify Risks, 161, 167 Identify Stakeholders, 24, 61, 149–150 Impact, 166 In Control, 121 Information Distribution Tools, 155 Information Gathering Techniques, 168 Initiating, 6, 23 Initiation, 26 Initiation Process Group, 24 Inputs, 22, 29 Inspection, 71, 114, 126 Inspections & Audits, 192 Integrated Change Control, 39, 47, 49, 53 Integration Management, 30, 39 Intellectual Property Management, 29 International Project Management Association, IPMA, 9 International Standards Organization, ISO, 11 Interpersonal Skills, 137, 142, 157 Interviewing, 168, 172 Interviews, 61 Invitation for Bid, IFB, 189 IPMA Competence Baseline, 10 IPMA Eye of Competence, 10 Ishikawa, 168 ISO/WD 21500, 11 Issue Log, 143, 147, 156, 161 Issues, 52

J Job Shadowing, 64 Join a PMP1 Study Group, 202 Joint Application Development, JAD, 62

K Knowledge Areas, 23, 29, 95

210

L Language Aids, 197, 199 Leads & Lags, 81 Lessons Learned, 2, 3, 39, 56, 57 Lessons Learned Documentation, 194 Lower Control Limit, LCL, 120 Lower Specification Limit, LSL, 121

M Make or Buy Analysis, 184 Make or Buy Decisions, 181, 187, 190 Management Reserves, 100 Management Responsibility, 115 Management Skills, 157 Manage Project Team, 129, 130, 141 Manage Stakeholder Expectations, 147, 155 Mandatory Dependencies, 81 Mandatory Standards, 198 Mean, 120 Methodology, 14 Milestone, 18, 26 Milestone List, 76, 79, 80 Milestone Schedule, 90 Mind Mapping, 79 Mind Maps, 63 Mitigate, 175 Modeling and Simulation, 173 Monitor and Control Project Work, 52 Monitor and Control Risks, 161, 177 Monitoring & Controlling, 6, 23 Monitoring & Controlling Process Group, 27, 54 Monte Carlo Analysis, 88

N Negotiated Settlements, 194 Negotiation, 134 Networking, 132 Nominal Group Technique, 63 Normal Distribution, 119, 172

O Observation & Conversation, 142 Observations, 64 Operational Work, 4, 21 Operations Management, 15

Index

Opportunity Cost, 184 Organizational Environment, 19 Organizational Process Assets, 19, 43, 45, 46, 49, 52, 53, 56, 66, 69, 70, 72, 77, 80, 83, 85, 87, 91, 97, 99, 101, 117, 125, 131, 134, 142, 149, 151, 154, 156, 158, 165, 168, 170, 184, 190 Organizational Process Assets Updates, 56, 73, 91, 124, 126, 144, 155, 157, 159, 178, 193, 194 Organizational Theory, 132 Organization Charts and Position Descriptions, 131 Out of Control, 121 Outputs, 22, 29

P Parametric Estimating, 86, 98 Pareto Diagram, 113, 126 Payment Systems, 192 Performance Reporting, 192 Performance Reports, 52, 142, 154, 159, 177, 192 Performance Reviews, 91, 108, 109 Perform Integrated Change Control, 53 Perform Qualitative Risk Analysis, 161, 169 Perform Quality Assurance, 113, 114, 123 Perform Quality Control, 71, 113, 114, 124 Perform Quantitative Risk Analysis, 161, 171 PERT. See Program Evaluation & Review Technique Phase Exit, 26 Phase Gates, 26 Phases, 23, 24 Plan Communications, 147, 150 Planned Value, PV, 107 Planning, 6, 23, 25 Planning Meetings and Analysis, 165 Planning Process Group, 24, 26, 165 Plan Procurements, 183 Plan Quality, 113, 114, 116 Plan Quality and Perform Quality Control Tools and Techniques, 124 Plan Risk Management, 161, 165 Plan Risk Responses, 161, 174

Index

PMI Code of Ethics and Professional Conduct, 198 PMP1, 7 Portfolio Management, 16 Pre-Assignment, 134 Precedence Diagramming Method, PDM, 80 Precision, 115 Prevention, 114, 125 Preventive Action, 51 PRINCE, 9 PRINCE2, 10 Probability, 166 Process Analysis, 124 Process Groups, 6, 15, 23, 24, 29 Process Improvement Plan, 123 Procurement Audits, 194 Procurement Contract Award, 191 Procurement Documentation, 193 Procurement Documents, 149, 188, 189, 192 Procurement Management, 35 Procurement Management Plan, 187 Procurement Negotiations, 191 Procurement Performance Reviews, 192 Product Analysis, 66 Product Development, 19 Product Life Cycle, 17 Product Scope Description, 67 Professional and Social Responsibility, 198 Program Evaluation & Review Technique, PERT, 9, 86 Program Management, 16 Progressive Elaboration, 47, 51 Project Charter, 3, 39, 41, 44, 60, 66, 149 Project Communications Management, 148 Project Cost Management, 95 Project Documents, 167, 190 Project Document Updates, 51, 53, 54, 67, 68, 70, 72, 73, 82, 84, 87, 90, 91, 99, 101, 123, 124, 126, 153, 157, 176, 178, 191 Project Exclusions, 67 Project Files, 56 Project Funding Requirements, 101 Project Governance, 18 Project Integration Management, 9, 39, 52 Projectized Organization, 19, 40 Project Life Cycle, 17 Project Management, 3, 6

211

Project Management Estimating Software, 98 Project Management Information System, PMIS, 16, 50, 51 Project Management Institute, PMI1, 9, 14 Project Management Maturity, 16 Project Management Office, PMO, 16, 44, 51, 78 Project Management Plan, 39, 44, 48, 52, 53, 56, 71, 72, 91, 101, 124, 125, 134, 137, 141, 154, 156, 158, 177, 189, 192, 193 Project Management Plan Updates, 51, 53, 54, 73, 91, 124, 126, 136, 144, 157, 176, 178, 191, 193 Project Management Processes, 7, 21 Project Management Software, 84, 108, 110 Project Manager, 2, 16, 20 Project or Phase Closure Documents, 18 Project Performance Appraisals, 142 Project Phase, 17 Project Processes, 14, 23 Project Procurement Management, 181 Project Quality Management, 113 Project Reporting, 27 Project Risk Management, 161 Project Schedule, 89, 91, 97, 99, 184 Project Schedule Network Diagrams, 87 Project Scope Management, 59 Project Scope Statement, 67, 69, 80, 85, 87, 165, 170 Project’s Product, 3, 4, 30, 32, 42, 50, 56, 75, 113 Project Staff Assignments, 136, 137, 141 Project Team, 3 Proposal Evaluation Techniques, 190 Proprietary Quality Management Methodologies, 122 Protect your Eyes, 203 Prototypes, 64 Published Estimating Data, 84

Q Qualified Seller List, 189 Quality Assurance, 123 Quality Audits, 124 Quality Checklists, 122, 125

212

Quality Control Measurements, 124, 126 Quality Function Deployment, QFD, 62 Quality Management, 26, 32, 33 Quality Management Plan, 26, 122, 167 Quality Metrics, 122, 124, 125 Quantitative Risk Analysis and Modeling Techniques, 172, 173 Questionnaires and Surveys, 64

R RACI Format, 132 Recognition & Rewards, 137, 140 Records Management System, 193, 194 Release Plan, 133 Reporting Systems, 158 Report Performance, 147, 157 Request for Information, RFI, 189 Request for Proposal, RFP, 189 Request for Quotation, RFQ, 189 Requirements Documentation, 64, 66, 69, 71, 72, 183 Requirements Management Plan, 65 Requirements Traceability Matrix, 65, 68, 71 Reserve Analysis, 86, 98, 100, 177 Resource Breakdown Structure, 84 Resource Calendar, 83, 85, 87, 99, 133, 136, 137, 191 Resource Leveling, 88 Resource Loading, 88 Resources, 47 Respect, 198 Responsibility, 198 Responsibility Assignment Matrix, RAM, 131 Return on Investment, ROI, 4 Risk, 19 Risk Audits, 177 Risk Breakdown Structure, 165 Risk Categories, 165 Risk Categorization, 170, 171 Risk Data Quality Assessment, 170 Risk Management, 34, 35, 162 Risk Management Plan, 166, 167, 170, 174 Risk Probability and Impact Assessment, 170 Risk Reassessment, 177

Index

Risk Register, 90, 98, 117, 167, 169, 170, 174, 177, 184 Risk Register Updates, 171, 174, 176, 178 Risk-Related Contract Decisions, 176, 184 Risk Response, 35, 169, 174, 176, 183 Risk Tolerance, 162, 163 Risk Urgency Assessment, 171 Rolling Wave Planning, 76, 78 Root Cause Analysis, 168 Rule of Seven, 121 Run Chart, 126

S Scatter Diagram, 126 Schedule Baseline, 75, 89, 90, 117 Schedule Compression, 88 Schedule Data, 90 Schedule Management Plan, 165, 167, 171 Schedule Network, 80, 81, 89, 90 Schedule Network Analysis, 87 Schedule Network Diagram, 82 Schedule Network Templates, 82 Schedule Performance Index, SPI, 91, 104, 107, 200 Schedule Variance, SV, 91, 104, 107, 200 Scheduling Tool, 89, 91 Scope Baseline, 59, 70, 78, 97, 99, 116, 167, 183 Scope Creep, 72 Scope Management, 30 Scope Statement, 59 Selected Sellers, 191 Seller Proposals, 190 Sensitivity Analysis, 173 Sequence Activities, 75, 79 Share, 175 Sharing, 184 Slack, 91 Sleep Well, 203 Source Selection Criteria, 187, 191 Special Cause, 120 Sponsor, 5, 21, 24, 41 Sport and Relaxation, 203 Staffing Management Plan, 133 Stakeholder, 3, 17, 42 Stakeholder Analysis, 147, 150

Index

Stakeholder Management Strategy, 150, 151, 156 Stakeholder Notifications, 155 Stakeholder Register, 3, 60, 68, 116, 150, 151, 156, 167 Stakeholder Risk Tolerances, 49 Standard Deviation, s, 86, 118, 120 Start-to-Start, SS, 80 Statement of Work, SOW, 42, 188, 191 Statistical Sampling, 122, 125 Status Meetings, 177 Steering Committee, 3, 162 Strategies for Negative Risks, 175 Strategies for Positive Risks, 175 Strong Matrix, 40 Subject Matter Experts, 61 SWOT Analysis, 168

T Team-Building Activities, 137, 138 Teaming Agreements, 184, 188, 190 Team Performance Assessments, 141, 142 Technical Performance Measurement, 177 Templates, 78 Terminate, 1 Three Point Estimates, 86, 98 Three-Point Method, 172 Time Management, 26, 31, 75 Time & Materials, T&M, 185 To-Complete Performance Index, TCPI, 108, 109, 200 Tolerances, 125 Tools & Techniques, 22, 29 Total Float, 91 Training, 137

213

Transfer, 175 Trend Analysis, 110 Trends, 171 Tuckman’s Team Development Model, 138

U Upper Control Limit, UCL, 120 Upper Specification Limit, USL, 121 Use Different Learning Materials, 202

V Validated Changes, 126 Validated Deliverables, 71, 126 Value, 102 Variables Sampling, 125 Variance Analysis, 72, 108, 110, 158 Variance and Trend Analysis, 177 Variance at Completion, VAC, 108, 200 Vendor Bid Analysis, 98 Verify Scope, 59, 70 Virtual Teams, 135

W WBS Dictionary, 70 Weak Matrix, 41 What-if Scenario Analysis, 88 Work Breakdown Structure, WBS, 59, 68 Work in Progress, 103 Work Package, 68, 70 Work Performance Information, 50, 53, 71, 72, 91, 101, 124, 158, 177, 192 Work Performance Measurements, 73, 91, 103, 125, 158

Overview of the PMBOK® Guide: Short Cuts for PMP® Certification

Overview of the PMBOK® Guide: Short Cuts for PMP® Certification, Second Edition

PMP Certification Beginners Guide

PMP Certification, A Beginner's Guide

PMP Certification, A Beginner's Guide

Preparing For The Project Management Professional (PMP) Certification Exam(pmp

Preparing For The Project Management Professional (PMP) Certification Exam(pmp

Preparing For The Project Management Professional (PMP) Certification Exam(pmp

Preparing for the Project Management Professional (PMP) Certification Exam

Preparing for the Project Management Professional (PMP) Certification Exam

Preparing for the Project Management Professional (PMP Certification Exam)

PMP Certification All-In-One Desk Reference For Dummies

Women's Cinema – The Contested Screen (Short Cuts)

Cuts

The Star System: Hollywood's Production of Popular Identities (Short Cuts)

Construction Extension to the PMBOK Guide

Cuts

Government Extension to the PMBOK Guide

Q & A's for the PMBOK Guide Third Edition

Feminist Film Studies: Writing the Woman into Cinema (Short Cuts)

Short Math Guide for Latex2e

Short Math Guide for LaTeX

Acrc Exam Certification Guide

CCDA exam certification guide

Clsc Exam Certification Guide

MySQL Certification Study Guide

CCNP ROUTE 642-902 Official Certification Guide (Exam Certification Guide)

Network+ Certification Training Guide

A+ Certification Study Guide

CCNP ROUTE 642-902 Official Certification Guide (Exam Certification Guide)

CCNP SWITCH 642-813 Official Certification Guide (Exam Certification Guide)

Overview of the PMBOK® Guide: Short Cuts for PMP® Certification