Free Project+ Full-Length Practice Exam: 90 Questions

This free full-length Project+ practice exam includes 90 original PM Mastery questions across the exam domains.

The questions are original PM Mastery practice questions aligned to the exam outline. They are not official exam questions and are not copied from any exam sponsor.

Count note: this page uses the full-length practice count maintained in the Mastery exam catalog. Some exam sponsors publish total questions, scored questions, duration, or unscored/pretest-item rules differently; always confirm exam-day rules with the sponsor.

Exam snapshot

Full-length exam mix

Practice questions

Questions 1-25

Question 1

Topic: Project Management Concepts

A project manager is creating a deliverables checklist for a SaaS email migration project. The checklist maps common deliverables to each project phase for governance reviews.

Which deliverable is NOT typically produced during the closing phase?

• A. Complete handover and transition to operations
• B. Draft the project charter and initial risk register
• C. Secure final customer acceptance and sign-off
• D. Archive project documents and record lessons learned

Best answer: B

What this tests: Project Management Concepts

Explanation: Closing focuses on formally completing the project and transitioning ownership. Typical closing deliverables include final acceptance, handover to operations, and capturing/archiving project records such as lessons learned. Creating the charter and initial risk artifacts belongs at the start of the project, during initiation.

Project phases are associated with distinct deliverables that support governance and control. During closing, the team confirms the work is complete, obtains formal acceptance, transitions the solution to operations/support, and captures administrative wrap-up items (for example, archiving documents and documenting lessons learned). A project charter and an initial risk register are created early to authorize the project and establish initial alignment and uncertainty, which is why they are initiation deliverables rather than closing outputs. The key takeaway is that closing is about acceptance and transition, not authorizing the project or starting the risk process.

A charter and initial risk identification are initiation outputs, not closing deliverables.

Question 2

Topic: Project Management Concepts

You are coordinating a company-wide MFA rollout. Key stakeholders are globally distributed across time zones and cannot attend a weekly meeting. The CIO asks for a weekly update that can be read quickly on a phone and must clearly show progress since last week, current risks/issues, and what happens next week.

Which is the BEST communication artifact to send each week?

• A. A one-page project status report with RAG, accomplishments, risks/issues, and next steps
• B. The RAID log exported from the tracking tool
• C. The full project schedule (Gantt chart) exported to PDF
• D. Weekly meeting minutes with detailed discussion notes

Best answer: A

What this tests: Project Management Concepts

Explanation: A one-page project status report is purpose-built to provide an at-a-glance, repeatable update for stakeholders who need information asynchronously. It concisely combines progress (what was completed), current risks/issues requiring attention, and near-term next steps. This matches the CIO’s “quick mobile read” requirement better than detailed logs or schedules.

The core concept is choosing the right communication artifact for the audience and constraint. With globally distributed stakeholders and no shared meeting time, the update must work asynchronously and be quickly consumable. A weekly project status report (often a one-pager or dashboard) is designed to summarize: progress since the last update, current risks/issues and impacts, and next-period planned work and needed actions/decisions.

A good weekly status report typically includes:

• Current overall status (often RAG)
• Key accomplishments and milestones reached
• Top risks/issues (with owners and requested help)
• Next steps for the upcoming period

Detailed artifacts (like schedules, logs, or minutes) can be linked for drill-down, but they are not the primary concise status update.

A concise status report is designed to summarize progress, highlight key risks/issues, and state upcoming work for asynchronous stakeholders.

Question 3

Topic: Project Management Concepts

A project team is delivering a customer portal using 2-week sprints, but the project manager added a “requirements sign-off” meeting and a CAB-style approval at the end of every sprint. The team is often idle waiting for approvals, and stakeholders complain that delivery flow is inconsistent.

Before deciding how to adjust the hybrid approach, what should the project manager verify FIRST?

• A. Whether additional developers can be added to the team
• B. Whether the schedule baseline should be reapproved by the sponsor
• C. The team’s average velocity over the last three sprints
• D. Which changes actually require formal governance approval

Best answer: D

What this tests: Project Management Concepts

Explanation: This scenario suggests a hybrid anti-pattern: inserting heavyweight stage-gate controls into each sprint, creating queues and blocking flow. The first step is to clarify which approvals are truly required (and when), so the team can align governance to releases or risk levels instead of gating routine sprint work.

A common anti-pattern in mixed agile/predictive approaches is applying predictive “phase gate” approvals at a sprint cadence, which creates handoffs, waiting, and stop-start delivery. To correct it while preserving flow, you first need to understand the real constraints: what governance, audit, or operational controls are mandatory, and whether they apply to all work or only to certain change types (for example, production releases vs. backlog refinement).

Once approval requirements are clarified, the project can redesign the workflow (e.g., keep sprint planning and execution uninterrupted, and align CAB/sign-off to release events or defined risk thresholds). Without validating approval obligations first, you risk removing a required control or optimizing the wrong bottleneck.

You must confirm mandatory approval constraints before removing gates or redesigning the workflow to keep delivery moving.

Question 4

Topic: Project Tools and Documentation

You are planning performance testing for a customer-facing SaaS rollout. A post-go-live performance incident would trigger SLA credits and emergency remediation totaling $200,000. Your objective is to select the option with the lowest expected total cost (testing cost + expected incident cost), while meeting both constraints: testing must be completed within 4 weeks and the testing budget cannot exceed $60,000.

Exhibit: Decision tree inputs (USD)

Which option should the project manager recommend?

• A. Comprehensive performance program
• B. No formal performance testing
• C. Basic smoke + small load test
• D. Full load + tuning cycle

Best answer: D

What this tests: Project Tools and Documentation

Explanation: This is a decision-tree expected value choice: add the up-front testing cost to the probability-weighted incident impact for each feasible option. The comprehensive program is infeasible due to both time and budget constraints. Among the remaining options, the full load plus tuning cycle produces the lowest expected total cost.

A decision tree compares alternatives by calculating expected monetary value (EMV) at each chance outcome, then adding any fixed up-front cost. Here, each option has one chance outcome (incident vs. no incident) with a stated probability and a single impact cost, so EMV is straightforward.

1. Eliminate any option that violates constraints (over $60,000 or over 4 weeks).
2. For each remaining option, compute:

Using the exhibit, the feasible options’ expected totals are $70,000 (basic), $65,000 (full load + tuning), and $75,000 (no testing), so the full load + tuning cycle is the best optimization under the stated constraints.

It meets the time and budget constraints and yields the lowest expected total cost: $45,000 + (10% \(\times\) $200,000) = $65,000.

Question 5

Topic: Project Life Cycle Phases

A project team is in the discovery phase for implementing a new SaaS CRM. To meet a tight deadline, the project manager decides to defer defining success criteria and measurable KPIs, planning to “figure out reporting later.” The team moves into requirements workshops with multiple departments.

What is the most likely near-term impact of this decision?

• A. Inability to calculate EVM performance indexes accurately
• B. More production defects after go-live
• C. Higher chance of vendor change orders late in the project
• D. More disagreement during requirements validation and sign-off

Best answer: D

What this tests: Project Life Cycle Phases

Explanation: Defining success criteria and candidate KPIs in discovery creates a shared, measurable definition of “done” and “value.” If these are deferred, stakeholders enter requirements validation without objective measures to judge whether needs are met. The near-term result is misalignment and slower approvals as teams debate what the solution must accomplish.

Success criteria and KPIs translate desired outcomes (for example, adoption, cycle-time reduction, data quality) into measurable targets that stakeholders can use to validate requirements and later accept deliverables. In discovery, this artifact aligns departments on what matters most and reduces ambiguity during requirements workshops.

When success criteria/KPIs are deferred:

• Stakeholders lack objective acceptance measures
• Requirements discussions drift toward preferences vs. outcomes
• Sign-off is delayed while expectations are reconciled

The most immediate consequence is stakeholder misalignment during requirements validation; cost, quality, and contract impacts are possible later but are not the near-term effect.

Without agreed success criteria and KPIs, stakeholders lack a shared basis to confirm requirements meet the intended outcomes.

Question 6

Topic: Project Tools and Documentation

You are coordinating an identity management project to integrate a new SaaS application with SSO. The work includes vendor-side configuration, firewall rule changes, DNS updates, certificate procurement, and user acceptance testing.

Several tasks can run in parallel, but others are blocked by vendor deliverables. Leadership wants a simple visual that clarifies task dependencies and helps identify what work is on the critical path for the go-live date.

Which tool/artifact should you create?

• A. Network diagram (dependency diagram)
• B. Gantt chart
• C. RACI matrix
• D. Swimlane flowchart

Best answer: A

What this tests: Project Tools and Documentation

Explanation: Because the main challenge is understanding dependency logic and vendor blockers, a network diagram is the best fit. It shows predecessor/successor relationships and makes the critical path visible so the team can see which delays will push the go-live milestone.

Use a network diagram when the primary need is to clarify sequencing and dependencies across many tasks—especially when vendor deliverables create hard blockers. By mapping each activity with its predecessors and successors, you can see which tasks can proceed in parallel and which must wait, then identify the critical path (the chain of dependent activities that determines the earliest possible finish date). This directly answers leadership’s question about what will actually delay go-live.

A schedule view like a Gantt chart is useful for tracking dates, but it often doesn’t communicate dependency logic as clearly as a dedicated network diagram when the deciding factor is dependency management.

A network diagram best visualizes task dependencies and highlights the critical path that drives the go-live date.

Question 7

Topic: Project Management Concepts

A project is implementing a new SaaS CRM and must complete a data migration and performance testing before a fixed go-live date in 8 weeks. The only DBA is allocated 80% to production operations during the same period, and the schedule shows the DBA assigned to both migration support and performance test environment setup on the critical path.

The sponsor confirms the budget cannot increase, but some CRM custom reports are “nice to have” for day-one.

Which TWO actions should the project manager take to address the resource constraint? (Select TWO.)

• A. Require the DBA to work overtime until both tasks are completed
• B. Reassign the performance test database setup to an available secondary DBA and update the schedule
• C. Purchase vendor DBA support services to cover the shortfall
• D. Move the go-live date by 2 weeks to match the DBA’s availability
• E. Submit a change request to defer the optional custom reports to a later release
• F. Continue with the plan and revisit resourcing after performance testing starts

Correct answers: B, E

What this tests: Project Management Concepts

Explanation: This scenario shows a single constrained specialist assigned to multiple critical-path tasks with no budget available to add paid resources. The best response is to reduce demand on the constrained resource by negotiating scope and to relieve the bottleneck by reassigning eligible work to another available resource while updating the plan.

The core concept is identifying a resource constraint (a scarce, overallocated specialist) and choosing practical adjustments that fit stated constraints. Here, the DBA is a bottleneck on the critical path, and the sponsor has ruled out increasing budget, so the project manager should focus on actions that either reduce required effort or redistribute work.

Effective adjustments include:

• Negotiate scope trade-offs (defer “nice-to-have” deliverables) through change control
• Reassign or split tasks to other qualified/available resources and update the schedule/RACI

Options that rely on unstated authority (buying vendor services), delay action, or shift the deadline without sponsor agreement don’t address the constraint appropriately. The key takeaway is to manage the constraint with scope and assignment changes that align to the project’s approved limits.

Reducing noncritical scope lowers the constrained DBA workload without requiring additional budget.

Redistributing work away from the constrained resource relieves the critical-path bottleneck.

Question 8

Topic: Basics of IT and Governance

A project team implemented an approved change to replace the company’s VPN gateway. The change record shows the implementation steps, but the “validation/closure” section is blank. After cutover, users report intermittent access; the team applies several configuration tweaks without submitting new change requests. The CAB keeps the change open because no one can confirm whether the change met its goals, and multiple retests are delaying the next milestone.

Which is the MOST likely underlying cause?

• A. Too many user tickets were logged after the cutover
• B. The network engineers lack expertise with VPN technologies
• C. The maintenance window was too short to complete the implementation
• D. Post-change success criteria and evidence collection were not defined or enforced

Best answer: D

What this tests: Basics of IT and Governance

Explanation: The clues point to a breakdown in post-implementation verification and closure: the validation section is blank, the CAB cannot confirm completion, and repeated tweaks occur outside change control. Defining measurable post-change success criteria and capturing verification evidence are required to close a change and demonstrate stability. Without that governance step, ownership is unclear and rework increases.

In change control, a change is not “done” when the implementation steps finish; it is done when post-change success criteria are validated and evidence is recorded (for example, test results, monitoring checks, and stakeholder acceptance). Here, the change record lacks a completed validation/closure section, and the CAB cannot determine whether objectives were met. That gap leads to unclear ownership for verification, repeated retesting, and engineers making follow-up tweaks outside the process to chase stability.

A solid fix is to require, for each change, documented success criteria (what will be true if the change is successful), named validation owners, and captured proof of completion/stability before closure and before making additional adjustments.

Other explanations focus on implementation difficulty, but the core failure is the missing post-change validation and evidence trail.

Without documented success criteria, assigned validation ownership, and captured test evidence, the team cannot prove stability and resorts to uncontrolled rework.

Question 9

Topic: Basics of IT and Governance

A project team is implementing a customer-support chatbot that will store EU customers’ chat transcripts and email addresses in a cloud database. The privacy officer warns that GDPR requirements (data minimization, retention limits, and deletion on request) must be met, and a previous project had significant rework because developers learned the constraints late.

Which is the BEST way for the project manager to communicate these compliance constraints clearly to the team and stakeholders to prevent rework?

• A. Document compliance requirements as acceptance criteria and review them at kickoff
• B. Add GDPR as a risk item and monitor it during status meetings
• C. Update the RACI so the privacy officer is accountable for GDPR
• D. Attach the cloud provider’s SOC 2 report to the project charter

Best answer: A

What this tests: Basics of IT and Governance

Explanation: To prevent rework, compliance constraints must be translated into clear, testable requirements that the team builds and verifies against. Capturing GDPR obligations as acceptance criteria (and reviewing them at kickoff) ensures shared understanding and makes compliance part of design, development, and testing from the start. This aligns stakeholders on what “done” means before work begins.

The core need is early, unambiguous communication of compliance constraints so the team can design and build correctly the first time. The most effective way is to express GDPR obligations as specific, testable requirements (for example, retention period, deletion workflow, data minimization fields) and embed them where work is planned and accepted—such as acceptance criteria for features and deliverables—then review them with stakeholders at kickoff to confirm understanding.

This approach prevents rework because it:

• Turns policy language into buildable/verifiable criteria
• Creates a shared baseline for design, development, and testing
• Provides a clear approval point before implementation starts

Tracking GDPR only as a risk or documenting roles does not make the constraints actionable for implementation and verification.

Making compliance constraints explicit in accepted requirements (and reviewing them early) sets build/test expectations and prevents late redesign.

Question 10

Topic: Project Management Concepts

A project to implement a new ITSM SaaS tool has a committed go-live date. The sponsor requests schedule compression.

Exhibit: Change request summary (CR-07)

Requested change: Move go-live 2 weeks earlier
Budget impact: No additional funds approved
Resource constraint: No additional FTE/contractors available
Quality: Acceptance criteria unchanged
Sponsor note: Will accept higher rework/coordination risk

Which schedule compression technique should the project manager use?

• A. Crash the schedule by adding contractors to critical-path tasks
• B. Reduce scope by removing lower-priority features from the release
• C. Fast-track by overlapping normally sequential activities
• D. Extend the schedule baseline and negotiate a later go-live date

Best answer: C

What this tests: Project Management Concepts

Explanation: The exhibit shows the deadline must move earlier with no additional budget and no additional resources. That rules out crashing, which relies on adding resources (and typically cost) to shorten the critical path. Fast-tracking is the appropriate compression technique because it overlaps work while accepting increased coordination and rework risk, which the sponsor explicitly accepts.

Schedule compression is used to meet an earlier end date without changing project scope. Crashing shortens the schedule by adding resources to critical-path activities, which typically increases cost and may be impossible when staffing is constrained. Fast-tracking shortens the schedule by overlapping activities that were originally planned in sequence (for example, starting configuration and training development before all requirements are finalized), increasing the risk of rework.

In the exhibit, the sponsor needs the schedule reduced by 2 weeks, but additional funds and additional staff are not approved, and the sponsor explicitly accepts higher rework/coordination risk. Those constraints align directly to fast-tracking rather than crashing.

The key takeaway is to match the compression method to the limiting constraint: cost/resources constraints point to fast-tracking (with risk), while available budget/resources point to crashing.

Fast-tracking can shorten the schedule without adding budget or staff by overlapping work, accepting increased rework risk as noted.

Question 11

Topic: Project Tools and Documentation

You are tracking costs for a SaaS email migration project. The sponsor asks for a simple forecast assuming the team continues spending at the same rate as it has so far.

Exhibit: Cost tracker (to date)

The project is 50% complete.

Use these spreadsheet-style calculations:

• Total BAC = sum of all Budget values
• Total AC = sum of all Actual values
• EAC (estimate at completion) = Total AC / percent complete
• VAC (variance at completion) = Total BAC − EAC

Which TWO calculations are correct? (Select TWO.)

• A. VAC is $6,000
• B. EAC is $79,500
• C. VAC is -$6,000
• D. EAC is $81,000
• E. Total AC is $40,500
• F. Total BAC is $75,000

Correct answers: C, D

What this tests: Project Tools and Documentation

Explanation: Using the provided formulas, first sum the Actual cost to date and divide by percent complete to forecast the estimate at completion (EAC). Then compare that forecast to the total budget (BAC) to compute the variance at completion (VAC). These two values show whether the project is trending over or under budget if current spending continues.

This is a simple cost forecast and variance calculation using totals from a cost tracker. Start by summing the budgeted amounts to get total BAC, and summing the actuals to get total AC. Because the project is 50% complete and you’re told to assume the current spending rate continues, forecast the total cost as EAC = AC / % complete. Finally, compute how far off the project is expected to finish versus the original budget using VAC = BAC − EAC (negative means over budget).

Key takeaway: ensure you calculate totals first, then apply the percent-complete forecast, and interpret the sign of the variance correctly.

Total AC is $40,500 and at 50% complete, $40,500 / 0.50 = $81,000.

Total BAC is $75,000 and VAC = $75,000 − $81,000 = -$6,000 (a $6,000 overrun).

Question 12

Topic: Basics of IT and Governance

You are coordinating a go-live for a new internal HR SaaS portal that will use SSO and be accessed at hr.company.com over HTTPS. The vendor says the application is ready, and leadership wants you to commit to a cutover date this week.

What should you verify or ask for FIRST before finalizing the go-live date?

• A. The vendor’s next release date and feature roadmap
• B. A detailed end-user training plan and communications schedule
• C. A revised cost estimate for year-two licensing and renewals
• D. Owners and lead times for SSO, DNS, certificates, and firewall changes

Best answer: D

What this tests: Basics of IT and Governance

Explanation: Before committing to a cutover date, you need to confirm whether critical access and connectivity prerequisites are ready and scheduled. SSO configuration, DNS changes, certificate issuance, and network/firewall rules commonly require separate teams and approvals, creating lead time and schedule risk. Verifying ownership and timelines for these dependencies prevents avoidable go-live blockers.

