Select Two (Multi-Select) Questions

The cost of implementing the resolution technique.

Why it fails: 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 it fails: 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.

Identified risks and mitigation strategies

Why it fails: 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 it fails: 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 it fails: 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 it fails: The risk register is a living project artefact maintained during execution, not part of the initial justification document. A business case summarises high-level risks alongside costs, benefits and options analysis, but the detailed register is created later in planning.

Detailed project schedule

Why it fails: A business case justifies investment through costs, benefits, options and risks; the detailed schedule is produced later during project planning, once the charter is approved. It would belong in the project management plan, not the document seeking funding approval.

Communication plan

Why it fails: The communication plan describes how information will be distributed during execution, so it is created during planning after the business case is approved. A business case instead captures the problem, options analysis, costs, benefits and risks used to justify the investment.

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

Why it fails: 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 it fails: 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 it fails: 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.

Require all team members to communicate in the same direct style

Why it fails: Imposing one direct communication style suppresses the cultural variation causing the problem, so quieter members stay unheard. It is tempting because standardising style can speed meetings, and it would suit a homogeneous team where a shared norm is genuinely agreed rather than mandated.

Tell the team that conflicts are normal and they should work it out themselves

Why it fails: Delegating the conflict leaves the underlying inclusion problem unaddressed, since the PM owns team ground rules and facilitation. It is tempting because avoiding premature intervention is sound when a capable team self-resolves minor disagreements, but not when members report being silenced.

Adding buffers to the schedule

Why it fails: Adding buffers to the schedule involves incorporating extra time, or contingency reserves, into the project timeline to account for uncertainties, risks, or unforeseen delays. While a prudent risk management practice, buffers are designed to absorb variations and protect the project's completion date, thereby extending the planned duration rather than shortening it. Consequently, this action directly counteracts any effort to compress the project schedule, making it an inappropriate response to significant schedule delays when compression is desired.

Resource leveling: smoothing resource demand to avoid peaks

Why it fails: Resource leveling is a schedule optimization technique used to adjust the project schedule to balance resource demand with available supply, particularly when resources are over-allocated or when a constant level of resource usage is desired. This process often involves delaying non-critical activities to smooth out resource peaks, which typically results in an extended project duration. Therefore, while beneficial for resource management and avoiding burnout, resource leveling is not a schedule compression technique and usually lengthens the project timeline.

Reducing scope: removing non-critical deliverables

Why it fails: Reducing scope involves formally removing non-critical deliverables or features from the project's agreed-upon requirements. While a reduction in scope might indirectly lead to a shorter schedule by eliminating associated work, it is fundamentally a scope management action that requires a formal change request and stakeholder approval. It is not classified as a direct schedule compression technique, which specifically focuses on accelerating existing work within the defined scope rather than altering the scope itself.

Avoid discussing potential conflicts to maintain harmony.

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

Ignore the conflict and hope it resolves on its own

Why it fails: Ignoring conflict is a passive and ineffective approach that rarely leads to resolution in a professional setting. Unaddressed conflicts tend to fester, escalate, and negatively impact team morale, productivity, and the overall project environment. A project manager's role includes actively managing team dynamics and addressing issues promptly to maintain a healthy and productive agile team.

Reassign the developers to different teams

Why it fails: Reassigning developers avoids addressing the underlying cause of the conflict, which could resurface in new teams or with different team members. This action also incurs significant costs related to onboarding, knowledge transfer, and potential disruption to project timelines. Furthermore, it signals an inability to resolve team issues, potentially damaging trust and the project manager's leadership credibility.

Escalate the conflict to the project sponsor

Why it fails: Escalating a team conflict directly to the project sponsor is an overreaction and bypasses the project manager's primary responsibility for team management and conflict resolution. This action should only be considered as a last resort when all other internal resolution attempts have failed, or if the conflict poses a significant, unmanageable risk to the project. Premature escalation can undermine team autonomy and the project manager's authority.

Increase sprint length to four weeks to give more time for tasks

Why it fails: Increasing sprint length from a typical two-week duration to four weeks in an agile environment often counteracts the benefits of iterative development. Longer sprints delay feedback from stakeholders and the team, increasing the risk of developing features that do not meet current needs or require significant rework. This reduces the project's adaptability and responsiveness to change, which is particularly critical for distributed teams needing frequent synchronization.

Allow team members to communicate directly with stakeholders without involving the project manager

Why it fails: While direct communication can sometimes be efficient, allowing team members to communicate directly with stakeholders without involving the project manager introduces significant risks. This practice can lead to unmanaged scope creep, conflicting instructions, and a lack of centralized information regarding stakeholder needs and expectations. The project manager's role includes managing stakeholder communications to ensure alignment with project objectives and maintaining a unified message, preventing potential misunderstandings or unauthorized changes.

Require all team members to work the same hours regardless of time zone

