practical project initiation - pearsoncmg.com€¦ · i “the wonderful—and scary—thing about...

i

“The wonderful—and scary—thing about Karl's writing is that he reminds you about all of the things that you need to do to be as successful as possible in a project. It is wonderful, because it is nice to have a comprehensive list. It is scary, because when you enumerate all of them, the list seems simply overwhelming, and you might be tempted to therefore not do any. Resist this temptation, scan the list, and then get started answering his questions as best you can. While you may not have all the answers, having a good set of questions is a great way to get started.”

Luke HohmannFounder and CEO, Enthiosys, Inc.

“Karl Wiegers’s Practical Project Initiation offers what its title promises—practical techniques, tips, advice, and tools for one of the most important things a project manager must do well: start projects on a sound path to success. Using a direct and easy-to-read style, Wiegers pro-vides a set of interlocking themes to consider and act upon. He provides pragmatic tools you can implement right away. You will use this book to cut to the chase and find the bottom-line advice you need to get your projects off to a good start.”

Ellen GottesdienerEBG ConsultingAuthor of Software Requirements Memory Jogger: A Pocket Guide to Help Software and Business Teams Develop and Manage Requirements (Goal/QPC, 2005) and Requirements by Collaboration: Workshops for Defining Needs (Addison-Wesley, 2002)

“If it’s about building software and it’s by Karl Wiegers, it’s surely worth reading.”

Robert L. GlassPresident, Computing Trends

“All project teams can benefit from improvement, but when they want to improve, they need concise information that can be used out of the box. Karl has a long history of providing information that is easy to understand and use out of the box. Whether it is estimation, setting priorities, or negotiation, you can quickly find the relevant section of the book, read it, and put it to use. This book is a great collection of essential, easy-to-understand tools.”

Neil PotterThe Process GroupCo-author of Making Process Improvement Work (Addison-Wesley, 2002)

PUBLISHED BY Microsoft Press A Division of Microsoft Corporation One Microsoft Way Redmond, Washington 98052-6399

Copyright © 2007 by Karl E. Wiegers

All rights reserved. No part of the contents of this book may be reproduced or transmitted in any form or by any means without the written permission of the publisher.

Library of Congress Control Number: 2007928773

Printed and bound in the United States of America.

1 2 3 4 5 6 7 8 9 QWT 2 1 0 9 8 7

Distributed in Canada by H.B. Fenn and Company Ltd.

A CIP catalogue record for this book is available from the British Library.

Microsoft Press books are available through booksellers and distributors worldwide. For further infor-mation about international editions, contact your local Microsoft Corporation office or contact Microsoft Press International directly at fax [email protected].

Microsoft, Microsoft Press, Excel and PowerPoint are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Other product and company names mentioned herein may be the trademarks of their respective owners.

The example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred.

This book expresses the author’s views and opinions. The information contained in this book is provided without any express, statutory, or implied warranties. Neither the authors, Microsoft Corporation, nor its resellers, or distributors will be held liable for any damages caused or alleged to be caused either directly or indirectly by this book.

Acquisitions Editor: Ben Ryan Developmental Editor: Devon Musgrave Project Editor: Victoria Thulman Editorial Production Services: S4Carlisle Publishing Services

Body Part No. X13-82872

Contents at a Glance

Part I Project Management Fundamentals1 A Project Management Primer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32 Project Management Good Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Just Too Much to Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Part II Preparing for Success4 Success Criteria Breed Success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 Are We There Yet? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616 Know Your Enemy: Introduction to Risk Management . . . . . . . . . . . . . . 777 Chartering a Course for Success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 938 Lessons Learned from Tool Adoption . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Part III Living with Reality9 Negotiating Achievable Commitments . . . . . . . . . . . . . . . . . . . . . . . . . . 119

10 Saving for a Rainy Day . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12911 Stop Promising Miracles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Part IV Measuring What Happens12 A Software Metrics Primer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15313 Metrics Traps to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Part V Learning Continuously14 Learning from Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17715 Looking Back, Looking Ahead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

vii

Table of ContentsPreface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Part I Project Management Fundamentals

1 A Project Management Primer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

Set Your Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Analyze Your Skills Gaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Define “Quality” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Recognize Progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Learn from the Past . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Set Improvement Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Start Slowly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Practice Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Project Management Good Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Laying the Foundation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Planning the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Estimating the Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Tracking Your Progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Learning for the Future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Practice Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3 Just Too Much to Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Constructing the Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Using the Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30


Microsoft is interested in hearing your feedback so we can continually improve our books and learning resources for you. To participate in a brief online survey, please visit:

www.microsoft.com/learning/booksurvey/

What do you think of this book? We want to hear from you!

viii Table of Contents

Part II Preparing for Success

4 Success Criteria Breed Success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Step 1: Define Business Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Step 2: Identify Stakeholders and Their Interests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Step 3: Identify Project Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Step 4: Derive Project Success Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46


5 Are We There Yet?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

How Do You Know When You’re Done? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Possible Release Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Defects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Quality Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Configuration Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Precise Release Criteria with Planguage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Marketplace Expectations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Making the Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70


6 Know Your Enemy: Introduction to Risk Management. . . . . . . . . . . . . . 77

What Is Risk? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Why Manage Risks Formally? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Typical Software Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Requirements Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Management Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Lack of Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Outsourcing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Risk Management Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Risk Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Risk Avoidance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Risk Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Documenting Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Risk Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Table of Contents ix

Risk Management Can Be Your Friend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Learning from the Past . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87


7 Chartering a Course for Success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Why Charter? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

What a Charter Is Not . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

What Goes in the Charter? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Project Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Business Objectives and Success Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Assumptions and Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Milestones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Business Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Approving the Charter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Using the Charter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Practice Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

8 Lessons Learned from Tool Adoption . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

General Lessons for Tool Adoption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Lessons from CASE Tool Adoption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Fitting Tools into Your Culture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110


Part III Living with Reality

9 Negotiating Achievable Commitments . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Making Project Commitments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Negotiating Commitments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Documenting Commitments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Modifying Commitments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Your Personal Commitment Ethic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124


x Table of Contents

10 Saving for a Rainy Day . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Selling the Skeptics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Send in the Reserves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

How Big Is Your Buffer? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Critical Chain Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134


11 Stop Promising Miracles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Wideband Delphi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Kickoff Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Individual Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Estimation Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Assemble Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Review Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Completing the Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Wideband Delphi Evaluated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146


Part IV Measuring What Happens

12 A Software Metrics Primer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Why Measure Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

What to Measure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Creating a Measurement Culture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Make It a Habit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Tips for Metrics Success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157


13 Metrics Traps to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Trap #1: Lack of Management Commitment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Trap #2: Measuring Too Much, Too Soon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Trap #3: Measuring Too Little, Too Late . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Trap #4: Measuring the Wrong Things . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Trap #5: Imprecise Metrics Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Trap #6: Using Metrics Data to Evaluate Individuals . . . . . . . . . . . . . . . . . . . . . . . . . 167

Trap #7: Using Metrics to Motivate, Rather than to Understand . . . . . . . . . . . . . . . 167

Trap #8: Collecting Data That Isn’t Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Table of Contents xi

Trap #9: Lack of Communication and Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Trap #10: Misinterpreting Metrics Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168


Part V Learning Continuously

14 Learning from Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Worst Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181


15 Looking Back, Looking Ahead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

Retrospective Defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

The Retrospective Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Kickoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Information Gathering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

Issue Prioritization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Issue Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Results Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Retrospective Success Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Action Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195


References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Microsoft is interested in hearing your feedback so we can continually improve our books and learning resources for you. To participate in a brief online survey, please visit:

www.microsoft.com/learning/booksurvey/

What do you think of this book? We want to hear from you!

xiii

Preface

Project initiation is the process of formally conceiving, approving, and launching a new project. You don’t really have a project until the appropriate stakeholders have approved it during initiation. The time and thought invested during initiation lays the groundwork for all the project work that follows.

All project managers know of certain steps to take at the beginning of a project. They need to develop a business case, write a project charter, obtain sponsorship and funding, assign a project manager, assemble the team, acquire other resources, and develop a project plan. I’m so confident that you already know about these essentials that, with the exception of developing a project charter, I don’t address them in this book.

However, numerous other activities are also vital to getting a project off to a good start. Unfortunately, project managers sometimes gloss over these steps. Perhaps they haven’t had enough experience to realize how important these steps are. Or maybe they don’t feel they can spend the time during the frenzy of project launch. But seasoned managers know that attending to these critical activities can separate success from failure.

This book describes many actions that lay the foundation for a successful project, actions to take during project initiation. Most of the chapters are based on articles I have published previously on various aspects of project management, although several new chapters are included as well. Both experienced and novice project managers will find the practices described here to be valuable. The focus is on software projects that are following any life cycle or methodology (including agile), but the practices apply just as well to nonsoftware projects. As with all process-related guidance, each project team needs to adapt my recommendations to the nature and size of their project. Nonetheless, I believe that every software project will benefit from thoughtfully applying the project initiation practices described here.

The book contains 15 chapters grouped into five parts. Part I, “Project Management Funda-mentals,” contains two chapters that describe some basic concepts and practices of project management in general. Some of these apply just to the project initiation phase, whereas oth-ers are applicable throughout the project’s duration. A third chapter presents a method and a spreadsheet tool for prioritizing projects in your backlog of requests. There’s no point in initi-ating a project unless you’re confident the organization is spending its money on the right project.