The core concept is dependency readiness: IT projects often rely on networking, identity, DNS, and certificate work that is outside the delivery team’s direct control. Even if the vendor application is “ready,” go-live can fail if SSO (SAML/OIDC) isn’t configured, DNS records aren’t created/propagated, TLS certificates aren’t issued/installed, or firewall/proxy rules aren’t implemented and tested.

Before setting a cutover date, confirm:

• Which dependencies are required for production access
• Who owns each dependency (IAM, network, DNS, security)
• Approval paths and lead times (CAB/change window, certificate issuance)
• Target dates and validation/testing plans

The key takeaway is that validating these prerequisites first reduces the highest-probability schedule and operational risks for an HTTPS, SSO-enabled custom domain go-live.

These common IT dependencies often have external approvals/lead times that drive schedule risk and can block go-live.

Question 13

Topic: Project Management Concepts

You are coordinating a SaaS CRM rollout. During UAT, testers cannot access the vendor’s staging environment because single sign-on (SSO) authentication is failing. The pilot go-live is in 5 business days, and UAT completion is on the critical path.

Which issue statement is best to enter in the issue log to optimize clarity and next-step execution (include impact, owner, and next action)?

• A. Issue: SSO login to vendor staging fails for all UAT testers, blocking UAT completion and threatening the pilot go-live in 5 business days. Impact: UAT paused; schedule at risk. Owner: IAM lead. Next action: Open Sev-2 ticket with vendor and schedule joint troubleshooting by end of day today.
• B. Issue: UAT access issue. Impact: Testers are annoyed and productivity is lower. Owner: QA team. Next action: Escalate to management and consider pushing the go-live date.
• C. Issue: Vendor staging is down and the CRM project may slip. Next action: Ask the team to investigate immediately.
• D. Issue: SSO might fail during go-live if the vendor’s certificate is misconfigured. Impact: Potential access problems. Owner: Project manager. Next action: Add this to the risk register.

Best answer: A

What this tests: Project Management Concepts

Explanation: A strong issue statement captures the current problem (not a future risk), the measurable impact to scope/schedule/cost/quality, a single accountable owner, and a concrete next action. The best option ties the SSO failure directly to blocked UAT on the critical path, assigns ownership to the appropriate functional lead, and specifies an immediate escalation step with a deadline.

Issue management depends on writing issues so they can be owned, prioritized, and resolved quickly. An effective issue statement is present-tense and specific (what is happening and where), includes the impact (especially to the critical path or operational risk), names one accountable owner, and defines the next action as a concrete step that can be tracked.

In this scenario, the SSO failure is already occurring and is blocking UAT, so it belongs in the issue log (not as a risk). Because UAT completion is on the critical path and go-live is near, the next action should be immediately executable (for example, a vendor ticket and scheduled troubleshooting) and timeboxed. Assigning the owner to the functional group best positioned to drive resolution improves speed and accountability.

It clearly states the current problem, impact to critical path, a single accountable owner, and an actionable next step with a timebox.

Question 14

Topic: Project Tools and Documentation

After a weekly status meeting for a SaaS rollout, the project coordinator is responsible for publishing meeting notes that enable follow-through. Which approach should the coordinator AVOID when documenting action items?

• A. Assigning action items to named owners with target dates
• B. Recording action items without an owner or due date
• C. Capturing key decisions and the rationale behind them
• D. Publishing the notes in a shared location and sending a recap

Best answer: B

What this tests: Project Tools and Documentation

Explanation: Meeting notes that support follow-through must make work trackable and accountable. Action items should be written so anyone can see what will be done, who owns it, and by when. Omitting owners or due dates turns action items into vague reminders that cannot be effectively managed.

To support follow-through, meeting notes should translate discussion into trackable outputs: decisions, action items, owners, and dates. An action item is only useful if it is unambiguous and assignable; otherwise it cannot be monitored, escalated, or reported in the next status cycle.

A practical action item format is:

• Task (what)
• Owner (who)
• Due date (when)
• Any dependency or needed input (if applicable)

Capturing decisions with rationale and distributing notes from a shared source improves alignment and reduces rework, but leaving action items without ownership or timing undermines execution and accountability.

Without clear ownership and target dates, action items are hard to track and rarely get completed.

Question 15

Topic: Project Management Concepts

A Scrum team is starting a two-week sprint for an internal ITSM portal upgrade. The product owner brings a backlog where most user stories have unclear priority, no acceptance criteria, and the team has not agreed on a Definition of Done. The product owner says the details can be clarified “as questions come up” during the sprint.

What is the most likely near-term impact of proceeding this way?

• A. A higher chance of uncontrolled scope changes in later releases
• B. Slower sprint planning and rework from misunderstood stories
• C. Faster delivery because the team has more flexibility
• D. UAT will fail at the end of the project due to defects

Best answer: B

What this tests: Project Management Concepts

Explanation: A good backlog enables the team to select the right work and build it correctly the first time. Missing priority, acceptance criteria, and a shared Definition of Done forces assumptions and extra clarification during execution. The near-term result is sprint planning friction and rework within the current sprint, which immediately threatens schedule and quality.

In agile, a “good” backlog/requirements set is ready enough for the team to plan and deliver: items are prioritized, each selected story has clear acceptance criteria, and the team shares a Definition of Done to prevent hidden work (testing, documentation, reviews) from being skipped. If the team proceeds with vague, unprioritized stories and no acceptance criteria/DoD, the immediate effect is confusion during sprint planning and then rework during the sprint as requirements are reinterpreted or changed. This shows up quickly as missed commitments, churn in scope within the sprint, and quality gaps from inconsistent completion standards. The key takeaway is that readiness reduces immediate execution risk; “we’ll clarify later” usually creates near-term delays and rework.

Without prioritization, acceptance criteria, and DoD, the team will make assumptions, causing planning churn and immediate rework.

Question 16

Topic: Basics of IT and Governance

You are the project coordinator for a customer-support SaaS rollout. The vendor’s default production environment is in the United States, but the project will load customer records that include EU residents’ names, emails, and support history. Your company policy states that personal data may be transferred cross-border only with an approved legal mechanism and documented guidance from the privacy/legal team.

Go-live is in 6 weeks, and the migration build is scheduled to start next week.

Which action best optimizes the schedule while meeting the compliance constraint?

• A. Ask the vendor to sign an NDA and begin loading the EU customer data
• B. Cancel the vendor selection and restart procurement for an EU-only provider
• C. Escalate to privacy/legal now to confirm transfer requirements and approved safeguards before starting the migration build
• D. Proceed with the U.S. environment and capture the risk for later remediation

Best answer: C

What this tests: Basics of IT and Governance

Explanation: This scenario triggers cross-border data transfer restrictions because EU personal data will be stored/processed outside the EU. The optimal move is to escalate immediately to privacy/legal to determine the approved transfer mechanism and required documentation before any data is loaded. Doing this before the build starts protects the schedule by preventing rework and avoiding a policy violation.

When a project involves moving or storing regulated personal data across borders (for example, EU resident data going to a U.S.-hosted SaaS), data transfer restrictions become a hard constraint, not just a technical preference. The project team should escalate early to the privacy/legal function (often via a DPO or compliance office) to confirm what is allowed and what safeguards and documents are required (such as a DPA, approved transfer mechanism, and any required assessments). Escalating before the migration build starts minimizes schedule risk because it prevents loading data into an unapproved environment and avoids costly rework or a compliance incident. The key takeaway is to treat cross-border transfers as a governance decision requiring formal guidance, not an implementation detail.

Cross-border transfer restrictions are a compliance constraint, so escalating early enables an approved path (or alternative hosting) without rework or unapproved data movement.

Question 17

Topic: Project Life Cycle Phases

A project is in the planning-to-execution transition for a SaaS CRM rollout with three integrations. After two weeks, the first integration milestone is missed, defects are being reworked, and tasks are repeatedly handed off with no clear owner. Several change requests are also being implemented “as time allows” without schedule impacts being assessed. The status report shows the same two integration engineers are assigned to all three integrations while also covering production support.

Which of the following is the MOST likely underlying cause?

• A. Resource capacity was not validated, causing critical resource over-allocation
• B. Requirements were not baselined, leading to frequent rework
• C. The team is not reporting status frequently enough
• D. Stakeholders are submitting too many change requests

Best answer: A

What this tests: Project Life Cycle Phases

Explanation: The symptoms point to a capacity constraint on critical resources: the same specialists are assigned across multiple integration workstreams while also handling operational duties. That over-allocation drives missed milestones, handoffs to “whoever is free,” and rushed rework. Unassessed “as time allows” changes are also typical when capacity and prioritization are not controlled.

The core issue is inadequate resource planning: assignments were made without confirming actual availability and competing operational commitments. When a few specialized resources are over-allocated, work queues up behind them, ownership becomes informal (tasks get reassigned based on who has time), and quality drops due to rushed context switching and partial handoffs. Uncontrolled changes often follow because the team tries to absorb new requests without formally rebalancing scope, schedule, or staffing.

To address this in planning, the project should validate capacity (including non-project work), prioritize work across integrations, and then level resources by reassigning tasks, adjusting the schedule, or adding/augmenting staff before committing to milestones. The closest traps describe outcomes (rework, many changes) rather than the underlying capacity constraint.

Key specialists are double-booked across work and support, leading to missed dates and ad hoc ownership.

Question 18

Topic: Project Management Concepts

A project team has completed UAT for a new single sign-on (SSO) integration for a SaaS app. All exit criteria in the test plan passed, and the vendor is requesting confirmation to release the production configuration. The go-live change window is in 5 business days, and the security lead (final approver) will be out of office starting tomorrow. Governance requires documented stakeholder acceptance before production changes.

What is the BEST next action?

• A. Update the project schedule to show the deliverable complete and close the task
• B. Proceed with the production release since UAT exit criteria were met
• C. Schedule an acceptance walkthrough and obtain documented sign-off today
• D. Send a status email stating the deliverable is accepted unless objections arise

Best answer: C

What this tests: Project Management Concepts

Explanation: Even with successful UAT, the deliverable is not formally accepted until the required stakeholders approve it. The constraints include a mandatory governance sign-off and an approver who will be unavailable, so the project manager should immediately confirm acceptance and capture documented approval. This enables the vendor to proceed and supports an auditable release decision before the change window.

Deliverable acceptance is a formal quality control step: stakeholders verify the work meets defined acceptance criteria, and the project records that approval (sign-off) before moving to the next phase (for example, production release). In this scenario, testing passed, but governance explicitly requires documented acceptance, and the final approver is about to be out of office. The best next action is to complete an acceptance review with the approver and capture sign-off (such as an acceptance form, ticket approval, or approval recorded in the change request) so the release decision is authorized and traceable.

Key takeaway: completion of work and successful testing do not replace formal stakeholder acceptance when sign-off is required.

This confirms stakeholder acceptance against the agreed criteria and captures the required approval before the approver is unavailable.

Question 19

Topic: Project Management Concepts

A project team is implementing a new SaaS help desk system. In the last two weeks, several tasks “fell through the cracks,” and during standups no one volunteers to own follow-ups because the team avoids challenging each other. The project manager wants the most immediate improvement in ownership and accountability.

Which action will most likely have the best near-term impact?

• A. Create a RACI and assign one accountable owner per deliverable
• B. Add schedule buffer to accommodate delays from coordination problems
• C. Hold a team-building event to improve morale and collaboration
• D. Increase the frequency of status meetings and require weekly reports

Best answer: A

What this tests: Project Management Concepts

Explanation: The symptoms point to unclear ownership, low accountability, and conflict avoidance. Defining roles and making a single person accountable for each deliverable is the fastest way to prevent tasks from being unowned and to create clear expectations for follow-up. A RACI makes gaps and overlaps visible and actionable immediately.

This scenario shows common team dysfunctions: unclear ownership (tasks are unclaimed), low accountability (no one is responsible for follow-up), and conflict avoidance (team members won’t challenge gaps). The most effective near-term corrective action is to make responsibility explicit by defining roles and assigning a single accountable owner for each deliverable or work package.

A practical approach is to:

• Publish/confirm a RACI for key deliverables and decisions
• Assign one “A” (accountable) per deliverable and communicate it
• Use the RACI to drive follow-ups and escalation when ownership is unclear

Meeting more often or adding buffer may temporarily mask the problem, but they don’t correct the underlying lack of clear ownership.

Clarifying ownership and accountability immediately reduces work ambiguity and missed handoffs.

Question 20

Topic: Project Life Cycle Phases

You are initiating an identity management (SSO) rollout for a SaaS HR system. The sponsor requires production go-live no later than July 15. The operations team enforces a production change blackout from June 25–30 for quarter close, and the vendor cannot configure SSO until network security completes IP allowlisting.

Which proposed high-level milestone is INCORRECT to define based on these scheduling constraints?

• A. Confirm a CAB-approved change window before production cutover
• B. Complete go-live by July 15 per sponsor deadline
• C. Schedule production cutover for June 28
• D. Complete IP allowlisting before vendor SSO configuration starts

Best answer: C

What this tests: Project Life Cycle Phases

Explanation: High-level milestones in initiation must respect known schedule constraints such as hard deadlines, blackout windows, and dependencies. A milestone that schedules a critical production event during an approved blackout window is not feasible and should not be baselined. The other milestone statements align to the stated dependency and governance constraints while meeting the required deadline.

In project initiation, high-level milestones should be realistic checkpoints that reflect known constraints and dependencies so stakeholders can agree on a feasible timeline. A production change blackout window is a firm scheduling constraint; planning a cutover inside it creates an immediate conflict with operations governance and increases the likelihood of schedule churn.

Good milestone definitions at this level:

• Respect blackout/freeze windows for production changes.
• Sequence work based on dependencies (e.g., allowlisting before SSO configuration).
• Include required approvals/timeboxes (e.g., CAB/change window confirmation).
• Align to the sponsor’s deadline without violating constraints.

The key takeaway is to surface and honor constraints early so the initial milestone plan is credible.

It places the cutover inside the stated June 25–30 blackout window.

Question 21

Topic: Project Management Concepts

You are coordinating a network segmentation project. A critical vulnerability requires an emergency firewall rule change that could disrupt a customer-facing application. The approved maintenance window starts in 45 minutes, and the change manager requires documented CAB approval before implementation. The decision makers (security lead, network lead, change manager) are available now, but they are in different locations and need to ask clarifying questions due to the technical complexity.

What is the BEST next action to communicate this request?

• A. Add the item to the next weekly status meeting agenda
• B. Send a detailed email to the full project distribution list
• C. Post the plan in the team chat channel for asynchronous responses
• D. Start an immediate bridge call with CAB approvers and leads

Best answer: D

What this tests: Project Management Concepts

Explanation: This situation is urgent (45-minute window), complex (risk of application impact), and requires a decision from specific approvers (CAB roles). A synchronous method that supports immediate Q&A is the most effective way to reach the right audience and obtain timely approval. Documentation can be captured during/after the call, but the immediate need is rapid alignment and authorization.

Choose the communication method by matching urgency, complexity, and audience. When a decision is needed quickly and the topic is technically complex, synchronous communication (bridge call/video call) is typically best because it enables immediate questions, shared understanding, and a clear decision in the moment. In this scenario, the audience is a small set of specific approvers (security lead, network lead, change manager) and the dependency is CAB approval before the maintenance window. A real-time bridge call aligns the right stakeholders quickly and supports rapid go/no-go authorization, with meeting notes serving as the documented approval record.

A live call is fastest for an urgent, complex decision and enables real-time CAB approval.

Question 22

Topic: Project Life Cycle Phases

You are planning a 10-week project to implement a SaaS HR onboarding system that will store employee PII. Legal requires a documented privacy impact assessment (DPIA) and security testing results approved before production cutover. The project has only $15,000 available for security/privacy work and cannot move the go-live date.

Which action best optimizes compliance and risk reduction while meeting the constraints?

• A. Add DPIA, vendor risk review, security tests, and approval gates to the WBS
• B. Commission a full third-party ISO 27001 certification audit before cutover
• C. Schedule the DPIA and security testing during post-go-live stabilization
• D. Rely on the vendor’s SOC 2 report instead of project security tasks

Best answer: A

What this tests: Project Life Cycle Phases

Explanation: The best approach is to explicitly plan security, privacy, and compliance work as project tasks with owners, estimates, and pre-cutover approval gates. This ensures the mandatory DPIA and security test approvals happen before production, avoiding last-minute delays and rework. It also supports risk-based prioritization within a fixed go-live date and limited budget.

In project planning, security, privacy, and compliance activities should be built into the work plan (WBS/schedule) as first-class deliverables with clear entry/exit criteria. In this scenario, the constraints are strict: DPIA and security testing approval must occur before production, and go-live cannot slip. The optimal plan is to add the required work as tasks and milestones now so dependencies (data flows, access model, test environments, vendor evidence, remediation time) are visible and can be managed.

Planning typically includes:

• Privacy/compliance tasks (data mapping, DPIA, required sign-offs)
• Security tasks (vendor assessment, configuration baselines, security test execution, remediation buffer)
• Governance gates (go/no-go criteria before cutover)

Deferring or substituting these activities increases the chance of a pre-cutover compliance stop, which is the highest-risk outcome under a fixed deadline.

This plans required compliance and security activities into the schedule with clear gates, reducing late rework while staying within fixed time/cost constraints.

Question 23

Topic: Project Tools and Documentation

A project team is distributed across three time zones and is implementing a new SaaS ticketing system. During the last two weeks, requirements have been re-explained multiple times in chat threads, and different team members are working from outdated notes. The project manager wants to reduce rework and improve alignment without changing scope.

What is the BEST next step?

• A. Replace the current tools with a new collaboration platform for the whole team
• B. Establish a single shared requirements workspace with version control and a clear update/decision process
• C. Begin configuration work now and capture changes as they are discovered
• D. Escalate to the sponsor to enforce accountability for missed understandings

Best answer: B

What this tests: Project Tools and Documentation

Explanation: Distributed teams need a consistent way to collaborate asynchronously and avoid fragmented information. Creating a single shared requirements workspace (with ownership, versioning, and a lightweight decision/update process) provides one source of truth that everyone can reference. This directly addresses outdated notes and repeated explanations while keeping the project moving.

The core collaboration practice for distributed teams is establishing a “single source of truth” for key project artifacts (requirements, decisions, action items) and defining how the team will use it. In this scenario, requirements are scattered across chats and personal notes, so the best next step is to centralize requirements in a shared document repository and set simple working agreements so updates are controlled and visible.

A practical next step includes:

• Create one shared requirements document/backlog and link it from a common project space
• Assign an owner and define how edits are made (review/approval and version history)
• Add a lightweight decision log and reference it from chat messages

This fixes the root cause (information fragmentation) before escalating or making disruptive tool changes.

A shared source of truth plus agreed collaboration norms prevents conflicting information and reduces rework for distributed teams.

Question 24

Topic: Project Life Cycle Phases

A project team is deploying a new SaaS ticketing system for the service desk. The organization is in a regulated industry, and an internal audit requires evidence that operational ownership, support escalation, and end-user/support training are in place before go-live in two weeks.

Which artifact should the project manager prioritize to plan the transition to operations and satisfy the audit requirement?

