3

LIFE CYCLE SELECTION

Projects come in many shapes and there are a variety of ways to undertake them. Project teams need awareness of the characteristics and options available to select the approach most likely to be successful for the situation.

This practice guide refers to four types of life cycles, defined as follows:

• Predictive life cycle. A more traditional approach, with the bulk of planning occurring upfront, then executing in a single pass; a sequential process.
• Iterative life cycle. An approach that allows feedback for unfinished work to improve and modify that work.
• Incremental life cycle. An approach that provides finished deliverables that the customer may be able to use immediately.
• Agile life cycle. An approach that is both iterative and incremental to refine work items and deliver frequently.

3.1 CHARACTERISTICS OF PROJECT LIFE CYCLES

Table 3-1 summarizes the characteristics of the four life cycle categories covered in this practice guide.

It is important to note that all projects have these characteristics—no project is completely devoid of considerations around requirements, delivery, change, and goals. A project's inherent characteristics determine which life cycle is the best fit for that project.

Another way to understand how project life cycles vary is by using a continuum ranging from predictive cycles on one end, to agile cycles on the other end, with more iterative or incremental cycles in the middle.

Figure X3-1 of Appendix X3 of the PMBOK® Guide – Sixth Edition displays the continuum as a flat line. This view emphasizes the shifting of project characteristics from one end to the other. Another way to visualize the continuum is with a two-dimensional square, as shown in Figure 3-1.

No life cycle can be perfect for all projects. Instead, each project finds a spot on the continuum that provides an optimum balance of characteristics for its context. Specifically,

• Predictive life cycles. Take advantage of things that are known and proven. This reduced uncertainty and complexity allows teams to segment work into a sequence of predictable groupings.
• Iterative life cycles. Allow feedback on partially completed or unfinished work to improve and modify that work.
• Incremental life cycles. Provide finished deliverables that the customer may be able to use immediately.
• Agile life cycles. Leverage both the aspects of iterative and incremental characteristics. When teams use agile approaches, they iterate over the product to create finished deliverables. The team gains early feedback and provides customer visibility, confidence, and control of the product. Because the team can release earlier, the project may provide an earlier return on investment because the team delivers the highest value work first.

3.1.1 CHARACTERISTICS OF PREDICTIVE LIFE CYCLES

Predictive life cycles expect to take advantage of high certainty around firm requirements, a stable team, and low risk. As a result, project activities often execute in a serial manner, as shown in Figure 3-2.

In order to achieve this approach, the team requires detailed plans to know what to deliver and how. These projects succeed when other potential changes are restricted (e.g., requirements changes; project team members change what the team delivers). Team leaders aim to minimize change for the predictive project.

When the team creates detailed requirements and plans at the beginning of the project, they can articulate the constraints. The team can then use those constraints to manage risk and cost. As the team progresses through the detailed plan, they monitor and control changes that might affect the scope, schedule, or budget.

By emphasizing a departmentally efficient, serialized sequence of work, predictive projects do not typically deliver business value until the end of the project. If the predictive project encounters changes or disagreements with the requirements, or if the technological solution is no longer straightforward, the predictive project will incur unanticipated costs.

3.1.2 CHARACTERISTICS OF ITERATIVE LIFE CYCLES

Iterative life cycles improve the product or result through successive prototypes or proofs of concept. Each new prototype yields new stakeholder feedback and team insights. Then, the team incorporates the new information by repeating one or more project activities in the next cycle. Teams may use timeboxing on a given iteration for a few weeks, gather insights, and then rework the activity based on those insights. In that way, iterations help identify and reduce uncertainty in the project.

Projects benefit from iterative life cycles when complexity is high, when the project incurs frequent changes, or when the scope is subject to differing stakeholders’ views of the desired final product. Iterative life cycles may take longer because they are optimized for learning rather than speed of delivery.

Figure 3-3 illustrates some elements of an iterative project life cycle for a single product delivery.

3.1.3 CHARACTERISTICS OF INCREMENTAL LIFE CYCLES

