PMBOK - Chapter 2 - 2.3 DEVELOPMENT APPROACH AND LIFE CYCLE PERFORMANCE DOMAIN (2/2)

2.3.4 CONSIDERATIONS FOR SELECTING A DEVELOPMENT APPROACH 

There are several factors that influence the selection of a development approach. They can be divided into categories of the product, service, or result; the project; and the organization. The following subsections describe the variables associated with each category.

2.3.4.1 Product, Service, or Result 

There are many variables associated with the nature of the product, service, or result that influence the development approach. The following list outlines some of the variables to consider when selecting the development approach. 

▶ Degree of innovation. Deliverables where the scope and requirements are well understood, that the project team has worked with before, and that allow for planning up front are well suited to a predictive approach. Deliverables that have a high degree of innovation or where the project team does not have experience are better suited to a more adaptive approach. 

▶ Requirements certainty. When the requirements are well known and easy to define, a predictive approach fits well. When requirements are uncertain, volatile, or complex and are expected to evolve throughout the project, a more adaptive approach may be a better fit.

▶ Scope stability. If the scope of the deliverable is stable and not likely to change, a predictive approach is useful. If the scope is expected to have many changes, an approach that is closer to the adaptive side of the spectrum can be useful. 

▶ Ease of change. Related to the requirements certainty and the scope stability, if the nature of the deliverable makes it difficult to manage and incorporate changes, then a predictive approach is best. Deliverables that can adapt easily to change can use an approach that is more adaptive. 

▶ Delivery options. As described in Section 2.3.2 on Delivery Cadence, the nature of the deliverable and whether it can be delivered in components influences the development approach. Products, services, or results that can be developed and/or delivered in pieces are aligned with incremental, iterative, or adaptive approaches. Some large projects may be planned using a predictive approach, but there may be some pieces that can be developed and delivered incrementally. 

▶ Risk. Products that are inherently high risk require analysis before choosing the development approach. Some high-risk products may require significant up-front planning and rigorous processes to reduce threats. Other products can reduce risk by building them modularly and adapting the design and development based on learning to take advantage of emerging opportunities or reduce the exposure to threats. 

▶ Safety requirements. Products that have rigorous safety requirements often use a predictive approach as there is a need for significant up-front planning to ensure that all the safety requirements are identified, planned for, created, integrated, and tested. 

▶ Regulations. Environments that have significant regulatory oversight may need to use a predictive approach due to the required process, documentation, and demonstration needs.

2.3.4.2 Project 

Project variables that influence the development approach are centered around stakeholders, schedule constraints, and funding availability. 

▶ Stakeholders. Projects that use adaptive methods require significant stakeholder involvement throughout the process. Certain stakeholders, such as the product owner, play a substantial role in establishing and prioritizing work.

▶ Schedule constraints. If there is a need to deliver something early, even if it is not a finished product, an iterative or adaptive approach is beneficial. 

▶ Funding availability. Projects that work in an environment of funding uncertainty can benefit from an adaptive or iterative approach. A minimum viable product can be released with less investment than an elaborate product. This allows for market testing or market capture with minimum investment. Further investments can be made based on the market response to the product or service. 

2.3.4.3 Organization

Organizational variables such as the structure, culture, capability, project team size, and location influence the development approach. 

▶ Organizational structure. An organizational structure that has many levels, a rigid reporting structure, and substantial bureaucracy frequently uses a predictive approach. Projects that use adaptive methods tend to have a flat structure and may operate with selforganizing project teams. 

▶ Culture. A predictive approach fits better in an organization with a culture of managing and directing, where the work is planned out and progress is measured against baselines. Adaptive approaches fit better within an organization that emphasizes project team selfmanagement. 

▶ Organizational capability. Transitioning from predictive development approaches to adaptive approaches and then to using agile methods is more than just stating that the organization will now be agile. It entails shifting the mindset starting at the executive level throughout the organization. Organizational policies, ways of working, reporting structure, and attitude should all be aligned in order to employ adaptive methods successfully. 