• A. Product backlog refinement session with operations participation
• B. Updated project charter naming operations as the project sponsor
• C. Operations handover checklist with support model and training sign-off
• D. Lessons learned register for post-project improvements

Best answer: C

What this tests: Project Life Cycle Phases

Explanation: Because the key discriminator is a compliance/audit requirement before go-live, the project needs a formal transition-to-operations artifact that proves readiness. An operations handover checklist (often including runbooks, escalation paths, and training records) documents ownership transfer and support expectations. This provides traceable evidence for operational acceptance and audit review.

Transition to operations focuses on making sure the operational team can support and own the solution after go-live. In a regulated environment, the decisive factor is auditability: you need documented proof that support responsibilities, escalation, and training are complete and accepted.

An operations handover/transition checklist is designed for this purpose and typically captures:

• Ownership and on-call/escalation paths
• Support model (tiers, SLAs/OLAs, vendor contacts)
• Required documentation (runbooks/KB articles)
• Training completion and operational acceptance/sign-off

This is more defensible for an audit than general project documents or agile ceremonies because it directly evidences operational readiness and ownership transfer.

A formal handover/transition checklist documents ownership, support processes, and training completion evidence needed for go-live approval.

Question 25

Topic: Project Life Cycle Phases

You are the project coordinator for a small project to implement a SaaS ticketing system. The project charter is approved, but during early planning a problem emerges: both the Service Desk manager and the Infrastructure lead believe they own decisions about user provisioning and access approvals. Team members are starting duplicate work because no one knows who assigns tasks or how updates will be shared.

What is the BEST next step?

• A. Build the detailed project schedule and start assigning tasks from it
• B. Create a RACI and confirm the team’s coordination approach at the kickoff
• C. Begin execution with a short sprint to clarify ownership through work
• D. Escalate the disagreement to the project sponsor for a decision

Best answer: B

What this tests: Project Life Cycle Phases

Explanation: In initiation and early planning, the team needs clear accountability and a defined way to coordinate work before tasks are assigned. A RACI clarifies who is responsible, accountable, consulted, and informed for key decisions like access approvals. Pairing that with agreed coordination mechanisms (cadence, tools, handoffs) prevents duplicated work and confusion.

The core need in the scenario is to establish initial team roles/responsibilities and define how work will be coordinated. When ownership is unclear (for example, who approves access and who performs provisioning), the project should formalize decision rights and working relationships before execution.

A practical next step is to:

• Draft a RACI for key deliverables/decisions (access approvals, configuration, integrations)
• Validate it with the functional leads and sponsor as needed
• Confirm coordination basics (task assignment method, meeting cadence, status channels, escalation path)

This creates a shared understanding of who does what and how work flows, which is a prerequisite to efficient task assignment and prevents premature escalation or “learning by doing” in production-like work.

Defining roles/responsibilities and how work is coordinated resolves ownership conflicts and prevents duplicated effort before execution begins.

Questions 26-50

Question 26

Topic: Project Tools and Documentation

You are reviewing the latest quality dashboard for a CRM migration project. The Quality Management Plan includes explicit thresholds that require action.

Exhibit: Quality dashboard (excerpt)

Metric: Critical defect escape rate (post-UAT / total tests)
Target: <= 2.0%
Action threshold: > 3.0% triggers corrective action within 2 business days
Current release candidate (RC-2): 3.8%

Based on the exhibit, what is the MOST appropriate next action?

• A. Proceed with deployment and capture the variance in lessons learned
• B. Ask the sponsor to approve relaxing the defect threshold for RC-2
• C. Log an issue and initiate corrective action with a root cause analysis
• D. Add a risk for potential quality problems and continue monitoring

Best answer: C

What this tests: Project Tools and Documentation

Explanation: The escape rate is an actual performance result and it is above the explicit action threshold in the Quality Management Plan. That means the project team must execute the defined response, not simply monitor or defer. The appropriate response is to treat it as a current problem and begin corrective action immediately.

This exhibit provides explicit targets and a trigger threshold, which turns the decision into a straightforward compare-and-act situation. The actual metric (3.8%) is above the action threshold (>3.0%), so the project must follow the pre-defined escalation/response in the Quality Management Plan.

A good next action is to:

• Record it as an issue (it has already occurred)
• Start corrective action, typically including root cause analysis and remediation
• Coordinate the response within the stated timebox (2 business days)

Monitoring is appropriate when you are still dealing with uncertainty (a risk) or when results are within tolerance; here the metric is outside the defined tolerance, so active correction is required.

The current escape rate exceeds the plan’s action threshold, so it must be treated as an issue requiring immediate corrective action.

Question 27

Topic: Project Life Cycle Phases

During execution of a SaaS CRM implementation, the project manager notices the last two status reports show the schedule slipping. The schedule performance index (SPI) has dropped from 0.97 to 0.85, and two tasks on the critical path are forecast to finish 10 business days late. The sponsor still expects the original go-live date.

Which corrective action should the project manager NOT take?

• A. Submit a change request if scope/date must change
• B. Re-sequence work and request temporary resources if approved
• C. Run a root-cause review and publish a recovery plan
• D. Report the project as green until the team catches up

Best answer: D

What this tests: Project Life Cycle Phases

Explanation: With an SPI trending down and critical-path tasks forecast late, the project needs transparent reporting and a planned corrective response. Corrective actions should diagnose the cause, adjust execution tactics, and use formal change control if baselines must change. Hiding the variance undermines decision-making and increases the chance of a larger failure later.

Corrective action in execution means responding to performance indicators (like SPI and critical-path slippage) with actions that bring the work back toward the approved baselines or formally change those baselines. Appropriate responses include understanding why work is slipping, creating and tracking a recovery plan, and using change control when the original scope/date is no longer achievable. You can also adjust how work is executed (for example, resequencing tasks or adding short-term help) as long as impacts and approvals are handled.

The anti-pattern is concealing negative status to avoid stakeholder concern; it delays escalation, blocks timely decisions, and typically increases schedule and risk exposure.

Misrepresenting status hides the variance and prevents timely corrective action and governance decisions.

Question 28

Topic: Project Tools and Documentation

A project team is replacing a shared spreadsheet tracker with a cloud-based project management tool. Key risks include losing historical project data during import, incorrect role permissions after migration, and tampered/altered records due to sync errors. The team has implemented backups, role-based access templates, and integrity checks.

Which evidence best validates that these tool-related risks are mitigated and the tool is ready for go-live?

• A. Completed cutover checklist with restore, RBAC, and integrity test results
• B. Stakeholder sign-off that the new tool “looks good” in a demo
• C. Import job summary showing 100% of rows processed
• D. Training completion report for all project coordinators

Best answer: A

What this tests: Project Tools and Documentation

Explanation: The strongest validation is objective test evidence that the specific risks were addressed. A cutover/readiness checklist that includes documented backup/restore results, role-based access control verification, and integrity check outcomes demonstrates data loss, access, and integrity mitigations are functioning before production use. This is more defensible than progress outputs or subjective approval.

For tool-related risks like data loss, access issues, and data integrity problems, the best readiness evidence is objective, repeatable validation that the mitigations work in a go-live-like condition. In this scenario, that means proving you can recover data (restore test), that permissions match intended roles (RBAC verification), and that imported/synced records remain accurate and unaltered (integrity/reconciliation checks). A cutover or go/no-go checklist that records these tests and their results provides auditable proof of readiness and directly ties to the risks being managed. Metrics about activity completion or subjective feedback do not validate that data can be recovered, access is correct, or records are intact.

A completed validation checklist with test results directly proves backup/restore, access controls, and data integrity work as intended.

Question 29

Topic: Project Tools and Documentation

A fully distributed team is implementing a new SaaS ticketing system. The project manager must provide evidence to stakeholders that the configuration and data migration for Release 1 are complete and accepted, even though the product owner and SMEs are in different time zones.

Which of the following best validates readiness and acceptance in this context?

• A. A shared acceptance checklist showing all criteria met, with linked UAT results and product owner sign-off
• B. A screenshot of the team’s virtual whiteboard with the final workflow diagram
• C. A chat thread where the product owner says the release “looks good”
• D. A report showing the number of closed migration tasks and messages sent during the week

Best answer: A

What this tests: Project Tools and Documentation

Explanation: Acceptance and release readiness should be validated with objective evidence tied to agreed-upon acceptance criteria. For distributed teams, the strongest validation is a shared, versioned artifact that records test results and explicit stakeholder approval. A completed acceptance checklist with UAT evidence and sign-off is auditable and reduces ambiguity across time zones.

The core concept is validating progress and acceptance using objective, auditable evidence rather than activity outputs or informal communication. In a distributed team, shared documentation becomes the “source of truth” because stakeholders cannot rely on hallway conversations or being present for the same meetings.

The best validation artifact is one that:

• Maps directly to agreed acceptance criteria
• Includes verifiable results (for example, UAT evidence)
• Captures an explicit approval/acceptance decision in a shared repository

A shared acceptance checklist with linked UAT results and product owner sign-off demonstrates that the deliverable meets requirements and has been formally accepted, which is stronger than diagrams, chats, or throughput-style metrics.

This provides objective, reviewable evidence of acceptance criteria being met and explicitly approved in a shared, auditable location.

Question 30

Topic: Project Tools and Documentation

You are preparing a status slide for an executive steering committee for a SaaS implementation. They asked for “schedule performance versus quality performance” on one slide, but did not specify what they mean by either term.

What should you ask/obtain FIRST before selecting the most appropriate chart(s)?

• A. The team’s planned PTO for the next month
• B. The project’s total budget and cost baseline
• C. The vendor’s latest SLA and penalty clauses
• D. Which schedule and quality metrics must be trended and compared

Best answer: D

What this tests: Project Tools and Documentation

Explanation: Different charts communicate different kinds of information (trend over time, variation, distribution, or ranked causes). Before you can pick the best chart(s) to show schedule performance versus quality performance, you need the exact measures the stakeholders expect and whether they want a time-based comparison. That clarification drives whether you use schedule-variance/burndown-style views and defect/quality trend or variation charts.

Chart selection depends on the question the audience is trying to answer. “Schedule performance” could mean planned vs actual dates, milestone slip, or iteration throughput; “quality performance” could mean defect trend, escaped defects, test pass rate, rework, or process stability. Those measures also imply different chart families (e.g., schedule variance/burndown/burnup for time-based progress; defect trend or control charts for quality over time; Pareto for top defect categories).

The first thing to obtain is the definition of the schedule and quality metrics to be communicated and whether the comparison is a trend over a shared time window. Once those are clear, you can select charts that correctly visualize the intended relationship without misleading stakeholders.

You must first clarify the specific schedule and quality measures (and whether they need trends) to choose an appropriate chart type.

Question 31

Topic: Project Life Cycle Phases

You are initiating a 10-week SaaS service desk implementation. Constraints: go-live must occur before a planned operations blackout in weeks 9–10; the security analyst is only available for scheduled reviews; the vendor provides a configuration consultant; the team is split across two time zones and production changes require CAB coordination. As the project manager, what is the BEST next action to establish initial team roles and how work will be coordinated?

• A. Create a RACI and communications cadence, then validate with stakeholders
• B. Begin requirements workshops and define roles after requirements stabilize
• C. Have managers provide resources as needed and coordinate primarily by email
• D. Build a detailed Gantt schedule and assign tasks to named individuals

Best answer: A

What this tests: Project Life Cycle Phases

Explanation: During initiation, the priority is to clarify who owns which deliverables and how the distributed team will work together. Creating a responsibility assignment approach (such as a RACI) and agreeing on meeting cadence, tools, and escalation paths establishes coordination while respecting limited security availability and CAB governance. This reduces early confusion and prevents delays caused by unclear handoffs and approvals.

In project initiation, you set up the team for execution by defining roles/responsibilities and the coordination model before detailed planning accelerates. A responsibility assignment matrix (RACI/RAM) clarifies who is Responsible, Accountable, Consulted, and Informed for key activities (configuration, security review, CAB submissions, testing, training). Pairing this with a lightweight communications plan (cadence across time zones, collaboration tools, escalation path, and decision/approval points) aligns internal staff and the vendor consultant early, which is critical with a fixed go-live window and limited specialist availability. Detailed scheduling and workshops work best after ownership and coordination rules are clear, so work doesn’t stall on handoffs or approvals.

A RACI plus an agreed communication/escalation cadence defines ownership and coordination early enough to meet the tight timeline and governance needs.

Question 32

Topic: Project Management Concepts

During a 30-minute weekly status meeting for a CRM migration, the infrastructure lead and security analyst argue about an encryption approach and begin talking over each other. The team must leave the meeting with a documented decision owner and next steps, but you also want to preserve collaboration for the rest of the project.

What should you do to best keep the meeting on track and resolve the disagreement?

• A. Escalate immediately to the project sponsor to decide during the meeting
• B. Restate the goal, timebox each viewpoint, align on decision criteria, and assign a small follow-up with an owner and due date
• C. End the discussion by taking a quick vote and moving to the next agenda item
• D. Let them continue until they reach agreement, even if the agenda runs long

Best answer: B

What this tests: Project Management Concepts

Explanation: The best option uses neutral facilitation to reduce tension while still producing an outcome within the timebox. By clarifying decision criteria, giving each side structured time, and assigning an owner with a short follow-up, you keep the meeting moving and maintain trust. This approach balances schedule constraints with collaboration.

Effective meeting facilitation in a disagreement focuses on process control (agenda/time) and relationship safety while still driving a decision or a clear path to one. In this scenario, you have a hard timebox and need documented ownership and next steps, so the optimal move is to de-escalate, structure the discussion, and create an accountable decision path.

A practical approach is:

• Restate the meeting objective and the decision needed
• Set ground rules (one speaker at a time) and timebox each perspective
• Capture agreed decision criteria (e.g., compliance requirement, performance impact, implementation effort)
• If the decision cannot be finalized quickly, assign a smaller working session with a single owner to return a recommendation by a specific time

This keeps the meeting on track, preserves collaboration, and still satisfies the requirement for ownership and next steps.

This uses facilitation techniques to de-escalate, keep within the time constraint, and still produce accountable next steps without damaging relationships.

Question 33

Topic: Project Life Cycle Phases

You are in the discovery phase for implementing a new SaaS ticketing system. The sponsor wants to confirm feasibility before approving the charter.

Exhibit: Discovery RAID excerpt

Constraint: Go-live by June 30 (end of fiscal year)
Constraint: Production change freeze June 15–30
Dependency: Vendor contract must be executed before tenant is provisioned
Dependency: Procurement cycle averages 6 weeks
Dependency: Security/privacy review required; typical lead time 4 weeks

Based on the exhibit, what is the BEST next action to address early dependencies and constraints that could affect feasibility?

• A. Commit to the June 30 go-live and plan to request a change-freeze exception later
• B. Add two additional engineers to compress the configuration schedule
• C. Begin configuration in a sandbox to avoid procurement delays
• D. Initiate procurement and the security/privacy review immediately and add these as schedule dependencies

Best answer: D

What this tests: Project Life Cycle Phases

Explanation: The exhibit highlights feasibility risk driven by external lead times: a 6-week procurement cycle and a 4-week security/privacy review, both required before the vendor can provision the tenant. With a fixed June 30 deadline and a change freeze starting June 15, these dependencies must be started immediately and reflected in the schedule. This is the most direct action to validate feasibility early.

In discovery, feasibility is often constrained by non-build work such as procurement, contracting, security/privacy assessments, and change windows. The exhibit shows two gating dependencies (contract execution and security/privacy review) with lead times that can consume most of the available calendar before the June 15 freeze and June 30 go-live. The best action is to start those lead-time activities immediately and document them as explicit schedule dependencies (and likely risks) so the project timeline reflects real gating work. If those approvals cannot complete in time, the sponsor can make an informed decision to adjust scope, timeline, or approach before committing.

The exhibit shows long lead-time external dependencies that must start now to meet the fixed go-live date and change-freeze constraint.

Question 34

Topic: Basics of IT and Governance

A project is rolling out a new identity provider (IdP) integration for a customer portal. To support go-live in 2 weeks, the team must add new inbound firewall rules on the production network segment used by several other applications. The change is planned and not related to an incident.

Company policy: All planned production infrastructure changes require formal review/approval through the change management process before implementation. A maintenance window is available every Saturday.

What should the project coordinator do NEXT to best meet the deadline while staying compliant and minimizing risk?

• A. Ask the project sponsor to approve the firewall change so work can start immediately
• B. Submit an RFC with impact/risk and rollback plan for CAB review, then schedule implementation in the next maintenance window
• C. Implement the firewall rules during off-hours and document the change after go-live
• D. Present the firewall change to the CCB because it is part of the project’s implementation plan

Best answer: B

What this tests: Basics of IT and Governance

Explanation: Because this is a planned production infrastructure change that can affect multiple services, it must follow formal change control. Routing it through the CAB with a documented impact assessment and rollback plan satisfies governance and reduces operational risk. Submitting promptly also preserves the ability to implement in the next available maintenance window and still meet the go-live date.

CAB/CCB governance depends on what is being changed. A CAB (Change Advisory Board) is used for reviewing and approving planned operational/production changes (for example, network, firewall, server, or platform changes) to manage risk, scheduling, and service impact. A CCB (Change Control Board) is typically used for changes to the project’s baselined scope/schedule/cost (for example, adding requirements or altering deliverables).

In this scenario, the firewall update is a planned production infrastructure change with potential cross-application impact, and policy requires formal change management. The best next step is to submit an RFC to the CAB with impact, risk, implementation steps, and a rollback plan, then schedule it into the next maintenance window to meet the deadline while controlling risk.

This routes a planned production change through the CAB as required while still fitting the weekly window and the 2-week deadline.

Question 35

Topic: Basics of IT and Governance

A project team is implementing a new HR SaaS platform. For the final week of user acceptance testing, a third-party integration vendor must be onboarded within two days to troubleshoot in the test environment and update design documents in the project wiki. An internal audit requirement states developers must have no standing production access, and the team cannot buy new tools this late in the project.

Which action best applies least privilege to project artifacts and environments while meeting the schedule constraint?

• A. Use RBAC groups with minimum permissions and time-bound prod elevation
• B. Give the vendor broad read access now and tighten after go-live
• C. Grant project-wide admin access to avoid onboarding delays
• D. Share one service account across dev/test/prod to simplify access

Best answer: A

What this tests: Basics of IT and Governance

Explanation: The best optimization is to use role-based access control with group-based permissions that grant only what each role needs in the wiki, repo, and test environment. For rare production needs, a time-bound elevation process avoids standing privileged access and aligns with the audit requirement. This approach can typically be implemented quickly using existing IAM/SSO groups and approvals.

Least privilege means users (including vendors) get only the minimum access needed for their tasks, and privileged access is limited in scope and time. In this scenario, the vendor only needs the test environment and specific project documentation, while the audit constraint prohibits standing production access for developers.

A practical, fast approach using existing capabilities is:

• Create or reuse IAM/SSO groups by role (vendor, QA, dev).
• Grant access only to the needed wiki space/repos and the test environment.
• Require just-in-time, time-bound elevation (with approval and logging) for any production break-fix work.

