DEVELOPMENT APPROACH

AND LIFE CYCLE

PERFORMANCE DOMAIN
This performance domain entails establishing the development approach, delivery
cadence, and project life cycle needed to optimize project outcomes.
DEVELOPMENT, CADENCE, AND LIFE CYCLE
RELATIONSHIP

The type of stuff we're delivering in a project dictates how we can build it. The kind
of deliverables we have and how we choose to develop them really set the pace
and number of our project deliveries. This combination of what we’re delivering
and how often we plan to deliver it shapes the whole project life cycle and its
different phases.

DELIVERY CADENCE
Delivery cadence is all about how often and when we deliver project outcomes.
Here's how it works:
● Single Delivery: For some projects, everything is delivered at the end. For
instance, if I'm working on reengineering a process, there might not be anything
to show until we nearly finish and roll out the new process.
● Multiple Deliveries: Other projects need us to deliver parts at different times.
Say I’m working on developing a new drug; I might have to handle deliveries like
preclinical submissions, results from different trial phases, registration, and
finally, the launch. These deliveries usually happen one after the other. However,
some projects, like updating building security, involve multiple components like
new barriers, badges, and keypads that can be delivered in any order but must
all be completed before we wrap up the project.
● Periodic Deliveries: This is similar to multiple deliveries, but it's all on a set
schedule. For example, if I'm developing a new software application, we might
have internal deliveries every two weeks, with public releases scheduled
periodically.
Development Approaches
The way I create and improve the
product, service, or result during the
project life cycle is defined by the
development approach I choose.
Different industries might call these
approaches different names, but
three common types are predictive,
hybrid, and adaptive. Think of these
approaches as a spectrum, with
predictive on one end and adaptive
on the other.
Predictive Approach: I use a predictive approach when everything about the
project and product requirements is clear from the start. You might also hear this
called a waterfall approach. It’s great when there’s a lot of riding on the project
and a lot of risks, needing frequent reviews, tight change control, and replanning
between phases. I can define everything like scope, schedule, costs, resources,
and risks early on, and they don’t change much. This approach lets me reduce
uncertainty early and do a lot of upfront planning. Sometimes, I might start with a
proof-of-concept to explore options, but mostly, the project follows a set plan,
often using templates from similar past projects.
Hybrid Approach: A hybrid approach mixes elements from both predictive and
adaptive methods. It's handy when the project requirements are a bit unclear or
risky. This approach works well when the deliverables can be broken down into
modules, or different teams can handle parts of the project. It's more flexible than
purely predictive but not as free-form as purely adaptive methods. Hybrid often
involves iterative or incremental development to help clarify requirements and
explore options. It builds the deliverable across several iterations, with each
adding more functionality within a fixed time frame, known as a timebox.
Adaptive Approach: I go for adaptive approaches when the project requirements
are really uncertain or likely to change. I start with a clear vision and initial
requirements but be ready to refine, detail, change, or replace them based on user
feedback, environmental changes, or surprises along the way. Adaptive methods
use iterative and incremental approaches too, but the iterations are usually shorter,
and the product evolves continuously based on stakeholder feedback.

While agility is more about the mindset than just a method, agile approaches are a
type of adaptive method. In agile, iterations might last 1 to 2 weeks with a showcase
of what’s been achieved at the end. My team and I stay deeply involved in planning
each iteration. We decide what we can accomplish based on a prioritized list,
estimate the effort needed, and work together throughout the iteration to get it done.
CONSIDERATIONS FOR SELECTING A DEVELOPMENT
APPROACH
When I'm choosing a development approach, there are a bunch of factors that
come into play. These can be about the product, service, or result we're delivering;
specifics of the project itself; and even the organization's characteristics. Let's
break these down:

Product, Service, or Result

