Project Management Fundamentals Quiz
True / False
Select all that apply
Put in order
Select all that apply
Put in order
Put in order
True / False
Frequent Project Management Fundamentals Mistakes (and Practical Fixes)
Most avoidable project failures come from small fundamentals being handled informally. Watch for these recurring errors and the concrete habits that prevent them.
Starting execution before the project is authorized
- Mistake: Treating early work as “just getting started” without a charter, sponsor alignment, or defined success criteria.
- Fix: Confirm sponsor, high-level scope, measurable objectives, and approval to proceed before planning details.
Confusing scope definition with a task list
- Mistake: Writing scope as activities (“build screens”) instead of deliverables (“approved UI design package”).
- Fix: Define deliverables, acceptance criteria, and out-of-scope items; then decompose deliverables into a WBS.
Building a schedule without dependencies or ownership
- Mistake: Dates assigned to tasks that have no predecessors, no resource assignments, and no clear definition of done.
- Fix: Sequence work with explicit dependencies, assign owners, and use milestones for approvals/hand-offs.
Mixing up risks, issues, and assumptions
- Mistake: Logging a current blocker as a “risk,” or treating a fragile assumption as if it were true.
- Fix: Use a RAID-style approach: risks are uncertain future events; issues are happening now; assumptions need validation dates.
Letting change requests bypass impact analysis
- Mistake: Accepting “small” changes without checking effect on scope, schedule, cost, and quality.
- Fix: Require a brief impact note (what changes, by how much, who approves) before updating baselines.
Reporting activity instead of control information
- Mistake: Status updates that list what people did, but omit variances, decisions needed, and forecasted completion dates.
- Fix: Report against baselines: planned vs actual, key risks/issues, upcoming milestones, and concrete asks.
Project Management Fundamentals Field Sheet (Print/Save as PDF)
Use this as a quick reference while studying or running a project. Tip: print this page or save it as a PDF so you can keep it next to your project plan.
Process groups (what “good” looks like)
- Initiating: Confirm business need, name sponsor/PM, identify high-level scope, and authorize work (charter).
- Planning: Define scope/WBS, schedule, cost approach, quality criteria, resource plan, comms plan, risk plan, procurement approach.
- Executing: Deliver work packages, manage team, manage stakeholder engagement, run quality assurance activities.
- Monitoring & Controlling: Measure performance vs baselines, control scope/schedule/cost/quality, manage change requests.
- Closing: Formal acceptance, transition/handover, close contracts, capture lessons learned.
Core artifacts (minimum viable set)
- Charter: why/what/who at a high level; authorizes the PM.
- Scope statement + acceptance criteria: boundaries and “done.”
- WBS: deliverable decomposition; supports estimating and assignment.
- Schedule baseline: milestones + dependency logic + resource assignments.
- RAID log: Risks, Assumptions, Issues, Dependencies with owners and dates.
- Change log: request → impact → decision → implementation date.
- Stakeholder register + comms plan: audience, message, cadence, channel, owner.
Scheduling essentials
- Critical path: longest path through the network; tasks on it have zero total float.
- Float (slack): how long a task can slip without delaying the end date (given current logic).
- Fast tracking: overlap tasks (risk: rework). Crashing: add resources/cost to shorten duration.
Earned value (if used)
- PV (Planned Value), EV (Earned Value), AC (Actual Cost)
- CPI = EV / AC (cost efficiency); SPI = EV / PV (schedule efficiency)
- Interpretation: CPI < 1 is over budget; SPI < 1 is behind schedule.
Change control (lightweight)
- Describe the change and the driver (regulatory, defect, stakeholder request).
- Estimate impact to scope, schedule, cost, risk, and quality.
- Get approval from the right authority (sponsor/CCB/product owner).
- Update baselines and communicate the decision with the new plan.
Job Task-to-Skill Map: What the Quiz Covers in Real PM Work
This quiz aligns to the day-to-day decisions that distinguish a structured project manager from an “accidental PM.” Use the map below to connect quiz topics to on-the-job outcomes.
1) Initiate and align the work
- Job task: Clarify why the project exists, who owns outcomes, and what success means.
- Skills assessed: Charter vs project plan, SMART objectives, initial scope boundaries, identifying stakeholders and constraints.
- What good looks like: Sponsor can state success criteria; team understands what is explicitly not included.
2) Turn deliverables into a plan you can manage
- Job task: Break work into deliverables and manageable components, then estimate and sequence.
- Skills assessed: Scope statement and WBS quality, dependencies, milestones, resource assignment, realistic estimating.
- What good looks like: Schedule is explainable (logic-driven), not just date-driven.
3) Control scope, schedule, and cost under change
- Job task: Evaluate new requests and protect baselines while still enabling value.
- Skills assessed: Change control steps, impact analysis, baseline management, variance interpretation, corrective vs preventive actions.
- What good looks like: Changes are decisions with documented trade-offs, not surprises.
4) Communicate for decisions (not just visibility)
- Job task: Keep stakeholders aligned with concise, decision-oriented updates.
- Skills assessed: Stakeholder analysis, communication planning, escalation triggers, meeting hygiene, status report structure.
- What good looks like: Stakeholders know current health, next milestones, top risks, and what you need from them.
5) Manage uncertainty and close cleanly
- Job task: Identify risks early, resolve issues quickly, and formalize acceptance and learning at the end.
- Skills assessed: Risk register usage, response strategies (avoid/mitigate/transfer/accept), issue management, lessons learned.
- What good looks like: Fewer “fire drills,” clearer handover, and reusable improvements for the next project.
Project Management Fundamentals FAQ: Scope, Schedule, Risk, and Control
What’s the difference between a scope statement and a WBS?
A scope statement defines boundaries: the major deliverables, acceptance criteria, constraints, and what’s out of scope. A work breakdown structure (WBS) decomposes those deliverables into smaller components so you can estimate, assign owners, and track completion. If a WBS element can’t be traced back to an approved deliverable, it’s a scope creep warning.
How do you handle scope creep without creating bureaucracy?
Use a lightweight rule: no change without impact. Capture the request, estimate effect on schedule/cost/risk/quality, and route approval to the right decision-maker (often the sponsor or a small change authority). If the change is accepted, update baselines and communicate the new commitments; if rejected, document the decision so it doesn’t reappear as “verbal scope.”
When should you use critical path thinking versus a simple task board?
Critical path analysis is most useful when the project has dependency-driven sequencing (approvals, hand-offs, lead times, integration points) and a fixed milestone date. A task board is great for visualizing flow, but it can hide dependency risk; pair it with a milestone plan and explicitly track the chain of work that gates the end date.
What belongs in a weekly project status update?
Report information that enables control: (1) progress against milestones, (2) key variances (planned vs actual), (3) top risks and active issues with owners and due dates, (4) decisions needed and by when, and (5) next-week focus. Avoid activity-only lists; stakeholders need implications and requests, not a diary.
What’s a practical way to build a risk register that people actually use?
Keep it short and operational: each risk needs a clear trigger, probability/impact rating, an owner, and a response you can execute (mitigate, avoid, transfer, accept) plus a target date. Review it at a predictable cadence (often tied to milestone checkpoints) and convert triggered risks into issues immediately so accountability doesn’t get lost.
What does “done” mean in project management fundamentals?
“Done” is verified and accepted, not just “worked on.” Define acceptance criteria early (tests passed, sign-off obtained, documentation delivered, training completed, handover performed). Many schedule slips come from hidden completion work—reviews, approvals, rework—so the quiz emphasizes linking deliverables to measurable acceptance.