Effective Project Management: Traditional, Agile, Extreme

technique. All of this will give you a complete understanding of how to successfully complete projects on time and within budget.

This comprehensive guide shows you how to:

• Apply all nine Knowledge Areas defined in PMBOK K® • Establish project management life cycles and strategies • Decide the best method for managing specific types of projects • Select and use best-of-breed project management tools and templates for each management task

• Utilize the Project Support Office, Project Portfolio Management, and Continuous Process Improvement programs • Prevent projects from becoming distressed and create effective intervention strategies • Manage multiple team projects by integrating the tools, templates, and processes into a single team

Robert K. Wysocki, PhD, has over 40 years of experience e as a project management consultant and trainer, information systems manager, systems and management consultan nt, author, training developer, and provider. He is the founder of Enterprise Information Insights, Inc., a project manag gement consulting and training practice. Wysocki has written 15 books on project management and information systtems management.

Effective Project Management

Get ready for a more robust approach to project management — one that recognizes the project environment and adapts accordingly. This resource first introduces you to the tools, templates, and processes that you’ll need in your toolkit. You’ll then explore five different project management life cycle (PMLC) models for managing a project: Linear, Incremental, Iterative, Adaptive, and Extreme. Along the way, you’ll find step-by-step guidance on how to apply each

Robert K. Wysocki

Traditional, Agile, Extreme

Gain the skills and tools to become an effective project manager

Wysocki

Effective Project Management

FIFTH EDITION ISBN: 978-0-470-42367-7 Visit our Web site at www.wiley.com/go/epm5e Projec Pro jjectt Management g ent

FIFTH EDITION

5

Effective Project Management

Effective Project Management Traditional, Agile, Extreme Fifth Edition

Robert K. Wysocki, Ph.D.

Wiley Publishing, Inc.

Effective Project Management: Traditional, Agile, Extreme, Fifth Edition Published by Wiley Publishing, Inc. 10475 Crosspoint Boulevard Indianapolis, IN 46256

www.wiley.com Copyright © 2009 by Robert K. Wysocki Published by Wiley Publishing, Inc., Indianapolis, Indiana Published simultaneously in Canada ISBN: 978-0-470-42367-7 Manufactured in the United States of America 10 9 8 7 6 5 4 3 2 1 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. 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 Web site 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 Web site may provide or recommendations it may make. Further, readers should be aware that Internet Web sites listed in this work may have changed or disappeared between when this work was written and when it is read. Library of Congress Cataloging-in-Publication Data Wysocki, Robert K. Effective project management : traditional, agile, extreme / Robert K. Wysocki. – 5th ed. p. cm. Includes bibliographical references and index. ISBN 978-0-470-42367-7 (paper/website) 1. Project management. I. Title. HD69.P75W95 2009 658.4 04–dc22 2009001889 For general information on our other products and services please contact our Customer Care Department within the United States at (877) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002. Trademarks: Wiley and the Wiley logo 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. Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books.

My mother died before this book was published and I wish to dedicate it to her. She wasn’t an educated person in the sense of formal education. She was able to complete only the 8th grade when the Great Depression brought untold problems on her family. She loved books and knew the importance of a good education. She gave me that same love of books and an education. This is my 17th book, and it is to her that I owe this success.

Wysocki

fauth.tex

V2 - 03/20/2009

3:07pm

About the Author

Robert K. Wysocki, Ph.D., has over 40 years’ experience as a project management consultant and trainer, information systems manager, systems and management consultant, author, training developer and provider. He has written 16 books on project management and information systems management. One of his books, Effective Project Management, 4th Edition, has been a best-seller and is recommended by the Project Management Institute for the library of every project manager. He has over 30 publications and presentations in professional and trade journals and has made more than 100 presentations at professional and trade conferences and meetings. He has developed more than 20 project management courses and trained over 10,000 project managers. In 1990 he founded Enterprise Information Insights, Inc. (EII), a project management consulting and training practice specializing in project management methodology design and integration, Project Support Office establishment, the development of training curriculum, and the development of a portfolio of assessment tools focused on organizations, project teams, and individuals. His clients include AT&T, Aetna, Babbage Simmel, British Computer Society, Boston University Corporate Education Center, Computerworld, Converse Shoes, the Czechoslovakian Government, Data General, Digital, Eli Lilly, Harvard Community Health Plan, IBM, J. Walter Thompson, Novartis, Peoples Bank, Sapient, The Limited, The State of Ohio, Travelers Insurance, Wal-Mart, Wells Fargo, ZTE, and several others. He is a member of the ProjectWorld Executive Advisory Board, the Project Management Institute, the American Society of Training and Development, the International Institute of Business Analysts and the Society of Human Resource Management. He is past Association Vice President of AITP (formerly DPMA). He earned a B.A. in mathematics from the University of Dallas, and an M.S. and Ph.D. in mathematical statistics from Southern Methodist University. vii

Page vii

Wysocki

fauth.tex

V2 - 03/20/2009

3:07pm

Page viii

Wysocki

fcredit.tex

V2 - 03/23/2009

10:42am

Credits

Executive Editor Bob Elliott Senior Development Editor Kevin Kent Technical Editor Brenda Gillingham Production Editor Dassi Zeidel Copy Editor Kathryn Duggan

Vice President and Executive Group Publisher Richard Swadley Vice President and Executive Publisher Barry Pruett Associate Publisher Jim Minatel Project Coordinator, Cover Lynsey Stanford Proofreader Publication Services, Inc.

Editorial Manager Mary Beth Wakefield

Indexer Ted Laux

Production Manager Tim Tate

Cover Designer Ryan Sneed

ix

Page ix

Wysocki

fcredit.tex

V2 - 03/23/2009

10:42am

Page x

Wysocki

f05.tex

V2 - 03/24/2009

3:24pm

Acknowledgments

This acknowledgment is really my special thanks to the teaching faculty of at least 100 universities and colleges all over the globe that have adopted previous editions. Many of them have offered feedback that I find most useful. Many of their suggestions have been incorporated in this fifth edition. I also owe a debt of gratitude to the many consultants and companies across the globe that have used APF and taken the time to comment on their experiences. I am aware of APF being adopted in several industries including banking, insurance, film production, retailing, drug research, distribution, professional services, supply chain management, and logistics. To them I offer my heartfelt thanks. Finally, I owe my heartfelt appreciation to Brenda Gillingham. She has taught from previous editions of this book and is a fulltime consultant at Sun Microsystems. Her help as technical editor was exemplary.

xi

Page xi

Wysocki

f05.tex

V2 - 03/24/2009

3:24pm

Page xii

Contents

Acknowledgments Preface to the Fifth Edition Introduction

xi xxxix xli

Part I

Defining and Using Project Management Process Groups

Chapter 1

What Is a Project? Defining a Project Sequence of Activities Unique Activities Complex Activities Connected Activities One Goal Specified Time Within Budget According to Specification What Is a Program? Establishing Temporary Program Offices Establishing Permanent Program Offices Understanding the Scope Triangle Scope Quality Cost Time Resources Envisioning the Scope Triangle as a System in Balance Managing the Creeps Scope Creep Hope Creep

1 5 6 6 6 7 7 7 7 8 8 8 9 9 9 10 10 10 11 11 12 13 13 14 xiii

xiv

Contents Effort Creep Feature Creep

Chapter 2

14 14

Applying the Scope Triangle Problem Resolution Scope Change Impact Analysis The Importance of Classifying Projects Establishing a Rule for Classifying Projects Classification by Project Characteristics Classification by Project Type Putting It All Together Discussion Questions

15 15 16 16 16 17 18 20 20

Understanding The Project Management Process Groups Understanding the Fundamentals of Project Management What Business Situation Is Being Addressed? What Do You Need to Do? What Will You Do? How Will You Do It? How Will You Know You Did It? How Well Did You Do? Defining the Five Process Groups The Scoping Process Group The Planning Process Group The Launching Process Group The Monitoring and Controlling Process Group The Closing Process Group Defining the Nine Knowledge Areas Mapping Knowledge Areas to Process Groups What the Mapping Means How to Use the Mapping Definition of a Project Management Life Cycle Using Process Groups to Define PMLCs A Look Ahead: Mapping Process Groups to Form Complex PMLCs Integration Management Scope Management Time Management Cost Management Quality Management Quality Planning Process Quality Assurance Process Quality Control Process Human Resource Management Projects as Motivation and Development Tools

21 22 23 24 25 25 25 26 27 27 28 28 29 30 30 30 30 31 31 32 32 32 32 33 33 33 34 34 34 34 35

Contents Communications Management Who Are the Project Stakeholders? What Do They Need to Know about the Project? How Should Their Needs Be Met? Risk Management Risk Identification Risk Assessment Risk Mitigation Risk Monitoring Procurement Management Vendor Solicitation Vendor Evaluation Vendor Selection Vendor Contracting Vendor Management

Chapter 3

xv 39 39 39 40 40 41 42 42 43 44 44 44 45 45 46

Putting It All Together Discussion Questions

46 47

How to Scope a Project Using Tools, Templates, and Processes to Scope a Project Managing Client Expectations Wants versus Needs Conducting Conditions of Satisfaction Establishing Clarity of Purpose Specifying Business Outcomes Conducting COS Milestone Reviews Planning and Conducting the Project Scoping Meeting Purpose Attendees Agenda Deliverables Gathering Requirements What Are Requirements? Types of Requirements Functional Requirements Non-Functional Requirements Global Requirements Product and/or Project Constraints Approaches to Gathering Requirements Building the Requirements Breakdown Structure Using the RBS to Choose a Best-Fit PMLC Model Diagramming Business Processes What Is a Business Process? Creating a Business Process Diagram

49 50 51 52 52 55 56 56 56 56 57 57 58 58 59 60 60 60 60 61 61 63 65 67 68 69

xvi

Contents Business Process Diagram Formats Context Diagrams Business Process Work Flow Diagrams

Prototyping Your Solution Use Cases Use Case Diagrams Use Case Flow of Events Validating the Business Case Outsourcing to Vendors and Contractors Procurement Management Life Cycle Vendor Solicitation Publishing a Request for Information Advertising Renting a Targeted List Asking Previous Vendors Attending Trade Shows Preparing and Distributing a Request for Proposal Managing RFP Questions and Responses Responding to Bidder Questions Vendor Evaluation Establishing Vendor Evaluation Criteria Evaluating Responses to the RFP Vendor Selection Vendor Contracting No Award Single Award Multiple Awards Contract Management Types of Contracts Discussion Points for Negotiating the Final Contract Final Contract Negotiation Vendor Management Expectation Setting — Getting Started Monitoring Progress and Performance Transitioning from Vendor to Client Closing Out a Vendor Contract Writing an Effective Project Overview Statement Parts of the POS Stating the Problem or Opportunity Establishing the Project Goal Defining the Project Objectives Identifying Success Criteria Listing Assumptions, Risks, and Obstacles Attachments

70 71 72

73 73 74 75 76 77 77 78 78 78 78 79 79 79 80 80 81 81 83 83 84 84 84 84 85 85 87 87 88 88 89 90 91 91 93 94 95 97 98 100 102

Contents Risk Analysis Financial Analyses

Chapter 4

102 102

Gaining Approval to Plan the Project Participants in the Approval Process Approval Criteria Project Approval Status Putting It All Together Discussion Questions

104 105 107 107 107 108

How to Plan a Project Tools, Templates, and Processes Used to Plan a Project The Importance of Planning Using Application Software Packages to Plan a Project Determining the Need for a Software Package? Project Planning Tools Sticky Notes Marking Pens Whiteboard How Much Time Should Planning Take? Running the Planning Session Planning and Conducting Joint Project Planning Sessions Planning the JPPS Attendees Facilities Equipment The Complete Planning Agenda Deliverables Conducting the JPPS Building the Work Breakdown Structure Uses for the WBS Thought-Process Tool Architectural-Design Tool Planning Tool Project-Status-Reporting Tool Generating the WBS Top-Down Approach Bottom-Up Approach Using the WBS for Large Projects Iterative Development of the WBS Six Criteria to Test for Completeness in the WBS Status and Completion Are Measurable The Activity Is Bounded The Activity Has a Deliverable Time and Cost Are Easily Estimated

109 111 112 113 113 114 114 115 115 116 116 117 118 119 122 122 122 123 124 124 126 127 127 127 127 128 129 130 131 132 132 133 134 134 134

xvii

xviii

Contents Activity Duration Is Within Acceptable Limits Work Assignments Are Independent The Seventh Criteria for Judging Completeness Exceptions to the Completion Criteria Rule Approaches to Building the WBS Noun-Type Approaches Verb-Type Approaches Organizational Approaches Selecting the Best Approach Representing the WBS

Estimating Estimating Duration Resource Loading versus Task Duration Variation in Task Duration Six Methods for Estimating Task Duration Extrapolating Based on Similarity to Other Activities Studying Historical Data Seeking Expert Advice Applying the Delphi Technique Applying the Three-Point Technique Applying the Wide-Band Delphi Technique Estimation Life Cycles Estimating Resource Requirements People as Resources Resource Breakdown Structure Determining Resource Requirements Resource Planning Estimating Cost Cost Budgeting Cost Control Constructing the Project Network Diagram Envisioning a Complex Project Network Diagram Benefits to Network-Based Scheduling Building the Network Diagram Using the Precedence Diagramming Method Dependencies Constraints Technical Constraints Management Constraints Interproject Constraints Date Constraints Using the Lag Variable Creating an Initial Project Network Schedule Critical Path Near-Critical Path

135 135 136 136 137 138 139 140 141 141

144 145 146 148 149 149 149 150 150 151 152 152 153 154 155 156 157 158 159 160 160 161 161 163 165 167 167 169 169 170 171 171 174 176

Contents Analyzing the Initial Project Network Diagram Compressing the Schedule Management Reserve

Chapter 5

176 177 179

Planning for Project Risk: The Risk Management Life Cycle Risk Identification Risk Categories Candidate Risk Drivers Risk Assessment Static Risk Assessment Dynamic Risk Assessment Risk Mitigation Risk Monitoring and Control Writing an Effective Project Proposal Contents of the Project Proposal Executive Summary Background Objective Overview of the Approach to Be Taken Detailed Statement of the Work Time and Cost Summary Appendices Format of the Project Proposal Gaining Approval to Launch the Project Putting It All Together Discussion Questions

180 181 181 183 183 184 185 187 187 188 189 189 189 189 189 190 190 190 190 190 191 191

How to Launch a Project Tools, Templates, and Processes Used to Launch a Project Recruiting the Project Team Core Team Members When to Select the Core Team Members Selection Criteria Client Team When to Select the Client Team Selection Criteria Contract Team Members Implications of Adding Contract Team Members Selection Criteria Balancing a Team Assimilating Diverging Accommodating Converging Developing a Team Deployment Strategy Developing a Team Development Plan

195 196 197 197 198 198 201 201 201 201 202 202 203 204 204 204 204 205 205

xix

xx

Contents Conducting the Project Kick-Off Meeting Sponsor-Led Part Project Manager–Led Part Purpose of the Project Kick-Off Meeting Attendees Facilities and Equipment The Working Session Agenda Establishing Team Operating Rules Situations that Require Team Operating Rules Problem Solving Decision Making Conflict Resolution Consensus Building Brainstorming Team Meetings Team War Room Physical Layout Variations Operational Uses Managing Scope Changes The Scope Change Management Process Management Reserve Scope Bank Managing Team Communications Establishing a Communications Model Timing Content Choosing Effective Channels Managing Communication beyond the Team Managing Communications with the Sponsor Upward Communication Filtering and ‘‘Good News” Communicating with Other Stakeholders Assigning Resources Leveling Resources Acceptably Leveled Schedule Resource-Leveling Strategies Utilizing Available Slack Shifting the Project Finish Date Smoothing Alternative Methods of Scheduling Tasks Further Decomposition of Tasks Stretching Tasks Assigning Substitute Resources Cost Impact of Resource Leveling

206 206 206 207 207 208 208 211 211 212 214 217 219 220 221 223 223 223 224 224 224 227 229 229 229 230 230 230 233 233 234 235 235 236 238 239 239 239 240 240 240 241 241 242

Contents

Chapter 6

Finalizing the Project Schedule Writing Work Packages Purpose of a Work Package Format of a Work Package Work Package Assignment Sheet Work Package Description Report Putting It All Together Discussion Questions

242 244 245 245 246 247 247 249

How to Monitor and Control a Project Tools, Templates, and Processes Used to Monitor and Control a Project Establishing Your Progress Reporting System Types of Project Status Reports Current Period Reports Cumulative Reports Exception Reports Stoplight Reports Variance Reports How and What Information to Update Frequency of Gathering and Reporting Project Progress Variances Positive Variances Negative Variances Applying Graphical Reporting Tools Gantt Charts Stoplight Reports Burn Charts Milestone Trend Charts Earned Value Analysis Integrating Milestone Trend Charts and Earned Value Analysis Integrating Earned Value Integrating Milestone Trend Data Managing the Scope Bank Building and Maintaining the Issues Log Managing Project Status Meetings Who Should Attend Status Meetings? When Are Status Meetings Held? What Is the Purpose of a Status Meeting? What Is the Status Meeting Format? The 15-Minute Daily Status Meeting Problem Management Meetings Defining a Problem Escalation Strategy

251 252 253 253 254 254 254 254 255 257 259 259 259 260 260 260 261 261 261 265 270 271 271

273 274 275 275 276 276 276 277 278 278

xxi

xxii

Contents Project Manager–Based Strategies Resource Manager–Based Strategies Client-Based Strategies The Escalation Strategy Hierarchy

Chapter 7

Part II Chapter 8

279 279 279 280

Gaining Approval to Close the Project Putting It All Together Discussion Questions

281 281 282

How to Close a Project Tools, Templates, and Processes Used to Close a Project Writing and Maintaining Client Acceptance Procedures Closing a Project Getting Client Acceptance Ceremonial Acceptance Formal Acceptance Installing Project Deliverables Phased Approach Cut-Over Approach Parallel Approach By-Business-Unit Approach Documenting the Project Reference for Future Changes in Deliverables Historical Record for Estimating Duration and Cost on Future Projects, Activities, and Tasks Training Resource for New Project Managers Input for Further Training and Development of the Project Team Input for Performance Evaluation by the Functional Managers of the Project Team Members Conducting the Post-Implementation Audit Writing the Final Report Celebrating Success Putting It All Together Discussion Questions

283 284 284 284 285 285 285 286 286 286 286 287 287 287 287 287 288 288 289 291 292 292 292

Establishing Project Management Life Cycles and Strategies

295

Project Management Landscape Assessing Goal and Solution Clarity and Completeness Traditional Project Management (TPM) Approaches Low Complexity Few Scope Change Requests Well-Understood Technology Infrastructure

297 299 301 302 302 303

Contents Low Risk Experienced and Skilled Project Teams Plan-driven TPM Projects Agile Project Management (APM) Approaches A Critical Problem Without a Known Solution A Previously Untapped Business Opportunity APM Projects Are Critical to the Organization Meaningful Client Involvement Is Essential APM Projects Use Small Co-located Teams Extreme Project Management (xPM) Approaches The xPM Project Is a Research and Development Project The xPM Project Is Very High Risk Emertxe Project Management (MPx) Approaches A New Technology Without a Known Application A Solution Out Looking for a Problem to Solve

Understanding the Complexity/Uncertainty Domain of Projects Requirements Flexibility Adaptability Change Risk vs. the Complexity/Uncertainty Domain Team Cohesiveness vs. the Complexity/Uncertainty Domain Communications vs. the Complexity/Uncertainty Domain Client Involvement vs. the Complexity/Uncertainty Domain The Client’s Comfort Zone Ownership by the Client Client Sign-Off Specification vs. the Complexity/Uncertainty Domain Change vs. the Complexity/Uncertainty Domain Business Value vs. the Complexity/Uncertainty Domain Additional Factors Affecting the Choice of Best-Fit PMLC Model Total Cost Duration Market Stability Technology Business Climate Number of Departments Affected Organizational Environment Team Skills and Competencies Introducing Project Management Life Cycles Traditional Project Management Approaches Linear Project Management Life Cycle Model

303 303 303 304 305 306 306 306 306 307 307 308 308 308 309

309 311 312 313 313 314 314 315 316 317 318 318 319 320 321 322 322 322 322 323 323 323 324 324 324 328 328

xxiii

xxiv

Contents Incremental Project Management Life Cycle Model Agile Project Management Approaches Iterative Project Management Life Cycle Model Adaptive Project Management Life Cycle Model Extreme Project Management Approach Emertxe Project Management Life Cycle Model Recap of PMLC Models Similarities between the PMLC Models Differences between the PMLC Models

Chapter 9

329 330 331 332 332 334 335 336 336

Choosing the Best-Fit PMLC Model Putting It All Together Discussion Questions

336 338 338

Traditional Project Management What Is Traditional Project Management? Linear Project Management Life Cycle Definition Characteristics Complete and Clearly Defined Goal, Solution, Requirements, Functions, and Features Few Expected Scope Change Requests Routine and Repetitive Activities Benefits of Using Established Templates Strengths Entire Project Is Scheduled at the Beginning of the Project Resource Requirements Are Known from the Start The Linear PMLC Model Does Not Require the Most Skilled Team Members Team Members Do Not Have to Be Co-Located Weaknesses Does Not Accommodate Change Very Well Costs Too Much Takes Too Long before Any Deliverables Are Produced Requires Complete and Detailed Plans Must Follow a Rigid Sequence of Processes Is Not Focused on Client Value When to Use a Linear PMLC Model Variations to the Linear PMLC Model The Rapid Linear PMLC Model Feature-Driven Development Linear PMLC Model Considerations in Choosing a Variation Adapting and Integrating the Tools, Templates, and Processes for Maximum Effectiveness Incremental Project Management Life Cycle Definition

341 342 343 343 344 344 345 345 348 349 349 349 350 350 350 351 351 351 351 353 353 353 353 354 355 356 357 357 358

Contents Characteristics Strengths Produces Business Value Early in the Project Enables You to Better Schedule Scarce Resources Can Accommodate Minor Scope Change Requests Between Increments Offers a Product Improvement Opportunity More Focused on Client Value Than the Linear PMLC Model Weaknesses The Team May Not Remain Intact Between Increments This Model Requires Handoff Documentation Between Increments The Model Must Follow a Defined Set of Processes You Must Define Increments Based on Function and Feature Dependencies Rather Than Business Value You Must Have More Client Involvement Than Linear PMLC Models An Incremental PMLC Model Takes Longer Than the Linear PMLC Model Partitioning the Functions May Be Problematic When to Use an Incremental PMLC Adapting and Integrating the Tools, Templates, and Processes for Maximum Effectiveness

Putting It All Together Discussion Questions Chapter 10 Using Critical Chain Project Management What Is the Critical Chain? Variation in Duration: Common Cause versus Special Cause Statistical Validation of the Critical Chain Approach The Critical Chain Project Management Approach Step 1: Creating the Early Schedule Project Network Diagram Step 2: Converting the Early Schedule to the Late Schedule and Adding Resources Step 3: Resolving Resource Conflicts Establishing Buffers Defining Buffers Types of Buffers Project Buffers Feeding Buffers Resource Buffers Other Buffers Using Buffers Managing Buffers

359 359 359 359 360 360 360 360 361 361 361 362 363 363 363 364 364 365 367

369 370 370 371 373 373 374 374

375 375 376 376 376 376 376 377 377

xxv

xxvi

Contents Penetration into the First Third of the Buffer Penetration into the Middle Third of the Buffer Penetration into the Final Third of the Buffer

Track Record of Critical Chain Project Management Putting It All Together Discussion Questions Chapter 11 Agile Project Management What Is Agile Project Management? Implementing APM Projects Fully Supported Production Versions of Partial Solutions Are Released to the End User Quarterly or Semi-Annually Intermediate Versions Are Released to a Focus Group Every 2–4 Weeks Co-Located APM Project Teams Cross-Project Dependencies Project Portfolio Management Iterative Project Management Life Cycle Definition of the Iterative PMLC Model Most of the Solution Is Clearly Known Likely to be Multiple Scope Change Requests Concern about Lack of Client Involvement Scoping Phase of an Iterative PMLC Model Planning Phase of an Iterative PMLC Model The Complete Plan for Building the Known Solution The Partial Plan for the High-Priority Functions Launching Phase of an Iterative PMLC Model Monitoring and Controlling Phase of an Iterative PMLC Model Closing Phase of an Iterative PMLC Model Characteristics The Solution Is Known, But Not to the Expected Depth Often Uses Iconic or Simulated Prototypes to Discover the Complete Solution Strengths Client Reviews Current Partial Solution for Improvement Can Process Scope Changes Between Iterations Adaptable to Changing Business Conditions Weaknesses Requires a More Actively Involved Client Than TPM projects Requires Co-Located Teams Difficult to Implement Intermediate Solutions Final Solution Cannot Be Defined at the Start of the Project

378 378 378

380 381 381 383 385 386

386 387 387 388 388

390 390 391 391 392 392 392 393 393 394 394 395 395 395 395 395 396 396 396 396 396 397 397 397

Contents Types of Iterative PMLC Models Prototyping PMLC Model Rational Unified Process (RUP) When to Use an Iterative PMLC Model Intuitive to the Client Easily Engages the Client Immediate Feedback on the Effect of Solution Change Tolerant of Assessing and Evaluating the Impact of Alternatives No Fixed Deadline for Completion

Adaptive Project Management Life Cycle Definition Scoping Phase of an Adaptive PMLC Model Planning Phase of an Adaptive PMLC Model Launching Phase of an Adaptive PMLC Model Monitoring and Controlling Phase of an Adaptive PMLC Model Closing Phase of an Adaptive PMLC Model Characteristics Iterative Structure Just-in-Time Planning Critical Mission Projects Thrives on Change through Learning and Discovery Strengths Does Not Waste Time on Non-Value-Added Work Avoids All Management Issues Processing Scope Change Requests Does Not Waste Time Planning Uncertainty Provides Maximum Business Value Within the Given Time and Cost Constraints Weaknesses of the Adaptive PMLC Model Must Have Meaningful Client Involvement Cannot Identify Exactly What Will Be Delivered at the End of the Project Types of Adaptive PMLC Models Adaptive Software Development (ASD) Adaptive Project Framework Client Situation Goal Objectives Solution Phase I: Needs Analysis Phase II: PMM High-level Design Phase III: PMM Detailed Design and Documentation Phase IV: PMM Implementation

397 398 400 403 403 403 404 404 404

404 404 406 406 407 407 408 408 409 409 409 409 409 410 410 410 410 411 411 411 411 412 414

444 444 444 444 445 445 445 446

xxvii

xxviii

