What Are the Characteristics of the Software to Be Developed? When I think of the software development landscape, I think of it in very simple terms. I see it as a two-dimensional grid like the one shown in Figure 1-1. The first dimension relates to the goal of the software development project. The goal is either clearly specified (therefore known) or it is not clearly specified (therefore not known). It’s an all or nothing situation. The boundary between clear and not clear is more conceptual that actual. The same is true of the second dimension, which relates to the solution or how you expect to reach the goal. That also has two categories. The solution is either clearly specified (and therefore known) or it is not clearly specified (and therefore not known). If you intersect these two dimensions as shown in the figure, then you have defined a four-category classification of software development projects. This classification is simple but inclusive of every software development project. That is, every software development project that ever has been or ever will be must fall into one and only one of these four categories. Why is this important? First and foremost, the characteristics of the software to be developed will play an important role in determining the model that will be used. Each of these quadrants presents the development team with a number of decisions regarding how to go forward. The next sections briefly examine each quadrant and the salient aspects of clarity or lack thereof with respect to goal and solution.
Quadrant 1: Goal and Solution Are Clearly SpecifiedHow could it be any better than to clearly know the goal and the solution? This is the best of all possible worlds, but it is also the least likely to occur in today’s fast-paced, continuously changing business world. Software development projects that fall into this quadrant are familiar to the organization. Perhaps similar projects have been done several times before. There are no surprises. The client has clearly specified the goal and how to reach that goal. Little change is expected. A variety of approaches is in use for such software development projects. They are all of the design-build-test-implement variety or some variation of the linear concept implied by these approaches. Such projects also put the team on familiar technology grounds. The hardware, software, and telecommunications environments are familiar to the team. They have used them repeatedly and have developed a skilled and competent developer bench to handle such projects. The limiting factors in these plan-driven approaches are that they are changeintolerant, are focused on delivering according to time and budget constraints, and rely more on compliance to plan than on delivering business value. The plan is sacred, and conformance to it is the hallmark of a successful project team. Because of the times we live in, these approaches are rapidly becoming dinosaurs. At least the frequency of their application is diminishing rapidly. They are giving way to a whole new collection of approaches that are more customer-focused and deliver business value rather than adhere to a schedule and budget plan. In addition to a clearly defined goal and solution, software development projects that correctly fall into this quadrant have several identifying characteristics as briefly identified here. Low Complexity Other than the fact that the project really is simple, this will often be attributable to the fact that the software development project rings of familiarity. It might be a straightforward application of established business rules and therefore take advantage of existing designs and coding. To the developer it might look like a cut-and-paste exercise. In such cases integration and testing will be the most challenging phases of the development project. The Changing Landscape of Software Development 9 You can still find situations where the project is complex but still well-defined. However, these are rare. Well-Understood Technology Infrastructure Awell-understood technology infrastructure is one that is stable and has been the foundation for many software development projects in the past. That means that the accompanying skills and competencies to work with the technology infrastructure are well-grounded in the development teams. Low Risk The total environment for development projects in this quadrant is that it is known. All that could happen to put the project at risk has occurred in the past, and you have well-tested and well-used mitigation strategies in place. Experience has rooted out all of the mistakes that could be made. The customer is confident that it has done a great job identifying requirements, functions, and features, and they are not likely to change. Except for acts of nature and other unavoidable events, the project is protected from avoidable events. You find few unanticipated risks in software development projects in this quadrant. Experienced and Skilled Developer Teams Past projects have been good training grounds for the teams. They have had opportunities to learn or to enhance their skills and competencies. I’ll have much more to say about teams in the chapters that discuss the Launch Phase of each SDPM strategy. They are a critical success factor in all software development projects. As the characteristics of the software to be developed changes, so also does the profile of the team that can be most effective in developing that software.
Quadrant 2: Goal Is Clearly Specified but Solution Is NotYou have a host of incremental, iterative, and adaptive approaches to SDPM that can be used when the goal is clearly defined, but how to reach the goal—the solution—is not. As you give some thought to where your projects would fall in this landscape, consider the possibility that many if not most of them are really these types of projects. If that is the case, shouldn’t you also be considering using an approach to managing these projects that accommodates the goal and solution characteristics of the project rather than trying to force fit some other approach that was designed for projects with much different characteristics? 1 I contend that the adaptive and iterative class of projects is continuously growing. I make it a practice at all “rubber chicken” dinner presentations to ask about the frequency with which the attendees encounter Quadrant 2 projects. With very small variance they say that at least 75 percent of all their projects are Quadrant 2 projects. Many of them try to adapt Quadrant 1 solutions to Quadrant 2 projects and meet with very little success. The results have ranged from mediocre success to outright failure. Quadrant 2 projects present a different challenge and need a different approach. For years I have advocated that the approach to the project must be driven by the characteristics of the project. To reverse the order is to court disaster. With the addition of the Quadrant 2 approaches discussed in Parts IV, V, and VI of this book, I cover the project landscape with a full complement of approaches for every conceivable type of project.
Quadrant 3: Goal and Solution Are Not Clearly SpecifiedQuadrant 3 extends to the remotest boundaries of project types. Quadrant 3 projects are those projects whose goal and solution cannot be clearly defined. What little planning is done just in time, and the project proceeds through several iterations until it converges on an acceptable goal and solution. If instead there isn’t any prospect of convergence, the customer might pull the plug and cancel the project at any time and look for alternative approaches.
Quadrant 4: Goal Is Not Clearly Specified but the Solution Is The fourth category represents projects whose goals are not known but whose solutions are. This is an impossible situation. It would be equivalent to solutions out looking for problems. Nevertheless, we all have had experiences working with professional services organizations that practice such approaches. They advocate a one-size-fits-all approach, which has never shown to be very successful. I have always discouraged a one-size-fits-all approach with my clients. Most see the wisdom in adopting this position.
Click Here to Purchase this Book