FOR DUMmIES - The Eye Various/For.Dummies... · · 2017-09-26Teresa earned her Project Management Professional Certification through the ... Using Earned Value Management in Software

Software ProjectManagement

FOR

DUMmIES

by Teresa Luckey, PMP, MBA, and Joseph Phillips, PMP

01_749346 ffirs.qxp 8/30/06 10:15 PM Page i

File AttachmentC1.jpg

Software ProjectManagement

FOR

DUMmIES

by Teresa Luckey, PMP, MBA, and Joseph Phillips, PMP


Software Project Management For Dummies

Published byWiley Publishing, Inc.111 River StreetHoboken, NJ 07030-5774www.wiley.com

Copyright 2006 by Wiley Publishing, Inc., Indianapolis, Indiana

Published by Wiley Publishing, Inc., Indianapolis, Indiana

Published simultaneously in Canada

No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form orby any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permit-ted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior writtenpermission of the Publisher, or authorization through payment of the appropriate per-copy fee to theCopyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600.Requests to the Publisher for permission should be addressed to the Legal Department, Wiley Publishing,Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4355, or online athttp://www.wiley.com/go/permissions.

Trademarks: Wiley, the Wiley Publishing logo, For Dummies, the Dummies Man logo, A Reference for theRest of Us!, The Dummies Way, Dummies Daily, The Fun and Easy Way, Dummies.com, and related tradedress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates in the UnitedStates and other countries, and may not be used without written permission. All other trademarks are theproperty of their respective owners. Wiley Publishing, Inc., is not associated with any product or vendormentioned in this book.

LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY: THE PUBLISHER AND THE AUTHOR MAKE NO REP-RESENTATIONS OR WARRANTIES WITH RESPECT TO THE ACCURACY OR COMPLETENESS OF THECONTENTS OF THIS WORK AND SPECIFICALLY DISCLAIM ALL WARRANTIES, INCLUDING WITHOUTLIMITATION WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE. NO WARRANTY MAY BE CRE-ATED OR EXTENDED BY SALES OR PROMOTIONAL MATERIALS. THE ADVICE AND STRATEGIES CON-TAINED HEREIN MAY NOT BE SUITABLE FOR EVERY SITUATION. THIS WORK IS SOLD WITH THEUNDERSTANDING THAT THE PUBLISHER IS NOT ENGAGED IN RENDERING LEGAL, ACCOUNTING, OROTHER PROFESSIONAL SERVICES. IF PROFESSIONAL ASSISTANCE IS REQUIRED, THE SERVICES OF ACOMPETENT PROFESSIONAL PERSON SHOULD BE SOUGHT. NEITHER THE PUBLISHER NOR THEAUTHOR SHALL BE LIABLE FOR DAMAGES ARISING HEREFROM. THE FACT THAT AN ORGANIZATIONOR WEBSITE IS REFERRED TO IN THIS WORK AS A CITATION AND/OR A POTENTIAL SOURCE OF FUR-THER INFORMATION DOES NOT MEAN THAT THE AUTHOR OR THE PUBLISHER ENDORSES THE INFOR-MATION THE ORGANIZATION OR WEBSITE MAY PROVIDE OR RECOMMENDATIONS IT MAY MAKE.FURTHER, READERS SHOULD BE AWARE THAT INTERNET WEBSITES LISTED IN THIS WORK MAY HAVECHANGED OR DISAPPEARED BETWEEN WHEN THIS WORK WAS WRITTEN AND WHEN IT IS READ.

For general information on our other products and services, please contact our Customer CareDepartment within the U.S. at 800-762-2974, outside the U.S. at 317-572-3993, or fax 317-572-4002.

For technical support, please visit www.wiley.com/techsupport.

Wiley also publishes its books in a variety of electronic formats. Some content that appears in print maynot be available in electronic books.

Library of Congress Control Number: 2005935165

ISBN-13: 978-0-471-74934-9

ISBN-10: 0-471-74934-6

Manufactured in the United States of America

10 9 8 7 6 5 4 3 2 1

1B/RZ/QZ/QW/IN

01_749346 ffirs.qxp 8/30/06 10:15 PM Page ii

www.wiley.com

About the AuthorsTeresa Luckey was born in Indianapolis, Indiana, the eighth of twelve children.She earned the degree of Bachelor of Science from the University of SouthernIndiana, with a major in Education. She earned her teaching endorsements inComputer Education and Mathematics from the University of Indianapolisand thoroughly enjoyed teaching (and learning from) junior high students forseveral years. After deciding to expand her horizons beyond the teachingprofession, she pursued her interests in information systems and projectmanagement while working at hospitals in Indianapolis, and then moved onto a consulting firm, where she now works as a manager implementing health-care systems. Teresa earned her Master of Business Administration degreefrom Indiana Wesleyan University, where she served as co-class presidentwith her husband, David. She is just shy of completing her Master of Science inNew Media at Indiana University School of Informatics. One of these days soon she hopes to finish that degree so that she can maintain her reputationas a life-long learner.

Teresa earned her Project Management Professional Certification through theProject Management Institute in 2001 and continues to maintain her certifica-tion. She enjoys contributing to the field of project management, particularlywith regard to healthcare software.

Teresa takes pleasure in spending time with her family especially her husband David and their children, Amanda, Sara, and Adam. Being a firmbeliever in the axiom that theres more to life than work, Teresa and herfamily are passionate about traveling and exploring all types of music.

01_749346 ffirs.qxp 8/30/06 10:15 PM Page iii

Joseph Phillips, PMP, Project+, is the Director of Education for ProjectSeminars. He has managed and consulted on projects for various industries,including technical, pharmaceutical, manufacturing, and architectural, amongothers.

Phillips has served as a project management consultant for organizations cre-ating project offices, maturity models, and best-practice standardization.

As a leader in adult education, Phillips has taught organizations how to successfully implement project management methodologies, informationtechnology project management, risk management, and other courses.Phillips has taught courses at Columbia College, University of Chicago,Indiana University, and others. He is a Certified Technical Trainer and hastaught over 10,000 professionals. Phillips has contributed as an author oreditor to more than 30 books on technology, careers, and project management.

Phillips is a member of the Project Management Institute and is active in local project management chapters. He has spoken on project management,project management certifications, and project methodologies at numeroustrade shows, PMI chapter meetings, and employee conferences. When notwriting, teaching, or consulting, Phillips can be found behind a camera or on the working end of a fly rod. You can contact Phillips through www.projectseminars.com.

01_749346 ffirs.qxp 8/30/06 10:15 PM Page iv

DedicationI dedicate this effort to David, Amanda, Sara, and Adam Luckey.

Authors AcknowledgmentsTeresa Luckey: Thanks to Kevin Kirschner, Editorial Manager, for his confi-dence in me and for providing me with this opportunity. I appreciate KatieFeltman, Acquisitions Editor, for her diligence in bringing this book to fruitionand for her patience in gracefully answering all of my questions. Nicole Haims,Project Editor, provided a great deal of guidance and support to me and I amgrateful to her for her efforts. Ed Kirschner, thanks for your ideas and input,and most of all thank you to David, Amanda, Sara, and Adam Luckey for yourunrelenting support throughout this and all endeavors.

Joe Phillips: Books, like projects, are never done alone.