Contents Phase V: PMM Training Program Business Value and Selected Success Criteria Roles and Responsibilities Project Schedule Dynamic Systems Development Method (DSDM) Scrum When to Use an Adaptive PMLC Model Has the Client Had Successful Adaptive Project Experience Before? Will this First-Time Adaptive Project Client Be Meaningfully Involved? Has the Client Appointed a Qualified Co-Project Manager? Adapting and Integrating the APM Toolkit Scoping the Next Iteration/Cycle Planning the Next Iteration/Cycle Launching the Next Iteration/Cycle Monitoring and Controlling the Next Iteration/Cycle Closing the Next Iteration/Cycle Deciding to Conduct the Next Iteration/Cycle Closing the Project Putting It All Together Discussion Questions Chapter 12 Extreme Project Management What Is Extreme Project Management? Extreme Project Management Life Cycle Definition Characteristics High Speed High Change High Uncertainty Strengths Keeps Options Open as Late as Possible Offers an Early Look at a Number of Partial Solutions Weaknesses May Be Looking for Solutions in All the Wrong Places No Guarantee That Any Business Value Will Result from the Project Deliverables INSPIRE Extreme PMLC Model INitiate SPeculate Incubate REview What Is Emertxe Project Management?

446 447 447 448 449 450 454 454 455 456

456 456 457 458 458 459 459 459 460 460 463 464 464 464 465 465 465 466 466 466 466 466 467 467 467 469 473 477 479

480

Contents The Emertxe Project Management Life Cycle When to Use an Emertxe PMLC Model Research and Development Projects Problem-Solution Projects

Part III

481 481 481 481

Using the Tools, Templates, and Processes for Maximum xPM Effectiveness Scoping the Next Phase Planning the Next Phase Launching the Next Phase Monitoring and Controlling the Next Phase Closing the Phase Deciding to Conduct the Next Phase Closing the Project Putting It All Together Discussion Questions

482 482 483 484 484 485 485 485 485 485

Building an Effective Project Management Infrastructure

489

Chapter 13 Establishing and Maturing a Project Support Office Background of the Project Support Office Defining a Project Support Office Temporary or Permanent Organizational Unit Portfolio of Services Specific Portfolio of Projects Naming the Project Support Office Establishing Your PSO’s Mission Framing PSO Objectives Exploring PSO Support Functions Project Support Consulting and Mentoring Methods and Standards Software Tools Training Staffing and Development Project Manager Resources Project Team Members Selecting PSO Organizational Structures Virtual versus Real Proactive versus Reactive Temporary versus Permanent Program versus Projects Enterprise versus Functional Hub-and-Spoke Understanding the Organizational Placement of the PSO

491 492 493 494 494 495 496 497 498 498 499 499 500 501 502 503 504 504 505 505 506 506 506 507 507 507

xxix

xxx

Contents Determining When You Need a Project Support Office The Standish Group Report User Involvement Executive Management Support Clear Business Objectives Agile Optimization Emotional Maturity Project Management Expertise Financial Management Skilled Resources Formal Methodology Tools and Infrastructure Spotting Symptoms That You Need a PSO Establishing a PSO PSO Stages of Maturity Growth Level 1: Initial Level 2: Repeatable Level 3: Defined Level 4: Managed Level 5: Optimized Planning a PSO The POS Planning Steps Facing the Challenges of Implementing a PSO Speed and Patience Leadership from the Bottom Up A Systems Thinking Perspective Enterprise-Wide Systems Knowledge Management Learning and Learned Project Organizations Open Communications Putting It All Together Discussion Questions

509 509 510 511 511 512 512 512 513 513 513 513 514 516 516 517 517 517 518 518 518 518 521 528 529 529 529 529 529 530 530 530 530

Chapter 14 Establishing and Managing a Project Portfolio Management Process Introduction to Project Portfolio Management Portfolio Management Concepts What Is a Portfolio Project? What Is a Project Portfolio? What Is Project Portfolio Management? The Project Portfolio Management Life Cycle ESTABLISH a Portfolio Strategy Strategic Alignment Model Boston Consulting Group Products/Services Matrix

533 534 534 534 535 536 536 538 539 541

Contents Project Distribution Matrix Growth versus Survival Model Project Investment Categories Model Choosing Where to Apply These Models EVALUATE Project Alignment to the Portfolio Strategy PRIORITIZE Projects and Hold Pending Funding Authorization Forced Ranking Q-Sort Must-Do, Should-Do, Postpone Criteria Weighting Paired Comparisons Model Risk/Benefit SELECT a Balanced Portfolio Using the Prioritized List Balancing the Portfolio Strategic Alignment Model and Weighted Criteria Project Distribution Matrix and Forced Ranking Model Graham-Englund Selection Model and the Risk/Benefit Matrix Balancing Using Partial Funding or Staffing of Projects MANAGE the Active Projects Project Status The Role of the Project Manager Reporting Portfolio Performance Schedule Performance Index and Cost Performance Index SPI and CPI Trend Charts Spotting Out-of-Control Situations Closing Projects in the Portfolio Attainment of Explicit Business Value Lessons Learned

Roles and Responsibilities of the PSO in Portfolio Management Project Sponsor Portfolio Manager Proposal Intake and Evaluation Project Prioritization Selection Support to the Portfolio Manager Monitoring and Reporting to the Portfolio Manager Facilitate Project Review Sessions Preparing Your Project for Submission to the Portfolio Management Process A Revised Project Overview Statement Parts of the POS POS Attachments A Two-Step Submission Process

542 544 544 545 546 546 547 548 548 549 550 551 553 553 554 556 558 562 562 563 564 564 565 565 565 569 569 570

570 570 571 571 571 571 571 571 572 572 573 575 576

xxxi

xxxii

Contents A New Submission Process

Agile Project Portfolio Management Putting It All Together Discussion Questions Chapter 15 Establishing and Managing a Continuous Process Improvement Program Understanding Project Management Processes and Practices The Project Management Process How Was It Developed? How Complete Is It? How Is It Documented? How Is It Supported? How Is It Updated? The Practice of the Project Management Process Are All Project Managers Required to Use the Process? Can Project Managers Substitute Other Tools, Templates, and Processes as They Deem Appropriate? Is There a Way to Incorporate Best Practices into the Practice of the Project Management Process? How Are Project Managers Monitored for Compliance? How Are Corrective Action Steps Taken to Correct for Noncompliance? How Are Project Manager Practices Monitored for Best Practices? Defining Process and Practice Maturity Level 1: Ad hoc or Informal Level 2: Documented Processes Level 3: Documented Processes That Everyone Uses Level 4: Integrated into Business Processes Level 5: Continuous Improvement Measuring Project Management Process and Practice Maturity The Process Quality Matrix and Zone Map What Process Has Been Defined So Far? Step 1: Define the Process Step 2: Validate and Finalize the PQM Step 3: Establish Correlations Step 4: Establish Metrics Step 5: Assess Project Managers against the PMMA Step 6: Assess Maturity Levels Step 7: Plot Results on the PQM Zone Map Using the Continuous Process Improvement Model Phase 1: Foundation Develop Mission/Vision Statement

576

578 580 580 583 584 585 585 585 585 586 586 586 586 587 587 587 587 587 588 589 589 589 590 590

591 591 595 596 596 596 596 597 597 597 597 597 598

Contents Identify CSFs Identify Business Processes Relate CSFs to Business Processes Phase 2: Assessment and Analysis Conduct Gap Analysis Select Knowledge Area or PM Process Identify Improvement Opportunities Analyze Improvement Opportunities Phase 3: Improvement Initiatives Define the Project Scope Plan Project Activities Schedule Project Work Monitor Project Progress Phase 4: Check Results

Part IV

599 599 599 599 600 600 600 601 601 602 602 602 602 602

Defining Roles and Responsibilities of the PSO Realizing the Benefits of Implementing a CPIM Applying CPIM to Business Processes Characteristics of Business Processes Process Effectiveness Process Efficiency Streamlining Tools Watching Indicators of Needed Improvement Documenting the ‘‘As Is” Business Process Envisioning the ‘‘To Be” State Defining the Gap between ‘‘As Is” and ‘‘To Be” Defining a Business Process Improvement Project Using Process Improvement Tools, Templates, and Processes Fishbone Diagrams and Root Cause Analysis Control Charts Flowcharting Histograms Pareto Analysis Run Charts Scatter Diagrams Force Field Analysis Trigger Values Putting It All Together Discussion Questions Basic Flow of Placing an Order

603 603 604 605 605 606 606 609 609 610 610 610 611 612 615 615 616 617 618 619 620 622 622 623 623

Managing the Realities of Projects

625

Chapter 16 Managing Distressed Projects What Is a Distressed Project?

627 628

xxxiii

xxxiv

Contents Why Projects Become Distressed or Fail Poor, Inadequate, or No Requirements Documentation Inappropriate or Insufficient Sponsorship Complexity of Requirements Not Recognized Unwillingness to Make Tough Decisions Lag Time between Project Approval and Kick-Off No Plan Revision after Significant Cuts in Resources or Time Estimates Done with Little Planning or Thought Overcommitment of Staff Resources Inconsistent Client Sign-Off No Credibility in the Baseline Plan Unmanageable Project Scope

629 629 629 629 630 630

Managing Distressed Projects Prevention Management Strategies Using Tools, Templates, and Processes to Prevent Distressed Projects Requirements Gathering WBS Construction Dynamic Risk Management Process Scope Change Management Process Milestone Trend Charts Earned Value Analysis Intervention Management Strategies Analyze Current Situation: Where Are We? Revise Desired Goal: Where Can We Go? Evaluate Options: How Can We Get There? Generate Revised Plan: How Will We Get There? Roles and Responsibilities of the PSO with Respect to Distressed Projects Analyzing the Current Situation Revising the Desired Goal Evaluating the Options Generating the Revised Plan Putting It All Together Discussion Questions

632 632

Chapter 17 Managing Multiple Team Projects What Is a Multiple Team Project? Challenges to Managing a Multiple Team Project Working with Fiercely Independent Team Cultures Working with Different Team Processes Accommodating Competing Priorities Communicating within the Team Structure Establishing a Project Management Structure

630 631 631 631 631 631

632 633 634 634 635 636 637 639 639 644 647 649

650 652 652 652 653 653 653 655 655 657 658 658 659 659 659

Contents Establishing One Project Management Life Cycle Building an Integrated Project Plan and Schedule Defining a Requirements Gathering Approach Establishing a Scope Change Management Process Defining the Team Meeting Structure Establishing Manageable Reporting Levels Sharing Resources across Teams Searching Out Your Second

Classifying Multiple Team Projects Two Teams Update or Enhance and Global New and Global Multiple Teams Update or Enhance Update or Enhance and Global New New and Global Project Office Structure Project Office Characteristics Organize and Manage the Entire Project Develop the High-Level Project Plan in Collaboration with Team Managers Integrate and Coordinate the Project Plans of Each Team Maintain the Overall Project Schedule Monitor and Manage Resource Use Prepare and Distribute Project Status Reports Plan and Conduct Team Meetings Process Scope Change Requests Solve Problems Escalated from the Individual Project Teams Negotiate and Resolve Problems between Teams Project Office Strengths Coordinates the Work of Several Independent Teams Scales to Large Projects Managed from a Single Integrated Plan Integrated Resource Management Control Allows Teams to Maintain Their Practices Project Office Weaknesses Requires Management Across Disparate Practices Requires Team Members to Manage Competing Priorities May Involve a Cumbersome Scope Change Management Process When to Use a PO Core Team Structure Core Team Characteristics

659 660 660 661 661 661 662 662

662 662 663 663 663 663 664 664 664 664 665 666 666 666 666 666 666 667 667 667 667 667 667 668 668 668 668 669 669 669 669 670

670 670

xxxv

xxxvi

Contents Advise Each Team on Technical Matters Provide Subject Matter Expertise on Enterprise Systems and Processes Support Each Team as Requested and as Needed Collaborate with and Advise the CT Manager as Requested Negotiate and Help Resolve Inter-Team Problems Core Team Strengths Enables the CT Manager to Select CT Members Provides the Best Available Advice to the CT Manager Coordinates the Work of Several Teams Lends Support and Credibility to the Decisions of the CT Manager Assigns Core Team Members 100 Percent to This Project Takes Advantage of the Most Experienced SMEs Allows Teams to Retain Their Business Unit Practices Core Team Weaknesses May Not Scale to the Larger Projects Does Not Necessarily Integrate Individual Team Plans Must Manage across Disparate Practices How to Deal with Divided Loyalties Repeatedly Uses the Same SMEs When to Use a CT

Super Team Structure Super Team Characteristics Organize and Manage the Project Develop the Project Plan Maintain the Overall Project Schedule Monitor and Manage Resource Utilization Prepare and Distribute Project Status Reports Plan and Conduct Team Meetings Process Scope Change Requests Super Team Strengths Manages from a Single Integrated Source Scales to Large Projects Integrates Resource Management Control Standardizes on a Set of Tools, Templates, and Processes Super Team Weaknesses The Difficulty in Establishing Standardization Team Members Have to Decide among Competing Priorities When to Use an ST Putting It All Together Discussion Questions

671 673 673 673 673 673 674 674 674 674 674 675 675 675 675 676 676 676 676 676

677 678 679 680 680 680 680 680 680 681 681 681 681 681 682 682 682 682

683 684

Contents Epilogue: Putting It All Together Finally What Business Situation Is Being Addressed? What Do You Need To Do? Experience Acquisition On-the-job Training Off-the-job Training Professional Activities What Will You Do? How Will You Do It? How Will You Know You Did It? How Well Did You Do? Where Do You Go from Here? — A New Idea to Consider The PM/BA Position Family Team Member Task Manager Associate Manager Senior Manager Program Manager Director Using the PM/BA Landscape for Professional Development What Might a Professional Development Program Look Like? Experience Acquisition On-the-Job Training Off-the-Job Training Professional Activities Using the PDP Career Planning Using the BA/PM Landscape Putting It All Together

685 686 686 686 687 687 687 688 688 688 688 688 689 692 692 693 694 695 696 697 697 698 699 699 699 700 701 703

Appendix A What’s on the Web Site?

705

Appendix B Bibliography

707

Index

719

xxxvii

Wysocki

fpref.tex

V2 - 03/24/2009

3:25pm

Page xxxix

Preface to the Fifth Edition

All four of the previous editions of Effective Project Management (EPM) have been successful and have grown in value from the feedback I have received from them. With the help and support of John Wiley & Sons we have branded Effective Project Management. I’m seeing others play off that name recognition, and I am encouraged. I am aware of over 100 colleges and universities worldwide that have adopted EPM. Their feedback and that of the professional market has been overwhelmingly supportive of my practical and easy to read format. Effective Project Management, Fifth Edition (EPM5) continues to meet the needs of higher education and the professional markets. I’ve been anxious to offer you this fifth edition because it is no exception. I’ve taken the opportunity to completely reorganize Effective Project Management, Fourth Edition (EPM4). That reorganization begins with a new subtitle. You will note that I have replaced Adaptive with Agile. I see Adaptive and Iterative project management as belonging to the class of Agile Project Management approaches and will further develop it as such. The new organization of EPM5 topics fits my understanding of the project management discipline perfectly. I’ve wanted to do this for quite some time and now is the time to act. There are a number of changes and additions throughout. Perhaps the most significant is the addition of several chapters on the contemporary project landscape. I’ve also added two new chapters: a chapter on project process and practice improvement programs and a chapter on prevention and intervention strategies for distressed projects. Both are important to a complete understanding of effective project management. Even after this fifth edition goes to press I still view EPM as a work in process. As I gain further experience with its use and as I hear about the experiences of clients, trainers, faculty and project management professionals, the work will undoubtedly improve. You might say that the development of xxxix

Wysocki

xl

fpref.tex

V2 - 03/24/2009

Preface to the Fifth Edition

EPM5 and its successor editions is an agile project. The goal is to produce a perfectly intuitive and common sense approach to project management. The solution however continues to be elusive. But we are converging on that solution with every edition of EPM! I would like to think that this edition offers you a complete view of effective project management as it is now practiced and how I believe it should be practiced in the very near future. The training and higher education market has been a strong market for EPM. In response to numerous requests from trainers and teaching faculty for a slide presentation, I have added that to the web site (accessible at www.wiley.com/go/epm5e). That slide presentation is a cradle to grave mirror image of the text. You can use it right out of the box to teach EPM, or you might want to modify it to fit your specific needs. The professional reference market has been equally strong. In response to numerous requests from practicing professionals I have expanded the coverage of contemporary approaches to project management. My clients have been a constant source of input. Their guidance has been invaluable to me. From them I have learned about implementation experiences and ways to improve my presentation of the processes and practices of contemporary project management. Thank you again for adding my book to your project management library. If you have any questions or would just like to comment, please let me hear from you at [email protected]. You have my promise that I will quickly respond personally to each and every communiqu´e. Enjoy! Robert K. Wysocki, Ph.D.

3:25pm

Page xl

Wysocki

flast.tex

V2 - 03/23/2009

10:44am

Introduction

Effective Project Management: Traditional, Agile, Extreme, Fifth Edition (EPM5) represents a significant change from the Fourth Edition. All of the pedagogical and organizational strengths of EPM4 are retained and expanded in EPM5. EPM5 offers five different project management life cycle (PMLC) models: (Linear, Incremental, Iterative, Adaptive, and Extreme) to managing a project. The choice of the best-fit PMLC is based on the characteristics of the project and the business and organizational environment in which the project will be undertaken. These approaches recognize that there are major differences among projects and that those differences require different management approaches if the project is to be managed and successfully completed. We commonly define a project as a unique experience that has never happened before and will never happen again under the same set of circumstances. So, then why don’t we define the management of such projects the same way? There are a number of factors affecting the choice of PMLC and the adaptation of those models as the project unfolds and conditions change. This is the approach I have taken for years and have been successful beyond the statistics on failure that we are all familiar with. I hope to convince you of the benefits of that view in this book. Forty years of experience managing projects of all types has led me to this conclusion. I want to share my thinking with you and convince you to follow my lead.

The Contemporary Project Environment The contemporary project environment is characterized by high speed, high change, lower costs, complexity, uncertainty, and a host of other factors. This presents a daunting challenge to the project manager as is described in the sections that follow. xli

Page xli

Wysocki

xlii

flast.tex

V2 - 03/23/2009

Introduction

High Speed The faster products and services get to market the greater will be the resulting value to the business. Current competitors are watching and responding to unmet opportunities, and new competition is waiting and watching to seize upon any opportunity that might give them a foothold or expansion in the market. Any weakness or delay in responding may just give them that advantage. This need to be fast translates into a need for the project management approach to not waste time — to rid itself as much as possible of spending time on non-value-added work. Many of the approaches you will study are built on that premise. The window of opportunity is narrowing and constantly moving. Organizations that can quickly respond to those opportunities are organizations that have found a way to reduce cycle times and eliminate non-value-added work as much as possible. Taking too long to roll out a new or revamped product can result in a missed business opportunity. Project managers must know how and when to introduce multiple release strategies and compress project schedules to help meet these requirements. Even more importantly, the project management approach must support these aggressive schedules. That means that these processes must protect the schedule by eliminating all non-value-added work. You simply cannot afford to burden your project management processes with a lot of overhead activities that do not add value to the final deliverables or that may compromise your effectiveness in the markets you serve. Effective project management is not the product of a rigid or fixed set of steps and processes to be followed on every project. Rather the choice of project management approach is based on having done due diligence on the project specifics and defined an approach that makes sense. I will spend considerable time on these strategies in later chapters.

High Change Clients are often making up their minds or changing their minds about what they want. The environment is more the cause of high change than is any ignorance on the part of the client. The business world is dynamic. It doesn’t stand still just because you are managing a project. The best-fit project management approach must recognize the realities of frequent change, accommodate it, and embrace it. The extent to which change is expected will affect the choice of a best-fit PMLC model. Change is constant! I hope that does not come as a surprise to you. Change is always with you and seems to be happening at an increasing rate. Every day you face new challenges and the need to improve yesterday’s practices. As John Naisbitt says in The Third Wave, ‘‘Change or die.’’ For experienced project

10:44am

Page xlii

Wysocki

flast.tex

V2 - 03/23/2009

10:44am

Introduction

managers as well as ‘‘wannabe’’ project managers, the road to breakthrough performance is paved with uncertainty and with the need to be courageous, creative, and flexible. If you simply rely on a routine application of someone else’s methodology, you are sure to fall short of the mark. As you will see in the pages that follow, I have not been afraid to step outside the box and outside my comfort zone. Nowhere is there more of a need for change and adaptation than in the approaches we take to managing projects.

Lower Cost With the reduction in management layers (a common practice in many organizations) the professional staff needs to find ways to work smarter, not harder. Project management includes a number of tools and techniques that help the professional manage increased workloads. Your staffs need to have more room to do their work in the most productive ways possible. Burdening them with overhead activities for which they see little value is a sure way to failure. In a landmark paper ‘‘The Coming of the New Organization’’ (Harvard Business Review, January/February 1988), written 20 years ago but still relevant, Peter Drucker depicts middle managers as either ones who receive information from above, reinterpret it, and pass it down or ones who receive information from below, reinterpret it, and pass it up the line. Not only is quality suspect because of personal biases and political overtones, but also the computer is perfectly capable of delivering that information to the desk of any manager who has a need to know. Given these factors, plus the politics and power struggles at play, Drucker asks why employ middle managers? As technology advances and acceptance of these ideas grows, we have seen the thinning of the layers of middle management. Do not expect them to come back; they are gone forever. The effect on project managers is predictable and significant. Hierarchical structures are being replaced by organizations that have a greater dependence on projects and project teams, resulting in more demands on project managers.

Increasing Levels of Complexity All of the simple problems have been solved. Those that remain are getting more complex with each passing day. At the same time that problems are getting more complex, they are getting more critical to the enterprise. They must be solved. We don’t have a choice. Not having a simple recipe for managing such projects is no excuse. They must be managed, and we must have an effective way of managing them. This book shows you how to create common sense project management approaches adapting a common set of tools, templates and processes to even the most complex of projects.

xliii

Page xliii

Wysocki

xliv

flast.tex

V2 - 03/23/2009

Introduction

More Uncertainty With increasing levels of complexity comes increasing levels of uncertainty. The two are inseparable. Adapting project management approaches to handle uncertainty means that the approaches must not only accommodate change but also embrace it and become more effective as a result of it. Change is what will lead the team and the client to a state of certainty with respect to a viable solution to its complex problems. In other words we must have project management approaches that expect change and benefit from it.

Challenges to Effective Project Management As discussed earlier in this introduction the contemporary project environment presents the project manager and the client with a number of challenges to managing such projects effectively. The use of the best-fit PMLC model will rise to these challenges and adapt as necessary.

Flexibility and Adaptability Traditional Project Management (TPM) practices were defined and matured in the world of the engineer and construction professional where the team expected (and got, or so it thought) a clear statement from clients as to what they wanted, when they wanted it, and how much they were willing to pay for it. All of this was delivered to the project manager wrapped in a neat package. The ‘‘i’’s were all dotted, and the ‘‘t’’s were all crossed. All the correct forms were filed, and all the boxes were filled with the information requested. Everyone was satisfied that the request was well documented and that the deliverables were sure to be delivered as requested. The project team clearly understood the solution they would be expected to provide, and they could clearly plan for its delivery. That describes the naive world of the embryonic project manager until the 1950s. By the mid-1950s the computer was well on its way to becoming a viable commercial resource, but it was still the province of the engineer. Project management continued as it had under the management of the engineers. The first sign that change was in the wind for the project manager arose in the early 1960s. The use of computers to run businesses was now a reality, and we began to see position titles like programmer, programmer/analyst, systems analyst, and primitive types of database architects emerging. These professionals were really engineers in disguise, and somehow, they were expected to interact with the business and management professionals (who were totally mystified by the computer and the mystics that could communicate with it) to design and implement business applications systems to replace

10:44am

Page xliv

Wysocki

flast.tex

V2 - 03/23/2009

10:44am

Introduction

manual processes. This change represented a total metamorphosis of the business world and the project world, and we would never look back. In the face of this transformation into an information society, TPM wasn’t showing any signs of change. To the engineers, every IT project management problem looked like a nail, and they had the hammer. In other words, they had one solution, and it was supposed to fit every problem. One of the major problems that TPM faced, and still faces, is the difference between wants and needs. If you remember anything from this introduction, remember that what the client wants is probably not what the client needs. If the project manager blindly accepts what the clients say they want and proceeds with the project on that basis, the project manager is in for a rude awakening. Often in the process of building the solution, the client learns that what they need is not the same as what they requested. Here you have the basis for rolling deadlines, scope creep, and an endless trail of changes and reworks. It’s no wonder that 70-plus percent of projects fail. That cycle has to stop. You need an approach that is built around change — one that embraces learning and discovery throughout the project life cycle. It must have built-in processes to accommodate the changes that result from this learning and discovery. I have talked with numerous project managers over the past several years about the problem of a lack of clarity and what they do about it. Most would say that they deliver according to the original requirements and then iterate to improve the solution one or more times before they satisfy the client’s current requirements. I asked them, ‘‘If you know you are going to iterate, why don’t you use an approach that has that feature built in?’’ Until recently with the emergence of agile project management approaches the silence in response to that question has been deafening. All of the agile and extreme approaches to project management emerging in practice are built on the assumption that there will be changing requirements as the client gains better focus on what they actually need. Sometimes those needs can be very different than their original wants. Obviously, this is no longer your father’s project management. The Internet and an ever-changing array of new and dazzling technologies have made a permanent mark on the business landscape. Technology has put most businesses in a state of confusion. How should a company proceed to utilize the Internet and extract the greatest business value? Businesses are asking even the more basic questions — ‘‘What business are we in?’’ ‘‘How do we reach and service our customers?’’ ‘‘What do our customers expect?’’ The dot.com era began quickly with a great deal of hyperbole and faded just as quickly. A lot of companies came into existence on the shoulders of highly speculative venture capital in the 1990s and went belly up by the end of the century. Only a few remain, and even their existence is tenuous. The current buzzwords e-commerce, e-business, and knowledge management have replaced B2B and B2C, and businesses seem to be settling down. But we are still a long way from recovery.

xlv

Page xlv

Wysocki

xlvi

flast.tex

V2 - 03/23/2009

Introduction

The question on the table is this: ‘‘What impact should this have on your approach to project management?’’ The major impact should be that project management approaches must align with the business of the enterprise. Project management needs to find its seat at the organization’s strategy table. Project managers must first align to the needs of the organization rather than their own home department. That is today’s critical success factor. The appearance of the business analyst has added new challenges as discussed in the next section.

Deep Understanding of the Business and Its Systems The best project managers understand the business context in which project deliverables must be defined, produced, and function. This means not only an understanding of the internal systems and their interaction but also the external systems environment of suppliers and customers in whose environments the deliverables must function. The systems analyst and business analyst are key components in that understanding. There is a good argument that can be offered for the morphing of the project manager and the business analyst into one professional having the requisite skills and competencies of both. That discussion is out of scope for this book but it is a discussion that needs to take place. For a series of articles that I wrote on this morphing of the project manager and the business analyst, a series that others have since commented on, see the Business Analyst Times.

Take Charge of the Project and Its Management I like simplicity, and I believe my definition of the project landscape using only two variables — goal and solution — with two values each — clear and not clear — is simple yet all inclusive of all projects. The result is four categories of projects. When the goal and solution are clear, it generates the Traditional Project Management (TPM) category. When the goal is clear but the solution is not, it generates the Agile Project Management (APM) category. When neither the goal nor the solution is clear, it generates the Extreme Project Management (xPM) category. And finally when the goal is not clear but solution is, it generates the Emertxe Project Management (MPx) category (while this may seem nonsensical; it is not — more on this one later). Every project that has ever existed or will exist falls into one and only one of these four categories. Each category gives rise to a PMLC, and each PMLC has at least one specific project management approach in it. This four category

