Team Skill 4: Managing Scope

So far in this book, we have introduced you to the team skills of analyzing the problem, understanding user and stakeholder needs, and defining the system. These three team skills all focus on a primary root cause of software development problems: the team's forging off into the solution space without having an adequate understanding of the problem to be solved . Although team members will need to practice these skills in order to develop them, doing so does not take great effort. We strongly recommend spending a little more time in these early lifecycle activities; even so, the entire set of activities described so far should consume only a small fraction of the project budget, perhaps only 5 percent or so of the total costs. Although the issues are complex, only a few team members ”analysts, the project manager, the technical lead, the product manager/project champion ”need to be heavily involved up to this point.

Hereafter, however, the game changes dramatically as the team size increases significantly. Each of these additional team members must participate in a coordinated team effort, and everyone must communicate effectively with one another. In addition, the investment, or "burn rate," of the project increases dramatically. We create test plans, build design models, refine requirements, elaborate the use cases, develop the code, and create momentum and a larger body of work that must be changed if the definition is not well understood or if the external requirements environment changes.

The requirements pyramid, by its very shape ”wider at the bottom ”correctly suggests that much more work is ahead of us. The team skill discussed in this section of the book develops a strategy for a most crucial activity: scope management. According to the Standish Group [1994] data, " 53% of the projects will cost 189% of estimates ." Data from our own experience is even worse : Almost all software projects will be late by a factor of 50% to 100%. Assuming that the other root causes in software development will not be solved overnight, it seems clear that our industry is either incompetent or trying to do too much with too few resources, skills, and tools. We are trying to stuff ten pounds of desired functionality into a five- pound bag. Although the physics of software development are not clear, it should be obvious that this element of our strategy is heading for trouble and that the quality of both our work products and our reputation is about to suffer.

So, before we increase the team size, before we develop the more detailed specifications, before we commit our technology ideas to designs, and before we build the test scripts, we must pause and learn how to manage the scope of the project . Part psychology, part technology, and part just good project management, mastery of this team skill will dramatically improve the probability of a successful project.

Chapter 18 Establishing Project Scope

Chapter 19 Managing Your Customer