Chapter 5

Determine the Project Life Cycle

In This Chapter:

Prior to planning the requirements activities, the core planning team needs to determine the development approach by selecting the project life cycle that will be followed. This is necessary because the requirements activities, their sequence and timing, and the requirements deliverables to be produced differ based on the project life cycle that is used. It is important to understand that whatever project life cycle is selected will impose some constraints that must be taken into account when planning requirements activities.

The Project Life Cycle

Project life cycles are used to add structure and control points to projects. Project life cycles attempt to bring order to project activities, thus providing a repeatable, predictable way to develop products. The project life cycle, usually depicted in a graphical model, acts as the framework guiding the project team through the project. It is therefore essential that the project life cycle is determined and agreed upon in the beginning of a project, prior to the start of requirements activities, since it defines what will be done from start to finish. The project life cycle identifies the technical work that is needed, the roles needed in each phase, and the control gate entry and exit criteria. A complete project life cycle defines the work from project management, business analysis, and IT perspectives:

Project management: The approach used to manage and control the project

Business analysis: The approach used to gather and document business requirements for the solution and to build, maintain, and retire components of the solution that are not automated by IT components

IT: The approach used to design, build, maintain, and retire the IT components of the solution

The project life cycle is combined with the product (or solution development) life cycle to create an integrated project life cycle. Figure 5-1 shows the integrated project life cycle.

Figure 5-1—Integrated Project Life Cycle

The Iterative Nature of Project Life Cycles

Although the activities in project life cycles appear to be sequential, it is important to keep in mind that they are almost always performed iteratively. Iteration is an effective technique when attempting to control a risky process such as business requirements definition or business solution development. Candid feedback mechanisms should be planned after each iteration to uncover defects and apply corrections as early in the project life cycle as possible.

The key to allowing for continuous feedback is for the business analyst to plan an iterative approach to requirements generation throughout the requirements phase, and indeed, throughout the remaining phases of the project. During the requirements phase, the technical leads are likely working on early iterations of the solution design and perhaps even building prototypes of high-risk solution components. As the business analyst conducts requirements tradeoff analyses to determine the best requirement to achieve business objectives, the architect does the same for solution options. Thus, early prototyping is the first step in iterative development.

Industry- or Product-Specific Project Life Cycles

Organizations use different project life cycles, each containing product and project management activities, depending on the nature of the end product they are creating.

Construction Project Life Cycle

A typical construction project life cycle contains the periods and phases depicted in Figure 5-2. The three periods within the cycle are:

Planning: The period determining the project scope and direction

Design: The period designing the building, selecting the contractors, and securing approval from the buyer to begin construction

Construction: The period preparing the site, constructing the building, and preparing for turnover for building occupancy and operations and maintenance

Government Acquisition Project Life Cycle

A typical government acquisition project life cycle contains the periods and phases depicted in Figure 5-3. The three periods within the cycle are:

Study: The period determining the project scope, requirements, design, and direction

Acquisition: The period selecting the contractor(s) and producing and delivering the solution to the buyer

Operations: The period deploying, operating, maintaining, and deactivating the system

Variations in Project Life Cycles

There are many variations in business system development project life cycles. Most of these come from the software engineering world and the IT domain as the result of trying to reduce software development project risks. For most business solution development projects with a significant IT component, and even for many nontechnical projects, at least one of these project life cycles will likely meet the project needs. Given certain project conditions, each of these approaches has the potential to work well:

Figure 5-2—Construction Project Life Cycle

Figure 5-3—Typical Project Life Cycle for a Major Acquisition

Waterfall model—Linear sequential development through the typical project phases: requirements, design, construction, test, deliver, operations and maintenance, retire.

Rapid application development (RAD) model—Builds system components concurrently and integrates the components at the end; used to compress the schedule.

Vee model—Includes the relationship between decomposition and integration, and the concept of incremental delivery.

Evolutionary development model—Build something and try it; learn from first cycle and try again.

Spiral development model—Risk-driven; develops requirements and system concept concurrently. Essentially an iterative waterfall model.

Agile development model—Risk-driven; risk is contained through the use of short development cycles and co-located teams. Used when requirements are difficult to define and expected to change.

Legacy maintenance model—Builds upgrades to existing systems; this abbreviated waterfall model is typically used.

