Business Environment: strategy and project benefits practice questions

Define activities, then estimate activity durations, then sequence activities, then determine the critical path

Why it fails: This order is incorrect because "Sequence Activities" must logically precede "Estimate Activity Durations." Establishing the dependencies, logical relationships, and applying leads or lags through sequencing provides the necessary context for more accurate duration estimates. Without understanding how activities relate to each other and potential resource conflicts across parallel paths, duration estimates might be less reliable and fail to account for the overall project's logical flow and constraints, making the subsequent critical path determination flawed.

Sequence activities, then define activities, then estimate activity durations, then determine the critical path

Why it fails: This sequence is fundamentally flawed because "Sequence Activities" cannot occur before "Define Activities." You must first identify and break down the work into discrete, manageable schedule activities before you can establish any logical relationships or dependencies between them. Attempting to sequence undefined or vaguely conceptualized activities would result in an incomplete, inaccurate, or impossible schedule network diagram, rendering all subsequent steps meaningless.

Define activities, then determine the critical path, then sequence activities, then estimate activity durations

Why it fails: This order is incorrect because "Determine the Critical Path" is a calculation performed on a fully developed schedule network, making it impossible to execute before "Sequence Activities" and "Estimate Activity Durations." The critical path analysis requires all activities to be logically linked with their dependencies (sequencing) and to have assigned durations (estimation). Without these foundational steps, there is no complete network diagram to analyze for the longest path, earliest/latest dates, or total float.

Let the teams continue as they have already started work.

Why it fails: Allowing teams to continue working on features that do not align with strategic themes represents a significant waste of organizational resources and effort. This action directly contradicts the principles of value delivery and economic prioritization central to SAFe, as the work would not contribute to the organization's overarching business objectives. Ignoring the misalignment undermines the entire purpose of strategic planning and portfolio governance, leading to inefficient outcomes.

Redirect the teams to work on features that align with the strategic themes.

Why it fails: While aligning with strategic themes is crucial, an RTE typically lacks the authority to unilaterally redirect an entire Agile Release Train (ART) to new features, especially after work has commenced. Such a significant change involves re-prioritization, potential scope adjustments, and impact analysis across multiple teams and dependencies, which requires collaboration and approval from Product Management, Product Owners, and potentially Portfolio Management. The RTE's role is to facilitate the ART, not to dictate its strategic content or make large-scale content changes.

Update the strategic themes to match the current work.

Why it fails: Strategic themes are high-level business objectives defined by enterprise executives and portfolio management to provide long-term strategic direction for the entire organization. Updating these foundational themes to simply match ongoing tactical work at the ART level reverses the strategic planning process. This approach undermines organizational governance, allowing execution to dictate strategy rather than strategy guiding execution, which can lead to a loss of focus on critical long-term goals and market opportunities.

Instruct the team to start working on the change immediately.

Why it fails: Directing the team to immediately implement an unapproved change completely bypasses the established change management process and the authority of the Change Control Board (CCB). This action constitutes unauthorized work, can lead to scope creep, misallocation of resources, and potentially jeopardize the project's baselines and overall success. All changes must follow the formal process of analysis, approval, and integration.

Communicate the change to all stakeholders before approval.

Why it fails: Communicating a proposed change to all stakeholders before it has been formally analyzed, approved, and integrated into the project plan is premature and can lead to significant confusion and rework. Stakeholders might act on unapproved information, causing misaligned expectations or initiating work based on a change that may ultimately be rejected. Formal communication should only occur once the change is approved and its implications are fully understood.

Immediately stop the project until the requirement is fully understood

Why it fails: Stopping the project may be too drastic without first analyzing the impact.

Ask the legal department to handle the requirement separately

Why it fails: The PM should integrate the response within the project, not delegate entirely.

Continue with the project as planned because the requirement was not in the initial scope

Why it fails: Ignoring regulatory requirements can lead to non-compliance and legal issues.

Risk register

Why it fails: Risk register contains risks, not benefits metrics.

Project schedule

Why it fails: Schedule does not contain benefits metrics.

Ignore the issue because the vendor will likely resolve it

Why it fails: Passivity forfeits the schedule float and lets the critical-path delay compound unchecked. It is tempting when the vendor sounds confident, but procurement risk demands active monitoring; ignoring a notified supply-chain disruption breaches the project manager's risk-response duty.

Ask the team to work overtime to compensate for the delay