Thank you to Teresa Luckey for her hard work and incredible input onthis project. A humongous thank you to Katie Feltman and all the folks atFor Dummies for their patience and persistence. I would also like to thank thehundreds of folks who have attended my PMP Boot Camps. Your questions,conversations, and recommendations have helped me write a better book.

Finally, thank you to Elizabeth Lee, Rick Gordon, Scot Conrad, Phil Stuck, andmy son, Kyle.

Both authors would like to recognize and thank Cynthia Snyder and KarenScott for being conscientious and thorough while reviewing this book.

01_749346 ffirs.qxp 8/30/06 10:15 PM Page v

Publishers AcknowledgmentsWere proud of this book; please send us your comments through our online registration formlocated at www.dummies.com/register/.

Some of the people who helped bring this book to market include the following:

Acquisitions, Editorial, and Media Development

Project Editor: Nicole Haims

Acquisitions Editor: Katie Feltman

Technical Editors: Cynthia Snyder and Karen Scott

Editorial Manager: Jodi Jensen

Media Development Manager:Laura VanWinkle

Editorial Assistant: Amanda Foxworth

Sr. Editorial Assistant: Cherie Case

Cartoons: Rich Tennant(www.the5thwave.com)

Composition Services

Project Coordinator: Jennifer Theriot

Layout and Graphics: Claudia Bell, Carl Byers,Lauren Goddard, Lynsey Osborn,Heather Ryan, Julie Trippetti

Proofreaders: David Faust, Jessica Kramer,Techbooks

Indexer: Techbooks

Publishing and Editorial for Technology Dummies

Richard Swadley, Vice President and Executive Group Publisher

Andy Cummings, Vice President and Publisher

Mary Bednarek, Executive Acquisitions Director

Mary C. Corder, Editorial Director

Publishing for Consumer Dummies

Diane Graves Steele, Vice President and Publisher

Joyce Pepple, Acquisitions Director

Composition Services

Gerry Fahey, Vice President of Production Services

Debbie Stailey, Director of Composition Services

01_749346 ffirs.qxp 8/30/06 10:15 PM Page vi

www.dummies.com

Contents at a GlanceIntroduction .................................................................1

Part I: Starting Your Software Project ............................7Chapter 1: Examining the Big Picture of Project Management.....................................9Chapter 2: Initiating a Software Project.........................................................................25Chapter 3: Creating the Software Scope........................................................................55

Part II: Planning Your Software Project........................77Chapter 4: Planning for Communications .....................................................................79Chapter 5: Planning for Software Project Risks..........................................................107Chapter 6: Planning for Software Quality ....................................................................131Chapter 7: Building the Project Team..........................................................................147Chapter 8: Creating Project Time Estimates ...............................................................165Chapter 9: Building Your Project Budget ....................................................................191

Part III: Executing Your Software Project Plan ............209Chapter 10: Working the Project Plan..........................................................................211Chapter 11: Working with Project People....................................................................229Chapter 12: Procuring Goods and Services ................................................................245

Part IV: Controlling Your Software Project ..................263Chapter 13: Managing Changes to the Software Project ...........................................265Chapter 14: Using Earned Value Management in Software Projects ........................281Chapter 15: Tracking Project Performance.................................................................295

Part V: Closing Your Software Project.........................313Chapter 16: Finalizing the Project Management Processes ......................................315Chapter 17: Documenting Your Software Project.......................................................333

Part VI: The Part of Tens ...........................................347Chapter 18: Ten Ways to Make Your Software Project Crash and Burn ..................349Chapter 19: Ten Ways to Make Any Software Project Better ....................................359

Appendix: Formal Project Management Training and Certification .........................................369

Index .......................................................................375

02_749346 ftoc.qxp 8/30/06 10:22 PM Page vii

02_749346 ftoc.qxp 8/30/06 10:22 PM Page viii

Table of ContentsIntroduction..................................................................1

About This Book...............................................................................................1Who Should Read This Book?.........................................................................2How This Book Is Organized...........................................................................3

Part I: Starting Your Software Project ..................................................3Part II: Planning Your Software Project................................................3Part III: Executing Your Software Project Plan....................................4Part IV: Controlling Your Software Project..........................................4Part V: Closing Your Software Project..................................................4Part VI: The Part of Tens .......................................................................5Appendix .................................................................................................5

Icons Used in This Book..................................................................................5Where to Go from Here....................................................................................6

Part I: Starting Your Software Project .............................7

Chapter 1: Examining the Big Picture of Project Management . . . . . .9Defining Software Projects ............................................................................10Defining Software Project Management ......................................................10Comparing Projects and Operations ...........................................................12Examining Project Constraints .....................................................................13Understanding Universal Constraints (Time, Cost, and Scope) ..............13

Managing time constraints..................................................................15Managing cost constraints ..................................................................16Managing the scope .............................................................................16

Controlling Scope Creep................................................................................17Making Sense of Project Success (Or Failure) ............................................18Starting and Finishing Software Projects ....................................................19Understanding What Makes Software

Project Management So Special................................................................20Breaking Moores Law..........................................................................21Dealing with Moore ..............................................................................21Dealing with the first-time, first-use penalty.....................................23

Chapter 2: Initiating a Software Project . . . . . . . . . . . . . . . . . . . . . . . . .25Identifying the Project Purpose....................................................................25

Talking to the stakeholders.................................................................26Reaching project consensus ...............................................................30

02_749346 ftoc.qxp 8/30/06 10:22 PM Page ix

Dealing with Politics ......................................................................................31Moving from Here to There...........................................................................32

Initiating the project ............................................................................34Planning the project.............................................................................36Examining project planning approaches...........................................37Executing the project...........................................................................38Controlling the project ........................................................................38Closing the project ...............................................................................38

Living with Stakeholders...............................................................................39Loving your project team ....................................................................39Loving your project sponsor ..............................................................40Balancing stakeholder expectations..................................................40

Completing a Project Feasibility Study .......................................................42What feasibility studies do (and dont do) .......................................43Finding a feasibility consultant...........................................................43

Understanding How Executives Select Projects.........................................44Using the benefit comparison selection model ................................45Using a scoring model .........................................................................46Facing a murder board.........................................................................46Finding a projects ROI.........................................................................46

Writing the Product Description ..................................................................49Making Your Project Wish List .....................................................................51

Finding the ideal tools .........................................................................51Building a dream team.........................................................................52Finding a preferred vendor .................................................................53

Recognizing Doomed Projects......................................................................54

Chapter 3: Creating the Software Scope . . . . . . . . . . . . . . . . . . . . . . . . .55Understanding Product Scope and Project Scope.....................................56

Completing stakeholder analysis .......................................................56Interviewing stakeholders now to avoid surprises later.................57

Managing Stakeholder Objectives................................................................58Knowing the sources of common conflicts.......................................58Resolving common conflicts...............................................................60

Building the Software Scope .........................................................................61Dealing with regulations and options ................................................62Dealing with project constraints ........................................................64Getting to the signature.......................................................................66

Creating the Project Scope ...........................................................................67Knowing what the project scope statement must include .............68What a project scope doesnt include ...............................................70

Creating a Work Breakdown Structure ........................................................70Creating your very own WBS ..............................................................71Making updates to the WBS ................................................................73Using a code of accounts.....................................................................73

Software Project Management For Dummies x

02_749346 ftoc.qxp 8/30/06 10:22 PM Page x