Lots of variables tie into what we're trying to create or deliver that affect which
development approach I might use:
● Degree of Innovation: If we’ve done something similar before and know
exactly what we need, a predictive approach works well because we can plan
everything upfront. But if we’re doing something totally new or don’t have
much experience with it, an adaptive approach is better because it allows for
flexibility.
● Requirements Certainty: If I know exactly what’s required, a predictive
approach is straightforward. But if things are uncertain or expected to
change, I lean towards an adaptive approach.
● Scope Stability: A stable scope means predictive works fine. But if I expect a
lot of changes, I need something more adaptive.
● Ease of Change: If changes are tough to handle once we start, predictive is
the way to go. If it’s easy to adapt as we go, then an adaptive approach can
work well.
● Delivery Options: Depending on whether the deliverable can be broken down
into parts, I might go for iterative, incremental, or adaptive methods. Even
within a largely predictive project, some parts might be tackled in increments.
● Risk: High-risk projects need careful thought before deciding on the approach.
Some need lots of upfront planning to mitigate risks, while others might
benefit from a more modular, adaptable process.
● Safety Requirements: If there are strict safety requirements, I often use a
predictive approach to ensure everything is planned and tested thoroughly.
● Regulations: If there’s heavy regulation, a predictive approach usually makes
more sense because of all the documentation and checks required.

Project
Certain project details also guide my choice of development approach:

● Stakeholders: If the project benefits from constant stakeholder input,

adaptive methods are key.
● Schedule Constraints: If I need to get something out quickly, even if it’s not
the final product, an iterative or adaptive approach can be really useful.
● Funding Availability: If funding is uncertain, starting with a minimal viable
product using an adaptive or iterative approach can help. This way, I can test
the waters with less upfront investment and decide later whether to invest
more based on the market’s response.
Organization
The organization's own setup also influences my choice:

● Organizational Structure: A more hierarchical structure tends to favor predictive

approaches, while a flatter structure might lean towards adaptive methods with
self-organizing teams.
● Culture: A control-oriented culture fits better with predictive methods. A culture
that supports team autonomy suits adaptive approaches.
● Organizational Capability: Switching from predictive to adaptive methods isn't just
a declaration—it's a cultural shift that starts from the top.
● Project Team Size and Location: Smaller, co-located teams often handle adaptive
approaches like agile well. Larger or mostly virtual teams might need more
structured, predictive methods, although there are ways to scale adaptive methods
to fit larger, dispersed teams too.
LIFE CYCLE AND PHASE DEFINITIONS
The types and number of phases in my project life cycle really depend on a
few key things, like how often we plan to deliver something (delivery cadence)
and how we choose to develop it. Let me walk you through some typical
phases you might see in a project life cycle:
● Feasibility: I check if the business case makes sense and whether we
have the capability to deliver what we intend to.
● Design: I plan and analyze what needs to be done, leading to the design of
the project deliverable.
● Build: The actual construction of the deliverable happens here, along with
integrated quality assurance to make sure everything's on track.
● Test: I do a final quality check and inspect the deliverables before they go
live or are accepted by the customer.
● Deploy: This is when the project deliverables are actually put to use. I also wrap
up any transitional activities needed for ongoing support, benefits realization,
and managing organizational change.
● Close: I close out the project, archive all the knowledge and artifacts we’ve
gathered, release team members, and wrap up any contracts.

Each of these phases usually ends with a phase gate review to make sure we've hit
the desired outcomes or exit criteria before moving to the next phase. These criteria
might be linked to deliverable acceptance, contractual obligations, specific
performance targets, or other clear measures.

In a predictive development approach, these phases happen one after another,

each focusing on a specific type of work (Figure 2-9). But sometimes, things like
scope changes or market shifts might cause us to repeat phases.
With an incremental development approach, the project goes through several
iterations of planning, designing, and building, adding more functionality with each
cycle (Figure 2-10).
In an adaptive development approach, like agile, at the end of each iteration or sprint,
I have a review where the customer checks out what we’ve done so far. Based on the
feedback from key stakeholders during this review, I update our project backlog to
prioritize features and functions for the next sprint (Figure 2-11)
Some adaptive methodologies don't really use a phased life cycle; instead, they
focus on optimizing the flow of work based on resources, materials, and other
factors. The goal here is to minimize waste and make our processes as efficient as
possible, using scheduling principles from systems like Kanban, which are part of
lean and just-in-time scheduling approaches.