10:44am

Page xlvi

Wysocki

flast.tex

V2 - 03/23/2009

10:44am

Introduction xlvii

classification gives rise to five PMLC models. It is these models — their recognition and use — that is the subject of this book.

Project Management Is Organized Common Sense The PMBOK definition of project management is crisp, clean, and clearly stated. It has provided a solid foundation on which to define the process groups and processes that underlie all project management. But I think there is another definition that transcends the PMBOK definition and is far more comprehensive of what project management entails. I offer that definition as nothing more than organized common sense. Projects are unique, and each one is different than all others that have preceded it. That uniqueness requires a unique approach that continually adapts as new characteristics of the project emerge. These characteristics can and do emerge anywhere along the project life cycle. Being ready for them and adjusting as needed means that we must be always attentive to doing what makes the most sense given the circumstances. Hence, project management is nothing more than organized common sense. We are not in Kansas anymore! The discipline of project management has morphed to a new state, and as this book is being written, that state is not yet a steady one. It may never be. What does all of this mean to the struggling project manager? To me the answer is obvious. You must open your minds to the basic principles on which project management is based so as to accommodate change and avoid wasted dollars and wasted time. For as long as I can remember, I and my colleagues have been preaching that one size does not fit all. The characteristics of the project suggest what subset of the traditional approach should be used on the project. This concept has to be extended to also encompass choosing the best-fit PMLC model based on the characteristics of the project at hand. For the interested reader you can learn more about this new mindset in my recent book Effective Software Project Management (Wiley, 2006). In that book I define a new discipline — one that fully integrates PMLCs and systems development life cycles (SDLCs) into a strategy that I have called a Software Development Project Methodology (SDPM). The result is an approach that aligns with the needs of the client, the enterprise, and the project.

Why I Wrote This Book I believe a number of professionals and practitioners are looking for some help. I am trying to fill their needs with this book. When scheduled training is not available or practical, my book can help. It is written to be studied. It is written to guide you as you learn about project management. It is written to

Page xlvii

Wysocki

flast.tex

V2 - 03/23/2009

10:44am

xlviii Introduction

be a self-paced resource, one that will immerse you in managing a project for a simulated company. Let it work with you through the entire project life cycle. On a more altruistic level, I have four reasons for writing this fifth edition: I’ve learned a lot about contemporary project management since the publication of EPM4 in December of 2006. Experience with my clients has made me rethink how we should explain the ever-changing discipline of project management and how we should approach the education and training of project managers. EPM4 did a good job of that. However, there is much more to be said, and EPM5 fills that gap. To come to the rescue of the discipline of project management. I believe that it is seriously out of alignment with the needs of our businesses. Project managers are trapped and need some alternatives and a working knowledge of their use. The high failure rates of projects are evidence of that misalignment. The problem is that project management is the hammer, and all projects are seen as nails. This is a one-size-fits-all approach to project management, and it simply doesn’t work. The nature and characteristics of the project must dictate the type of management approach to be taken. Anything short of that will fail. As I have already shown, projects have fundamentally changed, but our approach to managing them has not changed much. We need a more robust approach to project management — one that recognizes the project environment and adapts accordingly. To further document Adaptive Project Framework (APF). APF is really a hybrid that takes the best from TPM and xPM. It is an agile approach that works for all types of projects rather than just for software development projects as do most other agile approaches. It breaches the gap between projects with a clearly defined goal and solution and projects where the goal and the solution are not clearly defined. The work that I report here is a work in progress. APF has been adopted as the de facto agile model for several large and small companies. By putting it before my colleagues, I expect that others will contribute to its further maturation and application. My continual challenge to offer a practical how-to guide for project managers in the management of all of their projects. My style is applications-oriented. While the book is based on sound concepts and principles of project management, it is by no means a theoretical treatise. It is written from the perspective of the practicing project manager — me. I offer it to you to be your companion and to be used.

Page xlviii

Wysocki

flast.tex

V2 - 03/23/2009

10:44am

Introduction

EPM5, like all of its previous editions, was written for three distinct markets: the education market, the training market, and the professional reference market. It has been successful in all three. In this respect it occupies a unique position in the literature of project management.

Education Market Nearly 100 educators from colleges and universities have requested the EPM4 Discussion Question Answer File, so I know that at least that many educational organizations have adopted EPM4. A number of educators have shared their experiences with me. To them I owe a debt of gratitude. I’ve tried to incorporate their suggestions as best I can. The resulting book is much better for their inputs. On the EPM5 web site (www.wiley.com/go/epm5e) are files containing a set of slides for each chapter and a collection of class, team, and individual exercises I have used and recommend to you. These are comprehensive and may be modified to meet your specific needs. I encourage you to use them and adapt them to your training and education environment. If you have a need for other training materials to support your project management or business analyst curriculum, please contact me at [email protected].

Training Market In addition to many adoptions in the higher education market, EPM4 is also used in many training programs and corporate universities. EPM5 will continue to serve that market. All of the instructional materials available to the educator apply equally well to the trainer. I have successfully offered a number of variations of the EPM5 content in training programs of all lengths and configurations. I would be happy to share my experiences with any interested parties. You may reach me at [email protected].

Professional Market Originally the EPM series was written for the practicing professional. I have tried to maintain my allegiance to those professionals in the trenches who are trying to master a complex and ever-changing world of projects. They need answers, and I believe EPM5 provides those answers. If I can be of any help or give you any advice on your particular project management challenges, please contact me at [email protected].

How This Book Is Organized EPM5 is organized into 4 parts containing a total of 17 chapters.

xlix

Page xlix

Wysocki

l

flast.tex

V2 - 03/23/2009

Introduction

Part I: Defining and Using the Project Management Process Groups The purpose of Part I is to introduce you to the tools, templates, and processes that comprise the effective project manager’s toolkit. Since many of my readers will be familiar with the PMI PMBOK standards document, I have decided to group the toolkits around the five process groups, which I call Scoping, Planning, Launching, Monitoring and Controlling, and Closing. The nine Knowledge Areas defined in PMBOK are also introduced and briefly described. Each process group has a chapter devoted to it in which I provide working knowledge material for the tools, templates, and processes in that process group. Part I includes a condensed version of Chapters 1–11 of EPM4 with a few notable exceptions. All of the subject matter content of EPM4 is contained in EPM5. The case used in EPM4, Pizza Delivered Quickly (PDQ), is continued and expanded in EPM5. PDQ takes on a much different flavor in EPM5 as compared to EPM4. I’ve taken advantage of the opportunity to introduce and have you practice some of the contemporary nuances of projects. PDQ supports that effort. For the college and university faculty who are using my book in their courses, I have also added a few discussion questions at the end of each chapter. These are designed to actively engage the class in a sharing of ideas about how they would handle the situations presented.

Part II: Establishing Project Management Life Cycles and Strategies Part II begins with Chapter 8, ‘‘Project Management Landscape,’’ which is defined by the goal and solution that are either clear or not clear. This two-by-two grid defines four types of project management categories: Traditional Project Management (TPM), Agile Project Management (APM), Extreme Project Management (xPM), and a fourth category called Emertxe Project Management (MPx). On the surface the MPx category looks like a solution out looking for a problem. That is one interpretation, but there is another far more serious interpretation. I discuss that in Chapter 8. The TPM, APM, and xPM categories give rise to a landscape of five PMLC models: Linear, Incremental, Iterative, Adaptive, and Extreme. Each of these models presents different challenges to the project manager. Chapters 9–12 discuss each approach in detail focusing on their characteristics, strengths, weaknesses, when to use them, and how to adapt the toolkits to them.

10:44am

Page l

Wysocki

flast.tex

V2 - 03/23/2009

10:44am

Introduction

Part III: Building an Effective Project Management Infrastructure In Parts I and II I developed the PMLC models that I feel span the entire landscape of project types. In this part I develop the Project Support Office, Project Portfolio Management, and Continuous Process Improvement Programs. These are the organizational infrastructures to support project management. Their presence is necessary for any environment in which effective project management takes place. These might be considered advanced topics by some, but they are included to round out your understanding of the project management environment.

Part IV: Managing the Realities of Projects Part IV introduces two new topics to the EPM series. I have encountered both of these situations more than once in my consulting career. Very little is written about distressed projects and managing multiple team projects. I hope to at least make some contribution. Chapter 16, ‘‘Managing Distressed Projects,’’ is new to EPM5. Given the high failure rate of projects I felt it was important for the practitioner to know how to prevent projects from becoming distressed and, if distressed, how to create effective intervention strategies. The practitioner should find good value here. Chapter 17, ‘‘Managing Multiple Team Projects,’’ is also new to EPM5. In larger organizations it is not uncommon that projects will involve teams from different parts of the organization. Each of these teams comes with their own tools, templates, and processes and somehow must be integrated into a single team with a common set of tools, templates, and processes. Three models for accomplishing this integration are discussed.

The Rationale for Using this Book Organization This book does not advocate following recipes and stepwise procedures lists for managing projects. Rather it is based on constructing a best-fit project management approach based on the characteristics of the project, its environment, the business climate, the team skills profile, and other descriptors.

A Bottom Up Learning Experience To begin your study I introduce six questions that form an architecture for any effective project management approach. As long as your chosen approach

li

Page li

Wysocki

lii

flast.tex

V2 - 03/23/2009

Introduction

provides answers to these six questions, you will have defined an effective approach.

Learning about Process Groups The Project Management Institute (PMI) has provided a comprehensive definition of the basic building blocks from which every project management methodology can be defined. You first learn these and then apply them later in the book to specific project management methodologies and models.

Learning about How Process Groups Form Life Cycle Processes PMI defines the five basic process groups that can be used to form project management life cycle processes. Every effective project management life cycle will contain these five process groups. In some life cycles the process groups will appear once, in others several times.

Learning about Forming Strategies for Effective Life Cycle Management In this book the profile of the project and the degree to which requirements are specified and documented form the strategies for defining the best-fit project management life cycle. As the project work commences, the profile of the project and the requirements definition may change, prompting a change of strategy. Always keeping the project management approach aligned with the changing profile of the project is the unique feature of my approach to project management.

Learning How the Organization Can Support Effective Project Management The organization itself can be a supporter of or a hindrance to effective project management. I explore this in the three chapters Part III comprises.

Learning How to Adapt to the Realities of Projects In Part IV you learn about two project situations that arise frequently and that are not discussed earlier in the book. Despite all of your planning and strategizing to choose best-fit project management approaches, the project can still fall into a distressed state. Knowing how to prevent this from happening through early warning metrics is of primary importance, and how to recover

10:44am

Page lii

Wysocki

flast.tex

V2 - 03/23/2009

10:44am

Introduction

from a distressed state is also important. One chapter focuses on that topic. Another chapter focuses on the increasingly common multiple team project situation.

How to Use This Book As I noted earlier in this introduction, EPM5 simultaneously accommodates the education, training, and professional reference markets.

Introductory (Chapter 1–7) A good introductory 3-credit undergraduate course or 3-day training course would consist of Chapters 1–7. Chapters 1–7 introduce the tools, templates, and processes used by the contemporary project manager. These chapters are structured around the five process groups defined by the PMBOK.

Intermediate (Chapters 1–12) A good upper division undergraduate or introductory graduate course or 3-day intermediate training course would consist of Chapters 1–12. The prerequisite would be an introductory course in project management. However, my experience with training programs is not to have a prerequisite. I would recommend a 5-day training course that covers Chapters 1–12. Chapter 8 defines the project management landscape in terms of Traditional Project Management (Linear and Incremental), Agile Project Management (Iterative and Adaptive), and Extreme Project Management (Extreme). Chapters 9–12 provide a detailed discussion of each of these project situations.

Advanced (Chapters 8–17) A good graduate level course would consist of Chapters 8–17. For scheduling or topic interests, some subset from Chapters 8–17 could be chosen. This would open the opportunity for more in-depth coverage with supplemental readings and for course projects drawn from those chapters

Who Should Use This Book The original target audience for EPM1 was the practicing project manager. However, as I discovered, many of the second and third edition sales were to university and college faculty. I certainly want to encourage their use of

liii

Page liii

Wysocki

liv

flast.tex

V2 - 03/23/2009

Introduction

my book, so in EPM4 I further expanded the target market to include both practicing project managers and faculty. I added discussion questions to each chapter, and to assist in lecture preparation, I put copies of all figures and tables on the web site. EPM5 takes it to the next level with much more collateral content for the instructor.

Practicing Professionals This book adapts very well to whatever your current knowledge of or experience with project management might be: If you are unfamiliar with project management, you can learn the basics by simply reading and reflecting. If you wish to advance to the next level, I offer a wealth of practice opportunities through the case exercises. If you are more experienced, I offer several advanced topics, including TPM, APM, and xPM in Part II and a number of advanced topics in Parts III and IV. In all cases, the best way to read the book is front to back. If you are an experienced project manager, feel free to skip around and read the sections as a refresher course. The seasoned professional project manager will find value in the book as well. I have gathered a number of tools and techniques that appeared in the first edition of this book. The Joint Project Planning session, the use of sticky notes and whiteboards for building the project network, the completeness criteria for generating the Work Breakdown Structure, the use of work packages for professional staff development, and milestone trend charts are a few of the more noteworthy and original contributions.

Undergraduate, Graduate and Adjunct Faculty A significant adopter of EPM1 through EPM4 has been the education market. EPM5 offers even more to that market than all previous editions. The addition of complete PowerPoint slide files for each chapter adds value that wasn’t part of EPM4. The slides contain all of the content that should be in the class lectures. Faculty can add to, delete, or modify these files to suit their specific purpose and style for each lecture. I have also included a PowerPoint file of exercises. These are designed as individual, team, or class exercises.

N O T E The PowerPoint slide files and exercise file are available for download at the book’s web site at www.wiley.com/go/epm5e.

10:44am

Page liv

Wysocki

flast.tex

V2 - 03/23/2009

10:44am

Introduction

Corporate Trainers EPM5 also has the corporate trainer’s needs in mind. In addition to the materials available to the faculty for their credit courses, I will make available several venues for offering EPM5. These range from 3-day programs to 13- and 24-session programs. Contact the author at [email protected] with a statement of your specific needs.

Introducing the Case Study: Pizza Delivered Quickly (PDQ) Pizza Delivered Quickly (PDQ) is a local chain (40 stores) of eat-in and home delivery pizza stores. Recently PDQ has lost 30 percent of sales revenue due mostly to a drop in their home delivery business. They attribute this solely to their major competitor who recently promoted a program that guarantees 45-minute delivery service from order entry to home delivery. PDQ advertises one-hour delivery. PDQ currently uses computers for in-store operations and the usual business functions, but otherwise is not heavily dependent upon software systems to help them receive, process, and home deliver their customers’ orders. Pepe Ronee, their Supervisor of Computer Operations, has been charged with developing a software application to identify ‘‘pizza factory’’ locations and create the software system needed to operate them. In commissioning this project, Dee Livery, their president, said to pull out all the stops. She further stated that the future of PDQ depends on this project. She wants the team to investigate an option to deliver the pizza unbaked and ‘‘ready for the oven’’ in 30 minutes or less or deliver it pre-baked in 45 minutes or less. These pizza factories would not have any retail space. Their only function will be to receive orders, prepare, and deliver the pizzas. The factory location nearest the customer’s location will receive the order from a central ordering facility, process, and deliver the order within 30 or 45 minutes of order entry depending on whether the customer orders their pizza ready for the oven or already baked. There are six software applications that Pepe has identified for the solution.

Pizza Factory Locator Subsystem The first is a software subsystem to find pizza factory locations. It is not known how many such factories will be needed nor where they should be located. The software subsystem will have to determine that. Clearly this subsystem is a very complex application. The goal can be clearly defined, but even at that the solution will not be at all obvious. This subsystem will have to use a very

lv

Page lv

Wysocki

lvi

flast.tex

V2 - 03/23/2009

Introduction

sophisticated modeling tool. The requirements, functionality, and features are not at all obvious. Some of the solution can probably be envisioned, but clearly the whole solution is elusive at this early stage. Exactly how to model it is not known at the outset. It will have to be discovered as the development project is underway.

Order Entry Subsystem The second is an order entry subsystem to support store and factory operations. Telephone orders will come to a single location, be taken there and then routed to the appropriate store or factory electronically. This system focuses on routine business functions and should be easily defined. Off the shelf commercial software may be a big part of the final solution to support store and factory operations. This subsystem can utilize COTS (commercial off the shelf) order entry software.

Order Submit Subsystem This subsystem will direct the order to a store, factory or pizza van. The logistics for making this assignment are not at all clear, and subsystem design will be complex.

Logistics Subsystem This subsystem is the most complex of the six subsystems. It will require a holistic view of the entire PDQ system. Its complexity arises from the fact that the pizza vans are a mobile production and delivery facility. So the assignment of an order to a pizza van must take into account where the van is likely to be when it is time for order delivery.

Routing Subsystem This software application will be a routing subsystem for the delivery trucks. This application is straightforward and will probably involve having GPS systems installed in all the delivery trucks.

Inventory Management Subsystem The final application will be an inventory control system to manage inventories at all stores and factories and automatically reorder from the single vendor that PDQ has been using since it first started in the business. PDQ has been

10:44am

Page lvi

Wysocki

flast.tex

V2 - 03/23/2009

10:44am

Introduction

informed by their vendor that they can earn discounts by using the automatic reordering feature. This application should also be a COTS application. These applications are obviously very different software development projects requiring very different approaches. The Pizza Factory Locator subsystem will be a very sophisticated modeling tool. The requirements, functionality, and features are not at all obvious. Some of the solution can probably be envisioned, but clearly the whole solution is elusive at this early stage. Exactly how it will do modeling is not known at the outset. It will have to be discovered as the development project is underway. The Order Entry subsystem can utilize COTS order entry software that will have to be enhanced at the front end to direct the order to the closest factory and provide driving directions for delivery and other fulfillment tasks on the back end. The requirements, functionality, and features of this subsystem may be problematic. The six subsystems that make up the PDQ solution may each require a different project management approach. There will be a number of exercises incorporated in each chapter that require strategy formation and other decisions in order to find and maintain a best-fit project management approach.

What’s on the Web Site EPM5 offers more support to the educator and trainer than EPM4 did. There are two new instructional aids added to the web site.

N O T E EPM5’s web site can be found at www.wiley.com/go/epm5e.

Slide Presentation There is a PowerPoint file for each chapter available for download. Each file includes a complete set of slides for delivery of the content of the chapter. Instructors may add, delete, or modify to suit their interests and purposes.

Individual, Team, and Class Exercises EPM5 also offers at the web site another PowerPoint file containing several exercises that have been used successfully in both education and training offerings. In addition to these downloads, EPM4 included a question and answer file (based on the discussion questions at the end of each chapter) that could be obtained by certified faculty and instructors by writing the author at [email protected] and requesting the file. EPM5 continues that offer.

lvii

Page lvii

Wysocki

lviii

flast.tex

V2 - 03/23/2009

Introduction

Putting It All Together EPM5 is a valuable addition to the library of every professional with an interest in being an effective project manager. It is my intention to help project managers learn to think like effective project managers. To me an effective project manager is like a master chef. They know how to create recipes rather than just blindly follow existing recipes. As I’ve said already in this introduction, project management is nothing more than organized common sense, and this book will help you wake up the common sense you already possess and channel it into effective project management.

10:44am

Page lviii

Wysocki

p01.tex

V2 - 03/20/2009

PART

I Defining and Using Project Management Process Groups The purpose of Part I is to provide you with a working knowledge of the five Process Groups and nine Knowledge Areas that make up the Project Management Body of Knowledge (PMBOK). For each Process Group, the tools, templates, and processes aligned with that Process Group are explained in detail. This is very much an application orientation. Part II discusses how to use the Process Groups (and the tools, templates, and processes aligned with them) in specific situations, when to use them, and how to adapt them to meet your project needs. This is consistent with the bottom-up learning model used in this book. Upon completing Part I, you will have a working knowledge of all the contemporary tools, templates, and processes used to scope, plan, launch, monitor, control, and close projects.

Overview of Part I The following chapters comprise Part I and should be read and studied in the order presented.

4:58pm

Page 1

Wysocki

2

Part I

■

p01.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

Chapter 1: What Is a Project? To be called a project, an undertaking must meet a specific set of conditions. If an undertaking meets those conditions, then it must follow the prescribed project management methodology defined by the organization. A formal definition is put forth and the characteristics of the project are explored. Project management methodologies are often defined for specific types of projects. Project classification rules are explored.

Chapter 2: Understanding the Project Management Process Groups This chapter aligns with the PMBOK defined by the Project Management Institute (PMI). PMBOK is the standard by which project management methodologies are gauged. PMBOK defines five Process Groups and nine Knowledge Areas, which are discussed in this chapter. The tools, templates, and processes used in each Process Group are presented. A common misconception is that the five Process Groups define a project management methodology. They do not. The discussion of methodologies is taken up in Part II.

Chapter 3: How to Scope a Project Unless you know where you are going, how will you know if you ever get there? Completely and clearly documenting the client’s requirements is difficult and many would say impossible. The degree to which that exercise is satisfactorily done will be the major factor in deciding how the project should be managed.

Chapter 4: How to Plan a Project For some projects, a complete plan can be generated before any work begins. For others, planning is done just in time. The specific approach for your project depends on the completeness of the requirements specification.

Chapter 5: How to Launch a Project Assembling the team, establishing how it will function, and finalizing the project schedule are the major topics of this chapter.

Chapter 6: How to Monitor and Control a Project If you can’t measure it, you can’t manage it. Status reporting and other control tools are discussed in this chapter.

4:58pm

Page 2

Wysocki

Part I

■

p01.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

Chapter 7: How to Close a Project The project is done when the client says it is done. The acceptance criteria should have been defined during the planning phase and maintained throughout the project. The steps to closing the project are discussed in this chapter.

4:58pm

3

Page 3

Wysocki

p01.tex

V2 - 03/20/2009

4:58pm

Page 4

Wysocki

c01.tex

V2 - 03/20/2009

11:59am

CHAPTER

1 What Is a Project? Things are not always what they seem. — Phaedrus, Roman writer and fabulist

CHAPTER LEARNING OBJECTIVES After reading this chapter, you will be able to: ◆ Define a project ◆ List a project’s characteristics ◆ Distinguish a project from a program, activity, and task ◆ Understand the five parameters that constrain a project ◆ Know the importance of defining and using a project classification rule ◆ Understand the issues around scope creep, hope creep, effort creep, and feature creep

To put projects into perspective, you need a definition — a common starting point. All too often, people call any work they have to do a ‘‘project.’’ Projects actually have a very specific definition. If a set of tasks or work to be done does not meet the strict definition, then it cannot be called a project. To use the project management techniques presented in this book, you must first have a project.

5

Page 5

Wysocki

6

Part I

■

c01.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

Defining a Project A project is a sequence of unique, complex, and connected activities that have one goal or purpose and that must be completed by a specific time, within budget, and according to specification. This definition tells you quite a bit about a project. To appreciate just what constitutes a project, take a look at each part of the definition.

Sequence of Activities A project comprises a number of activities that must be completed in some specified order, or sequence. An activity is a defined chunk of work.

C R O S S - R E F Chapter 4 expands on this informal definition of an activity. The sequence of the activities is based on technical requirements, not on management prerogatives. To determine the sequence, it is helpful to think in terms of the following inputs and outputs: What is needed as input in order to begin working on this activity? What activities produce those deliverables as output? The output of one activity or set of activities becomes the input to another activity or set of activities. Specifying a sequence based on resource constraints or statements such as ‘‘Pete will work on activity B as soon as he finishes working on activity A’’ should be avoided because this establishes an artificial relationship between activities. What if Pete wasn’t available at all? Resource constraints aren’t ignored when you actually schedule activities. The decision of what resources to use and when to use them comes later in the project planning process.

Unique Activities The activities in a project must be unique. A project has never happened exactly in the same way before, and it will never happen again under the same conditions. Something is always different each time the activities of a project are repeated. Usually the variations are random in nature — for example, a part is delayed, someone is sick, or a power failure occurs. These are random events that can happen, but you never are sure of when or how, and what impact they will have on the schedule. These random variations are the challenge for the project manager.

11:59am

Page 6

Wysocki

c01.tex

Chapter 1

■

V2 - 03/20/2009

11:59am

What Is a Project?

Complex Activities The activities that make up the project are not simple, repetitive acts, such as mowing the lawn, painting the house, washing the car, or loading the delivery truck. They are complex. For example, designing an intuitive user interface to an application system is a complex activity.

Connected Activities Connectedness implies that there is a logical or technical relationship between pairs of activities. There is an order to the sequence in which the activities that make up the project must be completed. They are considered connected because the output from one activity is the input to another. For example, you must design the computer program before you can program it. You could have a list of unconnected activities that must all be complete in order to complete the project. For example, consider painting the interior rooms of a house. With some exceptions, the rooms can be painted in any order. The interior of a house is not completely painted until all its rooms have been painted, but they may be painted in any order. Painting the house is a collection of activities, but it is not considered a project according to the definition.

One Goal Projects must have a single goal — for example, to design an inner-city playground for ADC (Aid to Dependent Children) families. However, very large or complex projects may be divided into several subprojects, each of which is a project in its own right. This division makes for better management control. For example, subprojects can be defined at the department, division, or geographic level. This artificial decomposition of a complex project into subprojects often simplifies the scheduling of resources and reduces the need for interdepartmental communications while a specific activity is worked on. The downside is that the projects are now interdependent. Even though interdependency adds another layer of complexity and communication, it can be handled.

Specified Time Projects have a specified completion date. This date can be self-imposed by management or externally specified by a client or government agency. The deadline is beyond the control of anyone working on the project. The project is over on the specified completion date whether or not the project work has been completed.

7

Page 7

Wysocki

8

Part I

■

c01.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

Within Budget Projects also have resource limits, such as a limited amount of people, money, or machines that are dedicated to the project. These resources can be adjusted up or down by management, but they are considered fixed resources by the project manager. For example, suppose a company has only one web designer at the moment. That is the fixed resource that is available to project managers. Senior management can change the number of resources, but that luxury is not available to the project manager. If the one web designer is fully scheduled, the project manager has a resource conflict that he or she cannot resolve.

C R O S S - R E F Chapter 6 covers resource limits in more detail.

According to Specification The client, or the recipient of the project’s deliverables, expects a certain level of functionality and quality from the project. These expectations can be self-imposed, such as the specification of the project completion date, or client-specified, such as producing the sales report on a weekly basis. Although the project manager treats the specification as fixed, the reality of the situation is that any number of factors can cause the specification to change. For example, the client may not have defined the requirements completely, or the business situation may have changed (which often happens in projects with long durations). It is unrealistic to expect the specification to remain fixed through the life of the project. Systems specification can and will change, thereby presenting special challenges to the project manager.

C R O S S - R E F Chapters 8, 11, and 12 describe how to effectively handle client requirements.