Prototyping model—Builds nonworking mockups of the system or components of the system for proof of concept for high-risk areas or for requirements understanding.

Waterfall Model

The waterfall model is the classic solution development project life cycle. It is the oldest paradigm for software engineering, but it is also widely used as a generic model for other types of engineering endeavors. It is essentially a linear ordering of activities. The waterfall technique is rarely successful for large projects because users are typically excluded from influencing the product during development and must accept what is delivered. It presumes that requirements are fully developed and agreed upon and are very clear before the project moves to design and construction. It also assumes that events affecting the project are predictable, tools and activities are well-understood, and as a rule, that once a phase is complete it is not revisited.

The strengths of this approach are that it lays out the steps for solution development and stresses the importance of requirements. The limitations are that projects rarely follow the sequential flow. In addition, it is often difficult for the client to state all requirements early on in the project completely and succinctly, as required by this model.

The waterfall model endorses an “over the wall” approach, wherein responsibility for building the product is incrementally moved from one group to another. The contemporary movement, by contrast, is toward teams of people working on a complete project. The waterfall approach excludes an incremental approach to product development, which is probably much more realistic for complex projects. However, the waterfall model of project life cycles is highly effective for short-duration, well-understood projects with stable requirements. Figure 5-4 depicts the waterfall model.

Used When

The waterfall model is most effective for projects that are small, straightforward, predictable, independent, and low-risk.

Implications for Planning the Requirements Activities

When planning requirements activities, build the schedule to complete all requirements elicitation, analysis, specification, documentation, and validation activities in full prior to exiting the requirements phase. Also, plan to baseline the requirements and implement a rigorous change control process.

Figure 5-4—Waterfall Model

Rapid Application Development Model

If requirements are understood and scope is contained, rapid application development (RAD) allows the system to be developed in the shortest amount of time. Also called multiple build, RAD is similar to incremental development with the exception that functional pieces of the system are being delivered to the customer. These pieces may stand alone to be integrated during a later build, or they may be an integrated set of partial functionality that contains an increasing number of features with each build. Previously delivered builds are usually not maintained in the field, since subsequent builds often require changes to them. Because this life cycle requires customer input into the total number of builds, the functionality within each build, and expected delivery of each build, the requirements and design phases are usually completed prior to developing, testing, and delivering various builds.

Strengths: Greatly abbreviated development timeline; component-based approach allows for incremental testing and defect repair; and significantly reduced risk compared to single, comprehensive delivery.

Limitations: Can be costly if requirements aren’t well-defined (high risk of requirement defects) or the design is not sound (high risk of integration issues). In addition, many solutions cannot be structured into divisible subcomponents that can be worked on concurrently. RAD is highly effective for decomposing the development of a large, high-risk system into the development of a succession of smaller, lower risk subsystems. Figure 5-5 depicts the RAD model.

Used When

The RAD model is used most effectively when requirements are understood, scope is contained, and time-to-market is the most significant driver.

Implications for Planning the Requirements Activities

When planning a RAD project, schedule all requirements and design activities to be completed in full prior to beginning development of solution components. When the solution is developed through RAD techniques, it is prudent to divide the development of the solution into a core system (the operative part of the system), and special components (separate from the core, adding functionality in components). Further divide the core system into extension levels, building the foundation level first and then extending system capabilities incrementally. As the core system is developed and implemented, different technical teams work on specialized functional components. The goal is to build the specialized components with only a one-way dependency to the core system; therefore, specialized components are independent of each other and can be created in any order or even in parallel.²

Figure 5-5—Rapid Application Development

Vee Model

