Development Approach and Life Cycle Performance Domain

By , ,

Date: Jul 3, 2023

Return to the article

In this sample chapter from Certified Associate in Project Management (CAPM)® Exam Official Cert Guide, you will learn fundamental concepts involved in the Development Approach and Life Cycle Performance Domain and how to use deliverables and milestones in project planning and execution.

This chapter covers the following topics:

This chapter introduces the fundamental concepts involved in the Development Approach and Life Cycle Performance Domain. This domain involves the choices a project manager makes in terms of the order in which certain required tasks are done, to what extent the team can take different paths through those required steps, and how these factors influence the life cycle of the project. Several types of life cycles are described, including the typical considerations for choosing which type of life cycle is best for a given situation and project context. Finally, this chapter covers the important concepts related to deliverables and milestones to ensure that you know how to define them and use them in the planning and execution of a project.

CAUTION

The project management information, templates, tools, and techniques in this chapter are provided for your education only. Use this knowledge prudently when applying it to projects at work. Also, while we have aligned the material with the Project Management Institute’s (PMI’s) Exam Content Outline, there is no assurance that successfully completing this book will result in students passing the Certified Associate in Project Management (CAPM)® exam.

By the time you reach the end of this chapter, within the context of the following domains and tasks, you should be able to:

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should read this entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in doubt about your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 4-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes.”

Table 4-1 “Do I Know This Already?” Section-to-Question Mapping

Foundation Topics Section

Questions

Fundamentals of the Project Life Cycle

2, 13

Project Life Cycle vs. Product Life Cycle

5

Development Approach and Life Cycle Performance Domain Concepts

3, 8, 10

Life Cycles in Practice

1, 7, 12

Considerations for Selecting a Development Approach

9, 11, 14

Project Activity, Deliverables, and Milestones

4, 6, 15

CAUTION

The goal of self-assessment is to gauge your mastery of the topics in this chapter. If you do not know the answer to a question or are only partially sure of the answer, you should mark that question as wrong for purposes of the self-assessment. Giving yourself credit for an answer you correctly guess skews your self-assessment results and might provide you with a false sense of security.

1. If the requirements for software change in a minor way due to customer feedback or testing failure, the project team can revisit these minor changes through revised design, coding, and testing. The idea is to discover these issues as early as possible because the cost of changing the system can be greater as more of it is developed through the life cycle of the project. When you have this viewpoint, you are viewing software development as a(n) _____.

  1. predictive approach

  2. product approach

  3. adaptive approach

  4. hybrid approach

2. Which of the following is the term for a temporary endeavor to develop a unique outcome through a series of interrelated steps from initial concept to a completed state?

  1. Phase

  2. Product life cycle

  3. Activity

  4. Project life cycle

3. Your operations manager has tasked you with defining a development approach for the construction of a tool shed next to your manufacturing facility. The scope, schedule, cost, resource needs, and risks can be well defined in the early phases of the project life cycle, and they are relatively stable. Which approach should you take in this case?

  1. Predictive

  2. Product

  3. Adaptive

  4. Hybrid

4. Which of the following is the term for a scheduled step in a project plan that has a distinct beginning and end and may consist of several substeps?

  1. Phase

  2. Deliverable

  3. Activity

  4. Milestone

5. ABC Company has determined that its Widget 452 model is selling less briskly than it has during the past two years. Executives of the company determine that it is time to phase out Widget 452 and bring Widget 673 into production and sales. These factors would lead you to believe that the executives are discussing a(n) _____.

  1. phase

  2. product life cycle

  3. activity

  4. project life cycle

6. Which of the following is a tangible or intangible measurable output of one or more project activities?

  1. Milestone

  2. Deliverable

  3. Phase

  4. Objective

7. You are managing a software development project and have planned that the final deliverable will be brought into existence in successively refined stages at prototype, pilot, testing, and deployment stages. In this case, you are viewing software development as a(n) _____.

  1. predictive approach

  2. adaptive approach

  3. hybrid approach

  4. product approach

8. The product owner for a clothing manufacturer/retailer has tasked you with defining a development approach for a new line of children’s clothing. This organization has never sold clothing for children, and no one on the team has had any experience with this type of product. One very rigid consideration is that this particular company wants a line of children’s clothing that is unique in the market, so you cannot just import a line from another company and rebrand it. Which development approach should you use in this case?

  1. Predictive

  2. Product

  3. Adaptive

  4. Hybrid

9. Scheduling constraints, the availability of funding, and the nature of the involved stakeholders are all factors that are part of which aspect of the model of considerations for selecting a development approach?

  1. Product, service, or result

  2. Project

  3. Organization

  4. Competition