What Is a Program? A program is a collection of related projects. The projects must be completed in a specific order for the program to be considered complete. Because programs comprise multiple projects, they are larger in scope than a single project. For example, the United States government has a space program that includes several projects such as the Challenger project. A construction company contracts a program to build an industrial technology park with several separate projects. Unlike projects, programs can have many goals. For example, every launch of a new mission in the NASA space program includes several dozen projects in the form of scientific experiments. Except for the fact that they are all aboard

11:59am

Page 8

Wysocki

c01.tex

Chapter 1

■

V2 - 03/20/2009

11:59am

What Is a Project?

the same spacecraft, the experiments are independent of one another and together define a program.

Establishing Temporary Program Offices As the size of the project increases, it becomes unwieldy from a management standpoint. A common practice is to establish a temporary program office to manage these large projects. One of my clients uses a team size of 30 as the cutoff point. Whenever the team size is greater than 30, a program office is established. That program office consists of nothing more than the management structure needed for the project. There will be a program director and one or more program administrators as support. The program administrators support the program manager as well as the teams. Even for teams of 30, there will often be a subteam organization put in place to simplify the management of the team. Each subteam will be led by a subproject manager. When the project is completed, the program office disbands.

Establishing Permanent Program Offices A permanent program office is established to manage an ongoing and changing portfolio of projects. The portfolio consists of projects that have something in common — for example, all might be funded from the same budget, might be linked to the same goal statement, or might use the same resource pool. The permanent program office, unlike the temporary program office, manages a continuously changing collection of projects.

Understanding the Scope Triangle The following five constraints operate on every project: Scope Quality Cost Time Resources These constraints form an interdependent set — a change in one constraint can require a change in another constraint in order to restore the equilibrium of the project. In this context, the set of five parameters form a system that must remain in balance for the project to be in balance. Because they are so important to the success or failure of the project, each parameter is discussed individually in this section.

9

Page 9

Wysocki

10

Part I

■

c01.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

Scope Scope is a statement that defines the boundaries of the project. It tells not only what will be done but also what will not be done. In the information systems industry, scope is often referred to as a functional specification. In the engineering profession, it is generally called a statement of work. Scope may also be referred to as a document of understanding, a scoping statement, a project initiation document, or a project request form. Whatever its name, this document is the foundation for all project work to follow. It is critical that the scope be correct. Chapter 3 describes exactly how this should happen in its coverage of Conditions of Satisfaction (COS). Beginning a project on the right foot is important, and so is staying on the right foot. It is no secret that a project’s scope can change. You do not know how or when, but it will change. Detecting that change and deciding how to accommodate it in the project plan are major challenges for the project manager.

C R O S S - R E F Chapter 3 is devoted to defining project scope, and scope management is discussed in Chapter 6.

Quality The following two types of quality are part of every project: Product quality — The quality of the deliverable from the project. The traditional tools of quality control, discussed in Chapter 2, are used to ensure product quality. Process quality — The quality of the project management process itself. The focus is on how well the project management process works and how can it be improved. Continuous quality improvement and process quality management are the tools used to measure process quality. These are discussed in Chapter 15. A sound quality management program with processes in place that monitor the work in a project is a good investment. Not only does it contribute to client satisfaction, it helps organizations use their resources more effectively and efficiently by reducing waste and revisions. Quality management is one area that should not be compromised. The payoff is a higher probability of successfully completing the project and satisfying the client.

Cost The dollar cost of doing the project is another variable that defines the project. It is best thought of as the budget that has been established for the project.

11:59am

Page 10

Wysocki

c01.tex

Chapter 1

V2 - 03/20/2009

■

11:59am

What Is a Project?

This is particularly important for projects that create deliverables that are sold either commercially or to an external customer. Cost is a major consideration throughout the project management life cycle. The first consideration occurs at an early and informal stage in the life of a project. The client can simply offer a figure about equal to what he or she had in mind for the project. Depending on how much thought the client put into it, the number could be fairly close to or wide of the actual cost for the project. Consultants often encounter situations in which the client is willing to spend only a certain amount for the work. In these situations, you do what you can with what you have. In more formal situations, the project manager prepares a proposal for the projected work. That proposal includes an estimate (perhaps even a quote) of the total cost of the project. Even if a preliminary figure has been supplied by the project manager, the proposal allows the client to base his or her go/no-go decision on better estimates.

Time The client specifies a time frame or deadline date within which the project must be completed. To a certain extent, cost and time are inversely related to one another. The time a project takes to be completed can be reduced, but costs increase as a result. Time is an interesting resource. It can’t be inventoried. It is consumed whether you use it or not. The objective for the project manager is to use the future time allotted to the project in the most effective and productive ways possible. Future time (time that has not yet occurred) can be a resource to be traded within a project or across projects. Once a project has begun, the prime resource available to the project manager to keep the project on schedule or get it back on schedule is time. A good project manager realizes this and protects the future time resource jealously.

C R O S S - R E F Chapters 4 and 5, which discuss scheduling project activities, cover this topic in more detail.

Resources Resources are assets such as people, equipment, physical facilities, or inventory that have limited availabilities, can be scheduled, or can be leased from an outside party. Some are fixed; others are variable only in the long term. In any case, they are central to the scheduling of project activities and the orderly completion of the project. For systems development projects, people are the major resource. Another valuable resource for systems projects is the availability of computer processing

11

Page 11

Wysocki

Part I

■

V2 - 03/20/2009

Defining and Using Project Management Process Groups

time (mostly for testing purposes), which can present significant problems to the project manager with regard to project scheduling.

Envisioning the Scope Triangle as a System in Balance Projects are dynamic systems that must be kept in equilibrium. Not an easy task, as you shall see! Figure 1-1 illustrates the dynamics of the situation.

Co st

Tim e

12

c01.tex

Scope and Quality

Resource Availability

Figure 1-1 The scope triangle

The geographic area inside the triangle represents the scope and quality of the project. Lines representing time, cost, and resource availability bound scope and quality. Time is the window of time within which the project must be completed. Cost is the dollar budget available to complete the project. Resources are any consumables used on the project. People, equipment availability, and facilities are examples.

N O T E While the accountants will tell you that everything can be reduced to dollars, and they are right, you will separate resources as defined here. They are controllable by the project manager and need to be separately identified for that reason.

11:59am

Page 12

Wysocki

c01.tex

Chapter 1

V2 - 03/20/2009

■

11:59am

What Is a Project?

The project plan will have identified the time, cost, and resource availability needed to deliver the scope and quality of a project. In other words, the project is in equilibrium at the completion of the project planning session and approval of the commitment of resources and dollars to the project. That will not last too long, however. Change is waiting around the corner. The scope triangle offers a number of insights into the changes that can occur in the life of the project. For example, the triangle represents a system in balance before any project work has been done. The sides are long enough to encompass the area generated by the scope and quality statements. Not long after work begins, something is sure to change. Perhaps the client calls with an additional requirement for a feature that was not envisioned during the planning sessions. Perhaps the market opportunities have changed, and it is necessary to reschedule the deliverables to an earlier date, or a key team member leaves the company and is difficult to replace. Any one of these changes throws the system out of balance. The project manager controls resource utilization and work schedules. Management controls cost and resource level. The client controls scope, quality, and delivery dates. Scope, quality, and delivery dates suggest a hierarchy for the project manager as solutions to accommodate the changes are sought.

C R O S S - R E F Chapters 5 and 6 discuss this topic in greater detail.

Managing the Creeps While some of your team members may occasionally seem like creeps to you, that is not creep management I am talking about. Creeps here refer to minute changes in the project due to the obscure, and for awhile unnoticeable, actions of team members. Many of these go undetected until a problem raises its ugly head. There are four types of creeps, as described in the sections that follow.

Scope Creep Scope creep is the term that has come to mean any change in the project that was not in the original plan. Change is constant. To expect otherwise is simply unrealistic. Changes occur for several reasons that have nothing to do with the ability or foresight of the client, the project manager, or a project team member. Market conditions are dynamic. The competition can introduce or announce an upcoming new version of its product. Your management might decide that getting the product to market before the competition is necessary. Scope creep isn’t necessarily anyone’s fault. It is just a reality that has to be

13

Page 13

Wysocki

14

Part I

■

c01.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

dealt with. It doesn’t matter how good and thorough a job you and the client did in planning the project, scope creep is still going to happen. Deal with it! Your job as project manager is to figure out how these changes can be accommodated — tough job, but somebody has to do it. Regardless of how the scope creep occurs, it is your job as project manager to figure out how, or even if, you can accommodate the impact.

Hope Creep Hope creep happens when a project team member falls behind schedule but reports that he or she is on schedule, hoping to get back on schedule by the next report date. Hope creep is a real problem for the project manager. There will be several activity managers within your project team who manage a hunk of work. They do not want to give you bad news, so they are prone to tell you that their work is proceeding according to schedule when, in fact, it is not. It is their hope that they will catch up by the next report period, so they mislead you into thinking that they are on schedule. The activity managers hope that they will catch up by completing some work ahead of schedule to make up for the slippage. The project manager must be able to verify the accuracy of the status reports received from the team members. This does not mean that the project manager has to check into the details of every status report. Random checks can be used effectively.

Effort Creep Effort creep is the result of the team member working but not making progress proportionate to the work expended. Every one of us has worked on a project that always seems to be 95-percent complete no matter how much effort is expended to complete it. Each week the status report records progress, but the amount of work remaining doesn’t seem to decrease proportionately. Other than random checks, the only effective thing that the project manager can do is to increase the frequency of status reporting by those team members who seem to suffer from effort creep.

Feature Creep Closely related to scope creep is feature creep. Feature creep results when team members arbitrarily add features and functions to the deliverable that they think the client would want to have. The problem is that the client didn’t specify the feature, probably for good reason. If the team member has strong feelings about the need for this new feature, formal change management procedures can be employed.

C R O S S - R E F The change management process is discussed in Chapter 5.

11:59am

Page 14

Wysocki

c01.tex

Chapter 1

V2 - 03/20/2009

■

11:59am

What Is a Project?

Here’s an example of how feature creep can occur. The programmer is busy coding a particular module in the system. He or she gets an idea that the client might appreciate having another option included. The systems requirements document does not mention this option. It seems so trivial that the programmer decides to include it rather than go through the lengthy change process. If this feature is not documented, it will go unnoticed until it’s too late, and trouble will result. (Trust me, I have seen it happen on several occasions.) Here’s another example, which I personally experienced. This time it was induced by the client, and I was the project manager. The project involved the collection, storage, editing, retrieval, and reporting of an extensive database of teacher education data. The client called ahead and told me that she had just come up with a major design breakthrough with the raw input data and wanted to come over and show me. A few minutes later, she arrived at my office door. She proceeded to go through a lengthy demonstration of the color coding scheme she developed and used for the most recent data set. She was so proud of what she had done and it really was a stroke of genius, but not for me, because I had to read and interpret the data sheets. It broke my heart to have to tell her that I was profoundly color blind and couldn’t read her data sheets. Even when adding a feature or function seems rather insignificant, you need to look at the possible consequences. First of all, if the feature is not in the system requirements document, it is also not in the acceptance test procedure, the systems documentation, the user documentation, and the user training program. What will happen if something goes wrong with the new option? How will another programmer know what to do? What will happen when the user discovers the option and asks for some modification of it? You can see the consequences of such an innocent attempt to please. The message here is that a formal change request must be filed, and if it is approved, the project plan and all related activities will be appropriately modified.

Applying the Scope Triangle There are only a few graphics that I want you to burn into your brain because of their value throughout the entire project life cycle. The scope triangle is one such graphic. It will have at least two major applications for you: as a problem escalation strategy and as a reference for the project impact statement, which is created as part of the scope change process.

Problem Resolution The scope triangle enables you to ask the question, ‘‘Who owns what?’’ The answer will give you an escalation pathway from project team to resource

15

Page 15

Wysocki

16

Part I

■

c01.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

manager to client. The client and senior management own time, budget, and resources. The project team owns how time, budget, and resources are used. Within the policies and practices of the enterprise, any of these may be moved within the project to resolve problems that have arisen. In solving a problem, the project manager should try to find a solution within the constraints of how the time, budget, and resources are used. They do not need to go outside of their sphere of control. The next step in the escalation strategy would be for the project manager to appeal to the resource managers for problem resolution. The resource manager owns who gets assigned to a project as well as any changes to that assignment that may arise. The final step in the problem escalation strategy is to appeal to the client. They control the amount of time that has been allocated to the project. They control the amount of money that has been allocated. Finally, they control the scope of the project. Whenever the project manager appeals to the client, it will be to get an increase in time or budget and some relief from the scope by way of scope reduction or scope release.

Scope Change Impact Analysis The second major application of the scope triangle is as an aid in the preparation of the Project Impact Statement. This is a statement of the alternative ways of accommodating a particular scope change request of the client. The alternatives are identified by reviewing the scope triangle and proceeding in much the same way as discussed in the previous paragraph. Chapter 5 has a detailed discussion of the scope change process and the use of the Project Impact Statement.

The Importance of Classifying Projects Projects are unique and to some extent so is the best-fit model to manage them. Part II of the book is devoted to exploring five best-fit models and when to use them. For now it is sufficient to understand that a one-size-fits-all approach to project management doesn’t work and has never worked. It is far more effective to group projects based on their similarities and to use a project management approach designed specifically for each group of project types. That is the topic of this section.

Establishing a Rule for Classifying Projects For the purposes of this chapter, two different rules are defined here. The first is based on the characteristics of the project, and the second is based on the

11:59am

Page 16

Wysocki

c01.tex

Chapter 1

V2 - 03/20/2009

■

11:59am

What Is a Project?

type of project. Part II defines a third rule, which is based on the clarity and completeness of the goal and the solution.

Classification by Project Characteristics Many organizations choose to define a classification of projects based on such project characteristics as the following: Risk — Establish levels of risk (high, medium, and low). Business value — Establish levels (high, medium, and low). Length — Establish several categories (such as 3 months, 3 to 6 months, 6 to 12 months, and so on). Complexity — Establish categories (high, medium, and low). Technology used — Establish several categories (well-established, used occasionally, used rarely, never used). Number of departments affected — Establish some categories (such as one, a few, several, and all). Cost The project profile determines the classification of the project. The classification defines the extent to which a particular project management methodology is to be used. In Part II, you will use these and other factors to adjust the best-fit project management approach. I strongly advocate this approach because it adapts the methodology to the project. ‘‘One size fits all’’ does not work in project management. In the final analysis, I defer to the judgment of the project manager. In addition to the parts required by the organization, the project manager should adopt whatever parts of the methodology he or she feels improves his or her ability to help successfully manage the project. Period. Project characteristics can be used to build a classification rule as follows: Type A projects — These are high-business-value, high-complexity projects. They are the most challenging projects the organization undertakes. Type A projects use the latest technology, which, when coupled with high complexity, causes risk to be high also. To maximize the probability of success, the organization requires that these projects utilize all the methods and tools available in their project management methodology. An example of a Type A project is the introduction of a new technology into an existing product that has been very profitable for the company. Type B projects — These projects are shorter in length, but they are still significant projects for the organization. All of the methods and

17

Page 17

Wysocki

18

Part I

■

c01.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

tools in the project management process are probably required. Type B projects generally have good business value and are technologically challenging. Many product development projects fall in this category. Type C projects — These are the projects that occur most frequently in an organization. They are short by comparison and use established technology. Many are projects that deal with the infrastructure of the organization. A typical project team consists of five people, the project lasts six months, and the project is based on a less-than-adequate scope statement. Many of the methods and tools are not required for these projects. The project manager uses those optional tools only if he or she sees value in their use. Type D projects — These just meet the definition of a project and may require only a scope statement and a few scheduling pieces of information. A typical Type D project involves making a minor change in an existing process or procedure or revising a course in the training curriculum. Table 1-1 gives a hypothetical example of a classification rule. Table 1-1 Example of Project Classes and Definitions RISK

LIKELIHOOD COMPLEXITY TECHNOLOGY OF PROBLEMS

CLASS

DURATION

Type A

> 18 months High

High

Breakthrough

Certain

Type B

9–18 months Medium

Medium

Current

Likely

Type C

3–9 months

Low

Low

Best of breed

Some

Type D

< 3 months

Very low

Very low

Practical

None

These four types of projects might use the parts of the methodology shown in Figure 1-2. The figure lists the methods and tools that are either required or optional, given the type of project.

Classification by Project Type There are many situations in which an organization repeats projects that are of the same type. Following are some examples of project types: Installing software Recruiting and hiring Setting up hardware in a field office

11:59am

Page 18

Wysocki

c01.tex

Chapter 1

V2 - 03/20/2009

■

11:59am

What Is a Project?

Soliciting, evaluating, and selecting vendors Updating a corporate procedure Developing application systems

Project Management Process

Project Classification A

B

C

D

Define Conditions of Satisfaction Project Overview Statement Approval of Request

R R R

R R R

O R R

O R R

Plan Conduct Planning Session Prepare Project Proposal Approval of Proposal

R R R

R R R

O R R

O R R

Launch Kick-off Meeting Activity Schedule Resource Assignments Statements of Work

R R R R

R R R O

O R R O

O R O O

Monitor/Control Status Reporting Project Team Meetings Approval of Deliverables

R R R

R R R

R O R

R O R

Close Post-Implementation Audit Project Notebook

R R

R R

R O

R O

R = Required O = Optional

Figure 1-2 The use of required and optional parts of the methodology by type of project

These projects may be repeated several times each year and probably will follow a similar set of steps each time they are done.

C R O S S - R E F You will look at the ramifications of that repetition in Chapter 4 when Work Breakdown Structure (WBS) templates are discussed. The value of classifying projects by type is that each type of project utilizes a specific subset of the entire project management methodology. For example, projects that involve updating a corporate procedure are far less risky than application systems development projects. Therefore, the risk management aspects of each are very different. Risk management processes will be less important in the corporate procedure project; conversely, they will be very important in the applications development project.

19

Page 19

Wysocki

20

Part I

■

c01.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

Putting It All Together It should be clear to you by now that I advocate a very specific definition of a project. If a collection of work is to be called a project, it must meet the definition. Once you know that you have a project, it will be subjected to a specific set of requirements regarding its management.

Discussion Questions 1. Suppose the scope triangle were modified as follows: Resource Availability occupies the center, and the three sides are Scope, Cost, and Schedule. Interpret this triangle as if it were a system in balance. What is likely to happen when a specific resource on your project is concurrently allocated to more and more projects? As project manager, how would you deal with these situations? Be specific. 2. Where would you be able to bring about cost savings as a program manager for a company? Discuss these using the standard project constraints. 3. Discuss ways in which scope creep occurred on projects with which you have been associated. Was the project manager able to reverse scope creep? Is it possible to reverse scope creep? Defend your yes or no answer.

11:59am

Page 20

Wysocki

c02.tex

V2 - 03/20/2009

12:00am

CHAPTER

2

Understanding The Project Management Process Groups Project management is organized common sense. The PMI PMBOK Process Groups are not a project management life cycle; they are the building blocks of project management life cycles. — Robert K. Wysocki, Ph.D. President, Enterprise Information Insights, Inc.

CHAPTER LEARNING OBJECTIVES After reading this chapter, you will be able to: ◆ Explain the six basic questions that all valid project management methodologies must be able to answer ◆ Define the five Process Groups ◆ Define the nine Knowledge Areas ◆ Explain the dependency between the five Process Groups and nine Knowledge Areas ◆ Understand the basic concept of a project management life cycle

All of the project management life cycles (PMLCs) presented in Part II are constructed from the five Process Groups introduced in this chapter. The five Process Groups were originally defined by the Project Management Institute (PMI) in their standards guidelines called the Project Management Body of Knowledge (PMBOK). PMBOK has become the de facto standard for the practice of project management worldwide. This book is compatible with the five Process Groups and the related nine Knowledge Areas of PMBOK. It 21

Page 21

Wysocki

22

Part I

■

c02.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

is important that you understand the traditional processes and Knowledge Areas in detail because they are the basis of the project management models that you will learn about in Part II. This book extends its treatment beyond those traditional practices into the contemporary world of project management.

Understanding the Fundamentals of Project Management While the ancient Egyptians certainly followed some organized process to plan and build the pyramids, the history of modern project management dates from the 1950s. Several definitions have been put forward from PMI as well as others, and most of them are variations on the theme of managing projects so they are completed on-time, under-budget, and according to client specifications. That is all fine, but I have an even more fundamental definition to offer. My definition of project management is ‘‘organized common sense,’’ and indeed project management had better be organized common sense. If it’s not, why are you doing it? Many project management processes fly in the face of common sense, and that makes no sense to me. This is a fair question to ask of many of the methodologies I have seen in practice. Many project management methodologies place undue burdens on the project manager and team without any good reason. There are plenty of management challenges without having to add what I call non-value-added work. Many of the old school ideas about project management carry that burden. While my definition may appear rather simple, it sends a strong message about project management. However you choose to define your project management methodology, all valid project management methodologies must be reducible to answering the following six simple questions: What business situation is being addressed? What do you need to do? What will you do? How will you do it? How will you know you did it? How well did you do? If your project management methodology doesn’t embrace answering these six questions, it is incomplete. Go back to the drawing board. You will have to do better. Those of you who are new to project management, take heart. Project management boils down to answering these six questions and isn’t all that difficult to master. The organized, common-sense definition embraces answers

12:00am

Page 22

Wysocki

Chapter 2

■

c02.tex

V2 - 03/20/2009

12:00am

Understanding The Project Management Process Groups

to these six questions. You just need to take the time to stop and think about what you are about to do. Keep these six questions in mind and you will be well on your way to success as a project manager. Your organization’s policies and procedures with respect to project management must allow room for you to exercise common sense. In this book, you will learn about common-sense project management processes and practices, and what the organization can do to support you. You will also learn a lot about making common-sense decisions in a variety of challenging project situations. The situations you learn how to deal with here are not all-inclusive, but they are complete enough that you will be able to deal with other situations with the confidence that you understand how to use and adapt the fundamentals to any project situation you may confront. To get a clear understanding of the journey you’re about to undertake, consider this analogy of my approach to teaching project management and learning to be a cook or chef. You can learn to be a cook and be able to follow recipes, or you can learn to be a chef and be able to create recipes for cooks to follow. Being able to follow recipes is essential to being a good cook, but being able to create recipes is the mark of a great chef. My girlfriend provides a great example. Late one evening, she asked if I would like her to bake us a cheesecake. She makes a really great cheesecake, so how could I turn down such an offer? A few minutes later, I heard a groan coming from the kitchen. ‘‘What’s wrong,’’ I asked. ‘‘We’re all out of vanilla extract,’’ she announced. The markets were all closed by now, so we would have to wait until the next day. A few minutes later, I heard a confident ‘‘Yes!’’ coming from the kitchen, and soon afterwards, I could smell a cheesecake being baked. ‘‘Did you find the vanilla extract?’’ I asked. She said that we had some vanilla frosting in the cupboard, and it had vanilla extract in it. So she figured out how much vanilla frosting she would have to use in order to substitute for the vanilla extract. That cheesecake was her best ever. She showed that she can create recipes, not just follow recipes. I want to train you to be like a chef. The sign of a great project manager is one who can quickly adapt when a project does not meet the exact requirements of the approach being used or a surprise arises during the course of doing the project. I want to help you become that great project manager.

What Business Situation Is Being Addressed? The project is being proposed to address a specific business situation. The situation may be either of the following: A project that corrects a problem. The problem may be that the company is experiencing less than acceptable process performance;

23

Page 23

Wysocki

24

Part I

■

c02.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

a system no longer meets the needs for which it was originally put in place; business conditions or requirements have changed, and the system needs to change as well; or legal requirements and regulations have changed, and systems need to be updated. The project being proposed may address all or some part of the problem. A project that takes advantage of a heretofore untapped business opportunity. This could come about as a result of changing market conditions or the emergence of a new or improved technology. At the initiation stage of the project, before it is even approved, a brief statement is needed to identify the problem or opportunity being addressed.

What Do You Need to Do? What the client wants may not be what the client needs, and it is up to you, the project manager, to identify the client’s true needs. I have found in over 40 years of practicing project management that clients will often express their wants as their attempt at proposing a solution to an unstated problem. In some instances, the client knows exactly what has to be done, and in other cases, they are making a guess. Their wants may be a correct statement of their needs, but you don’t know that at the outset and they may not either. As part of the answer to the question ‘‘What do you need to do?’’ you will have to elicit a clear and complete statement of the problem to be solved and then provide a clear statement of how you intend to solve it. Gathering and documenting client requirements is usually how the solution is defined. The solution should address the client’s real needs, and you must convince them that it is the needs not the wants that you will address. As you will discover, forming the solution is often very difficult to do, especially at the beginning of the project. If you can provide a clear and complete requirements list, you will most likely use some type of traditional approach to managing the project. If you can’t identify a complete solution, you have a very different kind of management problem. If you find yourself in this kind of situation, welcome to the world of complex and uncertain projects. They occur far more frequently than any other type of project — they are the rule, not the exception. Solving the management problem for these complex and uncertain projects is the primary focus of this book. And I promise you that by following my lead, you will be able to effectively manage even the most complex and uncertain of projects. I speak to you from over 40 years of managing projects using organized, common-sense approaches, and what I am sharing with you in this book is my recorded history of successfully managing projects often marked by complexity and uncertainty.

12:00am

Page 24

Wysocki

Chapter 2

■

c02.tex

V2 - 03/20/2009

12:00am

Understanding The Project Management Process Groups

What Will You Do? Once you understand what is needed, you and the client have to decide what can be done to meet that need. Of course you would like to meet all client requirements, but that may not be possible. A partial solution may be all that you can provide, and others will have to pick up the pieces and provide additional parts of the solution. There can be a number of reasons for only being able to provide a partial solution that are outside the client’s, the enterprise’s, or your capabilities and resources. You will explore these situations in Part II, where you will learn how to determine the best project management model to follow. Even after you have made a choice to use what you believe to be the best-fit model, you will have to modify it at the beginning of the project or at points along the way. After all, each project is unique, so wouldn’t you expect your management approach to it to also be unique? And projects change, so wouldn’t you expect your approach to them to also change?

How Will You Do It? This is your plan for delivering an acceptable solution. The ideal plan will be the cradle-to-grave description of the work to be done, how long it will take, what resources will be needed, and how much the solution will cost. Whatever you may have been taught elsewhere, the reality is that developing such a complete plan is seldom possible. There are many situations that prevent the complete plan from being written and attained. These will be covered in Part II. When you can’t build that ideal plan, you will have to use some variant of a just-in-time planning model. There are several such models that you will learn about in Part II. A just-in-time plan actually evolves over the course of doing the project. Plan a little, do a little, and continue in that repetitive fashion until the project is completed. I will identify the different situations that arise and provide alternative approaches to planning and executing such projects. Here is where organized common sense makes its initial stand.

How Will You Know You Did It? Business reasons (success criteria) were put forth for justifying doing the project. An acceptable solution will meet both client requirements and those business success criteria. Client requirements are what the client believes define the best way to meet those business success criteria. If satisfying client requirements does result in the best solution, then those business success criteria will have been met as well. These will be quantified metrics with specific values that define project success. Either you met them and the project