ALIGNING OF DELIVERY CADENCE, DEVELOPMENT

APPROACH, AND LIFE CYCLE
In Section 2.3.3, I talked about some examples from a community center project to
show how delivery cadence, development approach, and life cycle work together. In
this case, the project includes four main elements: the building, the community
action patrol (CAP) training, senior services, and the website. The details about how
often we deliver and how we develop these are outlined in Table 2-4.
Based on this setup, here's how I might plan the life cycle of this project:

● Start Up: This phase kicks off once the business case is approved and the project
charter is signed off. Here, I develop a high-level roadmap, set up initial funding,
define team and resource needs, create a milestone schedule, and plan our
procurement strategy. All these need to be wrapped up before we move on from
the start-up phase, and we check everything at an origination phase gate review.
● Plan: Next, I take the high-level plans for the building and break them down into
detailed plans. I finish up the detailed design document for the CAP training, complete
an analysis and a gap analysis for the senior services, and draw up the initial
wireframe for the website. We need to finish all these tasks before we can close out
the planning phase, and we’ll have another review at a planning phase gate review.
● Development: This phase overlaps with testing and deployment because each
element has its own timeline and approach. For example, I'll start rolling out the
website early to keep the public updated about the community center's progress.
Some senior services and CAP training might even start before the community center
officially opens. Each part will have its own review before moving on to testing.
● Test: Testing also overlaps with development and deployment. The type of testing
depends on the deliverable—building inspections, beta versions of the CAP courses,
trial runs for the senior services, and live environment tests for each website release.
Each part must pass its tests before heading to deployment.
 ● Deploy: Deployment overlaps with development and testing. I might launch the
website relatively early in the project timeline. This phase iterates as more
deliverables become ready. The big finale will be the opening of the community center,
but I'll continue updating the website and senior services even after the center is
open.
● Close: This phase happens periodically as we complete different parts. For instance,
once the initial version of the website is up and running, I’ll start winding down the
project personnel involved and run retrospectives or lessons learned sessions for
each part. At the very end of the project, I’ll review all phase gate feedback and do a
final evaluation of how well we met our original plans and goals. Before the final
closeout, I’ll double-check the project charter and business case to make sure we
achieved the intended benefits and value.

Figure 2-12 in the document illustrates this life cycle. It shows how the start-up and
planning phases are back-to-back, while the development, test, and deployment phases
overlap due to the different timings and needs of the deliverables.
INTERACTIONS WITH OTHER PERFORMANCE
DOMAINS
The Development Approach and Life Cycle Performance Domain interacts with
several other domains, including Stakeholder, Planning, Uncertainty, Delivery, Project
Work, and Team Performance. The life cycle selected influences how planning is
done. In predictive life cycles, most of the planning is done upfront, and then they
continue to update plans with rolling wave planning and progressive elaboration. They
also update plans as they identify new threats and opportunities.
Choosing the development approach and delivery cadence is one way the team
reduces uncertainty in projects. For a deliverable with significant risks related to
regulatory requirements, they might choose a predictive approach to include extra
testing, thorough documentation, and robust processes. If there's a high risk
associated with stakeholder acceptance, they might opt for an iterative approach and
release a minimum viable product to gather feedback before adding more features.
The Development Approach and Life Cycle Performance Domain significantly
overlaps with the Delivery Performance Domain, particularly around delivery cadence
and development approach. The delivery cadence drives how they deliver value in
line with the business case and benefits realization plans. How they elicit product
requirements and meet quality standards, as outlined in the Delivery Performance
Domain, heavily influences their development approach.

When it comes to project team capabilities and leadership skills, the Team
Performance Domain and the Development Approach and Life Cycle Performance
Domain also interact. The team's way of working and my leadership style vary greatly
based on the development approach we choose. A predictive approach typically
means I put a lot of emphasis on upfront planning, measurement, and control. On the
other end, an adaptive approach, especially when implementing agile methods,
requires me to adopt more of a servant leadership style and often involves working
with self-managing teams.
MEASURING OUTCOMES