The five chapters in Part II, “Preparing for Success,” present concrete guidance on how to per-form some of the most important activities that will increase the chance of a happy outcome. Three chapters address identifying project stakeholders and their success criteria, determin-ing product release criteria, and identifying and planning to control project risks. Chapter 7 describes the project charter, a key initiation deliverable that makes sure the stakeholders share a common understanding of where the project is headed. Another aspect of software

xiv Preface

project initiation is to establish the necessary tool infrastructure for your team. Therefore, Chapter 8 presents several lessons I’ve learned from tool adoption in various organizations.

Project managers always hope for the best, but they should also plan for reality. Part III, “Living with Reality,” describes several ways to incorporate a heavy dose of reality into the project, beginning during initiation. Chapter 9 addresses the need for all project participants to negotiate realistically achievable commitments. Chapter 10 describes how to incorporate contingency buffers into project schedules to account for the inevitable surprises, underesti-mates, and risks that materialize. Finally, Chapter 11 presents the Wideband Delphi group estimation technique, which can yield more accurate estimates than any one individual will generate.

I began my career as a research chemist. As a scientist, I appreciated the importance of data and the insights data can provide. Since I moved into the software domain decades ago I’ve extended this interest into measuring various aspects of software development activities. Project initiation is the right time to determine what metrics your team needs to provide ade-quate visibility into progress. It’s also the right time to begin growing a measurement culture in your team. The two chapters in Part IV, “Measuring What Happens,” address the important topic of software metrics. Chapter 12 presents a concise primer on the concepts and practice of software measurement. Chapter 13 warns about 10 traps that can inhibit the success of measurement programs.

Project initiation is an excellent time to study the lessons garnered from previous projects. Chapter 14 in Part V, “Learning Continuously,” suggests ways to establish and use a lessons-learned repository. It also stresses the importance of thoughtfully selecting industry best prac-tices to apply and worst practices to avoid.

When a project team delivers its product the team members experience a range of emotions. They’re relieved to be done, they’re proud of the achievement, they’re tired, and they’re ready to move on to a new and interesting activity. But before they move on, the wise project man-ager will take the time to harvest knowledge from the project that can benefit future work. Therefore, the book concludes with a chapter on how to perform project retrospectives, which are the principal source of those lessons the project manager needs to study during project initiation.

Each chapter begins with a short scenario, typically describing an actual project experience I’ve had that conveyed a significant message. The scenarios illustrate problems that can arise if a project manager neglects that chapter’s principles and practices. A speech balloon icon in the margin highlights other true stories from real projects that support the points made in the chapter. The chapter then presents a tutorial that will let you put the chapter’s topics into action. Common project initiation traps to avoid are flagged with an icon of a maze in the margin.

Every chapter ends with several practice activities. Worksheets are included so you can begin to apply the chapter’s suggestions to your own project immediately. In addition, the book is

Preface xv

accompanied by a number of procedure descriptions, templates, spreadsheet tools, and the like. You may download these process assets from the companion Web site for this book: www.microsoft.com/mspress/companion/9780735625211. (To take advantage of these tools, you will need to be running Word, Excel, and Adobe Acrobat.) The worksheets from the end of each chapter are also available at that Web site so that you can make additional copies for use on other projects.

In my view, there is really no such thing as project management. What we call “project man-agement” is a composite of managing many other project elements: people, requirements, commitments, resources, change, risks, opportunities, expectations, technology, suppliers, and conflicts. Nearly every project includes these elements and the successful project man-ager must keep an eye on them all. Use the guidance provided in this book to help you launch your next project on a solid foundation.

AcknowledgmentsI appreciate the many helpful review comments provided by Jim Brosseau, Patt Dronen, Chris Fahlbusch, Ellen Gottesdiener, Andre Gous, Michael Green, Karen King, Lina Kurtysh, Linda Lewis, Jeannine McConnell, Ulla Merz, Neil Potter, Kathy Rhode, Jean Richardson, Johanna Rothman, Pam Rupert, Mary Sakry, Maureen Stankay, Donna Swaim, and Scott Whitmire. I’m grateful to Dan Read for suggesting that I write this book.

Thanks also go to the editing and production team at Microsoft Press for another fine job: Ben Ryan, Devon Musgrave, Victoria Thulman, and S4Carlisle Publishing Services.

Finally, as always, thanks to my wife, Chris Zambito, for her patience as I spent yet more hours at the keyboard. No surprises this time!

77

Chapter 6

Know Your Enemy: Introduction to Risk Management

In this chapter:

What Is Risk?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78

Why Manage Risks Formally? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78

Typical Software Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79

Risk Management Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81

Documenting Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84

Risk Tracking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85

Risk Management Can Be Your Friend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87

Learning from the Past . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87

Practice Activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88

When my wife and I moved from Rochester, New York, to Portland, Oregon, we had a great project plan. We had a realistic schedule for daily travel distances, routes and hotels selected, and sightseeing activities planned along the way. None of our planning, however, considered the possibility of hitting the world’s largest pothole in the middle of South Dakota, which cracked a wheel rim and caused a slow air leak from that tire. Nor did we anticipate the major wreck we had in Boise, Idaho. These unforeseen events were low-probability risks with high impacts. We eventually made it to Portland, but sometimes I think Lewis and Clark had an easier trip west.

Software engineers are eternal optimists. When planning software projects, we usually assume that everything will go exactly as planned. Or, we take the other extreme position: the creative nature of software development means we can never predict what’s going to happen, so what’s the point of making detailed plans? Both of these perspectives can lead to software surprises, when unexpected things happen that throw the project off track. In my experience, software surprises are never good news.1

Risk management has become recognized as a best practice in the software industry for reduc-ing the surprise factor (Brown 1996; DeMarco and Lister 2003). Although we can never pre-dict the future with certainty, we can apply structured risk management practices to peek over the horizon at the traps that might be looming. Then we can take actions to minimize the

1 This chapter was originally published in Software Development, 1998, 6(10): 38–42. It is reprinted here, with modifications, with permission of CMP Media Inc.

1

78 Part II Preparing for Success

likelihood or impact of these potential problems. Risk management means dealing with a con-cern before it becomes a crisis. This improves the chance of successful project completion and reduces the consequences of those risks that cannot be avoided.

During project initiation take the time to do a first cut at identifying significant risks. At this stage it’s most important to consider business risks, the risks of either undertaking or not undertaking the project. The project charter template described in Chapter 7 includes a slot for business risks. It’s possible that the risks will outweigh the potential benefits of the project. More likely, getting an early glimpse of potential pitfalls will help you make more sen-sible projections of what it will take to execute this project successfully. Build time for risk identification and risk management planning into the early stages of your project. You’ll find that the time you spend assessing and controlling risks will be repaid many times over.

What Is Risk?A “risk” is a problem that could cause some loss or threaten the success of your project, but which hasn’t happened yet. And you’d like to keep it that way. These potential problems might have an adverse impact on the cost, schedule, or technical success of the project, the quality of your products, or team morale. Risk management is the process of identifying, addressing, and controlling these potential problems before they do any harm.

Whether we tackle them head-on or keep our heads in the sand, risks have a potentially huge impact on many aspects of our project. The tacit assumption that nothing unexpected will derail the project is simply not realistic. Estimates should incorporate our best judgment about the potentially scary things that could happen on each project, and managers need to respect the assessments we make. Risk management is about discarding the rose-colored glasses and con-fronting the very real potential of undesirable events conspiring to throw the project off track.

Why Manage Risks Formally?A formal risk management process provides multiple benefits to both the project team and the development organization as a whole. First, it gives us a structured mechanism to provide visibility into threats to project success. By considering the potential impact of each risk item, we can focus on controlling the most severe risks first. We can marry risk assessment with project estimation to quantify possible schedule slippage if certain risks materialize into prob-lems. This approach helps the project manager generate sensible contingency buffers. Sharing what does and does not work to control risks across multiple projects helps the team avoid repeating the mistakes of the past. Without a formal approach, we cannot ensure that our risk management actions will be initiated in a timely fashion, completed as planned, and effective.

Controlling risks has a cost. We must balance this cost against the potential loss we could incur if we don’t address the risk and it does indeed bite us. Suppose we’re concerned about the ability of a subcontractor to deliver an essential component on time. We could engage multiple subcontractors to increase the chance that at least one will come through on

Chapter 6 Know Your Enemy: Introduction to Risk Management 79

schedule. That’s an expensive remedy for a problem that might not even exist. Is it worth it? It depends on the downside we incur if indeed the subcontractor dependency causes the project to miss its planned ship date. Only you can decide for each individual situation.

Typical Software RisksThe list of evil things that can befall a software project is depressingly long. The enlightened project manager will acquire lists of these risk categories to help the team uncover as many concerns as possible early in the planning process. Possible risks to consider can come from group brainstorming activities or from a risk factor chart accumulated from previous projects. In one of my groups, individual team members came up with descriptions of the risks they perceived, which I edited together and we then reviewed as a team.