10. You are the project manager for information systems in a major banking firm. This particular company has not had its own mobile application. The senior vice president for operations has asked you, along with others in the IT and operations groups, to define a project that will produce an initial mobile application. The vice president has been particularly emphatic about the fact that this application must meet all compliance requirements for consumer use; other than that, your teams have freedom in the design and operation of the app. These factors suggest that you probably want to use which development approach?

  1. Predictive

  2. Product

  3. Adaptive

  4. Hybrid

11. The project team size and location, the overall culture, and capability are all factors that are part of which aspect of the model of considerations for selecting a development approach?

  1. Product, service, or result

  2. Project

  3. Organization

  4. Competition

12. Certain aspects of your retail store project allow you to plan for a known outcome of the construction of your retail store location. Other aspects of the market development and product testing are less stable at the early stages because you want to establish a more unique approach to your store. To bring about the final operating store in your chosen location, which approach might you want to adopt?

  1. Predictive

  2. Adaptive

  3. Hybrid

  4. Product

13. A(n) _____ is a collection of logically related project activities that culminates in the completion of one or more deliverables.

  1. phase

  2. product life cycle

  3. activity

  4. project life cycle

14. Degree of innovation, ease of change, requirements, and regulations are all factors that are part of which aspect of the model of considerations for selecting a development approach?

  1. Product, service, or result

  2. Project

  3. Organization

  4. Competition

15. Although a(n) ______ is scheduled in a project plan, it has no estimated duration and is used to provide information about progress through the major segments.

  1. milestone

  2. deliverable

  3. phase

  4. activity

Foundation Topics

Fundamentals of the Project Life Cycle

Life cycle is a term we use to describe the overall time of existence of something. We know that stars such as our sun have a certain predictable life cycle, from the time they form to the last point of their existence. Trees have a life cycle, from a seed, to a towering adult, to a fallen trunk on the ground in the forest. In fact, if you look around in a forest, you can usually see trees in many phases of their life cycle. The fact that these phases are similar for different kinds of trees suggests that the phases within a life cycle are true on a very broad, or high-level, basis for everything we might classify as a tree. Therefore, if we can recognize where a tree is in its life cycle, we can predict what will likely come next.

In fact, it was a typical forest that inspired early astronomers to realize that all the objects they were seeing through their telescopes out there in the universe were not different objects at all; instead, they began to realize that many of them were similar objects at varying phases of existence along their individual life cycles.

The Concept of a Project Life Cycle

Like stars and trees, all projects have noticeable high-level phases as they evolve from initial ideas to completion. People think of projects also evolving in a somewhat sequential fashion, although we know it is common for changes in project requirements or other issues to result in a need to repeat previous sequential steps to include revisions. In general, when we think of this high-level progression from an initial state to a completed state, we can refer to it as a project life cycle. We can see many types of projects go through this sort of progression, even though the end goals, deliverables, or even application domains of the project (such as construction, software, or event management) might be very different from one another.

People use various terms when discussing the overall life cycle of a project, including stage, step, and phase. The various points in the life cycles of projects are described using terms such as prototype and final rollout. In Section 2.3 of the PMBOK® Guide – Seventh Edition, PMI has formalized two terms that are important foundational concepts for this chapter:

You can think of a project phase as a “chunk” of the project—a lower-level concept that involves logically related activities and the completion of specific deliverables or types of deliverables. These chunks make up the general project life cycle, which is an overall arc of existence for a project as it takes various shapes while evolving from start to finish.

Visualizing a Project Life Cycle

Figure 4-1 shows a project life cycle going through six phases:

Figure 4-1 A Typical Project Life Cycle

  1. Aspire: This is the project aspiration and ideation phase, the origin for projects. Here a project portfolio is created to address problems or opportunities in an organization. In this pre-project phase, you need to ensure that any proposed project idea is aligned with the organization’s mission.

  2. Business case analysis: The proposed project idea needs to be justified based on evidence and details; this is where the business case comes into play. The objective of the business case is to assess the project benefit and value that the proposed project brings to stakeholders. This life cycle phase involves documenting, among other things, a profit-and-loss investment analysis.

  3. Create charter: The project sponsor formally authorizes the existence of a project after considering the business case and organizational needs. The project charter is an official document that identifies the project manager and grants authority to apply organizational resources to project activities.

  4. Develop the project management plan: This phase looks at the activities that need to be completed to deliver the project successfully. It considers both project- and product-related activities. From a project manager’s perspective, this is a very important phase, and much effort is expended to plan and organize the project in detail.

  5. Execute the project management plan: In this phase, the project management plan is executed. The project team must be motivated and led successfully to produce the project deliverables. There is also a monitoring and controlling aspect to the execution phase; milestones must be attained within the targeted project schedule, cost, and quality constraints.

  6. Finish: Here the project is completed and closed. The project manager handles administrative closure and lessons learned, and communicates project results.

