Standard §4 · PRINTED PP. 57–76
Project Life Cycles
Chapter 4 separates several ideas that are often conflated: the project life cycle describes the path from start to closure; phases organize related activities around deliverables or outcomes; a development approach describes how a product, service, or result is created and evolved; delivery cadence describes when usable value is released; and five Project Management Focus Areas describe recurring management actions. Predictive, adaptive, and hybrid approaches form a spectrum rather than opposing ideologies. The correct choice depends on deliverable characteristics, project conditions, organizational capability, feedback needs, risk, safety, regulation, and the economics of change. Initiating, Planning, Executing, Monitoring and Controlling, and Closing occur in every approach, often overlapping and repeating within phases or iterations.
Understand the chapter
Chapter 4 separates several ideas that are often conflated: the project life cycle describes the path from start to closure; phases organize related activities around deliverables or outcomes; a development approach describes how a product, service, or result is created and evolved; delivery cadence describes when usable value is released; and five Project Management Focus Areas describe recurring management actions. Predictive, adaptive, and hybrid approaches form a spectrum rather than opposing ideologies. The correct choice depends on deliverable characteristics, project conditions, organizational capability, feedback needs, risk, safety, regulation, and the economics of change. Initiating, Planning, Executing, Monitoring and Controlling, and Closing occur in every approach, often overlapping and repeating within phases or iterations.
Learning objectives
- Distinguish project life cycle, product life cycle, phase, phase gate, development approach, delivery cadence, and Project Management Focus Area.
- Use entrance criteria, exit criteria, business evidence, and value alignment to support phase-gate decisions.
- Compare predictive, adaptive, and hybrid approaches without equating predictive with single delivery or adaptive with no planning.
- Explain iterative refinement, incremental delivery, timeboxing, flow-based work, work-in-process limits, and progressive elaboration.
- Select or combine development approaches using deliverable, project, and organizational factors.
- Choose among single, multiple, periodic, and continuous delivery cadences based on value and risk.
- Describe the purpose and interaction of the five Focus Areas in predictive, adaptive, and hybrid environments.
- Explain why Monitoring and Controlling runs in parallel with other work and why Closing may include early termination.
- Tailor phases, processes, activities, cadence, and governance while protecting the project's value proposition.
Key concepts
Life cycle, product life cycle, and development approach are different
The project life cycle spans the temporary initiative from start to closure. A product life cycle may continue through introduction, growth, maturity, and retirement and can contain many projects. A development approach is the way a project creates and evolves its deliverable. Keeping these concepts separate prevents teams from mistaking a product stage or software method for the entire project-management framework. Application: For a new device, map the temporary approval-and-launch project separately from the product's years of support and retirement, then choose different development approaches for hardware, software, and regulatory evidence if appropriate.
Phases and gates organize learning and commitment
A phase groups logically related activities that culminate in deliverables or outcomes. Phases may be sequential, overlapping, or transitional. Gates compare evidence with entrance or exit criteria and can authorize continuation, modification, repetition, temporary parking, or termination. Gates can occur before as well as after a phase and should test viability, resources, risk, acceptance, and strategic alignment—not merely document completion. Application: At a feasibility gate, require evidence about technical viability, regulatory path, funding, strategic fit, benefit assumptions, major risks, and readiness for the next commitment.
Uncertainty falls while the cost of change usually rises
Early in a project, risk and uncertainty are usually high, while choices and stakeholder influence may be relatively broad. As decisions are made and deliverables are accepted, uncertainty tends to fall; reversing accumulated work often becomes more expensive. Frequent feedback can detect problems earlier and reduce the cost of learning. Application: Prototype uncertain or high-impact assumptions before irreversible procurement, construction, migration, or regulatory commitments.
Predictive approaches optimize stable work
Predictive approaches suit conditions where scope and requirements can be stabilized early, significant up-front planning is useful, change is expensive, or regulation and investment require strong controls and gates. Scope, schedule, cost, resources, quality, and risk can be defined with relative confidence. Predictive work may still deliver incrementally when the total scope is known but partial delivery creates earlier value. Application: Use predictive planning for a regulated facility build with fixed safety requirements, but consider phased handovers if independently usable areas can produce value before total completion.
Adaptive approaches optimize learning under change
Adaptive approaches suit volatile requirements, uncertain solutions, complex work, and contexts where frequent stakeholder feedback is valuable. A stable vision can coexist with evolving details. Iterations refine the solution through repeated cycles; increments deliver usable portions that accumulate into the full product. Timeboxed or flow-based work controls exposure and supports learning, while backlogs, work-in-process limits, and recurring review keep effort aligned with capacity and value. Application: For a new digital service, fix the short iteration duration and team budget, then vary detailed scope by prioritizing the highest-value validated needs each cycle.
Hybrid approaches match methods to uncertainty
Hybrid is a deliberate combination of predictive and adaptive elements. The approaches may occur sequentially, concurrently, as a small adaptive component in a predictive project, or as a predictive component in an adaptive project. Hybrid is useful when deliverables are modular, workstreams face different uncertainties, or governance constraints apply unevenly. It should be designed around interfaces and risk rather than adopted as an undefined compromise. Application: Build a data center with predictive engineering and approvals while developing its management software adaptively; define integration milestones, shared configuration controls, and cross-stream acceptance criteria.
Approach selection is contextual
Deliverable factors include innovation, requirement certainty, scope stability, ease and cost of change, divisibility, safety, risk, regulation, and feedback value. Project factors include stakeholder availability, schedule and financing constraints, size, complexity, skills, and interdependencies. Organizational factors include structure, culture, capability, policy, team size, and location. Because these factors vary by workstream, one project may appropriately use several approaches. Application: Score major deliverables independently against uncertainty, change cost, compliance, feedback, modularity, and capability; then select and integrate approaches rather than labeling the whole initiative by habit.
Cadence determines when value and feedback arrive
A project may make one final delivery, several deliveries, periodic releases on a fixed rhythm, or continuous production-ready delivery. Cadence is related to but not dictated by development approach. Earlier delivery can reduce risk and accelerate feedback, but each release should be usable, controlled, and connected to the target business objective. Application: Choose continuous delivery for low-risk software changes only when automated testing, deployment controls, observability, and rapid recovery can keep every increment production-ready.
Focus Areas are recurring management actions, not phases
Initiating aligns purpose, authority, stakeholders, initial scope, and resources. Planning defines and progressively refines the course of action. Executing performs and coordinates the agreed work. Monitoring and Controlling measures performance, analyzes variance and trends, and agrees corrective action. Closing completes or terminates the project, phase, or contract and transfers outcomes appropriately. These actions overlap, repeat, and operate in every development approach. Application: In an adaptive project, perform lightweight initiation once, then repeat planning, execution, monitoring, and review within iterations while maintaining project-level governance and an eventual formal close.
Planning is progressive, not disposable
Predictive approaches often front-load planning; adaptive approaches begin with a high-level roadmap and plan frequently. Both use progressive elaboration as evidence develops. Plans are authoritative current hypotheses about how to deliver value, not promises that must remain unchanged when evidence demonstrates a better route. Application: Define which parts of the plan are baselined, which are rolling-wave details, the cadence for replanning, and the governance needed to change investment, dates, scope, or quality.
Monitoring and Closing protect value
Monitoring and Controlling is concurrent with other Focus Areas, not a late audit. It turns performance data, variance, trends, alternatives, and exceptional events into negotiated corrective action. Closing verifies completion and supports transfer to operations, but it can also formalize cancellation when continuing would worsen the return on investment. Application: Set event-driven and periodic review thresholds; when evidence undermines viability, compare correction, pivot, pause, and termination rather than automatically rebaselining.
Deeper understanding
Why it matters
Life-cycle phases structure investment decisions; development approach governs how a result evolves; cadence governs when it reaches users.
Decision questions
- What should a phase gate decide beyond whether planned tasks were completed?
- Why can one project use different approaches for different deliverables?
- What condition makes predictive planning useful, and what could undermine it?
Teach it back
- Distinguish project life cycle, product life cycle, phase, phase gate, development approach, delivery cadence, and Project Management Focus Area.
- Use entrance criteria, exit criteria, business evidence, and value alignment to support phase-gate decisions.
- Compare predictive, adaptive, and hybrid approaches without equating predictive with single delivery or adaptive with no planning.
Signals to notice
- Life-cycle phases structure investment decisions; development approach governs how a result evolves; cadence governs when it reaches users.
- Approach choice is contextual and can differ by deliverable, but integration and acceptance still require shared controls.
- The five Focus Areas overlap and recur; a useful method addresses all of them without forcing five sequential stages.
Section-by-section reading
Use the printed page references to read each section in the official publication, then explain the idea in your own words.
4.1 Project Phases
A project life cycle runs from start to closure and can be divided into phases with distinctive objectives, resources, entry conditions, and exit conditions. A phase gate is a decision opportunity that may follow one phase before further investment, not merely a ceremonial report. Phases can overlap or be arranged differently according to the work. Distinguish this temporary project life cycle from the longer life of a product it creates. At a gate, assess the evidence, remaining value, risk, and readiness to proceed; completion of a checklist alone cannot justify continuation. Define who decides and what happens if the evidence calls for rework, pause, or termination.
Understand this item
Why it matters: Phases and gates limit exposure by requiring evidence before the organization commits further resources.
Decision to make: At each gate, assess remaining value, risk, readiness, and alternatives, and define authority for proceed, rework, pause, or stop decisions.
Do not confuse it with: A phase organizes related project work; a gate is a governance choice about whether and how investment continues.
Teach it back: Explain why completing every pilot task does not by itself justify a hospital-wide rollout.
Apply it: A hospital reviews safety evidence after a pilot before authorizing a full ward rollout.
Check yourself: What should a phase gate decide beyond whether planned tasks were completed?
4.2 Project Development Approaches
A development approach describes how the result is created and evolved within the life cycle. Predictive approaches plan substantial detail early, adaptive approaches learn through repeated work and feedback, and hybrid arrangements combine elements. These describe a spectrum, not badges of organizational maturity. Selection depends on requirements stability, uncertainty, stakeholder access, risk, technical context, and constraints. An approach can be chosen for different deliverables within one project rather than imposed uniformly. Distinguish it from delivery cadence, which concerns when results reach users, and from the project phases, which organize the overall effort. Tailor the way of working to the actual decision and learning needs.
Understand this item
Why it matters: Approach selection determines where to seek early certainty and where to learn through feedback.
Decision to make: Choose predictive, adaptive, or hybrid treatment per deliverable using uncertainty, change cost, risk, and stakeholder access.
Do not confuse it with: A development approach describes how results evolve; phases organize the project life cycle, and cadence describes when usable results are delivered.
Teach it back: Explain why a facility can use controlled building design and iterative software testing within one project.
Apply it: A facility uses controlled building design and iterative testing for its occupant-facing scheduling software.
Check yourself: Why can one project use different approaches for different deliverables?
4.2.1 Predictive Approaches
Predictive development is useful when scope can be stabilized early and advance coordination is valuable, especially with major investment or regulatory oversight. Planning can establish requirements, sequences, cost expectations, and formal review points before substantial execution. This does not mean a team must refuse new information; changes should be evaluated against the baseline and intended value through appropriate control. Predictive is also distinct from single delivery: planned work can produce increments. The approach becomes less efficient when unknown needs continually invalidate detailed upfront assumptions. Ask whether the effort can specify and verify its result reliably enough to make early planning an advantage rather than a source of costly rework.
Understand this item
Why it matters: Predictive planning is valuable when requirements can be stabilized and advance coordination reduces risk or rework.
Decision to make: Confirm that scope is sufficiently knowable and verifiable before investing heavily in detailed upfront plans.
Do not confuse it with: Predictive does not mean ignoring change or delivering only once; it means using an established baseline and controlled evaluation of new information.
Teach it back: Explain why a bridge foundation suits predictive planning and what kind of uncertainty could undermine that choice.
Apply it: A bridge foundation design is approved against engineering and permit requirements before construction.
Check yourself: What condition makes predictive planning useful, and what could undermine it?
4.2.2 Adaptive Approaches
Adaptive development is suited to uncertain or changing requirements and solutions. A clear goal can coexist with progressively refined details. Repeated cycles may improve a design iteratively, while incremental delivery supplies usable pieces; these ideas can work together but are not synonyms. Frequent feedback helps test assumptions and reorder work. Stakeholder availability, team capability, and the cost of safe experimentation matter: a short cycle without meaningful feedback is only a short schedule. Adaptive methods do not excuse missing safety, compliance, or governance controls. Set boundaries for decisions, make work visible, and verify each increment before treating it as valuable. The approach should support learning rather than constant uncontrolled change.
Understand this item
Why it matters: Adaptive development converts uncertainty into learning through short feedback cycles and usable increments.
Decision to make: Ensure stakeholders can provide timely evidence, set governance boundaries, and verify each increment before reprioritizing.
Do not confuse it with: Iteration refines a result through repeated work; incremental delivery adds usable portions of the result.
Teach it back: Use a booking app to explain how one increment can be delivered and then improved through later iterations.
Apply it: A community app releases a simple booking feature, observes use, then refines navigation.
Check yourself: How do iterative refinement and incremental delivery differ?
4.2.3 Hybrid Approaches
Hybrid development combines predictive and adaptive elements in a deliberate arrangement. A regulated physical component may require stable design and approvals while a user interface can be tested in short cycles. Integration is the hard part: the two streams must share interface definitions, decision points, acceptance conditions, and realistic dependencies. Hybrid is not an excuse to switch methods whenever a task becomes inconvenient. Specify which parts can change readily, which need formal review, and when they come together. A largely predictive project may contain a small adaptive component, or the reverse. The mix should reflect differing uncertainty and constraints, not a fashionable label attached to an unchanged plan.
Understand this item
Why it matters: Hybrid development fits different uncertainty and control needs, but only if the streams are deliberately integrated.
Decision to make: Define stable and flexible components, shared interfaces, dependencies, acceptance rules, and synchronized decision points.
Do not confuse it with: Hybrid is an engineered combination of approaches; ad hoc switching changes methods without managing integration consequences.
Teach it back: Explain how fixed building interfaces can constrain adaptive room-booking software.
Apply it: A smart building fixes structural design through formal approvals while refining its room-booking interface in pilots.
Check yourself: Which integration controls would prevent adaptive software from conflicting with fixed building interfaces?
4.3 Considerations for a Development Approach Selection
Choose a development approach by examining the deliverables, the project situation, and the organization. No single factor determines the answer: requirement stability, safety, feedback access, schedule urgency, funding uncertainty, culture, and governance interact. Different parts of one investment may warrant different arrangements. Compare candidate approaches against where learning is needed and where advance certainty or formal control is essential. Make assumptions visible, especially about stakeholder availability and the cost of changing a built result. A decision should be revisited if those assumptions fail. The objective is an effective way to create and verify value, not conformity to a named methodology.
Understand this item
Why it matters: A sound approach reflects interacting deliverable, project, and organizational conditions rather than allegiance to a method.
Decision to make: Compare candidate approaches against where learning is needed, where certainty is essential, and which assumptions may change.
Do not confuse it with: Method selection by label asks what the organization prefers; contextual selection asks what this work can execute and verify effectively.
Teach it back: Name the three categories used to choose an approach and one assumption that should trigger reconsideration.
Apply it: A transit agency scores hardware certification needs separately from uncertainty about rider-facing app features.
Check yourself: Which three categories should frame a development-approach decision?
4.3.1 Deliverables
Properties of the deliverable affect how it should be developed. A physical structure that is expensive to alter after construction invites different planning from a digital interface that can be safely tested and revised. Requirements stability, technical novelty, interdependencies, and the possibility of incremental use all matter. Consider whether a partially complete result is valuable or dangerous, how acceptance can be demonstrated, and when users can supply feedback. Avoid classifying an entire project solely because one deliverable resembles past work. If components have different uncertainty and change costs, choose their methods separately and define the points at which they must integrate.
Understand this item
Why it matters: Deliverable characteristics reveal whether early specification, safe experimentation, or separate component approaches are appropriate.
Decision to make: Assess requirement stability, novelty, change cost, interdependencies, partial-use safety, and available feedback for each deliverable.
Do not confuse it with: A costly physical change rewards earlier certainty; a safely reversible digital change can support more experimentation.
Teach it back: Explain why certified control hardware and a reporting dashboard may need different development plans.
Apply it: A water treatment plant's certified control hardware and its reporting dashboard receive different development plans.
Check yourself: How does the cost of change in a deliverable affect approach selection?
4.3.2 Project
Project-level conditions include stakeholder involvement, schedule constraints, financing uncertainty, size, complexity, and risk. Early partial delivery may produce useful feedback or benefit; a fixed external deadline may call for more explicit advance sequencing. Uncertain funding can favor smaller commitments that provide evidence before the next investment. Yet a highly complex project also needs integration discipline regardless of approach. Determine whether decision makers and users can actually participate at the frequency an adaptive method assumes. Compare methods against constraints instead of inferring that fast delivery automatically means adaptation or that a fixed deadline automatically makes every requirement stable.
Understand this item
Why it matters: Project constraints determine whether an attractive approach is workable in practice.
Decision to make: Test stakeholder availability, deadlines, funding stages, complexity, integration needs, and risk before committing to a cadence of learning.
Do not confuse it with: Frequent planned dates do not make work adaptive; timely evidence and authority to respond to it do.
Teach it back: Explain why an adaptive plan fails when required users or decision makers cannot review increments promptly.
Apply it: A grant-funded service tests an initial neighborhood release before funding later expansion.
Check yourself: Why does an adaptive plan fail if required stakeholders cannot provide timely feedback?
4.3.3 Organization
Organizational culture, governance, policies, team skills, and tolerance for uncertainty influence whether an approach can be executed credibly. A team may prefer frequent releases, but its approval cycle, contracting model, or available product owner may prevent them. Conversely, a highly controlled organization can still allow adaptive learning inside clearly stated boundaries. Examine real decision latency and resource commitments rather than a policy's label. Identify where the organization must adapt to support the chosen method and where the method must accommodate nonnegotiable controls. Training alone is insufficient if people lack authority or time to respond to evidence. Tailoring should be explicit and approved.
Understand this item
Why it matters: Organizational capability can enable or block an approach regardless of what the project plan calls it.
Decision to make: Measure real approval latency, authority, contracting flexibility, skills, and committed product ownership, then tailor explicitly.
Do not confuse it with: Training teaches a method; organizational enablement supplies the time, authority, governance, and resources to practice it.
Teach it back: Explain how a long approval cycle can make short iterations adaptive in name only.
Apply it: A public agency retains mandatory procurement approval but lets a pilot team reorder approved test features.
Check yourself: What organizational bottleneck could make a nominally adaptive approach ineffective?
4.4 Delivery Cadence
Cadence describes when useful results are delivered: once, several times, periodically, or continuously. It is related to, but different from, the development approach. A predictive effort can stage several planned handovers; an adaptive effort can still have constraints on when users may receive work. Choose cadence based on what can be safely accepted and used, benefit timing, integration needs, and the receiving organization's capacity. Frequent delivery is not inherently valuable if each release disrupts operations or cannot pass necessary checks. A single handover may be appropriate when partial operation is unsafe. State what each delivery includes and how feedback from it changes subsequent work.
Understand this item
Why it matters: Cadence should deliver at intervals the receiving system can safely absorb and use.
Decision to make: Choose single, multiple, periodic, or continuous delivery based on benefit timing, safety, integration, acceptance, and operational capacity.
Do not confuse it with: Development approach governs how work evolves; delivery cadence governs when usable results reach recipients.
Teach it back: Explain how a predictively planned bus-shelter program can still hand over completed districts in stages.
Apply it: A city stages approved bus shelters by district but releases rider information updates more frequently.
Check yourself: Can predictive development still deliver multiple usable results?
4.5 Project Management Focus Areas
The five Focus Areas are initiating, planning, executing, monitoring and controlling, and closing. They describe recurring management concerns rather than compulsory sequential phases or an exhaustive inventory of formal processes. In practice they overlap; planning can be revised during execution, and monitoring accompanies work throughout. Each area can be expressed through practices suited to predictive, adaptive, or hybrid delivery. Do not confuse a phase named planning with the Planning Focus Area, which can recur in later phases. Use the five concerns to check that authorization, preparation, coordinated action, feedback and correction, and responsible closure are all addressed in the chosen way of working.
Understand this item
Why it matters: Focus Areas keep essential management concerns visible across any life cycle without imposing five rigid stages.
Decision to make: Check that authorization, planning, coordinated execution, monitoring and response, and orderly closure occur in forms suited to the approach.
Do not confuse it with: A phase is a segment of the life cycle; a Focus Area is a recurring management concern that can overlap and repeat.
Teach it back: Explain how planning and monitoring can occur while an adaptive team executes its current release.
Apply it: A pilot team replans its next release while executing the current one and monitoring adoption.
Check yourself: Why should Focus Areas not be treated as five consecutive project phases?
4.5.1 Initiating Focus Area
Initiating establishes the reason for the effort, authorizes work, and identifies key stakeholders and boundaries. Its form can be scaled to context, but the team needs a credible understanding of the intended value and who has authority to commit resources. At the beginning of a new phase, initiation-like decisions may recur. Distinguish approval to investigate from approval to construct or deploy: uncertainty may justify staged authorization. Record assumptions and constraints clearly enough for planning to begin without presenting them as settled facts. Early stakeholder identification should include those who will operate or experience the result, not only the person who signs the initial authorization.
Understand this item
Why it matters: Initiating creates legitimate authority and a shared basis for investing, planning, and stakeholder involvement.
Decision to make: Clarify purpose, intended value, sponsor, resource authority, boundaries, key stakeholders, assumptions, and level of authorization.
Do not confuse it with: Authorization to investigate permits learning; authorization to deploy commits to a later and usually larger level of work.
Teach it back: Explain what must be clear before a hospital pilot becomes authorized project work.
Apply it: A hospital authorizes a ward pilot with a named sponsor before considering system-wide deployment.
Check yourself: What must be clear before a team treats an idea as authorized project work?
4.5.2 Planning Focus Area
Planning determines a workable course of action and how the team will assess progress toward value. Its level of detail depends on uncertainty and the life cycle: a stable construction sequence can be planned further ahead, while an evolving interface may need rolling-wave elaboration. Plans should integrate scope, schedules, resources, risk, quality, and engagement rather than exist as isolated promises. They are updated when new evidence warrants it, including after execution begins. Progressive elaboration is disciplined refinement, not a license to omit critical safeguards. State decision points and assumptions so changes can be judged against objectives. Even a short adaptive cycle requires enough planning to coordinate work safely.
Understand this item
Why it matters: Planning integrates a workable path while allowing disciplined refinement as evidence changes.
Decision to make: Plan stable matters further ahead, elaborate uncertain work nearer execution, and keep assumptions and decision points visible.
Do not confuse it with: Progressive elaboration adds justified detail over time; vague planning omits necessary coordination or safeguards without a decision basis.
Teach it back: Explain how permit milestones can remain fixed while software iteration details are refined after feedback.
Apply it: A team fixes permit milestones but details the next software iteration only after user feedback.
Check yourself: How can planning continue during execution without making the original plan meaningless?
4.5.3 Executing Focus Area
Executing coordinates people and resources and performs the work needed to deliver the agreed result. The currently authorized plan guides action, but it can be changed through appropriate decisions when a better value proposition emerges. Execution includes engaging stakeholders and integrating work across contributors, not merely completing assigned tasks. Different development approaches influence the rhythm of work, yet all require clear priorities and evidence of what was achieved. Surface obstacles and quality concerns promptly rather than hiding them to preserve schedule appearances. A team should know both its discretion to adjust local methods and the threshold at which a changed baseline needs approval.
Understand this item
Why it matters: Executing turns authorized intent into verified results through integrated people, resources, work, and stakeholder engagement.
Decision to make: Give teams current priorities and local discretion, but escalate obstacles or changes that cross baseline authority.
Do not confuse it with: Producing tasks is one part of execution; coordination ensures contributions, users, resources, and quality evidence form an acceptable result.
Teach it back: Explain why an equipment installer must coordinate operational access and escalate an interface mismatch.
Apply it: A contractor installs equipment, coordinates access with operations, and escalates a discovered interface mismatch.
Check yourself: Why does executing involve stakeholder and resource coordination as well as producing deliverables?
4.5.4 Monitoring and Controlling Focus Area
Monitoring compares actual work and outcomes with intended objectives; controlling determines and implements an appropriate response. Track meaningful indicators, including quality, risk, stakeholder feedback, and value assumptions rather than relying on task completion alone. Deviations are information to interpret, not automatically failures to conceal. A corrective action may alter work, revise a plan, or call for a governance decision. The area operates alongside planning and execution in every approach, including short iterations. State tolerances and escalation routes so the team can respond while choices remain available. Also assess whether a formally on-track project is still likely to produce the intended benefit.
Understand this item
Why it matters: Monitoring and controlling convert performance evidence into timely correction while meaningful choices remain available.
Decision to make: Track objectives, quality, risk, feedback, and value assumptions against tolerances, then select or escalate an appropriate response.
Do not confuse it with: Monitoring detects and interprets variance; controlling decides and implements what to do about it.
Teach it back: Explain why an on-time pilot with low adoption still requires a controlling response.
Apply it: A pilot meets its release date but low adoption triggers a usability review before expansion.
Check yourself: How can a project be on schedule yet require a controlling response?
4.5.5 Closing Focus Area
Closing brings a project or phase to an orderly end, whether objectives were achieved or the effort is stopped early. Confirm acceptance or record the disposition of unfinished work, transfer responsibilities and knowledge, release resources, and settle relevant commitments. A cancellation still deserves a controlled close rather than quiet abandonment; it can protect remaining investment and preserve lessons. The operational owner must be prepared to support a delivered result, while later benefits may continue to be measured outside the project. Distinguish administrative completion from evidence of outcome realization. Document the rationale and any residual risks so future managers do not inherit an invisible obligation.
Understand this item
Why it matters: Orderly closure protects knowledge, resources, commitments, ownership, and residual risk whether work succeeds or stops early.
Decision to make: Confirm acceptance or disposition, transfer ownership and knowledge, settle obligations, release resources, and document lessons and remaining risks.
Do not confuse it with: Administrative closure ends authorized work; benefit realization may continue later under operational ownership.
Teach it back: Explain which closeout duties still apply when an app pilot is canceled before full delivery.
Apply it: A discontinued app pilot closes vendor accounts, transfers user data safely, and records why adoption failed.
Check yourself: What closeout duties remain when a project is terminated before delivery?
4.5.6 Focus Areas as a Whole
The Focus Areas apply across industries and development approaches, but their practices and sequence vary. They often overlap and repeat within phases or iterations: authorization can be revisited, plans elaborated, work performed, evidence assessed, and a completed increment closed. They are independent of a particular application area and should not be mistaken for five rigid stages. Look at the whole pattern to ensure no essential management concern disappears when a team adopts a different delivery method. Repetition should be purposeful: a short iteration can involve planning, execution, and checking without creating five unnecessary ceremonies. Maintain continuity of decision rights and value objectives across the cycles.
Understand this item
Why it matters: Using Focus Areas as a recurring whole prevents a chosen methodology from omitting essential management responsibilities.
Decision to make: Within phases or iterations, scale and repeat only the authorization, planning, work, checking, and closure activities that add control or learning.
Do not confuse it with: Purposeful recurrence revisits concerns as evidence changes; rigid ceremony repeats forms without improving decisions.
Teach it back: Explain how an adaptive release can involve several Focus Areas while retaining one sponsor and overall benefit goal.
Apply it: A digital pilot revisits plans and controls each release while retaining one sponsor and overall benefit goal.
Check yourself: How do Focus Areas recur in an adaptive cycle without becoming rigid phase gates?
Apply it to a project
A utility is building a smart-meter service. Physical meter certification, procurement, and field installation have stable safety requirements, costly late changes, and regulatory gates, so those streams use predictive planning. The customer portal and analytics have uncertain user needs and are developed in short adaptive iterations. Integration is hybrid: fixed interface standards and deployment windows connect evolving software to certified hardware. The project uses feasibility, pilot, regulatory approval, rollout, and transition phases, each with explicit entrance and exit criteria. Meters are delivered by region in multiple waves; portal updates follow a periodic cadence, with selected low-risk fixes moving toward continuous delivery after automation matures. Initiating aligns strategy and stakeholders; planning is detailed for field work and rolling-wave for software; execution and Monitoring and Controlling overlap; and Closing verifies operational support, benefit measures, contracts, lessons, and data ownership. A gate can pause rollout if cybersecurity evidence or customer outcomes undermine the value case.
What to watch for
- Misconception: Project phases and Focus Areas are the same. Correction: phases organize the life cycle; Focus Areas are management actions that can recur within every phase.
- Misconception: Predictive always means one final delivery. Correction: known total scope can still be delivered in planned increments.
- Misconception: Adaptive means no plan, baseline, or control. Correction: adaptive work uses vision, roadmaps, short-horizon planning, capacity or time constraints, reviews, and evolving baselines.
- Misconception: Iterative and incremental mean the same thing. Correction: iteration refines through repeated cycles; increments add usable portions of the solution.
- Misconception: Hybrid means weak discipline or indecision. Correction: a well-designed hybrid deliberately matches methods to different uncertainties, constraints, and workstreams.
- Misconception: Regulation always forces the entire project to be predictive. Correction: regulated evidence and gates may be predictive while uncertain, separable work uses adaptive practices.
- Misconception: Monitoring and Controlling begins after execution. Correction: it operates in parallel with other Focus Areas and across phases.
- Misconception: Closing only occurs after successful completion. Correction: phases, contracts, and projects may close normally, suspend, or terminate early.
- Misconception: The development approach alone determines delivery cadence. Correction: cadence is a separate design choice influenced by value, risk, divisibility, and release capability.
- Misconception: Once approved, the project management plan should not change. Correction: it should be updated when evidence shows that change improves the value proposition and governance approves it.
Test your reasoning
Which statement correctly distinguishes a development approach from a project phase?
Show answer and reasoning
A development approach explains how a deliverable is created and evolved; a phase groups logically related project activities around deliverables or outcomes. The approach is the method of development, while phases organize the project life cycle. One phase can use more than one approach, and one approach can span phases.
A team repeatedly refines a prototype, while each monthly release adds a usable capability. Which description is accurate?
Show answer and reasoning
The refinement is iterative and the releases are incremental. Iterations improve or clarify through repeated cycles; increments add usable parts that accumulate toward the complete solution.
Which situation most strongly favors a predictive approach?
Show answer and reasoning
Stable safety requirements, expensive physical rework, and mandatory regulatory reviews Stable scope, high change cost, major investment, safety, and regulation make robust up-front planning and controlled phase transitions valuable.
Which statement about Project Management Focus Areas is correct?
Show answer and reasoning
They are recurring, overlapping management actions that apply in every development approach. Initiating, Planning, Executing, Monitoring and Controlling, and Closing interact dynamically and may repeat within phases and iterations.
At a phase gate, evidence shows that strategic alignment has disappeared and no feasible modification restores the value case. What is the best decision?
Show answer and reasoning
End or park the project through the agreed governance process. Gate decisions can continue, modify, repeat, pause, or terminate work. Preserving resources can be more valuable than completing an initiative that no longer supports strategy.
Study companion only; the official guide is available from PMI.