25

Page 25

Wysocki

26

Part I

■

c02.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

was a success, or you didn’t and the project was to some degree a failure. The success criteria should be stated at the beginning of the project in such a way that it is obvious that by the end of the project they have or have not been met. This is not a debate that takes place at the end of the project. It is a quantified statement made with the client during the very early stages of the project.

How Well Did You Do? The project work is complete, and the solution has been implemented. It’s time for the post-mortem. There are two different things to consider in analyzing how well you did. The first is the quality of the product that was produced by the project. Did it meet the client requirements, and did it achieve the business success criteria that justified doing the project in the first place? Both you and the client assume that by satisfying requirements, the desired business value was achieved. The cause-and-effect relationship that you identified may or may not be the dominating factor. Perhaps there are other confounding factors that were not considered in the original requirements list. The requirements definition is complex. Most project management gurus would agree that in all but the most trivial projects, a complete requirements definition cannot be done at the beginning of the project. Instead, the requirements list is a changing and expanding list that evolves over the life of the project. Requirements are learned and discovered during the course of executing the project plan. Planning and managing such a project becomes a real challenge but is not insurmountable. Part II explores these situations in great detail. The second thing to consider is the process that was followed to produce the product. The correct analysis of the process that was followed will answer these four questions: How well defined and documented were the project management processes you chose to use? How well did the chosen processes fit the needs of the project? How well did the team follow the chosen processes? How well did the chosen processes produce the expected results? Answers to the first two questions provide input to needed project management process improvements, and answers to the last two questions will provide input to needed practice improvement efforts (for example, training needs or improved processes for making project assignments).

C R O S S - R E F Chapter 15 describes how to establish and conduct continuous process and practice improvement programs.

12:00am

Page 26

Wysocki

Chapter 2

■

c02.tex

V2 - 03/20/2009

12:00am

Understanding The Project Management Process Groups

Defining the Five Process Groups In addition to answering the six questions that a valid project management methodology must answer, whatever project management life cycle model you use must contain all of the following Process Groups: Scoping Process Group (which PMI calls the Initiating Process Group) Planning Process Group Launching Process Group (which PMI calls the Executing Process Group) Monitoring and Controlling Process Group Closing Process Group These five Process Groups are the building blocks of every PMLC. In the simplest of cases, the Process Groups will each be completed once and in the sequence listed here. In more complex situations, some or all of them might be repeated a number of times. These five Process Groups are defined in PMBOK. What follows is my adaptation of these Process Groups for use in this book and to prepare you to adapt them for your own use. I have added other processes to conform to the PMLC requirements in Part II. None of these adaptations contradict any of the principles underlying PMBOK.

The Scoping Process Group PMBOK calls this the Initiating Process Group. However, the term initiating can be confusing if you are new to project management. I find the term scoping to be clearer. This Process Group includes all processes related to answering the question ‘‘What do you need to do?’’ It does not include any processes related to doing any project work. That project work is defined in the Planning Process Group to be done later in the project life cycle. The Scoping Process Group also includes establishing the business success criteria that will be the metrics used to answer the question ‘‘How will you know you did it?’’ The Scoping Process Group includes the following processes: Recruiting the project manager Eliciting the true needs of the client Documenting the client’s needs Negotiating with the client about how those needs will be met

27

Page 27

Wysocki

28

Part I

■

c02.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

Writing a one-page description of the project Gaining senior management approval to plan the project As you can see, the successful completion of the Scoping Process Group is to gain the approval of senior management to move to the next phase of the project. In every PMLC, the next phase will be defined by the Planning Process Group. This direct linkage of the Scoping and Planning Process Groups is present in every PMLC you will study in Part II.

The Planning Process Group The Planning Process Group includes all processes related to answering the question ‘‘How will you do it?’’ These processes are as follows: Defining all of the work of the project Estimating how long it will take to complete the work Estimating the resources required to complete the work Estimating the total cost of the work Sequencing the work Building the initial project schedule Analyzing and adjusting the project schedule Writing a risk management plan Documenting the project plan Gaining senior management approval to launch the project There are a number of ways that each of the processes in the Planning Process Group can be done. The way that they are done may be a function of the PMLC model being used or any of several other factors. I’ll offer my experiences in executing each process and in many cases offer several alternative ways of conducting the process. Choosing which to use in a given situation is where organized common sense again takes its stance.

The Launching Process Group PMBOK calls this the Executing Process Group. It is that and more. The Launching Process Group includes all processes related to recruiting and organizing the team and establishing the team operating rules. These processes are preparatory to executing the project. The Launching Process Group also includes all of the processes related to getting the project work started. These would be the executing processes.

12:00am

Page 28

Wysocki

Chapter 2

■

c02.tex

V2 - 03/20/2009

12:00am

Understanding The Project Management Process Groups

The Launching Process Group includes the following processes: Recruiting the project team Writing a project description document Establishing team operating rules Establishing the scope change management process Managing team communications Finalizing the project schedule Writing work packages All of these processes relate more to the art of project management than to the science of project management. During the execution of this Process Group, the entire team may be coming together for the first time. There will be client members and your delivery team members present. Perhaps they are mostly strangers to one another. At this point, they are nothing more than a group. They are not yet a team but must become one in very short order. Thinking back over my early experiences as a project manager when meeting my team members for the first time, I think of my task to create a team as something akin to herding cats. You can’t herd cats. There will be confusion and anxiety as they stare across the table at each other wondering why they are there, what they will be doing on the project, and what is happening on the project they should be working on in their home department. Being fully aware of this, the project manager will conduct that first team meeting with care, giving team members an opportunity to introduce themselves and what they bring to the project to the other team members.

The Monitoring and Controlling Process Group The Monitoring and Controlling Process Group includes all processes related to the ongoing work of the project. These processes are as follows: Establishing the project performance and reporting system Monitoring project performance Monitoring risk Reporting project status Processing scope change requests Discovering and solving problems Here is where the real work of the project takes place. It is a Process Group that consists of both the art and science of project management. It occupies

29

Page 29

Wysocki

30

Part I

■

c02.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

the project manager with activities internal to the project team itself (mostly science but a dose of art as well) and with activities external to the project team and dealing with the client, the sponsor, and your senior management (mostly art but a dose of science as well). As problems and change requests arise, the strength of your relationship with your client will in large measure contribute to the success or failure of the project.

The Closing Process Group The Closing Process Group includes all processes related to the completion of the project, including answers to the three questions related to the question ‘‘How well did you do?’’ These processes are as follows: Gaining client approval of having met project requirements Planning and installing deliverables Writing the final project report Conducting the post-implementation audit The end is finally coming into sight. The client is satisfied that you have met the acceptance criteria. It’s time to install the deliverables and complete the administrative closedown of the project.

Defining the Nine Knowledge Areas The nine Knowledge Areas are part of the PMBOK and are all present in every project management life cycle. They define the processes within each Process Group and often are part of more than one Process Group. This book covers all nine Knowledge Areas. The names of the Knowledge Areas used here are the same as the names used by PMI. They are defined later in this section.

Mapping Knowledge Areas to Process Groups As you can see in Table 2-1, Process Groups and Knowledge Areas are closely linked.

What the Mapping Means This mapping shows how interdependent the Knowledge Areas are with the Process Groups. For example, eight of the nine Knowledge Areas are started during the Planning Process Group and executed during the Monitoring and Control Process Group. That gives clear insight into the importance of

12:00am

Page 30

Wysocki

Chapter 2

■

c02.tex

V2 - 03/20/2009

12:00am

Understanding The Project Management Process Groups

certain deliverables in the project plan and guidance as to the content of the project plan. Table 2-1 Mapping of the Nine Knowledge Areas to the Five Process Groups MONITORING SCOPING PLANNING LAUNCHING AND CONTROL- CLOSING KNOWLEDGE AREAS INTEGRATION

PROCESS

PROCESS

PROCESS

LING PROCESS PROCESS

GROUP

GROUP

GROUP

GROUP

GROUP

X

X

X

X

X

SCOPE

X

X

TIME

X

X

COST

X

X

QUALITY

X

X

X

HR

X

X

X

COMMUNICATIONS

X

X

X

RISK

X

PROCUREMENT

X

X

X

X X

How to Use the Mapping The mapping provides an excellent blueprint for designing your project management approach to a project. For example, Procurement Management spans the Planning, Launching, Monitoring and Controlling, and Closing Process Groups. Therefore, a PMLC model for Procurement Management will be effective if it has components in each of those Process Groups.

Definition of a Project Management Life Cycle A project management life cycle (PMLC) is a sequence of processes that includes scoping, planning, launching, monitoring, controlling, and closing the projects to which it applies. A valid PMLC always starts with a single scoping process and ends with a single closing process. The intervening processes must each be done at least once and may be repeated any number of times in some logical order. The logical ordering of these processes is a function of the characteristics of the project. This book defines five different PMLC models. Each is constructed to meet the specific needs of a specific type of project.

31

Page 31

Wysocki

32

Part I

■

c02.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

Using Process Groups to Define PMLCs Many who are new to project management make the mistake of calling the Process Groups a project management methodology. This is incorrect. However, by properly sequencing and perhaps repeating some Process Groups, you can define PMLCs that are project management methodologies. So the Process Groups are the building blocks of project management methodologies. Similarly, by selecting and adapting the processes within a Process Group, you can establish the specific processes that drive a PMLC. So the processes within a Process Group are the detailed building blocks of the phases of the PMLC.

A Look Ahead: Mapping Process Groups to Form Complex PMLCs There are five PMLCs that are defined in Part II. These five PMLCs are inclusive of all the meaningful PMLCs you could form, and they completely cover the four quadrant project landscape. So regardless of the kind of project you have to manage, you will be able to use one of the five PMLCs as the project management methodology for the project. A given PMLC can be modified to accommodate a specific project as described in Part II.

Integration Management This knowledge area addresses the glue that links all of the deliverables from the Process Groups into a unified whole. This linkage begins with the project description document and extends to the project plan and its execution, including monitoring progress against the project plan and the integration of changes, and finally through to project closure.

Scope Management The major focus of the Scope Management Knowledge Area is the identification and documentation of client requirements. There are many ways to approach requirements gathering and documentation. The choice of which approach or approaches to use depends on several factors. Following requirements gathering and documentation, you choose the best-fit project management life cycle and develop the Work Breakdown Structure (WBS) that defines the work to be done to deliver those requirements. That prepares the team and the client with the information they need to estimate time, cost, and resource requirements. The Scope Management Knowledge Area overlaps the Scoping and the Planning Process Groups.

12:00am

Page 32

Wysocki

Chapter 2

■

c02.tex

V2 - 03/20/2009

12:00am

Understanding The Project Management Process Groups

Time Management Time management includes both a planning component and a control component. The planning component provides time estimates for both the duration of a project task (that is, how long will it take in terms of clock time to complete the task) and the actual effort or labor time required to complete the task. The duration is used to estimate the total time needed to complete the project. The labor time is used to estimate the total labor cost of the project. The control component is part of the Monitoring and Controlling Process Group and involves comparing estimated times to actual times as well as managing the schedule and cost variances.

Cost Management Cost management includes both a planning component and a control component. The planning component includes building the project budget and mapping those costs into the project schedule. This provides a means of controlling the consumption of budget dollars across time. Variance reports and earned value reports are used in the Monitoring and Controlling Process Group.

Quality Management Good quality management is probably one of the Knowledge Areas that gets a rather casual treatment by the project manager and the team. A good quality management program contains the following three processes: Quality planning process Quality assurance process Quality control process The focus on quality is usually on the product or deliverable that is produced. If it meets specific physical and performance characteristics, it will be validated as fit for use and can be released to the client. Validation that a product is fit for use is the result of the product passing certain tests at various points in the product development life cycle. Passing these tests allows the product to pass to the next stage of development. Failure to pass a test leads to reworking the product until it passes or to outright rejection if reworking the product to remove whatever defects were discovered does not make good business sense. Quality in this context means the product meets the following criteria: It’s fit for use.

33

Page 33

Wysocki

34

Part I

■

c02.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

It meets all client requirements. It delivers on time, within budget, and according to specification. Note that this says nothing about exceeding requirements. Many project managers are ingrained with the idea that they have to ‘‘delight the client.’’ For example, if you promised product delivery on Friday, you try to get the product to the client on Thursday. Or if you estimated that the product would cost $2.00, you try to get the cost down to $1.95. These are all well and good and are part of excellent client service, but they have nothing to do with quality. Quality refers to meeting agreed requirements not exceeding them. Your quality management program should focus on meeting product and process requirements.

Quality Planning Process There will be standards that the product and the process will have to meet. These may be external to the organization (federal or agency quality requirements) or internal (company policies and guidelines). In addition, there will be project-specific requirements that must be met. Quality planning must integrate all of these into a cohesive program.

Quality Assurance Process Quality assurance includes activities that ensure compliance to the plan. The specific tools, templates, and processes that you use to do this are discussed in Chapter 15.

Quality Control Process This process involves the actual monitoring of the project using the quality tools, templates, and processes discussed in Chapter 15 as well as other project management monitoring and reporting tools.

Human Resource Management Some would suggest that the job of the project manager is to manage the work of the project. They would add that it is not the job of the project manager to manage the members of the team. Management of the team members is the province of their line manager. In a utopian world, this might be acceptable management practice, but in the contemporary project world, the situation is quite different. More than likely your request for a certain profile of skills and experiences among your team members will not be met by those who are assigned to work on your project. Skill shortages, unavailability of a

12:00am

Page 34

Wysocki

Chapter 2

■

c02.tex

V2 - 03/20/2009

12:00am

Understanding The Project Management Process Groups

specifically skilled person, and other factors will result in a less-than-adequate team. What you get is what you get, and you will have to make the best of it. Therefore, I don’t think it is that simple, and both the line manager and the project manager share the people management responsibilities. Because the skills and/or competency of the team you have to work with may not be ideal, staff development will be one area where you and the line manager share responsibility. The line manager is responsible for assigning people to projects in accordance with each person’s skill and competency profile as well as his or her career and professional development plans. Once a person is assigned to a project, it is then the project manager’s responsibility to make assignments in accordance with the person’s skill and competency profile and their professional development plans. Obviously this will be a collaborative effort between you and the line manager. Having motivated team members is in the best interest of the project, the project manager, and the organization. It is my opinion that when you align people’s interests and professional development needs to their project assignments, you gain a stronger commitment from the team members. Again, the line manager and the project manager share the responsibility for making this happen.

Projects as Motivation and Development Tools Not everyone can be motivated. To assume otherwise is risky. In fact, in most cases all that the manager can do is create an environment in which the subordinate might be motivated and then hope that he or she is. It’s really like farming. All the farmer can do is pick the crop to plant, the acreage to plant it on, and the fertilizer to use, and then hope that nature supplies the right amounts of rain, wind, and sunshine. The same scenario applies to the project manager. He or she must create a working environment that is conducive to and encourages the development of the team members, leaving it up to them to respond positively. Fortunately, you do have some information on what professional staffs perceive as motivators and hygiene factors on the job. Motivators are behaviors or situations that have a positive impact on the worker — they motivate the worker to better performance. Hygiene factors, on the other hand, are things that, by their absence, have a negative impact on performance, but don’t necessarily motivate the worker if they are present. To put it another way, workers have certain expectations, and to not fulfill them is to demotivate them. These are hygiene factors. For example, workers expect a reasonable vacation policy; to not have one acts as a demotivator. Conversely, having a good vacation policy does not necessarily motivate the worker. The following list of motivators was created as a result of a 1959 survey of professionals

35

Page 35

Wysocki

36

Part I

■

c02.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

by Frederick Herzberg,1 a professor known for his research in motivational theory. Although the survey was conducted 50 years ago, it has become a classic study and still applies today. Motivators

Herzberg identified the following motivators: Achievement Recognition Advancement and growth Responsibility Work itself Hygiene Factors

Herzberg identified the following hygiene factors: Company policy Administrative practices Working conditions Technical supervision Interpersonal relations Job security Salary Note that motivators are related to the job, specifically to its intrinsic characteristics, whereas hygiene factors are related to the environment in which the job is performed. The good news is that the manager has some amount of control over the motivators relating to the job. The bad news is that the hygiene factors, being environmental, are usually beyond the control of the project manager. As a project manager, you can bring hygiene factors to the attention of your senior management, but you’re otherwise powerless to change them. Motivating Factors

Daniel Couger, a professor of Computer Science at Colorado State, conducted a similar survey in 1985. Here the respondents were analysts and programmers. The responses were grouped by areas that the respondents considered 1 Both

Herzberg and Daniel Couger studies are reported in ‘‘Another Look at Motivating Data Processing Professionals’’ by Ramon A. Mata Toledo and Elizabeth A. Unger. Department of Computer Science, Kansas State University, Manhattan, KS: p. 4, 1985.

12:00am

Page 36

Wysocki

Chapter 2

■

c02.tex

V2 - 03/20/2009

12:00am

Understanding The Project Management Process Groups

motivators and areas that they considered demotivators. The following is a combined list of these areas, ordered from highest motivator to lowest motivator: The work itself Opportunity for achievement Opportunity for advancement Pay and benefits Recognition Increased responsibility Technical supervision Interpersonal relations Job security Working conditions Company policy The motivators that are high on the list tend to be intrinsic to the job, such as providing opportunities for advancement and recognition, whereas the demotivators, which are lower on the list, tend to be environmental factors such as working conditions (for example, parking areas) and company policy (for example, sick leave and vacation time). Several of the motivators are directly controlled or influenced by actions and behaviors of the project manager regarding the work that the team member will be asked to do. They are as follows: Challenge

Professionals respond to a challenge. In general, if you tell a professional that something cannot be done, his or her creative juices begin to flow. Some may even view such a statement as an insult to their intelligence and creativity. The result is a solution. Professionals dread nothing more than practicing skills, long since mastered, over and over again. Boredom sets in quickly and can lead to daydreaming and lack of attention to detail, which results in errors. Challenging the professional does not mean that every moment of every day should be spent solving previously unsolved problems. Usually, an hour or two on a new and challenging task per day is sufficient to keep a professional motivated throughout the day. Recognition

Professionals want to know that they are progressing toward a professional goal. Publicly and personally recognizing achievements and following with

37

Page 37

Wysocki

38

Part I

■

c02.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

additional challenges tells the professional that his or her contribution is valued. Recognition, therefore, does not necessarily mean dollars, promotions, or titles. Job Design

Because the job itself is such an important part of motivation, take a look at job design for just a moment. The following five dimensions define a job: Jobs that do not offer much task variety or the opportunity to learn and practice new skills become boring for most people. In designing jobs, it is important to consider building in some task variety. This variety, at the very least, can provide a diversion from what otherwise would be a tedious and boring workday. It can also provide a break during which the person can learn a new skill. With a little bit of forethought, the project manager can find opportunities for cross-training by introducing some task variety for new skills development.

Skill variety

W A R N I N G You, as the project manager, must consider the risk involved in such actions. The person may not rise to the challenge of the new task or might not have the native ability to master the skills needed to perform the new task. Task identity People need to know what they are working on. This idea is especially true for contracted team members. The project manager should help them understand their work in relation to the entire project. Knowing that their task is on the critical path will affect their attitude and the quality of their work. Task significance In assessing a task’s significance, workers ask themselves questions such as these: Does it make any difference if I am successful? If I am late, will anybody notice? Just how important is my work to the overall success of the project? Am I just doing busywork to pass the time? Team members need to know whether their effort and success make any difference to the success of the project. Autonomy Professionals want to know what is expected from them — what

are the deliverables? They don’t want to hear every detail of how they will accomplish their work. That is blatant micro-management and must be avoided at all costs. It’s okay to tell team members what they need to deliver, but not how they should go about delivering it. They want to make that decision themselves. Professionals tend to be rugged individualists. They want to exercise their creativity. They want freedom, independence, and discretion in scheduling their work and determining the procedures they will follow to carry it out.

12:00am

Page 38

Wysocki

Chapter 2

■

c02.tex

V2 - 03/20/2009

12:00am

Understanding The Project Management Process Groups

Feedback Good, bad, or indifferent, professionals want to know how effective

they are in their work. Paying attention to what a team member is doing is motivating in itself. Having something good to say is even better. When a person’s performance is below expectations, tell them. If you can convince them that they own the problem, ask them for an action plan to correct their marginal performance. Then help them do it.

Communications Management At the heart of many of the top ten reasons why projects fail is poor communications. As many as 70 percent of the IS/IT project failures can be traced back to poor communications. It is not difficult to plan an effective communications management process, but it seems to be very difficult to execute that plan. A good communications management process will have provisions in the process that answer the following questions: Who are the project stakeholders? What do they need to know about the project? How should their needs be met?

Who Are the Project Stakeholders? Any person or group that has a vested interest in the project is a stakeholder. Those who are required to provide some input to the project affect the project and are therefore stakeholders. They may not be willing stakeholders, but they are stakeholders nevertheless. Those who are affected by the project are stakeholders. Often they are the same group requesting the project, in which case they will be willing stakeholders. There will also be unwilling stakeholders who are affected by the project but had little or no say in how the project actually delivered against stated requirements. The project manager needs to be aware of all these stakeholder groups and communicate appropriately to them.

What Do They Need to Know about the Project? There will be a range of concerns and questions coming from every stakeholder group. Some of the more commonly occurring are as follows: What input will I be required to provide the project team? How can I make my needs known? When will the project be done? How will it affect me?

39

Page 39

Wysocki

40

Part I

■

c02.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

Will I be replaced? How will I learn how to use the deliverables? Your communications management plan will be effective only if it accounts for each group and their individual needs.

How Should Their Needs Be Met? This depends on the purpose of the communication. If it’s to inform, there will be many alternatives to choose from. If it’s to get feedback, you have fewer alternatives from which to choose. Chapter 5 provides all of the details on building an effective communications management plan.

Risk Management Unfortunately, many project managers view risk as something they pay attention to at the beginning of the project by building some type of risk management plan and then file it away so they can get on with the real work of the project. How shortsighted. Effective project managers treat risk management as a dynamic part of every project. Their plan has the following four parts: Risk identification Risk assessment Risk mitigation Risk monitoring In project management, a risk is some future event that happens with some probability and results in a change, either positive or negative, to the project. For the most part, risk is associated with loss, at least in the traditional sense. But there might be a gain if the event happens. For example, suppose you know that a software vendor is working on a language translator, and if it is available by a certain date, you will be able to use it to save programming time. More commonly, though, a risk event is associated with a loss of some type. The result might be a cost increase, a schedule slippage, or some other catastrophic change. The cost of loss can be estimated. The estimate is the mathematical product of the probability that the event will occur and the severity of the loss if it does. This estimate will force the project manager to make a choice about what to do, if anything, to mitigate the risk and reduce the loss that will occur. This estimate is the basis of a series of choices that the project manager has to make. First of all, should any action be taken? If the cost of the action

12:00am

Page 40

Wysocki

Chapter 2

■

c02.tex

V2 - 03/20/2009

12:00am

Understanding The Project Management Process Groups

exceeds the estimated loss, no action should be taken. Simply hope that the event doesn’t occur. The second choice deals with the action to be taken. If action is called for, what form should it take? Some actions may simply reduce the probability that the event will occur. Other actions will reduce the loss that results from the occurrence of the event. It is usually not possible to reduce either the probability or the loss to zero. Whatever actions are taken will only tend to reduce the loss in the final analysis. The business decision is to assess how the expected loss compares to the cost of defraying all or some of the loss and then taking the appropriate action. With project management, the risks that need to be managed are those that will hurt the project itself. Although the project may affect the total business, the total business isn’t the domain of the project manager.

N O T E As I alluded to earlier, newer risk theories deal with entrepreneurial risk for which there is not only a probability of loss, but also a possibility of gain. This is common in businesses where capital is put at risk in order to fund a new business venture. For the most part, this book deals with risk in the traditional sense, where risk is the possibility of loss.

Risk management is a broad and deep topic, and I am only able to brush the surface in this book. A number of reference books on the topic are available. The bibliography in Appendix B lists some specific titles you can use as a reference. The risk analysis and management process that I briefly describe answers the following questions: What are the risks? What is the probability of loss that results from them? How much are the losses likely to cost? What might the losses be if the worst happens? What are the alternatives? How can the losses be reduced or eliminated? Will the alternatives produce other risks? To answer these questions, the following sections define risk management in four phases: identification of risk, assessment of risk, risk response planning, and monitoring and controlling. These are the same phases defined by PMBOK.

Risk Identification To establish the risk management for the project, the project manager and project team must go through several processes. The first is identifying risk. In this part of the process, the entire team is brought together to discuss and identify the risks that are specific to the current project. I recommend that the

41

Page 41

Wysocki

42

Part I

■

c02.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

meeting focus solely on risk. A meeting with such a single focus enables the entire project team to understand the importance of risk management, and it gets everyone thinking about the various risks involved in the project. Risk arises from several different directions but it generally can be classified into one of the following four categories: Technical risks Project management risks Organizational risks External risks

C R O S S - R E F These categories of risk are defined in Chapter 4.

Risk Assessment There are two major factors in assessing risk. The first one is the probability that the risk event will occur. For instance, when a project involves migrating legacy systems to new systems, the interface points between the two are often where problems occur. The professional project manager will have a good sense of these types of risks and the chances that they will occur.

N O T E If you are certain that an event will occur, it’s not a risk; it’s a certainty. This type of event isn’t handled by risk management. Because you are sure that it will occur, no probability is involved. No probability, no risk.

The second part of risk assessment is the impact the risk will have on the project. If a risk has a 50-percent probability of occurring, you need to assess what the impact will be, because a 50-50 chance of something happening is fairly high. To assign a numerical score to a risk event, you simply multiply the probability of the risk occurring times the impact that the event’s occurrence would have. At first glance, this may seem to be a rigorous mathematical process, but it’s not. The probability of an occurrence is subjective to a great extent, as is the impact of the event. You should get advice from the team regarding both the probability of occurrence and the impact that risks will have on the project, but in the end, your experience and a good dose of common sense will give you a good start on handling the risk.

Risk Mitigation The next step in risk management is to plan, as much as possible, the responses that will be used if the identified risks occur. For instance, you may want to include a clause in your hardware contract with the vendor that if the servers don’t get to you by a certain date, then the vendor will pay a penalty.

12:00am

Page 42

Wysocki

Chapter 2

■

c02.tex

V2 - 03/20/2009

12:00am

Understanding The Project Management Process Groups

This penalty gives the vendor an incentive to analyze and mitigate the risks involved in late delivery of key equipment. For all the risks listed in the risk identification that you choose to act upon, you should have some type of action in mind. It’s not enough to simply list the risks; you need to plan to do something about the risk events should they occur. Another example of risk planning is planning for key personnel. What will you do if one of the key developers leaves the company before finishing the coding? This risk will impact the project severely if it occurs. Having someone capture code as it is written and debriefing with the developer each day are two ways of dealing with the risk of key personnel loss. How many others can you come up with? Coming up with contingency plans such as these is risk response planning. There are five different risk responses. They are briefly defined in the list below. Accept. There is nothing that can be done to mitigate the risk. You just have to accept it and hope it does not occur. Avoid. The project plan can be modified so as to avoid the situation that creates the risk. Contingency planning. If the risk event occurs, what will you do? Mitigate. What will you do to minimize the impact should the risk event occur? Transfer. Pass the impact should the risk event occur (i.e., buy an insurance policy).