The aspire and business case phases are often considered to be pre-project phases. Most project management practice and foundational project management standards focus on the remaining phases—from developing the charter to closing the project.

One of the reasons for this focus on the last four phases is that different vendors and organizations have unique proprietary activities for the pre-project phases: aspire and business case analysis.

For example, a life cycle could have just the phases of analysis, design, development, acceptance, and implementation. These five phases outline a methodical, step-by-step process for managing any project. With this approach, phases before analysis are considered pre-project activities; any phases after implementation are considered post-implementation phases. Post-implementation work might include such activities as project benefits tracking, in which the original concepts of the business case are measured and validated as being either achieved or not. The separations of pre- and post-implementation phases in these organizations can sometimes be due to the fact that other teams besides the “performing organization” (that is, the project team) are given charge of these front- and back-end phases. In contrast, the project team concentrates only on the five phases of work in between.

Stage Gates

Progressive elaboration takes place as a project progresses from one phase to another. The increasing amount of detail available as a project moves along provides opportunities to review whether there is any value in continuing to invest in the project. As illustrated in Figure 4-2, a stage gate is a point for deciding whether a project should be continued or terminated. Stopping a project early on can result in substantial cost savings. Steering committee members review the project progress, value, and business environment and decide whether to continue, suspend, or cancel the project completely. In other words, a stage gate is a gate that blocks further progress down the path of the project until some authority allows it to be opened after an appropriate review of the progress to this point. Stage gates are also known as phase review points or kill points.

Figure 4-2 Life Cycle Phases with Stage Gate Checkpoints

Project Life Cycle vs. Project Management Process Groups

How do the Project Management Process Groups, a hallmark of previous editions of the PMBOK® Guide, relate to a project life cycle? This is a common question and concern even among experienced practitioners. The PMIstandards+™ online guide defines 49 processes that are associated with project management process groups. While references to the Process Groups can be found in the current edition, details of project processes can be found now in Process Groups: A Practice Guide. We have also reproduced them in summary form for your reference in Appendix B, “PMBOK® Guide Process Groups and Processes.”

The five Project Management Process Groups—Initiating, Planning, Executing, Monitoring and Controlling, and Closing—are illustrated in Figure 4-3. There is some symmetry between a project life cycle and the Project Management Process Groups. The Initiating Process Group consists of processes such as Identify Stakeholders, Develop Project Charter; the Planning Process Group consists of processes such as Collect Requirements, Define Scope, and Create a Work Breakdown Structure (WBS). Similar processes are associated with Executing, Monitoring and Controlling, and Closing. We provide details of these processes in Chapter 5, “Planning, Project Work, and Delivery: Predictive Methodologies.”

Figure 4-3 Life Cycle Phases vs. PMBOK® Process Groups

Whereas a life cycle is more like a linear flow, the Project Management Process Groups can iterate at each life cycle phase. For example, consider a project that involves creating a charter document for the Olympics, as illustrated in Figure 4-4. The Olympics is such a massive event that creating a charter and getting all stakeholders onboard is a significant undertaking. This single complex project would involve all five process groups.

Figure 4-4 PMBOK Process Groups Can Apply at Each Phase of the Life Cycle

Figure 4-5 illustrates how the Project Management Process Groups iterate in large projects in each phase. Notice that it is possible to implement some or all of the processes associated with the project during each iteration.

Figure 4-5 Repeating Project Process Groups in a Project

Project Life Cycle vs. Product Life Cycle

The Standard for Project Management defines a product as an artifact that is produced, is quantifiable, and is either an end item or a component item. A product life cycle begins when a product is conceived and development is started. It is then introduced to the market. This is followed by a growth in sales, a sales peak, and often a gradual decline, after which the product is typically withdrawn from the market. At this point, a new version or a new product concept takes its place in another product cycle. Figure 4-6 illustrates a typical product life cycle. After development, a product typically goes through the introduction, growth, maturity, and decline phases.

Figure 4-6 Product Management Life Cycle

Profits follow a different curve. There is an early investment when the product is in development, so profits do not accrue instantly with the first sales; they are offset in time until the product has been in the marketplace long enough to have paid back the investments of development and for sales to have scaled up sufficiently for the product to become profitable. If the product is successful, there is a reasonable period of profitability during the product’s maturity stage. Inevitably, product yields decline in sales or interest and are superseded by newer or better product versions, or they are withdrawn from the marketplace.

Consider the case of a smartphone. After Release 1, a newer product version emerges as Release 2. If you consider each release as a project, you have multiple projects, as illustrated in Figure 4-6.

