Time to check what's stuck. This lesson works through five scenario-based questions that mirror what you'll face on a real project — and on a PMP or CAPM exam. Read each scenario, think through your answer, then read the explanation.
Question 1 — Is this a project?
Scenario: Your organisation's finance team processes supplier invoices every week using a documented three-step approval workflow. Is this a project?
Answer: No. Ongoing, repetitive work with no defined end date and no unique output is an operation, not a project. The finance team is running a process, not delivering a unique result.
Why it matters: Applying project management overhead to operational work adds cost without benefit. The distinction helps you decide whether something needs a PM at all — or just a good process owner.
Question 2 — The triple constraint
Scenario: A stakeholder asks you to add a new reporting module to a software project two weeks before the deadline. The budget is fixed. What do you do?
Answer: Surface the trade-off. Adding scope with a fixed budget and an immovable deadline means something else must be cut. Present the options: reduce scope elsewhere, extend the deadline (if possible), or defer the new module to a post-launch release. Never simply agree to absorb the addition.
Why it matters: Saying yes to scope without adjusting another constraint is how projects go over budget and miss deadlines. Your job is to make the trade-off visible, not to absorb it quietly.
Question 3 — Phase order
Scenario: Your manager is under pressure and asks you to skip the planning phase and move straight into execution to save time. What's the risk?
Answer: Execution without planning creates the illusion of speed. Without a defined scope, schedule, and risk register, the team works hard but in potentially the wrong direction. Rework, missed dependencies, and late-breaking stakeholder issues are the typical result — and fixing them costs far more time than planning would have taken.
Why it matters: Planning is an investment, not a delay. A week of solid planning typically saves three to five weeks of firefighting during execution.
Question 4 — Who signs the charter?
Scenario: You've drafted a project charter. Your manager says you should sign it yourself since you're the PM. Is this correct?
Answer: No. The charter is signed by the project sponsor — the senior leader who is authorising and funding the project. The PM's name appears in the charter as the appointed lead, but the authority comes from the sponsor's signature.
Why it matters: A charter signed by the PM instead of the sponsor carries no organisational weight. When you need to escalate a resource conflict or push back on a scope request, you need a sponsor-signed document behind you.
Question 5 — Temporary teams
Scenario: You're managing a cross-functional team where most members still report to their department heads. One team member consistently deprioritises project tasks in favour of their 'day job'. What's the most effective first step?
Answer: Have a direct conversation with the team member to understand the competing demands, then escalate to the sponsor if the conflict can't be resolved at the team level. The sponsor has the authority to negotiate with the functional manager — the PM usually doesn't.
Why it matters: Most PMs have influence, not authority, over their teams. Knowing when to escalate — and to whom — is a critical skill. Trying to force compliance without authority erodes the relationship and rarely works.
Course complete — what's next
You've covered the foundations: what a project is, the lifecycle that structures it, the roles that run it, and the charter that authorises it. These aren't just concepts — they're the vocabulary and the mental model you'll use on every project from here.
Head to the Intermediate courses to go deeper. Scope, Time & Cost will show you how to build a real WBS and estimate with confidence. Working with Stakeholders will give you the tools to manage the people side of delivery.