Some projects optimize for speed of delivery. Many businesses and initiatives cannot afford to wait for everything to be completed; in these cases, customers are willing to receive a subset of the overall solution. This frequent delivery of smaller deliverables is called an incremental life cycle (see Figure 3-4).

TIP

Are you unsure of how a new business service might work in practice? Create a proof of concept with evaluation criteria to explore desired outcomes. Use iterative approaches when you suspect the requirements will change based on customer feedback.

Incremental life cycles optimize work for delivering value to sponsors or customers more often than a single, final product. Teams plan initial deliverables before beginning their work, and they begin working on that first delivery as soon as possible. Some agile projects deliver value within days of project initiation. Others could take longer, ranging from 1 week to several weeks.

As the project continues, the team may deviate from the original vision. The team can manage the deviations, because the team delivers value sooner. The degree of change and variation is less important than ensuring customers get value sooner than at the end of the project.

Providing a customer a single feature or a finished piece of work is an example of the incremental approach.

For example, builders may want to show a finished room or floor of a building before they continue with the remainder of the building. In that case, they may complete a floor with fixtures, paint, and everything else intended for the finished floor before proceeding to the next floor. The customer is able to see and approve of the style, color, and other details, allowing adjustments to be made before further investments of time and money are made. This reduces potential rework and/or customer dissatisfaction.

3.1.4 CHARACTERISTICS OF AGILE LIFE CYCLES

In an agile environment, the team expects requirements to change. The iterative and incremental approaches provide feedback to better plan the next part of the project. However, in agile projects, incremental delivery uncovers hidden or misunderstood requirements. Figure 3-5 illustrates two possible ways to achieve incremental delivery so the project aligns with customer needs and can be adapted as necessary.

In iteration-based agile, the team works in iterations (timeboxes of equal duration) to deliver completed features. The team works on the most important feature, collaborating as a team to finish it. Then the team works on the next most important feature and finishes it. The team may decide to work on a few features at a time, but the team does not address all of the work for the iteration at once (i.e., does not address all of the requirements, followed by all of the analyses, etc.).

In flow-based agile, the team pulls features from the backlog based on its capacity to start work rather than on an iteration-based schedule. The team defines its workflow with columns on a task board and manages the work in progress for each column. Each feature may take a different amount of time to finish. Teams keep work-in-progress sizes small to better identify issues early and reduce rework should changes be required. Without iterations to define planning and review points, the team and business stakeholders determine the most appropriate schedule for planning, product reviews, and retrospectives.

Agile life cycles are those that fulfill the principles of the Agile Manifesto. In particular, customer satisfaction increases with early and continuous delivery of valuable products. Moreover, an incremental deliverable that is functional and provides value is the primary measure of progress. Agile life cycles combine both iterative and incremental approaches in order to adapt to high degrees of change and deliver project value more often.

3.1.5 AGILE SUITABILITY FILTERS

Various assessment models exist to help determine the likely fit or gaps for using agile approaches. These models assess project and organizational factors associated with adoption and suitability and then provide scores indicating alignment or potential risk areas. Appendix X3 provides a synthesis of popular assessment models for use as an agile suitability filter.

3.1.6 CHARACTERISTICS OF HYBRID LIFE CYCLES

It is not necessary to use a single approach for an entire project. Projects often combine elements of different life cycles in order to achieve certain goals. A combination of predictive, iterative, incremental, and/or agile approaches is a hybrid approach.

Figure 3-6 depicts the basic, pure approaches to project types that combine to form a hybrid model. The early processes utilize an agile development life cycle, which is then followed by a predictive rollout phase. This approach can be used when there is uncertainty, complexity, and risk in the development portion of the project that would benefit from an agile approach, followed by a defined, repeatable rollout phase that is appropriate to undertake in a predictive way, perhaps by a different team. An example of this approach is the development of a new high-tech product followed by rollout and training to thousands of users.

3.1.7 COMBINED AGILE AND PREDICTIVE APPROACHES

Another approach is to use a combination of agile and predictive approaches throughout the life cycle.

In Figure 3-7, a combination of both predictive and agile approaches are used in the same project. Perhaps the team is incrementally transitioning to agile and using some approaches like short iterations, daily standups, and retrospectives, but other aspects of the project such as upfront estimation, work assignment, and progress tracking are still following predictive approaches.