NOTE

When a product or service is introduced to the market, it is no longer a project. Product management is a complex discipline, but this chapter’s introduction to product management should give you sufficient knowledge to pass the CAPM® exam.

Development Approach and Life Cycle Performance Domain Concepts

Different approaches can be used for deployment, depending on the project goals and desired outcomes, as well as the risk or uncertainty associated with a project’s environment. The PMBOK® Guide – Seventh Edition considers this an important topic and has articulated this as a performance domain in Section 2.3, Figure 2-6. Figure 4-7 shows the key outcomes that should result from the successful execution of this domain.

Figure 4-7 Development Approach and Life Cycle Performance Domain (Source: Figure 2-6, PMBOK® Guide – Seventh Edition)

Terms Relevant to the Development Approach and Life Cycle Performance Domain

In addition to the terms project phase and project life cycle, this performance domain focuses on some other key terms:

Development approaches can be broadly seen as two extremes in terms of goals and implementation. Figure 4-8 shows the predictive and adaptive extremes, as well as a blended development approach that uses some of both, known as a hybrid approach.

Figure 4-8 Types of Development Approaches

The hybrid development approach combines two or more predictive and adaptive elements. For example, within a generally linear step-by-step project flow, you could have one of the steps refer to the development of a mobile app. This particular step might be adaptive until its completion, to account for the need to carefully iterate user input until a final, finished app has been delivered. After its completion, the remaining linear steps of the predictive approach take over until the completion of the project. Therefore, the hybrid development approach is seen as applying the best of both extremes in a combination that is most appropriate for the specific project outcomes that are needed.

Terms used to describe these approaches have varied over the years. Table 4-2 shows some different expressions related to predictive and adaptive approaches that are available in the literature and used in practice.

Table 4-2 Terms in Use Referring to the Predictive and Adaptive Approaches

Approach

Alternative Terms

Predictive

Waterfall, linear, structured, plan based, stable, traditional

Adaptive

Agile, iterative, incremental, spiral, extreme, evolutionary

Choosing the Predictive Approach

A predictive development approach can be considered when the project and product requirements can be defined, collected, and analyzed at the start of the project. This approach is widely referred to as a “waterfall” or “traditional” approach to project management. With the predictive development approach, you design and implement a project in a life cycle sequenced in distinct phases, from the initial conceptual and feasibility phase to the deployment of the final product or service. The predictive approach is more structured, predictable, and stable than the adaptive approach. Next, we review additional aspects of the predictive approach, as you will be tested extensively on this topic on the CAPM® exam.

The PMBOK® Guide – Seventh Edition, Section 2.3.3 indicates that the predictive approach is best used in the following situations:

Choosing the Adaptive Approach

An adaptive development approach is practical when requirements are subject to a high level of uncertainty and volatility and are likely to change throughout the project. In such an environment, you can proceed with an adaptive life cycle for project implementation. This life cycle is designed around iterations that repeat project phases. The project can move to the next phase only after customer or product stakeholder feedback is available. It suggests that a particular stage of development has reached a point at which it is appropriate to move on. Different expressions related to the adaptive approach can be found in the literature, but the most common terms are iterative, incremental, and agile.

The PMBOK® Guide – Seventh Edition, Section 2.3.3 indicates that the adaptive approach is best used in the following situations:

Choosing a Hybrid Approach

A hybrid development approach is a combination of adaptive and predictive approaches. This means that some elements from a predictive approach are used along with some elements from an adaptive approach. The project professionals must determine which elements are best for a particular aspect of a project and how to blend the different elements into an overall plan of action.

The PMBOK® Guide – Seventh Edition, Section 2.3.3 indicates that the hybrid approach is best used in the following situations:

NOTE

The Agile Practice Guide (see Appendix X3) introduces an Agile Suitability Filter tool to help project professionals evaluate criteria, facilitate discussions, and make an informed selection of recommended development approaches. Please review the various attributes of this useful tool.

Life Cycles in Practice

Summarizing the relevant definitions so far:

The project management development approach and delivery cadence can impact the phases of a project life cycle. If a project team adopts a predictive life cycle, then the project life cycle will likely be a traditional waterfall-like linear sequence of phases. However, if the team selects an adaptive development approach, the project life cycle will be made up of cyclical loops. These loops gradually produce the needed project outcomes as the deliverables of each loop are subjected to stakeholder feedback.

To aid in learning these often subtle differences, it is appropriate to take a look at some sample life cycles in practice from industry applications.

Industry Application: Predictive Life Cycle

Predictive life cycles are associated with clear phases; the project is constrained to develop requirements early and to stay with the original requirements and design plans that were created at the start of the project. The PMBOK® Guide – Sixth Edition, now part of the PMIstandards+™ online guide, states the following in Appendix X-3:

