42,99 €
42,99 €
-100%
Sammeln Sie Punkte in unserem Gutscheinprogramm und kaufen Sie E-Books und Hörbücher mit bis zu 100% Rabatt.
Mehr erfahren.
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Why another book on software project management? For some time, the fields of project management, computer science,and software development have been growing rapidly andconcurrently. Effective support for the enterprise demands themerging of these efforts into a coordinated discipline, one thatincorporates best practices from both systems development andproject management life cycles. Robert K. Wysocki creates thatdiscipline in this book--a ready reference for professionals andconsultants as well as a textbook for students of computerinformation systems and project management. By their very nature, software projects defy a "one size fits all"approach. In these pages you will learn to apply best-practiceprinciples while maintaining the flexibility that's essential forsuccessful software development. Learn how to make the planning process fit the need * Understand how and why software development must be planned on acertainty-to-uncertainty continuum * Categorize your projects on a four-quadrant model * Learn when to use each of the five SDPM strategies--Linear,Incremental, Iterative, Adaptive, and Extreme * Explore the benefits of each strategic model and what types ofprojects it supports best * Recognize the activities that go into the Scoping, Planning,Launching, Monitoring/Controlling, and Closing phases of eachstrategy * Apply this knowledge to the specific projects you manage * Get a clear picture of where you are and how to get where youwant to go
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 826
Veröffentlichungsjahr: 2010
0,0
Bewertungen werden von Nutzern von Legimi sowie anderen Partner-Webseiten vergeben.
Legimi prüft nicht, ob Rezensionen von Nutzern stammen, die den betreffenden Titel tatsächlich gekauft oder gelesen/gehört haben. Wir entfernen aber gefälschte Rezensionen.
Ähnliche
Table of Contents
Title Page
Copyright Page
ABOUT THE AUTHOR
CREDITS
Foreword
Introduction
Why Another Book on Software Project Management?
What Is This Book About?
What Is the Purpose of This Book?
Who Should Read This Book?
How Will You Benefit from Reading This Book?
How Is This Book Organized?
What Are the Features of the Book?
What’s on the Web Site?
How Should You Read This Book?
Summary
PART ONE - The Evolving State of ESPM
CHAPTER 1 - The Changing Landscape of Software Development
What Is a Software Development Project?
What Is Software Development Project Management?
The Complexity/Uncertainty Domain of SDPM
Balancing Staff, Process, Technology
Discussion Questions
CHAPTER 2 - SDPM Roadmap
The Contemporary Software Development Landscape
A Generic Template for Discussing SDPM Strategies
Discussion Questions
PART TWO - Linear ESPM
CHAPTER 3 - Linear SDPM Strategy
The Linear SDPM Strategy
Types of Linear SDPM Strategies
Discussion Questions
CHAPTER 4 - The Linear SDPM Scoping Phase
Solution Definition
Requirements Gathering
Customer Sign-Off on Requirements
Project Overview Statement
Discussion Questions
CHAPTER 5 - The Linear SDPM Planning Phase
Work Breakdown Structure Template
Dependency Diagramming
Project Scheduling
Resource Requirements
Discussion Questions
CHAPTER 6 - The Linear SDPM Launching Phase
Team Leadership Model
Organizing the Linear SDPM Strategy Project Team
Managing Concurrent Swim Lanes
Discussion Questions
CHAPTER 7 - The Linear SDPM Monitoring and Controlling Phase
Project Review Sessions
Scope Change Management
Milestone Trend Charts
Discussion Questions
CHAPTER 8 - The Linear SDPM Closing Phase
Requirements Validation
Acceptance Test Procedures
Customer Sign-Off
The Closing Phase
Lessons Learned
Discussion Questions
CHAPTER 9 - The Linear SDPM Strategy Summary
Comparing and Contrasting the SDPM Models
Points to Remember
Discussion Questions
PART THREE - Incremental ESPM
CHAPTER 10 - Incremental SDPM Strategy
The Incremental SDPM Strategy
Types of Incremental SDPM Strategies
Discussion Questions
CHAPTER 11 - The Incremental SDPM Scoping Phase
The Scoping Phase of an Incremental SDPM Strategy
The Scoping Phase of the Incremental SDPM Strategy for the Staged Delivery ...
The Scoping Phase of the Incremental SDPM Strategy for the Feature-Driven ...
The Role of the RBS
The Role of the Precedence Diagram
Discussion Questions
CHAPTER 12 - The Incremental SDPM Planning Phase
The Planning Phase of an Incremental SDPM Strategy
The Planning Phase of an Incremental SDPM Strategy for the Staged Delivery ...
The Planning Phase of an Incremental SDPM Strategy for the Feature-Driven ...
Discussion Questions
CHAPTER 13 - The Incremental SDPM Launching Phase
The Launching Phase of an Incremental SDPM Strategy
The Launching Phase of an Incremental SDPM Strategy for the Staged Waterfall Model
The Launching Phase of an Incremental SDPM Strategy for the Feature-Driven ...
Discussion Questions
CHAPTER 14 - The Incremental SDPM Monitoring and Controlling Phase
The Monitoring and Controlling Phase of an Incremental SDPM Strategy
Project Review Sessions
Scope Change Management
Discussion Questions
CHAPTER 15 - The Incremental SDPM Closing Phase
The Closing Phase of the Incremental SDPM Strategy
Incremental SDPM Strategy for the Closing Phase of the Staged Delivery ...
Incremental SDPM Strategy for the Closing Phase of the Feature-Driven ...
Discussion Questions
CHAPTER 16 - The Incremental SDPM Strategy Summary
Comparing and Contrasting the SDPM Models
Points to Remember
Discussion Questions
PART FOUR - Iterative ESPM
CHAPTER 17 - Iterative SDPM Strategy
The Iterative SDPM Strategy
Types of Iterative SDPM Strategies
Discussion Questions
CHAPTER 18 - The Iterative SDPM Scoping Phase
The Scoping Phase of an Iterative SDPM Strategy
The Scoping Phase of the Iterative SDPM Strategy for the Evolutionary ...
The Scoping Phase of the Iterative SDPM Strategy for the SCRUM Model
The Scoping Phase of the Iterative SDPM Strategy for the Rational Unified ...
The Scoping Phase of the Iterative SDPM Strategy for the Dynamic Systems ...
Discussion Questions
CHAPTER 19 - The Iterative SDPM Planning Phase
The Planning Phase of an Iterative SDPM Strategy
The Planning Phase of an Iterative SDPM Strategy for the Evolutionary ...
The Planning Phase of an Iterative SDPM Strategy for the SCRUM Model
The Planning Phase of an Iterative SDPM Strategy for the Rational Unified ...
The Planning Phase of an Iterative SDPM Strategy for the Dynamic Systems ...
Discussion Questions
CHAPTER 20 - The Iterative SDPM Launching Phase
The Launching Phase of an Iterative SDPM Strategy
The Launching Phase of an Iterative SDPM Strategy for the Evolutionary ...
The Launching Phase of an Iterative SDPM Strategy for the SCRUM Model
The Launching Phase of an Iterative SDPM Strategy for the Rational Unified ...
The Launching Phase of an Iterative SDPM Strategy for the Dynamic Systems ...
Discussion Questions
CHAPTER 21 - The Iterative SDPM Monitoring and Controlling Phase
The Monitoring and Controlling Phase of an Iterative SDPM Strategy
The Monitoring and Controlling Phase of an Iterative SDPM Strategy for the ...
The Monitoring and Controlling Phase of an Iterative SDPM Strategy for the ...
The Monitoring and Controlling Phase of an Iterative SDPM Strategy for the ...
The Monitoring and Controlling Phase of an Iterative SDPM Strategy for the ...
Discussion Questions
CHAPTER 22 - The Iterative SDPM Closing Phase
The Closing Phase of the Iterative SDPM Strategy
Iterative SDPM Strategy for the Closing Phase of the Evolutionary Development ...
Iterative SDPM Strategy for the Closing Phase of the SCRUM Model
Iterative SDPM Strategy for the Closing Phase of the Rational Unified Process Model
Iterative SDPM Strategy for the Closing Phase of the Dynamic Systems ...
Discussion Questions
CHAPTER 23 - The Iterative SDPM Strategy Summary
Traditional Versus Agile Projects
Traditional Versus Agile Project Managers
Traditional Versus Agile Teams
Traditional Versus Agile Project Planning
Traditional Versus Agile Scope Change Management
Discussion Question
PART FIVE - Adaptive ESPM
CHAPTER 24 - Adaptive SDPM Strategy
The Adaptive SDPM Strategy
Types of Adaptive SDPM Strategies
Discussion Questions
CHAPTER 25 - The Adaptive SDPM Scoping Phase
The Scope Phase of an Adaptive SDPM Strategy
The Scoping Phase of the Adaptive SDPM Strategy for the Adaptive Project ...
The Scoping Phase of the Adaptive SDPM Strategy for the Adaptive Software ...
Discussion Questions
CHAPTER 26 - The Adaptive SDPM Planning Phase
The Planning Phase of an Adaptive SDPM Strategy
The Planning Phase of an Adaptive SDPM Strategy for the Adaptive Project ...
The Planning Phase of an Adaptive SDPM Strategy for the Adaptive Software ...
Discussion Questions
CHAPTER 27 - The Adaptive SDPM Launching Phase
The Launching Phase of an Adaptive SDPM Strategy
The Launching Phase of an Iterative SDPM Strategy for the Adaptive Project ...
The Launching Phase of an Adaptive SDPM Strategy for the Adaptive Software ...
Discussion Question
CHAPTER 28 - The Adaptive SDPM Monitoring and Controlling Phase
The Monitoring and Controlling Phase of an Adaptive SDPM Strategy
The Monitoring and Controlling Phase of an Adaptive SDPM Strategy for the ...
The Monitoring and Controlling Phase of an Iterative SDPM Strategy for the ...
Discussion Question
CHAPTER 29 - The Adaptive SDPM Closing Phase
The Closing Phase of the Adaptive SDPM Strategy
Iterative SDPM Strategy for the Closing Phase of the Adaptive Project Framework Model
Adaptive SDPM Strategy for the Closing Phase of the Adaptive Software ...
Discussion Question
CHAPTER 30 - The Adaptive SDPM Strategy Summary
Traditional Versus Adaptive Projects
Traditional Versus Adaptive Project Managers
Traditional Versus Adaptive Teams
Traditional Versus Adaptive Project Planning
Traditional Versus Adaptive Scope Change Management
Discussion Question
PART SIX - Extreme ESPM
CHAPTER 31 - Extreme SDPM Strategy
The Extreme SDPM Strategy
Types of Extreme SDPM Strategies
Discussion Questions
CHAPTER 32 - The Extreme SDPM Scoping Phase
The Scoping Phase of an Extreme SDPM Strategy
The Scoping Phase of the Extreme SDPM Strategy for the INSPIRE Model
The Scoping Phase of the Extreme SDPM Strategy for the Flexible Model
Discussion Question
CHAPTER 33 - The Extreme SDPM Planning Phase
The Planning Phase of an Extreme SDPM Strategy
The Planning Phase of an Extreme SDPM Strategy for the INSPIRE Model
The Planning Phase of an Extreme SDPM Strategy for the Flexible Model
Discussion Questions
CHAPTER 34 - The Extreme SDPM Launching Phase
The Launching Phase of an Extreme SDPM Strategy
The Launching Phase of an Extreme SDPM Strategy for the INSPIRE Model
The Launching Phase of an Extreme SDPM Strategy for the Flexible Project Model
Discussion Question
CHAPTER 35 - The Extreme SDPM Monitoring and Controlling Phase
The Monitoring and Controlling Phase of an Extreme SDPM Strategy
The Monitoring and Control Phase of an Extreme SDPM Strategy for the INSPIRE Model
The Monitoring and Controlling Phase of an Extreme SDPM Strategy for the ...
Discussion Question
CHAPTER 36 - The Extreme SDPM Closing Phase
The Closing Phase of the Extreme SDPM Strategy
Iterative SDPM Strategy for the Closing Phase of the INSPIRE Model
Extreme SDPM Strategy for the Closing Phase of the Flexible Model
Discussion Question
CHAPTER 37 - The Extreme SDPM Strategy Summary
Traditional Versus Extreme Projects
Traditional Versus Extreme Project Managers
Traditional Versus Extreme Teams
Traditional Versus Extreme Project Planning
Traditional Versus Extreme Scope Change Management
Discussion Question
PART SEVEN - In Summary
CHAPTER 38 - Where Are You?
The Perspective of the Enterprise
From the Perspective of the Customer
From the Perspective of the Project Manager
From the Perspective of the Development Team
Tracking Where You Are
Discussion Question
CHAPTER 39 - Where Do You Want To Go and How Can You Get There?
Where Do You Want To Go?
How Will You Get There?
Discussion Questions
APPENDIX A - What’s on the Web Site?
APPENDIX B - Bibliography
APPENDIX C - The Project Overview Statement
APPENDIX D - Requirements Gathering
APPENDIX E - The Work Breakdown Structure
APPENDIX F - Estimation
APPENDIX G - The Project Network Diagram
APPENDIX H - The Resource Schedule
APPENDIX I - Organizing the Project Team
CHAPTER J - Project Performance Reporting
APPENDIX K - Business Process Flow Diagramming
INDEX
Effective Software Project ManagementPublished by Wiley Publishing, Inc. 10475 Crosspoint Boulevard Indianapolis, IN 46256 www.wiley.com
Copyright © 2006 by Robert K. Wysocki
Published by Wiley Publishing, Inc., Indianapolis, Indiana Published simultaneously in Canada
ISBN-13: 978-0-7645-9636-0 ISBN-10: 0-7645-9636-5
1B/QX/QT/QW/IN
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.
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 or to obtain technical support, please contact our Customer Care Department within the U.S. at (800) 762-2974, outside the U.S. at (317) 572-3993 or fax (317) 572-4002.
Library of Congress Cataloging-in-Publication Data
Wysocki, Robert K.
Effective software project management / Robert K. Wysocki.
p. cm.
Includes index.
1. Computer software—Development—Management. I. Title.
QA76.76.D47W97 2006
005.3’068—dc22
2005034341
Trademarks: Wiley and the Wiley logo are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries, and may not be used without written permission. All other trademarks are the property of their respective owners. Wiley Publishing, Inc., is not associated with any product or vendor mentioned in this book.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books.
ABOUT THE AUTHOR
Robert K. Wysocki, Ph.D., has over 40 years experience as a project management consultant and trainer, information systems manager, systems and management consultant, author, training developer, and provider. He has written 14 books on project management and information systems management. One of his books, Effective Project Management: Traditional, Adaptive, Extreme, Third Edition (Wiley, 2003), has been a best-seller and is recommended by the Project Management Institute for the library of every project manager. He has over 30 publications in professional and trade journals and has made more than 100 presentations at professional and trade conferences and meetings. He has developed more than 20 project management courses and trained over 10,000 project managers.
From 1963 to 1970 he was a systems consultant for one of the world’s largest electronics components manufacturers. In that capacity he designed and implemented several computer-based manufacturing and quality control systems. From 1970 to 1990 he held a number of positions in both state supported and private institutions in higher education as MBA Director, Associate Dean of Business, Dean of Computers and Information Systems, Director of Academic Computing, CIO, and Senior Planner.
In 1990, he founded Enterprise Information Insights, Inc. (EII), a project management consulting and training practice specializing in agile project management methodology design and integration, project support office establishment, the development of training curriculum, and the development of a portfolio of assessment tools focused on organizations, project teams, and individuals. His client list includes AT&T, Aetna, Babbage Simmel, BMW, British Computer Society, Boston University Corporate Education Center, Computerworld, Converse Shoes, the Czechoslovakian Government, Data General, Digital, Eli Lilly, Harvard Community Health Plan, IBM, J. Walter Thompson, Ohio State University, Peoples Bank, Sapient Corporation, The Limited, The State of Ohio, Travelers Insurance, TVA, the U.S. Coast Guard Academy, Wal-Mart, and several others.
He is a Senior Consultant at the Cutter Consortium where he is an active member of the Agile Project Management Practice. He has consulted widely in agile project management with such companies as Sapient, Wells Fargo, Wal-Mart, Blue Cross Blue Shield of Massachusetts, the TVA, and others. He is vice-president and president elect of APLN, a member of ASAPM and the Agile Alliance. He also serves as advisor to Project Summit and Business Analyst World. He is a member of the Project Management Institute, the American Society of Training & Development, and the Society of Human Resource Management. He is past association vice president of AITP (formerly DPMA). He earned a B.A. in Mathematics from the University of Dallas, and an M.S. and Ph.D. in Mathematical Statistics from Southern Methodist University.
CREDITS
Executive EditorBob Elliott
Senior Development EditorKevin Kent
Production EditorPamela Hanley
Copy EditorNancy Rapoport
Editorial ManagerMary Beth Wakefield
Production ManagerTim Tate
Vice President and ExecutiveGroup PublisherRichard Swadley
Vice President and ExecutivePublisherJoseph B. Wikert
Project CoordinatorRyan Steffen
Graphics and Production SpecialistsDenny Hager Jennifer Heleine Stephanie D. Jumper Alicia B. South
Quality Control TechnicianJoe Niesen
Media Development CoordinatorLaura Atkinson
Proofreading and IndexingTECHBOOKS Production Services
FOREWORD
The Declaration of Interdependence (that Bob Wysocki, I, and others co-authored) documents the fundamental principles that underlie an agile-adaptive approach to project management. (See www.apln.org for the complete Declaration.) Two of these principles, are particularly relevant to this book:
• We improve effectiveness and reliability through situationally specific strategies, processes, and practices.
• We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
No two people are alike. No two teams are alike. No two projects are alike. Yet many organizations and project managers attempt to “standardize” projects, essentially trying again and again and again to pound square pegs into round holes. I’ve watched team after team attack high-risk, high-uncertainty projects with meticulously laid out plans that were complete and utter fantasy. Furthermore, most team members knew that the plan was fantasy, but if you have only square pegs, you use square pegs.
Bob introduces us to square, round, triangular, and polygonal pegs—just the right one for specific situations. But even better, he helps us figure what kinds of holes we have. It’s one thing to have a principle that says “situationally specific,” but what are the situations? How many do we have? What are the key characteristics that define a “situation” for a project manager? Bob introduces us to a simple but powerful concept to guide practitioners in defining holes (the situation) and then presents us with a suite of pegs (solutions) that fit each type of hole.
Bob defines project situations using a four-quadrant analysis of the certainty, or uncertainty, of both ends and means. With some projects the ends, the business objectives and specific software requirements that enable us to meet the objectives, are fairly well known. On others, they are ill defined in the beginning and have to evolve over the life of the project as more is learned. Some projects may utilize a well-understood and proven technology, while others employ bleeding edge, state-of-the-art technology. When square peg project managers meet uncertainty, they try to pound out that uncertainty with a detail plan—but in reality that meticulous plan is nothing more than a superstition about the future. However, when the objectives, requirements, and technology are well known, we should be able to plan the project with some assurances that we can meet the plans for scope, schedule, and cost.
To differentiate projects using a slightly different analogy, when both ends and means are well known, we can utilize a traditional Plan-Do strategy in which we lay out the plan and then execute the steps. When both ends and means are not well known, the strategy could better be described as Envision-Explore. We lay out a rough plan, but we assume that significant changes will occur as we learn more during the project. The problem that many square-peg project managers fail to grasp is that many, if not most, high-risk and high-uncertainty issues cannot be “planned” away—they can only be “executed” away. You have to experiment with different options in order to attack uncertainty.
So the certainty-uncertainty of both ends and means provides us with a framework for identifying holes—specific situations. Bob next turns to the pegs—strategies that fit certain problems—strategy options that are absolutely critical in managing the variety of projects that organizations undertake today.
It is important to recognize that strategies and practices are separate things. Some people incorrectly think a particular practice is “agile,” while another is “traditional.” However, good practices can be used in either a traditional or an agile project (daily team meetings, for example). The critical factor in project management is strategy—the specific model of delivery one chooses to utilize.
Here again Bob elevates us from the simplistic—traditional or agile solutions—to a wider, richer strategy selection. He identifies four uniquely different strategies—Linear & Incremental, Iterative, Adaptive, and Extreme—and then provides us with the characteristics, advantages, and weaknesses of each.
In particular, Bob spends the bulk of the book delving into the latter three strategies—Iterative, Adaptive, and Extreme—because as the Declaration of Interdependence principle states, “We expect uncertainty and manage for it through iterations, anticipation, and adaptation.” Today, when more and more projects occupy the uncertainty of ends and means category (and the highest valued ones also), newer Adaptive and Extreme strategies are needed. Bob not only identifies these strategies, but defines them in enough detail that practitioners can effectively utilize them.
If you are tired of trying to stuff square pegs in round holes, if you are having trouble with projects where uncertainty and high risk create floundering projects, then this is the book you need to read.
Jim Highsmith Flagstaff, Arizona November 2005
INTRODUCTION
. . . Global 2000 companies will merge their SDLC (systems development life cycle) and PM (project management) strategies to develop domain specific “ILDEs” (integrated lifecycle and development environments) . . . how dysfunctional large companies are if they run Project Management Institute (PMI) guidance in their Project Management Office (PMO) whilst running Rational Unified Process (RUP) as their SDLC in the IT organization. . . . The most competitive companies will be the ones who merge the two schools of thought to deliver optimal value and efficiency by eliminating dysfunctional competitiveness between the project management process and the software lifecycle process.Adapted from Melinda-Carol Ballou “Coordinating Project and Software Life-cycle Processes,” META Group, November 2003, by David J. Anderson in a private communication
We are experiencing the convergence of two disciplines that will result in the creation of yet another discipline. The two disciplines are software development and project management. It is a convergence that is being formed out of necessity. We call this new discipline effective software project management (ESPM). It is the topic of this book.
Why Another Book on Software Project Management?
Modern project management is about 50 years old. It grew out of the engineering discipline as a management approach for construction projects. Concurrent with this development, the computer emerged as a primitive tool for businesses. The concurrent growth of project management, the computer as a commercial tool, and software development brought the need for all three to be merged into a discipline to support the enterprise. Today, that need is even more visible for several reasons:
• The discipline of project management is faced with major challenges especially in its ability to support advances in the software development arena
• There is a need to bring together a unified body of knowledge on project management for the software developer
• The practices of project management and software development need to mature into a strategic partnership to lead the formation of processes for the contemporary enterprise
• There is a need for a practical “how to” book that combines in a balanced framework the best practices from systems development life cycles (SDLC) and project management life cycles (PMLC)
These are the driving forces that led me to write this book. There is no book in the market that treats both of these topics in the integrated fashion and to the balanced depth as does this book.
What Is This Book About?
The literature abounds with books on information technology project management but they give passing treatment to how project management processes are applied to specific systems development methodologies. Similarly, there are a variety of books on specific systems development methodologies that do not provide in-depth treatment of project management as it relates to the systems development methodology. The missing piece is a book that gives equal treatment to project management as applied to specific systems development methodologies. Filling that gap is what this book is all about.
What Is the Purpose of This Book?
There are three purposes for this book:
• To be a professional reference for software professionals—The major software development models are discussed in this book along with the specific application of project management best practices to the management of those projects. In one place, software professionals can find everything they need to successfully manage their software development projects. In other words, this book is one-stop-shopping for the software development project manager.
• To give project management consultants a single source for software development project management principles and practices—For project management consultants whose clients are in the information technology business this book should be a constant companion. This book is a single source of in-depth application of project management best practices to the various needs of the information technology client.
• To be a textbook for students of computer information systems and project management—The companion book is Effective Project Management: Traditional, Adaptive, Extreme, Third Edition (Wiley, 2003). It was an experiment to write a book for both the professional reference market and the academic market. That experiment was a success as sales to the professional market continue to be healthy, and our new readers in the academic world adopt the book for their credit and non-credit courses at the undergraduate and graduate level. The book has been adopted in over 50 colleges and universities at the undergraduate, graduate, and continuing education markets. A number of training providers are also using the book as a supplement to their course materials. Our expectation is that this book will enjoy similar success in the academic market.
Who Should Read This Book?
The book is written both as a comprehensive reference for professional software development project managers and aspiring software development project managers and as a textbook for undergraduate and graduate students of computers and information systems and project management. It is my hope that this book will become a de facto source for all your software development project manager tool, template, and process needs. Anyone who aspires to successfully manage software development projects or successfully manage those who manage software development projects is a targeted reader. Specifically, the target markets are listed in the following sections, and how this book serves the needs of those markets is briefly discussed.
Seasoned Project Managers
You might have a varied and successful career as a project manager, perhaps serving the needs of the software developer. In this book I bring together in one reference a number of best practices in software development project management. If you are a project manager who is looking for an introduction to the management of software development projects, this book will serve that purpose. It is both introductory and advanced and will have a long and useful lifetime for you.
Frustrated Project Managers
Perhaps you have a history of less than stellar performance in the management of software development projects. In many cases you have tried unsuccessfully to adapt your current toolbox of management practices with limited success. You are no doubt looking for more, and this book is just the place. In this book, a number of best project management practices are adapted to the specific management requirements of various types of software development projects.
“Wanna Be” Project Managers
If you are new to software development project management, this book provides a solid foundation as well as the more advanced topics for the special management needs of more complex software development projects. This book is a fast-track introduction and an in-depth treatment of all you need to launch and grow a successful career as a software development project manager.
Occasional Project Managers
This book is a ready reference for those you project managers who haven’t mastered the more complex types of software development project management situations and need a reference that is “recipe oriented.” Your need is for guidance from day one to day last in software development projects. This book is an excellent fit for you.
Project Management Consultants and Software Development Consultants
As a consultant, you don’t often have the luxury of searching for that seldom needed solution. For you, this book is the reference for every viable integration of software development and project management. This is your “one-stop shopping” source.
Software Developers
Many software developers have depended on the systems development life cycle as a substitute for many parts of the project management life cycle. In many cases, the results have been less than expected. In this book, you will find a practical solution to the integration of software development and project management best practices. The result is to gain the skills and competencies to work smarter, not harder.
Software Development Managers
If you are a software development manager, by integrating project management best practices into the software development life cycle you will have a repeatable framework within which to better manage you business unit. This book contains a number of such management aids to meet your specific needs.
Project Management Instructors and Trainers and Software Development Instructors and Trainers
Because this book is applications-oriented, it can serve as a complete reference and support text for your project management and software development classes and training sessions. Each chapter contains a number of thought provoking discussion questions. Answers to the discussion questions can be found by contacting the author at [email protected]. See the companion Web site for this book at www.wiley.com/go/espm for more support materials as well.
Computer Information Systems Students
The integration of software development and project management is inevitable, and this book aims to be the de facto book on the topic. If you are a serious student of ESPM, you will want this book in your library.
Students
Whether you are an independent learner or are taking credit or non-credit course work in software development and project management, this book has something for you and may prove indispensable. It can serve as the primary text or as a supplemental reference text in courses in software development or software project management.
How Will You Benefit from Reading This Book?
In one place, the software developer can learn how project management best practices can support the effective completion of their project.
In one place, the project manager can see the connections between their discipline and effective software development.
In total, the software developer as project manager can reliably and repeatedly deliver software development projects.
How Is This Book Organized?
The book is organized into seven parts. Parts II through VI are structured to be as parallel as possible to facilitate finding, interpreting, and comparing information on different types of software development projects and their project management infrastructures.
NOTE
As you read through the following introduction to how the book is organized, don’t be put off if you don’t recognize all the terms or concepts mentioned. All these ideas, processes, and models are explained thoroughly as you progress through the book.
Part I: The Evolving State of ESPM
This introductory part provides a survey of both the project management landscape and the software development landscape. Both have been evolving independently of one another. The project management landscape is dotted with approaches that have not met the expectations of customers and clients. The failure rates of projects are beyond reasonable expectations, but little seems to have been done to reduce the unacceptably high failure rates. At the same time the software development landscape is dotted with a myriad of approaches for every conceivable type of software development situation. Some succeed while others fail. There seems to be a gap between the two situations. That gap is the lack of an integrated approach to software development project management.
The literature is filled with books that have a strong focus on software development with only brief treatment of project management. This book fills that gap. It gives equitable treatment to both topics and integrates them at a depth and breadth previously not available in the literature.
The underlying structure of this book is based on the certainty to uncertainty continuum, which is unique to this book. All software development models can be arrayed on this continuum. The linear models of Part II lie at the certainty end of this continuum. Parts III through VI discuss models that fall along this continuum from the certainty end to the uncertainty end.
Part I consists of two chapters.
Chapter 1: The Changing Landscape of Software Development
This chapter provides the conceptual foundation for the entire software development project management (SDPM) discipline. It categorizes projects based on the extent of goal clarity and solution clarity. It defines a four quadrant model as the basis of a discussion of risk, team cohesion, communications, customer involvement, change, specification, and business value.
Chapter 2: SDPM Roadmap
This chapter presents a high-level overview of the five SDPM strategies and the specific models that can be found in each strategy. For each strategy, I discuss the characteristics, strengths, and weaknesses.
Part II: Linear ESPM
Linear approaches to software development started with the definition of the Waterfall model. While the Waterfall model was designed to move sequentially from idea through deployment it was an approach that afforded no looking back. Once a phase was completed and approved, it was not visited again. That works as long as requirements are clearly and completely documented and there are no change requests from the client.
Part II has seven chapters.
Chapter 3: Linear SDPM Strategy
The introductory chapter in each of Parts II through VI defines the software project management life cycle of the project types covered in that part. There will be some variation to the Scope, Plan, Launch, Monitor/Control, and Close Phases because of the nature of the software development process being managed. The Linear SDPM type projects consist of the Standard Waterfall and Rapid Development Waterfall models.
Chapter 4: The Linear SDPM Scoping Phase
Because of the nature of Linear software development projects, requirements are completely and clearly identified and documented. A brief document called the Project Overview Statement is prepared and signed off by client and project manager.
Chapter 5: The Linear SDPM Planning Phase
Across all software development project types, the Planning Phase can run from very formal to very informal. Despite that, all of the tools, templates, and processes will be evident in some part of the Planning Phase. The focus here will be on the WBS, scheduling, and resource requirements.
Chapter 6: The Linear SDPM Launching Phase
Regardless of the software development approach being taken, the team needs to figure out how they are going to work together and establish the rules that will govern the engagement. The unique aspect of the Rapid Development Waterfall model is the use of concurrent development paths. These are called “swim lanes” and are a central focus in this chapter.
Chapter 7: The Linear SDPM Monitoring and Controlling Phase
The project work is underway. The focus in this chapter is on measuring project progress and performance. Part of that includes project review sessions and scope change management.
Chapter 8: The Linear SDPM Closing Phase
Through the acceptance procedures, the client will validate that requirements have been met, and it is time to deploy the software to the users. Lessons learned will be a big part of the closing activities, as will the celebration of success by the team.
Chapter 9: The Linear SDPM Strategy Summary
Each part ends with a chapter that compares and contrasts the models presented. In this chapter I discuss risk, change tolerance of the models, and team structures.
Part III: Incremental ESPM
The next set of variations that I cover involves Incremental models. Here, the full functionality is introduced in chunks. Deliverables are put into production status in sequence—each chunk adding more functionality than the last so that the system grows. In addition to getting business value earlier, the client may discover improvements that can be incorporated into later chunks. Whereas the Linear models are change intolerant, the Incremental models at least allow for some change.
Part III has seven chapters.
Chapter 10: Incremental SDPM Strategy
The Incremental SDPM is nothing more than a string of Linear SDPMs. Each Linear chunk adds another piece to the solution until eventually the complete solution emerges. Other than that, the only other difference is that partial solutions are put into production earlier and business value accrues. The Linear SDPM strategy deploys all functionality at the end of the project. Another way of looking at the difference is that the Linear model is the Incremental model with only one increment. The Staged Delivery Waterfall and the Feature-Driven Development model are the two variations discussed in Part III.
Chapter 11: The Incremental SDPM Scoping Phase
The Scoping Phase of the Incremental model and the Linear model are the same. Requirements are gathered and documented the same way. That means that the choice of Linear or Incremental can be postponed until requirements are gathered. Any concern that requirements may not be complete and clear may lead you to decide on using the Incremental model rather than the Linear model.
Chapter 12: The Incremental SDPM Planning Phase
Planning for the Incremental model requires a strategy for chunking the functionality into separate and dependent chunks. Each chunk should have enough functionality content to make it a useful partial solution that can be put into production status while waiting for the addition of the next chunk. The Function/ Feature Breakdown Structure is introduced as an aid to chunking.
Chapter 13: The Incremental SDPM Launching Phase
The project team may change at each increment, which is not the case with the Linear model. That places some additional burdens on each team. They will have to ensure a clean hand-off from team to team as the project moves from increment to increment.
Chapter 14: The Incremental SDPM Monitoring and Controlling Phase
Within each increment, the monitoring and controlling activities are the same as with the Linear model. The major area of concern is scope change management. Scope changes approved in one increment may affect later increments, and that needs to be accounted for in the scope change management process.
Chapter 15: The Incremental SDPM Closing Phase
The Closing Phase within each increment is the handoff activity from one team to another. That handoff will require some documentation different than if it were a Linear model.
Chapter 16: The Incremental SDPM Strategy Summary
There are only three points of comparison and contrast here. The first deals with introducing interim releases at each increment as compared to one for the Linear model, the second with the scope change management process, and the third with the handoff between increments.
Part IV: Iterative ESPM
The differences between the Incremental model and the Iterative model are vast. The Iterative model is used when functionality, requirements, and features are only partially known at the outset, and it is up to the model chosen to clarify that information. In Iterative ESPM the solution as it is known at each iteration is built and deployed. It is used and then modified in the next iteration. This process continues until the required solution is built.
Part IV has seven chapters.
Chapter 17: Iterative SDPM Strategy
An iteration is defined here as a development cycle that adds more functionality and/or features to an incomplete solution in order to have it converge on a complete solution. While iteration is easy to define, it has a number of variations that you will have to take into account. For example, you can iterate on any of the following requirements: design, functionality, features, usability, or code. There are four models that fit into the Iterative SDPM strategy group: Dynamic Systems Development Method (DSDM), Evolutionary Systems Development, Rational Unified Process (RUP), and SCRUM (not an acronym but a term used in rugby).
Chapter 18: The Iterative SDPM Scoping Phase
The major departure here from the previous two types of software development projects is the absence of a complete specification of requirements. The remaining three types of software development projects all have this in common but at different levels of incompleteness. These three types are collectively called “agile software development” and they are managed using “agile project management” approaches. The Iterative SDPM strategy is the first of the three I will discuss. Requirements gathering is by definition not something that can be completely done at the outset in an Iterative SDPM strategy. You can complete only part of it and will have to depend on the software development approach you take and the project management infrastructure to identify the remaining requirements. In other words, this and the next two SDPM strategies are characterized by processes of learning and discovery.
Chapter 19: The Iterative SDPM Planning Phase
All of the Iterative software development approaches depend on “just-in-time planning.” Only the next iteration will be planned, and it will be planned at the completion of the immediately preceding iteration.
Chapter 20: The Iterative SDPM Launching Phase
The team leadership models and team operating rules are very different for Iterative SDPM projects as compared to those you have studied so far. Even within the group of Iterative SDPM models, the leadership and team operating rules differ widely.
Chapter 21: The Iterative SDPM Monitoring and Controlling Phase
The further out you go in terms of uncertainty in the project the less formal you are in terms of project status reporting. Written reports become quite rare in the uncertain project environment. In these types of projects you are primarily looking for signs that the project is converging to an acceptable solution.
Chapter 22: The Iterative SDPM Closing Phase
Each iteration will have its own Closing Phase. It includes activities with the client to decide how to go forward (or even if to go forward) to the next iteration and what the next iteration will contain.
Chapter 23:The Iterative SDPM Strategy Summary
There are considerable differences between the four models that fall in the Iterative SDPM category. In this chapter, I present those differences and discuss selection strategies.
Part V: Adaptive ESPM
In this part I present two software development project management approaches to those projects whose goal is clear but whose solution is not. In informal surveys the vast majority of respondents confirm that adaptive approaches should be used in more than 75 percent of the software development projects. Unfortunately, many software developers try to adapt linear approaches when they clearly are a bad fit. The result is the high failure rate that accompanies such projects. The most notable difference between Iterative and Adaptive approaches is meaningful customer involvement. While a certain level of involvement is needed for Iterative approaches, that involvement increases dramatically as you transition to Adaptive ESPM.
Part V has seven chapters.
Chapter 24: The Adaptive SDPM Strategy
The Adaptive SDPM strategy is conceptually very different than the Iterative SDPM strategy. First there is the recognition that the solution is only partially known and must be discovered and integrated as the project work commences. Users of The Iterative SDPM strategy may not have to deal with that situation. While both life cycles are iterative, the role of the customer in the latter is direction setting where it is not in the Iterative ESPM life cycle. There are two models that follow the Adaptive SDPM strategy: Adaptive Project Framework (APF) and Adaptive Software Development (ASD). APF is a robust model in that it isn’t limited to software development, as is ASD. This chapter also discusses two variations to APF—business case justification and prototyping—and how APF can be embedded in other SDPM models.
Chapter 25: The Adaptive SDPM Scoping Phase
Scoping an Adaptive SDPM project is often a high-level activity. Because the solution is not known or at best partially known, scoping at a detailed level is something that happens over the cycles of the project. That means that requirements gathering and planning are also just-in-time activities.
Chapter 26: The Adaptive SDPM Planning Phase
As you move further into the uncertainty domain, Adaptive processes become lighter. By that I mean less documentation and formality are part of the project management approach. The transition is away from non-value-added work to value-added work. The Adaptive project is on an aggressive timeframe with frequent changes. Daily face-to-face team meetings take the place of internal status reports. Much more of a team aura pervades the project. The WBS becomes a just-in-time activity; dependency diagrams and formal project schedules give way to small team scheduling at the whiteboard. The critical path is meaningless in Adaptive project management.
Chapter 27: The Adaptive SDPM Launching Phase
In Adaptive SDPM, it is important that the team be solid and effective. Roles and responsibilities must be clearly understood. Team leadership becomes more of a coordinating activity because there will be any number of subteams working on some small aspect of the software system. Team leadership may change as the project transitions from phase to phase.
Chapter 28: The Adaptive SDPM Monitoring and Controlling Phase
The major difference here compared to the previous life cycles is that change is an integral part of the life cycle. It is not an add-on. It is a necessity. The solution will not be discovered unless change is driving the process.
Chapter 29: The Adaptive SDPM Closing Phase
At the completion of each iteration of an Adaptive SDPM project there is a checkpoint with the customer. This is a go/no go stage-gate for the project. There is a quality check on what has been done so far and a planning activity as newly discovered requirements, functionality, and features are integrated into the prioritization scheme and plans for the next iteration are formulated.
Chapter 30: The Adaptive SDPM Strategy Summary
The two models discussed in this part are compared and contrasted, and I discuss when to use them and when not to use them.
Part VI: Extreme ESPM
In Part VI, you have reached the models that deal with situations in which very little is known about the goal and perhaps nothing about the solution. Several ideas may be floating around as to what might generate a solution, but you may have little evidence to support those contentions. Think of it as a pure R&D situation, and you won’t be far off the mark.
Part VI has seven chapters.
Chapter 31: Extreme SDPM Strategy
The life cycle looks much like the Adaptive SDPM life cycle. The difference comes as you look inside each of the phases. Part VI covers several extreme-type models including INSPIRE and extreme programming.
Chapter 32: The Extreme SDPM Scoping Phase
In most cases scoping involves setting the boundaries of the project in terms of time and cost, cycle length, and other general parameters.
Chapter 33: The Extreme SDPM Planning Phase
Planning is just-in-time and not very detailed. The team and its subteams are left to direct their part of the project as they see fit. There are few standards because these would tend to stifle creativity.
Chapter 34: The Extreme SDPM Launching Phase
These are the activities that get the team started on the next iteration. There may be hand offs as new teams come into the picture to replace the previous cycle’s team.
Chapter 35: The Extreme SDPM Monitoring and Controlling Phase
Just as in the Adaptive SDPM, this is an informal process that is carried out among the team in its daily meetings. Customer involvement is very high and so little can be done that will stray from the project directives. Constant redirection and replanning is evident, even within an iteration.
Chapter 36: The Extreme SDPM Closing Phase
There are two Closing stages here. One is the Closing activities that pertain to the just completed iteration. The other is the Closing Phase that pertains to the project itself. The iteration closing activities consist of a review of what has been completed, an evaluation of whether or not the deliverables are converging on a solution, and a consideration of what should be done in the next iteration (assuming there is a next iteration). The project closing activities include the standard tasks: business value verification, post-implementation audit, and lessons learned.
Chapter 37: The Extreme SDPM Strategy Summary
The two models discussed in this part are compared and contrasted, and I discuss when to use them and when not to use them.
Part VII: In Summary
This is a comprehensive look back at the models in each of the SDPM strategies. I include an overall comparison, discuss the challenges yet to be faced, and offer suggestions of how you might approach each of the models.
Part VII has two chapters.
Chapter 38: Where Are You?
This is a closer look at the status of software development project management, its strengths and weaknesses, and the challenges yet to be faced.
Chapter 39: Where Do You Want to Go and How Can You Get There?
This is an attempt to envision an end state for software development project management and a plan to get there.
Appendixes
In addition to the chapters, you have two appendixes that can help direct you to further information and resources. Appendix A, “What’s on the Web Site,” explains what you will find if you surf to the Web site that’s associated with this book at www.wiley.com/go/espm. Then, in Appendix B, “Bibliography,” you will find a list of related materials for further reading.
Following these two appendixes are a number of appendixes that contain introductory materials for those who want to refresh their knowledge of the basics of project management. These appendixes include “The Project Overview Statement,” “Requirements Gathering,” “Work Breakdown Structure,” “Estimation,” “The Project Network Diagram,” “The Resource Schedule,” “Organizing the Project Team,” “Project Performance Reporting,” and “Business Process Flow Diagramming.”
What Are the Features of the Book?
This book is written in the same style and standards as my previous best-selling book: Effective Project Management: Traditional, Adaptive, Extreme, Third Edition (Wiley, 2003). This means the book has the following features:
• It is practice- and applications-oriented.
• It is readable.
• It provides intriguing and useful discussion questions.
• It makes figures and tables available for teacher/instructor use.
Practice- and Applications-Oriented
While all of my previous books have been grounded in concepts and principles, they all are practice- and applications-oriented. I’ve tried to maintain the research tradition in all that I write and at the same time spare you the task of translating theory to practice. At the same time I try to provide comparisons of different approaches to a problem so that you always know which approach to take and why. I will warn you of the traps. My vision is that you will have my books opened to the pages that discuss the “how to” aspects of a tool, template, or process as you are trying to implement them in your project.
Readable
In keeping with the practice and applications orientation, my writing style is conversational. I want you to feel like we are sitting across from one another having a conversation about some issue or topic. What I try to avoid is giving you a tome to read just to get a few nuggets of information. I am not verbose. I don’t have the time to write all those words, and you don’t have (or want) to spend the time to read them.
Discussion Questions for Instructors
The third edition of Effective Project Management: Traditional, Adaptive, Extreme departed somewhat from the second edition in that I tried to make that edition more appealing to the academic market while not sacrificing the professional market that had already been established with the second edition. By all measures that approach was successful, and the same style will be used here.
Each chapter ends with a few discussion questions that might be used by instructors to create some dialog with the class or might be used for written assignments. These are not your favorite “list the ten causes of the Civil War” type questions, but rather they are questions that I hope will be thought provoking. There are no right answers, although there are plenty of wrong answers. An answer file has been created for instructors. Just e-mail me at rkw@eiicorp com, identify yourself as a legitimate instructor or faculty member, and I’ll send you the answer file. I’d love to hear from you and hear how you are using the book and its materials.
Files of Figures and Tables
For the benefit of instructors and others who might want to use the figures and tables from the text, I have prepared files containing all of that information. All I ask is that you give the proper attributions for the source of your materials.
What’s on the Web Site?
A registered Web site has been built for readers of this book. There you will find the files of figures and tables previously mentioned. This Web site may be accessed at www.wiley.com/go/espm.
How Should You Read This Book?
Front to back would be a straightforward approach to reading this book and would support the needs of the academic market. The typical credit course might cover the book from Chapter 1 through Chapter 39. However, if you or your students need some background in project management, the appendixes can be quickly reviewed.
However, if you have more specific needs, each part can be read and referenced independently of any other part. Each part is targeted to a specific model type to accommodate the reference and application needs of the professional market. Each part is self-contained so that the practicing professional need refer only to the part appropriate to their project application. There is no need to read the entire book if your need is for a specific strategy.
Summary
My intent with this book is to bring together a breadth and depth of materials on software development life cycles and the project management tools, templates, and processes to support them. I have integrated the two disciplines. As far as I know this is the first book that can make that claim. I’ll let you be the judge as to whether or not I have met that objective and provided you with a unique reference book on the new and emerging discipline of software development project management. Good luck and may all your software development projects be effective and successful!
PART ONE
The Evolving State of ESPM
No one would argue that software development has undergone a major change in the past decade. On what seems to be a continuous basis you are bombarded with the latest and greatest models, tools, templates, and processes. You may be confused and wonder which of these, if any, make any sense. Should you use this one or that one or maybe the same one for all software development projects?
In this part I will lay the groundwork for what proposes to be the introduction of a new discipline—one that fully integrates software development life cycles and project management life cycles. This is the first attempt at defining such a discipline. Much remains to be done. But at least I can lay claim to trying to bring some order out of the seeming chaos faced by software developers and their project management partners.
CHAPTER 1
The Changing Landscape of Software Development
We’re trying to change the habits of an awful lot of people. That won’t happen overnight but it will bloody well happen.
John Akers, CEOIBM
The software project management landscape is ever-changing. It is defined by no less than five interdependent variables: the characteristics of the software project itself, the software development life cycle, the project management life cycle, the profile of the project team, and the technology that supports the whole. While this may seem overwhelming, it isn’t. I’ll explore the complexities of this multidimensional landscape with you and show you how to obtain and sustain an effective presence in this changing landscape.
Software development processes and modern project management processes are both about 50 years old. Both are adolescents. Both are trying to earn a seat at the corporate strategy table. Both are sure that they can contribute to the success of their enterprise. Unfortunately, both have a reputation for failing to live up to expectations. Both are struggling, and both face tremendous odds against making any positive impressions.
The equation that says you must strike a balance between people, process, and technology holds the clue as to where you should look. People are smart. Of that there is no doubt. How many times have you heard an executive say, “Just put five of our smart people together in a room, and they will solve any problem you can give them.” That may be true, but I don’t think anyone would bet the future of their enterprise on the continuing heroic efforts of the anointed few. Technology is racing ahead faster than any organization can absorb, so that can’t be the problem. Process is the only thing left, and it is to process that you turn in this book. But it isn’t just your normal everyday processes that have your attention. It is the integration of software development processes and project management processes that will demand your attention throughout this book. The result of that integration will be a type of discipline—effective software project management (ESPM). This book is about the concepts and principles of ESPM and its application to real software development problems.
Despite their brief history, software development and project management practitioner groups have never taken the pains to seriously integrate what they have learned with one another. Software developers use their systems development life cycle as a surrogate for project management. Traditional project managers are locked into the construction and engineering mindset that initially defined and continues to define the project management discipline. The impact of the construction and engineering practices on project management continues to be a roadblock to the further development of project management in the software development discipline. As a result, most software developers dismiss most project managers as incapable and irrelevant to meeting their needs. What is needed is to have traditional project managers think openly and creatively about how to effectively serve their customers and deliver business value as their prime directive.
That suggests a fresh approach to managing software development projects. I hope to do that in pages that follow. But right now that that doesn’t mean creating new tools, templates, or processes. What we have now is sufficient. What we do not have is the awareness, skills, and creativity to integrate project management life cycles (PMLC) and software development life cycles (SDLC), and the courage to stay the course in implementation of the resulting integrations.
In this book, I take the position that the characteristics of the software development project drive your choice as to the project management tools, templates, and processes that should be used. This is not a recipe book to be blindly followed. Rather, it is a book that teaches you how to create a recipe. In other words, one of my objectives is to help you think like a great project manager.
What Is a Software Development Project?
Several types of software development projects are within the scope of this book. They range from repeatable projects that have been done many times before to projects that are cutting edge problem solving projects. Each presents its own special challenge to the developer. The example given below will be the staging area for exploring effective approaches to software development project management (SDPM).
DEFINITION: SOFTWARE DEVELOPMENTPROJECT
A software development project is a complex undertaking by two or more persons within the boundaries of time, budget, and staff resources that produces new or enhanced computer code that adds significant business value to a new or existing business process.
Although this is a restrictive definition, it does define the types of software development projects that are addressed in this book. The criteria for these projects are that they have the potential of adding significant business value and are not trivial undertakings. These development projects will have significant business value, be highly visible, be of moderate to high complexity, and were needed yesterday.