The Software Engineering Institute has assembled a taxonomy of hierarchically-organized risks in 13 major categories, with some 200 thought-provoking questions to help you spot the risks facing your project (Carr et al. 1993). Steve McConnell’s Rapid Development (1996) also contains excellent resource material on risk management and an extensive list of common schedule risks.

Following are several typical risk categories and some specific risks that might threaten your project. Have any of these things have happened to you? If so, add them to your master risk checklist to remind future project managers to consider if it could happen to them, too. There are no magic solutions to any of these risk factors. We need to rely on past experience and a strong knowledge of software engineering and management practices to control those risks that concern us the most.

Expecting the project manager to identify all the relevant risks. Different project participants will think of different possible risks. Risk identification should be a team effort.

Dependencies

Some risks arise because of dependencies our project has on outside agencies or factors. We cannot usually control these external dependencies. Mitigation strategies could involve con-tingency plans to acquire a necessary component from a second source, or working with the source of the dependency to maintain good visibility into status and detect any looming prob-lems. Following are some typical dependency-related risk factors:

■ Customer-furnished items or information

■ Internal and external subcontractor or supplier relationships

■ Intercomponent or intergroup dependencies

■ Availability of trained and experienced people

■ Reuse from one project to the next


Requirements Issues

Many projects face uncertainty and turmoil around the product’s requirements. Some uncer-tainty is tolerable in the early stages, but the threat increases if such issues remain unresolved as the project progresses. If we don’t control requirements-related risks we might build the wrong product or build the right product badly. Either outcome results in unpleasant sur-prises and unhappy customers. Watch out for these risk factors:

■ Lack of a clear product vision

■ Lack of agreement on product requirements

■ Inadequate customer involvement in the requirements process

■ Unprioritized requirements

■ New market with uncertain needs

■ Rapidly changing requirements

■ Ineffective requirements change management process

■ Inadequate impact analysis of requirements changes

Management Issues

Although management shortcomings affect many projects, don’t be surprised if your risk management plan doesn’t list too many of these. The project manager often leads the risk identification effort, and most people don’t wish to air their own weaknesses (assuming they even recognize them) in public. Nonetheless, issues like those listed here can make it harder for projects to succeed. If you don’t confront such touchy issues, don’t be surprised if they bite you at some point. Defined project tracking processes and clear project roles and responsibil-ities can address some of these conditions.

■ Inadequate planning and task identification

■ Inadequate visibility into project status

■ Unclear project ownership and decision making

■ Unrealistic commitments made, sometimes for the wrong reasons

■ Managers or customers with unrealistic expectations

■ Staff personality conflicts

Lack of Knowledge

Software technologies change rapidly and it can be difficult to find suitably skilled staff. As a result, our project teams might lack the skills we need. The key is to recognize the risk areas early enough so we can take appropriate preventive actions, such as obtaining training, hiring


consultants, and bringing the right people together on the project team. Consider whether the following factors apply to your team:

■ Lack of training

■ Inadequate understanding of methods, tools, and techniques

■ Insufficient application domain experience

■ New technologies or development methods

■ Ineffective, poorly documented, or ignored processes

■ Technical approaches that might not work

Outsourcing

Outsourcing development work to another organization, possibly in another country, poses a whole new set of risks. Some of these are attributable to the acquiring organization, others to the supplier, and still others are mutual risks. If you are outsourcing part of your project work, watch out for the following risks:

■ Acquirer’s requirements are vague, ambiguous, incorrect, or incomplete.

■ Acquirer does not provide complete and rapid answers to supplier’s questions or requests for information.

■ Supplier lacks appropriate software development and management processes.

■ Supplier does not deliver components of acceptable quality on contracted schedule.

■ Supplier is acquired by another company, has financial difficulties, or goes out of business.

■ Supplier makes unachievable promises in order to get the contract.

■ Supplier does not provide accurate and timely visibility into actual project status.

■ Disputes arise about scope boundaries based on the contract.

■ Import/export laws or restrictions pose a problem.

■ Limitations in communications, materials shipping, or travel slow the project down.

Risk Management ComponentsRisk management is the application of appropriate tools and procedures to contain risk within acceptable limits. As with other project activities, begin risk management by develop-ing a plan. The work aids that accompany this book include a risk management plan template; an outline of this template appears in Figure 6-1. The template document includes guidance that describes how to complete each section. This template is suitable for larger projects. Small projects can include a concise risk management plan as a section within the overall project management plan.


Figure 6-1 Risk management plan template.

Risk management consists of the subactivities illustrated in Figure 6-2 and described in the next section (Boehm 1989).

Figure 6-2 Components of risk management.

Risk Assessment

Risk assessment is the process of examining a project to identify areas of potential risk. Risk identification can be facilitated with the help of a checklist of common risk areas for software projects, such as the brief lists presented in this chapter. You might also study an organization-wide compilation of previously identified risks and mitigation strategies, both successful and unsuccessful. Risk analysis examines how project outcomes might change as a result of the identified risks.

Risk prioritization helps the project focus on its most severe risks by assessing the risk expo-sure. Exposure is the product of the probability of incurring a loss due to the risk and the potential magnitude of that loss. I usually estimate the probability from 0.1 (highly unlikely) to 1.0 (certain to happen), and the loss (also called impact) on a relative scale of 1 (no prob-lem) to 10 (deep tapioca). Multiplying these factors together provides an estimate of the risk exposure due to each item, which can run from 0.1 (don’t give it another thought) through 10 (stand back, here it comes!). It’s simpler to estimate both probability and loss as High, Medium, or Low. Table 6-1 shows how you can estimate the risk exposure level as High, Medium, or Low by combining the probability and loss estimates. It’s also a good idea to consider the time horizon during which a risk might pose a threat. Confront imminent risks more aggressively than those for which you still have some breathing space.

1. Purpose2. Roles and Responsibilities3. Risk Documentation4. Activities5. Schedule for Risk Management Activities6. Risk Management Budget7. Risk Management ToolsAppendix. Sample Risk Documentation Form

Risk Management

Risk Assessment

Risk IdentificationRisk AnalysisRisk Prioritization

Risk Avoidance Risk Control

Risk Management PlanningRisk ResolutionRisk Monitoring


Table 6-1 Estimating Risk Exposure from Probability and Loss

Risk Avoidance

Risk avoidance is one way to deal with a risk: don’t do the risky thing! You might avoid risks by not undertaking certain projects, or by relying on proven rather than cutting-edge technolo-gies when possible. In certain situations you might be able to transfer a risk to some other party, such as a subcontractor.

Risk Control

Risk control is the process of managing risks to achieve the desired outcomes. Risk management planning produces a plan for dealing with each significant risk, including mitigation approaches, owners, and timelines. Risk resolution entails executing the plans for dealing with each risk. Finally, risk monitoring involves tracking your progress toward resolving each risk item.

Let’s look at an example of risk management planning. Suppose the “project” is to take a hike through a swamp in a nature preserve. You’ve been warned that the swamp might contain quicksand. So the risk is that we might step in quicksand and be injured or even die. One strategy to mitigate this risk is to reduce the probability of the risk actually becoming a prob-lem. A second option is to consider actions that could reduce the impact of the risk if it does in fact become a problem. So, to reduce the probability of stepping in the quicksand, we might be on the alert, looking for signs of quicksand as we walk, and we might draw a map of the swamp so we can avoid these quicksand areas on future walks. To reduce the impact if some-one does step in quicksand, perhaps the members of the tour group should rope themselves together. That way if someone does encounter some quicksand the others could quickly pull him to safety. In that way we reduce the impact of stepping in the quicksand. Although, of course, we still stepped in the quicksand.

Even better, is there some way to prevent the risk from becoming a problem under any circum-stances? Maybe we build a boardwalk as we go so we avoid the quicksand. That will slow us down and it will cost some money. But, we don’t have to worry about quicksand any more. The very best strategy is to eliminate the root cause of the risk entirely. Perhaps we should drain the swamp, but then it wouldn’t be a very interesting nature walk. By taking too aggressive a risk approach, you can eliminate the factors that make a project attractive in the first place.

Loss

Probability Low Medium High

Low

Medium

High

Low

Low

Medium

Low

Medium

High

Medium

High

High


Documenting RisksSimply identifying the risks facing a project is not enough. We need to write them down in a way that lets us communicate the nature and status of risks throughout the affected stake-holder community over the duration of the project. Figure 6-3 shows a form I’ve found to be convenient for documenting risks. It’s a good idea to keep the risk list itself separate from the risk management plan, as you’ll be updating the risk list frequently throughout the project.

Figure 6-3 A risk documentation form.

Use a condition-consequence format when documenting risk statements. That is, state the risk situation (the condition) that you are concerned about, followed by at least one potential adverse outcome (the consequence) if that risk should turn into a problem. Often, people sug-gesting risks state only the condition—“The customers don’t agree on the product requirements”—or the consequence—“We can only satisfy one of our major customers.” Pull those together into the condition-consequence structure: “The customers don’t agree on the pr oduct requirements, so we’ll only be able to satisfy one of our major customers.” This statement doesn’t describe a certain future, just a possible outcome that could harm the project if the condition isn’t addressed.