Part II: Planning Your Software Project ........................77

Chapter 4: Planning for Communications . . . . . . . . . . . . . . . . . . . . . . . .79The Importance of Communicating Effectively..........................................80

Ensuring accurate communication ....................................................80How not to communicate ....................................................................82

Care and Feeding of Nerds ............................................................................83Avoiding Communication Breakdowns .......................................................85

Facing the risks of communication meltdowns................................85Managing communications across the enterprise ...........................87

Calculating the Communication Channels..................................................88Building an Effective Communication Management Plan .........................91

Knowing the six things every communication plan needs .............91The communication responsibility matrix: Determining

who communicates to whom ..........................................................93Setting up ten-minute meetings..........................................................94

Defining Who Needs What Information.......................................................96What executives want to hear ............................................................96What functional managers need to hear ...........................................97What your project team needs to hear..............................................98What you need to hear ........................................................................99

Defining When Communication Is Needed ...............................................100Creating a communication schedule ...............................................100Hosting team and stakeholder meetings.........................................102

Defining Communication Modalities .........................................................104Modalities for formal communication .............................................104Modalities for informal communication..........................................105Automating communications............................................................105

Chapter 5: Planning for Software Project Risks . . . . . . . . . . . . . . . . .107Identifying Pure and Business Risks..........................................................108

Dealing with pure risks in software projects ..................................109Assessing business risks ...................................................................109Accepting everyday technology risks

with your software project ............................................................110Determining Stakeholder Risk Tolerance..................................................111Mitigating Risks Early On ............................................................................112Managing Risks in Your Organization........................................................113

Identifying risks ..................................................................................113Ranking risks.......................................................................................114

Relying on Quantitative Analysis ...............................................................116Creating a Contingency Reserve ................................................................117Using Software Models for Risk Management ..........................................118

Using the waterfall model..................................................................119Using the spiral model.......................................................................121

xiTable of Contents

02_749346 ftoc.qxp 8/30/06 10:22 PM Page xi

Using the V model ..............................................................................123Using the scrum development model..............................................124

Preparing a Risk Response Plan.................................................................126Avoiding risks .....................................................................................127Transferring risks ...............................................................................128Mitigating risks ...................................................................................128Accepting the risks.............................................................................129

Examining Risk Responses and Impacts ...................................................129Handling the ripple effect of risk response.....................................130Getting to say, I told you so! ..........................................................130

Chapter 6: Planning for Software Quality . . . . . . . . . . . . . . . . . . . . . . .131Defining Quality............................................................................................131

Referring to the product scope ........................................................132Referring to the project scope..........................................................133Avoiding gold-plated software ..........................................................134Examining quality versus grade .......................................................135

Working with a Quality Policy ....................................................................136Working ISO programs .......................................................................137Getting a Total Quality Management workout................................137Slipping into the sixth sigma.............................................................140Using homegrown, in-house quality solutions ...............................142

Balancing Time, Cost, and Quality.............................................................142Examining optimal quality ................................................................143Considering quality when making changes ....................................144

Chapter 7: Building the Project Team . . . . . . . . . . . . . . . . . . . . . . . . . .147Determining Your Project Needs................................................................148

Revisiting the work breakdown structure.......................................148Creating a roles and responsibilities matrix ...................................148

Finding the Talent ........................................................................................152Asking the Right Questions (In the Right Way) ........................................152

Asking questions that facilitate resource management ................153Asking questions that facilitate leadership potential....................154Finding a star ......................................................................................155Working with organizational structures ..........................................155

Determining Who Is Really in Charge ........................................................156Functioning in a functional organization.........................................157Mixing it up in a matrix......................................................................158Prospering in the projectized structure ..........................................159Cooling in a composite structure .....................................................161

Hosting Your First Project Team Meeting .................................................161Working with Organizational Policies........................................................162

Chapter 8: Creating Project Time Estimates . . . . . . . . . . . . . . . . . . . . .165Organizing Information Before You Build a Timeline ..............................166Understanding the Importance of a Project Network Diagram..............166

Software Project Management For Dummies xii

02_749346 ftoc.qxp 8/30/06 10:22 PM Page xii

Preparing to Create Your PND ....................................................................168Determining What May Happen and When ................................168Factoring in external dependencies.................................................170Putting together all the pieces..........................................................170Relying on network templates ..........................................................171Identifying subnets and fragnets ......................................................172

Using Historical Information to Complete Inexact Activity Time Estimates .............................................................172

Identifying Activity Duration Influencers..................................................173Documenting project assumptions ..................................................173Documenting project constraints ....................................................173Considering the project risks............................................................174Considering resource requirements and capabilities....................175Anticipating the first-time, first-use penalty ...................................176

Making the Project Duration Estimate ......................................................176Creating a rough order of magnitude estimate...............................177Creating an analogous estimate .......................................................177Creating a parametric estimate ........................................................178

Estimating Dos and Donts .........................................................................178Using PERT for the Most Accurate Estimates ..........................................179Knowing What to Say if the Boss Wants an Estimate Now .....................180Understanding the Way PND Paths Interact.............................................181

Calculating the critical path..............................................................181Calculating float..................................................................................182Applying float to the project.............................................................184

Creating the Project Schedule ....................................................................185Working with the project calendar...................................................185Working with a resource calendar....................................................186Using resource-leveling heuristics ...................................................187Crashing and fast tracking your project..........................................188

Chapter 9: Building Your Project Budget . . . . . . . . . . . . . . . . . . . . . . .191Creating Cost Estimates ..............................................................................191

Using the right resources (and using them wisely) .......................192Creating a rough estimate .................................................................193Creating a budget estimate ...............................................................194Creating a definitive estimate ...........................................................194

Creating an Accurate Estimate ...................................................................195Considering Project Profitability................................................................197Planning for Contingencies .........................................................................198Controlling Project Costs ............................................................................199

Understanding accounting blue dollars ..........................................199Understanding work-for-hire accounting ........................................199Following simple strategies to manage project expenses.............200

Having More Project than Cash..................................................................202Completing root cause analysis .......................................................203Reducing the project scope ..............................................................205Begging for cash .................................................................................206

xiiiTable of Contents

02_749346 ftoc.qxp 8/30/06 10:22 PM Page xiii

Recognizing Budgetary Problems Before You Get to the Root Cause Analysis Stage ....................................................207

Dealing with a Budget Problem that Your Bosses Know about (But Havent Addressed) ...................................................208

Part III: Executing Your Software Project Plan.............209

Chapter 10: Working the Project Plan . . . . . . . . . . . . . . . . . . . . . . . . . .211Authorizing the Project Work .....................................................................211

Creating a work authorization system.............................................212Using a project management information system .........................212

Ensuring Quality in Execution ....................................................................213Understanding the Interoperability

of the Quality Management Plan ............................................................216Following Quality Assurance ......................................................................217Following the Quality Policy.......................................................................218Managing Software Project Risks ...............................................................219

Gathering the ingredients for a solid risk management plan .......220Examining typical risks......................................................................221Getting a plan together ......................................................................221Gathering information to identify real risks ...................................222

Monitoring and Controlling Risks ..............................................................224Managing Secondary and Residual Risks..................................................225Documenting Risk Management Effectiveness.........................................226

Chapter 11: Working with Project People . . . . . . . . . . . . . . . . . . . . . .229Examining the Phases of Team Development...........................................229

