People — Leading Projects practice questions

Increase oversight to ensure no tasks are missed.

Why it fails: Increasing oversight, particularly when a team is already experiencing high workload and low morale, is likely to be perceived as micromanagement and a lack of trust. This approach erodes team autonomy and can further decrease motivation and morale, as it suggests that the project manager doubts the team's capability to manage their responsibilities, rather than addressing the root cause of their stress. It adds pressure without providing support.

Conduct a blame-free review of recent failures.

Why it fails: While a blame-free review of recent failures is a valuable practice for fostering a culture of continuous learning and process improvement, it does not directly address the immediate issue of low morale stemming from high workload. Such a review focuses on past events and systemic issues rather than providing immediate recognition or relief from current pressures, thus having minimal direct impact on the team's current emotional state or motivation.

Offer a bonus for meeting deadlines.

Why it fails: Offering a bonus for meeting deadlines is an extrinsic motivator that might provide a temporary boost in effort but does not address the underlying causes of low morale due to high workload. Monetary rewards often fail to foster long-term intrinsic motivation or improve job satisfaction, and can even lead to resentment if perceived as a compensatory measure for unreasonable demands rather than genuine appreciation.

Increase meeting duration to cover all topics in one session.

Why it fails: Increasing meeting duration to cover all topics in one session is counterproductive for team performance. Extended meetings often lead to decreased participant engagement, attention fatigue, and reduced information retention, ultimately hindering effective decision-making and action item follow-through. This approach also consumes valuable time that could be spent on actual work, thereby diminishing overall team productivity and morale.

Replace synchronous meetings with email updates.

Why it fails: Replacing synchronous meetings with email updates significantly degrades team performance by eliminating real-time interaction and immediate feedback. Email lacks the ability to convey non-verbal cues, facilitate spontaneous brainstorming, or allow for instant clarification of complex issues, which are crucial for effective collaboration and problem-solving. This can lead to misunderstandings, delayed decision-making, and a fragmented sense of team cohesion.

Encourage team members to record their contributions for later review.

Why it fails: Encouraging team members to record their contributions for later review can negatively impact team performance by stifling spontaneity and open communication. This practice may make individuals self-conscious, leading them to overthink or censor their input rather than engaging in free-flowing, creative discussions essential for innovation. Furthermore, it adds an administrative burden and delays feedback, hindering the agile and iterative processes crucial for high-performing teams.

Increase the frequency of status meetings to daily.

Why it fails: Increasing the frequency of status meetings to daily for a globally distributed team is often counterproductive and can lead to significant challenges. This approach can cause meeting fatigue, especially for team members forced to attend outside their typical working hours, thereby reducing their actual productive time for project tasks. Furthermore, daily synchronous meetings may not be the most efficient method for information dissemination across diverse time zones, as asynchronous updates can often serve the purpose more effectively.

Require all team members to work in a single time zone.

Why it fails: Requiring all team members to work in a single time zone is an impractical and unsustainable solution for a globally distributed project. This mandate would force some team members to work extremely inconvenient or overnight hours, leading to severe burnout, decreased morale, and high attrition rates. The very purpose of a globally distributed team is to leverage talent across different geographical locations, making such a requirement counterproductive to the project's setup and long-term viability.

Assign a single point of contact for each location to relay information.

Why it fails: Assigning a single point of contact (SPOC) for each location to relay all information can severely impede efficient communication and create significant bottlenecks within a globally distributed team. This centralized communication model slows down the flow of critical information, as all queries and updates must pass through an intermediary, potentially leading to delays, misinterpretations, and reduced direct collaboration among team members. It also places an undue burden on the SPOC, making the communication structure less resilient and agile.

1. Identify Stakeholders, 2. Plan Stakeholder Engagement, 3. Analyze Stakeholders, 4. Engage Stakeholders, 5. Monitor Stakeholder Engagement

Why it fails: This is incorrect because analysis of stakeholders must occur before planning engagement; you need to understand stakeholders' interests and influence to create an effective plan.

1. Identify Stakeholders, 2. Analyze Stakeholders, 3. Engage Stakeholders, 4. Plan Stakeholder Engagement, 5. Monitor Stakeholder Engagement

Why it fails: This is incorrect because engagement should follow planning; without a plan, engagement activities may be uncoordinated and ineffective.