This satisfies the audit requirement and reduces risk without adding cost or delaying onboarding; broad or shared access increases exposure and violates least-privilege expectations.

Role-based groups with least-privilege grants and just-in-time elevation meet audit constraints quickly without new tooling.

Question 36

Topic: Project Tools and Documentation

A project coordinator is supporting a hybrid project to migrate an internal app to a managed database service. Several tasks require quick stakeholder actions (UAT sign-offs, firewall rule approvals), but action items are currently tracked in meeting notes and followed up manually, and deadlines are being missed.

The coordinator configures a lightweight workflow in the team’s work tracker to assign owners, set due dates, and send automatic reminders/escalations when items are overdue. What is the most likely near-term impact of this change?

• A. A higher likelihood of scope creep as stakeholders request more features
• B. Fewer missed follow-ups and less time spent chasing action items
• C. An immediate increase in project cost due to additional tool licensing
• D. A significant reduction in production defects after go-live

Best answer: B

What this tests: Project Tools and Documentation

Explanation: Automating reminders and escalations in the existing work tracker directly reduces the manual overhead of checking notes and chasing owners. In the near term, this decreases the chance that approvals and sign-offs are forgotten or delayed. That improves workflow continuity and reduces schedule risk caused by missed follow-ups.

Lightweight automation (such as reminders, due dates, and escalation rules) is a productivity tool that improves follow-through on assigned actions without adding heavy process overhead. In this scenario, missed UAT sign-offs and firewall approvals are creating delays because the team relies on meeting notes and manual follow-ups.

By configuring a simple workflow, the coordinator:

• Makes ownership and due dates visible in one place
• Automatically prompts owners before and after due dates
• Escalates overdue items so blockers are addressed faster

The near-term effect is better task completion and fewer stalled handoffs, which reduces coordination time and helps protect the schedule.

Automated reminders and escalation reduce manual coordination and overdue approvals, improving near-term schedule flow.

Question 37

Topic: Project Management Concepts

A project to deploy a new identity provider (IdP) for 8,000 employees is trending 3 weeks behind schedule. The go-live date is fixed due to an expiring security exception. The sponsor has approved up to $60,000 of contingency funding, and the team agrees that some work can be overlapped if the project documents and manages the added rework risk.

Which TWO actions are appropriate schedule compression techniques for this situation? (Select TWO)

• A. Remove MFA for non-privileged users to reduce implementation effort
• B. Re-sequence work on non-critical-path training materials to start earlier
• C. Add an additional full regression test cycle before go-live
• D. Move the go-live date by 3 weeks and rebaseline the schedule
• E. Add a short-term contractor to build the production and DR environments
• F. Overlap IdP configuration with the final requirements sign-off

Correct answers: E, F

What this tests: Project Management Concepts

Explanation: With a fixed go-live date, the project needs schedule compression. Fast-tracking is appropriate when the team can overlap activities and manage the increased rework risk. Crashing is appropriate when additional budget is available to add resources to critical-path work and reduce duration.

Schedule compression shortens the timeline without changing project scope by using fast-tracking and/or crashing. In this scenario, the date cannot move, contingency funding is available, and the team is willing to accept and manage added risk—so both techniques can be applied.

• Fast-tracking: overlap activities that were planned sequentially (e.g., start configuration before full sign-off), which can reduce elapsed time but increases the chance of rework.
• Crashing: add resources or pay overtime for critical-path tasks (e.g., a contractor building environments) to shorten task duration, typically increasing cost.

Actions that change scope or add additional work are not schedule compression and may jeopardize the fixed deadline.

This is fast-tracking—performing activities in parallel to reduce the schedule while accepting higher rework risk.

This is crashing—adding resources (using approved funds) to shorten critical-path work.

Question 38

Topic: Project Life Cycle Phases

You are planning the production rollout of a new SSO integration for a customer support portal. The sponsor wants the rollout “as soon as possible,” while the operations manager is concerned about user lockouts and wants a cautious approach. You need to create the test/validation and rollout plan (pilot vs phased vs big-bang, rollback steps, and go/no-go checks), but the current requirements package does not state business impact tolerance.

What should you verify/obtain FIRST before selecting the rollout approach and validation depth?

• A. The vendor’s latest release notes and known-issues list
• B. A complete set of test cases for all portal features
• C. A detailed day-by-day rollout schedule with named resources
• D. Agreed go/no-go criteria, including acceptable downtime/user impact and rollback triggers

Best answer: D

What this tests: Project Life Cycle Phases

Explanation: A rollout plan should be sized to the organization’s risk tolerance, which is expressed through measurable go/no-go criteria (acceptable outage, user impact, and rollback triggers). Without those thresholds, you cannot justify a pilot vs phased vs big-bang rollout or determine the minimum validation needed to safely proceed. Getting stakeholder agreement first prevents building a plan that is either too risky or unnecessarily slow.

Test/validation scope and rollout strategy should be driven by business impact tolerance and explicit decision thresholds. For a change like SSO, the primary risk is user access failure, so you need agreed, measurable go/no-go criteria (for example, allowable downtime, maximum acceptable login failure rate, required monitoring period, and clear rollback triggers). Once those are approved by key stakeholders (business owner and operations), you can choose an approach (pilot/phased/blue-green) and define the validation gates and backout plan that match that tolerance.

The key takeaway is to clarify impact tolerance and decision criteria before building the rollout mechanics and test details.

These thresholds define stakeholder risk tolerance and drive how rigorous validation and the rollout/rollback strategy must be.

Question 39

Topic: Basics of IT and Governance

A project team is implementing a new SaaS HR onboarding platform. The vendor requests a file of real employee records to validate integrations in a UAT environment next week.

Company policy states that any new system handling employee PII requires a documented security risk assessment and a privacy impact assessment, both approved by InfoSec and the Privacy Officer, before production data is used outside existing systems.

What is the BEST next step?

• A. Initiate the security risk assessment and privacy impact assessment and route them for InfoSec and Privacy Officer approval before providing real employee data
• B. Escalate to the project sponsor to accept the compliance risk and authorize sharing the data
• C. Submit a change request to the CAB for approval to use real data in UAT
• D. Provide the data now and document the assessments retroactively to avoid delaying the UAT schedule

Best answer: A

What this tests: Basics of IT and Governance

Explanation: Because the data includes employee PII and will be used outside existing systems, the project must complete the required compliance documentation first. The correct next step is to initiate the security risk assessment and privacy impact assessment and obtain the specified approvals. This keeps the project aligned with governance requirements before sharing production data.

When a project introduces new handling of regulated or sensitive data (like employee PII), governance typically requires specific compliance artifacts (e.g., security risk assessment and privacy impact assessment/DPIA) and defined approvers (InfoSec, Privacy Officer) before data is shared or processed in new environments. In this scenario, the vendor’s request creates an immediate compliance trigger: using real employee data in UAT would violate the stated policy unless the assessments are completed and approved first. The right sequencing is to start and document the required assessments, route them to the required approvers, and only then allow production data use (often using masked/synthetic data in the interim if needed). The key takeaway is that required compliance documentation and approvals are prerequisites, not after-the-fact paperwork.

Policy requires documented risk and privacy assessments with approvals before any production PII is shared for testing.

Question 40

Topic: Project Life Cycle Phases

A project team is preparing to execute a migration of customer records into a new SaaS CRM for a healthcare client. Because the data includes regulated patient information, the client’s governance process requires documented approval that the scope, schedule, budget, and risk responses are acceptable before any production changes begin.

Which action should the project manager take to obtain approval to proceed into execution?

• A. Submit a change request to the change advisory board (CAB) to authorize the entire project scope
• B. Start execution with provisional baselines and confirm approvals during the first status meeting
• C. Hold a formal phase-gate planning review and secure sponsor/governance sign-off on the baselined project management plan
• D. Conduct the project kickoff meeting to align stakeholders and begin assigning work packages

Best answer: C

What this tests: Project Life Cycle Phases

Explanation: The key discriminator is the compliance requirement for documented approval before production-impacting work begins. A phase-gate (go/no-go) planning review is designed to verify planning completeness and formally approve baselines so the team can transition into execution under governance. This provides traceable sign-off that required controls are met before work starts.

Planning reviews confirm that the project is ready to move from planning into execution, and they culminate in formal approval (often a go/no-go decision) of the integrated plan and baselines. In a regulated healthcare data context, the decisive factor is the need for auditable documentation that scope, schedule, budget, and risk responses have been reviewed and accepted before any execution activities that could affect production.

A proper phase-gate planning review typically includes:

• Verifying the project management plan is complete and consistent
• Confirming baselines (scope/schedule/cost) and key risks/issues
• Obtaining sponsor/governance approval to proceed (go/no-go)

A kickoff aligns the team, but it does not replace the required formal authorization to enter execution.

A compliance-driven project needs a documented go/no-go (phase-gate) approval of baselines before starting execution work.

Question 41

Topic: Project Tools and Documentation

You are coordinating a 6-month SaaS CRM implementation. The client’s internal audit team will review requirements, approvals, change requests, and test evidence, and they expect artifacts to be quickly retrievable with a clear audit trail.

Which approach SHOULD AVOID?

• A. Store artifacts in a controlled shared repository structure
• B. Use a standard pattern: project-artifact-date-version
• C. Let each team choose filenames; rely on email search
• D. Include unique IDs in filenames (e.g., CR-017, DEC-04)

Best answer: C

What this tests: Project Tools and Documentation

Explanation: Auditable projects require consistent, predictable naming and centralized organization so artifacts can be found and traced to approvals and changes. Allowing each team to name files ad hoc and relying on email threads creates duplicate “sources of truth” and breaks traceability. Standard patterns, unique identifiers, and controlled repositories support retrieval and audit readiness.

For retrievability and auditability, project artifacts should follow a consistent naming convention and be stored in a shared, access-controlled location with an agreed folder taxonomy. File names should help someone who was not on the project quickly identify what the document is, which version is current, and how it relates to tracked items like change requests or decisions. Consistency matters more than the specific pattern, as long as the team applies it uniformly.

A common approach is to standardize on elements such as project identifier, artifact type, unique record ID (when applicable), date (using an unambiguous format), and version (draft/final or numeric). Centralizing storage reduces duplicates and supports an audit trail via approvals, metadata, and controlled updates.

Inconsistent, decentralized naming and storage makes artifacts hard to retrieve and weakens auditability.

Question 42

Topic: Project Management Concepts

You are coordinating an IT project to implement a new SaaS CRM and migrate 6 years of customer data. The sponsor asks for a weekly dashboard of performance metrics/KPIs to show project progress and whether the solution is meeting expectations.

The project brief lists scope items but does not specify measurable success targets (for example, acceptable migration error rate, performance expectations, or adoption goals). What should you obtain/confirm first before selecting the KPIs for the dashboard?

• A. A list of all stakeholders who want access to the dashboard
• B. The vendor’s standard SLA and support hours for the SaaS platform
• C. Documented success criteria and acceptance metrics with targets/baselines
• D. The team’s detailed timesheets from the previous two sprints

Best answer: C

What this tests: Project Management Concepts

Explanation: Before choosing KPIs, you need a clear definition of what “success” means for this project in measurable terms. Confirming acceptance criteria and specific targets/baselines ensures the dashboard metrics directly reflect required outcomes (data quality, performance, adoption) and allow objective variance tracking. Without defined targets, reported metrics may be meaningless or misaligned to stakeholder expectations.

Performance measurement works only when metrics are traceable to agreed objectives and quality expectations. In this scenario, the sponsor wants KPIs for both progress and outcomes, but the project brief lacks measurable success targets. The first step is to confirm documented success criteria and acceptance metrics (and their targets/baselines), typically from the charter, requirements, and acceptance criteria. Then you can select leading indicators for progress (for example, completed stories, test pass rate) and lagging indicators for outcomes (for example, migration accuracy, page response time, user adoption) that demonstrate whether the delivered CRM meets expectations. Getting audience/access preferences or unrelated operational details can come later, but they don’t establish what should be measured or what “good” looks like.

KPIs must be derived from agreed, measurable success criteria so progress and outcomes can be tracked against defined targets.

Question 43

Topic: Project Tools and Documentation

A team is delivering a customer portal in 2-week sprints. The release plan milestone assumes the remaining MVP backlog will be completed in the next 3 sprints.

Recent sprint data shows frequent mid-sprint additions, rising rework, and no single approver for scope decisions.

Exhibit: Velocity/capacity snapshot

Remaining MVP backlog (start of Sprint 5): 120 story points

Sprint 2: Capacity 100% | Committed 36 | Added mid-sprint 0  | Completed 26 | Rework 4
Sprint 3: Capacity 80%  | Committed 38 | Added mid-sprint 10 | Completed 24 | Rework 7
Sprint 4: Capacity 75%  | Committed 40 | Added mid-sprint 12 | Completed 23 | Rework 8

Based on the velocity/capacity trend and the forecast it implies, what is the MOST likely underlying cause of the missed milestones?

• A. A sudden drop in team productivity due to inadequate technical skills
• B. Testing is being performed too late in the sprint, which is the primary cause
• C. Lack of scope control and clear backlog ownership
• D. An external vendor dependency is delaying delivery of critical components

Best answer: C

What this tests: Project Tools and Documentation

Explanation: The last three sprints show delivered velocity around 23–26 points while work is still being added mid-sprint and capacity is reduced. That makes a 120-point remaining backlog take about 5 sprints at the current sustainable rate, not 3. The pattern points to governance issues (who can approve changes and when), not a one-time execution problem.

Use empirical velocity with current capacity constraints to forecast completion. The team is completing about 26, 24, and 23 points, so a reasonable forecast is roughly 24 points per sprint. With 120 points remaining, that implies about 5 more sprints, which directly conflicts with the plan’s 3-sprint milestone assumption.

The exhibit also shows a consistent pattern of mid-sprint scope being added (10–12 points) while capacity drops (to 80% and 75%). Combined with “no single approver,” the most likely root cause is weak scope/change control and unclear product ownership, which drives overcommitment, churn, and rework rather than enabling a stable plan based on capacity and velocity. The key takeaway is to base forecasts on actual throughput and control when/why work is injected.

Mid-sprint added work plus reduced capacity keeps delivered velocity near ~24 points, making the 3-sprint plan unrealistic and indicating uncontrolled changes/unclear decision authority.

Question 44

Topic: Project Life Cycle Phases

You are executing a hybrid project to migrate an on-prem file share to a SaaS collaboration platform. Midway through execution, the security team adds a new requirement for data loss prevention (DLP) rules that will affect configuration and user acceptance testing (UAT). The sponsor is focused on keeping the go-live date, but has not yet been briefed on the impact.

Which action SHOULD AVOID to maintain stakeholder alignment while adapting delivery?

• A. Shorten agreed UAT activities without sponsor approval to meet the date
• B. Process the new DLP requirement through change control
• C. Record the new requirement impact in the RAID log and assign an owner
• D. Re-plan the remaining work and review impacts with stakeholders

Best answer: A

What this tests: Project Life Cycle Phases

Explanation: During execution, adapting delivery is appropriate, but changes that affect scope, schedule, or quality must be communicated and governed to keep stakeholders aligned. Shortening agreed UAT without sponsor approval creates an unapproved quality tradeoff and undermines shared expectations for acceptance. Proper alignment requires transparent impact assessment and formal updates to plans and baselines.

Executing according to plan does not mean ignoring new constraints; it means managing them in a controlled, visible way so stakeholders stay aligned on what “done” and “go-live ready” mean. A new DLP requirement impacts configuration and UAT, so the project team should assess impacts, communicate them, and use the project’s change control/governance process to approve any scope, schedule, cost, or quality adjustments.

Cutting agreed UAT to protect the date is an anti-pattern because it introduces an implicit change to quality and acceptance criteria without stakeholder agreement, increasing the likelihood of defects, security gaps, or rejection at acceptance. The key takeaway is to adapt the plan transparently, update project artifacts, and obtain approvals for tradeoffs rather than making silent changes.

Unilaterally changing agreed quality/acceptance work breaks alignment and bypasses governance needed to adapt the plan.

Question 45

Topic: Project Life Cycle Phases

You are closing an ITSM tool implementation project. The sponsor asks how the team will verify that the business benefits are realized after the project is handed over to operations.

Exhibit: Closeout draft (excerpt)

Expected benefits:
- Reduce help desk tickets by 20%
- Cut monthly SaaS spend by \$8,000
Tracking: "Ops will monitor after go-live"

Based on the exhibit, what is the BEST next action to ensure benefits are tracked post-project and follow-up checkpoints are defined?

• A. Extend the project schedule until the 20% reduction is achieved
• B. Create a benefits realization plan with KPIs, baselines, owners, and 30/60/90-day checkpoints
• C. Add additional user acceptance testing focused on cost savings
• D. Close the project and let operations decide what to measure after go-live

Best answer: B

What this tests: Project Life Cycle Phases

Explanation: The closeout draft states desired outcomes but does not specify how they will be measured, who is accountable, or when results will be reviewed. A benefits realization plan addresses this by defining metrics, baselines/data sources, ownership, and scheduled follow-up checkpoints after handover to confirm whether benefits were achieved.

In project closing, benefits don’t automatically occur at go-live; they must be verified through a defined post-project approach. The exhibit is missing the essentials needed to track benefits: measurable KPIs (how each benefit will be quantified), the baseline (current ticket volume/spend), the data source/report owner, and specific follow-up checkpoints (for example, 30/60/90 days after go-live) where results are reviewed and actions are assigned. Creating a benefits realization plan (or adding a benefits tracking section to the transition/closeout package) makes the monitoring objective and accountable while still allowing the project to close once deliverables are accepted.

The exhibit lists benefits but lacks defined measures, ownership, and scheduled post-project reviews needed to verify realization.

Question 46

Topic: Project Management Concepts

A network segmentation project uses earned value to track performance. At the end of week 6, the project report shows:

What is the schedule variance (SV), and what does it indicate?

• A. SV = +$7,000; the project is ahead of schedule
• B. SV = +$7,000; the project is behind schedule
• C. SV = -$7,000; the project is ahead of schedule
• D. SV = -$7,000; the project is behind schedule

Best answer: D

What this tests: Project Management Concepts

Explanation: Schedule variance measures schedule performance by comparing earned value to planned value using SV = EV − PV. Here, EV is less than PV by $7,000, so SV is negative. A negative SV means the team has completed less work than planned at this point in the schedule baseline.

Schedule variance (SV) is an earned value metric used to interpret whether completed work is tracking to the plan.

Compute it directly from the given values:

A negative SV means the project has earned less value than was planned by this date, which indicates the project is behind schedule (in terms of work completed versus the baseline plan). The most common mistakes are reversing the subtraction or using the wrong interpretation for the sign.

SV is calculated as EV − PV, so $68,000 − $75,000 = -$7,000, indicating less work completed than planned.

Question 47

Topic: Project Management Concepts

A project team is delivering a custom reporting portal. During UAT, many “defects” are logged, but developers explain the behavior matches their interpretation of loosely written user stories. The rework is consuming significant time, and the sponsor wants better quality without adding new features.

Which action will most likely have the best near-term impact on reducing rework while improving quality without expanding scope?

