CHAPTER 6
Appropriate Project Cycles for Independent Projects
As depicted in the Project Complexity Model, independent business projects are typically of short duration and are staffed with competent project leadership and internal team members (two to four team members) who have worked together in the past, use repeatable processes, and have a track record of reliable estimates. Scope has been minimized, and both the schedule and budget have some flexibility.
The business objective on an independent project is clear, requirements are well-defined and stable, and the solution is readily achievable using existing, well-understood technology. In addition, the project has strong executive support, few stakeholders, and no political implications. Minimal organizational change is involved, affecting only one business unit, one familiar business process, or one IT system undergoing maintenance or enhancement. No new or unfamiliar regulatory requirements or punitive exposures are being addressed, and the IT complexity is low. Table 6-1 presents the complexity profile of an independent project.
TABLE 6-1. Complexity Profile of an Independent Project
| Complexity Dimensions | Complexity Profile of an Independent Project |
|---|---|
| Time/Cost | < 3 months < $250K |
| Team size | 3-4 team members |
| Team Composition and Performance |
|
| Urgency and Flexibility of Cost, Time, and Scope |
|
| Clarity of Problem, Opportunity, and Solution |
|
| Requirements Volatility and risk |
|
| Strategic importance, Political Implications, Multiple Stakeholders |
|
| Level of Organizational Change |
|
| Level of Commercial Change |
|
| Risks, dependencies, and External Constraints |
|
| Level of It Complexity |
|
In Figure 6-1, we see that with the exception of one complexity dimension, urgency/flexibility, our Project Complexity Formula (reproduced here as Table 6-2) tells us that this should be managed as an independent project.
FIGURE 6-1. Example of Independent Project
TABLE 6-2. Project Complexity Formula
| Highly Complex | Moderately Complex | Independent |
|---|---|---|
| Level of change = large-scale enterprise impacts or Both the problem and the solution are difficult to define or understand, and the solution is difficult to achieve. The solution is likely to use unproven technologies. or Four or more categories in the “highly complex” column |
Two or more categories in the “moderately complex” column or One category in the “highly complex” column and three or more in the “moderately complex” column |
No more than one category in the “moderately complex” column and No categories in the “highly complex” column |
As depicted in Figure 6-2, independent projects are usually predictable and respond well to the use of linear project cycles. Some emerging practices can be used with these cycles, most notably critical chain project management (CCPM), a scheduling technique that improves the plan by “… ensuring that it is feasible and immune from common cause variation (uncertainty, or statistical variations). It does this by aggregating uncertainty into buffers at the end of activity paths.”1 Advocates of CCPM contend that projects can be completed in record time using this scheduling and control technique. (For a complete discussion of the CCPM technique, see http://www.advanced-projects.com/CCPM/PMJOURN_R8.PDF.)
The following models can be used effectively to manage independent projects:
Waterfall model- Modified waterfall model
- Rapid application development (RAD) model
- Vee model.
WATERFALL MODEL
The waterfall model, the archetypical project cycle model from which all others are derived, is a highly effective project cycle for short-duration, well-understood projects with stable requirements and virtually no external dependencies. This is the classic systems development life cycle developed by Dr. Win Royce in 1969. Royce intended to provide a repeatable process for the undisciplined software development community. The model has been widely applied to both software and hardware development projects.
FIGURE 6-2. Independent Projects Mapped to Project Cycle Approaches
The waterfall model is essentially a linear, sequentially based ordering of activities that presumes that requirements are fully developed and approved. It also assumes that events affecting the project are predictable, tools and activities are well-understood, and as a rule, once a phase is complete, it will not be revisited. Development is seen as flowing steadily downward (like a waterfall) through the phases of the model. The “big design up front” approach is often associated with the waterfall model. This approach assumes that the solution design is completed and perfected before construction of the solution is started.
The strengths of the waterfall model are that it lays out the steps for development and stresses the importance of requirements. Its limitations are that projects rarely follow a sequential flow, and clients usually find it difficult to state all requirements fully early in the project. Changes to requirements that involve a change to the scope of the solution can have major impacts on the project schedule and budget, potentially leading to a troubled project. Figure 6-3 depicts the classic waterfall model approach to managing a project.
FIGURE 6-3. Waterfall Model
MODIFIED WATERFALL MODEL
The modified waterfall model uses identical phases as the waterfall model, but introduces flexibility by overlapping phases if needed and even splitting the project into subprojects after design is complete. The strength of this approach is that it allows implementation of components of the solution to add value earlier. Its weaknesses are that milestones may be more ambiguous, miscommunication may occur, and unidentified dependencies may create unforeseen problems.2 Figure 6-4 depicts the modified waterfall model.
FIGURE 6-4. Modified Waterfall Model
RAPID APPLICATION DEVELOPMENT MODEL
If requirements are understood and scope is contained, the RAD model allows for a greatly abbreviated development timeline compared to the waterfall model. This component-based approach allows for incremental testing and defect repair—and therefore significantly reduced risk—compared to single, comprehensive delivery. RAD can be costly, however, if requirements aren’t well-defined, which creates a high risk of requirements defects, or if the design is not sound, which creates a high risk of integration issues. Figure 6-5 depicts the RAD model.
FIGURE 6-5. RAD Model
VEE MODEL
The Vee model, developed by NASA to manage system engineering projects, is often used for projects once the basic system requirements are firm and system design decisions have been made. The Vee model accounts for the relationships between decomposition, integration, and verification. Integration and verification of subcomponents are planned early. The Vee model assumes the solution will be a closed system, i.e., self-contained and not influenced by its external environment. Accordingly, the system is decomposable, linear, and predictable.3
The Vee model involves progressively elaborating requirements, decomposing them for the system into segments, elements, subsystems, and finally components (the left side of the Vee), while defining the approach to integration, verification, and validation (the right side of the Vee) at every decomposition level. Then, integration builds components into subsystems, elements, segments, and finally the system.4
The Vee model assumes that the requirements and testing processes, elicited through various business analysis techniques, are known before building begins. In essence, the Vee model adds a vertical dimension to the waterfall model, altering the waterfall shape into a “V.” At the base of the Vee is the component build. Components of the system are developed in isolation, and each component produces part of the solution; functionality is gradually integrated into subsequent components.
Unfortunately, this approach does not scale up when addressing large, complex information-age projects because it assumes that a solution will operate in a steady state with static patterns versus flexible solutions that evolve and adapt to their changing environment. Solutions today must be “robust enough to withstand or flexible enough to bend and recover from constant change.”5 Figure 6-6 depicts the classic Vee model.
FIGURE 6-6. Vee Model
Well-understood, straightforward projects respond well to linear approaches to project management. When managing independent projects, consider the following project cycle models:
- The waterfall model for well-understood, predictable projects
- The modified waterfall model when implementation of solution components is needed to add value earlier than waiting for the full solution
- The RAD model when the need to deliver the new business solution is urgent
- The Vee model when planning integration and verification of subcomponents early in the project.
NOTES
1. Larry P. Leach, “Critical Chain Project Management Improves Project Performance,” Advanced Projects Institute (2000). Online at http://www.advanced-projects.com/CCPM/PMJOURN_R8.PDF (accessed March 2008).
2. Business eSolutions, “Project Lifecycle Models: How They Differ and When to Use Them.” Online at http://www.business-esolutions.com/islm.htm#modifiedwaterfall (accessed January 2008).
3. Linda J. Vandergriff, “Complex Venture Acquisition,” Complexity Conference White Paper (2006), 6.
4. Hal Mooz, Kevin Forsberg, and Howard Cotterman, Communicating Project Management (Hoboken, NJ: John Wiley & Sons, 2003), 334.
5. Linda J. Vandergriff, “Complex Venture Acquisition,” Complexity Conference White Paper (2006), 5.