1. Plan Stakeholder Engagement, 2. Identify Stakeholders, 3. Analyze Stakeholders, 4. Engage Stakeholders, 5. Monitor Stakeholder Engagement

Why it fails: This is incorrect because you must first identify and analyze stakeholders before you can plan how to engage them. Planning comes after analysis.

Ask the vendor to expedite the delivery at no extra cost

Why it fails: While negotiation is possible, the immediate step is to activate the contingency plan.

Immediately source an alternative vendor without formal approval

Why it fails: Sourcing without approval bypasses procurement processes and may violate contracts.

Notify the sponsor and request a schedule extension

Why it fails: Notifying stakeholders is important but implementing the contingency plan takes precedence.

Refuse to implement the requirement because it will delay the project

Why it fails: Refusing a mandatory requirement is not advisable; compliance is necessary.

Inform the sponsor that the deadline cannot be met and begin working on the requirement

Why it fails: Working without formal approval bypasses change control.

Ask the team to implement the requirement while working overtime to minimize schedule impact

Why it fails: Overtime is not a substitute for change control; the change must be formally approved.

Update the risk register and assess the impact on the critical path

Why it fails: This is part of the analysis, but the first step should be initiating a change request.

Direct the team to immediately implement the changes to ensure compliance

Why it fails: Changes should go through formal assessment and approval first.

Inform the team to continue working as planned since the regulation may not be enforced

Why it fails: Ignoring regulatory changes can expose the project to legal risks.

Assign team members to specific tasks immediately to ensure quick progress

Why it fails: While task assignment is essential for progress, doing so immediately without prior team formation activities can be detrimental. Premature task assignment often overlooks the need for team members to understand each other's strengths, establish communication protocols, or align on shared objectives. This approach can lead to individual silos, miscommunication, and a lack of collective ownership, ultimately hindering overall project success and team cohesion.

Conduct a team-building retreat after the first project milestone

Why it fails: A team-building retreat can be highly beneficial for enhancing team cohesion and morale, especially during later stages of team development or after achieving significant progress. However, the question asks for initial actions when building a new team. Delaying such an activity until after the first milestone misses the critical opportunity to establish foundational relationships and norms that are essential for effective collaboration and trust-building from the project's inception.

Provide each team member with a copy of the project management plan

Why it fails: Distributing the project management plan is an important informational step to ensure all team members understand the project scope, schedule, budget, and overall strategy. However, this action primarily focuses on information dissemination rather than active team formation or interaction. It doesn't inherently foster collaboration, establish interpersonal relationships, or build the collective identity necessary for a high-performing team, which are key aspects of team building.

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

Why it fails: Ignoring regulations can have legal consequences.

Update the risk register and move on

Why it fails: 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 it fails: Changes must go through change control first.

Document the conflict in the lessons learned register for future projects

Why it fails: While documentation is good, it is a post-resolution activity, not a primary action to resolve the current conflict.

Make a unilateral decision on resource allocation to end the conflict quickly

Why it fails: Imposing a decision without collaboration may escalate the conflict and damage relationships.

Reassign the team member to less critical tasks to minimize impact

Why it fails: This avoids addressing the performance issue and may not be fair to the team member.

Issue a formal warning and put the team member on a performance improvement plan

Why it fails: This may be premature without understanding all factors; consulting HR first is advisable.

Remove the team member from the project to protect the team's morale

Why it fails: Removal should be a last resort; the PM should first attempt to support improvement.

Instruct the team to start working on the new features immediately

Why it fails: Instructing the Development Team to immediately start working on new features during a Sprint Review is a violation of Scrum principles. The Sprint Backlog represents the Development Team's commitment to delivering a specific Increment towards the Sprint Goal, and introducing new work mid-sprint without proper prioritization and planning undermines this commitment. Such an action disrupts the team's focus, jeopardizes the current Sprint Goal, and can lead to scope creep and decreased predictability.

Agree to extend the sprint by one week to accommodate the changes

Why it fails: Extending the sprint length to accommodate new changes directly violates the Scrum principle of timeboxing. Sprints are fixed-length events, typically 1-4 weeks, providing a consistent rhythm and predictability for the Development Team and stakeholders. Altering the sprint duration undermines the team's ability to forecast, disrupts the regular cadence of planning and review, and can mask underlying issues with scope management or estimation rather than addressing them.