Why it fails: Overtime cannot manufacture a component the vendor has not shipped, so it burns cost without recovering the critical path. It is tempting as a fast schedule-compression lever, but crashing only works where the delayed activity is performed in-house and remains under the team's control.

Immediately terminate the contract with the vendor and hire a new one

Why it fails: Termination triggers breach, reprocurement and legal costs, and a replacement vendor cannot deliver faster than the disruption allows. It is tempting as decisive vendor management, yet contract closure is warranted only after documented default and failed corrective action, not on first notification.

Ask the team to begin work on the module immediately to accommodate the stakeholder

Why it fails: Implementing scope changes without going through change control violates the change management process.

Inform the stakeholder that no changes can be made once the project has started

Why it fails: This is incorrect — changes can be made through the formal change control process. Refusing outright without assessment is not the PMI approach.

Add the requirement to the product backlog and let the team address it in a future sprint without formal approval

Why it fails: Adding work to the backlog without change control approval bypasses formal governance and violates the project management plan.

Immediately reduce inspections as requested to stay on budget

Why it fails: Immediately reducing inspections without prior analysis is a critical error, as it bypasses essential quality management processes and risk assessment. Such a unilateral decision could severely compromise the project's quality standards, potentially leading to increased defects, rework, safety hazards, and ultimately higher costs in the long run. A project manager must always assess the impact of any proposed change on all project constraints and objectives before implementation.

Refuse the request and stop all cost-cutting measures

Why it fails: Refusing the request outright and halting all cost-cutting measures without any analysis or exploration of alternatives is an unprofessional and unproactive response. A project manager is expected to be a problem-solver, exploring all viable options to address project challenges like budget overruns. This approach fails to engage stakeholders constructively or seek mutually beneficial solutions, potentially escalating conflict rather than resolving the underlying issue.

Agree to reduce inspections but document it as a decision

Why it fails: Simply agreeing to reduce inspections and documenting the decision is insufficient and demonstrates a failure to follow proper project governance. While documentation is part of the process, it does not substitute for a thorough impact analysis, formal stakeholder approval, or adherence to the integrated change control process. This action exposes the project to unmitigated risks and potential quality degradation without proper assessment or formal authorization.

Ask the team to work overtime to catch up

Why it fails: Asking the team to work overtime may temporarily increase output but leads to burnout and does not address the root cause of the velocity drop.

Add more team members to increase capacity

Why it fails: Adding more team members can disrupt team cohesion and introduce a learning curve, often reducing velocity in the short term.

Reduce the sprint scope to match the current velocity

Why it fails: Reducing sprint scope without understanding why velocity dropped may mask underlying issues and prevent long-term improvement.

Escalate the issue to the project sponsor immediately

Why it fails: Escalating to the project sponsor immediately is not the first step because a contingency plan already exists; the PM should execute the plan before escalating.

Conduct a new risk assessment for the vendor delay

Why it fails: Conducting a new risk assessment is unnecessary because the risk and its response are already documented; this would delay action.

Add a 3-week buffer to the project schedule to absorb the delay

Why it fails: Adding a 3-week buffer is not following the contingency plan; the plan should be executed first to see if the backup supplier can mitigate the delay.

Ignore the audit report until the project is complete

Why it fails: Ignoring an audit report is a severe breach of project governance and professional responsibility, directly contravening the PMP Code of Ethics. Non-compliance, especially concerning data, can carry significant legal, financial, and reputational risks for the organization and the project. Promptly addressing audit findings is mandatory to mitigate potential penalties, maintain stakeholder trust, and ensure the project adheres to all regulatory and organizational standards throughout its lifecycle, rather than deferring critical issues.

Escalate the audit findings to executive management immediately

Why it fails: While executive management must ultimately be informed of significant compliance issues, immediate escalation without prior analysis and a proposed course of action is premature and demonstrates a lack of project management leadership. The project manager's role is to first analyze the findings, conduct a root cause analysis, and formulate a preliminary remediation plan. Presenting problems with potential solutions or a clear action plan to executive management is a more professional and effective approach, allowing them to make informed decisions rather than simply reacting to an unanalyzed issue.

Reassign the project team to different tasks to avoid further issues

Why it fails: Reassigning the project team is a superficial and ineffective response that fails to address the core problem of non-compliance. This action merely shifts personnel without resolving the underlying systemic or process deficiencies that caused the issue, potentially allowing the same problems to manifest in other areas or with different teams. A responsible project manager focuses on identifying and correcting the root causes of non-compliance, ensuring that the project's processes and outputs meet required standards, rather than avoiding the problem by reallocating resources.