Risk Monitoring Once you’ve identified the risk, assessed the probability and impact of the risks, and planned what to do if the risk event occurs, you need to monitor and control the project risks. The process of writing down the risks, assessing them, and posting them in the Team War Room makes everyone on the project team aware of their existence and is a good place to start. Start by creating a risk log. This document lists all risks that you want to manage, identifies who is supposed to manage the risk, and specifies what should be done to manage the risk event. A risk log is a simple template that can be created in a text document or spreadsheet package. A typical risk log is discussed in Chapter 4. Use the risk log to keep track of risk in the project, and you’ll have control over it. When you go to status meetings, you should always talk about risks and their management by the team. Keep the risks in front of the team so that each member will be aware of what risks are coming up and what is to be done about the risk event. Continuously paying attention to the risks is a good insurance policy against project failure.

43

Page 43

Wysocki

44

Part I

■

c02.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

Procurement Management The Procurement Management Knowledge Area consists of processes that span the Planning, Launching, Monitoring and Controlling, and Closing Process Groups. An effective procurement management life cycle consists of the following five phases: Vendor solicitation Vendor evaluation Vendor selection Vendor contracting Vendor management As a project manager, you will always have projects for which you must obtain hardware, software, or services from outside sources. This process is known as procurement, and the professional project manager must have a basic understanding of the acquisition procedure so that he or she can ensure that the organization is getting the right materials at the best cost or the best services at the best cost. To manage procurement, you need to go through a few processes, which are summarized in the next few sections. Chapter 3 presents a detailed discussion.

Vendor Solicitation After you’ve done your requirements gathering and have made the decision that you need an outside vendor, you can begin to prepare procurement documents for solicitation. These documents, called Requests for Proposals (RFPs), are what vendors use to determine if and how they should respond to your needs. The clearer the RFP, the better off you and the vendor are, because you will be providing basic information about what you want (don’t forget about the earlier discussion of needs versus wants). The more specific you are, the better the chance that the vendor will be able to respond to you quickly and efficiently. Many organizations have a procurement office. In this case, you need to give them a document with your requirements and let them do their work. If you don’t have a procurement office, you need to prepare a document to send to the vendors. You’ll want to have a lead writer (preferably not you) and someone from the legal department to ensure that what you’ve asked for in the document is clear and forms the basis for a contract between you and the vendor.

Vendor Evaluation Before you even start reading the responses to your proposal, set the standards for choosing a given vendor. These criteria may be based on technical expertise,

12:00am

Page 44

Wysocki

Chapter 2

■

c02.tex

V2 - 03/20/2009

12:00am

Understanding The Project Management Process Groups

experience, or cost, but whatever criteria you use, it must remain the same for all of the vendors. If you are a public company, every vendor you’ve turned down will ask for a copy of the winning bid. If they think they have a better bid, all sorts of nasty things may occur (read: legal action). If, however, you have a standards chart, you can point out that everyone was rated with the same criteria and that the winner had the best overall number. By determining your criteria for vendor selection early in the process, it is easier to make a decision and then defend it if need be.

Vendor Selection The result of vendor evaluation usually does not produce a single best choice. There will most likely be several competing vendors for all or parts of the work. So you have another decision to make and that is which vendor or vendors will win your business.

Vendor Contracting When the software application is to be developed solely by the vendor, the project manager’s primary job is contract management. Contract management involves the following: The vendor must supply you with deliverable dates so that you can determine whether the project is on time. The vendor should also supply a WBS detailing how the vendor breaks down the scope of the project and showing the tasks that make up the completion of a deliverable. The project manager should hold regular status meetings to track progress. These meetings should be formal and occur on specified dates. The status meetings should occur at least once a week, although in the early stages of the project, you may choose to have them more often. These status meetings will give you an idea of how the vendor is proceeding in fulfilling the contract, and by having them at weekly intervals, you won’t allow the project to get very far off course. At most, you will only need to correct a week’s worth of problems — anything longer than that can quickly become unmanageable. In your contract, state who the contract manager will be for your organization. This is typically the project manager (which will be you if you’re managing this project), but in some organizations, contract management functions are handled by a specific department or team. I prefer contract management to be in the hands of the project manager, or at least to have the project manager as part of the contract management team.

45

Page 45

Wysocki

46

Part I

■

c02.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

Vendor Management Closing out the contract is often an overlooked function of the project manager. It both certifies what has been done and gives all parties a chance to deal with open issues and final payments. The professional project manager will be aware of all of the steps that must be followed in the procurement process even though he or she may not be the person directly responsible for managing them. This is just another part of being a project management professional. Consider the following as you bring a contract to a close: There should be a clear understanding of when the project is finished. When you write your RFP, state clearly how the project finishes. That is often done by writing a project acceptance test procedure. It is nothing more than a checklist of what the client views as a completed project and what the final deliverable is. Failure to do this will almost always lead to cost overruns in the form of maintenance activities under the heading of project work. State what the final product of the project is to be, who is to determine if it has been delivered, and what is to be done with any open issues. Make this information as clear as possible, and you will save the company thousands of dollars. After the contract is closed, make sure you file all of the materials used during the project. These materials include the original RFP, the project baseline, the scope statement, the WBS, the various plans used to manage the project, and all changes, including those that were requested but turned down. You also need to show all payments and make sure that any subcontractors on the project were paid. Confirming that subcontractors have been paid is done through the vendor, who must show that all payments to subcontractors have been made. Put all this information into a large file and keep it. How long? I have seen instances of disputes coming up years after a project is finished. Keep it as long as the project product is in use. Ideally, keep these records permanently. Check with your management regarding your company’s retention policies.

Putting It All Together This chapter defined all of the Process Groups and listed the processes that they comprise. You know about Knowledge Areas and how they intertwine with the Process Groups. What you don’t yet know is how all of these processes are put together to produce project management methodologies specific to the varying management needs of different types of projects. That is the topic of Part II.

12:00am

Page 46

Wysocki

Chapter 2

■

c02.tex

V2 - 03/20/2009

12:00am

Understanding The Project Management Process Groups

The remaining chapters of Part I dig deeper into the Knowledge Areas and show you the many ‘‘how-to’s.’’ You will learn about the various methods that can be used to execute the processes within each Knowledge Area. In Part II, you will learn how to choose the best-fit method to execute a process, which may be a direct result of the type of project or dependent on one or more external factors.

Discussion Questions 1. Other than the five Process Groups and nine Knowledge Area approach taken by PMI, how else might you structure your approach to defining a project management methodology for your company? 2. As far as your company’s needs for a project management methodology are concerned, are any of the Process Groups incomplete? Do any of the Process Groups have superfluous processes that would not be applicable to your company? Which are they and why would they not work for you? 3. Can you think of a sixth Process Group or tenth Knowledge Area that your company would require of its project management methodology? 4. Consider a project management methodology that specifies only the six questions stated in the ‘‘Understanding the Fundamentals of Project Management’’ section of this chapter. All that is required of the project manager and client is to provide answers to those six questions. Could this approach be made to work? If yes, how? If not, why not?

47

Page 47

Wysocki

c02.tex

V2 - 03/20/2009

12:00am

Page 48

Wysocki

c03.tex

V2 - 03/20/2009

4:45pm

CHAPTER

3

How to Scope a Project Prediction is very difficult, especially about the future. — Neils Bohr Define the problem before you pursue a solution. — John Williams, CEO, Spence Corp.

CHAPTER LEARNING OBJECTIVES After reading this chapter, you will be able to: ◆ Understand what managing client expectations really means ◆ Explain the Conditions of Satisfaction (COS) development process ◆ Develop the COS document ◆ Recognize the importance of maintaining the COS throughout the entire project life cycle ◆ Plan and conduct the Project Scoping Meeting ◆ Build the Requirements Breakdown Structure (RBS) ◆ Diagram business processes ◆ Know what a prototype is and when to use one ◆ Validate a business case ◆ Outsource project work ◆ Understand procurement management (continued)

49

Page 49

Wysocki

50

Part I

■

c03.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

CHAPTER LEARNING OBJECTIVES (Continued) ◆ Define the basic parts and function of the Project Overview Statement (POS) ◆ Write a saleable POS for your project idea using the language of your business ◆ Understand the role of the POS in the project management life cycle (PMLC) ◆ Write clear goal and objective statements ◆ Establish measurable criteria for project success ◆ Identify relevant assumptions, risks, and obstacles ◆ Discuss attachments to the POS and their role in project approval ◆ Understand the approval process for the POS

The Scoping Process Group defines all of the tools, templates, and processes needed to answer two questions: ‘‘What do you need to do?’’ and ‘‘How will you know you did it?’’ If you don’t know where you are going, how will you know when and if you ever get there? If I had to pick the Process Group where most of the project failures originated, it would be the Scoping Process Group. Not only is it the most difficult of the five Process Groups, but it is also the most sloppily executed of the five Process Groups. So many times I have seen projects get off to a terrible start simply because there never was a clear understanding of exactly what was to be done. A definition of completeness or doneness was never documented and agreed to. In this chapter, you will learn all of the tools, templates, and processes needed to get you started on the right foot with a series of activities that lead to a clearly defined and understood definition of what the project is all about. After you have learned how to put an initial project scope in place, you will learn how to maintain that scope. It may change as you learn more about the solution during project execution, but that is the nature of projects. In my experience, if there is no change, there probably won’t be a satisfactory outcome either.

Using Tools, Templates, and Processes to Scope a Project The effective scoping of a project is as much an art as it is a science. There are a number of tools, templates, and processes that can be used during the scoping

4:45pm

Page 50

Wysocki

c03.tex

Chapter 3

■

V2 - 03/20/2009

4:45pm

How to Scope a Project

effort, and they are all precisely defined and documented in this chapter. That is the science of scoping. Knowing your client, the enterprise’s environment, and the market climate and how to adapt the tools, templates, and processes to them is the art of scoping. Virtually all of the scoping effort involves an interaction and collaboration between the client who is requesting a service or product and the project manager who is providing the service or product. That collaboration can be very informal (the ‘‘back of the napkin’’ approach) or very formal (a planned scoping meeting). In both cases, a document is prepared that answers the questions: ‘‘What do you need to do?’’ and ‘‘How will you know you did it?’’ The nature of that relationship will contribute to how the scoping effort proceeds and how successful it is likely to be. The following tools, templates, and processes are described in this chapter: Conditions of Satisfaction Project Scoping Meeting Requirements gathering Diagramming business processes Prototyping Validating business cases Procurement management Outsourcing Project Overview Statement Approval to plan the project

Managing Client Expectations Somehow clients always seem to expect more than project managers are prepared for or capable of delivering. I have seen this expectation gap manifest itself time and time again. I believe that it is more the result of a failure to communicate than it is of anything else. This lack of communication starts at the beginning of a project and extends all the way to the end. The project manager assumes he or she knows what the client is asking for, and the client assumes the project manager understands what they are asking for. In most cases, little is done to check the assumptions. That stops right here! I believe that miscommunication does not have to happen. The section ‘‘Conducting Conditions of Satisfaction’’ describes a tool that I have used successfully for many years. Understand at the outset that the tool is easy to explain and understand, but difficult to put into practice.

51

Page 51

Wysocki

52

Part I

■

c03.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

Wants versus Needs I believe that the root cause of many problems that come up in the course of a project originate from disconnects between what the client says they want and what they really need. The disconnect may come about because the client is swept up in a euphoria over the technology (for example, they may be enamored with what they see on the Web) that they have convinced themselves they have to have it without any further thought of exactly what it is they really need. The disconnect can also come about because the client does not really know what they need. In many cases, they can’t know. What they need can be discovered only through doing the project. Traditional project management (TPM) forces them to specify what they want. If there is any reason to believe that what the client says they want is different from what they need, the project manager has the responsibility of sifting and sorting this out ASAP. It would be a mistake to proceed without having the assurance that wants and needs are in alignment or can be brought into alignment. You should never start a project without knowing that the solution is in fact what will satisfy the client. That is one of the reasons for the Conditions of Satisfaction, discussed in the next section. It is a tool I have used for over 20 years, and it has served me well. Wants and needs are closely linked to one another but are fundamentally different. Wants tend to be associated with a solution that the client envisions. Needs tend to be associated with the problem. If wants are derived from a clear understanding of needs, then it is safe to proceed based on what the client wants, but you cannot always know that this is the case. To be safe, I always ask the client why they want what they want. By continuing this practice of asking why, you will eventually get to the root of the problem and needs become clear. This is not unlike a Root Cause Analysis (described in Chapter 15). The solution to that problem will be what the client really needs.

Conducting Conditions of Satisfaction You should begin every project with a communications tool called Conditions of Satisfaction (COS). The COS is a structured conversation between the client (the requestor) and the likely project manager (the provider). The deliverable from the COS is a one-page document (with attachments) called the Project Overview Statement (POS). The POS is a template that is used to clearly state what is to be done. It is signed by the requestor and the provider who participated in the COS exercise. When the POS is approved by senior management, the Scoping Phase is complete.

4:45pm

Page 52

Wysocki

c03.tex

Chapter 3

■

V2 - 03/20/2009

4:45pm

How to Scope a Project

N O T E The COS works well for smaller projects. It does not scale to large projects. For larger projects, a more formal process for gathering requirements is needed (described in the ‘‘Gathering Requirements’’ section later in this chapter).

If I had to pick one area where a project runs into trouble, I would pick the very beginning. For some reason, people have a difficult time understanding what they are saying to one another. How often do you find yourself thinking about what you are going to say while the other person is talking? If you are going to be a successful project manager, you must stop that kind of behavior. As a project manager, it is essential that you cultivate good listening skills. Good listening skills are important during the project scoping phase in two different project situations, as described here: The first situation, and the ideal one, occurs when a client makes a request for a project. At this point, two parties are brought together to define exactly what the request is and what kind of response is appropriate. The deliverable from this conversation is a COS. The second, and more likely, situation occurs when you inherit what I call the ‘‘water cooler project.’’ As the name suggests, these are the projects that are assigned to you when you accidentally meet your manager at the water cooler. Up to that point, you probably had not heard of the project, but you now need to find out all about it ASAP. The COS document is the result of your investigation. This section describes the process for developing the COS. The conversations and negotiations that eventually lead to an agreed-on COS have several dimensions. The process of developing the COS involves the following four parts: 1. Request. A request is made. 2. Clarification. The provider explains what he or she heard as the request. This conversation continues until the requestor is satisfied that the provider clearly understands the request. Both parties have now established a clear understanding of the request in the language of the requestor. 3. Response. The provider states what he or she is capable of doing to satisfy the request. 4. Agreement. The requestor restates what he or she understands the provider will provide. The conversation continues until the provider is satisfied that the requestor clearly understands what is being provided. At this point, both parties have established a clear understanding of what is being provided in the language of the provider.

53

Page 53

Wysocki

54

Part I

■

c03.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

Establishing a common language with which to communicate is critically important. If you don’t have that and verify that you do, you are planting the seeds of failure. Let’s walk through an example. Suppose you want a certain model of widgets in forest green to ship to your warehouse by December 1, 2009. You decide to visit the manufacturer to make this request. The conversation would go something like this: Requestor: I would like you to build five prototypes of the new forest green widgets and ship them to my warehouse on December 1, 2009. Provider: You are asking if we can get five green widget prototypes into your warehouse by December 1, 2009? Requestor: Actually, if you can get them shipped by December 1, 2009, that will be acceptable. But remember they have to be forest green. Provider: So if on December 1, 2009, I can ship five forest green widgets to your warehouse, you will be satisfied. Requestor: Yes, but they must be the new model, not the old model. Provider: The new model? Requestor: The new model. Provider: I believe I understand what you have asked for. Requestor: Yes, I believe you do. Provider: Because of my current production schedule and the fact that I have to change paint colors, I can ship two forest green widgets on November 25, 2009, and the remaining three on December 8, 2009. Requestor: If I understand you correctly, I will get five prototypes of the new forest green widgets in two shipments — two prototypes on November 25 and three on December 8. Is that correct? Provider: Not exactly. You won’t receive them on those dates. I will ship them to your warehouse on those dates. Requestor: So, let me summarize to make sure I understand what you are able to do for me. You will build a total of five forest green prototypes of the new widgets for me and ship two of them on November 25 and the remaining three on December 8? You will of course use our agreed shipment schedule so that the items will arrive two days later. Provider: That is correct. Requestor: That will be acceptable. This simple example points out the need to be very precise in what you are asking for and what you are expecting from the manufacturer. You can see the potential problem resulting from confusion between ship dates and receiving dates.

4:45pm

Page 54

Wysocki

c03.tex

Chapter 3

■

V2 - 03/20/2009

4:45pm

How to Scope a Project

Establishing Clarity of Purpose By the time you leave, both you and the client have stated your positions and know that the other party understands your position. Although the example is simple, it does establish a language between you and the provider, and both of you understand the situation. The seeds have been planted for a continuing dialog. As the project work progresses, any changes that come up can be dealt with effectively because the effort to understand each other has been made up front. The next step in the COS process is to negotiate to closure on exactly what will be done to meet the request. Obviously, some type of compromise will be negotiated. The final agreement is documented in the POS. More than likely, the parties will not come to an agreement on the first pass. As shown in Figure 3-1, this process repeats itself until there is an agreed-on request that is satisfied by an agreed-on response. As part of this agreement, the POS should include a statement of success criteria that specifies when and how the request will be satisfied. It is important that this statement be very specific. Do not leave it up to interpretation whether or not the conditions have been met. An ideal statement will have only two possible results: the criteria were met or the criteria were not met. There can be no in-between answer here. The success criteria (a.k.a. doneness criteria) will become part of the POS. The result is documented as the COS and serves as input to the POS. Clarify Request Request

Response Agreed-on Response

Negotiate agreement and write project overview statement

Figure 3-1 Establishing the COS

This early step of establishing and agreeing to what will be done is very important to the project’s success. It is difficult to do a thorough job, especially when everyone is anxious to get to work on the project. It is also a painful process. People can be impatient; tempers may flare. You may be inclined to skip this step. (‘‘Pain me now or pain me later’’ — you choose what you are willing to live with.) Even if the request seems straightforward, do not assume that you understand what the requestor has asked or that the requestor understands what you will provide, even if the request seems straightforward. Always use the COS to ensure that you both understand what is expected

55

Page 55

Wysocki

56

Part I

■

c03.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

and that you have a language with which the two of you can communicate clearly.

Specifying Business Outcomes As indicated in the previous section, it is a good idea to specify within the COS exactly what outcomes demonstrate that the COS has been met. The outcomes have been called success criteria, explicit business outcomes, and objectives, among other names. Whatever term you use, you are referring to a quantitative metric that signals success. That metric is discussed in more detail later in the chapter. For now just understand that it is a quantitative measure (for example, profit, cost avoidance, and improved service levels) that defines success.

Conducting COS Milestone Reviews The COS is not a static agreement. It is a dynamic agreement that becomes part of the continual project monitoring process. Situations change throughout the project life cycle and so will the needs of the client. That means that the COS will change. Review the COS at every major project status review and project milestone. Does the COS still make sense? If not, change it and adjust the project plan accordingly.

Planning and Conducting the Project Scoping Meeting There are a variety of ways to scope a project. At one extreme is a formal multiple-day meeting and at the other extreme is scoping on the back of a napkin over a cup of coffee at the local coffee stand. Both extremes and all of the variants in between are valid. It all depends. This section suggests the best way from my experiences. You will most likely throttle that way back to what is realistic for your environment, and that’s okay. The Project Scoping Meeting is your first substantive encounter with the client. You may have had a COS session and agreed on a high-level scope for the project but need more detail in order to write a POS. The Project Scoping Meeting takes the COS deliverable to the next level of detail. In this meeting, the core project team will be present, as will the client, several key managers, staff, and end users of the project deliverables.

Purpose There are two purposes to the Scoping Meeting. The first, which was discussed earlier in the chapter, is to draft the POS. The second is to draft the requirements

4:45pm

Page 56

Wysocki

c03.tex

Chapter 3

■

V2 - 03/20/2009

4:45pm

How to Scope a Project

document. This document will be used as further input to the POS and to help the team decide which project management approach is the best fit for this type of project.

Attendees A Scoping Meeting attended by 15–20 people is large but manageable. An experienced meeting facilitator could manage a group of more than 20 people, but it requires breakout groups and their coordination. This is definitely the territory of the skilled facilitator, not the project manager. Unfortunately the reality is that the project manager is usually recruited as the facilitator. If the scoping meeting requires more than 20 attendees, you might consider breaking the project up into two or more projects of lesser scope each or having more than one Scoping Meeting. The following three groups need to be represented at the Scoping Meeting: The client group — Decision makers as well as operations-level staff should be represented. Among them should be the individual(s) who suggested the project. The project manager and core members of the project team — The core members are the experienced professionals who will be with the project from beginning to end. For larger projects, they will be the future subproject managers and activity managers. In some cases, critical but scarce skilled professionals might also be present. The facilitator group — This group comprises two or three individuals who are experienced in conducting scoping and planning meetings. The facilitator group will have a meeting facilitator, a requirements gathering facilitator, and a position that I call a technographer. The two facilitators are often the same person. A technographer is the recording secretary for scoping and planning meetings who has solid experience using a variety of high-tech tools. Larger projects may require two such professionals.

Agenda A typical agenda of this meeting could be as follows: Introductions Purpose of the meeting (led by the facilitator) COS (conduct or review if done earlier) Description of the current state (led by the client representative) Description of the problem or business opportunity (led by the client representative)

57

Page 57

Wysocki

58

Part I

■

c03.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

Description of the end state (led by the client representative) Requirements definition and documentation (led by the facilitator) Discussion of the gap between the current and end states Choose the ‘‘best-fit’’ project management approach to close the gap (led by the project manager) Draft and approve the POS (whole group) Adjourn For very small projects, the agenda can be accomplished in one day. It would not be unusual for larger, more complex projects to require a full work week to cover the agenda. As an example of the latter, I ran a very complex Web-based decision support system project that was initially budgeted for three years and $5M. The Scoping Meeting took three days.

Deliverables The required deliverables from the Scoping Meeting are as follows: COS (may have been done prior to the Scoping Meeting) Requirements document Best-fit project management life cycle (PMLC) POS

Gathering Requirements As indicated earlier in the chapter, the COS approach does not scale very well. For large or complex projects, you should opt for a more formal requirements gathering approach. Requirements gathering is the first and very challenging task that the project manager and client will face in the life of the project. To do this effectively is as much an art as it is a science. On the art side of the equation, the project manager will have to prepare the client to engage in the gathering and documentation process. The attitude, commitment, willingness to be meaningfully involved, and preparation of the client are major determinants in the choice of approach. This preparation will include the choice of requirements gathering and documentation approaches to be used and perhaps some preliminary training of the client and the core team. Some clients will be open and proactive in participating; others will not. Some will be sure of their needs; others will not. Some will be expressing their wants, which may be very different from their needs. The project team should be searching for needs.

4:45pm

Page 58

Wysocki

c03.tex

Chapter 3

■

V2 - 03/20/2009

4:45pm

How to Scope a Project

On the science side of the equation are the many techniques that have been used successfully to gather and document requirements. I have had good success using prototyping, business process diagramming, and use cases. Those are the three approaches discussed in this chapter.

What Are Requirements? Requirements are the things that define deliverables and that the project manager should discover before starting to fully design, build, or execute a project. Discovering the requirements during the execution of the project has become the norm rather than the exception. Part II discusses in detail the PMLCs that are designed for this situation. Project requirements start with a definition of what the client really needs and end when those needs are satisfied. In this end-to-end chain of specifications, there is an ongoing danger of misunderstanding and ambiguity. This often leads to nonessential or overspecified requirements. Figure 3-2 is a lighthearted cartoon (source unknown) that illustrates the point.

How the customer explained it

How the project leader understood it

How the analyst designed it

How the programmer wrote it

How the business consultant described it

How the project was documented

What operations installed

How the customer was billed

How it was supported

What the customer really needed

Figure 3-2 Different perspectives on requirements

59

Page 59

Wysocki

60

Part I

■

c03.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

Types of Requirements Requirements define the product or service that constitutes the deliverable of the project. These requirements are the basis for defining the needs that the client is seeking to solve a problem or to take advantage of a business opportunity. At this early stage, the client, the project manager, and their teams are tasked with going through the process of establishing the requirements baseline for the project. This process is a systematic, step-by-step effort that requires the patience and diligence of both teams. It is these requirements that will eventually be used for estimating the cost, time, and resources required to do the project. Ultimately, these requirements drive acceptance of the product or service by the client. Requirements are separated into the following four categories. Functional requirements Non-functional requirements Global requirements Product and/or project constraints

Functional Requirements Functional requirements specify what the product or service must do. They are actions that the product or service must take, such as check, calculate, record, or retrieve. For example: ‘‘The service shall accept a scheduled time and place for delivery.’’

Non-Functional Requirements Non-functional requirements demonstrate the properties that the product or service should have in order to do what it must do. These requirements are the characteristics or qualities that make the product or service attractive, usable, fast, or reliable. Most non-functional requirements are associated with performance criteria and are usually requirements that will establish the product or service boundary. Non-functional requirements can sometimes be generated by the refinement of a global requirement. Non-functional requirements are usually associated with performance criteria that set the parameters for how a system is to function. For example: ‘‘The product shall have a homemade appearance.’’ or: ‘‘The product shall be packaged so as to be attractive to senior citizens.’’

Global Requirements Global requirements describe the highest level of requirements within the system or project. Global requirements describe properties of the system as

4:45pm

Page 60

Wysocki

c03.tex

Chapter 3

■

V2 - 03/20/2009

4:45pm

How to Scope a Project

a whole. During the initial stages of a project, many requirements end up being global requirements. The project manager and the team then refine them through the methods of requirement generation. Global requirements is a relatively new term. In the past, these have been called general requirements, product constraints, or constraining requirements. Be careful in your use of global requirements because in most cases they can be turned into non-functional requirements simply by asking the questions associated with what, why, or how. In fact, it is wise to move a global requirement to a non-functional requirement in order to gain a better focus on what the requirement really is. For example: ‘‘The system shall run on the existing network.’’ or ‘‘The system must be scalable.’’

Product and/or Project Constraints Product and/or project constraints are those requirements that, on the surface, resemble design constraints or project constraints. Design constraints are preexisting design decisions that mandate how the final product must look or how it must comply technologically. Project constraints cover the areas of budget and schedule along with deadlines and so on. One important note here is that product constraints can be listed as global requirements, but project constraints cannot. For example: ‘‘The maximum system response time for any client-based transaction must not exceed 4 milliseconds.’’ or ‘‘The total out-of-pocket cost plus five-year maintenance must not exceed $35 million.’’

