Select Two (Multi-Select) Questions

The cost of implementing the resolution technique.

Why wrong: Conflict resolution techniques primarily involve communication, negotiation, and mediation, which are generally low-cost activities focused on human interaction rather than significant financial outlay. While some external mediation might incur fees, the primary concern when selecting a technique is its effectiveness in resolving the underlying issue and preventing adverse project impacts. Prioritizing cost over efficacy could lead to unresolved conflicts, ultimately incurring far greater expenses through delays, rework, or damaged team morale.

The organizational hierarchy and reporting structure.

Why wrong: While organizational hierarchy defines formal communication channels and authority, it is less critical in *selecting* a conflict resolution technique than the specific nature of the conflict or the parties involved. The primary goal is to effectively resolve the conflict, irrespective of who reports to whom. Although a project manager might leverage their hierarchical authority in a "forcing" technique, the structure itself does not dictate *which* technique is inherently best suited for addressing the specific dynamics and root causes of a particular conflict.

Creating a risk register to document identified risks.

Why wrong: The risk register is an output of risk identification, not a technique.

Probability and impact matrix for ranking risks.

Why wrong: This is a tool for qualitative risk analysis, not for identification.

Inform the team to ignore the regulation until the project is complete

Why wrong: Ignoring regulations can have legal consequences.

Update the risk register and move on

Why wrong: The regulation is a certainty, not a risk; action is needed beyond updating the register.

Immediately instruct the team to implement the changes to ensure compliance

Why wrong: Changes must go through change control first.

Ask the product owner to reduce the scope of the next sprint

Why wrong: Asking the product owner to reduce the scope of the next sprint merely treats a symptom without addressing the root cause of the declining velocity. While it might make the sprint backlog "fit" the current reduced capacity, it does not resolve the systemic issues like technical debt, poor story readiness, or external interruptions that are causing the decline. This approach leads to a continuous need for scope reduction rather than a sustainable improvement in the team's actual delivery rate.

Add more developers to the team to increase capacity

Why wrong: Adding more developers to a team experiencing declining velocity is often counterproductive, as described by Brooks's Law. New team members require significant ramp-up time, diverting existing team members' attention for onboarding and training. Furthermore, increasing team size exponentially increases communication overhead and coordination complexity, potentially further decreasing overall productivity and velocity in the short to medium term, rather than solving the underlying issues.

Identified risks and mitigation strategies

Why wrong: Identified risks and their mitigation strategies are typically developed in detail during the project planning phase as part of comprehensive risk management. While a business case might briefly acknowledge high-level risks or assumptions, it does not delve into specific mitigation plans. The detailed analysis and strategic responses to potential threats and opportunities are too granular for the initial justification document.

Resource allocation plan

Why wrong: A resource allocation plan details how specific resources, such as personnel, equipment, and materials, will be assigned to project activities. While a business case may broadly outline resource requirements, the granular planning of resource allocation occurs much later, during the project planning phase, after the project has been formally authorized. It is not a prerequisite for justifying the project's existence.

Detailed project schedule

Why wrong: A detailed project schedule, outlining specific tasks, durations, dependencies, and milestones, is a primary output of the project planning process. The business case, conversely, is developed prior to project initiation and planning, serving to justify the project's existence. While a business case might include a high-level estimated timeline, it does not contain the granular detail of a comprehensive project schedule.

Risk register

Why wrong: Risk register is created during risk management planning.

Detailed project schedule

Why wrong: The schedule is developed during planning, not in the business case.

Communication plan

Why wrong: The communication plan is part of the project management plan.

Replace the least important sprint backlog item with the new work and adjust the sprint goal accordingly

Why wrong: Replacing sprint backlog items mid-sprint fundamentally undermines the Development Team's commitment to the sprint goal and the integrity of the sprint itself. The sprint backlog is a forecast of work to achieve the sprint goal, and arbitrarily swapping items disrupts the team's planned work, potentially leading to incomplete features, rework, and a loss of focus.

Instruct the team to include the new work in the current sprint and extend the sprint duration

Why wrong: Extending the sprint duration directly violates the Scrum principle of time-boxing, which mandates fixed-length sprints to create rhythm and predictability. Altering the sprint length mid-sprint disrupts the team's cadence, makes forecasting difficult, and can mask underlying issues with sprint planning or scope management rather than addressing them effectively.

Add the new work to the sprint backlog and ask the team to work overtime

Why wrong: Adding new work to the sprint backlog mid-sprint without adjusting the sprint goal or scope compromises the Development Team's ability to achieve their committed forecast. Furthermore, routinely asking the team to work overtime to accommodate unplanned scope additions is an unsustainable practice that leads to burnout, reduced quality, and a breakdown of trust within the team.

Inform the sponsor and ask for a project extension

Why wrong: While the sponsor should be informed, asking for an extension immediately may be premature without first attempting mitigation.

Immediately hire a replacement with the same skills