Keep the items that have high risk exposures at the top of your priority list. You can’t address every risk item, so use this prioritization mechanism to learn where to focus your risk control energy. Set goals for determining when each risk item has been satisfactorily controlled. Your mitigation strategies for some items may focus on reducing the probability, whereas the approach for other risks could emphasize reducing the potential loss or impact.

The cell in the form labeled Mitigation Approaches allows you to identify the actions you intend to take to keep the risk item under control. With any luck, some of your mitigation approaches will attack multiple risk factors. For example, one group with which I worked identified several risks related to failures of components of their Web delivery infrastructure (servers, firewall, e-mail interface, and so forth). A mitigation strategy that addressed several of those risks was to implement an automated monitoring system that could check the status of the servers and communication functions periodically and alert the team to any failures.

ID: <sequence number or a more meaningful label>

Description: <List each major risk facing the project. Describe each risk in the form“condition-consequence.”>

Probability: <What’s thelikelihood of this riskbecoming a problem?>

Loss: <What’s the damage ifthe risk does become aproblem?>

Exposure: <MultiplyProbability times Loss.>

First Indicator: <Describe the earliest indicator or trigger condition that might indicatethat the risk is turning into a problem.>

Mitigation Approaches: <State one or more approaches to control, avoid, minimize,or otherwise mitigate the risk.>

Owner: <Assign each risk mitigation actionto an individual for resolution.>

Date Due: <State a date by which themitigation approach is to be completed.>


Figure 6-4 illustrates an alternative template for your risk list, which is also included in the process assets on the Web site that accompanies this book. This format includes essentially the same information that’s in Figure 6-3 but it is laid out in a way that is amenable to storing in a spreadsheet or a table in a word-processing document. Storing the risks in a table or spreadsheet facilitates sorting the risk list by descending risk exposure.

Risk TrackingAs with other project management activities, you need to get into a rhythm of periodic moni-toring. You may wish to appoint a risk manager or “risk czar” for the project. The risk manager is responsible for staying on top of the things that could go wrong, just as the project manager is staying on top of the activities leading to project completion. One project team dubbed their risk manager “Eeyore” after the Winnie-the-Pooh character who always bemoaned how bad things could become. It’s a good idea to have someone other than the project manager serve as the risk manager. The project manager is focused on what he has to do to make a project succeed. The risk manager, in contrast, is identifying factors that might prevent the project from succeeding. In other words, the risk manager is looking for the black cloud around the silver lining that the project manager sees. Asking the same person to take these two opposing views of the project can lead to cognitive dissonance; in an extreme case, his brain can explode!

Keep the top 10 risks highly visible (McConnell 1996) and track the effectiveness of your mit-igation approaches regularly. As the initial list of top priority items gradually gets beaten into submission, new risks might float up into the top 10. You can drop a risk off your radar when you conclude that your mitigation approaches have reduced the risk exposure from that item to an acceptable level.

Assuming that a risk is controlled simply because the selected mitigation action has been completed. Controlling a risk might require you to change the risk control strategy if you conclude it is ineffective.

A student in a seminar once asked me, “What should you do if you have the same top five risks week after week?” A static risk list suggests that your risk mitigation actions aren’t working. Effective mitigation actions should lower the risk exposure as the probability, the loss, or both decrease over time. If your risk list isn’t changing, check to see whether the planned mitigation actions have been carried out and whether they had the desired effect.

Failing to look for new risks that might arise during the course of the project. Conditions can change, assumptions can prove to be wrong, and other factors might lead to risks that weren’t apparent or perhaps did not even exist at the beginning of the project.


IDD

escr

ipti

on

PL

EFi

rst

Ind

icat

or

Mit

igat

ion

Ap

pro

ach

Ow

ner

Dat

e D

ue

<Li

st e

ach

maj

or r

isk

faci

ngth

e pr

ojec

t. D

escr

ibe

each

ris

kin

the

form

“co

nditi

on –

cons

eque

nce”

. Exa

mpl

e:“S

ubco

ntra

ctor

’s s

taff

doe

sno

t ha

ve s

uffic

ient

tec

hnic

alex

pert

ise,

so

thei

r w

ork

isde

laye

d fo

r tr

aini

ng a

ndsl

owed

by

lear

ning

cur

ve.”

>

*P†L

‡E<

For

each

ris

k,de

scri

be t

he e

arlie

stin

dica

tor

or t

rigg

erco

nditi

on t

hat

mig

htin

dica

te t

hat

the

risk

is t

urni

ng in

to a

prob

lem

.>

<Fo

r ea

ch r

isk,

sta

te o

ne o

r m

ore

appr

oach

es t

o av

oid,

tra

nsfe

r,co

ntro

l, m

inim

ize,

or

othe

rwis

em

itiga

te t

he r

isk.

Acc

eptin

g th

e ri

skis

ano

ther

opt

ion.

Ris

k m

itiga

tion

appr

oach

es s

houl

d yi

eld

dem

onst

rabl

ere

sults

, so

you

can

mea

sure

whe

ther

the

risk

exp

osur

e is

cha

ngin

g.>

<A

ssig

n ea

chri

sk a

ctio

n to

an in

divi

dual

.>

<St

ate

a da

teby

whi

ch e

ach

miti

gatio

nac

tion

is t

o be

com

plet

ed.>

Key

:*P

= P

rob

abili

ty o

f o

ccur

renc

e o

f th

e ri

sk, e

xpre

ssed

as

a nu

mb

er b

etw

een

0.1

(hig

hly

unlik

ely)

and

1.0

(g

uara

ntee

d t

o ha

pp

en).

Alte

rnat

ivel

y, y

ou

coul

d e

stim

ate

this

as

Low

, Med

ium

, Hig

h.

†L=

Rel

ativ

e lo

ss if

the

ris

k d

oes

tur

n in

to a

pro

ble

m, e

xpre

ssed

as

a nu

mb

er b

etw

een

1 (m

inim

al im

pac

t) a

nd 1

0 (c

atas

tro

phe

). A

lter

nati

vely

, yo

u co

uld

es

tim

ate

this

as

Low

, Med

ium

, Hig

h. E

ven

bet

ter,

est

imat

e th

e ac

tual

loss

in t

erm

s o

f ca

lend

ar w

eeks

fo

r sc

hed

ule

imp

act,

do

llars

fo

r a

cost

imp

act,

etc

.

‡E=

Ris

k Ex

po

sure

. If

num

eric

val

ues

wer

e as

sig

ned

to

Pro

bab

ility

and

Lo

ss, t

hen

Ris

k Ex

po

sure

= P

* L

. If

rela

tive

val

ues

wer

e us

ed (L

ow

, Med

ium

, Hig

h),

esti

mat

e th

e o

vera

ll ri

sk e

xpo

sure

usi

ng T

able

6-1

.

Fig

ure

6-4

An

alte

rnat

ive

risk

list

tem

pla

te.


Risk Management Can Be Your FriendThe skillful project manager will use risk management to raise awareness of conditions that could cause the project to go down the tubes. Consider a project that begins with a fuzzy prod-uct vision and no customer involvement. The astute project manager will spot this situation as posing potential risks and will document them in the risk list. Early in the project’s life, the impact of this situation might not be too severe. However, if time passes and the lack of product vision and customer involvement are not improved, the risk exposure will steadily rise.

By reviewing the risk list periodically, the project manager can adjust the estimated probabil-ity and/or impact of these risks. The project manager can escalate risks that aren’t being con-trolled to the attention of senior managers or other stakeholders. They can then either stimulate corrective actions or else make a conscious business decision to proceed in spite of the risks. In this way we’re keeping our eyes open and making informed decisions, even if we can’t control every threat the project faces.

Learning from the PastWe can’t predict exactly which of the many threats to our projects might come to pass. How-ever, most of us can do a better job of learning from previous experiences to avoid the same pain and suffering on future projects. As you begin to implement risk management approaches, record your actions and results for future reference. Try these suggestions:

■ Record the results of even informal risk assessments, to capture the thinking of the project participants.

■ Document the mitigation strategies attempted for each risk you chose to confront, not-ing which approaches worked well and which didn’t pay off.

■ Conduct retrospectives to identify the unanticipated problems that arose (see Chapter 15). Should you have been able to see them coming through better risk management, or would you likely have been blindsided in any case? Could these same problems occur on other projects? If so, add them to your growing checklist of potential risk factors for the next project to consider.

Anything you can do to improve your ability to avoid or minimize problems on future projects will improve your company’s business success. Risk management can also reduce the chaos, frustration, and constant firefighting that impair the quality of work life in so many software organizations. The risks are out there. Find them before they find you.


Practice Activities1. On Worksheet 6-1 list some risk categories that might threaten the success of your

project. Identify several specific risk factors in each category.

2. Use Worksheet 6-2 to document several of the risks you identified in the previous prac-tice activity. Be sure to describe each risk in the form of a condition followed by one or more possible consequences. Plan how you might control each risk.


Risk Category Specific RisksWorksheet 6-1: Your Risk List


IDD

escr

iptio

nP

LE

Firs

