To help understand the impact and power of project development strategies, we assume that you have a simple set of system requirements, as shown in Figure 11.2.
Figure 11.2. Sample system requirements
In our example, there is a requirement for four processes, A, B, C, and D. There are four stakeholders, A, B, C, and D. The system processes use two sets of data, Data A and Data B.
There are four basic project development strategies, explained in the following sections.
Monolithic or Waterfall
As shown in Figure 11.3, this strategy involves developing the system or product as a whole with each phase as a stand-alone activity, and subsequent phases are not commenced until preceding phases are complete; that is, design is not commenced until analysis is complete. In effect, the waterfall or monolithic strategy treats system and product development as an assembly line.
Figure 11.3. Monolithic/waterfall strategy
It is probably the oldest of the strategies, and computing and business borrowed this strategy from the building, engineering, manufacturing, and defense industries in the early 1960s. I was taught this strategy as the only way to build systems in the late 1960s. Until the mid-1990s this was mandated as a standard for the U.S. defense industries  and many IT organizations.
In our example system, all the processes (A, B, C, D) and all the data (Data A and Data B) would be implemented in one big bang on the delivery date. Each phase of the development cycle would be completed before the subsequent phase commences.
Strengths and Weaknesses
The strengths of the waterfall strategy are its simplicity and ease of scheduling. Scheduling tools such as Microsoft Project are well-suited for this strategy. Given the longevity of this model, this strategy is the basis of most traditional software engineering approaches and texts and, as such, has become the intellectual framework for many IT people and the universities that train them.
The weaknesses of this strategy are substantial. It is poorly suited for the chaotic and client-driven business environment of the 21st century.
First, the business clients and stakeholders will not see any of the product until they see the whole product, so if the quality of the product or the functionality is not as expected, it is too late to find out after the product has been delivered. As we discussed earlier in this book, in traditional project management and system development approaches, the users were remote from the development effort and, as a result, often didn't really get a chance to determine whether their requirements were going to be met until late in the development cycle.
Second, it is totally inadequate for handling requirements changes. As shown in Figure 11.4, if a requirement change occurs during the design phase, there are only two viable choices. The first is to effectively ignore the change and schedule it as an enhancement after the initial delivery (this choice was widely used in the era when computer people and other experts controlled the development effort). The second is to loop back into the analysis phase to examine the requirements change. The allowing of looping back to earlier phases effectively destroys the strategy and research has shown that with backward looping allowed, the final phase of the development cycle is always the longest, as the team loops backward to all subsequent phases, attempting to eliminate as many errors and changes as possible.
Figure 11.4. The failure of the waterfall strategy
This looping often resulted in a bizarre phenomenon ”analysis paralysis ”where the team continually loops either within the analysis phase or between analysis and design as requirements continually change. This failure of the waterfall strategy is well illustrated in an Australian Department of Defence project, Supply System Redevelopment (SSR), where after more than 10 years of systems analysis, no firm requirement had been produced.
The third problem with the waterfall strategy is simply that it takes too long. There is considerable evidence that project team members experience a "midproject slump" as they begin to question whether they will ever produce a working system or product. It is also very difficult for the project manager to keep the team focused for long periods when they are beginning to question whether the project will ever end. In addition, the pressures for faster delivery cycles from business (discussed earlier in this book) demand alternative development strategies. Finally, long projects are more exposed to changes from external areas than shorter projects.
Release, Version, or Incremental
This strategy attempts to address some of the shortcomings of the waterfall strategy by shortening the development life cycle. There are two variations of this strategy.
This variation involves breaking the system into semi-independent subsystems or subproducts and then producing and implementing an entire operational subsystem or product as Version 1 or Release 1, then a second subsystem as Version 2 or Release 2, and so on, as shown in Figure 11.5. For example, Release 1 of the new banking product may not have all the features, but it is an effective stand-alone product. Release 2 adds some additional noncritical features.
Figure 11.5. The sequential release strategy
In our example, let's assume that we break our system into two releases as shown in Figure 11.6. Processes A and B with their related Data A are partitioned into Release 1 and Processes C and D are treated as Release 2. Note that each release has different stakeholders (this is very important and we spend more time on this concept later).
Figure 11.6. Partitioning into releases
Strengths and Weaknesses
Clearly, the sequential release strategy addresses the major weaknesses of the monolithic strategy by providing the capability of shortening the life cycle and delivering working product quicker. In addition, the sequential release strategy enables smaller teams (which, as we discuss later in this book, are more efficient and easier to manage) to develop big systems and products. In sequential release projects, the team is still focused on one specific group of functions (and data), which also helps team cohesion.
The weaknesses of sequential release are centered around the fact that you have to break up the system or product into subsystems or subproducts that are as independent as possible. Of course, the nature of systems and products is that they consist of interlinked subcomponents and it is the links that are the problem, not the components .
If you are using either the sequential or concurrent release strategies, you must ensure that the shared data (or links) between Release 1 and Release 2 is carefully managed. For example, using sequential release, after Release 1 is implemented Data A is being used in the production system. The support team, who are supporting Release 1, and the development team, who are working on Release 2, must communicate effectively and review each other's work. When the shared data (e.g., the format, content, and structure) is changed by one team, the other team must approve of the change and change either their system or design accordingly . The lack of management of the interfaces between releases has caused serious problems in many projects.
This strategy is another variation on the release approach where, as shown in Figure 11.7, the releases are scheduled concurrently.
Figure 11.7. Concurrent release strategy
The concurrent release strategy offers the best of all worlds . It enables bigger teams (broken into subteams by release) to work together to produce the entire system in a relatively rapid manner. In our example, one team would develop Release 1 while, concurrently, another team would be developing Release 2.
The key to understanding this version of the release strategy is that various components of the system or product each go through the development life cycle (methodology) independent of the other releases. In other words, Release 1 could be in the design phase while Release 2 is still in the analysis phase.
Strengths and Weaknesses
Clearly, this strategy has all the strengths and weaknesses of the sequential release strategy. In addition, as mentioned earlier, it has the additional advantage of being able to deliver more functionality in a relatively quick manner.
However, the issue of managing the interfaces or links between the releases is even more difficult in this strategy. In large and complex projects, it is possible that many releases could be under development concurrently and a change by one subproject manager and his or her technical experts in shared data or interfaces could ripple across a number of interrelated releases, causing major disruptions to the project. In addition, whereas in the sequential release strategy you are focused on one release, the concurrent release strategy involves focus on multiple releases. Each has its own scope, objectives, stakeholders, risks, and so on. In effect, you have an overall business case for the project and a series of subproject business cases, all of which have to be coordinated.
The concurrent release is not for first-time project managers, and our experience is that concurrent release strategy projects require higher levels of both project management effort and experience.
Fast Track, Evolutionary, or Production Prototyping
This involves producing a production prototype of the system as quickly as possible. It is better understood when you understand that the "street language" title of this strategy is the quick and dirty strategy.
Paul Melichar (1976) identified this strategy, and for many IT and other project professionals, it is seen as a covert and unprofessional strategy. Much of this view can be blamed on the majority of academics and quality assurance and software engineering gurus, who are still focused on the more professional and engineered strategies.
The key to understanding this strategy is that the whole requirement is developed as quickly as possible with careful and planned degradation of quality. This can be achieved by minimizing adherence to standards and by use of application generators or high-level languages (e.g., Visual Basic, etc.). The first operational prototype is shipped into production. Often in the fast track strategy, training, documentation, and testing are compromised (see Figure 11.8).
Figure 11.8. Fast track strategy
The initial version of the system or product is then redeveloped through a series of reengineering projects that include additional functionality.
As the pressure to be first to market and to beat competitors increases in many sectors of business, the use of the fast track strategy will grow, and it is our experience that fast-tracking is already the most commonly used strategy. Perfect examples of this justification of lower quality systems and products to gain market share by being first to market are the highly competitive area of World Wide Web browsers and the pharmaceutical industry. In amazing articles in Fast Company (both available on Fast Company's Web site at www.fastcompany.com), Eric Matson ("Speed Kills (the Competition)")  and Tom Steinert-Threlkeld ("Can You Work in Netscape Time?")  clearly show how companies such as Netscape and Quintiles have refined the fast track strategy and have used it to gain significant market positions .
Strengths and Weaknesses
The strengths of the fast track strategy are its sheer speed and that the entire product is built rather than a subcomponent, as in the release strategies. In addition, the fast track strategy is a highly charged, entrepreneurial, creative, and exciting strategy. More important, because of the schedule compression associated with the strategy, it is less exposed to changes (in some cases, the product is delivered before the requirements change) and well suited for high-risk projects (see later).
Given the potential for this strategy to involve long hours and degradation of quality, it is critical that the team members are highly skilled and experienced .  This is very important as the use of fast-tracking with inexperienced teams can lead to disaster. Also, because the delivered quality is typically low, the project sponsor and stakeholders must be prepared to support and fund the review and reengineer activities (see Figure 11.8). Without planning and implementation of the cleanup, fast track projects are simply excuses for putting quick and dirty systems into production. Finally, the fast track strategy requires very sophisticated and professional project management, including real-time planning as discussed in this book.
The hybrid strategy is a variation of concurrent release. The hybrid strategy really involves a series of concurrent releases or subprojects with each subproject or release using a different development strategy.
In our example, let's assume that Release 1 (Processes A and B with Data A) is a high-risk release, as Stakeholders A and B are likely to change their requirements and they have a relatively low quality expectation (as determined by our quality agreement). Release 2 (Processes C and D and Data B) is a lower risk, as Stakeholders C and D are more sure of their requirements and have very high quality expectations. In this case, the hybrid strategy would be ideal, with Release 1 being developed using the fast track strategy and, concurrently, Release 2 developed using either the monolithic or the sequential release strategy.
The hybrid strategy is very powerful and is the most common in large or superlarge projects.