Hard Difficulty 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.

Step in to make decisions when the team is struggling with a difficult issue

Why wrong: Stepping in to make decisions when the team struggles with a difficult issue directly undermines the principles of self-organization and team empowerment. While well-intentioned, this action creates a dependency on the project manager, preventing the team from developing critical problem-solving skills and collective ownership over challenges. An agile project manager should instead coach the team through the decision-making process, facilitating their resolution rather than dictating it.

Assign a senior team lead to oversee team decisions

Why wrong: Assigning a senior team lead to oversee team decisions fundamentally contradicts the agile principle of self-organization and reduces team autonomy. This introduces a hierarchical control layer that shifts decision-making authority away from the collective, diminishing the team's sense of ownership and accountability for their choices. A self-organizing team thrives when empowered to collectively determine its path, not when decisions are subject to external oversight.

Provide additional training on agile practices

Why wrong: While providing additional training on agile practices can certainly enhance a team's knowledge and skills, it does not directly address the project manager's role in *empowering* decision-making. Empowerment is about granting authority and fostering an environment of trust, not merely imparting information. Training equips the team with tools, but the project manager's actions regarding autonomy and trust are what truly enable self-organization and decision-making authority.

Assign roles and responsibilities yourself to avoid confusion

Why wrong: While direct assignment might seem efficient, it contradicts modern project management principles, particularly servant leadership and agile methodologies that emphasize team self-organization. Dictating roles without team input can lead to reduced morale, lack of ownership, and disengagement, as team members feel undervalued and their expertise is not leveraged. This approach stifles initiative and prevents the team from collectively developing a shared understanding and commitment to their responsibilities.

Increase supervision and hold daily status meetings

Why wrong: Increasing supervision and mandating daily status meetings in response to low morale and unclear roles is generally counterproductive and often perceived as micromanagement. This approach signals a lack of trust in the team's capabilities and autonomy, further eroding morale and potentially increasing stress rather than resolving the underlying issues of role clarity or engagement. Effective project managers empower teams, providing support and removing impediments, rather than imposing stricter controls that stifle initiative.

Immediately adjust the project budget and schedule to accommodate the requirement

Why wrong: Immediately adjusting the project budget and schedule without formal approval is a critical deviation from proper project governance. All proposed changes, especially those impacting baselines, must first undergo the Perform Integrated Change Control process. Bypassing this process leads to unauthorized changes, potential scope creep, and a loss of control over project baselines, jeopardizing project success and stakeholder trust.

Assign the new requirement to the development team to start work immediately

Why wrong: Assigning the new requirement to the development team to start work immediately is a significant project management misstep. Commencing work on an unapproved requirement bypasses the formal Integrated Change Control process, leading directly to unauthorized scope creep and potential rework. This action can destabilize the project baselines, consume resources without proper justification, and undermine the project manager's authority and the integrity of the project plan.

Inform the sponsor and stakeholders about the delay and await their decision.

Why wrong: This option is incorrect because a project manager's role extends beyond merely reporting problems. Upon a risk event's occurrence, the PM is expected to analyze the situation, evaluate potential solutions, and propose a course of action before escalating to the sponsor or stakeholders. Simply informing them and awaiting their decision abdicates the PM's responsibility for proactive problem-solving and issue management.

Do nothing since the risk was accepted.

Why wrong: This option is incorrect because 'risk acceptance' means acknowledging the possibility of a risk occurring and deciding not to take proactive action to change its probability or impact *before* it happens. However, once an accepted risk materializes, it transforms into an issue that requires active management and a response to mitigate its impact on project objectives. Doing nothing is never an appropriate response to an active project issue.

Implement the contingency plan from the risk register.

Why wrong: This option is incorrect because a contingency plan is a pre-defined response developed for specific risks, typically those with a 'mitigate' or 'transfer' strategy. If a risk was 'accepted,' it implies that no specific proactive or reactive plan, such as a contingency plan, was developed in advance to address it. Therefore, there would be no pre-existing contingency plan in the risk register to implement for an accepted risk.

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.

Invoke the penalty clause in the vendor contract for late delivery

Why wrong: Invoking a penalty clause, while a contractual right, is typically a last resort and not the initial project management response to a critical vendor issue. This action is punitive and reactive, potentially escalating conflict and damaging the long-term vendor relationship without first exploring collaborative solutions or assessing the full impact of the proposed substitute. The immediate priority is to find a viable solution to keep the project on track, which requires analysis, not just retribution.

Accept the vendor's suggestion to use the substitute material to avoid delay