Each sector has its own typical version of a predictive project life cycle. Because both the terminology and importance of deliverables are different across domains, each sector has naturally evolved its own detailed approach.

Predictive Life Cycle Example 1

For this example, we consider the construction industry. This example leverages a predictive life cycle, as shown in Figure 4-9.

Figure 4-9 Construction Example Using a Predictive Life Cycle

The key phases in a construction life cycle could be:

Predictive Life Cycle Example 2

Software development is increasingly associated with an adaptive approach because software is more often delivered through modules of code that accomplish a specific task. However, not all software can or should be delivered this way. Historically, many well-known systems development life cycles have used a sequential, phased approach to deliver software. Therefore, it is very important to show how a software project might use the predictive life cycle.

Representative key phases in a software development life cycle (also known as a systems development life cycle, or SDLC), as illustrated in Figure 4-10, are:

Figure 4-10 Software/Systems Development Life Cycle Example Using a Predictive Life Cycle

The process shown in Figure 4-10 is characterized as a predictive life cycle because the completed steps are generally not revisited again. For example, when the requirements are firmed up, they are not changed during the detailed design, coding, and testing steps. If the software development life cycle shown in Figure 4-10 is to succeed using this predictive life cycle approach, the business/system analysts must have fully complete requirements. Likewise, the coding team must have the final software architecture and detailed design documentation before software construction begins. A wide array of specialized staff is involved in this predictive life cycle.

The sequential nature of the SDLC approach does not preclude some level of iteration. If the requirements change in a minor way based on customer feedback or testing failure, the project team can certainly revisit these minor changes through revised design, coding, and testing. The idea is to discover these issues as early as possible because the cost of changing a system can increase as more of it is developed through the project’s life cycle.

However, if significant changes tend to be required frequently, or even if new requirements are injected into the project at later stages, this can have a significant impact on the prior design or coding stages, making it necessary to revisit these stages; in such situations, the predictive software development life cycle is not appropriate. Because modern software development projects tend to accommodate changes that have greater impact regularly, software development project teams are likely to consider an adaptive life cycle today for many such projects.

Industry Application: Adaptive Life Cycle

Adaptive life cycles are associated with the iteration and gradual delivery of working components over several iterations. As such, a project is less constrained to develop requirements early and, therefore, allows modifications as the deliverables are finally reviewed; this often makes the end product very different from what might have been articulated at the start of the project. The PMBOK® Guide – Sixth Edition, now part of the PMIstandards+™ online guide, states the following in Appendix X-3:

According to the PMBOK® Guide – Seventh Edition, adaptive life cycles have some distinct characteristics:

Adaptive Life Cycle Example: Adaptive Software Development

Figure 4-11 illustrates a software life cycle example as an adaptive life cycle. It includes some typical elements of an iterative adaptive software development life cycle. When the business analysis step is complete and requirements are captured (generally in writing), a prototype is implemented to demonstrate to the end user the product’s overall features. This prototype is not necessarily fully functional but is developed to give the stakeholders a concept of how the requirements can be implemented. You can see that a fully functional pilot is being demonstrated to the stakeholders at the end of the coding step. In each step, the goal is to gather insights and rework the outcomes of the previous step in the life cycle.

Figure 4-11 Iterative Adaptive Software Development Life Cycle

This life cycle derives benefits from stakeholder feedback and team insights. Critical risks are mitigated in this approach. The requirements might not have been clear in the beginning, but a prototype can clarify the requirements. Where complexity is high, you can see that a fully functional pilot can likely ensure that the deployment will be successful. A vital characteristic of the adaptive life cycle is cadence—how often a prototype, pilot, or deliverable is ready for review. In adaptive software development, the project is understood to involve a frequent cadence of incorporating stakeholder feedback early. Therefore, Figure 4-11 shows that the final deliverable appears in successively refined stages at the prototype, pilot, testing, and deployment stages.

Industry Application: Hybrid Life Cycle

As mentioned earlier in this chapter, in a hybrid development approach, some elements of a predictive approach are used along with some elements of an adaptive approach. Consider the following characteristics of a hybrid life cycle:

It is helpful at this point to look at an industry example of the implementation of a hybrid life cycle.

Hybrid Life Cycle Example: Small Restaurant Business

Sam and Mary Oduwa are talented chefs. Recent changes in the restaurant business environment and their professional careers prompted them to consider starting a restaurant. Working with their daughter, Myra, who is adept in technical matters, they focused on a two-step process: First, they want to create a virtual restaurant to understand their customers better and refine their menu. Second, they want to move to a physical restaurant near their hometown.

