Google Project Management common mistakes
Google Project Management · Understand the traps and how to avoid them.
Treating 'project', 'program', 'portfolio' and 'operations' as interchangeable and answering from a gut sense of size or importance (e.g. calling a large initiative a program just because it is big, or labelling ongoing customer support work a project).
Everyday business language blurs these terms, so candidates fall back on intuition instead of the formal definitions. The exam deliberately uses scenarios where a big effort is still a single project and a small effort is still a program.
What to do instead
Memorise and apply a hard decision rule before reading the options: a project is temporary and produces a unique deliverable; a program is a group of related projects managed together for shared benefit; a portfolio is a collection of projects/programs aligned to organisational strategy; operations is ongoing, repetitive work with no defined end date. Size never decides the label - the presence of an end date and a unique deliverable does.
Overstating or understating the project manager's authority - choosing options where the PM approves the project charter, sets or releases the budget, signs off on their own scope changes, or personally makes every decision on the team.
Learners map the PM role onto a general 'manager' mental model from other workplaces. The Google course defines PM authority very narrowly (coordination, communication, planning, monitoring) with the sponsor holding the money and approval power.
What to do instead
Anchor the role split: the sponsor authorises the project via the charter, provides resources and budget, and approves major changes or escalations; the PM plans, executes, monitors, communicates, and manages the team day to day without unilateral budget authority. When an option has the PM 'approving' funding, charter, or scope changes, it is almost always wrong; when it has the PM facilitating, documenting, communicating, or escalating to the sponsor, it is usually right.
Confusing the project charter with the business case, the project scope statement, or the project plan - for example selecting 'scope statement' when asked what formally authorises the project, or saying the charter contains the detailed WBS and schedule.
All of these are early documents, and the course presents them close together, so they blur into 'the startup paperwork'. The distinguishing feature (authorisation versus justification versus detail) is what the exam actually tests.
What to do instead
Lock in a one-line definition per document: business case = why we should do this (cost-benefit justification); project charter = the formal authorisation that names the sponsor, the high-level goal, the success criteria, and the PM; scope statement and project plan = what and how, developed later in planning. If the question stem asks what 'authorises' or 'kicks off' the project, the answer is the charter.
Treating stakeholder analysis as a general list-making exercise - assuming every stakeholder needs identical communication, defining stakeholders as only the paying client, or misapplying the power/interest grid (e.g. giving detailed weekly updates to a high-power, low-interest stakeholder instead of keeping them satisfied with brief summaries).
Stakeholders feel like a 'soft' topic, so candidates skim the grid logic and then answer from politeness instincts ('keep everyone fully informed at all times'), which contradicts the tailored-communication principle.
What to do instead
Practise the four quadrants explicitly: high power/high interest = manage closely; high power/low interest = keep satisfied with concise, high-level updates; low power/high interest = keep informed; low power/low interest = monitor. Also remember stakeholders include the sponsor, team, end users, suppliers, and functional managers - not just the client - and that the goal is fit-for-purpose communication, not maximum volume.
Mixing up the WBS, work packages, and milestones - describing the lowest WBS level as a task or milestone, saying the WBS sequences activities in date order, or choosing 'milestone' as the smallest unit of work.
In practice people build task lists that look like WBSs, so the deliverable-oriented nature of decomposition gets lost. The exam tests whether decomposition is deliverable-based or activity-based.
What to do instead
Remember three facts: a WBS decomposes deliverables (not activities) into progressively smaller components; the lowest level is a work package, which is then broken into activities/tasks during scheduling; a milestone has zero duration and marks a significant point, so it can never be 'work'. If an option says the WBS is organised by calendar sequence, eliminate it.
Choosing the wrong risk response strategy - picking a contingency plan when the question asks how to reduce the likelihood of the risk, saying 'accept' for a risk with a funded backup plan, or confusing avoidance with mitigation.
The strategy names are familiar English words with overlapping everyday meanings, and candidates answer by vibe ('we'd just deal with it') rather than by matching the definition to the verb in the question stem.
What to do instead
Map each verb to exactly one strategy before answering: avoid = change the plan to eliminate the risk; mitigate = reduce probability and/or impact before it occurs; transfer = shift financial impact to a third party (insurance, fixed-price contract); accept = acknowledge and handle if it happens (passive acceptance has no plan, active acceptance has a contingency reserve); escalate = outside your authority. If the stem says 'reduce the chance it happens', mitigation is the only fit.
Misidentifying team development stages and conflict handling - labelling a team that is clashing over roles and processes as 'norming', assuming a performing team never disagrees, or choosing to suppress/avoid conflict as the standard good answer.
Candidates remember the stage names as a generic list without the behavioural markers, and they import a 'conflict is bad' instinct that the course does not endorse.
What to do instead
Attach a behaviour to each stage: forming = polite, uncertain, dependent on the leader; storming = friction over goals, roles, and processes; norming = agreements form, trust builds, collaboration starts; performing = self-directed high output; adjourning = wrap-up and release. For conflict questions, prefer options that surface the issue and address it directly and collaboratively (e.g. facilitated discussion, focusing on interests not positions), and reject avoidance or smoothing as the default best answer.
Reflexively escalating or personally taking over in people-and-problem scenarios - for example picking 'escalate to the sponsor' as the first step when a stakeholder is unhappy with progress, or choosing to fix a team member's work personally instead of coaching or delegating.
Escalation feels safe and decisive, and 'do it myself' feels efficient, but both skip the diagnostic step. Exam scenarios almost always reward direct communication, information gathering, and empowering the team before escalating.
What to do instead
Apply a first-action ladder: gather information and talk directly to the person or team involved → attempt resolution within your authority (coach, renegotiate, adjust plan) → document → escalate to the sponsor only when the issue is beyond your authority or has already failed at a lower level. Whenever an option jumps straight to the sponsor or to doing the work yourself, treat it as a distractor unless the stem explicitly says the PM has no authority or prior attempts failed.
Swapping Scrum roles, events, and artifacts - saying the Scrum Master assigns tasks and owns the backlog, the Product Owner runs the Daily Scrum, the Sprint Review is the process-improvement meeting, or that the Sprint Retrospective is where the increment is demonstrated to stakeholders.
The three roles and four/five events are taught in one block and all sound 'meeting-ish' and 'leadership-ish', so they collapse together under exam pressure.
What to do instead
Anchor each item to a single distinguishing verb: Product Owner = prioritises and owns the product backlog and maximises value; Scrum Master = facilitates, coaches, and removes impediments (never assigns work); Developers = self-organise and deliver the increment. Events: Sprint Planning = choose what and how; Daily Scrum = synchronise and inspect progress toward the sprint goal; Sprint Review = demo the increment and gather stakeholder feedback; Retrospective = inspect the team's process and agree improvements. Match the verb in the option to the verb in the definition and eliminate on mismatch.
Treating Agile as the universally correct answer - choosing Agile for fixed-scope, fixed-deadline, regulatory or well-understood work, or endorsing the myth that Agile means no planning, no documentation, and no defined roles.
Agile is framed positively throughout the course, and candidates conflate 'modern and collaborative' with 'always appropriate'. Distractor options exploit both directions of this bias.
What to do instead
Decide by uncertainty and change, not by fashion: Agile fits when requirements are unclear or likely to change, when early and frequent delivery adds value, and when the customer can collaborate throughout; Waterfall/hybrid fits when scope is stable and mandated, when heavy documentation or regulatory sign-off is required, or when dependencies make sequential phases unavoidable. Also reject any option claiming Agile has no planning or no documentation - it has iterative planning (roadmap, release planning, sprint planning) and 'just enough' documentation.
Answering the question that was expected rather than the one written - missing sequencing keywords ('first', 'next', 'immediately', 'before'), missing negative stems ('EXCEPT', 'NOT'), and picking the most comprehensive or most senior-sounding option instead of the correct next step in the scenario's specific constraints.
Scenario-based questions are long and candidates pattern-match on topic words to save time, so a plausible-but-out-of-order action wins over the correct immediate step. Under time pressure the 'most thorough' option also feels safest.
What to do instead
Build a fixed reading routine: read the call at the end of the stem first, underline the sequencing or negative keyword, then restate the scenario's constraints (budget, deadline, stakeholder, phase) in one line before evaluating options. Eliminate any option that is a later step than the one asked for, even if it is a good action, and eliminate any option that ignores a stated constraint. When two options both seem right, choose the one that is the earliest reasonable action consistent with the PM's authority.