Why wrong: Hiring may take time; immediate actions should focus on mitigation.

Escalate the conflict to the project sponsor for resolution

Why wrong: The PM should first attempt to resolve the conflict before escalating.

Make a unilateral decision on the technical approach to end the conflict quickly

Why wrong: This may suppress the conflict but not resolve underlying issues, and can harm team morale.

Escalate the issue to the PMO or steering committee without further discussion

Why wrong: Should first discuss with the sponsor directly.

Agree to skip testing to meet the sponsor's request

Why wrong: Agreeing to skip testing compromises quality and is not professional.

Stakeholder register

Why wrong: The Stakeholder Register identifies project stakeholders, their roles, interests, influence, and potential impact on the project. While it helps understand who might be affected by a regulatory change, it does not contain the financial justification, cost-benefit analysis, or schedule baselines required to quantitatively assess the impact on the project's overall business case or its viability. Therefore, it cannot directly inform the sponsor about the change's effect on the project's financial justification.

Work breakdown structure dictionary

Why wrong: The Work Breakdown Structure (WBS) Dictionary provides detailed descriptions of the components in the WBS, including work package scope, deliverables, assigned responsibilities, and technical requirements. While crucial for understanding the project's scope decomposition, it does not contain information related to the project's financial justification, strategic alignment, or overall economic viability. Consequently, it offers no direct insight into how a regulatory change affects the project's business case or its financial performance metrics.

Offer monetary bonuses for meeting deadlines

Why wrong: Monetary incentives are extrinsic motivators that often provide only temporary boosts in morale, especially when underlying issues like excessive workload or unclear direction persist. While they can drive specific behaviors, they fail to address the root causes of burnout and dissatisfaction, potentially leading to resentment if not perceived as fair or sustainable. This approach would likely exacerbate the problem by adding pressure without resolving the core stressors.

Empower the team to self-organize and make decisions

Why wrong: While empowering a team to self-organize is a valuable practice for fostering autonomy and long-term engagement, it does not directly resolve the immediate and acute problems of unclear priorities and an overwhelming workload. Without clear boundaries and reduced pressure, self-organization can become chaotic or lead to further stress as the team struggles to prioritize within an unmanageable scope. This solution is premature given the current crisis.

Ask the team to work overtime to reduce the backlog

Why wrong: Demanding overtime directly increases the existing heavy workload and stress levels, which are primary contributors to low morale. This action signals a disregard for team well-being and sustainability, leading to further exhaustion, decreased quality of work, and potentially higher turnover. It's a counterproductive measure that intensifies the very problems it aims to solve.

Instruct the team to accept the 40-point goal to satisfy the product owner

Why wrong: Instructing the team to accept an externally imposed goal directly contradicts agile principles of self-organizing teams and voluntary commitments. Forcing a commitment undermines team autonomy, erodes psychological safety, and often leads to rushed work, increased technical debt, and decreased team morale, ultimately hindering the delivery of high-quality value and fostering an unsustainable pace.

Increase the sprint length to 3 weeks to allow more time

Why wrong: While changing sprint length is a team decision, simply extending the sprint duration does not address the underlying issues of estimation inaccuracy or capacity planning. This approach often masks the problem by providing a temporary buffer, potentially delaying crucial feedback cycles and increasing the risk of scope creep, rather than resolving the root cause of unrealistic commitments or poor estimation practices.

Ask the team to work overtime to compensate for lost velocity

Why wrong: Asking the team to work overtime treats a symptom—lost velocity—rather than the root causes of unclear requirements and frequent interruptions. In agile frameworks, overtime is a short-term capacity increase that does not improve requirement clarity or reduce workflow disruptions; it typically accelerates burnout and further degrades velocity. This option is tempting because overtime can temporarily boost output when a fixed deadline is at risk and the backlog is well-defined, making it a plausible corrective action for a pure capacity shortfall.

Add more team members to the next sprint to increase capacity

Why wrong: Adding team members to a struggling agile team, especially mid-project or sprint, often invokes Brooks's Law, where "adding manpower to a late software project makes it later." New members require onboarding, training, and integration into existing team dynamics, which diverts effort from current team members and initially reduces overall productivity and velocity rather than increasing it. This action fails to address underlying issues like unclear requirements or interruptions, which are more likely causes of declining velocity.

Reduce the sprint length to increase accountability

Why wrong: Reducing sprint length, while potentially increasing the frequency of feedback loops, does not inherently improve accountability or address the root causes of declining velocity, such as unclear requirements or external interruptions. Shorter sprints can actually intensify pressure, reduce the time available for complex tasks, and increase overhead from more frequent sprint ceremonies, potentially further destabilizing velocity rather than improving it. Accountability is better fostered through transparent progress, clear commitments, and regular retrospectives, not merely by shortening the iteration cycle.

Avoid discussing potential conflicts to maintain harmony.

