People — Leading Projects practice questions

Increase oversight to ensure no tasks are missed.

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Ask the remaining team members to absorb the departing member's tasks

Why wrong: Simply asking remaining team members to "absorb" additional tasks without a structured assessment of their current workload, capacity, or relevant skills is a significant risk. This approach often leads to team overload, decreased morale, burnout, and potential quality issues or missed deadlines due to an unmanaged increase in individual responsibilities. Effective project management requires a deliberate redistribution strategy to maintain productivity and team well-being.

Immediately hire a replacement with similar skills

Why wrong: While hiring a replacement is a necessary long-term solution, prioritizing immediate hiring is often impractical and not the most effective first response during an unexpected resignation. The recruitment process, including sourcing, interviewing, and onboarding, typically takes significant time, leaving an immediate resource gap. The primary focus should instead be on immediate knowledge transfer and task redistribution to maintain project progress and mitigate short-term risks.

Assign more challenging tasks to stretch their capabilities

Why wrong: While challenging tasks can be a motivator for some, particularly those seeking growth, unilaterally assigning them without assessing individual readiness, providing adequate support, or ensuring a balanced workload can lead to burnout, increased stress, and demotivation. This approach risks overwhelming team members rather than empowering them, potentially hindering project progress and team morale if not managed carefully with appropriate coaching.

Implement a penalty system for missed deadlines

Why wrong: Implementing a penalty system for missed deadlines primarily relies on fear and extrinsic negative reinforcement. This approach often erodes trust, fosters a blame culture, and can significantly demotivate team members, leading to reduced creativity, collaboration, and overall job satisfaction, which is counterproductive to building a high-performing project team focused on problem-solving and continuous improvement.

Offer monetary bonuses for early completion of milestones

Why wrong: While monetary bonuses can provide short-term extrinsic motivation, they often fail to foster sustainable intrinsic drive or long-term commitment. Over-reliance on such incentives can encourage a focus on speed over quality, lead to team members prioritizing individual gain over collaborative success, and may not address underlying issues causing performance gaps, potentially creating an unhealthy competitive environment within the project team.

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

Why wrong: 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 wrong: 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 wrong: 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.

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.

Provide individual rewards for top performers to motivate competition

Why wrong: For a newly formed team, emphasizing individual rewards for top performers can foster internal competition rather than the necessary collaboration and trust-building. This approach risks creating silos, discouraging knowledge sharing, and undermining the collective effort required to establish a cohesive and high-performing team. The primary focus for new teams should be on establishing a unified identity and shared success, not on individual accolades that can divide.

Assign a mentor from outside the team to guide team members

Why wrong: While mentorship is valuable, assigning an external mentor to a newly formed team may not effectively address the critical internal team dynamics and integration challenges. An outside mentor lacks direct insight into the nascent interpersonal relationships, emerging communication patterns, and specific project context that are crucial for a new team to coalesce. The immediate need is to build internal cohesion and shared understanding within the team itself, which an external mentor cannot directly facilitate.

Escalate the issue to the steering committee for guidance

Why wrong: Escalating to the steering committee at this initial stage is premature and bypasses the project manager's primary responsibility for risk management. A project manager is expected to first utilize established risk response plans, such as a contingency plan, which falls within their authority and scope of action. Escalation is typically reserved for risks that exceed the project manager's authority, resources, or impact thresholds, or when planned responses have proven ineffective, not as a first resort.

Brainstorm new solutions with the team since the risk was not anticipated

Why wrong: This option is incorrect because the question implies the risk of a critical vendor issue was anticipated, as evidenced by the existence of a "contingency plan" in the correct answer. Brainstorming new solutions, also known as developing a workaround, is typically reserved for unidentified risks that occur (unknown-unknowns) or when an existing risk response plan proves inadequate. Relying on ad-hoc brainstorming for an anticipated risk indicates a failure in prior risk planning.

Wait to see if the vendor can resolve the issue before taking action

Why wrong: Waiting for the vendor to resolve the issue without taking immediate action is a passive and irresponsible approach to risk management. This delay can significantly exacerbate the negative impact on the project's schedule, budget, and scope, potentially turning a manageable risk into a crisis. Effective project management requires proactive intervention and the prompt execution of planned responses to minimize adverse consequences, rather than hoping the problem resolves itself.

Encourage team members to use instant messaging for all communication

Why wrong: Encouraging team members to use instant messaging for all communication is an inadequate strategy for managing a complex project team. While instant messaging is effective for quick, informal exchanges, it lacks the structure, detail, and archival capabilities required for critical project discussions, formal decision-making, or comprehensive updates. Over-reliance on this informal channel can lead to misinterpretations, information fragmentation, and a lack of proper documentation, ultimately hindering effective project communication and accountability.