t Ind

icat

orM

itiga

tion

App

roac

hO

wne

rD

ate

Due

1 2 3 4 5 6

Wor

kshe

et 6

-2: D

ocum

entin

g Ri

sks

119

Chapter 9

Negotiating Achievable Commitments

In this chapter:

Making Project Commitments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120

Negotiating Commitments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120

Documenting Commitments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122

Modifying Commitments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123

Your Personal Commitment Ethic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124

Practice Activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126

I once observed a discussion between Steve, a senior manager, and Rob, a project manager, about a new project. “How long will this project take?” Steve asked. “Two years,” replied Rob. “No,” said Steve, “that’s too long. I need it in six months.” So what did Rob say? “Okay.” Now, what changed in those few seconds? Nothing! The project didn’t shrink by a factor of four. The development team didn’t get four times larger (although this would not have solved the problem). The team didn’t become 400% as productive. The project manager simply said what he knew Steve wanted to hear. Not surprisingly, the project took more than two years to complete.

Too many software projects are launched with the hope that productivity magic will happen, despite previous experiences to the contrary. Sometimes a team does get lucky or pulls off a miracle. More often, though, miracles don’t happen, leaving managers, customers, and devel-opers frustrated and disappointed. Successful projects are based on realistic commitments, not fantasies and empty promises. Project initiation is the right time to establish a convention for how you’re going to handle commitments on your project. This chapter presents several ways to improve your ability to make—and keep—achievable project commitments (Humphrey 1997).1

Expecting people to take imposed commitments seriously. The commitments you strive hardest to satisfy are those you make freely, not under duress.

1 This article was originally published in The Rational Edge, January 2002. It is reprinted here, with modifications, with permission from IBM.

1

120 Part III Living with Reality

Making Project CommitmentsA commitment is a pact one person makes with another. Both parties expect the pact to be kept. The commitment might involve delivering a specific work product or performing a par-ticular service by a specified time and at a certain level of quality. A software development project involves many commitments between customers, business managers, development managers, and individual team members. The project manager makes both individual com-mitments and commitments on behalf of the whole team. The project manager also requests commitments from team members and perhaps from external stakeholders. Some software projects have at least one formal commitment: a legally binding contract.

Effective commitments must meet two conditions:

1. We must make them freely. Powerful people can pressure us to say yes, but most people are unlikely to take ownership of an impossible commitment that is thrust upon them. Some people will pretend to make a commitment they don’t intend to fulfill to bring an unpleasant conversation to a close, but this undermines the commitment ethic.

2. They must be stated explicitly and be clearly understood by all parties involved. Ambiguity about the specifics of the commitment reduces the chance that it will be satisfied.

It’s easy to make unrealistic promises on software projects. Most developers are optimistic about their talents and overestimate their productivity. Project managers assume their staff have 40 or more hours of productive project time available each week, although the reality is considerably less. Managers and customers who don’t understand software development pressure the team to provide perfect estimates and to meet their aggressive business expecta-tions with little regard for the uncertainties we face. Often, we get incomplete or misleading information about the problem we’re asked to solve, which limits our ability to make mean-ingful estimates and commitments. Requirements are volatile, changing frequently for both good and not-so-good reasons. We need the freedom to renegotiate unrealistic commitments that turn out to be based on inaccurate information or premises that have changed.

Negotiating CommitmentsNegotiations are in order whenever there’s a gap between the schedule or functionality project stakeholders demand and your best prediction of the future as embodied in project estimates. Plan to engage in good-faith negotiations with customers, senior managers, and project team members about achievable commitments. Principled negotiation, a method to strive for mutu-ally acceptable agreements, involves four key precepts (Fisher, Ury, and Patton 1992):

■ Separate the people from the problem

■ Focus on interests, not positions

■ Invent options for mutual gain

■ Insist on using objective criteria

Chapter 9 Negotiating Achievable Commitments 121

Separate the People from the Problem Negotiation is difficult when emotions get in the way. It’s also hard to negotiate with individuals who wield more organizational power than you do. Before you dismiss a manager or customer as an unreasonable slave driver who makes impossible demands, recognize his legitimate concerns and objectives, including commit-ments others might have made that put him in a bind.

Focus on Interests, Not Positions A marketing manager who establishes a strong position in a negotiation (“This product absolutely must ship by November 5th!”) can find it difficult to change that position. If you, the project manager, define an opposing but equally entrenched position (“We can’t possibly be done before mid-January!”), conflict is inevitable. Rather than reaching an impasse by defending your terrain to the death, seek to understand the interests behind each party’s stated position.

Perhaps marketing’s real interest is to have a demo version available for an important trade show. Your interest might be to avoid burning out your team with massive overtime for four months and establishing a track record of failure. Maybe you and the marketing manager can agree on a core set of features and performance targets that would satisfy marketing’s primary interest and be achievable by the convention deadline. Delivery of the completed product could then be deferred to a more reasonable date.

Invent Options for Mutual Gain Negotiation is the way to close the gap between polarized positions. Begin with a win-win objective in mind (Boehm and Ross 1989), and look for cre-ative ways to satisfy each party’s interests. Think of feasible outcomes to which you are willing to commit and present those as options.

If you can’t commit to fully satisfying a key stakeholder’s demands, state what you are able to deliver. Could you make a more ambitious commitment if certain conditions were met, such as shedding your team’s maintenance responsibilities for existing products? If your team is pressured to work a lot of unpaid overtime to get the job done, will the company grant them compensating vacation time afterward?

Insist on Using Objective Criteria Negotiations based on data and analysis are more con-structive than those based on faith and opinions. Data from previous projects and estimates based on a rational planning process will help you negotiate with someone who insists his grandmother could finish the project in half the time you’ve proposed. When you’re relying on commitments from a third party, such as a subcontractor or a vendor, trust data and his-tory over promises. Keep these commitment tips in mind:

■ When requesting commitments from other people, remember that an estimate is not the same as a promise. Expect to receive a range for an estimate, not a single number or date. Alternatively, request a confidence level, a probability that the estimate will be met.

■ A common reason for commitment failure is making “best case” commitments rather than “expected case” commitments. Some teams define internal target delivery dates that are more optimistic than their publicly committed delivery dates (see Chapter 10, “Saving


for a Rainy Day”). This sensible approach helps compensate for imperfect estimates and unanticipated eventualities.

■ Improve your ability to meet commitments by creating more realistic estimates. Base your estimates on data of actual performance collected from previous activities.

■ To avoid overlooking necessary work, use planning checklists that list all the activities you might have to perform for common tasks.

■ Contingency buffers provide protection against estimation errors, erroneous assump-tions, potential risks that materialize, and scope growth (see Chapter 10).

Once some project requirements are defined, one approach to making commitments is to have team members “sign up” for specific task responsibilities (McConnell 1996; Jeffries, Anderson, and Hendrickson 2001). This is a characteristic of an organization with a healthy commitment ethic. Such voluntary personal commitments—based on each person’s evalua-tion of what it will take to accomplish a goal—motivate team members to make the project suc-ceed. A manager cannot impose this level of enthusiasm and commitment upon others.

Your committed delivery dates might be farther out than your managers or customers would like, but if you consistently fulfill the commitments you make, other people will know they can count on you and your team.

Documenting CommitmentsWhen my brother Bruce was an engineering manager, periodically he would discuss expecta-tions with certain individuals on his team. Sometimes Bruce would think a team member had made a commitment, but the team member viewed Bruce’s request merely as a suggestion. To reduce ambiguity, it’s helpful to write a brief summary of each commitment that you exchange with someone else. This confirms the communication and establishes a shared expectation of accountability. A written commitment record also permits tracking actual performance against expectations. Unless I write them down, I find it easy to lose sight of promises I’ve made to others and of things I’m expecting to receive from other people. A simple table such as that in Figure 9-1 is a convenient way to document commitments.

Verbal commitments that are unclear and undocumented. Negotiate to make interpersonal and intergroup commitments explicit and realistic. Renegotiate promptly if changes in cir-cumstances won’t permit you to keep them.


Figure 9-1 Template for a commitment record.

Modifying CommitmentsMany projects have formal agreements to implement a specific set of requirements by a partic-ular date. Such commitments can fall by the wayside if the requirements turn out to be tech-nically unfeasible or especially challenging, if customers modify them, or if the stated requirements were just the tip of the real requirements iceberg. Project stakeholders must alter their expectations and commitments in the face of evolving information.

Inevitably, project realities—requirements, resources, technologies, budgets, schedules—will change. Problems will arise, risks will materialize, and new functionality will be requested. If your customers demand 10 new features late in the development cycle, they can’t expect to get the product by the original deadline. Whenever it appears that some targeted deliverables won’t be completed before you run out of time and resources, the key project stakeholders need to decide how to respond. As described in Chapter 4 (“Success Criteria Breed Success”), you need to remember which project dimensions are constraints, which are important success drivers, and which ones you can adjust if necessary. Here are some options you might explore, guided by your established project priorities:

■ Can some lower-priority requirements wait for a later release?

■ Can delivery be delayed? By how long?

■ Can you channel more developers onto the project?