Understanding the life cycle of a typical project team..................230Making a team out of a group of people ..........................................232Training the project team..................................................................232

Doing Some Fun Team-Building Exercises ................................................233Managing Project Conflicts .........................................................................234

Dealing with stakeholders.................................................................235Dealing with project team members................................................236Documenting project conflicts and resolutions .............................237

Using Your Super Magic Project Manager Powers...................................238Forcing a decision ..............................................................................238Relying on expert power ...................................................................239Using coercive power ........................................................................240Rewarding the project team..............................................................242

You and Your Positional Power ..................................................................243

Chapter 12: Procuring Goods and Services . . . . . . . . . . . . . . . . . . . . .245Finding a Vendor ..........................................................................................246

Using RFIs to solicit vendors ............................................................247Hosting a bidders conference..........................................................248

Software Project Management For Dummies xiv

02_749346 ftoc.qxp 8/30/06 10:22 PM Page xiv

A day in the life of a bidders conference........................................248Setting up criteria for RFPs ...............................................................249

Selecting the Vendor....................................................................................250Considering market conditions ........................................................250Using a screening system ..................................................................251Using the help of others ....................................................................251Implementing a weighting system....................................................252

Negotiating for the Best Solution ...............................................................253Starting with price..............................................................................253Considering time, cost, and quality issues .....................................254

Administering Contracts .............................................................................255Selecting the contract type ...............................................................256Writing the terms and conditions ....................................................256Creating the statement of work ........................................................258Solving problems and compromising ..............................................259

Closing the Vendor Contract ......................................................................260Auditing the goods and services......................................................261Signing off for the procured goods and services ...........................261

Part IV: Controlling Your Software Project...................263

Chapter 13: Managing Changes to the Software Project . . . . . . . . . .265Introducing the Controlling Process Group..............................................266Controlling the Project Scope.....................................................................266

Examining the project scope ............................................................267Creating and following a change control system ...........................269Determining the value of the proposed change .............................271Correcting mistakes ...........................................................................271

Controlling Project Costs ............................................................................272Managing project cost variances .....................................................273Estimating the cost of change...........................................................274Forecasting variance..........................................................................274

Controlling the Project Schedule ...............................................................275Managing project time variances .....................................................275Estimating impact of change on the project schedule ..................277Forecasting schedule variances .......................................................278

Chapter 14: Using Earned Value Management in Software Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .281

Defining Earned Value Management ..........................................................281Understanding what earned value is (and isnt) ............................282Discovering the other pieces of the EV formula ............................282Determining a projects worth..........................................................283

Discovering the Earned Value Management Formulas............................284

xvTable of Contents

02_749346 ftoc.qxp 8/30/06 10:22 PM Page xv

Playing with Values ......................................................................................286Calculating your PV............................................................................286Calculating earned value ...................................................................287Calculating your AC ...........................................................................287Creating a new EAC ............................................................................288Determining the estimate to complete the project........................289Uh-oh! Whats your variance? ...........................................................289Finding your cost and schedule performance indexes .................292

Chapter 15: Tracking Project Performance . . . . . . . . . . . . . . . . . . . . . .295Planning Project Metrics .............................................................................296

Establishing project goals .................................................................296Planning for project metrics .............................................................297Determining realistic project milestones ........................................298

Implementing a Tracking Plan ....................................................................298Using project baselines......................................................................299Stressing accuracy in reporting........................................................300Using a Project Management Information System .........................302

Tracking Project Performance....................................................................302Using earned value management .....................................................303Creating Pareto charts.......................................................................303Creating control charts......................................................................306

Communicating Project Performance .......................................................308Relying on the communication management plan.........................308Automating project communications ..............................................309Hosting status meetings ....................................................................310Sharing good and bad news ..............................................................311

Part V: Closing Your Software Project .........................313

Chapter 16: Finalizing the Project Management Processes . . . . . . .315Closing the Software Project.......................................................................315

Completing quality control ...............................................................317Completing scope verification..........................................................318

Closing Out Vendor Contracts....................................................................319Auditing vendors work and deliverables .......................................320Paying the bills ...................................................................................322

Completing the Project (Or at Least Transferring It to Someone Else)............................................................322

Celebrating! .........................................................................................324Releasing project team members from the project team..............325

Case Study: Completing a Project Post Mortem ......................................328

Software Project Management For Dummies xvi

02_749346 ftoc.qxp 8/30/06 10:22 PM Page xvi

Chapter 17: Documenting Your Software Project . . . . . . . . . . . . . . . .333Using Teamwork When Writing Documentation ......................................334Completing the Lessons Learned Documentation...................................335

Getting your historical information together at the beginning of a project .........................................................336

Creating a lessons learned spreadsheet at the beginning of the project......................................................336

Organizing Your Lessons Learned Document ..........................................338Organizing the summary of your document...................................338Organizing the meat of the document .............................................339Organizing your references, contributors, and resources ............339Documenting the projects successes .............................................340Documenting the projects failures ..................................................340Documenting the better approach...................................................341Offering advice for future project managers...................................341

Creating the User Manual and Help System .............................................342Using the project scope as a reference............................................343Establishing operational transfer.....................................................343Avoiding helpless help systems .......................................................346

Part VI: The Part of Tens............................................347

Chapter 18: Ten Ways to Make Your Software Project Crash and Burn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .349

Failing to Plan ...............................................................................................349Ignoring Risk Management..........................................................................350Letting Your Ego Lead the Project .............................................................351Letting Your Iron Triangle Melt ..................................................................352Hiding from the Project Team.....................................................................353Hovering over the Project Team ................................................................353Creating Unrealistic Schedules...................................................................354Consistently Being Inconsistent.................................................................355Doing Nothing...............................................................................................356Being a Wimp ................................................................................................357

Chapter 19: Ten Ways to Make Any Software Project Better . . . . . .359Asking the Right Questions.........................................................................359Being a Good Communicator......................................................................360Showing Your Leadership Skills .................................................................361Creating the Right Project Plan ..................................................................361Finding the Correct Sponsor.......................................................................362

xviiTable of Contents

02_749346 ftoc.qxp 8/30/06 10:22 PM Page xvii

Recognizing Failure Before It Arrives ........................................................363Planning, Planning, and a Little More Planning........................................364Documenting Your Project Even if You Dont Want To............................365Hosting a Successful Project Meeting........................................................365Establishing Project Rules Before the Project Begins .............................367Communicating Good and Bad News ........................................................367

Appendix: Formal Project Management Training and Certification ..........................................369

Getting Up Close and Personal with the Project Management Institute ...........................................................369

Finding Out Whether the Project Management Professional Certification Is for You ......................................................370

Understanding what a PMP certification says to others...............371Understanding what the PMP certification gets you .....................371Getting started....................................................................................372

What Is the CAPM Certification? ................................................................373Deciding between the PMP and the CAPM ...............................................374

Index........................................................................375

Software Project Management For Dummies xviii

02_749346 ftoc.qxp 8/30/06 10:22 PM Page xviii

Introduction

Welcome to Software Project Management For Dummies; we hope youenjoy the ride as we take you through scenic highways dotted withthe hues and shades of software project management concepts, project teamdevelopment, and various descriptions of fascinating new terminology.

