People — Leading Projects practice questions

Escalate to the functional manager for reassignment.

Why wrong: Escalation should be a last resort; the PM should attempt resolution first.

Ask the team to vote on which style to adopt.

Why wrong: Voting is not appropriate for resolving interpersonal conflicts.

Assign them to separate tasks to avoid interaction.

Why wrong: Avoidance does not resolve the conflict and may cause further issues.

Reassign the task to another team member.

Why wrong: Reassigning without addressing the issue may not solve the root cause.

Ask the team member's manager to intervene.

Why wrong: The PM should handle performance issues directly first.

Remove the team member from the project.

Why wrong: Removal should be a last resort after documented attempts.

Define a new process for requirement clarification and enforce it.

Why wrong: This undermines team self-organization.

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

Why wrong: Avoids addressing the root cause.

Ask the product owner to provide more detailed user stories.

Why wrong: Dictating to the product owner is not collaborative.

Send a weekly status email to all team members.

Why wrong: Weekly may be too infrequent for alignment.

Record video updates and share them asynchronously.

Why wrong: Lack of real-time interaction reduces engagement.

Use a group chat for all project communication.

Why wrong: Chat can be distracting and may not ensure structured updates.

Schedule one-on-one meetings with only the quiet members.

Why wrong: Singling out may make them feel targeted.

Ask the most senior team member to represent others.

Why wrong: May not capture diverse views.

Implement a round-robin where everyone must speak.

Why wrong: Forcing participation can cause discomfort.

Increase oversight to ensure no tasks are missed.

Why wrong: Micromanagement decreases motivation.

Conduct a blame-free review of recent failures.

Why wrong: Blame-free reviews can help learning but do not directly improve morale.

Offer a bonus for meeting deadlines.

Why wrong: Monetary rewards are not long-term motivators.

Empower the team to make all project decisions.

Why wrong: Empowerment comes after trust is built.

Encourage open conflict to surface issues.

Why wrong: Conflict is productive later; early on it can be destructive.

Enforce the strict process to ensure quality.

Why wrong: Forcing may escalate conflict and reduce collaboration.

Suggest a compromise where both give up some requirements.

Why wrong: Compromise may not fully satisfy either party and could lead to suboptimal outcomes.

Ignore the conflict and hope it resolves itself.

Why wrong: Avoidance leads to unresolved issues and potential project delays.

Move on to the next agenda item to avoid discomfort.

Why wrong: Avoiding the issue does not build a safe environment.

Assign the developer a task to present the idea next week.

Why wrong: This may increase pressure rather than reduce fear.

Privately praise the developer for past contributions.

Why wrong: While positive, it doesn't directly encourage sharing in the meeting.

Use a functional structure where each team works independently.

Why wrong: Reduces collaboration and may cause integration issues.

Co-locate all team members in a single location.

Why wrong: Impractical due to time zone constraints and likely cost prohibitive.

Implement a matrix structure with dual reporting.

Why wrong: Does not specifically address time zone challenges.

Appoint a temporary project manager to oversee the team.

Why wrong: The team is capable of self-management; a new manager may reduce efficiency.

Ask the team to pause all non-urgent decisions until your return.

Why wrong: May cause unnecessary delays and reduce team autonomy.

Schedule daily status calls to monitor progress.

Why wrong: Too intrusive and may undermine team's self-sufficiency.

Continue monitoring; the velocity may recover naturally.

Why wrong: Delaying action could lead to further decline and turnover.

Reduce the project scope to lower pressure.

Why wrong: Scope reduction should be based on data, not assumptions.

Add more team members to distribute the workload.

Why wrong: New members require onboarding and may not alleviate burnout quickly.

Avoid discussing potential conflicts to maintain harmony.

Why wrong: Suppressing conflict leads to unresolved issues.

Mandate overtime to meet aggressive deadlines.

Why wrong: Causes burnout and reduces long-term productivity.

Assign roles and responsibilities without team input.

Why wrong: Reduces ownership and may cause resistance.

Wait until the next stakeholder feedback cycle to address concerns.

Why wrong: Delays resolution and risks escalation.

Reduce the number of status meetings to avoid information overload.

Why wrong: May further alienate the stakeholder.

Decide on the technical approach yourself and instruct the team.

Why wrong: Imposing a solution may reduce team ownership and morale.

Escalate the issue to the project sponsor for a decision.

Why wrong: Escalation should be a last resort; the PM should try to resolve first.

Reassign the developers to different tasks to avoid further conflict.

Why wrong: Avoidance does not resolve the underlying disagreement.

Use a shared spreadsheet to track tasks and progress.

Why wrong: Spreadsheets lack real-time communication features.

Create a project wiki and ask team members to update it regularly.

Why wrong: Wikis are static and may not foster active collaboration.

Schedule a weekly status email to all team members.

Why wrong: Email alone is insufficient for interactive collaboration.

Conduct daily stand-up meetings to clarify tasks.

Why wrong: Helpful but does not replace a formal responsibility assignment.

Require team members to create their own task lists and share them.

Why wrong: May lead to inconsistencies and overlaps.

Assign tasks based on seniority and expertise.

Why wrong: Does not clarify responsibilities comprehensively.

Assign a liaison from each culture to mediate communications.

Why wrong: May create bottlenecks and does not address root cause.

Standardize all communication to be direct and explicit.

Why wrong: May alienate high-context culture members.

Ask team members from low-context cultures to adapt to high-context styles.

Why wrong: Unfair and not a balanced approach.

Address the issue in the next team meeting to set expectations.

Why wrong: Public confrontation can damage trust and morale.

Reassign the team member to less critical tasks.

Why wrong: Avoids the issue and may not address root cause.

Report the team member to HR for performance improvement plan.

Why wrong: Should be a last resort after direct discussion.

It serves as a formal communication plan for the project.

Why wrong: Communication plan is a separate document.

It provides a basis for performance evaluations and bonus calculations.

Why wrong: Not the purpose of a team charter.

It clearly defines each team member's specific roles and responsibilities.

Why wrong: Roles/responsibilities are defined in RACI, not charter.