■ Will the customer pay extra to bring contractors on board to implement the new features?

If it becomes apparent that you or your team won’t meet a commitment, inform the affected stakeholders promptly. Don’t pretend you’re on schedule until it’s too late to make adjust-ments. Letting someone know early on that you can’t fulfill a commitment builds credibility and respect for your integrity, even if the stakeholders aren’t happy that the promise won’t be kept.

Commitment Made By Made To Date Due Comments


Rigidly adhering to impossible or obsolete commitments can lead to serious problems. One project manager promised year-end delivery of a mission-critical application. He maintained that his small team could do the job without additional resources, but the year drew to a close without a delivery. The next year, his manager brought more team members on board and the project made good progress. Again, the project manager promised to deliver by the end of that year but again he failed to do so. Unwilling to admit that he couldn’t achieve his commitment, he kept the challenges he was facing to himself, hoping to save face.

In fact, his stubbornness had the opposite effect. His development team lost credibility with both customers and managers. In addition, technology changes over the long course of the project rendered the new application largely irrelevant. When the system finally was deliv-ered, it was nearly dead on arrival and many stakeholders were disappointed. A more respon-sible manager would have acknowledged reality and renegotiated resources and delivery dates. And when it became clear that pursuing the initial requirements amounted to throwing good money after bad, the project’s decision makers should have redirected or canceled the project.

Your Personal Commitment EthicWell-intentioned people often commit to more than they can handle. I once managed a capa-ble and dedicated developer who always said “yes” whenever I asked her to take on a new responsibility. I soon learned, however, that often she didn’t deliver on schedule. Her in-basket was overflowing. There was simply no way she could complete everything to which she had agreed, despite her cooperative nature and good intentions.

The same sort of thing happened with this very book. The original publisher concluded part-way through the book production process that he was overextended and backed out of the contract. It could have been worse. The book could have lingered for months in an incomplete state, only to be cancelled after a lot of time and goodwill had passed under the bridge. But the contract cancellation did leave me with the problem of scrambling to find another publisher. As you can see, I was successful!

Accepting more responsibilities than you can fulfill makes you look unresponsive and makes others skeptical about your promises. A meaningful commitment ethic includes the ability to say “no,” or at least “whoa” (Karten 1994). Here are some other ways to say “no” that might sound more palatable:

■ “Sure, I can do that by Friday. What would you like me to not do instead?” (As project manager, you’re responsible for making these priority decisions.)

■ “We can’t get that feature into this release and still ship on schedule. Can it wait until the next release, or would you rather defer some other functionality?” (This is a way to say “not now” instead of “no.”)


■ “That sounds like something I can do, but I’m afraid it’s not as high on the priority list as my other obligations. Let me suggest someone else who might be able to help you more quickly than I can.”

Unachievable commitments. People won’t try as hard to achieve commitments they know are impossible. They don’t want to set themselves up for failure.

A track record of making realistic performance estimates and satisfying your commitments earns credibility. That credibility improves your future ability to negotiate problematic sched-ules or other commitment requests. Before you say, “Sure, no problem” to a request, use the commitment analysis checklist in Figure 9-2 to think through carefully whether you should make the commitment.

Figure 9-2 Commitment analysis checklist.

Despite occasional pressure to promise the impossible, I practice this personal philosophy: Never make a commitment you know you can’t keep. My personal preference is to undercom-mit and overdeliver. Keeping that resolve is both part of being a professional and a way to be recognized as someone who is reliable. Once I was discussing process improvement plans with my department’s aggressive and intimidating senior manager, four levels above me. Fred was pressuring me to agree to a timetable that my group had concluded was not remotely fea-sible. When I resisted, he grudgingly moved his objective out several months, but even that goal was pure fantasy. Finally I took a deep breath and said, “Fred, I’m not going to commit to that date.” Fred literally did not know what to say. I don’t think anyone had ever before refused to make a commitment he demanded.

It would be unprofessional to commit to an objective that I knew was unattainable, I explained. I said, “We’re not going to work any less hard if we have more time to do it, and our morale will be higher if we’re not set up for certain failure.” Reluctantly, Fred agreed to a more plausible target date. He didn’t shout at me or hit me or fire me, although in some situations those might be possibilities you need to consider.

Status Commitment Criteria

All parties fully understand what is being committed to.

I have examined my assumptions and any external dependencies that could affectmy ability to fulfill the commitment.

I have identified circumstances that could prevent me from keeping thecommitment. The likelihood that these circumstances will occur is:❏ Not very likely Somewhat likely Very likely

The commitment is realistic and achievable, based on what I know today.

I have documented the commitment, along with my assumptions anddependencies.

I will notify the other parties if anything affects my ability to deliver on thecommitment.

❏

❏

❏

❏

❏

❏

❏ ❏


As a project manager, don’t pressure your team members to commit to requirements or deliv-ery dates they don’t believe to be achievable. If you fear someone is getting in over his head, discuss the commitment details, assumptions, the risks of failing to meet the commitment, and other obligations that could get in the way. Stay on top of the promises you and your team members make to others by recording and tracking requirements and milestones. Also moni-tor the promises others make to you. Create an environment in which your team members can turn to you for help with negotiation and priority adjustments. Unfulfilled promises ulti-mately lead to unhappy people and projects that don’t succeed, so strive to build a realistic commitment ethic in your team.

Practice Activities1. Use Worksheet 9-1 to list your personal commitments or commitments you’ve made on

behalf of your team. Indicate whether they are realistically achievable, knowing what you know now. Identify your (or your team’s) interests with respect to each commitment and the interests of the person to whom you’ve made the commitment. Are any of these com-mitments at risk of not being satisfied?

2. Identify commitments that others have made to you. Assess the impact if any are not satisfied.


Com

mitm

ent

Mad

e To

Mad

e By

Dat

e D

ueYo

ur In

tere

sts

Thei

r In

tere

sts

Wor

kshe

et 9

-1: Y

our

Proj

ect’

s or

You

r Pe

rson

al C

omm

itmen

ts

Ach

ieva

ble?

203

Index

Aachievable commitments. See commitments,

achievableaction planning, 195

template for, 195actual/estimated duration metric, 155actual/estimated effort metric, 155actuals, recording, 20after-action report. See retrospectivesagile, xiii, 151Airlie Council, 178analysis, earned value, 16analysis paralysis, 180Anderson, Ann, 122anonymity, Wideband Delphi

method, 142, 144antipatterns for project management, 180assembly, task, Wideband Delphi

method, 144–45approval, of project charter, 103assertiveness, 4–5Assumptions

in project charter, 101Wideband Delphi method,

143,144,145Austin, Robert D., 157

Bbase measures, 154

precision of, 166Basili, Victor R., 154best practices, 7, 11–21, 177–79Boddie, John, 11, 177Boehm, Barry, 42, 82, 121, 138bottom-up estimates, 19Brackett, John W., 43Brooks, Frederick P., 46, 180Brown, Norm, 16, 77, 178Brown, William, 180budget buffers, 19buffers, contingency, 129–30, 19, 78, 122,

131–34budget, 19calculating, 130, 131–34critical chain project management, 134–36estimating, 133–34

feeding, 135iterations and, 131–32project, 135risk analysis and, 133–34schedule, 19skeptics, convincing, 130

businesscase, 41, 94. See also project charterdrivers, 26goals, 12, 40, 97objectives, 40–42, 51, 97requirements, 95risks, charter, 102

Ccalendar-time estimates, 18calibration, prioritization model, 29–30Campanis, Nicholas A., 146Capability Maturity Model for Software, 139Carr, Marvin J., 79CASE tools. See computer-aided software

engineering (CASE) toolsCaswell, Deborah L., 65change, responding to, 59charter. See project charterchecklists, tasks, 16classic mistakes, project management,

180–81coaching, 4code defects, 16code generators, 106, 110Collier, Bonnie, 190commitment analysis checklist, 125commitment ethic, personal, 124–26commitments, achievable, 14, 94, 119–20

commitment record template, 123documenting, 122making, 120modifying, 123–24negotiating, 120–22personal commitment ethic, 124–26worksheets, 127

commitments, negotiating, 120–22. See also achievable commitments

committed delivery date, 132communication

204 computer-aided software engineering (CASE) tools

inefficiencies, 18lack of, 168skills, 5

computer-aided software engineering (CASE) tools, 109–10

cone of uncertainty, 137–38confidence level, 146configuration management, 67

task estimates, 141tools, 106

conflict resolution, 4condition-consequence format for risks, 84consensus approach, 138. See also Wideband

Delphi method defects, 13conservatives market segment, 69–70constraints, 12–13

economic, 40in project charter, 101project, 44–46

Construx Software, 19context diagram, 100contingency buffers. See buffers, contingencycontingency plans, 17continuous learning, 175–76contracts, litigation, 130cost

as project dimension, 45drivers, 19tools, 107

Covey, Stephen, 39critical chain analysis, 19critical chain project management, 134–36critical path, 132culture

measurement, creating, 156–57, 164–65tools and, 110–11

customer representatives, 26, 30customer satisfaction, 4

product quality, 5–6, 14, 62

DDaskalantonakis, Michael K., 154data

