Effective Software Project Management

Robert K. Wysocki

• Publisher: Wiley
• Year: 2010
• Print ISBN: 9780764596360
• eBook ISBN: 9780470446539
• Topic: Informatik
• Subtopic: Projektmanagement

Why another book on software project management? For some time, the fields of project management, computer science, and software development have been growing rapidly and concurrently. Effective support for the enterprise demands the merging of these efforts into a coordinated discipline, one that incorporates best practices from both systems development and project management life cycles. Robert K. Wysocki creates that discipline in this book--a ready reference for professionals and consultants as well as a textbook for students of computer information 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-practice principles while maintaining the flexibility that's essential for successful software development. Learn how to make the planning process fit the need * Understand how and why software development must be planned on a certainty-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 of projects it supports best * Recognize the activities that go into the Scoping, Planning, Launching, Monitoring/Controlling, and Closing phases of each strategy * Apply this knowledge to the specific projects you manage * Get a clear picture of where you are and how to get where you want to go

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, CEO
IBM

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 DEVELOPMENT PROJECT

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.

Examples of Two Software Development Projects

I’ve crafted a hypothetical case study that will be a referent as I apply the SDPM strategies presented in this book. I hope that this will help you further align yourself with using the models and approaches that this book addresses. I’ll incorporate more details to the case study as needed. Any resemblance to past or present companies is strictly coincidental. The case study is purely hypothetical and written to illustrate the use of the concepts and principles in this book.

Introducing the Case Study

Pizza Delivered Quickly (PDQ) is a 40-store local chain of eat-in and home delivery pizza stores. Recently PDQ has lost 30 percent of sales revenue due mostly to a drop in their home delivery business. They attribute this solely to their major competitor who recently promoted a program that guarantees 30-minute delivery service from order entry to home delivery. PDQ advertises one-hour delivery. PDQ currently uses computers for in-store operations and the usual business functions but otherwise is not heavily dependent upon software systems to help them receive, process, and deliver their customers’ orders. Pepe Ronee, their Manager of Information Systems, has been charged with developing a software application to identify “pizza factory” locations and create the software system needed to operate them. In commissioning this project, Dee Livery, their president, said to pull out all the stops. She further stated that the future of PDQ depends on this project. She wants the team to investigate an option to deliver the pizza unbaked and “ready for the oven” in 30 minutes or less or deliver it pre-baked in 45 minutes or less.

These pizza factories would not have any retail space. Their only function would be to receive orders, and prepare and deliver the pizzas. The factory location nearest the customer’s location will receive the order from a central ordering facility, and process and deliver the order within 30 or 45 minutes of order entry, depending on whether the customer orders their pizza ready for the oven or already baked.

There are two software development projects identified here:

• The first is a software system to find pizza factory locations.

• The second is a software system to support factory operations.

Clearly the first is a very complex application. It will require heavy involvement by a number of PDQ managers. The goal can be clearly defined but even at that the solution will not be at all obvious. The second focuses on routine business functions and should be easily defined. Off-the-shelf commercial software may be a big part of the final solution to support factory operations.

These are obviously very different software development projects requiring very different approaches. The pizza factory location system will be a very sophisticated modeling tool. The requirements, functionality, and features are not at all obvious. Some of the solution can probably be envisioned, but clearly the whole solution is elusive at this early stage. Exactly how it will do modeling is not known at the outset. It will have to be discovered as the development project is underway. The operations system can utilize commercial off the shelf (COTS) order entry software, which will have to be enhanced at the front end to direct the order to the closest factory and provide driving directions for delivery and other fulfillment tasks on the back end. The requirements, functionality, and features of this system may be problematic.

As the case study unfolds in later chapters, you will see that this simple yet realistic case study is rich with learning opportunities. I expect to draw heavily on it for practical illustrations of the concepts and principles presented here.

What Is Software Development Project Management?

Now that you have a clear idea of what a software development project is, it’s important to clearly define what software development project management is.

DEFINITION: SDPM

Software development project management is the discipline of assessing the characteristics of the software to be developed, choosing the best fit software development life cycle, and then choosing the appropriate project management approach to ensure meeting the customer needs for delivering business value as effectively and efficiently as possible.

At the risk of cluttering up your vocabulary, I have coined a phrase that reflects the thinking process that I follow to craft a management approach to software development. The definition that follows is unique to this book but important to add to your vocabulary. From now on, any use of the term SDPM strategy refers to the definition given here.

DEFINITION: SDPM STRATEGY

A SDPM strategy is an integration of a software development life cycle and a project management life cycle into a customer-facing approach that will produce maximum business value regardless of the obstacles that may arise.

I want you to think of SDPM as an emerging discipline. It is new, although the two components that define it are not new. What is new is the integration of those components to produce an effective SDPM environment. The SDPM strategy for making this happen will be developed in this book.

The title of this section poses a question that is not trivial and certainly not a rhetorical question. I know several project managers that would like to have a working definition of exactly what constitutes software development project management. And further to the point, they would like to know how to do it. This book ...

Table of contents

• Title Page
• Copyright Page
• ABOUT THE AUTHOR
• CREDITS
• Foreword
• Introduction
• PART ONE - The Evolving State of ESPM
• PART TWO - Linear ESPM
• PART THREE - Incremental ESPM
• PART FOUR - Iterative ESPM
• PART FIVE - Adaptive ESPM
• PART SIX - Extreme ESPM
• PART SEVEN - In Summary
• 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