• A. Conduct requirements walkthroughs and add explicit acceptance criteria
• B. Add another developer to speed defect fixes
• C. Build a new automated regression test framework
• D. Defer unresolved UAT defects to a later release

Best answer: A

What this tests: Project Management Concepts

Explanation: The rework is primarily caused by unclear requirements and inconsistent expectations, not a lack of effort. Adding explicit acceptance criteria and validating them with stakeholders improves testability and alignment immediately. This prevents misunderstandings that become UAT churn, improving quality without changing the product scope.

A common cause of rework is ambiguous or unvalidated requirements, especially when user stories lack clear, testable acceptance criteria. When UAT findings are really expectation mismatches, the fastest quality improvement is prevention: confirm what “done” means before building and testing.

A practical near-term prevention action is to:

• Hold a short requirements/story walkthrough with key stakeholders
• Document acceptance criteria (and align the team’s definition of done)
• Use those criteria to drive development and UAT test cases

This reduces back-and-forth and “defects” caused by differing interpretations, improving quality without adding new features.

Clarifying and validating acceptance criteria up front prevents misunderstandings that drive rework and improves testability without adding features.

Question 48

Topic: Basics of IT and Governance

A project team is preparing to enable a new API integration for a SaaS rollout. The network engineer is ready to apply a firewall rule change during tonight’s standard maintenance window.

However, the change record in the ITSM tool is still in Draft status and is missing an impact assessment and rollback plan. No CAB approval has been recorded.

What is the best next step?

• A. Notify affected users and update the project schedule to reflect the planned change.
• B. Implement the firewall rule tonight to avoid delaying the project milestone.
• C. Complete the change record (impact, risk, rollback) and route it for CAB approval before scheduling implementation.
• D. Escalate to the project sponsor to bypass CAB and authorize the change.

Best answer: C

What this tests: Basics of IT and Governance

Explanation: The change is not ready to implement because required documentation (impact assessment and rollback plan) and CAB approval are missing. The next step is to complete the change record and obtain the required approvals so the change is authorized and supportable. This reduces operational risk and ensures governance requirements are met before execution.

In IT governance and change control, implementation should not occur until the change is fully documented and formally approved. Here, the change record is incomplete (missing impact assessment and rollback plan) and has no recorded CAB approval, which means the organization has not accepted the risk or validated the backout approach.

Best next-step sequence is:

• Complete the change documentation (scope, impact/risk, rollback, testing/verification, schedule)
• Obtain required approvals (e.g., CAB/authorized approver)
• Then schedule, communicate, and implement during the approved window

The key takeaway is that approvals and required documentation are prerequisites to execution, even when a maintenance window is available.

Change control requires a complete, approved change record before implementation to ensure risk, impact, and rollback are reviewed and authorized.

Question 49

Topic: Basics of IT and Governance

A project team is implementing a SaaS HR system. Recently, the team has missed two milestones due to rework after configuration settings and interface mappings “mysteriously” changed.

Clues:

• The requirements document, test cases, and cutover checklist are stored in a shared folder where “Everyone” has edit rights.
• The SaaS admin console shows several changes made outside the approved change window.
• The audit log lists the actor as a shared HR-Admin account for most of the changes, so the owner cannot be identified.

Which is the MOST likely underlying cause of these project issues?

• A. Least privilege and role-based access controls were not enforced for project artifacts and environments
• B. The communications plan did not specify meeting frequency and status reporting
• C. The QA team lacked an adequate test plan, leading to defects and rework
• D. Requirements were insufficiently detailed, causing stakeholders to request frequent updates

Best answer: A

What this tests: Basics of IT and Governance

Explanation: The key clues point to access control failures: broad edit rights on key artifacts, production-like admin changes outside the change window, and a shared admin account that removes traceability. Not applying least privilege and RBAC allows unauthorized or accidental changes that directly create rework and schedule slips. Fixing permissions and identity-based auditing addresses the root cause.

This scenario is best explained by weak access control and failure to apply least privilege to both project artifacts (documents) and the SaaS environment. When “Everyone” can edit baselines (requirements, test cases, cutover checklist), changes can occur without approval, introducing rework and delaying milestones. The shared HR-Admin account also breaks accountability: you can’t attribute changes to a person, making it hard to investigate and enforce process (such as CAB/change windows).

Appropriate controls include:

• Assigning role-based permissions (view vs. edit vs. admin)
• Removing shared accounts and using named accounts with MFA
• Restricting admin rights and limiting who can promote changes to production

The core takeaway is that governance depends on identity, auditing, and minimized permissions—not just communication or testing improvements.

Overly broad edit/admin access and shared accounts enable uncontrolled changes and prevent accountability through auditing.

Question 50

Topic: Project Tools and Documentation

You are taking over coordination for a hybrid cloud migration project. During an internal audit, the auditor reports that project artifacts are scattered across email threads and personal drives, and several documents cannot be traced to an approved version.

Which TWO actions best improve artifact retrievability and auditability through naming conventions and file organization? (Select TWO)

• A. Adopt a standard filename pattern that includes project ID, artifact type, date, and version
• B. Purge older drafts monthly so only the newest files remain
• C. Rename documents only after the project closes to avoid confusing contributors
• D. Allow ad hoc filenames as long as the document header includes the project name
• E. Ask each workstream lead to keep their own folder structure as long as they share links
• F. Rely on email subject lines to identify the latest approved attachment
• G. Store approved artifacts in a centralized repository with a defined folder taxonomy and access controls

Correct answers: A, G

What this tests: Project Tools and Documentation

Explanation: Retrievability and auditability come from consistent naming plus controlled, centralized storage. A standard filename convention makes it easy to search and to distinguish draft vs. approved versions. A centralized repository with a defined folder taxonomy and permissions creates a single source of truth and a clearer audit trail.

To make artifacts retrievable and auditable, you need both (1) predictable names and (2) predictable locations. A standard naming convention (for example, including a project identifier, artifact type, date, and version) enables fast searching/sorting and reduces “latest file” ambiguity. Centralizing approved artifacts into a controlled repository (with a defined folder taxonomy and appropriate access controls) provides a single source of truth, reduces version sprawl across personal locations, and supports audits by making it clear where approved versions live and who can change them. Approaches that depend on individual preferences, email threads, or deleting history reduce traceability and increase the risk that the team cannot prove which version was approved and used.

A consistent, information-rich pattern makes files searchable and supports version traceability during audits.

A single source of truth with consistent structure ensures artifacts can be found and their control history can be audited.

Questions 51-75

Question 51

Topic: Project Life Cycle Phases

You are planning a 3-week implementation of a new HR SaaS. Go-live is fixed for March 22, and the only production change window is the weekend before go-live.

Constraints and dependencies:

• HR must approve the attribute mapping before SSO/SCIM configuration.
• The vendor’s IP allowlist is required for SCIM and takes the network team 5 business days after receiving the final IP list.
• Security will not perform its 3-day review until the approved attribute mapping and the documented data flow (including network allowlist) are complete.
• UAT requires working SSO and SCIM in the test tenant.

Which sequencing approach BEST optimizes meeting the date while minimizing rework and approval risk?

• A. Approve attribute mapping → obtain final vendor IPs/metadata → submit allowlist ticket → configure SSO/SCIM in test in parallel → document data flow → security review → UAT → production change window
• B. Start UAT planning and have IAM configure SSO/SCIM before attribute mapping is approved
• C. Complete SSO/SCIM configuration and UAT first, then engage network and security for approvals
• D. Submit the network allowlist ticket immediately using placeholder IPs to start the 5-day clock

Best answer: A

What this tests: Project Life Cycle Phases

Explanation: The best plan respects the real dependencies and team handoffs: HR approval enables IAM work, the vendor IP list enables the network allowlist request, and the completed data-flow documentation enables the security review. Starting the 5-business-day network task as soon as its inputs are ready protects the schedule while allowing other work to proceed in parallel. This minimizes rework and reduces the risk of missing the single production window.

Sequencing should follow hard dependencies and known lead times, with clear handoffs between teams so long-lead work starts as early as possible. Here, HR approval of attribute mapping is a prerequisite for the IAM configuration, and the network allowlist cannot start until the final vendor IPs are provided. Security approval is gated by completed mapping and documented data flow (including the network design), so the plan must produce those inputs before requesting the review.

A schedule-optimized approach is to:

• Get HR sign-off on attribute mapping first.
• Hand off final vendor IPs/metadata to start the network ticket immediately.
• Configure SSO/SCIM in the test tenant while the allowlist is in progress.
• Finalize data-flow documentation, then hand off to security for review.

This protects the critical path and avoids invalid early approvals or rework caused by placeholder inputs.

It sequences work by true dependencies, starts the long-lead network handoff early, and parallelizes configuration and documentation to reach security/UAT in time.

Question 52

Topic: Project Management Concepts

You are coordinating an IT project to implement single sign-on (SSO) for 6 internal apps. The sponsor asks you to recommend a delivery approach.

Exhibit: Requirements and uncertainty summary (excerpt)

Hard deadline: New audit requirement effective October 1
Fixed scope: MFA for privileged users; 99.9% uptime target
Evolving needs: Self-service portal fields and reporting "not finalized"
Change history: 7 requirement updates in last 3 weeks
Technical uncertainty: IdP vendor API version changing weekly
Stakeholder preference: Biweekly demos to refine portal workflow

Which delivery approach is MOST appropriate based on the exhibit?

• A. Hybrid approach: predictive for compliance/SSO core, agile for portal/reporting
• B. Agile approach for the entire project
• C. No defined methodology until the vendor API stabilizes
• D. Predictive approach with all requirements baselined up front

Best answer: A

What this tests: Project Management Concepts

Explanation: A hybrid approach best matches mixed requirement stability. The audit deadline and clearly defined security controls benefit from predictive planning and baselining, while the frequently changing portal/reporting requirements and technical uncertainty are better handled with iterative delivery and regular stakeholder feedback. This reduces rework while still protecting the compliance date.

Selecting a delivery approach depends on how stable requirements are and how much uncertainty/change you expect. Here, several items are stable and deadline-driven (audit effective date, MFA for privileged users, uptime target), which supports predictive planning for the core SSO and compliance deliverables (clear scope, milestones, and change control). At the same time, the self-service portal and reporting are explicitly not finalized, the change history is high, and the vendor API is shifting—signals that iterative work with frequent demos and reprioritization will reduce rework and improve fit.

A hybrid approach lets you baseline and manage the compliance-critical components predictively while running agile iterations for the evolving portal/reporting features and integration adjustments. The key takeaway is to match the methodology to where requirements are stable versus volatile, not to force a single approach across all work.

The exhibit shows a fixed compliance deadline and stable core controls alongside high change frequency and evolving portal/reporting needs, which fits a hybrid approach.

Question 53

Topic: Project Life Cycle Phases

You are leading discovery for a SaaS service desk implementation. A key requirement is near-real-time user provisioning from the on-prem HR system. In an interview, the HR application owner states the system only supports a nightly CSV export and that enabling an API would require an unplanned upgrade that cannot start for 6 months.

What is the best next step?

• A. Proceed with detailed scheduling and planning assuming the API will be available later
• B. Document the dependency/constraint and run a feasibility/impact review with the HR owner and stakeholders
• C. Submit a formal change request to move provisioning to nightly batch processing
• D. Escalate to the steering committee to mandate an immediate HR system upgrade

Best answer: B

What this tests: Project Life Cycle Phases

Explanation: Discovery is where you surface constraints and dependencies that can make requirements infeasible. The new information about HR’s integration limits is a feasibility risk that must be documented and validated with the right SMEs and stakeholders. Confirming options and impacts comes before baselining requirements, schedule, or pushing a change through control processes.

In the discovery phase, a newly identified dependency or constraint (like “no API available for 6 months”) can directly affect project feasibility and must be handled before the project commits to a solution approach.

The best next step is to capture the constraint/dependency (e.g., in an assumptions/constraints log or RAID log) and promptly validate feasibility by engaging the system owner and impacted stakeholders to:

• Confirm technical options (batch file, middleware, upgrade timeline)
• Assess impacts to requirements, schedule, cost, and risk
• Decide whether to adjust requirements or pursue an alternative approach

Escalation, change control, and detailed planning are appropriate only after the constraint is understood and viable paths are identified.

Capturing the constraint and validating options/impacts is the appropriate next step in discovery before committing to requirements and plans.

Question 54

Topic: Project Life Cycle Phases

During discovery for a customer-data analytics platform, the team confirms a non-negotiable requirement: all PII must remain in-country due to regulation.

Discovery findings show the selected SaaS vendor cannot provide in-country hosting within the project timeline, and the only compliant alternative would increase costs by 40%, exceeding the sponsor’s stated budget cap with no funding flexibility. Key stakeholders are no longer aligned on a path forward.

What should the project manager recommend next?

• A. Pivot by requesting a budget increase to use a compliant alternative
• B. Proceed and record the compliance gap as a project risk
• C. Pivot by removing the in-country hosting requirement
• D. Stop and escalate a go/no-go decision using the discovery findings

Best answer: D

What this tests: Project Life Cycle Phases

Explanation: Discovery has identified a hard constraint (regulatory data residency) that the chosen solution cannot meet, and the only compliant alternative is not viable under the sponsor’s budget cap. With stakeholders no longer aligned and no feasible path that satisfies constraints, the appropriate outcome of discovery is to recommend stopping and seek a formal go/no-go decision based on documented findings.

A key purpose of the discovery phase is to validate feasibility and alignment before committing to detailed planning and execution. When discovery reveals a non-negotiable constraint (such as regulatory compliance) that cannot be met within approved time/cost limits, the project does not have a viable baseline to proceed.

In this scenario:

• The compliance requirement cannot be waived.
• The selected vendor cannot meet it in time.
• The only compliant option breaks the sponsor’s stated budget cap.
• Stakeholders are not aligned on an acceptable alternative.

Given these findings, the best recommendation is to stop and escalate a formal go/no-go decision using the documented discovery results, rather than treating the compliance gap as a manageable risk or attempting an unapproved scope/budget change.

A mandatory compliance constraint with no feasible, aligned option supports a stop/go-no-go recommendation rather than proceeding or forcing an unapproved pivot.

Question 55

Topic: Basics of IT and Governance

You are coordinating vendor selection for hosting a new customer analytics platform. Functional requirements and a cost cap are already approved, and two shortlisted vendors meet the technical needs.

The sponsor adds a high-level directive to choose the “most sustainable option” and says the outcome may be used for ESG reporting. Before you compare designs (region, architecture) and select a vendor, what should you ask for FIRST?

• A. Can the vendor start the deployment next month?
• B. What is each vendor’s total cost over three years?
• C. What measurable sustainability criteria and proof are required?
• D. How many integrations are needed with existing systems?

Best answer: C

What this tests: Basics of IT and Governance

Explanation: Because “most sustainable option” is vague, the project team can’t fairly compare vendors or design choices until sustainability is defined as measurable, testable requirements. Clarifying the required ESG criteria and acceptable evidence (e.g., renewable energy usage, emissions reporting, certifications) turns the directive into selection and acceptance criteria. That information then directly drives architecture trade-offs and vendor scoring.

Sustainability is typically a nonfunctional requirement that can materially change both design choices (e.g., hosting region, energy-efficient architecture, lifecycle impacts) and vendor selection (e.g., renewable energy commitments, emissions accounting, third-party certifications). In this scenario, the sponsor’s direction is not actionable until it is converted into measurable criteria and required evidence.

Clarify items such as:

• Which sustainability dimensions matter (carbon, energy, e-waste, water, packaging)
• Minimum standards/certifications required and acceptable proof
• Reporting needs (what must be measurable/auditable for ESG claims)

Once these are defined, you can incorporate them into the evaluation criteria/RFP scoring and assess how each design/vendor satisfies them. Cost, schedule, and integrations remain important, but they’re not the first gap to close here.

You must translate the vague “most sustainable” directive into measurable vendor/design criteria with verifiable evidence before evaluating options.

Question 56

Topic: Project Management Concepts

You are asked to draft a 30-minute meeting agenda for a cross-functional group to discuss “the deployment plan,” but the requestor did not specify what the meeting should accomplish.

Which question should you ask FIRST before building the agenda with purpose, outcomes, and timeboxes?

• A. Who is available during the proposed meeting window?
• B. Which stakeholders should be invited to the meeting?
• C. What decision or deliverable must the meeting produce?
• D. What pre-read documents should attendees review beforehand?

Best answer: C

What this tests: Project Management Concepts

Explanation: Start by clarifying the meeting’s purpose and the specific outcome it must generate (decision, plan, approvals, or action list). Once the outcome is known, you can sequence agenda topics to reach it and assign realistic timeboxes. Logistics, attendee lists, and pre-reads come after the objective is clear.

A usable meeting agenda is built around a clear purpose and measurable expected outcomes, then divided into timeboxed topics that logically lead to those outcomes. In the scenario, “discuss the deployment plan” is ambiguous: the meeting could be for information sharing, risk review, approval to proceed, or assigning owners to tasks. Asking what decision or deliverable the meeting must produce establishes the target end state, which then drives what topics to include, who needs to attend, what pre-work is required, and how to allocate the 30 minutes. Without an explicit outcome, timeboxing becomes guesswork and the meeting is likely to end without closure.

Key takeaway: clarify the required outcome first; then design the agenda to achieve it.

You must confirm the meeting’s purpose and expected outcome before you can timebox topics appropriately.

Question 57

Topic: Project Management Concepts

A new cloud engineer joins your team halfway through a 10-week migration to a new identity platform. They must start contributing within a week, and the work involves production access that requires approvals. Which action should the project coordinator NOT take when onboarding this team member to reduce ramp-up risk?

• A. Assign a buddy and schedule a short architecture and workflow walkthrough
• B. Submit role-based access requests immediately with least-privilege justification
• C. Provide a centralized onboarding packet with links to runbooks and key decisions
• D. Delay all access requests until their first week ends

Best answer: D

What this tests: Project Management Concepts

Explanation: Reducing ramp-up risk means removing predictable blockers early, especially access and context gaps. Initiating least-privilege access requests right away and providing structured context enables the new engineer to contribute sooner while still following approvals. Intentionally waiting to start access provisioning is an onboarding anti-pattern that creates avoidable idle time and delays delivery.

Efficient onboarding in an IT project focuses on quickly enabling safe productivity: timely access, clear context, and easy-to-find documentation. When access requires approvals, the coordinator should start requests immediately using predefined role-based groups and least-privilege rationale, because approval lead time is a known dependency. In parallel, a buddy and a brief walkthrough help the new member understand system boundaries, current priorities, and “how work flows” (tickets, environments, reviews). Centralizing runbooks, key decisions, and diagrams reduces time lost to searching and prevents inconsistent tribal-knowledge guidance. The key takeaway is to remove predictable friction early; delaying access provisioning adds avoidable schedule risk without improving governance.

Delaying required access increases ramp-up risk and blocks meaningful contribution, even when approvals are needed.

Question 58

Topic: Project Management Concepts

You are managing a SaaS SSO integration project. Two weeks before go-live, the identity engineer discovers the production rollout requires (1) a new outbound firewall rule to allow traffic to the SaaS, and (2) an update to the production IdP configuration.