▶ Project team size and location. Adaptive approaches, especially agile methods, often work better with project teams of 7 ± 2. Adaptive approaches also favor project teams that are located in the same physical space. Large project teams and project teams that are mostly virtual may do better by using an approach that is closer to the predictive side of the spectrum. However, there are approaches that seek to scale up the adaptive approaches to work with large and dispersed project teams.

2.3.5 LIFE CYCLE AND PHASE DEFINITIONS 

The type and number of project phases in a project life cycle depend upon many variables, chief among them the delivery cadence and the development approach, as described previously. Examples of phases in a life cycle include: 

▶ Feasibility. This phase determines if the business case is valid and if the organization has the capability to deliver the intended outcome. 

▶ Design. Planning and analysis lead to the design of the project deliverable that will be developed. 

▶ Build. Construction of the deliverable with integrated quality assurance activities is conducted. 

▶ Test. Final quality review and inspection of deliverables are carried out before transition, go-live, or acceptance by the customer. 

▶ Deploy. Project deliverables are put into use and transitional activities required for sustainment, benefits realization, and organizational change management are completed. 

▶ Close. The project is closed, project knowledge and artifacts are archived, project team members are released, and contracts are closed.

Project phases often have a phase gate review (also known as stage gate) to check that the desired outcomes or exit criteria for the phase have been achieved before proceeding to the next phase. Exit criteria may tie to acceptance criteria for deliverables, contractual obligations, meeting specific performance targets, or other tangible measures.

Figure 2-9 shows a life cycle where one phase finishes before the next one begins. This type of life cycle would fit well with a predictive development approach since each phase is only performed once, and each phase focuses on a particular type of work. However, there are situations, such as adding scope, a change in requirements, or a change in the market that cause phases to be repeated

Figure 2-10 shows a life cycle with an incremental development approach. There are three iterations of plan, design, and build shown in this example. Each subsequent build would add functionality to the initial build.

Figure 2-11 shows a life cycle using an adaptive development approach. At the end of each iteration (sometimes known as a sprint), the customer reviews a functional deliverable. At the review, the key stakeholders provide feedback, and the project team updates the project backlog of features and functions to prioritize for the next iteration.

This approach can be modified for use in continuous delivery situations, as described in Section 2.3.2 on Delivery Cadence.

Several adaptive methodologies, including agile, use flow-based scheduling, which does not use a life cycle or phases. One goal is to optimize the flow of deliveries based on resource capacity, materials, and other inputs. Another goal is to minimize time and resource waste and optimize the efficiency of processes and the throughput of deliverables. Projects that use these practices and methods usually adopt them from the Kanban scheduling system used in lean and just-intime scheduling approaches.

2.3.6 ALIGNING OF DELIVERY CADENCE, DEVELOPMENT APPROACH, AND LIFE CYCLE 

The community center examples described in Section 2.3.3 will be revisited to demonstrate how the delivery cadence, development approach, and life cycle fit together. In this example, there are four products and services: the building, the community action patrol (CAP) training, the senior services, and the website. Table 2-4 describes the delivery cadence and the development approach.

Table 2-4. Delivery Cadence and Development Approach

Based on this information, a potential life cycle might be: 

▶ Start Up. Entry criteria for this phase are that the business case has been approved and the project charter has been authorized. In this phase, the high-level roadmap is developed, initial funding requirements are established, project team and resource requirements are defined, a milestone schedule is created, and planning for a procurement strategy is defined. These deliverables should be complete prior to exiting the start-up phase. Exit criteria will be reviewed at an origination phase gate review. 

▶ Plan. In this phase, the high-level information for the building is decomposed into detailed plans. A detailed design document for the CAP training is completed. An analysis of the senior services offering is completed along with a gap analysis. The initial wireframe for the website is created. These deliverables should be complete prior to exiting the planning phase. Exit criteria will be reviewed at a planning phase gate review.

