Try 10 focused Project+ questions on Project Life Cycle Phases, with answers and explanations, then continue with PM Mastery.
| Field | Detail |
|---|---|
| Exam route | Project+ |
| Topic area | Project Life Cycle Phases |
| Blueprint weight | 30% |
| Page purpose | Focused sample questions before returning to mixed practice |
Use this page to isolate Project Life Cycle Phases for Project+. Work through the 10 questions first, then review the explanations and return to mixed practice in PM Mastery.
| Pass | What to do | What to record |
|---|---|---|
| First attempt | Answer without checking the explanation first. | The fact, rule, calculation, or judgment point that controlled your answer. |
| Review | Read the explanation even when you were correct. | Why the best answer is stronger than the closest distractor. |
| Repair | Repeat only missed or uncertain items after a short break. | The pattern behind misses, not the answer letter. |
| Transfer | Return to mixed practice once the topic feels stable. | Whether the same skill holds up when the topic is no longer obvious. |
Blueprint context: 30% of the practice outline. A focused topic score can overstate readiness if you recognize the pattern too quickly, so use it as repair work before timed mixed sets.
These questions are original PM Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.
Topic: Project Life Cycle Phases
You are planning a 4-month data center migration project. The sponsor asks how risks will be managed and how often the risk log will be updated.
Exhibit: Risk register (excerpt)
R-03: ISP circuit delivery delay | P=4 I=5 | Response: Mitigate | Owner: Vendor Mgr | Last review: 5 weeks ago
R-07: Weekend change window denied | P=3 I=4 | Response: Avoid | Owner: Ops Lead | Last review: 2 weeks ago
R-09: Firewall rule rework needed | P=2 I=3 | Response: Accept | Owner: Net Eng | Last review: 1 week ago
Based on the exhibit, what is the BEST next action?
Best answer: A
What this tests: Project Life Cycle Phases
Explanation: Risk management planning includes defining how risks will be identified, analyzed, responded to, and monitored, including an agreed update cadence. The exhibit shows a high-priority risk that has not been reviewed in over a month, indicating the monitoring process is not being executed consistently. Establishing a recurring review with risk owners and clear update expectations addresses the sponsor’s request.
A risk register is only effective if it is actively monitored and updated on a defined cadence. In planning, you should document risk management activities (identify, analyze, respond, monitor) and explicitly set when and how the risk log is reviewed and updated (for example, at a weekly status meeting, with ad-hoc reviews when triggers occur). The exhibit shows a high probability/high impact risk (R-03) with a last review of 5 weeks ago, suggesting the monitoring step and update cadence are not defined or not being followed. The best next action is to establish the risk review schedule, clarify responsibilities for updates, and ensure owners review their risks regularly and escalate based on agreed thresholds. This improves visibility, supports timely responses, and aligns expectations with the sponsor.
The project needs a documented plan to monitor and update risks on a set cadence, especially for the high-impact risk that is overdue for review.
Topic: Project Life Cycle Phases
You are coordinating a SaaS CRM implementation. Two milestones were missed after “surprise” items surfaced (a data-retention requirement and a vendor API limit), forcing rework in design and test plans. Stakeholders are submitting late changes, and the team says ownership is unclear for “what could go wrong.” You find a risk register created at kickoff, but it has no named risk owners and has not been updated in 8 weeks; weekly status meetings do not include risk review.
Which is the most likely underlying cause?
Best answer: D
What this tests: Project Life Cycle Phases
Explanation: The clues point to risk work not being actively performed or governed: the risk register has no owners, hasn’t been updated, and risks aren’t reviewed in status meetings. That indicates the project never planned how it would identify, analyze, respond to, and monitor risks, including a defined update cadence. As a result, predictable constraints surface late and drive rework and schedule slips.
The underlying problem is the absence of a planned, repeatable risk management approach. In planning, the team should define how risks will be identified, analyzed (probability/impact), assigned an owner with response actions, and monitored on a set cadence (for example, reviewing the risk register/RAID in each weekly status meeting and updating it when changes occur). The stem’s evidence—blank risk owners, an 8-week-old register, and no risk review agenda—explains why constraints like compliance needs and API limits were discovered late and caused rework and missed milestones.
Key takeaway: late discoveries are often a monitoring/cadence and ownership failure, not just “unlucky surprises.”
Without planned identification, analysis, response owners, and a regular review cadence, risks emerge late and cause rework and missed milestones.
Topic: Project Life Cycle Phases
You are planning a SaaS CRM implementation with a fixed go-live date tied to a contract renewal. In the draft resource histogram, the only security engineer and the only data engineer are each allocated at 160% for three consecutive weeks due to parallel tasks (SSO integration, data migration, and security testing). The sponsor confirms that several “nice-to-have” reports can be delivered after go-live, and the project has a small contingency budget available.
Which TWO actions should the project manager take to address the capacity constraint during planning? (Select TWO)
Correct answers: A, E
What this tests: Project Life Cycle Phases
Explanation: A planning-time capacity constraint is best addressed by either reducing the work those constrained resources must do or increasing available capacity with qualified staffing. Phasing lower-priority deliverables protects the fixed go-live date, and staff augmentation directly resolves overallocation in the resource plan. Together, these actions make the schedule and assignments achievable.
Resource planning requires matching work to available capacity and resolving overallocations before execution. With a fixed go-live date, the project manager should use two primary levers: prioritize work (reduce or phase scope so constrained roles have fewer tasks during the peak period) and adjust staffing (add qualified temporary resources, contractors, or shared services and then update the resource assignments). These actions directly reduce the 160% allocation to a feasible level while maintaining required deliverables for go-live.
Options that only change sequencing (like parallelizing more work) don’t create capacity, and options that depend on unsustainable effort (overtime) increase risk. If the date is contractually fixed, simply pushing the milestone is not an acceptable planning response without sponsor approval and broader change control.
Deferring lower-priority scope frees constrained resources while preserving the fixed go-live date.
Adding qualified resources reduces overallocation and makes the plan feasible without relying on unrealistic effort.
Topic: Project Life Cycle Phases
You are initiating an IT project to implement a company-wide password manager SaaS. The sponsor asks you to validate the draft project brief below to ensure it clearly defines the project’s goals, deliverables, and success criteria before approval.
Project brief (draft)
Business need: Reduce password-related help-desk tickets and improve account security.
Goal (draft): "Improve credential management for all employees this quarter."
Constraints: Must integrate with SSO; no disruption to production logins.
Assumptions: HR will provide the employee roster.
Out of scope: Replacing the identity provider.
Which TWO updates should you make to the project brief to meet the sponsor’s request? (Select TWO)
Correct answers: A, E
What this tests: Project Life Cycle Phases
Explanation: A project charter/brief must clearly state what the project will produce and how success will be measured. In the draft, the goal is vague and there are no stated deliverables or objective criteria to confirm the project achieved the intended outcome. Adding high-level deliverables and measurable success criteria addresses the sponsor’s request directly.
During project initiation, the project charter/project brief should be specific enough to align stakeholders on why the project exists, what it will deliver, and how “done” will be judged. In the draft, the business need is clear, but the goal is not measurable and there is no explicit deliverables list.
Update the brief by:
Detailed planning artifacts like a WBS, baselined schedule, or agile backlog come after approval and are not substitutes for deliverables and success criteria in the charter/brief.
A charter/brief should state what will be produced (major outputs), not just the business need.
Success criteria make the goal verifiable (for example, target adoption and ticket reduction).
Topic: Project Life Cycle Phases
You are initiating a company-wide SaaS HR system implementation. The project team is split across HR, IT, Security, and Legal, and each department head has been giving conflicting direction on requirements and approvals.
Because the team is distributed and decisions are stalling, which initiation artifact best establishes who the sponsor is and defines decision-making authority and escalation paths?
Best answer: C
What this tests: Project Life Cycle Phases
Explanation: When multiple leaders provide conflicting direction, the project needs formal governance before work proceeds. A project charter is the initiation document that identifies the sponsor and establishes decision authority and escalation paths so the team knows who can approve, who can break ties, and how unresolved decisions are escalated.
In project initiation, the project charter is the primary mechanism to formally authorize the project and define governance. In this scenario, the decisive problem is stalled, conflicting decisions across departments; the fix is to document who has decision rights and how disagreements are escalated.
A well-formed charter (or attached governance/escalation section) typically clarifies:
Other artifacts can support collaboration, but they do not formally establish authority the way a sponsor-approved charter does.
A project charter formalizes the sponsor’s authority and sets clear governance and escalation so decisions don’t stall.
Topic: Project Life Cycle Phases
You are initiating a project to implement a new SaaS CRM for the sales team. Several stakeholders have already mentioned “nice-to-have” items (data warehouse integration, mobile app customization, and new lead-scoring rules) that are not part of the initial funding request.
To prevent misunderstandings later, which artifact is the best evidence that the initial scope statement—including key exclusions—has been agreed to?
Best answer: B
What this tests: Project Life Cycle Phases
Explanation: The strongest validation at initiation is a scope statement that explicitly documents what is in scope and what is excluded, and is formally approved by the sponsor/key stakeholders. That approval provides objective evidence of shared expectations and reduces later disputes about “assumed” deliverables.
During project initiation, the purpose of the initial scope statement is to create shared understanding of what the project will deliver and, just as importantly, what it will not deliver. The most defensible evidence that exclusions were agreed to is a scope statement (or project brief/charter attachment) that explicitly lists out-of-scope items and has documented approval (sign-off) from the sponsor and required stakeholders. Notes, plans, and risk documents can support the conversation, but they do not validate acceptance of exclusions because they are not the authoritative agreement on scope boundaries. The key takeaway is that exclusions must be written into the scope statement and formally approved to prevent later misunderstandings and uncontrolled expansion.
A formally approved scope statement with clear exclusions is the strongest validation that stakeholders agreed on what will not be delivered.
Topic: Project Life Cycle Phases
A project team is in the execution phase of a migration to a new identity provider. Several integration problems have surfaced across multiple application teams, and the sponsor is concerned that risks and issues are being discussed but not actively driven to closure.
Which artifact would BEST validate that risks/issues are being monitored and that owners are accountable for next actions?
Best answer: A
What this tests: Project Life Cycle Phases
Explanation: To validate active monitoring and response, you need evidence that each risk/issue has an owner and a documented follow-up plan. A current RAID log (or risk register + issue log) shows status changes over time, next actions, and due dates, which demonstrates accountability and that items are being driven to resolution.
In project execution, “monitor and respond” means risks and issues are continuously tracked, assigned, updated, and escalated as needed. The best validating evidence is a current RAID log (or separate risk register and issue log) because it ties each item to an accountable owner and shows control information that proves active management, such as last updated date, current status, next action, and target/due date.
This artifact supports governance by making it easy to verify:
Narratives, minutes, and progress dashboards can be useful communications, but they do not consistently prove ownership and ongoing disposition of each risk/issue.
A maintained RAID log provides direct evidence of active tracking, ownership, and timely follow-up on risks and issues.
Topic: Project Life Cycle Phases
You are executing an IAM (identity and access management) rollout for a SaaS application. User acceptance testing is blocked because the security team has not approved the required SSO configuration change, and their current queue is 10 business days.
Constraints:
What should you do NEXT to best facilitate a timely decision and remove the blocker while meeting the constraints?
Best answer: A
What this tests: Project Life Cycle Phases
Explanation: The blocker is a required approval with a fixed deadline and a policy constraint that prevents bypassing security. The best optimization is to use the predefined escalation path, providing decision-ready information (impact and options) so the appropriate authorities can prioritize and decide quickly.
During execution, a key PM responsibility is to remove impediments and drive timely decisions using established governance. Here, the work cannot legally or procedurally proceed without security approval, and waiting would likely miss a fixed contractual go-live. The most effective next step is to formally capture the blocker (issue/RAID), quantify schedule impact, propose viable options (e.g., expedited review, temporary approved configuration, adjusted sequencing), and escalate according to the escalation matrix.
Escalation is appropriate when:
By escalating with clear impacts and options, you increase the chance of an expedited decision while staying compliant and avoiding unmanaged scope or risk.
This follows the defined escalation path to obtain a timely decision without violating policy or changing scope unilaterally.
Topic: Project Life Cycle Phases
You have been asked to lead an IT project to migrate the company’s internal wiki from an on-prem server to a SaaS platform. The sponsor wants you to “start next week” and asks you to schedule a kickoff meeting with IT, Security, and Operations.
You have not received a project charter or written authorization, and it is unclear who has approval to commit staff time and budget.
What should you obtain or verify FIRST before finalizing the kickoff and beginning work?
Best answer: B
What this tests: Project Life Cycle Phases
Explanation: Before scheduling a kickoff and initiating work, you need formal authorization that defines sponsorship and grants authority to proceed. A signed charter (or equivalent authorization) confirms the project exists, identifies the sponsor, and enables committing resources and budget. Without it, a kickoff risks misalignment and unauthorized commitments.
In project initiation, the key gate to “start” is formal authorization (often a project charter or project brief approved by the sponsor). This document confirms the business need, high-level scope, sponsor, and the project manager’s authority to use organizational resources. With that authorization in place, a kickoff can effectively align stakeholders on goals, roles, and next steps because participants know the project is approved and who can make decisions.
Planning artifacts like a WBS, vendor schedules, and a complete risk register are typically developed after authorization, using the charter as the foundation. If you begin coordinating work without formal approval, you may create conflicting expectations, spend unapproved funds, or pull people into meetings they are not authorized to support.
Formal authorization establishes the project manager’s authority and confirms sponsorship before committing resources and running kickoff.
Topic: Project Life Cycle Phases
You are preparing the baseline schedule for an IT network cutover project. The sponsor wants a committed go-live date, but the team has concerns about uncertainty.
Exhibit: Draft schedule excerpt
ID Activity Dur Predecessor(s) Uncertainty
1 Requirements sign-off 2d - Low
2 ISP circuit provision 10d 1 High
3 Firewall staging/config 4d 1 Medium
4 Integration testing 3d 2,3 Medium
5 Production cutover 1d 4 Low
Which action best incorporates appropriate buffer/contingency before baselining this schedule?
Best answer: B
What this tests: Project Life Cycle Phases
Explanation: Before setting a baseline, the schedule should reflect realistic reserves where uncertainty could impact committed dates. The ISP circuit provision has high uncertainty and is a predecessor to integration testing, making it the best place to add a visible schedule reserve. Once updated, the schedule can be approved and baselined for tracking variance.
A baseline schedule is the approved version of planned start/finish dates used to measure performance and manage changes. When building it, add contingency (schedule reserve) where variability is most likely to affect delivery—especially on or feeding into the critical path.
In the exhibit, integration testing cannot start until both the ISP circuit and firewall staging are complete, and the ISP task has high uncertainty and is the longer predecessor. Adding an explicit buffer between circuit provision and testing makes the contingency visible, allows stakeholders to agree to the trade-off (date vs. risk), and provides a controlled reserve that can be managed through change control if consumed. Padding every task hides the reserve, and adding buffer after cutover does not protect the go-live commitment.
The high-uncertainty vendor activity is on the critical path and gates testing, so a visible buffer there protects the committed dates before baselining.
Use the Project+ Practice Test page for the full PM Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.
Use the full PM Mastery practice page above for the latest review links and practice route.