Why wrong: Avoiding discussions about potential conflicts, while seemingly aimed at maintaining harmony, is a detrimental approach in project management. Suppressing disagreements prevents their healthy resolution, allowing underlying issues to fester and potentially escalate into more significant problems later. Effective project managers facilitate open communication and constructive conflict resolution to build trust and improve team dynamics, rather than ignoring challenges.

Mandate overtime to meet aggressive deadlines.

Why wrong: Mandating overtime to meet aggressive deadlines is a short-sighted strategy that often leads to negative long-term consequences. While it might offer temporary gains, it invariably causes team burnout, reduces morale, and significantly decreases overall productivity and quality over time. Sustainable project management prioritizes realistic planning, effective resource allocation, and maintaining a healthy work-life balance to ensure consistent performance and prevent attrition.

Assign roles and responsibilities without team input.

Why wrong: Assigning roles and responsibilities without team input undermines team ownership and can lead to significant resistance and disengagement. When team members are not involved in defining their contributions, their unique skills and preferences may be overlooked, resulting in suboptimal assignments and reduced accountability. Collaborative role definition promotes buy-in, leverages individual strengths, and ensures a more motivated and effective team.

Tell the team to work overtime to include the feature

Why wrong: Forcing the team to work overtime to accommodate an unplanned feature is an unsustainable practice that directly contradicts the agile principle of maintaining a sustainable pace. This approach can quickly lead to team burnout, decreased morale, and a significant drop in product quality due to rushed work and increased errors. Instead of addressing the root cause of the change, it merely shifts the burden onto the development team, jeopardizing long-term productivity and team health.

Add the feature to the current sprint backlog because the product owner requested it

Why wrong: Arbitrarily adding a new feature to the current sprint backlog solely because the product owner requested it directly violates the sprint commitment and undermines the stability of the sprint goal. The sprint backlog is a forecast of work the team commits to complete within a specific timebox, and introducing unplanned items without proper evaluation disrupts the team's focus and ability to deliver on their existing commitments. This practice can lead to incomplete work, missed deadlines, and a loss of predictability.

Ignore the request because it was not in the original scope

Why wrong: Ignoring a new feature request simply because it was not part of the original scope is a rigid and non-agile approach that risks stakeholder dissatisfaction and missed opportunities for value delivery. Agile methodologies embrace change and prioritize delivering the highest business value, acknowledging that requirements can evolve. A proactive project manager facilitates a process to evaluate and potentially integrate such changes, rather than dismissing them outright, to maintain stakeholder engagement and project adaptability.

Offer competitive salaries and bonuses.

Why wrong: While competitive salaries and bonuses are essential for attracting and retaining talent, they primarily function as "hygiene factors" according to Herzberg's Two-Factor Theory. These extrinsic rewards prevent dissatisfaction but do not inherently provide long-term motivation or job satisfaction beyond a basic threshold. Once compensation expectations are met, further increases typically do not drive sustained performance improvements or intrinsic engagement.

Closely monitor team members' work to ensure compliance.

Why wrong: Closely monitoring team members' work to ensure compliance often leads to micromanagement, which is highly detrimental to motivation and trust. This approach signals a lack of confidence in the team's capabilities and autonomy, stifling initiative and creativity. Instead of fostering accountability, it can create resentment, reduce job satisfaction, and ultimately decrease productivity as team members feel disempowered and undervalued.

Add the vendor's failure to the risk register as a new risk

Why wrong: Adding a vendor's failure to the risk register as a new risk is incorrect because the event has already occurred; it is no longer an uncertain future event. Risks are potential occurrences, whereas a materialized vendor failure is an actual issue that should be documented in an issue log. Once a risk materializes, it transitions from being managed proactively in the risk register to being managed reactively as an issue, with its impact addressed and lessons learned captured.

Authorize the team to source alternative materials locally

Why wrong: Unilaterally authorizing the team to source alternative materials locally is a significant deviation that bypasses formal change control processes. Changing materials can impact the project's scope, quality requirements, design specifications, schedule, and overall cost baseline. Such a decision requires a formal change request, thorough impact analysis by relevant experts, and approval from the Change Control Board (CCB) or appropriate stakeholders to ensure alignment with project objectives and standards.

Update the project management plan to use a different construction method

Why wrong: Updating the project management plan to use a different construction method represents a fundamental change to the project's execution strategy and scope. This significant modification would necessitate a formal change request, comprehensive impact analysis across all project baselines (scope, schedule, cost, quality), and approval through the integrated change control process, typically by the Change Control Board (CCB). Making such a change without proper analysis and approval can introduce new risks and jeopardize project success.

Reassign one developer to a different module to reduce interaction

Why wrong: This avoids the underlying issue and may not be feasible.

Ignore the conflict and hope it resolves on its own

Why wrong: Ignoring conflict typically worsens it.

Escalate the issue to the project sponsor for a decision

Why wrong: Escalating without trying to resolve first bypasses PM authority.