Exhibit: Change governance (excerpt)

- Production changes require a documented change request and CAB approval.
- Production changes must be implemented during the weekly change window (Sat 22:00–02:00).
- Any firewall/security control change requires InfoSec review/approval.
- Emergency change path is only for active service outage or critical security incident.

Which TWO actions should you take to follow the appropriate approval path? (Select TWO.)

• A. Submit a standard change request for the production IdP update and route it to the CAB
• B. Get the project sponsor’s approval and schedule the work during normal business hours
• C. Implement the changes in production now and complete the change record after go-live
• D. Obtain InfoSec review/approval for the new firewall rule before implementation
• E. Apply the changes only in the test environment and proceed with go-live
• F. Request emergency change approval so the changes can be made immediately

Correct answers: A, D

What this tests: Project Management Concepts

Explanation: The change involves production and security controls, so it must follow formal governance. That means using the standard change process with CAB authorization for production work and obtaining the required InfoSec approval for the firewall/security change. The approval path is driven by risk and environment, not by the project’s go-live date.

Change control governance typically varies by environment (dev/test vs. production) and by risk (especially security-impacting changes). In this scenario, both updates are explicitly production changes, and one is a firewall/security control change. Therefore you must route the production work through the formal CAB approval process and also obtain InfoSec sign-off for the firewall rule.

Using the emergency change path is reserved for a true outage or critical security incident; a looming go-live date does not qualify. The key takeaway is to match the approval route to the change’s environment and risk profile, then plan implementation within required operational controls like change windows.

Production configuration changes require a documented change request and CAB approval per the governance excerpt.

Firewall/security control changes require InfoSec approval, regardless of project schedule pressure.

Question 59

Topic: Project Management Concepts

You are tracking escaped defects per build during system testing for a web app release. The team uses the control limits below and reviews them weekly.

Exhibit: Control view (escaped defects/build)

Center line (CL): 3
UCL: 6
LCL: 0

Builds 1–8: 2, 3, 4, 3, 2, 3, 7, 3

Based on this control view, what should the project manager do next?

• A. Continue monitoring because the data returns to the center line
• B. Initiate corrective action and perform root cause analysis
• C. Update acceptance criteria to allow up to seven escaped defects
• D. Rebaseline the UCL and LCL to reflect the recent volatility

Best answer: B

What this tests: Project Management Concepts

Explanation: A control chart is used to determine whether process variation is in control. The data shows an out-of-control signal because one build’s escaped defects exceed the upper control limit. That indicates special-cause variation, so the appropriate response is to investigate and take corrective action rather than normalize the result.

Control views (such as control charts) help distinguish common-cause variation from special-cause variation. When results stay within the upper and lower control limits and show no nonrandom patterns, the process is considered stable and you typically continue monitoring.

Here, build 7 has 7 escaped defects, which is above the UCL of 6. A point outside the control limits is a classic out-of-control signal, meaning the process may have changed (for example, a bad merge, environment change, or test gap). The next step is to log the problem, investigate the cause, and implement corrective action to prevent recurrence.

Changing limits or criteria to “fit” the data would hide the signal instead of addressing it.

A point above the UCL indicates special-cause variation that warrants investigation and corrective action.

Question 60

Topic: Basics of IT and Governance

A project team is launching a new customer self-service portal. Company governance requires a WCAG 2.1 AA accessibility review as a release gate, but the project manager decides to skip the accessibility review to meet a marketing date.

What is the most likely near-term impact of this decision?

• A. The organization is fined by regulators immediately after deployment
• B. Go-live approval is delayed when the release gate fails, requiring rework
• C. The project’s cost baseline drops because less testing is performed
• D. The organization experiences increased customer churn over the next year

Best answer: B

What this tests: Basics of IT and Governance

Explanation: Because accessibility verification is a stated governance release gate, skipping it creates an immediate compliance/ethical risk that blocks approval. The most likely near-term consequence is a failed gate review that forces remediation work before production release. That directly impacts schedule and stakeholder alignment more quickly than external market or regulatory outcomes.

This is a governance and ethical risk tied to ESG (the “social” dimension): neglecting accessibility when it is an explicit release requirement. When a control is defined as a release gate, bypassing it doesn’t remove the obligation—it increases the likelihood of a failed approval, which typically results in stop-ship, rework, and a schedule slip while defects are fixed and revalidated.

A practical mitigation is to treat accessibility as a non-negotiable quality requirement:

• Keep WCAG acceptance criteria in scope from the start
• Schedule accessibility testing early and repeatedly
• Escalate date/scope trade-offs through change control rather than bypassing gates

The closest trap is assuming the decision mainly creates distant consequences, when the gate makes the impact immediate.

Skipping a required accessibility gate most immediately triggers a failed governance review, delaying release while issues are remediated.

Question 61

Topic: Project Tools and Documentation

You are coordinating a data center firewall replacement. The vendor just reported the firewall shipment (Task 2) will slip by 3 business days.

Exhibit: Gantt excerpt (baseline)

ID  Task                       Start   Finish  Pred
1   Requirements freeze         Mar 4   Mar 5   -
2   Firewall delivery           Mar 6   Mar 12  1
3   Install firewall            Mar 13  Mar 14  2
4   Approved cutover window     Mar 15  Mar 15  3
5   Post-cutover validation     Mar 18  Mar 19  4

The cutover window is pre-approved and cannot occur earlier than March 15. What is the best next step?

• A. Update the Gantt with the slip and recalculate dependent dates
• B. Escalate to the sponsor that the vendor is late
• C. Proceed with the install as scheduled to protect the cutover date
• D. Begin post-cutover validation planning to avoid idle time

Best answer: A

What this tests: Project Tools and Documentation

Explanation: Because the install and cutover tasks are finish-to-start dependent on the delivery, a 3-day slip can push the entire chain and threaten the fixed cutover date. The immediate next step is to update the schedule and recalculate dates to confirm the impact and quantify the schedule risk before requesting decisions or changes.

A Gantt chart is most useful when you apply task dependencies to see how a slip propagates through the schedule. Here, Task 3 cannot start until Task 2 finishes, and Task 4 cannot occur until Task 3 finishes. With a 3-business-day delay to delivery, you should first update Task 2 dates and let the schedule recalculate the downstream start/finish dates; this confirms whether the fixed cutover window becomes unattainable and which milestone(s) are impacted. Once the impact is quantified, you can log the issue/risk and take the appropriate governance step (for example, a change request to move the cutover). The key takeaway is to perform dependency-based impact analysis before escalating or replanning work.

Recomputing the schedule using the delivery dependency shows whether the fixed cutover milestone will be missed.

Question 62

Topic: Basics of IT and Governance

A project is migrating 120 on-prem VMs to a public cloud. The sponsor has set these priorities:

• Schedule is fixed: production cutover must occur by June 30.
• Cost is flexible: up to $50,000 additional spend is allowed.
• ESG requirement is mandatory: 100% of decommissioned servers must be processed by an R2- (or e-Stewards-) certified recycler, and the project must be able to prove compliant disposition during closeout.

Which evidence best validates the project met the ESG requirement without confusing it with cost or schedule performance?

• A. Gantt chart showing the decommissioning milestone is marked complete
• B. Updated cost baseline showing recycler spend stayed within $50,000
• C. Certified recycler asset-disposition report with serial numbers and certificates
• D. Recycler’s sustainability brochure describing its green practices

Best answer: C

What this tests: Basics of IT and Governance

Explanation: To validate an ESG compliance requirement, you need objective, auditable evidence that the required practice occurred. A certified recycler’s asset-disposition report that matches the organization’s retired equipment (by serial number) and includes the required certificates directly demonstrates compliant handling. Cost and schedule artifacts may support tradeoff decisions but do not prove ESG compliance.

When constraints and priorities are explicit, validating ESG compliance requires evidence that maps to the ESG requirement’s acceptance criteria, not to project performance metrics. Here, the requirement is specific and auditable: all decommissioned servers must be processed by an R2/e-Stewards certified recycler and the project must be able to prove it at closeout. The strongest validation is documentation that (1) identifies the exact assets disposed (e.g., serial numbers/asset tags), (2) shows they were handled by a certified recycler, and (3) provides official certificates (recycling/certificate of destruction/chain-of-custody).

Cost baselines and schedules are useful to evaluate the allowed tradeoff (extra spend to protect the fixed cutover date), but they do not demonstrate that the ESG handling requirement was actually met.

A certified disposition report that ties certificates to the actual retired assets is direct, auditable proof of ESG-compliant e-waste handling.

Question 63

Topic: Project Life Cycle Phases

You are assigned to lead an IT project to roll out MFA for a company’s SaaS apps before an external audit in 8 weeks. Stakeholders disagree on which apps are in scope, and operations is concerned about login outages. The sponsor is available today for a brief call and can electronically sign documents, but is traveling for the next 2 weeks.

Which action BEST ensures formal authorization to start and enables an effective kickoff that aligns stakeholders while meeting the timeline constraint?

• A. Begin technical implementation on the highest-risk apps now and document approval retroactively to protect the audit deadline
• B. Finalize a project charter and obtain the sponsor’s e-signature, then run a kickoff using the charter to confirm scope, roles, and communications
• C. Hold a kickoff immediately to negotiate scope, then submit the charter for approval after consensus is reached
• D. Request resource commitments from functional managers as the authorization to start, then schedule the kickoff when the sponsor returns

Best answer: B

What this tests: Project Life Cycle Phases

Explanation: Formal authorization to start is obtained through sponsor approval of the project charter (or equivalent project brief). Using that approved charter as the primary input to the kickoff aligns stakeholders on objectives, scope boundaries, roles, and communication paths. Getting an electronic sign-off now also avoids a 2-week delay that threatens the 8-week deadline.

In project initiation, the sponsor’s approval of a project charter (or project brief) is the standard mechanism for formally authorizing the project and empowering the project lead to use resources. With stakeholders already disagreeing on scope and operations risk, an effective kickoff should be anchored to the approved charter so participants align on what is in/out of scope, success criteria, key roles (often via RACI), and how decisions and changes will be handled.

A practical sequence that meets the time constraint is:

• Confirm the charter is complete enough for authorization (purpose, high-level scope, key stakeholders, constraints, risks).
• Obtain sponsor sign-off (e-signature is acceptable if allowed).
• Conduct the kickoff using the approved charter as the baseline to align expectations and next steps.

This approach avoids starting work without authority and prevents a kickoff from becoming an ungoverned scope negotiation.

A sponsor-approved charter provides formal authorization and a baseline for a kickoff that aligns stakeholders quickly without waiting 2 weeks.

Question 64

Topic: Project Management Concepts

You are managing a SaaS CRM implementation. During final integration testing, intermittent API failures are discovered. The technical lead believes the team can redesign the integration, but it may add time and possibly require additional middleware spend.

Before deciding whether to escalate this as an issue to the sponsor/steering committee or resolve it within the team, what should you verify FIRST?

• A. Whether the vendor contract includes penalties for missed go-live dates
• B. Whether schedule/cost/scope impact exceeds the team’s approval authority
• C. Whether users want additional enhancements added before launch
• D. Whether the defect can be reproduced reliably in the test environment

Best answer: B

What this tests: Project Management Concepts

Explanation: Escalate issues when the project team cannot approve the needed action, such as changes that affect baselined scope, schedule, cost, or risk acceptance. The first clarification is whether the likely impact crosses the team’s authority threshold and therefore needs formal approval. That determination drives both the escalation path and how the decision is documented.

Issue escalation is primarily an authority and governance decision: if resolving the problem requires approvals outside the team (for example, changing a baselined schedule/cost/scope or accepting significant risk), the PM should escalate through the defined path (sponsor, product owner, CAB/steering committee). In this scenario, the key unknown is whether the redesign/middleware impact will trigger formal change control or require sponsor-level tradeoffs.

Once you verify the expected impacts and the approval thresholds, you can:

• Log/update the issue with impact and owner
• Either assign the team to resolve within delegated authority, or raise it for decision
• Record the outcome (decision/change approval) in the appropriate log

Technical troubleshooting details matter, but they come after establishing whether the team is empowered to decide.

Escalation is driven by whether the issue’s impact requires a decision or approval outside the team’s authority.

Question 65

Topic: Project Management Concepts

You are managing an IAM/SSO integration for a new HR SaaS platform. During final testing, the security operations team reports that the required outbound firewall rule for production is missing.

Constraints:

• Go-live is in 8 business days to meet a contractual deadline.
• Standard firewall changes must be approved by the CAB, and the next CAB meeting is in 10 business days.
• A temporary emergency rule is possible, but it requires CIO approval.
• Your project authority does not include approving emergency production changes.

What is the BEST next action?

• A. Ask the team to redesign SSO to avoid firewall changes
• B. Submit an emergency change for approval and log the escalation
• C. Wait for the next CAB meeting and update the schedule
• D. Implement the temporary rule and notify security after go-live

Best answer: B

What this tests: Project Management Concepts

Explanation: This issue cannot be resolved within the project team because it involves an emergency production firewall change that requires CIO approval. With go-live occurring before the next CAB meeting, the project manager should escalate through the proper change-control path while documenting the issue, impact, and the escalation/decision owner. This preserves governance while protecting the deadline.

Issue management includes deciding whether the team can resolve a problem within its authority or whether it must be escalated to the appropriate decision-making body. Here, the missing firewall rule blocks production SSO, the go-live date occurs before the next CAB meeting, and an emergency change is allowed only with CIO approval—outside the project manager’s authority.

The best next action is to:

• Record the issue (impact, urgency, owner) in the issue/RAID log.
• Prepare a brief impact statement (schedule/operational risk) and request an emergency change.
• Escalate to the approver path (change manager/CAB process and CIO) and track the decision.

The key takeaway is to escalate when resolution requires approvals or authority beyond the team, and document the escalation and outcome for traceability.

The issue requires an out-of-team governance decision (emergency production change), so it must be escalated and documented with impact and ownership.

Question 66

Topic: Project Management Concepts

A team is midway through a SaaS help-desk implementation. Weekly status reports are mostly narrative, and the sponsor says they cannot tell whether the project is truly on track or whether quality is improving during system testing.

What is the BEST next step to address this problem?

• A. Hold a lessons-learned meeting to determine why current reporting is subjective
• B. Escalate to the steering committee to decide whether to pause testing
• C. Define a small set of agreed KPIs with targets and data sources, and add them to the status dashboard
• D. Begin tracking any available tool metrics immediately, then refine later if stakeholders disagree

Best answer: C

What this tests: Project Management Concepts

Explanation: The project needs objective, repeatable measures to show progress and outcomes, so the next step is to define KPIs that map to success criteria and can be consistently measured. Agreeing on targets and data sources (who collects what, and from where) ensures the metrics are trusted and comparable over time. Once defined, they can be built into the regular status reporting cadence.

When stakeholders say status is “subjective,” the immediate fix is to establish objective performance metrics and how they will be measured. Select a small set of KPIs that align to the project’s success criteria (for example, schedule predictability, cost performance, and test quality), define targets/thresholds, and document the data sources and cadence (e.g., test tool reports weekly, backlog aging daily). This creates a consistent way to track trends and outcomes and reduces debate about “how we’re doing.” After KPIs are defined and baselined, the team can collect data, publish a dashboard, and use the results to drive corrective actions if needed. Escalation or retrospectives can help later, but they don’t replace establishing measurable KPIs first.

You first align on measurable KPIs tied to schedule, cost, and quality outcomes before collecting and reporting trends.

Question 67

Topic: Project Management Concepts

You are coordinating an on-prem firewall refresh project. During weekly status, the procurement lead shares the following excerpt.

Exhibit: RAID log excerpt

ID: R-07
Type: Risk
Description: Firewall appliances may ship late
Trigger: Vendor confirms delay beyond March 15
Status update: Vendor email received; shipment delayed 10 days
Response: Expedite shipping; adjust install resources
Owner: Procurement lead

What is the BEST next action for the project coordinator?

• A. Submit a change request to extend the project end date
• B. Close R-07 since a response has been identified
• C. Move R-07 to the issue log and assign resolution actions
• D. Reassess probability and impact for R-07 in the risk register

Best answer: C

What this tests: Project Management Concepts

Explanation: A risk is a potential future event, while an issue is a current problem that has already happened. The exhibit shows the trigger condition was met and the vendor confirmed a 10-day shipment delay. That means the item is no longer uncertain and should be managed through the issue log with assigned actions and follow-up.

Risk management tracks uncertain future events (risks) and prepares responses if they occur. Issue management tracks current problems that are already impacting (or will definitely impact) the project and require active resolution.

In the exhibit, the trigger for R-07 is vendor confirmation of a delay beyond March 15, and the status update states the vendor email was received and the shipment is delayed 10 days. That confirms the event occurred, so it should be reclassified and managed as an issue with clear action items, dates, and ownership, while updating schedule impacts through normal planning controls as needed. The key distinction is uncertainty: risks are possible; issues are real/confirmed.

The delay has occurred (trigger met), so it should be tracked as an issue with owners and actions.

Question 68

Topic: Project Management Concepts

During a meeting for an identity management rollout, the security lead and operations lead begin arguing about whether multi-factor authentication must be enabled for all contractors on day one. The discussion is drifting into unrelated past incidents, and the team is falling behind the agenda. As the project coordinator facilitating the meeting, which TWO actions should you take to keep the meeting on track and resolve the disagreement while preserving collaboration? (Select TWO.)

• A. Hold an immediate vote to pick the most popular option.
• B. Allow discussion to continue until full consensus is reached.
• C. Escalate to the sponsor now to decide for the group.
• D. End the meeting and collect solutions by email after.
• E. Summarize both views and agree on decision criteria before choosing.
• F. Restate the objective and timebox discussion to regain focus.

Correct answers: E, F

What this tests: Project Management Concepts

Explanation: Effective facilitation keeps the group aligned to the meeting’s purpose and uses structured techniques to resolve conflict. Restating the desired outcome and timeboxing prevents derailment and protects the agenda. Summarizing positions and aligning on decision criteria turns a debate into a collaborative evaluation and decision.

The facilitator’s role is to keep the meeting moving toward a clear outcome while maintaining a respectful, collaborative environment. When discussion becomes circular or off-topic, first re-anchor the group to the objective (what decision is needed) and manage time so the agenda can be completed.

To reduce disagreement, use neutral facilitation: reflect what you heard from each side, confirm understanding, and guide the group to agree on decision criteria (for example, security risk reduction, operational impact, and rollout feasibility). Then evaluate options against those criteria and capture the decision and follow-up actions. This approach resolves conflict through structure and clarity rather than authority or popularity.

Re-centering the group on the meeting outcome and a time limit keeps the discussion productive and on agenda.

Neutral summarization plus shared decision criteria reduces conflict and enables a collaborative, fact-based decision.

Question 69

Topic: Basics of IT and Governance

A project team is rolling out SSO configuration changes for a SaaS application. The organization defines change types as follows:

• Standard: pre-authorized, low-risk, documented, repeatable; follows a defined procedure and does not require CAB approval each time
• Normal: requires impact assessment, scheduling, and CAB approval before implementation
• Emergency: unplanned, needed to restore service or prevent imminent outage; expedited approval with a required post-implementation review

