Project Management for Mere Mortals 0321423453, 9780321423450

Citation preview

Project Management for Mere Mortals ®

This page intentionally left blank

Project Management for Mere Mortals ®

Claudia M. Baca PMP, PMI Certified OPM3® Assessor and Consultant

Boston • San Francisco • New York • Toronto • Montreal London • Munich • Paris • Madrid Capetown • Sydney • Tokyo • Singapore • Mexico City

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. The publisher offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales, which may include electronic versions and/or custom covers and content particular to your business, training goals, marketing focus, and branding interests. For more information, please contact: U.S. Corporate and Government Sales (800) 382-3419 [email protected] For sales outside the United States please contact: International Sales [email protected] This Book Is Safari Enabled The Safari® Enabled icon on the cover of your favorite technology book means the book is available through Safari Bookshelf. When you buy this book, you get free access to the online edition for 45 days. Safari Bookshelf is an electronic reference library that lets you easily search thousands of technical books, find code samples, download chapters, and access technical information whenever and wherever you need it. To gain 45-day Safari Enabled access to this book: • Go to http://www.awprofessional.com/safarienabled • Complete the brief registration form • Enter the coupon code 4FRT-LSZQ-EQIP-MMQF-REWR If you have difficulty registering on Safari Bookshelf or accessing the online edition, please e-mail [email protected]. Visit us on the Web: www.awprofessional.com Library of Congress Cataloging-in-Publication Data: Baca, Claudia. Project management for mere mortals : the tools, techniques, teaming, and politics of project management / Claudia M. Baca. p. cm. ISBN 0-321-42345-3 (pbk. : alk. paper) 1. Project management. I. Title. HD69.P75B324 2007 658.4’04—dc22 2007011959 Copyright © 2007 Pearson Education, Inc. All rights reserved. Printed in the United States of America. This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. For information regarding permissions, write to: Pearson Education, Inc. Rights and Contracts Department 75 Arlington Street, Suite 300 Boston, MA 02116 Fax: (617) 848-7047 ISBN 0-321-42345-3 Text printed in the United States on recycled paper at Stoughton Courier in Stoughton, Massachusetts. First printing, June 2007

To my husband, Doug—my partner in everything!

This page intentionally left blank

Contents Foreword

xv

Preface

xvii

Acknowledgments

xxv

About the Author CHAPTER 1

Setting the Project Management Context

Concepts

xxvii 1 2

What Is Project Management? Role of the Project Manager The Hierarchy of Project Management Organizational Structures Life Cycle

Teaming

2 3 6 9 11

12

Empathy Negotiation Influencing Walking the Talk Ego in Check

13 13 13 13 13

Politics

14

Summary

15

Case Study

15

Review Questions

17

CHAPTER 2

You’ve Been Assigned a Project!

19

Chartering the Project

20

Formal Chartering Informal Chartering

20 23

Measures of Performance

23

Defining MOPs MOPs and the Triple Constraints More about MOPs Putting Together a MOP

25 27 29 31 vii

viii

Contents

Preliminary Scope Statements

32

Project Costs

35

Starting the Project Plan

38

Teaming

41

Politics

43

What’s in it for Them? How Much Power Do You Really Have?

43 45

Summary

47

Case Study

48

Review Questions

51

CHAPTER 3

How Big Is This Project?

53

Defining the Scope

54

Product Requirements

60

Setup Step Requirements Gathering Step Confirming the Requirements Step Baseline and Control Step

61 68 80 83

Creating the WBS

86

Desk Testing

90

Teaming

91

Politics

92

Summary

94

Case Study

95

Review Questions

97

CHAPTER 4

Laying Out the Work

Defining Tasks Creating the List of Tasks Completion Criteria

Sequencing the Work Dependencies Dependency Relationships Creating a Network Diagram

99 100 100 104

107 108 109 111

Contents

ix

Teaming

117

Politics

122

Summary

124

Case Study

124

Review Questions

130

CHAPTER 5

The Art of Estimating

131

Estimating Definitions

132

Estimating Techniques

135

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

What to Estimate Resource Estimation Duration Estimation Cost Estimation

135 136 136 137 137 140

140 141 148 153

Teaming

161

Politics

163

Preset Duration When the Boss Creates the Estimates

163 164

Summary

165

Case Study

165

Review Questions

168

CHAPTER 6

Quality—How Good Does It Have to Be?

Before You Plan

169 170

Quality Standards Quality Policy

171 173

Planning Quality In

174

The Cost of Quality

180

The Cost of Conformance The Cost of Nonconformance

180 181

x

Contents

Teaming

188

Decision Log Forcing Conflict

Politics

190 191

191

Scenario: The Climber Scenario: The Digger

193 194

Summary

194

Case Study

195

Review Questions

206

CHAPTER 7

Communication—What Do You Think About My Project?

Communication 101 Who Are the Recipients? Timing Is Everything Why Do This Communication? What to Communicate? Know Your Recipients—General Know Your Recipients—Special Handling

207 208 210 216 223 226 229 236

Teaming

248

Politics

249

Summary

251

Case Study

251

Review Questions

256

CHAPTER 8

Risk—What Should You Worry About?

What Is Your Risk Strategy?

257 258

Identifying Risk How Do You Gather Risks?

260 260

Not All Risks Are Created Equal

266

Impact Probability

Response Planning Getting Ready for Risks to Occur

Teaming

266 267

272 276

279

Contents

xi

Politics

281

Summary

283

Case Study

284

Review Questions

289

CHAPTER 9

Creating the Schedule

Pulling the Work Together Calculating Critical Path Calculating Critical Path for the TTR Project

291 292 293 298

Applying PERT Estimates

302

Assigning and Leveling Resources

304

Schedule Compression

314

Crashing Fast-Tracking Descoping

314 316 317

Understanding the Flow of the Work

322

Teaming

324

Politics

326

Summary

327

Case Study

327

Review Questions

330

CHAPTER 10 Budgeting—How Much?

331

Budgeting 101

332

Building the Budget

332

Reserves Fees

344 346

Reconciling the Budget

347

Budget Crashing Descoping

347 348

Cost Baseline

349

Teaming

350

Politics

352

xii

Contents

Summary

353

Case Study

353

Review Questions

366

CHAPTER 11 The Rhythm of Project Execution

369

All About Execution

370

Creating the Baselines

370

Getting into a Rhythm

373

Status Meetings Issues Management

The Work of Project Execution Types of Work Quality Audits

374 374

376 376 378

Teaming

380

Politics

382

Summary

383

Case Study

384

Review Questions

395

CHAPTER 12 Keeping the Project on Track Monitoring and Controlling Variance Variance Analysis Earned Value Technique Determining the Impact Corrective Action

Other Monitoring and Controlling Activities Controlling and Monitoring Project Risks Controlling and Monitoring the Product of the Project Monitoring the Implementation of Changes from Change Control

397 398 400 403 406 408

410 410 411 411

Teaming

412

Politics

413

Summary

415

Case Study

415

Review Questions

419

Contents

CHAPTER 13 Controlling Changes

xiii

421

The Concept of Change Control

422

The Process of Change Control

423

The Change Control Process Step by Step Change Tracking

424 431

Teaming

433

Politics

434

Summary

436

Case Study

436

VNLE Activities Going Well VNLE Activities Needing Improvement

Review Questions

CHAPTER 14 Success!—Closing the Project Preparing for Implementation Readiness Review Scope Verification Turnover

437 438

440

441 442 442 445 446

Closing the Project

446

Lessons Learned Celebrate!

447 449

Teaming

449

Politics

451

Summary

452

Case Study

452

Review Questions

456

Answers to the Review Questions . . . . . . . . . . . . . . . . . . . . . . . . . . 457 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471 Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479

This page intentionally left blank

Foreword Project management is a growing field. Take a minute to run a search on your favorite job hunting website with “project management” in the search field. You’ll find listings for thousands, even tens of thousands of jobs requiring project management experience. What I love about this topic is that it’s not limited to specific industries or professions. Engineers follow the same type of processes as real estate developers for completing a project. Each project starts with an idea, a plan is developed to describe the work, and then it’s carried out to fulfill the objective of the project. Along the way, the work is monitored and, when things stray, action is taken to bring the work back into compliance with the plan. The project management processes themselves are very similar, no matter what professions you work; of course, the actual work that’s performed varies from project to project and among industry areas. Unfortunately, project management is also one of those fields in which people tend to think that because they’ve performed a project at some time during their career, they’re a project manager. Or the boss decides to reward the best performer with a promotion, and the unlucky recipient finds himself floundering (likely for the first time in his career) because he doesn’t have a solid foundation of project management principles. That’s where Project Management for Mere Mortals comes in. Claudia has outlined the basics of project management in this book with real-life examples from her extensive career managing projects and teaching others about the topic. She has loaded this book with templates and checklists to help you hit the ground running on your next project. Whether you’re experienced at project management or not, you’ll find gold nuggets in Claudia’s book that you can apply immediately to your existing project. For example, every project requires a project schedule. Chapter 9 is of particular interest because it walks you through creating a schedule and determining the critical path in a step-by-step manner, with tips for quickly calculating the forward and backward passes. Enjoy Project Management for Mere Mortals, and good luck in your project management endeavors. Kim Heldman, PMP CIO for the Colorado Department of Natural Resources and best-selling author xv

This page intentionally left blank

Preface

Whether you think you can or think you can’t: either way you are right. —Henry Ford

I started my career in project management many years ago, when a wise woman I worked for said she had heard about a new discipline called project management and thought I should go to a class and check it out. I signed up for the class, called “Government Project Management.” On the first day, I walked into a room of 19 men in military uniform. I was the only woman and the only person from the private sector. When I was finished with the class, my organization decided that I was now a project manager and gave me a very complex project to run that included changing more than 500 software modules from all parts of the organization. I delivered the project three months late and well over budget. My career continued on, with me learning from the school of hard knocks until 1995. In 1995, I attained my Project Management Professional designation from the Project Management Institute, and also received a Master’s Certificate in Program Management from Denver University. These two accomplishments changed my career and my outlook on project management. Since I’ve received those two designations, I have never missed a triple constraint on a project for which I was the project manager. Now, I can’t say that I didn’t negotiate a new date, a new MOP, or a new budget since then. But my client or sponsor willingly agreed to the change based on what was best for the business and the project.

What Is This Book About? This book contains my knowledge gained over the years, as well as the knowledge of my friends who are great project managers. It covers the basics of good project management built on the good practices in The Guide to the Project Management Body of Knowledge (PMBOK Guide). It also covers tried-and-true techniques for making projects work—and work well. xvii

xviii

Preface

The book is organized by chapters that cover specific topics of project management. For example, Chapter 6 is all about project quality. But each chapter also has five sections for you to use. The first several parts of every chapter explore the mechanics of project management specific to the topic at hand. You will encounter processes, tools, and techniques that you can use to successfully deal with that topic on your projects. The next section in each chapter deals with the human resources on your project. How do you get your project team to work with you to create the objectives of the project? How do you build an atmosphere of success in which people want to work? Following the human resources section is a section that covers project politics. Throughout my career, I have worked very hard to deliver good projects. But I always had the feeling of being a salmon trying to swim upstream. It was never easy because of the politics in my organizations. In the politics section, you’ll investigate techniques for establishing a good offense for project politics, as well as learn what to do when a good offense is not enough. Each chapter has a case study section. This case study introduces our project manager hero, Chris Williams. You’ll watch as Chris uses the tools and techniques introduced in the chapter, as well as those you learned about in previous chapters. Finally, each chapter includes a set of review questions that cover the most important tools and techniques covered in that chapter. You’ll find the answers to the review questions in the Appendix. A unique feature of this book is the collaboration between this book and Microsoft Project for Mere Mortals, by Patti Jansen. These books were developed in conjunction with each other. Based on that collaboration, when you read about a topic described in this book, you can go to Patti’s book and see how you would handle the same topic in MS Project. With the two books, you’ll have everything you need to manage your next project using sound tools and techniques and MS Project.

Who Should Read This Book? The original intent of this book was to be a beginning project management book. Through the development, though, I’ve come to realize that facets of it apply to many different levels of experienced project managers. My reviewers

Preface

xix

have confirmed that they learned about new tools and techniques, even though they have been project managers for many years. Here’s a synopsis of what is available for each of you.

New Project Managers As a new project manager, you will find the basics of your craft covered in the pages of this book. As you get deeper into your newly chosen profession, you’ll find that some projects need more rigor than others. I have noted throughout this book where you should apply the different processes described. You’ll find techniques that you can use now and some that you will probably decide to use later in your career, as you get better at your craft.

Intermediate Experienced Project Managers You’ve managed a few projects, and things are getting better with each one. You are looking for a way to make a quantum leap to completely successful project management. This is the book for you. Here you have the opportunity to review what you do against the processes of this book. You can refine your own processes based on what you find here. Besides, with the time it takes to manage a successful project, you probably haven’t had the time to spend on the politics that are surrounding you. Here’s your opportunity to tackle some of those tough subjects in one book.

Experienced Professionals As an experienced project management professional, you have honed your craft and grown to be a really good project manager. However, you might find a few areas of your profession that need a little work. You’ll find a myriad of sound techniques in this book to warrant your time. Also, the book has been organized to enable you to find exactly the topic you are looking for, with specific ideas on how to handle that situation.

How This Book Is Organized The book is structured around project management topics. I start with a chapter defining some of the concepts of project management. But from the next chapter on, the book covers the topics in the order of planning activities: executing, monitoring, controlling, and closing. It looks as if the structure is

xx

Preface

sequential and that you must read the book start to finish. However, you can zone in on a specific topic and read about, for example, how to handle project risks from a planning perspective. Here’s what each chapter covers: • Chapter 1: “Setting the Project Management Context” This chapter establishes the structure of project management. I cover some of the fundamental definitions you should know. In the “Teaming” section, I cover the fundamental skills you should possess to effectively manage your team. And in “Politics,” you explore the overarching political environment in which a project manager works. • Chapter 2: “You’ve Been Assigned a Project!” This chapter is all about starting a project successfully. You’ll explore project initiation and the preliminary documentation that must be produced at the start of the project. A new concept, Measures of Performance, is introduced here. MOPs are a terrific way to get clear about the results of the project. In “Teaming,” you investigate how to get the best people assigned to your project.“Politics” covers planning for the politics that lie ahead. • Chapter 3: “How Big Is This Project?” You start this chapter by defining the scope of the project. Basically, that means asking this multipart question: How do you progressively elaborate the MOP to create the scope, the work breakdown structure, and the order of magnitude estimates for the project? A major element of the scope statement is product requirements, which I also cover here. The “Teaming” section is concerned with successfully getting the key players engaged in the work of the project. It also covers how to get people to work for you effectively when they don’t report to you on paper. In the “Politics” section, you’ll read about building alliances, who to target for alliances, and how to successfully create confidence in your project. • Chapter 4: “Laying Out the Work” This chapter continues the work of progressively elaborating the work breakdown structure. In it, you use the work packages to create activities or tasks. Then completion criteria are applied before the WBS is transformed into a network diagram. One of the tools and techniques used in the “Teaming” section is called team norms. I expand on this topic in the “Politics” section and talk about the rules of engagement when working with executives.

Preface

xxi

• Chapter 5: “The Art of Estimating” This chapter provides everything you need to successfully create estimates. It explores the different types of estimates as well as the different estimating techniques. In the “Teaming” section, I spend some time looking at a technique you can use to build the team while you get estimates created. The “Politics” section covers how to deal with a boss who creates estimates for you. • Chapter 6: “Quality—How Good Does It Have to Be?” Most project management references don’t spend a lot of time on project quality. This book devotes an entire chapter to the subject. The chapter covers quality from the moment you plan quality into your project, all the way through the concept of the cost of quality. In the “Teaming” section, you’ll concentrate on the Storming phase of project team development. In the “Politics” section, you’ll learn how to use the same quality concepts to enhance your interactions with your executive team. • Chapter 7: “Communications—What Do You Think About My Project?” It is time in this chapter to move into one of the most important planning elements that must be completed for your project: planning your communication. I introduce a communication template that spells out the “who, what, when, where, and why” of communication. After you have stepped through the entire template, you will see how you can effectively apply communication to your project team. I also cover some special tactics that you can use when your executive sponsor has lost interest in the project. • Chapter 8: “Risk—What Should You Worry About?” In this chapter, I spend some time laying out a methodology that is easy to use yet effective when dealing with risk. You can easily modify this strategy, depending on the size of your project and the rigor you want to apply. In the “Teaming” section, I talk about the project pessimist and how this person can really help you effectively plan the risks of your project. In the “Politics” section, the discussion revolves around how to let your executives know about project risks before they happen.

xxii

Preface

• Chapter 9: “Creating the Schedule” This chapter introduces tools and techniques that help you pull together your schedule and meet the project end date that the project sponsor requested. The “Teaming” section explores how to get commitment on project work and move through the stages of team development by doing project scheduling work together. In the “Politics” section, I talk about setting the stage for success or running into possible problems. • Chapter 10: “Budgeting—How Much?” I explore the last planning activity in this chapter, budgeting. I cover building the budget, including all the components that make up the budget, through reconciling the amount you’ve been given with what you actually need. In the “Teaming” section, I cover rewards and recognition. I explore a technique that doesn’t cost much but that works incredibly well to motivate the team. In “Politics,” I discuss the importance of executive education, as well as how to sell budgeting best practices to your executives. • Chapter 11: “The Rhythm of Project Execution” You will be amazed in this chapter by the activities that are be required for you to complete the execution of your project. I explore each thoroughly, along with what it takes to build a rhythm. The “Teaming” section covers the importance of training the project team; the “Politics” section investigates how to deal with some executive personality types that you might have seen in your career. • Chapter 12: “Keeping the Project on Track” I explore some important topics in this chapter: variance and the earned value technique. When you understand these concepts, you can explore how to determine the impact of the variances and take corrective action. The “Teaming” section covers the behaviors that you want to find, reward, and encourage in your team members. The “Politics” section addresses rumor control and your strategy for handling rumors.

Preface

xxiii

• Chapter 13: “Controlling Changes” Chapter 13 covers the concept of change control. I explore a changecontrol process step by step so you will know how to construct your own effective process. You’ll find that change requests are disruptive to the project team. This chapter explores tools and techniques in the “Teaming” section to combat those disruptions. In the “Politics” section, I discuss how to work with a Change Control Board (CCB) to get the right decisions needed for your project. • Chapter 14: “Success!—Closing the Project” This chapter covers the activities that you perform just before the end of your project. You’ll spend time planning the end of the project, conducting a readiness review, verifying your deliverables, and, finally, turning over the project to operations. I also cover the last set of activities that you perform to close the project, archiving the project documentation and gathering lessons learned. In the “Teaming” section, I cover a situation that I call the 95 percent phenomenon. I give you some practical ways of getting the team motivated to complete the project. In the “Politics” section, I discuss how to blow your own horn—tactfully and gracefully. The book finishes with an appendix,“Answers to the Review Questions,” a glossary, and a bibliography. The appendix contains the answers to the review questions at the end of each chapter.

About the Opening Quote I started this preface with a quote from Henry Ford. In it, he says that success is all about attitude. Project management is a discipline that you can learn and execute well. But the basis of your success is really all about your attitude. If you hold to the vision “think you can,” you will. You will find solutions. You will find mentors. You will find reference books that guide you though the ins and outs of project management. My hope is that this book becomes part of your success.

This page intentionally left blank

Acknowledgments How do you go about thanking the people who have been instrumental in getting a book created and out into your audience’s hands? It might be difficult to put my gratitude into words, but still I’ll try. First, I’d like to thank Elizabeth Hurley Peterson, Senior Editor at AddisonWesley, for giving me the opportunity to write this book. Working with Elizabeth was so much fun. She inspired me to take on this book by myself and helped me create the vision for what it would be. She then decided to leave and run a small project of her own: giving birth to twins! Karen Gettman, Editor-in-Chief, then picked up where Elizabeth left off. She was incredibly patient with my endless questions, even though she must deal with hundreds of people every day. She kept me focused on the goal. Karen then brought in project editor Kristen Erickson Weinberger, who brought me down to the finish line. Kristen is a terrific project manager in her own right. She kept me steered in the right direction and kept encouraging me to completion. Between Kristen and editorial assistant Romny French, I had my own cheering section that kept me motivated and excited about getting this book to the market. Next, I’d like to thank my reviewers. First, my developmental editors, Chris and Susan Zahn: Your suggestions were incredible and really improved the entire book. You never ceased to amaze me with what you knew and how helpful you were to get me to a better way of presenting my material. Next, I’d like to acknowledge my expert review team: Lisa Marie Jacobsen, CAPM Kaaren A. Walsh, PMP Janene A. Luders, PMP Kim Heldman, PMP Larry Bull, Product Manager You provided a wealth of feedback and insights. Some of your insights made me realize the marketing potential for this book and its potential audience.

xxv

xxvi

Acknowledgments

There were even times you kept me in stitches with your comments. All of your work was greatly appreciated. The next set of acknowledgments go to the production team at AddisonWesley, specifically Lori Lyons, Krista Hansing, Cheryl Lenser, and Nonie Ratcliff, for their expert eyes and commitment to get this book out in time and in perfect shape. A special thanks goes to Patti Jansen, author of the companion book Microsoft Project for Mere Mortals. I’m so glad we took this journey together. I don’t know what I would have done if I hadn’t had someone like you to talk to when the going got rough. Finally, to my husband Doug, for his unending patience and sacrifices that he made so I could do this work. Your comments, suggestions, and organizational skills really helped me in finishing this book. Your help and support has been invaluable.

About the Author Claudia M. Baca, PMP, PMI OPM3®, Certified Assessor/Consultant, has been active in the project management industry since 1984 and has project management experience in the information technology, telecommunications, and e-commerce industries. During her long and varied career, Claudia has managed multiple mission-critical projects for companies as varied as a major telecommunications company to an Internet start-up company. She most recently was the vice president of Consulting Services for a nationally known project management consulting firm. Currently, Claudia is an independent consultant focusing on project management consulting and training. She lectures for the Project Management Institute’s Denver chapter, as well as teaches for Colorado State University and Denver’s Front Range Community College. Claudia was a member of the leadership team that produced the standard for Project Management Maturity, OPM3, and is currently working on the second edition of that standard. She has a Master’s Certificate in Program Management from Denver University and earned her PMP in 1995. Claudia is also an experienced writer and technical editor. She coauthored the paper “Organizational Project Management Maturity Model (OPM3)”, presented at the PMI Global Congress Europe in 2003. She coauthored the paper “The Past, the Present and the Future of OPM3,” presented at the PMI Global Congress North America, 2004, and also coauthored “OPM3—The Path to Organizational Achievement of Strategic Business Improvement,”presented at the PMI North American Congress in October 2007 in Atlanta, Georgia. In addition, she is the technical editor of the PMP Project Management Professional Study Guide and the IT Project + Study Guide, and is the coauthor of PMP Project Management Professional Workbook, all published by Sybex. In 2005, Claudia published the Project Management Spotlight on Change Management in March and the PMP Project Management Professional Study Guide Deluxe Edition in August, both by John Wiley Publishing. Her first work for Addison-Wesley is Project Management for Mere Mortals, in 2007.

xxvii

xxviii

About the Author

Claudia was the first person to be certified by PMI® and Det Norske Veritas (DNV) as a PMI Certified OPM3® Assessor and Consultant. She has assessed and improved project management maturity in organizations ranging in size from a nuclear power plant to a 50-employee telecommunication networking company.

1 Setting the Project Management Context Getting something done is an accomplishment; getting something done right is an achievement. —Anonymous

Topics Covered in This Chapter Concepts Teaming Politics Case Study

This chapter establishes the structure for the rest of this book by laying out some of the defining concepts of project management. The first section begins by defining projects and project management. It includes a discussion of what makes a project versus what constitutes daily operations. Next, you will learn about your role as the project manager. You will discover the types of things you will do as a project manager. You’ll also identify the types of skills you will need to be successful. A discussion of organizational structures and how they can impact a project and a project manager’s success follows. You will learn about the different types of structures and the types of challenges that each structure poses to a project manager. The last topic in the first section is life cycles—specifically, the life cycle for project management. One of the main concepts discussed is the product that your project is creating. You must understand the product life cycle and how it works in conjunction with the project management life cycle. After laying the groundwork, the chapter finishes with two more topics: teaming and politics.

1

2

Chapter 1

In the section on teaming, you will learn about the specific skills you need to set up an effective team to work with you on your project. This section covers the ups and downs of working with other humans (a necessary evil!). The section on politics discusses the overarching political environment in which a project manager works. As you step though the rest of the chapters, you’ll learn about specific things you’ll need to do to manage the politics around you. Last but not least, this chapter ends with a case study that runs throughout the book. The case study introduces you to our project manager hero, Chris Williams, and the issues she faces as she starts a project. In each chapter, you’ll see how she incorporates what was covered in that chapter and previous chapters into her project.

Concepts Any discussion of the basic concepts of project management must begin with a definition of project management.

What Is Project Management? You’ll find a definition for project in every project management textbook that you pick up. Everyone has his or her own spin on this definition. A project is basically a unique endeavor that has a beginning and an end. That’s a pretty broad statement, but if you think about it for a minute, it really says a lot. Unique … that means it’s something that has never been done. Is writing a book a project? You bet! (Unless you want to get arrested for plagiarism!) Is your wedding a project? Yes, even if you get married more than once—each event is a project. Even though endeavors can be similar, their uniqueness makes them a project. The ultimate reference for project management is the ANSI standard, A Guide to the Project Management Body of Knowledge, or the PMBOK® Guide. The PMBOK® Guide defines a project as “the application of knowledge, skills, tools and techniques to project activities to meet project requirements.” Let’s inspect the rest of our definition,“has a beginning and an end.” Are you doing project management work if you’re working in an insurance office and you take claims every day? Probably not. The nature of the work has you doing the same thing every day, which could be considered day-to-day operations. Operations are ongoing or repetitive activities, whereas projects are

Setting the Project Management Context

3

constrained to end. Now, if they asked you, the claims administrator, to lead an effort to implement a revised method for answering calls, you would be doing project management. By our definition, the revised method is a unique endeavor and has a beginning; it will have an end when each claim administrator is trained in the revised method. Now you know the definition of a project. What is the definition of project management? Again, you’ll find that every textbook has a definition. Generally, though, project management is the act of managing an endeavor to bring it to the required results. Let’s break down this definition a little more. The words “required results” mean that you have worked with the organization, or the project sponsor (I talk more about project sponsors in the next chapter), to define the project deliverables or results. You’ve also worked with the sponsor to determine exactly what results are acceptable—or, in other words,“required.” Getting back to our definition of project management, the word management is used here to describe the planning, monitoring, and controlling activities that must be put into place for the project to reach its required results. Most of this book takes you through those processes step by step. The book also addresses the management skills needed for success.

Management Skills Wonderful books and articles on the market discuss management skills and management theory. As you hone your skills as a project manager, you might want to consider buying one for your reference shelf. One of my favorites is a quick read and a reprint from the Harvard Business Review (no. 922II): Managers and Leaders:Are They Different? by Abraham Zaleznik.

Now that you know the definition of both a project and project management, it’s time to talk about the project manager, the role you are now going to step into.

Role of the Project Manager I’ve seen jokes about self-centered people that describe the world revolving around that person. Well, joke or not, that is really the role of the project manager: The world of the project does revolve around the project manager.

4

Chapter 1

Figure 1.1 shows the elements of a typical project that all hinge on the project manager’s role. Let’s examine each of these roles. Risks Quality Deliverables Communication Schedule

Documentation

Customers

Scope Budget Processes Team members Vendors

Figure 1.1 The elements of project management.

Communicator Most project managers will tell you that most of their work hinges on their ability to communicate. In fact, some project management references state that a project manager will spend 80–90 percent of their time communicating; this is one of the strongest and most important skills a project manager must have. All communications flow from and to the project manager. The project manager communicates the work to be done to team members and lets interested parties (such as sponsors, stakeholder, and customers) know the status of the project, issues, and requested changes. Analyst The project manager’s role includes managing risks. Remember, the objective here is to deliver the required results. Project managers assess the possible risks. They analyze how to accept, avoid, remove, or mitigate those risks to ensure delivery. Strategist The project manager determines the best way to deliver the required results. Sometimes the best approach is delivering the results a step at a time. The

Setting the Project Management Context

5

incremental or phased approach requires that the project manager build several “what if” scenarios and determine which strategy will deliver the required results in the time frame requested and within the budget provided. Coordinator The project manager acts as a coordinator when working with the team to create the product of the project. The project manager seeks to instill a rhythm into the work, to ensure that hand-offs are smooth and that the work flows well from person to person. Documentor As you learn more about the project manager role, you will come to realize that a major portion of a project manager’s job involves documentation. The project manager cannot depend on verbal communication as the only means of communication. He must create documents to plan the project, reports to show the status; and capture the lessons he and his team have learned so that they can be shared with future teams. These are but a few of the types of documents that are created in the course of a project. Problem Solver The project manager takes on the role of problem solver and must figure out a way to reconcile differences to get things done. He must be persistent and tough minded, must demand hard work, and must foster goodwill among team members. Manager The project manager works to manage the efforts of the team. With that role comes the responsibility to coach team members, manage their performance, and create performance reviews. Leader One of the most important roles of a project manager is that of leader. Of course, the role of manager is important, but it must be balanced with strong leadership. Leadership entails motivating and inspiring team members to achieve the challenges before them. Leaders build an environment that is conducive to success. They establish goals and evoke images of what success looks like. With the role of the project manager defined and the definitions of a project and project management established, you are now ready to read more the hierarchy of project management. (You’ll find more information about the

6

Chapter 1

project manager’s role in relation to interacting with the team in the upcoming “Teaming” section.)

The Hierarchy of Project Management Hierarchy? I’ll bet you thought project management was a stand-alone discipline that is effectively used to deliver projects. Well, it is, but it also is part of a larger network of management discipline that organizations use to deliver their strategy. Figure 1.2 shows the hierarchy of project management. Let’s discuss each aspect of this hierarchy and how it relates to projects, starting at the top.

Organizational Strategy

Portfolio

Program

Projects

Figure 1.2 The hierarchy of project management.

Organizational Strategy The executives of an organization establish the strategy of the organization. This strategy might be increasing revenues, cutting costs, opening a new market, or introducing a new product. Most organizations go through this

Setting the Project Management Context

7

type of exercise each year to determine what they want to achieve. Some organizations are much less formal about establishing this strategy. I worked with a company once that produced financial graphs for other companies. The organization accepted every piece of work that was offered to them at an acceptable price. The employees complained that there was no corporate strategy. What they failed to realize is that accepting every piece of work was the corporate strategy. This organization wanted to establish itself as a “can do” organization. They also were trying to build relationships with each of the companies bringing them work. They had a strategy; it just wasn’t a formalized process. Anyway, this corporate strategy is the input into the project management hierarchy. The strategy drives the formation of portfolios, programs, and eventually, projects. Portfolios A portfolio is a grouping of programs and projects that the organization works in concert with each other. The organization builds the portfolio to manage the goals of the organizational strategy effectively. The Standard for Portfolio Management defines portfolio management as “the centralized management of one or more portfolios, which includes identifying, prioritizing, managing, and controlling projects, programs, and other related work, to achieve specific strategic business objectives.” As an example of a portfolio, imagine that a cell phone company has decided to be a leader in its field and builds a portfolio to manage the entire product’s operation. This portfolio aims to manage the research and development of the company’s product set. It might include a program that contains a set of enhancements for existing cell phones. It might have a project or two that are concerned with the latest, newest, and greatest features of new cell phones. The portfolio might even include a project that builds prototype phones of the future. The portfolio exists to manage the entire product set. In managing the portfolio, the portfolio manager or executive starts new projects because of the current market conditions and stops projects when that product or enhancement is no longer needed. The manager constantly prioritizes the work based on the market conditions. Programs A program is a grouping of related projects that are being worked in concert with each other, to realize certain benefits. The Standard for Program

8

Chapter 1

Management defines program management as “the centralized coordinated management of a program to achieve the program’s strategic objectives and benefits.” For example, imagine that a nonprofit organization has several fundraising projects worked together in a program. A program manager oversees the efforts of the separate project managers. This program manager makes sure that the anticipated level of funding is achieved through the program. This funding level matches the nonprofit’s strategy regarding funding. You can also see how the corporate strategy feeds into the program. Projects You have already read about the definition of a project and project management. This is the lowest level of the hierarchy. You’ve seen from the other two levels that the discipline of delivering a single project successfully is vital for an organization to deliver on its strategy using project management. Projects are the glue that holds the entire hierarchy together. PMO Although Figure 1.2 does not depict a PMO, it is also a core element of the project management hierarchy. A PMO sometimes stands for project management office, program management office, or portfolio management office, depending on what level the office has been established. A PMO is a central office that manages the workings of the project management hierarchy. PMOs can have many functions, but they mostly do some or all of the following: • Report on the status of projects, programs, and portfolios • Create project management standards that are used throughout the hierarchy • Act as a resource pool for experienced project managers that are used throughout the hierarchy • Allocate resources across the entire portfolio When you are assigned a project, you must figure out where your project sits within the project management hierarchy. It’s like the map at the mall that says “You are here.” Knowing this will help you to deliver according to the organization’s strategy, and you will understand the context of what you are trying to achieve with your project.

Setting the Project Management Context

9

Organizational Project Management If you are intrigued by the concept of the project management hierarchy, you’ll want to check out a new standard from the Project Management Institute, the Organizational Project Management Maturity Model (OPM3®). You can get more information on this standard at www.pmi.org.

Organizational Structures This section continues to paint the picture of “you are here” by now talking about organizational structures. When you work on a project, you want to understand the reporting structure of the organization. This reporting structure will impact how you work and possibly how much authority you’ll have as a project manager. Let’s inspect the different types of structures. Figure 1.3 shows the first structure, a typical functional organization. In a functional organization, the project manager could work in any of the departments of the organization and manage team members in any other part of the organization.

CEO

CFO

Team member

CIO

VP R&D

COO

Team member Team member

Figure 1.3 A functional organization.

Department Head

Department Head

Team member

Project manager

Team member

Team member

10

Chapter 1

In this figure, the project manager works in Operations and is managing team members in Finance and Information Technologies, as well as other people in his own organization. This structure can be quite challenging for the project manager because it is sometimes difficult to manage people in other organizations; the project manager is seldom given enough authority to really manage the people from organizations other than their own. People generally follow whoever controls their pay and bonuses. In this type of structure, the project manager is rarely given the opportunity to really manage—which means controlling pay and bonuses. Special considerations should be applied with a project manager in this type of an organization. I talk more about these special considerations in the “Teaming” section of Chapter 3,“How Big Is This Project?.” The second type of organization you need to understand is a projectized organization, shown in Figure 1.4.

CEO

COO

Department Head

VP R&D

Department Head

Staff

Staff

Staff

Staff

CIO

PMO

VP Project Management

Project Manager

Project Manager

Team member

Team member

Team member

Team member

Team member

Team member

Team member

Figure 1.4 A projectized organization.

We should all be so lucky to work in a projectized organization! In this type of organization, the leaders have realized that strategy is delivered via project management. The organization is built to support this strategy. When a project is launched, the right project manager is selected from the project management pool, and the team members are actually moved into the project management organization for the duration of the assignment. During this

Setting the Project Management Context

11

project, the project manager is their only boss, who controls their salary and bonuses. The PMO sets the standards, and all project managers follow those standards to the letter. This type of organization provides the ultimate support for project managers. Now, all sorts of variations in organizational structures exist between the projectized and functional organizations. The key for you is to identify the type of organization that you are working in and build the proper authority for yourself so you can succeed. Let’s move on to the last part of the project management structure: the project management life cycle.

Life Cycle Projects have a definite beginning and end, so they lend themselves to description as a set of phases or life cycle for the work of a project. Basically, the life cycle describes the stages of development that a project normally goes through to reach completion. Two types of life cycles exist: the project management life cycle and the product management life cycle. Project Management Life Cycle The PMBOK® Guide describes five key process groups that govern the work of project management: initiating, planning, executing, monitoring and controlling, and closing. These processes have a natural progression inherent in the work, and they must be used in conjunction with a life cycle that covers the phases of the project. The life cycle or phases that you choose should reflect the type of work being performed. Figure 1.5 depicts a generic life cycle. Feasibility

Planning

Construction

Turnover

Time

Figure 1.5 A project management life cycle.

In a project management life cycle, the work is divided into the following phases:

12

Chapter 1

• A feasibility phase, in which the initiating processes are completed • A planning phase, in which the planning processes are completed • A construction phase, in which execution and monitoring and controlling processes are completed • A turnover phase, in which closing processes are done Product Management Life Cycle The other life cycle that you should be aware of is the product management life cycle. Every project creates and delivers something, called the product of the project. Most times, that is an actual product, such as a new cell phone, a software system, a research paper, or a garage. Each product has its own life cycle that must be understood for the project life cycle to work correctly. The product management life cycle includes preliminary phases, such as business planning. When the business plan is set, product management is transferred to the project management life cycle for the product to be created. When the project completes, the product is transferred back to the product management life cycle. The product is placed into ongoing operations, and when it is no longer needed, it goes through a sunset phase, in which it is decommissioned. These two life cycles intersect at the proper points in time. This discussion on life cycles completes your orientation on the structure of project management. Let’s move on now and see how effective teaming is established.

Teaming One of the hardest areas of project management is actually managing the humans on the project. This book covers this area as a special topic throughout the chapters. Each chapter starts with the mechanics of project management and then deals with the human resource relations that make the mechanics work. So far, this chapter has introduced definitions and established context; this section does the same with the concept of teaming. This section covers the interpersonal skills you need to effectively manage a team of people. If you are not a good manager, you won’t be a good project manager. It takes a special set of interpersonal skills to effectively manage a group of people. The better these skills, the better your success will be. The following subsections cover a few of the interpersonal skills you need.

Setting the Project Management Context

13

Empathy Yes, you need empathy. Your ability to connect with the people who work for you is an important interpersonal skill. The more you connect with your team members and the more you show concern for team members as people, the more loyalty your team member will have for you.

Negotiation You will have many opportunities to demonstrate your negotiation skills when working with team members. Sometimes the project approach will be questioned by the team members, and they will have different ideas on how to proceed. You will need to negotiate to find the right method for moving forward that uses the best path for the good of the project without losing the commitment of the team members.

Influencing Your ability to influence others will be tested daily. Influencing is really all about “getting things done.” You will constantly be influencing your team members to make the right choices on behalf of the project: working that hour of overtime, getting along with a team member that they really don’t care for, and doing other things they might not want to do. A colleague of mine describes the influencer as the “compass” for the project. The project manager keeps the team pointed in the right direction, always influencing the team related to the project’s goals.

Walking the Talk One of the team-building activities I talk about in Chapter 4,“Laying Out the Work,” is using team norms. Norms are a set of rules that you and your team members agree to abide by in your dealings with each other. It is essential that you always follow the norms you establish. Say, for example, that you have a team norm to always confront other team members regarding a problem instead of talking about it or them behind their back. You must walk the talk and follow the norms to the letter. People will look to you to see how serious the team will be about following the norms.

Ego in Check There’s a time and a place for everything in life. Sometimes you can pat yourself on the back for a job well done. Just remember that you are not a

14

Chapter 1

successful project manager without the team that supports you. You are not a one-man show; you are a team. If you can’t keep your ego in check, you will alienate your team members. Teaming is covered as a special topic in every chapter. This list of interpersonal skills is just a start in getting you ready for managing your team.

Politics Have you ever worked at a company where you watched a perfectly good project manager’s reputation get trashed over a late delivery or a bad decision? I’ve watched a few of my friends go through this painful process that left them scratching their heads about what went wrong. Every chapter of this book covers the politics of project management. Each chapter begins with the mechanics of project management and the teaming elements, and then finishes with how to prevent or combat politics on your project. I worked with a very smart woman several years ago (let’s call her Ginger) who was an expert at making sure others knew what she wanted them to know. Ginger had just taken over a team of people and was replacing a manager who was removed because of poor performance. Every time I ran into her, I asked her how the new assignment was going. She would take about five minutes and tell me this: • This team of people had some major work problems. • The last manager was doing a very poor job. • She, Ginger, was really changing things for the better. She reiterated these points several times in that five-minute time period. She gave me the same elevator speech the next time I ran into her. I ran into another friend of mine sometime later and I asked if she had talked to Ginger. She said yes and covered the exact three same points almost verbatim to what I had heard. Another week passed, and I was talking to the vice president of the department. He asked if I had talked to Ginger lately. I said yes and, without hesitation, covered the same three points. I caught myself in the middle of this dissertation and realized how effective Ginger was at making sure everyone talked about her the way she wanted us to talk about her. She was an expert at her own public relations. Ginger was promoted several times and finally left the organization as a vice president. From an ethical

Setting the Project Management Context

15

standpoint, I really had a problem with that the way Ginger bad-mouthed her predecessor. But I had to admire the effectiveness of her routine. The whole point here is you are the public relations manager for your own project and your own career. You need to make sure that people hear what you want them to hear about you and your project. I believe you can do it in such a way that you won’t feel as if you have compromised your ethical standards. But you still need to plant the seeds. When dealing with politics, the best defense is a good offense. Start by taking on this role of PR manager. As you step through the rest of this book and learn the mechanics of project management, you’ll also learn the mechanics of being a PR manager.

Summary In this chapter, we established the structure for the rest of this book. We laid out some of the defining concepts of project management. We defined both a project and ongoing operations. Then we defined your role as the project manager. We also listed the types of skills you need to succeed. We then defined organization structures and life cycles, and looked at how they can impact a project and a project manager’s success. In the section on teaming, you encountered the specific skills you need to set up an effective team to work with you on your project. And in politics, you encountered Ginger and saw effective and not-so-effective means of becoming your public relations manager on your project. Now let me introduce you to our case study. This same scenario is used throughout the rest of the book. Our project management hero incorporates the topics covered in each chapter into her project for the Virtually Nostalgia Company.

Case Study Chris Williams was sitting at her desk reviewing the lessons learned from her last project when she got the call from the CEO’s administrative person. It’s not every day that the CEO wants to talk to you about a new project. Chris was pretty excited about the call and knew she shouldn’t jump the gun on planning until after the meeting tomorrow. So instead of daydreaming about

16

Chapter 1

the assignment, she reflected on what she had learned so far while working at Virtually Nostalgia. Chris started with the organization about six months ago, when the company started up as a subsidiary of a larger organization that wanted to exploit the retail nostalgia market. Virtually Nostalgia had built up its inventory of vendor products and plans to publish its catalog and launch its website in about nine months. Chris had successfully managed various small projects for the organization and looks at this new project as an excellent opportunity for her to demonstrate her capabilities to everyone in the organization. Even though her last project was successful, it was also a struggle because she hadn’t really done her homework. Sure, she knew what the point of the project was, but she failed to understand where her project fit into the project management hierarchy. She found out about halfway through the project that she was part of an overarching program. She had failed to talk to her program manager about expectations for her project. A couple key elements were missing from her delivery. But Chris has excellent teaming skills and, because of that, was able to motivate her team into taking on those additional critical elements. Another point that Chris missed was the fact that the PMO had established a project management life cycle that everyone was expected to follow. She was really embarrassed when she conducted her first project management review with the PMO and executive sponsor, and found out that her phases were named incorrectly. Chris also struggled with getting her team to work effectively for her. She had to work hard to connect to her team members, much harder than at the last company she worked for. She attributed this complexity to that fact that she was working in a true functional organization. She hadn’t made sure that she had set up the proper authority for herself in advance. Chris jotted down a few notes for herself and, since it was 5 p.m., decided to go home for the day. Going home at a decent hour is a real treat for a project manager. Chris knew that this next assignment could be very challenging and that she had better treat herself as long as she could. She looked forward to the meeting tomorrow and was glad it was set up for early in the morning.

Setting the Project Management Context

17

Review Questions 1. What is a project? 2. What is the difference between operations and projects? 3. What is the strongest skill a project manager must have that will take

80–90 percent of the time? 4. What is the input into the organizational project management hierarchy? 5. Why would an organization choose to use portfolio management? 6. Why would an organization choose to create a program? 7. Name one function that a PMO typically performs. 8. Name two types of organizations. 9. Which organization would a project manager prefer to work in? Why? 10. What two intersecting life cycles do you need to be aware of when

managing a project? 11. What are team norms?

This page intentionally left blank

2 You’ve Been Assigned a Project! An idea is a point of departure and no more. As soon as you elaborate it, it becomes transformed by thought. —Pablo Picasso

Topics Covered in This Chapter Chartering the Project Measures of Performance Preliminary Scope Statements Project Costs Starting the Project Plan Teaming Politics Summary Case Study

This chapter spends some time talking about how projects get officially launched via a project charter. It covers the formal and informal things that happen when you are assigned a project to lead. Next you’ll encounter a topic called Measures of Performance that describes the point of the project. This tool can really help define what success looks like when your project is completed. After that comes a discussion of preliminary scope statements, which are the beginning of the actual planning activities for a project. The section on scope statements also establishes how to progressively elaborate this planning until you are clear about what you are creating and how the work will progress on your project.

19

20

Chapter 2

The next topic is the costs of the project—specifically, the types of project costs and when to use each. At the beginning of the project, you will use very broad estimates. As you refine the project, your estimates will become clearer. The chapter then turns to project documentation. The first piece of major documentation that must be done on a project is the project plan. You’ll start that document in this chapter. After laying out these tools and techniques, the chapter winds up with the two other topics: teaming and politics. In the “Teaming” section, the discussion focuses on how you get ready for effective teaming. This is the beginning of the project. What do you need to do to make sure you get the best people on your team? The “Politics” section covers how to plan for the politics that are just ahead. What can you do to lay out a good offense so you don’t need a great defense? The chapter ends with the case study. In this section, you’ll find out what project Chris Williams has been assigned. You’ll watch her use the concepts laid out in this chapter and see if this project will define her career.

Chartering the Project Where to start, where to start? As the famous song goes,“Let’s start at the very beginning, a very good place to start.” Okay, okay you get the idea. You were walking down the hallway, and your boss was rushing past you and mentioned hurriedly that he has a new project for you. He tells you to schedule an appointment with him to discuss it. In some companies, this is the official beginning, or chartering, of a project. Each project should go through some type of authorization that tells the project manager it is okay to start working on a project. You’ll find chartering done very differently from organization to organization. Let’s examine some formal and informal approaches to chartering.

Formal Chartering One billing department I worked for years ago had a very formal process to authorize the beginning of a project. The organization felt that this type of rigor was warranted because several other departments depended on the

You’ve Been Assigned a Project!

21

billing department to put correct information on the bills and in the envelopes the bills were sent in. These are the steps they went through: 1. The marketing department created a document, a project charter, that

2.

3.

4.

5.

described the type of work the marketing department wanted done via a project. The charter included information about the business opportunity or the new product they wanted to offer and how it needed to be presented on the bill. The charter also included how much revenue they expected to generate with this product and, finally, how this project was tied to the corporate strategy. The billing department logged and reviewed the completed charter. The billing department then put together a high-level estimate of how long it would take to complete the work. Once a month, the billing department leaders and representatives from the other departments got together and reviewed all the charters they had received that month. They reviewed the tie to the corporate strategy, as well as the projected revenues for the charter. When the review was completed, they prioritized the list of charters. The functional leaders of the billing department reviewed the list of prioritized charters. They analyzed what work could be done based on the estimates provided and the prioritization. They created another list that showed what work could be done in what time frame. The billing department leaders and representatives reviewed and approved the final list. Then a project manager was assigned to each charter. The charters were forwarded to their project managers with the authorization signatures, and the project managers were authorized to proceed with the work.

Whew! That was a very drawn-out process. But again, the billing department felt it was necessary because more than 15 different clients were all competing for the same billing resources. This approach guaranteed that the work that got done was important to the strategy of the organization and brought in the most revenue possible for the company. You’ll see an example of a formal project charter in Figure 2.1. Now let’s look at a less formal approach.

22

Chapter 2

XYZ Corp Project Charter Document Project Name

Anticipated Start Date

Anticipated End Date

Assigned Project Manager

Business Need:

Currently the Customer Service Representative (CSR) organization conducts training for new CSRs. Depending upon the turnover rate, classes will start once a month or once a week. The length of the current class is three months. The organization needs the ability to get CSRs through this course in a more timely manner. Yet the organization is unwilling to sacrifice the quality of the training or the required customer satisfaction levels.

Project Description: This project is commissioned to analyze any and all means necessary to shorten the time required to train incoming customer service representatives. Once an approach is determined, executive management must concur with the approach.

Assumptions: 1. The project can be completed in 6–9 months. 2. The project can be completed for less than $500,000. 3. CSRs will pass the course at the same percentage that they do today.

Constraints: 1. The organization will not see a substantial increase in customer complaints because of the new training. 2. If a new computer system is required, the existing computer hardware will continue to be used.

Figure 2.1 A formal project charter.

You’ve Been Assigned a Project!

23

Informal Chartering In Chapter 1,“Setting the Project Management Context,” I mentioned a financial graphing firm I’ve worked with that accepts every piece of work that it receives at a reasonable price. The employees there complain that there is no corporate strategy and no chartering process in place. This company has nothing documented about how projects are initiated. Actually, though, the company follows a process for each phone call from a client. 1. The client calls the sales department and requests that a financial

graph module be created. 2. The sales department reviews the request and negotiates the price. When the price is acceptable, the sales manager calls the project management leader to turn over the piece of work. 3. The project management leader assigns the project to one of her project managers, who then calls the sales department to get the details of the project. This process is informal, yes, but the process has the components necessary to charter the project officially. The main point of both of these processes is that there is a moment in time at which the project is approved by the organization and the project manager is assigned. This official approval marks the beginning of the project. Project managers should be assigned to a project as soon as possible after the project has been chartered. Houston, we have a project. From here, you start getting clear about why this project has been commissioned and what the result is supposed to be. You start that process with the next subject, Measures of Performance.

Measures of Performance I worked at a company several years ago that spent several million dollars on a new computer system to assist customer service representatives in handling calls from customers. This new system was also replacing a similar computer system that ran on old hardware. The Vice President of Customer Service believed that the new system would reduce the time needed to train a customer service representative from three months to five weeks. The Vice President of Information Technologies believed that the new system would

24

Chapter 2

reduce system maintenance for his development staff by half. He thought he would get these gains because the new system was being developed in the latest and greatest software language. The Vice President of Computer Hardware believed that she would get to retire the old hardware because the new system required a brand-new hardware platform. I’m not quite sure what went wrong, but the new computer system did not meet its goals when it was completed. Rather than reducing the time to train a customer service representative, the new computer system increased training requirements because it did not completely replace the old computer system; it was designed to work in conjunction with the old system. The new system did not reduce the time required to maintain the computer code. The new computer language was more complex than the old language and took longer to work on. The developers who could write computer code in that language were more expensive to hire. Finally, the new system did not allow for the retirement of the old computer hardware platform because it was designed to work with the old system. The old system was removed only after the new system was completed and the customer service representatives had been trained and working on it for three months. The operations people just went in and removed it from the customer service representatives’ work stations. About a month later, the project manager was fired. I was in a different department at the time, but I remember the uproar this created. I could never figure out whether the project manager failed to learn the expectations of the executives or whether they had never communicated their expectations to him. Anyway, they still work there and he is gone. The lesson learned for good project managers is getting clear about why a project is being chartered. Why is the organization taking on this project? What is the point? A preventive technique I learned later in my career that might have averted this disaster is called Measures of Performance1 (MOP). MOPs are created to clearly define the expected business result of this project. It isn’t enough to deliver a computer system; the computer system must produce a business result. As you can see from the previous example, the project manager did not understand the business result that was supposed to be achieved. 1 My thanks to Wendi Peck and Dr. Bill Casey of Executive Leadership Group, Inc., who have done extensive work on Measures of Performance, for allowing me to use this concept in this book. I recommend reviewing their discussion of this concept in Chapter 92 of Business Driven Information Technology: Answers to 100 Critical Questions for Every Manager, by David Laube (ed.) and Ray Zammuto (ed.) (Stanford Press, 2003).

You’ve Been Assigned a Project!

25

Defining MOPs Let’s start with some definitions regarding MOPs. A good measure of performance consists of two parts: a driver and restrictions. These two elements work together to create a litmus test that everyone in the project can use to decide whether what they are about to do is the right thing for the project. The first element, the driver, provides a single statement that describes the business result that must be achieved. It is always described in measurable terms. It doesn’t describe the activities of the work; it sticks to the result or outcome of the work. If you think about the last example, this might have been a suitable driver for that project: Driver 1. Reduce customer service representative training time by more than 50 percent. or Driver 2. Reduce the customer service representative computer system maintenance by more than 40 percent.

or Driver 3. Retire the Atari customer service representative computer system hardware.

You’ll notice that all of these talk about a result that the project achieves. Whether you accomplish the assigned achievement is very clear because you can measure whether the work was done. All of these drivers are measurable. The first two define the acceptable accomplishment. They also show what you can do to improve upon that accomplishment—namely,“more than.” The last driver is black and white: Did you retire the hardware, or didn’t you? There isn’t any way to overachieve on this driver, but you can tell whether the achievement has been accomplished. Speaking of achievement, did you notice the use of that word in describing the point of the driver? Did you notice it was not words such as task or activity? You want to use accomplishments or achievements because you want the project manager and project team to come up with the most creative or elegant solution. Talking about achievements allows them to determine the best way to get the result you’ve requested. Sometimes it’s easy to confuse a lot of activity with real results. You get so caught up in the flurry of activity that you forget why you’re doing the work. An achievement driver keeps you focused on the point of the project.

26

Chapter 2

Also notice the lack of talk about “how” in any of these drivers. Telling the project team how to gain the achievement again restricts creativity. An example of a bad driver with a “how” in it might be something like this: Driver: By creating a new customer service representative computer system, reduce the customer service representatives’ training time by more than 50 percent.

There might be better solutions than a computer system for reducing the customer service representative’s training. The project team might decide that this is the best solution, but you want them to analyze all the possible solutions that will achieve this driver. Did you also notice the word OR in between the drivers? A project should be about a single achievable result. You are talking about more than one project if you have more than one achievement. Two drivers may indicate that you have two projects, which means that you should probably manage them together as a program. You might say that they could reduce the customer service representative training time while they retire the Atari hardware system. Well, you could, but when the project starts to slip and you need to make a decision on what to cut out of the project, which result will you abandon, the reduction in training time or the retirement of the hardware? To keep your focus clear, stay with one achievable result. The other element of a good MOP is the restrictions. A restriction is a boundary you must work within to succeed. Most things in life can be accomplished with enough time and enough money. However, most people don’t have unlimited resources to get a job done. The same theory applies here. If you are going to achieve a result, what limitations must you abide by to get the result achieved? The restrictions are the limitations on how you go about creating the driver or result, and they always relate to the result of the project. If you go back to the customer service representative example earlier, you might have settled on this driver: Driver: Reduce customer service representative training time by more than 50 percent.

You’ll want to determine exactly what boundaries you must stay within to achieve this driver. A good restriction might be this one: Restriction: Customer complaints do not increase more than 2 percent.

You’ve Been Assigned a Project!

27

With this driver and restriction, you might be able to cut some corners while reducing the training. But you can’t afford to cut too many corners; customer service complaints can’t be compromised. If you analyze the environment that the customer service representatives work in, you’ll find other restrictions that apply: Restriction: No increase in customer wait time. Restriction: Customer orders not delayed more than one hour.

I think you get the picture. The trick with restrictions is not to have too many of them. You want to make sure that a reasonable number have been applied to your driver, but make sure you don’t have more than three or four. More than that makes it impossible for the project team to get the work done.

MOPs and the Triple Constraints Managing a project is sometimes about trade-offs. You’ve heard people say that they want something delivered “good, fast, and cheap.”You’ve also heard the answer that you can’t have all three. I talk in terms of the triple constraints when it comes to project management. The triple constraints are the three parameters that are juggled through the execution of a project. You’ll see the triple constraints as time, cost, and scope in most project management textbooks. These three parameters describe the elements that you will juggle: the time of the project, the cost of the project, and the scope of the project. For example, your boss has asked you to lead a project to create a research white paper for an upcoming conference. The two of you have decided that the paper should be created in six months, at a cost of $25,000, with an agreed-upon scope. During the course of the project, your project team determines that $25,000 will not buy the amount of research needed to complete the paper. You go back to your boss and ask for more money. He says that no more money is available. If you can’t get more money, you either need to reduce the scope or elongate the schedule by losing one of your researchers. See how the three constraints work with each other for trade-offs? When you use Measures of Performance, you define the scope of the project to produce the result of the MOP; therefore, the MOP replaces the scope portion of the triple constraints. In Figure 2.2, the MOP is the third constraint with time and cost.

28

Chapter 2

COST $500,000

TIME 4th quarter

MOP D: Reduce CSR training time by more than 50% R: Customer complaints do not increase more than 2%

Figure 2.2 The triple constraints using MOPs.

With the triple constraints in mind, here is another point you’ll want to verify after you’ve decided on the right driver and the right restrictions. Have you embedded any information in the driver or restrictions about the cost of the project or the duration of the project? If you have, you need to remove them. Here’s what this would look like when done incorrectly: Driver: Reduce customer service representative (CSR) training time by more than 50 percent. Restriction: Customer complaints do not increase more than 2 percent. Restriction: By fourth quarter. Restriction: Without spending more than $500,000.

You can see that the time of the delivery of the project has been embedded in the restriction “By fourth quarter.” You can also see that the cost of the project has been embedded in the restriction “Without spending more than $500,000.” Putting the time and cost constraints into the MOP has removed them from the triangle. You’re now faced with a one-legged triangle with nothing left to negotiate, as depicted in Figure 2.3 You are not able to do trade-offs between the business result of the project with the time and the cost with the other two triple constraints embedded in your MOP. You are now accountable for delivering the MOP exactly as stated, with no negotiating room. If you had kept time and cost straight in

You’ve Been Assigned a Project!

29

your head and out of the MOP, you could still use them as negotiating tools. If the project is taking too long, you might increase the costs or reduce the business result.

MOP D: Reduce CSR training time by more than 50% R: Customer complaints do not increase more than 2% R: By 4th quarter R: Without spending over $500K

Figure 2.3 Nothing left to negotiate!

More about MOPs Another item that you will want to verify regarding your project’s MOP is its size or scope. Ask yourself the question “Can I be held accountable for all of this business result?” For example, imagine that you are in the Training department at your company. Your executive has asked you to put together a project that will increase customer satisfaction. You’ve decided that this MOP is right: Driver: Increase customer satisfaction by 5 percent. Restriction: Without increasing headcount.

You realize that you can impact customer satisfaction with the way the customer service representatives are trained. But your training is only one small aspect of customer satisfaction. The other elements include things such as the quality of the products you sell and whether the installer is on time. You know that you cannot impact these other areas of customer satisfaction based on your level in the company and your position in the training department. When faced with this dilemma, you should reduce your MOP to something you really can be held accountable for, something you can really impact. A better MOP for your project would be this one: Driver: Student exam results for satisfactory interaction with customers yield scores of 95 percent or better.

If the driver “Increase customer satisfaction by 5 percent” is important to your company, the executive also should establish a different project in

30

Chapter 2

which you can deliver this result. Perhaps this would be a program of which your project is one component: One project might set out to verify that what the customer service representatives learned in class was being applied while talking to customers. Another project might try to improve the installer’s arrival time. Yet another project might seek to increase the quality of the product the company produces. All of the projects would come together to get the business result of “an increase of 5 percent customer satisfaction.” The opposite of a MOP that is too big—a MOP that is too small—is also a problem. Say you are the manager of customer service representatives and are asked to get better survey results regarding customer service representatives’ interaction with customers. After reviewing the project and deciding what you can do, you craft a MOP that states this: Driver: Customer service representatives receive a 90 percent or better score on the customer service training.

Yes, this driver might get to increasing customer satisfaction, but how will it do so and when will it happen? This weak driver doesn’t get into the real business result and doesn’t provide a meaningful objective. Besides, you want to help your company and your career by going after stretch objectives that show your value as a project manager who gets the right results. Figure 2.4 captures this point and all the others I have covered, with a checklist to help you write clear MOPs. Measure of Performance Checklist Consists of two parts: driver and restrictions. Here are some reminders about how to craft each part.

A useful driver is: Measurable and verifiable A stretch objective Inclusive of ONE outcome only Results focused Absent references to budget and time frame Limited to the performer’s sphere of influence

A useful restriction is: What must not happen while pursuing the driver Measurable and verifiable Part of a short list of restrictions

Common Pitfalls: Avoid using restrictions to describe activities, additional objectives, budget, time frame of definition of terms.

Figure 2.4 MOP checklist.

You’ve Been Assigned a Project!

31

Putting Together a MOP You’re probably thinking that this MOP stuff is interesting theory, but how do you really get one put together? Most project sponsors don’t know exactly what they are after and don’t have the time or the training to draft something like this. (By the way, the project sponsor is the accountable executive for the project. You can usually tell who this person is because his or her neck is on the line for a successful delivery.) Well, you are probably right, so you’re the person who needs to draft this MOP. Here is a suggested process for you to consider using to draft a MOP. 1. After the project has been chartered, make an appointment to meet

2.

3.

4.

5.

with the project sponsor and/or the project customer. Plan on interviewing them about their intentions for the project. What do they want to achieve? What is the point? You probably have some of this information already from the project charter, but it likely won’t be in MOP format. Go back to your desk and analyze the comments from the sponsor and customer. Try to put yourself in their shoes. What business result is really needed for what they are trying to achieve? Draft a MOP for the project, trying to depict the business result you believe the sponsor is trying to achieve. If you can’t decide on one good MOP, create a couple of MOPs. Make sure that you have the proper restrictions built for each. Verify that each MOP is written well. Make sure no “hows” are embedded in the MOP. Verify that you have not embedded any time or cost into each. Also verify the size and scope for each MOP. Take the MOPs back to the project sponsor. Tell them about the MOP process, and show them what you have created. Most of the time, getting to see what you have provided gets their wheels turning. Most executives “get” this process quickly, and your draft gets the conversation going. By the time this meeting is over, you will know which of your MOPs is the right one, or you can write a new one with the sponsor.

Whatever approach you take to getting the MOP, make sure that your sponsor concurs on the MOP statement. With your sponsor’s concurrence, you have just defined what success looks like. You’ve defined what it will take to make you a hero.

32

Chapter 2

Preliminary Scope Statements The Measure of Performance is the initial piece of information that you craft for your project. You should also put together a few more key elements as you start the planning activities for your project. These pieces of information are grouped into a document called the preliminary scope statement, which defines the objectives and parameters of the project. You create a scope statement to begin the definition of exactly what your project will do. This is the tip of the iceberg that you are about to uncover as you do your project planning. In project management, the term progressive elaboration defines the process that you go through to plan a project. You start with an idea or an objective that is given to you. Then, step by step, layer by layer, you define the activities that the project must do to succeed. You start this progressive elaboration with the preliminary scope statement. What should a preliminary scope statement contain? Let’s look at few of the concepts you will want to cover in it. • Project objectives—The project objectives describe the purpose of the project. You covered this nicely with your MOP. In it, you clearly stated the business result that the project must obtain or the objectives it must meet. • Project constraints—Here you talk about the boundaries of the project or the constraints you will need to work within to guarantee your success. I already covered the constraints in the restrictions part of the MOP. (Nice little technique, that MOP!) • Assumptions—You will want to cover any assumptions you have made along the way, as when you defined the other elements of the preliminary scope statement,. Say, for example, that the project you are working on is a multiyear project with multiyear funding. An assumption might be that interest rates will remain between 6 percent and 7 percent. • Product requirements—Every project is commissioned to produce a product. A product can be a new widget, a white paper, or even a new concept. You will work with your project sponsor and project customer to define what functions this product should have. In the preliminary scope statement, you will work at a high level to understand the objectives and characteristics of the product.

You’ve Been Assigned a Project!

33

• Project organization—You want to consider and document how you will organize the project in this portion of the preliminary scope statement. You must answer questions such as the following: • Will you have people reporting directly to you? • Will you have representatives from functional organizations that act as your core team members? • Will your project be in a functional organization or a more projectized one? Your initial thoughts regarding that structure are documented here. • Deliverables—Here you document the expectations of the project sponsor and project customer regarding deliverables. A deliverable is a tangible output of the project. Deliverables can be the entire end product of the project or incremental activities that help build the product, such as documentation or test results. Must the product of the project be delivered all at once or one component at a time? • Early risks—You will probably hear a few things that they are worried about as you are interviewing the project sponsor and the project customer. As you keep listening, you probably can convert these worries into an initial set of risks. You’ll want to capture these in the preliminary scope statement, to be reviewed later when you begin your risk analysis. • Authority and accountability—One of the things that you will want to be very clear about and document in the preliminary scope statement is your level of authority and who will be accountable to you for delivering this project. You should have the authority to assign tasks directly to your project team, not through another manager, if your management is strong and supports project management. You should be able to get the right people on your team and get the wrong ones off your team. Finally, you should have input into your project team’s appraisals. As you work with the executive sponsor to lay out the objectives, also lay out as many of these authorizations as you can. • Cost estimates—This important topic is covered in its own section, coming up next. Defining these activities might take a while, but you can see from the topics covered that setting these expectations will enable you to build a strong foundation for planning the rest of your project. You’re probably wondering

34

Chapter 2

what you do with this preliminary scope statement. You use it as the beginning documentation for your project plan, which I talk about shortly. I’ve created a preliminary scope statement as an example for you in Figure 2.5. But first, let’s talk money.

3. Project Preliminary Scope Objectives: The scope of this project is to provide a customer service representative training class that is faster than today’s three-month class. The Measure of Performance for this project is: Driver: Reduce customer service representative (CSR) training time by more than 50%. Restriction: Customer complaints do not increase more than 2%. Constraints: 1. The organization will not see a substantial increase in customer complaints because of the new training. 2. If a new computer system is required, the existing computer hardware will continue to be used. Assumptions: 1. The project can be completed in 6–9 months. 2. The project will use the existing course development staff wherever possible. 3. The project will run a pilot course using a group of newly hired customer service representatives. 4. CSRs will pass the course at the same percentage that they do today. Project Organization: The project will be managed out of the Corporate Training organization. It will include key players and stakeholders from the Customer Service Representative organization. Deliverables: • Current state documentation This document will describe the objectives of the current customer service representative training. It will also cover what the current training topics are and the timing of those topics and the overall course.

Figure 2.5 Preliminary scope statement.

You’ve Been Assigned a Project!

35

• Training time reduction approach documentation This document will describe the overall approach to reducing the customer service representative training time. It will include changes to the training environment, hardware, software, classroom, and textbooks. It will describe the training objectives and the training approach that will be taken. You will want to get a signoff from the project sponsor on this document before proceeding to designing and building the training. • Customer service representative training time reduced by more than 50% This final deliverable will encompass the design, construction, testing, and refinement of the course until it reaches the desired goal. Early Risks: TBD Authority and Accountability: The project manager will be accountable for the project Measure of Performance and the restriction. The project staff will report directly to the project manager. The project manager will be accountable for the team members’ appraisal during the project. Cost Estimates: The organization has set aside $500,000 for the cost of the project based on previous similar projects.

Figure 2.5 Continued

Project Costs You saw in the previous section that in your discussions with the project sponsor, one of the things that you need to clarify is the cost of the project. This seems like a simple conversation, but setting correct expectations at this point is crucial to your success in terms of completing your project on time and within budget, while meeting the MOP. Before we get into how to set correct expectations, let’s do a little definition work regarding project costs. Consider the different types of cost estimates:

36

Chapter 2

• Order of magnitude estimates—Creating this estimate involves evaluating several major influences on the size of the project, comparing them to similar previous projects, and drawing relatively quick conclusions from them. I sometimes call it “Name That Tune.” Remember that old television show, where the contestants heard a couple of notes and bet on whether they could name the tune with the fewest notes? Well, this is a similar process. For example, if developing a new product would cost $1 million, but the current product is technologically more complex, the new project might cost $1.3 million (but not $300,000 or $2.3 million). You will find that this type of estimate is usually either too high or too low because it is done at the beginning of the project. • Definitive estimates—Definitive estimates are also known as detailed or bottom-up estimates. These estimates are derived by reviewing each task and assigning estimates to each. These estimates are the most precise type of estimate you can create. There are three types of definitive estimates: work effort, duration, and calendar. I cover each of these types of estimates in Chapter 5,“The Art of Estimating.” Definitive estimates are created in the planning process when all tasks are known. • Budget estimates—A budget estimate covers all the project elements, plus anything else that must be covered for the total project. Budget estimates are usually created at the end of the planning cycle, when all the plans are completed. You use every definitive estimate to determine what resources are required to work on that task. You determine the cost of every resource and determine the cost of each task. Then you add all the task costs together. When you have put the cost of the tasks together, you look to see if any additional costs need to be covered, such as management reserve money (I talk more about reserves in Chapter 5). When you have added up all the costs, you know what budget is required to fund your project. Now that you know what the types of estimates are and when they are created, let’s get back to the order of magnitude estimate. In your discussions with the project sponsor, he has probably told you that he has slotted a certain amount of money for this project. Here is where your negotiation skills come into play. It’s really important that you get a chance to set the real order of magnitude and budget estimates for the project. The figure he is giving you is what he thinks the project will take, without any real analysis.

You’ve Been Assigned a Project!

37

You can use this technique when approaching this hard conversation: 1. Thank the sponsor for the preliminary figure he has provided. 2. Educate him on the types of project estimates and when they are 3. 4.

5.

6.

created. Let him know how you will proceed in determining the true costs of the project. Let him know when he will hear about the order of magnitude estimates. This should give him an indication of whether what he has put aside will be close. Let him know that when you provide the order of magnitude estimate, you’ll also let him know when the definitive estimates will be completed. Tell him that you will also provide any risks associated with doing the project within the cost parameters that he has set out.

Laying out your approach with the sponsor will assure him that you know what you are doing. You are letting him know that there might not be enough money set aside to cover the budget of the project. You have this discussion by framing it in terms of risks. Besides that, right now you don’t know whether the money he has set aside will be a problem; you just want to make sure the door is open for further discussions as you learn more about what is required for this project. You will create an order of magnitude estimate after you review all the information the sponsor has provided and the information that you have documented in your preliminary scope statement. As I covered before, you should try to find a similar project and use the costs of that project to determine what your costs should be. If you don’t have a similar project, you must try to determine what the costs should be. Industry information says that order of magnitude estimates can be 75 percent higher or 25 percent lower than the actual cost of the project, so no need to fret over this estimate. You just want to make sure you are in the ballpark and that you get going on determining the real estimate. Of course, when you have completed the order of magnitude estimate, you’ll go back and have another discussion with the sponsor. Again, talk in terms of risks because you still don’t know what the true costs of the project are. Then you will document your order of magnitude estimate in your preliminary

38

Chapter 2

scope statement. Speaking of documentation, let’s start talking about the project plan, which is the overarching documentation for your project.

Starting the Project Plan You’ve completed the preliminary scope statement, and you need to put this documentation someplace where you can refer back to it during the project. Here is where the most important document of your project comes into play. This document is the project plan. Think of this document as a roadmap that provides all the context for the project. In it, you document your thoughts and actions for every aspect of the planning you are about to undertake. In it, you also provide information on how you will execute this plan, as well as how you will monitor and control the plan. A project plan should be as complex or as simple as your project itself. It will have a lot of documentation for a large project or a few meaningful items for a small project. You decide how much information is right. When determining what to put into this plan, use this rule of thumb: “When I get promoted and no longer can work on this project, what will my successor need to finish this project successfully?”You could have substituted,“When I hit the lottery…,” but that’s a different conversation. Let’s talk about the typical sections of a project plan and the types of information that it should contain. • Scope information—You document the preliminary scope statement that you just created. This is the basis for all future planning. One of the next planning steps you will perform is to create the scope statement for the project. You’ll want to capture that scope statement in this project management plan. • Work breakdown structure (WBS)—The WBS is a hierarchical depiction of the activities of the project. It is a massive brain dump of every activity that needs to be performed. You will want to keep a record of your original thinking. The WBS is a great tool for getting new team members up to speed on your project. • Schedule—After you complete the WBS, you use those activities to create a schedule with it. When you complete the schedule for the project, you will want to make sure it is covered in the project plan. Your schedule should cover major milestones in addition to the major deliverables.

You’ve Been Assigned a Project!

39

• Risk plan—You will want to capture any risks you have identified in your project plan as you continue to work through your planning efforts. You then can figure out a way to determine which risks really should be mitigated. With that, you’ll create a risk response plan, which is also part of your project plan. • Human resources strategy—In this section of the project plan, you capture all the information regarding the human resources on your project. This includes the project organization structure, a resource calendar, roles and responsibilities, and possibly even a placement plan—basically, where the resources will go when the project is completed. • Cost elements—This chapter has talked a lot about the costs of the project, especially the budget and order of magnitude estimates. In the project plan, you also cover any other cost information for your project, such as the cost baseline, which is used during execution of the project and so that you can compare what you planned on spending to what you are spending. • Communication plan—One of the most important jobs of a project manager is communicating. In this section of the project plan, you describe your efforts to provide effective communication. You describe who will be sent what information at what point in time during the life of your project. • Procurement plans—You might need to procure resources outside your organization while working on your project. Resources can mean tools or equipment or human resources. You describe how you will get these resources on your project. • Quality management—In your project, you plan for quality at the beginning of the project. You lay out plans for guaranteeing the quality of the product you are producing, as well as how to guarantee the quality of the processes you execute to create that plan. All of this information is documented in the project plan. • Project execution plan—In your plan, you also lay out how you will manage the execution of your project. You define processes such as change control and configuration management. You should cover everything that you plan to do during execution. • Execution monitoring and controlling—How will you control the project to guarantee delivery on time, on budget, and to the defined

40

Chapter 2

MOP? In your project planning, you define the monitoring and controlling you will do through the execution of your project. You decide what performance reports need to be generated and how you will take action when things are not going well. The project plan is a living document that is created during the planning phase and is constantly updated through the execution of your project. I’ve created a sample table of contents for a project plan in Figure 2.6.

DOCUMENT HISTORY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 TABLE OF CONTENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Business Need . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Project Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Project Preliminary Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4 Project Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.5 Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.6 Authority and Accountability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.7 Cost Estimates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.8 Scope Statement Inclusions and Exclusions . . . . . . . . . . . . . . . . . . . . . . 8 4. Measure of Success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Work Breakdown Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Assumptions and Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.2 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Quality Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Major Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Human Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1 Roles and Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. Project Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. Project Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 12. Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Figure 2.6 Project plan table of contents.

You’ve Been Assigned a Project!

41

13. Project Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 14. Execution Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 15. Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 16. Monitoring and Controlling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 17. Communications Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 18. Procurement Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Figure 2.6 Continued

This document is a history of what you plan to do, yet it is updated to show what you are currently doing. Again, you start this documentation with any preliminary information you receive from the project sponsor. You also include the preliminary scope statement you created in the last section.

Teaming During this preliminary stage of the planning process, it’s important to start thinking about what you will do to get the right team members on your project. This is not an activity that you want to leave to blind luck or chance; the right team members can make or break your project. You need a plan in place for getting these people lined up and ready to work. You should take several elements into account when you start planning for your team. You begin with some analysis of the current state of the organization, as well as what your project will need. The first element to review is the current organization structure. You will want to review how many departments your project spans. You will also want to analyze how work normally gets done in your organization. Will your team members be colocated? Will you need to have team members in different buildings, cities, or countries? Do you need to deal with collective bargaining agreements? With this information, you then need to determine what challenges you will face to get the right people for your team. Next, review the technical components of your project. Will you need specialized personnel who understand the technical components? Are these

42

Chapter 2

people in high demand? Who understands the technical aspects of your project better than anyone else in the organization? Who is second best? What challenges will the technical components create to getting the right people on your project? With this information in hand, you can now start determining how to build your project team. First, you will want to draft a team structure that outlines the best possible scenario for managing your project effectively. Next, identify your perfect target team. Also create a list of the next best alternative for the perfect team. Where can you do with a less experienced person than your perfect pick? Now looking at your perfect team and the next best alternative, describe the barriers you might encounter to staff this perfect team. Your analysis might include things such as these: • Matt is the best candidate for the core team lead of the Finance group because of his years of experience. He is currently on the XYZ project, and you might not be able to get him on your team. Check to see if the priority of your project is higher than the priority of the project Matt is working on today. You might be able to acquire him that way. If not, will your second-best alternative work? • You have found that Marcie, Matt’s boss, is difficult to work with. What will you do to guarantee a successful negotiation with her to achieve a win for her and for your project? • What authority have you been given as a project manager? Are you able to move the right people into your project without having to negotiate? (Most project managers will have to say “no” to this question and negotiate for the right people.) With your analysis complete, it is time to build your negotiation strategy. Understand the barriers well enough to know where you will need to spend extra time in your negotiations. You’ll need to have a strategy that covers all levels of the organization. Will it be more effective to start at the top of the organization and ask the executives for the resources you need? Will this approach upset the functional managers? Should you start with informal discussions, test the waters, and bring in the big guns only when you have to escalate? Only you will be able to say what is the right strategy. You know your organization and the politics of how things get done.

You’ve Been Assigned a Project!

43

The most important point in planning for your team negotiations is making sure that the people you get on your project want to be there. The managers you have negotiated with should be comfortable with the fact that this is the right person for the job. They haven’t lost anything (face included) in the negotiations. Okay, you now start the negotiations for the team members. As you plan for these people, you will also create the following sections in your project management plan: • Project organization chart • General time frames people will be on the project, including when they will be released • Training needs • How team member appraisals will be handled With the right strategy and good negotiation skills, you are well on your way to setting up the right team for your project. Let’s now talk about the politics around these preliminary planning activities.

Politics In the last chapter, I talked about you being the PR manager for your own career and your project. I continue with that topic in this chapter, with analyzing the politics facing you and how to start approaching them. I cover two important concepts here: “what’s in it for them” and “how much power do you really have?”

What’s in it for Them? We covered a lot of information in the last section about setting up the right team. We covered the analysis that you need to do to understand the barriers you will face when you negotiate your team. Another point in this barrier analysis has far-reaching impacts on the political environment: a political analysis. Use this technique for negotiating for team members, as well as to understand the entire political environment. This analysis process goes like this:

44

Chapter 2

1. Identify the project stakeholders. Make sure you have covered every-

one at every level who has something to gain or something to lose with the completion of this project. A stakeholder is a person or an organization or even the public. Stakeholders can be actively involved or can passively be the organization that receives the output of your project. Talk to your friends, coworkers, and executive sponsors to understand who these people are and what their motivation is concerning the project. This list might be quite extensive when you are finished. It might be a good idea to set it up in a spreadsheet arrangement, as depicted in Figure 2.7.

Formal Power

Informal Power

Will increase organization when project completed

VP

Highly respected

Susan Flannery

Will decrease organization when project completed

VP

Highly respected

Walt Johnson

Wants to be the best with new technology

Developer

People listen to him

Ginger Taylor

Will be outplaced

Business Analyst

Not broadly based

Stakeholder

Potential Agenda

Jose Levy

Figure 2.7 Spreadsheet arrangement of the project stakeholders. 2. Look at the list and, for each person, ask yourself,“What are the agen-

das of these stakeholders?” Do they want to see the project succeed or fail? Will they receive more power or influence if the project succeeds? Will they have their power base reduced if the project succeeds? Are extraneous factors creating hidden agendas? For example, is a bonus riding on an unreasonable completion date? 3. What formal power does this person have? Is he or she an executive, director, manager, or potential team member? 4. What informal power does this stakeholder have? Do other people listen to this person? Do other people fear this person? What alliances exist between this person and another stakeholder?

You’ve Been Assigned a Project!

45

With this analysis complete, you need to determine whom you should target in your PR campaign. Your list should include people with both formal and informal power, and those who have both a positive and a negative agenda. Yes, even the positive people need to be included. You want them to remain positive and strong supporters for you and your project. Start your PR campaign with an informal meeting with each of the people on your list. You want to know who they are and how they think. Remember the old saying,“Keep your friends close and your enemies closer.” This adage applies in project management, too. If these people resist talking to you, you can always couch your discussion in “risk identification and your unique perspective.” The purpose of the meeting is to get them talking and you listening. You start opening the door of communication. These people will know that you are approachable and that you will listen to what they have to say. Be sure to talk about the MOP of the project in your conversation; you want everyone to know what success looks like.

How Much Power Do You Really Have? In dealing with the political environment, it is always good to understand what power you really have. In figuring this out, you need to understand your place in the organization structure and what authority you really have. Let’s start with the organization structure. The first element to review is the current organization structure. You will want to review where you sit in the structure and determine the breath and depth of what departments your project spans. Figure 2.8 shows an organization’s structure in which the project manager sits in the IT department. Where the project manager sits in the organization can be a problem, depending on the size and scope of the project. If the project has the CIO as a sponsor and encompasses the Finance, R&D, and IT departments, having the project manager positioned three levels below the sponsor could cause problems: • Getting access to the CIO • Having to keep the manager and director in the loop when the project manager is talking to the CIO • Not having the authority to get people in R&D and Finance to work for the project manager

46

Chapter 2

CEO

CFO

Director

CIO

Director Development

R&D

Director Hardware

Quality Assurance

Director

Manager New Systems

Project Manager

Figure 2.8 Organizational chart showing the PM in the IT department

However, if the project is confined to your own organization and the Director of Development is your sponsor, the project manager is well positioned to manage the project. If you find yourself having the problems just mentioned, you will need to do one or more of the following: • Work out a temporary assignment of working at a level higher in the organization. • Document a roles and responsibilities matrix so that all your upper levels understand exactly what you are accountable for and to whom you are accountable. • Deal with the issues as they arise. Another way you can establish your authority is by having the project sponsor introduce you and your authority level at the beginning of the project.

You’ve Been Assigned a Project!

47

This technique can be very effective and can be done via e-mail or in the project kick-off meeting. You might want to write the announcement yourself and make sure the sponsor agrees with it. Then you can ask the executive sponsor to send the announcement out to the organization. You’ll want to craft something that contains your project name and outlines exactly what you are accountable for: “Sue Smith has taken the leadership of the XYZ project effective August 1. She will be accountable for the successful delivery of this project from a schedule cost and MOP perspective. Sue will begin her staffing activities in the near future….” Use these two political techniques to establish yourself and your power base. Be sure you understand who can become your supporters and who you might have problems with. You can build the rest of your PR strategy from there.

Summary In this chapter, you discovered how a project is started. You had a chance to see both informal and formal methods of project initiation. Then we spent a lot of time covering a topic called Measures of Performance, or how to define the point of the project. You then started the planning topics of project management with a preliminary scope statement. The section on scope statements also established how planning is progressively elaborated until you are clear about what you are creating as well as how the work will progress on your project. Our next topic was the costs of the project—specifically, the types of different project costs and when to use each. We then turned to project documentation—namely, the project plan. In the “Teaming” section, our discussion focused on how you get ready for effective teaming. And in the “Politics” section, we covered how to plan for the politics ahead. Now let’s head back to the case study. Let’s see what project Chris has been assigned to and how she deals with some of the preliminary planning issues while working at the Virtually Nostalgia Company.

48

Chapter 2

Case Study Chris Williams got to the office bright and early. She was pretty excited about the meeting with the CEO and wanted to get into the office. At 8:25, she headed down the hall to see June Jackson, the chief executive officer. June was at her desk when Chris arrived. She stood up and greeted Chris warmly. June told Chris that she was glad she had time to meet with her and that she had a very important project assignment for her. She launched off into a description.“As you know, we have been building up our inventory of products for our new subsidiary, Virtually Nostalgia. We’ve been able to keep this entire new subsidiary under wraps as we have been exploring this new market. Well, the more marketing information that we accumulate, the more we realize that we are sitting on a gold mine. We are, however, having a hard time finding vendors that produce the quality of products we want to sell. Anyway, that’s another problem. What I need you to do is project-manage the launch event for this new subsidiary’s new Web site and catalog. We have already decided that we want to be at a world trade event that is scheduled for September in Las Vegas. Not only will we be introducing our Web site and catalog to potential customers, but we will also be introducing them to companies that might align with us in advertising and sales joint ventures. We will use this event for several of our executives and key personnel to promote the launch as well as celebrate the launch of this new subsidiary.” June took a breath and said,“I know that you normally manage IT projects, and there are definitely some IT components in this project, but I think you are ready for a stretch assignment. You will be working with our travel and logistics department for all of the trade show setup. You’ll work with the operations group that builds and prints the catalog. You’ll work with marketing on the messaging for the show. I think you get the idea. Anyway, I need this to be big. I need to make a splash at this show. I want people to remember who we are and want to do business with us. We only have a year to see if this subsidiary is going to fly. We need to really get this thing going fast.” With that, June put down her pen and stood up. Chris took this as a cue that June was done, even though she had a million questions. Chris jumped in quickly. “June, I really thank you for the confidence you have in me and for giving me this project. I believe from our discussion that I can consider myself authorized to proceed with planning this project. With that, I’ll get started on my preliminary planning. I’ll get back on your calendar as soon as

You’ve Been Assigned a Project!

49

I have a few things lined up. I’ll need to make sure that I’m on the right track before I get too far into the plan.” June agreed, and Chris headed back down the hall to her cubicle. Chris immediately jotted down a few notes for herself and started to think about what would be required for this project. She was actually a little disappointed in the assignment. Setting up travel plans for a bunch of executives to man a booth in Las Vegas was not very exciting. She was hoping to get the implementation of the new CRM system. It seemed like this project was really important to June, and it would provide a lot of exposure for Chris with the executive suite. All in all, she thought it would probably be okay. That morning, Chris starting building her preliminary plan for the project. With her years of experience, she knew that getting the point of the project right would be difficult, so she started with some analysis of the departments affected by the project. She’d get that done and then start thinking about the business result. Chris captured the following for the departments impacted: • Sales Department—Would probably man the booth with salespeople, as well as help craft some of the materials for the booth • Marketing Department—Would probably help create some of the materials needed for the event • Logistics and Travel—Setting up arrangements with the trade show, travel arrangements, and catering • Operations—Making sure the product inventory is ready to go, that the catalog is created and printed, and that the requirements for the online catalog have been sent to IT • Business Development—Would probably be involved in getting new vendors to partner on sales and advertising • Information Technologies—Working with them to make sure the Web site is ready and can handle the anticipated traffic from the launch Chris thought that she had probably identified all of the departments, even if she hadn’t captured everything that they needed to do. She also decided that because she had so much to cover here, she had better set up a representative from each department to be part of her core team. They would help her coordinate the work in each of their departments. She added the departments and team structure setup to her preliminary plan.

50

Chapter 2

She also realized that because the project spanned so many departments, June would need to be the executive sponsor. Chris decided to talk to June about allowing her to report to her directly for the life of this project. That would really help her accessibility and communication with the sponsor. With that completed, Chris went back to thinking about the point of the project. She had just finished a project management book on a topic called Measures of Performance and wanted to try that technique in her planning. She thought about what June had described and ended up crafting three MOP drivers. The first covered the vendors for partnering on sales and advertising: “Sign up more than three sales and advertising vendors at the Las Vegas trade show.” She ran it against her MOP checklist and decided that she probably couldn’t be held accountable for that result, but that might be what June wanted as the real business result. The next driver she created was “Generate more than 100 product sales at the trade show.” She thought that she couldn’t be held accountable for this driver, either, but she wanted to make sure June agreed. After spending some more time thinking about the driver and making a few phone calls, Chris came up with a third driver: “Virtually Nostalgia will be named best in show at the September Nostalgia trade show.”Chris had talked to the trade show and found out that each attendee must fill out a survey at the end. This survey asked who had the best product demo, who had the best booth, and who provided the best event experience. Points were awarded in all of these categories, and the vendor with the best overall score would win best in show. What is really great about this survey is that other pertinent information is gathered but is not part of the overall score. The other items include who had the best products, who attendees would do business with in the future, and more. Chris felt she probably had the right driver for her level of authority. She also thought this driver got to June’s points of “I need this to be big. I need to make a splash at this show. I want people to remember who we are and want to do business with us.” Chris planned to talk to June about all three of these drivers to make sure that she really understood the point of the project. She knew they would have to settle on one driver. For the rest of the day, Chris continued to work on her preliminary scope statement. She established the major deliverables for the project, such as the plan for the project, a prototype of the “event experience” (okay, what the booth would look like), a prototype of a demo of the Web site, and the final deliverable of the event itself. She documented all of these in her preliminary

You’ve Been Assigned a Project!

51

scope statement and project plan. She then knew she was ready to talk to June again. She realized that June had not mentioned costs, and Chris wanted to make sure they were clear about the different types of estimates. After talking to June’s admin, Chris was able to get an hour on June’s calendar the day after tomorrow. That worked out perfectly because Chris had some legwork to do to find out as much as she could about the project stakeholders. Besides that, she still needed to get the order of magnitude estimate done for her meeting with June.

Review Questions 1. When a project is conceived, it goes through an authorization process 2. 3. 4. 5. 6. 7. 8. 9. 10.

in which a document is created. What is this document called? A measure of performance consists of what two parts? A measure of performance driver describes what? What is a MOP restriction? What is a preliminary scope statement? Describe progressive elaboration. What are the three types of cost estimates? What does industry information tell us the typical range is for an order of magnitude estimate? How is a project plan used? What are some typical components of a project plan?

This page intentionally left blank

3 How Big Is This Project? A user will tell you anything you ask about, but nothing more. —Anonymous

Topics Covered in This Chapter Defining the Scope Product Requirements Creating the WBS Desk Testing Teaming Politics Summary Case Study

The last chapter covered initiating a project and starting to define the scope of the project via the preliminary scope statement. This chapter continues the work of progressive elaboration and shows how to get into more detail. You start by defining the scope of the project, basically—you use the information you’ve already gathered to formally document the extent of the project via a scope statement. One of the inputs into the scope statement is the product scope description, which includes the product requirements. These requirements are very important to the success of the project, so you will go through the process of creating product requirements in this chapter. The next step is to create the work breakdown structure (WBS). This fundamental tool is the foundation for many of the topics ahead in this book. You will use it over and over again as input into your planning activities.

53

54

Chapter 3

Next, the chapter covers a handy technique that you can use throughout your project to make sure your project stays in scope: desk testing. You’ll learn how to use this tool after you’ve constructed the WBS to verify that you are still in scope. Following the discussion of desk testing, the chapter launches into the “Teaming” section. This section is concerned with successfully getting the key players engaged in the work of the project. It also covers how to get people to work for you effectively when they don’t report to you on paper. In the “Politics” section, you’ll read about building alliances, who to target for alliances, and how to successfully create confidence in your project. Finally, the chapter ends with the case study. Chris gets buy-in for the MOP for her project. She then creates the deliverables and gets her team engaged. You’ll see how she gets her team established for the work ahead. Let’s get started, then, with defining the scope of the project.

Defining the Scope The last chapter spent a lot of time talking about the preliminary project scope statement. This chapter elaborates on what was created preliminarily to complete the scope statement for the project. You might find when you are doing this work that what you created in the preliminary scope statement was actually done at too low of a level of detail, so no additional work is needed. The challenge here is to make sure that you have covered everything to a degree that allows the project team to understand what must be created to satisfy the objectives that the client has set out. In the preliminary scope statement, you captured the project objective, the MOP driver, and the project constraints in the form of the MOP restrictions. These two items do not require any more work for the scope statement. Where you really want to spend your time here is getting clear on two more pieces of information: • The deliverables for the project—the tangible output that can be handed over to show that work is being accomplished • What is explicitly included or excluded because of things such as budget restrictions or geographical limitation

How Big Is This Project?

55

Consider this to be two steps: creating deliverables and determining what is in and out of scope. I start with deliverables. You’ll actually create some deliverables by going back to the reduction of customer service rep training time and determining the deliverables for this for MOP. Driver: Reduce customer service representative training time by more than 50 percent. Restriction: Customer complaints do not increase more than 2 percent.

Okay, you have a driver that the project sponsor has signed off on. Now you need to create a list of deliverables for this business result you are going to achieve. Ask yourself, what interim steps must be accomplished to reach this driver? What events must happen to reach this driver? Think through both of those questions and create a list of things or events. Try this as brainstorming to start; you can always refine the list into deliverables later. This might be your brainstorming list: • • • • • • • • • • • • • •

I need to know what the training time is now. I need to know how many customer complaints are received today. I need to know what is currently trained. I need to interview the supervisors to make sure I understand what a customer service rep needs to know. I need to create learning objectives based on what customer service reps need to know. I need to determine whether it’s better to rewrite what they currently have or to start over. I need to determine whether using a different technology can help reduce the time. I will design the training based on all the information I’ve pulled together. I will create/redo the training material based on the design. I will time what has been created. I will adjust so that the duration of the class is 50 percent less. I will conduct a pilot class. I will have the pilot class use the new learning in the office for a week. I will monitor the customer complaints the pilot group gets after training.

56

Chapter 3

• I will verify that the duration of the class is 50 percent less in the pilot. • I will verify that the customer complaints from the pilot groups are less than 2 percent from the baseline. • I will adjust so that the duration of the class is 50 percent less. • I will verify that the learning objectives are met. • I will conduct the first class that takes 50 percent less time than the current class. That was a lot of brainstorming, but I think you get the idea. Now you need to analyze the list and see if there are natural groupings of ideas based on the timing of what has to happen in what sequence. Looks like you have four major areas that need to be addressed: • Determine the current state of customer service representative training. • Determine your approach to reduce the time. • Design and build the course. • Test and refine the course. If you look at those four major areas, you will realize that each of these areas needs to be documented. Some of them might even need the sponsor to sign off on them. So once again, you look at your list and determine whether these can be deliverables, a tangible output that can be handed over to show that work is being accomplished. Deliverables also need to be constructed in such a way that if the project was halted at the end of the deliverable for a year, another team could pick up where the last team left off. Imagine that your deliverables were these: • Current state documentation—This document will describe the objectives of the current customer service representative training. It also will cover the current training topics and the timing of those topics and the overall course. • Training time reduction approach documentation—This document will describe the overall approach to reducing the customer service representative training time. It will include changes to the training environment, hardware, software, classroom, and textbooks.

How Big Is This Project?

57

It will describe the training objectives and the training approach to be taken. You will want the project sponsor to sign off on this document before you design and build the training. • Customer service representative training time reduced by more than 50 percent—This final deliverable will encompass the design, construction, testing, and refinement of the course until it reaches the desired goal. Part of the trick with deliverables is making sure that you keep the project sponsor’s attention. Business changes fast, and priorities shift constantly. If you can time your deliverables for every couple weeks or months, and if you are consistent in their delivery, you’ll have a better chance of completing your project. When you falter on deliverables or you create one deliverable for the end of the project, sponsors sometimes wonder why they are spending their money on your project when all these new, pressing issues have just arisen. Okay, let’s move on to what is included in and excluded from the scope of the project. You provide what is excluded because sometimes it is easier for people to think about what shouldn’t be done versus what should be done. For this exercise, you will analyze the brainstorming list from the deliverables exercise. You’ll also look at your list of deliverables. One more thing: You’ll look at the restrictions from your MOP. They will definitely contribute to your thinking of what is in scope and what is out of scope. In fact, thinking about out-of-scope items is really another level of progressive elaboration for restrictions. So with that, you can start your brainstorming for what is in scope and what is out of scope. You might want to include your team in these brainstorming sessions. Remember, two heads are better than one. • In scope • New training textbooks • Changes to the training software system • Retraining of the customer service representatives • Classroom exercises • PowerPoint slides • User documentation

58

Chapter 3

• Reconfiguration of the existing classroom • Job aids • Instructor notes • Out of scope • Changes to the service representative system software • New classroom • New instructors • New hardware • New personal computers As you work through this list of what is out of scope and what is in scope, you might discover some things that need to be done that the deliverables do not cover. When doing this exercise, you included an item that is out of scope: new instructors. This item makes you realize that you are missing something in the brainstorming session: the fact that the current instructions must be retrained. You’ll find this process of defining deliverables and defining what is in scope and what is out of scope to be an iterative process. You’ll think of deliverables and create scope items. You’ll update the deliverables, which prompts more thinking about what is in scope and out. Give yourself a couple iterations before you stop the process. You’ll have a much better chance to make sure you cover everything. By the way, you added retraining of the current instructors to part of your last deliverable: customer service representative training time reduced by more than 50 percent. When you complete the iterations for the deliverables and the in-scope and out-of-scope statements, you document them and the rest of the preliminary scope statement information in the project plan, the repository for all your project information. Figure 3.1 presents a scope statement document. You are not quite done with the scope statement. One of the critical items that must be included in the scope statement is a description of the product that the project is commissioned to create. You will find that the clearer you

How Big Is This Project?

59

3. Project Preliminary Scope Objectives: The scope of this project is to provide a customer service representative training class that is faster than today’s three-month class. The Measure of Performance for this project is: Driver: Reduce customer service representative training time by more than 50%. Restriction: Customer complaints do not increase more than 2%. Constraints: 1. The organization will not see a substantial increase in customer complaints because of the new training. 2. If a new computer system is required, the existing computer hardware will continue to be used. Note: This is an excerpt of the preliminary scope and the scope statement. See Chapter 2, Figure 2.5 for the complete document. Deliverables: • Current state documentation • Training time reduction approach documentation • Customer service representative training time reduced by more than 50% 3.8 Scope Statement Inclusions and Exclusions • In scope • New training textbooks • Changes to the training software system • Retraining of the customer service representatives • Classroom exercises • PowerPoint slides • User documentation • Reconfiguration of the existing classroom • Job aids • Instructor notes • Out of scope • Changes to the service representative system software • New classroom • New instructors • New hardware • New personal computers

Figure 3.1 Project scope statement.

60

Chapter 3

get about the product description, the better results you will have in creating a successful project. Instead of creating a paragraph about the project, you’ll find that creating product requirements is a much more comprehensive method for defining the product. The next section covers creating product requirements in depth.

Product Requirements You are about to build a new product. What does it need to do? Shelter a human from rain? Interface with the widget? Have certain features and functions? These might describe the purpose of your product. But what does the new product have to do to achieve the purpose? Requirements describe what the product has to do. A good project plan must specify what the product’s requirements are. You must complete the requirements definition before you attempt to construct the product. It stands to reason that if you don’t have the correct requirements, you cannot build the correct product. Requirements can be subject to multiple and various interpretations. For example, your idea of a nice vacation might be very different from your partner’s idea of a nice vacation. Identifying requirements at the beginning of the project minimizes conflict and rework, and reduces the project duration. That’s something worth taking the time and effort for! Defining requirements and documenting them can be extremely challenging. The requirements can change quickly, depending on what is occurring in the general business environment and the organization itself. Additionally, the customer might not be very clear on what is really needed—and to make things worse, there could be multiple customers for the same product. Requirements creation is a process that starts with high-level concepts and, through a series of decomposition steps, creates specific statements that describe the product from several aspects. This process consists of four basic steps: setup, gathering, confirming, and baseline and control. These basic steps, sometimes known by different names, are commonly described as follows: 1. Setup—Someone discovers the need to create a project and, there-

fore, product requirements. That leads to a high-level definition of the project’s MOP and its scope. After the MOP is established, some key

How Big Is This Project?

61

planning activities for creating requirements are completed. These elements include who is impacted by the product, as well as what the impacts are. 2. Gathering—The project manager and other key parties now create the detailed requirements. They accomplish this step by using the appropriate tools and techniques to elicit requirements (we cover these tools and techniques shortly). Steps must be taken to ensure that the requirement statements are written and categorized properly. 3. Confirming—During this step, the project manager and other key parties determine the validity of the requirements that have been gathered. They look for ways to guarantee that the requirements are understood. They analyze each requirement for validity. Then they step back and look at the entire set of requirements and analyze whether the set really defines the intended product. 4. Baseline and control—The project manager oversees the client’s acceptance of the requirements. When all the necessary approvals are received, the requirements are baselined and procedures are put in place to control changes to the requirement set. Setup, gathering, and confirming don’t take place in a tidy linear sequence: These activities are interwoven, incremental, and iterative. As you work with customers, you’ll be asking questions and listening to the information they present (gathering). Concurrently, you will be processing this information to understand it, classifying it into various categories, and relating the customer needs to possible requirements. You will then structure the customer input into written documents and diagrams. You will work with your customer to review what you’ve written thus far, to correct any errors (confirming). This process continues throughout the requirements development cycle. Let’s explore each of these steps a little deeper now.

Setup Step The setup step is a series of activities that put together all the pieces necessary to get your requirements process off to a running start. Your deliverables for this step include these: • The intended audience • The work of the project in a graphical model

62

Chapter 3

The deliverables out of this step are used as inputs into the mainstream requirement activities in later steps. This step also establishes a firm foundation for the rest of your requirement activities. Requirements Audience Identification Many people will be impacted by or least interested in the product you are creating. Figuring out who these people are and the role they will play in your product is crucial to developing the right requirements. You might find a person who is very vocal about what the product should do. This person might constantly want to meet with you and influence your product. Wouldn’t it be nice to know in advance whether this person is the approval person for the requirements, the local champion of the users of the product, or the guy in the shipping department who is looking for a promotion? You’ll want to create a list of people who are the intended audience, or stakeholders, for this product. You’ll use your own knowledge of the organization, as well as information your team members and sponsors provide. You might have to do some interviews to make sure you’ve covered the entire audience. Let’s create some definitions for the people in a typical organization. • Project customer—The person who has asked for a product to be created via a project. The project customer will eventually use the product. • Project sponsor—The person who finances the project. The sponsor’s department is accountable for making sure the project is successfully completed. • Customers—The people who will ultimately operate your product. In some cases, the customers and the users might be the same person or group of people. • Stakeholders—The people who have an interest in your project. This interest can be both positive and negative. Stakeholders might be subject matter experts in the product you are creating. They might represent departments such as Legal, Human Resources, or Marketing. They also could be managers in the department that is impacted by the project, or even hired consultants who work in the department. • Approvers—The people who will sign off when the requirements are completed. • Team members—The people who will create the product of the project.

How Big Is This Project?

63

You need to consider another category of people as you identify the requirements audience. These people might have significant opinions and can make or break your requirements. They might already be identified as part of your requirements audience. If you’ve missed them, though, you could have a major gap in requirement acceptance. • Champions—The people who will work with your product every day. They are credible, and their coworkers believe what they say. Including them in your requirement audience could get the opposition in line. • Influencers—The people who advise the approvers. They are the ones who call the executives and tell them that the requirements are ready for signatures. • Challengers—The people who have something to gain if you miss requirements and, therefore, miss delivering the MOP of the project. With these people and roles in mind, develop a document for your reference that lists all the types of people in your intended audience. The template depicted in Figure 3.2 might be useful in helping you think about how to document your audience.

Role Project Customer Project Sponsor Approvers Project Manager Customers Users

Subject Matter Experts Legal Consultants

Name

64

Chapter 3

Role

Name

Human Resources Marketing Managers Others

Champions Influencers Challengers

Figure 3.2 Audience identification list.

You will use the audience identification list to determine who will actually participate in requirements creation, who will review requirements, and who will only receive information about the requirements. The template has now been updated with these additional categories. This updated template shown in Figure 3.3 will also be used later in the process to determine your requirements communication plan. Role Project Customer Project Sponsor Approvers Customers Users Subject Matter Experts Legal Consultants Human Resources Marketing Managers Others

Name

Create

Review

Interested

How Big Is This Project?

Role

Name

Create

Review

65

Interested

Champions Influencers Opponents

Figure 3.3 Audience identification list with roles.

Diagramming the Work The next step in requirements setup is diagramming the work that the requirements will cover. This is not a work breakdown structure of the project—you’re not ready for that yet. This is a diagram that explains the product of the project. In this step, you begin to understand the work of the project, or what the product will actually do. Diagram the business event that is affected by your intended change or product. You will create a diagram that shows data flowing between the business event and any entity with which it communicates. To create this diagram, you start with the Measure of Performance and what is in and out of scope for the project. Use these two pieces of information to create a statement that describes the work of the project. I continue to use a training class as an example. Remember the MOP? Driver: Reduce customer service representative training time by more than 50 percent Restriction: Customer complaints do not increase more than 2 percent

As you analyze the Measure of Performance and the scope statement, you determine that this is the work of your project: Building customer service representative (CSR) training that is 50 percent faster than today

This statement becomes the focal point of your diagram, which you begin in Figure 3.4.

66

Chapter 3

The work of building customer service rep (CSR) training, which is 50% faster than today’s training.

Figure 3.4 The work of your project.

The next step in creating your diagram is to determine what communication needs to occur between the work and other entities. You can formulate ideas on those communications by again analyzing your MOP and scope statement. You know that you’ll be dealing with these entities: • • • • •

IT Customer service representatives Training operations (classroom reconfiguration and training materials) Trainers CSR operations (current and future performance statistics)

Your diagram identifies the information provided to and received from the work of your project. The arrows represent the information received or generated by the work event. Starting with the customer service representatives, your diagram now looks like Figure 3.5. Your diagram should look like Figure 3.6 after you have completed your analysis. In creating this diagram, you have covered where requirements need to be created. You create requirements for each entity covering the communications that are diagrammed. In the example, you show an entity called CSR operations. You would create requirements for the work they do on our project. Specifically, you are looking at the current performance level of the customer service representatives when it comes to customer complaints (remember your restriction?), the duration of the current training, as well as what the future customer complaint level will be. You are now ready to start gathering requirements.

How Big Is This Project?

Customer Service Rep

Training

The work of building customer service rep (CSR) training, which is 50% faster than today’s training.

Figure 3.5 The work and other entities.

Information Technologies

Customer Service Rep

What needs to be modified for Training system Training

Modified Training system

Train the Trainers

The work of building customer service rep (CSR) training, which is 50% faster than today’s training.

What needs to be modified for classroom and training material

Modified classrooms and training material

Trainers Future Performance

Current Performance

CSR Operations

Figure 3.6 Completed diagram.

Training Operations

67

68

Chapter 3

Requirements Gathering Step This next step in your requirements process is a multidimensional piece of work. The project manager and the project team need to understand the dimension of the work the user currently does and the dimension of what the user wants the work to do in the future. To help you uncover all the requirements, look at these topics: • • • •

Tools and techniques for gathering requirements Approaches for gathering requirements Writing requirements Levels of requirements

Let’s first discuss some of the most effective tools and techniques for gathering requirements. Tools and Techniques Certain techniques can help in the gathering of requirements. The key to getting at the requirements is finding the techniques that will work for your specific project. Remember also that the project manager might or might not actually gather the requirements; anyone on the project who is qualified to do this work can handle it. Current Situation Review

For you to change the existing process, product, or system to do something new, you must understand what it does today. This analysis is called reviewing the current situation. When you review the current situation, keep in mind that you are not attempting to document the existing process; you are merely trying to establish the situation that the users currently face. Thus, the review of the current process, product, or system is done to ensure that you understand the situation before introducing any improvements. You can use two methods to achieve this understanding. The first is diagramming the process flow of the underlying work. Work with the user to build a process flow that describes the steps and decisions that are currently in place, as depicted in Figure 3.7.

How Big Is This Project?

69

Customer Requirements Defined

Gather Industry information on device availability

Create short list

If new manufacturer, contract negotiations

Potential Product Identified

Share with Segment and Sales

Start discussions regarding which channels

Create “shorter” list

Handsets to Engineering

Usability Testing/ Human Factors

Select

Figure 3.7 Data flow diagram.

70

Chapter 3

The second method of reviewing the current system is to inspect the documents and files that the organization uses. First, you collect samples of all documents, reports, forms, and files—anything that is used to record or send information pertaining to the product of your project. Inspect each of the items listed earlier, looking for nouns or “things.” These can be column headings, named boxes on forms, or simply the name of a piece of data on the document. For each noun, ask these questions: • • • •

What is the purpose of this thing? Why is this used? Who uses it? What does the CSR do with this? Is it used by the trainer? Are there relationships between the documents?

• Are rules attached to the different documents? • How does the organization ensure that the rules are followed? • Do the users feel that some of the documents are problematic? These questions will not in themselves reveal all the requirements for the product. They will, however, give you plenty of material and direction for further investigation. Shadowing

Shadowing is a wonderful way to observe the real work. Shadowing is based on the idea of being so close to the users that you are like their shadow. The shadow sits with the user to learn the job by observation, while asking questions and doing some of the work under the user’s supervision. It is unlikely that many people can explain what they do in enough detail for the project team to completely understand the work and then capture all the requirements. However, most people can explain what they are doing while they are doing it. If the person is doing his job in his normal workplace, he can provide a running commentary and provide details that might otherwise be lost. Only while working can the person describe his task precisely, telling you why he is doing things and what exceptions can occur. As the person performs his job and explains his actions, the shadow can ask questions:“Why did you do that?”“How often does that happen?”“What does this mean?” Eventually, the shadow should be able to see all the actions that the person takes.

How Big Is This Project?

71

The project team needs to look for patterns within the work. If your project is a new function within an existing product, you’ll want it to have the same type of pattern as the other job functions. These patterns might turn into look-and-feel requirements later. Interviewing

Interviewing is a more traditional way of gathering requirements. Used by itself, it can cause problems. Most people cannot describe their requirements in this type of an exercise. If you will use this technique, structure it so you can get the most pertinent information possible and match it with another technique. Here are some guidelines: • Before the interview: • Create a list of questions and provide it to the interviewee in advance. • During the interview: • Build pictures of what the interviewee is describing, wherever possible. • Listen. • Paraphrase. • Ask questions. • After the interview: • Document what you heard. Send the document to the interviewee for verification. Brainstorming

Brainstorming is a method for developing creative solutions to problems and, thus, can be used for requirements gathering. It works by focusing on a statement or problem, and then deliberately coming up with as many unusual solutions as possible and by pushing ideas as far as possible. During the brainstorming session, there is no evaluation or criticism of ideas—the idea is to open up as many possibilities as feasible and break down preconceptions about the limits of the problem. The results of the brainstorming session then can be analyzed, and the best solutions can be explored using either further brainstorming or other requirements-gathering techniques.

72

Chapter 3

Brainstorming can be done either in groups or by individuals. This technique can be used when several members of your requirements team are not colocated. Individual brainstorming tends to produce a wider range of ideas than group brainstorming. Individuals are free to explore ideas in their own time without any fear of criticism and without being dominated by other group members. With individual brainstorming, you send the statement or problem to each individual and ask them all to come up with as many ideas as possible and send them back to you. Regardless of whether you use the individual or group technique, do the following: 1. Compile a list of the ideas. 2. Remove duplicates. 3. Clarify incomplete ideas. 4. Meet with several of your clients and determine which ideas should

become a requirement. 5. Craft each idea into a proper requirement statement. Mind Mapping

The human brain is very different from a computer. Where a computer works on one instruction after another, the human brain does the same but also looks for associations with the information it is receiving. This association is sometimes done by using words. Each word or idea can have numerous links attaching it to other ideas and concepts. Mind maps are an effective method of note taking and are useful in generating ideas by association. To make a mind map, you start in the center of the page with the main idea and work outward in all directions, producing a growing and organized structure composed of words and images, as shown in Figure 3.8. Because of the large amount of association involved, a mind map can be very creative, tending to generate new ideas and associations that have not been thought of. The creative potential of a mind map is useful in brainstorming sessions. You need to start with only the basic work statement as the center and then generate associations and ideas from it to arrive at a large number of different possible approaches. You gain a better overview by presenting your thoughts and perceptions using color and pictures.

73

How Big Is This Project?

? Once we have their email address, what do we do?

STOP

What to offer Car loans Home loans

Rate comparison?

LOCATE AND CALCULATE AMORTIZATION SCHEDULE

!

Find us? Calculator

Search Engines!! Marketing plan Not enough hits!

Billboards

Telemarketing

Suze Orman

Figure 3.8 Mind mapping example.

Approaches for Gathering Requirements The techniques presented here are tools to help you do something very difficult: to extract precise information from the brain of another human. And that is the crux of it—you have to do this work. No tool yet invented can do it for you. Consider your users. They will be very conscious of some requirements and will bring them up early. Others are called the “unconscious” requirements, which are so integrated into the work that users have forgotten they exist. The techniques that capture the conscious requirements might not necessarily work on the unconscious ones. Then there are the “undreamed-of” requirements, which the users and customer are not aware they could have. Undreamed-of requirements are there because the users did not realize that they are possible. This could be because of a lack of technological sophistication, or they might have never seen their work in the way you will show it to them. Whatever the reason, part of your responsibility is to bring these requirements to the surface.

74

Chapter 3

So what techniques should you use for your project? To choose the most appropriate technique, consider these questions: • Who or what has the knowledge you are looking for? • What types of requirements are you searching for: business rules, how data is used, how the work gets done, etc.? • Will you be able to speak to the real people doing the work? • Is the knowledge conscious, unconscious, or un-dreamed of? Here are some guidelines that will help you select the best methods for gathering requirements: • Current situation review—This method is very effective for uncovering unconscious requirements. It is particularly helpful when you are adding new requirements or enhancing work that already exists. If a major source of requirements is your documentation, this is the right method to use. • Shadowing—Shadowing is useful for uncovering both unconscious and conscious requirements. It’s also a great technique when your users are too busy to talk. • Interviewing—This is a good method for discovering conscious requirements. • Brainstorming—This method helps uncover undreamed-of requirements. It is very useful when inventing new products with unknown/potential users. Writing Requirements Before you gather your requirements, you must understand the characteristics of a good requirement. Keep these characteristics in mind as you write and review the requirements, to produce better (although never perfect) requirement documents and build better products. Characteristics of Good Requirements

The characteristics of a good requirement include the following: • Distinct—Each requirement should specify exactly one distinct function—for example,“The training textbook should be overprinted in 12-point font.”

How Big Is This Project?

75

• Unambiguous—Be on the lookout for ambiguity. Ambiguity comes from the fact that there are different meanings and uses for the same word in the English language. All readers of a requirement statement should arrive at a single consistent interpretation of it. To reduce ambiguity, avoid vague terms such as user-friendly, robust, and easy. You might want to consider creating a glossary to define the different terms used. • Complete—Each requirement must fully describe the functionality to be delivered. It must contain all the information necessary for the team member to design and implement that functionality. • Necessary—Each requirement should document something that the customer really needs or something that is required for the product to work correctly or be useful to the customer. • Specific—Look-and-feel requirements should be specific. If you are expecting the product to run on a Windows Server platform, a lookand-feel requirement might be “The product shall comply with the Microsoft Common Engineering Criteria.” If there are other existing company products, you could use “The product shall conform to the established look and feel of the organization’s products.” • Correct—Each requirement must accurately describe the functionality to be built. Only the customers or their representative can determine the correctness of requirements, which is why it is essential to include users in reviews. • Feasible—It must be possible to implement each requirement within the product you are creating. If you are creating a new grocery cart, it is probably not feasible for there to be a requirement stating that “The cart must hover 6 inches above the ground.” The project manager will need to provide a reality check for what can technically be done and what can be done only at excessive cost. • Verifiable—Examine each requirement to see whether you can devise a test to verify that it was put in place properly. Style Guidelines

Keep the following recommendations in mind as you document software requirements: • Keep sentences and paragraphs short. • Use the active voice.

76

Chapter 3

• Write complete sentences exhibiting proper grammar, spelling, and punctuation. • Use terms consistently and as defined in the glossary. • Keep out the “hows.” Sometimes when people think they know a lot about a topic, they use terms that are specific to how the work should be done. For the training time reduction project, a requirement might be “The training will provide a final exam via a computer.” A computer might not be the best way to deliver this type of exam. This requirement is forcing a solution. It would be better to say,“The training will provide a final exam.” • State requirements in a consistent fashion, such as “The product shall” or “The user will,” followed by an action verb and then the observable results. Never use the verb may. Levels of Requirements Most requirements include three distinct levels: • Level 1: Business requirements • Level 2: Functional requirements • Level 3: Nonfunctional requirements Figure 3.9 shows these levels of requirements. Business requirements represent high-level objectives of the customer requesting the product. They are captured in documents describing the Measure of Performance and scope. The functional requirements specify what the product must do. They relate to the actions that the product must carry out to satisfy the needs of the customers. Nonfunctional requirements are the properties that your product must have. Think of these as the qualities that make the product attractive, or usable, or fast. They describe the qualities of the functional requirements. When creating requirements, you create them in successive layers of detail. Begin by identifying user goals and scope via the MOP and scope statement, and then create a work diagram. Elaborate the entities and communications of the work diagram into functional requirements that will enable the customers to perform the tasks. Then elaborate the functional requirements

How Big Is This Project?

77

into a set of nonfunctional requirements that describe the qualities of the functional requirements.

Business Requirements

Functional Requirements

Nonfunctional Requirements

Figure 3.9 Levels of requirements.

The business requirements were defined earlier in Chapter 2,“You’ve Been Assigned a Project!” and here in Chapter 3. I now spend some time on each of the lower level requirement types. Functional Requirements

Functional requirements are characteristics the product must have if it is to provide useful functionality for its customer. This is what the product will do. Functional requirements are typically stated in general, not specific, terms. Functional requirements are… • • • •

Specifications of the product’s functionality Actions the product must take—calculate, train, record, and retrieve Derived from the fundamental purpose of the product Not a quality—for example,“fast” is a quality and, therefore, is a nonfunctional requirement

78

Chapter 3

Think of functional requirements as the user requirements. That is, if you speak to a user or one of the businesspeople, they will describe the thing that the product must do to complete some part of the work. Here are some examples from the CSR training project: • The training will educate the CSR on all computer systems that a CSR uses. • The training will educate the CSR on all job aids that a CSR uses. • The training system will demonstrate all computer systems that a CSR uses. • The training will provide a final exam. Note the level of detail. These requirements are user requirements that the businesspeople can verify. In other words, the user should be able to tell you whether the functionality is correct, given the intended outcome of the work. Later the product designers might add more requirements. These will be the nonfunctional requirements that are needed to make the product work. Write each requirement. Read it aloud. Confirm with your user that you both understand the same meaning for the requirement. This might seem obvious, but “send the bill to the customer” could mean that it goes to the person who actually bought the goods, or it could mean that the bill is sent to the account holder. It is also unclear whether the bill is sent immediately after the purchase or at the end of the month. A short conversation with the user/client will clarify the real intentions. Nonfunctional Requirements

Nonfunctional requirements are properties or features that the product must have. They describe what the product needs to do so that it will meet the functional requirements. Nonfunctional requirements do not alter the product’s functionality. That is, the functional requirements remain the same no matter what properties or qualities you attach to them. The nonfunctional requirements add characteristics to the product. So you might think of the functional requirements as those that do the work, and the nonfunctional requirements as those that give character to the work.

How Big Is This Project?

79

Nonfunctional requirements can be categorized into different types. It does not matter what categorization you use or the names of the different types. This categorization helps you think through the possibilities so you can capture as many characteristics as possible. Here are some of the types of nonfunctional requirements: • Usability requirements—Based on the intended users Example: A newly trained Customer Service Representative will be able to use the system without committing errors. • Performance requirements—How fast, big, accurate, safe, reliable, etc. Example: The training system will mirror the CSR systems with 100 percent accuracy. Example: The training system must be available from 8 a.m. to 5 p.m. Eastern Standard Time. Example: The training system must be available Monday through Friday. • Operational requirements—The product’s intended operating environment Example: The training systems must run on a Microsoft Windows XP Professional personal computer operating system. • Maintainability and portability requirements—How changeable the product must be Example: The new software must work on both PC and Mac platforms. • Look-and-feel requirements—The intended appearance Example: The product must use the company colors and logo. Example: All user instructions must use 12-point Garamond font. • Security requirements—Security, confidentiality, and integrity of the product Example: The training environment will be accessible only by users with an authorized access code.

80

Chapter 3

• Cultural and political requirements—Human factors Example: The product’s operating instructions must be printed in English. Example: The product’s operating instructions must be printed in German. • Legal requirements—Conformance to applicable laws Example: The training material must accurately reflect the organization’s EEOC policy. For each functional requirement, ask the customer what qualities and characteristics it must have. Use your checklist of nonfunctional requirement types to determine whether you’ve covered every category.

Confirming the Requirements Step No simple, clear signal will indicate when you’re done gathering requirements. As customers and team members talk with their work associates, read industry and business literature, and muse in the shower each morning, they will generate ideas for potential inclusion in the product. You’ll never be completely done, but the following cues suggest that you’re reaching the point of diminishing returns on gathering requirements: • If customers begin to repeat issues they have already covered in previous discussion, perhaps you’re done. • If proposed new requirements are all of low priority relative to the ones you’ve already specified, perhaps you’re done. • If the customers are proposing capabilities that might be included in the future, not in the current release of the product, perhaps you’re done. When you reach the point of “done with gathering” your requirements, it’s time to confirm or verify your requirements. You do this with two approaches. First, you confirm and verify each requirement. Second, you confirm and verify the entire requirement set. Let’s start by discussing individual requirements.

How Big Is This Project?

81

Analyzing Individual Requirements

You can start confirming the requirements as soon as you have a single requirement. The aim is to trap requirements-related defects as early as they can be identified. The intention is to prevent incorrect requirements from being carried forward to the design and implementation, where they will be more difficult and expensive to find and correct. A requirement must pass a number of tests for it to remain in the requirements document. These tests ensure that the requirements are complete and accurate, and that they do not cause problems by being unsuitable for the design and implementation stages later in the project. Here are the tests you should perform: • Is the requirement understandable? You must make sure that each requirement has been written as clearly as possible. Being concise is important, but it should not become a detriment to understanding the requirement. Ask yourself, if two people read this requirement will they have two different understandings? • Is the requirement relevant? When you are gathering requirements, you inevitably will have requirements that are meaningless to the real purpose of your project. Irrelevant requirements quickly lead to requirements creep, with the probable result that the project will run over time and over budget and then won’t deliver the product that it set out to build in the first place. • Is the requirement viable? Each requirement must be tested for viability within the constraints that have been set. Compare the requirement to the restrictions in the MOP and the statements of what is out of scope. Make sure that none of the requirements that you have created violates these constraints. For example, you might look through the requirements that have been created and discover that one of them is “The new system must handle 10,000 transactions per second.”Your scope statement says that you must use an existing old hardware platform that handles only 1,000 transactions per second. In such a situation, you would go back to the client and either redo the requirement or get more money for a new hardware platform and change your scope statement.

82

Chapter 3

You must confirm each requirement as being viable, relevant, and understandable. Then it’s time to place them all in one document and confirm the entire requirement document. Analyzing Global Requirements

By the time you are ready to take stock of your requirements document, you should feel that the document is complete, or at least ready for a review. The objective of this review is to examine the requirements document and find out how good it really is. You’re looking for completeness, consistency, and modifiability. The review process is iterative until all problems have been resolved. Keep a record of discarded requirements and reasons why they have been discarded, to prevent their accidental reintroduction. The document can be considered complete when the bad requirements are weeded out and added to the list of discarded requirements. You should perform these tests on your requirements document: • Is the document complete? No requirements or necessary information should be missing. Missing requirements are hard to spot because they are invisible. Go back to the work diagram and look at all the business events. Have you completely covered the requirements for each event for when it works and when it doesn’t work? If you know you are lacking certain information, use “TBD” (to be determined) as a standard flag to highlight these gaps. Resolve all TBDs from a given portion of the requirements before you proceed with construction. • Is the requirement set consistent? Consistent requirements don’t conflict with other requirements or with higher-level requirements. Two requirements are conflicting if you cannot implement them both because their meanings are opposed; to implement one would mean not implementing the other. For example, if one look-and-feel requirement states that the product must employ a large surface area to display information, and an operational requirement says that the product must be used by someone moving about on foot, both cannot be implemented exactly as specified. Contradictory requirements must be resolved before the project can proceed.

How Big Is This Project?

83

• Is the requirement set modifiable? You must be able to revise the requirements document when necessary and maintain a history of changes made to each requirement. This requires that each requirement be uniquely labeled and expressed separately from other requirements so that it can be referred to unambiguously. Each requirement should appear only once in the requirements document because it is easy to generate inconsistencies by changing only one instance of a redundant requirement. A table of contents, an index, and a cross-reference listing will make the requirements document easier to modify. When these checks are done and you feel that the requirements are really completed, it is time to have your project sponsor and project customer sign the requirements document. Of course, you will need to conduct a review with them and other people in their organizations. Look back to your audience identification matrix and determine who should be part of this review.

Baseline and Control Step Even though you’ve gotten signatures, you’re not done with requirements! You must now baseline, or “freeze,” the requirements. When the customer and sponsor have approved the requirements document, it is essentially “frozen” in its approved state and provides a point of reference to determine whether the project is meeting the planned functionality. The baseline constitutes an agreement between the customers and the project team about the functional and nonfunctional requirements planned for the product. The requirements agreement is the bridge between creating requirements and managing the requirements while the product is being built. Requirements management includes all activities that maintain the integrity and accuracy of the requirements agreement as the project progresses. Requirements management emphasizes these actions: • Controlling changes to the requirements baseline • Keeping the project plan current with the requirements • Controlling versions of both individual requirements and requirement documents

84

Chapter 3

• Managing the relationships between requirements and other project deliverables • Tracking the status of the requirements Two major elements are involved in controlling the changes to the requirements baseline. The first is version control of the actual requirements document. Version control is an essential aspect of managing your requirements. Every version of the requirements documents must be uniquely identified. Every member of the team must be able to access the current version of the requirements, and changes must be clearly documented and communicated to everyone affected. To minimize confusion, conflicts, and miscommunication, permit only designated individuals to update the requirements. The second major element in controlling the changes to the requirements baseline is managing change requests to that baseline. An organization that is serious about controlling its projects will ensure that this is true: • • • •

Proposed changes are carefully evaluated. The appropriate individuals make decisions about changes. Changes are communicated to all affected participants. The project incorporates requirements changes in a disciplined fashion.

Chapter 13,“Controlling Changes,” talks at length about integrating change control, a discipline that works to keep all the project activities on track when changes are requested. This same principle works for your product requirements, just as it does for your project schedule. Now that you have completed your product requirements, you can add them or a reference to the requirements document for your project plan. I have created an example of that part of the project plan in Figure 3.10. You have now completed the scoping aspects of your project plan. It is time to move to the next level of progressive elaboration: creating the work breakdown structure.

How Big Is This Project?

85

5. Product requirements 1. Functional—The training will educate the CSR on all computer systems that a CSR uses. Nonfunctional: 1a. A newly trained Customer Service Representative will be able to use the system without committing errors. 2. Functional—The training will educate the CSR on all job aids that a CSR uses. Nonfunctional: 2a. The job aid must use the company colors and logo. 2b. All job aids must use 12-point Garamond font. 2c. The job aids must be printed in English. 2d. The job aids must be printed in German. 2e. The job aids must accurately reflect the organization’s EEOC policy. 3. Functional—The training system will demonstrate all computer systems that a CSR uses. Nonfunctional: 3a. The training system will mirror the CSR systems with 100% accuracy. 3b. The training system must be available from 8 a.m. to 5 p.m. Eastern Standard Time. 3c. The training system must be available Monday through Friday. 3d. The training systems must run on a Microsoft Windows XP Professional personal computer operating system. 3e. The training environment will be accessible only by users with an authorized access code. 4. Functional—The training will provide a final exam. Nonfunctional: 4a. The final exam will be mechanized.

Figure 3.10 Product requirements example.

86

Chapter 3

Creating the WBS This section moves into a very important area of project planning, creating the work breakdown structure (WBS). You use this tool to create a hierarchical depiction of the work of the project that covers the total scope. You are now starting to think at a lower level than before. With this tool, you actually start thinking in terms of small manageable units, the actual work packages that must be done to accomplish the project. Because the WBS is a hierarchical depiction of the project, you usually build it like a tree structure when you create it manually. The major project management software tools, such as Microsoft Project, create the WBS in an outline format. You will use the tree structure for the example here.

Microsoft Project and the WBS For details on how to successfully create a WBS using Microsoft Project, read Chapter 3 of Microsoft Project for Mere Mortals, by Patti Jansen.

A WBS has levels associated with it that actually show how the work breaks down from level to level. The highest level is usually the project name or, in your case, the MOP for the project. Intermediate levels are deliverables or other ways to summarize the project. These intermediate levels help you think through what work needs to be done for your project. The lowest level of the WBS is called the work package level. A WBS can have as many levels as make sense for you and your project team. This lowest level should be small enough to allow you to assign it to a person to complete. You will also be able to easily complete time and cost estimates for the work packages at this level. Let’s go back to the customer service representative training project and build the work breakdown structure. The first level of the WBS is the MOP that you created in the last chapter, depicted in Figure 3.11. Reduce customer service representative training time by more than 50%

Figure 3.11 The highest level of the WBS.

How Big Is This Project?

87

Now it’s time to create the next level down. For the example, you will use the three major deliverables. Remember when you are creating a WBS for your project that each level should be something meaningful for you and your team. The idea here is to capture all the work that must be done. Figure 3.12 depicts the second level of the WBS. Reduce customer service representative training time by more than 50%

Current state documentation

Training time reduction approach documentation

Customer service representative training time reduced by more than 50%

Figure 3.12 The second level of the WBS.

With the second level in place, it is time to either create another level or start creating the actual work packages that will need to be performed for this project. For the example, you will go directly to creating work packages. When you start this process, it is best to have some or all of your project team with you. A nice way to get this work done is to conduct a brainstorming exercise. Have each of your team members speak for the activities that they will have to perform for the project. Don’t concern yourself with the sequence of the work at this point. Just try to get all the activities captured. Some project managers choose to use self-sticking yellow notes. Each person has a pad and writes down what needs to be done. When the brainstorming is completed, the project manager goes back over the list to make sure that each work package has a noun and a verb. The project manager also reviews the entire list for duplicates or work packages that don’t make any sense. You should have a final list as in Figure 3.13 for the training project. It looks like you have created a lot of work packages, but you will find that only 80 percent of your project work has been created at this stage of progressive elaboration. You will find that you are missing a lot as you continue to build upon the WBS.

88

Chapter 3

Reduce customer service representative training time by more than 50%

Current state documentation

Training time reduction approach documentation

Customer service representative training time reduced by more than 50%

Interview CSR supervisors

Create approach document

Conduct the first class

Adjust the class for 50% less

Determine current customer complaints

Determine whether to rewrite or start over

Time the class

Verify the training class is 50% less

Determine current training time

Create learning objectives

Verify customer complaints are < 2%

Conduct pilot class

Create document

Determine whether to use a new technology

Train the trainer

Verify learning objectives are met

Design the class

Create textbooks

Create job aids

Build the class

Investigate what is currently trained

Figure 3.13 A completed WBS.

The last step in creating a WBS is putting together what is called a WBS dictionary. Basically, this is a set of documentation that explains any misleading terms or any assumptions you might have made while you were creating the WBS. You’ll also include any descriptions that lead to better understanding in your WBS dictionary.

How Big Is This Project?

89

Also take a few minutes and number your WBS, to keep track of your original thoughts. Later in the project, you will further define these work packages and sequence them in the order they should be performed. You want to make sure that you don’t lose any work, so you number them for future reference. Numbering is done like a typical outline, as shown in Figure 3.14. Reduce customer service representative training time by more than 50%

1.0 Current state documentation

2.0 Training time reduction approach documentation

3.0 Customer service representative training time reduced by more than 50%

1.1 Interview CSR supervisors

2.1 Create approach document

3.1 Conduct the first class

3.7 Adjust the class for 50% less

1.2 Determine current customer complaints

2.2 Determine whether to rewrite or start over

3.2 Time the class

3.8 Verify the training class is 50% less

1.3 Determine current training time

2.3 Create learning objectives

3.3 Verify customer complaints are < 2%

3.9 Conduct pilot class

1.4 Create document

2.4 Determine whether to use a new technology

3.4 Train the trainer

3.10 Verify learning objectives are met

3.5 Design the class

3.11 Create textbooks

3.6 Create job aids

3.12 Build the class

1.5 Investigate what is currently trained

Figure 3.14 WBS with numbering.

90

Chapter 3

Of course, your work here is not completed until you put the completed WBS into the project plan. You will find this handy later in the project, especially when you have new team members join the project. You’ll be able to show them the original thinking concerning the project via the WBS in the project plan.

Desk Testing Before you close this portion of planning for your project, you must complete one final check of the work that you have done so far. I call this verification method desk testing. This is a human test of the work so far, to guarantee that you are still in the scope that you defined. This verification should be done at the end of every level of decomposition that you complete. I put a reminder in this book at the points in time when this desk testing should be completed. Okay, here’s how you do this desk testing. Take out the scope statement that you have prepared in this chapter. Use the MOP and in scope and out of scope statements from this document. Also take out the WBS you just created. You will now do some analysis comparing the two pieces of work. Two tests must be performed: • Ask yourself whether the WBS covers all the elements and intentions of the MOP and in-scope statements. If so you are ready to move on to the next level of planning. If not, you need to determine what is missing and make sure it gets added to your WBS. • Ask yourself whether you have included anything additional in the WBS that was not covered in the MOP and scope statements. If you have and this item should not be part of the project, remove it from the WBS. If you have and this item should be part of your project, go back and update the scope statements; you might have to redo your MOP. You will find that constantly monitoring and testing your planning in this manner will keep you on track. It will keep you from creating more or less than what you should be creating for your project.

How Big Is This Project?

91

Teaming You should get your key players engaged while you are working the scope statement and WBS. You start this relationship with a private meeting with each of your core team members. You will want to cover some fundamental things in this meeting. Make a list to ensure that each is covered in detail. • Introductions—In this conversation, you cover your background and experience, and how they relate to this project. Don’t be afraid to talk about your weaknesses; you will want to make sure that the people on your core team help cover your weaknesses. Take time for your core team member to do the same. You already know some of the strengths of this person, or you wouldn’t have asked for him or her to be on your team. This member might bring other areas of strength to the project that you are not aware of. • Reporting relationship—This part of the conversation should cover the reporting relationship between the two of you. You will cover the authority and accountability you have been granted as the project manager. Make clear your expectations for performance and your input into this member’s appraisal. If this is a true cross-functional relationship, you will document what the person will be asked to do and then ask the team member and immediate supervisor to sign off on the work. Also make clear that this person has been hand-selected for this project because of his or her expertise. This member is special, and you respect him or her for what is brought to the table. • Risks—Spend the rest of your time together talking about the project itself. What risks does the person see with the project as a whole and his or her particular area? You are trying to do get the person to talk about his or her fears so that you can understand them better. The more you get this member to talk, the more information you have. Be sure to jot down some notes for risks that you will capture later. The most important part of this conversation is you listening. • Next steps—At the end of the meeting, tell the new core team member what the next steps will be in getting the project started. Let this member know where you are in the planning of the project and where his or her expertise will be used. Also let the member know that at the first team meeting, you will be creating team norms together. Ask the member to start thinking about what those norms should contain.

92

Chapter 3

After you have this preliminary conversation with each person individually, your next step will be the first meeting with your core team; the next chapter covers this.

Politics Earlier in this chapter, I talked about product requirements. I introduced an audience identification list that should be built to determine who should be included in creating, verifying, and signing off on requirements. I also identified three important informal roles that you need to be aware of when working on requirements: • Champions—The people who will work with your product every day. They are credible, and their coworkers believe what they say. Including them in your requirements audience could get the opposition in line. • Influencers—The people who advise the approvers. They are the ones who call the executives and tell them that the requirements are ready for signatures. • Challengers—The people who have something to gain if you miss requirements and, therefore, miss delivering the MOP of the project. This same strategy works with your total project and with the politics that can happen on a project. Take the time to review your “what’s in it for them?” list from the last chapter. Would you consider each of those stakeholders a champion, an influencer, or a challenger? Update your list with a determination of what role each person plays in relation to your project and the success of your career. Okay, you’ve updated your list and you’ve had informal meetings with each person on your list (if you did as was suggested in the last chapter). You now have to figure out how to build some strong alliances with the people on your list. Determine who is the most powerful and influential champion, influencer, and challenger. Don’t be surprised if these three people turn out to be executives as well as some of your team members or peers. These three people will be the primary target for alliance building. If you are successful with them, you can always go back to your list and determine who the next three people are or decide for yourself that these three people are strong enough in their positions to help you gain acceptance of your project.

How Big Is This Project?

93

How do you build an alliance while being ethical and genuine? By getting to know the top influencer, champion, and challenger. Remember, you have a common interest with these people: your project. Use this common interest as a way to open the door to an alliance with them. Let’s talk specifically about a strategy for each of these people: • Champions—These are the people who work with the product every day. The other product workers look to them for informal guidance and, most of the time, follow their lead. You should be interested in what these people think of your project. It behooves you to know them personally. You’ll want to set up time to frequently touch base with them: coffee, lunch, you know the drill. It is important that you pay personal attention to these people. Seeking them out shows your acknowledgment of their position as champions. In your discussions regarding the project, use their concerns as risks. When they provide positive feedback, ask if you can quote them on their remarks. When you run into opposition, quote the champions’ comments to the dissenter. Other people in the department will notice that you value the champions’ opinions. This will let a lot of people feel confident that they are being listened to via the champions’ voices. • Influencers—Again, these are the people who advise the approvers of the project. These folks might be your peers or confidants of the approvers. They also could be a trusted administrative assistant. Your strategy with influencers is to shower them with information about the project. Whenever you have anything positive to report, send them an e-mail or stop by their desks for a chat. They might think this is pretty strange if you haven’t taken the time to get to know them and start to build a relationship. So start with the informal meeting and again find common interests that you share. As you get to know them better, find out their opinions regarding the project. If it’s positive, follow the strategy presented earlier on working with the champion. If it is negative, follow the strategy presented next for the challenger. • Challengers—These people have something to gain if you miss requirements and, therefore miss delivering the MOP of the project. Your strategy is to find out what they are worried about. Again, get to know them and seek them out. As you find out more about them, find out what they are worried about. As you listen to them, turn the negative things that they are worried about into risks that you will use to

94

Chapter 3

create mitigation plans. Slowly but surely, as you continue to listen to them, you will finally get to the personal worries that are bothering them. Chances are it will have something to do with a basic fear that they will no longer be competent because of the changes you are creating with your project. It is your job to make sure these people have enough information about the new project and its work so they can start mentally trying out how it will be to work in the new environment. If you take action on all their worries, they will either stop talking negatively about the project, or they will lose credibility because they continually bring up the same problems that the rest of the team knows you are working on. The bottom line for all of these roles is this: You always need to know what these people think about your project. This shouldn’t be hard because the topic of every conversation is your favorite topic: your project. As you get to know these people better, look for any favors you can do for them. Don’t compromise your integrity here, but look for things that make sense and that you don’t mind doing to help build the allegiance. As you do more for them, ask them to return the favor by talking to dissenters or to do things on behalf of the project.

Summary We continued with the work of progressive elaboration in this chapter. We added more information to the preliminary scope statement to create the scope statement for the project. Part of what helps you define the scope is a definition of the product of the project. We spent a lot of time exploring product requirements and the steps you go through to create a good set of product requirements that will help you succeed in creating the right product. We then created the work breakdown structure. We explored the different levels of a WBS and created one for the training time reduction project. We then covered a technique called desk testing that helps you guarantee that your project stays in scope during every level of decomposition. In “Teaming,” we started to engage the key players of the project, and in the “Politics” section, we explored how to build alliances and successfully create confidence in your project. Now let’s see what Chris Williams has been doing on her project. She’s about to have her meeting on the MOP and begin with the scope statement.

How Big Is This Project?

95

Case Study Chris finished her order of magnitude estimate about an hour before her meeting with June and was relieved that all her agenda items were finally ready. She planned to talk to June about reporting directly to her, making sure that June would be the executive sponsor, and to discuss the MOP for the project, a position announcement, and the order of magnitude estimate that she just finished. Chris doubled-checked her materials before she hurried down the hall. After a brisk conversation 45 minutes later, Chris emerged from June’s office. She had answers to all her questions, and the meeting had gone well. June was impressed with Chris’s presentation of the MOP and how she had derived it. When June understood the concept, the wheels in her head started turning. She agreed that the “best in show”concept was good, but she also thought that actually being voted that was a little aggressive—especially because they had never entered this market and had never participated in this show. June asked Chris what the total points possible for the show would be. She also asked what the typical number was to win Best in Show. After finishing this discussion and realizing that the best anyone could get was 150 points, June decided that the MOP should be “Virtually Nostalgia will receive more than 125 points at the nostalgia trade show.” This MOP was aggressive yet achievable. Chris had to admit that she felt relieved with this MOP. Chris was disappointed with the reporting structure arrangement. She would continue reporting into the IT department, but June had at least decided to let her report directly to CIO Ken Hyde. June did agree to stay on as the executive sponsor, even though her calendar was pretty full. June wanted Chris to use Ken for issue resolution whenever Chris couldn’t see June fast enough. June did agree to send out an announcement regarding Chris’s new position and to cover her accountability and authority level. The last part of the conversation covered the order of magnitude estimate. June had put away $150,000 for the budget. After Chris looked at the preliminary scope statement she had created, she thought she would need about $250,000 as an order of magnitude for the project. Chris explained to June that she would know exactly how much was needed as soon as she finished her planning. June agreed to wait a while longer to set the final budget until she heard back from Chris. She also told Chris to try to keep the budget at $150,000.

96

Chapter 3

Chris headed back to her desk and decided it was time to start working on the deliverables for the project. She was nine months away from the actual show and knew that she would have to show progress over the coming months to make sure that management could see the progress. She also knew that this strategy would help management keep confidence in her and the project. Chris created some preliminary notes on the deliverables. She decided that the marketing plan for the event should probably be the first deliverable. She wondered whether she could deliver that in about three months. From there, she would create an event plan that would detail exactly what would be done for the event. She was hoping that she’d be able to complete the entire plan with specific details about a month or two after that. The final deliverable would be the event itself and the achievement of the “more than 125 points awarded.” Chris knew that she needed to get her core team together fairly quickly to lay out the WBS and verify the deliverables and the timing she was hoping to achieve. One more thing: Chris decided it was time to create a name for the project. She played around with a couple of titles and finally settled for Virtually Nostalgia Launch Event. Her company was big on acronyms, so she would refer to it as VNLE. Over the last couple days, Chris had been thinking about her core team and pretty much knew what people she wanted to get on her team. Even though she’d been thinking about who she wanted, she really hadn’t been doing her homework on building alliances with the executives she was going to work with to get the right people. Figure 3.15 depicts her ideal core team. Chris knew she was going to have problems getting Robin Good on her team. Robin really lived up to her name and was in high demand for challenging work. Chris had not taken the time to build an alliance with Karla Christie, Robin’s boss. In fact, Chris hardly knew her. Chris was afraid that if she didn’t do some relationship work with Karla, she’d end up with Someone Notsogood instead of Robin (she chuckled to herself). Chris asked Ken to set up a meeting with Karla, Ken, and Chris so that they could be introduced and Chris could tell her about the importance of the project. At the meeting, Chris noticed some negativity from Karla regarding the project. She decided that it was not yet time to ask for Robin for the team. The next day, Chris called and asked Karla to lunch. Chris asked for a crash course in marketing plans, one of Karla’s favorite topics.

How Big Is This Project?

97

June Jackson CEO

Ken Hale CIO

John Robinson VP Business Development

Greg Peterson VP Sales

Carl Price VN Web Project Manager

Karen French Business Development

Bill Ricardo Sales

Karla Christie VP Marketing

Robin Good Marketing

Chris Williams Project Manager

Sue Kim COO

Tina Johnson Logistics

Carol Hinnant Catalog Development

Figure 3.15 The core team.

The lunch went well. Chris asked a lot of probing questions and also got a crash course in marketing plans! When Karla talked about her concerns regarding the project, Chris took notes and told Karla that she would turn these into risks. At the end of the meeting,Chris was able to convince Karla to let Robin work on the project as a risk-mitigation plan. Mission accomplished! Shortly after the lunch with Karla, Chris started setting up her “getting to know you meetings” with the core team. She had a lot to do before they would get to finish the planning of the WBS and start requirements.

Review Questions 1. In the preliminary scope statement, you captured the project objec-

tive, the MOP driver, and the project constraints in the form of the MOP restrictions. What two pieces of information are added to these to create the project scope statement?

98

Chapter 3

2. Explain product requirements creation and the four logical steps to 3. 4.

5. 6. 7. 8. 9. 10.

create requirements. What are the two deliverables out of the setup step of product requirements? Explain the requirements gathering step of product requirements, as well as the four topics you must know to gather requirements successfully. What are the three levels of product requirements? What two approaches are used to confirm requirements? Explain the baseline and control step of product requirements. What is a work breakdown structure? What is usually depicted in the first level of a WBS? What is desk testing?

4 Laying Out the Work In preparing for battle, I have always found that plans are useless, but planning is indispensable. —Dwight D. Eisenhower

Topics Covered in This Chapter Defining Tasks Sequencing the Work Teaming Politics Summary Case Study

You’ve created a sound WBS and are ready to cover the next step in progressively elaborating the schedule of your project. This chapter covers taking the work breakdown structure to a lower level of detail in creating a task list—or, as it is sometimes called, an activity list. I give you some rules that will help you create the right level of detail for this list. Next you add more detail to each task by creating completion criteria. This activity helps you and the person working on the task be clear about what “done” looks like. With this detail created, it is time to lay out the work in the form of a network diagram. I spend some time on definitions and then create a network diagram for the example project. In the “Teaming” section, I spend some time on the stages of team development. I also cover the first meeting of your core team and the agenda items that should be covered to get the team moving through the stages of team development.

99

100

Chapter 4

One of the tools and techniques I use in the “Teaming” section is called team norms. These are basically the rules of engagement that the team will use to work with each other. I expand on this topic in the “Politics” section and talk about the rules of engagement when working with executives. In the case study, you will watch Chris as she gets started working with her core team. She’ll conduct the first team meeting and start working on the WBS. Let’s get started defining the tasks for the project.

Defining Tasks In the last chapter, you put together your work breakdown structure. You’ll remember that the lowest level of the WBS is the work package level. You might think that you are done with the WBS and ready to move to sequencing the activities, but in reality, you should think through another step before you move on to sequencing. That step is defining the tasks. You already have a great start based on what you put in the WBS, but here are some checks that will guarantee that you have workable activities. Let’s see how you think through creating tasks.

Creating the List of Tasks First, you need to gather some data that will help you determine the best set of tasks for your project. Start with the scope statement, deliverables, and project plan that you completed in Chapter 3,“How Big Is This Project?” Review these one more time to refresh your memory on what you are trying to deliver for this project. Then talk to other project managers in your organization to see if they have lessons learned concerning task creation. Can you find out what has gone well and what has gone not so well? Apply these lessons learned to what you are about to do. Also see if similar previous projects have had tasks like what you need to do. You might be able to use them directly on your project after some analysis. Finally, review what you have created with the WBS that you crafted in the last chapter. You will now do another level of decomposition on those work packages, if necessary. You’ll determine whether they need to be decomposed by doing the following analysis on the lowest level of your WBS. • Possible task duration—The PMBOK® Guide states that a task should be between 40 and 80 hours in length for you to manage it

Laying Out the Work

101

properly. The real question here is, how long can a task be out of control and you, the project manager, not know about it? You should create your tasks at a level low enough that you can make a status check and know whether the work is progressing properly for the time it has been estimated. One way to determine the proper length of tasks is by looking over the proposed duration of the project. If the length of the project is several months, you know you will need to collect status once a week or every couple of weeks. Therefore, your tasks should be one to two weeks in duration. If your project is several years in length, you will probably collect status every month to six weeks. Therefore, your tasks should be about a month in duration. Get the picture? • “To do” versus empowerment—Here’s where the tough part comes in. You need to weigh your ability to control the project schedule against the ability to empower your team members. No one likes to be told what to do, so you want to make sure that your tasks are not a to-do list. You want to give your team members enough flexibility to determine the right work to complete a task. You’re going to ask for top-notch people to work on your project. Do you need top-notch players when all they are doing is ticking off a to-do list? If this is the caliber of team members you’ll have, you’ll want to respect the credentials that they bring to the table by allowing them to be creative and find the right way to get the work done. Team members perform better when they are given the leeway to determine the right way to get the work done. The only time you might allow an exception to this empowerment thinking is when you have a small task that is critical to your success. The task could be only four hours in length, but because of its criticality, you might decide to leave it as a single task and not have it absorbed into a larger task. • Real activity?—One more check you will want to do is to ask yourself,“Is this a real activity?” Again, you will verify that each task has a noun and a verb. If that’s the case, you have an action that is being done on a thing that builds an activity. The other analysis you can do at this stage is to ask yourself,“What does ‘done’ look like?” Is a tangible thing created when the task is done? How will you tell if the task is completed? You know that you have a good list of tasks if you can answer these questions for every task.

102

Chapter 4

With the analysis competed, you will break down the tasks at the lowest level of the WBS even further. Let’s go back to the training class time reduction project and see how this is accomplished. Figure 4.1 shows the WBS. Reduce customer service representative training time more than 50%

1.0 Current state documentation

2.0 Training time reduction approach documentation

3.0 A customer service rep training course that is 50% less time than the previous course

1.1 Interview CSR supervisors

2.1 Create approach document

3.1 Conduct the first class

3.7 Adjust the class for 50% less

1.2 Determine current customer complaints

2.2 Determine whether to rewrite or start over

3.2 Time the class

3.8 Verify the training class is 50% less

1.3 Determine current training time

2.3 Create learning objectives

3.3 Verify customer complaints are < 2%

3.9 Conduct pilot class

1.4 Create document

2.4 Determine whether to use a new technology

3.4 Train the trainer

3.10 Verify learning objectives are met

3.5 Design the class

3.11 Create textbooks

3.6 Create job aids

3.12 Build the class

1.5 Investigate what is currently trained

Figure 4.1 Training class time reduction WBS

Laying Out the Work

103

You determined early on that this project should take about nine months to complete (as an order of magnitude time estimate). The triple constraints documented in the project plan also show the project being completed in the fourth quarter. So based on that proposed duration, you will be doing status meetings once a week with your project team. That means that the project manager will want tasks that can be completed in one or two status meetings or one to two weeks. Looking at the lowest level of the WBS, it looks like you are in pretty good shape. Most of the tasks look like they are about one to two weeks in length. Things such as “Create the approach document” should be done in that time frame. It might take a little longer, but that should be okay. A couple tasks are really short, as with “Verify that the duration of the training class is 50 percent less.” But that verification helps you meet the MOP for the project, so you likely decide to leave it on the WBS as is. One of the tasks says “Create document.”That won’t do. You need more information to make that a real activity that someone can complete successfully. Change that activity to “Create current state document.” Also, it’s hard to tell what you mean by “Time the class.” Is that the pilot class or the first public class? Clarify that by changing it to “Time the pilot class.” Here’s a problematic item: “Build the class.” The rule of thumb for training development is eight hours of development for every one hour of classroom time. The current training course is now 200 hours long; you have to get it to less than 100 hours. That means you have about 800 hours of development that must be accomplished—that is 20 weeks! You’ll have to break that down into modules to keep track of progress. When you finish your analysis and further decomposition, you now have this list of tasks: MOP: Reduce customer service representative training time by more than 50 percent 1.1 1.2 1.3 1.4 1.5 2.1 2.2

Interview CSR supervisors. Determine current customer complaints. Determine current training time. Create current state document. Investigate what is currently trained. Create approach document. Determine whether to rewrite or start over.

104

Chapter 4

2.3 2.4 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12.1 3.12.2 3.12.3 3.12.4 3.12.5 3.12.6 3.12.7 3.12.8

Create learning objectives. Determine whether to use a new technology. Conduct the first class. Time the pilot class. Verify that customer complaints are less than 2 percent. Train the trainer. Design the class. Create job aids. Adjust the class to 50 percent less. Verify that the training class is 50 percent less. Conduct the pilot class. Verify that learning objectives are met. Create textbooks. Create class module 1. Create class module 2. Create class module 3. Create class module 4. Create class module 5. Create class module 6. Create class module 7. Create class module 8.

With the task list now completed, you should gather any notes that you have put together and make sure that they are documented in the project plan with the list of tasks.

Completion Criteria Some of the most effective project plans contain some additional information regarding what “done” looks like for a task, or what are sometimes called completion criteria. Defining completion criteria makes it clear between you and the person working on the task when it is acceptable to say you are done. When you ask a teenager to clean his or her room, you know the teen’s definition of “done” is usually different than your definition. This is actually an easy technique that takes very little time and has great rewards. With the

Laying Out the Work

105

teenager, you might want to specify things like 1) bed made, 2) dirty clothing in washroom clothing basket, 3) clean clothes hung in closet or folded in drawers, 4) dirty dishes placed in dishwasher, etc. With this additional detail, you have a better chance of getting the results you are asking for. Let’s take a few minutes and go back over the lists of tasks and put together completion criteria for each.

Details, Details By the way, as you move through your project-planning activities, you will find that some of your lists and diagrams can get very long. No need to read every line just make sure you understand the concept. For those of you who love detail, though, I have included all the planning elements.

Reduce customer service representative training time by more than 50 percent 1.1 Interview CSR supervisors. CC: Three supervisors interviewed. Typed notes of interviews. 1.2 Determine current customer complaints. CC: The percentage of customer complaints per month for the last 6 months. Top types of complaints for each month. 1.3 Determine current training time. CC: Syllabus for current class. Document showing actual duration for classes held in the last six months. 1.4 Create current state document. CC: Document describing current details verified and signed by CSR supervisors. 1.5 Investigate what is currently trained. CC: Review of current materials. Document describing current training and materials used. 2.1 Create approach document. CC: Reviewed and signed by the project manager and sponsor. 2.2 Determine whether to rewrite or start over. CC: Pros and cons list. Documented decision-making process.

106

Chapter 4

2.3

Create learning objectives. CC: Document describing the learning objectives.

2.4

Determine whether to use a new technology. CC: Pros and cons list. Documented decision-making process.

3.1

Conduct the first class. CC: All exercises completed. Class evaluations from students.

3.2

Time the pilot class. CC: Document showing timing of each module, both estimated and actual time.

3.3

Verify that customer complaints are less than 2 percent. CC: The percentage of customer complaints per month for the last six months for newly trained CSRs. Top types of complaints for that time period.

3.4

Train the trainer. CC: All exercises completed. Class evaluations from students.

3.5

Design the class. CC: Spreadsheet that shows topics and exercises for each day and duration for those topics and exercises.

3.6

Create job aids. CC: Laminated job aids for inclusion in textbooks.

3.7

Adjust the class to 50 percent less. CC: Spreadsheet that shows estimated class time to actual class time. Documented adjustments that get to 50 percent reduction.

3.8

Verify that the training class is 50 percent less. CC: Document that class is 50 percent less, verified by students and signed by project sponsor.

3.9

Conduct the pilot class. CC: All exercises completed. Class evaluations from students.

3.10 Verify that learning objectives are met. CC: Document that shows mapping of learning objectives to postclass exam. Document that shows pilot students passed the exam at greater than 80 percent. (Pass rate of 80% for post-class exam.) 3.11 Create textbooks. CC: Physical textbooks are created and ready for pilot class.

Laying Out the Work

107

3.12.1 Create class module 1. CC: Document containing student textbook for this module. Document containing instructor notes. Documented handouts. Documented exercises. 3.12.2

Create class module 2. CC: Same as 3.12.1.

3.12.3 Create class module 3. CC: Same as 3.12.1. 3.12.4 Create class module 4. CC: Same as 3.12.1. 3.12.5 Create class module 5. CC: Same as 3.12.1. 3.12.6 Create class module 6. CC: Same as 3.12.1. 3.12.7 Create class module 7. CC: Same as 3.12.1. 3.12.8 Create class module 8. CC: Same as 3.12.1. Completion criteria can be built for all tasks or can be applied to just a critical few that you don’t want to take any chances on. Of course, this wonderful information needs to be documented in your project plan.

Task Notes A handy, dandy place to put your completion criteria is in the task notes in Microsoft Project. For more information, see Chapter 3 of Microsoft Project for Mere Mortals, by Patti Jansen.

Sequencing the Work Now that you have created the list of tasks that must be completed on your project, it’s time to figure out the best sequence in which to perform the work. The objective here is to lay out the work correctly. “Correctly” in this case means to lay it out the way it should be done if everything in the world

108

Chapter 4

was perfect and the stars aligned. You’re not going to pay any attention to the people needed to do the work. You’re also not going to pay any attention to how long it might take to get the work done. This exercise is really about the work itself, the natural sequence of how things should be done. I deal with the resources and the duration of the project in later chapters. Also forget about the fact that the boss wants the project done in six months and that your gut is saying this is more like a year-long project. To get started on this step, you need some definitions to ground you. You’ll start with the concept of dependencies.

Dependencies Webster defines a dependency as “something that is dependent on something else.” In the case of project management, this is actually a task that is dependent on another task. Basically, that means something can’t start until something else completes first. You must investigate the dependencies between your tasks to understand the natural sequence of the work. You can think of dependencies as three different types: • Mandatory—A mandatory dependency is a dependency that is inherent in the work itself. It’s the way the work has to be performed. As an example, you need to scrape off the old paint before you apply primer, before you actually paint the house. Now, you could do this work in a different order, but you would probably not like the results of what you’ve done. • Discretionary—A discretionary dependency is a dependency that is created by the project team because of the way it wants to get the work done. Say that you are running a manufacturing project and you have two different sets of machinery that can be used to produce your product. The first set of machinery requires three steps, and the second requires the same three steps done in a different order. The second set produces better widgets than the first. You decide to use the second set of machinery because it produces a product closer to your specifications. The reordering of the steps is a discretionary dependency. • External—An external dependency involves a relationship between the task of your project and an event or a task outside of your project. For example, your organization is ordering a new hardware platform that will be installed in two weeks. Your project will share this

Laying Out the Work

109

platform with two other applications. The organization ordering and installing the hardware is outside your project, but you are dependent on it being there in time for you to complete your project. You must determine the type of dependencies required for each of your tasks on your project. In addition to understanding the dependencies, you must understand dependency relationships.

Dependency Relationships Another set of definitions that you need to understand concerns the topic of dependency relationships, or how you describe the dependency between the two tasks. Let’s start first with two words that project managers use a lot: successors and predecessors. • A successor is a task that is done directly after another task. • A predecessor is a task that is done directly before another task. There are four types of dependency relationships: • Finish-to-start—In a finish-to-start relationship, the successor cannot start until the predecessor finishes. This relationship is usually shown as in Figure 4.2.

Task A

Task B

Figure 4.2 Finish-to-start relationship

In Figure 4.2, Task B cannot start until Task A is completed. As an example, Task B, painting, cannot start until Task A, priming, is completed. This is the most common relationship used and the way most people think. • Start-to-start—In a start-to-start relationship, the successor cannot start until the predecessor has started. Figure 4.3 shows this relationship. As an example, Task B, documentation, cannot start until Task A, the product requirements, are started.

110

Chapter 4

Task A

Task B

Figure 4.3 Start-to-start relationship

• Finish-to-finish—In a finish-to-finish relationship, the successor cannot finish until the predecessor has finished. Figure 4.4 shows how this relationship is usually depicted. As an example, Task B, documentation, cannot be finished until Task A, the requirements, are finished.

Task A

Task B

Figure 4.4 Finish-to-finish relationship

• Start-to-finish relationship—In a start-to-finish relationship, the successor cannot finish until the predecessor starts. Very few project managers actually use this relationship, which is depicted in Figure 4.5. Most people do not think in this manner. The only example of this relationship comes from a student in one of my classes who was in the

Laying Out the Work

111

Korean War. At the end of the war, the Koreans and Americans decided to throw a celebration. The Koreans had a major piece of the celebration to plan, and so did the Americans. The Americans, Task B, started their planning and were ready to announce that they were finished. The Koreans, Task A, had not started their planning yet. The Americans determined that they could not finish until the Koreans had at least started their planning.

Task A

Task B

Figure 4.5 Start-to-finish relationship

• Lag time—Yes, I know I said that there were only four relationships, but you also need to understand another factor: the concept of lag time. Lag time is used between a successor and predecessor task to depict some passage of time that must occur before you can start the successor task. Look back at the example in Figure 4.2. Task B, the painting, cannot start until Task A, the priming, is completed. You would probably add some lag time between these two tasks because you want the primer to be dry before the painting begins (at least, that’s what the paint can says you should do).

Dependency Relationships in Microsoft Project See how Microsoft Project handles dependency relationships in Chapter 5 of Microsoft Project for Mere Mortals, by Patti Jansen.

Creating a Network Diagram Now that you have finished defining some of the concepts you’re going to need, it is time to lay out the work of the project. The work will be laid out via a method called precedence diagramming. This method depicts the tasks

112

Chapter 4

as a box and uses lines with arrows to depict the logical relationship between the tasks. Figures 4.2–4.5 were all examples of the precedence diagramming method. When you finish using the precedence diagramming method, you will have created a network diagram. So how do you go about creating a network diagram? A great technique for completing your network diagram is to put your tasks on yellow sticky notes and find a large blank wall and some butcher paper. Put the butcher paper on the wall so you can draw lines between the yellow sticky notes. This technique will give you a great visual for your work, as well as allow you to move tasks easily until you have the network diagram the way you want it. You start by removing all the summary-level tasks. If you look back to the activity list depicted in Figure 4.1, those are items like “1.0: Current state documentation,”“2.0: Training time reduction approach documentation,” and “3.0: Customer service representative training time reduced by more than 50 percent.”You are really not interested in the summary-level work in creating a network diagram; you want to concentrate on sequencing the tasks. Next, look over the task list you created and determine what should be done first. You’ll come to realize that, in the training project, several things can be done in parallel if you have enough people to get the work done. (Remember, you’ll look at resources later.) Take a look at Figure 4.6, and you’ll see what I mean. You will line up these tasks to be done in parallel. That would be the right way to get the work done. Now look back at the task list and determine the successor to the task “Interview CSR supervisors.” The successor is the task “Create current state documentation.” Next, determine the successor tasks for the rest of your beginning tasks. Basically, you do the same for every task in the task list: determine the predecessor and successor for each piece of work.

Laying Out the Work

113

Interview CSR supervisors

Determine current customer complaints

Determine current training time

Investigate what is currently trained

Figure 4.6 The beginning of the network diagram

You continue this process through your diagram until it looks like Figure 4.7. You’ll notice that I used finish-to-start relationships throughout the diagram. In a couple places, I could have used a start-to-start relationship, but instead I chose to use the finish-to-start relationship. This relationship is how most people think. It is especially useful when working with a new team. If you have worked with a team before and you know that the members understand the dependency relationships, you can use the more complex relationships.

114

Chapter 4

You’ll also notice that I added two more tasks to the network diagram: “Create pilot textbooks” and “Revise material after the pilot.” These tasks are shown in Figure 4.7 in gray. When you create a WBS and a task list, even with the best processes in place for creating the work, you will find that you are still missing tasks. The rule of thumb is that you can expect to be missing 20 percent of the total tasks for your project. This process of laying out the work in a network diagram is essential for catching the tasks that are missing. You really can’t see what is missing until you sequence the work. Be sure to go back to your WBS and task list, and add the tasks that you just discovered.

Create class module 1

Interview CSR supervisors

Determine current customer complaints

Determine current training time

Create learning objectives

Create current state document

Determine whether to use a new technology

Create class module 2

Create approach document

Determine whether to rewrite or start over

Investigate what is currently trained

Design the class

Create class module 3

Create class module 4

Create class module 5

Create class module 6

Create class module 7

Create class module 8

Figure 4.7 A network diagram in development

Create job aids

Laying Out the Work

115

Look back through your diagram and verify that every task has a predecessor and a successor. You’ll notice that you have not defined the successor for the task “Train the trainer.”You’ll add a line and an arrow to the successor task of “Conduct the first class.”You might ask, what do you do with the beginning and ending tasks, since each of them must have a successor and predecessor? For those tasks, you complete the network diagram by adding a start and finish milestone to the diagram. You now have completed your network diagram (see Figure 4.8).

Network Diagrams in Microsoft Project When you understand how to manually create a network diagram, you should see how Microsoft Project creates this diagram for you in Chapter 5 of Microsoft Project for Mere Mortals, by Patti Jansen.

Create pilot textbooks

Conduct pilot class

Revise material after the pilot

Verify learning objectives are met

Verify the training class is 50% less

Time the pilot class

Figure 4.7 Continued

Create textbooks

Train the trainer

Adjust the class to 50% less

Conduct first class

Verify customer complaints are < 2%

116

Chapter 4

3.12.1 Create class module 1

3.12.2 Create class module 2

1.1 Interview CSR supervisors 2.3 Create learning objectives

3.12.3 Create class module 3

1.2 Determine current customer complaints 1.4 Create current state document

Start

2.4 Determine whether to use a new technology

2.1 Create approach document

3.5 Design the class

3.6 Create job aids 3.12.4 Create class module 4

1.3 Determine current training time 2.2 Determine whether to rewrite or start over

3.12.5 Create class module 5

1.5 Investigate what is currently trained

3.12.6 Create class module 6

3.12.7 Create class module 7

3.12.8 Create class module 8

3.13 Create pilot textbooks

3.9 Conduct pilot class

3.14 Revise material after the pilot

3.10 Verify learning objectives are met

3.8 Verify the training class is 50% less

3.11 Create textbooks

3.4 Train the trainer

3.7 Adjust the class to 50% less

3.2 Time the pilot class

Figure 4.8 A completed network diagram

3.1 Conduct first class

3.3 Verify customer complaints are < 2%

End

Laying Out the Work

117

You should perform one more check at this stage of laying out your work. Again, you go back to desk testing, a topic I covered in Chapter 3. This time, you will inspect the network diagram and verify it against the WBS and task list. Ask yourself these questions: • Are all the tasks from the WBS and task list covered in the network diagram? • Have I added tasks that are out of scope for what needs to be created? You can verify the first question by reviewing your network diagram numbering scheme against the WBS activity list and its numbering scheme. Make sure that none of your yellow sticky notes fell on the floor and didn’t get captured in the network diagram. The second question guarantees that you have added anything that is not warranted. You now can move on to find out how this stage of planning the project affects teaming.

Teaming In the last chapter, you spent some time with each of your new core team members. You had personal meetings with each of them and discussed things such as reporting relationships, their view of project risks, and next steps. You also spent some good quality time just getting to know each other. Now that the personal meetings are completed, it’s time to pull together your core team for your first team meeting. Before we launch into that agenda, however, let’s talk about team dynamics. In 1965, Bruce Tuckman created a model that describes the steps of working together that a normal project team goes through in creating an effective team: • Forming—Orientation to the project’s objectives, the project manager, and each other • Storming—Struggles for control, power, and influence • Norming—Cooperation and establishment of productive work practices • Performing—Interdependence, cohesiveness, and high productivity

118

Chapter 4

These phases of team development are easy to remember and make sense, so I use this model to describe the things you will need to do to move people through these phases to get them to perform as an effective team. I spend this chapter talking about the forming phase. As you can see from the short description provided, the forming stage is all about getting to know each other. Even more than that, it’s about getting the people on the team comfortable with each other. Remember the last team you were on and that awkwardness you felt when you didn’t know the people on the team? You were probably afraid to say anything, for fear that it might sound stupid. You also didn’t know the other team members’ areas of expertise, nor did they know yours. You might have been a little shy about speaking up, not wanting to risk looking silly. The forming stage is all about getting these team members comfortable with each other and with taking the risk to speak up and speak their mind. You have already spent some time with the team members in the forming stage. You did this in the introductory meeting. In it, you spent time getting to know them and they you. You now know the expertise they bring to the table. And because of that, they are starting to get more comfortable with you. You will continue the forming process in the first team meeting and start to get the team members comfortable with each other. Forming has not occurred yet because the team really hasn’t had the time to work together much. So what should be on your agenda for the first team meeting? The first item you will want to cover is introductions. You want the team member to disclose information about themselves so that each person in the room understands the contribution that they will make. You can do this simply by asking each person to talk about his or her background and experience. Or, if your project management style is more creative, you can do things such as the following: • Pair up each person with someone they don’t know or haven’t worked with very much. Have them interview each other regarding background and experience. Have person A interview person B. Have person B interview person A. Then ask person A to tell the whole group about person B, and vice versa. • Create a team resumé by having each person provide a few details about his or her experience and background. Use a flip chart to capture this information, and format the information resumé style.

Laying Out the Work

119

These are just two examples of how this can be accomplished. To find other ideas for effective introductions, think back to one of your previous training classes. What did the instructor do for introductions? Also, if you are interested, pick up a good book for training instructors that provides examples on training methods and exercises. When you have finished the introductions, you, the project manager, need to tie together the pieces of introduction information for the group. You might comment on the talent in the room or on the fact that each area of expertise needed for the project is covered by the individuals sitting in this meeting. The point is, if this team works effectively together, this project will go well. You want the members to know the possibilities of performance that can be achieved with this team. Everyone wants to work on a winning team. If you have time on your agenda, you might want to consider some type of team-building exercise. I know, this sounds old-fashioned and corny, but there is really some merit in doing this type of work. Again, you are looking for ways for these people to get comfortable with each other. This exercise could be as simple as having each person relate the type of animal he or she is like and why. You could have everyone go to lunch together. You could get personality profile tests and have everyone talk about their results. I think you get the idea. You are looking for any method that will get these people talking to each other and get them to know each other. Your next agenda item for the first core team meeting should be a technique called team norms. Team norms could also be called rules of engagement, or how the team members will work with each other. You might put together this list via brainstorming in the first core team meeting. You should facilitate the discussion, making sure everyone has a chance to speak. If you can’t facilitate, bring in someone outside your team to do the facilitation. Start by asking the core team about pet peeves when working on a project. What normally works for them? What doesn’t work for them? As people start to talk about items that bother them, you might end up with things on the list such as these: 1. We will respect each other’s opinions. 2. If a person has a problem with me, they will come to me first before

talking about the problem with someone else. 3. If you are late for a meeting, it’s your responsibility to get caught up. We will not start the meeting over for anyone.

120

Chapter 4

As the project manager, you will want some specific things on the list that have to do with how the team works also. You will want to include things such as these: 4. We agree to complete our tasks on time. If we believe we are going to

miss the end date on a task, we will tell the project manager as soon as we suspect we might miss the date. 5. After the project baselining is completed, if we find a problem in creating the product, we all agree to funnel that problem through the change-management process instead of just fixing it on our own 6. We agree not to make any unauthorized changes to the product, regardless of who asks. You’ll find these last two team norms especially useful when it comes to setting up your change-management system. But that’s jumping ahead; I cover that topic in Chapter 13,“Controlling Changes.” When everyone has had a chance to express how they want to be treated or how they are going to work together, go over the list that has been created. If there are duplicate team norms, try to merge them into one thought. Be sure to ask permission of the submitter before you change one of the thoughts. This demonstrates respect, which is one of the behaviors your team is striving for. When the duplicates are removed, ask your core team if there is any norm on the board that they cannot live with. Go around the table and ask each person. If someone has a problem with a norm, you will need to facilitate the changing of the norm until everyone agrees. When you have agreement, you once more need to ask each person if he or she can live with what has been created. If everyone agrees, you will create a document with the norms listed that everyone on the core team will sign. I’ve seen project managers put the signed team norms into picture frames and display them on each team member’s desk. That way, they become a constant reminder of the expectations. Your last agenda item should be a discussion of the project Measure of Performance, objectives, and any other project-planning work that was completed before the core team arrived on the project. Spend a significant amount of time setting the context of the project for the core team. Make sure you answer their questions and capture their concerns. Set the stage for how your meeting will work in the future with this meeting. One meeting-management technique that can be very useful is having

Laying Out the Work

121

preformatted issue, action item, and risk forms on the table during the meeting. Before moving on, let’s define each. • Issues—I define an issue as an item that needs discussion or research to complete. You’ll assign one person to be accountable for resolving the issue. You will also document the other people required to solve the issue. Make sure you note the start date and ask the responsible person to give you an estimated end date. Figure 4.9 shows the documentation normally captured for an issue. Issue #

Originator

Open Date

Due Date

Status

Issue Description

Resp

1.

Joe S.

4/15/07

4/30/07

Yellow

We cannot determine if funding was Sue provided for the development resources. Research with Finance and Executive Sponsor.

Resolution/Comments/Status

Closed Date

4/20 — Meeting held with executive sponsor. Need meeting with Finance.

Figure 4.9 An issues list form

• Action items—Action items are similar to issues, but the direction is clear and action just needs to be taken to complete the work. Again, you will assign the action item to one person to provide resolution. Keep track of the originator, the start date, and the due date. Allow space for the status and close date. Figure 4.10 shows the form used for action items. Issue #

Originator

Open Date

Due Date

Status

Action Item Description

Resp

Resolution/Comments/Status

Closed Date

1.

Sue O.

4/07/07

4/10/07

Yellow

Find out, who is running the XYZ project.

Sue

Jose Levy is the project manager for the XYZ project.

4/08/07

Figure 4.10 An action item list form

• Risks—Risks are such an important subject to a project that I devote an entire chapter to that subject in Chapter 8,“Risk—What Should You Worry About?.” I introduce a form for risk identification there.

122

Chapter 4

Keep blank risk, issue, and action item forms on the meeting table. When someone on the team brings up a pertinent point, ask that person to document what he or she just covered. At the end of the meeting, gather the forms and input them into a log, where you will track the completion or resolution of each item. This shows the team members that they will be heard and that problems will get documented and resolved. All these agenda items will get the team oriented to the project, to your style of project management, and to each other. The faster you get them through the forming stage of team development, the faster they will move through the rest of the stages and become a cohesive team that delivers.

Politics At this stage of your project, you are still able to plan your offensive moves concerning politics. In later chapters, I talk about some defensive moves to make when your offensive moves haven’t been enough to keep the politics at bay. In “Teaming,” I covered a technique called team norms. You used this technique to set up some effective ground rules for how the team will work together. Let’s now talk about team norms for the executives. Now, you might not be able to have a facilitated discussion in which you and the executives write down how you want to work together, but you will want to keep some fundamental items in mind while working with executives. Make your own list of executive team norms, and keep them handy as you are working with them. • Effectively utilize executive time—Every time you meet with an executive, make sure you have a clear agenda of points that need to be covered. Rummaging through papers trying to find the next topic is not the way to impress executives with your organization skills. • Be a bottom-liner—Summarize your information into a couple bullet points. Allow the executives to drill down where they need more information. Always assume that brevity is the best path unless told differently.

Laying Out the Work

123

• Delegate up—When action is needed and the people who are needed to complete the action are at a higher level than you, delegate up. Ask your executive sponsor to conduct a meeting, provide introductions, or make a phone call. Be clear about who needs to be contacted and what the action or message is. Executives will do what is necessary if you are clear about your needs. • Bring problems and solutions—When you have problems concerning your project and need the guidance of the executive sponsor, bring a solution with you. Have in mind a couple ways that the problem can be solved. Present these ideas with the problem. Executives don’t like having problems dumped on them with no solution in sight. • Use gentle reminders—Don’t assume that executives remember every detail of the conversation you had two weeks ago. They have probably talked to a hundred people since that time, and chances are good that they probably don’t remember exactly what was said before. Start your conversation with a gentle reminder, such as,“The last time I provided status, we talked about the issues with the Finance department not providing funding for the widget as we needed. You suggested….” • No surprises—When you have bad news about your project, make sure the executives get the information as soon as you get the information. Don’t allow them to be surprised by bad news from a source other than you. That “no surprises”rule is one usually learned in the school of hard knocks. A project manager I know was managing a very high-profile project. Late on a Friday night, her team finished a critical test for the product. The product failed. The project manager mentioned later that she thought about calling her executive sponsor but decided to not ruin his weekend. On Saturday afternoon, she received an irate phone call at home from the sponsor. He was livid. He had been out shopping with his wife and ran into the director of the Product Testing department. The director, of course, had heard about

124

Chapter 4

the failure. The testing director stopped the sponsor in the mall and asked him what he was going to do about the product failing the test. Needless to say, the executive sponsor was caught off guard and embarrassed. Armed with these team norms, you’ll have a better chance of building a wonderful rapport with the executives you work with. Sometimes the easiest way to fight politics or back-biting is by having the person who is receiving the information not believe it in the first place because they know you and your style.

Summary In this chapter, we applied another level of progressive elaboration to the WBS created in the last chapter, to create the task or activity level. Then we added some more detail to each task by creating completion criteria. This completion criteria gives the person who will do the work the definition of “done.” We then used the precedence diagramming method and created a network diagram that depicts the actual sequence of the work. In “Teaming,” we explored Bruce Tuckman’s model on the stages of team development. We also covered the first core team meeting and the agenda items you should consider using in your first meeting. We expanded on the Tuckman model in our “Politics” section and discussed the rules of engagement for working with executives. Now let’s see what Chris Williams has been doing on her project. She’s about to have her meeting on the MOP and begin the scope statement.

Case Study Chris was feeling pretty good about her accomplishments so far on the project. Getting Robin Good on the team was a significant accomplishment. Yet Chris knew she had a long way to go before she could say she was even making good progress. She had already completed the one-on-one meetings with

Laying Out the Work

125

the core team and was ready to conduct the first joint core team meeting. She knew this agenda would be critical for establishing how the team would work in the future. As Chris thought about the agenda, she came up with the following topics to cover: 1. Team introductions—Chris decided to use a technique that she had

seen in a previous training class. This technique has each participant draw a lifeline for themselves that includes their birth through today. On the lifeline they mark significant personal and professional events. They also include events that make them prepared for working on this team. 2. Team-building exercise—Chris had participated in an exercise in one of her previous classes that she thought was really good at stimulating team cooperation. In this exercise, the team goes out to the company parking lot or into a large room. Everyone spreads out, and a tennis ball is tossed from one person to the next. The rule of the game is that every person must touch the ball. The facilitator times how long it takes for the ball to be touched by every person. At the end of the first round, the facilitator challenges them to do it again, but faster. The team continues to go through rounds of passing the ball, each time a little faster. They continue this until someone comes up with the idea that if the team stands shoulder to shoulder and everyone just puts their hands out, they can all touch the ball in about 2 seconds. The exercise really opens your eyes to listening to everyone’s ideas— and the closer you get, the better the work gets done. 3. Team norms—Chris decided that she would bring in an outside facilitator for developing the team norms. She has a friend in the company who is a professional trainer. Chris will ask that person to help. Part of the reason Chris will use the facilitator is that she has several items that she wants included on the team norms list. That last project of hers was a killer when it came to change management. She wants to make sure that the mistakes she made on that project are the last time those mistakes happen in her career. Chris also realizes that it would be inappropriate for her to participate in and facilitate the session.

126

Chapter 4

4. Project orientation—In this section, Chris will talk to the team about

the project progress to date. She will cover the Measure of Performance and the preliminary scope statement. She will also cover the project organization. Chris believes that everyone should have a “you are here” picture, like the mall provides. Chris will also spend some time with the group talking about the last vendor trade show from the information she has been able to get so far. Last but not least, she will cover the project plan, what has been documented to date, and what else needs to be covered. 5. Brainstorming the WBS—Chris decides to get the team down to some “roll up your sleeves work” while the project orientation is fresh in their minds. She decides to go ahead and start the brainstorming exercise for the WBS. Chris looked over her agenda and decided that she was satisfied with what she has planned. She also thought she should plan for the session to be an allday event. With that done, she starting looking at the core team’s calendar’s to see if she could find a day in the next week that would work. A week later, at 5 p.m., Chris sat in the conference room and reflected on the first core team meeting. She was exhausted. The day had started at 8 a.m. and had just finished a few minutes ago. She was pleased with the results, though. The lifelines were interesting, and each person had talked briefly about the skills that they brought to the table. When the lifeline exercise was done, Chris spent some time summarizing each person’s skills. She herself was amazed at the caliber of people who made up her core team. She was pleased to be working with them. She had visions of a “Best in Show” award even though all she needs for this project is a score better than 125 points. The team-building exercise was a lot of fun, even though they felt silly out in the company parking lot tossing tennis balls around. It took them only four rounds before the team figured out how to get the ball touched in 2 seconds. Everyone was laughing and having a great time. Chris still felt like they got the point of the exercise.

Laying Out the Work

127

The team norms were a little controversial. Chris was pleased that she had her friend facilitate. A lot of ideas needed to be reworded, but they finally got to the point that everyone agreed on the eight items they had listed. Chris was able to get three of the team norms that she thought were important on the list. Two were about change management, and one was about task deadlines. The project orientation took longer than expected. The core team had a lot of questions and concerns. Chris was pleased that she had put together her forms for issues and action items; they came in handy as they were discussing the project. Even though they had captured lots of issues, the team felt that the MOP was attainable, even though it would be challenging to get high points at a show that they had never attended. The WBS also took a little longer than expected. But there was some good thinking going on in the room. The team had decided that the three major deliverables that Chris had determined a week ago were okay, and they decided to use those deliverables as the summary levels of the WBS. It took a while to build the lower levels of the plan, but they had gotten it done. They decided to create an intermediate level on the WBS, tasks by department. This really helped their thinking on who needed to do what. It was funny, though; in the end, they decided to drop that intermediate level. It created too many duplicates pieces of work that really were not necessary. Chris glanced at the wall at their finished WBS, depicted in Figure 4.11, and wondered if they had missed any tasks. She knew there was a good chance that they were missing some tasks, but they would figure that out in a couple days. She had scheduled the next core team meeting for the day after tomorrow. They would start to tackle creating a network diagram at that meeting.

128

Chapter 4

Virtually Nostalgia would receive > 125 points at the nostalgia trade show

1.0 Create trade show marketing plan

3.0 Implement trade show

2.0 Create detailed trade show plan

Go to next page 1.1 Gather previous trade show information

2.1 Design the booth sales approach

2.8 Review and revise demo requirements

1.2 Gather input from other departments

2.2 Create IT demo requirements

2.9 Design demo

1.3 Establish marketing goals

2.3 Design the trade show experience

2.10 Determine housing and travel requirements

1.4 Determine target audience

2.4 Design the marketing collateral

2.11 Gather marketing materials and booth shipping requirements

1.5 Create draft marketing plan

2.5 Design the booth

2.12 Determine catering requirements

1.6 Review and revise draft plan with other departments

2.6 Determine vendor partnership strategy

2.13 Determine trade show on site requirements

1.7 Create final marketing plan

2.7 Determine target vendors

2.14 Verify product inventory supports marketing plan

Figure 4.11 VNLE WBS

Laying Out the Work

Implement trade show

3.1 Prepare for trade show

3.2 Manage the trade show

3.1.1 Arrange fights and lodging

3.1.8 Establish pre meetings w vendors

3.2.1 Verify and correct logistics

3.1.2 Ship marketing materials and booth

3.1.9 Build marketing collateral

3.2.2 Manage the tradeshow event

3.1.3 Make catering arrangements

3.1.10 Build the booth

3.2.3 Staff the booth

3.1.4 Finalize trade show on site arrangements

3.1.11 Build demo

3.2.4 Get feedback for vendor experience during event

3.1.5 Verify product inventory supports trade show plan

3.1.12 Test demo

3.2.5 Receive > 125 points for trade show

3.1.6 Prototype the booth experience

3.1.13 Create Tradeshow buzz

3.1.7 Learn and practice demo

3.1.14 Verify web site is ready

3.1.15 Verify catalog is ready

Figure 4.11 Continued

129

130

Chapter 4

Review Questions 1. What three things should you think about when deciding to decom2. 3. 4. 5.

pose your work packages into smaller tasks? Why do you create completion criteria? What are the three types of dependencies? What is a successor task? What is a predecessor task?

6. What are the four types of dependency relationships? 7. What is lag time? 8. What is the output of the precedence diagramming method? 9. Describe the Bruce Tuckman Model of team development. 10. What is another name for team norms?

5 The Art of Estimating “Any project can be estimated accurately (once it’s completed).” —Mike Harding Roberts

Topics Covered in This Chapter Estimating Definitions Estimating Techniques What to Estimate Teaming Politics Summary Case Study

You’ve used the WBS and dependency analysis to create a network diagram. The next step in planning your project is to create estimates for the work that is depicted in the network diagram. You’ll get started with this chapter by looking over some definitions of terms used when estimating. In those definitions, I also talk about the different types of estimates and when each is used in the project life cycle. Next you’ll explore the different estimating techniques and when they are most commonly used to create estimates. You’ll then go back to the running example and actually create estimates for the duration, the work effort, and the resources needed for each task. As you create the estimates, you’ll get clear about when each of these estimates is created and what each is used for in the project. In the “Teaming” section, you’ll spend some time looking at a technique you can use to build the team while you get estimates created. In “Politics,” you’ll figure out how to deal with a boss who creates estimates for you.

131

132

Chapter 5

In the case study, Chris and the team will use the WBS and create the network diagram for the VNLE project. Chris will then start planning her next moves to finish the estimates for the project. Let’s move onward, then, to creating estimates.

Estimating Definitions Let’s start this chapter by defining some terms used when estimating any component in a project. Let’s get clear about the core concept: estimating. Estimating is the act of valuing or appraising something. For projects, you appraise certain items and put a value on them. In project management terms, you appraise things such as the project itself, phases of work, and tasks. The value, in this case, might be how long something will take, how many resources are needed, or how much something will cost. You will use this technique from the start of the project all the way to the end—yes, really to the end because you might have change requests coming in toward the end of the project that need to be estimated. In Chapter 2,“You’ve Been Assigned a Project!,”I briefly covered the different types of estimates: order of magnitude, definitive, and budget estimates. Let’s review each again. • Order of magnitude estimate—An order of magnitude estimate is usually done in the early stages of a project. Creating this estimate involves evaluating several major influences on the size of the project, comparing them to similar previous projects, and drawing relatively quick conclusions from them. I talk more about the techniques for creating estimates in a following section. Some people liken an order of estimate to a swag (a swag is an estimate that you know is not right but is at least close) or, to put it more bluntly, a guess. To be precise, an order of magnitude estimate is a calculated guess. You’ll find these estimates used mostly in the construction and engineering industries, but they can be used anywhere. This estimate is also sometimes called a top-down estimate. That term is really pretty descriptive because you are evaluating it from the perspective of the concept of the project, with very little information. In other words, you are looking at the top and then down through the project to try to figure out what it will take to put the project in place.

The Art of Estimating

133

• Definitive estimate—Webster defines the word definitive as “serving to define or specify precisely.” That is exactly what a definitive estimate is: a precise measure for a specific element of a project. Definitive estimates are also known as detailed, or bottom-up, estimates. These estimates are derived by reviewing each task and assigning estimates to each. These estimates are the most precise type of estimate you can create. Definitive estimates are created in the planning process when all tasks are known. Three types of definitive estimates are used: work effort, duration, and calendar. • Work effort—A work effort estimate is the amount of time that it takes to complete a piece of work without any interruptions. Say, for example, that your boss gave you an assignment to create a document. He asks you to work on it until it’s completed, and he’d like to review your first draft. You start the assignment on Monday at 8 a.m. You work until 10 a.m. and then take a 30-minute break for coffee and for returning e-mail. You start again at 10:30 a.m. and work until noon, when you stop for lunch. You continue developing the document from 1 p.m. until 2 p.m., when you get some more coffee and attend a quick meeting with a colleague until 3 p.m. You then work until 5 p.m. On Tuesday, you start working on the document promptly at 8 a.m. You finish the first draft at 10 a.m. and give the document to the boss. At 2 p.m., the boss returns the document, with markups. You work on creating the final version from 2 p.m. to 5 p.m. You leave it on the boss’s desk as you head out the door for home. The work effort for this task is shown in Table 5.1. Table 5.1 Work Effort Calculation Day

Time Spent

Work Effort

Monday

8 a.m.–10 a.m.

2 hours

10:30 a.m.–12 p.m.

1.5 hours

1 p.m.–2 p.m.

1 hour

3 p.m.–5 p.m.

2 hours

8 a.m.–10 a.m.

2 hours

2 p.m.–5 p.m.

3 hours

Tuesday

Total Work Effort

11.5 hours

134

Chapter 5

In creating a work effort estimate, you are doing the same thing you did to arrive at this work calculation. You are determining what it will take to complete a task when you track the actual time spent on the work and remove all the interruptions from the work to be done. • Duration—A duration estimate is the time it takes to complete a task when all interruptions are considered. Interruptions are not just when the phone rings, but are anything that stops the work from progressing. In this case, an interruption is the weekend, a vacation day, a trip to the doctor’s office, etc. In the previous example of creating a document, you look at the total amount of work that is accomplished, including the interruptions to calculate the duration. Take a look at Table 5.2 for the duration calculation. Table 5.2 Duration Calculation Day

Time Spent

Duration

Monday

8 a.m.–5 p.m.

1 day

Tuesday

8 a.m.–5 p.m.

1 day

Total Duration

2 days

You see here that working all day Monday and all day Tuesday constitutes the total duration of two days. Count the span of time from start to end, regardless of what has transpired in between. You started the work on Monday morning and finished it on Tuesday at the end of the day, so the duration is two days. • Calendar—A calendar estimate is the number of calendar days a task will need to run to completion. In the previous example on duration estimates, the task will require two calendar days. If the same task was started on Friday and completed on Monday after noon, you would say that the task took four calendar days. • Budget estimates—A budget estimate is an estimate that describes the total amount of money needed to cover the project. This estimate covers the cost for all the tasks of the project, as well as all resources for the project and any other fees that also need to be paid. I talk about budgets at length in Chapter 10,“Budgeting—How Much?.” A budget estimate is usually created before the actual work of the project begins, in the planning phase.

The Art of Estimating

135

It’s a great idea to spend a little time with your project team talking about the different types of estimates before you begin the estimates on your project. You want to make sure that everyone is talking about the same type of estimate when they provide an estimate. Your project could end up way out of whack if you are talking about duration estimates and your team is providing work effort estimates. Now that you understand these definitions, let’s talk about some techniques you can use to create the estimates on your project.

Estimating Techniques Creating an estimate can be both an art and a science. It’s an art because it is a skill acquired by experience, study, or observation of other projects. It’s also a science because you can apply statistics to what you are doing that will refine and polish your estimates. I cover a series of techniques here so you can choose the proper technique for your next project.

Analogous Estimating In the dictionary, you’ll find that the word analogous means showing a likeness that permits one to draw a conclusion or comparison. That is exactly what you do when you use the analogous estimating technique to estimate elements of your project. Using this technique, you will find a completed project that is similar to the project you are trying to estimate. You use your own expert judgment to determine what project is similar. You also use expert judgment to determine exactly what estimating elements you can reuse for your project. Say, for example, that you work in a research kitchen and you are starting a project to determine the exact nutrition contents of a new food item for the nutrition guidelines printed on the can. Chances are good that you have done these types of projects before. The new food item is peaches in a new top-secret syrup. Your boss has asked how long it will take to complete this analysis because several more new food items are coming to your research kitchen, and she is trying to determine how many food items you will be able to analyze in the next month. Looking back through your notes, you find a project in which you analyzed a new brand of peaches. You also find a project in which you analyzed a new special secret sauce. You would determine

136

Chapter 5

whether you should use the previous peaches, the previous secret sauce, or a combination of the two to use as a baseline for your estimate. When you determined the right baseline to use, you would then extrapolate any variations that might need to be accounted for. Variations would include things such as differences in the product or changes in costs (labor, chemicals, other materials, availability of test kitchens, etc.) since the last project. Taking all these things into consideration, you would then produce an estimate. This technique produces what are sometimes called top-down estimates. They are also called order of magnitude estimates, which I covered in the definitions section. Because analogous estimating can be very subjective, it is usually not very accurate.

Parametric Estimating Parametric modeling is a computer-based estimating method. In this mathematical model, data from thousands of previous projects is analyzed. The specific data that is analyzed includes product elements and their costs and schedules. A product element is standard to the particular industry that you work in. In the construction industry, a product element could be laying a foundation of a particular size, framing, drywall, etc. So if you are building a house, your model would be able to tell you that it typically takes X days to install a fiberglass front door that is 36 × 80. You could change the parameters of the front door and create a new estimate for a double door with side window panes. Parametric modeling tends to be more accurate than analogous estimating. The accuracy really depends on the quality of the underlying data. Parametric models are available for a lot of different industries.

Bottom-Up Estimating Bottom-up estimating is the most accurate and reliable method of estimating that is available. It requires that a single task be analyzed and estimated. For example, you might have a project that entails restructuring your shipping department for better efficiency. You have tasks such as “Move shelving unit to north area,”“Refurbish the product bins,” etc. You and your team would analyze each task by itself to understand exactly what it would take to complete the work. An estimate would be created that reflects that precise task.

The Art of Estimating

137

Three-Point Estimating Three-point estimating uses the estimate created in a bottom-up estimate and improves it by considering the amount of risk in each of the original estimates. These three points are considered: • Most likely—This should be the estimate that was created in the bottom-up estimate. It basically is your best guess of what has to be done to complete the task. • Optimistic—The optimistic estimate is derived by looking at the most likely estimate and determining how long it will really take if everything goes very well when executing the task. • Pessimistic—The pessimistic estimate is created by again looking at the most likely estimate and determining how long it will really take if everything goes very poorly when executing the task. In the previous bottom-up estimate, I used a task example of “Move shelving unit to north area.” In that estimating exercise, you came up with five days as the most likely time period. You would now reanalyze that estimate for an optimistic estimate. If everything goes very well, it could take as little as three days to complete the shelving move. Next you reanalyze the most likely estimate. You might determine that if Murphy’s law is in effect, it could probably take ten days to complete the task. With the three numbers created—5 (most likely), 3 (optimistic), and 10 (pessimistic), you would add them and create an average (6 days) that you can use as your estimate.

Reserve Analysis Another factor that you can apply to your estimating technique is called reserve analysis. Reserve analysis requires that you review your estimates for risk and apply an amount of padding to the estimate. This padding is also sometimes called adding reserve or contingency time. Make sure that, before you add reserves to your estimates, the original estimator hasn’t already done so. Two methods are commonly used to apply reserve to your estimate. In addition, I discuss the more sophisticated PERT approach. Commonly Used Methods The first method is applying a standard percentage. A lot of project managers just apply a 10 percent reserve to each of their estimates. In this case, a

138

Chapter 5

10-day estimate is now 11 days. There is no science to what you are doing here; you are just applying a little wiggle room in case your estimates are off. You could, however, review every task on your project schedule and apply the percentage of padding only to the tasks that have some risk associated with them. The second commonly used method for applying reserve is padding each estimate by a certain amount of work periods. You would build some type of formula to use or just apply more time or money to each task. In the previous example of “Move shelving unit to north area,” you have never moved a two-story shelving unit. You have estimated five days for the work but realize that there is risk associated with doing a task that has never been done. If that is the case, you might change the estimate to seven days. If you want to provide a more precise science to the art of reserve analysis, you might consider using the Program Evaluation and Review Technique (PERT) as a way of using statistics to determine what reserve to apply. PERT Estimating PERT estimating is very much like the three-point estimating technique that you looked at earlier. The primary difference is that, instead of using an average to calculate the new estimate, it uses expected values or weighted averages to perform the calculation. PERT relies heavily on the mathematics of probability. PERT can be used to provide more confidence to estimates that could be shaky. To do a PERT calculation, you start with the same three-point estimates of most likely, optimistic, and pessimistic. When you know the three estimates, you do a calculation to determine the weighted average. I call this the estimate. Next, you determine the standard deviation. The standard deviation is kind of an average difference among values, so, in this case, the standard deviation is a kind of average of the differences in your three estimates. You can use this calculation to determine the amount of additional time that can be added to the estimates to provide more confidence. Finally, you add the weighted average (estimate) to as many standard deviations as you need to establish the level of confidence you are looking for. Now examine your task “Move shelving unit to north area”and do a PERT calculation using the following steps:

The Art of Estimating

139

1. Determine an estimate of the number of days needed to complete the

task. The PERT formula for this calculation (based on what is called the Beta distribution) is: Estimate = (Optimistic + [4 × Most Likely] + Pessimistic) / 6 Your three-point estimates were 5 (most likely), 3 (optimistic), and 10 (pessimistic). So your calculation would be: Estimate = (3 + [4 × 5] + 10) / 6 Your estimate is 5.5. 2. Determine the standard deviation for the estimate. The PERT formula

for this calculation (based on the Beta distribution) is: Standard Deviation = (Pessimistic – Optimistic) / 6 Standard Deviation = (10 – 3) / 6 The standard deviation is 1.2 (rounded). 3. Determine the confidence level you want to achieve. Add the mean to

a standard factor multiplied by the standard deviation. Table 5.3 shows the standard factor and formula for each confidence level. If a task absolutely, positively has to be completed on time, you use the 99 percent confidence level. Table 5.3 Standard Factors and Formulas for Each Confidence Level Confidence Level

Standard Factor

Formula

50%

0

Estimate

60%

0.25

Estimate + (.25 × SD)

70%

0.53

Estimate + (.53 × SD)

80%

0.84

Estimate + (.84 × SD)

90%

1.28

Estimate + (1.28 × SD)

95%

1.65

Estimate + (1.65 × SD)

99%

2.33

Estimate + (2.33 × SD)

Using the 99 percent confidence level shown in Table 5.3, your task “Move shelving unit to north area” should have an estimate of 8.5 days (half-days rounded). The calculation is: (5.5 + [2.33 × 1.2]) = 8.3

140

Chapter 5

PERT estimating is sometimes applied to every single task of a project, as a method of reserve analysis. It is also sometimes applied to only a few tasks that have high risks associated with those particular tasks or to critical-path tasks. PERT Estimates Computer programs can help in this analysis. Obviously, if you do this for more than a handful of tasks, the calculations become overwhelming!

Expert Judgment The last estimating technique I cover is probably the most important and accurate technique that you can use. In this technique, called expert judgment, you look for an expert in a particular area to estimate the tasks in that particular area. If you are going to remodel your kitchen, you would want a kitchen remodeler to create the estimates; you would not use the fence builder to create the estimates for this type of work. This expert judgment technique can be used with all the other techniques to create more accurate estimates. The best scenario you can get in estimating is to have the actual expert create the estimate as well as do the work of the task. But I talk more about that later in the “Teaming” section of this chapter. Now that you have reviewed the different estimating techniques, you will need to decide what is the right technique or combination of techniques to use at what point in time for your project. For example, you might decide to use a combination of analogous and parametric estimating to create order of magnitude estimates at the beginning of your project. You might also decide to use bottom-up estimates and parametric modeling for the planning phase of your project. If you are really in doubt about your estimates, use several of the suggested techniques and see where the estimates converge. Let’s spend some time now talking about what to estimate on a project.

What to Estimate Now you have a chance to apply what you’ve learned about the different types of estimates and the different estimating techniques to a project. Then you’ll learn about what to estimate. Estimates are applied in a couple areas in

The Art of Estimating

141

projects. First, you estimate how many resources you will need on a project. Then you estimate the duration of the project. Finally, you estimate the cost of each task. This section covers each area and also updates the training example project.

Resource Estimation Resource estimating determines what resources will be used on a project and what quantities of each resource are required. These estimates are usually done in the planning process after the network diagram is created and before the schedule and costs of the project are finalized. Before you start the process of thinking through these estimates, I should clarify what I mean by “resources.” When I talk about project resources, I am not just talking about people; I am talking about any type of resource that can be used on a project, such as equipment or materials. Say, for example, that you’ve decided to take on putting up a new 6-foot fence for your home. You want to make sure you cover all the costs of the project so that you have all the resources covered. For the human resources, you and your brotherin-law will do the work. This won’t cost you anything in labor, but you know you’ll have to buy him a pizza for lunch and possibly a beer. For equipment, you already have a couple hammers, so that won’t be a problem. You’ll need to rent a post hole digger from the rental center. That should cover you on equipment. For materials, you’ll need wood, pizza, beer, nails, and gasoline for the post hole digger. Expert project managers make sure that the slightest or smallest resource needed is covered in their plan. Okay, now that I’ve covered the types of resources, let’s talk about the thought process that goes on when doing resource estimating. In this process, the project manager analyzes each task and determines what resources should be applied to each task. Before you do the actual estimating, you will want to verify a couple considerations. First, you need to understand your organization’s policies when it comes to securing resources. Ask questions such as these: Is there a procurement organization that I will have to work with if I need a contractor or consultant? Do we have a petty cash fund that I can use for incidentals? What about materials? Are they covered in my department’s budget, or are they items that I’ll have to make sure my project covers? I think you get the picture. With this knowledge, you can now move to the second consideration.

142

Chapter 5

Next, you need to understand what resources are available. Put together a list of the types of resources you might need. You will need to determine exactly when the types of resources you need will be available. If you are making a movie and you want a big-name star in your movie, you’ll probably need to schedule a year in advance to secure the type of actor you’re looking for. You might be able to shoot other scenes until that big name is available. Okay, with those items covered, you can begin your estimating process. The most accurate approach you can take with resource estimating is bottom-up estimating. Basically, you look at every task by itself and determine what type of resource is needed. At this point, you are not naming a specific name; you are looking for a type of resource. For a new food product that is being created in your organization’s test kitchen, you must determine how many chefs you will need versus whether Chef Jean Claude is available. You’ll get down to naming names in Chapter 9,“Creating the Schedule.” You continue through this analysis until you have determined what resources will be used for each task. But you start with creating a list of the types of resources you will need to execute your project. You also need to provide the total universe of resources of that type that could be available for working on your project. Let’s go back now to the training class time reduction project. This is the running example project used in the previous chapters. First review the MOP and the task list. Your MOP looks like this: MOP: Reduce customer service representative training time by more than 50 percent

The list of tasks includes the following: 1.1 Interview CSR supervisors. 1.2 Determine current customer complaints. 1.3 Determine current training time. 1.4 Create current state document. 1.5 Investigate what is currently trained. 2.1 Create approach document. 2.2 Determine whether to rewrite or start over. 2.3 Create learning objectives.

The Art of Estimating

2.4 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12.1 3.12.2 3.12.3 3.12.4 3.12.5 3.12.6 3.12.7 3.12.8

143

Determine whether to use a new technology. Conduct the first class. Time the pilot class. Verify that customer complaints are less than 2 percent. Train the trainer. Design the class. Create job aids. Adjust the class to 50 percent less. Verify that the training class is 50 percent less. Conduct the pilot class. Verify that learning objectives are met. Create textbooks. Create class module 1. Create class module 2. Create class module 3. Create class module 4. Create class module 5. Create class module 6. Create class module 7. Create class module 8.

You review the list and determine that you need the following resources: • • • • • • • •

Project manager Course developers Pilot class Trainers Graphic artist Regular class Technologists CSR supervisors

144

Chapter 5

• • • •

Training room Textbooks Reproduction facilities Customer service rep computer systems

The next step is to determine how many of these resources are available in the organization. You talk to HR, customer service, and training organizations, and now have this updated list shown in Table 5.4. Table 5.4 Resource Needed and Available Resource Needed

How Many Available?

Project managers

1

Executive sponsors

1

Course developers

3

Pilot classes

1

Trainers

4

Graphic artists

2

Regular classes

3

Technologists

2

CSR supervisors

5

Training rooms

2

Textbooks

100

Reproduction facilities

2

Computers

7

Customer service rep computer systems

3

The final step in estimating resources is to determine how many resources will be needed for each task of the network diagram. Start with the first four tasks in your network diagram, shown in Figure 5.1. You analyze each task and determine the appropriate resources needed to complete the task. Let’s start with task 1.1,“Interview CSR supervisors.”After thinking about this task, you determine that you would like the lead course developer to conduct that interview with you, the project manager. You also realize that interviewing the CSR supervisors is an opportunity to get to know the supervisors a little better, so you decide that every one of the supervisors should be interviewed.

The Art of Estimating

145

1.1 Interview CSR supervisors

1.2 Determine current customer complaints

1.3 Determine current training time

1.4 Investigate what is currently trained

Figure 5.1 The first four tasks

For task 1.2,“Determine current customer complaints,” you know you will get that information from the CSR supervisors, so the resources will be the same as in the first task. For task 1.3,“Determine current training time,” you decide that you have set up this network diagram pretty well because you can get that information from the CSR supervisors also. But you also add the current trainers as part of that discussion; you want their perspective on the timings, too. Task 1.4,“Investigate what is currently trained,” again has you talking to both the CSR supervisors and the current trainers. You would continue through the network diagram of tasks until you complete the resource estimation for each and have created a list such as the one shown in Table 5.5.

146

Chapter 5

Table 5.5 Resource Estimates Task

Resource Estimate

1.1 Interview CSR supervisors

1 course developer 1 project manager 5 CSR supervisors

1.2 Determine current customer complaints

1 course developer 1 project manager 5 CSR supervisors

1.3 Determine current training time

1 course developer 1 project manager 5 CSR supervisors 4 trainers

1.4 Create current state document

1 course developer 1 project manager

1.5 Investigate what is currently trained

1 course developer 1 project manager 5 CSR supervisors 4 trainers

2.1 Create approach document

1 course developer 1 project manager

2.2 Determine whether to rewrite or start over

1 course developer 1 project manager 1 executive sponsor

2.3 Create learning objectives

1 course developer

2.4 Determine whether to use a new technology

1 course developer 1 project manager 2 technologists 1 executive sponsor 1 customer service rep system

3.1 Conduct the first class

1 trainer 1 training room 1 regular class 20 textbooks 1 customer service rep system

3.2 Time the pilot class

1 course developer 1 CSR supervisor 1 project manager

3.3 Verify that customer complaints are less than 2 percent

5 CSR supervisors 1 course developer 1 project manager

147

The Art of Estimating

Task

Resource Estimate

3.4 Train the trainer

1 course developer 1 customer service rep system 4 trainers

3.5 Design the class

1 course developer 1 customer service rep system 1 project manager

3.6 Create job aids

1 course developer 1 graphic artist 1 project manager 2 computers

3.7 Adjust the class to 50 percent less

4 course developers 4 computers

3.8 Verify that the training class is 50 percent less

4 course developers 2 CSR supervisors 1 project manager

3.9 Conduct the pilot class

1 trainer 1 pilot class 1 project manager 2 CSR supervisors

3.10 Verify that learning objectives are met

1 trainer 1 pilot class 1 project manager 2 CSR supervisors

3.11 Create textbooks

1 course developer 1 reproduction facility

3.12.1 Create class module 1

1 course developer 1 computer 1 graphic artist

3.12.2 Create class module 2

1 course developer 1 computer 1 graphic artist

3.12.3 Create class module 3

1 course developer 1 computer 1 graphic artist

3.12.4 Create class module 4

1 course developer 1 computer 1 graphic artist continued

148

Chapter 5

Table 5.5 Resource Estimates Task

Resource Estimate

3.12.5 Create class module 5

1 course developer 1 computer 1 graphic artist

3.12.6 Create class module 6

1 course developer 1 computer 1 graphic artist

3.12.7 Create class module 7

1 course developer 1 computer 1 graphic artist

3.12.8 Create class module 8

1 course developer 1 computer 1 graphic artist

That completes the exercise in resource estimating. You move on now to the next estimating activity, duration estimating.

Resources in MSProject Have you been wondering how to set up resources in Microsoft Project? Be sure to check out Chapter 5 of Microsoft Project for Mere Mortals, by Patti Jansen.

Duration Estimation Duration estimating is determining how long it will take to complete a single task on the network diagram. These estimates are usually done in the planning process after the network diagram is created and before the schedule and costs of the project are finalized. Earlier in this chapter, we talked about the definition of a duration estimate. A quick reminder: A duration estimate is the time it takes to complete a task when all interruptions are considered. Determining the length or duration of each task leads you to how long your entire project will take. But I’m getting ahead of myself; I cover that in Chapter 9 when I discuss creating the schedule.

The Art of Estimating

149

Let’s start this thought process by first determining the measure of time you will use to create your duration estimates. You want to make sure that everyone on your project who is creating duration estimates uses the same measure of time. If everyone is providing hours as the basis, you don’t want one person providing the estimate in months. It just makes it too hard to translate when you’re trying to figure out how long it would take to get the project done. For the training time reduction project, I said earlier that this will probably involve an order of magnitude duration of nine months. Use that order of magnitude to start your analysis about what time scale to use. As you think through the time scale, you might realize that months will not work because this is only a nine-month project. The time scale of weeks is a possibility. Remember the discussion in Chapter 4,“Laying Out the Work,” about how long a task can be out of control and you, the project manager, not know about it? You realize that weeks will not work here because you do not want people to work weeks on end without you knowing how the work is going. The next increment down is days. If you estimate in days, you should be able to monitor how the work is getting done. The key here is to make sure that the tasks are broken down into small enough increments to make sure that you can track the work. With that analysis completed, you come to the conclusion that days is the time scale you want the entire team to use. Now it is time to determine how you will create the duration estimates for your project. You look through the different types of estimating techniques: • • • • • • •

Analogous Parametric Bottom-up Three-point Reserve analysis PERT Expert judgment

You review how each is used and determine that you will use a combination of bottom-up estimating and expert judgment.You also determine that you might be able to use parametric estimating for some of your course-development tasks if you can find the right mathematical models. You selected bottom-up

150

Chapter 5

with expert judgment because you know that inspecting each task one at a time will provide the most precise estimates. Having an expert create the estimates will also make sure they are sound. If you can get the actual person who will perform the task to create the estimate, that will be the icing on the cake. Having the actual person doing the work provide the estimate builds buy-in from that person. I talk more about that subject in the “Teaming”section of this chapter. You’ve also decided not to use the three-point, reserve analysis, or PERT estimating techniques at this point in time. You want to do some risk assessment first and then determine whether you should put the extra work into these estimating techniques. You are now ready to actually create the duration estimates for each task of your network diagram. You will find an expert (or one of the actual resources) to look at the tasks that will be assigned and have that person determine how long it will take to complete the work. Make sure that you tell your expert the time scale to use, as well as the meaning of a duration estimate. You should end up with a list such as the one shown in Table 5.6. Table 5.6 Duration Estimates Resource Estimate

Duration Estimate

1.1 Interview CSR supervisors

1 course developer 1 project manager 5 CSR supervisors

2 days

1.2 Determine current customer complaints

1 course developer 1 project manager 5 CSR supervisors

2 days

1.3 Determine current training time

1 course developer 1 project manager 5 CSR supervisors 4 trainers

2 days

1.4 Create current state document

1 course developer 1 project manager

3 days

1.5 Investigate what is currently trained

1 course developer 1 project manager 5 CSR supervisors 4 trainers

2 days

2.1 Create approach document

1 course developer 1 project manager

5 days

Task

151

The Art of Estimating

Resource Estimate

Duration Estimate

2.2 Determine whether to rewrite or start over

1 course developer 1 project manager 1 executive sponsor

2 days

2.3 Create learning objectives

1 course developer

2 days

2.4 Determine whether to use a new technology

1 course developer 1 project manager 2 technologists 1 executive sponsor 1 customer service rep system

3 days

3.1 Conduct the first class

1 trainer 1 training room 1 regular class 20 textbooks

25 days

Task

3.2 Time the pilot class

1 customer service rep system 1 course developer 1 CSR supervisor 1 project manager

25 days

3.3 Verify that customer complaints are less than 2%

5 CSR supervisors 1 course developer 1 project manager

30 days

3.4 Train the trainer

1 course developer 1 customer service rep system 4 trainers

15 days

3.5 Design the class

1 course developer 1 customer service rep system 1 project manager

5 days

3.6 Create job aids

1 course developer 1 graphic artist 1 project manager 2 computers

5 days

3.7 Adjust the class to 50% less

4 course developers 2 computers

5 days

3.8 Verify that the training class is 50% less

4 course developers 2 CSR supervisors 1 project manager

1 day

continued

152

Chapter 5

Table 5.6 Continued Resource Estimate

Duration Estimate

3.9 Conduct the pilot class

1 trainer 1 pilot class 1 project manager 2 CSR supervisors

25 days

3.10 Verify that learning objectives are met

1 trainer 1 pilot class 1 project manager 2 CSR supervisors

1 day

3.11 Create textbooks

1 course developer 1 reproduction facility

5 days

3.12.1 Create class module 1

1 course developer 1 computer 1 graphic artist

36 days

3.12.2 Create class module 2

1 course developer 1 computer 1 graphic artist

35 days

3.12.3 Create class module 3

1 course developer 1 computer 1 graphic artist

35 days

3.12.4 Create class module 4

1 course developer 1 computer 1 graphic artist

35 days

3.12.5 Create class module 5

1 course developer 1 computer 1 graphic artist

35 days

3.12.6 Create class module 6

1 course developer 1 computer 1 graphic artist

35 days

3.12.7 Create class module 7

1 course developer 1 computer 1 graphic artist

35 days

3.12.8 Create class module 8

1 course developer 1 computer 1 graphic artist

35 days

Task

Now that you have completed the duration estimates, it’s time to move to the last thing that you estimate on a project: costs.

The Art of Estimating

153

Durations in MSProject Have you been wondering how duration estimates get handled in Microsoft Project? Be sure to check out Chapter 6 of Microsoft Project for Mere Mortals, by Patti Jansen.

Cost Estimation Cost estimating is determining the cost of every task on the network diagram. These estimates are usually done in the planning process after the network diagram is created and before the schedule and budget of the project are finalized. Earlier in this chapter, you learned the definition of a budget estimate. It was defined as an estimate that describes the total amount of money needed to cover the project. A cost estimate is one of the parameters used to create the budget. Determining the cost of each task on the network diagram will lead you to how much the entire project will cost. Those costs and a couple other cost parameters will build up to your project budget. I cover budgets in Chapter 10. You must perform a couple steps in creating cost estimates: 1. Create a work effort estimate. 2. Get resource rates. 3. Apply resource rates to the work effort estimate.

Let’s go ahead and get started, then, on creating cost estimates. Earlier I defined a definitive estimate called work effort. I said it is the amount of time that it takes to complete a piece of work without any interruptions. So why am I talking about time right now when you are trying to get to costs? Well, deriving a work effort estimate is the basis for setting up costs. Work effort estimates cover the actual work performed on a project. You want to pay for only actual work; you never want to pay for the duration of a task. Here’s an example. I’m sure you or a friend or neighbor has hired a contractor before to do work around your house. As you are well aware, once a team is contracted to replace your bathroom floor, they show up on Thursday

154

Chapter 5

morning and rip out the old tile for a couple hours. Then they leave. They come back on Thursday afternoon and bring the new tile. They tell you that they’ll be back on Friday morning to lay the new floor. On Friday, they show up at 11 a.m. They work till 3 p.m. laying the new floor. At 3 p.m., they tell you they need to let the floor set and they’ll be back on Saturday at 7 a.m. to finish up. On Saturday, they show up at 9 a.m. and place the grout until 10:30. They instruct you to not walk on the floor, and they’ll be back on Monday to do the final cleaning. Monday afternoon they call and say they’ll be over on Tuesday at 8 a.m. They finally show up at 7 a.m. on Tuesday and are finished at 9 a.m. Thank goodness! If you are paying $100 an hour for duration, you would have paid $4,000 for the five days of duration for the entire project. You should have paid $1,150 for 11.5 hours of work effort. See? There is a big difference. Remember, you use work effort for costs, and you use duration for time. Work effort estimates are created a lot like duration estimates. First, you select the proper estimating technique from your list earlier in this chapter. In the case of the training time reduction project, you use a combination of bottom-up estimating and expert judgment. This is the same technique you used to create the duration estimates. If fact, most of the time, you can actually have your team members create both estimates at the same time. Just make sure that you are clear about which estimate you are creating when. Your experts have created the work effort estimate shown in Table 5.7. Table 5.7 Work Effort Estimates Resource Estimate

Duration Estimate

Work Effort Estimate

1.1 Interview CSR supervisors

1 course developer 1 project manager 5 CSR supervisors

2 days

1 day

1.2 Determine current customer complaints

1 course developer 1 project manager 5 CSR supervisors

2 days

1 day

2 days

1 day

Task

1.3 Determine current training time

1 course developer 1 project manager 5 CSR supervisors 4 trainers

155

The Art of Estimating

Task

Resource Estimate

Duration Estimate

Work Effort Estimate

1.4 Create current state document

1 course developer 1 project manager

3 days

2.5 days

1.5 Investigate what is currently trained

1 course developer 1 project manager 5 CSR supervisors 4 trainers

2 days

1 day

2.1 Create approach document

1 course developer 1 project manager

5 days

4 days

2.2 Determine whether to rewrite or start over

1 course developer 1 project manager 1 executive sponsor

2 days

1 day

2.3 Create learning objectives

1 course developer

2 days

1.5 days

2.4 Determine whether to use a new technology

1 course developer 1 project manager 2 technologists 1 executive sponsor 1 customer service rep system

3 days

1.5 days

3.1 Conduct the first class

1 trainer 1 training room 1 regular class 20 textbooks 1 customer service rep system

25 days

25 days

3.2 Time the pilot class

1 course developer 1 CSR supervisor 1 project manager

25 days

25 days

3.3 Verify that customer complaints are less than 2%

5 CSR supervisors 1 course developer 1 project manager

30 days

3.75 days

3.4 Train the trainer

1 course developer 1 customer service rep system 4 trainers

15 days

15 days

continued

156

Chapter 5

Table 5.7 Continued Resource Estimate

Duration Estimate

Work Effort Estimate

3.5 Design the class

1 course developer 1 customer service rep system 1 project manager

5 days

4 days

3.6 Create job aids

1 course developer 1 graphic artist 1 project manager 2 computers

5 days

4.5 days

3.7 Adjust the class to 50% less

4 course developers 4 computers

5 days

3 days

3.8 Verify that the training class is 50% less

4 course developers 2 CSR supervisors 1 project manager

1 day

1/4 day

3.9 Conduct the pilot class

1 trainer 1 pilot class 1 project manager 2 CSR supervisors

25 days

25 days

3.10 Verify that learning objectives are met

1 trainer 1 pilot class 1 project manager 2 CSR supervisors

1 day

1/2 day

3.11 Create textbooks

1 course developer 1 reproduction facility

5 days

4 days

3.12.1 Create class module 1

1 course developer 1 computer 1 graphic artist

36 days

28 days

3.12.2 Create class module 2

1 course developer 1 computer 1 graphic artist

35 days

27 days

3.12.3 Create class module 3

1 course developer 1 computer 1 graphic artist

35 days

27 days

3.12.4 Create class module 4

1 course developer 1 computer 1 graphic artist

35 days

27 days

3.12.5 Create class module 5

1 course developer 1 computer 1 graphic artist

35 days

27 days

Task

157

The Art of Estimating

Resource Estimate

Duration Estimate

Work Effort Estimate

3.12.6 Create class module 6

1 course developer 1 computer 1 graphic artist

35 days

27 days

3.12.7 Create class module 7

1 course developer 1 computer 1 graphic artist

35 days

27 days

3.12.8 Create class module 8

1 course developer 1 computer 1 graphic artist

35 days

27 days

Task

Now that you’ve completed your work effort estimates, you can move on to step 2 of your cost estimating process, getting resource rates. In this step, you will work with your Human Resources department, your procurement group, and anyone else who controls the data for how much a resource costs. Now, you might not be able to get the exact amount of money that a person gets paid, but you should be able to get an average or loaded rate for each type of resource. For example, the average instructor at your company might get paid $55,000 per year. You would break down that average yearly rate into a daily rate for each trainer. In some organizations, the loaded rate also includes overhead items such as benefits, office space, and other types of items. You need to be sure what is included and excluded in these rates. With your original list of resources, make sure you have a daily rate for each. You are doing daily rates because you are trying to do your estimates on a day time scale. When you are finished gathering the data, you will have a list like that shown in Table 5.8. Table 5.8 Resource Rates Resource

Daily Rate

Project manager

1 @ 350.00

Executive sponsor

1 @ 500.00

Course developers

1 @ 300.00

Pilot class

20 @ 100.00 = 2000.00

Trainers

1 @ 220.00 continued

158

Chapter 5

Table 5.8 Continued Resource

Daily Rate

Graphic artist

1 @ 200.00

Regular class

20 @ 100.00 = 2000.00

Technologists

2 @ 500.00

CSR supervisors

5 @ 300.00 = 1500.00

Training room

100.00

Textbooks

100.00 for 20 students, one time

Reproduction facilities

100.00

Computers

400.00

Customer service rep computer systems

400.00

Now that step 2 is completed, step 3 is actually pretty easy. Do the math! Take the work effort for every task and each resource, and multiply by the resource rate to determine the cost estimate for each task. Table 5.9 shows that for the training reduction time project. Table 5.9 Cost Estimates Resource Estimate

Work Effort Estimate

Cost Estimate

1.1 Interview CSR supervisors

1 course developer 1 project manager 5 CSR supervisors

1 day

300.00 350.00 1,500.00

1.2 Determine current customer complaints

1 course developer 1 project manager 5 CSR supervisors

1 day

300.00 350.00 1,500.00

1.3 Determine current training time

1 course developer 1 project manager 5 CSR supervisors 4 trainers

1 day

300.00 350.00 1,500.00 880.00

1.4 Create current state document

1 course developer 1 project manager

2.5 days

1.5 Investigate what is currently trained

1 course developer 1 project manager 5 CSR supervisors 4 trainers

1 day

Task

750.00 875.00 300.00 350.00 1,500.00 880.00

159

The Art of Estimating

Task

Resource Estimate

Work Effort Estimate

Cost Estimate

2.1 Create approach document

1 course developer 1 project manager

4 days

1,200.00 1,400.00

2.2 Determine whether to rewrite or start over

1 course developer 1 project manager 1 executive sponsor

1 day

300.00 350.00 250.00

2.3 Create learning objectives

1 course developer

1.5 days

450.00

2.4 Determine whether to use 1 course developer a new technology 1 project manager 2 technologists 1 executive sponsor 1 customer service rep system

1.5 days

450.00 525.00 750.00 250.00 600.00

3.1 Conduct the first class

1 trainer 1 training room 1 regular class 20 textbooks 1 customer service rep system

25 days

5,500.00 2,500.00 50,000.00 2,000.00 10,000.00

3.2 Time the pilot class

1 course developer 1 CSR supervisor 1 project manager

25 days

7,500.00 7,500.00 8,750.00

3.3 Verify that customer complaints are less than 2%

5 CSR supervisors 1 course developer 1 project manager

3.75 days

281.00 1,125.00 1,313.00

3.4 Train the trainer

1 course developer 1 customer service rep system 4 trainers

15 days

4,500.00 6,000.00 13,200.00

3.5 Design the class

1 course developer 1 customer service rep system

4 days

1,200.00 1,600.00

3.6 Create job aids

1 project manager 1 course developer 1 graphic artist 1 project manager 2 computers

4.5 days

1,400.00 1,350.00 900.00 1,575.00 3,600.00

3.7 Adjust the class to 50% less

4 course developers 4 computers

3 days

3,600.00 4,800.00

3.8 Verify that the training class is 50% less

4 course developers 2 CSR supervisors 1 project manager

1/4 day

300.00 150.00 87.50 continued

160

Chapter 5

Table 5.9 Continued Resource Estimate

Work Effort Estimate

Cost Estimate

3.9 Conduct the pilot class

1 trainer 1 pilot class 1 project manager 2 CSR supervisors

25 days

5,500.00 2,500.00 50,000.00 2,000.00

3.10 Verify that learning objectives are met

1 trainer 1 pilot class 1 project manager 2 CSR supervisors

1/2 day

110.00 1,000.00 175.00 300.00

3.11 Create textbooks

1 course developer 1 reproduction facility

4 days

1,200.00 400.00

3.12.1 Create class module 1

1 course developer 1 computer 1 graphic artist

28 days

8,400.00 11,200.00 5,600.00

3.12.2 Create class module 2

1 course developer 1 computer 1 graphic artist

27 days

8,100.00 10,800.00 5,400.00

3.12.3 Create class module 3

1 course developer 1 computer 1 graphic artist

27 days

8,100.00 10,800.00 5,400.00

3.12.4 Create class module 4

1 course developer 1 computer 1 graphic artist

27 days

8,100.00 10,800.00 5,400.00

3.12.5 Create class module 5

1 course developer 1 computer 1 graphic artist

27 days

8,100.00 10,800.00 5,400.00

3.12.6 Create class module 6

1 course developer 1 computer 1 graphic artist

27 days

8,100.00 10,800.00 5,400.00

3.12.7 Create class module 7

1 course developer 1 computer 1 graphic artist

27 days

8,100.00 10,800.00 5,400.00

3.12.8 Create class module 8

1 course developer 1 computer 1 graphic artist

27 days

8,100.00 10,800.00 5,400.00

Task

Total

417,726.50

The Art of Estimating

161

That concludes the exercise for creating cost estimates for your current project. But let’s take a second and talk about your future as a project manager when it comes to estimating. Some of the best project managers I know keep a history for themselves of tasks and estimates. As they complete a task, they make sure that they have kept the actual duration or work effort for each task. They then inventory these tasks, estimates, and actuals. They are building a library for themselves that they can use on future, similar projects. Indeed, they are building a set of product elements. Remember the discussion on product elements when you learned about parametric modeling? This library will help that project manager refine the estimating process and get better at completing projects on time and on budget. You will also see in Chapter 12,“Keeping the Project on Track,” how these estimates will help you keep the project on track. You can now move on to find out how this stage of planning the project impacts teaming.

Teaming Estimating seems like a solitary process in which one person sits at a desk and analyzes a specific task and determines what it will take to get the work done. Most of the time, estimating is done like this. But let’s talk about a technique that you can use to get good estimates done and build the team. I call this technique estimating brainstorming. First, let’s discuss who should participate in this technique. An estimating brainstorming session should be facilitated by the project manager and attended by either the actual people working on the project or experts in the field who can supply good estimates. Now, if your project is large, you might need multiple sessions split into work groups or functional areas. The key here is to get the actual people who will do the work to attend the session. Why is it so important to have the actual person doing the work do the estimating? It’s a human phenomenon that when people say they will complete a task, they will try their darndest to complete the task in the time they have stated. This phenomenon might be called commitment, peer pressure, loyalty to the group, loyalty to the boss, or integrity. But something drives humans to keep their word. Getting the actual person to do the estimates is a way to guarantee that you will get the best possibility of completing the task on time.

162

Chapter 5

Let’s get back to your estimating brainstorming session. You have the attendees set; now it’s time to create the structure of the meeting. In this meeting, you and the team will review the network diagram one task at a time. You need to analyze several things as part of this session: • Discuss resources—You and the team verify that the resource type that you assigned to the task is the right resource type. You also talk about other resources that might be needed to complete the task. • Review the completion criteria and dependencies—For each task, the team reviews the completion criteria. If changes need to be made to the criteria, they should be changed here. The team should review the predecessor activities and make sure they are correct. • Describe the work effort—The expert for the task or the person who will do the task describes the work for the task. This person verbally describes the activities that will happen to meet the completion criteria. Everyone else in the room listens to the approach and suggests activities that should be considered to complete the task. The activities are recorded and updated as part of the meeting documentation. • Determine the work effort estimate—The expert for the task or the person who will do the task determines the estimate for the work effort. • Determine the duration estimate—The expert for the task or the person who will do the task determines the estimate of the duration of the task. Okay, you now know how you will conduct the meeting and interact with the attendees. One more thing is the output of the meeting. You should document all the analysis that goes on in the meeting and provide copies of the documentation for the entire team. You will update your project plan and the network with the analysis. Why would this technique be used for building a stronger team? Getting everyone in a room together first forces conversations among the team members. Having each person describe the work activities needed to complete a task starts building trust among the team members. As they listen to each other describing the work from their areas of expertise, they start understanding the credentials that each of them brings to the table. They also get a chance to discuss the different approaches and to understand how each of them will approach the work. This approach of getting everything on the table right away will help later when team members start questioning

The Art of Estimating

163

each other’s ability to get the work done. You know the syndrome: Tasks start getting behind schedule, and you start hearing gossip that the owner of the task doesn’t know what he or she is doing. This technique is another good way of moving your team through the forming phase of Bruce Tuckman’s model, discussed in the last chapter. Now let’s discuss the politics surrounding estimating.

Politics One of the political moves that you will encounter concerning estimating is what I call “The boss knows best.” Now, unlike the television sitcom, where father really did know best, chances are good that your boss really does not know best when it comes to estimating your project. Based on what you’ve read in this chapter, you now know the rigor that must be applied to getting estimates right. You might run into this situation in a couple ways. First, your boss might give you a project and tell you that the project has to be done in six months. Second, a manager of the people working on the project might provide the estimates for them. Let’s come up with solutions to these scenarios.

Preset Duration When you are handed a project and the boss already has a duration in mind, you have some work to do to get the boss to understand that the desired date might not be doable. This is one of those situations when your instincts need to come into play on how best to handle the situation. The goal here is education. You want the boss to understand that several factors influence the end date for the project. No matter how much overtime your team puts in, you just might not have enough time to get all the features and functions the project calls for completed in the time frame. You might first start by acknowledging the fact that the boss wants the project in the preset time frame. Try to understand the business drivers that are forcing the project to that completion date. The market window might be right for the product introduction. The budget might expire on a certain date. Regardless of the reason for the preset date, make sure the boss knows that you understand the preset date and why it is important. Next, explore the possibility for compromise or trade-offs. You are just trying to find out if you have any possible negotiating room. Remember the triple constraints from Chapter 2? Explore the possibility of getting more funding if you need it. Find out if the MOP for the project can be negotiated. With

164

Chapter 5

this knowledge, you know whether you have any negotiating room. Don’t try to negotiate yet. You really don’t know at this time whether the project can or can’t be done in the time frame requested. Save the negotiation until you really need it. Finally, try to set the stage for negotiation. You might do this at the first meeting, or you might introduce the topic slowly over the course of your project’s planning. You need to be the judge of the best way to approach your boss. If possible, try to educate your boss on the subject of the triple constraints. That way, if you come to your boss later and need to negotiate, he or she won’t be surprised. The key here is to educate the boss on the right way to do project management. Planning the project the way I am discussing it in this book will get you to a successful completion. Having a preset date might or might not work. You need to plan the project the right way and make sure the boss is educated on that process. I finish this discussion in Chapter 9, where you will find out the end date of the project. You’ll also see what you can do to meet that preset date, and you’ll talk about what you can do politically to make you and your team heroes or to prepare the boss for negotiating and possible slippage.

When the Boss Creates the Estimates I’ve worked in organizations whose team members reported on a dotted line to me and still reported on a straight line to their functional managers. If this terminology is new to you, it means that these people had two bosses. We call this cross-functional or matrix management. At its best, it is very hard to do successfully. At its worst, it can be a nightmare for you, the project manager, as well as for the team members. In some situations, I’ve asked the team members to provide estimates for certain tasks, and their functional boss has actually prepared the estimates for them and provided the estimates to me. Usually, these estimates are close to what the real estimates should be. But the issue with this approach is that there is no ownership from the team members who have to do the work. You might also find that the estimate is absolutely perfect for the team member to be gone a certain amount of time and be back into their regular jobs just in time to complete some work for the functional manager. In reality, the managers are providing their people to you only when it is convenient for them. This is hardly a perfect solution for your project. So what do you do when the boss provides the estimates? Again, this depends on the relationship you have with the manager. If you know the manager well and have a good working relationship, the direct approach is probably best. Explain the ownership issue and propose that the two of you

The Art of Estimating

165

sit down with the team member and derive the estimates together. Try to understand the boss’s need for the employee to be back at a specific time. See what you two can do to find a win-win situation. Can you use another team member for a while in place of this team member? Can you resequence the tasks so that the team member can be utilized later, when it is more convenient for the boss? You get the picture. Now, if you have a strained relationship with the boss or perhaps you don’t know this person well, here are some approaches you can try. Again, the direct approach is always best, but if you have tried that and it didn’t work before, try this: Document exactly what you need the team member to do while working on your project. List things such as the estimates for the project, the exact tasks the team member will be performing, and the time frame for those tasks. Also list on this document exactly what you will be providing for the work this person does. List things such as task assignment, completion criteria, and feedback to the boss on the team member’s performance. When the document is complete, schedule a meeting with the team member’s boss and, if this is a really strained situation, that person’s boss, too. Work through the list of activities with the boss and negotiate until you both can accept what the activities are. Then everyone at the meeting should sign the document, showing their concurrence.

Summary We started this chapter with some definitions of terms used when doing estimates. We covered the different types of estimates and when each type is used in your project management life cycle. We then took those definitions and created estimates for our TTR project, our running example in this book. We created duration, work effort, and resources estimates for each task. We also looked at a group estimating technique in our “Teaming”section, and in the “Politics” section, we explored how to handle the boss who creates estimates for you.

Case Study It’s Thursday night, and Chris is driving home from work. She just completed her second core team meeting for this week. The first meeting this week was the orientation session, which created the WBS. This second one

166

Start

Chapter 5

1.3 Establish marketing goals

1.4 Determine target audience

1.1 Gather previous trade show information

2.6 Determine vendor partnership strategy

2.7 Determine target vendors

1.2 Gather input from other departments

2.1 Design the booth sales approach

2.5 Design the booth

2.3 Design the trade show experience

2.2 Create IT demo requirements

2.8 Review and revise demo requirements

2.10 Determine housing and travel requirements

2.12 Determine catering requirements

1.5 Create draft marketing plan

1.6 Review and revise draft plan with other departments

1.7 Create final marketing plan

2.4 Design the marketing collateral

2.11 Gather marketing material and booth shipping requirements

2.14 Verify product inventory supports the marketing plan

2.9 Design the demo

2.13 Determine trade show on site requirements

Figure 5.2 VNLE network diagram

concentrated on creating the first network diagram for the project. Chris had scheduled this meeting for two hours. It ended up taking more than four hours. She was pretty tired and needed to concentrate on her driving, but she kept reflecting on the dynamics she saw in the meeting. The VNLE core team consists of seven members, all very strong in their areas of expertise. She was surprised by how much arguing and jockeying for position was obvious in the meeting. She thought back to the Tuckman model of team development and realized that she saw evidence of all four stages in this one meeting. She saw forming in the way the she had to set ground rules and how tentative everyone was at first about how to approach the work. She saw storming evidenced by how people argued and tried to force their opinions on each other. She saw glimpses of norming when they came to concurrence on the sequence of each task. And she saw performing when the team finally started talking and working things through. At the end of the session, they had created the network diagram, and everyone agreed that this was the proper way to sequence the work. From this meeting, Chris decided that she would be making progress in team development when the majority of a core team meeting showed norming and performing activities. On Friday morning, Chris came back to the office and inspected the network diagram, shown in Figure 5.2.

The Art of Estimating

3.1.9 Build marketing collateral

167

3.1.3 Create trade show buzz

3.1.8 Establish pre-meetings with vendors

3.1.10 Build the booth

3.1.6 Prototype the booth experience

Detailed planning completed 3.1.11 Build the demo

3.1.12 Test the demo

3.1.2 Ship marketing material and booth Ready for the trade show

3.1.7 Learn and practice demo

3.1.14 Verify the web site is ready 3.1.1 Arrange flights and lodging

3.1.4 Finalize trade show on site requirements

3.1.3 Make catering arrangements

3.1.15 Verify the catalog is ready

3.1.5 Verify product inventory supports the trade show plan

3.2.1 Verify and correct logistics 1 day

3.2.2 Manage the trade show event 4 days

3.2.3 Staff the booth 4 days

3.2.4 Get feedback for vendor experience during event 4 days

Figure 5.2 Continued

3.2.5 Receive > 125 point for trade show 1 day

168

Chapter 5

She thought the network diagram looked pretty good and was pleased that the team had at least come to concurrence on the diagram. She had forgotten about the concept of milestones and had not talked to the team about creating milestones before they had started working on the network diagram. She found it fascinating that those milestones had naturally been created as they laid out the work. You’ll notice those milestones on Figure 5.2, labeled “Detailed planning completed” and “Ready for the trade show.” Chris had given them an assignment to study the diagram before the next meeting, on Tuesday. At that next meeting, they would start doing estimates for resources, duration, and costs. She had also decided that they could document each task’s completion criteria at the same time they worked on the estimates. Chris had decided to do the estimates as a joint effort. This team was still pretty new to each other. She thought they would learn a lot from each other if they did the estimates together. Besides, she still had a lot of work to do to get them to effectively work together. On Friday, Chris scheduled a meeting with June Jackson, the CEO to update her on the progress that the team was making.

Review Questions 1. An order of magnitude estimate is also sometimes called what? 2. A definitive estimate is also sometimes called what? 3. Describe analogous estimating. 4. What is parametric estimating? 5. What is the most accurate estimating method? 6. What are the three points of three-point estimating? 7. What is reserve analysis? 8. What are the three types of resources? 9. What things do you estimate on a project?

6 Quality—How Good Does It Have to Be? The bitterness of poor quality lasts long after the sweetness of making a date is forgotten. —Mike Harding Roberts

Topics Covered in This Chapter Before You Plan Planning Quality In The Cost of Quality Teaming Politics Summary Case Study

Whoa! Hold on there! I bet you’re thinking that you’re into the home stretch now for completing the planning on your project. Well, you’re right—you’re close to finishing up. But I still need to cover a couple items, including the topic of this chapter: quality. The network diagram is completed, and you now have estimates created for every task. You can’t say the network diagram is really done, though, until you make sure that what you are creating really fits the needs of the product’s intended users. This chapter starts with a discussion on quality—specifically, how to plan the quality into your project. The chapter then spends some time on a very important concept: the cost of quality. You’ll use this tool in the planning stages of a project as well as throughout its life cycle.

169

170

Chapter 6

In the “Teaming” section, you’ll going to concentrate on the storming phase of project team development. You’ll see how you can use the process you’ve created to instill quality in your project to also move the team through the stages of team development. In the “Politics” section, you’ll learn how to use the same concepts to enhance your interactions with your executive team. You’ll also go through a couple scenarios that you have probably come across in your corporate life, such as dealing with “the climber.” In the case study, you’ll catch up with Chris and her team. They’ve just finished doing their work effort and duration estimating. Will other issues come up for them?

Before You Plan You should know a couple things before you begin to plan the quality aspects of your project. You need to know definitions regarding quality, some background on the gurus of quality management, and, finally, what the PMBOK® Guide says about quality. You’ll then read about quality standards and policies. Let’s start with the definition of quality. So what is quality? Webster defines it as the “degree of excellence” (along with 12 other definitions). Names such as Deming, Baldrige, Juran, and Crosby come up when we talk about modern quality concepts. These gurus of quality management have created the current world view of quality, and their philosophies regarding quality management are embedded in most of the quality programs that you’ll hear about. In fact, in the PMBOK® Guide, this standard outlines a sound approach that mirrors a lot of what the gurus have advocated. That sound approach has you first doing quality planning. You will perform quality assurance and will control the outcome of the project by doing quality-control activities while you execute the project. The definition of quality planning from the PMBOK® Guide is “the process of identifying which quality standards are relevant to the project and determining how to satisfy them.” I discuss quality assurance in Chapter 11, “The Rhythm of Project Execution,” and quality control in Chapter 12,“Keeping the Project on Track.” These quality philosophies are important because, as the leader of your project, you must set the direction for your team when it comes to quality. Knowing about Deming’s 14 Points to Quality Improvement or Phillip Crosby’s

Quality—How Good Does It Have to Be?

171

process to get to zero defects could help you plan your project. The goal here is to create the right product the first time without a lot of rework or scrapping of materials or time. You need to deliver to the right MOP, on budget and on time. It could be impossible to hit even one of the triple constraints without the proper quality planning. Quality Philosophies Pick up a book or two by Deming, Baldrige, Juran, or Crosby if you don’t have a lot of background in the current quality philosophies.

Quality Standards As with anything in life, it’s best to understand the rules of the road before you begin your trip. The same holds true with planning projects. You’ve already determined the right path to do the work via the network diagram; you now must determine whether the right work is really getting done. Remember that a project is undertaken to accomplish a specific goal, and that goal contains either stated or unstated expectations of the quality it will contain. Part of your job as the project manager is to be sure you understand the expectations and that your project will deliver them. You translate the word expectations to the word quality. This means that if the project does not meet the stakeholders expectations, it is not of the proper quality. You should first learn about quality standards and how they should be applied to your project so that you can determine whether your project will meet the quality requirements. Industry Standards You must understand the standards for the industry in which you are working. Different industries have different quality standards. Spend time with your executive sponsor if you are new to this industry and find out what quality standards might govern your work. For example, your project might involve building a new manufacturing plant that will emit exhaust from the machinery; you then would need to understand the clean air standards for your municipality and country. One common standard that hundreds of organizations use worldwide is ISO 9000. This standard has become an international reference for

172

Chapter 6

quality management requirements for how businesses work with each other. It focuses on two points: • Customer quality requirements • Applicable regulatory requirements This focus helps an organization enhance customer satisfaction and achieve continual improvement of its processes. Variations on this standard that have been created for specific industries; as an example, TL9000 is the quality standard for the telecommunications industry. Organization Standards Next you need to focus in on your organization and determine what standards to apply to your project from that perspective. Be sure to determine whether these apply: • Project management process standards—A process owner or PMO for the organization usually manages these standards. They could cover all the work you are about to do on the project. For example, they might outline how projects are initiated or how project plans are created. You might deliver your project on time and on budget, but the project management process owners will not view you as successful if you don’t complete it with the standard processes. • Product standards—These standards cover how the product of the project is created. Your organization might have internal rules and regulations on how its products are created. For example, in an IT shop, you might have to use a standard library of software routines. Developers must investigate what routines are available. If a new routine is needed, procedures might govern how that routine gets approved and added to the library. Needless to say, these activities will affect the duration estimates that you’ve created. • Quality management standards—Your organization might have adopted these standards from an ISO or ANSI standard and refined them. This could include the quality management system that is in place at your organization, including Six Sigma and Total Quality Management. These quality programs might have specific processes about to gather such things as lessons learned.

Quality—How Good Does It Have to Be?

173

You now have gathered and explored the organizational standards; let’s talk about quality policies

Quality Policy Now check to see if your organization has a quality policy, or a statement that describes the organization’s intentions toward quality. A nice example is the slogan Ford Motor Company has used for years: “Quality is Job 1.” Some organizations post their quality policy on the wall next to the front door or use it in their commercials. A lot of major companies are proud of their products and want everyone to know where they stand on quality. In fact, if you do a Web search on “quality policy,” you’ll find millions of entries. Other organizations might or might not have a quality policy, or you may find that one has been created for just one department. The trick here is to start at the top of the organization and work your way down. Look for the quality policy for the whole company, and then search within your department or division. You get to create one for your project if you get down to where you work in the organization and you still haven’t found the policy. Yes that’s right—you get to write a quality policy for your project. Remember, you are the leader for the project, and your team members should understand that quality is important to the outcome of the project. Let’s take a look again at the training time reduction project. You came up with the following MOP and restrictions for this project: Driver: Reduce customer service representative training time by more than 50 percent. Restriction: Customer complaints do not increase more than 2 percent.

You also considered these other restrictions: Restriction: No increase in customer wait time. Restriction: No delay in customer orders longer than one hour.

Based on that MOP, it looks like the length of the training class is the most important element of the project. Yet from the restrictions, you can also see that customer service cannot be sacrificed just for a faster completion. You can probably craft a meaningful quality policy based on those restrictions:

174

Chapter 6

We strive to provide our customers with the highest-quality services to meet and exceed their expectations while reducing the time required to train effective service representatives.

Do you think that statement gets across the intention of not sacrificing customer service? Hopefully so. You might need to create a policy for your project and have a couple people read it to see if they understand your intention. When you think it’s right, make sure that your executive sponsor agrees before you publish it to the rest of the team. You’ve now gathered the standards and established a quality policy; its time to plan your approach to quality on your project.

Planning Quality In Unusual title for this section? No, not really. Remember that the quality gurus talk about the fact that quality is planned in, not inspected in. You should take that same approach for laying out the quality elements for a project: Plan it in. You must understand that will be concerned with two different aspects of quality when you start this planning: • Are you creating the right product that satisfies the objectives for which the project was undertaken? • Are the processes that you are using to create the product the right ones? Let’s start with the first element: Are you creating the right product that satisfies the objectives for which the project was undertaken? This aspect is actually pretty easy if you followed the steps outlined regarding creating product requirements in Chapter 3,“How Big Is This Project?.” If you did, you have a comprehensive list of functional and nonfunctional requirements that the appropriate people have signed off on. You have a very good chance of creating exactly what the project was intended to produce. If you did not create the requirements before, now is a good time to go back and get them done. You cannot guarantee that you understand the product to be created without these requirements. With them, you have a complete baseline of what needs to be done. This takes you to point two: Are the processes that you are using to create the product the right ones?

Quality—How Good Does It Have to Be?

175

This step takes a little more time and effort than the last step. Start by determining the goals of a sound product-development process. What are these goals? A few come to mind: • The process works the first time. • • • • •

No time is wasted. No rework has to be done. The schedule doesn’t have to be redone. The costs don’t have to be redone. The desired product quality is attained.

It sounds like you want to make sure that everything is right for the product. You had better know that the process is working as early as you can, to minimize rework along with schedule and cost changes. All sorts of statistics out there point to how much it costs to correct a problem in IT shops when developing code. The stats say that it is much cheaper to correct a problem early in the development process than later. Review your network diagram, based on your goals and the statistics. You must understand whether you have a good process that will detect problems early. Take a look at the network diagram for this project, depicted in Figure 6.1. You have set up a couple tasks right away to have the team look at what is currently happening with the training class and customer complaints. It makes sense to get those done first because it you can set a baseline of what is happening now. You can then create a current state document. After that, you can decide what your approach will be and can create an approach document. Next, you can launch right into designing the class. You’ve got to admit there are probably some holes here if you look at this approach from a quality perspective. The first glaring hole is this: Where are the requirements for the class? Won’t you just end up with essentially the same thing if you plan to use the previous class material as a basis for the new class? Wouldn’t it be good to understand the real requirements for the class and build the new class based on those requirements? You started the process in Chapter 3, but your network diagram doesn’t show the process completed or being used in any of your work here.

176

Chapter 6

3.12.1 Create class module 1

3.12.2 Create class module 2

1.1 Interview CSR supervisors 2.3 Create learning objectives

3.12.3 Create class module 3

1.2 Determine current customer complaints 1.4 Create current state document

Start

2.4 Determine whether to use a new technology

2.1 Create approach document

3.5 Design the class

3.6 Create job aids 3.12.4 Create class module 4

1.3 Determine current training time 2.2 Determine whether to rewrite or start over

3.12.5 Create class module 5

1.5 Investigate what is currently trained

3.12.6 Create class module 6

3.12.7 Create class module 7

3.12.8 Create class module 8

3.13 Create pilot textbooks

3.9 Conduct pilot class

3.14 Revise material after the pilot

3.10 Verify learning objectives are met

3.8 Verify the training class is 50% less

3.11 Create textbooks

3.1 Conduct first class

3.4 Train the trainer

3.7 Adjust the class to 50% less

3.2 Time the pilot class

Figure 6.1 Training time reduction network diagram

3.3 Verify customer complaints are < 2%

End

Quality—How Good Does It Have to Be?

177

The second hole is getting signatures. You learned in Chapter 3 that it’s important to get the executive sponsor’s sign-off. Shouldn’t this be shown on the network diagram? You also went to all that trouble in Chapter 3 to create an audience identification list. Shouldn’t you determine whether other people besides the executive sponsor should sign off? A walkthrough of the material and sign-off from other people might really help guarantee the quality of the product you are creating. So you have put in a couple new tasks that should increase the quality of the product being delivered. But you can see that after the documents are created, you we launch right into the design of the class and the creation of class modules. You have no checks in place to make sure that the duration of the class will be 50 percent less than it had been previously until after you conduct the pilot class. You might have to redo the design and all the class modules if you have problems, instead of just having to tweak the material. Looks like you should insert a task to verify the duration based on the design. You should also verify the duration when each of the class modules is completed. That way, you can rework something then and there before you get to the pilot class. The rest of the network diagram looks pretty good for completing the training class correctly. Oh, one more thing: you never do any validation concerning customer complaints until the entire project is just about done. Let’s put in a task to monitor the pilot class for customer complaints before doing any class revisions. That way, you’ll know whether to make any changes to the class material before you create the final version. You’ve reviewed your new work process and are still a little worried about whether what you have planned will work effectively. You can add another task to perform a process analysis in the middle of the project, to make sure that your process is working correctly. Another nice tool to use to understand is a quality audit, to ensure that you will meet the right level of quality. In fact, a quality audit can be used for planning purposes or for quality assurance or for quality control. A quality audit is a structured review that determines whether the project activities are complying with the organizational standards and policies for quality that have been set. An audit should be established for long projects whose success criteria include complying with standards. You’ve decided not to use an audit on your training time reduction project, however: You don’t have to meet any prerequisite standards or policies. Of course, you could still do a quality audit later, just for lessons learned.

178

Chapter 6

You’re now finished examining your network diagram and planning the quality elements to create the right product. With that, you have an updated network diagram that shows the quality tasks inserted into the plan (see Figure 6.2).

1.1 Interview CSR supervisors 2.3 Create learning objectives

1.2 Determine current customer complaints 1.4 Create current state document

Start

2.4 Determine whether to use a new technology

2.1 Create approach document

3.5 Design the class

3.15 Verify the timings

3.16 Process analysis

1.3 Determine current training time 2.2 Determine whether to rewrite or start over

1.5 Investigate what is currently trained

1.6 Create product requirements

1.7 Signoff requirements

Figure 6.2 Training time reduction network diagram with quality elements

You’ll also notice that the new network diagram shows the new tasks with WBS numbers; I added the tasks to the WBS, gave them the appropriate numbers, and, of course, updated the project plan with these changes. That completes your quality planning for the project. Again, Chapters 11 and 12 cover how to keep the quality you’ve planned in on track while you are executing the project. Let’s spend some time on another important element of quality before moving to the “Teaming” section: the cost of quality.

Quality—How Good Does It Have to Be?

3.12.1 Create class module 1

3.12.2 Create class module 2

3.12.3 Create class module 3

3.17 Verify Timings

3.6 Create job aids

3.13 Create pilot textbooks

3.18 Monitor for customer complaints

3.9 Conduct pilot class

3.12.4 Create class module 4

3.10 Verify learning objectives are met

3.12.5 Create class module 5

3.12.6 Create class module 6

3.8 Verify the training class is 50% less

3.12.7 Create class module 7 3.2 Time the pilot class

3.12.8 Create class module 8

3.14 Revise material after the pilot

3.7 Adjust the class to 50% less

Figure 6.2 Continued

3.11 Create textbooks 3.1 Conduct first class

3.4 Train the trainer

3.3 Verify customer complaints are < 2%

End

179

180

Chapter 6

The Cost of Quality The PMBOK® Guide, the ultimate project management reference, defines a tool and technique of the quality-planning process called the cost of quality. This tool is a very effective means of measuring what you planned to spend on quality against what you actually spent on quality at the end of the project, when your product is in the hands of the users. I start this topic with some definitions. The cost of quality is defined as the total costs incurred to ensure the proper quality for the product. The cost of quality consists of two aspects: the cost of conformance and the cost of nonconformance. Basically, that means “What do you pay to create the right product, and what do you pay when you don’t create the right product?” Let’s examine each of these costs a little more closely.

The Cost of Conformance The cost of conformance is all of the costs that you incur to create the right product. You’re probably thinking that the whole project is about creating the right product! Well, you’re partially right. This includes any of the tasks you put in place to prevent problems with the product and to appraise whether you really are creating the right product. Therefore, you need to calculate two types of conformance costs as part of the cost of quality: • Prevention costs—Prevention costs include tasks such as planning activities. The quality-planning exercise you just completed would be part of the cost of quality. Other prevention costs include training or indoctrination activities that you did with the team to guarantee that the members understood the work. Process analysis or process control activities done during the life of the project is calculated as part of the cost of quality. Also include any type of product design validation tasks. • Appraisal costs—Appraisal costs involve keeping errors from the customer. These include quality audits, tests, and evaluations. If your product must be calibrated before it is handed over to the customer, include these costs. Finally, include any type of inspection or field testing. I’ve covered the two types of costs that comprise the cost of conformance. Let’s now look at the costs that comprise the costs of nonconformance.

Quality—How Good Does It Have to Be?

181

The Cost of Nonconformance The costs of nonconformance are any costs that you incur because the product was not created right and things have to be redone. Two different types of cost of nonconformance exist: • Internal—An internal cost of nonconformance is any cost that you might incur while producing the product before it leaves your organization’s hands and goes to the customer. Look for rework to correct a problem and for parts of the product that must be scrapped because of problems. Finally, look for costs that are incurred because someone had to purchase additional materials for your product. • External—An external cost of nonconformance is a cost that is incurred when the product leaves the organization’s hands and problems occur in the customer’s hands. These include repairs and services, complaint handling, liability judgments, and product recalls. Loss of reputation should be considered part of the cost of nonconformance, although it is very hard to calculate. Now that you know the definitions of the cost of quality and its breakdowns of the cost of conformance and the cost of nonconformance, look at the training time reduction project and calculate the cost of quality that you have completed in your quality planning. This is the formula for cost of quality:

+ + + =

Prevention costs Appraisal costs Internal nonconformance External nonconformance Cost of quality

You have prevention costs in the form of the requirements work that you will do and in process analysis. Three tasks together with conducting the pilot class are also preventative tasks: 1) Verify that learning objectives are met, 2) Verify that the training class is 50 percent less, and 3) Time the pilot class. Then you must add in the other two tasks that verify the duration measurements. That covers your prevention costs.

182

Chapter 6

For appraisal costs, the task to monitor customer complaints after the pilot class is definitely an appraisal cost. The last appraisal cost is the last task: Verify that customer complaints are less than 2 percent. When you look over your network diagram for nonconformance tasks, you can find only two. Task 3.7, to adjust the class to last 50 percent less time, is a task that you have planned to rework (if necessary) to guarantee that you meet your MOP. You also plan to redo the textbooks (if necessary) in Task 3.14. Other internal nonconformance tasks might arise while you are executing the project. You have no external nonconformance costs right now. You might see these costs emerge when you turn over the class to the customer service representatives if you have not planned quality into your project. Now go back to the cost estimates that you created for your class, shown in Table 6.1. Table 6.1 Cost Estimates for Training Time Reduction Project Resource Estimate

Work Effort Estimate

1.1 Interview CSR supervisors

1 course developer 1 project manager 5 CSR supervisors

1 day

300 350 1,500

1.2 Determine current customer complaints

1 course developer 1 project manager 5 CSR supervisors

1 day

300 350 1,500

1.3 Determine current training time

1 course developer 1 project manager 5 CSR supervisors 4 trainers

1 day

300 350 1,500 880

1.4 Create current state document

1 course developer 1 project manager

2.5 days 2.5 days

1.5 Investigate what is currently trained

1 course developer 1 project manager 5 CSR supervisors 4 trainers

1 day

300 350 1,500 880

1.6 Create product requirements

1 project manager 5 CSR supervisors

4 days 4 days

1,400 6,000

Task

Cost Estimate ($)

750 875

Quality—How Good Does It Have to Be?

183

Resource Estimate

Work Effort Estimate

Cost Estimate ($)

1.7 Obtain sign-offs

1 project manager 5 CSR supervisors 1 executive sponsor

1 day 1 hour 1 hour

350 187.50 62.50

2.1 Create approach document

1 course developer 1 project manager

4 days

1,200 1,400

2.2 Determine whether to rewrite or start over

1 course developer 1 project manager 1 executive sponsor

1 day

300 350 250

2.3 Create learning objectives

1 course developer

1.5 days

450

2.4 Determine whether to use a new technology

1 course developer 1 project manager 2 technologists 1 executive sponsor 1 customer service rep system

1.5 days

450 525 750 250 600

3.1 Conduct the first class

1 trainer 1 training room 1 regular class 20 textbooks 1 customer service rep system

25 days

5,500 2,500 50,000 2,000 10,000

3.2 Time the pilot class

1 course developer 1 CSR supervisor 1 project manager

25 days

7,500 7,500 8,750

3.3 Verify that customer complaints are < 2%

5 CSR supervisors 1 course developer 1 project manager

3.75 days

281 1,125 1,313

3.4 Train the trainer

1 course developer 15 days 1 customer service rep system 4 trainers

Task

4,500 6,000 13,200 continued

184

Chapter 6

Table 6.1 Continued Resource Estimate

Work Effort Estimate

1 course developer 1 customer service rep system 1 project manager

4 days

3.6 Create job aids

1 course developer 1 graphic artist 1 project manager 2 computers

4.5 days

1,350 900 1,575 3,600

3.7 Adjust the class to 50% less

4 course developers 4 computers

3 days

3,600 4,800

3.8 Verify that the training class is 50% less

4 course developers 2 CSR supervisors 1 project manager

1/4 day

300 150 87.50

3.9 Conduct the pilot class

1 trainer 1 pilot class 1 project manager 2 CSR supervisors

25 days

5,500 2,500 50,000 2,000

3.10 Verify that learning objectives are met

1 trainer 1 pilot class 1 project manager 2 CSR supervisors

1/2 day

110 1,000 175 300

3.11 Create textbooks

1 course developer 1 reproduction facility

4 days

1,200 400

3.12.1 Create class module 1

1 course developer 1 computer 1 graphic artist

28 days

8,400 11,200 5,600

3.12.2 Create class module 2

1 course developer 1 computer 1 graphic artist

27 days

8,100 10,800 5,400

3.12.3 Create class module 3

1 course developer 1 computer 1 graphic artist

27 days

8,100 10,800 5,400

Task 3.5 Design the class

Cost Estimate ($) 1,200 1,600 1,400

Quality—How Good Does It Have to Be?

185

Resource Estimate

Work Effort Estimate

Cost Estimate ($)

3.12.4 Create class module 4

1 course developer 1 computer 1 graphic artist

27 days

8,100 10,800 5,400

3.12.5 Create class module 5

1 course developer 1 computer 1 graphic artist

27 days

8,100 10,800 5,400

3.12.6 Create class module 6

1 course developer 1 computer 1 graphic artist

27 days

8,100 10,800 5,400

3.12.7 Create class module 7

1 course developer 1 computer 1 graphic artist

27 days

8,100 10,800 5,400

3.12.8 Create class module 8

1 course developer 1 computer 1 graphic artist

27 days

8,100 10,800 5,400

3.13 Create pilot textbooks

1 course developer 1 reproduction facility

4 days

1,200 400

3.14 Revise materials after pilot

1 course developer 1 graphic artist 1 computer

4 days 1 day 4 days

1,200 200 1,600

3.15 Verify the timing (after design)

1 project manager 1 course developer

1 day

350 300

3.16 Process analysis

1 project manager 5 course developers

1 day

350 1,500

3.17 Verify the timing (after module creation)

1 project manager 1 course developer

1 day

350 300

3.18 Monitor for customer complaints (after pilot)

5 CSR supervisors 1 course developer 1 project manager

3.75 days

Task

281 1,125 1,313

186

Chapter 6

Then take just the tasks associated with the cost of quality, shown in Table 6.2, and you can calculate the cost of quality at the end of the quality-planning process. Your total cost of quality at this point in time is $53,860.50. Table 6.2 Tasks Associated with the Cost of Quality Resource Estimate

Work Effort Estimate

1.6 Create product requirements

1 project manager 5 CSR supervisors

4 days 4 days

1,400 6,000

1.7 Obtain sign-offs

1 project manager 5 CSR supervisors 1 executive sponsor

1 day 1 hour 1 hour

350 187.50 62.50

3.10 Verify that learning objectives are met

1 trainer 1 pilot class 1 project manager 2 CSR supervisors

1/2 day

110 1,000 175 300

3.8 Verify that the training class is 50% less

4 course developers 2 CSR supervisors 1 project manager

1/4 day

300 150 87.50

3.2 Time the pilot class

1 course developer 1 CSR supervisor 1 project manager

25 days

7,500 7,500 8,750

3.16 Process analysis

1 project manager 5 course developers

1 day

350 1,500

3.15 Verify the timing (after design)

1 project manager 1 course developer

1 day

350 300

3.17 Verify the timing (after module creation)

1 project manager 1 course developer

1 day

350 300

Task

Cost Estimate ($)

Conformance Prevention tasks

Quality—How Good Does It Have to Be?

Resource Estimate

Work Effort Estimate

3.18 Monitor for customer complaints (after pilot)

5 CSR supervisors 1 course developer 1 project manager

3.75 days

281 1,125 1,313

3.3 Verify that customer complaints are < 2%

5 CSR supervisors 1 course developer 1 project manager

3.75 days

281 1,125 1,313

3.7 Adjust the class to 50% less

4 course developers 4 computers

3 days

3,600 4,800

3.14 Revise materials after pilot

1 course developer 1 graphic artist 1 computer

4 days 1 day 4 days

1,200 200 1,600

Task

187

Cost Estimate ($)

Appraisal tasks

Nonconformance Internal

External

Total Cost of Quality

$53,860.50

Did you notice in the last paragraph the phrase at this point in time? That phrase emphasizes that you can use this technique of cost of quality throughout the project. You first establish the cost of quality after you complete the quality-planning process. You then use it for a quality baseline going forward through the execution of the project. I talk more about that baselining concept in Chapter 11. You can use the quality baseline to compare what you planned to spend on quality to what you actually spend on quality. Some of the best project managers I know stop in the middle of the project and determine what they are spending on quality. They take appropriate action depending on whether they are over or under what they projected. They then determine at the end of the project what they really spent.

188

Chapter 6

I’ve even seen one project manager, a year after the project’s completion, do another calculation for the cost of quality. After a year, the project manager was able to see the real impacts on the external cost of nonconformance. This was mainly done as a lessons learned exercise to help that person be a better project manager. You have not completed your quality planning and analysis. You now update your project plan with the quality policy and task updates at this point. You also document the projected cost of quality at the end of the planning stage. Remember, your project plan is a living document and always reflects what you are planning on your project. Let’s now move into the “Teaming” section and apply your quality principles to how the team works together.

Teaming In the last section, you took the time to plan for quality to guarantee that you would meet the objectives the project was established to provide. Basically, you instilled quality into your entire process. You want to do the same thing with your team: instill quality into the actions and interactions of the team members. Go back to the Tuckman model and his second stage of project team development, storming. You’re probably thinking,“Quality and storming—how do those work together?” Think through the steps that you established with quality. You established a quality policy and then reviewed every aspect of your project work via the network diagram. You then added tasks to the network diagram to guarantee the following: • • • • •

The process works the first time. No time is wasted. No rework has to be done. The schedule won’t have to be redone. The costs won’t have to be redone.

The same concepts apply to how the team works together. You want to be sure of the following: • Their interactions come to successful conclusions the first time. • No time is wasted because of the team’s interactions.

Quality—How Good Does It Have to Be?

189

• No rework or rediscussions have to be done because of the team’s interactions. • The schedule won’t slip because of the team’s interactions. • The costs won’t increase because of the team’s interactions. You basically go through the same process (set policy, do analysis, take action) when it comes to your team and how the members work together. Let’s examine the process and how it relates to building a team. The first step in your quality process was setting policy. Hopefully you have already set the policy of how the team interacts with each other via the team norms that you established back in Chapter 4,“Laying Out the Work.”This list of rules of engagement should cover exactly how the team wants to be treated and how their interactions should be conducted. Go back and take a look at what you have created. Do you have at least a few things on your team norms that set the policy for how the team works? If not, you can always pull the team together again and add more information to the team norms. You’ll want statements such as these: • We will respect each other’s opinions. • If a person has a problem with me, that person will come to me first before talking about the problem with someone else. The next step in your quality-planning process was to do analysis. You’ll do the same step here with your team. You’ll want to sit back for a little while and notice how the team interactions are working. Do you see all stages of team development happening (forming, storming, norming, and performing)? Does the team seem like it is stuck in storming? Are decisions that were made in previous meetings being constantly revisited? Is gossiping going on? Are people making snide comments about each other behind their backs? If any of these conditions are present, it’s time for you to take action. Remember, storming is a necessary step for the team to go through as it moves through the stages of team development. It’s your job to keep pushing the team members through that stage to performing; don’t let them get stuck in storming. The last step of your quality-planning process was to take action. That is exactly what you will do with your team. You can use a couple strategies to help move your team past storming.

190

Chapter 6

Decision Log The first strategy is a way to avoid making the team constantly revisit decisions it has already made. You’ll use a tool called a decision log. This is nothing more than a list of decisions that have been made on a project. You can establish a simple table that captures what has been decided. Table 6.3 shows a sample decision log and the type of information that you need to capture. Table 6.3 Decision Log #

Decision Description

Approved By

Date

Members Present When Decision Made

Try to be as descriptive as possible in capturing the information for the log. You don’t want people to read the log later and not understand the issue or the decision. It’s also a good idea to record who was present when the team made the decision. You’ll know then who needs to be briefed about what has transpired. Or perhaps you should add another team norm, such as “If you miss a team meeting, it’s your responsibility to get caught up by reviewing the minutes and the decision log.” The most important aspect of the decision log is how you use it. First you need to make sure that all decisions are captured. More important, though, you use the decision log to stop the discussions. When a team member wants to go back and revisit a decision, you need to pull out the log and make sure the entire team understands that the decision has been made. No need to go back and revisit that decision again. Of course, rediscussing a decision is warranted under some circumstances. You might get additional information and discover that the original decision was wrong. You need to determine the right action each time this type of conversation comes up. The goal here is to keep the team moving forward to create the right product and achieve that MOP.

Quality—How Good Does It Have to Be?

191

Forcing Conflict The second strategy to move the team past the storming stage of team development is forcing conflict. I read once that project managers need to embrace conflict. At that time, I thought that was a ridiculous concept. Who would want conflict on the team? Don’t you want a pleasant work environment? But I’ve come to realize that conflict is a way to actually get decisions made, get problems solved, and get the team to move on. Here’s how this works: You have a team norm of “If a person has a problem with me, that person will come to me first before talking about the problem with someone else.”You hear team member Maria talking about team member Ralph, so you go to Maria and ask her if she has talked to Ralph about the issue. Basically, you are holding her accountable for her agreement to follow the team norms. If her behavior doesn’t stop with that discussion, you might have to pull Maria aside and talk to her about her behavior. Or you might force Maria and Ralph to sit and talk about their problems. These discussions could be wrought with conflict, but it’s okay because forcing the conflict forces the storming to happen. If you force team members through the conflict, you’ll get the team to a place of cooperation and productive work. You’ll find yourself doing this quite often when you first start to use this strategy. The frequency will eventually taper off when the team understands that you mean business. Be consistent when taking action to instill quality into your team. You have to be consistent in disciplining children; you must do the same with your team. You must force conflict whenever you see problems arise. You must make sure decisions are logged and that the revisiting of prior decisions stops. If you take these actions every now and then, the team will believe you are serious about enforcing the team norms. Now let’s discuss the politics surrounding the interactions with your executive team.

Politics I know this is starting to sound like a broken record, but you’re probably wondering why you can’t apply the same quality-planning principles to your interactions with your executive team. You could go through the same

192

Chapter 6

process (set policy, do analysis, take action). Of course, a few differences arise in how you deal with the executives and some of the politics that come into play when dealing with those in the higher levels of the organization. Let’s examine the process and how it relates to these interactions. The first step in the quality process was to set policy. In dealing with your team, you use established team norms as your policy. You need to use a set of team norms with your executives as well. Now, you can’t march into your executive sponsor’s office and demand that the two of you set up team norms. But you can use an informal set when dealing with executives. You established an informal set of team norms for executives back in Chapter 4. Here’s a quick reminder of them: • • • • • •

Effectively utilize executive time Be a bottom-liner Delegate up Bring problems and solutions Use gentle reminders Don’t introduce surprises

Establish these norms now if you haven’t yet created them for your project. Remember, these are the rules of engagement you will use in your interactions with the executives. The executives might not even know that you have this list of norms, but they will appreciate your dealings with them if you follow them. The next step in your process is to do analysis. You’ll again want to step back and determine what is working and not working when you deal with the executives. The goal here is the same as mentioned earlier: • Interactions come to successful conclusions the first time. • No time is wasted because of the interactions. • No rework or rediscussions have to be done because of the interactions. • The schedule won’t slip because of the interactions. • The costs won’t increase because of the interactions.

Quality—How Good Does It Have to Be?

193

You have an additional goal for these interactions: • The executive will have confidence in the project manager’s ability to deliver. Of course, with confidence come rewards, recognition, and possibly promotions. You get the picture. The last step in the process is, of course, to take action. Let’s step through a couple political scenarios and see how you can use these executive rules of engagement to improve the quality of interactions between you and your executives.

Scenario: The Climber You have an aggressive person on your team who has become a confidant of your executive sponsor. You know they schedule lunch every couple of weeks together. Your team member is doing an effective job for you. He also doesn’t miss a beat when it comes to being able to promote himself and his achievements. You wonder at times whether this person is promoting himself to the detriment of you and the project. The last time you met with your sponsor, she brought up an issue that had been resolved in one day. She had heard of the issue but not the resolution. This issue was something that only you and your team would have known about; it would ordinarily not warrant the executive’s attention. In this type of situation, you know that the team member is going to provide information to the sponsor regardless of whether it is bad or good information. Take some offensive actions instead of trying to react to issues as they arise. Go back to the “no surprises” rule. You might want to spend some time with the sponsor to find out the level of detail she expects when it comes to information. You might have assumed that the sponsor wants to hear about only issues that you think warrant her attention; in reality, your sponsor might want to hear about a lot more. She might be very detail oriented. Perhaps it would be best to give the sponsor access to an electronic issues log, so she can browse to her heart’s content. Don’t hold back information from your team just because you think the climber might take issues to the sponsor. You are using honesty, ethics, and results to succeed; the climber could be choosing a different path. Cover the issues, and be confident of your skills and the results you bring. There is room for your team member to succeed along with you.

194

Chapter 6

Scenario: The Digger I once worked for a woman executive who was constantly digging for information. She would meet with my team members. She would stop people in the hall. She would take people out to coffee just to ask how the project was going. I always felt like she was checking up on me. Frankly, she was. One of the executive team norms that you have established is to make effective use of executive time. It is definitely not effective for an executive to constantly search out information. You have to ask yourself,“Why is the executive searching for more information?” Perhaps you are not providing enough information; you had better start analyzing what you are providing and talk to the executive about what else she needs. The executive might not feel confident that you will deliver on what needs to be done. If that is the case, you should spend some quality one-on-one time with the executive so she knows what you are capable of delivering. You want to make sure she knows that you have everything covered. The executive also might just like getting the “scoop”on what’s happening in her organization. You might not be able to stop this behavior. However, make sure you’re disseminating the right information about your project to all participants. That way, the executive will get a consistent story about the progress of your project. I spend more time talking about messaging in the next chapter.

Summary We started this chapter with a discussion on quality and, specifically, how to plan quality into your project. We then explored the concept of the cost of quality. We covered the different aspects of the cost of quality, including the cost of conformance and the cost of nonconformance. In the “Teaming” section, we concentrated on the storming phase of project team development. You saw how to also use the process you created to instill quality in your project to move the team through the stages of team development. In the “Politics” section, you learned how to use the same concepts to enhance your interactions with your executive team. We ran through a couple scenarios that you have probably come across in your corporate life, such as dealing with “the climber.”

Quality—How Good Does It Have to Be?

195

Now let’s see what Chris Williams has been doing on her project. She’s about to have her meeting with June on the current status, and she’s in for a surprise.

Case Study Chris had a pretty intense week last week. She met with the core team members last Tuesday, and they created the estimates for the project. They started by creating a list of the resources they would need on the project. They also determined how many of each of those resources are available in the organization. This first list is shown in Table 6.4. Table 6.4 Resources for VNLE Resource Needed

How Many Available?

Project manager

1

Executive sponsor

1

Core team

6

VP Sales

1

VP Marketing

1

VP Business Development

1

COO

1

CIO

1

Business development person

1

Marketing person

2

Salesperson

4

IT person

1

Logistics person

1

Marketing materials vendor

1

Booth construction subcontractor

1

VN Web project manager

1

Catalog department person

1

196

Chapter 6

The team then did some analysis and determined what resources should work on what tasks. They created both duration and work effort estimates for each resource for every task, as shown in Table 6.5. Chris had scheduled this exercise for two hours, but it ended up taking about six hours. Chris realized that it was mainly her fault for this wasted time. She had not defined the terms work effort and duration estimate to the team. About halfway through the exercise, she realized that her team needed some clarification of the terms. After the clarification, they started the whole exercise over again. What a waste! Table 6.5 Resource Estimates Resource Estimate

Work Effort Estimate

Duration Estimate

1 business development person 1 project manager 6 core team members

16 hours

5 days

4 hours 4 hours each

1.2 Gather input from other departments

6 core team members 1 project manager 1 VP Sales 1 VP Marketing 1 VP Business Development 1 COO 1 CIO

4 hours each 4 hours 2 hours 2 hours 2 hours 2 hours 2 hours

3 days

1.3 Establish marketing goals

1 core team member 1 VP Marketing

4 hours 2 hours

1 day

1.4 Determine target audience

1 core team member 1 VP Marketing

4 hours 2 hours

1 day

1.5 Create draft marketing plan

1 core team member

8 hours

3 days

1.6 Review and revise draft plan with other departments

6 core team members 1 project manager 1 VP Sales 1 VP Marketing 1 VP Business Development 1 COO 1 CIO

4 hours each 4 hours 1 hour 1 hour 1 hour 1 hour 1 hour

2 days

Task 1.1 Gather previous trade showinformation

197

Quality—How Good Does It Have to Be?

Task

Resource Estimate

Work Effort Duration Estimate Estimate

1.7 Create final marketing 1 core team member plan 1 marketing person 1 VP Marketing 1 project manager

2 hours 2 hours 1 hour 1 hour

1 day

2.1 Design the booth sales 1 core team member approach 1 salesperson 1 VP Sales

4 hours 8 hours 1 hour

2 days

2.2 Create IT demo requirements

6 core team members 1 project manager

4 hours each 4 hours

1 day

2.3 Design the trade show 6 core team members experience 1 marketing person 1 salesperson 1 VP Sales 1 VP Marketing

8 hours each 8 hours 8 hours 1 hour 1 hour

5 days

2.4 Design the marketing collateral

1 core team member 1 marketing person 1 VP marketing

8 hours 8 hours 1 hour

3 days

2.5 Design the booth

1 core team member 1 marketing person 1 VP Marketing

8 hours 8 hours 1 hour

3 days

2.6 Determine vendor partnership strategy

1 core team member 1 business development person 1 VP Business Development

4 hours 4 hours 1 hour

2 days

2.7 Determine target vendors

1 core team member 1 business development person 1 VP Business Development

16 hours 16 hours 2 hours

5 days

2.8 Review and revise demo requirements

6 core team members 1 IT person 1 project manager

2 hours each 2 hours 1 hour

1 day

2.9 Design the demo

6 core team members 1 IT person 1 project manager

4 hours each 4 hours 4 hours

2 days

continued

198

Chapter 6

Table 6.5 Continued Task

Resource Estimate

Work Effort Estimate

Duration Estimate

2.10 Determine housing and travel requirements

6 core team members 1 project manager

2 hours each 2 hours

1 day

2.11 Gather marketing materials and booth shipping requirements

6 core team members 1 project manager

2 hours each 2 hours

1 day

2.12 Determine catering requirements

6 core team members 1 project manager

2 hours each 2 hours

1 day

2.13 Determine trade show on-site requirements

1 core team member 1 logistics person

8 hours 8 hours

3 days

2.14 Verify that product inventory supports the marketing plan

1 project manager 1 Catalog department person

1 hour 1 hour

1/2 day

3.1.1 Arrange flights and lodging

1 logistics person

8 hours

5 days

3.1.2 Ship marketing material and booth

1 logistics person

2 hours

1 day

3.1.3 Make catering arrangements

1 logistics person

2 hours

1 day

3.1.4 Finalize trade show on-site requirements

6 core team members 1 project manager

2 hours each 2 hours

1 day

3.1.5 Verify that product inventory supports the trade show plan

1 Catalog department person 1 project manager

1 hour

1/2 day

1 hour

3.1.6 Prototype the booth experience

1 core team member 1 marketing person 1 VP Marketing

4 hours 4 hours 1 hour

2 days

3.1.7 Learn and practice the demo

4 salespeople

8 hours each

5 days

Quality—How Good Does It Have to Be?

Task

Resource Estimate

Work Effort Estimate

Duration Estimate

3.1.8 Establish premeetings with vendors

1 business development person

4 hours

3 days

3.1.9 Build marketing collateral

1 marketing person Materials vendor

8 hours FF price $2500

10 days

3.1.10 Build the booth

1 logistics person Booth construction subcontractor

8 hours FF price $50000

10 days

3.1.11 Build the demo

1 IT person 1 core team member

16 hours 8 hours

5 days

3.1.12 Test the demo

1 IT person 1 core team member

16 hours 8 hours

5 days

3.1.13 Create trade show buzz

2 marketing people

40 hours

30 days

3.1.14 Verify that the Web site is ready

1 project manager 1 VN Web project manager

1 hour

1 day

1 hour

3.1.15 Verify that the catalog is ready

1 core team member 1 project manager

1 hour 1 hour

1 day

3.2.1 Verify and correct logistics

1 core team member 1 logistics person

4 hours 4 hours

1 day

3.2.2 Manage the trade show event

1 project manager 1 core team member

40 hours 40 hours

4 days

3.2.3 Staff the booth

4 salespersons

32 hours

4 days

3.2.4 Get feedback for vendor 1 business development experience during event person

8 hours

4 days

3.2.5 Receive > 125 points for 1 project manager trade show

1 hour

1 day

199

200

Chapter 6

Chris had gotten resource rates from the human resource department prior to the meeting on Tuesday. The team was relieved to find that the rates provided were actually an average rate based on salary and benefits. They were afraid that their actual salaries would be provided. Those rates are shown in Table 6.6. Table 6.6 Resource Rates Resource

Hourly Rate

Project manager

100

Executive sponsor

300

Core team

50 each

VP Sales

200

VP Marketing

200

VP Business Development

200

COO

250

CIO

250

Business development person

50

Marketing person

50

Salesperson

40

IT person

40

Logistics person

25

Marketing materials vendor

FF price

Booth construction subcontractor

FF price

VN Web project manager

100

Catalog department person

25

The team decided to end the meeting on Tuesday with its duration and work effort estimates exercise. All the members cleared their schedule to meet again on Wednesday to finish doing the cost estimates (shown in Table 6.7).

201

Quality—How Good Does It Have to Be?

Table 6.7 Cost Estimates Task 1.1 Gather previous trade show information

1.2 Gather input from other departments

Resource Estimate

Work Effort Estimate

Cost Estimate ($)

1 business development person 1 project manager 6 core team members

16 hours

$800

4 hours 4 hours each

$400 $1,200

6 core team members 1 project manager 1 VP Sales 1 VP Marketing 1 VP Business Development 1 COO 1 CIO

4 hours each 4 hours 2 hours 2 hours 2 hours

$1,200 $400 $400 $400 $400

2 hours 2 hours

$400 $400

1.3 Establish marketing goals

1 core team member 1 VP Marketing

4 hours 2 hours

$200 $400

1.4 Determine target audience

1 core team member 1 VP Marketing

4 hours 2 hours

$200 $400

1.5 Create draft marketing plan 1 core team member

8 hours

$400

1.6 Review and revise draft plan with other departments

6 core team members 1 project manager 1 VP Sales 1 VP Marketing 1 VP Business Development 1 COO 1 CIO

4 hours each 4 hours 1 hour 1 hour 1 hour 1 hour 1 hour

$1,200 $400 $200 $200 $200 $200 $200

1.7 Create final marketing plan

1 core team member 1 marketing person 1 VP Marketing 1 project manager

2 hours 2 hours 1 hour 1 hour

$100 $100 $200 $100

2.1 Design the booth sales approach

1 core team member 1 salesperson 1 VP Sales

4 hours 8 hours 1 hour

$200 $320 $200 continued

202

Chapter 6

Table 6.7 Continued Task

Resource Estimate

Work Effort Estimate

Cost Estimate ($)

2.2 Create IT demo requirements

6 core team members 1 project manager

4 hours each 4 hours

$1,200 $400

2.3 Design the trade show experience

6 core team members 1 marketing person 1 salesperson 1 VP Sales 1 VP Marketing

8 hours each 8 hours 8 hours 1 hour 1 hour

$2,400 $400 $320 $200 $200

2.4 Design the marketing collateral

1 core team member 1 marketing person 1 VP marketing

8 hours 8 hours 1 hour

$400 $400 $200

2.5 Design the booth

1 core team member 1 marketing person 1 VP marketing

8 hours 8 hours 1 hour

$400 $400 $200

2.6 Determine vendor partnership strategy

1 core team member 1 business development person 1 VP business development

4 hours 4 hours

$200 $200

1 hour

$200

1 core team member 1 business development person 1 VP business development

16 hours 16 hours

$800 $800

2 hours

$400

2.8 Review and revise demo requirements

6 core team members 1 IT person 1 project manager

2 hours each 2 hours 1 hour

$600 $80 $100

2.9 Design the demo

6 core team members 1 IT person 1 project manager

4 hours each 4 hours 4 hours

$1,200 $160 $400

2.10 Determine housing and travel requirements

6 core team members 1 project manager

2 hours each 2 hours

$600 $200

2.11 Gather marketing materials and booth shipping requirements

6 core team members 1 project manager

2 hours each 2 hours

$600 $200

2.7 Determine target vendors

Quality—How Good Does It Have to Be?

Task

Resource Estimate

Work Effort Estimate

2.12 Determine catering requirements

6 core team members 1 project manager

2 hours each 2 hours

$600 $200

2.13 Determine trade show on-site requirements

1 core team member 1 logistics person

8 hours 8 hours

$400 $200

2.14 Verify that product inventory supports the marketing plan

1 project manager 1 Catalog department person

1 hour 1 hour

$100 $25

3.1.1 Arrange flights and lodging

1 logistics person

8 hours

$200

3.1.2 Ship marketing material and booth

1 logistics person

2 hours

$50

3.1.3 Make catering arrangements

1 logistics person

2 hours

$50

3.1.4 Finalize trade show on-site requirements

6 core team members 1 project manager

2 hours each 2 hours

3.1.5 Verify that product inventory supports the trade show plan

1 Catalog department person 1 project manager

1 hour

$25

1 hour

$100

3.1.6 Prototype the booth experience

1 core team member 1 marketing person 1 VP marketing

4 hours 4 hours 1 hour

$200 $200 $200

3.1.7 Learn and practice the demo

4 salespeople

8 hours each

3.1.8 Establish premeetings with vendors

1 business development person

4 hours

3.1.9 Build marketing collateral

1 marketing person Materials vendor

8 hours FF price $2500

203

Cost Estimate ($)

$600 $200

$1,280

$200

$400 $2,500 continued

204

Chapter 6

Table 6.7 Continued Resource Estimate

Work Effort Estimate

Cost Estimate ($)

3.1.10 Build the booth

1 logistics person Booth construction subcontractor

8 hours FF price $50000

$200 $50,000

3.1.11 Build the demo

1 IT person 1 core team member

16 hours 8 hours

$640 $400

3.1.12 Test the demo

1 IT person 1 core team member

16 hours 8 hours

$640 $400

3.1.13 Create trade show buzz

2 marketing people

40 hours

$4,000

3.1.14 Verify that the Web site is ready

1 project manager 1 VN Web project manager

1 hour 1 hour

$100 $100

3.1.15 Verify that the catalog is ready

1 core team member 1 project manager

1 hour 1 hour

$50 $100

3.2.1 Verify and correct logistics

1 core team member 1 logistics person

4 hours 4 hours

$200 $100

3.2.2 Manage the trade show event

1 project manager 1 core team member

40 hours 40 hours

$4,000 $2,000

3.2.3 Staff the booth

4 salespersons

32 hours

$5,120

3.2.4 Get feedback for vendor experience during event

1 business development person

8 hours

$400

3.2.5 Receive > 125 points for trade show

1 project manager

1 hour

$100

Task

Total

$55,060

Chris and the team finished the cost estimates, and Chris started to prepare for her update meeting with June. She wanted to make sure that she had the current status ready, as well as a list of any issues that needed June’s attention.

Quality—How Good Does It Have to Be?

205

On Friday morning, Chris spent an hour with June providing the information that she thought June would want to know. At the end of the meeting, June asked Chris what happened on Tuesday and why that meeting had taken so long. Chris sat back for a second, floored by the fact that June would even know anything about the meeting and the fact that it had taken so long. Chris composed herself and told June that she had made a mistake not defining the terms for the core team before beginning the exercise. She also said that she had corrected that behavior by establishing a meeting agenda and defining the terms on the agenda. Chris explained to June that she would not have this problem again. June said it was good that Chris had learned from her mistake. Such a small company didn’t have time to waste on mistakes like this. After the meeting, Chris spent a lot of time thinking about what had happened. She realized that she had made assumptions about what June wanted in the way of information. Needless to say, in the future, it would be best to make sure that June heard about such issues directly from Chris. Chris also realized that she needed to validate the list of executive team norms that she had put together based on her dealings with June. Chris had made too many assumptions about how to deal with June. Chris also realized that she would need to make sure that she acted fast whenever issues arose. It seemed that that the walls had ears. She would need to make sure that any issues that people could interpret as mismanagement or problems would need to be covered immediately, unless she asked the core team not to discuss meetings with others in the organization. Chris would need to step up her PR campaign for the project. She did not want to get into the game of holding back information from the core team. Chris realized that all these issues could be solved and got started on the new work week. This week, her team would get the project plan updated, discuss planning for quality, and get started on the project communication plan. She realized that these issues cropping up right now would really help her in doing the communication planning that she wanted to accomplish this week.

206

Chapter 6

Review Questions 1. Who are some of the gurus of modern-day quality management? 2. When planning quality into your project, you must understand the

3. 4. 5. 6. 7. 8. 9.

applicable quality standards. What are two areas you should check for quality standards? If your organization does not have a quality policy, what should a project manager do? When you are performing quality planning, you are concerned with two different aspects of quality. What are they? What is the cost of quality? What are the two types of cost of quality conformance costs? What are the two types of cost of quality nonconformance costs? What is the second stage of team development according to the Tuckman model? What tool do you use to avoid making the team constantly revisit decisions?

7 Communication—What Do You Think About My Project? Language is not only an instrument of communication or even of knowledge, but also an instrument of power. One seeks not only to be understood but also to be believed, obeyed, respected, distinguished. —Pierre Bourdieu

Topics Covered in This Chapter Communication 101 Teaming Politics Summary Case Study

It is time to move into one of the most important planning elements to complete for your project: planning your communication. I introduce a communication template that spells out the “who, what, when, where, and why” of communication. Then I explain the different elements of the template while you update it using the example project. After you have stepped through the entire template, you will see how you can effectively apply communication to your project team. I also cover some special tactics you can use when your executive sponsor has lost interest in the project. In the case study, you’ll see how Chris keeps working on moving the core team past storming while trying to get the quality and communication planning done.

207

208

Chapter 7

Communication 101 As a trainer of project management material, I have used an exercise that demonstrates the role of the project manager in communication. The exercise goes like this: 1. Break the class into groups of six. 2. The first five people in each group pick a letter of the alphabet. One

person is A. One person is B, etc. Person number 6 does not get a letter. 3. Have the students sit in the shape of an X, where A is the top-left corner, B is the top-right corner, C is the axis, D is the bottom-left corner, and E is the bottom-right corner. Person number 6 stands and works with the rest of the team. 4. When everyone is situated, you explain the rules of the game: • Everyone on the team must accomplish a task together. Person A has been given the task and knows what needs to be done. • The entire team has an antiquated e-mail system to use. E-mails are written on paper and then sent to the delivery mechanism, which is person number 6. • An e-mail can be sent to any person on the team, but all e-mails must first go to person 6. If the format of the e-mail is correct, person 6 gives the e-mail to person C. If the e-mail format is not correct, person number 6 destroys the e-mail. • Person C can send or forward e-mail to persons A, B, D, or E. Persons A, B, D, and E cannot correspond directly to each other, they can only correspond with Person C. • E-mails must have the following elements to get through the system: TO: FROM: DATE: RE: MESSAGE: The team has three work periods of ten minutes each. At the end of each work period, the instructor asks the team for status on completing the task. Sounds pretty complex? It is! It is also loads of fun to see the students passing emails as fast as they can write them. Most of the e-mails in the first two

Communication—What Do You Think About My Project?

209

rounds never even make it past the e-mail system to get distributed. Person C is usually inundated with e-mails and cannot even get a single e-mail of his or her own out. Imagine papers flying everywhere, and chaos and frustration for the team members; they can’t get any information, yet they are expected to accomplish a task. At the end of the exercise, you finally tell them who is playing what role. Person A is, of course, the executive sponsor, who knows what he wants done and communicates that task to person C. Person C is the project manager, the hub of everything that happens on the team and the communication axis. All communication really depends on the project manager. Without the project manager disseminating information, the team is lost and the right work doesn’t get done. By the way, I’ve had only about 1 team in 35 classes actually complete the assignment. This exercise really drives home the point that project manager communication is key to the success of a project. You provided a schedule of tasks for the work to be done, to guarantee a successful and on-time completion. You also want to build a plan of your communication activities, to guarantee successful communication on your project. You can’t plan all the communication activities on your project; you still need to do some extemporaneous communication from time to time. But for the most part, you can plan your activities in advance and execute them successfully. So why plan your communication activities in advance? I know, that’s a rhetorical question. But sometimes you need to be convinced to spend another couple hours at work when you should have gone home a couple hours ago. So many times project managers do their communication on the fly, with disastrous effects and too many missed opportunities. When you plan effective communication in advance, you accomplish the following: • Keep your stakeholders apprised of information that they need to know • Help people with the changes they might have to make because of this new product • Provide status to everyone with a need to know • Manage the perceptions about the project • Keep stakeholders apprised on project risks and responses • Disseminate the right information, in the correct format, to the right people at the right time

210

Chapter 7

These objectives spell out why you communicate. You also need to plan exactly what you will communicate to which people, at what point in time, and using what method. This is essentially the who, what, where, when, why, and how of communication. The communication template in Table 7.1 can help you organize your thoughts when creating this plan. Table 7.1 Communication Template Who

When

Why

What

How

Fill in this template as you think through the needs of the project and your needs to manage perceptions. Use this template as you step though the process of analysis for each column. With that, you can start on whom you communicate to.

Who Are the Recipients? In Chapter 3,“How Big Is This Project?,” you spent some significant time creating an audience identification list while you considered the requirements for the product. You can brush off that list and reuse it here as a basis for the total project communication. You’ll find it depicted in Table 7.2.

Communication—What Do You Think About My Project?

211

Table 7.2 Audience Identification List Role

Name

Project customer Project sponsor Approvers

Project manager Customers Users

Subject matter experts

Legal Consultants Human Resources Marketing Managers Others

Champions Influencers Challengers

Be sure to go back to Chapter 3 and review the definitions for each of these titles.

212

Chapter 7

Chances are good that this list is still valid and that you’ll need to communicate with the people who were involved in creating the product requirements throughout the life of the project. Now, however, you need to determine whether you need to include other people. You also should remove the terms champions, influencers, and challengers from the list; you’ll use those terms later in your communication analysis process. Also drop the term others from your list; you need to be specific here about the roles that need project communication. You should be specific yet generic at this point in time and deal with only roles for now. Later in the process, you’ll name names. One of the major groups that sometimes gets forgotten in project communication is the project team itself. The team members are some of the major stakeholders of the project, and you definitely need to keep them apprised of project information. You now have a list of generic roles that require project communication (see Table 7.3). Table 7.3 Communication Roles Checklist Who Project customer Project sponsor Approvers Customers Users Subject matter experts Legal Consultants Human Resources Marketing Managers Project team

When

Why

What

How

Communication—What Do You Think About My Project?

213

You can use this list going forward as a checklist of the types of roles you should be thinking about for project communication. Now consider this in light of the training time reduction project. Review the list of resources and make sure that you have covered all the roles from that project. This is the list of resources: • Project manager • Course developers • Pilot class • • • • • • • • •

Trainers Graphic artist Regular class Technologists CSR supervisors Training room Textbooks Reproduction facilities Customer service rep computer systems

Make sure each resource type is covered on the communication template. First is the project manager. You can disregard that resource, along with the training room, the textbooks, the reproduction facilities, and the customer service rep computer systems. Next are the course developers, who are team members. That role is covered. You might also include the graphic artist and the technologists in that group. Next are the pilot class and the regular class. It seems to me that the people involved here are the customers and users of the new training class; same goes for the CSR supervisors and the trainers. It looks like you are using the term customers and users interchangeably for this project. You can thus stop using the term users on your communication template. Okay, you’ve covered the resources from the resource list. Now you can review the rest of the roles from your checklist and see if they apply to this project. The first role is the project customer. In this case, this is the Vice President of Customer Service, who has requested this reduction in training time. Leave that role on the list. The next role is the project sponsor, who is the project manager’s executive. This is the executive accountable for the project. Definitely leave that person on the communication list.

214

Chapter 7

The next role is the approver. You added this role during the requirements work, to make sure you covered anyone who would sign off on the requirements. You must understand the development work of this project so you can understand who should sign off. The final sign-off on the deliverables will come from the project customer, the Vice President of Customer Service. The vice president will receive information from the CSR supervisors on whether the final sign-off should be given. Thus, the CSR supervisors will need some special communication to make sure they know that the training class is ready. The next role is subject matter experts. Will you bring in additional experts other than the technologists and the graphic designers? It doesn’t appear so. Remove that role from the communication list. The same holds true for the roles labeled Legal, Consultants, and Marketing. However, Human Resources is a different story; that department hires the customer service representatives and, thus, will need to know when the class is projected to be done so department managers can advise the new hires accordingly. The last role is managers. You need to find out whether you’ll need to communicate with other managers involved in the project. Start with the Customer Service department. Are there any other managers between the vice president and the CSR supervisors? Yes, there are two department heads in the organization, one for customer service and one for sales. The director in charge of customer service will need a lot of communication. The director in change of sales will probably need only some intermittent status information. You’ve finished reviewing the resources from your project plan for communication needs. You’ve also finished reviewing the roles from the communication template. The last thing that you need to do is good old-fashioned brainstorming. Sit back now and think about your project. Who else is involved who might need to know what is happening on your project? Two categories come to mind immediately. The first is the managers of the IT shop. You have some tasks established to determine whether the customer service rep system is redone. You’ve made some assumptions here that you won’t need to do that. But it’s best to keep that group informed. The other group that comes to mind is the executive office, which handles major customer complaints that have escalated so far that the customer service organization can no longer appease the customer. A risk exists that even with all the monitoring that you are planning to do, customer complaints

Communication—What Do You Think About My Project?

215

could increase. Best to keep that group informed so the members can plan their staffing accordingly. Now that you’ve completed your brainstorming, take the communication list to your team and see if they come up with anyone else to add. When you’re finished, you should have a list similar to Table 7.4. Table 7.4 Communication Roles Checklist Who Project customer Project sponsor Approvers CSR supervisors Customers Trainers CSR supervisors Pilot class Regular class Human Resources Managers Director of Customer Service Director of Sales IT managers Executive offices Project team Course developers Graphic artist Technologist

When

Why

What

How

216

Chapter 7

Let’s move on now to the second element of communication planning: when communication should happen.

Timing Is Everything Yes, that old saying is very true in the case of project communication. You will want to plan exactly what types of communication are provided at different times of the project. You can think through the timings in two ways. First, you can determine the timing by the phase of the project. Then you can talk about specific events that trigger communication. Time by Life Cycle Chapter 1,“Setting the Project Management Context,” discussed the project management life cycle and the product development life cycle. Whatever life cycle you decide to use for your project should encompass both the elements of product development and the processes of project management that must be completed. You will use a course development life cycle for the training time reduction project. This development model uses a systems approach for designing instruction similar to that of software engineering. This is an iterative process that begins by identifying instructional goals, ending with summative evaluation during the deployment phase. You’ll notice also that I have added a feasibility phase to the life cycle, to cover the work you must do to determine the approach to take. Figure 7.1 depicts the life cycle.

Feasibility

Design

Construction

Figure 7.1 Training time reduction life cycle

Pilot

Deploy

Communication—What Do You Think About My Project?

217

You can also see how the project’s network diagram fits into the life cycle, as depicted in Figure 7.2. Now let’s use the communication template and determine whether to tackle communication by phase. First, who needs to know that the feasibility phase has been completed and that the approach has been solidified? The project customer, the project sponsor, the CSR supervisors, the IT managers, the technologist, the trainers, and the directors of Customer Service and Sales would all want to know that information. Now let’s look at the design phase. Who would need to know what has happened with the design of the new class? The project customer, the project sponsor, the CSR supervisors, the director of Customer Service, and the course developers would need to know about the design phase. What about the construction phase of the project? Who would need to know information about the construction phase? Looks like the project customer, the project sponsor, the trainers, the CSR supervisors, the pilot class, and the project team all need information during construction. Finally, let’s look at the deployment phase, in which there is information required for all roles except the IT managers and the technologist. The only reason they are left out is because you assume in the feasibility phase that you will not make any changes to the computer system. Of course, this communication plan will change if that assumption does not hold true.

218

Chapter 7

Feasibility Design 1.1 Interview CSR supervisors 2.3 Create learning objectives

1.2 Determine current customer complaints 1.4 Create current state document

Start

2.4 Determine whether to use a new technology

2.1 Create approach document

3.5 Design the class

3.15 Verify the timings

1.3 Determine current training time 2.2 Determine whether to rewrite or start over

1.5 Investigate what is currently trained

1.6 Create product requirements

1.7 Signoff requirements

Figure 7.2 Training time reduction network diagram with life cycle phases

3.16 Process analysis

Communication—What Do You Think About My Project?

Construction Pilot 3.12.1 Create class module 1

3.12.2 Create class module 2

3.12.3 Create class module 3

3.17 Verify timings

3.6 Create job aids

3.13 Create pilot textbooks

3.9 Conduct pilot class

3.12.4 Create class module 4

3.10 Verify learning objectives are met

3.12.5 Create class module 5

3.12.6 Create class module 6

3.8 Verify the training class is 50% less

3.12.7 Create class module 7 3.2 Time the pilot class

3.12.8 Create class module 8

Deploy

3.14 Revise material after the pilot

3.7 Adjust the class to 50% less

Figure 7.2 Continued

3.11 Create textbooks 3.1 Conduct first class

3.4 Train the trainer

3.3 Verify customer complaints are < 2%

End

3.18 Monitor for customer complaints

219

220

Chapter 7

Table 7.5 summarizes when communication should be done by phase. Table 7.5 When Communication Should Be Done By Phase Who

When

Project customer

All phases

Project sponsor

All phases

Approvers CSR supervisors

Feasibility

Customers Trainers

All phases

CSR supervisors

All phases

Pilot class

Construction

Regular class

Deployment

Human Resources

Deployment

Managers Director of Customer Service

All phases

Director of Sales

Feasibility Deployment

IT managers

Feasibility

Executive offices

Deployment

Project team Course developers

Design Construction Deployment

Graphic artist

Construction Deployment

Technologist

Feasibility

Why

What

How

221

Communication—What Do You Think About My Project?

Events That Trigger Communication You can now look at the second level of analysis of timing project communication: triggering communication by events that happen on a project. Here you are looking for moments in time that specific communication must be sent. These are probably major milestones that happen within the phases of the project. Here’s how you do this analysis. Look back over the network diagram depicted in Figure 7.2. Determine whether any major events by themselves trigger a communication event. Do you see any items that you would want to tell people about to either claim victory or reassure the audience that things are getting done? A couple events could warrant their own communication event in this case. The first is the sign-off on the requirements in the feasibility phase. Most of the other major milestones are in the deployment phase,including completing the “train the trainer” class and training the first class. These are the types of items you can use to trigger communication events. You’ve now updated the communication plan with the event communication, as shown in Table 7.6. Table 7.6 Events That Trigger Communication Who

When

Project customer

All phases

Why

What

How

All events Project sponsor

All phases All events

Approvers CSR supervisors

Feasibility Requirements sign-off

Customers Trainers

All phases All events continued

222

Chapter 7

Table 7.6 Continued Who

When

CSR supervisors

All phases All events

Pilot class

Construction

Regular class

Deployment

Human Resources

Deployment

Managers Director of Customer Service

All phases All events

Director of Sales

Feasibility Deployment

IT managers

Feasibility

Executive offices

Deployment

Project team Course developers

Design Construction Deployment All events

Graphic artist

Construction Deployment

Technologist

Feasibility

Why

What

How

223

Communication—What Do You Think About My Project?

Why Do This Communication? You now can move to the next column of your communication plan. Here, you need to ask yourself why you need to communicate at this point in time or for this event. Ask yourself,“What is my communication trying to accomplish?”You might have already determined this as you picked out the phases of or the events for communication. Go back to your objectives for creating a communication plan in the first place. You need to use the “why” as a way to express the outcome you want to achieve by communicating. Remember, one of your major objectives was to manage perceptions. You can update the communication plan as you like while you are pondering this question. You can create a version that is yours alone to view. You also can create a sanitized version later to include in the project plan. You are probably asking “Why two versions?” Well, you might want to get personal about some of your reasons for communicating at different points in time or with different people. The example from here forward is the personal version. Go ahead and update the communication plan now with the “why” for each communication, as depicted in Table 7.7. Table 7.7 Why Communication Should Be Done Who

When

Why

Project customer

All phases

Have confidence that we will deliver what they ask.

All events

Major milestones are all on track.

All phases

Have confidence that we will deliver what they ask. We will make him look good

All events

Major milestones are all on track.

Project sponsor

What

How

continued

224

Chapter 7

Table 7.7 Continued Who

When

Why

Feasibility

Need them to be ready to sign off.

Requirements sign-off

Their work on requirements is completed.

All phases

Want them to know what is happening so they are ready to go with deployment.

All events

Want them to know what is happening so they are ready to go with deployment.

All phases

Want them to know what is happening so they are ready to go with deployment.

All events

Want them to know what is happening so they are ready to go with deployment.

Pilot class

Construction

Want them to know what is happening so they are ready to go with deployment.

Regular class

Deployment

Want them to know what is happening so they are ready to go with deployment.

Approvers CSR supervisors

Customers Trainers

CSR supervisors

What

How

225

Communication—What Do You Think About My Project?

Who

When

Why

Human Resources

Deployment

Want them to know what is happening so they are ready to go with deployment.

All phases

Have confidence that we will deliver what they ask.

All events

Major milestones are all on track.

Feasibility

Have confidence that we will deliver what they ask.

Deployment

Major milestones are all on track.

IT managers

Feasibility

Their work is done.

Executive offices

Deployment

Want them to know what is happening so they are ready to go with deployment.

Design

They need a consistent message of what is happening.

Construction

They need a consistent message of what is happening.

Deployment

They need a consistent message of what is happening.

All events

They need a consistent message of what is happening.

What

How

Managers Director of Customer Service

Director of Sales

Project team Course developers

continued

226

Chapter 7

Table 7.7 Continued Who

When

Why

Graphic artist

Construction

They need a consistent message of what is happening.

Deployment

They need a consistent message of what is happening.

Feasibility

They need a consistent message of what is happening.

Technologist

What

How

What to Communicate? Column four of the communication plan deals with what needs to be communicated. Here is where you get specific about what you want to tell people. Ask yourself, “What is the content of the message that should be provided here?” Don’t worry about how that communication is delivered yet; you will do that in the next column. You’ll find the What column updated in the communication plan in Table 7.8. Table 7.8 What to Communicate? Who

When

Why

What

Project customer

All phases

Have confidence that we will deliver what they ask.

Phase completed on time. All is well.

All events

Major milestones are all on track.

Milestone completed. All is well.

All phases

Have confidence that we will deliver what they ask. We will make him look good.

Phase completed on time. All is well.

All events

Major milestones are all on track.

Milestone completed. All is well.

Project sponsor

How

227

Communication—What Do You Think About My Project?

Who

When

Why

What

Feasibility

Need them to be ready to sign off.

Provide requirements. Provide who has been involved. Describe the process.

Requirements sign-off

Their work on requirements is completed.

Requirements completed. Who signed off?

All phases

Want them to know what is happening so they are ready to go with deployment.

Phase completed on time. All is well.

All events

Want them to know what is happening so they are ready to go with deployment.

Milestone completed. All is well.

All phases

Want them to know what is happening so they are ready to go with deployment.

Phase completed on time. All is well.

All events

Want them to know what is happening so they are ready to go with deployment.

Milestone completed. All is well.

Pilot class

Construction

Want them to know what is happening so they are ready to go with deployment.

Provide what to expect in pilot. What is their role?

Regular class

Deployment

Want them to know what is happening so they are ready to go with deployment.

Provide what to expect.

How

Approvers CSR supervisors

Customers Trainers

CSR supervisors

continued

228

Chapter 7

Table 7.8 Continued Who

When

Why

What

Human Resources

Deployment

Want them to know what is happening so they are ready to go with deployment.

Get ready. Our new training program will be in use soon.

All phases

Have confidence that we will deliver what they ask.

Phase completed on time. All is well.

All events

Major milestones are all on track.

Milestone completed. All is well.

Feasibility

Have confidence that we will deliver what they ask.

Milestone completed. All is well.

Deployment

Major milestones are all on track.

Milestone completed. All is well.

IT managers

Feasibility

Their work is done.

Feasibility is completed. Current system usable. Thanks for your help.

Executive offices

Deployment

Want them to know what is happening so they are ready to go with deployment.

Get ready. New training will be deployed soon. Cover results of customer complaint monitoring.

Design

They need a consistent message of what is happening.

Regular status.

Managers Director of Customer Service

Director of Sales

Project team Course developers

How

Communication—What Do You Think About My Project?

Who

Graphic artist

Technologist

When

Why

What

Construction

They need a consistent message of what is happening.

Regular status.

Deployment

They need a consistent message of what is happening.

Regular status. Moving into the home stretch.

All events

They need a consistent message of what is happening.

Milestone completed. All is well.

Construction

They need a consistent message of what is happening.

Regular status.

Deployment

They need a consistent message of what is happening.

Regular status.

Feasibility

They need a consistent message of what is happening.

Regular status.

229

How

Okay, you have updated the communication plan and are now ready to determine exactly how to deliver the communication to the recipients. You will answer the “how” question of your communication plan. First you must do a little analysis of your intended audience, both from a general perspective as well as specifically.

Know Your Recipients—General The key to effective communication is that a message is sent and the recipient receives the communication and understands it more or less as the originator of the message intended. How many times have you received an e-mail and glanced at it and said,“I’ll look at that later,” yet you never went back to it? That is exactly the scenario I am talking about here. You want to make sure that the message is actually received. Different groups of people have different preferences about how they best communicate. You also need to take into account how you deal with virtual teams and how to guarantee that

230

Chapter 7

they have received your message. It’s your job as the project manager to understand your audience well enough to make sure they receive and understand your message. You will need to go back over your communication plan now, to the Who column, and really think about how these people work and how best to communicate with them. Let’s start with the project sponsor and the project customer. Both are executives, and you know their time is very limited. You also need to make sure that they receive the right messages. Having a face-to-face meeting with both of them, scheduled every couple of weeks, is probably best. Now let’s look at the CSR supervisors both from a requirements approval perspective and as a customer of the project. They will need some special attention during the requirements work; you need them to both help build the requirements and to sign off on them when completed. For this work, you’ll want to meet with them regularly and make sure that they understand how the requirements have been built and that you answer any questions along the way. You’ll want to see whether any of the supervisors exhibit resistance. You could face a weeks-long stalemate if any of them are not satisfied with the quality of the requirements and they tell the project customer about their discomfort. It sounds like you should meet face to face with the CSR supervisors all the way through the feasibility phase. Now think about how to communicate with the CSR supervisors from the perspective of a customer of the project. These supervisors, when not in a meeting, spend all their time on the floor with the customer service reps. They answer questions, monitor their subordinates, and take calls from unhappy customers. They rarely look at e-mail. How can you communicate with people like these? Well, because you’ve done your homework, you know that an electronic dashboard in the customer service rep office displays the current wait time for customers, the current customer complaint percentages, and any other critical news. Everyone in the room reads this monitor because the wait times and complaint percentages are factored into calculating the bonus plans for the customer services reps and supervisors. You know they will see your message if you can get a quick status on the dashboard. Besides, you know that the customer service reps and supervisors are all nervous about the new training and how it might affect the complaint percentages and their bonus. I think you’re probably getting the picture now about understanding your audience and how you will determine how best to communicate to each

231

Communication—What Do You Think About My Project?

group on your communication management plan. Just make sure you do your homework and really understand how these people work. Go ahead and update the plan with your customized solutions for effective communication with each group, as shown in Table 7.9. Table 7.9 Know Your Recipients—General Who

When

Why

What

How

Project customer

All phases

Have confidence that we will deliver what they ask.

Phase completed on time. All is well.

1. Regular monthly status report. 2. Face to face every two weeks.

Project sponsor

All events

Major milestones are all on track.

Milestone completed. All is well.

1. TTR newsletter, announcing milestone. E-mail.

All phases

Have confidence that we will deliver what they ask. We will make him look good.

Phase completed on time. All is well.

1. Regular monthly status report. 2. Face to face every two weeks.

All events

Major milestones are all on track.

Milestone completed. All is well.

1. TTR newsletter, announcing milestone. E-mail.

Feasibility

Need them to be ready to sign off.

Provide requirements. Provide who has been involved. Describe the process.

1. Weekly face-to-face meeting.

Approvers CSR supervisors

continued

232

Chapter 7

Table 7.9 Continued Who

When

Why

What

How

Requirements sign-off

Their work on requirements is completed.

Requirements completed. Who signed off.

1. TTR newsletter, announcing milestone. E-mail. 2. Celebration and thank-you lunch.

Customers Trainers

All phases

Want them to know what is happening so they are ready to go with deployment.

Phase completed on time. All is well.

1. TTR newsletter on status. E-mail. 2. Meet two months before deployment face to face to provide status, answer questions.

All events

Want them to know what is happening so they are ready to go with deployment.

Milestone completed. All is well.

1. TTR newsletter, announcing milestone. E-mail. 1. TTR newsletter on status. E-mail.

CSR supervisors

All phases

Want them to know what is happening so they are ready to go with deployment.

Phase completed on time. All is well.

1. TTR newsletter on status. E-mail. 2. Electronic dashboard status.

233

Communication—What Do You Think About My Project?

Who

When

Why

What

How

All events

Want them to know what is happening so they are ready to go with deployment.

Milestone completed. All is well.

1. TTR newsletter, announcing milestone. E-mail. 2. Electronic dashboard.

Pilot class

Construction

Want them to know what is happening so they are ready to go with deployment.

Provide what to expect in pilot. What is their role?

1. TTR newsletter on status. E-mail. 2. Electronic dashboard.

Regular class

Deployment

Want them to know what is happening so they are ready to go with deployment.

Provide what to expect in class.

1. Insert into HR hiring notice on new class.

Human Resources

Deployment

Want them to know what is happening so they are ready to go with deployment.

Get ready. Our new training program will be in use soon.

1. TTR newsletter on status. E-mail. 2. Meet two months before deployment face to face to provide status, answer questions.

Managers Director of Customer Service

All phases

Have confidence that we will deliver what they ask.

Phase completed on time. All is well.

1. TTR newsletter on status. E-mail.

All events

Major milestones are all on track.

Milestone completed. All is well.

1. TTR newsletter, announcing milestone. E-mail. continued

234

Chapter 7

Table 7.9 Continued Who

When

Why

What

How

Director of Sales

Feasibility

Have confidence that we will deliver what they ask.

Milestone completed. All is well.

1. TTR newsletter on status. E-mail.

Deployment

Major milestones are all on track.

Milestone completed. All is well.

1. TTR newsletter on status. E-mail.

Feasibility

Their work is done.

Feasibility is completed. Current system usable. Thanks for your help.

1. TTR newsletter on status. E-mail.

IT managers

Executive offices

Deployment

Want them to know what is happening so they are ready to go with deployment.

Get ready. New training will be deployed soon. Cover results of customer complaint monitoring.

2. Celebration and thank-you lunch. 1. TTR newsletter on status. E-mail. 2. Meet two months before deployment face to face to provide status, answer questions. 3. Meet one month before deployment face to face to provide status and statistics, answer questions.

Communication—What Do You Think About My Project?

Who

235

When

Why

What

How

Design

They need a consistent message of what is happening.

Regular status.

1. TTR newsletter on status. E-mail.

Project team Course developers

2. Weekly face to face. Construction

They need a consistent message of what is happening.

Regular status.

1. TTR newsletter on status. E-mail. 2. Weekly face to face.

Deployment

They need a consistent message of what is happening.

Regular status. Moving into the home stretch.

1. TTR newsletter on status. E-mail. 2. Weekly face to face.

All events

They need a consistent message of what is happening.

Milestone completed. All is well.

1. TTR newsletter, announcing milestone. E-mail. 2. Weekly face to face.

Graphic artist

Construction

They need a consistent message of what is happening.

Regular status.

1. TTR newsletter on status. E-mail. 2. Weekly face to face.

Deployment

They need a consistent message of what is happening.

Regular status.

1. TTR newsletter on status. E-mail. 2. Weekly face to face.

Technologist

Feasibility

They need a consistent message of what is happening.

Regular status.

1. TTR newsletter on status. E-mail. 2. Weekly face to face.

236

Chapter 7

Tips on Communication Delivery When in doubt, try something different. Most projects send out paper status reports and e-mails to provide status. Most communications are not received. In other words, message sent does not necessarily equal message received. Try techniques that will create interest, such as a computer in the lunch room with the new computer system, where people can play. Create buzz: Set up a contest on naming an element of the project. Stop getting ho-hum communication results. Try something different.

Know Your Recipients—Special Handling One more thing before you say the communication plan is complete and ready to execute. You’ve analyzed who gets communication from a general or group perspective. Now you really need to get down to the fine details and do the same analysis for the individuals in each of these groups. In Chapter 3, I defined three types of individuals who might work on your project: • Champions—The people who will work with your product every day. They are credible, and their coworkers believe what they say. Including them in your special handling could get the opposition in line. • Influencers—The people who advise the approvers. They are the ones who influence the executives about the state of the project. • Challengers—The people who have something to gain if you miss delivering the MOP of the project. You will want to go through your list of who gets communication to see if any individuals fall into these categories. If so, they will require special handling when it comes to communication. Let’s run through an example. You have worked with the CSR supervisor Gayle Cosgrove for years. She has a very different style than you, and sometimes the two of you have not seen eye to eye. She tends to say the first thing that comes to mind when in a meeting. Usually, it’s an emotional response, not based in fact. She could ruin the credibility of your project and the status that you are providing if she provides emotional responses. In the past, you’ve seen her do this before— and it looked to you that she wasn’t getting enough information to speak factually. (You’ve heard that IT has asked her to continually clean out her inbox

Communication—What Do You Think About My Project?

237

of unread e-mails. She is using up too much disk space!) Your analysis of dealing with Gayle is that she will need special handling. She actually falls into all three categories of champion, influencer, and challenger. She’s a champion because her service reps respect her and her opinions. She’s an influencer because you won’t get the project customer sign-off without her concurrence. And she is a challenger because she doesn’t stay informed and then provides an emotional uninformed opinion. You should do the same analysis on every person who falls into the groups that you have listed. Ask yourself,“Is this person a champion, a challenger, or an influencer?” If not, ask yourself,“Is there sufficient communication for each person in each group here?” If so, ask yourself,“What do I need to do to guarantee the communication?” Table 7.10 shows the addition of a few people who need special handling into the communication. Table 7.10 Know Your Recipients—Specific Who

When

Why

What

How

Project customer

All phases

Have confidence that we will deliver what they ask.

Phase completed on time. All is well.

1. Regular monthly status report. 2. Face to face every two weeks.

Project sponsor

All events

Major milestones are all on track.

Milestone completed. All is well.

1. TTR newsletter, announcing milestone. E-mail.

All phases

Have confidence that we will deliver what they ask. We will make him look good.

Phase completed on time. All is well.

1. Regular monthly status report. 2. Face to face every two weeks. continued

238

Chapter 7

Table 7.10 Continued Who

When

Why

What

How

All events

Major milestones are all on track.

Milestone completed. All is well.

1. TTR newsletter, announcing milestone. E-mail.

Feasibility

Need them to be ready to sign off.

Provide requirements. Provide who has been involved. Describe the process.

1. Weekly faceto-face meeting.

Requirements sign-off

Their work on requirements is completed.

Requirements completed. Who signed off.

1. TTR newsletter, announcing milestone. E-mail.

Approvers CSR supervisors

2. Celebration and thank-you lunch. Gayle Cosgrove

Same as above. Same as above.

Same as above.

1 Use all previous steps. 2. Stop by the CSR area and have a “drop by” face-to-face conversation giving her status. Need to do this at least once a week.

Customers Trainers

All phases

Want them to know what is happening so they are ready to go with deployment.

Phase completed on time. All is well.

1. TTR newsletter on status. E-mail. 2. Meet two months before deployment face to face to provide status, answer questions.

Communication—What Do You Think About My Project?

Who

239

When

Why

What

How

All events

Want them to know what is happening so they are ready to go with deployment.

Milestone completed. All is well.

1. TTR newsletter, announcing milestone. E-mail. 1. TTR newsletter on status. E-mail.

Tom Simmons

Same as above. Same as above.

Same as above.

1. Use all previous steps. 2. Champion for the trainers. Give one-on-one status frequently. 3. Have a private walk-through of the design. 4. Have a private walk-through of the course after first module is completed. 5. Ask him to be the first trainer after deployment.

CSR supervisors

All phases

All events

Want them to know what is happening so they are ready to go with deployment.

Phase completed on time. All is well.

Want them to know what is happening so they are ready to go with deployment.

Milestone completed. All is well.

1. TTR newsletter on status. E-mail. 2. Electronic dashboard status. 1. TTR newsletter, announcing milestone. E-mail. 2. Electronic dashboard. continued

240

Chapter 7

Table 7.10 Continued Who

When

Why

What

How

Pilot class

Construction

Want them to know what is happening so they are ready to go with deployment.

Provide what to expect in pilot. What is their role?

1. TTR newsletter on status. E-mail. 2. Electronic dashboard. 3. Meet with them one month before pilot class and provide expectations. Determine if we have champions, influencers, or challengers.

Regular class

Deployment

Want them to know what is happening so they are ready to go with deployment.

Provide what to expect in class.

1. Insert into HR hiring notice on new class.

Human Resources

Deployment

Want them to know what is happening so they are ready to go with deployment.

Get ready. Our new training program will be in use soon.

1. TTR newsletter on status. E-mail.

All phases

Have confidence that we will deliver what they ask.

Phase completed 1. TTR newsletter on time. All is on status. E-mail. well.

All events

Major milestones are all on track.

Milestone completed. All is well.

2. Meet two months before deployment face to face to provide status, answer questions.

Managers Director of Customer Service

1. TTR newsletter, announcing milestone. E-mail.

241

Communication—What Do You Think About My Project?

Who

When

Why

What

How

Director of Sales

Feasibility

Have confidence that we will deliver what they ask.

Milestone completed. All is well.

1. TTR newsletter on status. E-mail.

Deployment

Major milestones are all on track.

Milestone completed. All is well.

1. TTR newsletter on status. E-mail.

Feasibility

Their work is done.

Feasibility is completed. Current system usable. Thanks for your help.

1. TTR newsletter on status. E-mail.

IT managers

Executive offices

Deployment

Want them to know what is happening so they are ready to go with deployment.

Get ready. New training will be deployed soon. Cover results of customer complaint monitoring.

2. Celebration and thank-you lunch. 1. TTR newsletter on status. E-mail. 2. Meet two months before deployment face to face to provide status, answer questions. 3. Meet one month before deployment face to face to provide status and statistics, answer questions.

Project team Course developers

Design

They need a consistent message of what is happening.

Regular status.

1. TTR newsletter on status. E-mail. 2. Weekly face to face.

Construction

They need a consistent message of what is happening.

Regular status. on status. E-mail.

1. TTR newsletter 2. Weekly face to face. continued

242

Chapter 7

Table 7.10 Continued Who

When

Why

What

How

Deployment

They need a consistent message of what is happening.

Regular status. Moving into the home stretch.

1. TTR newsletter on status. E-mail. 2. Weekly face to face.

All events

They need a consistent message of what is happening.

Milestone completed. All is well.

1. TTR newsletter, announcing milestone. E-mail. 2. Weekly face to face.

Graphic artist

Construction

They need a consistent message of what is happening.

Regular status.

1. TTR newsletter on status. E-mail. 2. Weekly face to face.

Deployment

They need a consistent happening.

Regular status.

1. TTR newsletter message of what is on status. E-mail. 2. Weekly face to face.

Technologist

Feasibility

They need a consistent message of what is happening.

Regular status.

1. TTR newsletter on status. E-mail. 2. Weekly face to face.

Did you notice some new information inserted for the pilot class? You realized how important the perceptions of the pilot class will be as you completed the analysis. You also realized that you really don’t know these people. In your notes on the How column, you have inserted that you will meet with them face to face to set expectations. In that meeting, you’ll try to figure out if we have challengers, champions, or influencers. You’ll then go back and update the communication plan with more information.

243

Communication—What Do You Think About My Project?

Going back to update the plan later is an important point. This communication plan is a living document. You must keep it updated, and as you see things change, you must add more information or perhaps change your strategy with different groups. Your personal communication plan is now finished. Some of the information you’ve provided is a little sensitive for a project sponsor or a team member to view. You’ll keep this version for yourself and create a sanitized version that will be published in the project plan. We’ve created a sanitized version in Table 7.11 for you to review. Table 7.11 Communication Plan Ready for Project Plan Who

When

Why

What

How

Project customer

All phases

Want them to know we are on track.

Phase completed on time. All is well.

1. Regular monthly status report. 2. Face to face every two weeks.

Project sponsor

All events

Major milestones are all on track.

Milestone completed. All is well.

1. TTR newsletter, announcing milestone. E-mail.

All phases

Want them to know we are on track.

Phase completed on time. All is well.

1. Regular monthly status report. 2. Face to face every two weeks.

All events

Major milestones are all on track.

Milestone completed. All is well.

1. TTR newsletter, announcing milestone. E-mail. continued

244

Chapter 7

Table 7.11 Continued Who

When

Why

What

How

Feasibility

Need them to be ready to sign off.

Provide requirements. Provide who has been involved. Describe the process.

1. Weekly faceto-face meeting.

Requirements sign-off

Their work on requirements is completed.

Requirements completed. Who signed off.

1. TTR newsletter, announcing milestone. E-mail.

Approvers CSR supervisors

2. Celebration and thank-you lunch. Customers Trainers

All phases

Want them to know we are on track.

Phase completed on time. All is well.

1. TTR newsletter on status. E-mail. 2. Meet two months before deployment face to face to provide status, answer questions.

All events

Want them to know what is happening so they are ready to go with deployment.

Milestone completed. All is well.

1. TTR newsletter, announcing milestone. E-mail. 1. TTR newsletter on status. E-mail.

CSR supervisors

All phases

Want them to know we are on track.

Phase completed on time. All is well.

1. TTR newsletter on status. E-mail. 2. Electronic dashboard status.

245

Communication—What Do You Think About My Project?

Who

Pilot class

When

Why

What

How

All events

Want them to know we are on track.

Milestone completed. All is well.

1. TTR newsletter, announcing milestone. E-mail. 2. Electronic dashboard.

Construction

Want them to know we are on track.

Provide what to expect in pilot. What is their role?

1. TTR newsletter on status. E-mail. 2. Electronic dashboard. 3. Meet with them one month before pilot class and provide expectations.

Regular class

Deployment

Want them to know what is happening so they are ready to go with deployment.

Provide what to expect in class.

1. Insert into HR hiring notice on new class.

Human Resources

Deployment

Want them to know we are on track.

Get ready. Our new training program will be in use soon.

1. TTR newsletter on status. E-mail. 2. Meet two months before deployment face to face to provide status, answer questions.

Managers Director of Customer Service

All phases

Want them to know we are on track.

Phase completed on time. All is well.

1. TTR newsletter on status. E-mail. continued

246

Chapter 7

Table 7.11 Continued Who

Director of Sales

IT managers

Executive offices

When

Why

What

How

All events

Major milestones are all on track.

Milestone completed. All is well.

1. TTR newsletter, announcing milestone. E-mail.

Feasibility

Want them to know we are on track.

Milestone completed. All is well.

1. TTR newsletter on status. E-mail.

Deployment

Major milestones are all on track.

Milestone completed. All is well.

1. TTR newsletter on status. E-mail.

Feasibility

Want them to know we are on track.

Feasibility is completed. Current system usable. Thanks for your help.

1. TTR newsletter on status. E-mail.

Deployment

Want them to know we are on track.

Get ready. New training will be deployed soon. Cover results of customer complaint monitoring.

2. Celebration and thank-you lunch. 1. TTR newsletter on status. E-mail. 2. Meet two months before deployment face to face to provide status, answer questions. 3. Meet one month before deployment face to face to provide status and statistics, answer questions.

Communication—What Do You Think About My Project?

Who

When

Why

What

How

Design

Need to know.

Regular status.

1. TTR developers newsletter on status. E-mail.

247

Project team Course

2. Weekly face to face. Construction

Need to know.

Regular status.

1. TTR newsletter on status. E-mail. 2. Weekly face to face.

Deployment

Need to know.

Regular status. Moving into the home stretch.

1. TTR newsletter on status. E-mail. 2. Weekly face to face.

All events

Need to know.

Milestone completed. All is well.

1. TTR newsletter, announcing milestone. E-mail. 2. Weekly face to face.

Graphic artist

Construction

Need to know.

Regular status.

1. TTR newsletter on status. E-mail. 2. Weekly face to face.

Deployment

Need to know.

Regular status.

1. TTR newsletter on status. E-mail. 2. Weekly face to face.

Technologist

Feasibility

Need to know.

Regular status.

1. TTR newsletter on status. E-mail. 2. Weekly face to face.

248

Chapter 7

You have completed your communication planning. Now you are ready to move into the “Teaming” section to talk about communication planning and how it will work with your team.

Teaming I once worked on a project that replaced an old major computing system with a new Web-based system. I was not familiar with the content of the computer system, so I relied heavily on one subject matter expert, Pat, to advise me on the functionality we were replacing. Pat was a crusty curmudgeon of a person. No one liked working with him because he didn’t like anything—yes, anything. He disagreed with the project approach, and he disagreed with the new system. He didn’t like his team members. I could go on for days on what he didn’t like. Yet the users of the new system respected him and knew he would watch out for their best interests. Of course, they had to get past his negativity before they could hear what he was really saying. How do you manage the perceptions of your project when you are dealing with a team member like this? You can use a couple techniques to combat this type of negativity and still manage the perceptions about the project. In fact, these are good practices to put into place for managing the team’s communication altogether. • Set the right expectations—To manage the perceptions about your project, you need to go back to the team norms again in order to set the proper expectations. You had the following team norms: 1. If a person has a problem with me, they will come to me first before talking about the problem with someone else. If you apply that same concept of “tell me before you tell others” to project status and issues, you could have a second team norm. 2. If you have something negative to say about the project, you will tell the project manager before you tell anyone else. Establish these norms and enforce; you’ll stand a better chance of disseminating consistent communication about your project. This norm also establishes the fact that you are willing to have the hard conversations with your team members about what they think is going wrong on the project. You might not be able to change their mind about what is wrong, but you will know what they are saying and will have a chance to proactively handle the negative information.

Communication—What Do You Think About My Project?

249

Besides, knowing what they think is going wrong also gives you the opportunity to capture these items as issues and work them, or, if appropriate, capture these items as risks so you can proactively handle the possible risk. I talk more about risks in the next chapter. • Look for influencers, champions, and challengers—Just as you looked for influencers, champions, and challengers across the roles and people affected by the project, you’ll do the same with your own team. Do you have one course developer who is really the leader for the other course developers? If so, you might want to spend extra time with this person to make sure he or she is on board and will bring along the rest of the course developers. You’ll also want to update your personal communication plan with special handling information for your project team. • Build the right environment—In your team meetings, it’s up to you to build the proper environment. Encourage open and frank discussions with the members. Reward and praise when things go right. Make sure that everyone understands the “lessons learned” when things go wrong. Get the project back on track and move on. Try to instill a “can do” attitude in all team members. People want to be part of a successful team. They want to achieve and receive acknowledgments for their achievements. Team members who are saying negative things about the project might be doing so because you haven’t convinced them that this project will succeed. Build a circle of events that spirals toward success. Turn the negative talk into issues and risks. Have that “can do” attitude with every problem that crops up. The team members will know there is a better chance for success when they see the circle of events. If you can get the positive momentum going, the team will get caught up in it. You can use these tricks of the trade to enhance your project communication plan, your team norms, as well as your style of project management to help manage the perceptions on your project. Now let’s see how politics and communication work together.

Politics The best defense is a strong offense. You build that offense with a wellthought-out communication plan that is systematically executed through the life of the project and updated with new information as warranted.

250

Chapter 7

You will find fewer politics if you can get a consistent message to the stakeholders of your project. Sure, bad news might crop up along the way, but less disruption will occur if you are consistent in your execution of the project and you have provided consistent information. The executives will have confidence in you to solve the problems that the project is facing. One issue you might face in working with your executives is maintaining buy-in. Remember, executives face new challenges every day. Markets shift, new competitive products are introduced, and business just changes. Your executives might lose interest in your project because of the other issues they are facing. They might start canceling meetings with you because they are just too busy. How do you make sure that they are getting the information you need them to have when your entire communication strategy is set up based on face-to-face meetings? Here are a couple of tactics you can use to get the information to them: • Double up—You probably noticed that we had the executives on the status report list as well as in face-to-face meetings. Always include the executives in all the paper status reports, as well as e-mail status. If they’re cancelling meetings, you might still be able to get the information to them via e-mail or paper reports. • Drop by—I once worked for an executive who always ate lunch at her desk in between meetings. You never knew what time of the day that was going to be, but you could count on it happening. I found her receptive to a quick chat after she finished her lunch. I would walk down the hall and past her office every now and then from 11 a.m. to 2 p.m. to see what was happening in her office. If she was eating, I left her alone and kept going. I came back 15 minutes later. I always knocked and asked if she had a minute to chat. I gave her status by “I just wanted you to know….” I really did keep these status chats to five minutes: short, sweet, and effective. • Who’s the confidant?—Find out who the executive’s confidant is. Find out who has access to the executive’s office when no on else can get in. Keep an eye open, and you should be able to tell within a couple weeks. I have found that a lot of the time, the executive administrative assistant is the confidant. If that is the case, stop by the assistant’s desk and ask to get five minutes with the executive. I always mention, “I only need to get 5 minutes because I want to make sure she knows that the XYZ issue has been solved and my project is back on track.”

Communication—What Do You Think About My Project?

251

You might not get the five minutes, but you can rest assured that the executive will get the message. • Voice mail blast—In talking to the executive administrative assistant, you can usually find out if the executive ever listens to his or her own voice mail. Sometimes the admin screens every voice mail and provides a summary to the executive. Chances are good, though, that the executive listens to voice mail after hours on the way home or first thing in the morning on the way to work. Send a voice mail to them at that time so the executive gets your message directly. I have scripted these messages to be short and to the point. I’ve even sent these types of messages at 10 p.m. before I head off to bed, to make sure the executive gets the message directly. These tactics will be useful in keeping your executives abreast of the work you are doing, regardless of how busy they are.

Summary We spent this entire chapter talking about one of the most important functions that a project manager performs, communicating. I introduced a communication template that spells out the “who, what, when, where, and why” of communication. Then I explained the different elements of the template while we updated it for our example project. We then explored how communication can be effectively applied to your project team. I also covered some special tactics you can use when your executive sponsor has lost interest in the project. In the case study, we’ll see how Chris keeps working to move the core team past storming while trying to get the quality and communication planning done.

Case Study Chris started the work week with hopes of getting a lot accomplished and finally finishing her project plan. She knew she needed to first get her quality planning done and then move on to getting the communication plan completed. She decided to bring the team together to review their team norms before she started on the quality planning. The team members had

252

Chapter 7

made some progress in the couple of weeks they had been together. The team still seemed to be working in all the stages of team development, but mostly the storming phase. Chris knew from the discussion she had had with June last week that they had better review the norms again, and they probably needed to add a couple more norms to their list. Chris needed to make sure that a consistent message was being reported to everyone concerned with the project. She didn’t mind that someone had told June of the problems with the estimating; she just wanted the solution to also be presented. On Tuesday, Chris and the core team met with two agenda items: 1. Review and discuss the team norms 2. Review the network diagram to ensure the quality of the project.

Chris also added a couple of definitions regarding quality to the agenda, keeping to her word to June. Chris started the meeting with the team norms discussion. She brought in a copy of the norms they had agreed to a couple weeks ago. Chris told the core team about her conversation with June and asked that two new norms be added to the list of eight: • When communicating issues and problems to people not on the project, the core team will also tell the person of the solution applied. • If you have something negative to say about the project, you will tell the project manager before you tell anyone else. Chris then got everyone on the core team to individually concur with the additions. Chris was pretty pleased. These people might be doing a lot of storming, but they at least tried to be reasonable. The team then moved on to the next agenda item, quality planning. Chris decided not to try to get all this work done in two hours. Instead, the core team would craft the quality policy together and publish it for the rest of the project team. Chris would then give the team a homework assignment to think about the objectives of quality planning (reduce rework, etc.). Each person would review the VNLE network diagram and bring suggestions to the meeting on Thursday. Chris would facilitate the discussions on what they would change on the network diagram. Chris thought this approach would allow everyone to really think about quality from their perspective. The facilitated session would give her a chance to facilitate the discussion to possibly force them through the storming she knew was going to happen anyway.

Communication—What Do You Think About My Project?

253

The team then worked on the quality policy for the next two hours. They finally came up with “The VNLE project will receive 125 points for the trade show while lining up potential vendors for future Virtually Nostalgia products. These deliverables will be created right the first time so the project will complete on time and on budget.” You wouldn’t think that two sentences would take two hours! Chris was glad she made the rest of the work homework assignments. She knew she had better get prepared for the session on Thursday. On Wednesday, Chris spent the day doing her own review of the VNLE network diagram, in preparation for the Thursday session. She also started building her own communication plan. She realized that she wanted the core team’s opinion on who they thought were the champions, challengers, and influencers. She didn’t know enough people at Virtually Nostalgia to make those determinations on her own. She prepared the agenda for the Thursday session and built these agenda items: • Quality planning 1. Each person describes thoughts for the tasks that should be added to the network diagram. No discussion from the rest of the team as team members present their thoughts. 2. Identify common tasks and apply them to the network diagram. 3. Discuss each diverse task and determine whether it should be added. 4. Create the final network diagram. • Communication planning 1. Brainstorm what groups are affected by this project. 2. Brainstorm who in these groups are challengers, influencers, and champions of the project and within their work groups. • Definitions Chris thought that this approach on quality planning would get each person to express his or her views. She could look for common views that might bring them closer together as a team. They could then deal with the ideas that were not common. Chris was also hoping that the brainstorming for the communication work would be fun as the entire team got to analyze the organization and what they knew of the different groups.

254

Start

Chapter 7

1.3 Establish marketing goals

1.4 Determine target audience

1.1 Gather previous trade show information

2.6 Determine vendor partnership strategy

2.7 Determine target vendors

1.2 Gather input from other departments

2.1 Design the booth sales approach

2.3 Design the trade show experience

1.5 Create draft marketing plan

1.6 Review and revise draft plan with other departments

1.7 Create final marketing plan

2.10 Determine housing and travel requirements

2.11 Gather marketing material and booth shipment requirements

2.14 Verify product inventory supports the marketing plain

2.5 Design the booth

2.15 Walkthrough and sign off design

2.4 Design the marketing collateral

Detailed planning completed

2.2 Create IT demo requirements

2.8 Review and revise demo requirements

2.9 Design the demo

2.16 Walk through and sign off the demo design

2.12 Determine catering requirements

2.13 Determine trade show on site requirements

Figure 7.3 VNLE network diagram with quality tasks

Thursday night, Chris was sitting in front of the fireplace having a cup of cocoa while she reviewed the new VNLE network diagram depicted in Figure 7.3. She was pretty pleased with her approach. This meeting had been the most productive by far. When everyone realized how many common ideas they had about quality, they seemed to respect each other a little more. They were actually fairly cordial to each other. Chris smiled to herself, pleased that her strategy had worked. And on top of a cordial meeting, she had a pretty good quality plan incorporated into the network diagram. Tomorrow she would incorporate their communication ideas into the communication plan. Speaking of that, she had not yet provided status reports to any of the executives on the project. She knew she had better get some information to them shortly. With that, she took another sip of cocoa and started to get ready for bed.

Communication—What Do You Think About My Project?

3.1.9 Build marketing collateral

3.1.16 Verify marketing collateral with focus group

3.1.13 Create trade show buzz

3.1.8 Establish premeetings with vendors

3.1.10 Build the booth

3.1.17 Verify the booth build with focus group 3.1.6 Prototype the booth experience

3.1.11 Build the demo

3.1.1 Arrange flights and lodging

3.1.19 Verify the booth experience with the focus group

3.1.2 Ship marketing material and booth

3.1.7 Learn and practice demo

3.1.12 Test the demo

Ready for the trade show

3.1.14 Verity the web site is ready

3.1.18 Verify demo with focus group

3.1.4 Finalize trade show on site requirements

3.1.3 Make catering arrangements

3.1.15 Verify the catalog is ready

3.1.5 Verify product inventory supports the trade show plan

3.2.1 Verify and correct logistics

3.2.2 Manage the trade show event

3.2.3 Staff the booth

3.2.4 Get feedback for vendor experience during event

Figure 7.3 Continued

3.2.5 Receive > 125 point for trade show

255

256

Chapter 7

Review Questions 1. List at least two reasons why you should plan communication in 2. 3. 4. 5. 6. 7.

advance. What list can you use as a basis of who should have project communication? What are the two ways to think through when communication happens? The communication template includes a column labeled Why. How is this column used? The communication template includes a column labeled What. How is this column used? The communication template includes a column labeled How. How is this column used? What types of questions should you ask yourself when you analyze the communication needs of an individual?

8 Risk—What Should You Worry About? Creative risk taking is essential to success in any goal where the stakes are high.Thoughtless risks are destructive, of course, but perhaps even more wasteful is thoughtless caution, which prompts inaction and promotes failure to seize opportunity. —Gary Ryan Blair

Topics Covered in This Chapter What Is Your Risk Strategy? Not All Risks Are Created Equal Response Planning Teaming Politics Summary Case Study It’s time to talk about an important subject that can make or break your project: risk. A lot of project managers talk about risk, but few do any thing about it. In this chapter, I spend some time laying out a methodology that is easy to use yet effective when you deal with risk. This chapter starts with a discussion of risk strategy. You will develop a risk strategy by asking questions such as “How will I deal with risks before they happen and while they are happening?” Then the discussion turns to effective methods of gathering risks. With a risk list created, you’ll then decide which risks you should plan to actually deal with—not all risks are created equal. You’ll learn to look at the risk list from the perspectives of probability, impact, and priority. You then will create a response strategy for all that you have determined warrant the level of effort. 257

258

Chapter 8

In the “Teaming”section, I talk about the project pessimist and how he or she can really help you effectively plan the risks of your project. I share with you the experience of a really good project manager to show how you can turn pessimism into a real project benefit. In the “Politics” section, the discussion revolves around covering your executives on project risks before they happen. You want to make sure that negative political situations don’t arise because your executives don’t know what can go wrong and what you are doing to protect the project. In the case study, you’ll watch Chris put together her communication plan. She’ll also lay out the rest of the planning activities that she needs to accomplish before she can baseline her project plan. She’ll also start her thinking regarding her risk strategy, which is where this chapter starts.

What Is Your Risk Strategy? As you start exploring the area of risks, it is best to lay out your strategy first. This whole subject of risk can be fraught with all sorts of planning land mines. You don’t want to find yourself in the middle of your project facing a major risk without knowing what to do. With a little up-front planning, you’ll know what can go wrong and what you’ll need to get done if things do go wrong. You must address several areas in your strategy: • • • •

What is your policy or your company’s policy concerning risks? What needs to be defined for the team to understand the strategy? Who is responsible for what regarding risks? What are the timings concerning risks?

Let’s start with the first area, your policy. To set your policy, you first must understand the nature of your project. Is this the first time your company has undertaken this type of project? Or is this a typical project? Depending on your answer, you might not need to spend a lot of time on risks. Of course, you will want to follow most of the process I lay out in this chapter if this is the first time your organization has taken on this type of project. You should also use this process if this is a high-stakes project—for example, your company might need to be first to market with a product. On the other hand, a company that routinely installs cell towers might need to cover only the

Risk—What Should You Worry About?

259

risks associated with the actual land where the cell tower is being installed. Be sure to set up your strategy with the rigor appropriate to the nature of your project. You will address the second area of risk in your strategy: what must be defined for your team to understand this strategy. You might need to define some terms in a risk glossary. With risk, as with other areas of your project, don’t assume that people understand what you are talking about. Try not to leave anything to the team’s imagination. For the third risk area, roles and responsibilities, you again must determine the rigor you will need. I’ve seen risk strategies assign a specific risk to an individual to watch for and then address if it happens. I’ve also seen project managers who have not assigned any risks to anyone on the team. Instead, the project manager just watches for risks and delegates as needed. The last area to cover in your risk strategy is the timings of risk. Here you might get clear about what risk activities will take place during what phases of your project. Again, determine the right level of rigor for your project. You might not even need to address timings if you are the project manager for that standard cell tower installation. That pretty much covers what you should include in your risk strategy. Of course, you might find other topics to address, based on your specific project and organization. It’s always better to overcover than undercover any area. You’ll find some information on other concepts in risk strategy, coming up shortly. Let’s apply the risk strategy to the training time reduction project. You begin to analyze the nature of the project and realize that this is a high-stakes project. You have agreed to deliver a very aggressive Measure of Performance; this amount of reduction is pretty aggressive. You also realize that the organization has never taken on a project like this. Based on those conclusions, you will put a lot of rigor into your strategy. You will address all the previously presented topics in your strategy. When you have completed your analysis, your policy will look like this:

TTR Project Risk Strategy The TTR project will address risks throughout the project. The project team will start by gathering risks during the planning phase of the project. We will determine the probability and impact for each risk. We will then prioritize each risk.

260

Chapter 8

A response plan will be created for the top 25 percent of the risk list. This response plan will also describe who is accountable for monitoring each risk. This person will also be accountable for implementing the response plan, if and when it is appropriate. New risks will be identified while the project is being executed. Each new risk will go through the exact same process after it is identified. Risks will be monitored and controlled throughout the life of the project. Glossary terms: Probability—The chance that a given event will occur Impact—The force of impression of one thing on another

Of course, you will place this strategy in your project plan after you have documented your policy. You will want to make sure that everyone on the project team will be able to read and understand it. Now let’s move on to risk identification.

Identifying Risk You probably started thinking about risk as soon as you began planning your project. Now, you might not have gone through a formal process in a team meeting of writing risks on a white board. But you have been worrying about certain things—you know, the items that keep you awake at night. That is the level of risk identification that you have already started. Now it’s time to start formalizing that process so you can do something about those risks. You start the process of risk identification by first defining what the word risk means to you and your project. The dictionary defines risk as a dangerous element or factor. You should define risk as anything that can keep you from meeting the triple constraints: on time, on budget, and meeting your MOP. And when I say “anything,” I mean anything. Remember you have a process to help you prioritize what you will take action on; you need to include everything possible on the list.

How Do You Gather Risks? Any way you can! Okay, actually, you should gather risks using formal as well as informal mechanisms. Gather them any way you can. And gather them

Risk—What Should You Worry About?

261

whenever they come up. The more you can identify risks and put them through the process covered in this chapter, the better your chance will be to successfully deliver to the triple constraints. This section starts your riskidentification process with a formal process: risk brainstorming. Formal Risk Gathering Risk brainstorming is great way to formally gather risks. In fact, this session can be an excellent team-building exercise. In a risk-brainstorming session, the entire team comes together to talk about what could possibly go wrong. Because of the nature of brainstorming, the team builds upon each other’s thoughts and usually constructs a very comprehensive list of potential risks. If fact, it allows each team member a chance to be heard. Here are some of the details concerning risk brainstorming: • Timing—You can begin to formally gather risks as soon as you have completed your risk policy statement. In fact, you can have a riskbrainstorming session at a set frequency all the way through the project. Different phases of work bring up different worries that you or the team might not have been thought about when the project was in the original planning phase. • Structure—A professional facilitator can best handle a riskbrainstorming session, if you can find one to use. If not, you, the project manager, become the facilitator. Be sure to set up some ground rules so that you are also able to participate. Use a room that has seating for everyone, with either a lot of white boards or flip chart easels that everyone can see. • Ground rules—Use a structured brainstorming format for risk identification. Make sure you explain the format and the ground rules to the team members. In this structured format, you go around the room and ask for ideas one person at a time. Any participant who has nothing to contribute should say “Pass.” No one is allowed to criticize, comment on, or question another person’s addition. You continue around the room until no one has any additional ideas. Be sure to hand off facilitation duties if you’re the project manager who is also acting as the facilitator: Hand the pen to someone else, have a seat, and provide your idea when it’s your turn to contribute. Then stand up and facilitate again after your idea has been recorded.

262

Chapter 8

You will probably get some pretty crazy and far-out risks during this session. Be sure to allow the team members to have some fun. Don’t stifle their creativity. Just let them get all their ideas out. The process will eventually weed out the risks that are too far fetched. When all ideas are covered, the facilitator should have the team members ask for clarification of any risks on the board that they do not understand. The participant who contributed the idea should explain it further, if necessary. The facilitator then should look for duplicate ideas. Both team members who contributed the ideas must agree that they are duplicates before you remove one of them. This last action should get you to a good list of risks that the team has built together. Place that set of risks on the master risk identification list, depicted in Figure 8.1. Number

Originator

Open Date

Risk Description

Probability

Impact

Respond?

Figure 8.1 Master risk identification list

Note that the master risk identification list provides a place to capture some significant information regarding new risks. You capture the person who originated or identified the risk and when it was originated. That way, you can always go back to the originator for more clarity, if needed. You should also get a good description of the risk. Two fields on this list, Probability and Impact, will be used later in your process. You will use the field labeled Respond? as an indication of whether this risk is strong enough for you to build a response strategy. I discuss that decision a little later in the process. Explain to the team what will happen with the items on the completed list. That way, the members understand the actions that will be taken and how

Risk—What Should You Worry About?

263

their ideas will be used. Again, use this session at a set frequency or whenever you think it is warranted to formally gather risks. Informal Risk Gathering I’ve seen really good project managers use other techniques to informally gather risks: • Status and risks—This method is used at every team meeting. The team members provide a status report on their activities for the week. Then the project manager ends the meeting with a discussion on risks. He asks the team members what new risks they have identified that week. Everyone contributes anything they can think of. The project manager records these risks on the master risk identification list. Everyone knows the process and what will happen to the risks they are bringing up. • Impromptu—In this risk-gathering technique, the project manager must be ready to capture risks whenever they come up. The project manager carries a risk identification form, depicted in Figure 8.2. Any time a team member discusses a subject that could entail a risk in normal conversation, the project manager brings out the form and says to the team member,“I think you’ve just identified a risk!” and then asks the person to quickly document the risk on the form provided. The project manager then gathers these forms and puts the risks on the master risk identification list, to be worked through the process. I’ve seen project managers carry these forms with them. They also leave these forms sitting on the team meeting table, as well as on desks, on the project intranet, and everywhere the team congregates physically or virtually. Another impromptu form of risk gathering is asking, whenever you think about it, every team member, your project sponsor, and yourself the simple question,“What are you worried about?”These are the items that are keeping people awake at night. Scan your master risk identification list when someone provides an answer, to see if the worry is already on the list. If not, add it. If those worries are on the list, you might find that they are important enough to warrant a response plan. If not, at least they have been analyzed; the person who brought the item up might sleep better because the worry has been addressed.

264

Chapter 8

ABC Project Impromptu Risks

Open Date:

Originator:

Description:

Comments/Status

Open Date:

Originator:

Description:

Comments/Status

Figure 8.2 Impromptu risk form

Let’s build a risk list now for the sample project, the training time reduction project. You’ve decided to use the formal brainstorming approach during the planning of the project. You will institute the impromptu approach for ongoing risk identification when you finish this planning. Remember that your risk list will be a living document that you will update constantly throughout the life of the project. Risks don’t go away just because you’ve finished your planning. Anyway, back to your master risk identification list. You have pulled your team members together and, through a structured brainstorming session, created the list shown in Figure 8.3. The list might contain only ten items at this time, but we’re sure it will continue to grow as the project progresses. As you look through the list, you’ll notice some very large risks, as well as a few items that are really questionable. Should you build a plan to address all these items? Unless you are building a space shuttle, probably not—it could take too many resources and too much time to address all these items. The pay-off might not be high enough to work on all the items on the list. That leads us to the next subject.

Originator

Open Date

Risk Description

1.

Course developer

10/1

There are five of us set up to do the work for this project, with no slack time. What happens if one of us gets sick?

2.

CSR supervisors

10/1

When the CSRs go through new training, there is always a spike in the time it takes to handle a customer while the new training is learned. Will this spike create customer complaints more than 2%?

3.

Reproduction facilities

10/1

We’ve been having problems with our paper supplier. We may not have enough paper on hand to create the textbooks in the time frame you want.

4.

Technologists

10/1

We have seen a new training system build by XYZ technologies that handles CSR transactions at lightening speed. If you choose to use the old system, you might not get processing that is fast enough to keep the customer complaints below 2%.

5.

Reproduction facilities

10/1

We are planning a remodeling project of our facilities during the time you are requesting the creation of the textbooks. We might not be able to meet the time frames you are requesting.

6.

Executive sponsor

10/1

Will the project be able to reduce the training time by the amount I’ve requested? I’m basing next year’s budget on this forecast.

7.

Course developers

10/1

We’ve been investigating a new course-development methodology. We’d like to use for the first time on this project.

8.

Graphic artist

10/1

I’m pregnant and due right after the first class is scheduled.

9.

CSR supervisors 10/1

None of our full-time employees has expressed an interest in being part of the pilot team.

10.

CSR supervisors 10/1

We’d like to videotape the course and be able to use it later for refresher training for the students.

Impact

Respond?

265

Figure 8.3 Master TTR risk identification list

Probability

Risk—What Should You Worry About?

Number

266

Chapter 8

Not All Risks Are Created Equal You learned in the last section that when you gather risks, you can end up with an entire gamut of risks. Some risks are very dangerous and should be mitigated. Others are a simple item that only one person is mildly worried about. Others fall into a gray area, where it might not be clear how to react. So how do you decide which risks you should really do something about? You use two methods to determine the risks for which you should take the time to build a response plan. These two methods are impact and probability.

Impact First you should determine impact. The definition of impact is the extent of damage that can be done to your project if the risk actually happens. You will need to do some creative thinking to determine impact. Basically, you are trying to determine what could really go wrong and what that would do to your project. You’ll need to take a couple steps: 1. Imagine the risk happening. 2. Imagine what would happen to your triple constraints (MOP, time, and

cost) because of this risk happening. 3. On a scale of 1 to 5, with 5 being the highest impact to your project, determine what number rating you would give the impact of this risk. Of course, your imagination is only so good. Problems could arise with what you come up with. But a slightly faulty plan is better than no plan. Going through these steps should help you determine an impact rating for each risk. Let’s put one of your risks from the TTR project through these steps. Use number 5 from Figure 8.3, the one concerning the remodeling of your facilities. First, do some imagining about the risk happening. You drive up to the vendor you usually use and get out of your car. You don’t see any other cars in the lot, which makes you a little nervous. You head to the front door

Risk—What Should You Worry About?

267

before you gather the course material, just in case there is a problem. On the door, you see a sign that reads “Closed until Tuesday for remodeling.” In a panic, you get back in the car and call your procurement office. Okay, now let’s move on to step two. You realize that you can take the course material to another company on the procurement list. It might cost you a little more, but time is of the essence. Quickly you rummage through your brain to remember the total budget figure for the project. You also remember the amount of slack that you provided in the budget for situations just like this. It sounds like you can absorb a minor overrun with this risk. Now moving to step 3, you decide that the impact rating for this risk should probably be a 2: You can make up the time and absorb a cost overrun in your project. This process is nice and straightforward. It can even be fun doing this imagining with your team. You’ll be surprised at what outlandish imaging a project team can come up with! Now that you’ve determined the impact, let’s discuss probability.

Probability As you continue to determine whether to act on a risk, you now turn to the probability of the risk happening. Probability is the chance that a given event will occur. You must look at both what damage a risk will provide (impact) as well as how likely it is that the risk will happen (probability). You also need to do some creative thinking to determine probability. Basically, you try to determine how possible it is that the risk will actually happen. You need to take a couple steps: 1. Look at your project plan and schedule. 2. Based on the current plan, ask yourself how possible it is that this risk

will actually happen. 3. On a scale of 1 to 5, with 5 being the most probable, determine what number rating would you give the probability of this risk.

268

Chapter 8

Let’s go back to risk number 5 on the TTR project, about the reproduction facilities doing their remodeling at the time you need your training materials reproduced. When you look at your project plan and the schedule you have created, you realize that your team is right. You will need to use the reproduction facility at exactly the same time that they are remodeling. After talking to the facility, though, you find that they are not expecting a complete shutdown. They believe that, in the worst-case scenario, some jobs might be a little late. You still give it a probability rating of 5 even though the facility doesn’t think this is a risk. You are very sure that this risk event will happen. Let’s go back through the rest of your risks on the master risk list and determine the impact and probability for each of the risks on your list. You can see the ratings for all the risks in Figure 8.4. You can see from this list that you really do have risks that are all over the board. A couple things that people considered a risk are those that you have built the project to achieve (such as number 6). Needless to say, they are high in impact yet low in probability because the entire project has been structured to achieve that outcome. The whole project is about mitigating that risk. Number 4 is another interesting risk that is high on impact and low on probability. You are not planning any changes to the computer system that runs the customer service rep software. The technologists are worried that you need new hardware to keep the customer complaints less than 2 percent. You work with the technologists and verify the current transaction time, and you have determined that there is not a good probability that this risk will occur. In fact, you are wondering why they thought this was a risk in the first place. Perhaps they’d like to buy new hardware? You’ll find that people have different motives and different worries when it comes to risk. What you think is a simple issue might be really upsetting one of your team members. Getting everything on the risk list and then working through the process helps allay your team members’ fears. It also helps you get to the bottom of what you should be concerned about.

Originator

Open Date

Risk Description

Probability

Impact

1.

Course developer

10/1

There are five of us set up to do the work for this project with no slack time. What happens if one of us gets sick?

3

5

2.

CSR supervisors

10/1

When the CSRs go through new training, there is always a spike in the time it takes to handle a customer while the new training is learned. Will this spike create customer complaints more than 2%?

4

5

3.

Reproduction facilities

10/1

We’ve been having problems with our paper supplier. We might not have enough paper on hand to create the textbooks in the time frame you want.

2

2

4.

Technologists

10/1

We have seen a new training system build by XYZ technologies that handles CSR transactions at lightening speed. If you choose to use the old system, you might not get processing that is fast enough to keep the customer complaints below 2%.

1

5

5.

Reproduction facilities

10/1

We are planning a remodeling project of our facilities during the time you are requesting the creation of the textbooks. We might not be able to meet the time frames you are requesting.

5

2

6.

Executive sponsor

10/1

Will the project be able to reduce the training time by the amount I’ve requested? I’m basing next year’s budget on this forecast.

1

5

7.

Course developers

10/1

We’ve been investigating a new course-development methodology. We’d like to use it for the first time on this project.

1

3

8.

Graphic artist

10/1

I’m pregnant and due right after the first class is scheduled.

4

1

9.

CSR supervisors

10/1

None of our full-time employees has expressed an interest in being part of the pilot team.

3

2

10.

CSR supervisors

10/1

We’d like to videotape the course and be able to use it later for refresher training for the students.

1

1

269

Figure 8.4 Master TTR risk identification list with impact and probability

Respond?

Risk—What Should You Worry About?

Number

270

Chapter 8

Now you have determined impact and probability; you need to determine which risks you will work on. You do that by adding up the probability and impact numbers you’ve generated. Then go back to your policy statement. What was the threshold of risks that you determined you would respond to? You stated in your policy statement that you would respond to the top 25 percent of your risk identification list. With that knowledge and the calculated probability and impact numbers, you now know that you will respond to risk numbers 1, 2, and 5. You will put a Yes in the Respond column of your master risk identification list, shown in Figure 8.5. You might think you are finished with the master risk identification list. Actually, your work with this list has just started. This is a living document that you continually update with risks as they become known. Use your impromptu method of gathering risks throughout the project. Determine impact and probability for each. Also continue to monitor the existing risks on your list to see if the impact and probability change as the project progresses. You will add new risks or make changes to existing risks; if they fall into the top 25 percent, you move them through the next step of the process: determining the response.

Originator

Open Date

Risk Description

Probability

Impact

Respond?

1.

Course developer

10/1

There are five of us set up to do the work for this project with no slack time. What happens if one of us gets sick?

3

5

Yes

2.

CSR supervisors

10/1

When the CSRs go through new training, there is always a spike in the time it takes to handle a customer while the new training is learned. Will this spike create customer complaints more than 2%?

4

5

Yes

3.

Reproduction facilities

10/1

We’ve been having problems with our paper supplier. We might not have enough paper on hand to create the textbooks in the time frame you want.

2

2

4.

Technologists

10/1

We have seen a new training system build by XYZ technologies that handles CSR transactions at lightening speed. If you choose to use the old system, you might not get processing that is fast enough to keep the customer complaints below 2%.

1

5

5.

Reproduction facilities

10/1

We are planning a remodeling project of our facilities during the time you are requesting the creation of the textbooks. We might not be able to meet the time frames you are requesting.

5

2

6.

Executive sponsor

10/1

Will the project be able to reduce the training time by the amount I’ve requested? I’m basing next year’s budget on this forecast.

1

5

7.

Course developers

10/1

We’ve been investigating a new course-development methodology. We’d like to use it for the first time on this project.

1

3

8.

Graphic artist

10/1

I’m pregnant and due right after the first class is scheduled.

4

1

None of our full-time employees has expressed an interest in being part of the pilot team.

3

2

1

1

9. 10.

CSR supervisors

10/1

CSR supervisors

10/1

We’d like to videotape the course and be able to use it later for refresher training for the students.

271

Figure 8.5 Master TTR risk identification list with top 25 percent

Yes

Risk—What Should You Worry About?

Number

272

Chapter 8

Response Planning The next step in the process is determining the response plan for each of your top 25 percent risks. You first must determine what your response strategies should be. Then you must decide which of these strategies are the most appropriate response to use on each of your top 25 percent risks. The last step in this part of your process is actually working the plan that you have established. Let’s start, then, with risk-response strategies. You can use four strategies when deciding how to respond to the risks on your project: avoid, transfer, mitigate, and accept. Consider these definitions: 1. Avoid—Early in your project, you have the opportunity to identify a

risk and then build a strategy to actually dodge the impacts of the risk. In this strategy, you use your planning activities to prevent the risk from occurring. When you use this strategy, you actually create new tasks for your project schedule and update your project plan with these new activities. 2. Transfer—When you use the risk-response strategy of transfer, you give the risk to another party to deal with. Sometimes you have to pay to transfer the risk. You might need to do this via a contract. Other methods used to transfer a risk can include purchasing insurance, a warranty, or possibly some type of guarantee. 3. Mitigate—This risk strategy is a way to soften the potential problems that a risk might cause in your project. Your analysis has stated that the risk is likely to occur. With this strategy, you look for ways to lessen the degree of impact and the degree of probability of occurrence. You also create new tasks for your project schedule and update your project plan with these new activities. 4. Accept—As the word implies, you accept that the risk exists and decide not to do anything about it. This seems very passive, but it actually is a good strategy to use for certain risks. Right now you have eight risks on your list for which you are using the acceptance

Risk—What Should You Worry About?

273

response strategy. You have determined that their impact and probability are too low to warrant any action. Of course, that could change in the future, so you continue to review and monitor these risks throughout the life of the project. With the four strategies defined, you go through your risk list and determine the appropriate strategy for each of your top 25 percent risks. Then with the strategy determined, you decide what steps you will take to respond to the risk. Let’s run through the process with the top three risks from the TTR project. The first risk is this one: “There are five of us (course developers) set up to do the work for this project, with no slack time. What happens if one of us gets sick?” You’ve determined that this risk has a combined probability and impact of 8. You need to do something about this situation. Even if the course developers stay healthy, what happens if one of them starts running behind schedule? How will you get caught up? You’re assuming that the work of the course developers is on the critical path, a concept covered in Chapter 9,“Creating the Schedule.” Even if their activities are not on the critical path, you know they are critical for the successful completion of the project. With that information, you’ve decided to mitigate this risk. You will search for and find a contract course developer. You will be ready to hire this contract course developer if the risk begins to happen. This contract course developer can work alongside the other course developers and will be available to help if one of the course developers gets sick or starts running behind schedule. In fact, you probably need to see if you can find a contract course developer who also can do graphic work. That would also help mitigate the risk of the pregnant graphic artist going on maternity leave early. This is the second risk of the top 25 percent: “When the CSRs go through new training, there is always a spike in the time it takes to handle a customer while the new training is learned. Will this spike create customer complaints more than 2 percent?” This risk was the highest rated for impact and probability on the list of risks. You need to take this one seriously and create a

274

Chapter 8

good response. You can’t afford to allow the customer complaints to rise above 2 percent, or you’ll miss your MOP. The data that the CSR supervisors collect shows that most people complain when they have a long wait time. To respond to this risk, you decide to work with the CSR supervisors to understand the calling trends of your customers. You need to understand exactly when you might have problems with wait times. Upon completion, you understand that Mondays are your worst day, when most of the complaints occur. These complaints happen when a customer has to hold for 15 seconds or more. In the past, the CSR supervisors have used an outsourced call center to handle their call overflow during the busy season. You decide to transfer this risk to the outsourced call center because the organization is already in place. You will set up your telephone system to transfer calls to the outsourced call center after the customer has been waiting 25 seconds. With this transferred risk, you will have a guarantee from the outsourced call center to handle any call within 5 seconds of delivery. Customers who are transferred and who later complain will not be part of your office’s complaint statistics. You will leave this agreement in place for the first six months of the new training, or until you know that you are satisfactorily under the 2 percent threshold. This will again impact your budget, which is discussed in Chapter 10,“Budgeting—How Much?” The last of the top 25 percent risks is number 5: “We are planning a remodeling project of our facilities during the time you are requesting the creation of the textbooks. We might not be able to meet the time frames you are requesting.” This risk was rated a 7 on the impact and probability scale. You’ve decided to use the avoid strategy with this risk. You don’t even need to deal with the possibility of this risk happening because you have a list of other vendors that you can use for your reproduction needs. You just need to test another of your vendors to verify the quality of the materials before you use them to create your first course. You have now completed the last risk of your top 25 percent. You update your master risk identification list, depicted in Figure 8.6.

Originator

Open Date

Risk Description

Probability

Impact

Respond?

1.

Course developer

10/1

There are five of us set up to do the work for this project with no slack time. What happens if one of us gets sick?

3

5

Mitigate—Be ready to hire a contract course developer to work with the other course developers. See if it’s possible to find someone with graphic skills, too.

2.

CSR supervisors

10/1

When the CSRs go through new training, there is always a spike in the time it takes to handle a customer while the new training is learned. Will this spike create customer complaints more than 2%?

4

5

Transfer—Develop an agreement with the outsourced call center for overflow calls on Mondays for 6 months.

3.

Reproduction facilities

10/1

We’ve been having problems with our paper supplier. We might not have enough paper on hand to create the textbooks in the time frame you want.

2

2

4.

Technologists

10/1

We have seen a new training system build by XYZ technologies that handles CSR transactions at lightening speed. If you choose to use the old system, you might not get processing that is fast enough to keep the customer complaints below 2%.

1

5

5.

Reproduction facilities

10/1

We are planning a remodeling project of our facilities during the time you are requesting the creation of the textbooks. We might not be able to meet the time frames you are requesting.

5

2

6.

Executive sponsor

10/1

Will the project be able to reduce the training time by the amount I’ve requested? I’m basing next year’s budget on this forecast.

1

5

7.

Course developers

10/1

We’ve been investigating a new coursedevelopment methodology. We’d like to use it for the first time on this project.

1

3

8.

Graphic artist

10/1

I’m pregnant and due right after the first class is scheduled.

4

1

9.

CSR supervisors

10/1

None of our full-time employees has expressed an interest in being part of the pilot team.

3

2

10.

CSR supervisors

10/1

We’d like to videotape the course and be able to use it later for refresher training for the students.

1

1

Mitigate—Hire a contract course developer with graphic skills.

275

Figure 8.6 Master TTR risk identification list with response plans

Avoid—Find another reproduction vendor. Be sure to test their quality of work.

Risk—What Should You Worry About?

Number

276

Chapter 8

Getting Ready for Risks to Occur You have built the response plan for your top 25 percent risks. Now you will add two more steps to your process when you are really serious about dealing with risks. In the first step, you assign a risk owner to each of your top 25 percent of risks. In the second, you determine an appropriate alarm for each risk. • Risk owner—You have built a response plan for each of your risks. You also want to create a risk owner for your top 25 percent of risks on your response plan. A risk owner provides accountability for the execution of the response strategy. With someone accountable, you have a better chance that the strategy will really be put in place and be executed well. Look to assign a member of your team who will be involved in the activities that surround the risk. You assign TTR risk 1 to your lead course developer. That lead will procure a contract course developer and also work with the contract course developer to make sure he or she is up-to-speed. • Alarms—Another strategy that you can use when dealing with risks is the strategy of an alarm. An alarm is sounded whenever the risk begins to occur. An alarm is placed only on risks that you have chosen to mitigate. With the avoid and transfer response strategies, you have decided to get rid of the risk as much as possible. With a mitigate risk-response strategy, you’ve decided to only soften the possibility of harm or occurrence. These risks might still happen. To effectively deal with the risks you’ve decided to mitigate, it is best to set up an alarm. An alarm describes what the risk looks like when it actually starts to happen. This triggering event tells the risk owner that it is time to act. The riskresponse plan must be put into place immediately to keep the risk from having a major impact on the project. In the case of the TTR project, you set up risk 1 as a risk to mitigate. The appropriate alarm for this risk will be any slippage in the course developer’s schedule. You know that the project manager will monitor the schedule every week. If the alarm starts to sound, the lead course developer will immediately hire the contract course developer and put the risk-response plan in place. You now update your master risk identification list with the risk owner and the alarm. You can see what this looks like in Figure 8.7.

Originator

Open Date

Risk Description

Probability

Impact

Respond?

1.

Course developer

10/1

There are five of us set up to do the work for this project with no slack time. What happens if one of us gets sick?

3

5

Mitigate—Be ready to hire a contract course developer to work with the other course developers. See if it’s possible to find someone with graphic skills, too. Owner: Lead course developer Alarm: Any course development schedule slippage.

2.

CSR supervisors

10/1

When the CSRs go through new training, there is always a spike in the time it takes to handle a customer while the new training is learned. Will this spike create customer complaints more than 2%?

4

5

Transfer—Develop an agreement with the outsourced call center for overflow calls on Mondays for 6 months. Owner: Lead CSR supervisor.

3.

Reproduction facilities

10/1

We’ve been having problems with our paper supplier. We might not have enough paper on hand to create the textbooks in the time frame you want.

2

2

4.

Technologists

10/1

We have seen a new training system build by XYZ technologies that handles CSR transactions at lightening speed. If you choose to use the old system, you might not get processing that is fast enough to keep the customer complaints below 2%.

1

5

Figure 8.7 Master TTR risk identification list with risk owners and alarms

Risk—What Should You Worry About?

Number

277

278

Originator

Open Date

Risk Description

Probability

Impact

Respond?

5.

Reproduction facilities

10/1

We are planning a remodeling project of our facilities during the time you are requesting the creation of the textbooks. We might not be able to meet the time frames you are requesting.

5

2

Avoid—Find another reproduction vendor. Be sure to test their quality of work. Owner: Lead course developer.

6.

Executive sponsor

10/1

Will the project be able to reduce the training time by the amount I’ve requested? I’m basing next year’s budget on this forecast.

1

5

7.

Course developers

10/1

We’ve been investigating a new coursedevelopment methodology. We’d like to use it for the first time on this project.

1

3

8.

Graphic artist

10/1

I’m pregnant and due right after the first class is scheduled.

4

1

9.

CSR supervisors

10/1

None of our full-time employees has expressed an interest in being part of the pilot team.

3

2

10.

CSR supervisors

10/1

We’d like to videotape the course and be able to use it later for refresher training for the students.

1

1

Figure 8.7 Continued

Mitigate—Hire a contract course developer with graphic skills. Owner: Lead course developer.

Chapter 8

Number

Risk—What Should You Worry About?

279

You also now insert your master risk identification list into your project plan. Both the project plan and the master risk identification list are living documents that you consistently update while you work on the project. Always combine your documents with the project plan, to keep the project plan current. You want to be able to hand the project plan to a new team member at any point in time, to bring someone new up to speed regarding the entire project by just reading and comprehending the project plan. You have completed your risk response plan and are now ready to work on the risks of the project while you execute the project. I talk about that later, in Chapter 12,“Keeping the Project on Track.” Now you are ready to move into the “Teaming” section to learn about the project pessimist and risk management.

Teaming A project management friend of mine related a story to me that has stayed with me as a lesson learned about how to handle a difficult team member and deal with risks at the same time. Pat was the project manager for a very complex project that involved multiple departments and a huge project team, as well as a huge budget. Pat had heard all about a team member, Jean, before she started the project. Jean was known around the organization as a grump. She didn’t like anything about the projects she worked on. She always found problems. And she was constantly talking about what was going to go wrong. She made it a habit to seek out her fellow team members to chat. In that chat, she received a lot of information. She also distributed a lot of information, and a lot of it was negative. Jean was like a harbinger of gloom and doom. Pat told me later that she made the entire team feel pessimistic about the project and its possibility for success. Pat is probably one of the best project managers I know. She delivers projects within the triple constraints and also makes the project environment so pleasant that people beg to come work for her. People sense success and want to be part of a winning team. Jean’s pessimism was just the type of challenge that Pat loved to take on. Pat began her “fix the Jean problem” with the foregone conclusion that she would probably have to move Jean off the team at some point. But she decided to do some research first to see if she could find another solution. She started by informally interviewing her team members about Jean. The

280

Chapter 8

team members didn’t even know they were being interviewed about Jean. They just thought that Pat was stopping by to say hi! In the interviews, Pat learned that Jean was the conveyor of project information. She had a chat with every team member at least once a week. The team members actually liked talking to Jean because they found out such important things. They just wished she would stop with the gloom and doom. Pat realized from the interviews that she had a natural project communications manager in Jean, and she planned to use that skill. She then needed to figure out what she would do about the gloom and doom component of Pat’s behavior. Pat realized that you might not be able to change the person’s personality, but you might be able to channel that behavior into something more constructive. The next time Pat had a conversation with Jean, she listened closely to the doom and gloom part of the conversation. She realized in her listening that the doom and gloom was everything that Jean was worried about. It was also what other people of the project were worried about. Indeed, some of the worries were pretty far fetched, but still they were worries. She realized at that instant that these risks needed to be captured. She then went off to formulate her “fix the Jean problem” plan. Pat introduced a new way of gathering risks at the next all-team meeting. She introduced what I called earlier in this chapter the impromptu form of risk gathering. She handed out the impromptu forms to everyone on the team and let them know that more forms were available on the server. She explained the concept of capturing worries because they are really risks. She also offered a prize to the team member who captured the most risks that ended up in the top 25 percent list. The prize would be given at the end of the project. That single move turned all the doom and gloom that Jean was distributing into something positive. From that point on in the project, the team members looked forward to Jean’s chats because they knew they would get a mountain of information about what could go wrong on the project. Those chats were no longer seen as a negative experience, but as a positive experience. Other times a team member was chatting with Jean and she began telling the same old story of gloom and doom; the team member dismissed the old story (because they had already captured it as a risk) and prompted Jean for new information. Pat told me later that she had actually gotten reports that Jean was speechless at times because people kept prompting her for new information.

Risk—What Should You Worry About?

281

As part of her plan, Pat also put some special handling information on the project communication plan. She made sure that Jean received as much project communication as she could handle. Jean was a natural communicator, so Pat knew she was another method of communication that the project could exploit. Pat was able to use a very pessimistic team member to the benefit of the project. She realized that she could not change Jean’s behavior and that she instead had to use it for a benefit. Overall, this was a win-win situation for the project and for Pat and Jean. By the way, Jean was not the winner of the most documented impromptu risks that hit the top 25 percent list. She never did figure out that her doom and gloom was actually project worries and risks that could be managed. And she never did change her pessimistic ways. I’ve since used this impromptu technique on all of my projects, even when I don’t have a Jean on the team. It builds the team to a common goal of meeting the project’s triple constraints and gets input from all on what can hurt the project. Speaking of what can hurt the project, how do you handle setting the stage with the project executives for what might go wrong with the project? I cover that next.

Politics Have you ever had a risk review with your executives? Chances are good that you probably said “No” to this question. Few project managers conduct this type of meeting with their executives. Frankly, the executives probably don’t have time to just sit and discuss project risks. But shouldn’t you prepare your executives for the things that could go wrong? Yes, you should! I’ve said before that, when dealing with politics, a good offense is the best defense. Laying the groundwork for what can go wrong is one of those key strategies that you use to deal with project politics. You might not schedule a meeting to just discuss risks with your executives, but you can get out the information in other ways. Here are but a few: • Use status reports—You might not think of a status report as a communication vehicle for risks, but you can definitely use it as one. Take a look at Figure 8.8.

Chapter 8

Acme Corp Training Time Reduction Project status Report Status Date: November 11

600

Budget Variance

500

Costs

282

Planned Value Schedule Variance

400 300 200 100 0 Today Date/Time

Status by Deliverable: Deliverable Due Date Create approach September 1 document Design the class Create class modules

November 1 February 1

Status C Y Y

Notes Completed on schedule Deviation due to illness of Lead designer. In jeopardy due to design running late

Issues for Leadership Attention: 1. IT has not signed off on the TTR Approach document. A separate meeting will be held to gather signoff. Risks for Leadership Attention: Risk: Course development staff is completely utilized on this project. There is no slack time in the schedule if anyone is unavailable. Response: Hire a contract course developer to fill if any issues arise. Status: Mitigation plan now being invoked due to illness of course developer lead

C = Completed G = All budget/milestones on target Y = Minor deviations at clients’ request R = Major deviations to budget/milestones

Figure 8.8 TTR status report

On this Status report, you are conveying the most important information that you want your executives to know. It covers the current view

Risk—What Should You Worry About?

283

of the schedule and the current view of the budget (I talk more about the current view and variance in Chapter 12). You also have covered issues that need management attention. Last but not least, you cover any risks that might need management attention. The key here is to put these risks on the status report before they happen. That way, your executives know about potential problems that might occur. Of course, you will always show what your response plan is; you don’t want your executives thinking that you don’t have a plan to cover problems. • Use executive briefings—Now, you might not be able to schedule an entire meeting to talk about risks, but you can probably get five minutes while you are talking to your executives about other project topics. Find a way to weave major risks that could harm your project into an executive meeting agenda. Try to establish a time once every couple weeks or months to get together with your executives to discuss the project. Always be sure to cover major risks. Remember, you have a “no surprises” rule for your executives, and you need to tell them what could go wrong. • Drop by—Once again, the “drop by” technique is an excellent way to keep your executive informed. With a quick “Do you have a minute?” drop-by, you can quickly inform the executive of problems and possibly imminent risks. The intent here is to make sure that negative politics don’t come your way because of project risks. Always make sure that the executives know what can go wrong and what you are doing about it in advance. You don’t want to have a major risk occur that requires a costly mitigation strategy, and the executive to not know anything about it until you are over budget. You also don’t want the gossip mongers to tell your executives about risks. You won’t have a chance to tell them how you have covered the risks and protected the project if they hear about risks as gossip.

Summary We opened this chapter with a discussion on risk strategy. We talked about how much risk should be applied to your project. The bottom-line concept is this: When your project stakes are high, you will want to apply more riskmanagement techniques to your project.

284

Chapter 8

We then spent some time on risk identification. We talked about the different formal and informal ways in which you can gather risks. Next we covered some techniques to help you decide which risks should be managed. We talked about the fact that not all risks are created equal, and we covered how to calculate probability and impact. We determined which risks required action. We then talked about the technique of building risk responses by determining exactly how each risk would be managed. Then we determined a risk owner and an alarm to make sure you understand when the risk actually starts to occur. In the “Teaming” section, we talked about how project pessimists can actually help the project manager build a comprehensive risk list. And in the “Politics” section, we discussed how to make sure that your executives know what can go wrong and what you are doing about it. Let’s find out now where Chris Williams is on the VNLE project. Has she completed the project communications plan, and how will she handle project risks?

Case Study On her way in to work on Friday, Chris remembered that she needed to get some messages to the executives. She had not talked to them in a while and suspected that they were wondering what was happening with the project. She also realized that she needed to get the communication plan done. The brainstorming that the team did yesterday would be a great help in getting that plan done. Chris also remembered that she still hadn’t done anything with the project risks. She knew she couldn’t finish the project plan until that was also completed. Whew! That’s still a lot to get done. Last night Chris had thought she could finalize the project plan today, but now it looked like she needed another couple days, if not a week, to get the rest of the activities done. With that last thought, she heard a siren behind her. Chris pulled over and was given a speeding ticket for doing 45 in a 35 mph zone. Evidently, as her mind raced, her foot got heavier on the gas pedal at the same time. Another lesson learned on this project: Don’t plan projects while driving! When Chris got to work, the first thing she did was sit down and jot down all the activities she needed to complete before she baselined the project plan:

Risk—What Should You Worry About?

285

1. Send a message to the executives. 2. Build the communication plan. 3. Create a risk strategy and a risk plan for the project. 4. Finish the project schedule and budget. 5. Baseline the project plan.

With the list made, she looked at the activities and decided that they were already in priority order. Time to get busy. Chris started with an e-mail to the executives, giving them the general status of what had been accomplished so far on the project. Her company uses e-mail more than any other medium for communication, so she decided that using e-mail for this status report was a safe bet. She also knew that she didn’t read everything in her e-mail every day, and chances were good that the executives were doing the same. She would not be able to use e-mail as the only communication means for the project. Chris sent the e-mail with a read receipt so she could see whether the executives even received the message. Having to think through the e-mail was actually a good starting point for building the communication plan. Chris also had the brainstorming from the team meeting earlier in the week and now had a good idea of what groups the project affected and who the challengers, influencers, and champions were. The core team, depicted in Figure 8.9, had identified the following key individuals: • Challengers: Sam McIntyre, Marketing, and Carlan Luber, Catalog Development • Influencers: Judy Warner, Logistics • Champion: June Thompson, CEO Chris added one more to the list: • Influencers: VNLE core team

286

Chapter 8

June Jackson CEO

Ken Hale CIO

John Robinson VP Business Development

Greg Peterson VP Sales

Carl Price VN Web Project Manager

Karen French Business Development

Bill Ricardo Sales

Karla Christie VP Marketing

Chris Williams Project Manager

Sue Kim OO

Robin Good Marketing

Tina Johnson Logistics

Carol Hinnant Catalog Development

Figure 8.9 VNLE core team

Chris knew she would need a comprehensive plan that spelled out the communication target, when communications would happen, why they wanted to communicate to the recipient, what the communication should be, and how the communication should happen. She worked until 4 p.m. creating the communication plan shown in Table 8.1. Table 8.1 VNLE Communication Plan Who

When

Why

What

How

Project sponsor/ customer

All phases

Want them to know we are on track.

Phase completed on time. All is well.

1. Regular monthly status report. 2. Face to face every two weeks.

287

Risk—What Should You Worry About?

Who

When

Why

What

How

All events

Major milestones are all on track.

Milestone completed. All is well.

1. VNLE newsetter, announcing milestone. E-mail.

All phases/ all events

Want them to know we are on track.

Phase completed on time. All is well.

1. VNLE newsletter on status. E-mail.

Event Staff Salespeople

2. Meet two months before trade show face to face to provide status, answer questions. Business Development

All phases/ all events

Want them to know what’s happening so they are ready to go with trade show.

Milestone completed. All is well.

1. VNLE newsletter, announcing milestone. E-mail. 2. Meet two months before trade show face to face to provide status, answer questions.

Executives VP of Sales VP of Marketing CIO COO

All phases

Want them to know we are on track.

Phase completed on time. All is well.

1. VNLE newsletter on status. E-mail.

All events

Major milestones are all on track.

Milestone completed. All is well.

1. VNLE newsletter, announcing milestone. E-mail.

continued

288

Chapter 8

Table 8.1 VNLE Communication Plan Who

When

Why

What

How

Business Development

Construction

Want them to know we are on track.

Get ready. Trade show will be here soon. Verify work to be done at trade show.

1. VNLE newsletter on status. E-mail. 2. Meet two months before trade show face to face to provide status, answer questions. 3. Meet one month before trade show face to face to provide status and statistics, answer questions.

Design

Need to know.

Regular status.

1. VNLE newsletter on status. E-mail. 2. Weekly face to face.

Construction

Need to know.

Regular status.

1. VNLE newsletter on status. E-mail. 2. Weekly face to face.

Trade show

Need to know.

Regular status. Moving into the home stretch.

1. VNLE newsletter on status. E-mail. 2. Weekly face to face.

All events

Need to know.

Milestone completed. All is well

1. VNLE newsletter, announcing milestone. E-mail. 2. Weekly face to face.

Project Team Core team

Risk—What Should You Worry About?

289

Who

When

Why

What

How

All team members

All phases/ all events

Need to know.

Regular status.

1. VNLE newsletter, announcing milestone. E-mail. 2. Monthly face to face.

Challengers/ influencers

Construction

Need to know.

Regular status.

1. TTR newsletter on status. E-mail. 2. Weekly faceto-face drop-by. 3. Lunch once a month.

Chris decided that this communication plan was “good enough” for now and that she would run it past the core team at the next meeting on Monday. Oh, that reminded her; she still needed to send out the agenda for that meeting! At the meeting on Monday she would cover the new communication plan and discuss the risk strategy for the project. She also wanted to have a brainstorming session to begin risk identification. Chris knew she’d be spending the weekend building the risk strategy if she wanted to get all that done on Monday at the meeting. Ah, such is the life of a project manager! With that decision, Chris sent out the agenda for Monday.

Review Questions 1. What typical elements does a risk strategy cover? 2. What are the two ways to gather risks? 3. What are the two ways to gather risks informally? 4. What is the definition of risk impact? 5. What is the definition of risk probability? 6. Why do you build a threshold of risk to create a response? 7. What four strategies might you use when deciding how to respond to 8. 9. 10. 11.

the risks on your project? Describe the avoid risk response strategy. Describe the transfer risk response strategy. Describe the mitigate risk response strategy. Describe the accept risk response strategy.

This page intentionally left blank

9 Creating the Schedule A schedule defends from chaos and whim. —Annie Dillard

Topics Covered in This Chapter Pulling the Work Together Applying PERT Estimates Assigning and Leveling Resources Schedule Compression Understanding the Flow of the Work Teaming Politics Summary Case Study

This is probably one of the most fun areas of work when you are planning a project, where all your hard work in planning comes together to produce the end date of the project. This chapter starts by pulling the work together via the network diagram. You’ll then perform a couple calculations to determine the critical path for the project. You’ll then have a good idea of the end date of the project. You’ll find a lot of sound tools and techniques in this chapter. You might decide to skip or mechanize a few if you are running a small project that does not require a lot of rigor. Hold off on saying that the end date is good until you look at the major risks facing the project and use PERT estimates to apply just the right amount of padding to a few tasks on the critical path. Then you can name names and apply the real resource to each task. After that, you can make sure that you don’t have any resource over allocations

291

292

Chapter 9

and can level out any problem areas. The network diagram with the project schedule is then complete. At this point, you can see whether the project schedule fits what was originally requested. If it doesn’t, you can use duration compression techniques to shorten the length of the project. You finish the work of the project schedule with one more technique that helps the project manager and team understand the flow of the work: a summarized network diagram. In “Teaming,” I talk about getting commitment on the project work and moving the team through the stages of team development by doing project scheduling work together. Finally, in the “Politics” section, I talk about the setting the stage for success or possible problems. In the case study, you’ll watch Chris handle some conflict on her core team while the members brainstorm the risks of the project.

Pulling the Work Together Let’s do a quick refresher on what you have accomplished so far in your project planning: 1. You have created a Measure of Performance that spells out the busi2.

3.

4. 5.

6. 7. 8.

ness result that the project needs to satisfy. From that MOP, you created a preliminary scope statement and finally a scope statement that spells out what you will do to accomplish the MOP. From the scope statement, you created a work breakdown structure that organized your thoughts about the work to be done down to the work package level. You performed activity sequencing to determine what piece of work should precede another piece of work. You estimated each task on the network diagram to understand the duration of the task, the work effort for the task, and what role should perform the task. You added tasks to your network diagram to ensure the quality of the project. You created a project communication plan. You analyzed the risks associated with the project and added tasks to your network diagram for risk-mitigation activities.

Creating the Schedule

293

Now you need to move the network diagram to its completed state. It’s time to determine the end date for the project. You set the end date of the project by performing several pieces of analysis on the network diagram. You first use the critical path method to determine the early start and finish dates for the project. You analyze the resources’ usage on the critical path to make sure that you don’t have resource problems with the way the work will be accomplished. You apply an estimating technique to your critical path for tasks that have high risk associated with them. You then determine whether the end date that you are projecting will satisfy your stakeholders. Three methods can reduce the length of the project if the end date is not what the stakeholders have requested. Finally, you complete a diagram to help you understand the flow of the work for the project. You have a lot to get through in this chapter, so let’s get started by calculating the critical path.

Calculating Critical Path You need to create the critical path through your network diagram to determine the end date of your project. The critical path is the series of tasks that must be accomplished without delay to meet the end date of the project. These tasks have no float or slack time available. (Slack or float is defined as the total amount of time that a task can be delayed without delaying the project finish date.) Figure 9.1 shows an example. You can see in this simple network diagram that one path of the network diagram has two tasks to be completed: Task A and Task B. These two tasks have a total duration of ten days. The second path of the network diagram has one task: Task C, with a duration of seven days. If you work these paths of the network diagram in parallel as they are depicted, you have three days of slack (or float) available for the second path of the network diagram. This means that you can start Task C on the third day of work, and the project will still complete on time. This also means that the path with Task A and Task B is the critical path for this small project. Tasks A and B must be worked as they are projected to start and stop. If they don’t, they will delay the end of the project. Now, it seems easy enough to do this calculation, but when you are trying to do this type of calculating on a network diagram with many paths that spans several months, it’s much more difficult. You also need to know the early start and early finish, and late start and late finish for every task. That information will tell you exactly when a task absolutely must start and end.

294

Chapter 9

Calculating a critical path involves three sets of calculations: a forward pass, a backward pass, and the float calculation. Let’s examine the forward pass first.

Task A 5 days

Task B 5 days

Start

End

Task C 7 days

Figure 9.1 Simple network diagram

The Forward Pass A forward pass is the calculation to determine the early start and the early finish for the network diagram. The early start date is the earliest point in time when a task can be started. The early finish is the earliest point in time that a task could possibly finish. You calculate the early start and finish as follows: 1. Determine the earliest a task can start. This is the early start. 2. Add the duration to the early start to calculate the early finish. 3. Where you have more than one predecessor for a task, use the largest

early finish as the early start for the successor task. Consider another simple network diagram, in Figure 9.2, and do a forward pass. In Figure 9.2, you started with Task 1 and determined that the earliest that task can start is day 0. Always use day 0 as the starting point for the forward pass. You then added the duration of three days to the early start of 0 to get the early finish of day 3.

Creating the Schedule

ES 3

EF 6

EF 11

Task 3 5 days

Task 2 3 days ES 0

ES 6

EF 3

ES 13

Task 1 3 days

EF 17

Task 5 4 days ES 3

295

ES 17

EF 18 Task 6 1 day

EF 13

Task 4 10 days

Figure 9.2 Calculated forward pass

For Task 2, you determined that the earliest day the task could start is day 3 because that is the point when its predecessor task is completed. You added the duration of three days to the early start, to get an early finish of day 6. You continue doing calculations for Tasks 3 and 4. For Task 5, you must perform the third step of your forward pass calculation. You first look at the two predecessor tasks, Task 3 and Task 4. You determine that Task 4 has the latest early finish. Therefore, the earliest that Task 5 can start is day 13. You then finish your calculations for Tasks 5 and 6. Because Task 6 is the last task on your project, you realize that the earliest that this project can finish is day 18. The Backward Pass A backward pass is a calculation to determine the late start and the late finish for the network diagram. The late start date is the latest point in time when a task can be started. The late finish is the latest point in time that a task could possibly finish. You calculate the late start and finish as follows: 1. Determine the latest a task can start. This is the late finish. 2. Subtract the duration from the late finish to calculate the late start. 3. Where you have more than one predecessor for a task, use the smallest

late finish as the late start for the successor task.

296

Chapter 9

Let’s do a backward pass for your simple network diagram. Figure 9.3 show the results. ES 3

EF 6

ES 6

Task 2 3 days ES 0

EF 3

LS 5

EF 11

Task 3 5 days

LF 8

LS 8

LF 13

ES 13

Task 1 3 days

LS 0

EF 17

ES 17

Task 5 4 days

LF 3

ES 3

EF 13

LS 13

EF 18

Task 6 1 day

LF 17

LS 17

LF 18

Task 4 10 days

LS 3

LF 13

Figure 9.3 Calculated backward pass

You start at the end of the network diagram for the backward pass. You use the early finish for the project as your late finish. Then for Task 6, subtract the duration to create the late start of day 17. For Task 5, use the last start of day 17 as the latest possible time that Task 5 can finish. You subtract the duration of four days to get the last start of day 13. You continue your calculations for Tasks 4, 3, and 2. When you get back to Task 1, you need to determine the late finish. You use the smallest or earliest late start from the two predecessor tasks—in this case, day 3 from Task 4—as your late finish for Task 1. You subtract the duration of three days from the late finish to derive the late start of 0. A quick way to make sure that you have done your forward pass and backward pass correctly is to verify that the first task has an early start and late start of 0 and that the early finish and the late finish have the same value. Calculating Float The final step of calculating the critical path is to calculate the float that is available for each task. The tasks with zero float make up the critical path.

Creating the Schedule

297

You calculate the float by subtracting the early start from the late start or by subtracting the early finish from the late finish. The float for Tasks 1, 4, 5, and 6 in Figure 9.3 is zero. The float for Tasks 2 and 3 is two days. This calculation tells us three things: 1. The earliest that Task 2 can start is day 3. Task 3 must start by day 5, to

avoid impacting the end date of the project. If Task 2 starts on day 3, Task 3 must start no later than day 8, to avoid impacting the end date of the project. 2. The critical path for the project is Tasks 1, 4, 5, and 6 because the critical path is the path through the network diagram that has no float available, as shown in Figure 9.4. 3. The length of this project is 18 days. ES 3

EF 6

ES 6

Task 2 3 days ES 0

EF 3

LS 5

EF 11 Task 3 5 days

LF 8

LS 8

LF 13

ES 13

ES 17

Task 5 4 days

Task 1 3 days LS 0

EF 17

LF 3

ES 3

EF 13

LS 13

EF 18

Task 6 1 day LF 17

LS 17

LF 18

Task 4 10 days

LS 3

LF 13

Figure 9.4 Simple network diagram critical path

If you look at the path created by Tasks 1, 2, 3, 5, and 6, you have what is called the “near critical”path. You must keep an eye on this set of work when you are managing project execution. That path of the network diagram will become the critical path if you have a slippage of two days for Tasks 2 and 3. Yes, you can have more than one path that is critical. Managing the work and slippage gets more coverage in Chapter 12,“Keeping the Project on Track.”

298

Chapter 9

Calculating Critical Path for the TTR Project Next, calculate the critical path for the TTR project. You can see the results of this calculation in Figure 9.5.

1.1 Interview CSR supervisors 2 days

1.2 Determine current customer complaints 2 days

2.3 Create learning objectives 2 days

1.4 Create current state document 3 days

2.4 Determine whether to use a new technology 3 days

2.1 Create approach document 5 days

3.5 Design the class 5 days

3.15 Verify the timings 2 days

3.16 Process analysis 2 days

Start 1.3 Determine current training time 2 days

2.2 Determine whether to rewrite or start over 2 days

1.5 Investigate what is currently trained 2 days

1.6 Create product Requirements 10 days

1.7 Signoff requirements 1 day

Figure 9.5 TTR critical path

You might think some of the results of these calculations are new and surprising. But your instincts probably already told you that the critical path would entail determining the product requirements, creating the approach document, designing the class, developing the first module for class, conducting the pilot class, revising materials, training the trainers, and conducting the first class. Table 9.1 shows precisely which tasks with no float comprise the critical path.

299

Creating the Schedule

3.12.1 Create class module 1 36 days

3.12.2 Create class module 2 35 days

3.12.3 Create class module 3 35 days 3.17 Verify timings 2 days

3.6 Create job aids 5 days

3.13 Create pilot textbooks 5 days

3.9 Conduct pilot class 25 days

3.12.4 Create class module 4 35 days

3.18 Monitor for customer complaints 30 days

3.10 Verify learning objectives are met 1 day 3.12.5 Create class module 5 35 days

3.8 Verify the training class is 50% less 1 day

3.12.6 Create class module 6 35 days

3.2 Time the pilot class 25 days

3.12.7 Create class module 7 35 days

3.12.8 Create class module 8 35 days

3.14 Revise material after the pilot 7 days

3.7 Adjust the class to 50 % less 5 days

3.11 Create textbooks 5 days

3.4 Train the trainer 15 days

Figure 9.5 Continued

3.1 Conduct first class 25 days

3.3 Verify customer complaints are < 2% 30 days

End

300

Chapter 9

Table 9.1 TTR critical path calculations

Task

Early Start

Late Start

Early Finish

Late Finish

Float

1.1 Interview CSR supervisors

0

3

2

5

2

1.2 Determine current customer complaints

0

3

2

5

2

1.3 Determine current training time

0

3

2

5

2

1.5 Investigate what is currently trained

0

3

2

5

2

1.4 Create current state document

2

5

5

8

3

2.3 Create leaning objectives

5

9

7

11

2

2.4 Determine whether to use a new technology

5

8

8

11

3

2.2 Determine whether to rewrite or start over

5

9

7

11

2

1.6 Create product requirements

0

0

10

10

0

1.7 Sign off on requirements

10

10

11

11

0

2.1 Create approach document

11

11

16

16

0

3.5 Design the class

16

16

21

21

0

3.15 Verify the timings

21

21

23

23

0

3.16 Process analysis

23

23

25

25

0

3.12.1 Create class module 1

25

25

61

61

0

3.12.2 Create class module 2

25

26

60

61

1

3.12.3 Create class module 3

25

26

60

61

1

3.12.4 Create class module 4

25

26

60

61

1

3.12.5 Create class module 5

25

26

60

61

1

3.12.6 Create class module 6

25

26

60

61

1

3.12.7 Create class module 7

25

26

60

61

1

3.12.8 Create class module 8

25

26

60

61

1

301

Creating the Schedule

Task

Early Start

Late Start

Early Finish

Late Finish

Float

3.17 Verify the timings

61

61

63

63

0

3.6 Create job aids

63

63

68

68

0

3.13 Create pilot textbooks

68

68

73

73

0

3.9 Conduct pilot class

73

73

98

98

0

3.10 Verify that learning objectives have been met

73

97

74

98

24

3.8 Verify that the training class is 50% less

73

97

74

98

24

3.2 Time the pilot class

73

73

98

98

0

3.18 Monitor for customer complaints

98

98

128

128

0

3.14 Revise material after the pilot

128

128

135

135

0

3.11 Create the textbooks

135

145

140

150

5

3.7 Adjust the class to 50% less

128

130

133

135

2

3.4 Train the trainer

135

135

150

150

0

3.1 Conduct first class

150

150

175

175

0

3.3 Verify that customer complaints are < 2%

175

175

205

205

0

Look back at Figure 9.5. Were you surprised that Task 3.4,“Train the trainer,” ended up being on the critical path? Look closely at the arrows though and how the predecessors flow; you’ll see that the predecessor tasks to Task 3.4 are Task 3.14,“Revise material after the pilot,” and Task 3.7,“Adjust the class to 50 percent less.” These predecessors are the types of things you should study closely as you do critical path calculations on your own project. Critical Path in MS Project If you think these calculations are difficult and time consuming, you should know that most software tools calculate critical path automatically for you. For more information on how Microsoft Project handles critical path, see Chapter 5 and Chapter 9 of Microsoft Project for Mere Mortals, by Patti Jansen.

302

Chapter 9

You have completed the critical path and now know that you tentatively can complete the project in 205 days. However, you should perform a few more analysis techniques to complete your network diagram before you can say that is a firm number. The first technique is applying PERT estimating.

Applying PERT Estimates In Chapter 5,“The Art of Estimating,” you encountered an estimating technique called PERT. Browse Chapter 5 again if you need a quick refresher on PERT estimates; I’ve covered the basics here, though. Remember that PERT is like the three-point estimating technique, but instead of using an average to calculate the new estimate, it uses expected values or weighted averages to perform the calculation. You use the three estimates to do a calculation to determine the estimate. Next, you determine the standard deviation. Last, you add the estimate to as many standard deviations as you need to provide the confidence you are looking for. You can use PERT to provide more confidence to estimates that could be shaky. Remember also that PERT estimates can apply to every task on your project. Some of the best project managers I know apply PERT estimates only to the tasks on the critical path that are the most risk prone. That is how you will apply PERT to your project in this book. This is the best point in time to apply PERT estimates to your project schedule because you understand the critical path of the project. Here is also where you have done some risk analysis and understand the critical path tasks that are the most risk prone. First, take a look at your master risk identification list. Identify the top 25 percent again. Then determine whether any of those top 25 percent risks are related to tasks on the critical path. Look back at an excerpt from your master risk identification list from the last chapter, shown in Figure 9.6. This is the highest risk that you had prioritized when you did your response planning. You look at your critical path in Figure 9.5 and realize that this risk is indeed related to your critical path Task 3.12,“Create class module 1.”You decide to apply the PERT estimating technique to it because this task meets both of your criteria of being on the critical path and being high risk. You first create three-point estimates for this task.You had already decided that 36 days was a good estimate. Use that as your most likely estimate. After thinking about what could go right and wrong,you determine that 45 days is a good pessimistic estimate and 31 days is the appropriate optimistic estimate.

Creating the Schedule

Number

Originator

Open Date

Risk Description

1.

Course developer

10/01/06

There are five of us set up to do the work for this project with no slack time. What happens if one of us gets sick?

Probability 3

Impact 5

303

Respond? Mitigate—Be ready to hire a contract course developer to work with the other course developers. See if possible to find someone with graphic skills too.

Figure 9.6 Master risk identification excerpt

Next you determine the estimate for the task. The formula for this calculation is as follows: Estimate = (Optimistic + [4 × Most Likely] + Pessimistic) / 6 Estimate = (31 + [4 × 36] + 45 / 6 Estimate = 36.7

Next you determine the standard deviation for the task. The formula for this calculation is as follows: Standard deviation = (Pessimistic – Optimistic) / 6 SD = (45 – 31) / 6 Standard deviation = 2.3

Then you decide that a confidence factor of 99 percent is the appropriate level of padding that should be applied to this estimate. You know that this task is critical to completing the project on time. You do your final calculation: Mean + (2.33 × SD) 36.7 + (2.33 × 2.3) = 43 (rounded)

You change the estimate for Task 3.12,“Create class module 1,” to 43 days instead of 36 days. You’ve also thus changed the end date of the project from 205 days to 212 days. You now need to look at your resource utilization before you have a firm project end date.

304

Chapter 9

Assigning and Leveling Resources You have defined the critical path for the project and applied PERT estimates to the tasks that you think are risky and on the critical path. You must assign the resources to each task before you finish the schedule for the project. Then you need to see whether your resource assignments have caused problems for your critical path. In Chapter 5, you did your resource estimates for each task. You know what generic resource should be assigned to each task. Now you actually name names and get clear about exactly who will do the work. Let’s use the simple network diagram that you created in Figure 9.4 to illustrate the process you will go through to assign and level resources. First take a look at Figure 9.4 back on page 297. You have six tasks that must be performed for this project. You have decided that, to keep your costs down, you want to use two resources: John and Maria. If you need more resources, Gerhard is also partially available. You first assign your most experienced and dependable resources to the critical path tasks. You assign Maria to Tasks 1, 4, 5, and 6, the critical path tasks. You assign your other resources to the other noncritical path tasks. John is then assigned to Tasks 2 and 3. You also realize that Task 2 requires two people to do the work. You want to see if Maria can both do the critical path and help John with Task 2. You can see the results of your assignment in Table 9.2. Table 9.2 Simple Network Diagram Resource Assignments

Task

Resource Estimate

Duration Estimate

Work Effort Estimate

Task 1

Maria

3 days

2.5 days

Task 2

John Maria

3 days

2.5 days 1 day

Task 3

John

5 days

3 days

Task 4

Maria

10 days

9.5 days

Task 5

Maria

4 days

3.5 days

Task 6

Maria

1 day

6 hours

Creating the Schedule

305

You should lay out the work in a graphical format that will allow you to see if you have resource problems and, therefore, need to use Gerhard instead of Maria to help with Task 2. For that, you use a Gantt chart. Start with a blank table, as shown in Table 9.3. This table should provide a place for the task name and a column for the task duration. The rest of the table should be columns that will fit the time scale of your project. Table 9.3 has 18 columns to cover the days in the simple network diagram. Table 9.3 Blank Gantt Chart Task D 1 2 3 4

5 6 7 8 9 10 11 12 13 14 15 16 17 18

Place the first task in the first open row, and color in the first three squares to show that Task 1 will cover 3 days. Then place Task 2 in the second row and show that Task 2 starts after Task 1. Color in days 4–6 for the three days’ duration. Continue laying out the Gantt chart until you have a diagram that matches Table 9.4. Table 9.4 Completed Gantt Chart for a Simple Project Task

D 1 2 3 4

Task 1 3 Task 2 3 Task 3 5 Task 4 1 0 Task 5 4 Task 6 1

5 6 7 8 9 10 11 12 13 14 15 16 17 18

306

Chapter 9

Using the Gantt chart format, you can already see that you have a problem with Maria doing work on both Task 2 and Task 4. Both tasks have work over the same days. Most projects won’t be as simple as the one you are using as an example; you won’t be able to see resource contention this easily. In fact, the better way to see resource contention is to create a resource histogram that shows how each resource is used on every day of the project. This bar chart shows the number of days that a person will be needed to work over the course of the project. This project involves 18 days of work, shown across the top of the resource histogram. The days that Maria is scheduled to work are shown at the bottom of the histogram. John’s scheduled days are shown in the row labeled 200% utilization. The extra time that Maria is supposed to work is shown in the row labeled 300% utilization. You can see from Figure 9.7, the resource histogram, that you have a problem on day 6: Maria is supposed to do her own work and then help John with Task 2. Based on this, you should either lengthen the project or have Gerhard help out with Task 2. Day

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

Utilization 300% 200% 100%

Legend: Maria -

John -

Overage -

Figure 9.7 Resource histogram

Now assign the resources to the TTR project. Start by putting the resource names to the generic list of resources. These are the people whom you have negotiated to get onto our project. Table 9.5 shows the list of generic resources.

Creating the Schedule

307

Table 9.5 Resources

Resource Needed

How Many Available?

Project manager

1

Executive sponsor

1

John Knowling

Course developers

4

Jodi, Karla, Sue, Joe

Pilot class

1

Trainers

4

Gretchen, Craig, Maria, Connie

Graphic artist

2

Clarice, Kelly

Regular class

3

Technologists

2

Doug, Bob

CSR supervisors

5

Carol, Wanda, Buddy, Denise, Janice

Training room

2

Textbooks

100

Reproduction facilities

2

Computers

7

Customer service rep computer systems

3

Who

You now can use this list and your list of tasks with the generic resources (as shown in Table 9.6) and do your resource assignments. You’ll notice also that you have highlighted the tasks in the table that are on the critical path. You have broken down the work effort estimate by person. Follow the strategy that you laid out earlier: 1. Assign the best and most dependable resources to the critical path. 2. Assign the rest of the resources to the project. 3. Do a resource histogram and determine where you have resource

issues—in other words, where too much time is assigned to one person. 4. Deal with each issue by adding more resources or redoing the schedule.

308

Chapter 9

Table 9.6 Tasks and Generic Resources

Task 1.1 Interview CSR supervisors

1.2 Determine current customer complaints

1.3 Determine current training time

1.4 Create current state document

Resource Estimate

Duration Estimate

Work Effort Estimate

1 course developer

2 days

1 day

1 project manager

2 hours

5 CSR supervisors

1 day

1 course developer

2 days

1 project manager

2 hours

5 CSR supervisors

1 day

1 course developer

2 days

1.6 Create product requirements

1 day

1 project manager

2 hours

5 CSR supervisors

1 day

4 trainers

1 day

1 course developer

3 days

1 project manager 1.5 Investigate what is currently trained

1 day

1 course developer

2.5 days .2 hours

2 days

1 day

1 project manager

.5 day

5 CSR supervisors

1 day

4 trainers

1 day

1 course developer

10 days

5 days

5 CSR supervisors

2 days

1 project manager

4 hours

309

Creating the Schedule

Task

Resource Estimate

Duration Estimate

Work Effort Estimate

1.7 Sign off on requirements

1 course developer

1 day

2 hours

2.1 Create approach document

1 project manager

2 hours

1 executive sponsor

2 hours

1 course developer

5 days

1 project manager 2.2 Determine whether to rewrite or start over

2.3 Create learning objectives

1 course developer

2 hours 2 days

3.1 Conduct the first class

1 day

1 project manager

2 hours

1 executive sponsor

2 hours

1 course developer

2 days

1 project manager 2.4 Determine whether to use a new technology

4 days

1 course developer

1.5 days 2 hours

3 days

1.5 days

1 project manager

2 hours

2 technologists

1.5 days

1 executive sponsor

2 hours

1 customer service rep system

1.5 days

1 trainer

25 days

25 days

1 training room

25 days

1 regular class

25 days

20 textbooks

25 days

1 customer service rep system

25 days continued

310

Chapter 9

Table 9.6 Continued

Task 3.2 Time the pilot class

3.3 Verify that customer complaints are < 2%

3.4 Train the trainer

Resource Estimate

Duration Estimate

Work Effort Estimate

1 course developer

25 days

25 days

1 CSR supervisor

3 days

1 project manager

2 hours

5 CSR supervisors

3.7 Adjust the class to 50% less

3.75 days

1 course developer

3.75 days

1 project manager

8 hours

1 course developer

15 days

15 days

1 customer service rep system

15 days

4 trainers

15 days

3.5 Design the class 1 course developer

3.6 Create job aids

30 days

5 days

4 days

1 customer service rep system

4 days

1 project manager

2 hours

1 course developer

5 days

4.5 days

1 graphic artist

3 days

1 project manager

2 hours

2 computers

4.5 days

4 course developers 4 computers

5 days

3 days 3 days

311

Creating the Schedule

Task

Resource Estimate

3.8 Verify that the train- 4 course developers ing class is 50% less

3.9 Conduct the pilot class

Work Effort Estimate

1 day

2 hours

2 CSR supervisors

2 hours

1 project manager

2 hours

1 trainer

25 days

25 days

1 project manager

2 hours

2 CSR supervisors

6 days 1 day

3.12.2 Create class module 2

3.12.3 Create class module 3

4 hours

1 pilot class

2 hours

1 project manager

2 hours

2 CSR supervisors

4 hours

1 course developer

5 days

1 reproduction facilities 3.12.1 Create class module 1

25 days

1 pilot class

3.10 Verify that learning 1 trainer objectives are met

3.11 Create textbooks

Duration Estimate

1 course developer

4 days 1 day

43 days

28 days

1 computer

28 days

1 graphic artist

5 days

1 course developer

35 days

27 days

1 computer

27 days

1 graphic artist

5 days

1 course developer

35 days

27 days

1 computer

27 days

1 graphic artist

5 days continued

312

Chapter 9

Table 9.6 Continued

Task 3.12.4 Create class module 4

3.12.5 Create class module 5

3.12.6 Create class module 6

3.12.7 Create class module 7

3.12.8 Create class module 8

3.13 Create pilot textbooks

Resource Estimate

Duration Estimate

Work Effort Estimate

1 course developer

35 days

27 days

1 computer

27 days

1 graphic artist

5 days

1 course developer

35 days

1 computer

27 days

1 graphic artist

5 days

1 course developer

35 days

27 days

1 computer

27 days

1 graphic artist

5 days

1 course developer

35 days

27 days

1 computer

27 days

1 graphic artist

5 days

1 course developer

35 days

27 days

1 computer

27 days

1 graphic artist

5 days

1 course developer

5 days

1 reproduction facility 3.14 Revise material after the pilot

27 days

2 course developers 1 graphic artist

4 days

1 day 7 days

6 days 1 day

Creating the Schedule

Task 3.15 Verify the timings (after design)

Resource Estimate

Duration Estimate

Work Effort Estimate

1 course developer

2 days

1.5 days

1 project manager 3.16 Process analysis

1 project manager

2 hours 2 days

1 quality auditor 3.17 Verify the timings (after module development)

1 course developer

2 CSR supervisors

4 hours 1.5 days

2 days

1 project manager 3.18 Monitor for customer complaints (after pilot class)

313

1.5 days

2 hours 30 days

3.75 days

1 course developer

3.75 days

1 project manager

4 hours

You analyzed the resources on the project and determined that Jodi is the strongest and most dependable course developer. You thus started the resource assignments with her. You placed Jodi on the critical path tasks, such as creating the product requirements, creating the approach document, designing the class, and creating the first course module and continuing through the rest of the critical path tasks. You then applied the rest of the resources to the noncritical path tasks. These are tasks such as completing the preliminary work (interviewing the CSR supervisors and determining the current training time). All the task assignments go well until you reach the creation of the course modules. Here you realize that you have a problem. You have four course developers and eight modules to create. You have a choice here to either elongate the schedule or hire more course developers. For now, you will elongate the schedule and then continue with the rest of your resource assignments. You will then build your resource histogram and see if you have any other resource contention problems. Before you deal with these issues, let’s talk

314

Chapter 9

about the next technique in creating the project schedule: schedule compression. Then you can come back to your scheduling dilemma. Resource Leveling in MS Project You now understand the concepts of resource assignment and leveling; you should see how easily you can do this in Microsoft Project. See Chapter 9 of Microsoft Project for Mere Mortals, by Patti Jansen.

Schedule Compression You have finished assigning the resources to the project and have dealt with the overallocation of your resources. You also have determined the probable end date for your project. However, you realize that the date you have calculated is past the due date that your executive sponsor has requested. How do you modify this schedule to get to the requested end date? The answer is schedule compression. Schedule compression is a term used in project management to describe activities that reduce the duration of your project. You always plan the project exactly as it should be performed. But you might get to end of the planning and find that the end date is not in line with the request from your sponsor or client. You then must look for ways to shorten the duration of the project. You’ll learn about three techniques in schedule compression in this section: crashing, fast-tracking, and descoping.

Crashing This duration-compression technique looks at the tasks of the project and tries to find a way to shorten the duration of the project while keeping costs under control. Most of the time, the reduction of the project length happens either by reanalyzing the critical path tasks and reducing the duration of some of the tasks or by adding more resources to applicable tasks to shorten the duration. Take a look at the simple network diagram again in Figure 9.4. You can see that the critical path for this diagram is Tasks 1, 4, 5, and 6. To crash the critical path, you adjust the duration of these tasks. The first method of crashing is to reanalyze the critical path tasks and reducing the duration, if possible.

Creating the Schedule

315

Your analysis after looking over the critical path and understanding the work that needs to be completed tells you that these are good durations and cannot be reduced. You then look at the critical path again and determine whether some tasks on the critical path can have more resources applied to them. In this analysis, you also need to make sure that the budget will allow more resources on the project. Referring back to the diagram in Figure 9.4, you see that Task 4 might be a good candidate for more resources. You talk to the resource assigned and determine that you can have both resources work together on day 1. Then two resources can split the work. They will have to work together again on the last day of the task and consolidate their work. Figure 9.8 depicts the resource change for Task 4. With this change, you can compress the schedule by four days. Don’t assume that you will be able to cut a task by half by adding another resource. You actually might be able to do this on some tasks, but you should always analyze the work to see how best to apply another resource. ES 3

EF 6

ES 6

Task 2 3 days ES 0

EF 3

LS 3

EF 11 Task 3 5 days

LF 6

LS 6

LF 11

ES 11

ES 15

Task 5 4 days

Task 1 3 days

LS 0

EF 15

LF 3

ES 3

EF 9

Task 4 6 days

LS 3

Figure 9.8 Splitting Task 4

LF 9

LS 11

EF 16

Task 6 1 day

LF 15

LS 15

LF 16

316

Chapter 9

Fast-Tracking Fast-tracking is a duration-compression technique that looks for opportunities to overlap the work on the critical path or to do critical path tasks in parallel instead of sequentially. Let’s consider a couple examples so you can see how fast-tracking works. Use the same simple network diagram again, shown in Figure 9.4. For fasttracking, you look for tasks that are scheduled for work sequentially. You first talk to the resources that are scheduled to do the work. You determine, based on their and your analysis, whether opportunities exist to speed up the work. First look at Tasks 1 and 4. You analyze the work and realize that Task 4 can be started after the first two days of work are completed on Task 1. The network diagram does not change its format much, but you will show the relationship now as a start-to-start relationship with two days of lag time. That means that Task 4 can start after Task 1 has started and two days have passed, as depicted in Figure 9.9. This change in the order of work reduces the duration by one day. ES 3

EF 6

ES 6

Task 2 3 days ES 0

EF 3

LS 5

EF 11

Task 3 5 days LF 8

LS 8

LF 13

ES 13

Task 5 4 days

Task 1 3 days

LS 0

EF 17

LF 3

S to S + 2 days of lag

ES 3

EF 13

LS 13

LF 17

ES 17

EF 18

Task 4 10 days

LS 3

Figure 9.9 Fast-tracking

Task 6 1 day

LF 13

LS 17

LF 18

Creating the Schedule

317

The other way to fast-track work is to find critical path tasks that can be done in parallel instead of sequentially. Tasks 5 and 6 are a possibility for this technique. You talk to the resources assigned to do this work and realize that they can indeed be done in parallel. You change your network diagram to look like Figure 9.9, showing these tasks now being done in parallel. You’ve now shortened the project duration by another day. Fast-tracking is a great technique to use when you can’t afford to increase your budget. Crashing is the technique to use when you still have some budget leeway available. The final duration technique is called descoping.

Descoping Descoping means exactly what the term implies: removing work from the project. Your client or executive sponsor probably has a good reason for asking you to deliver the project on a specific date. They probably have a specific financial or service goal to attain by that date. It might be time to descope the project if you have exhausted all your attempts to crash and fasttrack the project, and you have verified that the date is the most important one of the triple constraints. When you descope, you remove or change one or more of the following: • The measure of performance • Features of the product • Functionality of the product Changing or removing any of these three changes the scope of the project. Say, for example, that your organization is providing handyman services to consumers. One of the primary marketing thrusts for six months from now is the campaign “We’re here when you need us!” With that slogan, your organization will be providing emergency service within two hours of a consumer’s emergency call. Your project is to create a new hand-held service dispatch/GPS functionality device. This device will tell your dispatchers exactly where your handymen are and give them directions to get to the next emergency call. You have just finished all your project planning. You have a good schedule and a project plan that you can successfully execute. However, your finished network diagram shows that you are six weeks away from having the handheld device ready in time to launch with the new marketing campaign. You

318

Chapter 9

find that you can shave another two weeks off the schedule with crashing and fast-tracking. Now is the time to put on your thinking cap and come up with some “what if” scenarios to present to your client and/or executive sponsor. You must look for is a way to meet the organization’s needs while still delivering the majority of the project. You do your homework and analyze each possibility thoroughly. You then present each scenario to your client and/or executive sponsor, while providing enough information for them to make a sound decision. Here are some of the solutions to present to your executives: • You’ve talked to the marketing department and done some research together. You have found that when a marketing campaign is launched, it usually takes about three weeks for consumers to respond to a good campaign. The organization can take a risk and start the marketing campaign on time, and have the hand-held devices ready one month afterward. The schedulers will contact the handymen on their company cell phones during the gap between the campaign starting and the devices, as they do today. All the emergency calls will be handled manually, with the schedulers fielding each call, looking at the daily handyman schedule, picking a handyman to respond, and then calling the handyman to respond. • You have taken the time to rework the schedule into two sets of deliverables for another of the “what if” possibilities. In this new schedule, you can deliver the hand-held device with the launch of the marketing campaign for the first deliverable. The hand-held device will contain only the scheduling information for this deliverable. The schedulers will have all their information automated and will have computer support to select the most available and closest (to the emergency call) handyman for an emergency call. They will still look up the customer’s location using the Internet, as they do today, until the rest of the functionality is available. The second deliverable can be scheduled two months later. It will contain the GPS functions of where the handyman currently is, as well as the GPS location of the emergency client. The cost for making this functionality change is approximately $200,000. • You also can delay the marketing campaign for another month. You doubt that the executives will go with this plan, but it is another possibility. You gave your executives a couple “what ifs” that they can use to determine what scenario best fits their strategy. The middle scenario is an example of a

Creating the Schedule

319

descoping scenario. With this scenario, you have reduced the features and functionality of the product and actually started another project or phase to deliver the descoped functionality. That covers the three techniques of schedule compression. It’s now time to get back to the TTR project and see where you are with your end date. You had an issue with the actual course development when you finished your resource assignments and leveling: You have four course developers and eight modules to be created. You decided at that time to create four course modules in the first 43 days and then to do another batch of course development for the last four modules for another 35 days. That has elongated the project by another 35 days. The project now tentatively will last 247 days. You then continued with your resource assignments. You really feel that you have no other major issues. You can deal with your other resource problems using slack time or other noncritical resources. Now it is time to see if your project schedule meets the time frames that the client or executive sponsor requested. You look back at your project plan and find that the client requested that your work be completed by the fourth quarter at a cost of $500,000. It is now mid-January. The actual project execution is ready to start at the end of the week. You look at the work days available this year and the scheduled holidays, and you realize that the project will complete in mid-January next year. That is not the fourth-quarter deliverable you were asked to provide. Looks like you need to do some schedule compression to deliver at the time requested. One more thing: You had better take a preliminary look at your expected costs and see if you have any budget leeway. The next chapter talks more about setting up the budget and projecting the costs for the project. Your quick review of the budget says you have about $100,000 left. You know after taking that quick look at the budget that you can both crash and fast-track. Look back at Figure 9.5, the TTR project network diagram with the critical path shown. You decided to elongate the schedule and stay with the four course developers when you were doing your resource assignments and leveling. You now realize that, to make your end date, you will need to hire four contract course developers and bring the schedule back to its original 212-day duration. That bit of crashing just took 35 days off the schedule and brought your end date back into this year. Good project managers always try to have some time available for problems and schedule slippage. Look for one more area to crash or fast-track so you have a little time available for slippage issues. Right away you notice two places where you can compress the schedule. The first area is task 3.16,“Process analysis.”You have that task on the critical

320

Chapter 9

1.1 Interview CSR supervisors 2 days

1.2 Determine current customer complaints 2 days

2.3 Create learning objectives 2 days

1.4 Create current state document 3 days

2.4 Determine whether to use a new technology 3 days

2.1 Create approach document 5 days

3.5 Design the class 5 days

3.15 Verify the timings 2 days

Start 1.3 Determine current training time 2 days

2.2 Determine whether to rewrite or start over 2 days

3.16 Process analysis 2 days

1.5 Investigate what is currently trained 2 days

1.6 Create product requirements 10 days

1.7 Signoff requirements 1 day

Figure 9.10 TTR compressed network diagram

path. You really don’t need that to be in the middle of the project work; it can be done in parallel with other work activities. You can fast-track it and make it parallel to verify the timings, to save two days on the critical path. The other task that is a candidate for schedule compression is Task 3.6,“Create job aids.” Right now you have it in the critical path. It needs to start when the course modules are completed but does not need to wait until the timings are verified. Fast-tracking that task and making it parallel to verify timings can save another three days on the schedule. That is a total of five additional days you have cut from the schedule. Add that to the four course developers, and you have shaved off 40 days from the schedule, which puts you at the early part of the fourth quarter this year. Figure 9.10 shows the new network diagram with the changes you’ve made.

321

Creating the Schedule

3.12.1 Create class module 1 36 days

3.12.2 Create class module 2 35 days

3.12.3 Create class module 3 35 days 3.17 Verify timings 2 days

3.13 Create pilot textbooks 5 days

3.9 Conduct pilot class 25 days

3.12.4 Create class module 4 35 days

3.18 Monitor for customer complaints 30 days

3.10 Verify learning objectives are met 1 day

3.6 Create job aids 5 days 3.12.5 Create class module 5 35 days

3.8 Verify the training class is 50% less 1 day

3.12.6 Create class module 6 35 days

3.2 Time the pilot class 25 days

3.12.7 Create class module 7 35 days

3.12.8 Create class module 8 35 days

3.14 Revise material after the pilot 7 days

3.7 Adjust the class to 50 % less 5 days

Figure 9.10 Continued

3.11 Create textbooks 5 days

3.4 Train the trainer 15 days

3.1 Conduct first class 25 days

3.3 Verify customer complaints are < 2% 30 days

End

322

Chapter 9

You’ve now completed the schedule for the project. The duration is 207 days of work. Go back and do the following before you update your project plan with all this information: 1. Reverify the critical path—With all the changes you have made,

have you changed the critical path? 2. Reverify that you have not overloaded any of your resources— With all the changes you have made, have you overbooked any of your resources? 3. Analyze any new risks—With the changes you have made, have you created new risks that must have response plans created? You can now update your project plan with the compressed schedule, the critical path, and the resource assignments. Make sure that you update your assumptions and constraints, too, based on the work you’ve just completed. You should know about one more technique before you leave the topic of scheduling: understanding the flow of the work.

Understanding the Flow of the Work You can probably skip this section if you are working on a project that is of short duration and medium complexity. You can understand the flow of the work by glancing at the network diagram. But your project might be several months long and you might have work that flows from department to department. Then you might want to create what I’m going to call the 60,000-foot network diagram. Project managers use this technique to make sure that they understand the flow of the work, the timings of the hand-offs from department to department, and finally the major events that trigger a hand-off. Think of this as your roadmap through the major events of the project. It is an easy way to visually create the flow of the work. You’ll need to determine whether you have drawing software that you can use to create this diagram. A product such as Microsoft Visio is perfect for this type of work. If you don’t have a product like Visio, you can always handdraw the diagram. Look for ways to summarize the work in the network diagram for your project. For this exercise, you might or might not be able to use one of the

Creating the Schedule

323

higher levels of your work breakdown structure. You might not have created it in a way that it can be used for this diagram. Take a look at Figure 9.10, the TTR project after you’ve completed the schedule compression work. The tasks just to the right of start describe work that must be done to understand the current state, as well as work that must be done to decide on the approach. You could summarize this work as being “Current state and approach decisions.”You add up the durations on the network diagram path and get a total duration of eight days. Now look below that entire path of work. This is the work for product requirements and sign-offs. You could summarize that work as “Product requirements and sign-off,” and show a total duration of 11 days for that work. Continue working through your network diagram doing your summarization until you have created a diagram like that shown in Figure 9.11. Current state, and approach decisions 8 days

Dsocument approach 5 days

Start

Design and construct class 52 days

Pilot class creation, conducting, and verification 63 days

1st class creation, conducting and verification 77 days

End

Product requirements and sign off 11days

Figure 9.11 A 60,000-foot network diagram

This one-page diagram is an excellent tool for describing the major pieces of work to executives. It also is a great help in understanding the flow of the work for project managers who are new to a department or an industry. This is your “you are here” context diagram when you are talking to the project team. It’s also been useful in helping a project manager determine the frequency of status meetings and executive review meetings, but I talk about that later in Chapter 12.

324

Chapter 9

You have completed your project schedule and 60,000-foot network diagram. You are now ready to consider how to build the team’s commitment while working on the schedule.

Teaming Did you notice back in the section on duration compression that before you decided to change the flow of the work, you needed to talk to the person assigned? Seems like a simple and pretty common-sense thing to do. You’d be surprised, though, by how many project managers just go ahead and do these types of changes themselves. They are in a hurry, and talking to each resource takes time and energy. Well, some of the best advice you can get is to take the time and use the energy to talk to the resources about every change that affects their work. The idea here is that they will own the work if they create the work. This is also a sign of respect for the team members’ abilities. Your team will go through the stages of forming, storming, norming, and performing, according to the Tuckman model of the stages of team development. You are probably still seeing some storming going on if you have had enough opportunities in your planning for your team to interact. But you should also see some norming happening. People get to norming when they feel safe and comfortable. How do people start feeling safe and comfortable? One key factor is respect. You must show your team members that you respect them; they will move into the norming and performing stages more quickly than they otherwise would. You are also the example from which your team members will take their lead. You must exhibit respect to show them how you expect things to be done on your project. They will start exhibiting respect for each other (as they gain it). Now, it might take longer for some to get to respect than others, but you are setting the stage for the environment of the project. Creating the schedule is also a perfect time to get the team together for working sessions. Now is a good time to have a working session to do things such as PERT estimating and duration compression, especially if the team members have not had much of a chance to interact. At the very least, you need to pull the team together to talk about the finished schedule. You must cover one more administrative item at this point: completing your staffing management plan. All the way through this project, you have worked

Creating the Schedule

325

on team activities such as identifying the right resources for your project and negotiating for them to work with you. You’ve also spent a considerable amount of time working with the team members to develop their ability to work together. You covered all that information in your project plan, in the staffing section. You now need to revisit that section to make sure that you have covered all aspects of staffing and documented them well in your project plan. Figure 9.12 shows an excerpt of a staffing management plan. 10.1 Roles and Responsibilities Team members may change during the life cycle of the project. Stakeholder

Name

Responsibility

Sponsor

John Knowling

Responsible for verifying that deliverables meet the needs of the organization Responsible for budget approval Project-specific decision-making authority to set direction of the project Ensure organizational commitment to the project and validate project objectives

Leadership team

Carol, Wanda, Buddy, Denise, Janice

Oversee and manage general project direction, including modifications to work plan and personnel Review and critique monthly briefings report

Project team

Jodi, Karla, Sue, Gretchen, Craig, Maria, Connie, Bob Clarice, Doug, Kelly

Responsible for the day-to-day planning and executing activities for the project Review and critique communications and briefings Raise issues affecting the project

Figure 9.12 Staffing management plan excerpt

You need to touch on the following aspects in addition to what you have already covered: 1. Release criteria—You have negotiated for the right resources. Have

you also documented when they will be released from the project? You’ve completed the resource histogram and now have a good understanding of when each resource will complete his or her work. 2. Training required—For each resource on the project, you must document the training required. This will be training to perform the duties required of the resources while they work on the project. 3. Roles and responsibilities—You know all resources and have assigned tasks. It’s a good idea to get clear on who is responsible for what.

326

Chapter 9

Make sure that you have completed as many aspects of your team development as possible. Now it’s time to set the stage with the executives regarding the schedule.

Politics One of the most important meetings you will need to have with your project executives is what I call the “I’m a hero if” meeting. This is the meeting in which you have a frank conversation with the executives about the schedule of the project. This meeting will probably take an hour and should be conducted as soon as the schedule is completed. Make sure you get your meeting on the executive’s meeting docket when you think you are close to finishing the schedule. In this meeting, you walk the executive through the entire schedule and make sure he or she understands the flow of the work and the challenges that face the team. You want to show exactly what it will take to do the project correctly from a workflow point of view. Then you show what you’ve had to do to shorten the schedule to get it to the time period requested. The executive needs to understand the risks and the shortcuts you will take to get to the correct end date. You never say the words, but what you are conveying is “I’m a hero if I’m able to complete this project with the features and functionality you desire, with the date you’ve requested, and the money you’ve given me.” That way, you have warned the executive about the risks and dangers of the project. You’ve set the stage for what can go wrong. You’ve also set the stage that this is not going to be easy, but you and the team will find a way to complete it as requested. You are saying,“I can make this happen for you!” In politics, you always make sure that those that can make or break your career know and understand the project story. Again, my intent is to make sure that negative politics don’t come your way because of project risks or missed opportunities for important communications. You must always make sure that the executives know what can go wrong and what you are doing about it in advance.

Creating the Schedule

327

Summary In this chapter, we talked about the steps that you take to complete the project schedule. We opened this chapter by calculating the critical path to understand the preliminary completion date. Then we looked at the critical risks for the project and applied PERT estimates to the critical tasks affected by these risks. We then assigned the resources to the tasks of the project and determined whether we had any overallocation of resources. If there were overallocations, we smoothed out those issues. Next we determined whether the completed project schedule was in the time frame that was originally requested. We used the schedule-compression techniques of crashing, fast-tracking, and descoping to shorten the length of the project. Last, we talked about a new technique to use on big, complex projects to help the project manager understand the flow of the work. In the “Teaming” section, we talked about getting commitment from team members during the schedule-development process. In the “Politics” section, we looked at strategies to prepare executives for project challenges. Let’s see what Chris Williams did with the risk strategy over the weekend and whether she’s ready for her next core team meeting.

Case Study At her core team meeting on Monday, Chris presented her communication plan and the new risk strategy. The team added a few items to the communication plan but thought it was in good shape. However, the risk strategy generated a lot of conversation. The team members really didn’t understand risk management. Chris ended up spending most of the meeting explaining the strategy the team would follow. Chris had decided over the weekend that they would use probability and impact calculations to determine what risks they would work on. Robin Good and Carol Hinnant got into a heated discussion while they were discussing the new risk strategy. Chris let them go on for a few minutes but finally had to stop them from continuing their argument.

328

Chapter 9

Chris continued the meeting with a brainstorming session for the project risks. Carol and Robin got into another heated discussion. Chris again had to stop them from continuing their argument. Chris decided to stop the meeting and give everyone a 15-minute break before they continued the brainstorming session. Chris asked Robin and Carol to talk with her for a few minutes in the hallway during the break. Chris knew she couldn’t resolve the issues between the two women in those few minutes, but she asked them to curtail their arguments until the meeting concluded. Chris asked to talk to both of them after the meeting. The core team went back to the brainstorming session and put together a good list of risks. Then, as a team, they determined impact and probability for each risk. Though they were running out of time, but Chris had them create a mitigation strategy for the highest probability and impact risk just so they could see how the entire process would work. They had a master risk identification list at the end of the Monday meeting (see Figure 9.13). Carol and Robin were pretty quiet during the rest of the work session. They might not have said anything verbally, but their nonverbal signals were very strong. They pretty much glared at each other through the rest of the meeting. Chris sat down with them at the end of the meeting to find out what all the storming was about. At first, both women just said the other was wrong on the point they were discussing and that they were just trying to point out the error of that thinking. Chris said she thought something else was going on because the discussion had been so heated. Chris kept talking with them. She told the women that disagreements are okay in the team, but they looked like they were ready to go to the next level. After about 30 minutes of more heated discussion, Robin finally broke down and said that Carol had been talking about her behind her back and she was sick of it. After more heated discussions and a couple emotional outbursts, Chris was finally able to figure out that Carol had said something she thought was nonconfrontational about the Marketing department. Robin had heard the statement third-hand and thought it was directed at her.

Number

Originator

Open Date

Risk Description

Probability

Impact

1.

Tina Johnson

10/1

We are unhappy with our current shipping vendor. We have fired them. We are working on a new contract with a different company. This might or might not be completed in time for the trade show.

5

15

2.

Carol Hinnant

10/1

We have never done this type of project. How do we know our estimates are correct?

5

5

Carl Price

10/1

The Web site project is currently behind schedule. This trend is expected to continue.

3

3

4.

Chris Williams

10/1

We have made assumptions about the way the show score is calculated.

2

4

5.

Robin Good

10/1

The marketing approach that we are using is based on an approach that Karla used at her last employer. That firm just declared bankruptcy.

2

2

6.

Carol Hinnant

10/1

The catalog publisher we use has reported that they are having problems getting the paper we are requiring.

4

1

Figure 9.13 VNLE master risk identification list

Mitigate—We will need to apply the appropriate amount of padding to our tasks, to help guarantee that the work will be done in time.

Creating the Schedule

3.

Respond?

329

330

Chapter 9

Both women agreed that, from now on, while working on the project, they would directly talk to each other instead of listening to hearsay. With that, they concluded the meeting. Chris was pleased that she had forced the women to talk and hadn’t allowed the problem to fester. She also realized that she had lost the entire morning to this meeting and conflict resolution. At last she had a master risk identification list started. She decided to grab a quick lunch and eat at her desk. She had a lot to get done this week. She had scheduled a meeting with June on Friday afternoon to talk about the project schedule and risks. She still had to finish the project schedule and budget before that meeting.

Review Questions 1. What is a critical path? 2. What three calculations are necessary for calculating critical path? 3. What is the near critical path? 4. What is a resource histogram? 5. What strategy should you use when assigning resources to project

tasks? 6. What is schedule compression? 7. What are the three duration-compression techniques? 8. Describe a 60,000-foot network diagram.

10 Budgeting—How Much? The person who says it will take the longest and cost the most is the only one with a clue how to do the job. —Mike Harding Roberts

Topics Covered in This Chapter Budgeting 101 Building the Budget Reconciling the Budget Cost Baseline Teaming Politics Summary Case Study

In this chapter, I talk about project budgets, the last item in project planning. I cover how to build the budget, including all the components that make up the budget. Then I move on to budget reconciliation—in other words, what you can do when your budget is more than the amount provided in your order of magnitude estimate. I also spend some time describing the cost baseline. You must understand the importance of this concept before you begin to execute your project. In the “Teaming” section, you’ll learn about rewards and recognition. You’ll explore a technique that doesn’t cost much but works incredibly well to motivate the team. You’ll also do a team development checkup. Your team might not have worked past some of its storming activities, and you need to give them some more opportunities before you begin to execute your project. In “Politics,” we talk about the importance of executive education and how to sell budgeting best practices to your executives. 331

332

Chapter 10

Chris will spend this portion of the case study getting the schedule and budget ready for a meeting with her sponsor. She has a lot of work to get done before that meeting.

Budgeting 101 You have one more thing to complete in your project-planning activities: the budget. The budget is a money amount that covers the entire cost of the project. When I say “entire,” I mean entire. This chapter covers the costs for all resources on the project, including the labor of the individuals, the donuts for the core team meetings, the travel of the project manager, and the use of the computers, as just a few examples.“Project resources” don’t just include people; they include any type of resource that will be used on a project, including equipment or materials. The budget is a financial component that is created at the end of the project planning cycle. Don’t confuse the budget with an order of magnitude estimate; they are two entirely different things. The order of magnitude estimate is created at the beginning of the planning cycle. It is a guess about what the total cost of the project could be. The budget now gets down to establishing what the costs of the project will be. The budget is built with several components that, when added up, show the total cost of the project. Those components are items such as the cost of every resource on every task, contingency reserves, managerial reserves, and fees. The next section covers each of these components. I’ve set some context; let’s build a budget.

Building the Budget You start building the budget with your first component, the cost of every resource on every task. You should get very detailed in building this component, and you use the bottom-up estimating technique to build this set of costs. You want this budget to be as accurate as possible. (Remember, Chapter 5,“The Art of Estimating,” covered bottom-up estimating.) You worked with duration estimates when you built the schedule; you now work with work effort estimates as you build the budget. You pay for only

333

Budgeting—How Much?

the actual work performed. The first thing you need is a breakdown of the work effort estimates for the entire project. Let’s go back to that simple network diagram that you used in Chapter 9, “Creating the Schedule.” It is depicted again in Figure 10.1.

Task A 5 days

Task B 5 days

Start

End

Task C 7 days

Figure 10.1 Simple network diagram

This simple project includes three tasks: A, B, and C. It’s easy to convert this diagram into a table that depicts the same information (see Table 10.1). Table 10.1 Simple Project Task

Duration Estimate

A

5 days

B

5 days

C

7 days

You then add the work effort estimates to the project table, as shown in Table 10.2.

334

Chapter 10

Table 10.2 Simple Project with Work Effort Estimates Task

Duration Estimate

Work Effort Estimate

A

5 days

4.5 days

B

5 days

4 days

C

7 days

5.5 days

You determined in the last chapter who will do what task and actually named names. You add that to your table now, as shown in Table 10.3. Then you make sure that you have resource rates for both of your resources. Doug is shown at $500 per day, and Marie at $375 per day. Table 10.3 Simple Project with Assigned Resources Task

Duration Estimate

Work Effort Estimate

A

5 days

Doug: 4 days Marie: 1/2 day

B

5 days

Doug: 4 days

C

7 days

Doug: 4 days Marie: 1.5 days

You then basically do the math to get the cost of resources for every task. Table 10.4 shows the cost per task. Table 10.4 Cost of Resource per Task

Task

Duration Estimate

Work Effort Estimate

Cost Per Task

A

5 days

Doug: 4 days

$2,000

Marie: 1/2 day

$187.50

B

5 days

Doug: 4 days

$2,000

C

7 days

Doug: 4 days

$2,000

Marie: 1.5 days

$562.50

Total

$6,750

Budgeting—How Much?

335

The total cost of the resources for your simple project is $6,750. Getting the cost of resource per task is pretty simple if you’ve taken the time to do the estimates and build the schedule. It really is simple to do the math exercise, and it sets the basis for your budget. You’ll get more into the basis or cost baseline soon. You might look at the current situation at your company and realize that you are not held accountable for the budget results of your projects. A lot of companies don’t keep track of project budgets. If that is the case, you’re probably thinking,“I’ll read this later when I need it.” Stay with me here and keep reading. You need to start practicing with project budgets so that you can excel at your craft of project management. Sooner or later, your company will require you to build and track budgets, or you might end up at another company that requires it. You might as well get some practice with budgets before your next pay raise is contingent on your budget performance. A roadblock that you might run into when creating the project budget— either for practice or for a real project—might be resource rates. Give every resource a set, fictitious figure if you are building the budget just for practice. It seems kind of silly to build and track a fictitious budget, but you will thank yourself later, for two reasons: • Because you’ve had practice building and tracking a budget. • Because in Chapter 12,“Keeping the Project on Track,” you’ll be learning about variance analysis and earned value. You cannot do this level of tracking without having a cost for every task. But I talk more about that later. Another roadblock that you might run into regarding resource rates has to do with building a budget on a real project. You’ll want to make sure that the budget is as close to reality as possible. That means getting salary figures for the people working on your project. Never ask a supervisor or your Human Resources department for actual salary amounts; they probably will not give them to you. Instead, ask for a loaded salary rate or an average salary rate, whatever is the norm at your company. You know what an average salary rate is. A loaded salary rate is the salary of the person plus the amount of paid vacations they receive, plus the benefits they receive. An average salary is the actual amount of money each project manager at your company makes, divided by the number of project managers.

336

Chapter 10

Now back to the resource cost of every task. Let’s apply this set of calculations to the TTR project, the running example. In the last chapter, you completed your network diagram and you know the time it will take to complete the project. You have done your work effort estimates and have determined exactly which resource will work on what task. All you need now are the resource rates that you determined back in Chapter 5 to do this math exercise. Table 10.5 shows these again. You’ll also notice that the rate table has been updated with new resources that were added during your planning activities Table 10.5 Resource Rates Resource

Daily Rate

Project manager

1 @ 350

Executive sponsor

1 @ 500

Course developers

1 @ 300

Pilot class

20 @ 100 = 2,000

Trainers

1 @ 220

Graphic artist

1 @ 200

Quality auditor

1 @ 400

Regular class

20 @ 100 = 2,000

Technologists

2 @ 500

CSR supervisors

5@ 300 = 1,500

Training room

100

Textbooks

100 for 20 students, one time

Reproduction facilities

100

Computers

400

Customer service rep computer systems

400

Now it is time to do the math and calculate the cost per task for your TTR project. You can see the results of this calculation in Table 10.6.

Budgeting—How Much?

337

Table 10.6 Cost Per Task

Task 1.1 Interview CSR supervisors

1.2 Determine current customer complaints

1.3 Determine current training time

1.4 Create current state document

Resource Estimate

Duration Estimate

Work Effort Estimate

Daily Rate

Cost

Karla

2 days

1 day

300

300

1 project manager

2 hours

350 43.75 an hour

87.5

Carol, Wanda, Buddy, Denise, Janice

1 day

1,500 (300 × 5)

1,500

1 day

300

300

1 project manager

2 hours

350 43.75 an hour

87.5

Carol, Wanda, Buddy, Denise, Janice

1 day

1,500 (300 × 5)

1,500

1 day

300

300

1 project manager

2 hours

350 43.75 an hour

87.5

Carol, Wanda, Buddy, Denise, Janice

1 day

1,500

1,500

Gretchen, Craig, Maria, Connie

1 day

880

880

2.5 days

300

750

2 hours

350 43.75 an hour

87.5

Karla

Karla

Karla

1 project manager

2 days

2 days

3 days

continued

338

Chapter 10

Table 10.6 Continued

Task 1.5 Investigate what is currently trained

1.6 Create product requirements

Resource Estimate

Duration Estimate

Work Effort Estimate

Daily Rate

Cost

Karla

2 days

1 day

300

300

1 project manager

4 hours

350 43.75 an hour

174

Carol, Wanda, Buddy, Denise, Janice

1 day

1,500 (300 × 5)

1,500

Gretchen, Craig, Maria, Connie

1 day

880

880

5 days

300

1,500

1 day

1,500 (300 × 5)

1,500

4 hours

350 43.75 an hour

175

2 hours

300

600

1 project manager

2 hours

350 43.75 an hour

87.5

John Knowling

2 hours

62.5

125

4 days

300

1,200

2 hours

43.75

87.5

Jodi

10 days

Carol, Wanda, Buddy, Denise, Janice 1 project manager

1.7 Sign off on requirements

2.1 Create approach document

Jodi

Jodi

1 project manager

1 day

5 days

Budgeting—How Much?

Task

Resource Estimate

2.2 Determine Jodi whether to rewrite or start over

2.3 Create learning objectives

Work Duration Effort Daily Estimate Estimate Rate

Cost

2 days

1 day

300

300

1 project manager

2 hours

350 43.75 an hour

87.5

John Knowling

2 hours

62.5

125

1.5 days

300

450

2 hours

43.75

87.5

1.5 days

300

450

1 project manager

2 hours

350 43.75 an hour

87.5

Doug, Bob

1.5 days

1,000

1,500

John Knowling

2 hours

62.50

125

1 customer service rep system

1.5 days

400

600

25 days

220

5,500

1 training room

25 days

100

2500

1 regular class

25 days

2,000

50,000

20 textbooks

25 days

100

100

1 customer service rep system

25 days

400

10,000

Karla

2 days

1 project manager 2.4 Determine whether to use a new technology

3.1 Conduct the first class

339

Karla

Gretchen

3 days

25 days

continued

340

Chapter 10

Table 10.6 Continued

Task 3.2 Time the pilot class

3.3 Verify that customer complaints are < 2%

3.4 Train the trainer

3.5 Design the class

Resource Estimate

Duration Estimate

Work Effort Estimate

Daily Rate

Cost

Jodi

25 days

25 days

300

7,500

Carol

3 days

300

900

1 project manager

2 hours

350 43.75 an hour

87.5

Carol, Wanda, 30 days Buddy, Denise, Janice

3.75 days

1,500

5,625

Jodi

3.75 days

300

1,125

1 project manager

8 hours

350 43.75 an hour

350

15 days

300

4,500

1 customer service rep system

15 days

400

6,000

Gretchen, Craig, Maria, Connie

15 days

880

13,200

1 training room

25 days

100

2,500 1,200

Jodi

15 days

Jodi

5 days

4 days

300

1 customer service rep system

4 days

400

1,600

2 hours

350 43.75 an hour

87.5

4.5 days

300

1,350

Clarice

3 days

200

600

1 project manager

2 hours

350 43.75 an hour

87.5

2 computers

4.5 days

800

3,600

1 project manager 3.6 Create job aids

Karla

5 days

341

Budgeting—How Much?

Task

Resource Estimate

Duration Estimate

Work Effort Estimate

3.7 Adjust the class to 50% less

Jodi, Karla, Sue, Joe

5 days

3 days

1,200

3,600

3 days

1,600

4,800

2 hours

1,200

2,400

Carol, Wanda

2 hours

75

150

1 project manager

2 hours

350 43.75 an hour

87.5

25 days

220

5,500

1 pilot class

25 days

2,000

50,000

1 project manager

2 hours

350 43.75 an hour

87.5

Carol, Wanda

6 days

600

3,600

1 training room

25 days

100

2,500

20 textbooks

25 days

100

100

4 hours

220

880

1 pilot class

2 hours

250

500

1 project manager

2 hours

350 43.75 an hour

87.5

Carol, Wanda

4 hours

600

2,400

4 days

300

1,200

1 day

100

100

4 computers 3.8 Verify that the Jodi, Karla, training class is Sue, Joe 50% less

3.9 Conduct the pilot class

3.10 Verify that learning objectives are met

3.11 Create textbooks

Jodi

Gretchen

Sue 1 reproduction facility

1 day

25 days

1 day

5 days

Daily Rate

Cost

continued

342

Chapter 10

Table 10.6 Continued

Task

3.12.1 Create class module 1

3.12.2 Create class module 2

3.12.3 Create class module 3

3.12.4 Create class module 4

3.12.5 Create class module 5

3.12.6 Create class module 6

Resource Estimate

Duration Estimate

Work Effort Estimate

Daily Rate

Cost

Jodi

43 days

28 days

300

8,400

1 computer

28 days

400

11,200

Kelly

5 days

200

1,000

27 days

300

8,100

1 computer

27 days

400

11,200

Kelly

5 days

200

1,000

27 days

300

8,100

1 computer

27 days

400

11,200

Kelly

5 days

200

1,000

27 days

300

8,100

1 computer

27 days

400

11,200

Kelly

5 days

200

1,000

27 days

300

8,100

1 computer

27 days

400

11,200

Clarice

5 days

200

1,000

27 days

300

8,100

1 computer

27 days

400

11,200

Clarice

5 days

200

1,000

Karla

Sue

Joe

David

Gene

35 days

35 days

35 days

35 days

35 days

343

Budgeting—How Much?

Task

Duration Estimate

Work Effort Estimate

Daily Rate

Cost

35 days

27 days

300

8,100

1 computer

27 days

400

11,200

Clarice

5 days

200

1,000

27 days

300

8,100

1 computer

27 days

400

11,200

Clarice

5 days

200

1,000

4 days

300

8,100

1 day

100

100

6 days

600

3,600

1 day

200

200

1.5 days

300

450

2 hours

350 43.75 an hour

87.5

4 hours

350 43.75 an hour

175

1.5 days

400

600

1.5 days

300

450

2 hours

350 43.75 an hour

87.5

Resource Estimate

3.12.7 Create class Lisa module 7

3.12.8 Create class Ashley module 8

3.13 Create pilot textbooks

Sue

35 days

5 days

1 reproduction facility 3.14 Revise material after the pilot

Sue, Joe

7 days

Clarice 3.15 Verify the timings (after design)

Jodi

2 days

1 project manager 3.16 Process analysis

1 project manager

2 days

Vivek Rao 3.17 Verify the tim- Jodi ings (after module development) 1 project manager

2 days

continued

344

Chapter 10

Table 10.6 Continued

Task

3.18 Monitor for customer complaints (after pilot class)

Resource Estimate

Duration Estimate

Work Effort Estimate

Daily Rate

Cost

Carol, Wanda

30 days

3.75 days

600

2,250

Sue

3.75 days

300

1,125

1 project manager

4 hours

350 43.75 an hour

87.5

315,739

You can see that the accumulated cost per task is $315,739. The order of magnitude estimate for the project was $500,000, so you are on track for meeting the projected budget of the project. But you need to apply some more money amounts before you can say you are done with the budget. Let’s move on now to the second component of building a budget: reserves.

Reserves A reserve is an amount of money that is set aside as part of the budget but is used only for specific types of situations. You might have heard different terms used to describe this budget component, such as reserve, contingency, slush fund, etc. This book uses two terms: project reserve and managerial reserve. Project Reserve A project reserve is money that is set aside to cover any major risks that could hinder the project in meeting the project end date, the measure of performance, or the project budget. Project managers should have the authority to use this money at their discretion after it is approved by management. This money is usually set up as a percentage of the overall budget. Most organizations that allow a project reserve to be set up usually use a percentage of 10 to 15 percent. You might add 10 percent to the overall TTR project

Budgeting—How Much?

345

budget to cover any risks. This would add another $32,000 to the projected budget. Sometimes, though, the project manager and the team analyze each risk and come up with a money amount that should be put aside to cover each major risk. This is done very much like the PERT analysis that was covered in the last chapter. On the TTR project, let’s look once again at your master risk identification list. Figure 10.2 shows an excerpt of it. You take a look at your top 25 percent risks and review each one to see if a project reserve is warranted for it. You’ll notice that the first risk was updated after your work on the project schedule. It used to say that there are five course developers. You determined in your scheduling exercise that you need eight course developers to finish the project on time. Even having one course developer on each module could result in a problem if someone gets sick or falls behind schedule. You changed the risk then and left it on the master risk identification list. What money might be needed to cover this risk? Hiring a course developer would cost about $75 per hour and you would need that developer for approximately one month. That is $600 per day and $12,000 for 20 work days in a month. You would add $12,000 to your project reserve for this risk. You would then continue through the rest of the top 25 percent risks and do the same type of analysis to determine the money amount needed. You then would accumulate the figures to create the project reserve amount. 1. Course developer

10/1

There are eight of us set up to do the work for this project, with with no slack time. What happens if one of us gets sick?

3

5

Mitigate—Be ready to hire a contract course developer to work with the other course developers. See if it’s possible to find someone with graphic skills, too. Owner: Lead course developer Alarm: Any course-development schedule slippage

2. CSR supervisors

10/1

When the CSRs go through new 4 training, there is always a spike in the time it takes to handle a customer while the new training is learned. Will this spike create customer complaints more than 2%?

5

Transfer—Develop an agreement with outsourced call center for overflow calls on Mondays for 6 months. Owner: Lead CSR supervisor

Figure 10.2 Master risk identification list excerpt

346

Chapter 10

Managerial Reserve The other type of reserve amount that is put into a project budget is called a managerial reserve. Two major differences exist between a project reserve and a managerial reserve: • The project executives hold the managerial reserve; the project manager cannot use it without their approval. The project reserve is available for use by the project manager at his or her discretion. • The managerial reserve is used for risks that are unknown. The project reserve is used for known risks. Basically, the executives hold a managerial reserve for major emergencies, such as a fire in the workplace. These are things that you cannot anticipate will happen to your project. A managerial reserve is usually a percentage of the cost per task of the project. Most organizations use a set figure, such as 10 percent. Thus, you would place $32,000 in the managerial reserve for the TTR project. You need to know about one more component of a budget: a fee.

Fees A fee is a money amount that must be paid because of your project. Most times this fee is associated with the entire project, not a specific task. A fee that is associated with a specific task is shown as another resource for that task. A fee that is associated with the entire project should be built into the budget. Consider these examples of fees: • An insurance policy that the project must have—A project that is producing a movie for a major studio might need an insurance policy on the movie production. • Lawyer fees—Your project might need to put a contract in place with several project resources. A lawyer might be required to draw up the contracts on behalf of the project. On the TTR project, you’ve decided to rent space in an adjacent building for the course-development work. That way, your team will be away from the day-to-day distractions of running the call center and the normal training that goes on every day. You have a rental fee to pay of $25,000 for the one-year lease of this space.

Budgeting—How Much?

347

You’ve now completed the calculations for the cost per task, the reserves, and the fees. You can officially say that the budget is complete. You have taken into account all the components that make up the budget. What happens if the budget amount is more than what the order of magnitude estimate projected? That is called the budget reconciliation, and it’s the next topic.

Reconciling the Budget You might realize that the amount of money that you need for the project is way over the amount of money that has been set aside for this project. Dealing with this overage is called budget reconciliation. This technique is very similar to what you did when you realized the schedule was longer than what had been requested. Budget reconciliation is a term used in project management to describe activities that reduce the cost of your project. You always plan the project exactly as it should be performed. But you might get to the end of the planning and find that the budget is not in line with the money that has been secured for the project. You must look for ways to reduce the budget. You can use a couple techniques to reduce the budget of your project: budget crashing and descoping. Sound familiar?

Budget Crashing You used a similar technique in the schedule compression exercise in the last chapter. With the budget, you look for ways to reduce the cost of the project. You analyze each task and determine whether a lower-cost resource can be substituted for the higher-cost resource that you are currently using. The trick to this level of crashing is to reduce the cost of the task without sacrificing the quality or increasing the duration of the work. One area to review is where you are using outside contractors to do work. It is usually cheaper to use an employee than to use a contractor. You might not have many opportunities to reduce the cost of the task using crashing, but it is always worth a try. On the TTR project, look for places where you might be able to use a lowercost resource. You might be able to use a lower-priced or in-house graphic artist instead of the one you’ve decided to use. You should talk to the new possible resource to determine if that person can do the work on the same schedule and with the same quality.

348

Chapter 10

You can use one more technique to reduce the budget: descoping.

Descoping You encountered a similar technique in the last chapter, when you descoped to reduce the duration of the project; you now descope to reduce the budget. Your client or sponsor might have set aside a monetary amount to fund the project, so you might not have any other money available. You might have to reduce the scope to deliver the project. Remember that you remove or change the following when you descope: • The measure of performance • Features of the product • Functionality of the product Once again, you must analyze the project and the product of the project, and provide “what if” scenarios to your executives that they can use to make a sound decision on how to deliver the project at the budget they can afford. Remember, too, that another option your project executive should consider is just giving you more money to do the entire project! You are now familiar with the two techniques used to reduce a project budget. Let’s get back to the TTR project: You need to compare your budget with your order of magnitude estimate and see what you need to do with budget reconciliation. You determined earlier in this chapter that the total cost per task is $315,739. You looked at several of your tasks in the project reserve area and decided to use 10 percent of the cost per task. You add $32,000 to your cost per task. You’ve also decided to use 10 percent of the cost per task for the managerial contingency. You add another $32,000 to your budget. Last, you have a fee of $25,000 for the lease of the property next door. $315,739 $32,000 $32,000 $25,000 $404,739

Cost per task Project reserve Managerial reserve Lease fees Total budget

Budgeting—How Much?

349

Your original order of magnitude estimate for the project was $500,000. It looks like that was a very good estimate because you have no budget reconciliation work to do. The project sponsor will be very happy when you announce that the project can be accomplished for $100,000 less than you originally projected. You should learn about one more concept before leaving the topic of budgeting: the cost baseline.

Cost Baseline You created a cost baseline at the end of your budget calculations. A cost baseline is the money used during the execution of the project, as a basis for you to measure and monitor how the project spending is actually happening. More baselines are used than the cost baseline; Chapter 11,“The Rhythm of Project Execution,” covers all of them. The cost baseline is not the entire budget; it is a subset of the budget that is related to the work of the project. I described this earlier as the cost of resource per task. Take a look at the diagram in Figure 10.3, and you’ll see what I mean.

Cost of resource per task

Cost baseline

B Project Reserve U D G E Managerial T Reserve

Fees

Figure 10.3 Cost baseline and the budget

You will use the cost baseline extensively in the execution of the project to determine whether you are on track or off track when it comes to your

350

Chapter 10

project schedule and the budget—but you’ll learn more about that in Chapter 13,“Controlling Changes.” You now have completed the project budget and identified the project baseline. Of course, you must update your project plan with all this new information. Be sure to include any assumptions or constraints that you have made while building the budget in your documentation. What is really exciting is that the project planning is now done and you are ready to execute the project. Let’s also talk about rewards and recognition for your team, while you’re on the topic of money and budgets.

Teaming I worked with a really good project manager once who was a master at providing rewards and recognition to his project team. He usually didn’t have a lot of budget available for team awards, but he always figured out a way to motivate his team. Here is how he did it. Every week he had a project team meeting. He announced the team award of the week at the end of the meeting. His team members were very curious when he presented the first award and wondered whether they were going to get some money. The organization was notorious for never having money to award successful project teams. The project manager stood up at the end of the meeting and very formally announced the winner of the team award of the week. He covered exactly what behavior or actions the person had exhibited and why this was important to the team. He pulled out of his pocket a 50¢ candy bar and gave it to the team member. He asked everyone on the team to applaud the award. He then concluded the meeting. Each week he looked for some behavior or action that someone had exhibited that he could reward. He looked for successful project activities, perhaps completing a task ahead of schedule or complying with team norms. He was able to find something to reward if he looked hard enough. He was able to find much more to reward as the weeks passed: The team members began to understand what was expected of them based on who got a reward for what. Two months had passed since the first team award of the week, and the project manager began to notice that some people had pinned their award candy

Budgeting—How Much?

351

bar to the cork board above their desk. They were so proud of their award that they had kept it and displayed it like a plaque. He had found a way to motivate his team to perform the actions he wanted with a 50¢ candy bar. Of course, the recognition that the candy bar represented provided the motivation. But what a powerful way to motivate! You might need to use a similar method to motivate your team, depending on the culture of your organization. Now is the time to try to fund those rewards and bonuses. The category called the project reserve is exactly the place for you to put the funding for awards for your team. Of course, you will have to make your executives aware of what this money is set aside for and get their approval. But now is the time to try to sell the concept to your executives. You can try several different tactics here: • Just ask for it—See if the executives will allow you to put away a small amount of money for each person upon the successful completion of the project. If that doesn’t work, see if you can put aside a small amount of money to be used for exceptional performance on the team. • Bargain for it—Your executive might not agree to a small pot of money for rewards, so you can try bargaining for it. Maybe you’ll be able to bring the project in early or spend less than you originally planned, and you can use the difference for rewards. • Negotiate for it—Your organization might give bonuses at the end of the fiscal year. Perhaps some of that money could be earmarked for your team and the successful completion of the project. You can’t be devious about this type of money: You have to make sure that the executives know exactly how every penny of their money will be spent on a project. But remember, you can work miracles with a 50¢ candy bar if that is what it takes to motivate your team. The planning processes is now completed. You need to assess where your team is in the model of team development. A team that has not had enough opportunities to work together and move through the stages by now will have to work through the stages while you are executing the project. That could produce disastrous results if you have a short project. You might take a few moments here to do another team-building session to work through any more kinks in the team’s actions. But now it’s time to work with your executives on the budget.

352

Chapter 10

Politics One of the best offensive moves you can make when dealing with your executives is to educate them on important issues—especially if you want to get the best budget, the best schedule, and the best outcome for your project. A lot of the project managers I meet tell me that the order of magnitude estimate that they created early in the concept phase of the project is the money amount they are stuck with for the life of the project. They are expected to deliver to that amount. They also tell me the sad fact that someone who is not associated with the project usually comes up with the estimate. How do you deal with those types of situations? The answer is education. You might not be able to change things on your current project, but you might be able to change things for the future. Take a few minutes whenever you meet with your executives to find out their understanding of project budgets and reserves. Then slowly, step by step, educate them on what bestin-class organizations do with budgets and reserves. The trick here is to educate without the executives knowing you are educating. You don’t want to insult them. They probably are as bright as you (or even brighter) and know a lot more about running companies and politics than you do. They just might not know what it takes for good project management to occur. Best-in-class companies do this: • Set aside funding at the concept stage for a project • Allow project managers to plan the right way to execute a project • Look at the trade-offs among the triple constraints to determine what can give when the schedule, budget, and MOP can’t be done with the resources that have been reserved for the project • Understand known risks and unknown risks, and make sure money is available to handle these issues, especially if the project is critical to their strategy

Budgeting—How Much?

353

These ideas comes from the PMBOK® Guide, the worldwide standard in project management; the guide calls its processes industry good practices. These concepts are also covered in the Organizational Project Management Maturity Model (OPM3®), the worldwide standard for industry best practices. Now you have it from the experts that this is how good project management is done. You may have to sell these concepts to your executive after you’ve provided some education. Be ready to show them the benefits of putting these practices in place. The primary benefit is delivering the project to the triple constraints—and then you have to do it. Be sure to also include the budget in your “I’m a hero” meeting that I covered in the last chapter.

Summary This chapter was all about money—namely, the process of creating a budget and reconciling it to the original project. We described each of the components that make up a project budget. We also covered some of the key terms used in creating a budget, and we explored the cost baseline. In the “Teaming” section, we covered how to obtain the funding to reward your team. We also provided a technique to use if money is not available for rewards and recognition. In “Politics,” we talked about the importance of executive education. You might not be able to get the funding and reserves you need for your current project, but at least you are setting the stage for good project management in the future. Chris Williams plans to complete the project schedule and the budget this week. Let’s see how things are going.

Case Study Chris knew she would need to put in a lot of time this week to finalize the project schedule. She had lost most of Monday to the core team meeting and the argument between Carol and Robin. It was time well spent, though. Chris knew that these types of problems could tear a core team apart—or at

354

Start

Chapter 10

1.3 Establish marketing goals 1 day

1.4 Determine target audience 1 day

1.1 Gather previous trade show information 5 days

2.6 Determine vendor partnership strategy 2 days

2.7 Determine target vendors 5 days

1.2 Gather input from other departments 3 days

2.1 Design the booth sales approach 2 days

2.5 Design the booth 3 days

2.3 Design the trade show experience 5 days

2.15 Walkthrough and sign off design 1 day

2.10 Determine housing and travel requirements 1 day

1.5 Create draft marketing plan 3 days

2.2 Create IT demo requirements 1 day

1.6 Review and revise draft plan with other departments 2 days

1.7 Create final marketing plan 1 day

2.4 Design the marketing collateral 3 days

2.11 Gather marketing material and booth shipment requirement 1 day

2.14 Verify product inventory supports the marketing plan 1/2 day

2.8 Review and revise demo requirements 1 day

2.9 Design the demo 2 days

2.16 Walk through and sign off the demo design 1 day

2.12 Determine catering requirements 1 day

2.13 Determine trade show on site requirements 3 days

Figure 10.4 VNLE critical path

least make it so dysfunctional that it would be hard-pressed to get a lot done. Chris started creating the schedule for the project. She had a meeting scheduled with June on Friday and wanted to brief her on the schedule and, if she could get it done, the budget for the project. Chris started her analysis of the schedule by using her network diagram in critical path analysis. She also wanted to understand the near critical path. She’d had a problem in her last project with the near critical path slipping in its time commitments. She ended up with the near critical path becoming the critical path, and she hadn’t noticed the change. She almost didn’t complete the project on time. Chris swore to herself that would never happen to her again. Figure 10.4 shows the network diagram with the critical path.

Budgeting—How Much?

3.1.9 Build marketing collateral 10 days

3.1.16 Verify marketing collateral with focus group 10 days

3.1.13 Create trade show buzz 30 days

3.1.8 Establish premeetings with vendors 3 days

3.1.10 Build the booth 10 days

3.1.17 Verify the booth build with focus group 2 days 3.1.6 Prototype the booth experience 2 days

Detailed planning completed 3.1.11 Build the demo 5 days

3.1.1 Arrange flights and lodging 5 days

3.1.12 Test the demo 5 days

3.1.19 Verify the booth experience with the focus group 2 days

3.1.7 Learn and practice demo 5 days

3.1.18 Verify demo with focus group 2 days

3.1.14 Verity the web site is ready 1 day

3.1.4 Finalize trade show on site requirements 1 day

3.1.3 Make catering arrangements 1 day

3.1.15 Verify the catalog is ready 1 day

3.1.5 Verify product inventory supports the trade show plan

Ready for the trade show

3.2.1 Verify and correct logistics 1 day

3.2.2 Manage the trade show event 4 days

3.2.3 Staff the booth 4 days

3.2.4 Get feedback for vendor experience during event 4 days

Figure 10.4 Continued

3.2.5 Receive > 125 point for trade show 1 day

3.1.2 Ship marketing material and booth 1 day

355

356

Chapter 10

Chris looked at the time required to complete the project. She was currently at 78 days. Excellent. The trade show was in September, which meant that they had plenty of time to complete the work on the project. Chris stepped back for a moment and looked at the project schedule. From the looks of it, the marketing activities had turned out to be most of the critical path. The activity to create trade show buzz was one of the most important activities. Yet there was no activity to get feedback and adjust the marketing activities, if needed. Chris decided to add another task to the schedule to collect feedback on the buzz and make adjustments, if needed. This additional task would take about 15 more days. That now placed them at 93 days, into midAugust. Time to look at the risk list now and see if she needed to pad any of the activities or the critical path before she assigned resources. The largest risk on the VNLE master risk identification list, shown in Figure 10.5, is risk 2: We’ve never done this type of work and need to guarantee that the work can be done in that time. Chris went back over the critical path and analyzed the tasks there. Most of the tasks were things such as determining a partnership strategy, targeting vendors, and creating marketing plans. Chris ran down the hall and had a conversation with Robin, and showed her the tasks on the critical path. They both agreed that no additional padding was warranted because these are normal activities that the marketing department does every day. Chris continued her analysis of the critical path. She decided not to do PERT calculations on any of the critical path tasks. Okay, now on to assigning resources to the tasks and making sure there would not be any resource contention. Chris had been working with the executives John, Greg, Sue, and Ken over the last couple weeks to secure additional resources that she might need for the project. She had been pretty successful, but it also looked like the core team members would end up doing a lot of the work themselves. Chris had updated the resource listing as she got concurrence on who was going to work on the project. You can see this updated resource listing in Table 10.7. She then went ahead and did the resource assignments on each task. She assigned the tasks on the critical path first and then did the rest of the tasks.

Originator

Open Date

Risk Description

Probability

Impact

1.

Tina Johnson

10/1

We are unhappy with our current shipping vendor. We have fired them. We are working on a new contract with a different company. This might or might not be completed in time for the trade show.

5

15

2.

Carol Hinnant

10/1

We have never done this type of project. How do we know our estimates are correct?

5

5

3.

Carl Price

10/1

The Web site project is currently behind schedule. This trend is expected to continue.

3

3

4.

Chris Williams

10/1

We have made assumptions about the way the show score is calculated.

2

4

5.

Robin Good

10/1

The marketing approach that we are using is based on an approach that Karla used at her last employer. That firm just declared bankruptcy.

2

2

6.

Carol Hinnant

10/1

The catalog publisher we use has reported that they are having problems getting the paper we are requiring.

4

1

Figure 10.5 VNLE master risk identification list

Respond?

Mitigate—We will need to apply the appropriate amount of padding to our tasks to help guarantee that the work will be done in time.

Budgeting—How Much?

Number

357

358

Chapter 10

She loaded all the results into Microsoft Project and did her resource analysis in that tool. She had tried doing it manually before but had found it really difficult to build resource histograms for a project this size. At least doing it manually a couple times helped her understand what Microsoft Project was doing magically for her. Table 10.7 Resources for VNLE

Resource Needed

How Many Available?

Who?

Project manager

1

Chris Williams

Executive sponsor

1

June Jackson

Core team

6

Bill Ricardo, Robin Good, Tina Johnson, Carol Hinnant, Carl Price, Karen French

VP Sales

1

Greg Peterson

VP Marketing

1

Karla Christie

VP Business Development

1

John Robinson

COO

1

Sue Kim

CIO

1

Ken Hale

Business development person

1

Jacob Liesel

Marketing person

2

Cathy Bull, Larry Katherine

Salesperson

4

Dale Christenson, Mike Boyd, Becky Rasmussen, Jane Noble

IT person

1

Bill Cowan

Logistics person

1

Kim Billing

Marketing materials vendor

1

Material R US

Booth construction subcontractor

1

Sales Specialists

VN Web project manager

1

Carl Price

Catalog department person

1

Eva Benjamin

Focus group

1

Focus group—Marketing Concepts

359

Budgeting—How Much?

Chris was pleased with the results of the assignments. You can see the list of the assigned resources in Table 10.8. She also finished the resource leveling and found no issues on the project with who was doing the work. The only real issue she discovered was the time required by the core team. She knew that they had regular jobs as well as what they needed to do with the project. How would they get all this project work done and still do their regular jobs? She decided to set up a meeting with the executives and make sure their regular job load could be lightened for the weeks they were booked on the project. She knew she had better get that meeting set up immediately if she was going to still meet with June on Friday as scheduled. Chris also decided to call a team meeting on Thursday. She wanted to walk through the schedule with the entire team and verify the work effort estimates with the real people doing the work. She wanted to make sure that every person agreed with the estimates. She knew that if they created it, they would own it. She needed to remember to tell them this is a preliminary plan because June had not approved it yet. Chris then remembered that, in the meeting with June, she needed to discuss the budget, too. She had completely forgotten to get resource rates from the Human Resources department. She now needed to see if she could still get that done before Friday. Table 10.8 VNLE Resource Assignments

Task

Resource Estimate

Duration Estimate

Work Effort Estimate

1.1 Gather previous trade show information

Business development person—Jacob Liesel

5 days

16 hours

1 project manager— Chris Williams

4 hours

6 core team members— Bill, Robin, Tina, Carol, Carl, Karen

4 hours each

continued

360

Chapter 10

Table 10.8 Continued

Task

Resource Estimate

Duration Estimate

Work Effort Estimate

1.2 Gather input from other departments

6 core team members— Bill, Robin, Tina, Carol, Carl, Karen

3 days

4 hours each

1.3 Establish marketing goals

1 project manager— Chris Williams

4 hours

1 VP Sales—Greg Peterson

2 hours

1 VP Marketing—Karla Christie

2 hours

1 VP Business Development—John Robinson

2 hours

1 COO—Sue Kim

2 hours

1 CIO—Ken Hale

2 hours

1 core team member— Robin Good

1 day

1 VP Marketing—Karla Christie 1.4 Determine target audience

1 core team member— Robin Good

4 hours 2 hours

1 day

1 VP Marketing—Karla Christie

4 hours 2 hours

1.5 Create draft marketing plan

1 core team member— Robin Good

3 days

8 hours

1.6 Review and revise draft plan with other departments

6 core team members— Bill, Robin, Tina, Carol, Carl, Karen

2 days

4 hours each

1 project manager— Chris Williams

4 hours

1 VP Sales—Greg Peterson

1 hour

1 VP Marketing—Karla Christie

1 hour

1 VP Business Development— John Robinson

1 hour

361

Budgeting—How Much?

Task

1.7 Create final marketing plan

2.1 Design the booth sales approach

Resource Estimate

Duration Estimate

1 COO—Sue Kim

1 hour

1 CIO—Ken Hale

1 hour

1 core team member—Robin Good 1 day

2 hours

1 marketing person—Cathy Bull

2 hours

1 VP Marketing—Karla Christie

1 hour

1 project manager—Chris Williams

1 hour

1 core team member—Bill Ricardo

2 days

8 hours

1 VP Sales—Greg Peterson

1 hour 1 day

1 project manager—Chris Williams

2.4 Design the marketing collateral

4 hours

1 salesperson—Dale Christenson

2.2 Create IT demo 1 core team member—Bill, Robin, requirements Tina, Carol, Carl, Karen

2.3 Design the trade show experience

Work Effort Estimate

1 core team member—Bill, Robin, Tina, Carol, Carl, Karen

4 hours each 4 hours

5 days

8 hours each

1 marketing person—Cathy Bull

8 hours

1 salesperson—Dale Christenson

8 hours

1 VP Sales—Greg Peterson

1 hour

1 VP Marketing—Karla Christie

1 hour

1 core team member— Robin Good

3 days

8 hours

1 marketing person— Cathy Bull

8 hours

1 VP Marketing—Karla Christie

1 hour continued

362

Chapter 10

Table 10.8 Continued

Task

Resource Estimate

Duration Estimate

Work Effort Estimate

2.5 Design the booth

1 core team member— Robin Good

3 days

8 hours

2.6 Determine vendor partnership strategy

2.7 Determine target vendors

2.8 Review and revise demo requirements

2.9 Design the demo

1 marketing person—Cathy Bull

8 hours

1 VP Marketing—Karla Christie

1 hour

1 core team member— Karen French

2 days

4 hours

1 business development person—Jacob Liesel

4 hours

1 VP Business Development— John Robinson

1 hour

1 core team member— Karen French

5 days

16 hours

1 business development person—Jacob Liesel

16 hours

1 VP Business Development— John Robinson

2 hours

6 core team members—Bill, Robin, Tina, Carol, Carl, Karen

1 day

2 hours each

1 IT person—Bill Cowan

2 hours

1 project manager—Chris Williams

1 hour

6 core team members—Bill, Robin, Tina, Carol, Carl, Karen

2 days

4 hours each

1 IT person—Bill Cowan

4 hours

1 project manager—Chris Williams

4 hours

363

Budgeting—How Much?

Task

Resource Estimate

Duration Estimate

2.10 Determine housing and travel requirements

6 core team members—Bill, Robin, Tina, Carol, Carl, Karen

1 day

1 project manager— Chris Williams 2.11 Gather marketing materials and booth shipping requirements

1 core team member— Tina Johnson

1 core team member— Tina Johnson

1 day

1 core team member— Tina Johnson

1 day

2 hours each 2 hours

3 days

1 logistics person—Kim Billing 2.14 Verify that pro1 project manager— duct inventory supports Chris Williams the marketing plan

2 hours each

2 hours

1 project manager— Chris Williams 2.13 Determine trade show on-site requirements

2 hours each

2 hours

1 project manager— Chris Williams 2.12 Determine catering requirements

Work Effort Estimate

8 hours

8 hours 1/2 day

1 Catalog department person— Eva Benjamin

1 hour 1 hour

3.1.1 Arrange flights and lodging

1 logistics person—Kim Billing

5 days

8 hours

3.1.2 Ship marketing material and booth

1 logistics person—Kim Billing

1 day

2 hours

3.1.3 Make catering arrangements

1 logistics person—Kim Billing

1 day

2 hours

continued

364

Chapter 10

Table 10.8 Continued

Task

Resource Estimate

3.1.4 Finalize trade show 1 core team member— on-site requirements Tina Johnson

Duration Estimate

1 day

1 project manager— Chris Williams 3.1.5 Verify that product inventory supports the trade show plan

2 hours each 2 hours

1 Catalog department person—Eva Benjamin 1/2 day 1 project manager— Chris Williams

3.1.6 Prototype the booth experience

Work Effort Estimate

1 core team member— Robin Good

1 hour 1 hour

2 days

4 hours

1 marketing person—Cathy Bull

4 hours

1 VP Marketing—Karla Christie

1 hour

3.1.7 Learn and practice the demo

4 salespeople—Dale, Mike, Becky, Jane

5 days

8 hours each

3.1.8 Establish premeetings with vendors

1 business development person—Jacob Liesel

3 days

4 hours

3.1.9 Build marketing collateral

1 marketing person— Cathy Bull

10 days

8 hours

3.1.10 Build the booth

3.1.11 Build the demo

Materials vendor—Material R US

FF price $2,500

1 logistics person—Kim Billing 10 days

8 hours

Booth construction subcontractor—Sales Specialist

FF price $50,000

1 IT person—Bill Cowan 1 core team member Robin Good

5 days

16 hours 8 hours

365

Budgeting—How Much?

Task

Resource Estimate

Duration Estimate

Work Effort Estimate

3.1.12 Test the demo

1 IT person—Bill Cowan

5 days

16 hours

1 core team member— Bill Ricardo

8 hours

3.1.13 Create trade show buzz

2 marketing persons— Cathy Bull, Larry Katherine

30 days

40 hours

3.1.14 Verify that the Web site is ready

1 project manager— Chris Williams

1 day

1 hour

1 VN Web project manager— Carl Price 3.1.15 Verify that the catalog is ready

1 core team member— Eva Benjamin

1 hour 1 day

1 project manager— Chris Williams 3.1.16 Verify marketing collateral with focus group

1 core team member— Robin Good

1 hours 10 days

Focus group—Marketing Concepts 3.1.17 Verify the booth build with focus group

1 core team member— Robin Good

1 core team member— Robin Good

2 days

1 core team member— Robin Good Focus group

2 days

1 day 2 days

Focus group 3.1.19 Verify the booth experience with the focus group

8 days

7 days

Focus group—Marketing Concepts 3.1.18 Verify demo with focus group

1 hour

2 days 1 day

2 days

2 days

1 day continued

366

Chapter 10

Table 10.8 Continued

Task

Resource Estimate

Duration Estimate

Work Effort Estimate

3.1.20 Get buzz feedback and make adjustments

1 core team member— Robin Good

15 days

10 days

3.2.1 Verify and correct logistics

1 project manager— Chris Williams

1 hour

1 VP Marketing—Karla Christie

1 hour

1 core team member— Tina Johnson

1 day

1 logistics person—Kim Billings 3.2.2 Manage the trade show event

1 project manager— Chris Williams

4 hours 4 hours

4 days

1 core team member— Robin Good

40 hours

40 hours

3.2.3 Staff the booth

4 salespersons—Dale, Mike, Becky, Jane

4 days

32 hours

3.2.4 Get feedback for vendor experience during event

1 business development person—Jacob Liesel

4 days

8 hours

3.2.5 Receive > 125 points for trade show

1 project manager— Chris Williams

1 day

1 hour

Review Questions 1. What is a budget? 2. What is an order of magnitude estimate, and when is it created? 3. In what processes are work effort estimates and duration

estimates used? 4. What is a loaded salary rate? 5. What is an average salary rate?

Budgeting—How Much?

6. What is a reserve? 7. What are two types of reserves? 8. What are the two differences between a project reserve and a

managerial reserve? 9. What is a fee? 10. What is budget reconciliation? 11. What is the cost baseline?

367

This page intentionally left blank

11 The Rhythm of Project Execution Furious activity does not necessarily equate to progress and is not a substitute for understanding. —Anonymous

Topics Covered in This Chapter All About Execution Creating the Baselines Getting into a Rhythm Quality Audits Teaming Politics Summary Case Study

This chapter is all about what has to be done when you execute your project. It seems pretty straightforward that your team will be performing the tasks of the project. But you will be amazed by all the activities that need to be done while those tasks are being performed. One of the activities that you might not be familiar with is the concept of quality audits. I introduce that concept in this chapter and talk about what gets audited. I also cover the subject of how many quality audits you might consider on your project. I finish that topic with the timings of quality audits. First, though, you have to set up a baseline. I talk about each type of baseline and then cover how to use them and the purpose of baselining in general. Next comes the idea of getting into a rhythm on your project. In “Teaming,” I talk about another element to use to develop the project team: training. Team members will not perform effectively if they are not trained to do the job properly. I cover the different types of training that might be needed. 369

370

Chapter 11

In “Politics,” I talk about obstacles to executive communication. You might run into a couple executive types you have dealt with before: the Mad Hatter and the Executive Ostrich. In the case study, Chris spends most of her week getting ready for the meeting with June. She still has to complete the budget and the schedule to properly brief June. She gets caught up in a lot of meetings, though, and has a lot of details to work through to finish in time.

All About Execution Finally, you are ready to begin the execution process of your project. It seems like you’ve been planning forever. You’ll soon see that it was well worth it: You can much easier execute a project that you have planned well than a project that you have thrown together. You have created a workable plan and have anticipated what can possibly go wrong. You’ve also actually built mitigation plans, just in case things do go wrong. You are ready to go. So what needs to be done now that you are executing the project? Do you need to do specific activities, or is it simply a matter of performing each task in the project schedule? Actually, you must take care of a handful of executing activities. I cover those in this chapter. You’ll also see in Chapter 12,“Keeping the Project on Track,” and Chapter 13,“Controlling Changes,” that all the activities discussed in these three chapters get done while executing the project. You will be very busy executing the project, controlling changes, and keeping everything on track. Let’s start with a concept that sets the stage for all the work activities in these chapters: creating the baselines.

Creating the Baselines A baseline is the line you draw in the sand that states,“This was my intention. This is what I planned to do.”You always create a project plan with the best possible way of getting the work done. You might modify your planning at the end to get to a certain objective, but you understand exactly what the trade-offs are in getting to the objectives. You build the best possible plan and save it. This is your baseline. It provides a point in time for you to compare your plans against what is actually happening. You need to create several baselines when you have finished your project planning:

The Rhythm of Project Execution

371

• Schedule baseline—The schedule baseline is a copy of the tasks that your team must complete to execute the project on time. It is usually a copy of the network diagram or a Gantt chart of the schedule, showing each task, the predecessors and successors for each task, as well as the needed duration of each task. You’ll want to save this copy at the end of planning before any actual executing work begins. You can save this copy via either a project management software program, a spreadsheet, or any other electronic means. A hard copy will also do, if you value simplicity. The best way is to let your project management software keep the baseline for you; it will also do comparisons for you when you want to know if you are on track or off track. Really cautious project managers also store a copy of their project schedule in their project management software, just in case they lose their current copy of the project.

Baselines in Microsoft Project Microsoft Project creates a baseline for you and stores it for future comparisons. In fact, it has the capability to create several different baselines. For more on this topic, see Microsoft Project for Mere Mortals, by Patti Jansen.

• Cost baseline—You create the cost baseline during the budgeting process. This is the sum of all the work of the tasks of the project by resource and resource rate needed per task. Another view of the cost baseline is the budget minus any fees, reserves, or contingency money. This could be a spreadsheet that you’ve created that depicts all the budget components for your project. Again, the best way to create this kind of baseline is to let your project management software keep the baseline for you. The cost baseline will be stored within your project software tool if you populate the resource sheet with the project resources and their resource rate. You will also be able to run reports to do comparisons on what you’ve planned to spend versus what you have spent. Your organization might also have mechanized tools or spreadsheets that you must fill in for your accounting department. Find out what is required before you settle on a method.

372

Chapter 11

• Product requirements baseline—You created the requirements for the product of the project early in your planning process. You now need to baseline those requirements before you begin to create the product and basically execute those requirements. This is probably a text document, so you can create a baseline by doing the following: 1. Get a signature from the project client on the completeness and approval of the requirements. 2. Save a copy or use document versioning to show the version of the product requirements that were approved. Use this approved document as a marker to show the features and functions of what you plan to create; it will become very useful when people ask for changes in the product. You’ll get into that discussion in Chapter 13. • Quality baseline—The quality baseline is the information that you gathered in your quality planning process. This information spells out the quality objectives that you have planned for the project. You’ll again use this information while you are executing your quality plan, to compare your quality performance back to your objectives in your plan. You’ll probably get signatures and do version control to create this baseline. Putting all these baselines together creates what the PMBOK® Guide calls the performance measurement baseline. This is the sum and collection of all the parameters that you use to measure whether you are executing your project correctly. This includes all the baselines we just talked about. You are executing your project correctly if you will successfully deliver according to the triple constraints of time, budget, and the agreed-upon Measure of Performance. When can you change a baseline or rebaseline? Good question. Most organizations have set rules regarding when a project manager can rebaseline. The rule of thumb is only after some type of major event. Say, for instance, that you have signatures on the product requirements, and you’ve built the project schedule and budget to build that product. A major event occurs like one of the following:

The Rhythm of Project Execution

373

• The executive in charge of the product leaves the organization and a new executive joins the firm. The two have different visions for the product. • A competitor launches a product very similar to yours. You get the picture. The event makes you go back and rethink and redo the requirements; therefore, you have to replan the entire project. This is the type of situation that requires you to rebaseline different elements or the whole project because you are basically starting over on your project planning. The key here is to get approval from your project sponsor before you baseline. You can’t rebaseline just because something goes wrong; it has to be major and approved.

Getting into a Rhythm

Figure 11.1 The rhythm of execution

Status Meeting

Send Communication

Tasks Completed

Status Meeting

Issues Resolved

Tasks Completed

Status Meeting

Issues Resolved

Tasks Completed

Status Meeting

Tasks Completed

Tasks Completed

Activity Level

You’ve set your baseline, and the team begins the first set of tasks. You are on your way! It’s time to establish a few fundamental activities that will serve you and the project until you deliver the project. Here you try to establish a rhythm for your project. Successful projects have an unmistakable rhythm to them. Figure 11.1 shows the type of tempo you are looking for. You are looking for a steady drum beat of activities, like a heart rate monitor.

374

Chapter 11

You will strive throughout the project to keep this rhythm going and to not allow anything to disrupt it.

Status Meetings You can see from the rhythm diagram that the high point for your activity is the status meeting. This is your first fundamental activity. Now is the time to set the frequency of the status meetings. How often do you need the team to meet and discuss the status, issues, and successes? Chapter 4 talked about setting the frequency for how long a task can be out of control without you knowing about it. You must take that into consideration along with the drum beat. How often will you need the team to meet to talk about the status and issues and to keep them motivated? Most project managers set their status day to once a week, once every two weeks, or once a month, depending on the previous factors. People tend to stay away from Mondays and Fridays because a lot of people take these days off for holidays or vacation. You need to understand the culture of your organization and determine what time of day is most conducive to having your status meeting

Issues Management You also should establish your issues management process now. This is another activity that will help you set the rhythm of your project. Chapter 4, “Laying Out the Work,” briefly covered issues and defined an issue as an item that needs discussion or research before a task can be completed. Figure 11.2 depicts the process you will establish for managing issues. An identified issue should be brought to the project manager if urgent, or to the status meeting if not. Document the issue at the status meeting, making sure that you establish a due date. Assign one person to be accountable for resolving the issue. Also document the other people required to solve the issue. The people who need to resolve the issue should discuss and resolve the issue outside the status meeting. They should bring back information about their progress to the status meetings as they work through the issue. They also can bring back information about their final resolution when they reach that point. The entire team can discuss and document the issue and resolution at that status meeting. The issue then is closed after this last step. Figure 11.3 shows a sample issue-management form for your future use.

The Rhythm of Project Execution

At the status meeting

375

Outside of the status meeting

A new issue is discussed

Someone identifies an issue

The issue is documented

The designated people discuss and resolve

The originator and people needed to resolve are noted. A due date is given. One person takes accountability for getting resolution

Existing issues are updated with status

Resolutions to issues are discussed and documented

Figure 11.2 Issues management process

Issue # 1.

Originator Joe S.

Open Date

Due Date

Status

Issue Description

Resp

4/15/07

4/30/07

Yellow

We cannot determine if funding was Sue provided for the development resources. Research with Finance and Executive Sponsor.

Resolution/Comments/Status

Closed Date

4/20—Meeting held with executive sponsor. Need meeting with Finance.

Figure 11.3 Issues management form

Your job as the project manager is to manage the process and hold people accountable for getting the issues resolved. You also need to set up a file or

376

Chapter 11

database of issues so the team can review issues and their resolutions when they can’t attend the status meeting. You have established these two fundamental activities; you now can get into a rhythm for your project. The next critical step is to just get the work of project execution done.

The Work of Project Execution So far, the discussion has been pretty general concerning the work of project execution. Until now, it has simply been characterized as “successfully execute some tasks.” Let’s get specific now and talk about the types of work that get done while you execute your project.

Types of Work The types of work include the following: • Performing the tasks of the project—First and foremost, you and your team must perform every task of the WBS in the sequence that you laid out in your network diagram. You must do all this work with the intention of fulfilling the objectives that were originally requested of your project. You must course-correct if you perform the tasks that have been planned and they are not fulfilling the objectives of the project. • Staffing the project—You must staff the project as the need arises. You have already determined who will do what task. Now is the time to bring these people to the project and put them to work. You might need to provide some type of orientation to get these people ready to work and perform effectively. • Training resources—You might also have to supplement your project resources’ skills. Some team members might need a specific piece of training to work effectively. Every resource might need some level of training if you are working in a brand-new technology or process discipline. • Managing human resources—You are accountable for the performance of the resources on your project, regardless of the type of organization that you work in (projectized, matrixed, or functional). Thus,

The Rhythm of Project Execution

•

•

•

•

•

•

377

you must manage the resources. You must assign tasks, overcome roadblocks, follow up on work, and provide feedback. You must gather documentation on the performance of each team member and provide that to other supervisors at the end of the project. Managing other resources—You also must manage your resources during execution if you plan to use other types of resources. You must make sure that the bulldozer you need for Task 57 is delivered just before that task. You also must make sure that it is returned as soon as Task 57 is completed so you don’t pay late fees and expend more of your budget than was allocated. Installing methods and procedures—You might have done some very detailed planning on certain tasks while you were planning the project. This detail might include things such as step-by-step methods or procedures for getting the work done the right way. Now is the time to implement any of these work methods. Collecting work performance information—Earlier in this chapter, you established a status meeting as you set the rhythm of the project. Here is where you collect information from each team member regarding how the work is being performed. I talk about exactly what information you will collect in the next chapter, on monitoring and controlling the project. Reporting on project information—You must accumulate data regarding the performance of the project tasks. You must report on the data you’ve gathered, depending on your organization’s requirements for status reports. Even if your organization has no reporting requirements, you must provide reports based on what you have defined in your communication plan. Executing your communication plan—You also start to execute your communication plan. You must determine which elements of your plan need to be done at what point in time while the project is being executed. Implementing approved changes—You’ll find that as you and your team execute the project plan, someone might ask for changes to what has been originally planned. These requests for changes will go through an entire process that we describe in Chapter 13. Some will be denied, and some will be approved. Those that are approved will be completed as part of your execution process.

378

Chapter 11

• Validating project deliverables—As the team creates the product of the project, you must control the creation of those deliverables. You also must spend some time validating those deliverables back to the original request or requirements. • Gathering lessons learned—A lot of organizations collect lessons learned at the end of the project. Organizations that are adopting industry best practices are finding that it’s best to collect lessons learned all the way through the project. That way, the team members learn from their mistakes right away and have a chance to correct some of their problems along the way instead of waiting until the next project. This also allows the team to find out what they are doing right so they have a chance to continue with that winning performance. • Performing risk management—The team has a chance to manage the risks identified in the planning stage as the project tasks are being performed. The team members can put their response plans into place. This is also the time to gather new risks and continue managing the top 25 percent on the master risk identification list. And all you thought you were going to do was manage the completion of the project tasks! You probably feel like a juggler right now trying to figure out exactly how you will accomplish all of this. Is that you in Figure 11.4? Not to worry, though. You have everything covered in your project plan if you have done the level of planning that I have discussed all the way through this book. In it, you have documented every aspect of the planning, from how you will perform risk management to what training is needed for every resource on the project. Oh, you say I haven’t covered that yet? Well, this is covered in the “Teaming” section of this chapter. You need to do one more piece of work while you are executing your project: a quality audit.

Quality Audits You laid out activities that your resources must perform to guarantee the quality of the product you are creating. You execute those quality activities during the execution of your project. You might also find that the activities you have planned for quality are not substantial enough to guarantee the

The Rhythm of Project Execution

379

quality. How will you know if you need to implement more quality activities? A quality audit is the answer.

Install methods and procedures

Staff the project

Execute the tasks of the project Manage other resources Collect work performance information

Report out on project performance

Execute the communication plan

Implement approved changes

Validate project deliverables Train resources Gather lessons learned Perform risk management Manage human resources Conduct quality audits

Figure 11.4 Juggling the work of execution

A quality audit is a review that determines whether the project is complying with the quality standards that were set in the planning stage of the project. Someone outside the project team usually does the quality audit, to be objective in a review of the project. The auditor looks at two different sets of information in this review: • The product of the project—The auditor will verify that the product of the project is meeting the requirements that have been created to describe the product. The auditor will also verify that the procedures for creating the product are being used successfully. • The processes of the project—The auditor will review the processes of the project and determine whether they are being performed correctly. The auditor will also conduct an analysis to make sure that these processes are sufficient to manage the project to a successful completion.

380

Chapter 11

The objective of the quality audit is to look for ineffective and inefficient processes and procedures that will hamper the quality of the product and the project. Remember, the objective of the project is to deliver to the triple constraints of the MOP, cost, and time. You won’t fulfill the triple constraints if your project processes are not working. Now let’s talk about the timing of quality audits. You need to perform a quality audit at least twice on your project. You might even need more than two audits, depending on the length of the project. The first audit is performed at the end of the planning stage and the beginning of the execution stage of your project. This audit inspects the processes and procedures that have been designed for the execution stage. The auditor does a document check to verify what was created and make sure that the documents are sufficient for the size and complexity of your project. The team should immediately institute any recommendations that the auditor provides, before the team gets into the habit of executing an inefficient process. The second quality audit should be performed after the team has been working on project execution for a while. Here the auditor makes sure that the processes is being executed correctly. The auditor also inspects the deliverables of the process to make sure the process is producing the right quality of deliverable. You can see now why more than two audits might be needed. A project with a year length might be starting a new deliverable every couple of months. You might consider bringing in an auditor shortly after work begins on the next major deliverable, if your project can afford it. Another way to use a quality audit is in response to problems. Perform an audit when you start to see variance in the work being done. Bringing in an auditor when you start to see problems can be a diagnostic tool before your project really goes way off track. I talk more about this in the next chapter. Another important activity of project execution is developing the project team. Let’s move on to the “Teaming” section and talk about team development.

Teaming Your team must be a cohesive unit that performs well together during project execution. It is your job as the project manager to make sure this is happening. Two elements are important to developing your project team. The

The Rhythm of Project Execution

381

first is improving the feelings of cohesiveness so greater productivity takes place through teamwork. The “Teaming” sections in the last several chapters have referred to the Tuckman model, and I’ve provided ideas on what to do to get your team to the performing stage of team development. Hopefully by now you have done some extensive work to get your team performing well. You have used concepts such as doing team-building activities, setting up team norms, and providing rewards and recognition to develop the team. But you still need to address one more aspect of team development: training. A team will not complete its development until the team members feel secure in their ability to get the job done. Training involves many different aspects. I cover a few here that are most integral to the successful completion of your project. The first is skills-based training. Your project could be bringing a new way of doing work or a new technology to your organization. You will want to make sure that your staffing management plan covers this type of training needed for the resources of your project. Make sure that the training provided is just in time: You don’t want to have to retrain your team members because the class was two months before they actually got to start the work. The second type of training to provide is training on the project itself. It might be wise to hold an orientation session for each new team member who joins the project. This would include meeting the rest of the project team and walking through the project plan. Be sure to spend sufficient time on all elements of the project plan. Make sure that you cover the areas the new team member will be working in and that the other team members understand them. Also be sure to cover the team norms and rules of engagement that you all have agreed upon. You’ll want to get concurrence on the idea that the team members will comply with the team norms. The next type of training that you will want to provide is based on the individual’s performance on the project. You might find as you work with certain team members that they lack either the technical or the management skills necessary to satisfactorily perform their job. You’ll figure this out by observing their performance and getting feedback from other team members. Another tell-tale clue is tasks that are running late. Sometimes people just don’t have the skills to get the work done. You must create training opportunities as the need arises on your project. You might have to send the individual to formal training, or you might find a way to give on-the-job instruction.

382

Chapter 11

Sometimes all a new team member needs is a little mentoring to feel confident enough to get the task done. Polish off your general management skills and determine the best approach for each individual team member. Continue to monitor team development through the rest of the project. Remember that the dynamics of the team change every time a new team member joins the team. Now let’s talk about information distribution and executives who are hard to pin down.

Politics Providing project information is one of the most important activities of project execution. You will spend a lot of time doing this work. Some sources will tell you that project communication is 90 percent of a project manager’s job, yet sometimes it’s not very easy to get done. You will face obstacles depending on the type of executive personalities you are dealing with. Two of the most interesting executive personalities are the Mad Hatter and the Executive Ostrich. The Mad Hatter is the executive who is always running through the hall looking at a wristwatch and proclaiming,“I’m late! I’m late! For a very important date!” These executives are always on the go. They are often late for their meetings with you, if they haven’t first cancelled on you. When you do get to talk to them, it seems like their attention is waning. And most times they cut your meetings short. The Executive Ostrich has his or her head in the sand and won’t pay any attention to bad news. Most times these executives won’t even talk to you because they don’t want to hear bad news. Sometimes they resemble the Mad Hatter, but their motivation isn’t too much to do: It is “Just make it happen. Don’t tell me any bad news.” How do you handle these two types of executive personalities? The approach is pretty much the same for both: • Keep sending the information—You have to provide a status update, no matter what your executives say or how busy they are. You have to give the good news, the potential risks, and, if necessary, the bad news. Send them a copy of the monthly status report, if you send one out. Do so regardless of whether they read it.

The Rhythm of Project Execution

383

• Leave sticky notes on their desk with a quick update—Try leaving a sticky note on your executives’ desks about an important update if you suspect they’re not reading their status reports. Be sure not to waste their time with trivial information; limit this technique to just the important things that they must know. • Leave a 15-second voice mail—You can also try a 15-second voice mail. The Mad Hatter doesn’t have time for a lengthy message, and the Executive Ostrich doesn’t want bad news, so make it quick. Keep your messages brief. Practice crafting a quick message a time or two with just the most important bullets before you leave that voice mail. • Find out how best to get them the information—Chapter 3,“How Big Is This Project?,” talked about getting to know the executive’s administrative assistant. You can talk to this person now about how best to get information to your executive. You might find that leaving information with the administrative assistant is the most effective means of executive communication. Keep sending the information, regardless of the method you choose. You never want to be in the situation when something bad happens on the project and the executive says,“Why didn’t you tell me?” One of the key tools you can use in this type of a situation is a project diary. Get yourself a notebook or open a document file, and keep track of everything that happens on the project. Yes, everything. Some of the best project managers I know keep a detailed diary of every conversation, every e-mail sent, every problem, etc. The objective is to make sure that you are covered. An executive might comes back to you and say,“Why haven’t you kept me informed?,” but you’ll have a diary describing every item you’ve sent.

Summary This chapter talked about the rhythm of execution and the importance of setting a rhythm for your project team. We covered all the different types of baselines that you need to set to compare what you are executing to what you planned to do. We then talked about all the activities that you must do when executing the project. We spent a little more time on quality audits. In the “Teaming” section, we described another element of team development: training. We talked about three different types of training: skill training, team training, and performance training.

384

Chapter 11

The “Politics” section talked about some different personality types of project executives. Sometimes it is difficult to get the project information out and understood. We covered a couple of strategies that you can use when dealing with these different personality types. Now back to the case study, where Chris Williams is still working on finishing the schedule and the budget. She has a meeting coming up shortly with June and still has a lot of work to complete.

Case Study Chris rushed around the rest of the week trying to finalize the schedule and budget for her meeting with June on Friday afternoon. She was able to meet with the Human Resources manager on Wednesday morning. The manager couldn’t just turn over figures to Chris, as Chris had hoped. He needed a day to create either the loaded or the average salary rates. He also wanted to talk to June and see what her expectations were on how realistic the rates needed to be. He promised to get the rates to Chris no later than the close of business on Thursday. Scheduling the meetings with the executives didn’t go as well as Chris had hoped. She was able to set up only individual meetings instead of one joint meeting. That meant that she would have four meetings of at least 30 minutes to get through between Wednesday and Thursday afternoon. She wanted to leave Friday morning free to get ready for her meeting with June. She knew that would probably work out; she just didn’t have much time to do four meetings instead of one. On Wednesday morning, Chris walked through the preliminary schedule with the core team and the new team resources. She was amazed at how the dynamics had changed with the introduction of a few new team members. Her core team was kind of quiet, for a change. She was getting used to their storming and performing behaviors. It looked to her that they had stepped back to the forming stage of team development. She made a note to herself to schedule a team-building session next week with all of them; they needed a chance to get to know each other better. And she knew she needed to get them through forming, storming, and norming as fast as possible.

The Rhythm of Project Execution

385

Chris held two of the meetings with the executives on Wednesday. She had a chance to meet with Greg Peterson regarding Bill Ricardo’s work on the project. They agreed that Bill’s sales quotas would be decreased appropriately when he was tied up with the project. Chris also told Greg that she would provide a review of Bill’s work at the end of the project. The project would take up six months of Bill’s life, and Chris wanted to make sure that Greg was correctly apprised about the work Bill did. She also knew that if she had appraisal authority, she would have more authority with Bill. She knew Greg wouldn’t have a problem with receiving an appraisal from her; she had heard through the grapevine that he seldom did appraisals on his subordinates anyway. Her next meeting was with Ken Hale, her boss and Carl’s boss. Ken was pretty much in tune with project management activities and expected to free up Carl so that his entire workload consisted of the two projects he was working on: VNLE and the VN Web project. He also expected a full appraisal of Carl’s work on the project and asked Chris to sit with him when he was doing Carl’s final year-end appraisal. He wanted to make sure that Chris’s appraisal had equal weight when the final appraisal was completed. Chris was pretty pleased with the outcome of the meeting. Working for Ken was turning out better than she hoped. He also understood project management and accountability and authority really well. The only setback that Chris had on Wednesday was the fact that Karla, Robin’s supervisor, cancelled her meeting and rescheduled it for Thursday. Chris was more concerned about Robin’s schedule than that of anyone else. Most of Robin’s work was on the critical path of the project, and Chris wanted to make sure that she would be able to get it all done and not be hampered by her regular business activities. Well, she’d have to talk to Karla tomorrow. On Thursday morning, Chris got an e-mail from the HR manager with the rates shown in Table 11.1. She was really pleased to get the rates earlier than she had been told, but she couldn’t work on the budget then because she needed to run off to another meeting. She would have to get back to it later that day.

386

Chapter 11

Table 11.1 Resource Rates for VNLE

Resource Needed

Resource Rate Per Day

Who?

Project manager

$250

Chris Williams

Executive sponsor

$750

June Jackson

Core team

$200 each per day

Bill Ricardo, Robin Good, Tina Johnson, Carol Hinnant, Carl Price, Karen French

VP Sales

$700

Greg Peterson

VP Marketing

$500

Karla Christie

VP Business Development

$500

John Robinson

COO

$650

Sue Kim

CIO

$650

Ken Hale

Business development person

$175

Jacob Liesel

Marketing person

$190 each per day

Cathy Bull, Larry Katherine

Salesperson

$200 each per day

Dale Christenson, Mike Boyd, Becky Rasmussen, Jane Noble

IT person

$190

Bill Cowan

Logistics person

$100

Kim Billing

Marketing materials vendor

$1,000 per assignment

Material R US

Booth construction subcontractor

$5,000 per booth

Sales Specialists

VN Web project manager

$250

Carl Price

Catalog department person

$100

Eva Benjamin

Focus group

$5,000

Focus group—Marketing Concepts

Chris left for her next meeting, with Sue,Tina and Carol’s supervisor. Sue was pretty set in her ways in running her department and was not much of an

The Rhythm of Project Execution

387

advocate for project management. She said she would do what she could with Tina and Carol’s workload, but her people were expected to work overtime whenever there was extra work to do. Sue told Chris that she would make sure that Tina and Carol knew this was her expectation. Sue then excused herself from the meeting to take a quick call. She told Chris she’d be back in five minutes. Sue did come back in 5 minutes but was still on her cell phone and continued to talk for another 15 minutes. She wasted Chris’s time for a half-hour, until they finally got back to the discussion of the project and Sue’s subordinates. Chris offered appraisal information on the two women, and Sue told her that would be nice and that she’d be glad to look over the feedback. She also stated that she knew what her subordinates were doing and probably wouldn’t need anything additional. Chris left Sue’s office and mumbled under her breath,“What a waste of time!” Chris then went back to her desk and answered a couple phone calls and emails before she headed to her next meeting, with John. John was very agreeable to what Chris wanted and assured her that he would make his people available for the project. He had heard from June about the importance of the project and knew these new vendors could make or break this new launch. He did have some questions for Chris about the project, though. He and Chris spent the next hour discussing John’s questions. Chris made a mental note to update the communication plan on John; he would need a lot more detail to satisfy his communication needs. Chris got back to her desk after 2 p.m. Her meeting with Karla wasn’t until 5 p.m., so she had a couple hours to work on the project schedule and budget. Chris again analyzed the critical path. This time she was looking for the tasks that Carol and Tina had to perform. She knew she had a risk because of Sue’s stance about project work and overtime. Tina had two critical path tasks. Carol had none. She decided that she could absorb the risk of the overtime for these two tasks. Chris then started her calculations for the cost baseline on her project. She was able to get those done fairly quickly. You can see her finished work in Table 11.2. Now she needed to meet with Karla, Robin’s boss.

388

Chapter 11

Table 11.2 Cost Per Task for VNLE

Task

1.1 Gather previous trade show information

1.2 Gather input from other departments

1.3 Establish marketing goals

Resource Estimate

Duration Estimate

Work Effort

Cost of Task

Business development person—Jacob Liesel

5 days

16 hours

$350

1 project manager— Chris Williams

4 hours

$125

6 core team members— Bill, Robin, Tina, Carol, Carl, Karen

4 hours each

$600

4 hours each

$600

1 project manager— Chris Williams

4 hours

$125

1 VP Sales—Greg Peterson

2 hours

$175

1 VP Marketing— Karla Christie

2 hours

$125

1 VP Business Development— John Robinson

2 hours

$125

1 COO—Sue Kim

2 hours

$162.50

1 CIO—Ken Hale

2 hours

$162.50

4 hours

$100

2 hours

$125

4 hours

$100

2 hours

$125

8 hours

$200

6 core team members— Bill, Robin, Tina, Carol, Carl, Karen

1 core team member— Robin Good

3 days

1 day

1 VP Marketing—Karla Christie 1.4 Determine target audience

1 core team member— Robin Good

1 day

1 VP Marketing—Karla Christie 1.5 Create draft marketing plan

1 core team member— Robin Good

3 days

389

The Rhythm of Project Execution

Task

Resource Estimate

Duration Estimate

Work Effort

Cost of Task

2 days

4 hours each

$600

1 project manager— Chris Williams

4 hours

$125

1 VP Sales—Greg Peterson

1 hour

$87.50

1 VP Marketing— Karla Christie

1 hour

$62.50

1 VP Business Development—John Robinson

1 hour

$62.50

1 COO—Sue Kim

1 hour

$81.25

1 CIO—Ken Hale

1 hour

$81.25

2 hours

$50

2 hours

$47.50

1 hour

$62.50

1 hour

$31.25

4 hours

$100

1 salesperson—Dale Christenson

8 hours

$200

1 VP Sales—Greg Peterson

1 hour

$87.50

4 hours each

$600

4 hours

$125

1.6 Review and 6 core team members— revise draft plan with Bill, Robin, Tina, Carol, other departments Carl, Karen

1.7 Create final marketing plan

1 core team member— Robin Good

1 day

1 marketing person— Cathy Bull 1 VP Marketing— Karla Christie 1 project manager— Chris Williams 2.1 Design the booth sales approach

2.2 Create IT demo requirements

1 core team member— Bill Ricardo

6 core team members— Bill, Robin, Tina, Carol, Carl, Karen 1 project manager— Chris Williams

2 days

1 day

continued

390

Chapter 11

Table 11.2 Continued

Task

2.3 Design the trade show experience

2.4 Design the marketing collateral

2.5 Design the booth

Resource Estimate

Duration Estimate

Work Effort

Cost of Task

6 core team members— Bill, Robin, Tina, Carol, Carl, Karen

5 days

8 hours each

$1,200

1 marketing person—Cathy Bull

8 hours

$190

1 salesperson—Dale Christenson

8 hours

$200

1 VP Sales—Greg Peterson

1 hour

$87.50

1 VP Marketing—Karla Christie

1 hour

$62.50

8 hours

$200

1 marketing person— Cathy Bull

8 hours

$190

1 VP Marketing—Karla Christie

1 hour

$62.50

8 hours

$200

1 marketing person—Cathy Bull

8 hours

$190

1 VP Marketing—Karla Christie

1 hour

$62.50

4 hours

$100

1 business development person—Jacob Liesel

4 hours

$87.50

1 VP Business Development—John Robinson

1 hour

$62.50

16 hours

$400

1 business development person—Jacob Liesel

16 hours

$350

1 VP Business Development— John Robinson

2 hours

$125

1 core team member— Robin Good

1 core team member— Robin Good

2.6 Determine vendor 1 core team member— partnership strategy Karen French

2.7 Determine target vendors

1 core team member— Karen French

3 days

3 days

2 days

5 days

391

The Rhythm of Project Execution

Task

2.8 Review and revise demo requirements

2.9 Design the demo

Resource Estimate

Duration Estimate

Work Effort

Cost of Task

6 core team members— Bill, Robin, Tina, Carol, Carl, Karen

1 day

2 hours each

$300

1 IT person—Bill Cowan

2 hours

$47.50

1 project manager—Chris Williams

1 hour

$31.25

4 hours each

$600

1 IT person—Bill Cowan

4 hours

$95

1 project manager—Chris Williams

4 hours

$125

2 hours each

$300

2 hours

$62.50

2 hours

$100

6 core team members—Bill, Robin, Tina, Carol, Carl, Karen

2.10 Determine housing 6 core team members—Bill, and travel requirements Robin, Tina, Carol, Carl, Karen

2 days

1 day

1 project manager—Chris Williams 2.11 Gather marketing materials and booth shipping requirements

1 core team member— Tina Johnson

1 day

1 project manager— Chris Williams 2.12 Determine catering requirements

1 core team member— Tina Johnson

2 hours $62.50 1 day

1 project manager—Chris Williams 2.13 Determine trade show on-site requirements

1 core team member— Tina Johnson

3 days

1 logistics person—Kim Billing 2.14 Verify that product 1 project manager—Chris Williams inventory supports the marketing plan

1/2 day

1 Catalog department person— Carol Hinnant 3.1.1 Arrange flights and lodging

1 logistics person—Kim Billing

5 days

2 hours

$100

2 hours

$62.50

8 hours

$100

8 hours

$100

1 hour

$31.25

1 hour

$50

8 hours

$100 continued

392

Chapter 11

Table 11.2 Continued Resource Estimate

Duration Estimate

Work Effort

Cost of Task

3.1.2 Ship marketing material and booth

1 logistics person—Kim Billing

1 day

2 hours

$40

3.1.3 Make catering arrangements

1 logistics person—Kim Billing

1 day

2 hours

$40

3.1.4 Finalize trade show on-site requirements

1 core team member— Tina Johnson

1 day

2 hours

$100

2 hours

$62.50

1 hour

$25

1 project manager—Chris Williams

1 hour

$31.25

1 core team member—Robin Good 2 days

4 hours

$100

1 marketing person—Cathy Bull

4 hours

$95

1 VP Marketing—Karla Christie

1 hour

$62.50

Task

1 project manager—Chris Williams 3.1.5 Verify that product 1 Catalog department person— inventory supports the Carol Hinnant trade show plan

3.1.6 Prototype the booth experience

1/2 day

3.1.7 Learn and practice the demo

4 salespeople—Dale, Mike, Becky, Jane

5 days

8 hours each

$800

3.1.8 Establish premeetings with vendors

1 business development person— Jacob Liesel

3 days

4 hours

$87.50

3.1.9 Build marketing collateral

1 marketing person— Cathy Bull

10 days

8 hours

$190

Materials vendor—Material R US 3.1.10 Build the booth

1 logistics person—Kim Billing

FF price $2,500 $2,500 10 days

Booth construction subcontractor—Sales Specialist 3.1.11 Build the demo

1 IT person—Bill Cowan 1 core team member—Robin Good

5 days

8 hours

$100

FF price $50,000

$50,000

16 hours $380 8 hours

$200

393

The Rhythm of Project Execution

Task

Resource Estimate

Duration Estimate

Work Effort

Cost of Task

3.1.12 Test the demo

1 IT person—Bill Cowan

5 days

16 hours

$380

8 hours

$200

1 core team member—Bill Ricardo 3.1.13 Create trade show buzz

2 marketing persons— Cathy Bull, Larry Katherine

30 days

40 hours $1,900

3.1.14 Verify that the Web site is ready

1 project manager—Chris Williams

1 day

1 hour

$31.25

1 hour

$25

1 hour

$25

1 hour

$31.25

8 days

$1,600

7 days

$35,000

2 days

$400

1 day

$5,000

2 days

$400

1 day

$5,000

2 days

$400

1 day

$5,000

10 days

$2,000

1 VN Web project manager— Carl Price 3.1.15 Verify that the catalog is ready

1 core team member— Carol Hinnant

1 day

1 project manager—Chris Williams 3.1.16 Verify market- 1 core team member— ing collateral with Robin Good focus group

10 days

Focus group—Marketing Concepts 3.1.17 Verify the booth 1 core team member—Robin Good build with focus group

2 days

Focus group—Marketing Concepts 3.1.18 Verify demo with focus group

1 core team member—Robin Good

2 days

Focus group 3.1.19 Verify the booth 1 core team member—Robin Good experience with the focus group

2 days

Focus group 3.1.20 Get buzz feedback and make adjustments

1 core team member—Robin Good

1 project manager— Chris Williams

15 days

1 hour

$31.25 continued

394

Chapter 11

Table 11.2 Continued Resource Estimate

Task

Duration Work Estimate Effort

1 VP Marketing—Karla Christie 3.2.1 Verify and correct logistics

1 core team member— Tina Johnson

1 day

1 logistics person—Kim Billings 3.2.2 Manage the trade show event

1 project manager— Chris Williams

4 days

1 core team member— Robin Good

Cost of Task

1 hour

$62.50

4 hours

$100

4 hours

$50

40 hours

$1,000

40 hours

$800

3.2.3 Staff the booth

4 salespersons—Dale, Mike, Becky, Jane

4 days

32 hours

$3,200

3.2.4 Get feedback for vendor experience during event

1 business development person—Jacob Liesel

4 days

8 hours

$175

3.2.5 Receive > 125 points for trade show

1 project manager— Chris Williams

1 day

1 hour

$31.25

$129,298

The meeting with Karla lasted until 7 p.m. Karla’s staff is not very large, so, needless to say, she was hesitant about trying to lighten Robin’s workload. The problem was that not too many people can do what Robin does for the organization. Chris discussed the tasks that Robin needed to do and the concept of critical path, and Karla then understood the importance of freeing up Robin for the project work. Karla also didn’t understand the appraisal concept. Chris had to explain the concepts of accountability and authority in project management to her. Again, this took a while, but at the end, Karla said she would welcome Chris’s appraisal and together the two of them would determine Robin’s overall appraisal and her pay raise for that year. Success!

The Rhythm of Project Execution

395

By the end of the meeting, Chris was pretty tired. She decided to go home and get a good night’s sleep and attack the rest of the budget in the morning. She also decided that she had better get up early to get everything ready for her meeting with June. What a day!

Review Questions 1. What is a baseline? 2. What is a schedule baseline? 3. What is a cost baseline? 4. What is the product requirements baseline? 5. What is the quality baseline? 6. When you put all these baselines together, what are they called? 7. How often should a project manager conduct a status meeting? 8. What is an issue? 9. What are some of the types of activities performed during project

execution? 10. Why are quality audits performed during project execution?

This page intentionally left blank

12 Keeping the Project on Track There are moments when everything goes well, but don’t be frightened—it won’t last. —Jules Renard

Topics Covered in This Chapter Monitoring and Controlling Variance Other Monitoring and Controlling Activities Teaming Politics Summary Case Study

You’ve created the perfect project plan and you’ve started executing that plan. What could possibly go wrong? Well, possibly nothing and possibly everything. This chapter covers what you should do to monitor the activities of your project and how to take corrective action to keep the project on track. The first section spends a lot of time on schedule and cost variances. First you’ll explore variance analysis and the earned value technique, two methods used to determine variance. Then you’ll examine the impact of the variances that on your project. Corrective action comes next, including when to move quickly to fix an issue versus when to just monitor a situation for a while. The next section moves into other monitoring and controlling activities. This includes items such as performing risk monitoring and control, developing the product of the project, and managing change control. The “Teaming” section covers the behaviors that you want to find, reward, and encourage in your team members. These behaviors will drive the team

397

398

Chapter 12

to the performing stage of team development and also drive them and your project to a successful delivery. Rumor control and your strategy for handling rumors is the topic in the “Politics” section. You must monitor and control the information being passed about your project, just as you monitor and control the other aspects of the project. In the case study, Chris has a few last-minute details to finish before her meeting with June. She needs to get June’s approval before the team starts executing tasks next week.

Monitoring and Controlling Variance The execution of your project has begun, and you want to make sure that the project executes well and delivers to the schedule, the budget, and the MOP. You must monitor and control the project activities as they are executed so you can make that happen. This section starts with some of the basics that you must have in place to effectively monitor—and, therefore, control—your project. The first element is your status meetings. The last chapter covered the frequency and some of the agenda items of your status meetings. Now you’ll learn about gathering performance information during your status meetings. This is a critical element of monitoring and controlling: You can’t monitor or control if you don’t know exactly what is happening on the project. Some people call this monitoring and controlling; others call it “tracking” the project. Performance information is the status of how tasks are being performed during the execution. You examine in each status meeting the previous period of work. Let’s get clear about what I mean by “previous period.” Say, for example, that you have decided to hold your status meetings Tuesday afternoons at 1 p.m. You inspect the tasks that the team worked on in the previous week. Take a look at the network diagram in Figure 12.1. The status meeting in week 1 would occur just to get the team into a rhythm; no status would be given. The status meeting in week 2 would look at the status of the tasks the team worked on in week 1. The status meeting in week 3 would look at the tasks the team worked on in week 2. See what I mean by “previous period”? Figure 12.1 shows that, in the status meeting in week 2, you will get the status on Task A. The status meeting in week 3 examines the status on Tasks B, D, and E.

Keeping the Project on Track

Week 1

Week 2

399

Week 3

Task B

Task C

Task A

Task D

Task E

Figure 12.1 The previous reporting period

Getting status means asking a couple very specific questions about the work: • • • • •

How much work (hours or days) has been completed on the task? What is the percentage of completion? How much work is remaining to be done? What was the actual start date? Are any issues preventing the completion of the task?

You’ll see in a little while why all five of these questions are important to understand the status of each task. You need the performance information so you can analyze what is going right and what is going wrong on the project. You then must decide what you will do about it. You can use this performance information as the basis for two types of analysis while monitoring and controlling the project: variance analysis and earned value technique.

400

Chapter 12

Variance Analysis Variance analysis involves looking at the difference between what you planned to do and what you actually did. You can analyze the variance with the performance information that you’ve gathered. You must look at each task in step-by-step fashion and ask yourself some questions along the way to determine the amount of variance, if any. Then you step back and look at your entire project to determine the impact that variance has on the entire project. Let’s step through an example. I’ve converted Figure 12.1 to a Gantt chart, shown in Figure 12.2. Today’s date is January 30, 2007, and you have gotten status on Task A. The team member accountable for this task has told you the following: • • • • •

ID

All work has been completed on the task. It is 100 percent complete. There is 0 percent left to do. The task started on the correct start date. There are no outstanding issues at this point in time.

Task Name

Start

End

Duration

1

Task A

12/22/2007

1/26/2007

5d

2

Task B

1/29/2007

1/30/2007

2d

3

Task C

2/5/2007

2/7/2007

3d

4

Task D

1/29/2007

2/2/2007

5d

5

Task E

1/30/2007

2/7/2007

7d

Jan 21 2007

Jan 20 2007

21 22 23 24 25 26 27 28 29 30 31 1

2

3

Figure 12.2 Gantt chart view

You must analyze the task against what you planned to do. The task was done exactly as planned. You apply the actual work to your Gantt chart in Figure 12.3; see the actual task status bar above the projected task work bar.

401

Keeping the Project on Track

Both bars are the same because the task was completed exactly as planned. No more analysis is necessary at this point because the project is being executed exactly as planned.

ID

Task Name

Start

End

Duration

1

Task A

12/22/2007

1/26/2007

5d

2

Task B

1/29/2007

1/30/2007

2d

3

Task C

2/5/2007

2/7/2007

3d

4

Task D

1/29/2007

2/2/2007

5d

5

Task E

1/30/2007

2/7/2007

7d

Jan 21 2007

Jan 20 2007

21 22 23 24 25 26 27 28 29 30 31 1

2

3

100%

Figure 12.3 Status at week 1

Okay, now the date is February 6, 2007, and you are gathering status on week 2 work. The team members accountable for these tasks have provided the information in Table 12.1. There are no new issues on any of these tasks. Table 12.1 Status at Week 2 Task

Work Completed?

% Complete

Work Remaining?

Start Date?

Task B

2 days

100%

0

1/29

Task D

5 days

50%

5

1/29

Task E

2 days

29%

7

2/1

Let’s look at each task in the reporting period. First consider Task B. It was completed exactly as planned. Good job—nothing to do on this task. Now look at Task D. The team member reported that he has done five days of work. You look back at the original plan and see that the task was scheduled

402

Chapter 12

for five days, all to be completed this week. The team member also has reported that he is 50 percent complete and has five more days of work. At least the task started on time on the 29th. There are definitely some problems with this task. Now consider Task E. The team member has reported that she has done two days of work and is 29 percent complete. He still has five days remaining, and he started late, on February 1. This task is on track for the estimated work but started three days later than planned. Your Gantt chart now looks like Figure 12.4.

ID

Task Name

Start

End

Duration

1

Task A

1/22/2007

1/26/2007

5d

2

Task B

1/29/2007

1/30/2007

2d

3

Task C

2/5/2007

2/7/2007

3d

4

Task D

1/29/2007

2/2/2007

5d

5

Task E

1/30/2007

2/7/2007

7d

Jan 21 2007

Jan 20 2007

21 22 23 24 25 26 27 28 29 30 31 1

2

3

100%

100%

50%

29%

Figure 12.4 Status at week 3

The work that you’ve just completed is called variance analysis per unit of work. You also need to look at the variance of the tasks for the period for which you are gathering status. You accumulate all the variances for all the tasks in this period to see if you are still executing according to your plan. Normally, you determine what corrective actions you should take now that you understand the variance. But first let’s talk about the other analysis technique that can help you monitor and control your project work: the earned value technique.

Keeping the Project on Track

403

Earned Value Technique The earned value technique is another way of measuring work performance and comparing it to what was planned. Variance analysis looks at only one component of variance: schedule. Earned value gives you the opportunity to look at both the variance of the schedule and cost variance in the same analysis. This chapter provides some of the basics of earned value. You’ll want to get deeper into the use and formulas that are part of earned value analysis as you continue to hone your project-management skills. This method of analysis involves determining the cost of every task (or the entire project). You then apply mathematical calculations to the work that has been done to determine the schedule and the cost variance. How do you determine the cost of every task? You determine the cost of resource per task, or the cost baseline (see Chapter 10,“Budgeting—How Much?”). Remember that the cost baseline is the accumulated cost per resource per task; every task actually has a cost baseline. The cost baseline in the earned value technique is also called the planned value (PV). You can use this earned value technique because you decided to build and track a budget. I mentioned earlier that you’d be pleased later if you took the trouble to load in resource rates per task and actually set up all the project costs. This is where that work really pays off. Let’s determine the PV on Task E of the previous example. You used the resource Gene to do this work. Gene is paid a loaded rate of $1,000 per day. The planned value for Gene is $7,000. The other resource on that task is a backhoe that Gene was going to use on days 2 through 5. The backhoe is a rental, at $100 a day. Therefore, the planned value for the entire task is $7,400. Gene provided his status report on day five of the planned task completion and said he had started the work two days later than planned. He still ended up renting the backhoe for four days; he just started the rental later than anticipated. The earned value at the end of day 5 was $3,200: That was the value of the work accomplished up to that point in time. The value of work accomplished is also called the earned value (EV). The actual cost (AC) of the task is the actual cost incurred while accomplishing the work. In the example, Gene incurred a late fee when he picked up the backhoe later than planned. That was an extra $100 fee that the project had to pay, for a total cost as of day 5 of $3,300. Figure 12.5 shows the day-to-day expenditures on Task E.

404

Chapter 12

PV

DAY 1

DAY 2

DAY 3

DAY 4

DAY 5

DAY 6

DAY 7

1000

1100

DAY 8

DAY 9

1100

1100

1100

1000

1000

EV

1000

1100

1100

1100

1100

1000

1000

AC

1100

1100

1100

1100

1100

1000

1000

Figure 12.5 PV, EV, and AC

Your figures at this point at the end of day 5 are as follows: Planned value = $5,400 Earned value = $3,200 Actual cost = $3,300

Now you have calculated the planned value, the earned value, and the actual cost; you can apply some basic formulas to that information to determine schedule and cost variance. The schedule variance formula is as follows: Schedule Variance = Earned Value – Planned Value

This is the schedule variance for Task E: $3,200 – $5,400 = –$2,200

A negative schedule variance means that the project is running behind schedule. A positive variance means that the project is running ahead of schedule. Now let’s calculate the cost variance. This is the formula for the cost variance: Cost Variance = Earned Value – Actual Cost

This is the cost variance for Task E: $3,200 – $3,300 = –$100

A negative cost variance means the project is over budget. A positive variance means that the project is under budget.

Keeping the Project on Track

405

You might want to do two more calculations when determining your variance on budget and schedule: the Schedule Performance Index and the Cost Performance Index. Both of these indexes measure the efficiency in how your project is executing. • Schedule Performance Index—The Schedule Performance Index shows the ratio of earned value to planned value. This is the formula: EV ÷ PV = SPI An SPI of 1 or larger shows a favorable trend in the schedule of your project. An SPI that is smaller than 1 shows an unfavorable trend in executing the schedule. Let’s do a calculation using the same example as when you calculated the schedule variance. Planned value = $5,400 Earned value = $3,200 Actual cost = $3,300 3,200 ÷ 5,400 = .59 Based on that calculation and the trend information, you know that your project is off track and the trend is not favorable. • Cost Performance Index—The Cost Performance index shows the efficiency of the budget of the project. It is the ratio of earned value to actual costs. This is the formula: EV ÷ AC = CPI The same rules apply; 1 or larger is favorable, and anything lower than 1 is unfavorable. Here’s the calculation using the same example: Planned value = $5,400 Earned value = $3,200 Actual cost = $3,300 3,200 ÷ 3,300 = .97 You can use that calculation and the trend information to determine that your budget is off track and that the trend is not favorable. The good news is that the budget is not off by much, and you should be able to get it back on track. You can easily do the earned value technique on a small project manually. You might find it difficult to see what tasks are causing problems for your

406

Chapter 12

project if it involves a lot of tasks; your project-management software can more easily do all the calculations for you. You would just generate an earned value report. You’ll know that your project is over budget if you scan down the column of cost variance and see a negative figure; you can find out exactly what task is causing your project to go off track by looking for a negative number in the schedule variance column. Earned Value in Microsoft Project Setting up and getting earned value reports in Microsoft Project is pretty straightforward. For more information, see Chapter 11 of Microsoft Project for Mere Mortals, by Patti Jansen.

Determining the Impact You must determine the impact on the project when you discover schedule or cost variances. The variance could be minor and require no action, or it could be major and require some fast action to get the project back on track. Let’s talk first about variances with the schedule. You first need to determine whether schedule variances are affecting tasks on the critical path. If so, you must take immediate action to get the project back on track. Every day of slippage on the critical path causes a day of slippage on the end of the project. Variances for tasks that are not on the critical path require two pieces of information to determine the impact: • How much float is available? Think back to when you did your critical path analysis back in Chapter 9,“Creating the Schedule.” There you determined the amount of float time available for every task. You should be able to absorb the slippage with no impact on your schedule if the variance here is less than amount of float available. Take a look at Figure 12.6, an excerpt from the TTR project. The critical path involves Tasks 3.14 and 3.4, for a total of 22 days. The tasks on the noncritical path are Tasks 3.7 and 3.11, for a total of 10 days. Imagine that the slippage is happening on the path for Tasks 3.7 and 3.11; these tasks can slip for 11 or fewer days, with no impact on your schedule.

Keeping the Project on Track

3.14 Revise material after the pilot 7days

3.11 Create textbooks 5 days

3.7 Adjust the class to 50% less 5 days

3.4 Train the trainer 15 days

407

3.18 Monitor for customer complaints 30 days

Figure 12.6 Critical path with float

• Is this path now critical? The amount of slippage might be exactly the same amount of float that is available. If so, ask yourself,“Has this path now become another critical path?” Imagine that the path for Tasks 3.7 and 3.11 slips by 12 days; it then becomes another critical path to watch and track. A slippage of more than 12 days makes this the new critical path. You should ask the same two questions with the budget variance as you did with the schedule variance. You can also do another earned value calculation to forecast the impact on your budget. The most used formula for creating this forecast is called estimate at completion (EAC). This calculation will tell you what you should expect to spend for the total project: BAC ÷ CPI = EAC

You are probably wondering what the BAC is and how you get it. BAC stands for budget at completion and is the same as the cost baseline. Say, for example, that the cost baseline for a project was set at $150,000 and your cost performance index is running at 1. Your estimate at completion would be $150,000. You should expect your project to complete at the amount of money you established as the cost baseline. You can do a lot of additional forecasting with earned value calculations. In fact, you can calculate the EAC in three additional ways. You use these different formulas depending on the type of variance that you are seeing on your

408

Chapter 12

project. I don’t discuss them here because I consider them advanced techniques. However, I encourage you to spend some more time getting to know and understand these techniques; you will find them important as you continue to hone your project management skills. You’ll have a pretty good understanding after you do the earned value calculations and variance analysis of how far off track your project is and the possible impact on your schedule and/or the budget. Now what? You take action!

Corrective Action You now have a good sense of the magnitude of the problems that you are seeing on your project. You understand what the variance is doing to your critical path. You’ve done some earned value calculations, and now you need to take action. Variance will continue to grow unless treated. Never allow variances to fester; they won’t go away and usually they will just get worse. Besides, you are saying to your team members that it’s okay to slip dates or overspend. You don’t want them to believe that it will be okay to miss any of the triple constraints. Your actions will be more severe depending on the impact you’ve analyzed. Your actions on the critical path must be decisive and must get you back on track the very week you see the variance. Your actions on noncritical-path tasks might not be as fast or decisive, but still you need to take action. Critical Path Tasks You’ve seen a variance on a critical path task. You must take action immediately to keep the project ending on the date you’ve committed. You must immediately analyze the situation and do some root cause analysis. What exactly is causing the variance? These are the types of things you’re looking for: • Was the hand-off from the last task not done well enough for the person who was supposed to start the task to know he or she could begin? • Is the person performing the task able to get the work done? Is there a deficiency of execution or a deficiency of knowledge? • Was the person who is performing the task waiting for another dependency that the project plan did not identify?

Keeping the Project on Track

409

• Did a risk cause the delay? • Was the estimated time for the task just too low? You need to do two things after you determine the root cause of the problem: • Crash, fast-track, or descope the project to get it back on track. These are the same techniques that you learned about in Chapter 9 to take care of variances. Find a way to add more resources to get the project back on track. Find a way to do more tasks in parallel. Or remove some of the scope if the time element of your triple constraints is the most important aspect of project delivery. You’ll have to really analyze the situation to guarantee that you don’t trade in a schedule problem for a budget problem. You might have to go to the project sponsor to clarify the most important delivery aspect of the project. You’ll make better trade-off decisions with this in mind. • Fix the problem so it doesn’t happen again later in the project. Then turn your attention to fixing the underlying problem when you’ve gotten the project back on track. You might need to address resource issues, or you might face fundamental issues with how your estimates were created. Find a way to resolve the issue so it doesn’t happen again. Noncritical Path Tasks A variance with noncritical path tasks involves pretty much the same scenario. First find out the underlying problem causing the variance. Ask the same types of questions as those you posed before. Then consider the following: • The slack time can accommodate the variance, so your job is to calculate the new slack time available. You also must monitor this path for additional problems that will keep your project from completing on time and on budget. • Work on fixing the underlying problems that caused the variance in the first place, just as with the critical path tasks. Document in your project plan the corrective actions that you will take to fix variance on your project. These should be executed the same as any

410

Chapter 12

other project tasks. You’ve spent a lot of time understanding, calculating, and taking corrective actions while monitoring and controlling your project. You’ve got still other monitoring and controlling activities to do in addition to these. Let’s cover those now.

Other Monitoring and Controlling Activities You probably thought you were done with monitoring and controlling! Yet the world is complex and demands that a lot of parallel activities be performed well to deliver according to the triple constraints. You must perform other monitoring and controlling activities while you are evaluating cost and schedule variances. Let’s first cover project risks.

Controlling and Monitoring Project Risks You established a sound method of identifying, analyzing, and assessing project risks while you were working on your risk planning. You will monitor and control the risks of your project while you are executing your project. You will continue your risk process as new risks come up. You will monitor your master risk identification list and watch for triggers. You will identify residual risks that appear. And you will monitor your entire risk process to guarantee that it is working effectively. Now is the time to assess how the entire process is working. Let’s cover each of these actions with a little more detail: • Identify new risks—A new risk can occur every time you notice a variance and take corrective action. Other risks might have escaped you or your team members. You invoke your risk management process with each of these activities and run new risks through your entire process of identifying them, determining their impact and probability, and creating the right risk response plans for them. • Monitor for risk alarms—Your risk response plan included alarms for your top 25 percent risks. You and your team members now will monitor these risks. You must verify that the right alarm is in place and take action if the alarm starts to occur. • Watch for residual risks—A residual risk occurs when a risk response has been implemented and the risk is still present. Yes, it is

Keeping the Project on Track

411

possible that, even with all your planning, the risk is in place after you have responded to it. This situation doesn’t happen often, but you should be aware of this condition and be on the lookout to respond to the risk again. • Monitor the risk process—Last but not least, you will want to inspect your entire risk process of identifying risks, determining probability and impact, prioritizing risks, and responding to risks. You also might check out whether creating risk responses for the top 25 percent is enough. Are other risks impacting your project? Are these risks that were identified but lower in priority?

Controlling and Monitoring the Product of the Project Another activity that you will be doing during project execution is monitoring and controlling the creation of the product of your project. You spent time on the project creating product requirements and getting clear about what exactly you are creating. You also laid out a perfect sequence of work that constructs that product. Now you will be monitoring the construction. You will want to compare the output of the different stages of the work to the specifications, to verify that the right product is being created. You will also want to make sure that your process of construction is inspected in a quality audit. This audit will also help you verify the construction and the processes you are following to construct the product.

Monitoring the Implementation of Changes from Change Control The last additional monitoring and controlling activity consists of monitoring the approved changes that are now being implemented on your project. Change control is one of the necessary evils of project management. You’ve spent a lot of time planning to get things right, but others might still request changes to what you have planned. The concept of change control is so important that I’ve devoted Chapter 13,“Controlling Changes,” to this topic. First, though, let’s talk about how to work with your team while you monitor and control the activities of your project.

412

Chapter 12

Teaming You will want to find, reward, and encourage your team to exhibit two behaviors. These behaviors will help you immensely in the coming months as you all struggle to get your deliverables out the door. The first is reporting facts. The last thing you want is a loose interpretation from the team member when you ask for status reports. There’s a time and a place for everything; you are looking for the facts during status reports. Encourage your team to be as factual as possible. Remember the five questions you should ask each team member: • • • • •

How much work has been completed on the task? What is the percentage of completion? How much work remains to be done? What was the actual start date? Are any issues preventing the completion of the task?

Encourage your team members to write down the actual time spent working on each task. Keeping a log or a journal makes it much easier for each member to report exactly how much time has been spent. Have team members explain their rationale for the percentage of work completed; grill them, if necessary, so they really think about the accurate percentage. Have team members provide a detailed description of the amount of work remaining. Encourage questions and challenges from the rest of the team members if they don’t understand how the time estimated equates to that work. Remember, conflict can be good, especially if it gets you to facts that help you judge whether you’ll have problems getting the work done. Also remember, though, to demonstrate respect with any challenges and questions. The leader of this group sets the stage for respectful conflict that leads to successful delivery. That brings up the next behavior you should instill, reward, and encourage: the behavior of success. Seek out the team members who deliver as they said they would. Reward them in front of the team; the whole team needs to see how important this successful behavior is to you. Look for and reward the team members who solve problems. Look for the team members who report, week after week, successful completion of their tasks. These are the

Keeping the Project on Track

413

heroes of your project, and these are the behaviors that you want the rest of the team to display. Don’t let the project failures get all the attention. I once worked in an IT shop where the programs for this company processed all night. We had one complex program that had problems almost every night. The developer, George, would waltz into the office every morning around 10 a.m. and complain about getting woken up every night to fix the problems. His boss would tell him,“Poor George!,” and everyone felt sorry for him for being disturbed. His boss spent a lot of time with him telling him how bad she felt about his getting up every night. She encouraged her entire team to support him and to give him attention. That boss took another position about a month later, and Kathy replaced her. Kathy heard from George on her first day in the office about the program having problems. She did some root cause analysis of the issues the program was having. She took George aside after a week of watching him come in and look for attention. She told George that because he was the only one working on the program, he was causing the problems with his sloppy work. She would not tolerate these kinds of problems. Kathy told him that he had better get the problems worked out, or he wouldn’t be working there anymore. Funny thing, the program stopped having problems shortly after that. George settled down and did a good job. He left about a month to work in another place in the company where he could get the attention he was looking for. I guess the moral of the story is to find and reward the behaviors you want your team to exhibit until the entire team displays the behaviors that will drive the project to success. Don’t devote your energy and attention to the failures; deal with them and get back to the successes. Continue to encourage the proper behaviors until your team is an effective performing unit. Let’s now talk about rumor control.

Politics You are monitoring and controlling the variance in the schedule and variances in the budget. You are watching the risks and the creation of the project. You need to monitor one more item during this period: what people are saying about your project. That is, you need to exercise rumor control, as we say in the project management trenches. Nothing can hurt a project manager’s reputation more than unfounded rumors that get out of hand. Some

414

Chapter 12

project managers’ reputations never recover from those types of problems. You need to have a strategy for handling the rumors on your project. The first component of your strategy is to establish a rumor-monitoring network. Ask your trusted friends and core team members to keep their ears open to what people are saying about your project. Have informal meetings with them on a regular basis to find out what the rumor mill is saying. I’ve actually seen project managers put activities on their calendar to prowl for rumors. The second component of your strategy is to execute your communication plan. Here you fill the information void with solid factual information. Negative rumors will have less credibility if you fill the void with the information that you want people to have. Next, update your communication plan as the project progresses. Compare it to the rumors you are hearing. Your communication plan should be sufficient to preempt any rumors that happen. Finally, decide how to handle any rumor that you hear about. Rumors that the project is going so well that you’re getting a promotion can stay out there, of course. You surely won’t mind it when people are talking positively about you and your project, although rumors seldom hit the positive aspects of you or your work. Most rumors will be negative. Some people just love to hear about how other people are struggling or failing, and they love to pass on that information. Take action when you hear a negative rumor about your project. What action that is depends on the validity of the rumor. • If the rumor is true—Yes, we all have problems on projects. Even the best plans sometimes fail. Rumors could be circulating about your project going off track—and it is. Make sure everyone knows what you are doing about it. Make sure your team sees you in action when you set out to correct the variance. Leave frequent voice mails for your executives and project sponsors, to keep them abreast of the problems and the solutions you are implementing. Also make sure the entire team knows when the project gets back on track. • If the rumor is false—Make sure your communication plan is sound and covers the situations about which rumors are flying. Make sure that people know the truth about your project and what is happening via status reports in your team meetings and status reports to your directors. Remember, there’s nothing wrong with a quick phone call or pop into your boss’s office to give a quick status update. Don’t give

Keeping the Project on Track

415

the rumor any of your energy, and don’t repeat it to anyone. Instead, make sure you are conveying the right status and information regarding how you and the project are doing. Paying too much attention to the rumor and fighting it off tends to make people believe it because you are defending yourself so hard. Remember, rumors will pass and the truth of your project’s execution will speak for itself when you finish according to the triple constraints.

Summary This chapter covered monitoring and controlling all the elements of your projects. We covered the two ways to monitor the schedule and the budget of your project: variance and earned value analysis. Then we covered exactly what you need to do when you find variances on your project. We also talked about other things to monitor, including your risk process and the construction of the product of your project. In “Teaming,” we talked about the behaviors that you want to see in your team members and how to encourage your team to exhibit them. You are instilling in them the practice of solving problems with facts. You also want them to have a winning attitude that drives them and the project to success. In “Politics,” we talked about monitoring and controlling rumors. We laid out a simple strategy for you to use when dealing with rumors. Chris Williams still has a few things to finish in the case study before she talks to June about the schedule and the budget. The project is set to begin execution next week, and Chris needs June’s approval before the project moves on. Let’s see if she gets everything done and see how the meeting goes.

Case Study Chris got to the office at 6 a.m. on Friday morning. She wanted to make sure that she had everything ready and very professional looking for her meeting with June. She was really glad that the meeting wasn’t until 1 p.m. Chris went back to working on her budget. Yesterday she determined that the cost of resource per task was $129,298. That was a good figure, and Chris was pleased that it was below the amount June was holding for the project. She

416

Chapter 12

knew that she wasn’t done,though; she still needed to add some money to the budget in the form of project reserves, managerial reserves, and fees. Chris wondered if she should bother trying to get these monies. Her organization didn’t bother with any other reserves or contingencies most of the time. But this project seemed to be very important to the organization, and Chris knew that asking for it was the right thing to do. She analyzed the risk list to see if sufficient risks needed to be covered with project contingencies individually. She decided that a percentage should be okay: She decided to ask for $13,000 for the project reserve. Chris also planned to ask for $13,000 for managerial reserve. Chris could not think of any fees needed for the budget. Still, she sent out an urgent e-mail to the core team, to see if they knew of any necessary fees. She then finished up the schedule. Chris had completed the critical path analysis over the last 2 days and knew that the project was tentatively scheduled for 93 days. The project would start in March, and the trade show would take place in September: Ninety-three days put them at mid-August, which was perfect. Chris decided not to increase any of the tasks with PERT estimates because the risks were not high enough to warrant that level of padding. Chris’s resource assignments showed no resource contention problems on the project. Chris was very wise, though, and looked at possible resource contention between the core team’s regular jobs versus the work they had to do on the project. That is where the resource contention lay. But Chris had verified with each supervisor the level of contention and had been able to minimize the risk for everyone working on the critical path. Chris had also met with the core team and verified the estimates with everyone who would do the work. Everyone felt pretty comfortable with the estimates. Chris realized that with the confirmation of the estimates, she was done with the schedule. The schedule ended in mid-August, so there was no need to crash, fast-track, or descope the project. Chris did not need to do the following: • Reverify the critical path • Reverify that she had overloaded any of the resources while she was compressing • Analyze any new risks Yeah! One step of her analysis done. Chris was amazed, though. She’d never had a schedule work out so well. She usually spent days trying to figure out

Keeping the Project on Track

417

how to compress the schedule. This was the first time in her career that she had a project actually make the due date the sponsor had requested. Chris decided to start the presentation to June. This was an informal meeting, but she still thought it best to provide the information in presentation format. Chris started with the scheduling information. She created a Gantt chart to show June how the project schedule was laid out. She had read in one of her textbooks that the Gantt chart view was the best view to use to talk to an executive. It took Chris another hour to create the Gantt chart and the rest of the presentation. She left a page blank until she got the budget done. Chris had a page for the schedule, one for the budget, one for risks, and one for issues. Of course, she started the overview with a recap of the project MOP. She wanted to keep that in the forefront of June’s mind. E-mails concerning feels started to trickle in while Chris worked on the presentation. Most of the e-mail said,“No fees required.” Chris thought she was done, but she received one more e-mail from Robin, who reminded Chris that there was a $5,000 registration fee per organization for the trade show. Chris was really glad that she had sent out the e-mail; she had forgotten all about the registration fee. Chris then tallied up the monies for the budget: $129,298 $13,000 $13,000 $5,000 $160,298

Cost baseline Project reserves Managerial reserves Registration fees Total budget

Chris reviewed her figures once more. She decided to put some money in for “On the Spot Awards” for her team members. She added $10,000 to the project reserve area, which raised the budget to $170,298. She knew this was going to be a stretch, but it never hurts to ask. Chris then completed her presentation for June. She had only enough time to grab a quick bite before heading down to June’s office. Chris emerged from June’s office around 2:30. The briefing had gone well, and June was pleased with the progress of the team so far. The MOP was right and the schedule was good, but June didn’t like the budget amount. She didn’t believe in reserves and contingencies. She believed that she paid big bucks for project managers and that they should make sure that the project could be done without any contingencies or reserves. Chris continued trying to educate June about unknown-type risks. June eventually agreed that those

418

Chapter 12

types of problems could happen, but at the end of the conversation, June decided to leave the budget at $150,000. She challenged Chris to deliver the project to a budget of $134,298. That was the cost baseline plus the fees. June left the other $15,000 in the budget as a managerial contingency, for money that could be used only if June agreed. June would let Chris have the additional $10,000 for “on the spot” type awards if Chris and the team could deliver at $134,298. Chris was pleased with the outcome but also knew that she had a challenge ahead of her to get this project delivered to that budget. Chris also decided as she walked done the hall not to tell the core team about the on-the-spot award possibilities. This company didn’t do these types of awards very often, so they would not be expecting it. She would need to find another way to motivate the team to move forward. Chris returned to her desk and began creating the baselines for the different components of the projects. She baselined the schedule, the budget, and the requirements they had gathered on the demo, as well as the other types of trade show requirements they had. She also needed to baseline the quality requirements. Chris decided that it would be best to also do a quality audit. Chris had a friend, Sue, who also was a project management for the company. Chris had already talked to Sue about coming in and being an objective reviewer of the processes of the project and the processes they would use to create the product. Chris decided to call Sue and set up this quality audit for as early as possible for the next week. Chris had the baselines done and the quality audit scheduled for next week, and she was ready for executing the project. It was a good thing, too, because the first set of tasks was scheduled to start next week. Chris set up a recurring meeting in her calendar system for every other week on Tuesday to gather status for the previous period. Chris decided that was enough for this week. She had gotten a lot done and was looking forward to a quiet weekend before the team really got busy next week with the execution of the project. She knew she would have a lot of late nights coming up to put in place the level of monitoring and control that she thought this project needed. Chris ran into Tina Johnson on her way out the door. Tina mentioned to Chris that she had heard a rumor that the trade show had changed the entire point value system and that their MOP was all wrong. Chris sighed and kept going on her way home. She knew this rumor could wait until Monday. And so it begins.

Keeping the Project on Track

419

Review Questions 1. What five questions are asked when gathering status? 2. What two types of analysis are done when trying to monitor and con-

trol a project? 3. Describe earned value. 4. What is the formula for schedule variance? 5. What is the formula for cost variance? 6. What are the two index formulas for earned value analysis? 7. What types of activities will you perform during the monitoring and

controlling processes regarding risks?

This page intentionally left blank

13 Controlling Changes “Anything that can be changed will be changed

until there is no time left to change anything.” —Anonymous

Topics Covered in This Chapter The Concept of Change Control The Process of Change Control Teaming Politics Summary Case Study

This chapter covers one of the most important concepts of controlling your project: change control. I explain in this chapter what could get changed on your project. I also cover team norms, an important prerequisite that you’ll want to make sure is in place before you start managing changes. I then cover a change control process step by step so you will know how to construct your own effective process. I describe each step along with the critical elements of each. Finally, I discuss change tracking and how important it is to you, both in considering individual change requests and in using your change request log as a barometer for your project. Chapter 11,“The Rhythm of Project Execution,” delved into the rhythm of the project. You’ll find that change requests are disruptive to the project team. The “Teaming” section covers ways to keep the team focused on their regular project work. Finally, the “Politics” section discusses how to work with a Change Control Board (CCB) to get the right decisions needed for your project

421

422

Chapter 13

A couple months have passed in the case study, and Chris has stopped to review what is working and what needs improvement. You’ll get a chance to see some of the mistakes she made and what she has done to correct them.

The Concept of Change Control Have you ever worked on a project and, while you are constructing the product of the project, the client asks you to change a feature or a function of the product? Of course you have! That is the nature of change—it will happen no matter how well you plan your projects. Human nature is such that people just can’t remember all that they want, or they can’t think past a certain level to understand the implications of what they asked for originally. Remember, too, that the world also changes, and those changes could impact your project. This chapter is all about changes, what are they, and how you manage them. Let’s start with this question: “What do we control using a change control process?”You learned in the last chapter that a lot of monitoring and controlling activities happen on a project. You get a bit more focused with change control. You control any request that changes the plan of record, which you baselined at the end of planning. The plan of record consists of the product requirements that have been signed off on, the baselined schedule, and the baselined costs of the project. Basically, it is the baselined project plan: • The product requirements—You had your client sign on the dotted line to signify that the product requirements described exactly the product to be constructed. The signature also signifies that nothing more than that product will be constructed. A change request that asks you to add a new feature to the product you’re creating is an example of this type of change. • The schedule—You have a schedule that has been approved. You have also baselined the schedule to keep a record of what you plan to do. Imagine that an executive comes to you and asks for you to deliver the product one month earlier because that delivery fits better with his marketing plans; that’s an example of a change request that affects the schedule. • The budget—You created a project budget that was also approved. You baselined it and kept a copy to compare against while the project is being executed. Your organization has been having financial issues.

Controlling Changes

423

The executives have decided to cut both operational and project budgets. They contact you and tell you to cut your budget by 10 percent. This is an example of a change request that affects the budget. The objective here is to control any change that anyone wants to make to your project after it has been baselined and approved. Now, sometimes you will have no choice but to accept the change, as in the budget cut example, but you will always understand exactly what the change means to your project. You must have a process in place to control changes.

The Process of Change Control You establish your change control process during the planning portion of the project. This is another item that you should set up in your project plan. You must fully document and describe the process. You must also take time out of your busy schedule to educate your project team, executives, and clients on the process. Then when you start executing the project and a change is requested, everyone on the team will know exactly what the process is. One prerequisite activity also needs to be established before you build your change control process. Chapter 4,“Laying Out the Work,” covered how to establish team norms. The project manager added two team norms to the list the team members created: • After the project baselining is completed, if we find a problem in creating the product, we all agree to funnel that problem through the change management process instead of just fixing it on our own. • We agree not to make any unauthorized changes to the product, regardless of who asks. The first prerequisite is pretty easy, and everyone agrees to it pretty readily. The second one tends to be harder to follow. Everyone agrees up front, but when it comes to project execution, it tends to fall apart. Say, for example, that you are a mural painter and part of your goal is to always keep your client happy. You have a client who has ordered a standard mural at the standard price for the main living area. You start the job, but the homeowner then asks you to change the color on the outermost edge to match the decor. Your dilemma is this: Do you charge the client more and take longer to get

424

Chapter 13

the work done, or keep the client happy and just make the change? The same type of thing will happen on your project. The team will be working well together, and one of the people in charge of the product will ask one of your team members to change one of the features or functions just slightly. It’s imperative that this change come through the change control process, for the following reasons: • No one else on the project will know about the feature or function if the team member makes the change quietly, and it could cause problems at a later stage of development. Another team member might think it’s a mistake and have it removed. • No one will know to test the feature or function if the team member makes the change quietly. The change might also need to be documented; it could run up the costs of the project. • Doing a small “favor” for the client could cause the entire project to miss one or more of the triple constraints. Your team might or might not be able to make the requested change, but you will always investigate whether it can be done. Make sure your clients know that you will accommodate their change requests if at all possible, and that you’ll explain to them why any change can’t be made. Hopefully, these understandings between your project team and your client can establish a successful change control process. Now let’s move on to the actual steps in the process of change control.

The Change Control Process Step by Step Figure 13.1 shows the change control process that you establish and manage through the execution of the project. This section covers each step of the process in depth. Let’s get started. Step 1: The Client Requests a Change to the Project A change request can be generated at any point in the execution of the project, from the day you finished the baselines to a couple days before you deliver the project. Make sure that clients know how to get the change request to you. They could e-mail you or fill in a paper form—whatever will be easiest for them. You are trying to encourage them to stay within your process, so make it easy on them.

Controlling Changes

The client requests a change to the project

The change is logged in the Change Log

The change request is reviewed by the team

The team determines the impact to the project

The change is accepted or rejected

Notify the project team and the requestor of the decision

Figure 13.1 Change control process diagram

425

426

Chapter 13

You’ll need to gather some basic information from them, too: • • • •

A description of the change they are asking for The name of the requestor The reason for the change The risk (from their perspective) to the project if the change is not made

Figure 13.2 shows a change request form. CR Number 0000035 Date Request Title Requestor

New Handbook Aileen Fischer

Reason

CSR’s need

Priority

High

Status

Completed

10/06

Risk If Change Not Made

Client has stated that this should reduce the risk on the project to complete the new training and still have customer complaints under 2%.

Change Description

The client on our project has asked for a new handbook to be created and available at every service representative’s desk. This handbook would be a summarization of some of the class material. The client has seen this type of a handbook work very well for managing questions from the service reps after they finish class. She thinks these handbooks need to be done even though job aids are being created.

Time estimate to Implement Approval Resolution

15 days duration CCB

Cost Estimate If Known

Approved

$3700

Scheduled Implementation Date Date Date

With first pilot class 10/08 10/09

Figure 13.2 Change request form

Try to give the client some idea about how long it will take the team to get through the process when the client first provides a change request. Also be sure to tell the client when you’ll provide an update about the change.

Controlling Changes

427

Step 2: The Change Is Logged in the Change Log Log the first change request in your change control log, and then track it through the change process. You might want to keep this log in a place where the team can review what is happening and what changes are being requested. Also make notes for yourself on when you need to get back to the requestor with a status report. Step 3: The Change Request Is Reviewed by the Team You will have change control meetings to review the change request. You can carve out some time from your regular status meeting for this review, or you can set up a separate meeting just to look at change requests. The participants of this meeting will probably be your core team. You can use other team members, but make sure that all areas of the project are represented in this meeting. You review the request in this meeting. You’ll want to verify that all team members understand the change. Assign each team member the responsibility to create estimates for the change. You might even be able to create the estimates right there in the change request review meeting if the change is small. Be sure the team members know when the estimating work is due back to you. Step 4: The Team Determines the Effect on the Project You and the team will discuss the estimates when the team comes back together with the estimates of the project. This is the first activity in this step; you actually have a few activities to accomplish here. Make sure that you have both the duration estimate and the work effort estimate with the estimates that the team turns in because you will analyze the effect on both the budget and the schedule. Ask the team what resources will be required to work on the change request when you have the estimates. You’ll also need to know whether any dependencies affect getting the work done. Then you go to the next step: analyzing the impact on the schedule All that information now enables you to determine exactly where on the project network diagram the change will need to be done. Let’s run through an example. Your TTR project team is in the process of creating the course modules. The client for the project has asked for a new handbook to be created and available at every service representative’s desk. This handbook would summarize some of the class material. The client has seen this type of a handbook work very well for managing questions from the service reps after they finish class. She thinks these handbooks need to be created even

428

Chapter 13

though you are planning to create job aids. She has stated that this should reduce the risk on the project to complete the new training and still have customer complaints at less than 2 percent. Your team has completed the estimates and has determined that the work effort for the handbook will be 12 days. The duration is 15 days. The team members have also told you that one of the course developers will need to create the handbook. They think Jodi or Karla would be the best resource for the task, but Sue or Joe might also be able to get the work done. The only dependency for getting the handbook done is finishing the course material first and verifying the timings. Of course, you will want to have the handbook as part of the pilot course to see how it works with the service reps. You insert the change request into the project schedule temporarily to do some more analysis (see Figure 13.3). The first question that you ask yourself is,“If we do this change request, will it impact the end date of the project?” The answer for this example is “Yes, it will.” The current critical path is 10 days in length. This change request is 15 days. This becomes the new critical path for the project. The next step is determining the effect on the budget. The work effort estimate in this case is 12 days. That is an additional $3,600 at the course developer rate. Of course, you’d also need the reproduction facilities at $100. That’s a total of $3,700 for the change request. Your budget is set at $404,739; you originally set aside $500,000. There is no problem accepting this change request from a cost perspective; it falls well within the monies set aside for the project. Last but not least, you go back to the MOP for the project and determine whether the change request changes your ability to deliver the MOP. This is your MOP for the TTR project: Reduce customer service representative training time by more than 50 percent

You determine after your analysis that this change request will not jeopardize the MOP. In fact, this change request should help you meet the MOP, according to your client. You finish your analysis and decide that the change request will impact one of the three triple constraints. You cannot extend the project beyond its due date, so you should reject this change request.

Controlling Changes

429

3.12.1 Create class module 1 36 days

3.12.2 Create class module 2 35 days

3.12.3 Create class module 3 35 days 3.16 Process analysis 2 days

3.17 Verify timings 2 days

3.6 Create job aids 5 days

3.13 Create pilot textbooks 5 days

3.9 Conduct pilot class 25 days

3.12.4 Create class module 4 35 days

3.18 Monitor for customer complaints 30 days

3.10 Verify learning objectives are met 1 day 3.12.5 Create class module 5 35 days

Handbook change request 15 days

3.12.6 Create class module 6 35 days

3.8 Verify the training class is 50% less 1 day

3.2 Time the pilot class 25 days

3.12.7 Create class module 7 35 days

3.12.8 Create class module 8 35 days

Figure 13.3 Change request in TTR project

A Couple More Considerations

Let’s talk about two more items that could affect your decision to accept or reject the change. The first is the timing of the change request. You might find it easier to accept a change if the client requests it early in the execution of the project because so much time is available to get the work done. Of course, that is all contingent on the prerequisite tasks for the change. But things will change as time wears on and the end of construction of your product of the project gets closer: The lack of time available will influence you to reject change requests just because no time is available to get the work done. In fact, you might consider setting a date a week or two before

430

Chapter 13

the end of the construction of the product and telling the entire team, clients and all, that you will no longer accept any change requests after that date. The second consideration is what I call the incremental effect. I worked on a large project once that lasted for an entire year. I had calculated my schedule very carefully and knew exactly how much available slack time the project had. I received a few change requests about six months into the construction of the product. I knew that I had more than 30 days of slack available. These change requests added together were only 17 days. I should have been fine applying these additional days because none of them affected the critical path of the project. However, I ended up delivering more than three months late. The effect of taking on a change request is not always equal to the number of days provided in the estimate. I’ve learned that the number of changes that you take on also increases the amount of time needed to implement them. I haven’t been able to devise an exact formula for them, but know that when you accept your third change request and it is estimated at three days, it will probably take you more than six days to get it implemented. This is another place where PERT estimates, or at least three-point estimates, should be done. Always use the pessimistic estimate when you’ve got more than a couple change requests you are implementing. Step 5: The Change Is Accepted or Rejected You should understand your authority level in accepting or rejecting changes before you receive a change request. Most organizations allow their project managers to manage the change control process and accept changes that do not affect the triple constraints. In other words, if a change can fit into the approved project schedule without delaying the end date, if the budget is not overrun, and if the MOP is still achievable, the project manager can authorize any of those changes. However, the project manager cannot approve any change that makes the project end date slip, overruns the budget, or affects the achievement of the MOP. Many organizations establish a group of people called a Change Control Board (CCB) that authorizes those large changes that affect the MOP. The Change Control Board usually consists of the executives who have something to lose or gain with the completion of the project. The Change Control Board for the TTR project would probably consist of the executive of the Customer Service Representatives department, your executive, and any others who have a vested interest in the project. You might not be able to put together a Change Control Board at your company; if so, at least let

Controlling Changes

431

your executive or the client executive make the decisions on changes that impact one or more of the triple constraints. Let’s go back to the example. You have determined that the requested change affects the triple constraints. Therefore, you will send it to your Change Control Board to decide the fate of the change request. You, the project manager, should always send a recommendation to the CCB. You should also consider sending the potential risks associated with approving this change. Basically, send as much information as you have to the CCB so it can make an informed decision. The CCB will inform you of its decision. You then will communicate the decision to the team and the requester. You have one more activity to do if the CCB approves the change: You must rebaseline the elements of the project that change because of the change request. In the TTR example, you will rebaseline the schedule and the budget. You will also update the project plan with the new information. Be sure to update your change log with the disposition of the change request. Step 6: Notify the Project Team and the Requestor of the Decision You must let the requestor know what has happened after the CCB approves or rejects the change request. The board might have rejected the request; if so, make sure the requestor understands why and what process the board used to arrive at that decision. Also tell your team about the decision, regardless of the outcome. For a rejected change request, make sure the team members know not to do any further work on the request. For an approved change, discuss who will do the work and when that work will get done, just as you planned the original work of the project. Make sure that the team members see that the plan of record has been changed to reflect the request and that it is authorized at the appropriate level.

Change Tracking Another part of your change control process involves change tracking. I briefly mentioned logging and tracking changes in the discussion on the change-control process. Let’s spend another couple minutes talking tracking. Part of the joy and curse of project management is being able to look at minute details regarding the project on one day, and then the next day needing to think at a summary or global level to understand the implications of

432

Chapter 13

what is going on. Change tracking gives you the ability to obtain both details and a summary-level understanding of what is happening with changes. Change tracking is usually done via some type of change request log, depicted in Figure 13.4. PROJECT CHANGE REQUEST LOG Project Name: TTR Project Manager: M. Smith Change Request No. 000034

000035

Change Description

Change learning objectives Now Process Monitor

Priority

Requested By

Status

Date Resolved

Comments/Resolution

High

CBoeding

Open

Pending

Waiting on initial analysis

High

AFischer

Open

10/9

Scheduled with pilot class

Figure 13.4 Change request log

From a detailed perspective, you will track every change from the moment it hits your desk until the moment you notify the client and the team of the disposition. You’ll want to make sure that a single change request flows through the process in a timely manner. Treat each change as the most important activity on your to do list. This is mainly because it is important to the person who made the request in the first place. You want the client and the team to follow the process. You watching the process will show that this is important to you. On the summary level, you can use your change log as a barometer to gauge how things are going on the project. Consider a few examples: • You’ll know that you shut down your planning too early if you start executing the project and get barraged with change requests. • Glancing at your change list gives you an indication of the quality of your planning. You’ll know that you’ve had problems with project planning if you have a lot of changes that come through regardless of the time period. • Chapter 12,“Keeping the Project on Track,” discussed estimate at completion. It mentioned several different ways to calculate EAC, depending on the types of variances you are seeing. Variances and a lot of

Controlling Changes

433

change requests coming in tell you that you should use the EAC formula that states that you are having variances and expect the trend to continue. That covers change control from a process perspective. Now let’s talk about change control and the effect on your team.

Teaming Earlier this chapter discussed the incremental effect and how it takes longer to work on a change request when many change requests are coming in. This incremental effect can create major risks for your project. Another major risk that you will deal with when handling change requests is the number of distractions. You’ll find that, every time you receive a change request, your team will be distracted and will have a hard time getting its work done. Think about how change normally affects you. Imagine that you’ve heard a rumor that the project you were working on will be cancelled because of budget cuts. You try to keep working, but you constantly find yourself doing “what if” in your mind.“What if they lay me off if the project is cancelled? What if I end up working for someone else if they cancel my project?”You know how hard it is to concentrate when rumors are flying. Your team will have the same issues when it comes to change requests. The team members have worked hard to plan the project. They have invested a lot of themselves into the design of the work. Now, seemingly out of left field, someone wants to change what they have designed. They review the request and create estimates, and then they wait for an answer. Will this change be approved? The team members will look at their regular work to be done as they wait for the answer. Sometimes they will realize that what they’re working on will change, so they will begin to think, “Why keep going?” Sometimes they’ll get so busy talking to their co-workers about the change that they just won’t get anything done. Any way you look at it, change requests are a really big distraction. Part of your job as project manager is helping the team stay in rhythm even with the change requests that are coming in. You will want to build an environment in which change requests are just another “what if” scenario. Team members thus will not fret about, worry about, or even think about change requests until they are approved. You might even want to add some specific rules to your team norms addressing how to think about change requests.

434

Chapter 13

How you handle the first change request will be key to the attitude of the team. Be clear in your expectations, and reward the team members who stay on track and don’t get distracted by change requests. Monitor the team’s activities closely during this time period; get any people who are gossiping about the change request back to their regular project work. Of course, the team members might get too distracted with the change requests even with your close monitoring. If so, you can use another strategy: Separate the review and discussion on change requests to a meeting outside your status meetings. Call this meeting something different, such as “What-If Investigations,” to help keep things in perspective for the team. You might even consider changing out some of the people who estimate change requests and who are very distracted. Replace your key team members who can’t get past the distractions with less key individuals who can still do a good job of estimating and determining impacts. Remember the rhythm that you created when you started executing? You’ll want to continue beating the drum to the rhythm of the project and keep your team delivering to that rhythm. Don’t miss a beat because of change requests. You’ll know whether change requests should or shouldn’t be approved when they go to the CCB. You understand your project and the expected business result better than just about anyone. You want the right outcome. The “Politics” section covers influencing the CCB.

Politics You have probably heard that most executive decisions are made before the meeting where the decisions are made. Well, this is pretty true. Executives make sure that they have all the information they need to make a good solid decision. Usually that happens well before the decision meeting. You don’t want to take any chance that the CCB will make the wrong decision for your project. You can use some techniques before the CCB ever meets, as well as before decision meetings, to help get you to the outcome you are looking for. First, stack the deck in your favor before the start of the first CCB meeting. Set up a decision-making process that allows for disagreements and specifies how these disagreements will be settled. You probably want to establish a tie-breaker as part of the committee setup. Usually that tie-breaker is the

Controlling Changes

435

chairperson of the committee. The chairperson should be the person who has the most skin in the game: your executive boss. CCB decisions will be a breeze if you and your executive boss are on the same page. You’ll then watch change requests come into your project during execution, and you and your team will evaluate them. Send any change request that impacts the triple constraints to the CCB. You also should offer a recommendation for what you’d like to see happen. It might be wise to have some private conversations with the executives on the CCB instead of just sending your recommendation along with the other paperwork. You will want to meet with each of them for just a few minutes so they really understand the ramifications of the decision they are about to make. I’ve found that a good technique is to get on their meeting schedule for a CCB briefing. Bring all the paperwork with you when you have the meeting. Walk the executives through the material and make sure you answer all their questions. You have more homework to do if you think the executives will not make the decision you want. First, make sure you understand why they aren’t going in the direction you want. Then you have a couple of choices on how to handle the situation. One solution is to do some more homework. You know why the executive is not in favor of the way you think the decision should go. You also know his or her reasoning. You need to do some research to build a case against the executive’s way of thinking and a case for the decision you want. Go back to see the executive only when you have both cases built with new compelling information; don’t waste time trying to argue a case that you can’t influence if you haven’t been able to find new compelling arguments. It will also hurt your credibility to go back for no good reason. You might simply have to live with the executive’s decision. Another solution is to build strength in numbers. Your CCB might consist of several executives. If so, talk to each one and find out where they stand on the decision. You might find that each has a compelling reason to make the decision in your favor. You can use this new information on the holdouts, to explain the position of the rest of the CCB. Just the fact that the rest of the board is going in the opposite direction could be enough to sway the holdout executive. You probably get the picture here. Don’t wait for the CCB meeting to make the decision. Some of these decisions are too critical for you and the success

436

Chapter 13

of your project to stand by and let the decision get made without really good input. Stack the deck in your favor and continue working the issues to get the outcome you want.

Summary Change control is one of the important management activities that you must establish to keep your project on track. This chapter provided the basics you need to build a strong and effective change control process. We first covered what might get changed during a project. We also talked about a prerequisite activity: team norms. We then built a change control process step by step, with an explanation of the critical elements of each step. We also discussed the importance of tracking the changes both from the perspective of each individual change and from a summary or trending level. In the “Teaming” section, we talked about keeping the project team working to the rhythm of the project. Change requests can disrupt the flow of the work; work with your team to keep it on track. In the “Politics” section, we talked about setting up the Change Control Board to get the right outcome for your project. The VNLE project in the case study has been progressing for a couple months now. Chris has decided to step back and do a lessons learned session to see how things are going on the project. Let’s peek in and see what has happened over the last several months.

Case Study Wow! Chris was amazed that three months had passed since she had met with June and gotten approval on the timeline, budget, and MOP for the VNLE project. She had decided during her project planning to stop after a couple months and do a lessons learned session. She wanted to make sure that she was learning from mistakes on the project as the team continued to move forward. She had been jotting down items since she had baselined and now had a pretty good list of lessons learned from her perspective. She had also had a brainstorming session with the team. Together they built a pretty comprehensive list of what was working and what needed improvement. Chris was pleased with her terminology: She called that second category “what needs improvement” instead of talking about what was going wrong. It seems like people are less defensive when problems are phrased that way.

Controlling Changes

437

Chris decided to review the list one more time, before she took additional action on any of the items. She wanted to at least understand the major activities. She first reviewed what was going well.

VNLE Activities Going Well These things were going well: • Issues management—The first issue on the list was the rumor that Tina Johnson had heard regarding the awarding of points for the trade show. Chris had placed the information on the issues list and assigned it to herself. She had spent several hours after that talking to the trade show management team and getting to the bottom of the rumor. Tina was right after all; it came to light that the trade show will score one of the many categories differently than was originally published. The good news was the change they were implementing did not change the approach for Chris and the team. More importantly, Chris used that rumor as a way to demonstrate how the issues management process would work. The team saw how the issue had been documented, managed, and resolved. The process has been working smoothly since that first example. • Results of the quality audit—Chris’s project manager friend did a nice job with the quality audit. The results prompted Chris and the team to change a few of their procedures. Overall, however, everything was looking very good. The audit set up a nice baseline that they could compare against later. • Reward program—All team members agreed that the reward program Chris had established was working well. They were pleased and looked forward to the time when they would get a reward. Chris had set up the “Team Member of the Week” award, which she awarded at the end of every staff meeting. She highlighted the team member’s contribution and then provided a gift certificate for the closest book store. The team members got a little recognition and a free book out of the deal. Chris felt it was well worth $10 out of her pocket every week for the performance she was getting. That seemed to sum up the high points on the list. Chris was pleased about how things were generally going. She had taken some action immediately on

438

Chapter 13

the things that needed improvement. Next come the low points on the project so far.

VNLE Activities Needing Improvement The low point on the project included the following: • The frequency of the status meetings—Chris had decided to set up the status meetings for every other week (or twice a month) when she began executing the project. She had determined that, with no major scheduling issues, they would have plenty of time to recover if anything went wrong. She changed her mind on the frequency of the meetings after one month, though. The first reason was prompted by Task 2.5,“Design the sales booth.” The first status meeting revealed that the predecessor Task 2.1,“Design the booth sales approach,” had been completed and that the work of Task 2.5 had begun. Bill Ricardo had reported that he was 50 percent finished and had 1 1/2 days left to finish. That task also had more than 10 days of slack time. Yet the 1 1/2 days of work remaining had not been finished at Chris’s next status meeting. Bill mentioned that Greg Peterson had given him several other things to do, and he just hadn’t gotten back to finishing up that task. Thank goodness there were still a couple days of slack left, or this one task would have become the critical path. Chris had heard the old adage of how long can a task be out of control and the project manager not know about it, and she finally knew why it was true. The second reason that Chris changed the frequency of the status meetings had to do with the attitude of the team. A status meeting of every two weeks left the team members feeling that they had plenty of time to get the work done. They basically ignored their project work as soon as they left the status meetings and didn’t worry about it until a couple days before the next status meeting. At that point, it was too late to get as much work done as they had planned. Chris wondered if having plenty of time to get the work done would cause problems, and it had! Chris moved the status meetings to every week. That way, she was able to get a rhythm going and keep an eye on all the work that needed to get done.

Controlling Changes

439

• Change-control system setup—Chris had overlooked establishing the change control system until the team got into the execution part of the project. She actually didn’t remember to set it up until it was too late. The team had finished most of the work on the marketing plan. Robin had done a nice job of getting feedback from all the departments. She had even gotten Karla’s signature on the final marketing plan. Robin was well into the creation of the marketing collateral when Karla came back to her and said she had been thinking about the collateral and asked Robin to change a few things. Karla is Robin’s boss, so Robin thought nothing about making the changes that were requested. Robin reported what she was doing at the next status meeting and said that she was running behind schedule because of the changes. She also had to pay the materials vendor another $2,500 because she had changed the specifications on the vendor. Chris quickly realized that she had been delinquent in setting up proper change control. She told the team the mistake she had made and explained the change control process to them. They then put the marketing collateral change through the process. Chris would not have approved the change had the process been in place, but it was too late to stop it now; the project schedule and budget would have to live with her mistake. The schedule was now five days behind, which brought the project end date to the week before the trade show. Chris still had five more days of slack time between meeting the end date of the project and supporting the trade show event. The budget was a different story, though. Chris had no extra money beyond the $134,298 that June had given her. She knew she had to go to June and get her to agree to release another $2,500 out of the managerial reserve. Chris also knew that because of this problem, she had lost the possibility of the $10,000 for the “on the spot” awards. It was a good thing she had initially decided to not tell the team and had created the “Team Member of the Week” award! Chris called June as soon as the status meeting was over. She didn’t want June to hear about the problem through the grapevine. June did eventually release the managerial reserve and increased the budget to $136,798. Chris had some hard lessons learned on the “what needs improvement” list. She firmly believed that she had learned the lessons well and would not have

440

Chapter 13

these types of issues on her next project. But she also knew there was still be time to deliver this project as a success. She also still time to make more mistakes and to fail at one or more of the triple constraints. Chris knew she had better keep an eye on all the tasks and make sure her processes were working well. Chris then went back to her communication plan to determine what she needed to do next.

Review Questions 1. What do you control using a change control process? 2. What three baselined elements do you apply change control to? 3. What prerequisite activity needs to be established before you build

your change control process? 4. What the four things do you need from the requestor for every change request? 5. What types of changes does a Change Control Board review? 6. Who is usually on the Change Control Board?

14 Success!—Closing the Project “I can give you a six-word formula for success: Think things through—then follow through. —Edward Rickenbacker

Topics Covered in This Chapter Preparing for Implementation Closing the Project Teaming Politics Summary Case Study

You are heading into the final stretch of your project. This chapter covers the activities that you perform just before the end of your project. You’ll spend time planning the end of the project, conducting a readiness review, verifying your deliverables, and finally turning over the project to operations. You’ll also learn about the last set of activities that you perform to close the project, including archiving the project documentation and gathering lessons learned. Have you ever had a project that just wouldn’t end? The “Teaming” section covers this situation, which I call the 95 percent phenomenon. I’ll give you some practical ways to motivate your team to complete the project. The “Politics” section discusses how to blow your own horn tactfully and gracefully. Chris is at the end of the VNLE project and is going to have the trade show from hell. Let’s check in and see if she is able to pull off the score she has committed to.

441

442

Chapter 14

Preparing for Implementation You are finishing up the tasks of your project and are probably thinking that you have finally made it to Easy Street. Well, hold on there. You still have a couple important activities to do to prepare for implementation. You’ll start with a concept called a readiness review.

Readiness Review A readiness review is just what it sounds like: a review to make sure you are ready to hand over your project and its product to your operations. You use this technique on medium- to large-sized projects to assure the project’s executives that everything is ready to go. You might not need to do a readiness review if your project is small or if your company routinely undertakes projects. You first need to identify what should be in place to ensure a smooth handoff to operations. This planning activity should actually start well into the planning or execution of the project. You will want to gather as much information as possible to make sure the implementation of your project works without a hitch. First look around the operations environment. How is work conducted? Plan to interview the operations personnel to find out how they would like to have the implementation occur. Put yourself in the shoes of the executives. What would you be worried about if you were in their shoes? What should you check out before you begin the turnover? Last, you might want to look at lessons learned from previous projects. What worked before when turning over a project? What did not work? Build a list of components to review or verify for completeness before you begin the hand-off. I’ve separated the example list into what every project manager should be looking at and what to consider if you are managing IT components as part of your project. Here’s the list for every type of project manager: • Methods and procedures—Have all methods and procedures required to work with the product been created? • Training—Have all personnel who will work with the product of the project been trained to work effectively with the product? • Testing completed, reviewed, and signed off on—Has any testing that was planned for the product of the project been completed? Has the client signed off on the testing results?

Success!—Closing the Project

443

• Compliance—Has the product of the project passed all required standards and audit requirements? Have signatures been obtained? • Notification—Are the notifications that the product is being transferred to operations written and ready to be sent? • Conversion required?—Does the product of the project replace an existing product? If so, does the old product need to be removed from inventory? How will the product be disposed of? • Operational staffing—What additional staff is required to manage the product of the project? Has a staffing plan been created? Has the staff been acquired? Here’s the list for those managing projects with IT components: • Capacity planning—Has the proper analysis been conducted to determine the size of hardware needed to run the application? • Defined and implemented operation environment—Was capacity planning taken into consideration when the hardware was ordered? Has the hardware been purchased, installed, and configured for production? Has a disaster recovery plan been created? Have the proper utilities for restoration and recovery been put in place? Have installation plans been documented? Does the production department know how to install the software? Has the production department signed off on the assurance statement that the hardware is ready? • Installation of workstations—Does your project include the installation of workstations? If so, is the installation complete? Has the appropriate software been loaded on each? Have the licenses been purchased? • System documentation—Has all documentation that is needed for smooth operation been completed? Has the documentation been reviewed with the operations staff that will operate the application in the production environment? • Service level agreements—Have the appropriate service level agreements been put in place? Have signatures been gathered?

444

Chapter 14

This is a pretty comprehensive list, but you might need to add still more to it. Your project is a unique endeavor, so you might need to have unique activities on your list to inspect for readiness. You’re probably getting the picture. This is your checklist that states that the project deliverables are ready. Let’s go back to the running example project and look at the readiness checklist for the TTR project (see Figure 14.1).

Responsible

Target Close Date

Jodi

1/15

Has the trainer been trained?

Jodi

1/30

2.2

Has the pilot class been completed?

Jodi

3/1

2.3

Have the results of the pilot class been confirmed and signed off?

PM

4/1

Number

Issue

1

Methods and Procedures

1.1

Are the guidelines to train the trainer completed?

2

Training

2.1

3

PM

4/15

Sue

6/1

Has a staffing plan been created?

PM

1/1

Is the staff ready to use the new product?

See 2.1

Conversion Have old training materials been disposed of?

6

See 2.2

Notification Is the notification ready to go?

5

Status

Testing Completed Has the pilot class been completed?

4

Actual Close Date

Operational Staffing

Figure 14.1 TTR readiness review checklist

Step through your project and create the list shown in Figure 14.1. You’ll see that a lot of the general issues in the checklist are covered with some of the activities that you had planned. An example is “Is the staff ready to use the new project?.” That is covered by your activities to train the trainer. Use this checklist to make sure that you’ve tied up all the loose ends before you turn over the project to operations.

Success!—Closing the Project

445

You might consider having a formal readiness review meeting after all testing activities have been completed and before you turn over the product to operations. This is your final check that the project should proceed with formal acceptance. You will perform a second activity, called scope verification, when your readiness review is completed. I cover this next.

Scope Verification You must set up a formal process at the end of the project to provide the final inspection of the product of the project. This activity is sometimes called scope verification because it enables you and your client to inspect the product of the project and make sure that it matches the scope that you originally identified for the project. This activity involves comparing the scope statement from your project management plan to the deliverables that you have created. The result of this formal review is a signed document from you and the client that the deliverables are formally accepted and ready to move to operations. You would set up the formal review process for the TTR project after the pilot training class is completed. You would also make sure that the following tasks are completed before formal acceptance: • • • •

3.10: Verify that the learning objectives are met 3.8: Verify that the training class is 50 percent less 3.2: Time the pilot class 3.18: Monitor for customer complaints

Completing all these tasks implies that the formal acceptance meeting would happen 30 days after the pilot class finishes because the last task has a 30-day duration. The executive sponsor, the CSR supervisors, representatives from the training department, and, of course, the project manager should attend the formal acceptance meeting. You present the results of the pilot class regarding the learning objectives, the timings, and customer complaints. All this information must prove that the MOP has been achieved when turnover happens. You provide a formal acceptance document for all participants to sign if everyone concurs.

446

Chapter 14

You then can turn over your product to the training department, to execute the first real class with the new training materials. Your MOP requires validation with a real class, so you will continue to monitor the results during and after the class.

Turnover The process of turning over your deliverables to operations is unique to every project. You’ll want to accomplish that with the same level of planning that you put into the beginning of your project. Now is not the time for sloppy work. You will be familiar with this process if you’ve ever bought a new house. It involves a formal walkthrough of the property in which you create a list of issues that need to be resolved after turnover. Then you sign all the legal documents and, as the new homeowner, accept the keys. One of the most successful turnover approaches I’ve seen is to hold a formal turnover meeting in which the project team describes each deliverable and their components. The deliverable is then handed off from one person to the next, either figuratively or virtually. With a virtual turnover, you provide the location of the product and assign one of your team members to work with one of the operations personnel to manage the physical movement of the product. Issues are captured, and an accountable person is assigned to complete any remaining issues. After formal turnover, you start winding down all the project activities.

Closing the Project It seems like this is the time to take your next assignment and move on. But you need to do a couple additional activities to close the project. First, you must learn the archiving procedures at your company. Your organization might not have a policy or procedure, so check within your department and perhaps with your boss. Use these procedures as a guideline for what to do with your project documentation. Then gather your project documentation, including the project plan, the official sign-off, the product requirements, and any other pertinent documentation that you and the team have produced throughout the life of the project. Then prepare the documentation for archiving according to your company procedures.

Success!—Closing the Project

447

Some organizations do not have procedures in place for archiving. Good project managers usually prepare a directory with their computer documents area and move all the electronic files into the directory structure. They scan in paper documents such as sign-off sheets and place them in the directory structure. They also prepare an index file that explains what all the documents are and identifies where they are in the directory structure. Finally, they move the entire structure and create a couple CDs that include all the information. They give one CD to the client of the project and to the project manager’s boss, and they keep one for themselves. Hold off on burning that CD right now, though. You need to create one more official project document: a lessons learned document.

Lessons Learned Identifying lessons learned is a fundamental process that you put in place when you want to improve your work and the work of your organization. You do this to look for the processes, tools, and techniques that worked well on the project, as well as the processes, tools, and techniques that need improvement. The previous chapter’s case study section mentioned the importance of phrasing the pros and cons of your project. People tend to be less defensive when you talk about “things that need improvement” versus “things that just didn’t go right.” You will want to set up one or more meetings to have a facilitated brainstorming session when it is time to gather lessons learned. Why one or more meetings? You know your team and your client pretty well by now, and you know whether you will get good information if they are all in the same room together at the same time. You might want to consider having several meetings if you’re worried about information sharing. Find a person in your organization to facilitate the session. You should not act as the facilitator; you’ll want to freely contribute, the same as the rest of your team. Also be sure to set aside plenty of time for this session. Start the meeting by setting some ground rules: • No subject is off-limits. • Speak in terms of process problems, not people problems. • When you want to talk about what worked right, you can speak specifically about individuals.

448

Chapter 14

Have the facilitator conduct the meeting and get information from the team members on both what worked right and what needs improvement. You might even consider obtaining suggestions on how to implement improvements. Sometimes these sessions turn into a “pat yourself on the back” session. There’s nothing wrong with that, but people tend to avoid the hard discussions. You might have to broach that first hard subject to get the other team members to disclose what didn’t work from their perspectives. The facilitator should look for duplicates and ideas that can be consolidated. You should probably end the meeting with a thanks to all who participated. The next project will go better, thanks to them. Figure 14.2 shows a lessons learned document sample. What Worked Right?

What Needs Improvement?

1. The team worked well together.

1. Change requests took longer than was estimated.

2. The project manager kept us well informed.

2. The executive offices were not prepared for the new class conversion.

3. The pilot class was well received.

3. We were not ready for the pilot class.

Figure 14.2 Lessons learned sample

The lessons learned process is not finished when you have two columns of ideas generated on paper. The key to real lessons learned is to find an organizational owner for each issue that needs improvement. This owner should look for ways to solve the issue going forward. Turning over the list to a PMO for resolution would be a perfect solution. Your organization might not be set up for accountability to improve the project management processes, so the next best thing is you. Here is an opportunity for you to hone and improve your project management skills. Review the list and determine what you should work on, what you should fix for the organization, and what you should fix personally. Pull out this list before you start the next project, and review what worked and what needs improvement. Know what you do well, and make it better. Know what you can do to improve, and make it happen on your next project. Also take the time to document the performance of each individual who worked for you on your project. You should create an appraisal or at least provide some feedback regarding each person’s performance, depending on

Success!—Closing the Project

449

the agreement you have with each member’s boss. Your high achievers will thank you for it. Your not-so-high performers will hopefully learn from the feedback.

Celebrate! Take time to celebrate before you move on to your next assignment. You and your team need to stop for a moment and savor the victory of completing the project. You don’t need to have a wonderful monetary award for each individual on the team; most companies don’t provide such bonuses. But do find a way to reward your team members for their work. One creative project management friend of mine uses a nice technique to recognize her team members. She captures silly quotes from people throughout the project and compiles a list of them. She gives a framed set of Project Quotes to each team member at the closing meeting so they can remember some of the fun they had working on it. She also provides a testimonial for each team member: I’d like to acknowledge Joe for his contributions on the project. The contribution that sticks out in my mind is when he realized that the shipment didn’t contain the final packing list. Weren’t we surprised when we looked out our office window and saw him running after the delivery truck to get that packing list into that shipment? Here’s to Joe.

This type of acknowledgment keeps people wanting to work on her teams with future projects. You can do this or find your own way to celebrate your success. Have a party, or just stop and talk to each individual for a minute—but find something that works for you in your organization. You are ready to close down your project, but your team might not want to. Let’s talk about that next.

Teaming Your team has been making great progress. The project is just about ready to wrap up. You are ready to set up the formal deliverable meeting. You determined at the last status meeting that the project is 95 percent complete. The project is 95 percent complete at today’s status meeting; no progress has

450

Chapter 14

happened. The goal line is so close you can taste it. Why are you still at 95 percent complete? You are experiencing the 95 percent phenomenon, in which the team just can’t finish that last piece of work and can’t complete the project. Something is standing in the way of getting the project finished. The first possible issue in the way is fear of completion. Your team members likely have moved into the performing stage of team development and are performing like a well-tuned machine. They are experiencing camaraderie, kinship, and an environment of success. Sometimes things are so good that they don’t want the experience to end, and they start faltering at the finish line. The second issue is fear of the future. Your team members might not know what they will do when the project is finished. Do they have another project to move to? Are they being released from your company? Why would they want this wonderful experience to end if they don’t know what they will do next? Your job as the project manager is to help allay the fears of the project team as you near project completion. You can take some specific actions to help get past the 95 percent phenomenon: • You need to dispose of the resources on your project. Dispose isn’t a good word when you are talking about human resources, but the intent here is to make sure every resource knows what comes next. Have a conversation with each resource near the end of the project, and make sure each person knows what he or she will be doing and who he or she will be working for when the project is finished. • Your team has helped create this environment of success they are all working in. Have a private conversation with any high performers who are faltering at the finish line. Make sure they understand that they helped create the environment of success on the project. They also have the power to re-create this environment on the next project, regardless of whether you are the project manager. They can always coach and mentor the next project manager, if needed. Sometimes this assurance that the next situation will be just as good is enough to get people moving forward. • Tell individuals who are leaving the company or moving to a new part of the organization that you’ll provide a reference for them. This assumes that you have already removed the troublemakers and poor performers from the project. Sometimes knowing that you have documented their performance and will offer a reference is enough to allay people’s fear of moving to completion.

Success!—Closing the Project

451

You’ll continue working with your team members to get the project done and out the door. You might find yourself having a lot of small meetings to understand the fears and the issues that are keeping your team members from finishing up. This will be time well spent. Your team is back on track and you are ready to finish up your project; it’s time to get in to see your executive again

Politics You work in three steps when you do a presentation: 1. Tell them what you are going to tell them. 2. Tell them what you want them to know. 3. Tell them what you told them.

That’s pretty straightforward. You use that same philosophy when dealing with your executives on your project. You start by laying out a really good plan that spells out the MOP, time, and budget parameters. You get your executives’ agreement that these are the right parameters. You then tell them that you will deliver to those parameters after they agree (you tell them what you are going to tell them). You tell them all the way through the project how you are doing and exactly what you are doing to deliver to those parameters (you tell them what you want them to know). Then you tell them at the end of the project that the job is done (you tell them what you told them). Why do so many of us have a problem blowing our own horn when it comes to project success? Maybe it’s just the thought of bragging. Many of us were conditioned not to brag about ourselves when we were growing up. The key here is that you are not bragging if you are just stating the facts of what has been done. Don’t assume that your executives have noticed that you have delivered exactly the way you said you would. They might be too busy to notice. Get a couple minutes on their schedule to talk about the project objectives and completion. Couch the discussion in a lessons learned discussion, and make sure they know that you did exactly what you said you would do. This is the time to make your next political move, to ask for the next big project or position yourself for the great appraisal or possibly that big

452

Chapter 14

promotion. You start this process by making sure that your executive knows that you will deliver on what you say you will deliver on and that you understand the big picture when it comes to your company. You’ve proved this big-picture thinking by delivering a business result in the form of your MOP. Aren’t you glad you took the time to craft the right MOP? Now is not the time to be shy and bashful. Now is the time to state facts on your performance and the performance of your project. Remember, you are not blowing your own horn; you are just providing data on the project and your performance.

Summary Closing a project is an emotionally challenging time for both the project team and the project manager. But you’ve executed the project well and are closing it down with the same flair as your execution. This chapter discussed the activities that you must perform just before closing. This includes planning the end of the project, conducting a readiness review, verifying your deliverables, and finally turning over the project to operations. We also covered the actual closing of the project, in which you perform activities such as archiving the project documentation and gathering lessons learned. In the “Teaming” section, we talked about the 95 percent phenomenon and what to do if the team won’t finish the project. Hopefully, we’ve provided a couple sound techniques you can use if this happens to you. In our “Politics” section, we talked about making political moves. This includes telling your executives about your project successes and making sure they know that you are a big-picture thinker. Now is not the time to be shy and timid about what you’ve accomplished We finish up the VNLE project now with Chris attending the trade show and having a few problems along the way.

Case Study Chris was amazed by how the time had flown on the project. Today is Monday, and the trade show is Friday, Saturday, and Sunday this week. Chris plans to fly out on Wednesday to set up for the trade show on Thursday. The show begins at 10 a.m. on Friday.

Success!—Closing the Project

453

What a whirlwind this project has been! The project got off track at least three times since her last lessons learned session and required some extensive work from Chris and the team to get it back on track. The major problem they had, though, was the VNLE Web site not being ready on time. Chris was tracking that project, too, and she was able to sound some alarms about six weeks ago that the Web site would not be done in time for the trade show. Chris and Carl Price, the Web site project manager, did some extensive planning to build a workaround so the trade show could go off without a hitch. The Web site was missing the interface to the ordering system, so Carl set up the Web site in a computer environment where only the trade show participants would be able to access it. They could browse the catalog and order anything, just as if they were on the real Web site. The only difference was that it looked like everything was being done electronically. In actuality, a message was being sent to a temporary employee who filled the order via a piece of paper that she ran down to the warehouse after she had called the bank to okay the credit card payment. They had figured out a way to make everything look like it was working when it wasn’t. The term Carl kept using was “smoke and mirrors.” The other good news was that, with the workaround, Carl was able to get a few more weeks to finish his project before the system went live after the trade show. Carl’s project also was paying for the temporary Web site and the other computer environment. Chris was able to keep her project to the budget of $136,798. Today Chris and the team were doing one more review to make sure they were ready for the trade show. Chris had created a checklist, and she and the team had spent the morning going over the checklist one more time. They had verified the following: 嘼 嘼 嘼 嘼 嘼 嘼 嘼

The logistics had been completed. The booth had been shipped and received. The demo was working. All the salespeople had been trained on the demo. The meetings with the vendors had occurred. The vendor feedback forms had been created. Everyone going to the trade show was healthy and ready to go.

454

Chapter 14

Chris also set up a conference call with June for Sunday night at 7 p.m. to tell her the results of the trade show. The show was supposed to end at 6 p.m., and they planned to have their results by 6:30 p.m. Chris busied herself with last-minute details for the next couple days. She also spent some time with each of her team members to make sure they knew that they would return to their regular jobs on Monday. Chris asked them to spend some time with her on Tuesday morning to do a lessons learned session on the project. Chris knew the feedback would be valuable if the company wanted to try this type of market launch again. She also got a time slot on June’s meeting calendar so they could talk about how well the project had gone. Chris felt that she was ready for a promotion and planned to make sure June knew why Chris was ready. Chris also planned to ask June to mentor her to her next promotion. But before she knew it, Chris was landing in Las Vegas and heading to her hotel on Wednesday night. Chris and Robin started putting the booth together with the convention staff on Thursday morning. They opened the boxes and realized that, during the shipment, all the lettering had fallen off. Evidently, the booth constructor had not let the glue dry sufficiently before crating everything up. Chris and Robin worked until midnight reapplying the letters and finishing the setup of the booth. The trade show opened, and the first day went without a hitch. Chris kept looking over her shoulder, though, to see if the lettering was still there. Two of the salespeople called Chris at 6 a.m. Saturday and said that they had gotten food poisoning at dinner the night before; there was no way they’d be able to support the booth. Chris knew that she and Robin would have to spend the day at the booth helping out. Chris was disappointed, though. She needed to spend time with Jacob Liesel and make sure he was getting feedback from the vendors on the trade show experience. He knew what needed to be done, so Chris would have to trust that he was doing what was assigned to him. Chris ended up going to bed at 9 p.m. after that long day. Chris got a call again Sunday from the two salespeople, and they were still sick. She worked with the hotel to get them in to see a doctor. They were supposed to fly home that night, but they wouldn’t make it in the condition they were in. Chris got to the trade show a little late. She was relieved to find Robin and the other two salespeople working with potential customers. Robin whispered to Chris later in the day that when she arrived, she had found that several of the letters had fallen off the display again. She had brought some safety pins with her and ended up pinning the letters to the

Success!—Closing the Project

455

display. She was pretty pleased that they barely showed. Chris rolled her eyes and wondered how they would ever get a good rating, with all the challenges they’d had. The crowd started to disperse at 6 p.m., and Chris was finally able to catch Jacob to find out how things were going with the vendors. He had run into several who were noncommittal, but several others had been pleased with what they had seen and wanted to continue partnership discussions. Chris, Jacob, and Robin started tearing down the booth, removing the safety pins from the letters and getting everything ready for shipment back to the office. The trade show management took the stage and announced the awards for the show at promptly 6:30 p.m. Chris and Virtually Nostalgia did not take the award for best booth. They also didn’t take the award for biggest crowd. In fact, they didn’t take any of the smaller awards. Chris was feeling pretty disappointed that all their hard work had been sabotaged by display letters and food poisoning. The convention center management then made the announcement for best in show. Chris had already gone back to tearing down the booth and trying to figure out how she was going to explain everything to June. Virtually Nostalgia’s main competitor in this market, Bye Gone Days, took best in show, with 130 points. The convention center management then awarded the final award, “Best New Vendor,” to Virtually Nostalgia, with 126 points! Chris rushed to the stage, accepted the award, and then rushed out to call June. Chris headed to the airport with an incredible roller-coaster day under her belt, only to find that her flight had been cancelled because of bad weather in Denver. Chris had to laugh, though: it really had been a good day, even with a cancelled flight. Chris made it back to the office on Tuesday morning just in time for the lessons learned meeting. To her surprise, June was there. June wanted to thank the team members for all their hard work, creating such a successful launch for their market. June continued and told the group that she had heard about a concept called “on the spot awards” and wanted to personally give these checks to the team. She gave each core team member a check for $1,000. Chris received a check for $3,000. June had given the team the $10,000 she had promised, even though they had overrun the budget by $2,500. Chris tried to compose herself and the team after June left and get them back to the lessons learned and the task of closing the project properly. It was pretty hard, though; everyone was so excited about the award. This had never happened at Virtually Nostalgia. The team decided to wait until

456

Chapter 14

Wednesday, when they could concentrate again to complete the lessons learned. Chris went back to her desk and thought she’d clean up some of the proper paperwork. She checked her e-mail first and found a meeting request from June. The message also said,“Since you’ve done such a phenomenal job with this launch, let’s start talking about your next assignment. Come see me tomorrow afternoon.” Chris was a little disappointed. She had been hoping for a couple weeks before she jumped into the next project. But she also knew that this was the price you pay when you are good at what you do. Chris wondered if this was the time to broach the subject of a pay raise.

Review Questions 1. What is a readiness review? 2. When do you plan for a readiness review that is conducted at the end 3. 4. 5. 6. 7. 8.

of the project? What components should be reviewed or verified for completeness before you begin the hand-off to operations? What IT components should be reviewed or verified for completeness before you begin the hand-off to operations? Give the name of the formal process that you set up at the end of the project to provide a final inspection of the product of the project. Describe the lessons learned process. Why should you be careful in how you phrase the objectives of a lessons learned session? What is the 95 percent phenomenon?

Answers to the Review Questions Chapter 1 1. A project is a unique endeavor that has a beginning and an end. 2. Operations are activities that are ongoing or repetitive, whereas projects are constrained to end. 3. Communications is the strongest skill a project manager must have; it will take 80 to 90 percent of his or her time. 4. The corporation’s strategy is input into the organizational project management hierarchy. 5. Organizations use portfolio management to identify, prioritize, manage, and control projects, programs, and other related work, to achieve specific strategic business objectives. 6. An organization would establish a program to manage projects in a coordinated manner to achieve the strategic objectives and benefits. 7. PMOs typically perform some or all of the following functions: • Report on the status of projects, programs, and portfolios • Create project management standards that are used throughout the hierarchy • Act as a resource pool for experienced project managers that is used throughout the hierarchy • Allocate resources across the entire portfolio 8. The two types of organizations are functional and projectized. 9. A project manager would want to work in a projectized organization because this type of an organization has realized that it needs projects to deliver the company’s strategy and has set up the organizational structure to support project management. 10. The two intersecting life cycles that you need to be aware of when managing a project are the project management life cycle and the product management life cycle. 11. Norms are a set of rules that you and your team members agree to abide by in your dealings with each other. 457

458

Answers to the Review Questions

Chapter 2 1. A project goes through an authorization process in which a project charter is created. 2. A Measure of Performance consists of a driver and restrictions. 3. The Measure of Performance driver provides a single statement that describes the business result that must be achieved. It is always described in measurable terms. It doesn’t describe the activities of the work; it sticks to the result or outcome of the work. 4. A MOP restriction is a boundary that you will need to work within to succeed. 5. A preliminary scope statement defines the objectives and parameters of the project. You create a scope statement to begin defining exactly what your project will do. 6. The term “progressive elaboration” defines the process that you go through to plan a project. You start with an idea or an objective that is given to you. You then define, step by step and layer by layer, the activities that the project must do to succeed. You start this progressive elaboration with the preliminary scope statement. 7. The three types of cost estimates are order of magnitude, budget, and definitive. 8. Industry information says that order of magnitude estimates can be 75 percent higher or 25 percent lower than the actual cost of the project. 9. A project plan is a road map that provides all the context for the project. You document in it your thoughts and actions for every aspect of the planning you are about to undertake. You also provide information on how you will execute this plan, as well as how you will monitor and control the plan. 10. Typical elements of a project plan include these: • Scope information • Work breakdown structure (WBS) • Schedule • Risk plan • Human resources strategy • Cost elements

Answers to the Review Questions

• • • • •

459

Communication plan Procurement plans Quality management Project execution plan Execution monitoring and controlling

Chapter 3 1. The preliminary scope statement captured the project objective, the MOP driver, and the project constraints in the form of the MOP restrictions. These two pieces of information are added to create the project scope statement: • The deliverables for the project—the tangible output that can be handed over to show that work is being accomplished • What is explicitly included or excluded because of things such as budget restrictions or geographical limitation 2. Product requirements creation is a process that starts with high-level concepts and, through a series of decomposition steps, creates specific statements that describe the product from several aspects. This process is made up of four basic steps: setup, gathering, confirming, and baseline and control. 3. These are the two deliverables of the setup step of product requirements: • The intended audience • The work of the project in a graphical model 4. The gather requirements step in the requirements process is a multidimensional piece of work. The project manager and the project team must understand the dimension of the work that the user currently does and the dimension of what the user wants the work to do in the future. You must understand the following to help you uncover all the requirements needed: • Tools and techniques for gathering requirements • Approaches for gathering requirements • Writing requirements • Levels of requirements

460

Answers to the Review Questions

5. The three levels of product requirements are business, functional, and nonfunctional requirements. 6. These two approaches are used to confirm requirements: • Confirm and verify each requirement • Confirm and verify the entire requirement set 7. You must baseline the requirements when your requirements have been signed off on. This baseline then is essentially “frozen” in its approved state and provides a point of reference to determine whether the project is meeting the planned functionality. 8. A work breakdown structure is a hierarchical depiction of the work of the project that covers the total scope. 9. The first level of a WBS usually depicts the project name or MOP. 10. Desk testing is a human test of the work so far, to guarantee that you are still in the scope that you defined. This verification should be done at the end of every level of decomposition that you complete.

Chapter 4 1. Take three items into consideration when you are determining whether to break down a work package into smaller tasks: • Possible task duration • To-do tasks versus empowerment • Real activity 2. Defining completion criteria makes it clear for both you and the person working on the task when it is acceptable to say you are finished. 3. The three types of dependencies are mandatory, discretionary, and external. 4. A successor is a task that is done directly after another task. 5. A predecessor is a task that is done directly before another task. 6. These are the four types of dependency relationships: • Finish to start • Start to finish • Start to start • Finish to finish

Answers to the Review Questions

461

7. Lag time is used between a successor task and a predecessor task to depict some passage time that must occur before you can start the successor task. 8. The output of the precedence diagramming method is called a network diagram. 9. In 1965, Bruce Tuckman created a model that describes the steps of working together that a normal project team goes through in creating an effective team. He described these steps as follows: • Forming—Orientation to the project’s objectives, the project manager, and each other • Storming—Struggle for control, power, and influence • Norming—Cooperation and establishment of productive work practices • Performing—Interdependence, cohesiveness, and high productivity 10. Team norms are also called rules of engagement.

Chapter 5 1. An order of magnitude estimate is also sometimes called a top-down estimate. 2. A definitive estimate is also sometimes called a bottom-up estimate. 3. The analogous estimating technique involves finding a completed project that is similar to the project you are trying to estimate. You use your own expert judgment to determine what is a similar project and then use the previous project estimates to derive the estimates for your project. 4. Parametric modeling is a computer-based estimating method. Data from thousands of previous projects is analyzed in this mathematical model. The specific data that is analyzed is product elements and their costs and schedules. 5. Bottom-up estimating is the most accurate estimating method. 6. The three points of three-point estimating are most likely, optimistic, and pessimistic.

462

Answers to the Review Questions

7. Reserve analysis requires that you review your estimates for risk and apply an amount of padding to the estimate. 8. The three types of resources are humans, equipment, and materials. 9. You must estimate resources, costs, and duration on projects.

Chapter 6 1. The modern-day gurus of quality management are Deming, Baldrige, Juran, and Crosby. 2. You must understand the applicable quality standards when planning quality into your project. You should investigate industry and organizational quality standards. 3. A project manager should create a quality policy for the project if the organization does not have one. 4. Quality involves two different aspects of quality: • Are you creating the right product to satisfy the objectives for which the project was undertaken? • Are you using the right processes to create the product? 5. The cost of quality is defined as the total costs incurred to provide the proper quality for the product. The cost of quality consists of the cost of conformance and the cost of nonconformance. 6. Prevention and appraisal costs are the two types of conformance costs that must be calculated as part of the cost of quality. 7. The two types of cost of nonconformance are internal and external costs of nonconformance. 8. The second stage of team development according to the Tuckman model is storming. 9. You use a decision log to avoid having the team constantly revisiting decisions that have already been made.

Answers to the Review Questions

463

Chapter 7 1. You plan communication for several reasons: • To keep your stakeholders apprised of information that they need to know • To help people with the changes they might have to make because of this new product • To provide status to everyone with a need to know • To manage perceptions about the project • To keep stakeholders appraised on project risks and responses • To disseminate the right information, in the correct format, to the right people at the right time 2. The audience identification list forms the basis of who should have project communication. 3. You can think through when to do project communication according to both project life cycle and project events. 4. Use the “why” as a way to express the outcome you want to achieve by communicating. 5. Column 4 of the communication plan identifies what needs to be communicated. Here is where you get specific about what you want to tell the recipient of the communication. Ask yourself,“What is the content of the message that should be provided here?” 6. The How column of the communication template documents exactly how the communication will be delivered to the recipients. 7. Analyzing the communication needs of an individual involves asking yourself,“Is this person a champion, a challenger, or an influencer?” If not, ask yourself,“Is there sufficient communication for each person in each group here?” If so, ask yourself,“What do I need to do to guarantee the communication?”

464

Answers to the Review Questions

Chapter 8 1. These are the typical elements of a risk strategy: • Your risk policy • Risk definitions • Risk glossary • Risk roles and responsibilities • Risk timings 2. The two ways to gather risks are formally, via a risk brainstorming session, and informally. 3. You can gather risks informally in two ways: • Status and risks • Impromptu 4. Risk impact is the extent of damage that can be done to your project if the risk actually happens. 5. Risk probability is the chance that a given event will occur. 6. You build a threshold of risks order to determine exactly what risks to create response plans for. 7. You can use four strategies when deciding how to respond to the risks on your project: avoid, transfer, mitigate, or accept. 8. Avoid This strategy implements planning activities to prevent the occurrence of the risk. You actually create new tasks for your project schedule and update your project plan accordingly. 9. Transfer You actually give the risk to another party to deal with. The risk then becomes that party’s responsibility. 10. Mitigate This risk strategy softens the potential problems that a risk might present to your project. 11. Accept This strategy involves accepting that the risk exists and deciding not to do anything about it.

Answers to the Review Questions

465

Chapter 9 1. The critical path is the series of tasks that must be accomplished with no delay to meet the end date of the project. 2. You use three sets of calculations to determine the critical path. First you do a forward pass, then you do a backward pass, and then you calculate the float. 3. The near-critical path is a path of the network diagram that has very little float available. That path can become the critical path if a delayed task uses up the float. 4. A resource histogram shows how each resource is used on every day of the project. This bar chart shows the number of days that a person will be needed to work over the course of the project 5. You should use this strategy when assigning resources to project tasks: • Assign the best and most dependable resources to the critical path. • Assign the rest of the resources to the project. • Do a resource histogram to determine where you have resource issues (for instance, where too much work is assigned to one person). • Deal with each issue by adding more resources or redoing the schedule. 6. Schedule compression consists of activities that you do to reduce the duration of your project. 7. The three duration-compression techniques are crashing, fast-tracking, and descoping. 8. Project managers use a 60,000-foot network diagram to make sure that they understand the flow of the work, the timings of the hand-offs from department to department, and the major events that trigger a hand-off. Think of this as your roadmap through the major events of the project.

466

Answers to the Review Questions

Chapter 10 1. The budget is a money amount that covers the entire cost of the project. 2. The order of magnitude estimate is created at the beginning of the planning cycle. It is a guess about the total cost of the project. 3. You worked with duration estimates when you build the schedule; you work with work effort estimates when you build the budget. 4. A loaded salary rate is the salary of the person, plus the amount of paid vacations they receive and the benefits they receive. 5. An average salary is the actual amount of money each project manager at your company makes divided by the number of project managers. 6. A reserve is an amount of money that is set aside as part of the budget but that is used only for specific types of situations. 7. The two types of reserves are project reserve and managerial reserve. 8. Two major differences exist between a project reserve and the managerial reserve: • The project manager cannot use managerial contingency without the project executives’ approval. • The managerial contingency is used for risks that are unknown; the project reserve is used for known risks. 9. A fee is a money amount that must be paid because of your project. Most times, this fee is associated with the entire project, not a specific task. 10. You might realize after calculating the budget that the amount of money that you need is way over the amount of money that has been set aside for this project. Dealing with this overage is called budget reconciliation. 11. The cost baseline is not the entire budget. It is a subset of the budget that has to do with the work of the project. It is the cost of resource per task.

Answers to the Review Questions

467

Chapter 11 1. A baseline provides a point in time for you to compare your plans against what is actually happening during project execution. 2. The schedule baseline is a copy of the tasks that must be completed to execute the project on time. This is usually a copy of the network diagram or a Gantt chart of the schedule. It shows each task and the predecessors and successors for each task, as well as the needed duration of each task. 3. The cost baseline is the sum of all the work of the tasks of the project, by resource and resource rate needed per task. Another view of the cost baseline is the budget minus any fees, reserves, or contingency money. 4. The product requirements baseline is a copy of the product requirements that the client and executive sponsor of the project have signed off on. 5. The quality baseline is the information that you gathered in your quality planning process. This information spells out the quality objectives that you have planned for the project. 6. All these baselines together create what the PMBOK® Guide calls the performance measurement baseline. 7. Your project status meetings should be often enough that you can answer the question “How long can a task be out of control without me knowing about it?” 8. An issue is an item that requires discussion or research to complete a task. 9. These types of activities are performed during project execution: • Performing the tasks of the project • Staffing the project • Training resources • Managing human resources • Managing other resources • Installing methods and procedures • Collecting work performance information • Reporting on project information

468

Answers to the Review Questions

• Executing your communication plan • Implementing approved changes • Validating project deliverables • Gathering lessons learned • Performing risk management 10. You might find that the activities you have planned for quality are not substantial enough to guarantee the quality. You should perform a quality audit to determine whether you need to implement more quality activities.

Chapter 12 1. You should ask five questions when gathering status: • How much work (hours or days) has been completed on the task? • What is the percentage of completion? • How much work remains to be done? • What was the actual start date? • Are any issues preventing the completion of the task? 2. The two types of analysis that you do while monitoring and controlling the project are variance analysis and the earned value technique. 3. The earned value technique is another way of measuring work performance and comparing it to what was planned. Earned value gives you the opportunity to look at both the variance of the schedule and cost variance in the same analysis. 4. This is the formula for schedule variance: Schedule Variance = Earned Value – Planned Value 5. This is the formula for the cost variance: Cost Variance = Earned Value – Actual Cost 6. The two index formulas for earned value analysis are the Schedule Performance Index and the Cost Performance Index. Both of these indexes measure the efficiency of how your project is executing.

Answers to the Review Questions

469

7. You monitor and control the risks of your project while you are executing your project. You must continue your risk process as new risks come up. You monitor your master risk identification list and watch for alarms, and you identify any residual risks that appear. You also monitor your entire risk process to guarantee that it is working effectively.

Chapter 13 1. You control any request that changes the plan of record, which you baselined at the end of planning. 2. You apply these three baselined elements to change control: • Product requirements • Schedule • Budget 3. The one prerequisite activity that you need to establish before you build your change-control process is establishing team norms. 4. You need four things from the requestor for every change request: • A description of the change he or she is asking for • The name of the requestor • The reason for the change • The risk (from his or her perspective) to the project if the change is not made 5. A Change Control Board is usually put into place to review changes that make the project end date slip, overrun the budget, or affect the achievement of the MOP. 6. The Change Control Board usually consists of the executives who have something to lose or gain with the completion of the project.

Chapter 14 1. A readiness review is a review to make sure you are ready to hand over your project and its product to your operations.

470

Answers to the Review Questions

2. This planning activity should start well into the planning or execution of the project. 3. You should review or verify these components for completeness before you begin the hand-off to operations: • Methods and procedures • Training • Testing completed, reviewed, and signed off on • Compliance • Notification • Conversion required? • Operational staffing 4. You should review or verify these IT components for completeness before you begin the hand-off to operations: • Capacity planning • Defined and implemented operation environment • Installation of workstations • System documentation 5.

6.

7. 8.

• Service level agreements The formal process that you must set up at the end of the project to provide the final inspection of the product of the project is called scope verification. Lessons learned is one of those fundamental processes that you put into place when you want to improve your work and the work of your organization. You look for the processes, tools, and techniques that worked well on the project, as well as the processes, tools, and techniques that need improvement. People tend to be less defensive when you talk about processes needing improvement versus things that just didn’t go right. The 95 percent phenomenon is a condition in which the team just can’t finish that last piece of work and can’t complete the project. There is something standing in the way of getting the project finished.

Glossary

accept risk response strategy—Strategy in which you accept that the risk exists and decide not to do anything about it. average salary rate—The actual amount of money each project manager at your company makes, divided by the number of project managers. avoid risk response strategy—Strategy in which you actually prevent the occurrence of the risk through your planning activities. You create new tasks for your project schedule and update your project plan with these new activities. baseline—Provides a point in time for you to compare your plans against what is actually happening during project execution. bottom up estimating—An estimating technique in which the smallest task of a project is estimated. budget—A money amount that covers the entire cost of the project. budget reconciliation—You might realize after calculating the budget that the amount of money that you need is way over the amount of money that has been set aside for this project. Dealing with this overage is called budget reconciliation. business requirements—A set of attributes that a product must contain from a business perspective. Change Control Board—A board that is usually put in place to review changes that result in a slipped project, overrun the budget, or affect the achievement of the MOP. The Change Control Board usually consists of executives who have something to lose or gain with the completion of the project.

471

472

Glossary

cost baseline—The sum of all the work of the tasks of the project by resource and resource rate needed per task. The cost baseline is not the entire budget; it is a subset of the budget that has to do with the work of the project. It is the cost of resource per task. Another view of the cost baseline is the budget minus any fees, reserves, or contingency money. cost of quality—The total costs incurred to ensure the proper quality for the product. The cost of quality consists of the cost of conformance and the cost of nonconformance. cost variance—The measure of variance on the costs of the project. The formula for the cost variance is: Cost Variance = Earned Value – Actual Cost

crashing—A schedule-compression method that reduces the overall duration of a task for the least cost. critical path—The series of tasks that must be accomplished with no delay to meet the end date of the project. descoping—A schedule-compression method that removes product features or functions, or reduces the MOP of a project. definitive estimate—An estimate that describes the smallest parameter possible. For example, work effort and duration estimates are definitive estimates. desk testing—A human test of the work so far, to guarantee that you are still in the scope that you defined. This verification should be done at the end of every level of decomposition that you complete. discretionary dependency—A dependency that is put in place because of the needs of the project. driver—The measure of performance driver provides a single statement that describes the business result that must be achieved. It is always described in measurable terms. It doesn’t describe the activities of the work; it sticks to the result or outcome of the work. earned value technique—A way of measuring work performance and comparing it to what was planned. Earned value gives you the opportunity to look at both the variance of the schedule and cost variance in the same analysis. external dependency—A dependency that is created because of factors outside the project.

Glossary

473

fast tracking—A schedule-compression method that overlaps activities to shorten the overall duration of the project. fee—A money amount that must be paid because of your project. Most times, this fee is associated with the entire project, not a specific task. functional organization—An organizational structure that is established by specialty. functional requirements—The functions that a product must have to work correctly. issue—An item that must be discussed or researched to complete a task. lag time—A lag changes a logical relationship between a predecessor task and a successor task by delaying the start of the successor task. lessons learned—A fundamental process that you put in place when you want to improve your work and the work of your organization. You look for the processes, tools, and techniques that worked well on the project, as well as the processes, tools, and techniques that need improvement. loaded salary rate—The salary of the person, plus the amount of paid vacations they receive, plus the benefits they receive. mandatory dependency—A dependency that is inherent because of the type of work required. Measure of Performance—A measurable business result that is the objective of a project. A Measure of Performance consists of a driver and restrictions. mitigate risk response strategy—Risk strategy that softens the potential problems that a risk might present to your project. near critical path—A path of the network diagram that has very little float available. That path can become critical if a delayed task uses up the float. network diagram—A diagram that depicts the relationships of all the tasks on a project. The output of the precedence diagramming method is called a network diagram. nonfunctional requirements—The characteristics that a product must have. operations—Ongoing or repetitive activities—operations contrast with projects, which are constrained to end.

474

Glossary

order of magnitude estimate—A guess about the total cost of the project. The order of magnitude estimate is created at the beginning of the planning cycle. parametric modeling—A computer-based estimating method. Data from thousands of previous projects is analyzed in this mathematical model. The specific data that is analyzed are product elements and their costs and schedules. performance measurement baseline—All baselines that are created; together, these are referred to as the performance measurement baseline. plan of record—The project plan what you baseline at the end of planning. PMO—A organizational entity that works as a centralized unit to perform some of all of the following activities: • Report on the status of projects, programs, and portfolios • Create project management standards that are used throughout the hierarchy • Act as a resource pool for experienced project managers that is used throughout the hierarchy • Allocate resources across the entire portfolio portfolio management—A mechanism for identifying, prioritizing, managing, and controlling projects, programs, and other related work to achieve specific strategic business objectives. predecessor—A task that is done directly before another task. preliminary scope statement—Defines the objectives and parameters of the project. You create a scope statement to begin defining exactly what your project will do. product management life cycle—A series of phases that together describe the stages of development of a specific product. product requirements—The product that the project will deliver. product requirements baseline—A copy of the product requirements that the client and executive sponsor of the project have signed off on. program management—A mechanism for managing projects in a coordinated manner to achieve the strategic objectives and benefits.

Glossary

475

progressive elaboration—Term used to define the process that you go through to plan a project. You start with an idea or an objective that is given to you. You then define, step by step and layer by layer, the activities that the project must do to succeed. You start this progressive elaboration with the preliminary scope statement. project—A unique endeavor that has a beginning and an end. project management life cycle—A series of phases that together describe the stages of development of a specific project. project plan—A road map that provides all the context for the project. In it, you document your thoughts and actions for every aspect of the planning you are about to undertake. You also provide information on how you will execute this plan, as well as how you will monitor and control the plan. projectized organization—An organizational structure that has been established to deliver the organization’s strategy using projects. quality baseline—The information that you have gathered in your qualityplanning process. This information spells out the quality objectives that you have planned for the project. readiness review—A review to make sure you are ready to hand over your project and its product to your operations. reserve analysis—Analysis in which you review your estimates for risk and apply an amount of padding to the estimate. reserves—An amount of money that is set aside as part of the budget but is used for only specific types of situations. resource histogram—Bar chart that shows how each resource is used on every day of the project. It shows the number of days that a person will be needed to work over the course of the project. restriction—A boundary you will need to work within to succeed. risk impact—The effect that a risk will have on the possible project outcome. risk probability—The chance that a given risk event will occur. schedule baseline—A copy of the tasks that must be completed to execute the project on time. This is usually a copy of the network diagram or a Gantt chart of the schedule. It shows each task and the predecessors and successors for each task, as well as the needed duration of each task.

476

Glossary

schedule compression—Activities that you do to reduce the duration of your project. schedule variance—The measure of variance on a schedule. The formula for schedule variance is: Schedule Variance = Earned Value – Planned Value

scope verification—The formal process that you must set up at the end of the project that provides the final inspection of the product of the project. successor—A task that is done directly after another task. team norms—A set of statements that describe the project’s rules of engagement. transfer risk response strategy—Strategy in which you actually give the risk to another party to deal with. The risk becomes that party’s responsibility. variance analysis—Method that analyzes the planned activities against the completed activities, to determine whether there is any difference. work breakdown structure—A hierarchical depiction of the work of the project that covers the total scope.

Bibliography Carnegie Mellon University/Software Engineering Institute. “Oriented Domain Analysis.” 2007. http://www.sei.cmu.edu/domain-engineering/ FODA.html. Carnegie Mellon University/Software Engineering Institute. The Capability Maturity Model: Guidelines for Improving the Software Process. Reading, MA: Addison-Wesley, 1995. Crosby, Philip B. Quality Is Free: The Art of Making Quality Certain. New York: New American Library, 1980. Jansen, Patti. Microsoft Project for Mere Mortals. Boston: Addison-Wesley, 2007. Juran, J. M. Juran on Leadership for Quality. Southbury, CT: Juran Institute, 1989. Laube, David R., and Zammuto, Ray F. (eds.). Business Driven Information Technology:Answers to 100 Critical Questions for Every Manager. Stanford, CA: Stanford Business Books, 2003. Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK Guide), Third Edition. Newton Square, PA: Project Management Institute, 2004. Project Management Institute. The Standard for Portfolio Management. Newton Square, PA: Project Management Institute, 2006. Project Management Institute. The Standard for Program Management. Newton Square, PA: Project Management Institute, 2006. Tuckman, Bruce. “Developmental Sequence in Small Groups.” Psychological Bulletin 63:384–399. Walton, Mary. The Deming Management Method. New York: Perigee Books, 1986. Zaleznik, Abraham. “Managers and Leaders: Are They Different?” Harvard Business Review, January 2004. 477

This page intentionally left blank

Index A acceptance (risk response strategy), 272 accepting change requests, 430-431 accountability in preliminary scope statement, 33 achievements. See drivers action items, 121 alarms for risks, 276 alliance building, 92-94 case study, 96 analogous estimating, 135-136 analyst (role of project manager), 4 appraisal costs, 180 case study, 385-387, 394 approvers, 62 archiving project documentation, 446-447 assigning resources, 304-309, 312-314 assumptions in preliminary scope statement, 32 audience identification (product requirements), 62-65 recipients of communication identifying, 210-216 types of effective communication with, 229-231, 236-237, 242-243, 248

audits, quality, 177, 378-380 case study, 437 authority establishing, 45-47 in preliminary scope statement, 33 avoidance (risk response strategy), 272

B backward passes, calculating critical paths, 295-296 baseline and control phase (product requirements), 61, 83-84 baselined project plan, change-control process and, 422 baselines case study, 418 cost baselines, 349-350, 371 case study, 387-388 creating, 370-373 cost baselines, 371 product requirements baselines, 372 quality baselines, 372 schedule baselines, 371 Microsoft Project, 371 quality baselines, 187 bottom-up estimating (definitive estimates), 36, 133-136

479

480

Index

brainstorming deliverables, 55-56 for estimating, 161-163 gathering product requirements, 71-72 in-scope and out-of-scope elements, 57-58 risks, 261-263 budget crashing, 347 budget reconciliation, 347 budget crashing, 347 descoping, 348-349 budgets, 332 building, 332 cost per task, 336-344 resource rates, 334-336 work effort estimates, 333 case study, 384-388, 394-395, 415-418 resources, 358-366 change-control process and, 422 cost baselines, 349-350 estimates, 36, 134 cost estimating and, 153 fees, 346-347 politics of project management, 352-353 reserves, 344 managerial contingency, 346 project reserves, 344-345 variances, impact of, 407-408 business requirements, 76

C calculating critical paths, 293-294 backward passes, 295-296 floats, 296-297 forward passes, 294-295 calendar estimates, 134

case study appraisals, 385-387, 394 baselines, 418 budgets, 384-388, 394-395, 415-418 resources, 358-366 communication plan, 284-289, 327 cost estimates, 195-205 critical path, 356-357 estimates, 165-168 first team meeting, 124-129 lessons learned, 436-440 network diagrams, 165-168 politics of project management, quality-planning process and, 205 product requirements for, 95-97 project closing, 452-456 project plan development for, 48-51 quality planning, 251-254 resource estimates, 195-200 risk identification, 356-357 risk strategy, 328-329 rumors, handling, 328-330 scheduling, 353-357 setup for, 15-16 team norms, 251-252 variance monitoring, 416 CCB (Change Control Board) accepting/rejecting change requests, 430-431 politics of project management, 434-436 celebrations after closing project, 449 challengers, 63, 92, 236 alliance building with, 93 champions, 63, 92, 236 alliance building with, 93

Index

Change Control Board (CCB) accepting/rejecting change requests, 430-431 politics of project management, 434-436 change requests accepting/rejecting, 430-431 estimating impact on project, 427-430 logging, 427, 431-432 notifying decision on, 431 receiving, 424-426 reviewing, 427 change-control process case study, 436 change requests accepting/rejecting, 430-431 estimating impact on project, 427-430 logging, 427, 431-432 notifying decision on, 431 receiving, 424-426 reviewing, 427 importance of following, 424 monitoring implementation of changes, 411 politics of project management, 434-436 of product requirements, 84 steps, list of, 424-425 team, effect on, 433-434 team norms and, 423-424 what to control, 422-423 chartering projects, 20 formal chartering, 20-22 informal chartering, 23 “climbers” (politics of project management), 193

481

closing projects archiving project documentation, 446-447 case study, 452-456 celebrations, 449 lessons learned, 447-449 95 percent phenomenon, 449-451 presentation for executives, 451-452 collecting work performance information, 377 communication exercise to demonstrate, 208-209 planning, 209-210 case study, 284-289 contents of communication, 226, 229 delivery techniques, 236 politics and, 249-251 reasons for communicating, 223 recipients of communication, 210-216, 229-231, 236-237, 242-243, 248 team aspects, 248-249 timing of communication, 216-221 politics of project management, 382-383 communication plan case study, 327 project execution, 377 in project plans, 39 rumors, 414-415 communication template, 210 communicator (role of project manager), 4 completeness of global requirements, 82 completion criteria, creating, 104-107

482

Index

compressing schedules, 314 crashing, 314-315 descoping, 317-322 fast-tracking, 316-317 confirming phase (product requirements), 61, 80-83 conflict, forcing, 191 conformance, cost of, 180 consistency of global requirements, 82 constraints in preliminary scope statement, 32 controlling product of project, 411 project risks, 410-411 rumors, 413-415 variances budget variances, 407-408 case study, 416 corrective action, 408-410 earned value technique, 403-406 schedule variances, 406-407 status meetings, 398-399 variance analysis, 400-402 coordinator (role of project manager), 5 core team members case study, 96-97 first meeting, 117-122 case study, 124-129 private meetings with, 91-92 corporate strategy, 6-7 corporate structures, types of, 9-11 corrective action (variances), 408 critical-path tasks, 408-409 noncritical-path tasks, 409-410 cost, as triple constraint, 27-29 cost baselines, 349-350, 371 case study, 387-388 cost elements in project plans, 39

cost estimates, 153-161 case study, 201-204 order of magnitude estimates, 36-38 in preliminary scope statement, 33 types of, 35-36 cost of conformance, 180 cost of nonconformance, 181-188 cost of quality cost of conformance, 180 cost of nonconformance, 181-188 defined, 180 cost per task, 336-344 case study, 387-388 Cost Performance Index, 405 crashing (schedule compression), 314-315 critical paths, calculating, 293-294 backward passes, 295-296 case study, 298-302, 356-357 floats, 296-297 forward passes, 294-295 critical path tasks, corrective action, 408-409 cross-functional management, 164 cultural requirements, 80 current situation review (gathering product requirements), 68-70 customers, 62

D day-to-day operations, projects versus, 2 decision logs, 190 definitive estimates (bottom-up estimates), 36, 133-136 deliverables case study, 96 creating, 55-57 in preliminary scope statement, 33

Index

delivery techniques (communication), 236 dependencies, types of, 108-109 dependency relationships, 109-111 descoping budget reconciliation, 348-349 schedule compression, 317-322 description of product in scope statement, 58 desk testing (project plans), 90 detailed estimates (bottom-up estimates), 36, 133-136 diagram of work in product requirements setup, 65-67 dictionary (WBS), 88 “diggers” (politics of project management), 194 discretionary dependencies, 108 distraction of change-control process on team, 433-434 documentation archiving, 446-447 as deliverables, 56 MOPs (measures of performance), 23-24 drafting, 31 drivers, 25-26 restrictions, 26-27 scope of, 29-30 triple constraints and, 27-29 preliminary scope statements, 32-35, 54 project plans, 38-41 case study, 48-51 desk testing, 90 sections of, 38-40 documentor (role of project manager), 5 drafting MOPs, 31

483

drivers of MOPs, 25-26 duration estimates, 134, 148-152 preset duration, negotiating, 163-164 work effort estimates versus, 153

E early risks in preliminary scope statement, 33 earned value technique, 403-406 ego, restraining (interpersonal skills), 13 empathy (interpersonal skills), 13 empowering team members, 101 encouraging team members, 412-413 end dates, calculating critical paths, 293-294 backward passes, 295-296 case study, 298-302 floats, 296-297 forward passes, 294-295 estimates. See also estimating budget estimates, 134 cost estimates and, 153 calendar estimates, 134 case study, 165-168 cost estimates, 153-161 case study, 201-204 order of magnitude estimates, 36-38 in preliminary scope statement, 33 types of, 35-36 created by boss, 164-165 definitive estimates, 133-134 duration estimates, 134, 148-152 preset duration, 163-164 work effort estimates versus, 153 optimistic estimates, 137 order of magnitude estimates, 132, 332 creating with analogous estimating, 135-136

484

Index

pessimistic estimates, 137 politics and, 163-165 resource estimates, 141-148 case study, 195-200 what to estimate, 140 work effort estimates, 133-134, 333 cost estimates and, 153-156 duration estimates versus, 153 estimating. See also estimates analogous estimating, 135-136 bottom-up estimating, 136 brainstorming sessions for, 161-163 change requests’ impact on project, 427-430 defined, 132 expert judgment estimating, 140 parametric modeling, 136 PERT (Program Evaluation and Review Technique) estimating, 138-140 reserve analysis, 137-140 three-point estimating, 137 events, triggering communication by, 221 executing projects, 370 baselines, 370-373 cost baselines, 371 product requirements baselines, 372 quality baselines, 372 schedule baselines, 371 collecting work performance information, 377 communication plans, 377 gathering lessons learned, 378 implementing approved changes, 377 installing methods and procedures, 377 managing human resources, 376 managing resources, 377 performing risk management, 378 performing tasks of project, 376

politics of project management, 382-383 quality audits, 378-380 reporting on project information, 377 rhythm, establishing, 373-374 issues management, 374-376 status meetings, 374 staffing projects, 376 teams, 380-382 training resources, 376 validating project deliverables, 378 execution monitoring and controlling in project plans, 39 Executive Ostrich (executive personality), 382 executive personalities, 382-383 executive team. See also politics of project management closing presentation for, 451-452 communication planning, 249-251 quality-planning process and, 191-194 case study, 205 risk management, 281-283 executive team norms, 122-124 expert judgment estimating, 140 external cost of nonconformance, 181 external dependencies, 108

F fast-tracking schedule compression, 316-317 fear of completion, 450 fear of the future, 450 fees, 346-347 finish-to-finish relationships, 110 finish-to-start relationships, 109 floats, calculating, 296-297 flow of work, 322-324

Index

forcing conflict, 191 formal chartering, 20-22 formal risk gathering, 261-263 forming stage (team development), 117-122 forward passes, calculating critical paths, 294-295 functional organizations, 9-10 functional requirements, 76-78

G Gantt chart, 400 gathering phase (product requirements), 61, 68-80 levels of requirements, 76-80 tools and techniques for, 68-74 writing requirements, 74-76 global requirements, confirming, 82-83

H hierarchy of project management, 6-8 human resources, managing, 376. See also teams human resources strategy in project plans, 39

I–J identifying risks, 410 impact of risks, determining, 266-267 implementation preparation readiness reviews, 442-445 scope verification, 445-446 turnover (of project deliverables), 446 implementing changes (project execution), 377 impromptu risk gathering, 263 in-scope elements, brainstorming, 57-58

485

incremental effect (change requests), 430 individual requirements, confirming, 81-82 industry quality standards, 171-172 influence (interpersonal skills), 13 influencers, 63, 92, 236 alliance building with, 93 informal chartering, 23 informal risk gathering, 263-265 installing methods and procedures, 377 internal cost of nonconformance, 181 interpersonal skills, list of, 12-14 interviewing (gathering product requirements), 71 introductions in case study, 125 at first team meeting, 118-119 ISO 9000 quality standard, 171 issues, defined, 121 issues management case study, 437 project execution, 374-376

K–L lag time, 111 leader (role of project manager), 5 legal requirements, 80 lessons learned, 447-449 case study, 436-440 gathering, 378 leveling, resources, 304-309, 312-314 life cycles communication timing and, 216-220 defined, 11 product management life cycle, 12 project management life cycle, 11-12

486

Index

loaded salary rates, 335 logging change requests, 427, 431-432 look-and-feel requirements, 79

M Mad Hatter (executive personality), 382 maintainability requirements, 79 management phase (product requirements), 83-84 management skills defined, 3 resources for, 3 manager (role of project manager), 5 managerial contingency, 346 Managers and Leaders:Are They Different? (Zaleznik), 3 managing human resources, 376 resources, 377 mandatory dependencies, 108 master risk identification list (PERT estimates), 302 matrix management, 164 measures of performance (MOPs), 23-24 drafting, 31 drivers, 25-26 restrictions, 26-27 scope of, 29-30 triple constraints and, 27-29 meeting-management techniques, 120-122 methods, installing, 377 Microsoft Project baselines, 371 critical paths, 301 leveling resources, 314 mind mapping (gathering product requirements), 72-73

mitigation (risk response strategy), 272 modifiability of global requirements, 83 monitoring change control implementation, 411 changes, 431-432 product of project, 411 project risks, 410-411 variances budget variances, 407-408 case study, 416 corrective action, 408-410 earned value technique, 403-406 schedule variances, 406-407 status meetings, 398-399 variance analysis, 400-402 MOPs (measures of performance), 23-24 drafting, 31 drivers, 25-26 restrictions, 26-27 scope of, 29-30 triple constraints and, 27-29 motivating teams, 350-351

N negative schedule variance, 404 negotiating as interpersonal skill, 13 preset project duration, 163-164 for team members, 41-43 network diagrams case study, 165-168 creating, 111-117 quality planning, incorporating, 175-178 95 percent phenomenon, 449-451 nonconformance, cost of, 181-188 noncritical path tasks, corrective action, 409-410

Index

nonfunctional requirements, 76-80 norming stage (team development), 117 norms, following (interpersonal skills), 13. See also team norms notifying change request decisions, 431 numbering WBS (work breakdown structure), 89

O objectives in preliminary scope statement, 32 offices (PMOs), 8 operational requirements, 79 operations, projects versus, 2 OPM3® (Organizational Project Management Maturity Model), 9 optimistic estimates, 137 order of magnitude estimates (top-down estimates), 36-38, 132, 332 creating with analogous estimating, 135-136 organization quality standards, 172 Organizational Project Management Maturity Model (OPM3®), 9 organizational strategy, 6-7 organizational structures, types of, 9-11 out-of-scope elements, brainstorming, 57-58

P padding estimates in reserve analysis, 137 parametric modeling, 136 percentages in reserve analysis, 137 performance measures. See MOPs performance requirements, 79 performing risk management, 378

487

performing stage (team development), 117 PERT (Program Evaluation and Review Technique) estimating, 138-140 schedules, 302-303 pessimistic estimates, 137 pessimistic team members, risk management and, 279-281 planning communication, 209-210 case study, 284-289 contents of communication, 226, 229 delivery techniques, 236 politics and, 249-251 reasons for communicating, 223 recipients of communication, 210-216, 229-231, 236-237, 242-243, 248 team aspects, 248-249 timing of communication, 216-221 project plans, 38-41 case study, 48-51 desk testing, 90 sections of, 38-40 quality planning, 174-175 case study, 251-254 defined, 170 in network diagram, 175-178 politics of, 191-194, 205 for teams, 188-191 response planning (for risks), 272-279 risk strategy, 258-260 teams, 41-43 PMBOK® Guide, 2 cost of quality, 180 quality planning, 170 PMOs, defined, 8

488

Index

political requirements, 80 politics of project management, 14-15 alliance building, 92-94 authority, establishing, 45-47 budgets, 352-353 CCB (Change Control Board), 434-436 closing presentation for executives, 451-452 communication planning, 249-251, 414-415 communication with executives, 382-383 estimates and, 163-165 project execution, 382-383 quality-planning process and, 191-194 case study, 205 risk management, 281-283 rumor control, 413-415 case study, 418 schedules, 326 stakeholder identification, 43-45 team norms, 122-124 portability requirements, 79 portfolio management, defined, 7 portfolios, defined, 7 precedence diagramming, 111 predecessors, 109 preliminary scope statements, 32-35, 54 preparing for implementation readiness reviews, 442-445 scope verification, 445-446 turnover (of project deliverables), 446 preset project duration, negotiating, 163-164 prevention costs, 180 probability of risks, determining, 267-271 problem solver (role of project manager), 5

procedures, installing, 377 procurement plans in project plans, 39 product description in scope statement, 58 product development life cycle, communication timing and, 216-220 product elements, 136 building library of, 161 product management life cycle, 12 product of projects, monitoring and controlling, 411 product requirements, 60-85 baseline and control phase, 61, 83-84, 372 case study, 95-97 change-control process and, 422 characteristics of, 74-75 confirming phase, 61, 80-83 gathering phase, 61, 68-80 levels of requirements, 76-80 tools and techniques for, 68-74 writing requirements, 74-76 in preliminary scope statement, 32 setup phase, 60-67 audience identification, 62-65 diagram of work, 65-67 product standards, 172 Program Evaluation and Review Technique (PERT) estimating, 138-140 schedules, 302-303 program management, defined, 8 programs, defined, 7 progressive elaboration, 32 project closing archiving project documentation, 446-447

Index

case study, 452-456 celebrations, 449 lessons learned, 447-449 95 percent phenomenon, 449-451 presentation for executives, 451-452 project costs, 35-37 project customers, 62 project deliverables, validating, 378 project documentation archiving, 446-447 as deliverables, 56 MOPs (measures of performance), 23-24 drafting, 31 drivers, 25-26 restrictions, 26-27 scope of, 29-30 triple constraints and, 27-29 preliminary scope statements, 32-35, 54 project plans, 38-41 case study, 48-51 desk testing, 90 sections of, 38-40 project execution, 370 baselines, 370-373 cost baselines, 371 product requirements baselines, 372 quality baselines, 372 schedule baselines, 371 collecting work performance information, 377 communication plans, 377 gathering lessons learned, 378 implementing approved changes, 377 installing methods and procedures, 377 managing human resources, 376 managing resources, 377 performing risk management, 378

489

performing tasks of project, 376 politics of project management, 382-383 quality audits, 378-380 reporting on project information, 377 rhythm, establishing, 373-374 issues management, 374-376 status meetings, 374 staffing projects, 376 teams, 380-382 training resources, 376 validating project deliverables, 378 project execution plan in project plans, 39 project management defined, 2-3 hierarchy of, 6-8 project management life cycle, 11-12 communication timing and, 216-220 project management process standards, 172 project managers, roles of, 3-5 project organization in preliminary scope statement, 33 project plans, 38-41 case study, 48-51 desk testing, 90 sections of, 38-40 project reserves, 344-345 project risks brainstorming, 261-263 defined, 121 identifying, 260, 410 case study, 356-357 formal risk gathering, 261-263 informal risk gathering, 263-265 impact of, determining, 266-267 monitoring and controlling, 410-411

490

Index

probability of, determining, 267-271 residual risks, monitoring for, 410 response planning, 272-279 project scope statement, example of, 59 project sponsors, 62 projectized organizations, 10-11 projects chartering, 20 formal chartering, 20-22 informal chartering, 23 day-to-day operations versus, 2 defined, 2-3 in project management hierarchy, 8 staffing, 376 tracking. See monitoring public relations. See politics of project management

Q quality, cost of cost of conformance, 180 cost of nonconformance, 181-188 defined, 170, 180 quality audits, 177, 378-380 case study, 437 quality baseline, 187, 372 quality management in project plans, 39 standards, 172 quality philosophies, 170-171 quality planning, 174-175 case study, 251-254 defined, 170 in network diagram, 175-178 politics of, 191-194 case study, 205 for teams, 188-191 quality policies, creating, 173-174 quality standards, 171-172

R readiness reviews, 442-445 receiving change requests, 424-426 recipients of communication, 210-216, 229-231, 236-237, 242-243, 248 reconciling budgets, 347 budget crashing, 347 descoping, 348-349 rejecting change requests, 430-431 relevance of individual requirements, 81 reporting facts to team members, 412 project information, 377 reporting structures, types of, 9-11 requests for change accepting/rejecting, 430-431 estimating impact on project, 427-430 logging, 427, 431-432 notifying decision on, 431 receiving, 424-426 reviewing, 427 requirements, 60-85 baseline and control phase, 61, 83-84, 372 case study, 95-97 change-control process and, 422 characteristics of, 74-75 confirming phase, 61, 80-83 gathering phase, 61, 68-80 levels of requirements, 76-80 tools and techniques for, 68-74 writing requirements, 74-76 in preliminary scope statement, 32 setup phase, 60-67 audience identification, 62-65 diagram of work, 65-67 reserve analysis, 137-140

Index

reserves, building budgets, 344 managerial contingency, 346 project reserves, 344-345 residual risks, monitoring, 410 resource estimating, 141-148 case study, 195-200 resource rates, 334-336 case study, 200, 386 in cost estimating, 157-158 resources assigning and leveling, 304-309, 312-314 budgets (case study), 358-366 managing, 377 training, 376 response planning (for risks), 272-279 restrictions of MOPs, 26-27 results, 25-26 reviewing change requests, 427 current situation (gathering product requirements), 68-70 rewarding team members, 350-351, 412-413 case study, 437 rhythm, establishing (project execution), 373-374 issues management, 374-376 status meetings, 374 risk management performing, 378 pessimistic team members and, 279-281 politics and, 281-283 risk owners, 276 risk plan in project plans, 39 risk process, monitoring, 411

491

risk strategy, 258-260 in case study, 328-329 identifying risks, 260 formal risk gathering, 261-263 informal risk gathering, 263-265 risk triggers, monitoring, 410 risks brainstorming, 261-263 defined, 121 identifying, 260, 410 case study, 356-357 formal risk gathering, 261-263 informal risk gathering, 263-265 impact of, determining, 266-267 monitoring and controlling, 410-411 probability of, determining, 267-271 residual risks, monitoring for, 410 response planning, 272-279 rules of engagement. See team norms rumors case study, 328-330, 418 controlling, 413-415

S salary rates, 334-336 case study, 200, 386 in cost estimating, 157-158 schedule baselines, 371 schedule compression, 314 crashing, 314-315 descoping, 317-322 fast-tracking, 316-317 Schedule Performance Index, 405 schedule variance, 405 impact of, 406-407 negative schedule variance, 404

492

Index

schedules. See also variances assigning and leveling resources, 304-309, 312-314 case study, 353-357 change-control process and, 422 compressing, 314 crashing, 314-315 descoping, 317-322 fast-tracking, 316-317 end dates, 293 calculating critical paths, 293-297 flow of work, 322-324 PERT estimates, 302-303 politics of project management, 326 in project plans, 38 teams, 324-326 scope deliverables, creating, 55-57 inclusions versus exclusions, 57-58 of MOPs, 29-30 preliminary scope statement, 32-35, 54 product description in, 58 project scope statement example, 59 as triple constraint, 27-29 scope information in project plans, 38 scope verification, 445-446 security requirements, 79 sequencing tasks, 107 dependencies, 108-109 dependency relationships, 109-111 network diagram, creating, 111-117 setup phase (product requirements), 60-67 audience identification, 62-65 diagram of work, 65-67 shadowing (gathering product requirements), 70-71

staffing projects, 376 teams, 41-43 stakeholders, 62 identifying, 43-45 standards, quality standards, 171-172 start-to-finish relationships, 110 start-to-start relationships, 109 status meetings case study, 438 monitoring variances, 398-399 project execution, 374 storming stage (team development), 117 moving past, 188-191 strategist (role of project manager), 4 strategy, 6-7 successors, 109

T task list, creating, 100-104 tasks completion criteria, creating, 104-107 duration of, 100 empowering team for, 101 sequencing, 107 dependencies, 108-109 dependency relationships, 109-111 network diagram, creating, 111-117 team members, 62 team norms, 119-120 case study, 125, 251-252 change-control process and, 423-424 communication planning and, 248 for executives, 122-124 quality planning process and, 188-191 team-building exercises in case study, 125 at first team meeting, 119

Index

teams change-control process, effect on team, 433-434 communication planning, 248-249 core team members case study, 96-97, 124-129 first meeting, 117-122 private meetings with, 91-92 empowering for tasks, 101 estimating brainstorming sessions, 161-163 interpersonal skills, list of, 12-14 motivating, 350-351 phases of development, 117 planning, 41-43 project completion, 449-451 project execution, 380-382 quality planning process and, 188-191 reporting facts, 412 reviewing change requests, 427 rewarding and encouraging, 412-413 risk management, 279-281 schedules, 324-326 training, 380-382 templates, communication template, 210 testing (project plans), 90 three-point estimating, 137 time, as triple constraint, 27-29 time scales for duration estimates, 149 timing of communication, 216-221 top-down estimates (order of magnitude estimates), 36-38, 132, 332 creating with analogous estimating, 135-136 tracking change control implementation, 411 changes, 431-432 product of project, 411

493

project risks, 410-411 variances budget variances, 407-408 case study, 416 corrective action, 408-410 earned value technique, 403-406 schedule variances, 406-407 status meetings, 398-399 variance analysis, 400-402 training resources, 376 teams, project execution, 380-382 transfer (risk response strategy), 272 triggering communication by events, 221 triple constraints, MOPs and, 27-29 Tuckman, Bruce, 117 turnover (of project deliverables), 446

U–V understandability of individual requirements, 81 usability requirements, 79 validating project deliverables, 378 variance analysis, 400-402 variances, monitoring budget variances, 407-408 case study, 416 corrective action, 408-410 earned value technique, 403-406 schedule variances, 406-407 status meetings, 398-399 variance analysis, 400-402 verifying phase (product requirements), 61, 80-83 version control of product requirements, 84 viability of individual requirements, 81

494

Index

W–Z WBS (work breakdown structure) completion criteria, creating, 104-107 creating, 86-90 in project plans, 38 task list, creating, 100-104 work effort estimates, 133-134, 333 cost estimating and, 153-156 duration estimates versus, 153 work flow, 322-324 work package level of WBS, 86 work packages, creating, 87-88. See also tasks writing requirements, 74-76 Zaleznik, Abraham, 3

at www.awprofessional.com/register You may be eligible to receive: • Advance notice of forthcoming editions of the book • Related book recommendations • Chapter excerpts and supplements of forthcoming titles • Information about special contests and promotions throughout the year • Notices and reminders about author appearances, tradeshows, and online chats with special guests

If you are interested in writing a book or reviewing manuscripts prior to publication, please write to us at: Editorial Department Addison-Wesley Professional 75 Arlington Street, Suite 300 Boston, MA 02116 USA Email: [email protected]

Visit us on the Web: http://www.awprofessional.com

Like this book? You will love our new LiveLessons Video instruction from a project management expert!

Project Management for Mere Mortals® The Tools, Techniques, Teaming, and Politics of Project Management ISBN 10: 0321509196 ISBN 13: 9780321509192

Includes: I DVD featuring 3–4 hours of instructor-led classroom sessions divided into 15–20 minute step-by-step hands-on labs I Printed study guide This is a hands-on project management video with real examples and techniques that work. Here is just a sample of what’s covered: I Teaches you the basics of project management, the role of project manager, and how PMBOK fits in I Helps you understand the basics of building a team and balancing team dynamics I Describes how to create project plans, schedules, and budgets I Takes you into advanced skills such as estimating, cost budgeting, baselining, and change control ®

Your instructor is Claudia M. Baca, an independent project management consultant and PMI trainer and lecturer for the Project Management Institute chapter in Denver with more than 20 years of project management experience. If you are tired of expensive off-site training programs and want to learn from the best technologists in the industry, try LiveLessons: self-paced, personal video instruction from the world’s leading technology experts. To learn more about other LiveLessons visit www.mylivelessons.com

4()3"//+)33!&!2)%.!",%$ ).#,5$%3&2%% $!9 !##%334/ 4(%/.,).%%$)4)/. 4HE3AFARI§ %NABLEDICONONTHECOVEROFYOURFAVORITETECHNOLOGY BOOKMEANSTHEBOOKISAVAILABLETHROUGH3AFARI"OOKSHELF7HEN YOU BUYTHISBOOK YOUGETFREEACCESSTOTHEONLINEEDITIONFOR DAYS 3AFARI"OOKSHELFISANELECTRONICREFERENCELIBRARYTHATLETSYOUEASILY SEARCHTHOUSANDSOFTECHNICALBOOKS FINDCODESAMPLES DOWNLOAD CHAPTERS ANDACCESSTECHNICALINFORMATIONWHENEVERANDWHEREVER YOUNEEDIT

4/ '!). $!9 3!&!2)%.!",%$!##%334/ 4()3"//+

s s s

'OTOHTTPWWWAWPROFESSIONALCOMSAFARIENABLED #OMPLETETHEBRIEFREGISTRATIONFORM %NTERTHECOUPONCODEFOUNDINTHEFRONT OFTHISBOOKONTHEh#OPYRIGHTvPAGE

)FYOUHAVEDIFFICULTYREGISTERINGON3AFARI"OOKSHELFORACCESSINGTHEONLINEEDITION PLEASEE MAILCUSTOMER SERVICE SAFARIBOOKSONLINECOM