Overview
Program Life Cycle Management is 44% of the PgMP exam and holds 35 of the outline's 72 tasks. It follows a program through definition, delivery and closure: developing the charter, scope statements, roadmap, responsibility assignment matrix, program WBS, management plan and schedule; chartering constituent projects; deploying governance, communication and PMIS; leading people; consolidating data, analyzing variances and trends, managing issues, changes and risks; and finally approving component closure, transitioning results and recording lessons learned.
The skill tested is working one level above the project. A program manager integrates, escalates, rebalances resources and protects benefits across components; a project manager delivers one component's scope. Most wrong answers in this domain are good project-manager actions taken by the wrong person or at the wrong level. The domain borrows its targets from Strategic Program Alignment and Benefits Management and operates inside the framework set by Governance.
How it's tested
Questions follow the life cycle: definition, delivery and closure. Expect FIRST/NEXT sequencing, BEST-response judgment about issues, changes and underperforming components, and occasional calculations such as program-level earned value. The winning option usually acts at program level, uses the agreed plan or process, and considers impact on other components and benefits before deciding.
-
Right level, right owner
A component issue, change or risk is described, and you decide whether the project manager handles it, the program manager resolves it, or governance must decide. Authority thresholds and cross-component impact are the clues.
-
Analyze before acting
A variance, trend or change request appears. The best answer consolidates data or assesses impact across components before recommending corrective action or approval.
-
Life cycle sequencing
You order steps such as charter, roadmap, program WBS, schedule, component chartering, closure approval and transition, or pick what must happen before a component may start or close.
A key component reports a three-month slip and its project manager asks to cut testing to recover. Cutting testing looks decisive, but the program manager should first assess the slip's impact on dependent components, the integrated schedule and benefit timing. If the impact exceeds the program manager's authority, the change goes to the governance board with options; otherwise it follows the program change management plan.
Tasks 35
Official tasks from the PMI outline, in outline order.
2.1 Develop the program charterDocument scope, assumptions, constraints, high-level risks and benefits to formalize the program.
- What it means
- The program manager turns the alignment work into a charter covering scope, assumptions, constraints, high-level risks, benefits, resources and governance, which leadership approves to authorize the program.
- What to understand
- The charter is the bridge from justification to delivery. Everything in later plans should be traceable to it, and changes to its fundamentals go back to the sponsor.
- How it shows up
- A stem asks which document should be completed before chartering component projects. The program charter comes first.
- Common confusion
- Confusing the program charter with component project charters, which the program issues later under task 2.16.
2.2 Translate strategic objectives into high-level program scope statementsNegotiate scope with stakeholders so it reflects strategy.
- What it means
- The program manager works with stakeholders to convert strategic objectives into high-level scope statements that define what the program will and will not deliver.
- What to understand
- Scope is derived from objectives and benefits, and negotiation is expected because stakeholders often want more than strategy supports.
- How it shows up
- Stakeholders push to add a capability unrelated to the stated objectives. The answer negotiates scope back to strategy.
- Common confusion
- Treating high-level scope as a list of project deliverables. At program level it describes outcomes and boundaries.
2.3 Develop a program roadmapUse goals, history and stakeholder input to sequence major milestones.
- What it means
- Building on the preliminary roadmap, the program manager defines the program roadmap showing major milestones, component sequencing, decision points and when benefits are expected.
- What to understand
- The roadmap guides component sequencing and stakeholder expectations. It changes only through governance because others plan against it.
- How it shows up
- A sponsor asks how components will be sequenced to deliver early benefits. A roadmap showing milestone order answers it.
- Common confusion
- Using the roadmap and the integrated schedule interchangeably; the schedule adds detail and dates for component work.
2.4 Develop a responsibility assignment matrixIdentify and assign program roles and responsibilities.
- What it means
- The program manager defines who is responsible, accountable, consulted and informed for program-level work and decisions, often as a RACI chart covering sponsors, the governance board, program staff and component managers.
- What to understand
- A RACI chart (responsible, accountable, consulted, informed) has exactly one accountable role per item. Gaps or duplicate accountability cause stalled decisions.
- How it shows up
- Two component managers both believe they own an interface deliverable. The fix is clarifying the responsibility assignment matrix.
- Common confusion
- Assigning accountability to several people for safety. Shared accountability means nobody is accountable.
2.5 Define standard measurement criteria, including KPIs, for success and review pointsAgree how success will be measured and when it will be reviewed.
- What it means
- The program manager sets standard criteria and key performance indicators that define success, plus the review points at which progress is measured against them.
- What to understand
- Standard criteria let data from different components be compared and rolled up. Review points create the rhythm for governance decisions.
- How it shows up
- Components report progress in incompatible formats. The response is to define standard measurement criteria.
- Common confusion
- Letting each component choose its own metrics, which prevents program-level consolidation.
2.6 Conduct program kick-off with key stakeholdersFamiliarize the organization with the program and its expectations.
- What it means
- The program manager holds a kick-off with sponsors, governance members, component managers and other key stakeholders to communicate goals, roles, governance and the roadmap.
- What to understand
- Kick-off builds shared understanding and commitment. It follows authorization and enough planning to present roles and direction credibly.
- How it shows up
- A program has been chartered but component teams interpret its goals differently. A kick-off aligns them.
- Common confusion
- Holding the kick-off before the charter is approved, which presents direction that may still change.
2.7 Develop a detailed program scope statementIncorporate the vision and internal and external inputs into a detailed scope.
- What it means
- The program manager refines high-level scope into a detailed program scope statement that reflects the vision, requirements and constraints from inside and outside the organization.
- What to understand
- The detailed scope is the basis for the program WBS and component definitions. Ambiguity here becomes gaps or overlaps between components.
- How it shows up
- Two components both plan to build the same reporting function. The detailed scope statement should have assigned it.
- Common confusion
- Writing the detailed scope before agreeing high-level scope with stakeholders.
2.8 Develop program WBSDecompose program scope to determine, plan and assign work.
- What it means
- The program work breakdown structure decomposes the program into components and program-level work packages, usually stopping at the level where components are assigned and leaving detailed decomposition to component teams.
- What to understand
- The program WBS includes program management work itself, such as governance and integration, not just component deliverables.
- How it shows up
- A question asks where program-level activities like benefit reporting appear. They belong in the program WBS.
- Common confusion
- Decomposing the program WBS down to activities. Detailed decomposition belongs to the component projects.
2.9 Establish the program management plan and scheduleIntegrate component plans into one program plan and schedule.
- What it means
- The program manager integrates subsidiary plans and component plans into a program management plan and an integrated program schedule that shows component timing and interdependencies.
- What to understand
- The program schedule focuses on milestones and dependencies between components. Program-level float and interfaces matter more than activities inside each component.
- How it shows up
- One component's delivery feeds three others. The question asks which artifact exposes the dependency, and the answer is the integrated program schedule.
- Common confusion
- Expecting the program schedule to contain every component activity.
2.10 Optimize the program management planIdentify, review and level resource requirements across components.
- What it means
- The program manager reviews resource demand across all components and levels or reallocates scarce resources so the plan is achievable and supports priority benefits.
- What to understand
- Resource leveling at program level resolves conflicts between components, sometimes by resequencing lower-priority work.
- How it shows up
- Two components need the same specialist team at the same time. The program manager resolves it by priority and benefit impact.
- Common confusion
- Leaving shared-resource conflicts for component managers to negotiate alone.
2.11 Define the project/program management information system (PMIS)Select tools and processes to share information.
- What it means
- The program manager defines the information system, tools and processes that collect, store and share program and component data.
- What to understand
- A shared PMIS makes consolidation and reporting possible. Without it, status is assembled manually and often inconsistently.
- How it shows up
- Status reports from components conflict with each other. Defining a common PMIS and data standards addresses the root cause.
- Common confusion
- Treating PMIS as one software tool; it covers processes and data standards too.
2.12 Identify and manage unresolved project-level issuesCreate monitoring and escalation for issues components cannot solve.
- What it means
- The program manager sets up a mechanism to monitor component issues and escalate those that exceed component authority or affect other components.
- What to understand
- Escalation thresholds are defined in advance. An issue moves up when it crosses a threshold, not when someone is uncomfortable.
- How it shows up
- A component issue threatens another component's milestone. It becomes a program-level matter.
- Common confusion
- Pulling every component issue up to program level, which overloads the program and undermines component managers.
2.13 Develop the benefits management planDefine how benefits will be integrated, transitioned and sustained.
- What it means
- The program manager develops the plan that sets out how benefits will be delivered, measured, integrated into operations and sustained after transition.
- What to understand
- This plan operationalizes the benefits identified during alignment and connects component outputs to outcomes. Domain 3 covers its detail.
- How it shows up
- A component produces outputs but nobody knows how to measure the resulting benefit. The benefits management plan should define it.
- Common confusion
- Assuming benefits are measured only at program closure.
2.14 Develop key performance indicators (KPIs)Use decomposition and mapping to manage the program.
- What it means
- The program manager decomposes goals into measurable indicators and maps them to components so performance can be tracked at program level.
- What to understand
- Good KPIs link component performance to program objectives and benefits; leading indicators give warning before outcomes slip.
- How it shows up
- Leadership asks for early warning of benefit risk. Leading KPIs mapped to components answer this.
- Common confusion
- Using only lagging indicators such as final cost, which reveal problems too late.
2.15 Monitor human resources for program and project roles, including subcontractorsTrack staffing and identify opportunities for contract negotiation.
- What it means
- The program manager tracks staffing across program and component roles, including subcontractors, and identifies when contracts or resource agreements need renegotiation.
- What to understand
- Program-level visibility of people and contracts reveals shortages, overlaps and opportunities to consolidate vendors.
- How it shows up
- Several components use the same subcontractor on separate contracts. Consolidated negotiation is a program-level opportunity.
- Common confusion
- Treating subcontractor management as purely a component concern.
2.16 Charter and initiate constituent projects/componentsAssign project managers and allocate resources to start components.
- What it means
- The program manager authorizes component projects by issuing their charters, assigning project managers and allocating budget and resources according to the roadmap.
- What to understand
- Components start when program conditions are met, such as dependencies, funding and resources, not simply when a team is ready.
- How it shows up
- A component team wants to start early while a predecessor is unfinished. The program decides based on dependencies and benefit sequencing.
- Common confusion
- Thinking component charters come from outside the program; within a program, the program initiates them.
2.17 Establish consistency by deploying the governance frameworkRoll out uniform standards, resources and infrastructure across components.
- What it means
- The program manager deploys the governance framework, standards, templates, resources and infrastructure so all components work consistently.
- What to understand
- Consistency enables comparison, consolidation and predictable escalation. Domain 5 selects the framework; this task puts it into use.
- How it shows up
- Components use different change processes. Deploying the common governance framework fixes the inconsistency.
- Common confusion
- Confusing designing the governance framework (Domain 5) with deploying it (this task).
2.18 Establish a communication feedback plan and reporting processCapture lessons learned and feedback through regular reporting.
- What it means
- The program manager creates the feedback loop and reporting process that moves information between components, the program and stakeholders, including lessons learned.
- What to understand
- Feedback is two-way. Reports that only flow upward miss problems that stakeholders and component teams could flag early.
- How it shows up
- Stakeholders complain they hear about problems late. A defined feedback and reporting process is the fix.
- Common confusion
- Treating reporting as a one-way status broadcast.
2.19 Lead human resource functionsTrain, coach, mentor and recognize the team.
- What it means
- The program manager leads people across the program by developing skills, coaching component managers, mentoring and recognizing contributions.
- What to understand
- Program leadership is largely indirect; influence over component managers and teams matters as much as formal authority.
- How it shows up
- A capable component manager is struggling with a new type of work. Coaching and mentoring is the leadership response before replacement.
- Common confusion
- Jumping to replacing people before developing them.
2.20 Review project managers' performanceAssess how component managers execute against their plans.
- What it means
- The program manager reviews how each project manager delivers against the project plan and program standards, and provides feedback.
- What to understand
- Reviews focus on contribution to program outcomes, not only on the component's own metrics.
- How it shows up
- A component is on budget but repeatedly misses interface commitments to other components. The review should address it.
- Common confusion
- Judging component managers only on their own schedule and budget.
2.21 Execute the appropriate program management plansCarry out quality, risk, communication, resourcing and other plans.
- What it means
- The program manager executes the program's subsidiary plans, such as quality, risk, communication and resourcing, and makes sure components follow them.
- What to understand
- Plans exist to be used. When a situation is covered by an agreed plan, follow the plan before improvising.
- How it shows up
- A communication problem arises that the communication plan already addresses. The answer is to apply the plan.
- Common confusion
- Creating a new process for a situation an existing plan already covers.
2.22 Consolidate project and program dataUse predefined reporting tools to roll up information.
- What it means
- The program manager collects component and program data through the agreed tools and methods and consolidates it into a single view of program performance.
- What to understand
- Consolidation must use raw values, such as summed earned value and actual cost, not averages of component indices.
- How it shows up
- A calculation asks for program CPI from component data. Sum EV and AC first, then divide.
- Common confusion
- Averaging component CPIs or SPIs, which ignores the size of each component.
2.23 Evaluate the program's statusMonitor and control while keeping program information current.
- What it means
- The program manager evaluates consolidated status against the baseline and benefits to decide whether the program remains on track.
- What to understand
- Status includes benefit realization, not only cost and schedule. A program on budget but missing benefit targets is not healthy.
- How it shows up
- All components are green but adoption of delivered capability is low. Program status should flag the benefit risk.
- Common confusion
- Equating program health with the sum of component health.
2.24 Approve closure of constituent projects/componentsClose components once defined deliverables are complete.
- What it means
- The program manager approves closing a component when its deliverables are complete and accepted, its results transitioned and its resources released.
- What to understand
- Component closure can happen while the program continues. Approval confirms the outputs are ready to support benefits.
- How it shows up
- A project manager wants to close a component but transition to operations is incomplete. Approval waits until transition criteria are met.
- Common confusion
- Assuming components can only close when the whole program closes.
2.25 Analyze variances and trendsCompare actual and forecast cost, schedule, quality and risk.
- What it means
- The program manager compares actual and forecast values with the plan to find variances and trends, using tools such as earned value management.
- What to understand
- Know the core formulas: CV = EV - AC, SV = EV - PV, CPI = EV / AC, SPI = EV / PV, EAC = BAC / CPI under typical variance. Trends over several periods matter more than one data point.
- How it shows up
- A stem gives EV, AC and PV and asks what they indicate. A CPI below 1 means over budget; an SPI below 1 means behind schedule.
- Common confusion
- Reversing the formulas, for example dividing AC by EV.
2.26 Update program plans by incorporating corrective actionsAdjust plans so resources are employed effectively.
- What it means
- When analysis shows the program drifting, the program manager updates plans with approved corrective actions so resources stay focused on objectives.
- What to understand
- Corrective actions that change baselines go through change control. Updates keep plans realistic and traceable.
- How it shows up
- A trend shows sustained overspend in one component. Corrective action is planned and the program plan updated through the change process.
- Common confusion
- Changing baselines informally without approval.
2.27 Manage program-level issuesResolve issues in areas such as people, finance, technology and scheduling.
- What it means
- The program manager owns issues that span components or exceed component authority, using an issue log and the escalation path.
- What to understand
- An issue is a current problem; a risk is uncertain. Program-level issues get owners, actions and deadlines.
- How it shows up
- A vendor dispute affects three components. The program manager manages it as a program-level issue.
- Common confusion
- Logging a current problem as a risk.
2.28 Manage changes per the change management planControl scope, quality, schedule, cost and contracts.
- What it means
- The program manager applies the program change management plan to requests that affect program scope, quality, schedule, cost or contracts, routing them to the right authority.
- What to understand
- Change authority is tiered: components decide within their thresholds, the program decides above them, and governance decides changes that affect the charter, benefits or strategic alignment.
- How it shows up
- A sponsor verbally asks for a new feature. The program manager logs it and runs it through change management.
- Common confusion
- Implementing a senior stakeholder's request without formal change control.
2.29 Conduct impact assessments for program changesAssess impact and recommend decisions for approval.
- What it means
- Before a change is approved, the program manager assesses its impact on components, interdependencies, benefits, risk and resources, then recommends a decision.
- What to understand
- Impact assessment comes before approval or rejection. Its scope is the whole program, not only the requesting component.
- How it shows up
- A change request arrives with urgent pressure. The NEXT step is impact assessment, not immediate approval.
- Common confusion
- Approving or rejecting before assessing cross-component impact.
2.30 Manage risk per the risk management planHandle program risks to protect objectives.
- What it means
- The program manager identifies, analyzes, responds to and monitors program risks, including risks that arise from interdependencies and aggregated component risk.
- What to understand
- Program risk includes opportunities and risks that individual components cannot see. Risks are escalated by threshold, and program reserves cover program-level exposure.
- How it shows up
- Three components each list a minor supplier risk. Combined, the program faces a major single-supplier dependency to manage at program level.
- Common confusion
- Treating program risk as a list of component risks without aggregation.
2.31 Complete a program performance analysis reportCompare actual and planned values to report performance.
- What it means
- The program manager produces a report comparing actuals with plans for cost, schedule, quality, risk and benefits, with conclusions for stakeholders.
- What to understand
- The report supports decisions, so it includes interpretation and forecast, not raw data alone.
- How it shows up
- The governance board needs to decide on continued funding. A performance analysis report with forecasts supplies the evidence.
- Common confusion
- Sending raw dashboards in place of analysis.
2.32 Conduct program closureClose the program within the boundaries of governance.
- What it means
- The program manager closes the program when the governance body agrees that benefits are delivered or that the program should end for other reasons, such as a strategic change.
- What to understand
- Program closure needs governance approval. A program may also close early when the business case no longer holds.
- How it shows up
- Strategy changes and the program's benefits are no longer needed. The program manager recommends closure to governance.
- Common confusion
- Assuming a program closes only when every planned component is finished.
2.33 Execute the transition and close-out of the program and constituent projects/componentsHand over results and close remaining components.
- What it means
- The program manager transitions products, services and ongoing benefit responsibilities to operations or other owners and closes remaining components, contracts and records.
- What to understand
- Transition assigns ongoing ownership for sustaining benefits. Close-out also releases resources and settles contracts.
- How it shows up
- Operations has not accepted a delivered system. Close-out waits until transition and acceptance are complete.
- Common confusion
- Closing contracts and releasing staff before operations has accepted the handover.
2.34 Conduct post-review meetingsPresent program performance reports to obtain feedback.
- What it means
- At or near closure, the program manager presents performance results to stakeholders to gather feedback and confirm acceptance.
- What to understand
- The post-review is a feedback and acceptance step, not a celebration. It informs lessons learned and future programs.
- How it shows up
- Before final archiving, the program manager needs stakeholder feedback on outcomes. A post-review meeting is the step.
- Common confusion
- Skipping post-review because all components are closed.
2.35 Report lessons learned and best practicesArchive lessons to the knowledge repository.
- What it means
- The program manager records lessons learned and best practices and archives them in the organization's knowledge repository.
- What to understand
- Lessons are captured throughout the program and finalized at closure so future programs can use them.
- How it shows up
- A question asks when lessons learned should be captured. Throughout the life cycle, then consolidated at closure.
- Common confusion
- Capturing lessons only at the end, when many details are lost.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Program life cycle phases
PMI's Standard for Program Management describes programs moving through definition, delivery and closure, with components started and closed during delivery.
- Remember
- Components can begin and end at different times while the program continues.
- Tested as
- Sequencing questions use the phase to decide what is appropriate next.
- Trap
- Mapping program phases one-to-one onto project process groups.
-
Program WBS
Decomposition of program scope into components and program-level work, including program management activities.
- Remember
- It stops at the component level; detailed decomposition belongs to component teams.
- Tested as
- Questions about where program-level work appears or how far to decompose.
- Trap
- Decomposing the program WBS down to activities.
-
Integrated program schedule
Program-level schedule showing component milestones, program activities and interdependencies.
- Remember
- Its value is in exposing cross-component dependencies.
- Tested as
- Dependency and slip scenarios point to it.
- Trap
- Confusing it with the roadmap or expecting component activity detail.
-
Cost performance index (CPI)
CPI = EV / AC; below 1 means more is being spent than the value of work done.
- Remember
- At program level, sum EV and AC across components before dividing.
- Tested as
- Calculation and interpretation questions on program cost health.
- Trap
- Averaging component CPIs.
-
Schedule performance index (SPI)
SPI = EV / PV; below 1 means less work is done than planned by this point.
- Remember
- Like CPI, roll up EV and PV first for the program figure.
- Tested as
- Schedule-health interpretation in status scenarios.
- Trap
- Reading an SPI of 1.1 as behind schedule.
-
Estimate at completion (EAC)
Forecast total cost; with typical variance expected to continue, EAC = BAC / CPI.
- Remember
- Use BAC / CPI when current efficiency is expected to persist; other formulas apply for atypical variance.
- Tested as
- Forecast questions in performance analysis reports.
- Trap
- Using the original budget as the forecast after sustained overspend.
-
Escalation threshold
Predefined limits on cost, schedule, scope or risk beyond which a decision moves to the next authority level.
- Remember
- Escalate when a threshold is crossed or other components are affected, not by preference.
- Tested as
- Right-level decision questions across issues, risks and changes.
- Trap
- Escalating everything, or resolving cross-component matters inside one component.
-
Program change management
The process for evaluating, approving and implementing changes to program scope, schedule, cost, quality, contracts and benefits.
- Remember
- Log, assess impact across the program, decide at the right authority level, then update plans and communicate.
- Tested as
- Informal requests from senior stakeholders are a classic stem.
- Trap
- Implementing a sponsor's informal request without change control.
-
Issue vs. risk
An issue is a current problem requiring action; a risk is an uncertain event that may affect objectives.
- Remember
- Issues go to the issue log with owners and deadlines; risks go to the risk register with responses.
- Tested as
- Stems describing something that has already happened test this distinction.
- Trap
- Adding a current problem to the risk register.
-
Responsibility assignment matrix (RACI)
A matrix mapping work or decisions to roles as responsible, accountable, consulted or informed.
- Remember
- Exactly one accountable role per item.
- Tested as
- Ownership disputes between components.
- Trap
- Assigning accountability to more than one role.
-
Component closure vs. program closure
Components close when their deliverables are accepted and transitioned; the program closes when governance agrees benefits are delivered or the program should end.
- Remember
- Component closure happens during delivery; program closure needs governance approval.
- Tested as
- Closure-timing and approval questions.
- Trap
- Holding all component closures until program end.
-
PMIS
The project/program management information system: tools, processes and data standards used to collect, store and share program information.
- Remember
- Common data standards are what make consolidation possible.
- Tested as
- Inconsistent reporting scenarios.
- Trap
- Thinking a single software purchase solves inconsistent data.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Program manager vs. project manager responsibilities
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Program manager | Integrates components, manages interdependencies, protects benefits and escalates to governance | Works across components and decides on cross-component trade-offs | Micromanaging component tasks |
| Project manager | Delivers one component's scope, schedule, cost and quality | Works inside component authority limits | Making changes that affect other components without escalation |
Issue vs. risk vs. change request
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Issue | A current problem affecting the program | Already happening; needs an owner and resolution | Logging it as a risk |
| Risk | An uncertain event that could affect objectives, positively or negatively | May happen; handled with planned responses | Ignoring opportunities |
| Change request | A proposal to modify scope, schedule, cost, quality, contracts or benefits | Needs impact assessment and approval at the right level | Implementing before approval |
Program roadmap vs. integrated program schedule vs. program WBS
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Program roadmap | High-level milestones, sequencing and benefit timing | Strategic communication of direction | Expecting dependency detail |
| Integrated program schedule | Component milestones, program activities and interdependencies with dates | Used to manage timing and dependencies | Loading it with every component activity |
| Program WBS | Decomposition of program scope into components and program work | Defines what work exists, not when | Decomposing below the component level |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Solving it inside the component
- What candidates pick
- Tell the project manager to fix a slip by crashing or cutting scope inside the component.
- Why it looks right
- It is fast and keeps the problem contained.
- Why it's wrong
- If the slip affects dependent components or benefit timing, the decision belongs at program level, where impact can be assessed across the program.
Clue to watch for The scenario mentions other components, shared resources or a milestone that others depend on.
-
Approve the urgent change
- What candidates pick
- Approve a sponsor's change request immediately because the sponsor is senior.
- Why it looks right
- The sponsor funds the program and the request sounds sensible.
- Why it's wrong
- All changes follow the change management plan: log, assess impact, then decide at the authority level the plan specifies.
Clue to watch for A senior person asks for something informally or urgently.
-
Averaging indices
- What candidates pick
- Report program CPI as the average of component CPIs.
- Why it looks right
- Averaging feels like a fair summary.
- Why it's wrong
- Components differ in size; the program index must be computed from summed EV and AC (or PV), otherwise a small component distorts the result.
Clue to watch for The question gives component EV, AC or PV values of different sizes.
-
Green components mean a healthy program
- What candidates pick
- Report the program as on track because every component is on schedule and budget.
- Why it looks right
- Component dashboards all look good.
- Why it's wrong
- Program status includes benefits and integration. Outputs delivered on time can still fail to produce the expected benefits.
Clue to watch for The stem mentions low adoption, unrealized benefits or interface problems.
-
Close when deliverables are done
- What candidates pick
- Approve component closure and release staff as soon as deliverables are complete.
- Why it looks right
- The scope is finished and the team is costly.
- Why it's wrong
- Closure follows acceptance and transition; releasing the team before operations accepts the handover puts sustained benefits at risk.
Clue to watch for Operations has not signed off, or support arrangements are not in place.
-
Escalate everything
- What candidates pick
- Send every component issue to the governance board.
- Why it looks right
- Escalation looks cautious and transparent.
- Why it's wrong
- Escalation is threshold-based. Issues within program authority are resolved by the program manager; overloading governance slows decisions.
Clue to watch for The issue is within defined tolerances or the program manager's authority.
Answer framework
For any Domain 2 scenario, decide the level and the process before choosing an action.
- Locate the program in its life cycle phase and identify which plan, process or artifact governs the situation.
- Determine whether the matter stays inside one component or affects interdependencies, shared resources, benefits, contracts or other components, because that decides who owns it.
- Gather and consolidate the facts first: summed earned value data, trend over several periods, and an impact assessment across the program.
- Apply the agreed plan or threshold, resolving the matter within your authority or escalating it to the governance board with options, impacts and a recommendation.
- Update plans, logs and stakeholders after the decision, and confirm the action still protects benefit delivery and timing.
Practice question
Want more like this? The PgMP practice test has questions for every domain.
Checklist
0 of 13
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Because this domain is 44% of the exam, give it the largest block of study time, but study it in life cycle order so the 35 tasks form a story rather than a list. Start with definition tasks (charter, scope statements, roadmap, RACI, measures, kick-off, detailed scope, program WBS, plan and schedule), then delivery tasks (component chartering, governance deployment, PMIS, reporting, leadership, consolidation, variance analysis, issues, changes, risks), then closure (component closure approval, program closure, transition, post-review, lessons learned).
High-priority concepts are the escalation logic and the change process, because they appear in many scenario shapes. Practice deciding who owns a decision using thresholds and cross-component impact. Drill program-level earned value until summing before dividing is automatic.
The most underestimated area is closure: candidates assume it is administrative, but the exam tests acceptance, transition to operations and governance approval. After this domain, read Governance to understand the framework you are deploying, then practice long mixed sets of life cycle scenarios and review every miss by asking whether you answered at project level instead of program level.
FAQ
Why is Program Life Cycle Management weighted so heavily?
It is 44% of the exam and holds 35 of the 72 ECO tasks, covering everything from chartering to closure. It reflects the day-to-day work of running a program, so it shows up in a wide range of scenario types.
How many questions come from this domain?
Applying 44% to the 170-question exam gives roughly 75 questions as an editorial planning estimate. PMI does not publish per-domain question counts.
Are there calculations in Domain 2?
Expect earned value interpretation and possibly calculation: CPI = EV / AC, SPI = EV / PV, CV = EV - AC, SV = EV - PV and EAC = BAC / CPI for typical variance. At program level, sum component values before computing indices.
How do I know whether to escalate an issue?
Use the defined thresholds and impact. If the issue exceeds a component's authority or affects other components, it moves to the program; if it affects the charter, benefits or strategic alignment, or exceeds program authority, it goes to the governance board.
Can a component close before the program ends?
Yes. Components close when deliverables are complete and accepted and results have transitioned, while the program continues to manage other components and benefits.
How is this domain different from PMP-style project management?
The task names look familiar, but the decisions are made across components: integrating schedules, rebalancing resources, assessing cross-component impact and protecting benefits. Answers that optimize one component at the expense of the program are usually wrong.
Which domains should I study alongside this one?
Governance defines the framework, thresholds and stage gates you apply here, and Benefits Management defines what the life cycle is ultimately delivering. Studying them together makes the escalation and closure questions easier.
Other Project Management certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
- PRINCE2 7 Practitioner Study guide
- PMI Risk Management Professional Study guide
- PMI Scheduling Professional Study guide
- Project Management Professional Study guide
- CompTIA Project+ Study guide
- PRINCE2 7 Foundation Study guide
- Portfolio Management Professional Study guide
- Certified Associate in Project Management Study guide
- Agile Project Management Study guide
- PMI Agile Certified Practitioner Study guide
- Project Management Professional (PMBOK 7) Study guide
- Disciplined Agile Scrum Master Study guide
Test your Domain 2 knowledge
You have walked through the 35 life cycle tasks, program-level earned value, change and issue control, and closure. Test whether you consistently answer from the program level under timed conditions.