Over the last month, several production changes were implemented during business hours without appearing on the change calendar. Some changes included new firewall rules and an authentication policy update, which required rollback and caused rework. When asked, the team says the changes were “standard” so CAB approval was not needed, and no one can clearly state who approved them.

Which of the following is the most likely underlying cause?

• A. Stakeholders are not receiving status updates on progress
• B. Change types are being misclassified, bypassing the required approval path
• C. The schedule is unrealistic due to underestimated effort
• D. Testing is insufficient, causing defects and rollbacks

Best answer: B

What this tests: Basics of IT and Governance

Explanation: The symptoms point to a breakdown in change control governance, not just execution problems. The team is using the “standard change” label to skip CAB and scheduling, even though the described changes are not pre-authorized, low-risk, or repeatable. That misclassification drives uncontrolled changes, unclear approval ownership, and rework.

In IT governance, the handling path depends on correct change classification. In the scenario, firewall rules and authentication policy updates are not described as pre-authorized, repeatable procedures; they require assessment and scheduled approval, which aligns with a normal change path. Calling them “standard” to avoid CAB creates a control gap: changes are not assessed, not scheduled on the calendar, and approval accountability is unclear. That governance failure explains the missed coordination, rollbacks, and rework.

Key takeaway: when definitions are provided, validate the change against those definitions first; the correct process flow (CAB/scheduling vs. pre-authorized procedure vs. expedited emergency handling) follows from that classification.

Labeling non-repeatable, higher-risk changes as “standard” avoids CAB review and leads to uncontrolled implementations.

Question 70

Topic: Project Life Cycle Phases

You are initiating an enterprise SaaS rollout. During the kickoff, the business unit director says they are the sponsor, but the IT manager says all scope and budget decisions must go through the PMO. Team members are unsure who can approve changes and where to escalate blockers.

Which TWO actions should the project manager take during initiation to clearly identify the sponsor and establish decision-making authority and escalation paths? (Select TWO)

• A. Ask the most senior stakeholder in meetings to make decisions as they arise
• B. Proceed with requirements workshops and let governance roles be finalized during planning
• C. Send a project-wide email requesting volunteers to serve as approvers for scope and budget
• D. Create and publish a RACI and escalation matrix that defines approvers and escalation tiers
• E. Confirm the project sponsor and decision rights, and document them in the project charter
• F. Log the sponsor confusion as a risk and wait to escalate until the risk triggers

Correct answers: D, E

What this tests: Project Life Cycle Phases

Explanation: During initiation, the project manager should remove ambiguity about who sponsors the project and who has approval authority. The most effective way is to formally document the sponsor and decision rights in the charter and to define how decisions and escalations will be handled using clear governance artifacts that stakeholders can follow.

In project initiation, unclear sponsorship and approval authority quickly creates delays, conflicting direction, and uncontrolled changes. The project manager should explicitly identify who owns the business outcome (the sponsor) and document decision-making authority (who can approve scope, budget, and priority changes) in an initiation artifact such as the project charter. In parallel, the team needs a practical governance mechanism that states who is Responsible, Accountable, Consulted, and Informed for key decisions and how to escalate when a decision is blocked.

These actions:

• establish a single, recognized sponsor (or named governance body) with defined authority
• make approval and escalation paths visible and repeatable for the team

Relying on informal “whoever is senior” decisions or postponing governance typically increases rework and schedule impacts.

The charter is the initiation artifact used to formally name the sponsor and define high-level authority for approvals.

A RACI/escalation matrix makes decision-makers explicit and provides a clear path for escalating issues and conflicts.

Question 71

Topic: Project Life Cycle Phases

You are in the discovery phase for a SaaS CRM implementation. After an initial stakeholder interview, you review the draft project brief excerpt below.

Exhibit: Project brief (draft excerpt)

Goals: Replace legacy CRM by Oct 31
High-level requirements:
- SSO with corporate IdP (owner: IT)
- Migrate accounts/contacts (owner: Sales Ops)
Constraints:
- Change freeze: TBD
- Data residency requirement: TBD
Assumptions:
- Vendor supports SSO for all users
- Legal review not required

Which is the BEST next action to elicit high-level requirements/constraints and document assumptions?

• A. Start building the WBS and baseline the schedule using the Oct 31 date
• B. Send the draft brief to the vendor and ask them to finalize requirements
• C. Submit a change request to remove the data residency constraint to protect the timeline
• D. Schedule a requirements workshop with IT, Security/Compliance, and Legal to confirm constraints and validate/update the assumptions log

Best answer: D

What this tests: Project Life Cycle Phases

Explanation: The exhibit shows key discovery items are unresolved (constraints marked TBD) and assumptions are unverified. The best next step is structured stakeholder elicitation with the right functions (security/compliance and legal) to confirm constraints like data residency and change freezes, and to document and validate assumptions. This reduces downstream rework and prevents planning on incorrect premises.

In discovery, the goal is to elicit and confirm high-level requirements and constraints, and to capture assumptions as items that must be validated. The exhibit contains two clear gaps: constraints are listed as TBD (change freeze, data residency), and assumptions are stated as facts (vendor supports SSO for all users; legal review not required) without validation.

The best next action is to bring the appropriate stakeholders together to confirm:

• High-level requirements ownership and intent (e.g., SSO scope)
• Constraints that govern delivery (e.g., freeze windows, residency)
• Assumptions that must be verified and tracked to closure

Only after these are validated should the team proceed with detailed planning and baselines; otherwise the plan will be built on unknowns.

It targets the missing constraint owners and converts unverified assumptions/TBDs into documented, validated requirements and constraints.

Question 72

Topic: Project Management Concepts

You are coordinating a small project to upgrade the internal wiki. Midway through, an audit finding requires implementing company-wide MFA for all VPN users within 8 weeks.

Operations has a defined “standard change” workflow for work that is low risk, costs under $5,000, takes under 3 days, and does not require user training.

The MFA work is estimated at $45,000, needs new licensing, coordination with HR and Security, user communications/training, and after-hours cutovers.

What is the best next step?

• A. Perform intake to classify the MFA effort and, if it meets project criteria, initiate a separate project for sponsorship and chartering
• B. Escalate the audit finding to the steering committee as an unresolved issue
• C. Add the MFA work to the current wiki project scope and update the WBS
• D. Log a standard change ticket and schedule the work at the next CAB meeting

Best answer: A

What this tests: Project Management Concepts

Explanation: The MFA effort is far larger and riskier than the organization’s definition of a standard operational change. Because it requires budget, cross-functional coordination, communications/training, and controlled cutovers, it has clear project characteristics. The next step is to run it through intake and start a separate, governed project (charter/sponsor) rather than burying it in operations or an unrelated project.

Use project characteristics to decide whether work should be handled as operations or initiated as a separate project. Operations work is typically repeatable and handled through routine workflows (tickets/standard changes). A project is temporary and produces a unique outcome, often requiring dedicated funding, cross-functional resources, higher risk management, and formal approvals.

Here, the MFA effort exceeds the stated standard-change constraints (cost and duration) and introduces additional coordination and adoption work (licensing, HR/Security alignment, training, after-hours cutovers). The best next step is to perform intake/analysis and initiate a separate project so sponsorship, scope, schedule, and governance are set appropriately. Folding it into the wiki project or pushing it straight to CAB skips the prerequisite decision and approvals.

The MFA effort is temporary, unique, cross-functional, and exceeds standard-change limits, so it should be initiated and governed as its own project.

Question 73

Topic: Basics of IT and Governance

A company is selecting a vendor for a new SaaS service desk platform. The project charter includes an ESG requirement: the chosen vendor must (1) maintain an environmental management program and (2) provide annual greenhouse-gas (GHG) emissions reporting with independent assurance to support the company’s supplier reporting.

Which evidence best validates that a vendor meets this sustainability requirement for selection?

• A. Signed self-attestation in the RFP response
• B. Slide deck showing reduced energy use in a product demo
• C. Third-party assured ESG report plus current ISO 14001 certificate
• D. Vendor sustainability web page describing green initiatives

Best answer: C

What this tests: Basics of IT and Governance

Explanation: Sustainability requirements are vendor selection criteria that must be validated with objective, auditable evidence. A third-party assured emissions report demonstrates verified GHG reporting, and an ISO 14001 certificate demonstrates a maintained environmental management system. Together they directly validate compliance with the charter’s ESG requirements.

When sustainability (ESG) requirements affect design choices and vendor selection, they should be treated like other nonfunctional constraints: measurable, included in evaluation criteria, and verified with reliable evidence. Marketing statements and demos may indicate intent, but they don’t provide audit-ready validation.

In this scenario, the requirement has two parts—an environmental management program and independently assured annual GHG reporting—so the best validation is documentation that is both recognized and verifiable (e.g., ISO certification and third-party assurance of emissions reporting). This type of evidence supports procurement defensibility and downstream compliance reporting better than internally generated or vendor-authored claims.

Independent assurance and a recognized certification provide objective proof the vendor meets the ESG requirements.

Question 74

Topic: Project Tools and Documentation

You are coordinating a hybrid project to migrate 200 users to a new SaaS ticketing platform. Go-live is in 10 business days, and the change window requires CAB approval for any scope changes. During UAT, the security lead requests adding SSO enforcement and removing local logins, stating an internal audit is scheduled next month. The product owner verbally agrees in a stand-up and asks the team to “just implement it” to avoid delay.

What is the BEST next action to maintain traceability and governance?

• A. Document the request in the change log and the approval rationale in the decision log, then submit it for the required change-control/CAB review
• B. Update the project schedule and backlog to reflect the added work, then proceed based on the product owner’s verbal approval
• C. Implement the change immediately and capture details in meeting notes after go-live
• D. Ask the security lead to email the request to the team so the requirement is documented, then proceed with implementation

Best answer: A

What this tests: Project Tools and Documentation

Explanation: The project has an explicit governance constraint (CAB approval) and an imminent deadline, so the team needs a clear, auditable trail of what changed and who authorized it. Recording the request in the change log and the approval/justification in the decision log provides traceability, supports audits, and ensures the change follows the established control process before work begins.

Change logs and decision logs support traceability by recording what was requested/changed, when it was raised, impacts, disposition, and who approved it (including the rationale). In this scenario, the request affects security posture and authentication behavior, and the organization requires CAB review for scope changes in the production change window. The best next action is to formally record the change in the change log and capture the approval decision (or the pending decision) and rationale in the decision log, then route it through the defined change-control path. This preserves governance and prevents “verbal approvals” from bypassing required controls when schedules are tight.

Logging the change and the decision creates an auditable trail and ensures the required governance path is followed before implementation.

Question 75

Topic: Project Management Concepts

You are the project coordinator for a hybrid project to implement a new IT service management (ITSM) ticketing system and migrate existing tickets. The sponsor’s draft charter lists the success criteria as “improve customer support” and “make reporting better.” Before the kickoff meeting, you are asked to define clearer, measurable project objectives and success criteria.

Which TWO actions best accomplish this? (Select TWO)

• A. Define measurable acceptance criteria for key deliverables and obtain sign-off
• B. Convert goals into SMART objectives with baselines, targets, and dates
• C. Adopt the vendor’s default SLA metrics as success criteria without changes
• D. Use sprint burndown trends as the primary definition of project success
• E. Defer defining success criteria until after the first prototype review
• F. Set success criteria as completing on time and within budget

Correct answers: A, B

What this tests: Project Management Concepts

Explanation: Measurable objectives and success criteria should be specific, quantifiable, and time-bound so stakeholders can verify outcomes. Translating vague goals into SMART targets establishes what “better” means in the project context. Defining acceptance criteria for major deliverables ensures there are objective pass/fail measures and formal agreement on what “done” looks like.

Clear success criteria connect the project’s work to observable outcomes and make completion verifiable. In this ITSM implementation, “improve support” should be translated into SMART objectives (baseline + metric + target + timeframe), such as reducing average time to resolve incidents or increasing first-contact resolution after go-live. In parallel, define measurable acceptance criteria for major deliverables (configuration, data migration, integrations, reporting) so stakeholders can objectively confirm requirements were met (for example, data migration accuracy percentage, UAT pass criteria, or report refresh performance) and approve them. Progress metrics (like burndown) help manage delivery, but they do not replace outcome-based success criteria that define whether the project achieved its intended results.

SMART objectives make success measurable by defining what will change, by how much, and by when.

Acceptance criteria tie deliverables to objective pass/fail measures that stakeholders can validate and approve.

Questions 76-90

Question 76

Topic: Project Life Cycle Phases

You are in the discovery phase of a CRM SaaS implementation project. The sponsor needs a rough-order-of-magnitude (ROM) cost estimate by tomorrow to decide whether to fund planning.

You have data from a recent, similar CRM project:

• 100 users cost $120,000

For the new project:

• 150 users
• Two additional integrations are expected; add 20% to the analogous cost
• Present ROM as a range of \(\pm 25\%\)

What is the best next step?

• A. Create a ROM of $162,000–$270,000 with assumptions
• B. Request a fixed-price quote from vendors before estimating
• C. Escalate to the steering committee due to unclear requirements
• D. Build a WBS and create a bottom-up estimate

Best answer: A

What this tests: Project Life Cycle Phases

Explanation: In discovery, a ROM estimate is typically built using analogous data and stated adjustment factors, then expressed as a broad range with documented assumptions. Scaling $120,000 from 100 to 150 users and adding 20% for integrations yields an adjusted point estimate. Applying \(\pm 25\%\) provides the ROM range the sponsor needs for a go/no-go decision.

A ROM estimate in the discovery phase is meant to be fast, assumption-driven, and based on limited information—often using analogous project data and simple adjustment factors. Here, you scale the historical cost to the new project size, apply the stated complexity adjustment, and then express the result as a range.

The key is to deliver the ROM range with clear assumptions, rather than delaying for detailed planning artifacts.

Analogous cost scales to $216,000 after adjustments, and \(\pm 25\%\) produces a $162,000–$270,000 ROM range.

Question 77

Topic: Project Life Cycle Phases

You are initiating a SaaS identity-management rollout. The project team is split across three time zones, and several workstreams (network, security, HR) will contribute tasks and information asynchronously.

Which approach best sets up a RAID log and defines ownership so the team can consistently track and act on new items?

• A. Capture risks and issues in meeting minutes and assign owners to action items
• B. Track dependencies in the schedule and track issues in the help desk system
• C. Create a shared RAID log with R/A/I/D sections and an assigned owner per entry
• D. Use a risk register only, and review it during the weekly status call

Best answer: C

What this tests: Project Life Cycle Phases

Explanation: A RAID log is a lightweight, centralized way to capture risks, assumptions, issues, and dependencies with clear ownership. With a distributed team working asynchronously, the most important factor is having one shared, consistently updated source of truth. Assigning an owner to every RAID item ensures accountability for analysis, updates, and escalation.

In project initiation, establishing how the team will capture and manage uncertainties is a key coordination step. A RAID log consolidates risks, assumptions, issues, and dependencies into one place, and it is most effective when each entry has a clearly named owner responsible for keeping it current and driving the next action (mitigation, validation, resolution, or escalation). Because the team is distributed and work happens asynchronously, a shared RAID log (in an agreed repository/tool) prevents items from being lost in emails or scattered documents and supports consistent review in status updates. The key takeaway is to centralize R/A/I/D tracking and make ownership explicit per item, not just per meeting or per document type.

A single shared RAID log with named owners provides one source of truth for a distributed team and makes follow-up accountability clear.

Question 78

Topic: Project Life Cycle Phases

You are initiating a SaaS CRM implementation and want to set up a RAID log that the team will use from kickoff onward. Multiple stakeholders (IT, Sales Ops, Security, and the vendor) will contribute items, and you need clear ownership and follow-up.

Which approach should you AVOID?

• A. Define required fields (type, description, impact, owner, due date) and require an owner at entry
• B. Let contributors log items without an owner, and assign owners during status meetings
• C. Set a review cadence and escalation path for overdue RAID items, including decision points
• D. Assign ownership to the role best able to act (e.g., vendor for deliverables, Security for controls)

Best answer: B

What this tests: Project Life Cycle Phases

Explanation: A RAID log works only if each item has an accountable owner from the start, so it can be tracked, updated, and escalated. In initiation, the goal is to establish a repeatable logging and review approach that prevents items from “floating” without action. Any process that delays ownership undermines control and timely mitigation.

In project initiation, setting up a RAID log is about creating a single place to capture and actively manage risks, assumptions, issues, and dependencies with clear accountability. Each entry should be actionable: it needs an owner (person or role), a due date/next step, and enough detail to support review and escalation. Ownership should be assigned to the party best positioned to resolve or influence the item, not left undefined.

A practical initiation setup includes:

• Required fields and definitions for R/A/I/D categories
• “Owner at entry” rule plus review cadence (e.g., weekly)
• Escalation/decision path when items are overdue or blocking

The key takeaway is that delaying assignment of owners creates gaps in follow-up and increases the chance that critical items are missed.

Delaying ownership makes follow-up ambiguous and allows risks/issues/dependencies to go unmanaged between meetings.

Question 79

Topic: Project Life Cycle Phases

A project team has finished a SaaS identity management rollout. The sponsor says in a meeting that the solution “looks good,” but no one has signed the acceptance document, and the acceptance criteria checklist has not been formally validated.

To meet a new internal priority, the project manager reassigns the implementation team and marks the deliverable as complete without obtaining formal stakeholder sign-off.

What is the most likely near-term impact of this decision?

• A. Loss of future sales opportunities from negative references
• B. Increased probability of a regulatory audit finding next year
• C. Higher long-term employee turnover due to reduced morale
• D. Disputed acceptance that delays project closure and rework

Best answer: D

What this tests: Project Life Cycle Phases

Explanation: In project closing, deliverables must be verified against acceptance criteria and formally accepted by the customer/stakeholders. If the team is released without sign-off, acceptance remains unresolved and disagreements surface immediately when the sponsor asks for closure activities. The near-term result is often delayed closure and rapid rework to meet documented criteria.

The core closing activity is to confirm the delivered product meets documented acceptance criteria and to capture formal acceptance (sign-off). Verbal approval is not the same as formal acceptance; without it, the project cannot cleanly transition to operations, close procurement, or finalize closure documentation. Reassigning the team before validating criteria and obtaining sign-off increases the immediate risk that stakeholders identify gaps, reject the deliverable, or request fixes as a condition of acceptance. That drives near-term schedule and cost impact through unplanned rework and delays to closure activities. The key takeaway is to validate acceptance criteria and secure formal acceptance before declaring the deliverable complete and releasing resources.

Without validating acceptance criteria and getting sign-off, the customer can reject the deliverable and force immediate rework before closure.

Question 80

Topic: Project Life Cycle Phases

You are planning the rollout of a new SaaS-based IT service management (ITSM) tool to replace the company’s on-prem ticketing system. Go-live is in 6 weeks.

Exhibit: Risk and constraint excerpt

R1: Ticketing outage >30 min during business hours is unacceptable (High)
R2: Call center must continue creating tickets during cutover (High)
R3: Compliance requires stored evidence of test results and approvals (Med)
Constraint: Only production change window is Sun 2:00–4:00 a.m.
Dependency: SSO integration and email ingestion must be validated end-to-end