Ensure that the current project's scope management plan includes a robust change control process

Why it fails: Lessons learned frequently highlight challenges with uncontrolled changes and scope creep in previous projects. Therefore, proactively ensuring the current project's scope management plan incorporates a robust change control process is a direct and highly effective application of such lessons. This mitigates future risks by establishing clear procedures for evaluating and approving any proposed modifications, thereby protecting the project baseline.

Request approval from the sponsor to implement the lessons

Why it fails: Implementing lessons learned, particularly those related to internal process improvements or adjustments within the project manager's authority, typically does not require formal sponsor approval. Seeking sponsor approval for every application of lessons learned would introduce unnecessary bureaucratic delays and hinder the project manager's ability to proactively adapt and improve project execution. Sponsor approval is generally reserved for significant changes impacting project baselines or strategic objectives.

Adopt agile without informing the sponsor.

Why it fails: Adopting a significant methodological change like agile without informing the sponsor is a breach of project governance and transparency. The sponsor is a key stakeholder responsible for project funding and strategic alignment, and such a unilateral decision undermines trust and could lead to a lack of support or even project termination. Project managers are ethically obligated to maintain open communication and seek approval for major deviations from the agreed-upon project approach.

Follow the sponsor's directive and use waterfall.

Why it fails: While the sponsor's input is crucial, a project manager's role includes providing professional judgment and advising on the best approach for project success, especially when the team's expertise suggests otherwise. Blindly following a directive that may be suboptimal for a software development project, which often benefits from agile's iterative nature, could lead to inefficiencies, increased risks, and potential project failure. The PM should advocate for the team's insights and the project's best interests.

Escalate to the PMO to resolve the conflict.

Why it fails: Escalating to the Project Management Office (PMO) should be considered a last resort when direct attempts at conflict resolution have failed. The project manager's primary responsibility is to proactively manage conflicts and facilitate solutions among project stakeholders. Immediately escalating bypasses the opportunity for collaborative problem-solving and may be perceived as an inability to manage stakeholder relationships, which is a core competency for a PMP.

Reject the request to avoid scope creep.

Why it fails: Rejecting discards a request the project manager has already judged to add significant business value, and the project manager lacks authority to dismiss it unilaterally. This tempts as scope-creep protection, but change requests belong in Perform Integrated Change Control for the CCB to assess.

Accept the request and manage the risk with a contingency plan.

Why it fails: Accepting bypasses integrated change control, altering scope and baselines without approval, and a contingency plan cannot authorise unapproved scope. This tempts when value seems obvious, but the change request must go through the Perform Integrated Change Control process for evaluation and approval.

Ignore the request because it is out of scope.

Why it fails: Ignoring the request breaches the project manager's duty to record and process every change request through Perform Integrated Change Control, leaving no documented decision. This tempts when the request looks clearly out of scope, yet even rejected requests must be logged, evaluated and formally dispositioned.

To define how the project will be executed, monitored, and controlled.

Why it fails: This statement is incorrect because defining how a project will be executed, monitored, and controlled is the explicit purpose of the Project Management Plan. The Project Management Plan is a comprehensive document that integrates all subsidiary plans and baselines, detailing the strategies and processes for managing the project work, scope, schedule, cost, quality, resources, communications, risk, procurement, and stakeholder engagement throughout the project lifecycle. The business case, conversely, is developed much earlier to justify the project's existence, not to plan its detailed execution.

To outline how the project's benefits will be delivered and measured.

Why it fails: This statement is incorrect because outlining how a project's benefits will be delivered and measured is the primary function of the Benefits Management Plan. While the business case identifies the potential benefits that justify the project, the Benefits Management Plan specifically details the processes for creating, maximizing, and sustaining those benefits. This plan defines the benefit owner, metrics, assumptions, and the timeline for benefit realization, often extending beyond the project's completion.

To authorize the project manager to use organizational resources.

Why it fails: This statement is incorrect because authorizing the project manager to use organizational resources is the specific purpose of the Project Charter. The Project Charter is a formal document issued by the project initiator or sponsor that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities. The business case, while providing justification, does not grant any formal authority to the project manager.

Immediately stop the project to avoid further losses.