Require all team members to work during the same four-hour overlap window

Why it fails: Mandating a shared four-hour window imposes rigid synchronous hours across four time zones, harming the flexibility that makes virtual teams effective. It tempts because overlap does enable real-time collaboration, and would suit a team spanning only two adjacent time zones with naturally aligned working hours.

Schedule daily stand-up meetings at a fixed time convenient for the project manager

Why it fails: A fixed time chosen for the project manager's convenience forces some time zones into unsociable hours, worsening the disengagement driving the complaints. Rotating meeting times is the inclusive alternative. It tempts because a single recurring slot appears to guarantee attendance, which suits co-located teams sharing one working day.

Assign all critical tasks to other team members

Why it fails: While temporarily reassigning tasks might mitigate immediate risks, it fails to address the underlying skill gap or performance issue of the team member. This approach merely shifts the burden to other team members, potentially leading to burnout or over-reliance on a few individuals, and does not contribute to the long-term development or capability building of the project team. A PMP focuses on sustainable solutions and team growth.

Immediately replace the team member with a contractor

Why it fails: Immediately replacing a team member, especially one with critical skills, is a drastic and often costly measure that should be considered only after all other performance improvement strategies have been exhausted. This action can negatively impact team morale, disrupt project continuity due to onboarding time for a new resource, and may not be justified if the underlying issue is a solvable skill gap rather than a fundamental inability or unwillingness to perform. Project managers prioritize development and retention where feasible.

Ignore the issue, hoping the team member will self-correct

Why it fails: Ignoring performance issues, particularly when critical skills are involved, is a detrimental approach that can lead to escalating problems, project delays, and quality compromises. A project manager has a responsibility to proactively address team member performance, as inaction can negatively impact team morale, foster resentment among other team members, and ultimately jeopardize project success. This passive stance is contrary to effective project leadership.

Provide training on generational differences focusing on each generation's weaknesses

Why it fails: Focusing training on generational weaknesses can inadvertently foster stereotypes and create an environment of judgment rather than collaboration. This approach undermines psychological safety and team cohesion, as it highlights perceived deficiencies instead of leveraging diverse strengths. Effective diversity training emphasizes understanding different perspectives and communication styles to build bridges and enhance mutual respect, not to categorize and critique.

Create a social media group for team bonding

Why it fails: While a social media group can facilitate informal team bonding, it does not directly address the core issue of ensuring equal valuation and inclusion within the project's operational work. Such platforms primarily support social interaction and may not translate into equitable participation, recognition, or influence in project tasks and decision-making processes. True inclusion requires integrating diverse perspectives into the actual work structure and decision-making.

Assign mentors from older generations to younger team members

Why it fails: Assigning mentors exclusively from older to younger generations, while beneficial for individual development, does not inherently ensure equal valuation of all generational contributions within the project team. This structure can inadvertently reinforce a hierarchical knowledge transfer model, potentially overlooking the valuable insights and reverse mentoring opportunities that younger generations offer. True equal valuation requires creating reciprocal learning environments and ensuring all voices are heard and respected in project decision-making, not just through a one-way mentorship.

Immediately direct the team to continue using the new pipeline and escalate the senior developer's resistance to the functional manager.

Why it fails: This is wrong because escalating without first attempting to resolve the issue undermines team autonomy and can damage trust. PMP emphasizes servant leadership and conflict resolution at the lowest level. Directing the team without understanding the technical problems may also ignore legitimate impediments that could be fixed, and escalation should be a last resort after team-based attempts.

Ask the senior developer to document their concerns and present them at the next retrospective, then continue with the new pipeline in the meantime.

Why it fails: This is wrong because it delays resolution until the retrospective, which may be after the sprint goal is already jeopardized. While retrospectives are valuable, immediate impediments require timely attention. This approach also puts the burden solely on the senior developer and does not engage the whole team in finding a solution, which is less effective for urgent issues.

Allow the senior developer to revert to the manual process for the remainder of the sprint to avoid conflict and keep the team moving.

Why it fails: This is wrong because unilaterally reverting to the old process bypasses team decision-making and may create inconsistency, technical debt, and confusion. It also avoids addressing the root cause of the pipeline issues. While avoiding conflict might seem expedient, it sacrifices the team's long-term capability and does not align with PMP's emphasis on collaborative problem-solving.