defining, 158field descriptions, lessons learned, 182historical, 20measurement, correlation of, 165–66metrics, 167–68misinterpreting, 168–69privacy, 156

sharing, 157–58trends, 158unused, 168

datasheet, project, 41, 94. See also projectcharter

debriefing. See retrospectivesdecision making, 44, 98decision matrix analysis, 26–31decision rules, 44, 98defects, 13

code, 16metric, 156release criteria, 64–65rework estimates, 141

degrees of freedom, 12–13, 45deliverables, in project charter, 101–2delivery date, planned vs. committed, 132Delphi. See Wideband Delphi estimation

methodDeMarco, Tom, 77, 130, 134, 190dependencies

in project charter, 101risks related to, 79

Derby, Esther, 187, 188derived measures, 154design tools, 106Dettmer, William, 136diagrams

CASE, 109context, 100flexibility, 45–46Kiviat, 45

diffusion of innovation, 69dimensions, project, 44–46

in project charter, 101worksheet, 55

documentation, commitment, 122, 123drivers, 45

business, 26cost, 19prioritization, 26–30project, 12–13schedule as, 13, 46technical, 26

dysfunctional measurement, 157, 165

Eearly adopters market segment, 14, 69early majority market segment, 69earned value analysis, 16

International Function Point Users Group (IFPUG) 205

Eastman Kodak Company, 3, 5, 177errors, estimation, 146Estimate Express software, 19Estimate software, 19, 137–38estimated/actual duration metric, 155estimated/actual effort metric, 155estimates, 18–19, 137–138

buffer, 133–34errors, 146vs. predictions, 146recording, 20results review, 145single-point, 145–46tools for, 19Wideband Delphi. See Wideband Delphi

methodwork, 18–19

estimating work, 18–19estimation, Wideband Delphi. See Wideband

Delphi estimationestimation. See estimatesestimation meeting, Wideband Delphi

method, 142–44ethic, personal commitment, 124–26evaluation, individual, 167Evanco, William M., 179evolutionary delivery, 179experience. See learningexternal stakeholders, 42exit criteria, Wideband Delphi method,

145–46

Ffacilitator, retrospectives, 144, 190–91, 193Fearey, Peter, 190features, as project dimension, 45feeding buffers, 135. See also buffers,

contingencyFisher, Roger, 14, 120flexibility diagram, 45–46Fogle, Sam, 178Foody, Michael A., 66formal commitments, 120forming, group stage, 107freedom, degrees of, 12–13, 45functional requirements, 95functionality, 67

GGilb, Tom, 47n, 68

goal-question-metric (GQM), 154, 157, 166worksheet, 161

goalsbusiness, 12, 40, 97. See also business

objectivesfor improvement, 7–8metrics and, 154product release, 13–14setting, 4

Goldratt, Eliyahu, 134good practices, 21 tips for project

management, 11–21worksheet for, 23

Gottesdiener, Ellen, 44, 98GQM (goal-question-metric).

See goal-question-metric (GQM)Grady, Robert B., 65, 156, 167Green, Michael, 136Greene, Jennifer, 138ground rules for retrospectives, 190group(s)

estimation, 19processes, 107

HHendrickson, Chet, 122Highsmith, Jim, 45historical data, 20, 130human resources, in project charter, 102Humphrey, Watts, 146

IIannino, Anthony, 65ideas, selling, 4IEEE Std 1058-1998, 15IFPUG (International Function Point Users

Group), 47III, 94inch-pebbles, 15–16, 20individual-level metrics, 155, 156, 167information-gathering stage, retrospectives,

190–92initiation, project; See project initiationinnovation, diffusion of, 69innovators market segment, 69interests, stakeholder, 42–44internal stakeholders, 42International Function Point Users Group

(IFPUG), 47

206 interpersonal skills

interpersonal skills, 4iron triangle,” 44issue analysis and prioritization, in

retrospectives, 192iterations

contingency buffers and, 131–32estimates and, 138

JJeffery, D. R., 131Jeffries, Ron, 122Jones, Capers, 153, 179just-in-time training, 18

KKarten, Naomi, 124Kerth, Norman, 21, 187, 188, 189key stakeholders, 43keywords, vision statement, 99kickoff meeting, Wideband Delphi

method, 140kickoff stage, retrospectives, 189Kiviat diagram, 45KLOC, 65knowledge, lack of, risks related to, 80–81KnowledgePlan software, 19

Llabor-hour estimates, 18, 140–41laggards market segment, 70Larsen, Diana, 187, 188late majority market segment, 14, 69–70Lawrence, M. J., 131Leach, Lawrence, 19, 134, 135leadership

vs. management, 3services of, 4

learningbest practices, 177–79continuous, 175–76from experience, 177lessons, 181–82worst practices, 180–81

learning curve, 17tool adoption, 111

lessons learned, 181–82worksheet for, 185

Lewis, James P., 16

long-term goals, 7–8life cycle best practices, 179life cycle model selection, 179listening skills, 4–5Lister, Tim, 39, 77, 131, 134litigation, contract, 130Loulis, Carol, 178

Mmanagement. See also configuration

management; project management;software management

commitment, lack of, 164irrational, 180vs. leadership, 3retrospectives results, 192risks related to, 80senior, 4, 71, 111, 130, 192Theory-W, 179

management reserves, 19, 129. See also buffers, contingency

market segments, 14marketing requirements document, 41, 94. See

also project chartermarketplace expectations, 69–70May, Lorin J., 188McConnell, Steve, 7, 18, 79, 85, 122, 137, 146,

178, 180McGary, Rudd, 40, 133McManus, John, 42measurement, 151. See also software metrics

dysfunctional, 157, 165mentoring, 4merging, task lists, 144–45metrics, software. See software metricsmilestones

in project charter, 101–2miniature, 179

mistakes, classic, project management, 180moderator, Wideband Delphi method, 139,

140, 144Monte Carlo simulation, 146Moore, Geoffrey, 69, 99More About Software Requirements

(Wiegers), 100motivation, and metrics, 167–68multitasking, 18multivoting, 192Musa, John D., 65

project buffer 207

NNASA lessons learned database, 181negotiation, 14, 94

commitment, 120–22. See also commitments, achievable

principled, 14, 120–21, 179Neuendorf, Bill, 178“no,” saying, 124–25nonhuman resources, in project charter, 102norming, group stage, 107

Oobjective criteria, 121–22objectives

business, 40–42, 51, 97defining, 40–42in project charter, 97retrospectives, 193win-win, 121

Okumoto, Kazuhira, 65Open Source Applications Foundation, 63–64organization-level metrics, 156outsourcing, risks related to, 81

PParkinson, C. Northcote, 131Parkinson’s Law, 131, 134past, learning from, 7, 87Patton, Bruce, 14, 120Paulk, Mark, 139peer review, 16, 65, 103people skills, 4performance evaluation, 167performing, group stage, 107personal commitment ethic, 124–26persuasion, 4plan, project management

vs. charter, 95writing, 14–15

Planguage, 47nrelease criteria, 68

planned delivery date, 132planning

action, 195stage, retrospectives, 189stage, Wideband Delphi method, 139too much, 180worksheets, 16

postmortems, 21, 188. See also retrospectives

post-project reviews, 21, 188. See also retro-spectives

Potter, Neil, 138pragmatists market segment, 69predictions, vs. estimates, 146predictive capability, prioritization model,

29–30presentation skills, 5principled negotiation, 14, 120–21, 179priorities, setting, 3–4prioritization, project, 25

calibrating model, 26drivers, 26–30model construction, 26–30model use, 30–31spreadsheet, 33

prioritization, of retrospective issues, 192privacy, of metrics data, 195probability distribution, 130

Wideband Delphi method, 146procedures, defining, 158Process Group, The, 138process, vs. tools, 106process improvement, 17

retrospectives and, 187–88product

functions, 40operational and temporal context, 41release criteria, See release criteria, product

product size metric, 155productivity, tools and, 107progress

recognizing, 6–7tracking, 20

project(s)appropriateness, 2constraints, identifying, 44–46overconstrained, 13, 46plan template, 15prioritization. See prioritization, projectrejecting, 103retrospectives, 21risks, 16–17scope, 100sponsor, 98successful, defining, 11work estimations, 18–19

project buffer, 135. See also buffers,contingency

208 project charter

project charter, 41, 45, 78, 93–95approval, 103components, 96–102defined, 95vs. project management plan, 95vs. requirement specification, 95template for, 96use, 103–4

project constraints, 44–46project datasheet, 41, 94. See also project

charterproject description, in project charter, 97project dimensions, 44–46project drivers, 12–13project initiation document. See project charterproject initiation phase, 1, 37–38, 129–30, 131,

151, 153, 175, 177charter, 93–94, 95, 96, 97, 104commitments, 117, 119estimates, 137–38human resources, 102mistakes, 180release criteria, 61retrospectives, 187risk management, 78stakeholders, 98tools, 105

project-level metrics, 155project management See also individual