Approaches to Gathering Requirements It is very important to realize that requirements identification and categorization is critical to understanding the direction of the project. It is now that the framework for the project begins to take shape. The steps to generate requirements begin by looking at the business function as a whole. This is followed by the selection of a method or methods for gathering requirements. This effort must be planned. There are several approaches to requirements gathering. The most commonly used requirements-gathering methods are as follows: Facilitated group sessions Interviews Observation Requirements reuse Business process diagramming Prototypes Use case scenarios

61

Page 61

Wysocki

62

Part I

■

c03.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

N O T E There is extensive literature on all of these methods. A particularly good reference is Mastering the Requirements Process by Suzanne Robertson and James C. Robertson (Addison-Wesley, 2006). The bibliography in Appendix B has a few more references you might want to check.

I single out business process diagramming, prototyping, and use cases as the three requirements-gathering methods that I have had the most success with. Typically, more than one method is chosen to generate requirements. Selecting the best methods to generate potential requirements for the project is the responsibility of the project manager, who must evaluate each method for costs, ease of implementation with the client, and risks. Further, selection of a particular method should be based on specific product and project needs, as well as proven effectiveness. Certain methods have been proven effective for specific client groups, industries, and products. An example of this would be using physical, three-dimensional prototypes in product development and construction. I’ll come back to a more detailed discussion of these three methods of requirements gathering later in this chapter. Table 3-1 briefly describes the strengths and risks associated with each method. Table 3-1 Methods for Requirements Gathering METHOD

STRENGTHS

RISKS

Facilitated group sessions

Excellent for cross-functional processes. Detailed requirements can be documented and verified immediately. Resolves issues with an impartial facilitator.

Use of untrained facilitators can lead to a negative response from users. The time and cost of the planning and/or executing session can be high.

Interviews

End-user participation. High-level descriptions of functions and processes are provided.

Descriptions may differ from actual detailed activities. Without structure, stakeholders may not know what information to provide. Real needs may be ignored if the analyst is prejudiced.

Observation

Specific and complete descriptions of actions are provided. Effective when routine activities are difficult to describe.

Documenting and videotaping may be time-consuming and expensive, and may have legal overtones. Confusing or conflicting information must be clarified. Can lead to misinterpretation of what is observed. (continued)

4:45pm

Page 62

Wysocki

c03.tex

Chapter 3

■

V2 - 03/20/2009

4:45pm

How to Scope a Project

Table 3-1 (Continued) METHOD

STRENGTHS

RISKS

Requirements reuse

Requirements are quickly generated and refined. Redundant efforts are reduced. Client satisfaction is enhanced by previous proof. Quality is increased. Reinventing the wheel is minimized.

Requires a significant investment for developing archives, maintenance, and library functions. May violate intellectual rights of previous owner. Similarity of an archived requirement to a new requirement may be misunderstood.

Business process diagramming

Excellent for cross-functional processes. Visual communication through process diagrams. Verification of ‘‘what is’’ and ‘‘what is not.’’

Implementation of improvement is dependent on an organization being open to changes. Good facilitation, data gathering, and interpretation are required. Time-consuming.

Prototypes

Innovative ideas can be generated. Users clarify what they want. Users identify requirements that may be missed. Client-focused. Early proof of concept. Stimulates thought processes.

Client may want to implement the prototype. Difficult to know when to stop. Specialized skills are required. Absence of documentation.

Use case scenarios

The state of the system is described before the client first interacts with that system. Completed scenarios are used to describe state of system. The normal flow of events and/or exceptions is revealed. Improved client satisfaction and design.

Newness has resulted in some inconsistencies. Information may still be missing from the scenario description. Long interaction is required. Training is expensive.

Building the Requirements Breakdown Structure For the purposes of this book, I want you to envision a Requirements Breakdown Structure (RBS) much like the one shown in Figure 3-3. The experienced practitioner will recognize the RBS as a high-level Work Breakdown Structure (WBS). In Chapter 4, you will learn about the WBS and how to build it. The

63

Page 63

Wysocki

64

Part I

■

c03.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

structure is useful as an aid in helping decide which PMLC model is the best fit for the project. For example, Linear and Incremental PMLCs would be appropriate for projects in which all of the features for all sub-functions and functions are defined as part of the Scoping Process. If some features are thought to be missing, an Iterative PMLC may be appropriate. If some of the features and some of the functions are not known, then an Adaptive PMLC would be appropriate. Finally, if not only the functions are not known but also the project goal and solution are not known, then an Extreme PMLC would be best. Within each of these five types of PMLC models, there are various best-fit approaches you can use. Chapter 8 picks up on this topic with considerable detail on choosing best-fit models. As you gather and document requirements by whatever method you choose, place them in their appropriate level in the RBS. The graphical format shown in Figure 3-3 works well. Alternatively, you could present the RBS in an indented outline format. It’s all a matter of taste. Project Goal & Solution

Requirement #1

Function #1.1

Sub-function #1.2.1

Feature #1.2.1.1

Function #1.2

Sub-function #1.2.2

Feature #1.2.1.2

Feature #1.2.1.3

Requirement #n

Function #1.3

Function #n.1

Function #n.2

Function #n.3

Sub-function #1.2.3

Feature #1.2.1.4

Feature #n.3.1

Feature #n.3.2

Feature #n.3.3

Feature #n.3.4

Figure 3-3 The Requirements Breakdown Structure

The RBS is a hierarchical description of what the solution has to do in order to acceptably meet client needs. It is similar to the functional form of the WBS in that regard. At the highest level, it identifies requirements. These may be identified using any of the approaches discussed earlier in this chapter. Initially you may assume that the list of requirements is complete, but that may not be true. Additional requirements may be discovered in the course of doing the project. The requirements level of decomposition is optional. At the discretion of the project manager, the highest level of decomposition may be at the function level. This level comprises the functions that must be performed

4:45pm

Page 64

Wysocki

c03.tex

Chapter 3

■

V2 - 03/20/2009

4:45pm

How to Scope a Project

in order for a solution to be acceptable. It is important to understand that the RBS reflects what is known about the solution at the time the RBS is first defined. This initial list of functions may or may not be complete. Neither you nor the client can be expected to know if that list is complete. You might know that it is incomplete, but you wouldn’t know that it is complete. How could you? For the sake of generating the RBS, you have to proceed on the basis that the initial list will be complete. If it turns out that it is not, you will discover that as part of doing the project. At the next level of decomposition are sub-functions. For some functions, you may not have any idea of what those sub-functions might be and that is okay. In any case, the project team should make every effort to identify the sub-functions that further define a function. Once these sub-functions have been developed, the function they define will now be complete. This is the same as the premise underlying the WBS architecture and is very intuitive. For many adaptive projects, additional sub-functions will be discovered as part of doing the project. At the lowest level of decomposition are features. For some sub-functions, you may not have any idea as to what those features might be. That’s okay — for many adaptive and iterative projects, additional features will be discovered as part of doing the project. Regardless of the method you use to generate requirements, I strongly advise creating an RBS for every project for the following reasons: The RBS is most meaningful to the client. The RBS is a deliverables-based approach. The RBS is consistent with the Project Management Body of Knowledge (PMBOK) defined by the Project Management Institute (PMI). The RBS remains client-facing as long as possible into the planning exercise.

Using the RBS to Choose a Best-Fit PMLC Model You have now reached the point where a critical decision needs to be made about how to manage this project. At this point, the project management gurus would agree that you cannot say that the requirements list is complete. You can never really know that until the project is complete and all success criteria have been met. However, you can say that the requirements are not complete. There are certain parts missing, and you know they are missing. The more that is missing, the more complex the process of managing the project will be. The development manager and the client manager must make an initial decision on the best-fit PMLC based on the degree to which requirements are complete.

65

Page 65

Wysocki

66

Part I

■

c03.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

Completeness is more of an expression of the comfort level you have with the RBS than it is any quantitative measure of completeness. It is a subjective call, and it is not a ‘‘once for the whole life of the project’’ decision. — it can change as the clarity and completeness of the requirements changes. For example, at some point in the project life cycle, the project team may experience the great ‘‘AHA!’’ At last the project team sees what the complete solution looks like. Does it make sense to change the PMLC? It might. It might not. Here are some criteria to consider: What are the cost and time penalties for abandoning the current PMLC and changing to a different PMLC? Can the project team adapt to the new PMLC? How certain are you and your client that a change will result in a better solution? What is the cost versus the benefit of the change? As you can see, gathering and documenting client requirements is extremely difficult even in the simplest of situations. Poorly defined requirements are the root cause of many project failures, so it is critical that you approach this task with the best-fit requirements gathering approach available to you. For clients, the requirements gathering approach you use is difficult because they are being asked to think about satisfying their needs using tools that they may not be familiar with. For project managers, the requirements gathering approach they choose may be difficult because they may not have made the distinction between client wants and client needs. For both parties, requirements gathering is a learning experience. How well the client and the project manager are able to learn will be the key to project success. Therefore, the choice of PMLC will be a critical success factor for that learning to take place and for successful requirements gathering and documentation. In addition to being a good representation of the requirements, the RBS works very well as a requirements gathering approach for any project because of the following characteristics: It does not require a trained facilitator. It does not require learning one of the contemporary approaches to requirements gathering. It presents an intuitive approach to gathering requirements. It allows the client to work with the project team in an environment that is familiar to them, enabling them to stay in their own comfort zone.

4:45pm

Page 66

Wysocki

c03.tex

Chapter 3

■

V2 - 03/20/2009

4:45pm

How to Scope a Project

It paints a clear picture of the degree to which the solution is clearly defined. It provides the input needed to choose the best-fit PMLC model and the appropriate project management approach.

Diagramming Business Processes N O T E This section is adapted from Appendix K of my book, Effective Software Project Management (Wiley, 2006).

Often, you will choose to start identifying requirements for the project by mapping the current business process (the ‘‘As Is’’ process) or processes that are going to be affected. You might also want to map the business process after the solution is installed (the ‘‘To Be’’ process). Both of these are excellent artifacts to use as input to the requirements gathering process. From the business process development perspective, gathering requirements often begins with knowledge of the current or ‘‘As Is’’ business process and ends with the ‘‘To Be’’ business process. The gap between the ‘‘As Is’’ and ‘‘To Be’’ processes is filled with new or enhanced project deliverables. Having the ‘‘As Is’’ and the ‘‘To Be’’ business process flow diagrams is an invaluable aid in the ensuing solutions development effort. It is an ongoing dictum of today’s business that you must continuously improve your business processes. The old ‘‘If it ain’t broke, don’t fix it’’ adage no longer applies. If you aren’t improving your processes and the way that they support your clients, you run the risk of losing market share. Your client should also be taking the lead in approaching your teams to demand process improvement. Conversely, they are your clients, and you should be ever watchful for ways to improve the service that your clients provide to their clients. All organizations are under pressure to improve. The pressure can come from their clients, the competition, environmental changes, or a combination of the three. The improvements can be in their products or their processes. All too often, the client doesn’t give their business to the company with the best product. When clients find that a supplier is too difficult to deal with, they will decide to use a ‘‘second best’’ supplier who is easier to deal with. This also applies to internal organizations. One reason for outsourcing is a belief (frequently inaccurate) that other groups will be easier, faster, or cheaper to deal with. Internal organizations need to counter this belief by clearly demonstrating that they are continuously improving what they can deliver and their methods of delivery.

67

Page 67

Wysocki

68

Part I

■

c03.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

What Is a Business Process? A business process is a collection of activities that takes one or more kinds of input from one or more different sources and produces value for the client (see Figure 3-4). The focus of the business must be to ensure that the effort of dealing with the process does not outweigh the value received from completing the process. Input A Change of state

Input B Input C Business Process

Figure 3-4 A business process

Order entry and fulfillment is a clear example of a business process. From the client’s viewpoint, the process starts when the client places an order; it ends when the client receives the goods requested. There are numerous activities in between. Credit checks may be run to confirm that the client can pay for the order. Inventory is assessed to confirm you have what the client is requesting. A typical list of activities would include the following: Receiving the order Logging the order Verification of completeness Client credit check Determining the price Inventory checking Production request Order picking Order packaging Shipment You will notice that the activity in a high-level business process may include activities that can be regarded as processes in and of themselves. Processes can be decomposed into other processes until you reach the task level where some interim component is produced. The key is to start with the client as the focus of the original process and then define the sub-processes by their contribution to added value.

4:45pm

Page 68

Wysocki

c03.tex

Chapter 3

■

V2 - 03/20/2009

4:45pm

How to Scope a Project

Creating a Business Process Diagram How do you diagrammatically represent a business process? You can use the standard flowchart to keep it simple and couched in symbols you are already familiar with. Figure 3-5 shows the more commonly used symbols.

Operation

Inspection

Storage

Transmission

Movement

Document

Annotation

Connector

Decision

Delay

Direction of Flow

Boundaries

Figure 3-5 Standard flow chart symbols

The symbols shown in the figure denote the following process steps: Operation — Denotes that a change has taken place. The input is somehow changed as a result of having gone through this process. Movement — Denotes the movement of output from one process step to become the input to the next process step. Decision — Denotes that a question needs to be answered. There are two flow paths that emanate from a decision box: Yes or True and No or False. You follow one of these paths based on the decision. Inspection — Someone other than the person producing the output must inspect it for quality, conformance, or some other tangible characteristic. Often an approval is included as a successful inspection. Document — Denotes a paper document. Delay — Denotes a wait state in a process. It’s usually associated with something joining a queue and waiting for the operator of the next process step to become available. Storage — Indicates that an item has been placed in storage and must wait for a release before moving to the next process step. This usually represents wasted time that must be removed from a process.

69

Page 69

Wysocki

70

Part I

■

c03.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

Annotation — Provides added detail about some process, which is needed for clarification. It might also include the position title of the person responsible for the process. Direction of Flow — Denotes the order of process steps. Transmission — The interrupted arrow indicates when information is to be transmitted from one physical or virtual location to another. Connector — Connects the flow between two separate locations; often used as an off-page connector. Boundaries — Denotes the initiating and closing processes of a flow diagram. Usually the words START or BEGIN are associated with the initiating process, and STOP or END with the closing process.

Business Process Diagram Formats Three common formats are used to render business process diagrams. The first (shown in Figure 3-6) is the top-down and left-to-right format. It is commonly used in program and system flow charts. The second is the ‘‘swim-lane’’ format (shown in Figure 3-7). It identifies the actors who participate in the business process.

Order request

A

Order generated

OK?

Credit Checked

Credit Validated

B

C

No

Notification of problem

Order information

Order canceled

Yes

Problem resolved?

Order entered

Yes Notify customer

No A

B

C

Figure 3-6 The top-down, left-to-right format

Software developers are typically most familiar with the top-down, left-to-right format. It harkens back to the early days of programming and is the standard they adopted several decades ago. It follows the logical thought patterns of software developers and is therefore their popular choice. However, I prefer the swim-lane format when diagramming business processes. For one, it is a client-facing format. By that I mean it is intuitive to the

4:45pm

Page 70

Wysocki

c03.tex

Chapter 3

■

V2 - 03/20/2009

4:45pm

How to Scope a Project

client and represents their processes in a way that they can easily understand. Part II of this book uses swim lanes extensively.

Notify customer

Customer Order request Sales Order generated

Notification of problem

Problem resolved?

No

Order canceled

Yes No

Credit Credit Checked

OK?

Yes

Credit Validated

Order Entry Order information

Order entered

Figure 3-7 The swim-lane format

Context Diagrams One way to describe your process at a very high level is with the context diagram. It is a good starting point. A context diagram describes a rough process or a set of processes. It generally has only the following few components: A stick figure representing the external entity that is triggering the process A large circle representing the organization responding to the request A text block showing each organization or process acting to fulfill the request Arrows showing the rough flow between text blocks The context diagramming process (shown in Figure 3-8) requires that the group identify one or more candidate processes. For example, a process might start with a client request or action and end with a fulfillment. The modeling activity starts by identifying those two points. You show the process start by using an arrow from the client to the organization. You show the process end by using an arrow from the organization to the client. That provides an initial bounding of the process, and the group can decide whether that particular process has enough issues to warrant more time diagramming. If the process merits more discussion, the diagramming process continues by identifying the first group to receive the request and the action sequence that the organization

71

Page 71

Wysocki

72

Part I

■

c03.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

performs to fulfill the request. Simply put, the group uses Post-it notes and arrows to show what goes on in the organization to fulfill the request. This should be done at a high level, and the constrained area of the circle helps maintain this high-level perspective.

Fast and easy

Existing customer

Request for product

Product delivered

Order Processing

Credit Department

Shipping

Warehousing

When promised and accurate

Organization

Figure 3-8 Context diagramming process

Frequently the group will make refinements as they go. The most common refinement is a clearer identification of the existing client being focused upon or the transaction being performed. For example, ‘‘client’’ might become ‘‘existing client’’ if the process is different (or should be different) for an existing client versus a new client. The group can then annotate the process with success criteria, issues, and so on.

Business Process Work Flow Diagrams When you need to identify the actual and ideal path that any product or service follows for the purpose of assessing process quality and to identify deviations and improvement opportunities, the flow chart is an excellent tool to use. It is a picture of steps in a process, and can be used to examine the relationship and sequence of steps; to identify redundancy, unnecessary complexity, and inefficiency in a process; and to create common understanding of the process flow. Considered one of the simplest tools, the flow chart can be as basic or technically intricate as the process it is used to illustrate. Each type of process step is traditionally identified on the chart by a standardized geometric shape. A flow chart illustrates a process from start to finish and should include every step in between. By studying these charts, you can often uncover loopholes, which are potential sources of trouble. Flow charts can be applied to anything from the travels of an invoice and the flow of materials to the steps in making a sale or servicing a product.

4:45pm

Page 72

Wysocki

c03.tex

Chapter 3

■

V2 - 03/20/2009

4:45pm

How to Scope a Project

In process improvement, flow charts are often used to clarify how a process is being performed or to agree upon how it should be performed. When a process is improved, the changes should be noted on the flow chart in order to standardize the revised flow. Follow these steps to create a flow chart: 1. Decide on the process to be diagrammed. 2. Define the beginning and ending steps of the process, also known as boundaries. 3. Describe the beginning step using the Boundaries symbol. 4. Keep asking ‘‘What happens next?’’ and writing each of the subsequent steps in Operations symbols below the Boundaries symbol. 5. When a decision step is reached, write a yes/no question in a diamond and develop each path. 6. Make sure that each decision loop reenters the process or is pursued to a conclusion. 7. Describe the ending step using the Boundaries symbol. Sometimes a process may have more than one ending boundary.

Prototyping Your Solution Many clients cannot relate to a narrative description of a system but they can relate to a visual representation of that system. For requirements gathering purposes, the idea of a prototype was conceived several decades ago. Its original purpose was to help clients define what they wanted. By showing them a mock-up of a solution, they could comment on it and give the developers more insight into what constitutes an acceptable solution. Originally these prototypes were storyboard versions, not production versions. (Later prototypes did become production versions of the solution but that is another story for another time.)

Use Cases Use cases are an excellent forum for working with the client to define the functions and features of the solution. They tell the story of how the solution will operate in the mind of the client and are documented following a specific graphic and textual format. They are rendered in the language of the client and for that reason have found favor with most developers. This section describes use cases in sufficient detail to get you started. The bibliography in Appendix

73

Page 73

Wysocki

74

Part I

■

c03.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

B has several additional references for those who would like to explore use cases in more detail. Figure 3-9 depicts the position of use cases in the overall project scoping.

POS

Project Scoping Requirements Gathering

Use Cases

Additional Documents

Requirements Document

Project Planning Phase

Figure 3-9 Use cases in the Scoping Phase

Project scoping can be part of the Scoping Process Group or Planning Process Group. It is a matter of procedure and protocol in the organization. In Figure 3-9, project scoping is between the Scoping Process Group, which has the POS as output, and the Planning Process Group. It will be the same regardless of where you position it in your project management process. Requirements gathering consists of several different approaches of which use cases is but one. After the use cases have been defined and documented, a single requirements document is assembled, and the project can move to the approval stage or, if the approval stage has already been reached, to the Planning Phase. There are two artifacts in use cases: use case diagrams and use case flow of events, as described in the following sections.

Use Case Diagrams A use case diagram is a simple way to describe how an individual interacts with a business process. It consists of one of more stick figures (the actors),

4:45pm

Page 74

Wysocki

c03.tex

Chapter 3

■

V2 - 03/20/2009

4:45pm

How to Scope a Project

ovals (the process steps), and connecting arrows (the interactions), as shown in Figure 3-10. Actor: Someone or something outside the system that interacts with the system The System

?

Yes

Yes

Yes

$

Use Case: A sequence of steps performed by the system to produce value for the actor

Figure 3-10 Use case diagram

An actor initiates the use case by interacting directly with the system. The system gathers information from the actor, processes it, and returns a result to the actor. In the simple example shown in Figure 3-10, the system asks the actor a question, the answer is processed by the system, and a result (money in this case) is delivered to the actor. This is the so-called ‘‘happy path.’’ Several scenarios may spin off of this simple example. In one scenario, the actor may provide the wrong answer, and the system aborts the request. Alternatively, the system may give the actor a second opportunity to provide the correct answer. If this were an ATM scenario, it may be that the client wants to withdraw more money than is in the account, and the system will return the appropriate message — without the money, of course. In this example, there is only one actor — referred to as the primary actor. There may be secondary actors as well. For example, if the online bank transaction requires another actor to verify account status, that actor is called a secondary actor. Again, the secondary actor may be someone or something, such as another system.

Use Case Flow of Events This document reads like the script in a play. It is initiated with an action by the primary actor, the system responds, the actor takes another action, and this back and forth exchange continues until the use case ends. Consider the case study described in the following sidebar of an order entry transaction for a company called PDQ (Pizza Delivered Quickly). In this use case, the actor is

75

Page 75

Wysocki

76

Part I

■

c03.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

a client who has direct access to the system. If a person (instead of a system) were taking the order from the client, he or she would be the actor and not the client. CASE STUDY — PIZZA DELIVERED QUICKLY (PDQ) Here is an example of an order entry use case for PDQ. The basic flow of placing an order goes like this: 1. The use case begins when the actor indicates that he or she wants to place an order. 2. The system requests order information (coupon information). 3. The actor provides valid order information. 4. The actor indicates that the order information is complete. 5. The system validates the delivery address (additional detail). 6. The system prices the order. 7. The system displays the completed order with the price. 8. The actor confirms the order. 9. The system assigns the order to the appropriate preparation location. 10. The system prioritizes the order within all store orders. This ends the use case. Again, this use case is the so-called ‘‘happy path.’’ There are several alternatives that could fall under this use case. They are called scenarios. One scenario might be that the actor changes his or her mind and cancels the order after finding out the price. Another scenario might be that the system cannot validate the address and terminates the order.

Validating the Business Case The more complexity and uncertainty associated with the project, the more likely senior management will want assurances that the approach that will be used to solve the problem or take advantage of a business opportunity makes good business sense. A very important question will be, ‘‘Does the resulting business value exceed the total cost of the deliverables?’’ Validation may take the form of using the organization’s templates to establish validity. You may have to simulate the deliverables by building a prototype of the solution. You can expect to provide any number of financial analyses such as cost/benefit, Return on Investment (ROI), breakeven, and cash flow analyses, among others. Some of these might accompany the POS.

4:45pm

Page 76

Wysocki

c03.tex

Chapter 3

■

V2 - 03/20/2009

4:45pm

How to Scope a Project

Outsourcing to Vendors and Contractors There will be several reasons to consider using outside resources for your project. These include the following: You do not have the necessary skills and competencies on your staff. Buying the solution is less costly and more effective than building the solution. There is a commercial product available that will meet your needs. It is more cost-effective to have a specialist provide the service. It is not part of your core business activity. You would like to develop the skills by first using a contractor. In all of these situations you will have to follow a structured process to define your needs, solicit vendors or contractors, evaluate what they are able to provide, select the one or ones you will do business with, negotiate a contract to secure their services or products, manage their work, and close the contract. If your needs are significant and costly, be very careful. It is easy to get hurt. You will need an expert to guide you along the way and that may even mean hiring a consultant to represent you. No one ever said that this would be easy.

Procurement Management Life Cycle The procurement management life cycle was introduced in Chapter 2 and is covered in detail here. As a project manager, you will always have projects for which you must obtain hardware, software, products, and/or services from outside sources. The process that supports this acquisition is known as procurement, and the professional project manager must have a basic understanding of procurement so that he or she can ensure that the organization is getting the right materials at the best cost from a qualified vendor. As you learned in Chapter 2, procurement spans four Process Groups. Deciding that you will need outside resources usually takes place during the Scoping Phase. Planning for procurement takes place during the Planning Phase and involves both what you’re going to procure and the time that you’re going to procure it. Procurement execution takes place during the Launching Phase and the Monitoring and Controlling Phase. Finally, contract closing takes place during the Closing Phase. To manage procurement, you need to go through a few processes, which are discussed in the subsections that follow.

77

Page 77

Wysocki

78

Part I

■

c03.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

The procurement management life cycle consists of the following five processes: Vendor solicitation Vendor evaluation Vendor selection Vendor contracting Vendor management

Vendor Solicitation There are several ways to build a list of potential vendors. They are described in the following sections.

Publishing a Request for Information The Request for Information (RFI) is frequently used when you have little knowledge of exactly what is available on the commercial market or you can’t identify vendors who have the specific capability you are looking for. The RFI is a broad net designed to find possible vendors who have some product or service to offer that may meet your needs. The RFI is a letter, and the response usually comes in the form of a letter or brochure. Based on the response to your RFI, you will decide the following: Who should be invited to respond to your Request for Proposal (RFP) Specific content to include in your RFP If one of the vendors should be invited to write the RFP

Advertising Pick any medium that a potential vendor would likely read and advertise your project there. Many vendors will belong to professional associations. If such associations exist, get their mailing lists or advertise in their trade publications.

Renting a Targeted List There are many sources for such mailing lists. The reputable ones will have exhaustive profiling capabilities so that you can narrow the list as much as you wish.

4:45pm

Page 78

Wysocki

c03.tex

Chapter 3

■

V2 - 03/20/2009

4:45pm

How to Scope a Project

Asking Previous Vendors Vendors who have worked with you in the past may be good sources for your current project, or they may be able to recommend other vendors who can meet the specific needs of this project.

Attending Trade Shows Attend trade shows where potential vendors are likely to have a booth. This is a non-threatening approach and may even gain you some references to other vendors.

Preparing and Distributing a Request for Proposal After you’ve done your requirements gathering, you can begin to prepare procurement documents for solicitation. These documents, called Requests for Proposals (RFPs), are what vendors use to determine how they should respond to your needs. The clearer the RFP, the better off you and the vendor are, because you will be providing basic information about what you want. The more specific you are, the better the chance that the vendor will be able to respond to you quickly and efficiently. Many organizations have a procurement office. In this case, you need to give them a document with your requirements and let them do their work. If you don’t have a procurement office, you need to prepare a document to send to the vendors. You should have a lead writer (someone other than you, if possible) create the document content based on your input, and have someone from the legal department ensure that what you’ve asked for in the document is clear and forms the basis for a contract between you and the vendor.