Increase the frequency of status reports to ensure everyone is updated

Why wrong: Increasing the frequency of status reports primarily serves as a one-way information dissemination mechanism, which is insufficient for building a cohesive and collaborative virtual team. While reports provide updates, they do not facilitate interactive problem-solving, dynamic discussions, or the relationship-building essential for team cohesion. An overemphasis on reporting can also create an administrative burden, diverting time from more productive, interactive engagement necessary to foster a strong team dynamic and address complex issues collaboratively.

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

Why wrong: Requiring all team members to work the same hours regardless of their time zone is an impractical and detrimental approach for virtual teams. This strategy disregards individual work-life balance, local cultural norms, and physiological needs, leading to significant burnout, reduced productivity, and high levels of resentment. Such an inflexible policy can severely damage team morale, increase attrition rates, and ultimately undermine the benefits of a globally distributed workforce, making it unsustainable in the long term.

Assign team members to specific tasks immediately to ensure quick progress

Why wrong: 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 wrong: 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 wrong: 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.

Work breakdown structure (WBS)

Why wrong: The Work Breakdown Structure (WBS) is a deliverable-oriented hierarchical decomposition of the total scope of work to be carried out by the project team. Its primary purpose is to organize and define the project's total scope, breaking down project deliverables into smaller, more manageable components. While it clarifies *what* work needs to be done, it explicitly does not assign *who* performs the work or define individual roles and responsibilities, thus it cannot resolve role ambiguity.

Risk register

Why wrong: The risk register is a project document used to record, track, and manage identified risks throughout the project lifecycle. It typically includes details such as risk descriptions, probability, impact, risk owners, and planned responses. Its function is solely focused on risk management, not on defining the organizational structure or the specific roles and responsibilities of project team members, making it irrelevant for clarifying team roles.

Project schedule

Why wrong: The project schedule is a model that presents linked activities, durations, and dependencies, illustrating the sequence and timing of work to be performed. Its main objective is to show *when* tasks are to be completed and the critical path for project completion. While it organizes the project timeline, it does not inherently define *who* performs each task or their specific responsibilities within the team structure, making it ineffective for resolving role ambiguity.

Monitor team interactions closely and report any issues to senior management

Why wrong: This approach demonstrates a fundamental lack of trust in the team's ability to self-manage and resolve minor issues, fostering an environment of micromanagement. Prematurely escalating team interaction issues to senior management undermines the project manager's role in facilitating team development and problem-solving, thereby damaging team morale and cohesion. It prevents the team from developing essential self-sufficiency and conflict resolution skills.

Assign individual tasks and avoid collaboration to prevent conflict

Why wrong: While seemingly preventing immediate conflict, this strategy severely limits the inherent benefits of a virtual team, such as diverse perspectives, shared problem-solving, and collective ownership. It actively inhibits the formation of a cohesive team identity and prevents members from leveraging each other's unique strengths, which are crucial for complex project success and robust team development. This approach fails to address underlying communication or interpersonal challenges proactively.

Allow the team to self-organize without any initial guidance

Why wrong: For a newly formed virtual team, especially one that has never collaborated, a complete lack of initial guidance can lead to significant confusion, duplicated efforts, and unmet expectations regarding roles and processes. While self-organization is a desirable long-term goal for mature teams, new teams require a structured foundation, clear objectives, and defined operating principles to establish effective collaboration and productivity. Without this initial framework, the team may struggle to gain traction and achieve project goals efficiently.

Add more team members to the sprint

Why wrong: Adding more team members to an ongoing sprint often decreases productivity initially due to increased communication overhead and the time required for new members to onboard and understand the project context. This phenomenon, known as Brooks's Law, suggests that adding resources to a late software project makes it later, as the existing team must divert effort to training and integration rather than feature development. It rarely provides an immediate solution for low velocity and can disrupt established team dynamics.

Replace underperforming team members

Why wrong: Replacing team members is a drastic and demotivating action that should only be considered after extensive coaching, performance management, and root cause analysis have failed. Low sprint velocity is often a systemic issue related to process, environment, or unclear requirements, rather than solely individual underperformance. Such a move can severely damage team morale and trust, potentially exacerbating velocity problems and creating a culture of fear.

Increase the sprint length to give the team more time

Why wrong: Increasing sprint length merely postpones the problem and does not address the underlying causes of low velocity, such as unclear requirements or technical impediments. Agile principles emphasize short, iterative cycles to maximize feedback and adaptability; longer sprints reduce the frequency of inspection and adaptation, delaying value delivery and potentially leading to larger, more complex issues at the sprint review. This approach often masks inefficiencies rather than resolving them.

Remove the developers from the project to avoid further conflict