Were two experienced software project managers, and we wrote this bookbecause we want you to benefit from the lessons weve learned through yearsof experience. You dont have to suffer to be a success. You just have tofollow our example.

About This BookThe purpose of this book is to assist you in understanding and using softwareproject management concepts. We want to pique your curiosity about someof the project management topics and processes and provide you with sometips on communicating project information to team members, executives,clients, and other important stakeholders. With the help of this book, you candevelop high-performing project teams who complete projects on time andunder budget. Not only that, with the help of Software Project Management ForDummies, we hope that youll cultivate high-performing teams who respectyour authority and believe in your abilities, even though you sometimesmake them work overtime.

This book isnt intended to be a complete reference for discovering every-thing there is to know about software project management. Its also notintended to be your sole source of information if youre preparing for yourPMP certification (for that you might want to check out PMP Certification ForDummies by Peter Nathan Gerald Everett Jones and published by our friendsat Wiley).

Were ambitious, but not unrealistic, and we know that project managementof any type is a little bit of an art and involves a lot of practice. There is somuch more to know that this book would have ended up being as big as, well,as big as something thats really big. Its not that we necessarily excludedanything from this book, but we touched on some topics at a high level for

03_749346 intro.qxp 8/30/06 10:16 PM Page 1

the sake of practicality. We discuss quality management for example, but vol-umes upon volumes have been written on just that one topic, so we couldntgive you every bit of information just the information you need to get thejob done and get on to the next task.

To find out more about software project management and project manage-ment in general, or to study for your PMP certification, you may want to checkout Software Project Management Kit For Dummies by Greg Mandanis and AllenWyatt. We also personally reread many times PMP: Project ManagementProfessional Study Guide, 3rd Edition, by Kim Heldman (Wiley). AlthoughHeldmans book is written in a different format and follows a different flowthan the PMP bible, Guide to the Product Management Body of Knowledge(PMI), it contains the same information and its a good companion to theGuide to the PMBOK.

Who Should Read This Book?So youve just picked up this treasure in the bookstore and youre looking itover trying to decide whether its the book for you. Well, this book is defi-nitely for you if you are

An experienced software project manager who is interested in improvingyour skills and finding out a little bit more from other experienced soft-ware project managers perspectives.

An experienced general project manager who is moving into softwareproject management (or maybe youve been thrust into software projectmanagement without a lot of time to prepare).

Just starting to get to know the discipline of project management anddeciding whether you should move in the direction of software projectmanagement.

An ambitious project team member who has become an ad-hoc projectmanager because your boss isnt showing enough leadership.

Not involved in a project management career at all, but contemplatingsoftware project management as an alternative.

So, whether or not you are currently a project manager or software projectmanager, actively working on a project team, or completely in the dark aboutthis mysterious field, this book has something for you. If youre experienced,youre bound to discover a new method for handling a situation, and if youredeciding whether or not to delve into the field of software project manage-ment, this book may help you make that significant decision.

2 Software Project Management For Dummies

03_749346 intro.qxp 8/30/06 10:16 PM Page 2

How This Book Is OrganizedThis book contains six major parts. Each part contains several chapters. Lookat the Table of Contents and decide which areas are of most interest to you. Orskim through the index for a keyword or term that you want information about.

This book was written in a format that coincides with the natural progressionof a software project, from planning stages until the very end. However, itsnot absolutely imperative that you read all of the chapters in order. Feel freeto skip to and fro. All projects move at their own pace and have their ownunique challenges, so some chapters might have more relevant informationfor you right now than others. We do think you should start at Chapter 1before you move forward, and if you never deal with creating software pro-ject budgets, you can safely skip Chapter 9. If youre not working with ven-dors or contracts, you could also safely skip Chapter 12. Some projectmanagers on smaller projects might not have to worry about earned valuemanagement, so skip Chapter 14 with a clear conscience if you dont need toknow about this topic.

Part I: Starting Your Software ProjectPart I introduces you to those elements of software project management thatare the foundation upon which you construct the remaining phases of yoursoftware project. All the other chapters in the book are based on the con-cepts contained within Part I.

Part II: Planning Your Software ProjectPart II introduces you to the basic concepts and essential elements of creat-ing your software project plans. You discover how to

Document your scope statement

Comprehend the importance of project communication

Develop a risk management plan and understand why thats so crucial toyour projects success

Create a quality management plan

Recruit the appropriate members for your software project team

Generate top-notch schedules and budgets

3Introduction

03_749346 intro.qxp 8/30/06 10:16 PM Page 3

Part III: Executing Your Software Project PlanPart III introduces you to your next steps after planning your software project.You can create the most fantastic software project plan your stakeholdershave ever set eyes on, but if you dont know how to execute the project plan,whats the point? That would be like going bear hunting with a BB gun.

Amaze your friends and flabbergast your competition by discovering how to

Work the software project plan youve created

Ensure that your software project plan contains all of the required quality aspects to make it a huge success

Understand different personality types on your team and develop a high-performance project team

Get a feel for some of the different types of contracts

Part IV: Controlling Your Software ProjectPart IV introduces you to the concept of putting controls on your softwareproject after it gets started. You can figure out how to develop change controlprocesses and you can discover the importance of following these processesthe easy way (discovering this on your own, the hard way, can be prettybrutal, believe us).

After reading Part IV, youll understand how to be proactive in determiningwhether your project is under or over budget, ahead of or behind schedule,and whether the project scope is creeping up on you. You can also be awareof how to track and communicate your project performance.

Part V: Closing Your Software ProjectPart V introduces you to the steps that you must complete in order to bringyour project to a successful closing. Youll find out about all the fun thingsyou get to do at the end of your project such as

Helping your project team members with their next steps

Taking care of vendors and contracts


03_749346 intro.qxp 8/30/06 10:16 PM Page 4

Documenting your lessons learned (which of course you started docu-menting at the start of your project planning)

Completing audits and quality control

Celebrating your successes

Part VI: The Part of TensIn this part, you get some important tips on what to do, and what not to do, ifyou want to make your software project a huge success. You get pointers onproject team leadership and communicating the good and not so good news that routinely comes up when youre managing a big project. Find outonce and for all how to run flawless and effective meetings so that everyoneremains focused and productive.

AppendixRead the appendix to find out more about resources offered by the ProjectManagement Institute. You can also find out about the coveted ProjectManagement Professional Certification exam.

No matter what area of project management you enter, you should becomethoroughly familiar with the Project Management Institute. Its an enormouslyhelpful resource.

Icons Used in This BookIn this book, we use a few graphical icons to help point out especially vitalinformation. Dont skip these icons they offer shortcuts to software projectmanagement success.

This icon provides you with some tricks of the trade, enabling you to benefitfrom our experiences and mistakes. No need to thank us.

Take special notice of items marked with this icon. You may need this infor-mation later.

5Introduction

03_749346 intro.qxp 8/30/06 10:16 PM Page 5

Duck! If you dont heed the information highlighted by the Warning icon, yoursoftware project may be in jeopardy.

We use this icon to point out real-life examples, scenarios that weve encoun-tered, or hypothetical situations to which you can apply the tools and tech-niques were describing.

This icon informs you that were providing you with some technical informa-tion that may not be especially important to you. You can skip this informa-tion if you would rather not let your inner geek roam free.