N O T E Remember that a contract always implies some type of adversarial relationship. Both parties to the contract want to get the best possible terms for their side. When you’re creating an RFP, keep in mind that although you definitely want to get the best possible terms for your side, you must make sure the terms aren’t so difficult that they prohibit many people from responding. You must encourage as much participation in your RFP as possible. Don’t get into a draconian mode whereby the RFP almost punishes the people who are responding to it.

You need to state the time conditions for response, which means that you state how many days you will give people to respond, as well as how long you will need to review the responses before making a choice. By putting a

79

Page 79

Wysocki

80

Part I

■

c03.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

timeline on both the vendor and your organization, the process goes faster, and expectations are clear at the beginning of the process. The RFP is the heart of the procurement process and provides the basis for the contract and the work to be completed. It clearly explains all of the deliverables expected of the vendor. I recommend that your RFP contain the following: Introduction Business profile Problem or opportunity POS (optional) RBS (optional) Vendor responsibility Contract administration Instructions to vendors Vendor point of contact Time and cost estimates Pricing Evaluation criteria

Managing RFP Questions and Responses You can expect to receive questions from the vendors who receive your RFP. All potential vendors must be aware of all questions and your responses. That’s the law! You need to have some mechanism whereby you can answer questions concerning the RFP.

Responding to Bidder Questions After the RFP has been distributed, you have to decide how to handle questions that will surely arise from the vendors who have received your RFP. There are three ways to handle these questions: Answer questions individually. Receive questions directly from the vendors and distribute your responses electronically to all vendors on the distribution list. Hold a bidders’ conference. This is a common event. All vendors who wish to respond to the RFP must attend and ask their questions. That way every potential bidder will hear the questions and answers in real time. The bidders’ conference can be held at a hotel or conference site convenient to your campus but is usually held on your campus.

4:45pm

Page 80

Wysocki

c03.tex

Chapter 3

■

V2 - 03/20/2009

4:45pm

How to Scope a Project

Put your RFP online and respond to questions online. This arrangement gives every vendor who is registered to respond to your RFP a chance to see other organizations’ questions and to have a permanent record of your responses to questions posed. This process works only if you have someone constantly monitoring the web site for questions, and someone who is responsible for answering the questions. This process also eliminates the traveling burden on vendors who may be far away geographically. By going online, you level the playing field for all vendors. The important thing is to make sure all potential bidders have the same information. Otherwise, you are subject to being accused of unfair business practices.

Vendor Evaluation Vendor evaluation consists of creating a rule by which all RFP responses are evaluated on the same scale.

Establishing Vendor Evaluation Criteria Vendor selection implies that you have specified a set of established criteria that vendors will be evaluated against. The main objective is to ensure that the evaluation of all responses to the RFP is consistent, objective, and comprehensive. Although there are many criteria that have been developed for vendor evaluation, it is important for you to first decide what the desired vendor relationship will be and define the problem to be solved. You can then develop a specific set of vendor selection criteria that will facilitate the systematic choice of a vendor. This implies that an evaluation team is involved. That team reviews baseline vendor evaluation criteria checklists, debates with the other team members about the relative importance of each criterion, and reaches consensus. This further implies that only the essential criteria are chosen for each vendor, and extraneous criteria that ‘‘might’’ be necessary should be eliminated. Criteria might also be classified as ‘‘must have,’’ ‘‘should have,’’ or ‘‘it would be nice to have,’’ and some type of scoring algorithm should be applied to the criteria in each classification. There are several qualitative factors that might also be used. They include the following: Corporate experience with similar work Financial stability Technical approach

81

Page 81

Wysocki

82

Part I

■

c03.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

Personnel experience, skills, and competencies Risk management processes Location Applicable tools, templates, and processes References for similar work Some type of weighted scoring algorithm should be employed to assess these qualitative factors. There are several quantitative models for evaluating and ranking vendors. Two models that I have used with good success and that are easy to master and administer are Forced Ranking and Paired Comparisons. Forced Ranking

In the Forced Ranking example shown in Table 3-2, there are six vendors (numbered 1 through 6) and four consultants (A, B, C, and D) who are doing the evaluation. The result of a Forced Ranking is a prioritized list of vendors. Each consultant must rank the six vendors from best to worst in terms of their overall satisfaction of the RFP. (A variation would be to specify the criteria and ask for the ranking based on the criteria.) In this example, Consultant A ranked Vendor 4 as best and Vendor 3 as worst. To determine the overall highest-ranked vendor, add the rankings across the rows. In this case, Vendor 2 is ranked first. Table 3-2 Forced Ranking CONSULTANT VENDOR

A

B

C

D

RANK SUM

FORCED RANK

1

2

3

2

4

11

3

2

4

1

1

2

8

1

3

6

2

5

5

18

5

4

1

5

3

1

10

2

5

3

4

4

3

14

4

6

5

6

6

6

23

6

Paired Comparisons

Paired Comparisons is another way to create a single prioritized ranking. Here every vendor is compared against every other vendor. In the example shown in Table 3-3, Vendor 1 is compared against Vendor 2 in the first row. If Vendor 1 is preferred, a 1 is placed in row 1 under the Vendor 2 column and a 0 is

4:45pm

Page 82

Wysocki

c03.tex

Chapter 3

■

V2 - 03/20/2009

4:45pm

How to Scope a Project

placed in the Vendor 2 row under the Vendor 1 column. To determine the overall highest-ranked vendor, sum the values in each row. The highest row total identifies the highest priority vendor. Table 3-3 Paired Comparisons 1

2

3

4

5

6

SUM

RANK

1

X

1

1

0

1

1

4

2

2

0

X

1

0

1

1

3

3

3

0

0

X

0

0

1

1

5

4

1

1

1

X

1

1

5

1

5

0

0

1

0

X

1

2

4

6

0

0

0

0

0

X

0

6

Evaluating Responses to the RFP Vendor RFP response evaluation is a structured method for assessing the vendor’s ability to successfully deliver against the requirements stated in the RFP. It should be based on the execution by a team with the best knowledge of the disciplines represented in the RFP. In many cases, this will be an outside team of subject matter experts (SME). The primary deliverable from this unbiased evaluation is a ranked list. Comments are often requested regarding those vendors who meet the minimal requirements as stated in the RFP. It is not unusual to have more than one evaluation phase. This may be necessary if there are several qualified respondents. The evaluation of vendor responses to the RFP is often used to reduce the number of viable bidders to a more manageable number, usually no more than five. These survivors will then be invited to make an onsite presentation of their proposed solutions. These presentations will often be attended by end users and others who will interact with the solution. They will evaluate each vendor’s proposed solution using criteria developed specifically for this onsite presentation. The data collected here will be used to support the final selection of the winning bidder. In most cases, the short list will contain more than one vendor, so your job of vendor evaluation is not yet done.

Vendor Selection Before you even start reading the responses to your RFP, set the standards for choosing a given vendor. These criteria may be based on technical expertise, experience, or cost, but whatever basis you use for choosing a vendor, it must

83

Page 83

Wysocki

84

Part I

■

c03.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

remain the same for all of the vendors. If you are a public company, every vendor you’ve turned down will ask for a copy of the winning bidder. If they think they have a better bid, all sorts of nasty things may occur (read: legal action). If, however, you have a standards chart, you can point out that everyone was rated with the same criteria and that the winner had the best overall number. By determining your criteria for choice early in the process, it is easier to make a decision and then defend it if need be. Selecting the vendor is a critical decision. There is no guarantee that even if you diligently follow the evaluation process, you will end up with a vendor that you are comfortable with and whom you can select with confidence. Some selection processes may result in failure. Don’t feel obligated to choose one from the remaining list of contenders for your business. It is good practice to let potential bidders know that you may not award the contract after going through the process.

Vendor Contracting Making the actual selection can be very simple and straightforward, depending on the evaluation process. There are several possible scenarios to consider.

No Award In this scenario, none of the evaluations result in a vendor who satisfactorily meets the requirements; therefore, no award will be made. In this case, you will probably want to rethink the RFP. Could you be asking for more than any vendor can reasonably provide? If so, you should consider revising the project scope.

Single Award In this scenario, the results of the evaluation are clear, and a single vendor emerges with the highest evaluation across all criteria. In simpler cases, the evaluation criteria are designed to produce a single score, and the highest scoring vendor who meets the minimal requirements will be awarded the business. However, don’t think that this is the end and you have a vendor. You still have a contract to negotiate and need vendor acceptance of that contract.

Multiple Awards When there are multiple criteria, each with its own scoring algorithm, there may not be a clear single vendor who scored high enough across the criteria to be awarded the business. In this case, you may decide to award parts of

4:45pm

Page 84

Wysocki

c03.tex

Chapter 3

■

V2 - 03/20/2009

4:45pm

How to Scope a Project

the business to different vendors. If this possibility exists, you must make it clear in the RFP that the business could be awarded to several vendors who must then work together on the project. The RFP should require information on any similar situations in which the vendor has had experiences. If you have multiple vendors, you will obviously have an added management burden.

Contract Management When the software application is to be developed solely by the vendor, the project manager’s primary job is contract management. Contract management involves the following deliverables: The vendor must supply you with deliverable dates so that you can determine whether the project is on time. The vendor should supply a WBS, detailing how the scope of the project will be broken down and showing the tasks that make up the completion of a deliverable. Regular status meetings should be held to track progress. These meetings should be formal and occur on specified dates. A status meeting should occur at least once a week, although in the early stages of the project, you may choose to have status meetings more often. Status meetings give you an idea of how the vendor is proceeding in fulfilling the contract, and by having such meetings at weekly intervals, you won’t allow the project to get very far off course. This way, you can correct, at most, a week’s worth of problems — anything longer than that can become unmanageable. In your contract, state who the contract manager will be for your organization. If you are managing the project, it will probably be you, but in some organizations, contract management functions are handled by a specific department or team. I prefer contract management to be in the hands of the project manager, or at least to have the project manager as part of the contract management team.

N O T E If the contract is run on a deliverable basis — that is, the vendor agrees to given deliverables on certain dates — it is extremely important to state the payment mechanism. The person who signs off on each deliverable is extremely important to the vendor and should be specifically assigned in the RFP.

Types of Contracts There are several types of contract structures you might consider. The four most popular contract types are briefly described in the following sections.

85

Page 85

Wysocki

86

Part I

■

c03.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

Fixed Price

This form of contract is best used when the requirements are well known and the buyer (that’s you) knows that changes will be kept to a minimum. Although many buyers seem to always want a Firm Fixed Price (FFP) contract, it is wise to keep in mind that the supplier (a.k.a. vendor) should have the capability that is described by the Software Engineering Institute (SEI) in the Capability Maturity Model (CMM), Level 3. Only suppliers with organizational processes that are documented, trained, followed, and kept current will have a strong enough organizational measurement repository. These depositories will contain historical data based on many projects to be able to comfortably bid on FFP contracts. Of course all potential suppliers will agree to a FFP, but it is often done to get in the door and hope details can be worked out later with the buyer. It is not done from a base of data. Time and Materials

Labor rates are established for each of the vendor’s position classes that will be assigned to the project. These are stated in the RFP response and agreed to as part of contract negotiations. Time cards are kept by the vendor, and you are invoiced as agreed to in the contract’s terms and conditions. Materials are acquired by the vendor as agreed to in the contract. The necessary documentation is provided as attachments to the invoices. Retainer

Retainer contracts specify a fixed amount per period to be paid to the vendor, with an agreed number of person days per period provided by the vendor in return for the fee. Retainer contracts are often used when a detailed Statement of Work cannot be provided. In these contracts, it is your responsibility to make periodic assignments with deadlines to the vendor. Cost Plus

This form of contract is especially useful if you are willing to pay more for higher performance and quality but are not sure how to determine the supplier’s true capability. A Cost Plus contract includes direct labor and indirect cost (overhead, actual work performed, and so on) to make up the bill rate, with other direct costs listed separately. Cost Plus puts a major emphasis on contractor performance and quality and can be used as a way to enforce standards and procedures. The award fee is negotiated at the beginning of contract and is directly tied to vendor performance. Vendor performance should be measured in terms of specific quantitative metrics so there is no argument about attainment.

4:45pm

Page 86

Wysocki

c03.tex

Chapter 3

■

V2 - 03/20/2009

4:45pm

How to Scope a Project

Cost Plus contracts can also include penalties for not meeting acceptance criteria.

Discussion Points for Negotiating the Final Contract This section of the RFP specifies the areas that will be discussed for the final terms and conditions of the contract following vendor selection. You do not want to present the vendors with any surprises. Some of the areas you will want to discuss in the RFP include the following: Work schedule Payment schedule Fees Personnel assigned to the contract Rights in data Other terms and conditions Ownership Warranties Cancellation terms

Final Contract Negotiation Establishing and maintaining the vendor agreement provides the vendor with the project needs, expectations, and measures of effectiveness. The vendor agreement typically includes the following: Statement of work for the vendor Terms and conditions List of deliverables, schedule, and budget Defined acceptance process, including acceptance criteria Identification of the project and supplier representatives responsible and authorized to agree to changes to the vendor agreement Description of the process for handling requirements change requests from either side The processes, procedures, guidelines, methods, templates, and so on that will be followed Critical dependencies between the project and the vendor

87

Page 87

Wysocki

88

Part I

■

c03.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

Descriptions of the form, frequency, and depth of project oversight that the vendor can expect from the project, including the evaluation criteria to be used in monitoring the vendor’s performance Clear definition of the vendor’s responsibilities for ongoing maintenance and support of the acquired products Identification of the warranty, ownership, and usage rights for the acquired products

Vendor Management I have always recommended that you do whatever you can to make the vendor feel like an equal partner in the project. That means including them in every team activity for which it makes sense to have them involved.

Expectation Setting — Getting Started Starting a contract on the right foot avoids a lot of subsequent frustration for both parties. A good start-up allows the project team and contractor team working relationship to be established early on so that they can function as a unified team throughout the project. Communication needs to be established early among all relevant stakeholders in order to optimize the development environment before the implementation starts. Conducting meetings and having face-to-face discussions are the easiest and best ways to set clear expectations and gain a mutual understanding of the requirements and expected performance. It is important to remember that the individuals who created and sent the RFP response may not be the same individuals who will actually work on the project. Therefore, it is good practice to hold some type of orientation with the vendor team at the beginning of the project to ensure that both parties share the same understanding of the project goal and objectives. During this vendor orientation, you should provide answers to the following questions: For whom does the vendor work? What is expected of the vendor? What tools and facilities are available to the vendor? What training is available to the vendor? To your team by the vendor? What must the vendor deliver? When must it be produced? Who will receive the deliverables? How will the deliverables be evaluated?

4:45pm

Page 88

Wysocki

c03.tex

Chapter 3

■

V2 - 03/20/2009

4:45pm

How to Scope a Project

However, if the vendor is not onsite, this orientation will pay for itself thousands of times over.

Monitoring Progress and Performance Monitoring and reporting the progress and performance of one or more vendors takes effort, and you should not expect a vendor to manage their own reporting. The best way to think of the vendor is as a member of the project team. The activities of receiving status reports from the project members and holding project reviews to discuss progress, risks, problems, and ensuing tasks all apply to a vendor as well. The following discussion of monitoring vendor activities is not intended to be complete or absolute, but rather should be used as a starter kit for subsequent tailoring to ensure proper attention is being devoted to the vendor based on business objectives, constraints, requirements, and operational environment. Monitoring Requirements Change Requests

One of the most important areas to consider is the requirement change request. These will most likely come from your team and client, but you might also give the vendor the same privileges. After all, they are the experts at what they are doing and may be able to contribute to the betterment and overall success of the project. The bottom line is that requirements management is a collaborative effort of both parties. Changes to the requirements must be controlled as they evolve over the product life cycle due to changing needs and derived requirements. All appropriate stakeholders on both sides must review and agree on the change requests to the requirements before they are applied. Approved changes to the requirements are tracked and a change history is maintained for each requirement along with the rationale for the change. Applied changes to requirements must be communicated to all stakeholders in a timely manner. The change process is similar to the process used when no vendor is involved, except for the addition of the vendor’s project impact analysis. An impact analysis is conducted on each requirements change request before negotiations take place or a decision to accept or reject the change request is made. The implication will be that a contract or schedule change may be required on the part of the vendor. Even if that is not the case and the vendor’s work will not be impacted, it is recommended that you keep the vendor in the approval chain for all change requests. The vendor’s approval of all change requests is necessary. Let the vendor decide if their work will be impacted. The vendor’s project impact analysis report may conclude that the proposed change will not impact their work in any way, but the vendor needs to officially convey that to the project manager (you).

89

Page 89

Wysocki

90

Part I

■

c03.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

Monitoring the Performance of Standard Project Activities

The following key metrics need to be provided by the vendor to track actual versus planned contract performance: Labor hours Cost Schedule Cost and schedule are part of the earned value analysis, which you will learn about in Chapter 6. Other performance metrics that should be tracked by both the vendor and the project manager include the following: Frequency of change requests over time Incidence of bugs Risks Issues resolution Staffing levels and changes by position type

Transitioning from Vendor to Client Transitioning from the vendor’s environment to your environment for integration and acceptance testing requires thought and up-front planning. You need to determine what deliverables and/or services you expect to receive in order to successfully transition the product or product component from the vendor to you. The project manager in collaboration with the vendor should develop a high-level summary of the checklist to assist the transitioning of the deliverables: What do you expect to be delivered and how will you accept it? What environment must you provide in order to accept the vendor’s deliverables? What support must the vendor provide during acceptance of the deliverables? How will problems be resolved? What type of maintenance agreement do you expect? What about future changes? It is assumed that acceptance criteria have already been defined and agreed to.

4:45pm

Page 90

Wysocki

c03.tex

Chapter 3

■

V2 - 03/20/2009

4:45pm

How to Scope a Project

Closing Out a Vendor Contract Closing out the contract is often an overlooked function of the project manager. It both certifies what has been done and gives all parties a chance to deal with open issues and final payments. The project manager must be aware of all steps to be followed in the procurement process even though he or she may not be the person directly responsible for managing them. This is just another part of being a professional project manager. Consider the following as you bring a contract to a close: There should be a clear understanding of when the project is finished. When you write your RFP, state clearly the list of deliverables you expect in order for the project to be considered complete and what the final deliverable is. Failure to do this will almost always lead to cost overruns in the form of maintenance activities under the heading of project work. State what the final product of the project is to be, who is to determine if it has been delivered, and what is to be done with any open issues. Make this information as clear as possible and you will save the company thousands of dollars. After the contract is closed, make sure you file all of the materials used during the project. These materials include the original RFP, the project baseline, the scope statement, the WBS, the various plans used to manage the project, and all changes, including those that were requested but turned down. You also need to show all payments and make sure that any subcontractors on the project were paid. Confirming that subcontractors have been paid is done through the vendor, who must show that all payments have been made to the subcontractors. Put all this information into a large file and keep it. How long? I have seen instances of disputes coming up years after a project is finished. Keep it as long as the project product is in use. Ideally, keep these records permanently.

Writing an Effective Project Overview Statement The COS and the requirements document are the primary inputs you need to generate the Project Overview Statement (POS). The POS is a short document (ideally one page) that concisely states what is to be done in the project, why it is to be done, and what business value it will provide to the enterprise when completed.

91

Page 91

Wysocki

92

Part I

■

c03.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

The main purpose of the POS is to secure senior management’s approval and the resources needed to develop a detailed project plan. It will be reviewed by the managers who are responsible for setting priorities and deciding what projects to support. It is also a general statement that can be read by any interested party in the enterprise. For this reason, the POS cannot contain any technical jargon that generally would not be used across the enterprise. After it is approved, the POS becomes the foundation for future planning and execution of the project. It becomes the reference document for questions or conflicts regarding the project’s scope and purpose. My idea for the POS originated at Texas Instruments in the early 1960s. They used a form of the POS as part of a process whereby anyone in the organization could suggest an idea for increasing efficiency, improving productivity, or seizing a business opportunity. One particular example has stayed with me over all these years. It involved a maintenance man whose only equipment was a Phillips-head screwdriver. He walked the halls of an approximately 1,800,000-square-foot building and tightened the screws that held the wall-mounted ashtrays in position. You could smoke inside the building in those days. They became loose from people or equipment bumping into them. The maintenance man had an idea for replacing these screws with another fastening device that would not work loose, and he presented his idea using a POS. The project was funded, and he was appointed project manager. The project was completed successfully, and his job was thus eliminated. (I hope he was able to move on to something a little more challenging and rewarding!) Today, several organizations use the POS or some adaptation of it. Because the POS can be drafted rather quickly by one person, it serves to capture a brief statement of the nature of the idea. Senior management can react to the proposed idea without spending too much time. If the idea has merit, the proposer will be asked to provide a detailed plan. The idea may be conditionally accepted, pending a little more justification by the proposer. Again, the idea is pursued further if it has merit. Otherwise, it is rejected at this early stage, before too much time and too many resources are spent on needless planning. The POS can serve other purposes as well. Here are a couple of examples. Inherited Project. Sometimes you inherit a project. In these instances, the project has been defined and scoped. A budget, staff resources, and a completion date have also been determined. In this scenario, do you write a POS? Yes! There are at least two reasons to write a POS when you inherit a project. The first is to become familiar with and understand the project as

4:45pm

Page 92

Wysocki

c03.tex

Chapter 3

■

V2 - 03/20/2009

4:45pm

How to Scope a Project

well as the client’s and management’s expectations. I can’t stress enough how important it is for both the requestor and provider to ensure that what will be delivered is what the client expects. The second reason is that the POS will become the referent for the planning team. It is the foundation on which the project plan will be built. The project team can use the POS as the tiebreaker or referent to resolve any misunderstandings. In this case, the project scope has been determined, and it is up to the planning team to ensure that the resulting project plan is within the scope of the project, as defined in the POS. Briefing Tool. An equally important reason for writing a POS is to give your team briefing information on the project. In addition to reaching a consensus with your client on what will be done, the team members need to have an understanding of the project at their level of involvement. Think of this as a COS for the team. Here the focus is on ensuring that you (as the project manager) and the team have a common understanding of the project. The POS serves as a good briefing tool for staff members who are added after the project commences. It helps them get up to speed with their understanding of the project.

Parts of the POS The POS has the following five component parts: Problem or opportunity Project goal Project objectives Success criteria Assumptions, risks, and obstacles Its structure is designed to lead senior managers from a statement of fact (problem or opportunity) to a statement of what this project will address (project goal). Senior management is interested in the project goal and whether it addresses a concern of sufficiently high priority; therefore, they need details on exactly what the project includes (project objectives). The business value is expressed as quantitative business outcomes (success criteria). Finally, conditions that may hinder project success are identified (assumptions, risks, and obstacles). The following sections take a closer look at each of these POS components. An example POS is shown in Figure 3-11.

93

Page 93

Wysocki

94

Part I

■

c03.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

PROJECT Project Name OVERVIEW STATEMENT Problem/Opportunity

Project No.

Project Manager

Goal

Objectives

Success Criteria

Assumptions, Risks, Obstacles

Prepared by

Date

Approved by

Date

Figure 3-11 An example POS

Stating the Problem or Opportunity The first part of the POS is a statement of the problem or opportunity that the project addresses. This statement is fact — it does not need to be defined or defended. Everyone in the organization will accept it as true. This is critical because it provides a basis for the rest of the document. The POS may not have the benefit of the project manager’s being present to explain what is written or to defend the reason for proposing the project to management. A problem or opportunity statement that is known and accepted by the organization is the foundation on which to build a rationale for the project. It also sets the priority with which management will view what follows. If you are addressing a high-priority area or high-business-value area, your idea will get more attention and senior management will read on. Here are several examples of situations that will lead to a statement of the problem or opportunity that has given rise to this POS.

4:45pm

Page 94

Wysocki

c03.tex

Chapter 3

■

V2 - 03/20/2009

4:45pm

How to Scope a Project

Known Problem or Opportunity. Every organization has a collection of known problems. Several attempts to alleviate part of or the entire problem may have already been made. The POS gives proposers a way to relate their idea to a known problem and to offer a full or partial solution. If the problem is serious enough and if the proposed solution is feasible, further action will be taken. In this case, senior managers will request a more detailed solution plan from the requestor. With the business world changing and redefining itself continuously, opportunities for new or enhanced products and services present themselves constantly. Organizations must be able to take advantage of them quickly because the window of opportunity is not wide and is itself constantly moving. The POS offers an easy way to seize these opportunities. Client Request. Internal or external clients make requests for products or services, and their requests are represented in the COS. The POS is an excellent vehicle for capturing the request and forwarding it to senior management for resolution. More recently, with employee-empowerment trends, a worker may not only receive a request, but also has the authority to act on that request. The POS, coupled with the COS, establishes an excellent and well-defined starting point for any project. Corporate Initiative. Proposals to address new corporate initiatives should begin with the POS. Several ideas will come from the employees, and the POS provides a standardized approach and document from which senior management can prioritize proposals and select those that merit further attention. A standard documentation method for corporate initiatives simplifies senior management’s decision-making process for authorizing new projects. Mandated Requirements. In many cases, a project must be undertaken because of a mandated requirement, arising from market changes, client requirements, federal legislation, as well as other sources. The POS is a vehicle for establishing an agreement between the provider and the decision maker about the result of the project. The POS clarifies for all interested parties exactly how the organization has decided to respond to the mandate.

Establishing the Project Goal The second section of the POS states the goal of the project — what you intend to do to address the problem or opportunity identified in the first section of the POS. The purpose of the goal statement is to get senior management to value the idea enough to read on. In other words, they should think enough of the

95

Page 95

Wysocki

96

Part I

■

c03.tex

V2 - 03/20/2009

Defining and Using Project Management Process Groups

idea to conclude that it warrants further attention and consideration. Several submissions may propose the same issue. Because yours will not be the only proposal that’s submitted, you want it to stand out among the crowd. A project has one goal. The goal gives purpose and direction to the project. At a very high level, it defines the final deliverable or outcome of the project in clear terms so that everyone understands what is to be accomplished. The goal statement will be used as a continual point of reference for any questions that arise regarding the project’s scope or purpose. The goal statement must not contain any language or terminology that might not be understandable to anyone having occasion to read it. In other words, no ‘‘techie talk’’ is allowed. It is written in the language of the business so that anyone who reads it will understand it without further explanation from the proposer. Under all circumstances, avoid jargon. Just like the problem or opportunity statement, the goal statement is short and to the point. Keep in mind that the more you write, the more you increase the risk that someone will find fault with something you have said. The goal statement does not include any information that might commit the project to dates or deliverables that are not practical. Remember that you do not have much detail about the project at this point. The specification of a date deserves further discussion because it is of major interest to the client and to senior management. First, and most important, you do not control the start date and therefore you cannot possibly know the end date. For example, it might be that the most specific statement you could make at this point is that you could complete the project approximately 9 to 12 months after starting. Even such a broad statement as that is fraught with risk because you do not know the particulars of the project yet. Senior management will need some type of statement regarding completion before they will give authorization to continue the project to the planning stages. Your objective is to postpone giving any fixed duration or completion date until you have completed the project plan. Unfortunately, most managers have a habit of accepting as cast in stone any number that they see in writing, regardless of the origin of the number. The goal statement should not include a specific completion date. (I realize that this is easier said than done) If you expect management to ask for a date, estimate the