Escalate to the functional manager for reassignment.

Why it fails: Escalation transfers the decision to the functional manager, who cannot apply the project manager's integrative conflict-resolution techniques or address the working relationship directly. It is tempting because escalation suits genuine authority disputes, resource conflicts beyond the project manager's remit, or repeated non-compliance after direct intervention has already failed.

Ask the team to vote on which style to adopt.

Why it fails: Voting imposes a majority preference, which does not reconcile the two developers' conflicting styles and can entrench the minority's resentment. Team voting suits selecting among options where group consensus genuinely matters, such as choosing a shared tool or process; resolving an interpersonal working-style clash requires direct collaborative problem-solving instead.

Assign them to separate tasks to avoid interaction.

Why it fails: Separating the developers removes the interaction but leaves the underlying conflict unresolved, and the stem requires addressing delays caused by that conflict. Task segregation suits genuinely independent workstreams with no shared deliverables; here the two senior developers must collaborate, so avoidance forfeits the collaboration the project needs.

Reassign the task to another team member.

Why it fails: Reassigning the task to another team member without addressing the root cause of the original team member's consistent lateness is a reactive and short-sighted solution. While it might temporarily resolve the immediate deliverable issue, it fails to correct the underlying performance problem, which could manifest in future assignments or impact other project areas. This approach also bypasses the project manager's responsibility to coach and develop team members, which is critical for long-term team effectiveness and project success.

Ask the team member's manager to intervene.

Why it fails: Asking the team member's functional manager to intervene immediately is an inappropriate first response for a project manager. The project manager has direct responsibility for managing the performance of project team members regarding project-specific tasks and deliverables. Escalating the issue prematurely undermines the project manager's authority and direct communication channels, which are essential for effective project leadership and problem-solving. Direct engagement with the team member should always precede external intervention.

Remove the team member from the project.

Why it fails: Removing a team member from the project is an extreme measure that should only be considered as a last resort, after all other corrective actions and performance improvement efforts have been formally attempted and documented without success. Such an action can significantly disrupt project continuity, incur costs for replacement and onboarding, and negatively impact team morale. A project manager's role includes coaching and developing team members, making immediate removal an abandonment of that responsibility without due process.

Define a new process for requirement clarification and enforce it.

Why it fails: This approach is overly prescriptive and autocratic, directly contradicting the agile principle of self-organizing teams. A Scrum Master or project manager imposing a solution without team involvement stifles ownership and innovation, preventing the team from collaboratively discovering the most effective way to address their challenges and improve their processes.

Tell the team to adapt as best they can with the current requirements.

Why it fails: This response is dismissive and fails to uphold the Scrum Master's role in removing impediments and fostering continuous improvement. It ignores the team's frustration, which is a critical signal identified during a retrospective, and does not facilitate problem-solving or collaboration, thereby hindering agile principles of adaptation and inspect-and-adapt.

Ask the product owner to provide more detailed user stories.

Why it fails: While seemingly helpful, this option is prescriptive and assumes a specific solution without understanding the Product Owner's perspective or the underlying reasons for current story detail levels. It dictates a course of action rather than facilitating a dialogue, potentially creating friction and failing to address the systemic issue collaboratively, which is contrary to agile collaboration and servant leadership.

Send a weekly status email to all team members.

Why it fails: Sending a weekly status email is generally insufficient for a new project manager to quickly establish team cohesion, address immediate impediments, or ensure timely alignment on critical tasks. This method lacks the immediacy and interactive feedback necessary to foster a collaborative environment and proactively manage risks in dynamic project environments, potentially leading to delayed issue resolution and misunderstandings.

Record video updates and share them asynchronously.

Why it fails: While asynchronous video updates offer flexibility, they inherently lack the real-time interactive component crucial for a new project manager to build rapport, facilitate immediate problem-solving, and ensure shared understanding across the team. This one-way communication style prevents spontaneous discussion, clarification of ambiguities, and the collaborative decision-making vital for team integration and effective issue resolution, reducing overall engagement.

Use a group chat for all project communication.

Why it fails: Relying solely on a group chat for all project communication can quickly lead to information overload, significant distractions, and a lack of structured decision-making. Important discussions and decisions can become buried in a continuous stream of messages, making it challenging for a new project manager to track progress, ensure accountability, and maintain a clear, auditable record of critical project information.