Why wrong: Accepting the vendor's substitute material without formal change control is a critical breach of project governance. This unilateral decision bypasses necessary impact analysis on scope, schedule, cost, and quality, and circumvents the formal approval process by the Change Control Board (CCB) or relevant stakeholders. Such an action introduces unmanaged risks and can lead to unauthorized budget overruns or scope creep, undermining project control.

Look for alternative vendors who can deliver the original component on time

Why wrong: Immediately searching for alternative vendors is premature and potentially inefficient without first evaluating the current vendor's proposed substitute. This approach is resource-intensive, time-consuming, and could introduce new procurement risks and delays, especially if the original component is specialized. The project manager should first assess the viability of the proposed solution through the change control process before expending significant effort on a potentially unnecessary vendor search.

The 'feature/login' branch is still active and contains unmerged commits.

Why wrong: This statement is incorrect because the exhibit clearly indicates that the 'feature/login' branch has been successfully merged into 'main'. Once a branch is merged, all its commits become part of the target branch's history, meaning there are no longer any "unmerged" commits from 'feature/login' relative to 'main'. While the branch pointer itself might persist, its content has been fully integrated.

The 'feature/login' branch has not been merged into main.

Why wrong: This option is incorrect. The visual representation of the Git history, specifically the presence of a merge commit on the 'main' branch, serves as direct evidence that the 'feature/login' branch's changes have been fully incorporated. A merge commit explicitly records the integration of one branch's history into another, making this statement false.

The 'feature/login' branch is behind main by one commit.

Why wrong: This statement is inaccurate. After 'feature/login' has been merged into 'main', all commits from 'feature/login' are now present in 'main'. While 'main' might subsequently gain new commits, making 'feature/login' appear "behind" in terms of the latest 'main' state, the statement implies 'feature/login' is missing a commit that 'main' has *from its own history*, which is not the case post-merge. The branch's contributions are fully integrated into 'main'.

Formally document the missed deadlines and issue a warning to the team member.

Why wrong: This punitive action is not the first step; the PM should seek to understand first.

Reassign the team member's tasks to others to avoid further delays.

Why wrong: This may overload others and does not address the root cause.

Replace the team member with a more productive resource.

Why wrong: This is a drastic step without understanding the reason.

Reduce project scope by eliminating non-essential deliverables

Why wrong: Reducing project scope by eliminating non-essential deliverables is a valid schedule compression technique, but it requires a formal change request process and stakeholder approval. This approach alters the project's baseline scope, potentially impacting the value delivered to the customer. It is generally considered a last resort or a strategic decision rather than an immediate tactical response to an unexpected delay, as the primary goal is often to meet the original scope and schedule if possible.

Update the risk register and inform stakeholders of the delay without taking action

Why wrong: Merely updating the risk register and informing stakeholders without implementing corrective actions represents a passive acceptance strategy, which is generally not an appropriate response to a project being behind schedule. While communication is crucial, a project manager is is expected to proactively identify and implement schedule compression techniques to mitigate the delay. This approach fails to address the negative schedule variance and could lead to further deterioration of the project's performance objectives.

Immediately apply fast tracking to overlap activities on the critical path

Why wrong: Fast tracking involves performing activities in parallel that would normally be done in sequence, which can compress the schedule. However, this technique inherently increases project risk due to potential rework, quality issues, and increased communication complexity, as subsequent activities may begin before predecessors are fully complete. While a valid option, it is often less direct than crashing when resources are available and the primary concern is reducing duration without significantly increasing risk.

Add the testing tasks to the project schedule and continue

Why wrong: Directly adding new tasks to the project schedule without formal assessment and approval bypasses the established change control process. This action constitutes unauthorized scope creep, potentially impacting the project's scope, schedule, and cost baselines without proper evaluation or stakeholder consensus. It violates the project management plan's governance framework, leading to unmanaged risks and potential project failure.

Immediately implement the necessary changes to comply with the regulation

Why wrong: Implementing changes immediately, even for compliance, circumvents the critical change control process defined in the project management plan. This premature action prevents a thorough analysis of the regulation's full impact on project objectives, resources, and existing deliverables. Such an approach introduces significant risks, as unassessed changes can lead to rework, budget overruns, and unintended negative consequences without proper stakeholder review and approval.

Inform the sponsor and ask for more budget and time

Why wrong: While informing the sponsor and discussing potential budget and time impacts are crucial, doing so *before* formally assessing the new requirements via a change request is premature. This approach skips the necessary structured analysis of alternatives, impacts, and potential solutions that the change control process provides. A formal change request ensures that all implications are thoroughly documented, evaluated, and presented to the sponsor with data-driven recommendations, rather than an immediate, unquantified demand.

