Development approaches, life cycles and tailoring

Every project must decide how it will produce its deliverables: plan everything up front and build to the plan, discover and deliver in short cycles, or combine the two. That decision, the development approach, shapes the life cycle, the cadence of delivery, the roles on the team and the documents produced. Because about 60 % of 2026 PMP exam items reflect adaptive or hybrid approaches, and the rest predictive, you must be comfortable with all three and able to recognize which suits a situation. This lesson defines the approaches and life cycles, explains the factors that drive the choice, and introduces tailoring, the deliberate adaptation of approach, processes and artifacts to fit the project.

Development approaches

A development approach is the method used to create and evolve the product, service or result during the project. PMI describes a spectrum rather than separate boxes.

Iterative and incremental are different ideas that are often combined. Iterative is about refining: getting something better through repetition and feedback. Incremental is about adding: delivering more capability over time. Agile approaches use both: each iteration produces a working increment that is then refined in later iterations.

Life cycles and phases

A project life cycle is the series of phases a project passes through from start to completion. A phase is a collection of logically related activities that ends with one or more deliverables. Predictive life cycles often use phases such as feasibility, design, build, test, deploy and close, each ending with a phase gate, a review where governance decides whether to continue, change direction or stop. Adaptive life cycles repeat short cycles, often called iterations or sprints, typically one to four weeks long, each producing a potentially usable increment. Flow-based approaches such as Kanban have no fixed iterations; work items move through the system continuously, limited by work-in-progress limits.

The product life cycle is broader than the project life cycle. A product may be conceived, developed, launched, grown, matured and retired over many years, and several projects may occur along the way: the original development, later enhancements and eventually decommissioning. Keeping the product life cycle in mind helps a project manager plan for operations, support and eventual disposal, which connects to the sustainability principle.

Cadence

Delivery cadence describes the timing and frequency of deliveries. A predictive project may have a single delivery at the end. Multiple deliveries occur when parts of the scope are delivered at different times, as with phased go-lives. Periodic deliveries follow a fixed schedule, such as monthly releases. Continuous delivery releases increments as soon as they are ready, which in software can mean many times a day. Cadence should match how quickly stakeholders can absorb change and how valuable early delivery is.

Choosing an approach

There is no universally best approach. The choice depends on characteristics of the product, the project and the organization. PMI identifies factors such as these.

• Product, service or result: degree of innovation, requirements certainty, scope stability, ease of change, delivery options, risk and safety requirements, and regulation.
• Project: stakeholder availability and needs, schedule constraints, funding availability and structure.
• Organization: structure, culture, capability, team size and location, and experience with the approach.

PMI's Agile Practice Guide, developed with the Agile Alliance, offers a similar suitability filter that rates culture, team and project attributes. Whatever tool is used, the scoring is a conversation starter. The exam expects you to recognize signals: high uncertainty and the ability to deliver in pieces point toward adaptive; fixed regulatory specifications and costly change point toward predictive; a mix points toward hybrid.

Hybrid in practice

Hybrid approaches are common and are prominent on the exam. They take several forms: running some deliverables predictively and others adaptively; using an adaptive approach inside a predictive governance framework of phase gates and funding approvals; starting with an adaptive discovery phase and then building predictively once requirements are clear; or the reverse, using predictive planning for a fixed platform and adaptive cycles for features. The key is that the combination is chosen deliberately to fit the work, not drifted into because nobody decided.

Tailoring

Tailoring is the deliberate adaptation of the approach, governance and processes to make them more suitable for the given environment and the work at hand. The PMBOK Guide says plainly that projects should not apply every process, artifact or practice; they should select and adapt what adds value. Over-processing wastes effort and frustrates teams; under-processing exposes the project to avoidable risk. In the 8th edition, tailoring guidance appears within each performance domain.

Tailoring typically follows four steps. First, select the initial development approach. Second, tailor for the organization: organizational policies, PMO standards and governance may require certain processes or documents. Third, tailor for the project: consider size, complexity, criticality, team and stakeholders. Fourth, implement ongoing improvement: review in retrospectives or lessons-learned sessions and adjust as the project proceeds.

In the Canadian federal context, the Project Complexity and Risk Assessment result helps determine how much oversight and documentation a project needs, which is a form of organizational tailoring. Departments also tailor gating to their own project management frameworks.

Approaches beyond software

Adaptive approaches began in software but now appear in many fields. Marketing teams run campaigns in short cycles, testing messages and adjusting based on results. Construction teams use pull planning and short-interval scheduling from lean construction, where the people doing the work plan the next few weeks together. Product hardware teams build rapid prototypes and test them with users before committing to tooling. Policy teams pilot a new service in one region before national rollout. In each case the principle is the same: when uncertainty is high, learn through short cycles of delivery and feedback rather than betting everything on an up-front plan.

Conversely, predictive approaches remain essential where change is expensive or dangerous. You cannot iterate on the foundation of a high-rise once concrete has cured, and you cannot release an untested change to a nuclear safety system. Even agile organizations use predictive planning for long-lead procurement, regulatory submissions and infrastructure. The skill the exam tests is matching the approach to the work, not loyalty to a method.

Life cycle examples

Note that a flow-based approach suits work that arrives continuously rather than as a defined project scope. Many teams use Kanban boards with explicit work-in-progress limits so that they finish work before starting more, which shortens the time each item takes from request to delivery.

Whatever the approach, write down the reasons for the choice in the project management plan or equivalent. If the context changes, for example requirements stabilize or a regulator imposes new documentation rules, the team can revisit the decision knowingly rather than drifting into a different way of working. Changing approach mid-project is legitimate when it is deliberate and agreed with governance.

A useful exam heuristic: when a scenario describes an organization new to agile, the best answer usually involves coaching, a pilot team or a hybrid step rather than an overnight switch. Lasting changes in approach need training, leadership support and time for teams to learn new habits.