The vee model, which was created by NASA to manage project complexity, is often used for moderate- to high-risk projects. It includes the relationship between decomposition and integration, and the concept of incremental delivery. The vee model involves progressively elaborating requirements (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. It assumes the requirements and testing processes, elicited through various business analysis techniques, are known before building begins. Figure 5-6 depicts the vee model.

Used When

The vee model is used most effectively when projects are complex, requirements are extensive and difficult to define, and a sequentially phased development process can be used. Note that when requirements are elusive, it is prudent to draft test cases first or concurrently with the requirements documentation. Drafting a test case can often clarify requirements and also ensures that the requirements are testable.

Figure 5-6—Vee Model

Implications for Planning the Requirements Activities

Since the vee model involves progressively elaborating requirements while defining the approach to integration, verification, and validation (IV&V) at every decomposition level, the requirements activities are scheduled in concert with the IV&V activities. Therefore, the requirements activities will likely be longer in duration, and will take place before building begins.

Evolutionary Delivery Model

Evolutionary delivery allows for building a simple, working version of the solution and then adding functionality incrementally to improve the product based on experience from prior versions. In practice, evolutionary delivery transforms a single vee into a series of vees. Figure 5-7 shows the typical approach to evolutionary development.

Used When

The evolutionary delivery model is best used when the requirements are not fully known initially and when the project is large, high-risk, and complex.

Figure 5-7—Evolutionary Delivery Model

Implications for Planning the Requirements Activities

When planning requirements activities, each increment will include activities to elicit, analyze, specify, and validate requirements. Therefore, the planning effort involves scheduling the full life cycle for each increment, not just the requirements activities. Obviously, not all increments can be planned in the beginning; some can be planned only when more is learned about the solution requirements from early deliveries of simple versions of the solution.

Spiral Development Model

The spiral development model couples the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential waterfall model. Using the spiral development model, the team keeps cycling through the same set of life cycle phases until the product development is complete. Each cycle is characterized by four phases: plan/requirements, design, build, and evaluate. Detailed plans are built only for the current phase of the spiral. Benefits include:

The development environment is tightly controlled.

Validation occurs early (good for large-scale systems and software).

Risks are addressed at each level, so risk is reduced.

The systematic, stepwise approach of the classic waterfall model project life cycle is maintained, but reframed into an iterative framework.

Used When

The spiral development model is very effective when the customer (or management) does not know what the final product should look like and a prototype will not answer the question. The purpose of each cycle is to attempt to develop whatever part of the system currently presents the highest risk (risk-driven spiral). The spiral model is used when it is important to test the reaction of the real customer using initial functionality before deciding what additional functionality would increase value. Figure 5-8 shows the complexity of spiral development.

Implications for Planning the Requirements Activities

When planning requirements activities, detailed plans (plan/requirements, design, build, and evaluate) are built only for the current phase of the spiral.

Agile Development Model

Interest has blossomed in agile development in the past two years, although the roots of the movement go back to the early 1990s. Agile managers understand that demanding certainty in the face of uncertainty (as in the waterfall model) may be unrealistic. The agile approaches focus on collaborative values and principles with a high degree of interaction among project team members and customers. Agile project managers rely on face-to-face interaction more than on documentation; they seek to avoid bureaucracy.

Figure 5-8—Spiral Development Model

Using agile development, a project’s overall scope, objectives, constraints, clients, risks, etc., are briefly documented, followed by short, iterative, feature-driven, time-boxed cycles. Using multiple exploratory cycles allows for constant feedback to stay on track. The focus is on delivering business value incrementally, which requires continued interaction between developers and customers. (For more information about agile development, see www.agilealliance.com.) See Figure 5-9 for a depiction of agile development.

Figure 5-9—Agile Development Model

Used When

Use agile methods when these conditions are present: project value is clear; the customer can participate throughout the project; customer, designers, and developers are co-located; incremental feature-driven development is possible; and visual documentation (cards on the wall vs. formal documentation) is acceptable.

Implications for Planning the Requirements Activities

Planning a project using the agile development model is challenging. The business analyst works collaboratively with the project manager, the business representative, and the development team to plan the activities and document the scope, objectives, constraints, clients, and risks. In addition, the requirements and solution architecture are defined at a very high level so that a release plan can be developed for incremental delivery of the solution. After risks have been resolved, features delivered by each increment are prioritized based on business value.

The business analysis plans focus on building initial requirements models, prioritizing customer requests, validating increments as they are built and tested, reprioritizing the features in backlog after each increment is delivered, and reviewing the business case after each incremental delivery to ensure the project is continuing to add more value than it is costing the organization. Caution: While the agile development model focuses more on building models and code versus documents, the business analyst’s challenge is to document the business and system requirements in enough detail so that the system can be maintained once it is in operations.

Legacy Maintenance Model

Legacy maintenance differs from new solution development in that it is usually a succession of parallel microprojects that involve fixing defects and implementing relatively minor enhancements to a solution that is in operation. Legacy maintenance can be thought of as one cycle: implement the change request. Maintenance teams usually follow an abbreviated waterfall model approach, which is generally successful, assuming the projects are small, well-understood, and low-risk. Figure 5-10 depicts a typical legacy maintenance project life cycle.

Used When

The legacy maintenance model is used most effectively for projects that are very small upgrades or fixes to existing business solutions.

Implications for Planning the Requirements Activities

The plan includes activities that involve tracking the backlog of work, working with a change control group to evaluate and prioritize changes, working with the maintenance team, and working with configuration management staff to ensure that fixes are not accidentally overwritten and that older versions of subcomponents are not reintroduced into the production system.

Prototyping Model

Prototyping often begins during requirements elicitation to confirm understanding of the requirements. The overall objectives for the new solution that are known are defined, and areas where further definition is needed are identified for exploration through prototyping. For areas of risk, a prototype if often constructed to help visualize the solution. The prototype is evaluated by the customer/user and is used to refine requirements for the solution to be developed. Iteration occurs as the prototype is fine-tuned to satisfy the needs of the customer while enabling the solution developers to better understand what needs to be built.

Figure 5-10—Legacy Maintenance Model

Once complete, the prototype is used as a reference for requirements documentation, or it can be baselined and used as part of the requirements specification. There are two types of prototypes: (1) rapid prototypes, where the prototype is discarded, and (2) evolutionary prototypes, where the mockup evolves into the end product. Strengths of rapid prototyping are that it allows a small-scale trial in light of uncertain requirements, and it provides insight so requirements can be clearly defined and understood.

Used When

The prototype model is highly effective when requirements are vague, highly uncertain, or subject to volatility. Use when it is necessary to build something before requirements can be understood.

Implications for Planning the Requirements Activities

When planning requirements activities, consider building paper-based or physical prototypes while eliciting and analyzing requirements. To plan, begin with requirements gathering sessions and build a quick design. The customer reviews the design and refines requirements, and then the developers produce successive iterations as the prototype is fine-tuned to satisfy the needs of the customer. Figure 5-11 depicts the iterative nature of refining the prototype until is adequately fulfills the requirement.

Figure 5-11—Prototyping Model

Select the Appropriate Project Life Cycle

The business analyst works collaboratively with the project manager and the technical and business leads to determine the most appropriate project life cycle for use on the project. This essential step ensures the solution development phases, subphases, and deliverables are well-understood prior to planning the requirements elicitation, analysis, and specification activities. When selecting the appropriate project life cycle, we provide two approaches, one based on project strengths and one based on project size, complexity, and risk.

Project Life Cycle Selection Based on Project Strengths

Table 5-1 offers an overall summary of when to use the different project life cycles based on project strengths. The X in a column represents a project’s strength. For example, if project strengths include proven processes, project brevity, and stable requirements, choose the waterfall model as project life cycle. The hybrid cycle is, as the name implies, a combination of two or more approaches.³

Project Life Cycle Selection Based on Project Size, Complexity, and Risk

The project profile (refer once again to Table 3-1) is also helpful when determining the appropriate project life cycle to use. Consider the following when selecting the project life cycle based on the project profile.⁴

Table 5-1—Project Characteristics and Product Cycles

Project Life Cycle for Small, Independent, Low-Risk Projects

The waterfall model is a highly effective project life cycle for short-duration, well-understood projects with stable requirements and few or no dependencies. The waterfall model 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. The waterfall model lays out the steps for development and stresses the importance of requirements. However, keep in mind that projects rarely follow the sequential flow, and customers usually find it difficult to completely state all requirements early in the project.

Project Life Cycle for Medium-Sized, Moderately Complex Projects

As projects become more complicated and more dependencies exist, it is wise to break the work down into manageable components or subprojects delivered incrementally. The challenge is to ensure that the increments can be integrated into a fully functioning solution that meets project objectives. The vee model, which adds the vertical dimension to the waterfall model, altering the waterfall shape into a V shape, is useful for moderately complex projects. At the base of the vee is the component build. Components of the system are developed in increments, and each component produces a partial implementation; functionality is gradually added in subsequent increments.

Project Life Cycle for Large, Highly Complex Projects

Since complex projects are by their very nature less predictable, it is important for the project team to keep its options open, and, indeed, to even build options into the project approach. This keep-our-options-open approach requires a considerable amount of time to be spent on researching and studying the business problem or opportunity; conducting competitive, technological, and benchmark studies; defining dependencies and interrelationships; and identifying all potential options to meet the business need or solve the business problem. In addition, the team analyzes the economic, technical, operational, cultural, and legal feasibility of each solution option until it is clear which option has a highest probability of success.

The model that applies in this situation is the spiral development model, often described as an iterative waterfall approach. In addition, the evolutionary development model can be used, which allows for the implementation of the solution incrementally based on experience and learning from the results of prior versions. Solution functions are prioritized based on business value and, once high-risk areas are resolved, the highest value components are delivered first. This approach may also involve rapid prototyping—a fast build of a solution component to prove an idea is feasible.

Tailor the Project Life Cycle

Once the project life cycle is selected, the core team has all the information needed to tailor the approach to requirements development. Tailoring is the process of customizing the project life cycle to meet the unique needs of a particular project. It involves examining the profile of the project once again before selecting the deliverables, activities, and reviews that fit the essential characteristics of the particular project. Tailoring helps evaluate the project life cycle requirements in order to develop optimum plans. Specifically, tailor the project life cycle in order to:

Save money

Prevent duplication

Meet (preserve) the schedule

Meet quality expectations

Add value

Tailoring applies to both the project and product life cycles. The project manager tailors the project life cycle for the system of planning and control meetings held, the amount of project management documentation produced and maintained, and the general level of rigor and formality. The business analyst tailors the requirements activities within the product life cycle for the number of requirements elicitation events conducted, the number of requirements artifacts produced, the number of control gate reviews conducted to validate requirements, and the general level of rigor and formality.

Determine the Solution Delivery Strategies

There is another factor to consider before finalizing the requirement management plan. In addition to selecting the appropriate project life cycle, there are several delivery strategies to choose from, as listed below.

Single development with single delivery

Incremental development

Single delivery

Incremental delivery

Evolutionary development

Single delivery

Incremental delivery

Table 5-3 provides guidelines for selecting the optimum delivery strategy.

Table 5-3—Solution Delivery Strategies

Use This Approach …	When These Characteristics Are Present
Single development with single delivery	All requirements are known and stable. Full capability is required with initial deployment. Funding is available for full development.
Incremental development with a single delivery	System increments are delivered in phases: To initiate development of long-lead, critical technology For cost-effectiveness Increments are developed individually for assembly into a complete system.
Incremental development with incremental deliveries	Final system requirements and incremental requirements are completely determined beforehand. Increments are planned, developed, and delivered, allowing for assembly into an operational system that incrementally increases functionality. Each increment provides early but limited functionality. Budget limitations and/or incremental funding are accommodated. Successful integration requires careful requirements definition and design.
Evolutionary development	All requirements cannot be completely specified beforehand. Use a trial-and-error process. The development process itself uncovers unforeseen needs and system applications. User feedback is essential. New or enhanced functionality is added to the functioning system at each iteration to satisfy newly discovered needs.

Project Life Cycle Training

Another factor to be taken into account is whether the project team is familiar with the project life cycle that is selected. If the project is using a new development approach, the project manager needs to allocate time and cost for the team members to learn the new development process, tools, and techniques. The first project that implements a new project life cycle will often serve as the pilot. New methods or tools create increased need for training, communication, coaching, and mentoring. The business analyst will also need to plan training time for new users so they can learn how to contribute to elicitation exercises.

Summary

Project life cycles are used to help add structure and control points to projects.

Project life cycles bring order to and reduce the risk of project activities.

Project life cycles provide a repeatable, predictable way to develop products.

The project life cycle identifies the technical work that is needed, the roles needed in each phase, and the control gate entry and exit criteria.

A complete project life cycle defines the work from project management, business analyst, and IT perspectives.

It is essential that the project life cycle is determined and customized in the beginning of a project, prior to the start of requirements activities.

Action Plan for the Business Analyst

Enlist the project manager and the business and technical leads to determine the project life cycle and delivery approach to be used for the project.

Together, tailor and customize the requirements activities, deliverables, and reviews based on the needs of the project. Remember that the more unstable and unclear the requirements are, the more rigor and flexibility are needed.