Escalate the issue to the project sponsor to overrule the product owner

Why wrong: Escalation should be after coaching and within the Scrum framework.

Shorten the sprint length to two or three days to accommodate frequent changes

Why wrong: Shorter sprints may increase overhead and still not address the root cause.

Accept the changes as the product owner has authority over priorities

Why wrong: The scrum master should protect the sprint goal and ensure stability.

Inform the project sponsor about the executive's behavior and ask them to intervene.

Why wrong: While escalation may be needed, the PM should first address the issue directly.

Tell the team to prioritize the executive's requests to maintain a good relationship.

Why wrong: This undermines the sprint plan and team focus.

Update the risk register to document this as a future risk.

Why wrong: This is reactive; the PM needs to address the current issue immediately.

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.

Accept the story as is to meet the deadline

Why wrong: Accepting an unrefined story "as is" solely to meet a deadline is counterproductive in an agile environment. This approach risks significant rework, technical debt, and delivering a low-quality increment that may not meet the true user need. The Scrum Master's role is to ensure clarity and quality, not to push through ambiguous work that undermines the team's ability to deliver value.

Escalate to the project sponsor

Why wrong: Escalating directly to the project sponsor is a premature and inappropriate first step for an issue arising during sprint planning. The Scrum Master's primary responsibility is to facilitate communication and problem-solving within the Scrum team, empowering them to resolve impediments collaboratively. Such an action bypasses the team's self-organizing capabilities and the Scrum Master's role in facilitating internal resolution, which should always be attempted first.

Remove the product owner from the meeting

Why wrong: Removing the Product Owner from sprint planning is an unprofessional and counterproductive action. The Product Owner is an essential member of the Scrum Team, responsible for clarifying product backlog items and ensuring the team understands the value to be delivered. Such an act would be highly disrespectful, undermine team collaboration, and directly impede the team's ability to effectively plan the sprint and commit to a meaningful Sprint Goal.

Document the sponsor's request and proceed with the inspection as planned without further discussion

Why wrong: Documenting the sponsor's request and proceeding without further discussion is an inadequate response that fails to address a critical project risk. This approach neglects the project manager's responsibility for proactive stakeholder engagement and risk communication. Simply recording the request without explaining the potential regulatory and safety consequences leaves the project vulnerable to non-compliance and demonstrates a passive stance on professional obligations.

Comply with the sponsor's request to maintain a good relationship

Why wrong: Complying with the sponsor's request to skip a mandatory inspection, even to maintain a good relationship, is a serious breach of ethical conduct and professional responsibility. This action could lead to significant legal liabilities, severe safety hazards, and reputational damage for the project and organization. A PMP must prioritize adherence to regulatory requirements and the PMI Code of Ethics over short-term stakeholder satisfaction.

Propose reducing the inspection scope rather than skipping it entirely

Why wrong: Proposing to reduce the inspection scope rather than skipping it entirely still carries substantial risks of non-compliance and compromised project quality or safety. Mandatory inspections often have minimum requirements dictated by law or industry standards, which cannot be arbitrarily altered. This compromise may still violate regulations, expose the project to legal penalties, and fail to adequately mitigate potential hazards, demonstrating a misunderstanding of compliance thresholds.

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.

Recommend increasing resources for Project B to get it back on track

Why wrong: As a portfolio manager, the primary role is to provide a holistic view and analysis of the entire portfolio, not to unilaterally recommend specific operational solutions for individual projects. Increasing resources for one project without assessing the overall portfolio's strategic objectives, resource constraints, and interdependencies could negatively impact other projects or the portfolio's strategic alignment. Such a significant resource allocation decision requires a broader strategic discussion and approval from the portfolio governing body.

Recommend stopping Project C and reallocating resources to Project B

Why wrong: While portfolio managers analyze project performance and strategic fit, making a direct recommendation to stop a project and reallocate resources is a strategic decision reserved for the portfolio governing body. The portfolio manager's role is to present the facts, potential impacts, and various options, allowing the committee to weigh the strategic implications and make the ultimate decision regarding project termination or resource shifts across the portfolio. This maintains proper governance and accountability for strategic portfolio choices.

Ask each project manager to submit a recovery plan and then decide

Why wrong: Requesting individual recovery plans from project managers is an operational step that typically occurs *after* a strategic decision has been made at the portfolio level regarding which projects to prioritize or adjust. Before diving into project-level recovery, the portfolio manager must first present the holistic portfolio status and strategic alignment to the governing committee. This ensures that any subsequent recovery efforts are aligned with the overall strategic direction and resource allocation determined by the portfolio's governing body.