The Four Development Strategies


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

graphics/11fig02.jpg

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

graphics/11fig03.jpg

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 [4] and many IT organizations.

[4] William Perry, a former Secretary of Defense, sent a memo to the U.S. Defense Department clearly abandoning the waterfall strategy as the only way to build systems in the early 1990s. The waterfall strategy had been embedded in DOD-STD 2167, which was a standard that all defense projects had been forced to follow for many years .

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.

Fred Brooks' Revision

In the 20th anniversary edition of his classic The Mythical Man Month , Fred Brooks [1975] admitted that the waterfall model, which had been integral to his view of systems development, was totally wrong, citing the same weaknesses that we have found over the past 25 years. We have also been advising our clients to avoid the waterfall for all but small, low-risk projects over the same period.

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

graphics/11fig04.jpg

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.

Sequential Release

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

graphics/11fig05.jpg

Don't Buy Version 1

Cynics among our readers will recognize the concept of releases of products. Who remembers Microsoft Windows 3.0 or the first "portable" computers?

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

graphics/11fig06.gif

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.

Minimum Deliverable

One of the key considerations when you are planning a project, especially during the discussion about project development strategies, is for you and your project sponsor to negotiate the minimum deliverable or core functionality. There are a couple of ways that you can identify the core functionality of the system. The simplest way is to ask your sponsor and critical stakeholders, "If everything goes wrong in this project and, as you know things tend to go wrong, what is the minimum that has to be implemented by the deadline?" Clearly, the minimum functionality or core functionality should be scheduled for Release 1.

Concurrent Release

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

graphics/11fig07.jpg

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.

A Dirty Little Secret?

In hundreds of project management workshops, we have observed thousands of business and IT project managers struggling to admit that they have used the fast track strategy. In fact, many feel a little nervous that our group explains this strategy to business stakeholders and senior management. In other words, this strategy is a dirty little secret. This is paradoxical as, in other areas such as construction and manufacturing, fast-tracking is common.

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

graphics/11fig08.gif

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)") [5] and Tom Steinert-Threlkeld ("Can You Work in Netscape Time?") [6] clearly show how companies such as Netscape and Quintiles have refined the fast track strategy and have used it to gain significant market positions .

[5] "Speed kills the competition," Fast Company, Issue 4, August/September 1996, pp. 84 “93.

[6] "Can you work in Netscape time?," Fast Company, Issue 1, November 1995, pp. 86 “92.

A Couple of Seconds of Netscape Time

In the Fast Company article on Netscape there are some wonderful examples of the issues surrounding the fast track strategy. The issue of fast to market is highlighted by the fact that for each week Netscape delayed in shipping Navigator, their major competitor Mosaic was shipping 600,000 copies! As Jim Clark, the co-founder of Netscape comments, "If we had been 6 months later we would have been lost in the noise." The success of early shipping of a bug-ridden Netscape [PQD in action] was proven when, 6 months after shipping, Netscape commanded 75% of all browser traffic and Mosaic's share had fallen from 60% to 5%. One of Netscape's core principles is "fast enough never is."

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).

The Down-side of Fast Track

While the concept of rapid implementation using fast track is appealing to a business executive looking to beat competitors to market, our research has shown that the support costs of fast tracked products can be 5 times higher than for higher quality products. These support costs need to be considered before fast-tracking is approved.

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 . [7] 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.

[7] It is interesting to note that Microsoft and other "fast track" companies prefer Generation X people for these intense projects because of their youth, lack of "outside" lives, flexibility, ability to multitask, and stamina. Experience may thus need to be tempered with physical fitness and total focus.

Hybrid

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.



Radical Project Management
Radical Project Management
ISBN: 0130094862
EAN: 2147483647
Year: 2002
Pages: 136
Authors: Rob Thomsett

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net