Why wrong: Removing developers from the project is an extreme and generally counterproductive measure for conflict resolution, especially for disagreements over technical standards. This action leads to a significant loss of project knowledge and experience, disrupts team dynamics, and negatively impacts project velocity and morale. A PMP's role is to facilitate resolution and foster a productive environment, not to eliminate team members as a first or even early resort, which could be seen as an avoidance tactic rather than true resolution.

Decide on a coding standard yourself and enforce it

Why wrong: As an agile project manager, unilaterally deciding on and enforcing a coding standard is an autocratic approach that undermines the principles of self-organizing teams and shared ownership. While it might offer a quick fix, it often leads to resentment, reduced buy-in, and passive resistance from the developers, as they were not involved in the decision-making process. This diminishes team autonomy and misses an opportunity to build consensus and improve team collaboration through shared problem-solving.

Escalate the conflict to the functional managers of the developers

Why wrong: Escalating the conflict to functional managers prematurely bypasses the project team's ability to self-organize and resolve internal issues, which is a core agile principle. A project manager's primary responsibility is to facilitate conflict resolution within the team, providing support and tools for them to work through disagreements. Escalation should only be considered after the project manager has exhausted all reasonable attempts to mediate and facilitate a resolution directly with the involved parties, as it can disempower the team.

Instruct the team to start implementing the change immediately

Why wrong: Directing the team to implement a significant change, like one stemming from a new regulatory requirement, without formal approval from the Change Control Board (CCB) is a critical deviation from integrated change control. Such an action bypasses established governance, risks unauthorized scope creep, misallocation of resources, and potential rework if the change is later rejected or modified. All changes impacting baselines must follow the defined change control process to maintain project integrity and control.

Ignore the regulation because the project is already underway

Why wrong: Ignoring a new regulatory requirement simply because the project is already in the execution phase is a severe breach of compliance and project governance. Regulatory non-compliance can lead to significant legal penalties, fines, project suspension, reputational damage, and even project cancellation. Project managers are obligated to ensure the project adheres to all applicable laws, regulations, and standards throughout its lifecycle, necessitating immediate action to address such changes.

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.

Require everyone to work the same core hours regardless of time zone

Why wrong: Mandating uniform core hours for a team spread across three continents is impractical and detrimental to team morale and productivity. This approach forces some members to work during their night hours, leading to burnout, reduced engagement, and potential resentment, directly violating principles of sustainable project management and team well-being. It fails to leverage the benefits of asynchronous work and exacerbates, rather than alleviates, the challenges of time zone differences and feelings of isolation.

Send a weekly email newsletter with project updates and achievements

Why wrong: A weekly email newsletter is a one-way communication tool primarily focused on information dissemination, not interaction or relationship building. While useful for status updates and acknowledging achievements, it does not facilitate the two-way dialogue, spontaneous interactions, or personal connections essential for fostering team cohesion and trust in a virtual setting. It fails to address the emotional and social needs of a distributed team, which are critical for mitigating isolation and building a strong team identity.

Assign a mentor to each new team member from a different region

Why wrong: Assigning individual mentors is beneficial for onboarding and professional development, particularly for new team members integrating into a diverse, virtual environment. However, this strategy primarily focuses on individual support and knowledge transfer rather than fostering collective team cohesion or addressing widespread feelings of isolation across the entire group. While valuable for individual growth and integration, it does not create the broad, informal social connections or shared team identity necessary for a high-performing distributed team.

Implement a strict performance review system with individual targets

Why wrong: Implementing a strict performance review system primarily focused on individual targets can inadvertently foster internal competition among team members rather than promoting the necessary collaboration for project success. This approach risks creating silos, discouraging knowledge sharing, and potentially undermining trust, particularly in a global team where collective effort and mutual support are paramount for overcoming geographical and cultural barriers.

Rotate team members across different roles to increase versatility

Why wrong: While rotating team members across different roles can enhance individual versatility and cross-functional understanding over time, it is not the most direct or effective strategy for initially building collaboration and trust within a new global team. This approach might introduce additional complexity, stress, and uncertainty, potentially hindering the establishment of stable working relationships and clear responsibilities, which are foundational for trust and effective teamwork.

Assign a single communication tool and require its exclusive use

Why wrong: Mandating the exclusive use of a single communication tool, without considering the diverse technical capabilities, time zones, or cultural preferences of a global team, can inadvertently hinder effective communication rather than streamline it. This rigid approach may create barriers for team members who are less familiar with the tool, lack reliable access, or prefer alternative methods for specific types of interactions, ultimately impeding information flow and collaboration.

Ignore the conflict and hope it resolves on its own

Why wrong: 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 wrong: 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 wrong: 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.