Using both predictive and agile approaches is a common scenario. It would be misleading to call the approach agile since it clearly does not fully embody the agile mindset, values, and principles. However, it would also be inaccurate to call it predictive since it is a hybrid approach.

3.1.8 PREDOMINANTLY PREDICTIVE APPROACH WITH SOME AGILE COMPONENTS

Figure 3-8 shows a small agile element within a chiefly predictive project. In this case, a portion of the project with uncertainty, complexity, or opportunity for scope creep is being tackled in an agile way, but the remainder of the project is being managed using predictive approaches. An example of this approach would be an engineering firm that is building a facility with a new component.

While the majority of the project may be routine and predictable, like many other facility projects the organization has undertaken before, this project incorporates a new roofing material. The contractor may plan for some small-scale installation trials on the ground first to determine the best installation method and to uncover issues early while there is plenty of time to solve them and incrementally improve processes through experimentation and adaptation.

3.1.9 A LARGELY AGILE APPROACH WITH A PREDICTIVE COMPONENT

Figure 3-9 depicts a largely agile approach with a predictive component. This approach might be used when a particular element is non-negotiable or not executable using an agile approach. Examples include integrating an external component developed by a different vendor that cannot or will not partner in a collaborative or incremental way. A single integration is required after the component is delivered.

3.1.10 HYBRID LIFE CYCLES AS FIT-FOR-PURPOSE

Project teams may design a hybrid life cycle based on project risks. For example, a campus construction project may have multiple buildings to improve and build. An incremental approach would focus resources on completing some buildings earlier than others, accelerating the return on investment. Each individual delivery may be sufficiently well known to benefit from a predictive life cycle for that building alone.

The goal of project management is to produce business value in the best possible way given the current environment. It does not matter if that way is agile or predictive. The question to ask is: “How can we be most successful?”

Is feedback needed as the team produces value? If so, increments will help. Is it necessary to manage risk as ideas are explored? If so, iterations or agile will help.

When the organization cannot deliver intermediate value, agile approaches may not be useful. That is okay—agile for the sake of agile is not the goal. The point is to select a life cycle or a combination of life cycles that work for the project, the risks, and the culture.

Agile is about customer-based delivery on a frequent basis. That delivery creates feedback for the team. The team uses that feedback to plan and replan the next chunk of work.

3.1.11 HYBRID LIFE CYCLES AS TRANSITION STRATEGY

Many teams are not able to make the switch to agile ways of working overnight. Agile techniques look and feel very different to those who are accustomed to and have been successful in a predictive environment. The larger the organization and the more moving parts, the longer it will take to transition. For that reason, it makes sense to plan a gradual transition.

A gradual transition involves adding more iterative techniques to improve learning and alignment among teams and stakeholders. Later, consider adding more incremental techniques to accelerate value and return on investment to sponsors. This combination of various approaches is considered a hybrid approach.

Try these new techniques on a less risky project with a medium- to low-degree of uncertainty. Then, when the organization is successful with a hybrid approach, try more complex projects that require more of those techniques to be added. This is a way to tailor the progressive hybrid transition to the organization's situation and specific risks and the team's readiness to adapt and embrace the changes.

3.2 MIXING AGILE APPROACHES

Agile teams rarely limit their practices to one agile approach. Each project context has its own peculiarities, such as the varied mix of team member skills and backgrounds; the various components of the product under development; and the age, scale, criticality, complexity, and regulatory constraints of the environment in which the work takes place.

Agile frameworks are not customized for the team. The team may need to tailor practices to deliver value on a regular basis. Often, teams practice their own special blend of agile, even if they use a particular framework as a starting point.

3.3 PROJECT FACTORS THAT INFLUENCE TAILORING

Sometimes project attributes require tailoring an approach for a better fit. Table 3-2 identifies some project factors and tailoring options to consider.

Table 3-2. Tailoring Options to Improve Fit

For additional guidance on factors that influence tailoring see Appendix X2 on Attributes that Influence Tailoring.