What readers are saying about Man age It! As a 30+ year veteran in the growth of PM, I gained insight into things I have been doing for years. Here, process takes a backseat to context, and Johanna provides the professional with one of the finest com- pendiums of observations, advice, and counsel on managing projects I have come across. Mike Dwyer Sr. Manager, Strategic Initiatives, Healthways Johanna packs a wealth of practical advice into this book. Even the most experienced project managers will find numerous nuggets and gems that they can immediately apply to their project work. James A . Ward Sen ior Project Management Consultant, James A. Ward and Associates, Inc. As I was reading this book, I was picturing in my mind many simi- lar experiences. As I thought to myself, “But what about this?” I kept finding what I was thinking of! This is one of the best IT books I have ever read, but it still shows Johanna’s personality. It almost feels like she is at your elbow as you read it. Eric Petersen Sen ior Consultant, Emprove Most project management stuff I’ve read is very cerebral and theoret- ical, and then sometimes it’s extraordinarily specific and dictatorial but in a realm that has nothing to do with me. This book provides just what I need—specific suggestions about dealing with reality. Moreover, it suggests how to think about the problem, rather th an stopping at the cookbook answer. Peter Harris Solutions Architect, Claricode, Inc. This book is a pleasure to read and is packed with wisdom. Junior p r o ject managers will get a great introduction with some really valu- able practical advice, while senior project managers will learn some new tricks and relearn some forgotten fundamentals. Project spon- sors and customers should get a copy too. I pulled some classics from my shelves including DeMarco, Weinberg, Brooks, McConnell, Cock- burn, McCarthy, and Humphrey. Johanna is as readable as the best of them. George Hawthorne Pro ject Manager, Oblomov Consulting I’ve been on the receiving end of (mostly) poor project management for nearly twenty years. I had never entertained the thought of becoming a project manager, however, until I read this book. Johanna places the art in perspective and codifies a practical, flexible approach, founded on empirical process control theory that thrives on dynamic environments—where continuous learning is essential t o pr oject suc- cess. I’ve implored everyone associated with project work to read it. Twice. Bil Kleb Aer ospace Engineer In twenty years of managing projects, there have been many new items for project managers to consider. Johanna Rothman describes many of them in Manage I t! The chapter on meetings is worth the price of the book by itself. Read this book, and practice its principles. The people who work on your projects will th i nk you are really smart. Dwayne Phillips Sen ior Systems Engineer Each project is unique—which is why all project managers need to know more than one approach for managi ng projects. Johanna walks us through her thought process to assess the context around the project, choose a life cycle, and establish clear criteria for a project. Her advice will help you make choices that will help your project suc- ceed. Esther Derby Pre sident, esther derby associates, inc. Manage It! Your Guide to Modern, Pragmatic Project Management Johanna Rothman The P ragmatic Bookshelf Raleigh, North Carolina Dallas, Texas Many of the designations used by manufacturers and sellers to distinguish their prod- uct s are c l aimed as trademarks. Where those designations appear in this book, and The Pragmatic Programmers, LLC wa s aware of a trademark claim, the designations have been printed in initial capital letters or in all capitals. The Pragmatic Starter Kit, The Pragmatic Programmer, Pragmatic Programming, Pragmatic Bookshelf and the linking g device are trademarks of The Pragmatic Programmers, LLC. Every precaution was taken in the preparation of this book. However, the publisher assumes no responsibility for errors or omissi ons, or for damages that may result from the use of information (including program listings) contained herein. Our Pragmatic courses, workshops, an d other products can help you and your team create better software and have more fun. For more information, as well as the latest Pragmatic titles, please visit us at http://www.pragmaticprogrammer.com Copyright © 2 007 Johanna Rothman. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or tran smit- ted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior consent of the publisher. Printed in the United States of America. ISBN-10: 0-9787392-4-8 ISBN-13: 978-0-9787392-4-9 Printed on acid-free paper with 85% recycled, 30% post-consumer content. First printing, June 2007 Version: 2007-5-29 To Ilse Rothman, the fir st project manager I knew who worked in timeboxes and chunks. And for Naomi, Shaina, and Mark, who su pported me whenever I descended into my “ca ve” to wr i t e. Contents Foreword 12 Preface 14 1 Starting a Project 17 1.1 Define Projects and Project Managers . . . . . . . . . . 17 1.2 Manage Your Drivers, Constraints, and Floats . . . . . 19 1.3 Discuss Your Project Constraints with Your Client or Sponsor 2 2 1.4 Decide on a Driver for Your Project . . . . . . . . . . . . 23 1.5 Manage Sponsors Who Want to Over constrain Your Project 25 1.6 Write a Project Charter to Share These Decisions . . . 27 1.7 Know What Quality Means for Your Project . . . . . . . 30 2 Planning the Project 33 2.1 Start the Wheels Turning . . . . . . . . . . . . . . . . . 33 2.2 Plan Just Enough to Start . . . . . . . . . . . . . . . . . 34 2.3 Develop a Project Plan Template . . . . . . . . . . . . . 35 2.4 Define Release Criteria . . . . . . . . . . . . . . . . . . . 42 2.5 Use Release Criteria . . . . . . . . . . . . . . . . . . . . 47 3 Using Life Cycles to Design Your Project 50 3.1 Understanding Project Life Cycles . . . . . . . . . . . . 50 3.2 Overview of Life Cycles . . . . . . . . . . . . . . . . . . . 51 3.3 Seeing Feedback in the Project . . . . . . . . . . . . . . 55 3.4 Larger Projects Might Have Multiple Combinations of Life Cyc les 56 3.5 Managing Architectural Risk . . . . . . . . . . . . . . . 60 3.6 Paddling Your Way Out of a Waterfall . . . . . . . . . . 62 3.7 My Favorite Life Cycles . . . . . . . . . . . . . . . . . . . 63 CONTENTS 8 4 S c heduling the Project 64 4.1 Pragmatic Approaches to Project Scheduling . . . . . . 64 4.2 Select from These Scheduling Techniques . . . . . . . 66 4.3 Start Scheduling with a Low-Tech Tool . . . . . . . . . 69 5 Estimating the Work 77 5.1 Pragmatic Approaches to Project Estimation . . . . . . 77 5.2 Milestones Define Your Project’s Chunks . . . . . . . . 91 5.3 How Little Can You Do? . . . . . . . . . . . . . . . . . . 93 5.4 Estimating with Multitasking . . . . . . . . . . . . . . . 93 5.5 Scheduling People to Multitask by Design . . . . . . . . 94 5.6 Using Rolling-Wave Scheduling . . . . . . . . . . . . . . 95 5.7 Deciding on an Iteration Duration . . . . . . . . . . . . 96 5.8 Estimating Using Inch-Pebbles Wherever Possible . . . 98 6 Recognizing and Avoiding Schedule Games 101 6.1 Bring Me a Rock . . . . . . . . . . . . . . . . . . . . . . 101 6.2 Hope Is Our Most Important Strategy . . . . . . . . . . 104 6.3 Queen of Denial . . . . . . . . . . . . . . . . . . . . . . . 106 6.4 Sweep Under the Rug . . . . . . . . . . . . . . . . . . . 109 6.5 Happy Date . . . . . . . . . . . . . . . . . . . . . . . . . 111 6.6 Pants on Fire . . . . . . . . . . . . . . . . . . . . . . . . 113 6.7 Split Focus . . . . . . . . . . . . . . . . . . . . . . . . . . 115 6.8 Schedule Equals Commitment . . . . . . . . . . . . . . 117 6.9 We’ll Know Where We Are When We Get There . . . . . 119 6.10 The Schedule Tool Is Always Right . . . . . . . . . . . . 121 6.11 We Gotta Have It; We’re Toast Without It . . . . . . . . 124 6.12 We Can’t Say No . . . . . . . . . . . . . . . . . . . . . . 126 6.13 Schedule Chicken . . . . . . . . . . . . . . . . . . . . . . 128 6.14 90% Done . . . . . . . . . . . . . . . . . . . . . . . . . . 129 6.15 We’ll Go Faster Now . . . . . . . . . . . . . . . . . . . . 131 6.16 Schedule Trance . . . . . . . . . . . . . . . . . . . . . . 133 7 Creating a Great P roject Team 135 7.1 Recruit the People You Need . . . . . . . . . . . . . . . 135 7.2 Help the Team Jell . . . . . . . . . . . . . . . . . . . . . 137 7.3 Make Your Organization Work for You . . . . . . . . . . 140 7.4 Know How Large a Team You Need . . . . . . . . . . . . 143 7.5 Know When to Add More People . . . . . . . . . . . . . 145 7.6 Become a Great Project Manager . . . . . . . . . . . . . 145 7.7 Know When It’s Time to Leave . . . . . . . . . . . . . . 148 Report erratum t h i s copy is (First printing, June 2007) CONTENTS 9 8 S t eering the Project 156 8.1 Steer the Project with Rhythm . . . . . . . . . . . . . . 156 8.2 Conduct Interim Retrospectives . . . . . . . . . . . . . 157 8.3 Rank the Requirements . . . . . . . . . . . . . . . . . . 158 8.4 Timebox Requirements Work . . . . . . . . . . . . . . . 161 8.5 Timebox Iterations to Four or Fewer Weeks . . . . . . . 164 8.6 Use Rolling-Wave Planning and Scheduling . . . . . . . 165 8.7 Create a Cross-Functional Project Team . . . . . . . . 168 8.8 Select a Life Cycle Based on Your Project’s Risks . . . 169 8.9 Keep Reasonable Work Hours . . . . . . . . . . . . . . . 170 8.10 Use Inch-Pebbles . . . . . . . . . . . . . . . . . . . . . . 171 8.11 Manage Interruptions . . . . . . . . . . . . . . . . . . . 172 8.12 Manage Defects Starting at the Beginning of the Project 174 9 Maintaining P roject Rhythm 179 9.1 Adopt or Adapt Continuous Integration for Your Project 179 9.2 Create Automated Smoke Tests for the Build . . . . . . 181 9.3 Implement by Feature, Not by Architecture . . . . . . . 182 9.4 Get Multiple Sets of Eyes on Work Products . . . . . . 187 9.5 Plan to Refactor . . . . . . . . . . . . . . . . . . . . . . . 188 9.6 Utilize Use Cases, User Stories, Personas, and Scenarios to D efine Requirements 190 9.7 Separate GUI Design from Requirements . . . . . . . . 191 9.8 Use Low-Fidelity Prototyping as Long as Possible . . . 192 10 Managing Meetings 194 10.1 Cancel These Meetings . . . . . . . . . . . . . . . . . . . 194 10.2 Conduct These Types of Meetings . . . . . . . . . . . . 197 10.3 Project Kickoff Meetings . . . . . . . . . . . . . . . . . . 198 10.4 Release Planning Meetings . . . . . . . . . . . . . . . . 198 10.5 Status Meetings . . . . . . . . . . . . . . . . . . . . . . . 199 10.6 Reportin g Status to Management . . . . . . . . . . . . . 204 10.7 Project Team Meetings . . . . . . . . . . . . . . . . . . . 205 10.8 Iteration Review Meetings . . . . . . . . . . . . . . . . . 206 10.9 Troubleshooting Meetings . . . . . . . . . . . . . . . . . 206 10.10 Manage Conference Calls with Remote Teams . . . . . 208 11 Creating and Using a Project Dashboard 212 11.1 Measurements Can Be Dangerous . . . . . . . . . . . . 212 11.2 Measure Progress Toward Project Completion . . . . . 215 11.3 Develop a Project Dashboard f or Sponsors . . . . . . . 238 11.4 Use a Project Weather Report . . . . . . . . . . . . . . . 241 Report erratum t h i s copy is (First printing, June 2007) CONTENTS 10 1 2 Ma naging Multisite Projects 246 12.1 What Does a Question Cost You? . . . . . . . . . . . . . 247 12.2 Identify Your Project’s Cultural Differences . . . . . . . 248 12.3 Build Trust Among the Teams . . . . . . . . . . . . . . 249 12.4 Use Complementary Practices on a Team-by-Team Basis 252 12.5 Look for Potential Multisite Project and Multicultural Pro blems 260 12.6 Avoid These Mistakes When Outsourcing . . . . . . . . 262 13 Integrating Testing into the Project 265 13.1 Start People with a Mind-Set Toward Reducing Technical Debt 265 13.2 Reduce Risks with Small Tests . . . . . . . . . . . . . . 266 13.3 TDD Is the Easiest Way to Integrate Testing into Your Project 267 13.4 Use a Wide Variety of Testing Techniques . . . . . . . . 270 13.5 Define Every Team Member’s Testing Role . . . . . . . 273 13.6 What’s the Right Developer-to-Tester Ratio? . . . . . . 277 13.7 Make the Testing Concurrent w i th Development . . . . 283 13.8 Define a Test Strategy for Your Project . . . . . . . . . . 283 13.9 System Test Strategy Template . . . . . . . . . . . . . . 284 13.10 There’s a Difference Between QA and Test . . . . . . . 286 14 Managing Programs 288 14.1 When Your Project Is a Program . . . . . . . . . . . . . 288 14.2 Organizing Multiple Related Projects into One Release 289 14.3 Organizing Multiple Related Projects Over Time . . . . 291 14.4 Managing Project Managers . . . . . . . . . . . . . . . . 294 14.5 Creating a Program Dashboard . . . . . . . . . . . . . . 296 15 Completing a Project 298 15.1 Managing Requests for Early Release . . . . . . . . . . 298 15.2 Managing Beta Releases . . . . . . . . . . . . . . . . . . 299 15.3 When You Kn ow You Can’t Meet the Release Date . . . 300 15.4 Shepherding the Project to Completion . . . . . . . . . 308 15.5 Canceling a Project . . . . . . . . . . . . . . . . . . . . . 312 16 Managing the Project Portfolio 315 16.1 Build the Portfolio of All Projects . . . . . . . . . . . . . 315 16.2 Evaluate the Projects . . . . . . . . . . . . . . . . . . . . 317 16.3 Decide Which Projects to Fund Now . . . . . . . . . . . 318 16.4 Rank-Order the Portfolio . . . . . . . . . . . . . . . . . . 318 16.5 Start Projects Faster . . . . . . . . . . . . . . . . . . . . 319 16.6 Manage the Demand for New Features with a Product Backlog 321 16.7 Troubleshoot Portfolio Management . . . . . . . . . . . 323 Report erratum t h i s copy is (First printing, June 2007) [...]... decisions yourself Your project and the organization will benefit You can’t create project requirements that don’t fit inside the project constraints If you try, you have the problem of a ten-pound project in a five-pound project bag No matter what you try, you just don’t have enough people, time, money, or tools to release a product when management wants it, with the features management wants, and without too... the management team has talked to the chief architect about what’s possible and what’s not That’s part of the project, even if you don’t think it is part of the project Since the project starts before you think it does, don’t be worried about iterating on the project charter, the project plan, and the project schedule As a pragmatic project manager, you spend the first part of the project trying to wrap... TO S TAR T 2.2 Plan Just Enough to Start You’ve got a charter, but what is your plan? Your management still wants to have an idea of when you’ll deliver which features into the code base How will you measure progress? When will the project be done? Your plan does not have to be perfect In fact, there’s no way it can be Your plan only has to be good enough to start the project with a chance of success... Choose one item, say time to release That is what you identify as your driver What’s left on your list? You’ll see things such as feature set, low defects, and cost to release Which of the remaining items will you need to manage to make the project successful? Create a hierarchy with these concerns being a little less critical to the success of your project than the driver Your customers’ expectations and... future are not good You must take advantage of all practices and techniques to reduce your project s risk, including considering agile techniques for every project This book is a risk-based guide to making good decisions about how to plan and guide your projects It will help software project managers, team members, and software managers succeed Much of the information also applies if you are building... project like that before! But now that I know, I can figure out how to do this 1.6 Write a Project Charter to Share These Decisions A project charter identifies the project requirements and constraints, and it helps a project manager decide how to design the project The charter is the one place the entire project team and the sponsors can visit to make sure they all agree on the decisions about the project. .. by a project manager Wideman says that a project manager “heads up the project team and is assigned the authority and responsibility for conducting the project and meeting project objectives through project management. ”2 That’s great as a formal definition But here’s a working definition you might find more ambiguous and, at the same time, more accurate: Project manager: The person whose job it is to articulate... that was all there was to it, anyone could be a project manager First, write down your customers’ expectations—what’s driving the project from your customers’ perspective [Rot98] Your list includes what your customers expect (the feature set), when they will receive it (time to release), and how good it is (defect levels) [Gra92] Next, write down the constraints you are under What’s your environment like?... reluctant to decide In this case, make the decisions and show them to your sponsor She might be more willing to correct your rankings or sign off on them than to create her own You have a couple more approaches: to imagine the future and to use context-free questions to elicit what’s really driving your project Report erratum this copy is (First printing, June 2007) 25 M ANAGE S PONSORS W HO WANT TO O VERCONSTRAIN... between you and your sponsor Use these questions as a starting point in the conversation The more information you gather at the beginning about the project s value to the sponsor, the more you’ll understand how to design the project What Does Success Look Like? by Justin, project manager I’m a couple of months into managing a two -to- three-year project, when my boss comes to me and says he wants to add a feature . every project. This book is a risk-based guide to making good decisions about how to plan and guide your projects. It will help software project managers, team. Driver for Your Project . . . . . . . . . . . . 23 1.5 Manage Sponsors Who Want to Over constrain Your Project 25 1.6 Write a Project Charter to Share These