Hide Notes 

Slide 1: g Easier! Making Everythin ™ 3rd Edition Project ement Manag Learn to: • Organize and schedule projects efficiently and effectively • Motivate any team to gain maximum productivity • Assess risks, manage changes, maintain communication, and live up to expectations • Plan for resources and stay within a budget Stanley E. Portny, PMP® Internationally recognized expert in project management
Slide 2: Get More and Do More at Dummies.com ® Start with FREE Cheat Sheets Cheat Sheets include • Checklists • Charts • Common Instructions • And Other Good Stuff! To access the Cheat Sheet created specifically for this book, go to www.dummies.com/cheatsheet/projectmanagement Get Smart at Dummies.com Dummies.com makes your life easier with 1,000s of answers on everything from removing wallpaper to using the latest version of Windows. Check out our • Videos • Illustrated Articles • Step-by-Step Instructions Plus, each month you can win valuable prizes by entering our Dummies.com sweepstakes. * Want a weekly dose of Dummies? Sign up for Newsletters on • Digital Photography • Microsoft Windows & Office • Personal Finance & Investing • Health & Wellness • Computing, iPods & Cell Phones • eBay • Internet • Food, Home & Garden Find out “HOW” at Dummies.com *Sweepstakes not currently available in all countries; visit Dummies.com for official rules.
Slide 3: Project Management FOR DUMmIES 3RD ‰ EDITION by Stanley E. Portny Certified Project Management Professional (PMP)
Slide 4: Project Management For Dummies®, 3rd Edition Published by Wiley Publishing, Inc. 111 River St. Hoboken, NJ 07030-5774 www.wiley.com Copyright © 2010 by Wiley Publishing, Inc., Indianapolis, Indiana Published simultaneously in Canada No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at http:// www.wiley.com/go/permissions. Trademarks: Wiley, the Wiley Publishing logo, For Dummies, the Dummies Man logo, A Reference for the Rest of Us!, The Dummies Way, Dummies Daily, The Fun and Easy Way, Dummies.com, Making Everything Easier, and related trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/ or its affiliates in the United States and other countries, and may not be used without written permission. All other trademarks are the property of their respective owners. Wiley Publishing, Inc., is not associated with any product or vendor mentioned in this book. LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY: THE PUBLISHER AND THE AUTHOR MAKE NO REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE ACCURACY OR COMPLETENESS OF THE CONTENTS OF THIS WORK AND SPECIFICALLY DISCLAIM ALL WARRANTIES, INCLUDING WITHOUT LIMITATION WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE. NO WARRANTY MAY BE CREATED OR EXTENDED BY SALES OR PROMOTIONAL MATERIALS. THE ADVICE AND STRATEGIES CONTAINED HEREIN MAY NOT BE SUITABLE FOR EVERY SITUATION. THIS WORK IS SOLD WITH THE UNDERSTANDING THAT THE PUBLISHER IS NOT ENGAGED IN RENDERING LEGAL, ACCOUNTING, OR OTHER PROFESSIONAL SERVICES. IF PROFESSIONAL ASSISTANCE IS REQUIRED, THE SERVICES OF A COMPETENT PROFESSIONAL PERSON SHOULD BE SOUGHT. NEITHER THE PUBLISHER NOR THE AUTHOR SHALL BE LIABLE FOR DAMAGES ARISING HEREFROM. THE FACT THAT AN ORGANIZATION OR WEBSITE IS REFERRED TO IN THIS WORK AS A CITATION AND/OR A POTENTIAL SOURCE OF FURTHER INFORMATION DOES NOT MEAN THAT THE AUTHOR OR THE PUBLISHER ENDORSES THE INFORMATION THE ORGANIZATION OR WEBSITE MAY PROVIDE OR RECOMMENDATIONS IT MAY MAKE. FURTHER, READERS SHOULD BE AWARE THAT INTERNET WEBSITES LISTED IN THIS WORK MAY HAVE CHANGED OR DISAPPEARED BETWEEN WHEN THIS WORK WAS WRITTEN AND WHEN IT IS READ. For general information on our other products and services, please contact our Customer Care Department within the U.S. at 877-762-2974, outside the U.S. at 317-572-3993, or fax 317-572-4002. For technical support, please visit www.wiley.com/techsupport. Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books. Library of Congress Control Number: 2010924586 ISBN: 978-0-470-57452-2 Manufactured in the United States of America 10 9 8 7 6 5 4 3 2 1
Slide 5: About the Author Stan Portny, president of Stanley E. Portny and Associates, LLC, is an internationally recognized expert in project management and project leadership. During the past 30 years, he’s provided training and consultation to more than 150 public and private organizations in consumer products, insurance, pharmaceuticals, finance, information technology, telecommunications, defense, and healthcare. He has developed and conducted training programs for more than 50,000 management and staff personnel in engineering, sales and marketing, research and development, information systems, manufacturing, operations, and support areas. Stan combines an analyst’s eye with an innate sense of order and balance and a deep respect for personal potential. He helps people understand how to control chaotic environments and produce dramatic results while still achieving personal and professional satisfaction. Widely acclaimed for his dynamic presentations and unusual ability to establish a close rapport with seminar participants, Stan specializes in tailoring his training programs to meet the unique needs of individual organizations. His clients have included ADP, ADT, American International Group, Burlington Northern Railroad, Hewlett Packard, Nabisco, Novartis Pharmaceuticals, Pitney Bowes, UPS, Vanguard Investment Companies, and the United States Navy and Air Force. A Project Management Institute–certified Project Management Professional (PMP), Stan received his bachelor’s degree in electrical engineering from the Polytechnic Institute of Brooklyn. He holds a master’s degree in electrical engineering and the degree of electrical engineer from the Massachusetts Institute of Technology. Stan has also studied at the Alfred P. Sloan School of Management and the George Washington University National Law Center. Stan provides on-site training in all aspects of project management, project team building, and project leadership. He can work with you to assess your organization’s current project-management practices, develop planning and control systems and procedures, and review the progress of ongoing projects. In addition, Stan can serve as the keynote speaker at your organization’s or professional association’s meetings. To discuss this book or understand how Stan can work with you to enhance your organization’s project-management skills and practices, please contact him at Stanley E. Portny and Associates, LLC, 20 Helene Drive, Randolph, New Jersey 07869; phone 973-366-8500; e-mail Stan@StanPortny.com; Web site www.StanPortny.com.
Slide 7: Dedication To my wife, Donna; my son, Brian; and my son and daughter-in-law, Jonathan and Marci. May we continue to share life’s joys together. Author’s Acknowledgments Writing and publishing this book was a team effort, and I would like to thank the many people who helped to make it possible. First, I want to thank Tracy Boggier, my acquisitions editor, who first contacted me to discuss the possibility of my writing this third edition of my book. Thanks to her for making that phone call, for helping me prepare the proposal, for helping to get the project off to a smooth and timely start, for coordinating the publicity and sales, and for helping to bring all the pieces to a successful conclusion. Thanks to Georgette Beatty, my project editor, and Amanda Langferman, my copy editor, for their guidance, support, and the many hours they spent polishing the text into a smooth, finished product. And thanks to Anita Griner, my technical reviewer, for her many insightful observations and suggestions. Finally, thanks to my family for their continued help and inspiration. Thanks to Donna, who never doubted that this book would become a reality and who shared personal and stylistic comments as she reviewed the text countless times while always making it seem like she found it enjoyable and enlightening. Thanks to Brian, Jonathan, and Marci, whose interest and excitement helped motivate me to see the third edition of this book through to completion.
Slide 8: Publisher’s Acknowledgments We’re proud of this book; please send us your comments at http://dummies.custhelp.com. For other comments, please contact our Customer Care Department within the U.S. at 877-762-2974, outside the U.S. at 317-572-3993, or fax 317-572-4002. Some of the people who helped bring this book to market include the following: Acquisitions, Editorial, and Media Development Senior Project Editor: Georgette Beatty (Previous Edition: Chad R. Sievers) Acquisitions Editor: Tracy Boggier Copy Editor: Amanda M. Langferman (Previous Edition: Pam Ruble) Assistant Editor: Erin Calligan Mooney Editorial Program Coordinator: Joe Niesen Technical Editor: Anita E. Griner, MBA, PMP Editorial Manager: Michelle Hacker Editorial Assistant: Jennette ElNaggar Cover Photo: iStock Cartoons: Rich Tennant (www.the5thwave.com) Composition Services Project Coordinator: Katherine Crocker Layout and Graphics: Ashley Chamberlain, Samantha K. Cherolis, Joyce Haughey Proofreaders: John Greenough, Sossity R. Smith Indexer: Cheryl Duksta Publishing and Editorial for Consumer Dummies Diane Graves Steele, Vice President and Publisher, Consumer Dummies Kristin Ferguson-Wagstaffe, Product Development Director, Consumer Dummies Ensley Eikenburg, Associate Publisher, Travel Kelly Regan, Editorial Director, Travel Publishing for Technology Dummies Andy Cummings, Vice President and Publisher, Dummies Technology/General User Composition Services Debbie Stailey, Director of Composition Services
Slide 9: Contents at a Glance Introduction ................................................................ 1 Part I: Understanding Expectations (The Who, What, and Why of Your Project) ............................................ 7 Chapter 1: Project Management: The Key to Achieving Results ................................. 9 Chapter 2: Clarifying What You’re Trying to Accomplish — and Why .................... 29 Chapter 3: Knowing Your Project’s Audience: Involving the Right People .............. 51 Chapter 4: Developing Your Game Plan: Getting from Here to There ...................... 71 Part II: Planning Time: Determining When and How Much .......................................................... 95 Chapter 5: You Want This Project Done When? .......................................................... 97 Chapter 6: Establishing Whom You Need, How Much, and When .......................... 129 Chapter 7: Planning for Other Resources and Developing the Budget ................... 151 Chapter 8: Venturing into the Unknown: Dealing with Risk and Uncertainty ........ 163 Part III: Group Work: Putting Your Team Together ..... 183 Chapter 9: Aligning the Key Players for Your Project ............................................... 185 Chapter 10: Defining Team Members’ Roles and Responsibilities .......................... 199 Chapter 11: Starting Your Project Team Off on the Right Foot ............................... 221 Part IV: Steering the Ship: Managing Your Project to Success .................................................... 237 Chapter 12: Tracking Progress and Maintaining Control ......................................... 239 Chapter 13: Keeping Everyone Informed .................................................................... 263 Chapter 14: Encouraging Peak Performance by Providing Effective Leadership..... 281 Chapter 15: Bringing Your Project to Closure............................................................ 291 Part V: Taking Your Project Management to the Next Level ......................................................... 303 Chapter 16: Using Technology to Up Your Game ...................................................... 305 Chapter 17: Monitoring Project Performance with Earned Value Management.... 319
Slide 10: Part VI: The Part of Tens .......................................... 333 Chapter 18: Ten Questions to Ask Yourself as You Plan Your Project ................... 335 Chapter 19: Ten Tips for Being a Better Project Manager........................................ 339 Appendix: Combining the Techniques into Smooth-Flowing Processes ........................................ 343 Index ...................................................................... 347
Slide 11: Table of Contents Introduction ................................................................. 1 About This Book .............................................................................................. 2 Conventions Used in This Book ..................................................................... 2 What You’re Not to Read ................................................................................ 3 Foolish Assumptions ....................................................................................... 3 How This Book Is Organized .......................................................................... 3 Part I: Understanding Expectations (The Who, What, and Why of Your Project) ................................................................. 4 Part II: Planning Time: Determining When and How Much .............. 4 Part III: Group Work: Putting Your Team Together ........................... 4 Part IV: Steering the Ship: Managing Your Project to Success ........ 4 Part V: Taking Your Project Management to the Next Level ............ 4 Part VI: The Part of Tens ....................................................................... 5 Icons Used in This Book ................................................................................. 5 Where to Go from Here ................................................................................... 5 Part I: Understanding Expectations (The Who, What, and Why of Your Project) ............................................. 7 Chapter 1: Project Management: The Key to Achieving Results. . . . . .9 Determining What Makes a Project a Project .............................................. 9 Understanding the three main components that define a project ............................................................................................ 10 Recognizing the diversity of projects................................................ 11 Describing the four stages of a project ............................................. 12 Defining Project Management ...................................................................... 14 Examining the initiating processes.................................................... 15 Considering the planning processes ................................................. 18 Examining the executing processes .................................................. 19 Examining the monitoring and controlling processes .................... 20 Acknowledging the closing processes .............................................. 21 Knowing the Project Manager’s Role .......................................................... 21 Looking at the project manager’s tasks ............................................ 21 Staving off potential excuses for not following a structured project-management approach .......................................................... 22 Avoiding “shortcuts” ........................................................................... 23 Staying aware of other potential challenges .................................... 24 Do You Have What It Takes to Be an Effective Project Manager? ........... 25 Questions .............................................................................................. 25 Answers ................................................................................................. 25 Relating This Chapter to the PMP Exam and PMBOK 4............................ 26
Slide 12: x Project Management For Dummies, 3rd Edition Chapter 2: Clarifying What You’re Trying to Accomplish — and Why . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29 Defining Your Project with a Scope Statement .......................................... 29 Looking at the Big Picture: How Your Project Fits In................................ 31 Figuring out why you’re doing the project ....................................... 32 Drawing the line: Where your project starts and stops .................. 40 Stating your project’s objectives ....................................................... 41 Marking Boundaries: Project Constraints .................................................. 45 Working within limitations ................................................................. 46 Dealing with needs............................................................................... 48 Facing the Unknowns When Planning ......................................................... 49 Relating This Chapter to the PMP Exam and PMBOK 4............................ 49 Chapter 3: Knowing Your Project’s Audience: Involving the Right People . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51 Understanding Your Project’s Audiences .................................................. 51 Developing an Audience List ........................................................................ 52 Starting your audience list.................................................................. 52 Ensuring your audience list is complete and up-to-date ................ 56 Using an audience list template ......................................................... 58 Considering the Drivers, Supporters, and Observers in Your Audience ............................................................................................ 59 Deciding when to involve your audiences ........................................ 61 Using different methods to keep your audiences involved ............ 64 Making the most of your audience’s involvement ........................... 65 Confirming Your Audience’s Authority ...................................................... 66 Assessing Your Audience’s Power and Interest ........................................ 67 Relating This Chapter to the PMP Exam and PMBOK 4............................ 68 Chapter 4: Developing Your Game Plan: Getting from Here to There. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71 Divide and Conquer: Working on Your Project in Manageable Chunks ................................................................................... 71 Thinking in detail ................................................................................. 72 Thinking of hierarchy with the help of a Work Breakdown Structure ....................................................................... 73 Dealing with special situations .......................................................... 79 Creating and Displaying Your Work Breakdown Structure...................... 82 Considering different schemes for organizing your WBS ............... 82 Using different approaches to develop your WBS........................... 83 Considering different ways to categorize your project’s work ...... 85 Labeling your WBS entries.................................................................. 86 Displaying your WBS in different formats ........................................ 87 Improving the quality of your WBS ................................................... 89 Using templates.................................................................................... 90
Slide 13: Table of Contents Identifying Risks While Detailing Your Work ............................................. 91 Documenting What You Need to Know about Your Planned Project Work................................................................................ 93 Relating This Chapter to the PMP Exam and PMBOK 4............................ 94 xi Part II: Planning Time: Determining When and How Much ........................................................... 95 Chapter 5: You Want This Project Done When? . . . . . . . . . . . . . . . . . . .97 Picture This: Illustrating a Work Plan with a Network Diagram .............. 98 Defining a network diagram’s elements ............................................ 98 Drawing a network diagram................................................................ 99 Analyzing a Network Diagram .................................................................... 100 Reading a network diagram .............................................................. 101 Interpreting a network diagram ....................................................... 102 Working with Your Project’s Network Diagram ...................................... 107 Determining precedence ................................................................... 107 Using a network diagram to analyze a simple example ................ 110 Developing Your Project’s Schedule ......................................................... 114 Taking the first steps ......................................................................... 115 Avoiding the pitfall of backing in to your schedule....................... 116 Meeting an established time constraint.......................................... 116 Applying different strategies to arrive at your picnic in less time ...................................................................................... 117 Estimating Activity Duration ...................................................................... 122 Determining the underlying factors ................................................ 123 Considering resource characteristics ............................................. 123 Finding sources of supporting information .................................... 124 Improving activity duration estimates ............................................ 124 Displaying Your Project’s Schedule .......................................................... 126 Relating This Chapter to the PMP Exam and PMBOK 4.......................... 127 Chapter 6: Establishing Whom You Need, How Much, and When . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129 Getting the Information You Need to Match People to Tasks ............... 130 Deciding the skills and knowledge that team members must have ........................................................................................ 130 Representing skills, knowledge, and interests in a Skills Matrix ............................................................................. 132 Estimating Needed Commitment ............................................................... 134 Using a Human Resources Matrix .................................................... 134 Identifying needed personnel in a Human Resources Matrix ...... 135 Estimating required work effort ....................................................... 136
Slide 14: xii Project Management For Dummies, 3rd Edition Factoring productivity, efficiency, and availability into work-effort estimates ............................................................. 137 Reflecting efficiency when you use historical data ....................... 138 Accounting for efficiency in personal work-effort estimates ....... 140 Ensuring Your Project Team Members Can Meet Their Resource Commitments ........................................................................................... 142 Planning your initial allocations ...................................................... 142 Resolving potential resource overloads ......................................... 145 Coordinating assignments across multiple projects..................... 147 Relating This Chapter to the PMP Exam and PMBOK 4.......................... 149 Chapter 7: Planning for Other Resources and Developing the Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .151 Determining Nonpersonnel Resource Needs ........................................... 151 Making Sense of the Dollars: Project Costs and Budgets ....................... 154 Looking at different types of project costs..................................... 154 Recognizing the three stages of a project budget ......................... 156 Refining your budget as you move through your project’s stages .............................................................................. 157 Determining project costs for a detailed budget estimate ........... 158 Relating This Chapter to the PMP Exam and PMBOK 4.......................... 162 Chapter 8: Venturing into the Unknown: Dealing with Risk and Uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163 Defining Risk and Risk Management ......................................................... 163 Focusing on Risk Factors and Risks .......................................................... 165 Recognizing risk factors .................................................................... 166 Identifying risks .................................................................................. 169 Assessing Risks: Probability and Consequences..................................... 170 Gauging the likelihood of a risk........................................................ 171 Estimating the extent of the consequences ................................... 173 Getting Everything under Control: Managing Risk .................................. 176 Choosing the risks you want to manage ......................................... 176 Developing a risk-management strategy ......................................... 177 Communicating about risks.............................................................. 178 Preparing a Risk-Management Plan ........................................................... 180 Relating This Chapter to the PMP Exam and PMBOK 4.......................... 181 Part III: Group Work: Putting Your Team Together ...... 183 Chapter 9: Aligning the Key Players for Your Project . . . . . . . . . . . . .185 Defining Three Organizational Environments.......................................... 185 The functional structure ................................................................... 186 The projectized structure ................................................................. 188 The matrix structure ......................................................................... 189
Slide 15: Table of Contents Recognizing the Key Players in a Matrix Environment ........................... 192 The project manager ......................................................................... 192 Project team members ...................................................................... 194 Functional managers ......................................................................... 194 Upper management ........................................................................... 195 Working Successfully in a Matrix Environment ....................................... 195 Creating and continually reinforcing a team identity ................... 195 Getting team member commitment................................................. 196 Eliciting support from other people in the environment ............. 196 Heading off common problems before they arise ......................... 197 Relating This Chapter to the PMP Exam and PMBOK 4.......................... 198 xiii Chapter 10: Defining Team Members’ Roles and Responsibilities . . . 199 Understanding the Key Roles..................................................................... 199 Distinguishing authority, responsibility, and accountability....... 200 Comparing authority and responsibility ........................................ 200 Making Project Assignments ...................................................................... 201 Delving into delegation ..................................................................... 201 Sharing responsibility ....................................................................... 206 Holding people accountable when they don’t report to you ....... 207 Picture This: Depicting Roles with a Responsibility Assignment Matrix ................................................................................... 210 Introducing the elements of a RAM ................................................. 210 Reading a RAM ................................................................................... 212 Developing a RAM .............................................................................. 213 Ensuring your RAM is accurate........................................................ 214 Dealing with Micromanagement ................................................................ 216 Realizing why a person micromanages ........................................... 216 Helping a micromanager trust you .................................................. 217 Working well with a micromanager ................................................. 218 Relating This Chapter to the PMP Exam and PMBOK 4.......................... 218 Chapter 11: Starting Your Project Team Off on the Right Foot. . . . . .221 Finalizing Your Project’s Participants ...................................................... 222 Are you in? Confirming your team members’ participation ......... 222 Assuring that others are on board .................................................. 224 Filling in the blanks ............................................................................ 225 Developing Your Team ............................................................................... 226 Reviewing the approved project plan ............................................. 227 Developing team and individual goals ............................................ 228 Specifying team member roles ......................................................... 228 Defining your team’s operating processes ..................................... 229 Supporting the development of team member relationships ...... 230 All together now: Helping your team become a smooth-functioning unit ................................................................ 230
Slide 16: xiv Project Management For Dummies, 3rd Edition Laying the Groundwork for Controlling Your Project ............................ 232 Selecting and preparing your tracking systems ............................ 232 Establishing schedules for reports and meetings ......................... 233 Setting your project’s baseline ........................................................ 234 Hear Ye, Hear Ye! Announcing Your Project............................................ 234 Setting the Stage for Your Post-Project Evaluation ................................. 235 Relating This Chapter to the PMP Exam and PMBOK 4.......................... 236 Part IV: Steering the Ship: Managing Your Project to Success..................................................... 237 Chapter 12: Tracking Progress and Maintaining Control . . . . . . . . . .239 Holding On to the Reins: Project Control ................................................. 239 Establishing Project Management Information Systems ........................ 241 The clock’s ticking: Monitoring schedule performance ............... 242 All in a day’s work: Monitoring work effort .................................... 248 Follow the money: Monitoring expenditures ................................. 252 Putting Your Control Process into Action ................................................ 256 Heading off problems before they occur ........................................ 256 Formalizing your control process ................................................... 257 Identifying possible causes of delays and variances .................... 258 Identifying possible corrective actions........................................... 259 Getting back on track: Rebaselining ................................................ 259 Reacting Responsibly When Changes Are Requested ............................ 260 Responding to change requests....................................................... 260 Creeping away from scope creep .................................................... 261 Relating This Chapter to the PMP Exam and PMBOK 4.......................... 262 Chapter 13: Keeping Everyone Informed . . . . . . . . . . . . . . . . . . . . . . . .263 I Said What I Meant and I Meant What I Said: Successful Communication Basics ............................................................................ 264 Breaking down the communication process .................................. 264 Distinguishing one-way and two-way communication .................. 265 Can you hear me? Listening actively ............................................... 265 Choosing the Appropriate Medium for Project Communication .......... 267 Just the facts: Written reports ......................................................... 268 Move it along: Meetings that work .................................................. 270 Preparing a Written Project-Progress Report .......................................... 272 Making a list (of names) and checking it twice .............................. 273 Knowing what’s hot (and what’s not) in your report.................... 273 Earning a Pulitzer, or at least writing an interesting report ......... 274 Holding Key Project Meetings .................................................................... 276 Regularly scheduled team meetings................................................ 276 Ad hoc team meetings ....................................................................... 277 Upper-management progress reviews ............................................ 278
Slide 17: Table of Contents Preparing a Project Communications Management Plan ....................... 279 Relating This Chapter to the PMP Exam and PMBOK 4.......................... 279 xv Chapter 14: Encouraging Peak Performance by Providing Effective Leadership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .281 Comparing Leadership and Management................................................. 281 Developing Personal Power and Influence ............................................... 282 Understanding why people do what you ask ................................. 282 Establishing the bases of your power ............................................. 284 You Can Do It! Creating and Sustaining Team Member Motivation ...... 285 Increasing commitment by clarifying your project’s benefits ..... 286 Encouraging persistence by demonstrating project feasibility ... 287 Letting people know how they’re doing ......................................... 288 Providing rewards for work well done ............................................ 289 Relating This Chapter to the PMP Exam and PMBOK 4.......................... 290 Chapter 15: Bringing Your Project to Closure . . . . . . . . . . . . . . . . . . . .291 Staying the Course to Completion............................................................. 292 Planning ahead for your project’s closure ..................................... 292 Updating your initial closure plans when you’re ready to wind down the project .............................................................. 293 Charging up your team for the sprint to the finish line ................ 293 Handling Administrative Issues ................................................................. 294 Providing a Good Transition for Team Members .................................... 295 Surveying the Results: The Post-Project Evaluation ............................... 297 Preparing for the evaluation throughout the project ................... 297 Setting the stage for the evaluation meeting .................................. 298 Conducting the evaluation meeting................................................. 300 Following up on the evaluation ........................................................ 301 Relating This Chapter to the PMP Exam and PMBOK 4.......................... 302 Part V: Taking Your Project Management to the Next Level .......................................................... 303 Chapter 16: Using Technology to Up Your Game . . . . . . . . . . . . . . . . .305 Using Computer Software Effectively........................................................ 305 Looking at your software options .................................................... 306 Helping your software perform at its best...................................... 310 Introducing project-management software into your operations .............................................................................. 312 Making Use of E-Mail ................................................................................... 313 Distinguishing the pros and cons of e-mail .................................... 313 Using e-mail appropriately ............................................................... 315 Getting the most out of your e-mail ................................................. 315 Supporting Virtual Teams with Communication Technology ............... 316 Relating This Chapter to the PMP Exam and PMBOK 4.......................... 318
Slide 18: xvi Project Management For Dummies, 3rd Edition Chapter 17: Monitoring Project Performance with Earned Value Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .319 Defining Earned Value Management ......................................................... 319 Understanding EVM terms and formulas........................................ 320 Looking at a simple example ............................................................ 323 Determining the reasons for observed variances ......................... 325 The How-To: Applying Earned Value Management to Your Project ..... 326 Determining a Task’s Earned Value .......................................................... 329 Relating This Chapter to the PMP Exam and PMBOK 4.......................... 332 Part VI: The Part of Tens ........................................... 333 Chapter 18: Ten Questions to Ask Yourself as You Plan Your Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .335 What’s the Purpose of Your Project? ........................................................ 335 Whom Do You Need to Involve? ................................................................ 336 What Results Will You Produce? ............................................................... 336 What Constraints Must You Satisfy? ......................................................... 336 What Assumptions Are You Making? ........................................................ 337 What Work Has to Be Done? ...................................................................... 337 When Does Each Activity Start and End? ................................................. 337 Who Will Perform the Project Work? ........................................................ 338 What Other Resources Do You Need? ...................................................... 338 What Can Go Wrong? .................................................................................. 338 Chapter 19: Ten Tips for Being a Better Project Manager . . . . . . . . .339 Be a “Why” Person....................................................................................... 339 Be a “Can Do” Person .................................................................................. 339 Think about the Big Picture ....................................................................... 340 Think in Detail .............................................................................................. 340 Assume Cautiously ...................................................................................... 340 View People as Allies, Not Adversaries .................................................... 340 Say What You Mean, and Mean What You Say ........................................ 341 Respect Other People ................................................................................. 341 Acknowledge Good Performance .............................................................. 341 Be a Manager and a Leader ........................................................................ 342 Appendix: Combining the Techniques into Smooth-Flowing Processes ......................................... 343 Index ....................................................................... 347
Slide 19: Introduction rojects have been around since ancient times. Noah building the ark, Leonardo da Vinci painting the Mona Lisa, Edward Gibbon writing The Decline and Fall of the Roman Empire, Jonas Salk developing the polio vaccine — all projects. And, as you know, these were all masterful successes. (Well, the products were a spectacular success, even if schedules and resource budgets were drastically overrun!) Why, then, is the topic of project management of such great interest today? The answer is simple: The audience has changed and the stakes are higher. Historically, projects were large, complex undertakings. The first project to use modern project-management techniques — the Polaris weapons system in the early 1950s — was a technical and administrative nightmare. Teams of specialists planned and tracked the myriad of research, development, and production activities. They produced mountains of paper to document the intricate work. As a result, people started to view project management as a highly technical discipline with confusing charts and graphs; they saw it as inordinately time-consuming, specialist-driven, and definitely off-limits for the common man or woman! Because of the ever-growing array of huge, complex, and technically challenging projects in today’s world, people who want to devote their careers to planning and managing them are still vital to their successes. Over the past 25 to 30 years, however, the number of projects in the regular workplace has skyrocketed. Projects of all types and sizes are now the way that organizations accomplish their work. At the same time, a new breed of project manager has emerged. This new breed may not have set career goals to become project managers — many among them don’t even consider themselves to be project managers. But they do know they must successfully manage projects to move ahead in their careers. Clearly, project management has become a critical skill, not a career choice. Even though these people realize they need special tools, techniques, and knowledge to handle their new types of assignments, they may not be able or willing to devote large amounts of time to acquiring them, which is where this book comes in. I devote this book to that silent majority of project managers. P
Slide 20: 2 Project Management For Dummies, 3rd Edition About This Book This book helps you recognize that the basic tenets of successful project management are simple. The most complex analytical technique takes less than ten minutes to master! In this book, I introduce information that’s necessary to plan and manage projects, and I provide important guidelines for developing and using this information. Here, you discover that the real challenge to a successful project is dealing with the multitude of people whom a project may affect or need for support. I present plenty of tips, hints, and guidelines for identifying key players and then involving them. But knowledge alone won’t make you a successful project manager — you need to apply it. This book’s theme is that project-management skills and techniques aren’t burdensome tasks you perform because some process requires it. Rather, they’re a way of thinking, communicating, and behaving. They’re an integral part of how we approach all aspects of our work every day. So I’ve written the book to be direct and (relatively) easy to understand. But don’t be misled — the simple text still navigates all the critical tools and techniques you’ll need to support your project planning, scheduling, budgeting, organizing, and controlling. So buckle up! I present this information in a logical and modular progression. Examples and illustrations are plentiful — so are the tips and hints. And I inject humor from time to time to keep it all doable. My goal is that you finish this book feeling that good project management is a necessity and that you’re determined to practice it! Conventions Used in This Book To help you navigate through this book, I use the following conventions to help you find your way: ✓ I use italics to point out new words and to alert you to their definitions, which are always close by. On occasion, I also use italics for added emphasis. ✓ I use bold text to indicate keywords in bulleted lists or to highlight action parts in numbered lists. ✓ I put all Web sites in monofont. When this book was printed, some Web addresses may have needed to break across two lines of text. If that happened, rest assured that I haven’t put in any extra characters (such as hyphens) to indicate the break. So, when using one of these Web addresses, just type in exactly what you see in this book, pretending as though the line break doesn’t exist.
Slide 21: Introduction 3 What You’re Not to Read Of course, I want you to read every single word, but I understand your life is busy and you may have time to read only what’s relevant to your experience. In that case, feel free to skip the sidebars. Although the sidebars offer interesting and real-life stories of my own experiences, they’re not vital to grasping the concepts. Foolish Assumptions When writing this book, I assumed that a widely diverse group of people will read it, including the following: ✓ Senior managers and junior assistants (tomorrow’s senior managers) ✓ Experienced project managers and people who’ve never been on a project team ✓ People who’ve had significant project-management training and people who’ve had none ✓ People who’ve had years of real-world business and government experience and people who’ve just entered the workforce I assume that you have a desire to take control of your environment. After reading this book, I hope you wonder (and rightfully so) why all projects aren’t well managed — because you’ll think these techniques are so logical, straightforward, and easy to use. But I also assume you recognize there’s a big difference between knowing what to do and doing it. And I assume you realize you’ll have to work hard to overcome the forces that conspire to prevent you from using these tools and techniques. Finally, I assume you’ll realize that you can read this book repeatedly and learn something new and different each time. Think of this book as a comfortable resource that has more to share as you experience new situations. How This Book Is Organized Each chapter is self-contained, so you can read the chapters that interest you the most first — without feeling lost because you haven’t read the book from front to back. The book is divided into the following six parts.
Slide 22: 4 Project Management For Dummies, 3rd Edition Part I: Understanding Expectations (The Who, What, and Why of Your Project) In this part, I discuss the unique characteristics of projects and the key issues you may encounter in a project-oriented organization. I also show you how to clearly define your project’s proposed results, how to identify the people who will play a role, and how to determine your project’s work. Part II: Planning Time: Determining When and How Much In this part, I cover how to develop the project schedule and estimate the resources (both personnel and nonpersonnel) you need. I also show you how to identify and manage project risks. Part III: Group Work: Putting Your Team Together In this part, I show you how to identify, organize, and deal with people who play a part in your project’s success. I explain how to define team members’ roles and get your project off to a positive start. Part IV: Steering the Ship: Managing Your Project to Success In this part, I explain how to monitor, track, analyze, and report on your project’s activities. I also show you how to establish and maintain effective communications between you and all your project audiences and how to demonstrate leadership that energizes your project team. Then I discuss how to bring your project to a successful closure. Part V: Taking Your Project Management to the Next Level Here, I discuss how to use available technology to help you plan, organize, and control your project. I also discuss a technique for evaluating activity performance and resource expenditures on larger projects.
Slide 23: Introduction 5 Part VI: The Part of Tens Every For Dummies book has this fun part that gives you tidbits of information in an easy-to-chew format. In this part, I share tips on how to plan a project and how to be a better project manager. I also include one additional nugget of information: The appendix illustrates systematic processes for planning your project and for using the essential controls that I discuss throughout this book. Icons Used in This Book I include small icons in the left margins of the book to alert you to special information in the text. Here’s what they mean: This icon leads into hypothetical situations illustrating techniques and issues. I use this icon to point out terms or issues that are a bit more technical. I use this icon to point out important information you want to keep in mind as you apply the techniques and approaches. This icon highlights techniques or approaches you can use to improve your project-management practices. This icon highlights potential pitfalls and danger spots. Where to Go from Here You can read this book in many ways, depending on your own project-management knowledge and experience and your current needs. However, I suggest you first take a minute to scan the table of contents and thumb through the sections of the book to get a feeling for the topics I address. If you’re new to project management and are just beginning to form a plan for a project, first read Parts I and II, which explain how to plan outcomes, activities,
Slide 24: 6 Project Management For Dummies, 3rd Edition schedules, and resources. If you want to find out how to identify and organize your project’s team and other key people, start with Chapter 4 and Part III. If you’re ready to begin work or you’re already in the midst of your project, you may want to start with Part IV. Or, feel free to jump back and forth, hitting the chapters with topics that interest you the most. The most widely recognized reference of project-management best practices is A Guide to the Project Management Body of Knowledge (PMBOK), published by the Project Management Institute (PMI). The fourth and most recent edition of PMBOK (PMBOK 4) was published in 2008. The Project Management Professional (PMP) certification — the most recognized project-management credential throughout the world — includes an examination (administered by PMI) with questions based on PMBOK 4. Because I base my book on best practices for project-management activities, the tools and techniques I offer are in accordance with PMBOK 4. However, if you’re preparing to take the PMP examination, use my book as a companion to PMBOK 4, not as a substitute for it. As you read this book, keep the following points in mind: ✓ PMBOK 4 identifies what best practices are but doesn’t address in detail how to perform them or deal with difficulties you may encounter as you try to perform them. In contrast, my book focuses heavily on how to perform the project-management techniques and processes. ✓ I’ve revised and updated my book so that all the tools and techniques discussed and all the terminology used to describe those tools and techniques are in agreement with those used in PMBOK 4. ✓ Where appropriate, I include a section at the end of each chapter that specifies where the topics in the chapter are addressed in PMBOK 4. ✓ PMBOK 4 often contains highly technical language and detailed processes, which people mistakenly dismiss as being relevant only for larger projects. My book, however, deliberately frames terms and discussions to be user-friendly. As a result, people who work on projects of all sizes can understand how to apply the tools and techniques presented. No matter how you make your way through this book, plan on reading all the chapters more than once — the more you read a chapter, the more sense its approaches and techniques will make. And who knows? A change in your job responsibilities may create a need for certain techniques you’ve never used before. Have fun and good luck!
Slide 25: Part I Understanding Expectations (The Who, What, and Why of Your Project)
Slide 26: he most difficult part of a new project is often deciding where to begin. Expectations are high, while time and resources are frequently low. In this part, I identify how a project differs from other activities you perform in your organization, and I present a snapshot of the steps you need to take to plan, organize, and control your project. I offer you specific techniques and approaches to define clearly what you want your project to accomplish and who needs to be involved. Finally, I show you how to determine the work you have to do to meet the expectations for your project. T In this part . . .
Slide 27: Chapter 1 Project Management: The Key to Achieving Results In This Chapter ▶ Characterizing projects ▶ Breaking down project management ▶ Coming to grips with the project manager’s role ▶ Determining whether you have what you need to be a successful project manager uccessful organizations create projects that produce desired results in established time frames with assigned resources. As a result, businesses are increasingly driven to find individuals who can excel in this projectoriented environment. Because you’re reading this book, chances are good that you’ve been asked to manage a project. So, hang on tight — you’re going to need a new set of skills and techniques to steer that project to successful completion. But not to worry! This chapter gets you off to a smooth start by showing you what projects and project management really are and by helping you separate projects from nonproject assignments. This chapter also offers the rationale for why projects succeed or fail and gets you into the project-management mindset. S Determining What Makes a Project a Project No matter what your job is, you handle a myriad of assignments every day: prepare a memo, hold a meeting, design a sales campaign, or move to new offices. Or maybe your day sounds more like this: make the information
Slide 28: 10 Part I: Understanding Expectations (The Who, What, and Why of Your Project) systems more user-friendly, develop a research compound in the laboratory, or improve the organization’s public image. Not all these assignments are projects. How can you tell which ones are and which ones aren’t? This section is here to help. Understanding the three main components that define a project A project is a temporary undertaking performed to produce a unique product, service, or result. Large or small, a project always has the following three components: ✓ Specific scope: Desired results or products (Check out Chapter 2 for more on describing desired results.) ✓ Schedule: Established dates when project work starts and ends (See Chapter 5 for how to develop responsive and feasible project schedules.) ✓ Required resources: Necessary amounts of people, funds, and other resources (See Chapter 6 for how to establish whom you need for your project and Chapter 7 for how to set up your budget and determine any other resources needs.) As illustrated in Figure 1-1, each component affects the other two. For example: Expanding the type and characteristics of desired outcomes may require more time (a later end date) or more resources. Moving up the end date may necessitate paring down the results or increasing project expenditures (for instance, by paying overtime to project staff). Within this three-part project definition, you perform work to achieve your desired results. Product Figure 1-1: The relationship between the three main components of a project. Schedule Resources
Slide 29: Chapter 1: Project Management: The Key to Achieving Results Although many other considerations may affect a project’s performance (see the discussions in the “Defining Project Management” section later in this chapter for more), these three components are the basis of a project’s definition for the following three reasons: ✓ The only reason a project exists is to produce the results specified in its scope. ✓ The project’s end date is an essential part of defining what constitutes successful performance — the desired result must be provided by a certain time to meet its intended need. ✓ The availability of resources shapes the nature of the products the project can produce. A Guide to the Project Management Body of Knowledge, 4th Edition (PMBOK 4), elaborates on these components by ✓ Emphasizing that product includes the basic nature of what is to be produced (for example, a new training program or a new prescription drug), as well as its required characteristics (for example, the topics that the training program must address), which are defined as its quality ✓ Noting that resources refers to funds, as well as to other, nonmonetary resources, such as people, equipment, raw materials, and facilities PMBOK 4 also emphasizes that risk (the likelihood that not everything will go exactly according to plan) is an important consideration when defining a project and that guiding a project to success involves continually managing tradeoffs among all these factors. 11 Recognizing the diversity of projects Projects come in a wide assortment of shapes and sizes. For example, projects can ✓ Be large or small • Installing a new subway system, which may cost more than $1 billion and take 10 to 15 years to complete, is a project. • Preparing an ad hoc report of monthly sales figures, which may take you one day to complete, is also a project. ✓ Involve many people or just you • Training all 10,000 of your organization’s staff in a new affirmativeaction policy is a project. • Rearranging the furniture and equipment in your office is also a project.
Slide 30: 12 Part I: Understanding Expectations (The Who, What, and Why of Your Project) ✓ Be defined by a legal contract or by an informal agreement • A signed contract between you and a customer that requires you to build a house defines a project. • An informal promise you make to install a new software package on your colleague’s computer also defines a project. ✓ Be business-related or personal • Conducting your organization’s annual blood drive is a project. • Having a dinner party for 15 people is also a project. No matter what the individual characteristics of your project are, you define it by the same three components I describe in the previous section: results (or scope), start and end dates, and resources. The information you need to plan and manage your project is the same for any project you manage, although the ease and the time to develop it may differ. The more thoroughly you plan and manage your projects, the more likely you are to succeed. Describing the four stages of a project Every project, whether large or small, passes through the following four stages: ✓ Starting the project: This stage involves generating, evaluating, and framing the business need for the project and the general approach to performing it and agreeing to prepare a detailed project plan. Outputs from this stage may include approval to proceed to the next stage, documentation of the need for the project and rough estimates of time and resources to perform it (often included in a project charter), and an initial list of people who may be interested in, involved with, or affected by the project. ✓ Organizing and preparing: This stage involves developing a plan that specifies the desired results; the work to do; the time, the cost, and other resources required; and a plan for how to address key project risks. Outputs from this stage may include a project plan documenting the intended project results and the time, resources, and supporting processes to help create them. ✓ Carrying out the work: This stage involves establishing the project team and the project support systems, performing the planned work, and monitoring and controlling performance to ensure adherence to the current plan. Outputs from this stage may include project results, project progress reports, and other communications. ✓ Closing the project: This stage involves assessing the project results, obtaining customer approvals, transitioning project team members to new assignments, closing financial accounts, and conducting a postproject evaluation. Outputs from this stage may include final, accepted and approved project results and recommendations and suggestions for applying lessons learned from this project to similar efforts in the future.
Slide 31: Chapter 1: Project Management: The Key to Achieving Results 13 A project by any other name — just isn’t a project People often confuse the following two terms with project: ✓ Process: A process is a series of routine steps to perform a particular function, such as a procurement process or a budget process. A process isn’t a one-time activity that achieves a specific result; instead, it defines how a particular function is to be done every time. Processes like the activities that go into buying materials are often parts of projects. ✓ Program: This term can describe two different situations. First, a program can be a set of goals that gives rise to specific projects, but, unlike a project, a program can never be completely accomplished. For example, a health-awareness program can never completely achieve its goal (the public will never be totally aware of all health issues as a result of a health-awareness program), but one or more projects may accomplish specific results related to the program’s goal (such as a workshop on minimizing the risk of heart disease). Second, a program sometimes refers to a group of specified projects that achieve a common goal. For small projects, this entire life cycle can take a few days. For larger projects, it can take many years! In fact, to allow for greater focus on key aspects and to make it easier to monitor and control the work, project managers often subdivide larger projects into separate phases, each of which is treated as a miniproject and passes through these four life cycle stages. No matter how simple or complex the project is, however, these four stages are the same. In a perfect world, you complete one stage of your project before you move on to the next one; and after you complete a stage, you never return to it again. But the world isn’t perfect, and project success often requires a flexible approach that responds to real situations that you may face, such as the following: ✓ You may have to work on two (or more) project stages at the same time to meet tight deadlines. Working on the next stage before you complete the current one increases the risk that you may have to redo tasks, which may cause you to miss deadlines and spend more resources than you originally planned. If you choose this strategy, be sure people understand the potential risks and costs associated with it (see Chapter 8 for how to assess and manage risks). ✓ Sometimes you learn by doing. Despite doing your best to assess feasibility and develop detailed plans, you may realize you can’t achieve what you thought you could. When this situation happens, you need to return to the earlier project stages and rethink them in light of the new information you’ve acquired.
Slide 32: 14 Part I: Understanding Expectations (The Who, What, and Why of Your Project) ✓ Sometimes things change unexpectedly. Your initial feasibility and benefits assessments are sound and your plan is detailed and realistic. However, certain key project team members leave the organization without warning during the project. Or a new technology emerges, and it’s more appropriate to use than the one in your original plans. Because ignoring these occurrences may seriously jeopardize your project’s success, you need to return to the earlier project stages and rethink them in light of these new realities. Defining Project Management Project management is the process of guiding a project from its beginning through its performance to its closure. Project management includes five sets of processes, which I describe in more detail in the following sections: ✓ Initiating processes: Clarifying the business need, defining high-level expectations and resource budgets, and beginning to identify audiences that may play a role in your project ✓ Planning processes: Detailing the project scope, time frames, resources, and risks, as well as intended approaches to project communications, quality, and management of external purchases of goods and services ✓ Executing processes: Establishing and managing the project team, communicating with and managing project audiences, and implementing the project plans ✓ Monitoring and controlling processes: Tracking performance and taking actions necessary to help ensure project plans are successfully implemented and the desired results are achieved ✓ Closing processes: Ending all project activity As illustrated in Figure 1-2, these five process groups help support the project through the four stages of its life cycle. Initiating processes support the work to be done when starting the project, and planning processes support the organizing and preparing stage. Executing processes guide the project tasks performed when carrying out the work, and closing processes are used to perform the tasks that bring the project to an end. The figure highlights how you may cycle back from executing processes to planning processes when you have to return to the organizing and preparing stage to modify existing plans to address problems you encounter or new information you acquire while carrying out the project work. Finally, monitoring and controlling processes are used in each of the four stages to help ensure that work is being performed according to plans.
Slide 33: Chapter 1: Project Management: The Key to Achieving Results 15 Monitoring and controlling processes Planning processes Figure 1-2: The five projectmanagement process groups that support the four project life cycle stages. Initiating processes Closing processes Executing processes Starting the project Organizing and preparing Carrying out the work Closing out the project Successfully performing these processes requires the following: ✓ Information: Accurate, timely, and complete data for the planning, performance monitoring, and final assessment of the project ✓ Communication: Clear, open, and timely sharing of information with appropriate individuals and groups throughout the project’s duration ✓ Commitment: Team members’ personal promises to produce the agreed-upon results on time and within budget Examining the initiating processes All projects begin with an idea. Perhaps your organization’s client identifies a need; or maybe your boss thinks of a new market to explore; or maybe you think of a way to refine your organization’s procurement process. Sometimes the initiating process is informal. For a small project, it may consist of just a discussion and a verbal agreement. In other instances, especially for larger projects, a project requires a formal review and decision by your boss and/or other members of your organization’s senior management team. Decision makers consider the following two questions when deciding whether to move ahead with a project: ✓ Should we do it? Are the benefits we expect to achieve worth the costs we’ll have to pay? Are there better ways to approach the issue? ✓ Can we do it? Is the project technically feasible? Are the required resources available?
Slide 34: 16 Part I: Understanding Expectations (The Who, What, and Why of Your Project) If the answer to both questions is “Yes,” the project can proceed to the organizing and preparing stage (see the following section), during which a project plan is developed. If the answer to either question is a definite, iron-clad “No,” under no circumstances should the project go any further. If nothing can be done to make it desirable and feasible, the decision makers should cancel the project immediately. Doing anything else guarantees wasted resources, lost opportunities, and a frustrated staff. (Check out the later sidebar “Performing a benefit-cost analysis” if you need extra help determining the answer to the first question.) Suppose you’re in charge of the publications department in your organization. You’ve just received a request to have a 20,000-page document printed in ten minutes, which requires equipment that can reproduce at the rate of 2,000 pages per minute. You check with your staff and confirm that your document-reproducing equipment has a top speed of 500 pages per minute. You check with your suppliers and find out that the fastest document-reproducing equipment available today has a top speed of 1,000 pages per minute. Do you agree to plan and perform this project when you know you can’t possibly meet the request? Of course not. Rather than promising something you know you can’t achieve, consider asking your customer whether she can change the request. For example, can she accept the document in 20 minutes? Can you reproduce certain parts of the document in the first ten minutes and the rest later? During some projects, you may be convinced that you can’t meet a particular request or that the benefits of the project aren’t worth the costs involved. Be sure to check with the people who developed or approved the project. They may have information you don’t, or you may have additional information that they weren’t aware of when they approved the request. Performing a benefit-cost analysis A benefit-cost analysis is a comparative assessment of all the benefits you anticipate from your project and all the costs to introduce the project, perform it, and support the changes resulting from it. Benefit-cost analyses help you to ✓ Decide whether to undertake a project or decide which of several projects to undertake. ✓ Frame appropriate project objectives. ✓ Develop appropriate before and after measures of project success. ✓ Prepare estimates of the resources required to perform the project work. You can express some anticipated benefits in monetary equivalents (such as reduced operating costs or increased revenue). For other benefits, numerical measures can approximate some,
Slide 35: Chapter 1: Project Management: The Key to Achieving Results 17 but not all, aspects. If your project is to improve staff morale, for example, you may consider associated benefits to include reduced turnover, increased productivity, fewer absences, and fewer formal grievances. Whenever possible, express benefits and costs in monetary terms to facilitate the assessment of a project’s net value. Consider costs for all phases of the project. Such costs may be nonrecurring (such as labor, capital investment, and certain operations and services) or recurring (such as changes in personnel, supplies, and materials or maintenance and repair). In addition, consider the following: ✓ Potential costs of not doing the project ✓ Potential costs if the project fails ✓ Opportunity costs (in other words, the potential benefits if you had spent your funds successfully performing a different project) The farther into the future you look when performing your analysis, the more important it is to convert your estimates of benefits over costs into today’s dollars. Unfortunately, the farther you look, the less confident you can be of your estimates. For example, you may expect to reap benefits for years from a new computer system, but changing technology may make your new system obsolete after only one year. Thus, the following two key factors influence the results of a benefit-cost analysis: ✓ How far into the future you look to identify benefits ✓ On which assumptions you base your analysis Although you may not want to go out and design a benefit-cost analysis by yourself, you definitely want to see whether your project already has one and, if it does, what the specific results of that analysis were. The excess of a project’s expected benefits over its estimated costs in today’s dollars is its net present value (NPV). The net present value is based on the following two premises: ✓ Inflation: The purchasing power of a dollar will be less one year from now than it is today. If the rate of inflation is 3 percent for the next 12 months, $1 today will be worth $0.97 12 months from today. In other words, 12 months from now, you’ll pay $1 to buy what you paid $0.97 for today. ✓ Lost return on investment: If you spend money to perform the project being considered, you’ll forego the future income you could earn by investing it conservatively today. For example, if you put $1 in a bank and receive simple interest at the rate of 3 percent compounded annually, 12 months from today you’ll have $1.03 (assuming zero-percent inflation). To address these considerations when determining the NPV, you specify the following numbers: ✓ Discount rate: The factor that reflects the future value of $1 in today’s dollars, considering the effects of both inflation and lost return on investment ✓ Allowable payback period: The length of time for anticipated benefits and estimated costs In addition to determining the NPV for different discount rates and payback periods, figure the project’s internal rate of return (the value of discount rate that would yield an NPV of zero) for each payback period.
Slide 36: 18 Part I: Understanding Expectations (The Who, What, and Why of Your Project) Beware of assumptions that you or other people make when assessing your project’s potential value, cost, and feasibility. For example, just because your requests for overtime have been turned down in the past doesn’t guarantee they’ll be turned down again this time. Considering the planning processes When you know what you hope to accomplish and you believe it’s possible, you need a detailed plan that describes how you and your team will make it happen. Include the following in your project-management plan: ✓ An overview of the reasons for your project (Chapter 2 tells you what to include.) ✓ A detailed description of intended results (Chapter 2 explains how to describe desired results.) ✓ A list of all constraints the project must address (Chapter 2 explores the different types of constraints a project may face.) ✓ A list of all assumptions related to the project (Chapter 2 discusses how to frame assumptions.) ✓ A list of all required work (Chapter 4 discusses how to identify all required project work.) ✓ A breakdown of the roles you and your team members will play (Chapter 10 explains how to describe roles and responsibilities.) ✓ A detailed project schedule (Chapter 5 explains how to develop your schedule.) ✓ Needs for personnel, funds, and nonpersonnel resources (such as equipment, facilities, and information) (Chapter 6 illustrates how to estimate resource personnel needs, and Chapter 7 takes a close look at estimating nonpersonnel needs and developing your project’s budget.) ✓ A description of how you plan to manage any significant risks and uncertainties (Chapter 8 explains how to identify and plan for risks.) ✓ Plans for project communications (Chapter 13 discusses how to keep everyone who’s involved in your project up-to-date.) ✓ Plans for ensuring project quality (Chapter 12 covers how to track progress and maintain control of your project throughout its life cycle so as to achieve success.) Always put your project plans in writing; doing so helps you clarify details and reduces the chances that you’ll forget something. Plans for large projects can take hundreds of pages, but a plan for a small project can take only a few lines on a piece of paper (or a tablecloth!).
Slide 37: Chapter 1: Project Management: The Key to Achieving Results The success of your project depends on the clarity and accuracy of your plan and on whether people believe they can achieve it. Considering past experience in your project plan makes your plan more realistic; involving people in the plan’s development encourages their commitment to achieving it. Often the pressure to get fast results encourages people to skip the planning and get right to the tasks. Although this strategy can create a lot of immediate activity, it also creates significant chances for waste and mistakes. Be sure your project’s drivers and supporters review and approve the plan in writing before you begin your project (see Chapter 3). For a small project, you may need only a brief e-mail or someone’s initials on the plans. For a larger project, though, you may need a formal review and signoff by one or more levels of your organization’s management. 19 Examining the executing processes After you’ve developed your project-management plan and set your appropriate project baselines, it’s time to get to work and start executing your plan. This is often the phase when management gets more engaged and excited to see things being produced. Preparing Preparing to begin the project work involves the following tasks (see Chapter 11 for details): ✓ Assigning people to all project roles: Confirm the individuals who’ll perform the project work, and negotiate agreements with them and their managers to assure they’ll be available to work on the project team. ✓ Introducing team members to each other and to the project: Help people begin developing interpersonal relationships with each other. Help them appreciate the overall purpose of the project and how the different parts will interact and support each other. ✓ Giving and explaining tasks to all team members: Describe to all team members what work they’re responsible for producing and how the team members will coordinate their efforts. ✓ Defining how the team will perform its essential functions: Decide how the team will handle routine communications, make different project decisions, and resolve conflicts. Develop any procedures that may be required to guide performance of these functions. ✓ Setting up necessary tracking systems: Decide which system(s) and accounts you’ll use to track schedules, work effort, and expenditures, and set them up.
Slide 38: 20 Part I: Understanding Expectations (The Who, What, and Why of Your Project) ✓ Announcing the project to the organization: Let the project audiences know that your project exists, what it will produce, and when it will begin and end. Suppose you don’t join your project team until the actual work is getting underway. Your first task is to understand how people decided initially that the project was possible and desirable. If the people who participated in the start of the project and the organizing and preparing stages overlooked important issues, you need to raise them now. When searching for the project’s history, check minutes from meetings, memos, letters, e-mails, and technical reports. Then consult with all the people involved in the initial project decisions. Performing Finally, you get to perform the project work! The performing subgroup of the executing processes includes the following tasks (see Chapters 13 and 14 for more details): ✓ Doing the tasks: Perform the work that’s in your plan. ✓ Assuring quality: Continually confirm that work and results conform to requirements and applicable standards and guidelines. ✓ Managing the team: Assign tasks, review results, and resolve problems. ✓ Developing the team: Provide needed training and mentoring to improve team members’ skills. ✓ Sharing information: Distribute information to appropriate project audiences. Examining the monitoring and controlling processes As the project progresses, you need to ensure that plans are being followed and desired results are being achieved. The monitoring and controlling processes include the following tasks (see Chapter 12 for specific activities): ✓ Comparing performance with plans: Collect information on outcomes, schedule achievements, and resource expenditures; identify deviations from your plan; and develop corrective actions. ✓ Fixing problems that arise: Change tasks, schedules, or resources to bring project performance back on track with the existing plan, or negotiate agreed-upon changes to the plan itself. ✓ Keeping everyone informed: Tell project audiences about the team’s achievements, project problems, and necessary revisions to the established plan.
Slide 39: Chapter 1: Project Management: The Key to Achieving Results 21 Acknowledging the closing processes Finishing your assigned tasks is only part of bringing your project to a close. In addition, you must do the following (see Chapter 15 for a discussion of each of these points): ✓ Get your clients’ approvals of the final results. ✓ Close all project accounts (if you’ve been charging time and money to special project accounts). ✓ Help team members move on to their next assignments. ✓ Hold a post-project evaluation with the project team to recognize project achievements and to discuss lessons you can apply to the next project. (At the very least, make informal notes about these lessons and how you’ll use them in the future.) Knowing the Project Manager’s Role The project manager’s job is challenging. For instance, she often coordinates technically specialized professionals — who may have limited experience working together — to achieve a common goal. Although the project manager’s own work experience is often technical in nature, her success requires a keen ability to identify and resolve sensitive organizational and interpersonal issues. In this section, I describe the main tasks that a project manager handles and note potential challenges she may encounter. Looking at the project manager’s tasks Historically, the performance rules in traditional organizations were simple: Your boss made assignments; you carried them out. Questioning your assignments was a sign of insubordination or incompetence. But these rules have changed. Today your boss may generate ideas, but you assess how to implement them. You confirm that a project meets your boss’s (and your organization’s) real need and then determine the work, schedules, and resources you require to implement it. Handling a project any other way simply doesn’t make sense. The project manager must be involved in developing the plans because she needs the opportunity to clarify expectations and proposed approaches and then to raise any questions she may have before the project work begins. The key to project success is being proactive. Instead of waiting for others to tell you what to do,
Slide 40: 22 Part I: Understanding Expectations (The Who, What, and Why of Your Project) ✓ Seek out information because you know you need it. ✓ Follow the plan because you believe it’s the best way. ✓ Involve people whom you know are important for the project. ✓ Raise issues and risks, analyze them, and elicit support to address them. ✓ Share information with the people you know need to have it. ✓ Put all important information in writing. ✓ Ask questions and encourage other people to do the same. ✓ Commit to your project’s success. Staving off potential excuses for not following a structured projectmanagement approach Be prepared for other people to fight your attempts to use proven projectmanagement approaches. And trust me: You need to be prepared for everything! The following list provides a few examples of excuses you may encounter as a project manager and the appropriate responses you can give. ✓ Excuse: Our projects are all crises; we have no time to plan. Response: Unfortunately for the excuse giver, this logic is illogical! In a crisis, you have limited time and resources to address the critical issues, and you definitely can’t afford to make mistakes. Because acting under pressure and emotion (the two characteristics of crises) practically guarantees that mistakes will occur, you can’t afford not to plan. ✓ Excuse: Structured project management is only for large projects. Response: No matter what size the project is, the information you need to perform it is the same. What do you need to produce? What work has to be done? Who’s going to do it? When will it end? Have you met expectations? Large projects may require many weeks or months to develop satisfactory answers to these questions. Small projects that last a few days or less may take only 15 minutes, but, either way, you still have to answer the questions. ✓ Excuse: These projects require creativity and new development. They can’t be predicted with any certainty. Response: Some projects are more predictable than others. However, people awaiting the outcomes of any project still have expectations for what they’ll get and when. Therefore, a project with many uncertainties needs a manager to develop and share initial plans and then to assess and communicate the effects of unexpected occurrences.
Slide 41: Chapter 1: Project Management: The Key to Achieving Results Even if you don’t encounter these specific excuses, you can adapt these response examples to address your own situations. 23 Avoiding “shortcuts” The short-term pressures of your job as a project manager may encourage you to act today in ways that cause you, your team, or your organization to pay a price tomorrow. Especially with smaller, less formal projects, you may feel no need for organized planning and control. Don’t be seduced into the following, seemingly easier shortcuts: ✓ Jumping directly from starting the project to carrying out the work: You have an idea and your project’s on a short schedule. Why not just start doing the work? Sounds good, but you haven’t defined the work to be done! Other variations on this shortcut include the following: • “This project’s been done many times before, so why do I have to plan it out again?” Even though projects can be similar to past ones, some elements are always different. Perhaps you’re working with some new people, using a new piece of equipment, and so on. Take a moment now to be sure your plan addresses the current situation. • “Our project’s different than it was before, so what good is trying to plan?” Taking this attitude is like saying you’re traveling in an unknown area, so why try to lay out your route on a road map? Planning for a new project is important because no one’s taken this particular path before. Although your initial plan may have to be revised during the project, you and your team need to have a clear statement of your intended plan from the outset. ✓ Failing to prepare in your carrying out the work stage: Time pressure is often the apparent justification for this shortcut. However, the real reason is that people don’t appreciate the need to define procedures and relationships before jumping into the actual project work. See Chapter 11 for a discussion of why this preparation step is so important — and get tips on how to complete it. ✓ Jumping right into the work when you join the project in the carrying out the work stage: The plan has already been developed, so why go back and revisit the starting the project and the organizing and preparing stages? Actually, you need to do so for two reasons: • To identify any issues that the developers may have overlooked • To understand the reasoning behind the plan and decide whether you feel the plan is achievable ✓ Only partially completing the closing stage: At the end of one project, you often move right on to the next. Scarce resources and short
Slide 42: 24 Part I: Understanding Expectations (The Who, What, and Why of Your Project) deadlines encourage this rapid movement, and starting a new project is always more challenging than wrapping up an old one. However, you never really know how successful your project is if you don’t take the time to ensure that all tasks are complete and that you’ve satisfied your clients. If you don’t take positive steps to apply the lessons this project has taught you, you’re likely to make the same mistakes you made in this project again or fail to repeat this project’s successful approaches. Staying aware of other potential challenges Projects are temporary; they’re created to achieve particular results. Ideally, when the results are achieved, the project ends. Unfortunately, this transitory nature of projects may create some project-management challenges, including the following: ✓ Additional assignments: People may be asked to accept an assignment to a new project in addition to — not in lieu of — existing assignments. And they may not be asked how the new work may affect their existing projects. (Higher management may just assume the project manager can handle everything.) When conflicts arise over a person’s time, the organization may not have adequate guidelines or procedures to resolve those conflicts (or they may not have any guidelines at all). ✓ New people on new teams: People who haven’t worked together before and who may not even know each other may be assigned to the same project team. This lack of familiarity with each other may slow the project down because team members may • Have different operating and communicating styles • Use different procedures for performing the same type of activity • Not have the time to develop mutual respect and trust Flip to Part III for guidance on how to put together a successful team and get off on the right foot. ✓ No direct authority: For most projects, the project manager and team members have no direct authority over each other. Therefore, the rewards that usually encourage top performance (such as salary increases, superior performance appraisals, and job promotions) aren’t available. In addition, conflicts over time commitments or technical direction may require input from a number of sources. As a result, they can’t be settled with one, unilateral decision. (See Chapter 10 for suggestions on how to work effectively with people when you have no direct authority over them.)
Slide 43: Chapter 1: Project Management: The Key to Achieving Results 25 Do You Have What It Takes to Be an Effective Project Manager? You’re reading this book because you want to be a better project manager, right? Well, before you really jump in, I suggest you do a quick self-evaluation to see what your strengths and weaknesses are. By answering the following ten questions, you can get an idea of what subjects you need to spend more time on so you can be as effective as possible. Good luck! Questions 1. Are you more concerned about being everyone’s friend or getting a job done right? 2. Do you prefer to do technical work or manage other people doing technical work? 3. Do you think the best way to get a tough task done is to do it yourself? 4. Do you prefer your work to be predictable or constantly changing? 5. Do you prefer to spend your time developing ideas instead of explaining those ideas to other people? 6. Do you handle crises well? 7. Do you prefer to work by yourself or with others? 8. Do you think you shouldn’t have to monitor people after they’ve promised to do a task for you? 9. Do you believe people should be self-motivated to perform their jobs? 10. Are you comfortable dealing with people at all organizational levels? Answers 1. Although maintaining good working relations is important, the project manager often must make decisions for the good of the project that some people don’t agree with. 2. Most project managers achieve their positions because of their strong performance on technical tasks. However, after you become a project manager, your job is to encourage other people to produce high-quality technical work rather than to do it all yourself.
Slide 44: 26 Part I: Understanding Expectations (The Who, What, and Why of Your Project) 3. Believing in yourself is important. However, the project manager’s task is to help other people develop to the point where they can perform tasks with the highest quality. 4. The project manager tries to minimize unexpected problems and situations through responsive planning and timely control. However, when problems do occur, the project manager must deal with them promptly to minimize their impact on the project. 5. Though coming up with ideas can help your project, the project manager’s main responsibility is to ensure that every team member correctly understands all ideas that are developed. 6. The project manager’s job is to provide a cool head to size up the situation, choose the best action, and encourage all members to do their parts in implementing the solution. 7. Self-reliance and self-motivation are important characteristics for a project manager. However, the key to any project manager’s success is to facilitate interaction among a diverse group of technical specialists. 8. Although you may feel that honoring one’s commitments is a fundamental element of professional behavior, the project manager needs both to ensure that people maintain their focus and to model how to work with others cooperatively. 9. People should be self-motivated, but the project manager has to encourage them to remain motivated by their job assignments and related opportunities. 10. The project manager deals with people at all levels — from upper management to support staff — who perform project-related activities. Check out the table of contents to find out where I discuss these different aspects of the project manager’s job in more depth. Relating This Chapter to the PMP Exam and PMBOK 4 Pay special attention to Table 1-1, which notes topics in this chapter that may be addressed on the Project Management Professional (PMP) certification exam and that are included in A Guide to the Project Management Body of Knowledge, 4th Edition (PMBOK 4).
Slide 45: Chapter 1: Project Management: The Key to Achieving Results 27 Table 1-1 Topic Chapter 1 Topics in Relation to the PMP Exam and PMBOK 4 Location in PMBOK 4 1.2. What is a Project? Comments The two definitions are essentially the same. The two sets of four project life cycle stages are the same. The two definitions are the same. Definition of a project (see the section “Determining What Makes a Project a Project”) The stages in a project’s life cycle (see the section “Describing the four stages of a project”) Definition of project management (see the section “Defining Project Management”) The five project-management process groups (see the section “Defining Project Management”) The initiating processes (see the section “Examining the initiating processes”) The planning processes (see the section “Considering the planning processes”) The executing processes (see the section “Examining the executing processes”) The monitoring and controlling processes (see the section “Examining the monitoring and controlling processes”) The closing processes (see the section “Acknowledging the closing processes”) The project manager’s role (see the section “Knowing the project manager’s role”) 2.1.1. Characteristics of the Project Life Cycle 1.3. What is Project Management? 1.3. What is Project Management? The two sets of five process groups are the same. The processes listed in both sources are essentially the same. The processes listed in both sources are essentially the same. The processes listed in both sources are essentially the same. The processes listed in both sources are essentially the same. 3.3. Initiating Process Group 3.4. Planning Process Group 3.5. Executing Process Group 3.6. Monitoring and Controlling Process Group 3.7. Closing Process Group 1.6. Role of a Project Manager The processes listed in both sources are essentially the same. The listings of roles in the two sources are essentially the same.
Slide 46: 28 Part I: Understanding Expectations (The Who, What, and Why of Your Project)
Slide 47: Chapter 2 Clarifying What You’re Trying to Accomplish — and Why In This Chapter ▶ Understanding your project’s Scope Statement ▶ Figuring out how your project fits into the big picture ▶ Identifying project constraints — and working with them ▶ Handling the unknowns of project planning A ll projects are created for a reason — someone identifies a need and devises a project to address that need. How well the project ultimately addresses that need defines the project’s success or failure. This chapter helps you develop a mutual agreement between the project’s requesters and the project team about your project’s goals and expectations. It also helps you establish the conditions necessary to perform the project work. Defining Your Project with a Scope Statement A Scope Statement is a written confirmation of the results your project will produce and the terms and conditions under which you’ll perform your work. Both the people who requested the project and the project team should agree to all terms in the Scope Statement before actual project work begins. Your Scope Statement should include the following information: ✓ Justification: How and why your project came to be, the business need(s) it addresses, the scope of work to be performed, and how it will affect and be affected by other related activities
Slide 48: 30 Part I: Understanding Expectations (The Who, What, and Why of Your Project) ✓ Objectives: The products, services, and/or results your project will produce (also referred to as deliverables) ✓ Product scope description: The features and functions of the products, services, and/or results your project will produce ✓ Product acceptance criteria: The process and criteria for accepting completed products, services, or results ✓ Constraints: Restrictions that limit what you can achieve, how and when you can achieve it, and how much achieving it can cost ✓ Assumptions: Statements about how you will address uncertain information as you conceive, plan, and perform your project Think of your Scope Statement, when viewed together with the other components of your project plan, as a binding agreement in which ✓ You and your team commit to producing certain results. Your project’s requesters commit that they’ll consider your project 100 percent successful if you produce these results. ✓ You and your team identify all restrictions regarding your approach to the work and what you need to support your work. Your project’s requesters agree that there are no restrictions other than the ones you’ve identified and that they’ll provide you the support you declare you need. ✓ You and your team identify all assumptions you made when agreeing to the terms of your Scope Statement. Your project’s requesters agree that, if any of these assumptions prove to be invalid, you may have to modify some or all of your project plans. Of course, predicting the future is impossible. In fact, the farther into the future you try to look, the less certain your predictions can be. However, your Scope Statement represents your project commitments based on what you know today and expect to be true in the future. If and when situations change, you have to assess the effect of the changes on all aspects of your project and propose the necessary changes to your Scope Statement. Your project’s requesters always have the option of either accepting your proposed changes (allowing the project to continue) or canceling your project.
Slide 49: Chapter 2: Clarifying What You’re Trying to Accomplish — and Why 31 Documents closely related to a Scope Statement Your organization may use a number of other documents that address issues similar to those included in the Scope Statement. When you use these other documents as sources of information to prepare or describe your project plan, be careful to note how they differ from the Scope Statement. Here’s a list of some of the more common documents that contain information similar to that in a Scope Statement: ✓ Market requirements document: A formal request to develop or modify a product. This document (typically prepared by a member of your organization’s sales and marketing group) may lead to the creation of a project. However, in its original form, this document reflects only the desires of the person who wrote it. It doesn’t reflect an assessment of whether meeting the request is possible or in the company’s best interest, nor is it a commitment to meet the request. ✓ Business requirements document: A description of the business needs that a requested product, service, or system must address. ✓ Technical requirements or specifications document: A description of the characteristics that the products and services produced must have. ✓ Project request: A written request for a project by a group within the organization. The project request indicates a desire for a project rather than a mutual agreement and commitment to perform it. ✓ Statement of work: A narrative description of products, services, or results to be supplied by a project. ✓ Project profile: A document that highlights the key information about a project (sometimes also called a project summary or a project abstract). ✓ Project charter: A document issued by upper management that formally establishes a project and authorizes the project manager to use organizational resources to perform project activities. ✓ Work order: A written description of work that people or groups within your organization will perform in support of your project. The signed work order focuses on work performance rather than overall project outcomes. ✓ Contract: A legal agreement for providing specified goods or services. Looking at the Big Picture: How Your Project Fits In Understanding the situation and thought processes that led to your project’s creation helps ensure that you and your project successfully meet people’s expectations. This section helps you clarify the first two elements of your Scope Statement: your project’s justification and objectives.
Slide 50: 32 Part I: Understanding Expectations (The Who, What, and Why of Your Project) Figuring out why you’re doing the project When you take on a project, why you’re doing it may seem obvious — because your boss told you to. The real question, though, isn’t why you choose to accept the assignment but why the project must be done (by you or anyone else) in the first place. The following sections help you identify people who may benefit from your project so you can then determine how their expectations and needs helped to justify the project. Identifying the initiator Your first task in discovering your project’s underlying justification is to determine who had the original idea that led to your project (this person is called the project’s initiator). Project success requires that, at a minimum, you meet this person’s needs and expectations. Identifying your project’s initiator is easy when he’s the person who directly assigns it to you. More likely, however, the person who gives you the project is passing along an assignment he received from someone else. If your project has passed through several people before it reaches you, you may have difficulty determining who really had the initial idea. Further, the original intent may have become blurred if people in the chain purposely or inadvertently changed the assignment a little as they passed it on. To determine who came up with the original idea for your project, take the following steps: 1. Ask the person who assigns you the project whether he originated the idea. 2. If that person didn’t initiate the idea, ask the following questions: • Who gave him the assignment? • Who else, if anyone, was involved in passing the assignment to him? • Who had the original idea for the project? 3. Check with all the people you identified in Step 2 and ask them the same questions. 4. Check the following written records that may confirm who originally had the idea: • Minutes from division-, department-, and organization-wide planning and budget sessions • Correspondence and e-mail referring to the project • Reports of planning or feasibility studies
Slide 51: Chapter 2: Clarifying What You’re Trying to Accomplish — and Why A feasibility study is a formal investigation to determine the likely success of performing certain work or achieving certain results. In addition to helping you identify the people who initiated your project, these written sources may shed light on what these people hope to get from it. 5. Consult with people who may be affected by or are needed to support your project; they may know who originated the idea. Be as specific as possible when specifying your project initiator. In other words, don’t write “The sales department requested promotional literature for product Alpha.” Instead, write “Mary Smith, the sales representative for the northeast region, requested promotional literature for product Alpha.” Be sure to distinguish between drivers and supporters as you seek to find your project’s initiator (see Chapter 3 for more information about drivers and supporters): ✓ Drivers have some say when defining the results of the project. They tell you what you should do. ✓ Supporters help you perform your project. They tell you what you can do. For example, the vice president of finance who requests a project to upgrade the organization’s financial information systems is a project driver. The manager of the computer center who must provide staff and resources to upgrade the organization’s information systems is a project supporter. Sometimes supporters claim to be drivers. For example, when the manager of the computer center is asked, he may say he initiated the project. In reality, however, the manager authorized the people and funds to perform the project, but the vice president of finance initiated the project. 33 Recognizing other people who may benefit from your project Although they may not have initiated the idea, other people may benefit from your completed project. They may be people who work with, support, or are clients of your project’s drivers, or they may have performed similar projects in the past. They may have expressed interests or needs in areas addressed by your project in meetings, correspondence, or informal conversations. Identify these other people as soon as possible to determine what their particular needs and interests are and how you can appropriately address them. These additional audiences may include people who ✓ Know the project exists and have expressed an interest in it ✓ Know it exists but don’t realize it can benefit them ✓ Are unaware of your project
Slide 52: 34 Part I: Understanding Expectations (The Who, What, and Why of Your Project) Identify these additional audiences by doing the following: ✓ Review all written materials related to your project. ✓ Consult with your project’s drivers and supporters ✓ Encourage everyone you speak to about the project to identify others who may benefit from it. As you identify people who can benefit from your project, also identify people who strongly oppose it. Figure out why they oppose your project and whether you can address their concerns. Take the time to determine whether they may be able to derive any benefits from your project, and, if they can, explain these benefits to them. If they continue to oppose your project, make a note in your risk-management plan about their opposition and how you plan to deal with it (see Chapter 8 for how to analyze and plan for project risks and uncertainties). Distinguishing the project champion A project champion is a person in a high position in the organization who strongly supports your project; advocates for your project in disputes, planning meetings, and review sessions; and takes necessary actions to help ensure that your project is successful. Sometimes the best champion is one whose support you never have to use. Just knowing that this person supports your project helps other people appreciate its importance and encourages them to work diligently to ensure its success. Check with your project’s drivers and supporters to find out whether your project already has a champion. If it doesn’t, work hard to recruit one by looking for people who can reap benefits from your project and who have sufficient power and influence to encourage serious, ongoing organizational commitment to your project. Explain to these people why the success of your project is in their best interest and how you may need their specific help as your project progresses. Assess how interested they are in your project and how much help they’re willing to provide. Considering people who’ll implement the results of your project Most projects create a product or service to achieve a desired result. Often, however, the person who asks you to create the product or service isn’t the one who’ll actually use it. Suppose your organization’s director of sales and marketing wants to increase annual sales by 10 percent in the next fiscal year. She decides that developing and introducing a new product, XYZ, will allow her to achieve this goal. However, she won’t actually go to all your organization’s customers and sell them XYZ; her sales staff will. Even though they didn’t come up with the idea to develop XYZ, the sales staff may have strong opinions about the characteristics XYZ should have — and so will the customers who ultimately buy (or don’t buy!) the product.
Slide 53: Chapter 2: Clarifying What You’re Trying to Accomplish — and Why To identify the real users of project products and services, try to do the following early in your project planning: ✓ Clarify the products and services that you anticipate producing. ✓ Identify exactly who will use these products and services and how they’ll use them. After you identify these people, consult with them to determine any additional interests or needs they may have that your project should also address. 35 Determining your project drivers’ real expectations and needs The needs that your project addresses may not always be obvious. Suppose, for example, that your organization decides to sponsor a blood drive. Is the real reason for your project to address the shortage of blood in the local hospital or to improve your organization’s image in the local community? The needs your project must satisfy to successfully achieve its purpose are termed your project’s requirements. When you clearly understand your project’s requirements, you can ✓ Choose project activities that enable you to accomplish the true desired results (see Chapter 4 for information on identifying project activities). ✓ Monitor performance during and at the end of the project to ensure that you’re meeting the real needs (see Chapter 12 for more information on how to track a project during performance). ✓ Realize when the project isn’t meeting the real needs so that you can suggest modifying or canceling it. When you’re initially assigned a project, you hope you’re told the products you’re supposed to produce and the needs you’re supposed to address. However, often you’re told what to produce (the outcomes), but you have to figure out the needs yourself. Consider the following questions as you work to define your project’s requirements: ✓ What needs do people want your project to address? Don’t worry at this point whether your project actually can address these needs or whether it’s the best way to address the needs. You’re just trying to identify the hopes and expectations that led to this project in the first place. ✓ How do you know that the needs you identify are the real hopes and expectations that people have for your project? Determining people’s real thoughts and feelings can be difficult. Sometimes they don’t want to share them; sometimes they don’t know how to express them clearly.
Slide 54: 36 Part I: Understanding Expectations (The Who, What, and Why of Your Project) When speaking with people to determine the needs your project should address, try the following techniques: ✓ Encourage them to speak at length about their needs and expectations. ✓ Listen carefully for any contradictions. ✓ Encourage them to clarify vague ideas. ✓ Try to confirm your information from two or more independent sources. ✓ Ask them to indicate the relative importance of addressing each of their needs. The following scheme is useful for prioritizing a person’s needs: ✓ Must: The project must address these needs, at the very least. ✓ Should: The project should address these needs, if at all possible. ✓ Nice to: It would be nice for the project to address these needs, if doing so doesn’t affect anything else. See whether your organization performed a formal benefit-cost analysis for your project. A benefit-cost analysis is a formal identification and assessment of the following (see Chapter 1 for further details): ✓ The benefits anticipated from your project ✓ The costs of • Performing your project • Using and supporting the products or services produced by your project The benefit-cost analysis documents the results that people were counting on when they decided to proceed with your project. Therefore, the analysis is an important source for the real needs that your project should address. Confirming that your project can address people’s needs Although needs may be thoroughly documented (see the preceding section), you may have difficulty determining whether your project can successfully address those needs. On occasion, companies fund formal feasibility studies to determine whether a project can successfully address a particular need. Other times, however, your project may be the result of a brainstorming session or someone’s creative vision. In this case, you may have less confidence that your project can accomplish its expected results. Don’t automatically reject a project at this point, but do aggressively determine the chances for success and the actions you can take to increase these chances. If you can’t find sufficient information to support your analysis, consider asking for a formal feasibility study.
Slide 55: Chapter 2: Clarifying What You’re Trying to Accomplish — and Why If you feel the risk of project failure is too great, share your concerns with the key decision makers and explain why you recommend not proceeding with your project. See the discussion of risk management in Chapter 8 for more information. 37 Uncovering other activities that relate to your project Your project doesn’t exist in a vacuum. It may require results from other projects, it may generate products that other projects will use, and it may address needs that other projects also address. For these reasons, you need to identify projects related to yours as soon as possible so you can coordinate the use of shared personnel and resources and minimize unintended overlap in project activities and results. Check the following sources to identify projects that may be related to yours: ✓ Your project’s audiences ✓ Centrally maintained lists of projects planned or being performed by your organization ✓ Organization-wide information-sharing vehicles, such as newsletters or your organization’s intranet ✓ Your organization’s project management office (PMO) ✓ Upper-management committees responsible for approving and overseeing your organization’s projects ✓ Your organization’s finance department, which may have established labor or cost accounts for such projects ✓ Your organization’s procurement department, which may have purchased goods or services for such projects ✓ Your organization’s information technology department, which may be storing, analyzing, or preparing progress reports for such projects ✓ Functional managers whose people may be working on such projects Emphasizing your project’s importance to your organization How much importance your organization places on your project directly influences the chances for your project’s success. When conflicting demands for scarce resources arise, resources usually go to those projects that can produce the greatest benefits for the organization. Your project’s perceived value depends on its intended benefits and people’s awareness of those benefits. Take the following steps to help people understand how your project will support the organization’s priorities:
Slide 56: 38 Part I: Understanding Expectations (The Who, What, and Why of Your Project) ✓ Look for existing statements or documents that confirm your project’s support of your organization’s priorities. Consult the following sources to find out more about your organization’s priorities: • Long-range plan: A formal report that identifies your organization’s overall direction, specific performance targets, and individual initiatives for the next one to five years • Annual budget: The detailed list of categories and individual initiatives that your organization will financially support during the year • Capital appropriations plan: The itemized list of all planned expenditures (over an established minimum amount) for facilities and equipment purchases, renovations, and repairs during the year • Your organization’s Key Performance Indicators (KPIs): Performance measures that describe your organization’s progress toward its goals When you review these documents, note whether your project or its intended outcome is specifically mentioned. In addition, determine whether your organization has made specific commitments to external customers or upper management related to your project’s completion. ✓ Describe in the justification portion of your Scope Statement how your project relates to the organization’s priorities. Include existing discussions of your project from the information sources mentioned in the preceding step. If your project isn’t specifically referenced in these sources, prepare a written explanation of how your project and its results will impact the organization’s priorities. Occasionally, you may find it difficult to identify specific results that people expect your project to generate. Perhaps the person who initiated the project has assumed different responsibilities and no longer has any interest in it, or maybe the original need the project was designed to address has changed. If people have trouble telling you how your project will help your organization, ask them what would happen if you didn’t perform your project. If they conclude that it wouldn’t make a difference, ask them how you can modify your project to benefit the organization. If they don’t think your project can be changed to produce useful results, consider suggesting that the project be canceled. Organizations are consistently overworked and understaffed. Spending precious time and resources on a project that everyone agrees will make no difference is the last thing your organization needs or wants. More likely, people do realize that your project can have a positive impact on the organization. Your job, then, is to help these people consistently focus on these valuable results.
Slide 57: Chapter 2: Clarifying What You’re Trying to Accomplish — and Why Being exhaustive in your search for information In your quest to find out what your project is supposed to accomplish and how it fits into your organization’s overall plans, you have to seek information that’s sensitive, sometimes contradictory, and often unwritten. Getting this information isn’t always easy, but following these tips can help make your search more productive: ✓ Try to find several sources for the same piece of information. The greater the number of independent sources that contain the same information, the more likely the information is correct. ✓ Whenever possible, get information from primary sources. A primary source contains the original information. A secondary source is someone else’s report of the information from the primary source. Suppose you need information from a recently completed study. You can get the information from the primary source (which is the actual report of the study written by the scientists who performed it), or you can get it from secondary sources (such as articles in magazines or scientific journals by authors who paraphrased and summarized the original report). The farther your source is from the primary source, the more likely the secondary information differs from the real information. ✓ Look for written sources because they’re the best. Check relevant minutes from meetings, correspondence, e-mail, reports from other projects, long-range plans, budgets, capital improvement plans, market requirement documents, and benefit-cost analyses. ✓ Speak with two or more people from the same area to confirm information. Different people have different styles of communication as well as different perceptions of the same situation. Speak with more than one person, and compare their messages to determine any contradictions. If you get different stories, speak with the people again to verify their initial information. Determine whether the people you consulted are primary or secondary sources (primary sources tend to be more accurate than secondary ones). Ask the people you consulted to explain or reconcile any remaining differences. ✓ When speaking with people about important information, arrange to have at least one other person present. Doing so allows two different people to interpret what they hear from the same individual. ✓ Write down all information you obtain from personal meetings. Share your written notes and summaries with other people who were present at the meeting to ensure that your interpretation is correct and to serve as a reminder of agreements made during the meeting. ✓ Plan to meet at least two times with your project’s key audiences. Your first meeting starts them thinking about issues. Allow some time for them to think over your initial discussions and to think of new ideas 39
Slide 58: 40 Part I: Understanding Expectations (The Who, What, and Why of Your Project) related to those issues. A second meeting gives you a chance to clarify any ambiguities or inconsistencies from the first session. (See Chapter 3 for more information on project audiences.) ✓ Practice active listening skills in all your meetings and conversations. See Chapter 13 for information on how to practice active listening. ✓ Wherever possible, confirm what you heard in personal meetings with written sources. When you talk with people, they share their perceptions and opinions. Compare those perceptions and opinions with written, factual data (from primary sources, if possible). Discuss any discrepancies with those same people. Drawing the line: Where your project starts and stops Sometimes your project stands alone, but more often it’s one part of related efforts to achieve a common result. You want to avoid duplicating the work of these other related projects, and, where appropriate, you want to coordinate your efforts with theirs. Your description of your project’s scope of work should specify clearly where your project starts and where it ends. Suppose your project is to develop a new product for your organization. You may frame your project’s scope description as follows: This project entails designing, developing, and testing a new product. If you feel your statement is in any way ambiguous, you may clarify your scope further by stating what you will not do: This project won’t include finalizing the market requirements or launching the new product. To make sure your project’s scope of work description is clear, do the following: ✓ Check for hidden inferences. Suppose your boss has asked you to design and develop a new product. Check to be sure she doesn’t assume you’ll also perform the market research to determine the new product’s characteristics. ✓ Use words that clearly describe intended activities. Suppose your project entails the implementation of a new information system. Are you sure that everyone defines implementation in the same way? For instance, do
Slide 59: Chapter 2: Clarifying What You’re Trying to Accomplish — and Why people expect it to include installing the new software, training people to use it, evaluating its performance, fixing problems with it, or something else? ✓ Confirm your understanding of your project’s scope with your project’s drivers and supporters. A colleague of mine had an assignment to prepare for the competitive acquisition of certain equipment. She developed a plan to include the selection of the vendor, award of the contract, and production and delivery of the equipment. Her boss was stunned with my colleague’s project estimate of six months and $500,000. He thought it would take less than two months and cost less than $25,000. After a brief discussion with her boss, my colleague realized her only job was to select the potential vendor, not actually place the order and have the equipment manufactured and delivered. Although she clarified her misunderstanding, she still wondered aloud, “But why would we select a vendor if we didn’t want to actually buy the equipment?” Of course, she missed the point. The question wasn’t whether the company planned to buy the equipment. (Certainly the intention to buy the equipment was the reason for her project.) The real question was whether her project or a different project in the future would purchase the equipment. 41 Stating your project’s objectives As I mention earlier in this chapter, objectives are outcomes your project will produce (they’re also referred to as deliverables). Your project’s outcomes may be products or services you develop or the results of using these products and services. The more clearly you define your project’s objectives, the more likely you are to achieve them. Include the following elements in your objectives: ✓ Statement: A brief narrative description of what you want to achieve ✓ Measures: Indicators you’ll use to assess your achievement ✓ Performance specifications: The value(s) of each measure that define success Suppose you take on a project to reformat a report that summarizes monthly sales activity. You may frame your project’s objective as shown in Table 2-1.
Slide 60: 42 Part I: Understanding Expectations (The Who, What, and Why of Your Project) Table 2-1 Statement A revised report that summarizes monthly sales activity An Illustration of a Project Objective Measures Content Performance Specifications Report must include total number of items sold, total sales revenue, and total number of returns for each product line. Report must be operational by August 31. Development expenditures are not to exceed $40,000. New report format must be approved by the vice president of sales, regional sales manager, district sales manager, and sales representatives. Schedule Budget Approvals Sometimes people try to avoid setting a specific target by establishing a range of values that defines successful performance. But setting a range is the same as avoiding the issue. Suppose you’re a sales representative and your boss says you’ll be successful if you achieve $20 million to $25 million in sales for the year. As far as you’re concerned, you’ll be 100 percent successful as soon as you reach $20 million. Most likely, however, your boss will consider you 100 percent successful only when you reach $25 million. Although you and your boss appeared to reach an agreement, you didn’t. In the following sections, I explain how to create clear and specific objectives, identify all types of objectives, and respond to resistance to objectives. Making your objectives clear and specific You need to be crystal clear when stating your project’s objectives. The more specific your project objectives are, the greater your chances are of achieving them. Here are some tips for developing clear objectives: ✓ Be brief when describing each objective. If you take an entire page to describe a single objective, most people won’t read it. Even if they do read it, your objective probably won’t be clear and may have multiple interpretations. ✓ Don’t use technical jargon or acronyms. Each industry (such as pharmaceuticals, telecommunications, finance, and insurance) has its own vocabulary, and so does each company within that industry. Within companies, different departments (such as accounting, legal, and information services) also have their own jargons. Because of this proliferation of specialized languages, the same three-letter acronym (TLA) can have two or more meanings in the same organization! To reduce the chances for misunderstandings, express your objectives in language that people of all backgrounds and experiences are familiar with.
Slide 61: Chapter 2: Clarifying What You’re Trying to Accomplish — and Why ✓ Make your objectives SMART, as follows: • Specific: Define your objectives clearly, in detail, with no room for misinterpretation. • Measurable: State the measures and performance specifications you’ll use to determine whether you’ve met your objectives. • Aggressive: Set challenging objectives that encourage people to stretch beyond their comfort zones. • Realistic: Set objectives the project team believes it can achieve. • Time sensitive: Include the date by which you’ll achieve the objectives. ✓ Make your objectives controllable. Make sure that you and your team believe you can influence the success of each objective. If you don’t believe you can, you may not commit 100 percent to achieving it (and most likely you won’t even try). In that case, it becomes a wish, not an objective. ✓ Identify all objectives. Time and resources are always scarce, so if you don’t specify an objective, you won’t (and shouldn’t) work to achieve it. ✓ Be sure drivers and supporters agree on your project’s objectives. When drivers buy into your objectives, you feel confident that achieving the objectives constitutes true project success. When supporters buy into your objectives, you have the greatest chance that people will work their hardest to achieve them. If drivers don’t agree with your objectives, revise them until they do agree. After all, your drivers’ needs are the whole reason for your project! If supporters don’t buy into your objectives, work with them to identify their concerns and develop approaches they think can work. 43 Probing for all types of objectives When you start a project, the person who makes the initial project request often tells you the major results she wants to achieve. However, she may want the project to address other items that she forgot to mention to you. And other (as yet unidentified) people may also want your project to accomplish certain results. You need to identify all project objectives as early as possible so you can plan for and devote the necessary time and resources to accomplishing each one. When you probe to identify all possible objectives, consider that projects may have objectives in the following three categories: ✓ Physical products or services ✓ The effects of these products or services ✓ General organizational benefits that weren’t the original reason for the project
Slide 62: 44 Part I: Understanding Expectations (The Who, What, and Why of Your Project) Suppose that your information technology (IT) department is about to purchase and install a new software package for searching and analyzing information in the company’s parts-inventory database. The following are examples of objectives this project may have in each category: ✓ Physical product or service: The completed installation and integration of the new software package with the parts-inventory database ✓ The effect of a product or service: Reduced inventory-storage costs due to timelier ordering facilitated by the new software ✓ A general organizational benefit: Use of the new software with other company databases An objective is different from a serendipity (a chance occurrence or coincidence). In the previous example of the new software package, consider that one project driver won’t be completely satisfied unless the software for the parts-inventory database is also installed and integrated with the company’s product-inventory database. In this case, installing the system on the company’s product-inventory database must be an objective of your project so you must devote specific time and resources to accomplish it. On the other hand, if your audience will be happy whether you do or don’t install the software on the second database, being able to use the software on that database is a serendipity — so you shouldn’t devote any time or resources specifically to accomplishing it. Determining all project objectives requires you to identify all drivers who may have specific expectations for your project. See Chapter 3 for a discussion of the different types of audiences and tips on how to identify them all. Anticipating resistance to clearly defined objectives Some people are uncomfortable committing to specific objectives because they’re concerned they may not achieve them. Unfortunately, no matter what the reason, not having specific objectives makes it more difficult to know whether you’re addressing your drivers’ true expectations and whether you’re meeting those expectations. In other words, when your objectives aren’t specific, you increase the chances that your project won’t succeed. Here are some excuses people give for not defining their objectives too specifically, along with suggestions for addressing those excuses: ✓ Excuse 1: Too much specificity stifles creativity. Response: Creativity should be encouraged — the question is where and when. You want your project’s drivers to be clear and precise when stating their objectives; you want your project’s supporters to be creative when figuring out ways to meet these objectives. You want to understand what people do expect from your project, not what they may expect. The more clearly you can describe their actual objectives, the easier it is to determine whether (and how) you can meet them.
Slide 63: Chapter 2: Clarifying What You’re Trying to Accomplish — and Why ✓ Excuse 2: Your project entails research and new development, and you can’t tell today what you’ll be able to accomplish. Response: Objectives are targets, not guarantees. Certain projects have more risks than others. When you haven’t done a task before, you don’t know whether it’s possible. And, if it is possible, you don’t know how long it’ll take and how much it’ll cost. But you must state at the outset exactly what you want to achieve and what you think is possible, even though you may have to change your objectives as the project progresses. ✓ Excuse 3: What if interests or needs change? Response: Objectives are targets based on what you know and expect today. If conditions change in the future, you may have to revisit one or more of your objectives to see whether they’re still relevant and feasible or whether they, too, must change. ✓ Excuse 4: The project’s requestor doesn’t know what she specifically wants her project to achieve. Response: Ask her to come back when she does. If you begin working on this project now, you have a greater chance of wasting time and resources to produce results that the requestor later decides she doesn’t want. ✓ Excuse 5: Even though specific objectives help determine when you’ve succeeded, they also make it easier to determine when you haven’t. Response: Yep. That’s true. However, because your project was framed to accomplish certain results, you need to know if those results were achieved. If they weren’t, you may have to perform additional work to accomplish them. In addition, you want to determine the benefits the organization is realizing from the money it’s spending. 45 Marking Boundaries: Project Constraints Naturally, you’d like to operate in a world where everything is possible — that is, where you can do anything necessary to achieve your desired results. Your clients and your organization, on the other hand, would like to believe that you can achieve everything they want with minimal or no cost to them. Of course, neither situation is true. Defining the constraints you must work within introduces reality into your plans and helps clarify expectations. As you plan and implement your project, think in terms of the following two types of constraints: ✓ Limitations: Restrictions other people place on the results you have to achieve, the time frames you have to meet, the resources you can use, and the way you can approach your tasks ✓ Needs: Requirements you stipulate must be met so you can achieve project success
Slide 64: 46 Part I: Understanding Expectations (The Who, What, and Why of Your Project) The following sections help you determine your project’s limitations and needs. Working within limitations Project limitations may influence how you perform your project and may even determine whether or not you (and your project’s drivers and supporters) decide to proceed with your project. Consult with your project’s drivers and supporters to identify limitations as early as possible so you can design your plan to accommodate them. Understanding the types of limitations Project limitations typically fall into several categories. By recognizing these categories, you can focus your investigations and thereby increase the chances that you’ll discover all limitations affecting your project. Your project’s drivers and supporters may have preset expectations or requirements in one or more of the following categories: ✓ Results: The products and effect of your project. For example, the new product must cost no more than $300 per item to manufacture, or the new book must be fewer than 384 pages in length. ✓ Time frames: When you must produce certain results. For example, your project must be done by June 30. You don’t know whether it’s possible to finish by June 30; you just know that someone expects the product to be produced by then. ✓ Resources: The type, amount, and availability of resources to perform your project work. Resources can include people, funds, equipment, raw materials, facilities, information, and so on. For example, you have a budget of $100,000; you can have two people full time for three months; or you can’t use the test laboratory during the first week in June. ✓ Activity performance: The strategies for performing different tasks. For example, you’re told that you must use your organization’s printing department to reproduce the new users’ manuals for the system you’re developing. You don’t know what the manual will look like, how many pages it’ll be, the number of copies you’ll need, or when you’ll need them. Therefore, you can’t know whether your organization’s printing department is up to the task. But at this point, you do know that someone expects you to have the printing department do the work. Be careful of vague limitations; they provide poor guidance for what you can or can’t do, and they can demoralize people who have to deal with them. Here are some examples of vague limitations and how you can improve them:
Slide 65: Chapter 2: Clarifying What You’re Trying to Accomplish — and Why ✓ Time frame limitation: • Vague: “Finish this project as soon as possible.” This statement tells you nothing. With this limitation, your audience may suddenly demand your project’s final results — with no advance warning. • Specific: “Finish this project by close of business June 30.” ✓ Resource limitation: • Vague: “You can have Laura Webster on your project part time in May.” How heavily can you count on her? From Laura’s point of view, how can she juggle all her assignments in that period if she has no idea how long each one will take? • Specific: “You can have Laura Webster on your project four hours per day for the first two weeks in May.” When people aren’t specific about their constraints, you can’t be sure whether you can honor their requests. The longer people wait to be specific, the less likely you are to adhere to the limitation and successfully complete your project. 47 Looking for project limitations Determining limitations is a fact-finding mission, so your job is to identify and examine all possible sources of information. You don’t want to miss anything, and you want to clarify any conflicting information. After you know what people expect, you can determine how (or whether) you can meet those expectations. Try the following approaches: ✓ Consult your audiences. Check with drivers about limitations regarding desired results; check with supporters about limitations concerning activity performance and resources. ✓ Review relevant written materials. These materials may include longrange plans, annual budgets and capital appropriations plans, benefitcost analyses, feasibility studies, reports of related projects, minutes of meetings, and individuals’ performance objectives. ✓ When you identify a limitation, be sure to note its source. Confirming a limitation from different sources increases your confidence in its accuracy. Resolve conflicting opinions about a limitation as soon as possible. Addressing limitations in your Scope Statement List all project limitations in your Scope Statement. If you have to explore ways to modify your project plan in the future, this list of limitations can help define alternatives that you can and cannot consider.
Slide 66: 48 Part I: Understanding Expectations (The Who, What, and Why of Your Project) You can reflect limitations in your project in two ways: ✓ Incorporate limitations directly into your plan. For example, if a key driver says you have to finish your project by September 30, you may choose to set September 30 as your project’s completion date. Of course, because September 30 is the outside limit, you may choose to set a completion date of August 31. In this case, the limitation influences your target completion date but isn’t equivalent to it. ✓ Identify any project risks that result from a limitation. For example, if you feel the target completion date is unusually aggressive, the risk of missing that date may be significant. You want to develop plans to minimize and manage that risk throughout your project. (See Chapter 8 for more information on how to assess and plan for risks and uncertainties.) Dealing with needs As soon as possible, decide on the situations or conditions necessary for your project’s success. Most of these needs relate to project resources. Here are a few examples of resource-related needs: ✓ Personnel: “I need a technical editor for a total of 40 hours in August.” ✓ Budget: “I need a budget of $10,000 for computer peripherals.” ✓ Other resources: “I need access to the test laboratory during June.” Be as clear as possible when describing your project’s needs. The more specific you are, the more likely other people are to understand and meet those needs. Sometimes you can identify needs very early in your project planning. More often, however, particular needs surface as you create a plan that addresses the drivers’ expectations. As your list of needs grows, check with your project’s supporters to decide how the new needs can be met and at what cost. Check with your project’s drivers to confirm that the estimated additional cost is justified, and modify your project documentation to reflect any changes in planned results, activities, schedules, or resources.
Slide 67: Chapter 2: Clarifying What You’re Trying to Accomplish — and Why 49 Facing the Unknowns When Planning As you proceed through your planning process, you can identify issues or questions that may affect your project’s performance. Unfortunately, just identifying these issues or questions doesn’t help you address them. For every potential issue you identify, make assumptions regarding unknowns associated with it. Then use these assumptions as you plan your project. Consider the following examples: ✓ Issue: You don’t have a final, approved budget for your project. Approach: Assume you’ll get $50,000 for your project. Plan for your project to spend up to, but no more than, $50,000. Develop detailed information to demonstrate why your project budget must be $50,000, and share that information with key decision makers. ✓ Issue: You don’t know when you’ll get authorization to start work on your project. Approach: Assume you’ll receive authorization to start work on August 1. Plan your project work so that no activities start before August 1. Explain to key decision makers why your project must start on August 1, and work with them to facilitate your project’s approval by that date. Note: Don’t forget to consider all project assumptions when you develop your project’s risk-management plan. See Chapter 8 for more info. Relating This Chapter to the PMP Exam and PMBOK 4 Table 2-2 notes topics in this chapter that may be addressed on the Project Management Professional (PMP) certification exam and that are also included in A Guide to the Project Management Body of Knowledge, 4th Edition (PMBOK 4).
Slide 68: 50 Part I: Understanding Expectations (The Who, What, and Why of Your Project) Table 2-2 Topic Contents of a Scope Statement (see the section “Defining Your Project with a Scope Statement”) Definition and examples of project audiences (see the section “Figuring Out Why You’re Doing the Project”) Chapter 2 Topics in Relation to the PMP Exam and PMBOK 4 Location in PMBOK 4 5.2.3.1. Project Scope Statement 5.1. Collect Requirements 2.3. Stakeholders Comments The Scope Statement contents addressed in this book agree with those stated in PMBOK 4. Project audiences are composed of drivers, supporters, and observers (see Chapter 3). Drivers and supporters together are called stakeholders. PMBOK 4 only considers stakeholders when discussing people to consider involving in your project. In addition to what this book covers, PMBOK 4 distinguishes between project requirements and product requirements. PMBOK 4 uses the term product acceptance criteria to encompass measures and specifications. The definition of a constraint in both books is the same. PMBOK 4 doesn’t specifically distinguish between limitations and needs. The definition of an assumption in both books is the same. Defining and determining project requirements (see the section “Determining your project drivers’ real expectations and needs”) Framing project objectives (see the section “Stating your project’s objectives”) Definition and examples of project constraints (see the section “Marking Boundaries: Project Constraints”) Definition and examples of project assumptions (see the section “Facing the Unknowns When Planning”) 5.1. Collect Requirements 5.1. Collect Requirements 1.3. What is Project Management? 6.4.1.5. Project Scope Statement 6.4.1.5. Project Scope Statement
Slide 69: Chapter 3 Knowing Your Project’s Audience: Involving the Right People In This Chapter ▶ Identifying your project’s diverse audiences and building an audience list ▶ Considering your drivers, supporters, and observers ▶ Determining who has authority in your project ▶ Prioritizing your audiences by their levels of power and interest O ften a project is like an iceberg: Nine-tenths of it lurks below the surface. You receive an assignment and you think you know what it entails and who needs to be involved. Then, as the project unfolds, new people emerge who may affect your goals and your approach to the project. You risk compromising your project in the following two ways when you don’t involve key people or groups in your project in a timely manner: ✓ First, you may miss important information that can affect the project’s performance and ultimate success. ✓ Second, and sometimes more painful, you may insult someone. And you can be sure that, when someone feels you have slighted or insulted him, he’ll take steps to make sure you don’t do it again! As soon as you begin to think about a new project, start to identify people who may play a role. This chapter shows you how to identify these candidates; how to decide whether, when, and how to involve them; and how to determine who has the authority, power, and interest to make critical decisions. Understanding Your Project’s Audiences A project audience is any person or group that supports, is affected by, or is interested in your project. Your project’s audiences can be inside or outside your organization, and knowing who they are helps you
Slide 70: 52 Part I: Understanding Expectations (The Who, What, and Why of Your Project) ✓ Plan whether, when, and how to involve them. ✓ Determine whether the scope of the project is bigger or smaller than you originally anticipated. You may hear other terms used in the business world to describe project audiences, but these terms address only some of the people from your complete project audience list. Here are some examples: ✓ A stakeholder list identifies people and groups who support or are affected by your project. The stakeholder list doesn’t usually include people who are merely interested in your project. ✓ A distribution list identifies people who receive copies of written project communications. These lists are often out-of-date for a couple of reasons. Some people remain on the list simply because no one removes them; other people are on the list because no one wants to run the risk of insulting them by removing them. In either case, having their names on this list doesn’t ensure that these people actually support, are affected by, or are interested in your project. ✓ Team members are people whom the project manager directs. All team members are stakeholders, and, as such, they’re part of the project audience, but the audience list includes more than just team members. Developing an Audience List As you identify the different audiences for your project, record them in an audience list. Check out the following sections for information on how to develop this list. Starting your audience list A project audience list is a living document. You need to start developing your list as soon as you begin thinking about your project. Write down any names that occur to you; when you discuss your project with other people, ask them who they think may be affected by or interested in your project. Then select a small group of the audiences you identify and conduct a formal brainstorming session. Continue to add and subtract names to your audience list until you can’t think of anyone else. In the following sections, I explain how to refine your audience list by using specific categories and recognizing important potential audiences; I wrap up with a sample to show you how to put your own list together.
Slide 71: Chapter 3: Knowing Your Project’s Audience: Involving the Right People Using specific categories To increase your chances of identifying all appropriate people, develop your audience list in categories. You’re less likely to overlook people when you consider them department by department or group by group instead of trying to identify everyone from the organization individually at the same time. Start your audience list by developing a hierarchical grouping of categories that covers the universe of people who may be affected by, needed to support, or interested in your project. I often start with the following groups: ✓ Internal: People and groups inside your organization • Upper management: Executive-level management responsible for the general oversight of all organization operations • Requesters: The person who came up with the idea for your project and all the people through whom the request passed before you received it • Project manager: The person with overall responsibility for successfully completing the project • End users: People who will use the goods or services the project will produce • Team members: People assigned to the project whose work the project manager directs • Groups normally involved: Groups typically involved in most projects in the organization, such as the human resources, finance, contracts, and legal departments • Groups needed just for this project: Groups or people with special knowledge related to this project ✓ External: People and groups outside your organization • Clients or customers: People or groups that buy or use your organization’s products or services • Collaborators: Groups or organizations with whom you may pursue joint ventures related to your project • Vendors, suppliers, and contractors: Organizations that provide personnel, raw materials, equipment, or other resources required to perform your project’s work • Regulators: Government agencies that establish regulations and guidelines that govern some aspect of your project work • Professional societies: Groups of professionals that may influence or be interested in your project • The public: The local, national, and international community of people who may be affected by or interested in your project 53
Slide 72: 54 Part I: Understanding Expectations (The Who, What, and Why of Your Project) Dealing with reality rather than ignoring it A number of years ago, I ran into a woman who had attended one of my project-management training sessions. She said she was using several of the techniques discussed in the course and found them to be very helpful. However, she also said that, after making a serious attempt to create an audience list, she found this tool to be impractical and of little value. She explained that her boss had assigned her a project that she had to finish in two months. She immediately developed an audience list, but, much to her horror, the list included more than 150 names! How, she wondered, was she supposed to involve more than 150 people in a two-month project? She concluded that the audience list was clearly of no help. In fact, her audience list had served its purpose perfectly. Identifying the people at the outset who would affect the success of her project gave her three options: ✓ She could plan how and when to involve each person during the project. ✓ She could assess the potential consequences of not involving one or more of her audiences. ✓ She could discuss extending the project deadline or reducing its scope with her boss if she felt she couldn’t ignore any of the audiences. The audience list itself doesn’t decide whom you should involve in your project. Instead, it specifies those people who may affect the success of your project so you can weigh the benefits and the costs of including or omitting them. Continue to subdivide these categories further until you arrive at position descriptions and the names of the people who occupy them. Considering audiences that are often overlooked As you develop your audience list, be sure not to overlook the following potential audiences: ✓ Support groups: These people don’t tell you what you should do; instead, they help you accomplish the project’s goals. If support groups know about your project early, they can fit you into their work schedules more readily. They can also tell you information about their capabilities and processes that may influence what your project can accomplish and by when you can do so. Such groups include • Facilities • Finance • Human resources • Information services • Legal services • Procurement or contracting
Slide 73: Chapter 3: Knowing Your Project’s Audience: Involving the Right People 55 Discovering the real end users A major international bank based in the United States had spent millions of dollars revising and upgrading its information system. Project personnel had worked closely with special liaisons in Europe who represented the interests of the local bank personnel who would actually be entering and retrieving data from the new system. When the bank introduced the upgraded system, they discovered a fatal problem: More than 90 percent of the local bank personnel in Europe were non-English speaking, but the system documentation was all written in English. The enhanced systems were unusable! The system designers had spent substantial time and money working with the liaisons to identify and address the interests and needs of the end users. However, the liaisons had raised only issues from their own experience instead of identifying and sharing the needs and concerns of the local bank personnel. Because English was the primary language of all the liaisons, they failed to consider the possible need to prepare system instructions in multiple languages. Putting the local bank personnel on the audience list along with the liaisons would’ve reminded the project personnel not to overlook their special needs. • Quality • Security • Project management office ✓ End users of your project’s products: People or groups who will use the goods and services your project produces. Involving end users at the beginning and throughout your project helps ensure that the goods and services produced are as easy as possible to implement and use and are most responsive to their true needs. It also confirms that you appreciate the fact that the people who will use a product may have important insights into what it should look like and do, which increases the chances that they will work to implement the products successfully. In some cases, you may omit end users on your audience list because you don’t know who they are. In other situations, you may think you have taken them into account through liaisons — people who represent the interests of the end users. (Check out the nearby sidebar “Discovering the real end users” for a costly example of what can happen when you depend solely on liaisons.) ✓ People who will maintain or support the final product: People who will service your project’s final products affect the continuing success of these products. Involving these people throughout your project gives them a chance to make your project’s products easier to maintain and support. It also allows them to become familiar with the products and effectively build their maintenance into existing procedures.
Slide 74: 56 Part I: Understanding Expectations (The Who, What, and Why of Your Project) Examining a sample audience list Suppose you’re asked to coordinate your organization’s annual blood drive. Table 3-1 illustrates some of the groups and people you may include in your project’s audience list as you prepare for your new project. Table 3-1 Category Internal Subcategory A Portion of an Audience List Audiences Executive oversight committee, vice president of sales and marketing, vice president of operations, vice president of administration Vice president of sales, manager of community relations Senior events coordinator Customer service representative, community relations representative, administrative assistant Finance, facilities, legal, and human resources departments Project manager and team from last year’s blood drive, public relations Prior donors, potential donors, hospitals and medical centers receiving the blood from the drive Attending nurses, food-service provider, facility’s landlord, local blood center Local board of health American Medical Association, American Association of Blood Banks Local community, local newspapers, local television and radio stations Upper management Requester Project manager Team members Groups normally involved Groups needed just for this project External Clients, customers Vendors, contractors Regulatory agencies Professional societies Public Ensuring your audience list is complete and up-to-date Many different groups of people may influence the success of or have an interest in your project. Knowing who these people are allows you to plan to involve them at the appropriate times during your project. Therefore,
Slide 75: Chapter 3: Knowing Your Project’s Audience: Involving the Right People identifying all project audiences as soon as possible and reflecting any changes in those audiences as soon as you find out about them are important steps to take as you manage your project. To ensure your audience list is complete and up-to-date, consider the following guidelines: ✓ Eventually identify each audience by position description and name. You may, for example, initially identify people from sales and marketing as an audience. Eventually, however, you want to specify the particular people from that group, such as brand manager for XYZ product, Sharon Wilson, and their contact information. ✓ Speak with a wide range of people. Check with people in different organizational units, from different disciplines, and with different tenures in the organization. Ask every person whether she can think of anyone else you should speak with. The more people you speak with, the less likely you are to overlook someone important. ✓ Allow sufficient time to develop your audience list. Start to develop your list as soon as you become project manager. The longer you think about your project, the more potential audiences you can identify. Throughout the project, continue to check with people to identify additional audiences. ✓ Include audiences who may play a role at any time during your project. Your only job at this stage is to identify names so you don’t forget them. At a later point, you can decide whether, when, and how to involve these people (see the “Considering the Drivers, Supporters, and Observers in Your Audience” section later in this chapter). ✓ Include team members’ functional managers. Include the people to whom the project manager and team members directly report. Even though functional managers usually don’t perform project tasks themselves, they can help ensure that the project manager and team members devote the time they originally promised to the project and that they have the resources necessary to perform their project assignments. ✓ Include a person’s name on the audience list for every role she plays. Suppose your boss plans to provide expert technical advice to your project team. Include your boss’s name twice — once as your direct supervisor and once as the technical expert. If your boss is promoted but continues to serve as a technical advisor to your project, the separate listings remind you that a new person now occupies your direct supervisor’s slot. ✓ Continue to add and remove names from your audience list throughout your project. Your audience list evolves as you understand more about your project and as your project changes. Plan to review your list at regular intervals throughout the project to identify names that should be added or deleted. Encourage people involved in your project to continually identify new audiences as they think of them. 57
Slide 76: 58 Part I: Understanding Expectations (The Who, What, and Why of Your Project) ✓ When in doubt, write down a person’s name. Your goal is to avoid overlooking someone who may play an important part in your project. Identifying a potential audience member doesn’t mean you have to involve that person; it simply means you have to consider her. Eliminating the name of someone who won’t be involved is a lot easier than trying to add the name of someone who should be. Using an audience list template An audience list template is a predesigned audience list that contains typical categories and audiences for a particular type of project. You may develop and maintain your own audience list templates for tasks you perform, functional groups may develop and maintain audience list templates for tasks they typically conduct, or your organization’s project management office may develop and maintain templates for the entire organization. Regardless of who maintains the template, it reflects people’s cumulative experiences. As the organization continues to perform projects of this type, audiences that were overlooked in earlier efforts may be added and audiences that proved unnecessary may be removed. Using these templates can save you time and improve your accuracy. Suppose you prepare the budget for your department each quarter. After doing a number of these budgets, you know most of the people who give you the necessary information, who draft and print the document, and who have to approve the final budget. Each time you finish another budget, you revise your audience list template to include new information from that project. The next time you prepare your quarterly budget, you begin your audience list with your template. You then add and subtract names as appropriate for that particular budget preparation. When using audience list templates, keep the following guidelines in mind: ✓ Develop templates for frequently performed tasks and for entire projects. Audience list templates for kicking off the annual blood drive or submitting a newly developed drug to the Food and Drug Administration are valuable. But so are templates for individual tasks that are part of these projects, such as awarding a competitive contract or printing a document. Many times projects that appear totally new contain some tasks that you’ve done before. You can still reap the benefits of your prior experience by including the audience list templates for these tasks in your overall project audience list. ✓ Focus on position descriptions rather than the names of prior audiences. Identify an audience as accounts payable manager rather than Bill Miller. People come and go, but functions endure. For each specific project, you can fill in the appropriate names.
Slide 77: Chapter 3: Knowing Your Project’s Audience: Involving the Right People ✓ Develop and modify your audience list template from previous projects that actually worked, not from initial plans that looked good but lacked key information. Often you develop a detailed audience list at the start of your project but don’t revise the list during the project or add audiences that you overlooked in your initial planning. If you only update your template with information from an initial list, your template can’t reflect the discoveries you made throughout the project. ✓ Encourage your team to brainstorm possible audiences before you show them an existing audience list template. Encouraging people to identify audiences without guidance or restrictions increases the chances that they’ll think of audiences that were overlooked on previous projects. ✓ Use templates as starting points, not ending points. Make clear to your team that the template isn’t the final list. Every project differs in some ways from similar ones. If you don’t critically examine the template, you may miss people who weren’t involved in previous projects but whom you need to consider for this one. ✓ Reflect your different project experiences in your audience list templates. The post-project evaluation is an excellent time to review, critique, and modify your audience list for a particular project (see Chapter 15 for details on the post-project evaluation). Templates can save time and improve accuracy. However, starting with a template that’s too polished can suggest you’ve already made up your mind about the contents of your final list, which may discourage people from freely sharing their thoughts about other potential audiences. In addition, their lack of involvement in the development of the project’s audience list may lead to their lack of commitment to the project’s success. 59 Considering the Drivers, Supporters, and Observers in Your Audience After identifying everyone in your project audience, it’s time to determine which of the following groups they fall into. Then you can decide whether to involve them and, if so, how and when. ✓ Drivers: People who have some say in defining the results of your project. You’re performing your project for these people. ✓ Supporters: The people who help you perform your project. Supporters include individuals who authorize or provide the resources for your project, as well as those who actually work on it.
Slide 78: 60 Part I: Understanding Expectations (The Who, What, and Why of Your Project) Including a project champion A project champion is a person in a high position in the organization who strongly supports your project; advocates for your project in disputes, planning meetings, and review sessions; and takes whatever actions are necessary to help ensure the successful completion of your project. As soon as you start planning, find out whether your project has a champion. If it doesn’t, try to recruit one. An effective project champion has the following characteristics: ✓ Sufficient power and authority to resolve conflicts over resources, schedules, and technical issues ✓ A keen interest in the results of your project ✓ A willingness to have his or her name cited as a strong supporter of your project ✓ Observers: People who are neither drivers nor supporters, but who are interested in the activities and results of your project. Observers have no say in your project, and they’re not actively involved in it. However, your project may affect them at some point in the future. Separating audiences into these three categories helps you decide what information to seek from them and what to share with them, as well as to clarify the project decisions in which to involve them. Suppose an information technology group has the job of modifying the layout and content of a monthly sales report for all sales representatives. The vice president of sales requested the project, and the chief information officer (CIO — the boss of the head of the information technology group) approved it. As the project manager for this project, consider categorizing your project’s audiences as follows: ✓ Drivers: The vice president of sales is a driver because he has specific reasons for revising the report. The CIO is a potential driver because she may hope to develop certain new capabilities for her group through this project. Individual sales representatives are all drivers for this project because they’ll use the redesigned report to support their work. ✓ Supporters: The systems analyst who designs the revised report, the training specialist who trains the users, and the vice president of finance who authorizes the funds for changing the manual are all supporters. ✓ Observers: The head of the customer service department is a potential observer because he hopes your project will lead to an improved problem-tracking system this year.
Slide 79: Chapter 3: Knowing Your Project’s Audience: Involving the Right People Beware of supporters who try to act like drivers. In the preceding example, the analyst who finalizes the content and format of the report may try to include certain items that she thinks are helpful. However, only the real drivers should determine the specific data that go into the report. The analyst just determines whether it’s possible to include the desired data and what doing so will cost. Keep in mind that one person can be both a driver and a supporter. For example, the vice president of sales is a driver for the project to develop a revised monthly sales report, but he’s also a supporter if he has to transfer funds from the sales department budget to pay for developing the report. The following sections help you identify when you need to involve drivers, supporters, and observers, and the best ways to keep them involved. 61 Deciding when to involve your audiences Projects pass through the following four stages as they progress from an idea to completion (see Chapter 1 for detailed explanations of these stages): ✓ Starting the project ✓ Organizing and preparing ✓ Carrying out the work ✓ Closing the project Plan to involve drivers, supporters, and observers in each stage of your project’s life cycle. The following sections tell you how you can do so. Drivers Involve drivers from the start to the finish of your project. Keeping them involved is critical because they define what your project should produce, and they evaluate your project’s success when it’s finished. Check out Table 3-2 to see how to keep drivers involved during the four stages of your project. Table 3-2 Stage Starting the project Involving Drivers in the Different Project Stages Involvement Level Heavy Rationale Identify and speak with as many drivers as possible. Their desires and your assessment of feasibility can influence whether you should pursue the project. If you uncover additional drivers later, explore with them the issues that led to the project; ask them to identify and assess any special expectations they may have. (continued)
Slide 80: 62 Part I: Understanding Expectations (The Who, What, and Why of Your Project) Table 3-2 (continued) Stage Involvement Level Rationale Organizing and preparing Moderate to heavy Consult with drivers to ensure your project plan addresses their needs and expectations. Have them formally approve the plan before you start the actual project work. As the project gets under way, announce and introduce the drivers to the project team. Having the drivers talk about their needs and interests reinforces the importance of the project and helps team members form a more accurate picture of project goals. Also, having the drivers meet team members increases the drivers’ confidence that the members can successfully complete the project. While performing the project work, keep drivers apprised of project accomplishments and progress to sustain their ongoing interest and enthusiasm. Involving drivers in this way also allows you to confirm that the results are meeting their needs. Carrying out the work Moderate Closing the project Heavy Have drivers assess the project’s results and determine whether their needs and expectations were met. Identify their recommendations for improving performance on similar projects in the future. Supporters Just as with drivers, involve supporters from start to finish. Because they perform and support the project work, they need to know about changing requirements so they can promptly identify and address problems. Keeping them actively involved also sustains their ongoing motivation and commitment to the project. Check out Table 3-3 to see how to keep supporters involved during your project’s four stages. Table 3-3 Stage Starting the project Involving Supporters in the Different Project Stages Involvement Level Moderate Rationale Wherever possible, have key supporters assess the feasibility of meeting driver expectations. If you identify key supporters later in the project, have them confirm the feasibility of previously set expectations.
Slide 81: Chapter 3: Knowing Your Project’s Audience: Involving the Right People Stage Organizing and preparing Involvement Level Heavy Rationale Supporters are the major contributors to the project plan. Because they facilitate or do all the work, have them determine necessary technical approaches, schedules, and resources. Also have them formally commit to all aspects of the plan. Familiarize all supporters with the planned work. Clarify how the supporters will work together to achieve the results. Have supporters decide how they’ll communicate, resolve conflicts, and make decisions throughout the project. Throughout the project, keep supporters informed of project progress, encourage them to identify performance problems they encounter or anticipate, and work with them to develop and implement solutions to these problems. Closing the project Heavy Have supporters conclude their different tasks. Inform them of project accomplishments and recognize their roles in project achievements. Elicit their suggestions for handling similar projects more effectively in the future. 63 Carrying out the work Heavy Observers After you choose the observers with whom you want to actively share project information, involve them minimally throughout the project because they neither tell you what should be done nor help you do it. Table 3-4 shows how you may keep observers involved. Because observers don’t directly influence or affect your project, be sure to carefully manage the time and effort you spend sharing information with them. When deciding whom to involve and how to share information with them, consider the following: ✓ Their level of interest in your project ✓ The likelihood that your project will affect them at some point in the future ✓ The need to maintain a good working relationship with them See the section “Assessing Your Audience’s Power and Interest” later in this chapter for information on what to consider when deciding how to involve different audiences.
Slide 82: 64 Part I: Understanding Expectations (The Who, What, and Why of Your Project) Table 3-4 Stage Starting the project Organizing and preparing Carrying out the work Closing the project Involving Observers in the Different Project Stages Involvement Level Minimal Minimal Minimal Rationale Inform observers of your project’s existence and its main goals. Inform observers about the project’s planned outcomes and time frames. Tell observers that the project has started, and confirm the dates for planned milestones. Inform observers of key project achievements. When the project is done, inform observers about the project’s products and results. Minimal Using different methods to keep your audiences involved Keeping drivers, supporters, and observers informed as you progress in your project is critical to the project’s success. Choosing the right method for involving each audience group can stimulate that group’s continued interest and encourage its members to actively support your work. Consider the following approaches for keeping your project audiences involved throughout your project: ✓ One-on-one meetings: One-on-one meetings (formal or informal discussions with one or two other people about project issues) are particularly useful for interactively exploring and clarifying special issues of interest with a small number of people. ✓ Group meetings: These meetings are planned sessions for some or all team members or audiences. Smaller meetings are useful to brainstorm project issues, reinforce team member roles, and develop mutual trust and respect among team members. Larger meetings are useful to present information of general interest. ✓ Informal written correspondence: Informal written correspondence (notes, memos, letters, and e-mails) helps you document informal discussions and share important project information. ✓ More formal information-sharing vehicles: Information resources, such as project newsletters or sites on the organization’s intranet, may be useful for sharing nonconfidential and noncontroversial information with larger audiences.
Slide 83: Chapter 3: Knowing Your Project’s Audience: Involving the Right People ✓ Written approvals: Written approvals (such as a technical approach to project work or formal agreements about a product, schedule, or resource commitment) serve as records of project decisions and achievements. See Chapter 13 for additional information on sharing information about your project’s ongoing performance. 65 Making the most of your audience’s involvement To maximize your audiences’ involvement and contributions, consider the following guidelines throughout your project: ✓ Involve audiences early in the project planning if they have a role later on. Give your audiences the option to participate in planning even if they don’t perform until later in the project. Sometimes they can share information that’ll make their tasks easier. At the least, they can reserve time to provide their services when you need them. ✓ If you’re concerned with the legality of involving a specific audience, check with your legal department or contracts office. Suppose you’re planning to award a competitive contract to buy certain equipment. You want to know whether prospective bidders typically have this equipment on hand and how long it’ll take to receive it after you award the contract. However, you’re concerned that speaking to potential contractors in the planning stage may tip them off about the procurement and lead to charges of favoritism by unsuccessful bidders who didn’t know about the procurement in advance. Instead of ignoring this important audience, check with your contracts office or legal department to determine how you can get the information you want and still maintain the integrity of the bidding process. ✓ Develop a plan with all key audiences to meet their information needs and interests as well as yours. Determine the information they want and the information you believe they need. Also decide when to provide that information and in what format. Finally, clarify what you want from them and how and when they can provide it. ✓ Always be sure you understand each audience’s What’s In It For Me (WIIFM). Clarify why it’s in each audience’s interest to see your project succeed. Throughout your project, keep reminding your audiences of the benefits they’ll realize when your project’s complete and the progress your project has made toward achieving those benefits. Find out more about identifying project benefits for different audiences in Chapter 14.
Slide 84: 66 Part I: Understanding Expectations (The Who, What, and Why of Your Project) Confirming Your Audience’s Authority In project terms, authority refers to the overall right to make project decisions that others must follow, including the right to apply project resources, expend funds, or give approvals. Having opinions about how an aspect should be addressed is different from having the authority to decide how it will be addressed. Mistaking a person’s level of authority can lead to frustration, as well as wasted time and money. Confirm that the people you’ve identified as audiences have the authority to make the decisions they need to make to perform their tasks. If they don’t have that authority, find out who does and how to bring those people into the process. At the beginning of the carrying out the work stage in your projects, take the following steps to define each audience member’s authority: 1. Clarify each audience member’s tasks and decisions. Define with each person his tasks and his role in those tasks. For example, will he just work on the task, or will he also approve the schedules, resource expenditures, and work approaches? 2. Ask each audience member what his authority is regarding each decision and task. Ask about individual tasks rather than all issues in a particular area. For example, a person can be more confident about his authority to approve supply purchases up to $5,000 than about his authority to approve all equipment purchases, no matter the type or amount. Clarify decisions that the audience member can make himself. For decisions needing someone else’s approval, find out whose approval he needs. (Ask, never assume!) 3. Ask each audience member how he knows what authority he has. Does a written policy, procedure, or guideline confirm the authority? Did the person’s boss tell him in conversation? Is the person just assuming? If the person has no specific confirming information, encourage him to get it. 4. Check out each audience member’s history of exercising authority. Have you or other people worked with this person in the past? Has he been overruled on decisions that he said he was authorized to make? If so, ask him why he believes he won’t be similarly overruled this time. 5. Verify whether anything has recently changed regarding each audience member’s authority.
Slide 85: Chapter 3: Knowing Your Project’s Audience: Involving the Right People Is there any reason to believe that this person’s authority has changed? Is the person new to his current group? To his current position? Has the person recently started working for a new boss? If any of these situations exists, encourage the person to find specific documentation to confirm his authority for his benefit as well as yours. Reconfirm the information in these steps when a particular audience’s decision-making assignments change. Suppose, for example, that you initially expect all individual purchases on your project to be at or under $2,500. Bill, the team representative from the finance group, assures you that he has the authority to approve such purchases for your project without checking with his boss. Midway through the project, you find that you have to purchase a piece of equipment for $5,000. Be sure to verify with Bill that he can personally authorize this larger expenditure. If he can’t, find out whose approval you need and plan how to get it. 67 Assessing Your Audience’s Power and Interest An audience’s potential impact on a project depends on the power it has to exercise and the interest it has in exercising that power. Assessing the relative levels of each helps you decide with whom you should spend your time and effort to realize the greatest benefits. Power is a person’s ability to influence the actions of others. This ability can derive either from the direct authority the person has to require people to respond to her requests (ascribed power; see the previous section and Chapter 10 for more about authority) or the ability she has to induce others to do what she asks because of the respect they have for her professionally or their affinity for her as a person (achieved power). (See Chapter 14 for more information.) In either case, the more power a person has, the better able she is to marshal people and resources to support your project. On the other hand, a person’s interest in something is how much she cares or is curious about it or how much she pays attention to it. The more interested a person is in your project, the more likely she is to want to use her power to help the project succeed. You can define an audience’s relative levels of power and interest related to your project as being either high or low. You then have four possible combinations for each audience’s relative levels of power and interest. The particular values of an audience’s power and interest ratings suggest the chances that the audience may have a significant impact on your project and, therefore, the relative importance of keeping that audience interested and involved in your project.
Slide 86: 68 Part I: Understanding Expectations (The Who, What, and Why of Your Project) Most often you base the assessments of an audience’s power over and interest in your project on the aggregated individual, subjective opinions of you, your team members, members of your project’s other audiences, people who have worked with the audience on other projects, subject matter experts, and/or members of the audience themselves. If you assign a value of 1 to each individual rating of high and 0 to each individual rating of low, you’d rate an audience’s power or interest as high if the resulting average of the individual assessments were 0.5 or greater and low if it were below 0.5. Typically, drivers and supporters have higher levels of power over your project than observers. Figure 3-1 depicts a Power-Interest Grid, which represents these four possible power-interest combinations as distinct quadrants on a two-dimensional graph. As the project manager, you should spend a minimal amount of time and effort with audiences who have low levels of both power and interest (Quadrant I), increasingly greater amounts of time and effort with audiences that have a low level of power and a high level of interest (Quadrant II) and a low level of interest and a high level of power (Quadrant III), respectively. You should spend the most time and effort keeping audiences with high degrees of both power and interest (Quadrant IV) informed and involved. (Check out Chapter 13 for different ways to communicate with your project’s audiences.) High Figure 3-1: Involving Power audiences with differLow ent levels of power and interest in your project. III. Keep satisfied IV. Manage closely I. Minimum effort Low II. Keep informed High Interest Relating This Chapter to the PMP Exam and PMBOK 4 Table 3-5 notes topics in this chapter that may be addressed on the Project Management Professional (PMP) certification exam and that are also included in A Guide to the Project Management Body of Knowledge, 4th Edition (PMBOK 4).
Slide 87: Chapter 3: Knowing Your Project’s Audience: Involving the Right People 69 Table 3-5 Topic Definition of project audience (see the section “Understanding Your Project’s Audiences”) Chapter 3 Topics in Relation to the PMP Exam and PMBOK 4 Location in PMBOK 4 2.3. Stakeholders 10.1. Identify Stakeholders Comments Project drivers and supporters are the project stakeholders. PMBOK 4 addresses stakeholders only when discussing people to consider involving in your project. PMBOK 4 discusses how to develop a stakeholder register rather than an audience list. Developing an audience list (see the section “Developing an Audience List”) Examples of project audiences (see the section “Developing an Audience List”) Classifying audiences as drivers, supporters, or observers (see the section “Considering the Drivers, Supporters, and Observers in Your Audience”) Keeping audiences involved (see the section “Considering the Drivers, Supporters, and Observers in Your Audience”) 3.3.2. Identify Stakeholders 10.1.3.1. Stakeholder Register 2.3. Stakeholders 10.1. Identify Stakeholders 2.3. Stakeholders The examples of stakeholders (drivers and supporters in this book) are similar. PMBOK 4 considers drivers and supporters (although it doesn’t refer to them by those names) only when discussing people who may affect your project. The two discussions of how and when to involve stakeholders address similar approaches and alternatives. 2.3. Stakeholders 10.3. Distribute Information 10.4. Manage Stakeholder Expectations 10.1.2.1.Stakeholder Analysis Conducting a stakeholder analysis (see the section “Assessing Your Audience’s Power and Interest”) The two discussions of why and how to conduct a stakeholder analysis address similar points.
Slide 88: 70 Part I: Understanding Expectations (The Who, What, and Why of Your Project)
Slide 89: Chapter 4 Developing Your Game Plan: Getting from Here to There In This Chapter ▶ Dividing your work into manageable pieces ▶ Developing and displaying a Work Breakdown Structure ▶ Dealing with unknown circumstances and documenting what you need to know he keys to successful project planning and performance are completeness and continuity. You want to identify all important information in your project plan and address all aspects of your plan during project performance. Describing in detail all the work required to complete your project helps you accomplish these tasks. Your description of project work provides the basis for scheduling and resource planning, defining roles and responsibilities, assigning work to team members, capturing key project performance data, and reporting on completed project work. This chapter helps you break down your project work into manageable pieces. T Divide and Conquer: Working on Your Project in Manageable Chunks Two of my major concerns when I start a new project are remembering to plan for all important pieces of work and accurately estimating the time and resources required to perform that work. To address both issues, I develop a logical framework to define all work that’s necessary to complete the project. A while back, a friend who loves jigsaw puzzles told me about an acquaintance who had asked him to assemble a 5,000-piece puzzle of the United States. When his acquaintance suggested that, before he start, he determine whether any pieces were missing and, if so, which ones, my friend laughed.
Slide 90: 72 Part I: Understanding Expectations (The Who, What, and Why of Your Project) He always found out this information by trying to assemble the puzzle and noting any holes that remained after he’d used all the available pieces. How else could he do it? You’ve probably had a similar puzzle-like experience with your project assignments. Suppose you’re asked to design and present a training program. You and a colleague work intensely for a couple of months developing the content and materials, arranging for the facilities, and inviting the participants. A week before the session, you ask your colleague whether he’s made arrangements to print the training manuals. He says that he thought you were dealing with it, and you say that you thought he was dealing with it. Unfortunately, neither of you arranged to have the manuals printed because you each thought the other person was handling it. Now you have a training session in a week, and you don’t have the time or money to print the needed training notebooks. How can you avoid situations like this one in the future? By using a structured approach in the organizing and preparing stage of your project to identify all required project work. The following sections explain how to accomplish this task by subdividing project intermediate and final products into finer levels of detail and specifying the work required to produce them. Thinking in detail The most important guideline to remember when identifying and describing project work is this: Think in detail! In my experience, people consistently underestimate the time and resources they need for their project work because they just don’t recognize everything they have to do to complete it. Suppose you have to prepare a report of your team’s most recent meeting. Based on your past experience with preparing many similar reports, you quickly figure it’ll take a few days to do this one. But how confident are you that this estimate is correct? Are you sure you’ve considered all the different work that writing this particular report will entail? Will the differences between this report and others you’ve worked on mean more time and more work for you? How can you tell? The best way to determine how long and how much work a project will take to complete is to break down the required project work into its component deliverables, a process called decomposition. (A deliverable is an intermediate or final product, service, and/or result your project will produce. See Chapter 2 for more information on project deliverables, or objectives as they’re often called.) The greater the detail in which you decompose a project, the less likely you are to overlook anything significant. For example, creating the report in the preceding illustration actually entails producing three separate deliverables: a draft, reviews of the draft, and the final version. Completing the final version of the report, in turn, entails producing two deliverables: the
Slide 91: Chapter 4: Developing Your Game Plan: Getting from Here to There handwritten version and the printed version. By decomposing the project into the deliverables necessary to generate the final report, you’re more likely to identify all the work you need to do to complete the project. Observe the following two guidelines when decomposing your project: ✓ Allow no gaps: Identify all components of the deliverable you’re decomposing. In the example of creating a meeting report, if you have allowed no gaps, you’ll have the desired final product in hand after you’ve produced the draft, the reviews of the draft, and the final version. However, if you feel that you’ll have to do additional work to transform these three subproducts into a final product, you need to define the subproduct(s) that this additional work will produce. ✓ Allow no overlaps: Don’t include the same subproduct in your decomposition of two or more different deliverables. For example, don’t include completed reviews of the draft by your boss and the vice president of your department as parts of the draft (the first deliverable) if you’ve already included them with all other reviews under reviews of the draft (the second deliverable). The first guideline — allow no gaps — is also referred to as the 100% rule. This rule states that the components of a project include 100% of the work and all the deliverables required by the project scope and do not include any work or deliverables that fall outside of the project scope. This rule applies at all levels within the hierarchy. Specifying the parts and subparts of your project in this way decreases the chance that you’ll overlook something significant, which will help you develop more accurate estimates of the time and resources needed to do the project. 73 Thinking of hierarchy with the help of a Work Breakdown Structure Thinking in detail is critical when you’re planning your project, but you also need to consider the big picture. If you fail to identify a major part of your project’s work, you won’t have the chance to detail it! Thus, you must be both comprehensive and specific. My friend’s jigsaw puzzle dilemma (refer to this section’s intro) suggests an approach that can help you achieve your goal. He can count the pieces before assembling the puzzle to determine whether any piece is missing. However, knowing that he has only 4,999 pieces can’t help him determine which piece is missing. He needs to divide the 5,000 pieces into smaller groups that he can examine and understand. Consider that he divides the puzzle of the United States into 50 separate 100-piece puzzles, one for each of the 50 states. Because he knows the United States has 50 states, he’s confident that each piece of the puzzle should be in one and only one box.
Slide 92: 74 Part I: Understanding Expectations (The Who, What, and Why of Your Project) Suppose he takes it a step further and divides each state into four quadrants each comprised of 25 pieces. Again, he can count the pieces in each box to see whether any are missing. However, determining which one of 25 pieces is missing from the northeast sector of New Jersey is easier than figuring out which piece is missing from the 5,000-piece puzzle of the entire United States. Figure 4-1 shows how you can depict necessary project work in a Work Breakdown Structure (WBS), a deliverable-oriented, hierarchical decomposition of the work required to achieve a project’s objectives and produce the required project products. The different WBS levels have had many different names. The top element is typically called a project and the lowest level of detail is typically called a work package. However, the levels in between have been called phases, subprojects, work assignments, tasks, subtasks, and deliverables. In this book, the top-level box (the Level 1 component) is a project, the lowest-level of detail is a work package, and the elements in between are Level 2 components, Level 3 components, and so forth. A work package is comprised of activities that must be performed to produce the deliverable it represents. Specifically, Figure 4-1 shows that the entire project, represented as a Level 1 component, can be subdivided into Level 2 components, and some or all Level 2 components can be subdivided into Level 3 components. You can continue to subdivide all the components you create in the same manner until you reach a point at which you think the components you defined are sufficiently detailed for planning and management purposes. These Level “n” components, where n is the number of the lowest-level component in a particular WBS branch, are called work packages. Level 1 Level 2 Level 3 Level “n” Figure 4-1: Developing a Work Breakdown Structure. Project Components Components Work packages Suppose you’re responsible for creating and presenting a new training program for your organization. To get started, you’d develop a WBS for this project as follows: 1. Determine the major deliverables or products to be produced. Ask yourself, “What major intermediate or final products or deliverables must be produced to achieve the project’s objectives?”
Slide 93: Chapter 4: Developing Your Game Plan: Getting from Here to There You may identify the following items: • Training program needs statement • Training program design • Participant notebooks • Trained instructor • Program testing • Training program presentation 2. Divide each of these major deliverables into its component deliverables in the same manner. Choose any one of these deliverables to begin with. Suppose you choose Training program needs statement. Ask, “What intermediate deliverables must I have so I can create the needs statement?” You may determine that you require the following: • Interviews of potential participants • A review of materials discussing the needs for the program • A report summarizing the needs this program will address 3. Divide each of these work pieces into its component parts. Suppose you choose to start with Interviews of potential participants. Ask, “What deliverables must I have to complete these interviews?” You may decide that you have to produce the following deliverables: • Selected interviewees • Interview questionnaire • Interview schedule • Completed interviews • Report of interview findings But why stop here? You can break each of these five items into finer detail and then break those pieces into even finer detail. How far should you go? The following sections can help you answer that question. 75 Asking four key questions Determining how much detail you need isn’t a trivial task. You want to describe your work in sufficient detail to support accurate planning and meaningful tracking. But the benefits of this detail must justify the additional time you spend developing and maintaining your plans and reporting your progress. Asking the following four questions about each WBS component can help you decide whether you’ve defined it in enough detail:
Slide 94: 76 Part I: Understanding Expectations (The Who, What, and Why of Your Project) ✓ Do you require two or more intermediate deliverables to produce this deliverable? ✓ Can you accurately estimate the resources you’ll need to perform the work to produce this deliverable? (Resources include personnel, equipment, raw materials, money, facilities, information, and so on.) ✓ Can you accurately estimate how long it will take to produce this deliverable? ✓ If you have to assign the work to produce this deliverable to someone else, are you confident that person will understand exactly what to do? If you answer yes to the first question or no to any one of the other three, break down the deliverable into the components necessary to produce it. Your answers to these questions depend on how familiar you are with the work, how critical the activity is to the success of your project, what happens if something goes wrong, whom you may assign to perform the activity, how well you know that person, and so on. In other words, the correct level of detail for your WBS depends on your judgment. If you’re a little uneasy about answering these four questions, try this even simpler test: Subdivide your WBS component into additional deliverables if you think either of the following situations applies: ✓ The component will take much longer than two calendar weeks to complete. ✓ The component will require much more than 80 person-hours to complete. Remember that these estimates are just guidelines. For example, if you estimate it’ll take two weeks and two days to prepare a report — you’ve probably provided sufficient detail. But if you figure it’ll take two to three months to finalize requirements for your new product, you need to break the deliverable finalized requirements into more detail because ✓ Experience has shown that there can be so many different interpretations of what is supposed to occur during these two to three months that you can’t be sure your time and resource estimates are correct, and you can’t confidently assign the task to someone to perform. ✓ You don’t want to wait two or three months to confirm that work is on schedule by verifying that a desired product has been produced on time. Making assumptions to clarify planned work Sometimes you haven’t defined the work in sufficient detail, but certain unknowns stop you from defining it further. How do you resolve this dilemma? You make assumptions regarding the unknowns. If, during the course of your project, you find that any of your assumptions are wrong, you can change your plan to reflect the correct information.
Slide 95: Chapter 4: Developing Your Game Plan: Getting from Here to There For example, suppose you decide that the Completed interviews deliverable from Step 3 in the example to develop and present a new training program introduced earlier in this section needs more detail so you can estimate its required time and resources. However, you don’t know how to break it down further because you don’t know how many people you’ll interview or how many separate sets of interviews you’ll conduct. If you assume you’ll interview five groups of seven people each, you can then develop specific plans for arranging and conducting each of these sessions. In most situations, it’s best to consider a guess in the middle of the possible range. To determine how sensitive your results are to the different values, you may want to analyze several different assumptions. Be sure to write your assumption down so you remember to change your plan if you conduct more or less than five interview sessions. See the discussion in Chapter 2 for more information about detailing assumptions. 77 Using action verbs to describe activities Use action verbs when framing the titles of the activities that comprise a work package to clarify the nature of the work they entail. Action verbs can improve your time and resource estimates, your work assignments to team members, and your tracking and reporting because they provide a clear picture of what an activity entails. Consider the assignment to prepare a report after a team meeting. Suppose you choose Draft Report to be one of its work packages. If you don’t break down Draft Report further, you haven’t indicated clearly whether it includes any or all of the following actions: ✓ Collecting information for the draft ✓ Determining length and format expectations and restrictions ✓ Handwriting the draft ✓ Reviewing the draft yourself before officially circulating it to others But, if you simply word the work package Design and handwrite the draft report — voilà! Your scope of work is instantly clearer. A few well-chosen words at this level go a long way. Using a WBS for large and small projects You need to develop a WBS for very large projects, very small projects, and everything in between. Building a skyscraper, designing a new airplane, researching and developing a new drug, and revamping your organization’s information systems all need a WBS. So, too, do writing a report, scheduling and conducting a meeting, coordinating your organization’s annual blood drive, and moving into your new office. The size of the WBS may vary immensely depending on the project, but the hierarchical scheme used to develop each one is the same.
Slide 96: 78 Part I: Understanding Expectations (The Who, What, and Why of Your Project) Conducting a survey: Using the Work Breakdown Structure Suppose your boss asks you to estimate how long it’ll take to survey people regarding the characteristics a new product your company may develop should have. Based on your experience with doing similar types of assessments in the past, you figure you’ll need to contact people at the company headquarters, at two regional activity centers, and from a sampling of current clients. You tell your boss the project will take you between one and six months to complete. Have you ever noticed that bosses aren’t happy when you respond to their question of “How long will it take?” with an answer of “Between one and six months”? You figure that finishing anytime before six months meets your promise, but your boss expects you can be done in one month, given some (okay, a lot of) hard work. The truth is, though, you don’t have a clue how long the survey will take because you have no idea how much work you’ll have to do to complete it. Developing a WBS encourages you to define exactly what you have to do and, correspondingly, improves your estimate of how long each step will take. In this example, you decide to conduct three different surveys: personal interviews with people at your headquarters, phone conference calls with people at the two regional activity centers, and a mail survey of a sample of your company’s clients. Realizing you need to describe each survey in more detail, you begin by considering the mail survey and decide it includes five deliverables: ✓ A sample of clients to survey: You figure you need one week to select your sample of clients if the sales department has a current record of all company clients. You check with that department, and, thankfully, it does. ✓ A survey questionnaire: As far as this deliverable is concerned, you get lucky. A colleague tells you she thinks that the company conducted a similar survey of a different target population a year ago and that extra questionnaires from that effort may still be around. You find that a local warehouse has 1,000 of these questionnaires and —yes! — they’re perfect for your survey. How much time do you need to allow for designing and printing the questionnaires? Zero! ✓ Survey responses: You determine you’ll need a response rate of at least 70 percent for the results to be valid. You consult with people who’ve done these types of surveys before and find out that, to have an acceptable chance of achieving a minimum response rate of 70 percent, you have to use the following three-phased approach: 1. Initial mailing out and receiving of questionnaires (estimated time = four weeks) 2. Second mailing out and receiving of questionnaires to nonrespondents (estimated time = four weeks) 3. Phone follow-ups with people who still haven’t responded, encouraging them to complete and return their surveys (estimated time = two weeks) ✓ Data analyses: You figure you’ll need about two weeks to enter and analyze the data you expect to receive. ✓ A final report: You estimate it’ll take two weeks to prepare the final report.
Slide 97: Chapter 4: Developing Your Game Plan: Getting from Here to There 79 Now, instead of one to six months, you can estimate the time you need to complete your mail survey to be 15 weeks. Because you’ve clarified the work you have to do and how you’ll do it, you’re more confident you can reach your goal, and you’ve increased the chances that you will! Note: To develop the most accurate estimates of your project’s duration, in addition to the nature of the work you do, you need to consider the types and amounts of resources you require, together with their capacities and availabilities (see Chapter 5 for more on how to estimate durations). However, this example illustrates that using just a WBS to refine the definition of your project’s work components significantly improves your estimates. Occasionally your detailed WBS may seem to make your project more complex than it really is. I agree that 100 tasks (not to mention 10,000) written out can be a little unnerving! However, the WBS doesn’t create a project’s complexity; the WBS just displays it. In fact, by clearly portraying all aspects of your project work, the WBS actually simplifies your project. Check out the sidebar “Conducting a survey: Using the Work Breakdown Structure” for an illustration of how a WBS helps you develop a more accurate estimate of the time you need to complete your work. Dealing with special situations With a little bit of thought, you can break most WBS elements into components. However, this section looks a little more closely at several special situations that require some creativity. Representing conditionally repeating work Suppose your project contains a deliverable that requires an unknown number of repetitive cycles to produce, such as getting a report approved. In reality, you write the report and submit it for review and approval. If the reviewers approve the report, you proceed to the next phase of your project (such as distributing the report). But if the reviewers don’t approve the report, you have to revise it to incorporate their comments and then resubmit it for a second review and approval. If they approve the second draft, you proceed to the next phase of your project. But if they still don’t approve that draft, you have to repeat the process (or try to catch them in a better mood). Revising the draft is conditional work; it will only be done if a certain condition (in the report example, not receiving the reviewers’ approval) comes to pass. Unfortunately, a WBS doesn’t include conditional work — you plan to perform every piece of work you detail in your WBS. However, you can represent conditional work in the following two ways:
Slide 98: 80 Part I: Understanding Expectations (The Who, What, and Why of Your Project) ✓ You can define a single deliverable as Approved report and assign it a duration. In effect, you’re saying that you can create as many Reviewed but not approved versions of the report as necessary (each of which is an intermediate deliverable) to obtain the final reviewed and approved version within the established time period. ✓ You can assume that you’ll need a certain number of revisions and include the intermediate deliverable created after each one (a different Reviewed but not approved version of the report) in your WBS. This approach allows more meaningful tracking. Whichever approach you choose, be sure to document it in your project plan. Assuming that your project needs three reviews and two revisions doesn’t guarantee that your draft will be good to go only after the third review. If your draft is approved after the first review, congratulations! You can move on to the next piece of work immediately (that is, you don’t perform two revisions just because the plan assumed you would have to!). However, if you still haven’t received approval after the third review, you continue to revise it and submit it for further review until you do get the seal of approval you need. Of course, then you have to reexamine your plan to determine the impact of the additional reviews and revisions on the schedule and budget of future project activities. A plan isn’t a guarantee of the future; it’s your statement of what you’ll work to achieve. If you’re unable to accomplish any part of your plan, you must revise it accordingly (and promptly). Handling work with no obvious break points Sometimes you can’t see how to break a piece of work into two-week intervals. Other times that detail just doesn’t seem necessary. Even in these situations, however, you want to divide the work into smaller chunks to remind yourself to periodically verify that your current schedule and resource estimates are still valid. Check out the sidebar “Keeping a close eye on your project” for an illustration of why it’s important to have frequent milestones to support project tracking and how to deal with WBS components that have no obvious break points. No matter how carefully you plan, something unanticipated can always occur. The sooner you find out about such an occurrence, the more time you have to minimize any negative impact on your project.
Slide 99: Chapter 4: Developing Your Game Plan: Getting from Here to There 81 Keeping a close eye on your project A number of years back, I met a young engineer at one of my training sessions. Soon after he joined his organization, he was asked to design and build a piece of equipment for a client. He submitted a purchase request to his procurement department for the raw materials he needed and was told that, if they didn’t arrive by the promised delivery date in six months, he should notify the procurement specialist he was working with so she could investigate the situation. He was uneasy about waiting six months without checking periodically to see whether everything was still on schedule, but being young, inexperienced, and new to the organization, he wasn’t comfortable trying to fight this established procedure. So he waited six months. When he didn’t receive his raw materials by the promised delivery date, he notified the procurement specialist, who, in turn, checked with the vendor. It turned out that there had been a major fire in the vendor’s facilities five months earlier and that production had just resumed the previous week. The vendor estimated his materials would be shipped in about five months! I suggested that he could’ve divided the waiting time into one-month intervals and called the vendor at the end of each month to see whether anything had occurred that changed the projected delivery date. Although checking periodically wouldn’t have prevented the fire, he would’ve known about it five months sooner and could’ve made other plans immediately. (See Chapter 8 for more information on how to deal with risk and uncertainty in your projects.) Planning a long-term project A long-term project presents an entirely different challenge. Often the work you perform a year or more in the future depends on the results of the work you do between now and then. Even if you can accurately predict the work you’ll perform later, the farther into the future you plan, the more likely it is that something will change and require you to modify your plans. When developing a WBS for a long-term project, use a rolling-wave approach, in which you continually refine your plans throughout the life of your project as you discover more about the project and its environment. This approach acknowledges that uncertainties may limit your plan’s initial detail and accuracy, and it encourages you to reflect more accurate information in your plans as soon as you discover it. Apply the rolling-wave approach to your long-term project by taking the following steps: 1. Break down the first three months’ work into components that take two weeks or less to complete. 2. Plan the remainder of the project in less detail, perhaps describing the work in packages you estimate to take between one and two months to complete.
Slide 100: 82 Part I: Understanding Expectations (The Who, What, and Why of Your Project) 3. Revise your initial plan at the end of the first three months to detail your work for the next three months in components that take two weeks or less to complete. 4. Modify any future work as necessary, based on the results of your first three months’ work. 5. Continue revising your plan in this way throughout the project. Creating and Displaying Your Work Breakdown Structure You can use several different schemes to develop and display your project’s WBS, and each one can be effective under different circumstances. This section looks at a few of those different schemes and provides some examples and advice on how and when to apply them. Considering different schemes for organizing your WBS You can use many different schemes to subdivide project work into WBS components; the following are five possible ones with examples of each: ✓ Product components: Floor plan, training manuals, or screen design ✓ Functions: Design, launch, review, or test ✓ Project phases: Initiation, design, or construction ✓ Geographical areas: Region 1 or the northwest ✓ Organizational units: Marketing, operations, or facilities Project phases, product components, and functions are the most often used. When you choose a scheme to organize the subelements of a WBS component, continue to use that same scheme to define all subelements under that WBS component to prevent possible overlap in categories. For example, consider that you want to develop finer detail for the WBS component titled Report. You may choose to break out the detail according to function, such as Draft report, Reviews of draft report, and Final report. Or you may choose to break it out by product component, such as Section 1, Section 2, and Section 3.
Slide 101: Chapter 4: Developing Your Game Plan: Getting from Here to There Don’t define Report’s subelements by using some items from both schemes, such as Section 1, Section 2, Reviews of draft report, and Final report. Combining schemes in this way increases the chances of either including work twice or overlooking it completely. For example, the work to prepare the final version of Section 2 could be included in either of two subelements: Section 2 or Final report. Consider the following questions when choosing a scheme: ✓ What higher-level milestones will be most meaningful when reporting progress? For example, is it more helpful to report that Section 1 is completed or that the entire Draft report is done? ✓ How will you assign responsibility? For example, is one person responsible for the draft, reviews, and final report of Section 1, or is one person responsible for the drafts of Sections 1, 2, and 3? ✓ How will you and your team members actually do the work? For example, is the drafting, reviewing, and finalizing of Section 1 separate from the same activities for Section 2, or are all chapters drafted together, reviewed together, and finalized together? 83 Using different approaches to develop your WBS How you develop your WBS depends on how familiar you and your team are with your project, whether similar projects have been successfully performed in the past, and how many new methods and approaches you’ll use. Choose one of the following two approaches for developing your WBS depending on your project’s characteristics: ✓ Top-down: Start at the top level in the hierarchy and systematically break WBS elements into their component parts. This approach is useful when you have a good idea of the project work involved before the actual work begins. The top-down approach ensures that you thoroughly consider each category at each level, and it reduces the chances that you overlook work in any of your categories. ✓ Brainstorming: Generate all possible work and deliverables for this project and then group them into categories. Brainstorming is helpful when you don’t have a clear sense of a project’s required work at the outset. This approach encourages you to generate any and all possible pieces of work that may have to be done, without worrying about how to organize them in the final WBS. After you decide that a proposed piece of work is a necessary part of the project, you can identify any related work that is also required.
Slide 102: 84 Part I: Understanding Expectations (The Who, What, and Why of Your Project) Whichever approach you decide to use, consider using stick-on notes to support your WBS development. As you identify pieces of work, write them on the notes and put them on the wall. Add, remove, and regroup the notes as you continue to think through your work. This approach encourages open sharing of ideas and helps all people appreciate — in detail — the nature of the work that needs to be done. The top-down approach Use the following top-down approach for projects that you or others are familiar with: 1. Specify all Level 2 components for the entire project. 2. Determine all necessary Level 3 components for each Level 2 component. 3. Specify the Level 4 components for each Level 3 component as necessary. 4. Continue in this way until you’ve detailed all project deliverables and work components completely. The lowest-level components in each WBS chain are your project’s work packages. The brainstorming approach Use the following brainstorming approach for projects involving untested methods or for projects you and your team members aren’t familiar with: 1. Write down all deliverables and components of work that you think your project entails. Don’t worry about overlap or level of detail. Don’t discuss wording or other details of the work items. Don’t make any judgments about the appropriateness of the work. 2. Group these items into a few major categories with common characteristics and eliminate any deliverables or work components that aren’t required. These groups are your Level 2 categories. 3. Divide the deliverables and work components under each Level 2 category into groups with common characteristics. These groups are your Level 3 categories. 4. Now use the top-down method to identify any additional deliverables or work components that you overlooked in the categories you created. 5. Continue in this manner until you’ve described all project deliverables and work components completely. The lowest-level components in each WBS chain are your project’s work packages.
Slide 103: Chapter 4: Developing Your Game Plan: Getting from Here to There 85 Considering different ways to categorize your project’s work Although you eventually want to use only one WBS for your project, early in the development of your WBS, you can look at two or more different hierarchical schemes. Considering your project from two or more perspectives helps you identify work you may have overlooked. Suppose a local community wants to open a halfway house for substance abusers. Figures 4-2 and 4-3 depict two different schemes to categorize the work for this community-based treatment facility. The first scheme classifies the work by product component, and the second classifies the work by function: ✓ Figure 4-2 defines the following components as Level 2 categories: staff, facility, residents (people who’ll be living at the facility and receiving services), and community training. ✓ Figure 4-3 defines the following functions as Level 2 categories: planning, recruiting, buying, and training. Figure 4-2: A product component scheme for a WBS for preparing to open a communitybased treatment facility. Community-Based Treatment Facility Staff Director Other staff Staff Staff training Facility Facility requirements Facility Facility supplies Residents Criteria for residents Residents Residents’ supplies Community training Figure 4-3: A functional scheme for a WBS for preparing to open a communitybased treatment facility. Community-Based Treatment Facility Planning Facility requirements Criteria for residents Recruiting Director Staff Residents Buying Facility supplies Residents’ supplies Facility Training Staff training Community training
Slide 104: 86 Part I: Understanding Expectations (The Who, What, and Why of Your Project) Both WBSs contain the same lowest-level components or work packages. When you think about your project in terms of major functions (rather than final product components), you realize that you forgot the following work: ✓ Planning for staff recruiting ✓ Buying staff supplies ✓ Planning for your community training After you identify the work components you overlooked, you can include them in either of the two WBSs. Be sure you choose only one WBS before you leave your project’s planning phase. Nothing confuses people faster than trying to use two or more different WBSs to describe the same project. Labeling your WBS entries As the size of a project grows, its WBS becomes increasingly complex. Losing sight of how a particular piece of work relates to other parts of the project is easy to do. Unfortunately, this problem can lead to poor coordination between related work efforts and a lack of urgency on the part of people who must perform the work. Figure 4-4 illustrates a scheme for labeling your WBS components so you can easily see their relationships with each other and their relative positions in the overall project WBS: ✓ The first digit (1), the Level 1 identifier, indicates the project in which the item is located. ✓ The second digit (5) indicates the Level 2 component of the project in which the item is located. ✓ The third digit (7) refers to the Level 3 component under the Level 2 component 1.5. in which the item is located. Figure 4-4: A useful scheme for identifying your WBS components. 1.5.7.3. Order Materials Level 4 (Work package) Level 3 Level 2 Level 1 (Project)
Slide 105: Chapter 4: Developing Your Game Plan: Getting from Here to There ✓ The fourth and last digit (3) is a unique identifier assigned to distinguish this item from the other Level 4 components under the Level 3 component 1.5.7. If 1.5.7.3. Order Materials isn’t subdivided further, it’s a work package. 87 Displaying your WBS in different formats You can display your WBS in several different formats. This section looks at three of the most common ones. The organization-chart format Figure 4-5 shows a WBS in the organization-chart format (also referred to as a hierarchy diagram or graphical view). This format effectively portrays an overview of your project and the hierarchical relationships of different categories at the highest levels. However, because this format generally requires a lot of space, it’s less effective for displaying large WBSs. 1. Report Figure 4-5: Drawing your WBS in the organization-chart format. 1.1. Draft report 1.2. Review of draft report 1.3. Final report 1.3.1. Handwriten final report 1.3.2. Printed final report The indented-outline format The indented-outline format in Figure 4-6 is another way to display your WBS. This format allows you to read and understand a complex WBS with many components. However, you can easily get lost in the details of a large project with this format and forget how the different pieces all fit together. Both the organization-chart format and the indented-outline format can be helpful for displaying the WBS for a small project. For a large project, however, consider using a combination of the organization-chart and the indentedoutline formats to explain your WBS. You can display the Level 1 and Level 2 components in the organization-chart format and portray the detailed breakout for each Level 2 component in the indented-outline format.
Slide 106: 88 Part I: Understanding Expectations (The Who, What, and Why of Your Project) 1. Report 1.1. Draft report Figure 4-6: Depicting your WBS in the indentedoutline format. 1.2. Reviews of draft report 1.3. Final report 1.3.1. Handwritten final report 1.3.2. Printed final report The bubble-chart format The bubble-chart format in Figure 4-7 is particularly effective for supporting brainstorming to develop your WBS for both small and large projects. You interpret the bubble-chart format as follows: ✓ The bubble in the center represents your entire project (in this case, Report). ✓ Lines from the center bubble lead to Level 2 breakouts (in this case, Draft report, Reviews of draft, and Final report). ✓ Lines from each Level 2 component lead to Level 3 components related to the Level 2 component. (In this case, the Level 2 element Final report consists of the two Level 3 elements Handwritten final report and Printed final report.) 1.2. Reviews of draft 1. Report 1.3.2. Printed final report Figure 4-7: Drawing your WBS in the bubblechart format. 1.3. Final report 1.1. Draft report 1.3.1. Handwritten final report
Slide 107: Chapter 4: Developing Your Game Plan: Getting from Here to There The freeform nature of the bubble-chart format makes it effective for easily recording thoughts generated during a brainstorming session. You can also easily rearrange components as you proceed with your analysis. The bubble-chart format isn’t effective for displaying your WBS to audiences who aren’t familiar with your project. Use this format to develop your WBS with your team, but transpose it into an organization-chart or indented-outline format when you present it to people outside your team. 89 Improving the quality of your WBS You increase the chances for project success when your WBS is accurate and complete and when people who will be performing the work understand and agree with it. The following guidelines suggest some ways to improve your WBS’s accuracy and acceptance: ✓ Involve the people who’ll be doing the work. When possible, involve them during the initial development of the WBS. If they join the project after the initial planning, have them review and critique the WBS before they begin work. ✓ Review and include information from WBSs from similar projects. Review plans and consult people who’ve worked on projects similar to yours that were successful. Incorporate your findings into your WBS. ✓ Keep your WBS current. When you add, delete, or change WBS elements during your project, be sure to reflect these changes in your WBS. (See “Documenting What You Need to Know about Your Planned Project Work” later in this chapter for more about sharing the updated WBS with the team.) ✓ Make assumptions regarding uncertain activities. If you’re not sure whether you’ll do a particular activity, make an assumption and prepare your WBS based on that assumption. Be sure to document that assumption. If your assumption proves to be wrong during the project, change your plan to reflect the true situation. (See the sections “Making assumptions to clarify planned work” and “Representing conditionally repeating work” for more about assumptions.) ✓ Remember that your WBS identifies only your project’s deliverables; it doesn’t depict their chronological order. Nothing is wrong with including activities from left to right or top to bottom in the approximate order that you’ll perform them. However, in complex projects, you may have difficulty showing detailed interrelationships among activities in the WBS format. The purpose of the WBS is to ensure that you identify all project deliverables. Check out Chapter 5 for more on developing your project schedule.
Slide 108: 90 Part I: Understanding Expectations (The Who, What, and Why of Your Project) Using templates A WBS template is an existing WBS that contains deliverables typical for a particular type of project. This template reflects people’s cumulative experience from performing many projects of the same type. As people perform more projects, they add deliverables to the template that were overlooked and remove deliverables that weren’t needed. Using templates can save you time and improve your accuracy. Although templates can save time and improve accuracy, don’t inhibit people’s active involvement in the development of the WBS by using a template that’s too polished. Lack of people’s involvement can lead to missed activities and lack of commitment to project success. This section looks at how you can develop a WBS template and improve its accuracy and completeness. Drawing on previous experience By drawing on previous experience, you can prepare your WBS in less time than it takes to develop a whole new WBS and be more confident that you’ve included all essential pieces of work. Suppose you prepare your department’s quarterly budget. After doing a number of these budgets, you know most of the work you have to perform. Each time you finish another budget, you revise your WBS template to include new information you gleaned from the recently completed project. The next time you start to plan a quarterly budget–preparation project, begin with the WBS template you’ve developed from your past projects. Then add and subtract elements as appropriate for this particular budget preparation. Improving your WBS templates The more accurate and complete your WBS templates are, the more time they can save on future projects. This section offers several suggestions for continually improving the quality of your WBS templates. When using templates, keep the following in mind: ✓ Develop templates for frequently performed tasks as well as for entire projects. Templates for the annual organization blood drive or the submission of a newly developed drug to the Food and Drug Administration are valuable. So are templates for individual tasks that are part of these projects, such as awarding a competitive contract or having a document printed. You can always incorporate templates for individual pieces of work into a larger WBS for an entire project.
Slide 109: Chapter 4: Developing Your Game Plan: Getting from Here to There ✓ Develop and modify your WBS template from previous projects that worked, not from initial plans that looked good. Often you develop a detailed WBS at the start of your project, but you may forget to add intermediate or final deliverables that you overlooked in your initial planning. If you update your template from a WBS that you prepared at the start of your project, it won’t reflect what you discovered during the actual performance of the project. ✓ Use templates as starting points, not ending points. Make it clear to your team members and others involved in the project that the template is only the start for your WBS, not the final version. Every project differs in some ways from similar ones performed in the past. If you don’t critically examine the template, you may miss work that wasn’t done in previous projects but that needs to be done in this one. ✓ Continually update your templates to reflect your experiences from different projects. The post-project evaluation is a great opportunity to review and critique your original WBS. (See Chapter 15 for information on how to plan and conduct this evaluation.) At the end of your project, take a moment to revise your WBS template to reflect what you found. 91 Identifying Risks While Detailing Your Work In addition to helping you identify work you need to complete, a WBS helps you identify unknowns that may cause problems when you attempt to perform that work. As you think through the work you have to do to complete your project, you often identify considerations that may affect how or whether you can perform particular project activities. Sometimes you have the information you need to assess and address a consideration and sometimes you don’t. Identifying and dealing effectively with information you need but don’t have can dramatically increase your chances for project success. Unknown information falls into one of two categories: ✓ A known unknown: Information you know you need that someone else has but you don’t. ✓ An unknown unknown: Information you know you need that neither you nor anyone else has because it doesn’t yet exist. You deal with known unknowns by finding out who has the information you need and then getting it. You deal with unknown unknowns by using one or more of the following strategies:
Slide 110: 92 Part I: Understanding Expectations (The Who, What, and Why of Your Project) ✓ Buying insurance to minimize damage that occurs if something doesn’t turn out the way you expected ✓ Developing contingency plans to follow if something doesn’t turn out the way you expected ✓ Trying to influence what the information eventually turns out to be In the project Conducting a survey discussed in the “Conducting a survey: Using the Work Breakdown Structure” sidebar earlier in this chapter, you figure you’ll need a week to select a sample of clients to survey if the sales department has a current data tape listing all the company’s clients. At this point, whether the data tape exists is a known unknown — it’s unknown to you, but, if it exists, someone else knows about it. You deal with this unknown by calling people to find someone who knows whether such a data tape does or does not exist. You experience a different situation when you become aware that twice in the past month computer operators at your company accidentally destroyed a data tape when they spilled coffee on it as they were preparing to mount it on a tape drive. As part of your current project (Conducting a survey), you need to have a computer operator mount a tape on a tape drive. Not surprisingly, you’re now concerned that the operator may spill coffee on your tape and destroy it, too. Whether or not the operator will spill coffee on your tape is an unknown unknown when you prepare the WBS for your project plan. You can’t determine beforehand whether the operator will spill coffee on your tape because it’s an unintended, unplanned act (at least you hope so!). Because you can’t find out for certain whether or not this occurrence will happen, you can consider taking one or more of the following approaches to address this risk: ✓ Develop a contingency plan. For example, in addition to developing a scheme for the computerized selection of names directly from the data tape, have the statistician who guides the selection of the sample develop a scheme for selecting names randomly by hand from the hard copy of the data tape. ✓ Take steps to reduce the likelihood that coffee is spilled on your data tape. For example, on the morning that your data tape is to be run, check beforehand for open cups of coffee in the computer room. Of course, if you feel the chances the operator will spill coffee on your data tape are sufficiently small, you can always choose to do nothing beforehand and just deal with the situation if and when it actually occurs.
Slide 111: Chapter 4: Developing Your Game Plan: Getting from Here to There Developing the WBS helps you identify a situation that may compromise your project’s success. You then must decide how to deal with that situation. See Chapter 8 for more detailed information on how to identify and manage project risks and uncertainties. 93 Documenting What You Need to Know about Your Planned Project Work After preparing your project WBS, take some time to gather essential information about all work packages (lowest-level WBS components), and keep it in a WBS dictionary that’s available to all project team members. You and your team will use this information to develop the remaining parts of your plan, as well as to support the tracking, controlling, and replanning of activities during the project. The project manager (or her designee) should approve all changes to information in this dictionary. At a minimum, the WBS dictionary contains but isn’t limited to the following information for all WBS components: ✓ WBS component title and WBS identification code: Descriptors that uniquely identify the WBS component ✓ Activities included: List of all the activities that must be performed to create the deliverable identified in the work package ✓ Work detail: Narrative description of work processes and procedures ✓ Schedule milestones: Significant events in the component’s schedule ✓ Quality requirements: Desired characteristics of the deliverables produced in the WBS component ✓ Acceptance criteria: Criteria that must be met before project deliverables are accepted ✓ Required resources: People, funds, equipment, facilities, raw materials, information, and so on that these activities need For larger projects, you maintain the WBS — including all its components from Level 1 down to and including the work packages — together in the same hierarchical representation, and you keep all the activities that comprise the work packages in an activity list and/or the WBS dictionary. Separating the WBS components in this way helps you more easily see and understand the important interrelationships and aspects of the project deliverables and work. On smaller projects, however, you may combine the deliverable-oriented WBS components and the activities that comprise each work package in the same hierarchical display.
Slide 112: 94 Part I: Understanding Expectations (The Who, What, and Why of Your Project) Relating This Chapter to the PMP Exam and PMBOK 4 Table 4-1 notes topics in this chapter that may be addressed on the Project Management Professional (PMP) certification exam and that are also included in A Guide to the Project Management Body of Knowledge, 4th Edition (PMBOK 4). Table 4-1 Topic Chapter 4 Topics in Relation to the PMP Exam and PMBOK 4 Location in PMBOK 4 5.3. Create WBS Comments The definitions of WBS used by the two sources are equivalent. Both sources mention the same techniques and approaches. Definition of a WBS (see the section “Divide and Conquer: Working on Your Project in Manageable Chunks”) Creating your WBS (see the sections “Using different approaches to develop your WBS,” “Considering different ways to categorize your project’s work,” “Labeling your WBS entries,” “Improving the quality of your WBS,” and “Using templates”) Different WBS display formats (see the section “Displaying your WBS in different formats”) WBS dictionary (see the section “Documenting What You Need to Know about Your Planned Project Work”) 5.3.2.1. Decomposition 5.3.2.1. Decomposition 5.3.3.2. WBS Dictionary Both sources address the same display formats. The definitions of the WBS dictionary used by the two sources are equivalent.
Slide 113: Part II Planning Time: Determining When and How Much
Slide 114: ou have the greatest chance of achieving project success when you have a plan that meets your client’s needs and that you believe is possible to accomplish. In this part, I show you how to develop a feasible and responsive initial project schedule and how to respond when you need to complete your project earlier than planned. I discuss how to estimate the people, funds, and other resources you need to perform the project work. And last, but definitely not least, I discuss how you can identify and deal with potential project risks. Y In this part . . .
Slide 115: Chapter 5 You Want This Project Done When? In This Chapter ▶ Creating a network diagram for your project ▶ Using your network diagram to determine schedule possibilities ▶ Forming your project’s initial schedule ▶ Estimating activity durations and presenting your project’s schedule roject assignments always have deadlines. So even though you’re not sure what your new project is supposed to accomplish, you want to know when it has to be finished. Unfortunately, when you find out the desired end date, your immediate reaction is often one of panic: “But I don’t have enough time!” The truth is, when you first receive your project assignment, you usually have no idea how long it’ll take to complete. Initial reactions tend to be based more on fear and anxiety than on facts, especially when you’re trying to juggle multiple responsibilities and the project sounds complex. To help you develop a more realistic estimate of how long your project will take, you need an organized approach that clarifies how you plan to perform your project’s activities, what schedules are possible, and how you’ll meet deadlines that initially appear unrealistic. This chapter describes a technique that helps you proactively develop an achievable schedule (while keeping your anxiety in check). The discussion in this chapter on using network diagrams to develop project schedules is the most technically detailed presentation in this book. Even though the technique takes about ten minutes to master, the explanations and illustrations can appear overwhelming at first glance. If this is your first contact with flowcharts, I suggest you initially scan this chapter for the main points and then read the different sections several times. The more you read the text, the more logical the explanations become. However, if you get frustrated with the technical details, put the book away and come back to it later. You’ll be surprised how much clearer the details are the second or third time around! P
Slide 116: 98 Part II: Planning Time: Determining When and How Much Picture This: Illustrating a Work Plan with a Network Diagram To determine the amount of time you need for any project, you have to determine the following two pieces of information: ✓ Sequence: The order in which you perform the activities ✓ Duration: How long each individual activity takes For example, suppose you have a project consisting of ten activities, each of which takes one week to complete. How long will it take you to complete your project? The truth is, you can’t tell. You may finish the project in one week if you can perform all ten activities at the same time and have the resources to do so. You may take ten weeks if you have to do the activities one at a time in sequential order. Or you may take between one and ten weeks if you have to do some, but not all, activities in sequence. To develop a schedule for a small project, you can probably consider the durations and sequential interdependencies in your head. But projects with 15 to 20 activities or more — many of which you can perform at the same time — require an organized method to guide your analysis. This section helps you develop feasible schedules by showing you how to draw network diagrams and then how to choose the best one for your project. Defining a network diagram’s elements A network diagram is a flowchart that illustrates the order in which you perform project activities. It’s your project’s test laboratory — it gives you a chance to try out different strategies before performing the work. No matter how complex your project is, its network diagram has the following three elements: milestones, activities, and durations. Milestone A milestone, sometimes called an event, is a significant occurrence in the life of a project. Milestones take no time and consume no resources; they occur instantaneously. Think of them as signposts that signify a point in your trip to project completion. Milestones mark the start or end of one or more activities. Examples of milestones are draft report approved and design begun.
Slide 117: Chapter 5: You Want This Project Done When? Activity An activity is a component of work performed during the course of a project. Activities take time and consume resources; you describe them using action verbs. Examples of activities are design report and conduct survey. Make sure you define activities and milestones clearly. The more clearly you define them, the more accurately you can estimate the time and resources needed to perform them, the more easily you can assign them to someone else, and the more meaningful your reporting of schedule progress becomes. 99 Duration Duration is the total number of work periods it takes to complete an activity. The amount of work effort required to complete the activity, people’s availability, and whether people can work on the activity at the same time all affect the activity’s duration. Capacity of nonpersonnel resources (for example, a computer’s processing speed and the pages per minute that a copier can print) and availability of those resources also affect duration. In addition, delay can add to an activity’s duration. For example, if your boss spends one hour reading your memo after it sat in her inbox for four days and seven hours, the activity’s duration is five days, even though your boss spends only one hour reading it. Understanding the basis of a duration estimate helps you figure out ways to reduce it. For example, suppose you estimate that testing a software package requires that it run for 24 hours on a computer. If you can use the computer only 6 hours in any one day, the duration for your software test is four days. Doubling the number of people working on the test won’t reduce the duration to two days, but getting approval to use the computer for 12 hours a day will. The units of time describe two related, but different, activity characteristics. Duration is the number of work periods required to perform an activity; work effort is the amount of time a person needs to work full time on the activity to complete it. (See Chapter 6 for more details on work effort.) For example, suppose 4 people had to work together full time for 5 days to complete an activity. The activity’s duration is 5 days. The work effort is 20 person-days (4 people multiplied by 5 days). Drawing a network diagram Determining your project’s end date requires you to choose the dates that each project activity starts and ends and the dates that each milestone is reached. You can determine these dates with the help of a network diagram. The activity-on-node technique (also called activity-in-box or precedence diagramming method) for drawing a network diagram uses the following three symbols to describe the diagram’s three elements:
Slide 118: 100 Part II: Planning Time: Determining When and How Much ✓ Boxes: Boxes represent activities and milestones. If the duration is 0, it’s a milestone; if it’s greater than 0, it’s an activity. Note that milestone boxes are sometimes highlighted with lines that are bold, double, or otherwise more noticeable. ✓ Letter t: The letter t represents duration. ✓ Arrows: Arrows represent the direction work flows from one activity or milestone to the next. Upon completion of an activity or reaching of a milestone, you can proceed either to a milestone or directly to another activity as indicated by the arrow(s) leaving that activity or milestone. Figure 5-1 presents a simple example of an activity-on-node network diagram. When you reach Milestone A (the box on the left), you can perform Activity 1 (the box in the middle), which you estimated will take two weeks to complete. Upon completing Activity 1, you reach Milestone B (the box on the right). The arrows indicate the direction of workflow. Figure 5-1: The three symbols in an activityon-node network diagram, with t representing duration. Milestone A tA = 0 Activity 1 t1 = 2 weeks Milestone B tB = 0 Duration Those of you who have worked with network diagrams in the past may have seen them drawn in another format called activity-on-arrow, also called the classical approach, an arrow diagram, or a PERT chart (see the section “Improving activity duration estimates” later in this chapter for an explanation of PERT analysis). This format represents milestones with circles and activities with arrows. However, because the activity-on-node technique is the one most used today, I draw all network diagrams in this book in this format. Analyzing a Network Diagram Think of your project as a trip you and several friends are planning to take. Each of you has a car and will travel a different route to the final destination. During the trip, two or more of your routes will cross at certain places. You agree that all people who pass through a common point must arrive at that
Slide 119: Chapter 5: You Want This Project Done When? point before anyone can proceed on the next leg of the journey. The trip is over when all of you reach the final destination. You certainly don’t want to undertake a trip this complex without planning it out on a road map. After all, planning your trip allows you to ✓ Determine how long the entire trip will take. ✓ Identify potential difficulties along the way. ✓ Consider alternate routes to get to your final destination more quickly. This section helps you plan your project schedule by telling you how to read and interpret a road map (your network diagram) so you can determine the likely consequences of your possible approaches. 101 Reading a network diagram Use the following two rules as you draw and interpret your network diagram. After you understand these rules, analyzing the diagram is a snap: ✓ Rule 1: After you finish an activity or reach a milestone, you can proceed to the next activity or milestone, as indicated by the arrow(s). ✓ Rule 2: Before you can start an activity or reach a milestone, you must first complete all activities and reach all milestones with arrows pointing to the activity you want to start or milestone you want to reach. Figure 5-2 illustrates a network diagram. According to Rule 1, from Start, you can proceed to work on either Activity 1 or 3, which means you can do either Activity 1 or Activity 3 by itself or both Activities 1 and 3 at the same time. In other words, these two activities are independent of each other. You may also choose to do neither of the activities. Rule 1 is an allowing relationship, not a forcing relationship. In other words, you can work on any of the activities that the arrows from Start lead to, but you don’t have to work on any of them. For example, suppose a part of your plan includes two activities to build a device: receive parts and assemble parts. As soon as you receive the parts, you can start to assemble them; in fact, you can’t start to assemble them until you receive them. But after you receive all the parts you ordered, neither rule says you must start to assemble them immediately; you can assemble them if you want to, or you can wait. Of course, if you wait, the completion of the assembly will be delayed. But that’s your choice. According to Rule 2, you can start working on Activity 2 in Figure 5-2 as soon as you complete Activity 1 because the arrow from Activity 1 is the only one leading to Activity 2. Rule 2, therefore, is a forcing (or requiring) relationship. If
Slide 120: 102 Part II: Planning Time: Determining When and How Much arrows from three activities led to Activity 2, you’d have to complete all three activities before starting Activity 2. (The diagram doesn’t indicate that you can start working on Activity 2 by completing only one or two of the three activities that lead to it.) Activity 1 t1 = 5 Activity 2 t2 = 1 Start t=0 End t=0 Activity 3 Activity 4 t4 = 3 Activity 5 t5 = 2 Figure 5-2: Example of a network diagram. t3 = 1 Critical path (in bold) = 7 weeks All times are in weeks Interpreting a network diagram You can use your network diagram to figure out when to start and end activities and when you’ll finish the entire project if you perform the activities in this way. To find out the schedule that your approach will allow, you need the following information: ✓ Critical path: A sequence of activities that takes the longest time to complete ✓ Noncritical path: A sequence of activities in which you can delay activities and still finish your project in the shortest possible time ✓ Slack time (also called float): The maximum amount of time you can delay an activity and still finish your project in the shortest possible time ✓ Earliest start date: The earliest date you can start an activity ✓ Earliest finish date: The earliest date you can finish an activity ✓ Latest start date: The latest date you can start an activity and still finish your project in the shortest possible time ✓ Latest finish date: The latest date you can finish an activity and still finish your project in the shortest possible time You can use the Critical Path Method (CPM) to determine this information and to build your project’s overall schedule. The following sections illustrate how this method works.
Slide 121: Chapter 5: You Want This Project Done When? The importance of the critical path The length of your project’s critical path(s) in your network diagram defines your project’s length (hence, the Critical Path Method for determining your project’s schedule). If you want to finish your project in less time, consider ways to shorten its critical path. Monitor critical-path activities closely during performance because any delay in critical-path activities will delay your project’s completion. Also closely monitor any activities on paths that are close to being critical because any minor delay on those paths can also delay your project’s completion. Your project can have two or more critical paths at the same time. In fact, every path in your project can be critical if every one of them takes the same amount of time. However, when every path is critical, you have a high-risk situation; a delay in any activity immediately causes a delay in the completion of the project. Critical paths can change as your project unfolds. Sometimes activities on a critical path finish so early that the path becomes shorter than one or more other paths that were initially considered noncritical. Other times, activities on an initially noncritical path are delayed to the point where the sum of their completion times becomes greater than the length of the current critical path (which turns the initially noncritical path into a critical one). 103 The forward pass — determining critical paths, noncritical paths, and earliest start and finish dates Your first step in analyzing your project’s network diagram is to start at the beginning and see how quickly you can complete the activities along each path. This start-to-finish analysis is called the forward pass. To help you understand what a forward pass is, you can perform one through the diagram in Figure 5-2. According to Rule 1, you can consider working on either Activity 1 or Activity 3 (or both together) as soon as the project starts (check out the section “Reading a network diagram” earlier in this chapter for more info on the two rules of network diagram analysis). First, consider Activities 1 and 2 on the upper path: ✓ The earliest you can start Activity 1 is the moment the project starts (the beginning of week 1). ✓ The earliest you can finish Activity 1 is the end of week 5 (add Activity 1’s estimated duration of five weeks to its earliest start time, which is the start of the project). ✓ According to Rule 2, the earliest you can start Activity 2 is the beginning of week 6 because the arrow from Activity 1 is the only one leading to Activity 2. ✓ The earliest you can finish Activity 2 is the end of week 6 (add Activity 2’s estimated duration of one week to its earliest start time at the beginning of week 6).
Slide 122: 104 Part II: Planning Time: Determining When and How Much So far, so good. Now consider Activities 3, 4, and 5 on the lower path of the diagram: ✓ The earliest you can start Activity 3 is the moment the project starts (the beginning of week 1). ✓ The earliest you can finish Activity 3 is the end of week 1. ✓ The earliest you can start Activity 4 is the beginning of week 2. ✓ The earliest you can finish Activity 4 is the end of week 4. You have to be careful when you try to determine the earliest you can start Activity 5. According to Rule 2, the two arrows entering Activity 5 indicate you must finish both Activity 1 and Activity 4 before you begin Activity 5. Even though you can finish Activity 4 by the end of week 4, you can’t finish Activity 1 until the end of week 5. Therefore, the earliest you can start Activity 5 is the beginning of week 6. If two or more activities or milestones lead to the same activity, the earliest you can start that activity is the latest of the earliest finish dates for those preceding activities or milestones. Is your head spinning, yet? Take heart; the end’s in sight: ✓ The earliest you can start Activity 5 is the beginning of week 6. ✓ The earliest you can finish Activity 5 is the end of week 7. ✓ The earliest you can finish Activity 2 is the end of week 6. Therefore, the earliest you can finish the entire project (and reach the milestone called End) is the end of week 7. So far, you have the following information about your project: ✓ The length of the critical path (the shortest time in which you can complete the project) is seven weeks. Only one critical path takes seven weeks; it includes the milestone Start, Activity 1, Activity 5, and the milestone End. ✓ Activity 2, Activity 3, and Activity 4 aren’t on critical paths. The backward pass — determining latest start and finish dates and slack times You’re halfway home. In case resource conflicts or unexpected delays prevent you from beginning all the project activities at their earliest possible start times, you want to know how much you can delay the activities along each path and still finish the project at the earliest possible date. This finishto-start analysis is called the backward pass.
Slide 123: Chapter 5: You Want This Project Done When? To return to the example started in the preceding section: You found out from the forward pass that the earliest date you can reach the milestone End is the end of week 7. However, Rule 2 in the earlier section “Reading a network diagram” says you can’t reach the milestone End until you’ve completed Activities 2 and 5. Therefore, to finish your project by the end of week 7, the latest you can finish Activities 2 and 5 is the end of week 7. Again, consider the lower path on the diagram in Figure 5-2 with Activities 3, 4, and 5: ✓ You must start Activity 5 by the beginning of week 6 to finish it by the end of week 7 (because Activity 5’s estimated duration is two weeks). ✓ According to Rule 2, you can’t start Activity 5 until you finish Activities 1 and 4. So, you must finish Activities 1 and 4 by the end of week 5. ✓ You must start Activity 4 by the beginning of week 3. ✓ You must finish Activity 3 before you can work on Activity 4. Therefore, you must finish Activity 3 by the end of week 2. ✓ You must start Activity 3 by the beginning of week 2. Finally, consider the upper path on the network diagram in Figure 5-2: ✓ You must start Activity 2 by the beginning of week 7. ✓ You can’t work on Activity 2 until you finish Activity 1. Therefore, you must finish Activity 1 by the end of week 6. Here again, you must be careful in your calculations. You must finish Activity 1 by the end of week 5 to start Activity 5 at the beginning of week 6. But, to start work on Activity 2 at the beginning of week 7, you must finish Activity 1 by the end of week 6. So, finishing Activity 1 by the end of week 5 satisfies both requirements. If two or more arrows leave the same activity or milestone, the latest date you can finish the activity or reach the milestone is the earliest of the latest dates that you must start the next activities or reach the next milestones. In Figure 5-2, the latest start dates for Activities 2 and 5 are the beginnings of week 7 and week 6, respectively. Therefore, the latest date to finish Activity 1 is the end of week 5. The rest is straightforward: You must start Activity 1 by the beginning of week 1 at the latest. To organize the dates you calculate in the forward and backward passes, consider writing the earliest and latest start dates and the earliest and latest finish dates at the top of each milestone or activity box in the project’s network diagram. Figure 5-3 illustrates how this looks for the example in Figure 5-2. 105
Slide 124: 106 Part II: Planning Time: Determining When and How Much ES = B1 EF = E5 LS = B1 LF = E5 Activity 1 t1 = 5 ES = B1 EF = B1 LS = B2 LF = B2 Start t=0 Slack = 0 ES = B6 EF = E6 LS = B7 LF = E7 Activity 2 t2 = 1 Slack = 1 week ES = E7 EF = E7 LS = E7 LF = E7 End t=0 ES = B1 EF = E1 LS = B2 LF = E2 Activity 3 t3 = 1 Slack = 1 week ES = B2 EF = E4 LS = B3 LF = E5 Activity 4 t4 = 3 Slack = 1 week ES = B6 EF = E7 Slack = 0 LS = B6 LF = E7 Activity 5 t5 = 2 Slack = 0 B1 = Beginning of week 1 E1 = End of week 1 Figure 5-3: Example of a network diagram with earliest and latest start and finish dates. Slack = 0 ES = Earliest start EF = Earliest finish LS = Latest start LF = Latest finish Now that you have all the earliest and latest start and finish dates for your milestones and activities, you need to determine the slack time for each activity or milestone. (An activity’s slack time is the amount of time it can be delayed without causing a delay in your overall project completion time.) You can determine slack time in one of two ways: ✓ Subtract the earliest possible start date from the latest allowable start date. ✓ Subtract the earliest possible finish date from the latest allowable finish date. Thus, you can determine that Activities 2, 3, and 4 have slack times of one week, while Activities 1 and 5 have no slack time. Figure 5-3 displays this information. Note: If an activity’s slack time is zero, the activity is on a critical path. Although slack time is defined as the amount of time an activity or milestone can be delayed without delaying your project’s completion time, slack time is actually associated with a sequence of activities rather than with an individual activity. The information in Figure 5-3 indicates that both Activity 3 and Activity 4 (which are on the same path) have slack times of one week. However, if Activity 2 is delayed by a week, Activity 3 will have zero slack time. A Guide to the Project Management Body of Knowledge, 4th Edition (PMBOK 4) identifies the following two types of slack:
Slide 125: Chapter 5: You Want This Project Done When? ✓ Total slack: The total amount of time a schedule activity may be delayed without delaying the project end date or a schedule constraint. This is the same as what I refer to as slack. ✓ Free slack: The amount of time a schedule activity may be delayed without delaying the early start of any immediately following schedule activities. As an example of these terms, look at the network diagram in Figure 5-3. Consider that Activity 3 is scheduled to start at the beginning of week 1 and Activity 4 is scheduled to start at the beginning of week 3. You can delay the start of Activity 3 by up to one week and Activity 4 will still be able to start at the beginning of week 3. So, Activity 3 has a free slack of one week. Coincidently, Activity 3 also has a total slack of one week because if you delay its start by more than one week, the completion of the project would be delayed beyond the current scheduled completion date of the end of week 7. Note: The concept of total slack is more often used in schedule analyses, and that’s the concept I use in this book. For simplicity, I refer to this information item simply as slack rather than total slack. 107 Working with Your Project’s Network Diagram The preceding sections explain the general rules and procedures for drawing and analyzing any network diagram. This section tells you how to create and analyze the network diagram for your own project. Determining precedence To draw your project’s network diagram, you first have to decide the order of your project’s activities. This section tells you different reasons why you may need to perform activities in a particular order. Looking at factors that affect predecessors A predecessor to an activity (Activity A, for example) is an activity or milestone that determines when work on Activity A can begin. PMBOK 4 identifies the following four relationships that can exist between a predecessor and the activity or milestone coming immediately after it (termed its successor): ✓ Finish-to-start: The predecessor must finish before the successor can start. ✓ Finish-to-finish: The predecessor must finish before the successor can finish.
Slide 126: 108 Part II: Planning Time: Determining When and How Much ✓ Start-to-start: The predecessor must start before the successor can start. ✓ Start-to-finish: The predecessor must start before the successor can finish. The finish-to-start precedence relationship is the one most commonly used, so it’s the one I address in this book. In other words, in this book, a predecessor is an activity that must be completed before its successor activity can start or its successor milestone can be reached. Sometimes an activity can’t start precisely when its predecessor is finished. A lag is the amount of time after its predecessor is completed that you must wait before an activity can start. A lead is the amount of time before its predecessor is finished that an activity can begin. In this book, I only consider situations where lead and lag times are zero. An activity is an immediate predecessor to Activity A if you don’t have any other activities between it and Activity A. When you determine the immediate predecessors for every activity, you have all the information you need to draw your project’s network diagram. The following considerations affect the order in which you must perform your project’s activities: ✓ Mandatory dependencies: These relationships must be observed if project work is to be a success. They include • Legal requirements: Federal, state, and local laws or regulations require that certain activities be done before others. As an example, consider a pharmaceutical company that has developed a new drug in the laboratory and demonstrated its safety and effectiveness in clinical trials. The manufacturer wants to start producing and selling the drug immediately but can’t. Federal law requires that the company obtain Food and Drug Administration (FDA) approval of the drug before selling it. • Procedural requirements: Company policies and procedures require that certain activities be done before others. Suppose you’re developing a new piece of software for your organization. You’ve finished your design and want to start programming the software. However, your organization follows a systems development methodology that requires the management-oversight committee to formally approve your design before you can develop it. • Hard logic: Certain processes must logically occur before others. For example, when building a house, you must pour the concrete for the foundation before you erect the frame. ✓ Discretionary dependencies: You may choose to establish these relationships between activities; they aren’t required. They include
Slide 127: Chapter 5: You Want This Project Done When? • Logical dependencies: Performing certain activities before others sometimes seems to make the most sense. Suppose you’re writing a report. Because much of Chapter 3 depends on what you write in Chapter 2, you decide to write Chapter 2 first. You could write Chapter 3 first or work on both at the same time, but that plan increases the chance that you’ll have to rewrite some of Chapter 3 after you finish Chapter 2. • Managerial choices: Sometimes you make arbitrary decisions to work on certain activities before others. Consider that you have to perform both Activity C and Activity D. You can’t work on them at the same time, and there’s no legal or logical reason why you should work on one or the other first. You decide to work on Activity C first. ✓ External dependencies: Starting a project activity may require that an activity outside the project be completed. For example, imagine that your project includes an activity to test a device you’re developing. You want to start testing right away, but you can’t start this activity until your organization’s test laboratory receives and installs a new piece of test equipment they plan to order. 109 Choosing immediate predecessors You can decide on the immediate predecessors for your project’s activities in one of two ways: ✓ Front-to-back: Start with the activities you can perform as soon as your project begins and work your way through to the end. To use this method, follow these steps: 1. Select the first activity or activities to perform as soon as your project starts. 2. Decide which activity or activities you can perform when you finish the first ones (from Step 1). 3. Continue in this way until you’ve considered all activities in the project. ✓ Back-to-front: Choose the activity or activities that will be done last on the project and continue backward toward the beginning. To use this method, follow these steps: 1. Identify the last project activity or activities you will conduct. 2. Decide which activity or activities you must complete right before you can start to work on the last activities (from Step 1). 3. Continue in this manner until you’ve considered all activities in your project. Regardless of which method you use to find your project’s immediate predecessors, record the immediate predecessors in a simple table like Table 5-1. (This table lists the immediate predecessors in the example shown in Figure 5-2.)
Slide 128: 110 Part II: Planning Time: Determining When and How Much Table 5-1 Work Breakdown Activity Code 1 2 3 4 5 Immediate Predecessors for Figure 5-2 Activity Description Activity 1 Activity 2 Activity 3 Activity 4 Activity 5 Immediate Predecessors None 1 None 3 1, 4 Determine precedence based on the nature and requirements of the activities, not on the resources you think will be available. Suppose Activities A and B of your project can be performed at the same time but you plan to assign them to the same person. In this case, don’t make Activity A the immediate predecessor for B, thinking that the person can work on only one activity at a time. Instead, let your diagram show that A and B can be done at the same time. Later, if you find out you have another person who can help out with this work, you can evaluate the impact of performing Activities A and B at the same time. (See Chapter 6 for a discussion on how to determine when people are overcommitted and how to resolve these situations.) When you create your network diagram for simple projects, consider writing the names of your activities and milestones on sticky-back notes and attaching them to chart paper or a wall. For more complex projects, consider using an integrated project-management software package. (See Chapter 16 for a discussion of how to use software to support your project planning, and check out Microsoft Office Project 2007 For Dummies by Nancy Muir [Wiley] for the lowdown on the most popular project-management software package.) Using a network diagram to analyze a simple example Consider the following example of preparing for a picnic to illustrate how to use a network diagram to determine possible schedules while meeting project expectations and satisfying project constraints. (I’m not suggesting that you plan all your picnics this way, but the situation does illustrate the technique rather nicely!) Deciding on the activities It’s Friday evening, and you and your friend are considering what to do during the weekend to unwind and relax. The forecast for Saturday is for sunny and mild weather, so you decide to go on a picnic at a local lake.
Slide 129: Chapter 5: You Want This Project Done When? Because you want to get the most enjoyment possible from your picnic, you decide to plan the outing carefully by drawing and analyzing a network diagram. Table 5-2 illustrates the seven activities you decide you must perform to prepare for your picnic and get to the lake. 111 Table 5-2 Activity Identifier Code 1 2 3 4 5 6 7 Activities for Your Picnic at the Lake Activity Description Load car Get money from bank Make egg sandwiches Drive to the lake Decide which lake to go to Buy gasoline Boil eggs (for egg sandwiches) Who Will Be Present You and your friend You Your friend You and your friend You and your friend You Your friend Duration (In Minutes) 5 5 10 30 2 10 10 In addition, you agree to observe the following constraints: ✓ You and your friend will start all activities at your house at 8 a.m. Saturday — you can’t do anything before that time. ✓ You must perform all seven activities to complete your project. ✓ You can’t change who must be present during each activity. ✓ The two lakes you’re considering are in opposite directions from your house, so you must decide where you’re going to have your picnic before you begin your drive. Setting the order of the activities Now that you have all your activities listed, you need to decide the order in which you will do them. In other words, you need to determine the immediate predecessors for each activity. The following dependencies are required: Your friend must boil the eggs before he can make the egg sandwiches (duh!), and both of you must load the car and decide which lake to visit before you start your drive. The order of the rest of the activities is up to you. You may consider the following approach:
Slide 130: 112 Part II: Planning Time: Determining When and How Much ✓ Decide which lake before you do anything else. ✓ After you both agree on the lake, you drive to the bank to get money. ✓ After you get money from the bank, you get gasoline. ✓ At the same time, after you agree on the lake, your friend starts to boil the eggs. ✓ After the eggs are boiled, your friend makes the egg sandwiches. ✓ After you get back with the gas and your friend finishes the egg sandwiches, you both load the car. ✓ After you both load the car, you drive to the lake. Table 5-3 depicts these predecessor relationships. Table 5-3 Activity Identifier Code 1 2 3 4 5 6 7 Predecessor Relationships for Your Picnic Activity Description Load car Get money from bank Make egg sandwiches Drive to lake Decide which lake Buy gasoline Boil eggs (for egg sandwiches) Immediate Predecessors 3, 6 5 7 1 None 2 5 Creating the network diagram Now that you have your immediate predecessors in mind, you can draw the network diagram for your project from the information in Table 5-5. To do so, follow these steps: 1. Begin your project with a single milestone and label it Start. 2. Find all activities in the table that have no immediate predecessors — they can all start as soon as you begin your project. In this case, only Activity 5 has no immediate predecessors. 3. Begin your diagram by drawing the relationship between the Start of your project and the beginning of Activity 5 (see Figure 5-4). Depict Activity 5 with a box and draw an arrow to it from the Start box.
Slide 131: Chapter 5: You Want This Project Done When? 113 Figure 5-4: Starting your picnicat-the-lake network diagram. Start t=0 Decide which lake t5 = 2 All times are in minutes 4. Find all activities that have your first activity as an immediate predecessor. In this case, Table 5-3 shows that Activities 2 and 7 have Activity 5 as an immediate predecessor. Draw boxes to represent these two activities, and draw arrows from Activity 5 to Activities 2 and 7 (see Figure 5-5). 5. Continue in the same way with the remaining activities. Recognize from Table 5-5 that only Activity 6 has Activity 2 as an immediate predecessor. Therefore, draw a box to represent Activity 6 and draw an arrow from Activity 2 to that box. Table 5-3 also shows that only Activity 3 has Activity 7 as an immediate predecessor. So draw a box to represent Activity 3, and draw an arrow from Activity 7 to Activity 3. Figure 5-5 depicts your diagram in progress. Now realize that Activity 1 has both Activities 3 and 6 as immediate predecessors. Therefore, draw a box representing Activity 1 and draw arrows from Activities 3 and 6 to this box. Get money t2 = 5 Buy gasoline t6 = 10 Start t=0 Decide which lake t5 = 2 Figure 5-5: Continuing your picnicat-the-lake network diagram. Boil eggs All times are in minutes t7 = 10 Make sandwiches t3 = 10
Slide 132: 114 Part II: Planning Time: Determining When and How Much The rest is pretty straightforward. Because only Activity 4 has Activity 1 as its immediate predecessor, draw a box representing Activity 4 and draw an arrow from Activity 1 to Activity 4. 6. After adding all the activities to the diagram, draw a box to represent End, and draw an arrow from Activity 4 (the last activity you have to complete) to that box (see Figure 5-6 for the complete network diagram). Get money t2 = 5 Start t=0 Figure 5-6: Completed picnic-atthe-lake network diagram. Decide which lake t5 = 2 Boil eggs t7 = 10 Buy gasoline t6 = 10 Load car t1 = 5 Make sandwiches t3 = 10 Drive to lake t4 = 30 End t=0 Critical path (in bold) = 57 minutes All times are in minutes Now for the important timing-related questions. First, how long will you and your friend take to get to the lake for your picnic? The upper path (Start, Activities 5, 2, 6, 1, 4, and End) takes 52 minutes to complete, and the lower path (Start, Activities 5, 7, 3, 1, 4, and End) takes 57 minutes to complete. Thus, it will take 57 minutes from the time you start until you arrive at the lake for your picnic, and the lower path is the critical path. The second timing-related question you have to answer is: Can you delay any activities and still get to the lake in 57 minutes? If so, which ones can you delay and by how much? To answer these questions, consider the following: ✓ The network diagram reveals that Activities 5, 7, 3, 1, and 4 are all on the critical path. Therefore, you can’t delay any of them if you want to get to the lake in 57 minutes. ✓ Activities 2 and 6 aren’t on the critical path, and they can be performed at the same time as Activities 7 and 3. Activities 7 and 3 take 20 minutes to perform, while Activities 2 and 6 take 15 minutes. Therefore, Activities 2 and 6 have a total slack time of 5 minutes. Developing Your Project’s Schedule Developing your project’s schedule requires the combination of activities, resources, and activity-performance sequences that gives you the greatest
Slide 133: Chapter 5: You Want This Project Done When? chance of meeting your client’s expectations with the least amount of risk. This section helps you start making a project schedule. It also focuses on some potential pitfalls and solutions for meeting time crunches. 115 Taking the first steps After you specify your project’s activities (see the discussion on creating Work Breakdown Structures in Chapter 4), take the following steps to develop an initial project schedule: 1. Identify immediate predecessors for all activities. Immediate predecessors define the structure of your network diagram. 2. Determine the personnel and nonpersonnel resources required for all activities. The type, amount, and availability of resources affect how long you need to perform each activity. 3. Estimate durations for all activities. See the section “Estimating Activity Duration” for details on how to do so. 4. Identify all intermediate and final dates that must be met. These dates define the criteria that your schedule must meet. 5. Identify all activities or milestones outside your project that affect your project’s activities. After you identify these external activities and milestones, you can set up the appropriate dependencies between them and your project’s activities and milestones. 6. Draw your network diagram. Use the network diagram to determine what schedules your project can achieve. 7. Analyze your project’s network diagram to identity all critical paths and their lengths and to identify the slack times of noncritical paths. This information helps you choose which project activities to monitor and how often to monitor them. It also suggests strategies for getting back on track if you encounter unexpected schedule delays. (See the section “Interpreting a network diagram” earlier in this chapter for additional information on critical and noncritical paths.) If the completion date is acceptable to your client, you’re done with your scheduling. However, if your client wants you to finish faster than your initial schedule allows, your analyses are just beginning.
Slide 134: 116 Part II: Planning Time: Determining When and How Much Avoiding the pitfall of backing in to your schedule Beware of developing a schedule by backing in, that is, starting at the end of a project and working your way back toward the beginning to identify activities and estimate durations that allow you to meet your client’s desired end date. Using this approach substantially decreases the chances that you’ll meet the schedule for the following reasons: ✓ You may miss activities because your focus is on meeting a time constraint, not ensuring that you’ve identified all required work. ✓ You base your duration estimates on what you can allow activities to take rather than what they’ll require. ✓ The order for your proposed activities may not be the most effective one. I was reviewing a colleague’s project plan a while back and noticed that she had allowed one week for her final report’s review and approval. When I asked her whether she thought this estimate was realistic, she replied that it certainly wasn’t realistic but that she had to use that estimate for the project plan to work out. In other words, she was using time estimates that totaled to the number she wanted to reach rather than ones she thought she could meet. Meeting an established time constraint Suppose your initial schedule has you finishing your project in three months, but your client wants the results in two months. Consider the following options for reducing the length of your critical paths: ✓ Recheck the original duration estimates. • Be sure you have clearly described the activity’s work. • If you used past performance as a guide for developing the durations, recheck to be sure all characteristics of your current situation are the same as those of the past performance. • Ask other experts to review and validate your estimates. • Ask the people who’ll actually be doing the work on these activities to review and validate your estimates. ✓ Consider using more-experienced personnel. Sometimes moreexperienced personnel can get work done in less time. Of course, using more-experienced people may cost you more money. Further, you’re not the only one in your organization who needs those more-experienced personnel; they may not always be available to help with your project!
Slide 135: Chapter 5: You Want This Project Done When? ✓ Consider different strategies for performing the activities. As an example, if you estimate a task you’re planning to do internally to take three weeks, see if you can find an external contractor who can perform it in two weeks. ✓ Consider fast tracking — performing tasks that are normally done sequentially at the same time. While fast tracking can shorten the overall time to perform the tasks, it also increases the risk of having to redo portions of your work, so be ready to do so. As you reduce the lengths of critical paths, monitor paths that aren’t initially critical to ensure that they haven’t become critical. If one or more paths have become critical, use these same approaches to reduce their lengths. 117 Applying different strategies to arrive at your picnic in less time Consider the example of preparing for a picnic (which I introduce in the “Using a network diagram to analyze a simple example” section) to see how you can apply these approaches for reducing a project’s time to your own project. Figure 5-6 illustrates your initial 57-minute plan. If arriving at the lake in 57 minutes is okay, your analysis is done. But suppose you and your friend agree that you must reach the lake no later than 45 minutes after you start preparing on Saturday morning. What changes can you make to save you 12 minutes? You may be tempted to change the estimated time for the drive from 30 minutes to 18 minutes, figuring that you’ll just drive faster. Unfortunately, doing so doesn’t work if the drive really takes 30 minutes. Remember, your plan represents an approach that you believe has a chance to work (though not necessarily one that’s guaranteed). If you have to drive at speeds in excess of 100 miles per hour over dirt roads to drive to the lake in 18 minutes, reducing the duration estimate has no chance of working. (However, doing so does have an excellent chance of getting you a speeding ticket.) To develop a more realistic plan to reduce your project’s schedule, take the following steps: 1. Start to reduce your project’s time by finding the critical path and reducing its time until a second path becomes critical. 2. To reduce your project’s time further, shorten both critical paths by the same amount until a third path becomes critical. 3. To reduce the time still further, shorten all three critical paths by the same amount of time until a fourth path becomes critical, and so on.
Slide 136: 118 Part II: Planning Time: Determining When and How Much Performing activities at the same time One way to shorten the time it takes to do a group of activities is by taking one or more activities off the critical path and doing them in parallel with the remaining activities. However, often you have to be creative to simultaneously perform activities successfully. Consider the 57-minute solution to the picnic example in Figure 5-6. Assume an automatic teller machine (ATM) is next to the gas station that you use. If you use a full-service gas island, you can get money from the ATM while the attendant fills your gas tank. This strategy allows you to perform Activities 2 and 6 at the same time — in a total of 10 minutes rather than the 15 minutes you indicated in the initial network diagram. At first glance, it appears you can cut the total time down to 52 minutes by making this change. But look again. These two activities aren’t on the critical path, so completing them more quickly has no impact on the overall project schedule. (Before you think you can save five minutes by helping your friend make the sandwiches, remember: You agreed that you can’t swap jobs.) Now you have to try again. This time, remember you must reduce the length of the critical path if you want to save time. Here’s another idea: On your drive to the lake, you and your friend are both in the car, but only one of you is driving. The other person is just sitting there. If you agree to drive, your friend can load the fixings for the sandwiches into the car and make the sandwiches while you drive. This adjustment appears to take ten minutes off the critical path. But does it really? The diagram in Figure 5-6 reveals that the upper path (Activities 2 and 6) takes 15 minutes and the lower path (Activities 7 and 3) takes 20 minutes. Because the lower path is the critical path, removing five minutes from it can reduce the time to complete the overall project by five minutes. However, reducing the lower path by five minutes makes it the same length (15 minutes) as the upper path. As a result, both paths take 15 minutes, and both are now critical. Taking an additional five minutes off the lower path (because the sandwiches take ten minutes to make) doesn’t save more time for the overall project because the upper path still takes 15 minutes. However, removing the extra five minutes from the lower path does add five minutes of slack to the lower path. Figure 5-7 reflects this change in your network diagram. Now you can consider using your first idea to get money at the ATM while an attendant fills your car with gas. This time, this move can save you five minutes because the upper path is now critical. Finally, you can decide which lake to visit and load the car at the same time, which saves you an additional two minutes. Figure 5-8 illustrates the final 45-minute solution.
Slide 137: Chapter 5: You Want This Project Done When? Get money t2 = 5 Start t=0 Figure 5-7: Making sandwiches while driving to the lake. Decide which lake t5 = 2 Boil eggs t7 = 10 Buy gasoline t6 = 10 Load car t1 = 5 Drive to lake t4 = 30 Make sandwiches t3 = 10 End t=0 119 Critical path (in bold) = 52 minutes Get money t2 = 5 Start t=0 Figure 5-8: Getting to your picnic at the lake in 45 minutes. Buy gasoline t6 = 10 Boil eggs t7 = 10 Ready to load car t=0 Load car t1 = 5 Ready to drive t=0 Drive to lake t4 = 30 End t=0 Decide which lake t5 = 2 Make sandwiches t3 = 10 Critical path (in bold) = 45 minutes Consider a situation in which you have to complete two or more activities before you can work on two or more new ones. Show this relationship in your diagram by defining a milestone that represents completion of the activities, drawing arrows from the activities to this milestone and then drawing arrows from that milestone to the new activities (refer to Figure 5-8). In the example, you first complete the activities Get money, Buy gasoline, and Boil eggs, and then you can perform the activities Load car and Decide which lake. You represent this relationship by drawing arrows from each of the first three activities to a newly defined milestone, Ready to load car, and by drawing arrows from that milestone to the activities Load car and Decide which lake. If you think this analysis is getting complicated, you’re right. You pay a price to perform a group of activities faster. This price includes ✓ Increased planning time: You have to detail precisely all the activities and their interrelationships because you can’t afford to make mistakes. ✓ Increased risks: The list of assumptions grows, increasing the chances that one or more will turn out to be wrong.
Slide 138: 120 Part II: Planning Time: Determining When and How Much In the picnic-at-the-lake example, you make the following assumptions to arrive at a possible 45-minute solution: ✓ You can get right into the full-service island at a little after 8 a.m. ✓ Attendants are available to fill up your tank as soon as you pull into the full-service island. ✓ The ATM is free and working when you pull into the full-service island. ✓ You and your friend can load the car and make a decision together without getting into an argument that takes an hour to resolve. ✓ Your friend can make sandwiches in the moving car without totally destroying the car’s interior in the process. At the same time that making assumptions can increase the risks involved in your possible project schedule, identifying the assumptions you make can increase the chances that those assumptions will come true — or at least convince you to develop contingency plans in case they don’t. Consider your assumption that you can get right into a full-service island at about 8 a.m. on Saturday. You can call the gas station owner and ask whether your assumption is reasonable. If the gas station owner tells you he has no idea how long you’ll have to wait for someone to pump your gas, you may ask him whether it would make a difference if you paid him $200 in cash. When he immediately promises to cordon off the full-service island from 7:55 a.m. until 8:20 a.m. and assign two attendants to wait there, one with a nozzle and the other with a charge receipt ready to be filled out (so you’ll be out in ten minutes), you realize you can reduce most uncertainties for a price! Your job is to determine how much you can reduce the uncertainty and what price you have to pay to do so. Devising an entirely new strategy So you have a plan for getting to the lake in 45 minutes. You can’t guarantee the plan will work, but at least you have a chance. However, suppose your friend now tells you he really needs to get to the lake in 10 minutes, not 45! Your immediate reaction is probably “Impossible!” You figure creative planning is one thing, but how can you get to the lake in 10 minutes when the drive alone takes 30 minutes? By deciding that you absolutely can’t arrive at the lake in 10 minutes when the drive alone takes 30 minutes, you’ve forgotten that the true indicator of success in this project is arriving at the lake for your picnic, not performing a predetermined set of activities. Your original seven activities were fine, as long as they allowed you to get to the lake within your set constraints. But if the activities won’t allow you to achieve success as you now define it (arriving at the lake in ten minutes), consider changing the activities. Suppose you decide to find a way other than driving to get from your home to the lake. After some checking, you discover that you can rent a helicopter
Slide 139: Chapter 5: You Want This Project Done When? for $500 per day that’ll fly you and your friend to the lake in ten minutes. However, you figure that you both were thinking about spending a total of $10 on your picnic (for admission to the park at the lake). You conclude that it makes no sense to spend $500 to get to a $10 picnic, so you don’t even tell your friend about the possibility of renting the helicopter. Instead, you just reaffirm that getting to the lake in ten minutes is impossible. Unfortunately, when you decided not to tell your friend about the helicopter option, you didn’t know your friend found out that he could make a $10,000 profit on a business deal if he could get to the lake in ten minutes. Is it worth spending $500 to make $10,000? Sure. But you didn’t know about the $10,000 when you gave up on getting to the lake in ten minutes. When developing schedule options, it’s not your job to preempt someone else from making a decision. Instead, you want to present all options and their associated costs and benefits to the decision maker so he can make the best decision. In this instance, you should’ve told your friend about the helicopter option so he could’ve considered it when he made the final decision. 121 Subdividing activities You can often reduce the time to complete a sequence of activities by subdividing one or more of the activities and performing parts of them at the same time. To relate back to the picnic-at-the-lake example, your friend can save seven minutes when boiling the eggs and preparing the egg sandwiches by using the approach I illustrate in Figure 5-9. Here’s what your friend needs to do: ✓ Divide the activity of boiling the eggs into two parts: • Prepare to boil the eggs: Remove the pot from the cupboard, take the eggs out of the refrigerator, put the water and eggs in the pot, put the pot on the stove, and turn on the heat — estimated duration of three minutes. • Boil the eggs in water: Allow the eggs to boil in a pot until they’re hard — estimated duration of seven minutes. ✓ Divide the activity of making the egg sandwiches into two parts: • Perform the initial steps to make the sandwiches: Take the bread, mayonnaise, lettuce, and tomatoes out of the refrigerator; take the wax paper out of the drawer; put the bread on the wax paper; put the mayonnaise, lettuce, and tomatoes on the bread — estimated duration of seven minutes. • Finish making the sandwiches: Take the eggs out of the pot; shell, slice, and put them on the bread; slice and finish wrapping the sandwiches — estimated duration of three minutes. ✓ First prepare to boil the eggs; next boil the eggs in water and perform the initial steps to make sandwiches at the same time; finally, finish making the sandwiches.
Slide 140: 122 Part II: Planning Time: Determining When and How Much Boil eggs in water t5B = 7 Prepare to boil eggs t5A = 3 Figure 5-9: Reducing duration by subdividing activities. Perform initial steps to make sandwiches t3A = 7 Finish making sandwiches t3B = 3 Time to boil eggs and make sandwiches = 13 minutes As Figure 5-9 illustrates, the total time to boil the eggs and prepare the sandwiches is: 3 minutes + 7 minutes + 3 minutes = 13 minutes. Note: The total time for the original activity to boil the eggs is still ten minutes (three minutes to prepare and seven minutes in the water), and the total time for the original activity to make the sandwiches is also still ten minutes (seven minutes for the initial steps and three minutes to finish up). But by subdividing the activities and scheduling them in greater detail, you can complete them in 13 minutes rather than 20. Estimating Activity Duration A duration estimate is your best sense of how long you need to actually perform an activity. The estimate is not how long you want the activity to take or how long someone tells you it must take; the estimate is how long you think it really will take. Overly optimistic or unrealistically short duration estimates can cause an activity to take longer than necessary for the following two reasons: ✓ Because unrealistic estimates appear to meet your schedule targets, you don’t seek realistic alternative strategies that increase the chances of accomplishing activities in their declared durations. ✓ If people believe duration estimates are totally unrealistic, they’ll stop trying to achieve them. When delays occur during an activity, people will accept them as inevitable instead of seeking ways to overcome them. This section looks more closely at what you need to estimate activity duration accurately, including an understanding of the activity’s components and processes and the resources required to support these processes.
Slide 141: Chapter 5: You Want This Project Done When? 123 Determining the underlying factors The underlying makeup of an activity determines how long it will take to complete. Therefore, accurately estimating that activity’s duration requires you to describe its different aspects and determine the effect of each one on the activity’s length. When estimating an activity’s duration, consider past experience, expert opinion, and other available sources of information to clarify the following components of the activity: ✓ Work performed by people: Physical and mental activities that people perform, such as writing a report, assembling a piece of equipment, and thinking of ideas for an ad campaign ✓ Work performed by nonhuman resources: Activities that computers and other machines perform, such as testing software on a computer and printing a report on a high-speed copy machine ✓ Physical processes: Physical or chemical reactions, such as concrete curing, paint drying, and chemical reactions in a laboratory ✓ Time delays: Time during which nothing is happening, such as needing to reserve a conference room two weeks before holding a meeting (Time delays are typically due to the unavailability of resources.) Considering resource characteristics Knowing the types of resources an activity requires can help you improve your estimate of the activity’s duration. For example, not all copy machines generate copies at the same rate. Specifying the characteristics of the particular machine you’ll use to make copies can improve the activity’s duration estimate. To support project work, you may need the following types of resources: personnel, equipment, facilities, raw materials, information, and funds. For each resource you need, you have to determine its ✓ Capacity: Productivity per unit time period ✓ Availability: When a resource will be available For example, a copy machine that produces 1,000 copies per minute can complete a job in half the time a machine that produces 500 copies per minute requires. Likewise, a large printing job can take half as long if you have access to a copy machine for four hours a day rather than two hours a day. (See Chapter 7 for more information on estimating project requirements for nonhuman resources.)
Slide 142: 124 Part II: Planning Time: Determining When and How Much Finding sources of supporting information The first step toward improving your estimate’s accuracy is to take into account the right kinds of information, such as determining how long similar activities have actually taken in the past rather than how long people thought they would or should take. However, your estimate’s accuracy also depends on the accuracy of the information you use to derive it. The information you need often has no single authoritative source. Therefore, compare information from the following sources as you prepare your duration estimates: ✓ Historical records of how long similar activities have taken in the past ✓ People who’ve performed similar activities in the past ✓ People who’ll be working on the activities ✓ Experts familiar with the type of activity, even if they haven’t performed the exact activity before Improving activity duration estimates In addition to ensuring accurate and complete data, do the following to improve the quality of your duration estimates (see Chapter 4 for more details about how to define and describe your project’s activities): ✓ Define your activities clearly. Minimize the use of technical jargon, and describe work processes fully. ✓ Subdivide your activities until your lowest-level activity estimates are two weeks or less. ✓ Define activity start and end points clearly. ✓ Involve the people who’ll perform an activity when estimating its duration. ✓ Minimize the use of fudge factors. A fudge factor is an amount of time you add to your best estimate of duration “just to be safe.” Automatically estimating your final duration estimates to be 50 percent greater than your initial ones is an example. Fudge factors compromise your project planning for the following reasons: • Work tends to expand to fill the allotted time. If you’re able to finish an activity in two weeks but use a 50-percent fudge factor to indicate a duration of three weeks, the likelihood that you’ll finish in less than three weeks is almost zero. • People use fudge factors to avoid studying activities in sufficient depth; as a result, they can’t develop viable performance strategies.
Slide 143: Chapter 5: You Want This Project Done When? • Team members and other project audiences lose faith in your plan’s accuracy and feasibility because they know you’re playing with numbers rather than thinking activities through in detail. No matter how hard you try, estimating duration accurately can be next to impossible for some activities. For example, you may have an exceptionally difficult time coming up with accurate duration estimates for activities you haven’t done before, activities you’ll perform in the future, and activities with a history of unpredictability. In these cases, ✓ Make the best estimate you can by following the approaches and guidelines in this section. ✓ Monitor activities closely as your project unfolds to identify details that may affect your initial estimate. ✓ Reflect any changes in your project schedule as soon as you become aware of them. In situations where you’ve performed an activity many times before and have historical data on how long it took each time, you may be able to estimate with confidence how long the activity will take the next time you perform it. In less certain situations, however, you may choose to consider the activity’s duration as a random variable that can have a range of values with different probabilities. The Program Evaluation and Review Technique (PERT) is a network analysis methodology that treats an activity’s duration as a random variable with the probability of the variable having different values being described by a Beta distribution. According to the characteristics of a Beta distribution, you determine the average value (also called the expected value) of the activity’s duration from the following three time estimates: ✓ Optimistic estimate (to): If you perform the activity 100 times, its duration would be greater than or equal to this number 99 times. ✓ Most likely estimate (tm): If you perform the activity 100 times, the duration would be this number more times than any other. ✓ Pessimistic estimate (tp): If you perform this activity 100 times, its duration would be less than or equal to this number 99 times. The expected value of the duration (te) is then defined by the following formula: Expected value = te = (to + 4tm + tp) ÷ 6 If only a small number of activities in your network are uncertain, you may assign their durations to be equal to their expected values and determine the critical path, earliest and latest start and finish times, and slack times as before. However, if all activities in your network are uncertain, you may 125
Slide 144: 126 Part II: Planning Time: Determining When and How Much choose to develop three time estimates for each activity. In this case, you can use the properties of the Beta distribution to determine the probability that the length of the critical path falls within specified ranges on either side of the expected value. Displaying Your Project’s Schedule Unless all your activities are on a critical path, your network diagram doesn’t specify your exact schedule. Rather, it provides information for you to consider when you develop your schedule. After you select your actual dates, choose one of the following formats in which to present your schedule: ✓ Milestone list: A table that lists milestones and the dates you plan to reach them ✓ Activity list: A table that lists activities and the dates you plan to start and end them ✓ Combined milestone/activity list: A table that includes milestone and activity dates ✓ Gantt chart: A timeline that illustrates when each activity starts, how long it continues, and when it ends ✓ Combined milestone and Gantt chart: A timeline that illustrates when activities start, how long they continue, when they end, and when selected milestones are achieved Figure 5-10 presents the 45-minute schedule for your picnic at the lake (from Figure 5-8) in a milestone/activity list. You may combine two or more formats into a single display. Figure 5-11 illustrates a combined WBS, Responsibility Assignment Matrix (see Chapter 10), and Gantt chart (in which triangles represent milestones) for the picnicat-the-lake example. In addition to requiring less paperwork to prepare and being easier to update and maintain than separate information documents, a combined display can provide greater insight into the plan by presenting two or more aspects together for ready comparison. Each format can be effective in particular situations. Consider the following guidelines when choosing the format in which to display your schedule: ✓ Milestone lists and activity lists are more effective for indicating specific dates. ✓ The Gantt chart provides a clearer picture of the relative lengths of activities and times when they overlap. ✓ The Gantt chart provides a better high-level overview of a project.
Slide 145: Chapter 5: You Want This Project Done When? 127 Milestone/Activity 1. Get money 2. Buy gasoline 3. Boil eggs A. Ready to load car 4. Load car 5. Decide which lake B. Ready to drive 6. Make egg sandwiches 7. Drive to lake C. End – arrived at lake Start Date End Date (minutes after (minutes after Person Responsible project start) project start) You You Your friend You and your friend You and your friend You and your friend You and your friend Your friend You and your friend You and your friend 0 0 0 10 10 15 15 5 10 10 10 15 12 15 25 45 45 Comments Critical path Critical path Critical path Critical path Critical path Critical path Critical path Figure 5-10: Representing your picnicat-the-lake schedule in a milestone/ activity list. Note: Events are in bold. Work Breakdown Structure Activity/Milestone Responsibility Assignment Matrix Personnel You P S P P S P P P P Friend S P P P P S S S S 0 5 Gantt Chart Time (in minutes after start) 10 15 20 25 30 35 40 45 50 55 Figure 5-11: Representing your picnic-atthe-lake schedule in a combined WBS, Responsibility Assignment Matrix, and Gantt chart. ID 10 8 2 6 7 3 5 9 1 4 11 WBS code Title Start Preparations Money Gas Eggs Egg sandwiches Decide which lake Travel Loading car Driving to lake End 1.0. 2.0. 2.1. 2.2. 2.3. 2.4. 3.0. 4.0. 4.1. 4.2. 5.0. Summary activities Critical path is outlined in bold P = Primary responsibility S = Secondary responsibility Relating This Chapter to the PMP Exam and PMBOK 4 Table 5-4 notes topics in this chapter that may be addressed on the Project Management Professional (PMP) certification exam and that are also included in A Guide to the Project Management Body of Knowledge, 4th Edition (PMBOK 4).
Slide 146: 128 Part II: Planning Time: Determining When and How Much Table 5-4 Topic Chapter 5 Topics in Relation to the PMP Exam and PMBOK 4 Location in PMBOK 4 6.2.2. Sequence Activities: Tools and Techniques Comments The terms and approaches in this book are the same as those used in PMBOK 4. The terms and approaches in this book are the same as those used in PMBOK 4. The terms and approaches in this book are the same as those used in PMBOK 4. The terms and approaches in this book are the same as those used in PMBOK 4. The terms and approaches in this book are the same as those used in PMBOK 4. The terms and approaches in this book are the same as those used in PMBOK 4. Definition of network diagram (see the section “Picture This: Illustrating a Work Plan with a Network Diagram”) Reading and interpreting a network diagram (see the section “Analyzing a Network Diagram”) Understanding precedence (see the section “Determining precedence”) Developing the schedule (see the section “Developing Your Project’s Schedule”) Estimating duration (see the section “Estimating Activity Duration”) 6.5.2.2. Critical Path Method 6.2.2. Sequence Activities: Tools and Techniques 6.5.2. Develop Schedule: Tools and Techniques 6.4. Estimate Activity Durations Displaying the schedule (see the section “Displaying Your Project’s Schedule”) 6.5.3.1. Project Schedule
Slide 147: Chapter 6 Establishing Whom You Need, How Much, and When In This Chapter ▶ Focusing first on people’s abilities ▶ Accurately planning your project’s personnel needs ▶ Striking a balance among all your resource commitments I remember reading the following declaration by a stressed-out project manager: “We’ve done so much with so little for so long [that] they now expect us to do everything with nothing!” The truth is, of course, you can’t accomplish anything with nothing; everything has a price. You live in a world of limited resources and not enough time, which means you always have more work to do than time and resources allow. After you decide which tasks to pursue, you need to do everything possible to perform them successfully. Carefully planning for the personnel you need to perform your project increases your chances of succeeding by enabling you to ✓ Ensure the most qualified people available are assigned to each task. ✓ Explain more effectively to team members what you’re asking them to contribute to the project. ✓ Develop more accurate and realistic schedules. ✓ Ensure that people are on hand when they’re needed. ✓ Monitor resource expenditures to identify and address possible overruns or underruns. Some organizations have procedures that detail and track every resource on every project. Other organizations don’t formally plan or track project resources at all. However, even if your organization doesn’t require you to plan your resource needs and track your resource use, doing so is invaluable to your project’s success.
Slide 148: 130 Part II: Planning Time: Determining When and How Much This chapter helps you figure out whom you need on your project, when, and for how long. It also discusses how you can identify and manage conflicting demands for people’s time. Getting the Information You Need to Match People to Tasks Your project’s success rests on your ability to enlist the help of appropriately qualified people to perform your project’s work. You begin your project planning by determining your project’s required results and major deliverables (see Chapter 2 for details on how to do this). You continue your planning by detailing the intermediate and final deliverables that your project must generate in a Work Breakdown Structure (WBS; see Chapter 4 for more information). Your next step is to decide which activities you’ll need performed to create the deliverables identified in your project’s work packages (the lowest-level components in the WBS) and to determine the skills and knowledge people must have to perform them. As you find out in the following sections, getting appropriately qualified people to perform your project’s activities entails the following two steps: ✓ Determining the skills and knowledge that each activity requires ✓ Confirming that the people assigned to those activities possess the required skills and knowledge and that they’re genuinely interested in working on their assignments A skill is something you must be able to do to perform an activity successfully. Knowledge is information you must have in your head to be able to perform an activity successfully. Interest is your personal desire to know about and be involved with the subject matter of an activity and to have a part in successfully producing the result of the activity. Possessing the necessary skills and knowledge means you’re capable of doing a task. Being interested in the task increases the chances you’ll apply your skills and knowledge to actually accomplish the task successfully. Deciding the skills and knowledge that team members must have To begin deciding the skills and knowledge that people must have for your project, obtain a complete list of all your project’s activities. Specify your project’s activities by decomposing all the work packages (the lowest-level WBS components) in your project’s WBS into the individual actions required to complete them.
Slide 149: Chapter 6: Establishing Whom You Need, How Much, and When You may find information to help you complete this task in your project’s WBS dictionary; you identify and describe your project’s activities and their important characteristics — such as a unique name and identifier code, duration, predecessors, and successors — in this document. (See Chapter 4 for details on WBS dictionaries and decomposition.) Next, determine each activity’s skill and knowledge requirements by reviewing activity descriptions and consulting with subject-matter experts, your human resources department, and people who have worked on similar projects and activities in the past. Because you’ll ask functional managers and others in the organization to assign staff to your project who have the specified skills and knowledge that your project work requires, you should check with these people before you prepare your list of required skills and knowledge to see whether they have developed any skills rosters and, if they haven’t, the schemes (if any) that they or the organization currently uses to describe staff’s skills and knowledge. Then, if possible, you can use the same or a similar scheme to describe your project’s skill and knowledge requirements to make it easier for the managers to identify those people who are appropriately qualified to address your project’s requirements. For most situations, you need to know two pieces of information about a task to determine the qualifications that a person must have to perform it: ✓ The required levels of proficiency in the needed skills and knowledge ✓ Whether the assignment will entail working under someone else’s guidance when applying the skills or knowledge, working alone to apply the skills or knowledge, or managing others who are applying the skills or knowledge. An example of a scheme that describes these two aspects of a skill or knowledge requirement is (X, Y). X is the required level of proficiency in the skill or knowledge and has the following values: ✓ 1 = requires a basic level of proficiency ✓ 2 = requires an intermediate level of proficiency ✓ 3 = requires an advanced level of proficiency Y is the required working relationship when applying the skill or knowledge and has the following values: ✓ a = doesn’t entail managing others using the skill or knowledge ✓ b = entails managing others using the skill or knowledge 131
Slide 150: 132 Part II: Planning Time: Determining When and How Much In addition to providing a basis for assigning appropriately qualified people to project teams, information about employees’ skills and knowledge can also support ✓ Training: The organization can develop or make available training in areas in which the organization has shortages. ✓ Career development: The organization can encourage individuals to develop skills and knowledge that are in short supply to increase their opportunities for assuming greater responsibilities in the organization. ✓ Recruiting: Recruiters can look to hire people who have the capabilities that will qualify them for specific job needs in the organization. ✓ Proposal writing and new business development: Information about people’s skills and knowledge can be included in proposals to demonstrate the organization’s capability to perform particular types of work. Representing skills, knowledge, and interests in a Skills Matrix Whether you’re able to influence the people assigned to your project team, people are assigned to your team without your input, or you assume the role of project manager of an existing team, you need to confirm the skills, knowledge, and interest of your team members. If you have a team that was assembled without considering your opinion on the capabilities needed to perform your project’s work, it’s essential that you find out team members’ skills, knowledge, and interests so you can make the most appropriate task assignments. If some or all of your team has been chosen in response to the specific skills and knowledge needs that you discussed with the organization’s management, you should document people’s skills and knowledge and verify their interests, in case you need to assign people to unanticipated tasks that crop up or if you have to replace a team member unexpectedly. A Skills Matrix is a table that displays people’s proficiency in specified skills and knowledge, as well as their interest in working on assignments using these skills and knowledge. Figure 6-1 presents an example of a portion of a Skills Matrix. The left-hand column identifies skill and knowledge areas, and the top row lists people’s names. At the intersection of the rows and columns, you identify the level of each person’s particular skills, knowledge, and interests. Figure 6-1 shows that Sue has an advanced level of proficiency in technical writing and can work independently with little or no supervision. In addition, she’s interested in working on technical writing assignments. Ed has an advanced level of proficiency in the area of legal research and is capable of managing others engaged in legal research. However, he’d prefer not to