Where to Go from HereTake a gander at the Table of Contents to decide where you want to beginyour software project management extravaganza. Then you may want tobegin with Chapter 1 for an introduction to project management, or you mayprefer to dive right into the deep end and read about procuring goods andservices. Its all good. As you read through the material, if you have any ques-tions or comments, please feel free to e-mail [email protected].

Good reading and good luck. We hope you enjoy the exhilarating world ofsoftware project management as much as we do.


03_749346 intro.qxp 8/30/06 10:16 PM Page 6

Part IStarting Your

Software Project

04_749346 pt01.qxp 8/30/06 10:16 PM Page 7

In this part . . .

Part I provides an overview of software project man-agement and introduces you to some of the jargonused in this field. Dont miss these chapters they formthe foundation for all remaining chapters in the book.

04_749346 pt01.qxp 8/30/06 10:16 PM Page 8

Chapter 1

Examining the Big Picture of Project Management

In This Chapter Defining what a software project is

Examining project management attributes

Starting and finishing a software project

Dealing with software project nuances

Leading and managing project teams

Heres a tough decision for you: Manage a project to create a new pieceof software that can make or break your entire organization, or jumpfrom an airplane with a parachute that may or may not function. Forsome project managers the decision is the same either way.

But not for you. At least youre on the right track to capture, improve, andsuccessfully lead your projects to completion.

The adrenaline rush in skydiving (and in project management) may not be atthe same level, but the butterflies in your stomach definitely are. Theresreally one secret to skydiving and its the same secret to successful projectmanagement. (No, its not dont do it.) The key to successful software pro-ject management and skydiving is preparation.

Many projects fail at the beginning rather than the end. After you do the prepwork, you must execute your plan, take control of your project, and ultimatelybring it to its natural (and successful) conclusion.

05_749346 ch01.qxp 8/30/06 10:18 PM Page 9

Defining Software ProjectsSoftware project management is a type of project management that focusesspecifically on creating or updating software. Just as there are billions of icecream flavors, there are billions of types of software. Project managers, effec-tive ones, can lick them both.

A project, technically, is a temporary endeavor to create a unique product orservice. For some people, everything is a project; for others, projects are spe-cial, lofty activities that occur infrequently. A project is a unique entity. Inother words, the creation of a new application is unique, whereas the mainte-nance and day-to-day support of an existing application is not so unique.Projects can have many attributes:

They change or improve environments in organizations.

They get things done.

They are unique from other work.

They have a defined start and end date.

They require resources and time.

They solve problems.

They seize opportunities.

They are sometimes challenging.

Defining Software Project ManagementFor some people, project management is just a stack of work doled out to agroup of people by a goober called the project manager. For other folks, pro-ject management is a foggy, scary science directed by a different goober witha slide ruler. And for others still, a project manager is a goober that touts for-mulas, certifications, and facts without ever really getting things done.

But in effective project management there aint no room for goobers. Effectiveproject management centers on the serious business of getting work done ontime and within budget while meeting customer expectations. Effective pro-ject management is about accomplishment, leadership, and owning the pro-ject scope. Its an incredible feeling to sign off on the project and know thatyou and your project team contributed to the projects success.

Management is concerned with one thing: results.

10 Part I: Starting Your Software Project

05_749346 ch01.qxp 8/30/06 10:18 PM Page 10

Project management involves coordinating people, vendors, and resources.Project management requires excellent communication skills, a strong will toprotect the project scope, and leadership skills to enforce quality throughoutthe project work.

According to the Project Management Institute (www.pmi.org), the definingresource on all things related to project management, project management iscentered on nine knowledge areas. Events in each knowledge area affect whathappens in the other eight knowledge areas. Table 1-1 gives you the lowdown.

Table 1-1 The Nine Project Management Knowledge AreasKnowledge Area What It Does

Project Scope Management Controlling the planning, execution, andcontent of the project is essential. Youneed to pay special attention to bothproject and product scope so that thesoftware you end up with is what youintended to make in the first place.

Project Time Management Managing everything that affects theprojects schedule is crucial. Whowants tax software that comes out onApril 16?

Project Cost Management Projects cost money, and this knowl-edge area centers on cost estimating,budgeting, and control.

Project Quality Management No project is a good project if the deliv-erable stinks. Quality doesnt happen byaccident, so this knowledge area worksto ensure that the product you are pro-ducing is a quality product that meetscustomer expectations.

Project Human Resources Management The members of the project team mustget their work done. Hiring or assigningpeople who are competent and manag-ing them well are at the center of thisknowledge area.

Project Communications Management Project managers spend 90 percent oftheir time communicating. Communica-tions management focuses on whoneeds what information and when.

(continued)

11Chapter 1: Examining the Big Picture of Project Management

05_749346 ch01.qxp 8/30/06 10:18 PM Page 11

Table 1-1 (continued)Knowledge Area What It Does

Project Risk Management This knowledge area is about avoidingdoom. The focus is on how to anticipaterisks, handle them when they arise, andtake advantage of the opportunities thatcan help a project.

Project Procurement Management Sometimes during the course of yoursoftware project, you may be requiredto work with vendors to purchasegoods and/or services. You may evenbe the vendor that someone else iscontracting for their project. Thisknowledge area is concerned with theprocesses to create vendor contractsand to purchase goods and services.

Project Integration Management What happens in one knowledge areaaffects attributes of the other knowl-edge areas. The ninth knowledge areais fan-freakin-tastic because its pur-pose is to ensure the coordination of allthe other knowledge areas.

Comparing Projects and OperationsThere is a distinct difference between projects and operations. Operations arethe day-to-day activities that your organization does. For example, a car man-ufacturer makes cars. An airline flies people from one city to another. A helpdesk supports technical solutions. Within each of these companies residevarious departments working on projects that enable operations to function.A project at an automobile manufacturer might be to design a new sports car.The car manufacturers operations involve manufacturing that design againand again.

Software creation is special. Imagine you have customers around the worldwho want you to create a piece of software that helps them keep track ofsports statistics. This is your new business you create sports stat softwareand youre a gazillionaire.

Each flavor of the software you create could be a separate project; your com-pany has software for baseball stats, football stats, soccer stats, field hockeystats, and everyones favorite sport, water polo stats. Each project has its


05_749346 ch01.qxp 8/30/06 10:18 PM Page 12

own requirements, its own purpose, its own budget, and its own project man-ager and project team. Each project has its own resources, schedule, bud-gets, and goals.

Your day-to-day support of the software, the sales of the software, the creditcard purchases, and the delivery of millions in cash to your bank account areall part of operations.

Some companies have changed their approach to business by treating all oftheir operations as projects. This microscale of their enterprise, where everyactivity is part of a project and all projects contribute to the betterment ofthe organization, is called management by projects.

Examining Project ConstraintsA constraint is anything that restricts the project managers options.Constraints are requirements, confines, or, if youre a glass-is-half-empty kind of person, prison walls. Constraints can include

Resource constraints such as a team member being assigned to toomany concurrent projects

Tight deadlines

Budgetary limitations

Government regulations

Limitations of software

Scope limitation, such as being required to use a particular existinginterface

Hardware requirements

Anything else that restricts your options

Understanding Universal Constraints(Time, Cost, and Scope)

The three universal project constraints you will always face are

Time: Time constraints may range from a reasonable schedule to animpossibly short timeframe that cant budge because the productsimply must be on shelves by September 15 (never mind that September15 was last week).