Why it fails: Immediately stopping the project without a thorough re-evaluation of its business case and strategic alignment is a reactive decision that lacks a data-driven approach. Project termination, even when necessary, should follow a structured process involving updated financial analysis, risk assessment, and stakeholder consultation to ensure all implications are understood. This avoids potential loss of sunk costs without confirming the project's continued unviability.

Continue the project as planned because the strategic goal has not changed.

Why it fails: Continuing the project as planned, despite a change in the underlying conditions that impact its benefits, is irresponsible project governance. While the overarching strategic goal might persist, the project's ability to deliver the expected value or justify its investment may have significantly diminished. A re-evaluation of the business case is critical to ensure the project remains viable and aligned with current organizational priorities and resource allocation.

Add more features to differentiate the product from the competitor's.

Why it fails: Arbitrarily adding more features to the product without a formal change control process is a significant risk, potentially leading to scope creep, increased costs, and schedule delays. Such a decision would bypass necessary impact analysis, stakeholder approval, and re-evaluation of the project's business case, which is essential for maintaining project integrity and delivering the intended value. This approach is reactive and lacks proper governance.

Work breakdown structure (WBS) for benefit delivery.

Why it fails: The Work Breakdown Structure (WBS) is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. It is a fundamental component of scope management, detailing *what* work is needed, not *how* the project's outputs will generate value or *when* that value will be measured. Therefore, it is distinct from the Benefits Management Plan, which focuses on benefit realization.

Business case assumptions and constraints.

Why it fails: The business case provides the foundational justification for a project, outlining its objectives, expected benefits, and the initial assumptions and constraints under which it is conceived. While the Benefits Management Plan is developed based on the information presented in the business case, it does not replicate or contain the business case's underlying assumptions and constraints. Instead, the plan details the *process* for managing the realization of the benefits identified in that business case.

Project charter approval signatures.

Why it fails: The project charter is a formal document that authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities. The approval signatures on the project charter signify official project initiation and stakeholder agreement to the project's high-level objectives. These signatures are a procedural element of the charter itself, not a substantive component of the Benefits Management Plan, which focuses on the detailed management of benefit realization.

Escalate the issue to the steering committee for a decision.

Why it fails: Escalating an issue to the steering committee without first conducting a thorough analysis and proposing viable solutions is generally considered an abdication of the project manager's responsibility. The PM is expected to identify problems, analyze their impact, and formulate recommendations, presenting the committee with options and a preferred course of action rather than just a dilemma. This demonstrates a lack of proactive problem-solving and strategic thinking.

Implement option 1 to control costs and then inform the sponsor of the reduced benefits.

Why it fails: Unilaterally implementing a cost-cutting measure that potentially reduces project benefits, especially without prior analysis of its impact on grant compliance, is a high-risk approach. Informing the sponsor *after* the fact demonstrates a lack of stakeholder engagement and could lead to severe consequences, including grant revocation or loss of trust. The project manager must ensure that any changes align with project objectives and constraints, seeking approval for significant deviations.

Request additional funding from the CFO, emphasizing the risk of non-compliance.

Why it fails: Requesting additional funding from the CFO solely by emphasizing non-compliance risk, without a detailed business case, cost-benefit analysis, or exploration of alternative solutions, is unlikely to be successful. Financial stakeholders require comprehensive justification, including a clear understanding of the return on investment, the impact of not funding, and a well-structured proposal demonstrating due diligence. A simple request without a strategic financial argument will likely be rejected.

The business case justifying the project

Why it fails: The business case is a foundational document created *before* the project is authorized, providing the necessary information to determine if the project is worth the investment. While it outlines the project's justification and expected benefits, it serves as input to the project charter and subsequently influences the benefits management plan, rather than being an integral component of the plan itself. Its primary role is to justify the project's initiation, not to detail the ongoing management of benefits realization.

The project's strategic objectives

Why it fails: The project's strategic objectives articulate how the project aligns with the organization's overarching long-term goals and mission. While the benefits management plan must ensure that the project's benefits contribute to these strategic objectives, the objectives themselves are formally documented in the project charter, which authorizes the project. The benefits management plan details *how* the benefits contributing to these objectives will be managed, not the objectives themselves.

The project scope statement

Why it fails: The project scope statement meticulously defines the work required to deliver the project's product, service, or result, including its boundaries, deliverables, and acceptance criteria. While the project's scope is executed to enable the realization of benefits, the scope statement itself is a component of the project management plan, specifically the scope baseline. The benefits management plan focuses on the *outcomes* and *value* derived from the project's deliverables, not the deliverables themselves.