Which rollout and validation approach best fits the risks and constraints in the exhibit?

• A. Pilot one site, parallel run, UAT sign-off, rollback plan
• B. Big-bang cutover with smoke testing only
• C. Incremental production changes without a rollback plan
• D. Rely on vendor demo as acceptance; deploy all at once

Best answer: A

What this tests: Project Life Cycle Phases

Explanation: The exhibit shows very low tolerance for downtime during business hours, a need to keep ticket creation running through cutover, and a compliance requirement for test evidence and approvals. A pilot with a parallel run enables validation of SSO and email ingestion end-to-end while limiting blast radius. A rollback plan and UAT sign-off support risk control and auditability within the limited change window.

A rollout plan should match stakeholder risk tolerance and operational constraints. Here, the organization cannot accept more than 30 minutes of outage during business hours and must maintain ticket intake during cutover, so a “big-bang” approach is too risky. A pilot (phased rollout) to a single site or small user cohort, combined with a short parallel run, reduces impact if defects appear and ensures the business can continue creating tickets.

The validation plan should include end-to-end testing for the stated dependencies (SSO and email ingestion), documented test results, and a formal approval (UAT sign-off) to satisfy compliance. Because the only production window is limited, the plan should also include rehearsed cutover steps and a rollback procedure that can be executed within the window.

This approach controls risk while still enabling progress toward the 6-week go-live.

A pilot with parallel operations, documented validation, and rollback best aligns to low outage tolerance and compliance evidence needs.

Question 81

Topic: Basics of IT and Governance

A project team is preparing to go live with a new SaaS-based ticketing system that will be supported by the internal service desk. The change window is next week, and the CAB requires evidence that operations/support is ready to take ownership after deployment.

Which artifact best validates operational readiness and an effective handover?

• A. A project status report showing 90% of tasks completed
• B. Meeting minutes from the final stakeholder review meeting
• C. Sprint velocity and burndown charts for the last two iterations
• D. A completed and signed handover/operational readiness checklist (runbooks, monitoring, escalation, and ownership)

Best answer: D

What this tests: Basics of IT and Governance

Explanation: Operational readiness is validated by evidence that support can run and troubleshoot the service after cutover, not by general progress indicators. A handover/operational readiness checklist captures the specific items operations needs (runbooks, monitoring, escalation paths, and ownership) and provides explicit sign-off that those items are complete.

To ensure a smooth transition to steady-state, operations/support should be engaged before go-live to confirm they can monitor, support, and maintain the delivered solution. The strongest validation is an operational readiness or handover checklist (often paired with a transition plan) that documents and confirms completion of key support prerequisites such as runbooks, monitoring/alerting, access, escalation/SLAs, ownership, and knowledge transfer.

This artifact is purpose-built to demonstrate readiness and accountability for the support organization, which is what CAB and go-live governance typically want as acceptance evidence. Progress reports, agile delivery metrics, and meeting notes can indicate activity occurred, but they do not confirm operational capability or a formal transfer of responsibility.

A signed readiness/handover checklist directly evidences support procedures, monitoring, escalation, and ownership are in place before go-live.

Question 82

Topic: Project Tools and Documentation

You need to schedule a recurring requirements workshop for a SaaS implementation. Required attendees include SMEs in New York, London, and Bangalore, and several have declined the initial invite citing “outside working hours.” Before selecting a new time, what should you verify or obtain FIRST to reduce scheduling friction using calendar/scheduling tools?

• A. A commitment from HR to enforce attendance for all invited participants
• B. Each required attendee’s time zone, working hours, and free/busy availability (including holidays/blackout dates)
• C. A finalized list of workshop agenda topics and the timebox for each topic
• D. The executive sponsor’s preferred recurring time for the workshops

Best answer: B

What this tests: Project Tools and Documentation

Explanation: The immediate problem is that the proposed meeting time conflicts with participants’ working hours across time zones. The first step is to collect accurate availability signals (time zones, working hours, holidays/blackout dates, and free/busy) so a scheduling tool can identify feasible overlapping windows and prevent repeated declines.

When scheduling across regions, you can’t choose a workable time until you know the constraints the calendar tool will use to find overlaps. Start by confirming each required attendee’s time zone and standard working hours, and collecting free/busy information plus known blackout dates (regional holidays, on-call rotations, planned PTO) via shared free/busy access or a scheduling poll. With those inputs, you can propose 2–3 viable windows or set a rotation that fairly distributes inconvenience, and the tool can correctly display local times and avoid conflicts. Picking a time based on preference, agenda content, or enforcement assumptions doesn’t solve the root cause: missing/incorrect availability constraints.

You need accurate time zone and availability inputs (free/busy, working hours, holidays) before proposing meeting windows that the scheduling tool can optimize.

Question 83

Topic: Project Management Concepts

A project manager is coordinating a CRM SaaS cutover scheduled for tonight. Two hours before the change window, the vendor reports a data sync defect that could affect customer records. The PM must quickly align the vendor, the internal app owner, the on-call operations lead, and the CAB approver on a go/no-go decision.

Which communication approach should the PM NOT use in this situation?

• A. Add the issue to the next weekly status meeting agenda
• B. Hold a brief focused meeting and follow up with a written decision summary
• C. Start an immediate bridge call with the decision makers
• D. Send a high-priority message to the on-call channel and page the CAB approver

Best answer: A

What this tests: Project Management Concepts

Explanation: For an urgent, high-impact decision, the project manager should use synchronous, direct methods to reach the right stakeholders quickly. Deferring communication to a routine cadence delays decisions and increases operational risk during the change window. Escalation should match the urgency and the need for immediate stakeholder alignment.

The core concept is selecting a communication method that matches urgency, complexity, and audience. A potential customer-data impact right before a change window requires fast, interactive communication with the specific decision makers (vendor, app owner, operations, and CAB approver) to clarify impacts and decide go/no-go.

Appropriate methods here are those that:

• Reach the right people immediately (paging/priority messaging)
• Enable rapid clarification and agreement (bridge call/brief meeting)
• Create an audit trail after the decision (written recap/decision log)

Relying on a routine weekly status meeting is an anti-pattern because it is neither timely nor targeted to the urgent decision and escalation needs.

A weekly meeting is too slow and passive for an urgent, high-impact go/no-go decision.

Question 84

Topic: Project Life Cycle Phases

You are closing an IAM (identity and access management) upgrade project. The solution is live, but the project sponsor asks you to close the project this week.

Exhibit: Transition-to-Operations checklist (excerpt)

Item                        Status      Owner
Operational runbook          Draft       Project team
Monitoring/alert thresholds  Not set     NOC
On-call escalation path      TBD         Service desk
Support team ownership       TBD         Service desk mgr
Knowledge transfer session   Not scheduled Project team

Based on the exhibit, what is the BEST next action to ensure a proper handoff and long-term ownership?

• A. Schedule the handover session and obtain support ownership sign-off
• B. Extend the warranty period so the project team stays on-call
• C. Close the project and let operations finalize remaining items
• D. Move the incomplete items to the issue log and archive project documents

Best answer: A

What this tests: Project Life Cycle Phases

Explanation: The checklist indicates transition items that are not complete and, critically, operational ownership is still “TBD.” In project closing, you should complete the handover by scheduling knowledge transfer and securing explicit acceptance of support ownership (who owns the service, monitoring, and escalation) so the deliverable has a long-term operational home.

Transitioning deliverables to operations/support is a required part of project closing, not an optional follow-up. The exhibit shows key operational readiness items (runbook, monitoring thresholds, escalation path) and, most importantly, the support ownership assignment are incomplete or unassigned (TBD). Before closing, the project manager should coordinate a formal handover to the service desk/NOC, complete the remaining support artifacts, and confirm long-term ownership through an agreed acceptance step (often documented via sign-off, a transition checklist, or a service ownership assignment).

Practical next steps include:

• Schedule and run a knowledge transfer session
• Assign named operations owners for monitoring and escalation
• Finalize the runbook and validate alerting
• Capture operational acceptance/ownership in the handover record

Extending project-team coverage may help temporarily, but it does not establish operational ownership.

The exhibit shows ownership and support readiness gaps that must be resolved and formally accepted by operations before closing.

Question 85

Topic: Project Management Concepts

You are managing a SaaS reporting enhancement using Scrum (2-week sprints). A compliance stakeholder submits a new request during an active sprint.

Exhibit: Change/request log (excerpt)

Sprint 6 capacity: 40 pts | Committed: 38 pts
ID: CR-08
Request: Add "Admin audit export" report
Reason: New compliance question from auditors
Estimate: 5 pts
Notes: Not in Sprint 6 goal; PO available today
Status: Submitted

Based on the exhibit, what is the BEST next action?

• A. Reject CR-08 because sprint scope cannot change until the next release cycle
• B. Capture CR-08 as a backlog item and have the product owner reprioritize it with the team
• C. Direct the team to add CR-08 to Sprint 6 without changing any committed work
• D. Submit CR-08 to the change control board for approval and rebaseline the project

Best answer: B

What this tests: Project Management Concepts

Explanation: Because the work is being delivered using Scrum, the request should be handled through backlog refinement and prioritization with the product owner. The exhibit shows the item is new, estimated, and not aligned to the current sprint goal, so it should enter the product backlog and be scheduled based on value and capacity rather than treated as a formal baseline change.

In predictive projects, scope changes are typically processed through formal change control (impact analysis, approval, and updates to baselines). In agile/hybrid delivery, change is expected and is usually managed by updating and reprioritizing the product backlog.

Here, the exhibit shows a Scrum team mid-sprint with 38 of 40 points committed and a new 5-point request that is not part of the sprint goal. The appropriate handling is to:

• Record the request as a user story/backlog item
• Have the product owner prioritize it against other work
• Only pull it into the current sprint if the team and product owner renegotiate the sprint (e.g., swap out comparable scope)

Key takeaway: agile changes are managed primarily by reprioritization; predictive changes are managed by formal change control and rebaselining.

In agile delivery, changes are typically handled by adding/refining backlog items and reprioritizing (including trading scope within a sprint) rather than formal rebaselining.

Question 86

Topic: Basics of IT and Governance

You are gathering requirements for a new mobile app that lets customers schedule service visits. A stakeholder asks to “collect customer details (including date of birth and a photo ID) so we can personalize offers later,” but they have not explained how the data will be used or how long it must be kept.

What should you ask/verify FIRST before finalizing the requirement?

• A. Whether the vendor’s SLA provides 99.9% uptime for the scheduling service
• B. Which specific data elements are truly needed, their purpose, and the required consent/legal basis
• C. Whether the marketing team can provide the offer content by the planned release date
• D. Which encryption standard the app will use for stored customer records

Best answer: B

What this tests: Basics of IT and Governance

Explanation: Before accepting collection of sensitive customer data, you must clarify the business purpose and confirm the lawful basis/consent for each intended use. This allows you to apply data minimization (only collect what is necessary) and define privacy requirements such as retention and permitted uses. Those privacy decisions drive the rest of the solution requirements.

When a requirement proposes collecting personal data (PII), the project team should first clarify how the data will be used and whether the collection is necessary for that purpose. This enables data minimization (avoid collecting unnecessary fields like photo ID if not required) and ensures the requirement includes the appropriate consent or other lawful basis for processing (especially for secondary uses like marketing). Once purpose, necessity, and consent/legal basis are clear, you can then refine related requirements such as retention period, access controls, and security controls. Starting with technical controls (like encryption) is important, but it is premature until you know what data must be collected and why.

This clarifies PII use, supports data minimization, and ensures consent/legal basis is built into the requirement before design decisions are made.

Question 87

Topic: Project Life Cycle Phases

You are executing a data center network segmentation project. Go-live must occur during a pre-approved CAB change window in 6 weeks. The only firewall engineer is reassigned to an unplanned operations incident for the next 2 weeks, and their configuration work is a predecessor to security testing that must start 3 weeks before go-live. The project budget is capped, and any added labor requires sponsor approval.

What is the BEST next action to resolve the resource conflict and maintain delivery flow?

• A. Pause project work until the firewall engineer returns
• B. Re-sequence near-term work and secure temporary firewall coverage; update the schedule
• C. Request the CAB to move the change window to a later date
• D. Direct the team to work overtime to absorb the firewall tasks

Best answer: B

What this tests: Project Life Cycle Phases

Explanation: This is a resource constraint on a predecessor activity that threatens a fixed go-live window. The best response is to adjust the plan to keep other work progressing while actively resolving the constraint by obtaining alternate coverage through the proper channels. Updating the schedule and communicating the revised near-term plan maintains delivery flow and manages expectations.

During execution, a resource conflict on a critical predecessor should be handled by quickly analyzing schedule impact and adjusting work sequencing so the team can continue delivering while the constraint is addressed. Here, firewall work gates security testing and the CAB window is fixed, so waiting or immediately pushing dates creates avoidable schedule risk.

A practical next action is:

• Re-sequence tasks that do not depend on the firewall engineer
• Coordinate with the functional manager/vendor pool for temporary coverage or partial allocation
• Update the schedule (and RAID/communications as needed) and seek sponsor approval if added labor is required

The key takeaway is to keep the project moving by re-planning around the constrained resource while following approval and change-control expectations.

Replanning around the constrained resource while obtaining coverage preserves the testing dependency and keeps work moving without bypassing governance.

Question 88

Topic: Project Management Concepts

A project team has completed a new SSO integration for a SaaS application. All UAT test cases tied to the acceptance criteria passed, and the business owner wants the release moved into production within 24 hours. The vendor’s final invoice cannot be paid until the deliverable is formally accepted, and the organization requires an auditable record of acceptance.

Which action best confirms deliverable acceptance with stakeholders while meeting the constraints?

• A. Announce acceptance in the status meeting notes and proceed with production deployment
• B. Send a summary email stating the deliverable is accepted unless objections are raised by end of day
• C. Ask the product owner for a verbal approval and record it in the issue log
• D. Obtain stakeholder e-signature on an acceptance form that references the acceptance criteria and UAT results

Best answer: D

What this tests: Project Management Concepts

Explanation: Deliverable acceptance should be confirmed against predefined acceptance criteria and captured as a formal, auditable sign-off. An e-signed acceptance form that references the criteria and UAT evidence meets governance needs, enables vendor payment, and supports the near-term production release. It also reduces disputes by clearly documenting what was accepted and when.

Deliverable acceptance is a quality control checkpoint: stakeholders confirm the deliverable meets the agreed acceptance criteria, and the project documents that decision. In this scenario, acceptance must be both timely (24-hour release window) and auditable (required for payment and governance). The best approach is to capture explicit stakeholder sign-off on a deliverable acceptance record that points to the specific acceptance criteria and objective evidence (such as UAT results). This creates a durable audit trail, supports financial/procurement processes, and reduces the risk of later disagreement about whether the deliverable met expectations. Informal approvals (verbal, meeting notes, or “silence is consent”) are weaker controls and can fail audits or payment requirements.

A formal acceptance record tied to documented criteria provides auditable sign-off and supports vendor payment without delaying the release.

Question 89

Topic: Project Tools and Documentation

A project team is distributed across three time zones implementing a new SaaS ticketing system. The last two milestones were missed due to rework, and stakeholders disagree on what was “approved.” Requirements are stored in multiple emailed spreadsheets, while decisions and change requests are made in chat threads and not reflected in the backlog. Task ownership is also unclear because action items are not captured after virtual meetings.

Which is the MOST likely underlying cause?

• A. The team’s time zone differences prevent effective collaboration
• B. The schedule was built with overly optimistic estimates
• C. The team lacks a shared, controlled source of truth for requirements, decisions, and changes
• D. The vendor is failing to deliver the SaaS configuration on time

Best answer: C

What this tests: Project Tools and Documentation

Explanation: The clues point to collaboration breakdowns, not a planning or vendor problem. When requirements and decisions live in emailed files and chat threads without being reconciled into shared artifacts, teams work from different versions and changes go uncontrolled. Establishing shared docs/backlog as the single source of truth with clear ownership prevents repeated rework and disputes over approvals.

In distributed teams, missed milestones with heavy rework often come from fragmentation of project information. Here, requirements are in multiple emailed spreadsheets and change/decision discussions happen in chat without being captured in a shared backlog or decision log. That creates competing “truths,” unclear ownership for updates, and uncontrolled changes—so people implement different interpretations and then redo work.

A lightweight collaboration practice to prevent this is to:

• Maintain one shared requirements/backlog location (with version control)
• Capture decisions and changes in shared logs and link them to work items
• Assign explicit owners for artifact updates and meeting action items

The time zone constraint may exist, but the stronger root cause is the lack of shared, governed collaboration artifacts.

Scattered docs and chat-only decisions indicate missing collaboration norms for shared documentation, ownership, and change tracking.

Question 90

Topic: Project Life Cycle Phases

A project team is closing an ITSM/ticketing SaaS implementation. The approved business case targets a 20% reduction in mean time to resolve (MTTR) and a 10-point increase in customer satisfaction (CSAT) within 6 months of go-live.

Constraints:

• The project ends at go-live + 2 weeks (warranty period)
• No budget for new tooling or custom development after close
• Operations will own the platform after handoff

Which approach best defines how benefits will be tracked post-project and establishes appropriate follow-up checkpoints while meeting the constraints?

• A. Create a benefits realization plan with KPI definitions, baselines, data sources, benefit owners in Operations, and 30/90/180-day checkpoint reviews using existing ITSM reports
• B. Hold a single benefits review 12 months after go-live and compare results to industry benchmarks
• C. Track benefits by confirming training completion and go-live communications are delivered
• D. Build a custom analytics dashboard after close to automate benefit reporting and alerts

Best answer: A

What this tests: Project Life Cycle Phases

Explanation: Benefits tracking after project close is best handled with a benefits realization plan that defines what will be measured, who owns the measures, where the data comes from, and when results will be reviewed. Using existing ITSM reporting satisfies the “no new tooling” constraint while still enabling objective verification. Scheduled 30/90/180-day checkpoints align to the 6-month benefits window and ensure accountability after handoff to Operations.

In project closing, the project manager should ensure the organization can validate the business case outcomes after the project team disbands. A benefits realization plan (or benefits management plan) does this by documenting the benefit measures and the post-project follow-up cadence.

A solid plan for this scenario should include:

• KPI definitions tied to the business case (MTTR and CSAT)
• Baselines (pre-go-live values) and targets (20% MTTR reduction, +10 CSAT)
• Data sources and reporting method (existing ITSM reports/surveys)
• Named benefit owners in Operations and review participants (sponsor/ops lead)
• Scheduled checkpoints (e.g., 30/90/180 days) with actions if benefits lag

The key takeaway is to operationalize benefit measurement and ownership without creating new post-close costs or dependencies.

It ties the business-case outcomes to measurable KPIs with owners, baselines, and scheduled checkpoints using existing reporting, requiring no new post-close spend.

Continue with full practice

Use the Project+ Practice Test page for the full PM Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.

Focused topic pages

• Project+: Project Management Concepts
• Project+: Project Life Cycle Phases
• Project+: Project Tools and Documentation
• Project+: Basics of IT and Governance

Free review resource

Use the full PM Mastery practice page above for the latest review links and practice route.