▶ Development. This phase will overlap with the test and deploy phases since the deliverables have different delivery cadences and different approaches. The website will have early deliveries to inform the public of the progress for the community center. Some senior services and the CAP training may begin prior to the opening of the community center. Each deliverable may have a separate review prior to entering the testing phase. 

▶ Test. This phase will overlap with the development and deploy phases. The type of test will depend on the deliverable. This phase includes inspections for the building, a beta delivery of the CAP courses, small-scale trials for the senior services, and operating in a test environment for each release for the website. Each deliverable will go through the applicable testing prior to moving to the deploy phase. 

▶ Deploy. This phase will overlap with the development and test phases. The first deployment of the website may be somewhat early in the project. Activities in this phase will iterate as more deliverables become available. The final deployment for the project will be the opening of the community center. Ongoing updates to the website and the senior services will be part of operations once the community center is open. 

▶ Close. This phase takes place periodically as deliverables are completed. When the initial website has been deployed, project personnel (including contractors) will be released and retrospectives or lessons learned for each deliverable will be completed. When the entire project is done, information from the various phase gate reviews and an overall evaluation of project performance compared to baselines will be conducted. Prior to final closeout, the project charter and the business case will be reviewed to determine if the deliverables achieved the intended benefits and value.

Figure 2-12 shows a possible life cycle for the community center project. The start-up and planning phases are sequential. The development, test, and deploy phases overlap because the different deliverables will be developed, tested, and deployed at different times, and some deliverables will have multiple deliveries. The development phase is shown in more detail to demonstrate different timing and delivery cadence. The test phase cadence would follow the development phase cadence. The deliveries are shown in the deploy phase.

What’s in a Name? Not all project practitioners differentiate between the development approach and the life cycle. Some practitioners will say a project follows an agile life cycle when they are actually talking about the development approach. Some practitioners refer to predictive approaches as waterfall. Adaptive development approaches may also be known as evolutionary approaches. 

Because project management is evolving, the language used continues to evolve. The best way to understand what a person is referring to is to determine how they are developing deliverables and ask them the names of the phases in the life cycle. This can help frame the project and understand how people are using terms.

2.3.7 INTERACTIONS WITH OTHER PERFORMANCE DOMAINS 

The Development Approach and Life Cycle Performance Domain interacts with the Stakeholder, Planning, Uncertainty, Delivery, Project Work, and Team Performance Domains. The life cycle selected impacts the way in which planning is undertaken. Predictive life cycles undertake the bulk of the planning up front and then continue to replan by using rolling wave planning and progressive elaboration. Plans are also updated as threats and opportunities materialize. 

The development approach and delivery cadence is one way to reduce uncertainty on projects. A deliverable that has a lot of risk associated with meeting regulatory requirements may choose a predictive approach to build in extra testing, documentation, and robust processes and procedures. A deliverable that has a lot of risk associated with stakeholder acceptance may choose an iterative approach and release a minimum viable product to the market to get feedback before developing additional features and functions.

The Development Approach and Life Cycle Performance Domain has significant overlap with the Delivery Performance Domain when considering delivery cadence and development approach. The delivery cadence is one of the main drivers of delivering value in alignment with the business case and the benefits realization plans. Eliciting the product requirements and meeting the quality requirements as described in the Delivery Performance Domain have a significant influence on the development approach. 

The Team Performance Domain and the Development Approach and Life Cycle Performance Domain interact when it comes to project team capabilities and project team leadership skills. The project team’s way of working and the project manager’s style vary significantly depending on the development approach. A predictive approach usually entails more emphasis on up-front planning, measurement, and control. On the other end of the spectrum, an adaptive approach, especially when using agile methods, requires more of a servant leadership style and may have self-managing project teams. 

2.3.8 MEASURING OUTCOMES 

Table 2-5 identifies the outcomes on the left and ways of checking them on the right.

Table 2-5. Checking Outcomes—Development Approach and Life Cycle Performance Domain