Why it fails: Requiring all team members in a distributed environment to work the same hours, irrespective of their local time zones, is highly impractical and detrimental to team morale and productivity. This approach forces some individuals to work during late nights or early mornings, leading to burnout, reduced efficiency, and potential attrition. Effective distributed team management leverages time zone differences for continuous work streams and prioritizes flexible work arrangements to support work-life balance.

Ask them directly why they are not participating

Why it fails: Directly asking a new team member why they are not participating can be perceived as confrontational or accusatory, potentially increasing their discomfort and reluctance rather than encouraging engagement. This approach fails to consider the need for psychological safety and trust-building, which are foundational for effective team integration and open communication. A project manager should first seek to understand the underlying reasons through observation and indirect support.

Assign them a complex task to prove their abilities

Why it fails: Assigning a complex task to a new team member solely to "prove their abilities" is counterproductive and risks overwhelming them, potentially exacerbating their reluctance and anxiety. Effective team integration focuses on gradual assimilation, providing appropriate support and tasks that build confidence, rather than immediately placing high-pressure demands. This approach neglects the importance of understanding a new member's current capabilities and fostering a supportive learning environment.

Require them to present an idea in the next meeting

Why it fails: Requiring a new, potentially reluctant team member to present an idea in an upcoming meeting can create undue pressure and anxiety, likely backfiring by increasing their discomfort and withdrawal. This coercive approach fails to build confidence or address underlying reasons for their reluctance, instead forcing them into a vulnerable position without adequate preparation or psychological safety. Effective integration prioritizes gradual engagement and supportive opportunities over immediate, high-stakes demands.

Immediately assign the team to fix the vulnerability without formal approval

Why it fails: Assigning the team to fix a vulnerability without formal approval, even if urgent, bypasses established project governance and the integrated change control process. This action can lead to unauthorized scope creep, unbudgeted expenses, and unapproved schedule deviations, potentially disrupting other project activities and stakeholder expectations. While speed is sometimes critical, proper documentation and approval are essential for maintaining control and accountability.

Add the vulnerability to the risk register and continue with the current sprint as planned

Why it fails: Simply adding a newly discovered vulnerability to the risk register and continuing as planned is an inadequate response, especially if the vulnerability poses an immediate or significant threat to the project or its deliverables. While risk identification is important, this approach fails to address the identified issue proactively or reactively. It neglects the need for a proper impact assessment and a planned response, potentially leading to greater problems down the line.

Implement a temporary workaround to reduce the risk and monitor the situation

Why it fails: Implementing a temporary workaround might mitigate immediate risk, but it is typically an unplanned response to an emergent issue, not a substitute for a formal resolution. While useful in a crisis, relying solely on a workaround without pursuing a permanent fix through the change control process leaves the underlying problem unresolved and can introduce technical debt or new risks. A permanent solution, once identified, must be formally managed.

Conduct a new risk assessment to identify new risks

Why it fails: While periodic risk reassessments are a vital part of the Monitor Risks process to identify new risks or re-evaluate existing ones, conducting a full new assessment is not the immediate or primary action when a known risk event has just occurred. The immediate priority is to implement the pre-planned response for that specific risk; a comprehensive reassessment would typically follow or be part of a scheduled review, not an instantaneous reaction to a single materialized risk.

Add the risk to the watch list for monitoring

Why it fails: Adding a risk to the watch list is inappropriate once the risk event has actually occurred. The watch list is specifically for low-priority risks or those requiring further analysis, which are being monitored but do not warrant immediate response planning. Once a risk materializes, it transitions from a potential event to an actual issue, requiring active management and response implementation, followed by status updates in the risk register, not passive monitoring on a watch list.

Ignore the requirement until the next project phase

Why it fails: Ignoring a newly discovered regulatory requirement is a critical failure in project management, directly violating the project's compliance obligations and risk management plan. Such an action exposes the organization to significant legal penalties, reputational damage, and potential project cancellation. Project managers are responsible for proactive identification and management of all project constraints and external factors, including regulatory changes, throughout the project lifecycle.

Implement the requirement immediately to ensure compliance

Why it fails: Implementing a new regulatory requirement immediately without following the established Perform Integrated Change Control process is a direct violation of the project management plan and organizational governance. Such an action bypasses formal impact assessment, stakeholder approval, and baseline updates, leading to uncontrolled scope creep, schedule delays, and budget overruns. All changes, especially those impacting baselines, must undergo formal review and approval to maintain project integrity and control.

Exploit

Why it fails: Exploit is a proactive risk response strategy applied exclusively to *opportunities*, aiming to ensure a positive impact is realized with certainty. This involves taking direct action to make the opportunity happen, such as assigning the best resources to achieve a cost saving or developing a new product feature. Since the context of the question implies dealing with a *threat* (based on the correct answers being threat responses), Exploit is an inappropriate strategy for managing negative risks.

Enhance