Due to the relatively stable technology and flexible options for food delivery, Sam and Mary believe they can get going quickly. Their supportive local bank successfully approved their business proposal for funding to start their virtual restaurant business, and they obtained the needed permits from their local government office.

Sam and Mary visualized three stages through which their business could progress and created a timeline consisting of a one-month period for each stage (see Figure 4-12).

Figure 4-12 A Hybrid Project to Open a Small Restaurant

In an adaptive life cycle, these short, repetitive timelines can be referred to as sprints. Each sprint typically lasts one to four weeks. Sam and Mary considered the following phases as incremental approaches toward their final restaurant opening:

  1. Cook at home.

  2. Rent a kitchen near their home.

  3. Open a restaurant in a single location.

Sam and Mary also recognized that, although they could be very flexible with the first two phases, the third phase would require a more detailed plan, and the physical restaurant would need to be fully functional upon opening. Therefore, although they could use an adaptive approach for the first two phases (involving concept, construct/deliver, and close steps for each phase), they would need to develop a sequential plan to successfully implement the final restaurant location. Food menus and customer reputation could be iteratively built through the adaptive phases so they would be ready to implement in phase 3. However, the physical location would require a step-by-step development approach to be ready to serve customers.

Knowing that the third phase would likely take longer than the previous two phases, and knowing that it would have very defined dependencies, Sam and Mary started the predictive plan for phase 3 in parallel with the first two adaptive phases. This allowed them to select the location, get permits, design the renovation, sign construction contracts, and procure the necessary equipment and furniture, all while perfecting their menus at home and serving their first customers using equipment in their rented kitchen. When all these preliminary steps were complete, they could quickly move into their new location and be ready for their restaurant’s grand opening.

This restaurant business development example demonstrates combined characteristics of adaptive and predictive approaches—a hybrid life cycle.

Considerations for Selecting a Development Approach

Several factors influence the selection of a development approach. The PMBOK® Guide – Seventh Edition, Section 2.3.4 outlines these factors, as shown in Figure 4-13. The criteria can be divided into three categories: product, service, or result; project; and organization. It is important to review the meanings of each of these components.

Figure 4-13 Considerations for Selecting a Development Approach

Product, Service, or Result

The factors influencing the product, service, or result consideration all have to do with the nature of a project’s outcome, whether it is a product, a service, or another type of result.

Degree of Innovation

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

Requirements Certainty

A predictive approach works well when the requirements are well known and easy to define. When requirements are uncertain, volatile, or complex and are expected to evolve throughout the project, a more adaptive approach is a better fit.

Scope Stability

If the scope of the deliverable is stable and not likely to change, a predictive approach is practical. If the scope is expected to undergo many changes, an approach that is closer to the spectrum’s adaptive side can be helpful.

Ease of Change

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

Delivery Options and Cadence

The nature of the deliverable, such as whether it can be delivered in components, influences the development approach. Products, services, or results that can be developed and delivered in pieces are aligned with incremental, iterative, or adaptive approaches.

Risk

You can reduce risk by building products modularly and adapting the design and development based on learning to take advantage of emerging opportunities or reduce the exposure to threats. Adaptive approaches frequently mitigate high-risk requirements by addressing their viability first.

Safety Requirements and Regulations

Products that have rigorous safety requirements often use a predictive approach because significant up-front planning is needed to ensure that all the safety requirements are identified, planned for, created, integrated, and tested. Likewise, environments that are subject to significant regulatory oversight may need a predictive approach due to the required process, documentation, and demonstration needs.

Project

The factors in the project consideration column all have to do with aspects of the project, such as how it is structured, constrained, and funded.

Stakeholders

Specific stakeholders, such as product owners, play a substantial role in establishing requirements from the customer’s perspective and prioritizing work. If such dedicated project team staff are available to support project work, adaptive methods are preferred.

Schedule Constraints

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

Funding Availability

Projects that work in an environment of funding uncertainty can benefit from an adaptive 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.

Organization

The factors in the organization consideration column all have to do with the organizational environment of the project, including the culture, structure, and complexity.

Organizational Structure

An organizational structure with many levels, a rigid reporting structure, and substantial bureaucracy is likely to use a predictive approach. In contrast, projects that use adaptive techniques are associated with a flat structure.

Culture

A predictive approach fits better in an organization with a culture of managing and directing. Here the work is planned out and progress is measured against baselines. Adaptive approaches fit better within an organization that emphasizes project team self-management.

Organizational Capability

If organizational policies embrace attitudes and beliefs that support an agile mindset, then adaptive methods are likely to succeed.

Project Team Size and Location

Adaptive approaches often work best with project teams of five to nine individuals. Adaptive approaches also favor project teams that are located in the same physical space.