05_749346 ch01.qxp 8/30/06 10:19 PM Page 13

Cost: Cost constraints are the usual budgetary restrictions that youexpect. (Heres a nickel. Make it happen.)

Scope: Sometimes scope is a no-brainer (youre working on the 700threv of Acme Wizware to fix a bug). On the other hand, scope can be a bittrickier if youre dealing with an executive who isnt sure what he wants.

We guarantee that executives will always know when a product is neededand how much money you can have to get it done. If theres a single areathat the big-wigs wont have nailed down, its scope.

These three constraints make up what we affectionately refer to as the some-what inflexible-sounding nickname the Iron Triangle of project management.Check out Figure 1-1. Each side of the Iron Triangle represents one of thetriple constraints. For a project to be successful, each side must remain inbalance with the other two. You will read more about project constraints inChapter 3.

In order to achieve quality in the project deliverable, and in the managementof the project, the Iron Triangle must remain balanced.

For example, say your boss decides to add more stuff to the project scope(now instead of simply fixing a mathematical bug in your Wizware accountingsoftware, you have to create a whole new feature in the software that editsphotos and home movies). Even though your boss has changed the scope,you have to deliver more stuff within the same amount of time and with thesame amount of cash, as Figure 1-2 depicts. Youll need more time, moremoney, or both for the triangle to remain equilateral.

Quality

Scope

CostTim

eFigure 1-1:The IronTriangle

describesconstraints

that allprojects

must face.


05_749346 ch01.qxp 8/30/06 10:19 PM Page 14

Managing time constraintsTime constraints are simply deadlines. You have a project to create a newpiece of software within six months. Or theres an opportunity in the market-place for a new application, but the window of opportunity is small, so youhave no time to waste. Time can also be calculated as labor: Working or bill-able hours, processor speed, database consistency, and even networklatency issues can be used to estimate time constraints.

Original Iron Triangle

Iron Triangle whenScope Changes

Scope

CostTim

eFigure 1-2:

Increases tothe project

scopeenlarge the Iron

Triangle.


Introducing the law of diminishing returnsTime is time. Dont be fooled into thinking youcan buy more time no one can. You can buymore labor if you think it will help your team domore work faster, but thats not the same thingas adding time to a project. The law of dimin-ishing returns dictates that adding labor doesntexponentially increase productivity; in fact, atsome point productivity can even go backwards(is that antiductivity?). When that happens,youve hit a plateau, and then everyone is sadbecause you just cant do more with the laboryou have.

For a real-life example of the law of diminishingreturns, consider that you may have two hard-working, experienced programmers working on

a section of code. In your quest to finish the pro-ject on time, you add one more programmer tothe mix. Now the programmers may be com-pleting the code more quickly, and youre soexcited that you decide to add six more pro-grammers so that you can finish even sooner.You soon realize that although adding one pro-grammer increased your productivity, adding sixmore only created chaos, with programmersstepping on each others toes, inadvertentlyneutralizing each others code, and creating acontentious environment. You reached the pointof diminishing returns when you added six programmers.

05_749346 ch01.qxp 8/30/06 10:19 PM Page 15

Time constraints require more than just hitting a target deadline. Unavailableresources (your ace programmer is on vacation), skewed milestone targetswithin the project, conflicting versioning deadlines, and so on, all presentconstraints on the projects timeline. A time constraint is any factor or issuethat changes or impacts the original timeframe of the project. (No timemachines allowed in project management, sorry.)

Managing cost constraintsCost constraints are easy to identify because they deal with cash money.Well, its not always cash, but you get the idea; the miniscule funds in yourproject budget to complete the project work create a unique constraint. Yourcosts include computers and languages to code in, labor, and anything elseyou need to buy in order to get the job done.

For some folks the funds are blue dollars, departmental dollars that shift fromone department to another based on the project costs. For other people thebudget is a very real number in dollars and cents: Customers hire you tocomplete work for them; then they give you a satchel full of cash.

Projects almost always cost somebody something. Be sure to factor in hiddencosts for labor, resources, computers, pizza, celebrations, training, bribes,and more. Just kidding about the bribes part. As far as you know.

Managing the scopeThe third part of the Iron Triangle is the scope. There are two scopes withinproject management:

Product scope: The product scope describes, lists, and categorizes allthe features and components of the finished deliverable. This is whatthe customers see in their minds eye.

Project scope: This is where you focus. The project scope is all therequired work, and only the required work, to create the project deliver-able. The project scope focuses on work, activities, and progress toachieve the product scope. The project scope must be protected fromunapproved changes because it dictates what the project team will doand what the end result of the project will be.

The product scope and the project scope are in love. The product scopekisses details in the project scope and the project scope returns the favor. Itsromantic. Each scope depends on the other, and what happens in eitherscope affects the other. If there is disharmony between these two scopes,trouble is brewing.


05_749346 ch01.qxp 8/30/06 10:19 PM Page 16

Controlling Scope CreepChanges to the project scope can affect cost and time constraints, meltingyour Iron Triangle. The Iron Triangle is a key tool in project management andis ideal for negotiations with stakeholders. For example, if your stakeholderinsists on adding software functionality to your project scope, you can usethe Iron Triangle as a tool to explain that when you increase one side of thetriangle (the scope side) the triangle is no longer in balance. To change thescope, you must change the cost or the schedule (or both) to keep the trian-gle balanced. The Iron Triangle is also a terrific tool to use in discussionswith the project team, and to keep your own duties as project manager inalignment (see Understanding Universal Constraints (Time, Cost, andScope), earlier in this chapter).

Unplanned changes to the project scope, sometimes called scope creep, arethe little extras that expand the scope without reflecting the changes in thecost and time baselines. Youll notice from the graphic that with scope creep,the lines of the Iron Triangle are no longer even. See Figure 1-3.


Delivering whats promised (and only whats promised)

In the Iron Triangle the project managers con-cern is on the project scope the project work.The project manager must direct the projectteam to do the required work, nothing more orless, to deliver exactly what the product scopecalls for.

Nothing more? Shouldnt the project managerand the project team always deliver more thanwhat was promised? No, no, no! This may shockyou, but the job of the project manager and theproject team is to deliver exactly what you andthe customer have agreed to create.

Let me write that again so you dont think its atypo: The project manager should deliver exactlywhat the customer expects.

You and the project stakeholders should defineeverything the project should deliver as soon aspossible. When value-added changes are madeafter the project scope has been created, theanalysis of these changes takes time andmoney and may impact the schedule.

Were not saying the project manager shouldhold back good designs, ideas, and incrediblefeatures that the customer may want and canuse. Were saying that neither the project man-ager, nor any stakeholder, can arbitrarily addfeatures to the software because doing sowould be to change the project scope.

05_749346 ch01.qxp 8/30/06 10:19 PM Page 17

The reason scope creep is so poisonous is because it can happen so easily,and so innocently. And yet, it can be so deadly. When the scope goes off track,time and funds are stolen from the original baselines. Its not as if extra moneyand time are magically added to the project to handle all the little extras.Balancing the three sides of the triangle ensures a high-quality final product.

Changes to the project scope should be controlled and managed through achange control system, which you can find out more about in Chapter 13. Inessence, a change control system accommodates a process for documentingrequested changes and requires obtaining appropriate approval for allrequested project changes. The key is to avoid changes that are not directlyapproved or requested by the customer.