subentries as main entriesachievable commitments, 119–26best practices, 177–79buffers, 129–36charter, 93–104classic mistakes, 180–81critical chain, 134–36definition of, xvestimates, 137–46good practices, 11–21improvement goals, 7–8initiation phase. See project initiation phasepast, learning from, 7plan, vs. charter, 95progress, recognizing and tracking, 6–7, 20quality, defining, 5–6skill gap analysis, 4–5release criteria, 61–71risk management, 77–87starting slowly, 8–9status tracking, 20

success criteria, 37–48tool adoption, 105–11tools, 106worst practices, 180–81

Project Management Institute, 5, 42, 103project management plan, 14–17project managers, 1, 87, 139. See also

managementproject sponsor, 98project team. See team memberspublic speaking skills, 5

Qquality

assurance plan, 41attributes, 5–6attributes, release criteria, 66control, 16control tasks, estimates, 141customer view, 5–6, 14, 62defects, 64–65defining, 5–6as project dimension, 44–45engineering view, 62improvement tools, 106metrics, 154–55tools and, 107

quality improvement review. See retrospectivesquestions, metrics and, 154

RRand Corporation, 138Rapid Development (McConnell), 7, 79, 178rating scales, project prioritization drivers, 27,

30–31Rational Edge, The, 39n, 119n, 129nrecognition, team members, 6–7Reifer, Donald J., 11nrelease criteria, product, 13–14, 41, 61–64

ambiguous, 62, 63configuration management, 67defects, 64–65functionality, 67marketplace expectations, 69–70Planguage and, 47n, 68quality attributes, 66sample, 63, 64support, 67–68testing, 65–66worksheets, 73, 75

software 209

requirementsrisk related to, 80metric, 155tools, 106vs. project charter, 95

resources, in project charter, 102retrospectives, 7, 21, 187

action planning, 195after iterations, 188defined, 187–88process, 188–93process improvement and, 187reporting results, 192–93risk management, 87summary report template, 192–93success factors, 193–95worksheet for, 197–98

rewards, team members, 6–7rework, 16

tasks, estimates, 141risk(s)

analysis, buffers and, 133–34assessment, 82avoidance, 82, 83business, in project charter, 102contingency buffers, 19control, 83defined, 78documenting, 84–85exposure, 17identification, 82list, top 10, 179management. See risk managementmonitoring, 82, 83prioritization, 82resolution, 82, 83software, 79–81tracking, 85worksheets, 89, 91

risk list, template for, 85–86risk management, 16–17, 77–78

components, 81–83defined, 78documenting risks, 84–85past, learning from, 87rationale for, 78–79, 87software risks, 79–81plan template, 81–82tracking, 85worksheets, 89, 91

risk management plan, template for, 81–82

roles and responsibilities in project charter, 98Rogers, Everett M., 69Rombach, H. Dieter, 154Ross, Ronnie, 42, 121Rothman, Johanna, 13, 14, 63, 187nRubin, Howard, 163

Ssafety increments, 131, 134safety time. See contingency buffersSakry, Mary, 138Sassenburg, Hans, 65scales, rating, 27schedule

buffers, 19as project dimension, 44–45estimates, 141, 142learning curve time, 17milestones, 101–2over-scheduling, 18process improvement time, 17rework time, 16slips, 16training time, 18

Schragenheim, Eli, 136scope, in project charter, 100senior management. See management, seniorSeven Habits of Highly Effective People, The

(Covey), 39Shoemaker, F. Floyd, 69short-term goals, 7–8Simmons, Erik, 68simulation, Monte Carlo, 146single-point estimates, 145–46six sigma quality, 6size, product metric, 155skeptics market segment, 70skill gaps, analyzing, 4–5SLIM-Estimate software, 19SMART

business objectives, 41release criteria, 63

Smith, Larry, 42software

development tools. See tool adoptionindustry, best practices, 7management, 3metrics. See software metricsquality, 5–6, 62, 64–65. See also qualityrelease criteria. See release criteria, product

210 Software Development (CMP Media Inc.)

requirements, 95risks, 79–81

Software Development (CMP Media Inc.), 3n, 25n, 61n, 77n, 105n, 137n, 153n, 163n, 187n

Software Engineering Institute, 79Software Estimation (McConnell), 18Software Management (Reifer), 11nsoftware metrics, 20, 62

culture, measurement, creating, 156–57, 164–65

reasons for, 153–54tips for success, 157–58traps to avoid, 163–69vague, 166what to measure, 154–56worksheets for, 159, 161, 171, 173–74

sponsor, project, 98spreadsheet, for project prioritization, 33staff, as project dimension, 44–45staged delivery, 179stakeholders, 12

analysis, 42–43charter, 97, 103identifying, 42–44worksheet, 53

statement of work. See project charterstatic code analyzers, 106Stellman, Andrew, 138storming, group stage, 107success criteria, 12, 39–40

in project charter 97define business objectives (step 1), 40–42derive success criteria (step 4), 46–48identify project constraints (step 3), 44–46identify stakeholders and their interests

(step 2), 42–44sample, 47, 48worksheet, 57

support, product release criteria, 67–68symbolic recognition, 6

Ttask lists, Wideband Delphi method

final, 145individual, 140–42merging, 144–45

task(s)assembly, Wideband Delphi method, 144–45completion, 20

decomposing, 15–16estimation, Wideband Delphi method,

140–41lists. See task lists, Wideband Delphi methodwork estimations, 18worksheets for, 16

team membersas degree of freedom, 13job satisfaction, 12metrics for, 155, 156needs of, 3–4preparing, 194recognition of, 6–7resources, charter, 102roles, in project charter, 98selecting, 194tool adoption, 107training time, 18, 168turnover, 12Wideband Delphi method, 139, 140

technology drivers, 26technology enthusiasts market segment, 69templates. See also worksheets

action plan, 195commitment record, 123estimation form, Wideband Delphi

method, 141lessons learned, 182project charter, 96project management plan, 15, 41retrospective summary report, 192–93risk list, 85–86risk management plan, 82vision statement, 99

testing, 16as release criteria, 65–66

Theory-W management, 179time lines, retrospectives, 190timebox development, 179tool adoption, 105–8

CASE, 109–10culture and, matching, 110–11lessons learned from, 105–11worksheet for, 113, 115

toolsmetrics tracking, 157productivity and, 108quality and, 108vs. process, 106–7

tracking

Zultner, Richard E. 211

metric, 157progress, 20risks, 85

tradeoff matrix, 45tradeoffs, 44–45training, 18

lack of, 168tool adoption, 111

trends, data, 158

UUnified Modeling Language (UML), 109Ury, William, 120user requirements, 95

VVerner, June M., 179vision, in project charter, 98–99vision and scope document, 41, 94, 99. See also

project chartervisionaries market segment, 69Voas, Jeffrey, 44

Wwaiting times, estimates, 141, 142, 144Walsh, James, 65weighting factors for project prioritization,

27–28Weinberg, Jerry, 189Whitten, Neal, 192Wideband Delphi method, 19, 138–39

anonymity, 142, 144assumptions, 143, 144, 145completion, 145–46cone of uncertainty, 137–38estimation form, sample, 141estimation meeting, 142–44evaluation of method, 146kickoff meeting, 140planning stage, 139preparation, individual, 140–42results review, 145task assembly, 144–45

worksheet, 149Wiegers, Karl E., 3, 13, 17, 18, 41, 44, 45, 62,

65, 66, 99, 101, 109, 153, 156win-win objectives, 121work, estimating, 18–19work effort distribution metric, 156worksheets

achievable commitments, 127business objectives, 51good practices, 23lessons learned, 185metrics, 159, 161, 171, 173–74planning, 16prioritization, 33, 35project dimensions, 55release criteria, 73, 75responding to change, 59retrospectives, 197–98risk documenting, 91risk lists, 89stakeholders, 53success criteria, 57tool adoption, 113, 115Wideband Delphi, 149

worst practices for project management,180–81

Wysocki, Robert K., 40, 133

YYourdon-DeMarco analysis, 109

ZZultner, Richard E., 134

i

About the AuthorKarl E. Wiegers is Principal Consultant with Process Impact, a software process consulting and education company in Portland, Oregon. His interests include project manage-ment, requirements engi-neering, peer reviews, process improvement, risk management, and metrics. Previously, he spent 18 years at Eastman Kodak Company as a research scientist, software devel-oper, software manager, and software process and qual-ity improvement leader. Karl has a Ph.D. in organic chemistry from the University of Illinois.

In addition to Practical Project Initiation: A Handbook with Tools, Karl is the author of the books Software Requirements, 2nd Edition (Microsoft Press, 2003); More About Software Requirements (Microsoft Press, 2006); Peer Reviews in Software: A Practical Guide (Addison-Wesley, 2002); and Creating a Software Engineering Culture (Dorset House, 1996). Karl has written more than 170 articles on software development and management, chemistry, and military history. Karl has served on the Editorial Board for IEEE Software magazine and as a contributing editor for Software Development magazine. He is a frequent speaker at conferences and professional soci-ety meetings. When he isn’t in front of the keyboard, Karl is usually playing his guitars, drink-ing some wine, or reading about military history. You can reach Karl at www.processimpact.com.

practical project initiation - pearsoncmg.com€¦ · i “the wonderful—and scary—thing about...

Documents