Why it fails: Enhance is a risk response strategy applied solely to *opportunities*, focusing on increasing the probability or positive impact of a favorable event. This might involve adding resources, adjusting project scope, or improving processes to maximize potential benefits. As the context of the correct answers points to managing *threats*, Enhance is an unsuitable response, as one would not seek to increase the probability or impact of a negative event.

Reduce the frequency of communication to minimize coordination overhead

Why it fails: Reducing communication frequency, especially in a geographically dispersed team, is counterproductive and highly risky. It inevitably leads to increased misunderstandings, delayed information flow, and a lack of shared understanding regarding project status, risks, and dependencies. While it might seem to reduce "overhead," the resulting rework, errors, and missed deadlines will significantly outweigh any perceived efficiency gains, ultimately jeopardizing project success.

Require all team members to be available during a fixed 4-hour overlap window each day

Why it fails: Mandating a fixed 4-hour daily overlap window for a team distributed across four countries is often impractical and unsustainable. Such a requirement would likely force some team members to work extremely early mornings or late nights consistently, leading to burnout, decreased morale, and potential attrition. While some overlap is beneficial, a rigid, extended fixed window severely impacts work-life balance and fails to leverage the flexibility that distributed work can offer, making it an unfeasible long-term solution.

Decide on the technical approach yourself

Why it fails: A Project Manager imposing a technical decision directly undermines team autonomy and the principle of self-organizing teams, which are central to modern project management. This approach fails to leverage the collective expertise of the senior developers, potentially leading to a suboptimal solution and disengagement, rather than fostering a collaborative problem-solving environment. The PM's role is to facilitate, not dictate, technical solutions.

Escalate to the project sponsor for a decision

Why it fails: Escalating a team-level conflict directly to the project sponsor prematurely is generally inappropriate and bypasses the Project Manager's responsibility to facilitate resolution within the team. Such an action indicates a failure to attempt resolution at the lowest possible level, burdens higher management unnecessarily, and can erode the team's confidence in their ability to self-organize and resolve internal issues. Escalation should be a last resort after all internal attempts have failed.

Reassign one developer to another project to avoid further conflict

Why it fails: Reassigning a team member to avoid conflict is an avoidance strategy that fails to address the underlying issue and can have detrimental effects on project continuity and team morale. This action does not resolve the root cause of the conflict, potentially creating new resource allocation problems and signaling to the team that difficult conversations are to be avoided rather than constructively managed. It is a temporary fix that does not foster a healthy, problem-solving culture.

Implement a reward system for individual performance metrics

Why it fails: While individual recognition can be motivating, implementing a reward system solely based on individual performance metrics in a hybrid project can inadvertently foster internal competition rather than collaboration. This approach may discourage knowledge sharing, mutual support, and the collective problem-solving essential for integrated team success, especially when team members are geographically dispersed and rely heavily on seamless interaction to achieve shared project objectives.

Assign a single point of contact in each country to relay information

Why it fails: Assigning a single point of contact (SPOC) in each country to relay all information can introduce significant communication bottlenecks and delays in a hybrid project. This hierarchical structure reduces direct, real-time interaction between team members, potentially leading to misinterpretations, slower decision-making, and a lack of shared understanding. Effective hybrid projects thrive on transparent, multi-directional communication channels, not on centralized information gatekeepers.

Require all team members to relocate to a central office for the project duration

Why it fails: Requiring all team members to relocate to a central office directly contradicts the fundamental nature of a hybrid project and is often impractical and cost-prohibitive. Such a mandate would incur substantial expenses for relocation, housing, and office space, while also potentially causing significant disruption to team members' personal lives and leading to attrition. A core principle of hybrid project management is leveraging distributed teams, not eliminating them.

Implement anonymous voting for all decisions

Why it fails: Implementing anonymous voting for *all* decisions, while seemingly promoting honesty, can actually hinder constructive debate and team cohesion. This approach often reduces accountability for opinions expressed and prevents the open discussion necessary to understand underlying reasoning or resolve disagreements collaboratively. For complex project decisions, transparency and direct engagement are typically more effective than anonymous input.

Make decisions quickly to avoid prolonged debates

Why it fails: Making decisions quickly to avoid prolonged debates is a detrimental approach that often suppresses valuable input and leads to suboptimal project outcomes. Rushing the decision-making process prevents thorough analysis of options, overlooks potential risks, and fails to incorporate diverse perspectives from the team. This can result in costly rework, missed opportunities, and decreased team buy-in, especially in complex hybrid projects.

Only ask for opinions from senior team members to streamline discussions

Why it fails: Limiting opinion solicitation solely to senior team members to streamline discussions is counterproductive and undermines effective project management. This practice disenfranchises junior members, stifles innovation, and ignores valuable insights from individuals closer to the technical work or specific problem domains. It reinforces a hierarchical culture that actively suppresses diverse perspectives, leading to less comprehensive solutions and reduced team engagement.