Project Activity, Deliverables, and Milestones

Now that you have an understanding of project phases and life cycles, you are ready for a description of some common elements that are present in all types of approaches. In this final section, we introduce project activities, deliverables (including their measurement), and project milestones.

Project Activities

An activity—or task, story, work package, or use case—is a scheduled step in a project plan that has a distinct beginning and end. An activity usually involves several substeps; when those substeps are completed, the whole activity can be regarded as completed. Several related activities can be combined to form a summary activity.

Let’s work through an example of a party where food, games, and entertainment are being planned. We might list several activities, such as these:

Deliverables

Project deliverables are measurable outputs of activities. They can be tangible or intangible. You can imagine handing off (delivering) something to the project sponsor or stakeholders at the conclusion of an activity. For the party project example, the following sample list shows activities and the deliverable associated with each activity:

It is important to recognize that the overall project itself is associated with a deliverable. The overall product or service being delivered by the project as a whole can be regarded as an end deliverable.

Intermediary deliverables also are present, such as the design and delivery of various project components. The project management process results in specific process deliverables, such as documentation and managerial reports. Examples of intermediary deliverables include:

Measuring Deliverables

Every deliverable must be checked for compliance with the scope, schedule, and budget. The outcomes hinge on assessing or measuring the quality and acceptability of the deliverable. Therefore, when the deliverables are proposed, the project manager must consider how they are to be assessed and measured; this is a necessary step in defining a deliverable. Examples of measurable deliverables include miles of roadway completed, pages of document completed, and square meters of wall painted. Even deliverables such as software can be measurable if they are described correctly according to their functions (for example, “A new customer can register a new account successfully by using the customer account registration function”).

Let’s get into a bit more detail. When you propose a document as a deliverable, for example, someone knowledgeable about the deliverable should be able to provide an expected outline and maybe even an expected page count. Besides helping to better describe the deliverable, these measures are essential because they provide a foundation for cost and schedule estimation, especially if the organization has a good idea of how many units per hour, day, or week a typical employee can produce. If a road construction crew can pave 3 kilometers of roadway per day, and the total crew typically is paid a certain overall set of wages per day, then knowing the total length of roadway defined by the end deliverable will assist the project manager in estimating the time to completion and the total labor cost estimate for this deliverable.

When a deliverable is defined and then assigned to a given resource, these measures can communicate what level of effort is expected. At any given elapsed point in time, you can then reasonably measure the progress against expectations estimated for that elapsed time. If actual deliverables are only half of what was expected, for example, then you immediately know that you have a problem and should investigate how to get the progress back on track.

Milestones

A milestone is a significant point or event in the project. The term originated from the ancient Roman Empire. The Romans were famous for building roadways across thousands of miles, and many of them remain visible today. Figure 4-14 shows an example of a Roman milestone—a marker made of stone that was placed along a roadway and engraved with the distance from the milestone to specific destinations in the Roman Empire. These milestones enabled the Roman army generals to calculate how long it would take to move troops from one area of the empire to another. Merchants and travelers also used these milestones to determine where they were on a given roadway that could be correlated to a map. In other words, the milestones were markers providing specific geolocation information that could be used to predict the time and cost in getting from one place to another. Highway construction engineers use similar markers on our roads today, although they are no longer made of stone; they are usually small signposts set at regular intervals along a highway, each with a code that corresponds to the distance from the start of the highway.

Figure 4-14 A Milestone from the Ancient Roman Empire

Just as milestones informed the ancient Romans—and still inform today’s land travelers—milestones are used in project management to allow a project manager to track progress along the timeline of a project. Milestones can be used to designate the completion of certain segments or deliverables for a project. Complex projects may have many milestones in the timeline, and they are helpful in determining how much work has been completed and how much remains to be done.

Like the markers of stone in ancient Rome, a project milestone is an event that marks either the beginning or the end of activities. A milestone has no duration or resources assigned; it is simply a marker for reference. Project software tools can typically show views of milestone completion, comparisons of estimates with actual progress, and so on.

At the point of project planning and estimating, each milestone should have a target date associated with it that shows the expected point at which all the activities before that milestone will be completed. During project planning, the date associated with the milestone is the planned milestone completion date; after successful execution, it becomes the actual milestone completion date.

For example, completing the definition of project scope is typically a major milestone for projects. Completing project planning is another major milestone; it marks the completion of the project management plan deliverable and the customer’s acceptance of the plan. This type of milestone might be called Project Planning Complete and is first given a planned date of completion and then given the actual date when the customer accepts the plan.