Making Sense of Project Success (Or Failure)

Most projects start with an optimistic attitude about creating a deliverable,keeping the customer happy, and making this the best software project ever.And then things (bad things) happen. The good projects end on time and asplanned. Ah, paradise. Wed wager that these projects have three things incommon:

A leader who knows what he or she is doing

A tight change control system (see Chapter 13)

Team members who understand what the project is supposed to deliverand can therefore get results

Quality Scopecreep

Scopecreep

Scope

CostTim

e

Figure 1-3:Scope

creep isproject

poison thatchanges thealignment of

the IronTriangle.


05_749346 ch01.qxp 8/30/06 10:19 PM Page 18

Commonly, projects limp to the finish line, late, overbudget, and after crush-ing the morale of everyone involved. Done, but maybe not done well. Theseprojects typically have three attributes:

Poor requirements from the project customers

Poor communications through the project manager

Poor morale from the project team

The saddest of projects are the ones that never make it to the finish. Thisbunch misses deadlines, blows budgets, or experiences a radical change ofscope so often that no one (not even the PM) knows exactly what the projectshould be creating anymore. Failed projects usually have some, if not all, ofthese attributes:

No clear vision of what the project priorities are

Lack of leadership from the project manager and/or sponsor

A timid project manager

Lack of autonomy for the project manager

New resumes being typed in unison

Starting and Finishing Software ProjectsAll projects, from your software creations to building the bridge over theRiver Kwai, pass through five process groups as defined by the ProjectManagement Institute. A process group is a mini life cycle that moves the pro-ject one step closer to completion. Process groups are cycles because theprocesses dont just happen once; they are repeated throughout the projectas many times as needed.

Figure 1-4 demonstrates a sequence for process groups; the processes floworganically, in the order that best suits the needs of the project. Although wehope you dont have to keep repeating some of these stages, if your projectisnt going according to plan you will have to do just that.

All projects, software and otherwise, go through these project managementprocesses. Each of these project management processes has its nuances. Wedescribe them in more detail in Chapter 2.


05_749346 ch01.qxp 8/30/06 10:19 PM Page 19

Initiating: Thats really where you are now. The project is in the processof getting selected, sponsored, funded, and launched.

Planning: As you can see in Figure 1-4, planning is an iterativeprocess. Planning basically determines how the project work will get accomplished.

Executing: After you get a plan, your project team does the work.

Controlling: Your project team does the work, but you control them.

Closing: Ah, paradise. After the project work has been completed, youtie up loose ends and close out the software project.

Understanding What Makes SoftwareProject Management So Special

Theres nothing special about software project management that changes theIron Triangle or the five process groups. What is special about project man-agement, however, is the nature of the work.

Just as the particulars of designing a new warehouse, building a house, orcreating a prototype for a remote controlled airplane are unique, so is thecreation of software:

Software development is weird and requires a specialized skill set to doit well.

Software creation is tough.

Software development can be boring, routine, and mind numbing.

Software creation can create challenges within the development of thecode.

Initiating Processes Planning Processes

Controlling Processes

Closing Processes

Executing Processes

Figure 1-4:All projects

followrepeating

sequencescalled

processgroups.


05_749346 ch01.qxp 8/30/06 10:19 PM Page 20

Breaking Moores LawA long time ago, in 1965, Gordon Moore wrote a scientific paper calledCramming More Components onto Integrated Circuits. The synopsis of hispaper is that the number of transistors per integrated circuit could doubleevery two years. The press loved it. The theory became known as MooresLaw. And hes been pretty accurate on his prediction.

The importance of Moores Law in software project management is that moretransistors per circuit mean faster processors. Faster processors mean moreelaborate software. More elaborate software means we need faster proces-sors. And on and on the cycle goes.

Because information technology (IT) drives many businesses today, there is a direct connection between the speed of technology and an organizationsbottom line. Between the two is the software the organization relies on.Consequently, businesses demand software thats reliable, secure, and scal-able. Your organizations profitability, stability, and ability to attract new cus-tomers rely on you and your project team.

Although businesses rely on technology to remain competitive, many soft-ware project managers miss this key point: Its not about the technology.Software project management is about the business. Its about helping yourcompany, your colleagues, and even the stockholders of your organization tobe successful.

If youre an IT guru you may easily fall in love with the bits and bytes of day-to-day software development. However, if youre a project manager, youcannot. Your focus should be on one thing: getting the project done ontime and on budget.

Dealing with MooreAs your project moves towards completion, chances are there will beleapfrogs in the technology youre dealing with. Therell be new versions ofoperating systems, service packs to address problems in versions of softwareyour software relies on, and more. Part of software project management is tohave a plan to address these potential changes. Every (yes, every) softwareproject manager should have an allotment of time added to the projectschedule specifically for planning and responding to Moores Law. Youresaying, My customers and management wont give me more time just forplanning and responding. My customers and management barely give me


05_749346 ch01.qxp 8/30/06 10:19 PM Page 21

enough time to complete my project if everything goes perfectly. Notice thatwe said you should have more time. That doesnt mean you will. After all,time is money.

So what do you do? By relying on historical information, you can help yourproject adjust to Moores Law. If you have documented instances of past pro-jects that failed because of a lack of time to respond to changing technology,use it. If you have records of your past projects, you can show how the pro-ject would have, or at least could have, been more successful with this allot-ment of time.

This is a good time to remind you to save your project documentation so thatyou and other software project managers can use it for the same purpose inthe future. Check out Part V of this book for more on documentation.

Documented instances are your best argument. Were not saying its a slam-dunk, but wed wager dollars to donuts youll at least have a meaningful con-versation about the extra time allotment for planning. Ask your customer ormanagement to try it one time and see what happens. And then document,document, document to prove your point.

If you dont have these project records, well, theres good news and badnews. The bad news is that its hard to argue for additional time for planningwithout proof of why the time will be needed. The good news is that you canstart now. Without the additional time allowed for your project, heres whatwe recommend:

Do a thorough risk assessment. Document how the risks due to changesin technology could contribute to failure.

Document lost time. Document any lost time tied to technical changes(research, team training, subject matter experts, and so on).

Document lessons learned. Begin your lessons learned documentation,a document that highlights all the lessons learned, with attention totechnology changes, at the start of the project, and as your software project progresses, complete your lessons learned documentation.

Communicate proactively. Communicate to your stakeholders whenchanges to technology enter and influence your project.

As a technology professional, its your job to have your finger on thepulse of change in your industry. You dont want to be blindsided bysome major technological event, and you never want to withhold infor-mation to your stakeholders that could affect the longevity of a softwareproduct. The most important thing you can do is balance cost effective-ness and profitability.


05_749346 ch01.qxp 8/30/06 10:19 PM Page 22

Dealing with the first-time, first-use penaltyOne of the most common questions when it comes to software project man-agement is, How can we tell how much thisll cost or how long thisll take ifits never been done before?

This is the first-time, first-use penalty. The penalty is that you just dont know.It may cost thousands, even millions, if the technology has never, ever beendone before. And time? Well, thats even more difficult to grasp.

Youve experienced this. The first time your project team develops code in anew langua

Documents

FOR DUMmIES - The Eye Various/For.Dummies... · · 2017-09-26Teresa earned her Project Management Professional Certification through the ... Using Earned Value Management in Software