26,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
* The increase in project outsourcing has forced traditional programmers to take on the role of project managers and quickly learn how to manage software projects * The author discusses all of the essentials in widely accepted project management methodology, from managing programmers to assessing and eliminating risk * The book covers the iterative development model, using Microsoft Project 2003, as well as a variety of methodologies including eXtreme, open source, SQA testing, software life cycle management, and more * The companion Web site contains tools, case studies and other resources to help even novices get up and running
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 619
Veröffentlichungsjahr: 2011
Ähnliche
Software Project Management For Dummies®
by Teresa Luckey, PMP, MBA, and Joseph Phillips, PMP
Software Project Management For Dummies®
Published byWiley Publishing, Inc.111 River St.Hoboken, 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 or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permission should be addressed to the Legal Department, Wiley Publishing, Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4355, or online at http://www.wiley.com/go/permissions.
Trademarks: Wiley, the Wiley Publishing logo, For Dummies, the Dummies Man logo, A Reference for the Rest of Us!, The Dummies Way, Dummies Daily, The Fun and Easy Way, Dummies.com, and related trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates in the United States and other countries, and may not be used without written permission. All other trademarks are the property of their respective owners. Wiley Publishing, Inc., is not associated with any product or vendor mentioned in this book.
LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY: The publisher and the author make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fitness for a particular purpose. No warranty may be created or extended by sales or promotional materials. The advice and strategies contained herein may not be suitable for every situation. This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services. If professional assistance is required, the services of a competent professional person should be sought. Neither the publisher nor the author shall be liable for damages arising herefrom. The fact that an organization or Website is referred to in this work as a citation and/or a potential source of further information does not mean that the author or the publisher endorses the information the organization or Website may provide or recommendations it may make. Further, readers should be aware that Internet Websites listed in this work may have changed or disappeared between when this work was written and when it is read.
For general information on our other products and services, please contact our Customer Care Department within the U.S. at 877-762-2974, outside the U.S. at 317-572-3993, or fax 317-572-4002.
For technical support, please visit www.wiley.com/techsupport.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books.
Library of Congress Control Number: 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
About the Authors
Teresa Luckey was born in Indianapolis, Indiana, the eighth of twelve children. She earned the degree of Bachelor of Science from the University of Southern Indiana, with a major in Education. She earned her teaching endorsements in Computer Education and Mathematics from the University of Indianapolis and thoroughly enjoyed teaching (and learning from) junior high students for several years. After deciding to expand her horizons beyond the teaching profession, she pursued her interests in information systems and project management while working at hospitals in Indianapolis, and then moved on to a consulting firm, where she now works as a manager implementing healthcare systems. Teresa earned her Master of Business Administration degree from Indiana Wesleyan University, where she served as co-class president with her husband, David. She is just shy of completing her Master of Science in New Media at Indiana University School of Informatics. One of these days — soon — she hopes to finish that degree so that she can maintain her reputation as a life-long learner.
Teresa earned her Project Management Professional Certification through the Project Management Institute in 2001 and continues to maintain her certification. She enjoys contributing to the field of project management, particularly with 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 firm believer in the axiom that there’s more to life than work, Teresa and her family are passionate about traveling and exploring all types of music.
Joseph Phillips, PMP, Project+, is the Director of Education for Project Seminars. He has managed and consulted on projects for various industries, including technical, pharmaceutical, manufacturing, and architectural, among others.
Phillips has served as a project management consultant for organizations creating 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, information technology 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 has taught over 10,000 professionals. Phillips has contributed as an author or editor 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 numerous trade shows, PMI chapter meetings, and employee conferences. When not writing, 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.
Dedication
I dedicate this effort to David, Amanda, Sara, and Adam Luckey.
Authors’ Acknowledgments
Teresa Luckey: Thanks to Kevin Kirschner, Editorial Manager, for his confidence in me and for providing me with this opportunity. I appreciate Katie Feltman, Acquisitions Editor, for her diligence in bringing this book to fruition and 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 am grateful 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 your unrelenting 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 on this project. A humongous thank you to Katie Feltman and all the folks at For Dummies for their patience and persistence. I would also like to thank the hundreds 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, and my son, Kyle.
Both authors would like to recognize and thank Cynthia Snyder and Karen Scott for being conscientious and thorough while reviewing this book.
Publisher’s Acknowledgments
We’re proud of this book; please send us your comments through our online registration form located 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
Contents
Title
Introduction
About This Book
Who Should Read This Book?
How This Book Is Organized
Icons Used in This Book
Where to Go from Here
Part I : Starting Your Software Project
Chapter 1: Examining the Big Picture of Project Management
Defining Software Projects
Defining Software Project Management
Comparing Projects and Operations
Examining Project Constraints
Understanding Universal Constraints (Time, Cost, and Scope)
Controlling Scope Creep
Making Sense of Project Success (Or Failure)
Starting and Finishing Software Projects
Understanding What Makes Software Project Management So Special
Chapter 2: Initiating a Software Project
Identifying the Project Purpose
Dealing with Politics
Moving from Here to There
Living with Stakeholders
Completing a Project Feasibility Study
Understanding How Executives Select Projects
Writing the Product Description
Making Your Project Wish List
Recognizing Doomed Projects
Chapter 3: Creating the Software Scope
Understanding Product Scope and Project Scope
Managing Stakeholder Objectives
Building the Software Scope
Creating the Project Scope
Creating a Work Breakdown Structure
Part II : Planning Your Software Project
Chapter 4: Planning for Communications
The Importance of Communicating Effectively
Care and Feeding of Nerds
Avoiding Communication Breakdowns
Calculating the Communication Channels
Building an Effective Communication Management Plan
Defining Who Needs What Information
Defining When Communication Is Needed
Defining Communication Modalities
Chapter 5: Planning for Software Project Risks
Identifying Pure and Business Risks
Determining Stakeholder Risk Tolerance
Mitigating Risks Early On
Managing Risks in Your Organization
Relying on Quantitative Analysis
Creating a Contingency Reserve
Using Software Models for Risk Management
Preparing a Risk Response Plan
Examining Risk Responses and Impacts
Chapter 6: Planning for Software Quality
Defining Quality
Working with a Quality Policy
Balancing Time, Cost, and Quality
Chapter 7: Building the Project Team
Determining Your Project Needs
Finding the Talent
Asking the Right Questions (In the Right Way)
Determining Who Is Really in Charge
Hosting Your First Project Team Meeting
Working with Organizational Policies
Chapter 8: Creating Project Time Estimates
Organizing Information Before You Build a Timeline
Understanding the Importance of a Project Network Diagram
Preparing to Create Your PND
Using Historical Information to Complete Inexact Activity Time Estimates
Identifying Activity Duration Influencers
Making the Project Duration Estimate
Estimating Do’s and Don’ts
Using PERT for the Most Accurate Estimates
Knowing What to Say if the Boss Wants an Estimate Now
Understanding the Way PND Paths Interact
Creating the Project Schedule
Chapter 9: Building Your Project Budget
Creating Cost Estimates
Creating an Accurate Estimate
Considering Project Profitability
Planning for Contingencies
Controlling Project Costs
Having More Project than Cash
Recognizing Budgetary Problems Before You Get to the Root Cause Analysis Stage
Dealing with a Budget Problem that Your Bosses Know about (But Haven’t Addressed)
Part III : Executing Your Software Project Plan
Chapter 10: Working the Project Plan
Authorizing the Project Work
Ensuring Quality in Execution
Understanding the Interoperability of the Quality Management Plan
Following Quality Assurance
Following the Quality Policy
Managing Software Project Risks
Monitoring and Controlling Risks
Managing Secondary and Residual Risks
Documenting Risk Management Effectiveness
Chapter 11: Working with Project People
Examining the Phases of Team Development
Doing Some Fun Team-Building Exercises
Managing Project Conflicts
Using Your Super Magic Project Manager Powers
You and Your Positional Power
Chapter 12: Procuring Goods and Services
Finding a Vendor
Selecting the Vendor
Negotiating for the Best Solution
Administering Contracts
Closing the Vendor Contract
Part IV : Controlling Your Software Project
Chapter 13: Managing Changes to the Software Project
Introducing the Controlling Process Group
Controlling the Project Scope
Controlling Project Costs
Controlling the Project Schedule
Chapter 14: Using Earned Value Management in Software Projects
Defining Earned Value Management
Discovering the Earned Value Management Formulas
Playing with Values
Chapter 15: Tracking Project Performance
Planning Project Metrics
Implementing a Tracking Plan
Tracking Project Performance
Communicating Project Performance
Part V : Closing Your Software Project
Chapter 16: Finalizing the Project Management Processes
Closing the Software Project
Closing Out Vendor Contracts
Completing the Project (Or at Least Transferring It to Someone Else)
Case Study: Completing a Project Post Mortem
Chapter 17: Documenting Your Software Project
Using Teamwork When Writing Documentation
Completing the Lessons Learned Documentation
Organizing Your Lessons Learned Document
Creating the User Manual and Help System
Part VI : The Part of Tens
Chapter 18: Ten Ways to Make Your Software Project Crash and Burn
Failing to Plan
Ignoring Risk Management
Letting Your Ego Lead the Project
Letting Your Iron Triangle Melt
Hiding from the Project Team
Hovering over the Project Team
Creating Unrealistic Schedules
Consistently Being Inconsistent
Doing Nothing
Being a Wimp
Chapter 19: Ten Ways to Make Any Software Project Better
Asking the Right Questions
Being a Good Communicator
Showing Your Leadership Skills
Creating the Right Project Plan
Finding the Correct Sponsor
Recognizing Failure Before It Arrives
Planning, Planning, and a Little More Planning
Documenting Your Project Even if You Don’t Want To
Hosting a Successful Project Meeting
Establishing Project Rules Before the Project Begins
Communicating Good and Bad News
Appendix: Formal Project Management Training and Certification
Getting Up Close and Personal with the Project Management Institute
Finding Out Whether the Project Management Professional Certification Is for You
What Is the CAPM Certification?
Deciding between the PMP and the CAPM
Introduction
Welcome to Software Project Management For Dummies; we hope you enjoy the ride as we take you through scenic highways dotted with the hues and shades of software project management concepts, project team development, and various descriptions of fascinating new terminology.
We’re two experienced software project managers, and we wrote this book because we want you to benefit from the lessons we’ve learned through years of experience. You don’t have to suffer to be a success. You just have to follow our example.
About This Book
The purpose of this book is to assist you in understanding and using software project management concepts. We want to pique your curiosity about some of the project management topics and processes and provide you with some tips on communicating project information to team members, executives, clients, and other important stakeholders. With the help of this book, you can develop high-performing project teams who complete projects on time and under budget. Not only that, with the help of Software Project Management For Dummies, we hope that you’ll cultivate high-performing teams who respect your authority and believe in your abilities, even though you sometimes make them work overtime.
This book isn’t intended to be a complete reference for discovering everything there is to know about software project management. It’s also not intended to be your sole source of information if you’re preparing for your PMP certification (for that you might want to check out PMP Certification For Dummies by Peter Nathan Gerald Everett Jones and published by our friends at Wiley).
We’re ambitious, but not unrealistic, and we know that project management of any type is a little bit of an art and involves a lot of practice. There is so much more to know that this book would have ended up being as big as, well, as big as something that’s really big. It’s not that we necessarily excluded anything from this book, but we touched on some topics at a high level for the sake of practicality. We discuss quality management for example, but volumes upon volumes have been written on just that one topic, so we couldn’t give you every bit of information — just the information you need to get the job done and get on to the next task.
To find out more about software project management and project management in general, or to study for your PMP certification, you may want to check out Software Project Management Kit For Dummies by Greg Mandanis and Allen Wyatt. We also personally reread many times PMP: Project Management Professional Study Guide, 3rd Edition, by Kim Heldman (Wiley). Although Heldman’s book is written in a different format and follows a different flow than the PMP bible, Guide to the Product Management Body of Knowledge (PMI), it contains the same information and it’s a good companion to the Guide to the PMBOK.
Who Should Read This Book?
So you’ve just picked up this treasure in the bookstore and you’re looking it over trying to decide whether it’s the book for you. Well, this book is definitely for you if you are
An experienced software project manager who is interested in improving your skills and finding out a little bit more from other experienced software project managers’ perspectives.
An experienced general project manager who is moving into software project management (or maybe you’ve been thrust into software project management without a lot of time to prepare).
Just starting to get to know the discipline of project management and deciding whether you should move in the direction of software project management.
An ambitious project team member who has become an ad-hoc project manager because your boss isn’t showing enough leadership.
Not involved in a project management career at all, but contemplating software project management as an alternative.
So, whether or not you are currently a project manager or software project manager, actively working on a project team, or completely in the dark about this mysterious field, this book has something for you. If you’re experienced, you’re bound to discover a new method for handling a situation, and if you’re deciding whether or not to delve into the field of software project management, this book may help you make that significant decision.
How This Book Is Organized
This book contains six major parts. Each part contains several chapters. Look at the Table of Contents and decide which areas are of most interest to you. Or skim 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 progression of a software project, from planning stages until the very end. However, it’s not absolutely imperative that you read all of the chapters in order. Feel free to skip to and fro. All projects move at their own pace and have their own unique challenges, so some chapters might have more relevant information for you right now than others. We do think you should start at Chapter 1 before you move forward, and if you never deal with creating software project budgets, you can safely skip Chapter 9. If you’re not working with vendors or contracts, you could also safely skip Chapter 12. Some project managers on smaller projects might not have to worry about earned value management, so skip Chapter 14 with a clear conscience if you don’t need to know about this topic.
Part I: Starting Your Software Project
Part I introduces you to those elements of software project management that are the foundation upon which you construct the remaining phases of your software project. All the other chapters in the book are based on the concepts contained within Part I.
Part II: Planning Your Software Project
Part II introduces you to the basic concepts and essential elements of creating 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 that’s so crucial to your project’s success
Create a quality management plan
Recruit the appropriate members for your software project team
Generate top-notch schedules and budgets
Part III: Executing Your Software Project Plan
Part III introduces you to your next steps after planning your software project. You can create the most fantastic software project plan your stakeholders have ever set eyes on, but if you don’t know how to execute the project plan, what’s 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 you’ve 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 Project
Part IV introduces you to the concept of putting controls on your software project after it gets started. You can figure out how to develop change control processes and you can discover the importance of following these processes the easy way (discovering this on your own, the hard way, can be pretty brutal, believe us).
After reading Part IV, you’ll understand how to be proactive in determining whether 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 aware of how to track and communicate your project performance.
Part V: Closing Your Software Project
Part V introduces you to the steps that you must complete in order to bring your project to a successful closing. You’ll find out about all the fun things you 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
Documenting your lessons learned (which of course you started documenting at the start of your project planning)
Completing audits and quality control
Celebrating your successes
Part VI: The Part of Tens
In this part, you get some important tips on what to do, and what not to do, if you want to make your software project a huge success. You get pointers on project team leadership and communicating the good — and not so good — news that routinely comes up when you’re managing a big project. Find out once and for all how to run flawless and effective meetings so that everyone remains focused and productive.
Appendix
Read the appendix to find out more about resources offered by the Project Management Institute. You can also find out about the coveted Project Management Professional Certification exam.
No matter what area of project management you enter, you should become thoroughly familiar with the Project Management Institute. It’s an enormously helpful resource.
Icons Used in This Book
In this book, we use a few graphical icons to help point out especially vital information. Don’t skip these icons — they offer shortcuts to software project management success.
This icon provides you with some tricks of the trade, enabling you to benefit from our experiences and mistakes. No need to thank us.
Take special notice of items marked with this icon. You may need this information later.
Duck! If you don’t heed the information highlighted by the Warning icon, your software project may be in jeopardy.
We use this icon to point out real-life examples, scenarios that we’ve encountered, or hypothetical situations to which you can apply the tools and techniques we’re describing.
This icon informs you that we’re providing you with some technical information that may not be especially important to you. You can skip this information if you would rather not let your inner geek roam free.
Where to Go from Here
Take a gander at the Table of Contents to decide where you want to begin your software project management extravaganza. Then you may want to begin with Chapter 1 for an introduction to project management, or you may prefer to dive right into the deep end and read about procuring goods and services. It’s all good. As you read through the material, if you have any questions or comments, please feel free to e-mail [email protected].
Good reading and good luck. We hope you enjoy the exhilarating world of software project management as much as we do.
Part I
Starting Your Software Project
In this part . . .
Part I provides an overview of software project management and introduces you to some of the jargon used in this field. Don’t miss these chapters — they form the foundation for all remaining chapters in the book.
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
Here’s a tough decision for you: Manage a project to create a new piece of software that can make or break your entire organization, or jump from an airplane with a parachute that may — or may not — function. For some project managers the decision is the same either way.
But not for you. At least you’re on the right track to capture, improve, and successfully lead your projects to completion.
The adrenaline rush in skydiving (and in project management) may not be at the same level, but the butterflies in your stomach definitely are. There’s really one secret to skydiving and it’s the same secret to successful project management. (No, it’s not “don’t do it.”) The key to successful software project management and skydiving is preparation.
Many projects fail at the beginning rather than the end. After you do the prep work, you must execute your plan, take control of your project, and ultimately bring it to its natural (and successful) conclusion.
Defining Software Projects
Software project management is a type of project management that focuses specifically on creating or updating software. Just as there are billions of ice cream flavors, there are billions of types of software. Project managers, effective ones, can lick them both.
A project, technically, is a temporary endeavor to create a unique product or service. For some people, everything is a project; for others, projects are special, lofty activities that occur infrequently. A project is a unique entity. In other words, the creation of a new application is unique, whereas the maintenance 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 Management
For some people, project management is just a stack of work doled out to a group of people by a goober called the project manager. For other folks, project management is a foggy, scary science directed by a different goober with a slide ruler. And for others still, a project manager is a goober that touts formulas, certifications, and facts without ever really getting things done.
But in effective project management there ain’t no room for goobers. Effective project management centers on the serious business of getting work done on time and within budget while meeting customer expectations. Effective project management is about accomplishment, leadership, and owning the project scope. It’s an incredible feeling to sign off on the project and know that you and your project team contributed to the project’s success.
Management is concerned with one thing: results.
Project management involves coordinating people, vendors, and resources. Project management requires excellent communication skills, a strong will to protect the project scope, and leadership skills to enforce quality throughout the project work.
According to the Project Management Institute (www.pmi.org), the defining resource on all things related to project management, project management is centered on nine knowledge areas. Events in each knowledge area affect what happens in the other eight knowledge areas. Table 1-1 gives you the lowdown.
Comparing Projects and Operations
There is a distinct difference between projects and operations. Operations are the day-to-day activities that your organization does. For example, a car manufacturer makes cars. An airline flies people from one city to another. A help desk supports technical solutions. Within each of these companies reside various 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 manufacturer’s operations involve manufacturing that design again and again.
Software creation is special. Imagine you have customers around the world who want you to create a piece of software that helps them keep track of sports statistics. This is your new business — you create sports stat software and you’re a gazillionaire.
Each flavor of the software you create could be a separate project; your company has software for baseball stats, football stats, soccer stats, field hockey stats, and everyone’s favorite sport, water polo stats. Each project has its own requirements, its own purpose, its own budget, and its own project manager and project team. Each project has its own resources, schedule, budgets, and goals.
Your day-to-day support of the software, the sales of the software, the credit card purchases, and the delivery of millions in cash to your bank account are all part of operations.
Some companies have changed their approach to business by treating all of their operations as projects. This microscale of their enterprise, where every activity is part of a project and all projects contribute to the betterment of the organization, is called management by projects.
Examining Project Constraints
A constraint is anything that restricts the project manager’s options. Constraints are requirements, confines, or, if you’re a glass-is-half-empty kind of person, prison walls. Constraints can include
Resource constraints such as a team member being assigned to too many concurrent projects
Tight deadlines
Budgetary limitations
Government regulations
Limitations of software
Scope limitation, such as being required to use a particular existing interface
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 an impossibly short timeframe that can’t budge because the product simply must be on shelves by September 15 (never mind that September 15 was last week).
Cost: Cost constraints are the usual budgetary restrictions that you expect. (“Here’s a nickel. Make it happen.”)
Scope: Sometimes scope is a no-brainer (you’re working on the 700th rev of Acme Wizware to fix a bug). On the other hand, scope can be a bit trickier if you’re dealing with an executive who isn’t sure what he wants.
We guarantee that executives will always know when a product is needed and how much money you can have to get it done. If there’s a single area that the big-wigs won’t have nailed down, it’s scope.
These three constraints make up what we affectionately refer to as the somewhat inflexible-sounding nickname the Iron Triangle of project management. Check out Figure 1-1. Each side of the Iron Triangle represents one of the triple constraints. For a project to be successful, each side must remain in balance with the other two. You will read more about project constraints in Chapter 3.
In order to achieve quality in the project deliverable, and in the management of the project, the Iron Triangle must remain balanced.
Figure 1-1: The Iron Triangle describes constraints that all projects must face.
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 accounting software, you have to create a whole new feature in the software that edits photos 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 the same amount of cash, as Figure 1-2 depicts. You’ll need more time, more money, or both for the triangle to remain equilateral.
Figure 1-2: Increases to the project scope enlarge the Iron Triangle.
Managing time constraints
Time constraints are simply deadlines. You have a project to create a new piece of software within six months. Or there’s an opportunity in the marketplace for a new application, but the window of opportunity is small, so you have no time to waste. Time can also be calculated as labor: Working or billable hours, processor speed, database consistency, and even network latency issues can be used to estimate time constraints.
Introducing the law of diminishing returns
Time is time. Don’t be fooled into thinking you can buy more time — no one can. You can buy more labor if you think it will help your team do more work faster, but that’s not the same thing as adding time to a project. The law of diminishing returns dictates that adding labor doesn’t exponentially increase productivity; in fact, at some point productivity can even go backwards (is that antiductivity?). When that happens, you’ve hit a plateau, and then everyone is sad because you just can’t do more with the labor you have.
For a real-life example of the law of diminishing returns, consider that you may have two hardworking, experienced programmers working on a section of code. In your quest to finish the project on time, you add one more programmer to the mix. Now the programmers may be completing the code more quickly, and you’re so excited that you decide to add six more programmers so that you can finish even sooner. You soon realize that although adding one programmer increased your productivity, adding six more only created chaos, with programmers stepping on each other’s toes, inadvertently neutralizing each other’s code, and creating a contentious environment. You reached the point of diminishing returns when you added six programmers.
Time constraints require more than just hitting a target deadline. Unavailable resources (your ace programmer is on vacation), skewed milestone targets within the project, conflicting versioning deadlines, and so on, all present constraints on the project’s timeline. A time constraint is any factor or issue that changes or impacts the original timeframe of the project. (No time machines allowed in project management, sorry.)
Managing cost constraints
Cost constraints are easy to identify because they deal with cash money. Well, it’s not always cash, but you get the idea; the miniscule funds in your project budget to complete the project work create a unique constraint. Your costs include computers and languages to code in, labor, and anything else you need to buy in order to get the job done.
For some folks the funds are blue dollars, departmental dollars that shift from one department to another based on the project costs. For other people the budget is a very real number in dollars and cents: Customers hire you to complete work for them; then they give you a satchel full of cash.
Projects almost always cost somebody something. Be sure to factor in hidden costs for labor, resources, computers, pizza, celebrations, training, bribes, and more. Just kidding about the bribes part. As far as you know.
Managing the scope
The third part of the Iron Triangle is the scope. There are two scopes within project management:
Product scope: The product scope describes, lists, and categorizes all the features and components of the finished deliverable. This is what the customers see in their minds’ eye.
Project scope: This is where you focus. The project scope is all the required work, and only the required work, to create the project deliverable. The project scope focuses on work, activities, and progress to achieve the product scope. The project scope must be protected from unapproved changes because it dictates what the project team will do and what the end result of the project will be.
The product scope and the project scope are in love. The product scope kisses details in the project scope and the project scope returns the favor. It’s romantic. Each scope depends on the other, and what happens in either scope affects the other. If there is disharmony between these two scopes, trouble is brewing.
Delivering what’s promised (and only what’s promised)
In the Iron Triangle the project manager’s concern is on the project scope — the project work. The project manager must direct the project team to do the required work, nothing more or less, to deliver exactly what the product scope calls for.
Nothing more? Shouldn’t the project manager and the project team always deliver more than what was promised? No, no, no! This may shock you, but the job of the project manager and the project team is to deliver exactly what you and the customer have agreed to create.
Let me write that again so you don’t think it’s a typo: The project manager should deliver exactly what the customer expects.
You and the project stakeholders should define everything the project should deliver as soon as possible. When value-added changes are made after the project scope has been created, the analysis of these changes takes time and money and may impact the schedule.
We’re not saying the project manager should hold back good designs, ideas, and incredible features that the customer may want and can use. We’re saying that neither the project manager, nor any stakeholder, can arbitrarily add features to the software because doing so would be to change the project scope.
Controlling Scope Creep
Changes to the project scope can affect cost and time constraints, melting your Iron Triangle. The Iron Triangle is a key tool in project management and is ideal for negotiations with stakeholders. For example, if your stakeholder insists on adding software functionality to your project scope, you can use the Iron Triangle as a tool to explain that when you increase one side of the triangle (the scope side) the triangle is no longer in balance. To change the scope, you must change the cost or the schedule (or both) to keep the triangle balanced. The Iron Triangle is also a terrific tool to use in discussions with the project team, and to keep your own duties as project manager in alignment (see “Understanding Universal Constraints (Time, Cost, and Scope),” earlier in this chapter).
Unplanned changes to the project scope, sometimes called scope creep, are the little extras that expand the scope without reflecting the changes in the cost and time baselines. You’ll notice from the graphic that with scope creep, the lines of the Iron Triangle are no longer even. See Figure 1-3.
Figure 1-3: Scope creep is project poison that changes the alignment of the Iron Triangle.
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. It’s not as if extra money and 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 a change control system, which you can find out more about in Chapter 13. In essence, a change control system accommodates a process for documenting requested changes and requires obtaining appropriate approval for all requested project changes. The key is to avoid changes that are not directly approved 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 as planned. Ah, paradise. We’d wager that these projects have three things in common:
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 deliver and can therefore get results
Commonly, projects limp to the finish line, late, overbudget, and after crushing the morale of everyone involved. Done, but maybe not done well. These projects 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. This bunch misses deadlines, blows budgets, or experiences a radical change of scope so often that no one (not even the PM) knows exactly what the project should be creating anymore. Failed projects usually have some, if not all, of these 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 Projects
All projects, from your software creations to building the bridge over the River Kwai, pass through five process groups as defined by the Project Management Institute. A process group is a mini life cycle that moves the project one step closer to completion. Process groups are cycles because the processes don’t just happen once; they are repeated throughout the project as many times as needed.
Figure 1-4 demonstrates a sequence for process groups; the processes flow organically, in the order that best suits the needs of the project. Although we hope you don’t have to keep repeating some of these stages, if your project isn’t going according to plan you will have to do just that.
All projects, software and otherwise, go through these project management processes. Each of these project management processes has its nuances. We describe them in more detail in Chapter 2.
Figure 1-4: All projects follow repeating sequences called process groups.
Initiating: That’s really where you are now. The project is in the process of getting selected, sponsored, funded, and launched.
Planning: As you can see in Figure 1-4, planning is an iterative process. 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, you tie up loose ends and close out the software project.
Understanding What Makes Software Project Management So Special
There’s nothing special about software project management that changes the Iron Triangle or the five process groups. What is special about project management, however, is the nature of the work.
Just as the particulars of designing a new warehouse, building a house, or creating a prototype for a remote controlled airplane are unique, so is the creation of software:
Software development is weird and requires a specialized skill set to do it well.
Software creation is tough.
Software development can be boring, routine, and mind numbing.
Software creation can create challenges within the development of the code.
Breaking Moore’s Law
A long time ago, in 1965, Gordon Moore wrote a scientific paper called “Cramming More Components onto Integrated Circuits.” The synopsis of his paper is that the number of transistors per integrated circuit could double every two years. The press loved it. The theory became known as Moore’s Law. And he’s been pretty accurate on his prediction.
The importance of Moore’s Law in software project management is that more transistors per circuit mean faster processors. Faster processors mean more elaborate software. More elaborate software means we need faster processors. 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 organization’s bottom line. Between the two is the software the organization relies on. Consequently, businesses demand software that’s reliable, secure, and scalable. Your organization’s profitability, stability, and ability to attract new customers rely on you and your project team.
Although businesses rely on technology to remain competitive, many software project managers miss this key point: It’s not about the technology. Software project management is about the business. It’s about helping your company, your colleagues, and even the stockholders of your organization to be successful.
If you’re an IT guru you may easily fall in love with the bits and bytes of day-to-day software development. However, if you’re a project manager, you cannot. Your focus should be on one thing: getting the project done — on time and on budget.
Dealing with Moore
As your project moves towards completion, chances are there will be leapfrogs in the technology you’re dealing with. There’ll be new versions of operating systems, service packs to address problems in versions of software your software relies on, and more. Part of software project management is to have a plan to address these potential changes. Every (yes, every) software project manager should have an allotment of time added to the project schedule specifically for planning and responding to Moore’s Law. You’re saying, “My customers and management won’t give me more time just for planning and responding. My customers and management barely give me enough time to complete my project if everything goes perfectly.” Notice that we said you “should” have more time. That doesn’t mean you will. After all, time is money.
So what do you do? By relying on historical information, you can help your project adjust to Moore’s Law. If you have documented instances of past projects 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 project would have, or at least could have, been more successful with this allotment of time.
This is a good time to remind you to save your project documentation so that you and other software project managers can use it for the same purpose in the future. Check out Part V of this book for more on documentation.
Documented instances are your best argument. We’re not saying it’s a slam-dunk, but we’d wager dollars to donuts you’ll at least have a meaningful conversation about the extra time allotment for planning. Ask your customer or management to try it one time and see what happens. And then document, document, document to prove your point.
If you don’t have these project records, well, there’s good news and bad news. The bad news is that it’s hard to argue for additional time for planning without proof of why the time will be needed. The good news is that you can start now. Without the additional time allowed for your project, here’s what we recommend:
Do a thorough risk assessment. Document how the risks due to changes in 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 to technology changes, at the start of the project, and as your software project progresses, complete your lessons learned documentation.
Communicate proactively. Communicate to your stakeholders when changes to technology enter and influence your project.
As a technology professional, it’s your job to have your finger on the pulse of change in your industry. You don’t want to be blindsided by some major technological event, and you never want to withhold information to your stakeholders that could affect the longevity of a software product. The most important thing you can do is balance cost effectiveness and profitability.
Dealing with the first-time, first-use penalty
One of the most common questions when it comes to software project management is, “How can we tell how much this’ll cost or how long this’ll take if it’s never been done before?”
This is the first-time, first-use penalty. The penalty is that you just don’t know. It may cost thousands, even millions, if the technology has never, ever been done before. And time? Well, that’s even more difficult to grasp.
You’ve experienced this. The first time your project team develops code in a new language, productivity slides. The first time an end user loads and uses your application, there’s a learning curve.
Leading versus managing
When you think of leadership you probably think of positive attributes; a leader is honest, inspiring, and motivating. All true. And when you think of a manager you probably have thoughts like work-centric, accountability, and results- oriented. Also true.
A project manager has to be both a leader and a manager. A leader aligns, motivates, and directs people towards accomplishments. A leader is interested in what others want and what others need. A leader can empathize, inspire, and help others reach their goals. A leader cares.
A manager is concerned about one thing: results. A manager needs the team members to deliver on their promises. A manager needs to see progress and accomplishment. A manager may care about the project team, but not as much as he cares about the project team’s ability to get the work done.
A truly effective project manager, regardless of the situation, organizational structure, or technology the project focuses on, must be a leader and a manager. You have to be both.
Take note. If you’ve got any skills at all and you’re just starting out in this business, you are probably either a good manager or a good leader, but not yet both. You’ll soon find out which category you fall into. Remember, not everyone has to like you, but everyone has to respect you. If team members refer to you as Mussolini when they’re standing around the water cooler, you’re probably overdoing the management part of your job. If they call you “all talk and no action,” you may need to beef up those management skills and lay off the motivational seminars. As you evolve as a PM, you’ll find the right balance between these two extremes.
The first time you stretch your teams, you face challenges with deadlines, cost, and even attitude. Productivity slides, but eventually productivity should curve beyond current levels to a new plateau. At least that’s the theory. Actual mileage may vary.
Chances are your team has worked with the programming language before. Chances are you’ve done a similar project before. Chances are you have a gut feeling for the time, cost, and feasibility of the project. Chances are, based on your experience, you have some idea of how the project is going to go.
Of course, out here in the real world, you can’t go on hunches. Even though it’s not feasible to expect these things, your customers, your boss, and your stakeholders want just the facts, only the most definite answers, and the most exact time and cost figures possible.
This is where an acceptable range of variances must be introduced. A range of variance is a cushion based on your estimates. No, we’re not talking about bloating your estimates, but establishing a level of confidence in the estimates you give. A range of variance is the +/– percentage, time, or cost you append to your estimates. See Figure 1-5.
Figure 1-5: The ideal baseline, the accepted range of variance, and the actual results for a typical software project can vary wildly.
Chapter 2
Initiating a Software Project
In This Chapter
Determining what the project’s purpose is
Handling the various organizational entities
Studying the project’s feasibility
Determining which plan works best
Recognizing problems in your software project
Projects, big and small, have to be initiated. All initiation really means is that everyone acknowledges that the project has a purpose (and that everyone agrees on what that purpose is): to solve a problem, to grasp an opportunity, or to meet demand for a new piece of software.
Software projects, all software projects, have one thing in common: They attempt to provide something for someone else, whether it’s the organization or the customer. The goal, from a project manager’s perspective, is to solve the problem to satisfy the demand.
Identifying the Project Purpose
Before you, the project manager, or your organization can go about the business of satisfying the demand you’re fulfilling with your software product, you must take care of a few formalities. Yes, formalities. In some organizations, perhaps yours, the only formality of initiating a project is a shopping list of demands thrown onto your desk.
You have our sympathy.
Successful projects, and, by default, successful project managers, have to start by ironing out a few details. Make sure these questions are asked and successfully answered:
Why is the project being initiated? You first have to know the project purpose.
Does everyone agree on this purpose and goals? There must be consensus on what the project will create. There must be consensus on the goals of the project. If not, you can count on trouble before the project is complete.
The project purpose is just a fancy way of understanding the background of why the project is being initiated. If you don’t have enough background information, you won’t be able to ask the right questions to create a solution that solves the problem, grabs the opportunity, or improves the organization.
Your fundamental purpose, at this point in the project life cycle, is to understand why the project is being initiated. But another crucial element to successful project management is to be in tune with the structure of your organization.
Talking to the stakeholders
When a project is being initiated, you want to capture as much information as possible about the project goals. Without a clear picture of what the project is to capture, it’s going to be challenging to plan and prepare for your software project.
Stakeholders, from your customers to senior management, will have different concepts about what signifies that a project is complete. You need to know what their expectations are so you can reach the project completion with few surprises (or headaches). Here are five questions every project manager should ask stakeholders:
What are the factors for completion? You should ask this key question far in advance of starting the project work. As a project manager you need to know what the project will accomplish and be able to plan how to get there. If the qualifications for completion are unknown or fuzzy at best, you’re not ready to get to work. Starting a project without knowing what the end result should be is like building a house without blueprints.
What is the goal of this project? Knowing the project’s goal helps you and the team plan. For some projects the goal will be to win new customers, or to make internal processes more efficient, or to solve a problem. Other projects may be financially based. For example, the goal may be to create this essential transition to VoIP without spending more than $235,000.
What are the areas of the organization that this project will affect? The answer to this question tells you who you need to communicate with. It also brings to attention that there may be stakeholders who aren’t attending meetings and should be. Although it’s easy to identify the end-users of your software, there may be “hidden stakeholders” to consider: accounting, security personnel, government agencies, a training team, and so on.
What is the project priority? Chances are good you’ll be managing more than one project at a time, and there are equal chances that your project team members will be on multiple projects as well. When you consider these odds it’s best to know your priorities so you know where to spend your energy. Consider your software conformance to the Sarbanes-Oxley Act versus a feature to search a database through a Web browser. Both may be important, but you’ll need to determine which takes priority. Refer to Sarbanes-Oxley For Dummies, by Jill Gilbert Welytok (Wiley), for information on this important act.
What is the accepted range of variance? The range of variance is the +/– value associated with the budget and the schedule. For example, a project may have a budget of $450,000, +45,000 to –$25,000. This means the project could actually cost as much as $495,000 or as little as $425,000. You can actually apply the same methods to the project schedule. This nugget of info can help you plan and react to problems within the project — and you know there’ll be problems.
Check out Figure 2-1. This fancy-schmancy triangle is a model of how most organizations operate. Each level of your organization has different needs, different concerns, and different goals for your project. You need to address each level of your organization to get the project moving to completion.
Figure 2-1: Organiza-tions are comprised of executives, functional manage-ment, and operations.
Discussing high-level stuff with the executives
At the top of the pyramid live all of the executives with their elegant high heels, expensive suits, diamond earrings, cufflinks, fancy ties, and caviar dinners. Executives are responsible for setting the vision and direction of their organization. This small group of people (or sometimes even a single person) has a vision for the organization and is interested in taking herself and her employees there. Usually.
The executives want to know why any project is occurring because they want to confirm that the project aligns with their vision. If your project doesn’t align with the company’s vision, kill it before someone else does.
Questions you need to ask executives, assuming you’ll be interacting with this crowd:
What are the factors for project success?
What’s your vision for the project result?
What’s more important, time or budget?
What risks do you anticipate for this project’s success?
Sometimes you experience a disconnect between a project’s stated purpose and its actual purpose. The more detailed information you get from the executives the more likely you are to identify this disconnect early and straighten it out.