In this final section, we have introduced the idea of using project activities as a way to define the steps needed for project completion; project deliverables (including their measurement) as the means through which we can determine that a project has met its expectations of scope; and project milestones, which provide markers along the project timeline that can be used to measure estimated and actual progress. These concepts are universal with regard to project approach: They are integral in helping a project manager ensure successful project completion, no matter which development approach is chosen.

Summary

This chapter addresses the basics of project life cycles and project phases. It compares project life cycles with product life cycles, showing common concepts as well as differences in the management of each type of life cycle. It also explores the foundational concepts of predictive, adaptive, and hybrid approaches and illustrates sample industry life cycles. Finally, this chapter addresses the nature of project activities, deliverables, and milestones, all of which can be found in any type of project life cycle approach. This chapter is intended to give you foundational information that will be helpful as you explore more detailed considerations of these approaches in future chapters.

Exam Preparation Tasks

As mentioned in the section “How This Book Is Organized” in Chapter 1, you have a couple choices for exam preparation: the exercises here; Chapter 12, “Tailoring and Final Preparation”; and the exam simulation questions in the Pearson Test Prep Software Online.

Review All Key Topics

Review the most important topics in this chapter, noted with the Key Topics icon in the outer margin of the page. Table 4-3 lists these key topics and the page number on which each is found.

Table 4-3 Key Topics for Chapter 4

Key Topic Element

Description

Page Number

Figure 4-1

A Typical Project Life Cycle

98

Paragraph

Stage gates

99

Paragraph

Life cycle phases vs. Process Groups

101

Figure 4-6

Product Management Life Cycle

103

Figure 4-7

Development Approach and Life Cycle Performance Domain

104

Paragraph

The hybrid development approach

104

List

Choosing the predictive approach

105

List

Choosing the adaptive approach

106

List

Choosing the hybrid approach

106

Figure 4-13

Considerations for Selecting a Development Approach

113

Paragraph

Project activities

115

Paragraph

Deliverables

115

Paragraph

Measuring deliverables

116

Paragraphs

Milestones

118

Define Key Terms

Define the following key terms from this chapter and check your answers in the glossary:

project phase

project life cycle

progressive elaboration

stage gate

product

deliverable

development approach

predictive development approach

adaptive development approach

hybrid development approach

iterative

incremental

milestone

Suggested Reading and Resources

© 2024 Pearson Education, Pearson IT Certification. All rights reserved.

800 East 96th Street, Indianapolis, Indiana 46240

sale-70-410-exam    | Exam-200-125-pdf    | we-sale-70-410-exam    | hot-sale-70-410-exam    | Latest-exam-700-603-Dumps    | Dumps-98-363-exams-date    | Certs-200-125-date    | Dumps-300-075-exams-date    | hot-sale-book-C8010-726-book    | Hot-Sale-200-310-Exam    | Exam-Description-200-310-dumps?    | hot-sale-book-200-125-book    | Latest-Updated-300-209-Exam    | Dumps-210-260-exams-date    | Download-200-125-Exam-PDF    | Exam-Description-300-101-dumps    | Certs-300-101-date    | Hot-Sale-300-075-Exam    | Latest-exam-200-125-Dumps    | Exam-Description-200-125-dumps    | Latest-Updated-300-075-Exam    | hot-sale-book-210-260-book    | Dumps-200-901-exams-date    | Certs-200-901-date    | Latest-exam-1Z0-062-Dumps    | Hot-Sale-1Z0-062-Exam    | Certs-CSSLP-date    | 100%-Pass-70-383-Exams    | Latest-JN0-360-real-exam-questions    | 100%-Pass-4A0-100-Real-Exam-Questions    | Dumps-300-135-exams-date    | Passed-200-105-Tech-Exams    | Latest-Updated-200-310-Exam    | Download-300-070-Exam-PDF    | Hot-Sale-JN0-360-Exam    | 100%-Pass-JN0-360-Exams    | 100%-Pass-JN0-360-Real-Exam-Questions    | Dumps-JN0-360-exams-date    | Exam-Description-1Z0-876-dumps    | Latest-exam-1Z0-876-Dumps    | Dumps-HPE0-Y53-exams-date    | 2017-Latest-HPE0-Y53-Exam    | 100%-Pass-HPE0-Y53-Real-Exam-Questions    | Pass-4A0-100-Exam    | Latest-4A0-100-Questions    | Dumps-98-365-exams-date    | 2017-Latest-98-365-Exam    | 100%-Pass-VCS-254-Exams    | 2017-Latest-VCS-273-Exam    | Dumps-200-355-exams-date    | 2017-Latest-300-320-Exam    | Pass-300-101-Exam    | 100%-Pass-300-115-Exams    |
http://www.portvapes.co.uk/    | http://www.portvapes.co.uk/    |