---
title: "PMGT 170 · Get projects done on time"
publisher: Maestro College (Maestro Open)
lessons: 38
source: https://open.maestrocollege.edu/get-projects-done-on-time
full: https://open.maestrocollege.edu/get-projects-done-on-time/llms-full.txt
---

# Get projects done on time (PMGT 170)

Start, plan, lead and deliver a project, with the tools and habits that keep work on time.

Project Management introduces project lifecycle management and methodologies. Students explore project planning, agile methodologies, team coordination, risk management, and modern project management and collaboration tools

## Course objectives
- Project management fundamentals
- Project planning and scheduling
- Managing teams and resources
- Agile and traditional methodologies
- Identifying and managing project risks
- Defining success metrics (SMART, leading and lagging indicators)
- Building work breakdown structures, estimates, and critical paths

## Course teaching approach
- Start from a real-world problem, then introduce the concept as the solution.
- Keep it true beginner level, hands-on, a little gamified. The learner should feel they are winning.
- Balance explanation, demonstration and practice. No copy-paste exercises: give small story-based tasks.
- End with one fun closed question about the topic.

## Lessons
### Unit 1: Starting a project
#### 1. Why project management matters for your career
- Identify what a project manager actually does — turning a goal into a structured plan with clear tasks, owners, deadlines, and risk responses
- Identify the most common reasons projects fail, including unclear scope, poor communication, and unmanaged risks
- Identify how a project manager's core responsibilities directly address these common failure factors

Teaching notes: Do not introduce the CrossTown Fitness scenario here — that happens in the next lesson. Use short, varied real-world examples of project failures (e.g., software launches with unclear scope, events that missed deadlines because of poor communication, rollouts that broke because risks were ignored) to illustrate each failure factor. For each failure factor — unclear scope, poor communication, unmanaged risks — connect it to a specific core PM responsibility so the learner sees exactly why the discipline exists. Keep this short; the course will return to each failure mode in depth later.

#### 2. Framing the project problem and defining success
- Distinguish between a business problem, a project deliverable, and a desired outcome
- Write a clear problem statement that focuses on the observarble problem and not the solution or root cause hypothesis
- Define 2-3 project success metrics by aligning them with goals, applying SMART criteria, clearly specifying their definition, and selecting appropriate metric types  leading and lagging)

#### 3. Project stakeholders
- Identify the main stakeholder groups for a project and describe what each one cares about
- Distinguish between stakeholders with high influence and stakeholders with high interest at a beginner level
- Create a stakeholder register with exactly 5–7 stakeholders, each row covering: name or group, one-line interest, influence (high/low), and one line on what this means for the project

Teaching notes: Use the CrossTown Fitness scenario here. Explain that before writing a charter, a project manager needs to know who cares about the project, what each group wants, and whose needs will shape success. Keep the lesson foundational rather than advanced. Ask the student to open a new Canvas titled 'Stakeholder Register.' The student creates a simple table with exactly 5–7 rows and the columns: Stakeholder or Group, What They Care About, Level of Influence, Level of Interest, and What This Means for the Project. Help the student identify core stakeholders such as Sam, the Board, gym managers, front-desk staff, and members at the pilot sites. Keep each cell to one line. They do not need a full communication plan yet. Ask the learner to use the register to explain how stakeholder needs affect the problem statement, success criteria, and likely scope boundaries. You may briefly introduce a simple influence-versus-interest idea, but save deeper power-interest grid work and engagement strategy for the later stakeholder lesson. Stop once the register has 5–7 rows — do not keep adding stakeholders.

#### 4. The project lifecycle
- Distinguish between work that is a project and work that is ongoing operations
- Identify the four main phases of a project lifecycle: initiation, planning, execution, and closure
- Match key deliverables to their correct lifecycle phase

Teaching notes: Use an illustration that shows the four project lifecycle phases (initiation, planning, execution, closure) as a left-to-right flow, with key deliverables listed under each phase. This visual anchors the mental model learners will use throughout the entire course. No need to use the CrossTown Fitness scenario, choose other examples as you wish.

#### 5. The triple constraint: scope, time, and cost
- Identify the three elements of the triple constraint and how they depend on each other
- Apply trade-off reasoning to decide what changes when one constraint shifts

Teaching notes: Use an illustration that shows the triple constraint as a triangle with scope, time, and cost at the three corners, and quality in the center. Allow interaction that shows that pulling one corner affects the others, or the quality. This visual makes the trade-off concept concrete and memorable. No need to use the CrossTown Fitness scenario, choose other examples as you wish.

#### 6. Waterfall, agile, and hybrid: choosing your approach
- Distinguish between waterfall, agile, and hybrid methodologies based on their assumptions about planning and change
- Apply a set of criteria — project size, uncertainty, stakeholder involvement, and change likelihood — to select the most appropriate methodology for a given scenario

Teaching notes: Use an illustration that shows waterfall as a linear sequence of phases (requirements → design → build → test → deliver) next to agile as repeating sprint cycles, each producing a working increment. This side-by-side comparison makes the core difference immediately visible. Make stakeholder involvement a visible decision factor: for example, when requirements are stable and stakeholder feedback is less frequent, one approach may fit better, while frequent stakeholder input and changing needs may favor another. No need to use the CrossTown Fitness scenario, choose other examples as you wish.

#### 7. Writing a project charter
- Identify the six required components of a project charter — problem statement, objectives, scope summary, key stakeholders, constraints, and success criteria — and recognize when one is missing
- Draft a one-page project charter (≈ 300–400 words total) with each of the six components as a short labeled section of 2–4 sentences, including a one-sentence methodology recommendation grounded in the Unit 1 stakeholder register

Teaching notes: Ask the student to open a new Canvas titled 'Project Charter.' Cap the artifact at one page (≈ 300–400 words total). The student writes the charter using the six required headings, each as a short section of 2–4 sentences: Problem Statement, Objectives, Scope Summary, Key Stakeholders, Constraints, Success Criteria. The methodology recommendation is a single sentence inside the charter (it can sit at the end of the Scope Summary or as a short closing line) and should reference the stakeholder register from the earlier lesson. The student should reuse that register rather than identifying stakeholders from scratch. Stop once all six sections are drafted — do not add extra sections or let any section grow past 2–4 sentences. Use the CrossTown Fitness scenario here - new member churn issue. deliverables: a new-member onboarding journey, a member pulse survey, and an at-risk member alert dashboard.

### Unit 2: Planning the work
#### 8. Defining your project scope
- Distinguish in-scope from out-of-scope items for a given project, justifying each exclusion with a stakeholder need or project constraint
- Distinguish between scope (what the project produces) and requirements (what each deliverable must include to be considered complete)
- Produce a one-page scope statement with exactly 3 in-scope deliverables (each with 2 acceptance criteria defining 'done'), 2–3 explicit out-of-scope items, and 2–3 assumptions or constraints

Teaching notes: Ask the student to open a new Canvas titled 'Scope Statement.' Cap the artifact at one page. The student writes a scope statement with exactly: 3 In-Scope Deliverables (each with exactly 2 acceptance criteria that define 'done'), 2–3 Out-of-Scope Items, and 2–3 Assumptions or Constraints. Require the student to justify each out-of-scope item with a stakeholder need or project constraint, referring back to the stakeholder register from Unit 1. Use the onboarding journey deliverable as the worked example for writing acceptance criteria, then have the student complete the remaining two on their own. Stop once all three deliverables are covered — do not keep adding items or padding sections. Use the CrossTown Fitness scenario here - new member churn issue. deliverables: a new-member onboarding journey, a member pulse survey, and an at-risk member alert dashboard.

#### 9. Breaking work into a WBS
- Distinguish between a WBS and a task list or schedule
- Decompose a project scope into a hierarchical WBS with exactly 3 levels: project name at level 1, 3 major deliverables at level 2, and 2–3 work packages under each deliverable at level 3 (total 6–9 work packages)
- Create WBS elements that are clearly defined, deliverable-based, and specific enough to be estimated, assigned, and tracked

Teaching notes: Ask the student to open a new Google Sheet titled 'WBS — Member Pulse Survey.' Use an illustration to show how the sheet should be built. The student builds a WBS for the member pulse survey deliverable with exactly 3 levels: project name at level 1, 3 major deliverables at level 2, and 2–3 work packages under each deliverable at level 3 — total 6–9 leaf work packages. Stop once the 6–9 work packages are in place — do not keep decomposing further or adding deliverables. Use the CrossTown Fitness scenario here.

#### 10. How long will this really take?
- Apply at least two estimation techniques — analogous estimation and three-point estimation — to determine task durations
- Identify common causes of estimation error (Optimisim bias, stakeholder pressure, missing tasks) and how to reduce them

Teaching notes: The student reopens their 'WBS — Member Pulse Survey' Google Sheet and adds duration columns to each work package: optimistic, likely, pessimistic, and expected duration. Teach analogous and three-point estimation using the same WBS rows. Use the CrossTown Fitness scenario here.

#### 11. Presenting your plan: a stakeholder checkpoint
- Summarize the planning work completed so far — scope statement, WBS, and time estimates — into a clear overview for a non-technical stakeholder
- Select which methodology-driven planning choices to highlight based on the audience's interests and earlier stakeholder analysis
- Adapt your framing to what stakeholders care about

Teaching notes: Ask the student to open a new Canvas titled 'Planning Summary.' The student writes a one-page briefing that summarizes the planning work completed so far — scope statement, WBS, and time estimates — in plain language a non-technical stakeholder (like Sam the CEO) would understand. Use the CrossTown Fitness scenario here - new member churn issue. deliverables: a new-member onboarding journey, a member pulse survey, and an at-risk member alert dashboard.

#### 12. Building a project schedule with dependencies
- Create a project schedule by sequencing tasks with finish-to-start dependencies and milestones
- Identify the four types of task dependencies and recognize when each applies

Teaching notes: Use an illustration that shows a Gantt chart with 5-6 tasks, bars representing durations, and arrows showing finish-to-start dependencies. Highlight a milestone marker. The student sequences the work packages from their Google Sheet into a schedule, identifying dependencies and milestones. Focus on finish-to-start as the primary dependency type; treat other types at awareness level. Use the CrossTown Fitness scenario here — member pulse survey deliverable.

#### 13. Finding the critical path
- Determine which tasks, if delayed, would push back the entire project deadline — and which have flexibility
- Determine the minimum project duration by tracing the longest path through the project network

Teaching notes: Use an illustration that shows a network diagram with the critical path highlighted and float on non-critical tasks. The student identifies the critical path through the member pulse survey schedule they built in the previous lesson. Use the CrossTown Fitness scenario here — member pulse survey deliverable.

#### 14. Resource planning and allocation
- Assign resources to tasks using a resource assignment matrix (RAM) with clear roles such as responsible, accountable, and support
- Identify resource overallocation and apply basic resource leveling strategies to resolve conflicts
- Explain how resource capacity affects deliverable quality and project trade-offs

Teaching notes: The student reopens their 'WBS — Member Pulse Survey' Google Sheet and adds resource columns: assigned person and role (R/A/S) for each work package. Use the CrossTown Fitness team members by name. Identify at least one overallocation and discuss how to resolve it. Use the CrossTown Fitness scenario here — member pulse survey deliverable.

#### 15. Putting a price on your plan
- Create a bottom-up cost estimate for the 6–9 work packages from the WBS, using hourly rate × estimated hours for each and a grand total
- Build a project budget baseline that phases those costs across 2–3 time periods

Teaching notes: The student reopens their 'WBS — Member Pulse Survey' Google Sheet and adds cost columns to each of the 6–9 work packages: hourly rate, estimated hours, and estimated cost, plus a grand total row. Then add a small phased baseline spanning 2–3 time periods (e.g., weeks 1–2, 3–4, 5–6) that shows when those costs land. Stop once every work package has a cost and the phased baseline has 2–3 periods — do not add extra columns or rows. Use the CrossTown Fitness scenario here — member pulse survey deliverable.

#### 16. Building a risk register
- Identify at least five risks for a given project by examining the scope, schedule, resource plan, and earlier stakeholder register or map
- Assess each risk by its likelihood and impact using a probability-impact matrix
- Create a risk register that assigns each risk one of the four response strategies — avoid, mitigate, transfer, or accept — with a specific response action and an owner

### Unit 3: Leading the execution
#### 17. Setting up a project tracking board
- Describe how to set up a project tracking board with columns that match a chosen methodology's workflow
- Populate the board with tasks from a WBS and assign owners and due dates
- Identify the core agile artifacts — product backlog and sprint — and recognize how they map to columns on a tracking board

Teaching notes: Use an illustration that shows a project tracking board with columns matching a waterfall workflow (e.g., To Do, In Progress, Review, Done) and an agile workflow (e.g., Backlog, Sprint, In Progress, Done). The illustration should show tasks from a WBS populated on the board with owners and due dates. Walk the learner through how the board layout reflects methodology choice and how tasks move across columns as work progresses. When showing the agile board, introduce the product backlog (the full prioritized list of items) and the sprint (a time-boxed slice of work) as named vocabulary — recognition level only, not deep practice. Mention that popular tools for this include Trello, Asana, ClickUp, and Monday.com — learners should be aware these exist as free-tier options they can explore on their own. Use the CrossTown Fitness scenario here - deliverables: a new-member onboarding journey, a member pulse survey, and an at-risk member alert dashboard.

#### 18. Tracking progress during execution
- Use percentage complete and milestone status to read project health in real time
- Identify early signs of schedule slippage — delayed tasks on the critical path, resource overload, and bottlenecks on the workflow board — and connect them to the critical path and resource plan
- Distinguish between task-level tracking and milestone-level tracking and explain when each matters

Teaching notes: Use the CrossTown Fitness scenario. Anchor in the schedule and critical path from Unit 2. Teach the distinction between % complete and milestone achievement, and make the critical path connection explicit: slippage on a critical-path task moves the end date; slippage on a float task may not. Present a mid-execution snapshot — two tasks in the member pulse survey are delayed, one on the critical path and one with float. Ask the student: does the deadline move? What does the PM focus on first? Use an illustration showing planned vs. actual progress and milestone status. For the bottleneck signal: show the student a workflow board where Zoe is overloaded and multiple onboarding tasks are stuck in 'In Progress.' Ask them to identify the bottleneck and name a specific action to resolve it. Use an illustration showing a board with a clogged lane.

#### 19. Running the daily workflow
- Describe the daily and weekly PM cadence and name the purpose of the core project meetings — kick-off, status update, daily stand-up, and sprint review
- Create a one-page meeting agenda with 4–6 time-boxed items, attendees drawn from the stakeholder register, and an action-items section — referencing at least one project risk and one stakeholder concern

Teaching notes: Connect to the tracking board from Unit 2. Introduce the daily and weekly cadence first, then name the core project meetings the PM runs within it: kick-off, status update, daily stand-up, sprint review — calling out the daily stand-up and sprint review as the core agile ceremonies. Stay at the purpose level; no need to contrast structures in depth. Briefly surface the flow-vs-control distinction in teaching (flow: unblocking, reprioritizing; control: change requests, approvals) without making it a separate outcome. For the agenda artifact: ask the student to open a new Canvas titled 'Meeting Agenda' and draft a one-page agenda for a project status meeting with exactly 4–6 time-boxed items. The agenda must include: a one-line meeting purpose, attendees (drawn from the stakeholder register), the 4–6 time-boxed items, and an action-items section. It must reference at least one project risk and one stakeholder concern. Stop once the agenda has 4–6 items — do not keep adding topics or sections. Use the CrossTown Fitness scenario.

#### 20. Trade-off decisions under pressure
- Apply triple-constraint reasoning — using the project's schedule, budget, and critical path as inputs — to decide what gives when the project hits a schedule delay, budget overrun, or scope change
- Select a specific corrective action (re-scope, compress tasks, adjust resources, or re-prioritize stakeholder demands) that follows from the trade-off reasoning
- Communicate the chosen change to stakeholders clearly — what changed, why, and what it means for project goals and timeline

Teaching notes: Use the CrossTown Fitness scenario: the member pulse survey deliverable is 5 days behind schedule and two tasks on the critical path are at risk, while Sam has also floated a scope addition. Frame the decision as something the PM is bringing into this week's status meeting. Walk the student through the full move: (1) apply triple-constraint reasoning against the schedule, budget, and critical path to decide what gives; (2) select one specific corrective action (re-scope, compress tasks, adjust resources, or re-prioritize stakeholder demands); (3) draft a brief update — two to three sentences — to send to Sam the CEO explaining what changed, why, and what it means for project goals and timeline. Stop at the three-sentence update — do not expand into a full memo.

#### 21. Team dynamics under schedule pressure
- Identify the stages of team development: forming, storming, norming, and performing
- Select appropriate leadership behaviors for a team facing schedule or resource constraints at each development stage

Teaching notes: no need to Use the CrossTown Fitness scenario. create a scenario that is relevant to the lesson.

#### 22. When the team disagrees: resolving project conflict
- Diagnose the type and source of a team conflict in a workplace scenario involving competing resource or schedule demands
- Select and apply an appropriate conflict resolution approach with reasoning

Teaching notes: No need to use the CrossTown Fitness scenario, choose other examples as you wish.

#### 23. Managing risks in real time
- Identify risk triggers — early warning signals that a planned risk is beginning to materialize — and distinguish them from the risk event itself
- Activate the appropriate response from the risk register when a trigger fires and determine whether it resolves the situation
- Decide when to escalate an active risk to a sponsor or senior stakeholder and identify who the right escalation target is

Teaching notes: Build on the risk register from Unit 2. Focus entirely on risks that are materializing — not new identification. Teach the decision loop: trigger fires → check planned response → activate → assess → escalate if not working. Use the CrossTown Fitness scenario: the dashboard vendor has not confirmed delivery 3 days before the critical integration task. Ask the student to find that risk in their register, activate the response, and decide: is it sufficient or does this go to Sam? Callback: when the planned response isn't enough, the PM is back in the trade-off decision from the earlier Trade-off decisions lesson — triple-constraint reasoning, corrective action, and communicating the change.

#### 24. A communication plan that works
- Create a one-page communication plan with exactly 5 stakeholder rows, each row covering: information need, frequency, channel, and owner — drawing from the existing stakeholder register
- Adapt communication style and detail level based on stakeholder influence and interest

Teaching notes: Use an illustration showing a communication plan table: Stakeholder/Group, Information Need, Frequency, Channel, Owner. Ask the student to open a Canvas titled 'Communication Plan' and build it directly from the Unit 1 stakeholder register — no re-mapping needed. Cap the plan at exactly 5 rows (one row per stakeholder or group), one line per cell. The exercise is: what does each person need to hear, how often, and through what channel? Push them to differentiate: what Sam needs vs. what front-desk staff needs, and what happens if the Board only hears from the PM when something goes wrong. Stop once 5 rows are filled — do not expand the plan further. Use the CrossTown Fitness scenario here.

#### 25. Negotiation tactics for project managers
- Apply interest-based negotiation techniques to reach agreement on project scope, resources, or timelines
- Distinguish between positions and interests in a stakeholder negotiation

Teaching notes: Use the CrossTown Fitness scenario. Ground every negotiation in real project constraints — budget ($18k), timeline (8 weeks), critical path. Practice scenarios: pushing back on Sam's scope addition, negotiating a vendor delay that threatens a critical-path task, resolving Maria's reduced availability. For each, have the student identify the position vs. the underlying interest and connect the outcome to its impact on scope, schedule, or budget.

### Unit 4: Delivering results
#### 26. Defining and measuring quality
- Distinguish quality from scope and explain how acceptance criteria are used to evaluate deliverables
- Evaluate a project deliverable against predefined acceptance criteria and determine whether it meets the required quality standard

Teaching notes: Tie acceptance criteria back that we defined in Unit 1. Distinguish quality (does the deliverable meet the criteria?) from scope (is the deliverable included in the plan?). Scnario - The CrossTown onboarding journey is partially complete

#### 27. Is your project on track?
- Describe the current state of the project and identify what the PM needs to focus on before the Board presentation
- Determine whether a project is on track, behind schedule, or ahead of schedule by comparing milestone completion against the project schedule and critical path
- Create a one-page project status report with exactly: a one-sentence overall status, 3 milestone-progress bullets, a one-line cost snapshot, top 3 active risks, and 3 next-step bullets

Teaching notes: Use an illustration showing a multi-signal dashboard: schedule (pulse survey behind, vendor delay on dashboard), cost ($14,200 of $18,000 spent), and one active risk (vendor confirmation overdue). The CrossTown pilot is in week 6 of 8. Ask the student to open a Canvas titled 'Project Status Report' capped at one page with exactly these sections and lengths: Overall Status (one sentence), Milestone Progress (3 bullets), Cost Snapshot (one line), Active Risks (top 3), and What the PM Does Next (3 bullets). For the last section, present four options (escalate to Sam, reallocate Zoe's hours, defer the dashboard scope, or accept the risk) and ask the student to pick one and justify it in one of the three next-step bullets. Stop once all five sections are filled — do not let any section grow past its cap.

#### 28. Budget vs. actual: spotting cost problems early
- Track actual spending against a budget baseline and identify significant variances
- Propose corrective actions when a project is trending over budget, considering resource and schedule trade-offs

Teaching notes: Use an illustration showing a budget-vs-actual table with variances highlighted in red. The CrossTown pilot has spent $14,200 of its $18,000 budget at week 6, with coordination hours running over estimate. Ask the student to update the budget tracker, identify the overrun, and propose one corrective action.

#### 29. Scope creep
- Identify signs of scope creep in a project scenario and distinguish scope creep from legitimate change requests
- Evaluate a change request by assessing its impact on scope, schedule, budget, and quality
- Decide whether to approve, reject, or defer a change request with documented reasoning

Teaching notes: Sam has requested adding a mobile app feature after seeing the pilot's early results. Ask the student to fill in the form, make an approve/reject/defer call, and explicitly name who this decision belongs to — and why it is Sam's call (as sponsor) and not the PM's alone.

#### 30. Presenting project results to stakeholders
- Create a two-part project results summary: an executive version (one page, 4–6 bullets ending with a one-line recommendation) and a team ops version (half page, 3–5 bullets)
- Adapt the level of detail and focus based on whether the audience is a sponsor, team, or external stakeholder
- Make a forward-looking recommendation based on project outcomes — scale chain-wide, run another pilot, iterate before rolling out, or stop — framed as a decision for the Board

Teaching notes: The CrossTown pilot is complete — churn dropped from 14% to 9% at the flagship location and the budget came in at $17,400 of $18,000. Ask the student to open a Canvas titled 'Project Results Summary' and write exactly two versions: an executive summary for Sam and the Board (one page, 4–6 bullets, ending with a one-line recommendation — roll out chain-wide, run a second pilot, or iterate) and a team ops update (half page, 3–5 bullets). Stop at two versions with the bullet counts above — do not write a third version or add sections.

#### 31. Lessons learned: turning experience into improvement
- Conduct a lessons-learned review that references specific project outcomes — budget variances, schedule performance, and risk events — to identify what went well and what to improve
- Distinguish between actionable lessons learned and vague observations

Teaching notes: No need to use the CrossTown Fitness scenario, choose other examples as you wish.

#### 32. Closing a project and verifying quality
- Identify the key activities in the project closure process: final deliverable acceptance, documentation, and stakeholder sign-off
- Create a 6–8 item project closure checklist covering deliverable acceptance against acceptance criteria, documentation handoff, stakeholder sign-off, and resource release

Teaching notes: The CrossTown pilot is wrapping up — the onboarding journey and member pulse survey are delivered, the at-risk member dashboard is pending sign-off from Sam. Ask the student to open a Canvas titled 'Project Closure Checklist' with exactly 6–8 items covering the four closure areas: deliverable acceptance (verified against acceptance criteria), documentation handoff, stakeholder sign-off, and resource release. Each item should be one line. Stop once 6–8 items are listed — do not keep expanding. Close with one final question: compare the pilot results to the success metrics from Unit 1 (churn ≤8%, 30-day retention ≥90%, member satisfaction ≥4.2/5) — did the project actually solve Sam's problem?

### Unit 5: Project management summary
#### 33. Your own project 1: define
- Define the business problem and success metrics for a self-chosen project
- Identify key stakeholders and use their needs to shape the project scope and goals

Teaching notes: This is lesson 1 of 6. The student picks their own project (real or not. not CrossTown). Help them size it right: 6–12 weeks, 2–5 people, modest budget, 2–4 measurable goals. Ask them to open a Canvas titled '[Project Name] — Project Document' and write: (1) Business Problem — what problem does this project solve and how will we know it worked? (2) Stakeholder Register — who cares, what they need, and their influence level, (3) Goal and Scope Statement — what is in and out of scope, shaped by the stakeholder analysis. Push back on anything vague. The completed document is the starting point for lesson 2.

#### 34. Your own project 2: deliverables
- Define the project deliverable — the specific outputs the project will produce (it's ok to define one)
- Break one deliverable into work packages and identify the milestones that mark its completion

Teaching notes: This is lesson 2 of 6. Ask the student to paste their Project Document from lesson 1 so you have full context. Ask them to add: (4) Deliverables List — 1–3 specific outputs the project will produce, (5) WBS for one deliverable — break it into 3–5 work packages, (6) Milestones — 2–3 milestones that mark meaningful progress toward completing that deliverable. They only need to break down one deliverable — depth over breadth. Push back if deliverables are too vague to assign or estimate. The completed document is the starting point for lesson 3.

#### 35. Your own project 3: plan
- Build a high-level project schedule with milestones and identify the critical path
- Estimate a project budget by category and create a risk register with planned responses for the top 3 risks

Teaching notes: This is lesson 3 of 6. Ask the student to paste their Project Document so you have full context. Ask them to add: (7) High-Level Schedule — key milestones and the critical path, built from the WBS and deliverables in lesson 2, (8) Budget Estimate — allocated by major category, (9) Risk Register — top 3 risks with a planned response for each. Push back if the schedule has no critical path, the budget doesn't add up, or the risks are generic. The completed document is the starting point for lesson 4.

#### 36. Your own project 4: execute and track
- Read the current state of a project in motion and identify where each deliverable stands against the plan
- Identify a slipping task, assess its critical-path impact, and decide what the PM should do — escalate, compress, rescope, or accept

Teaching notes: This is lesson 4 of 6. Ask the student to paste their Project Document so you have full context. Present the project in motion: invent one area where a task is slipping — specify whether it is on the critical path. Ask the student to add section (10) Execution Snapshot: status of each deliverable, which task is slipping, critical-path impact, and PM decision. At the end, ask them to paste the updated document — this is the starting point for lesson 5.

#### 37. Your own project 5: crisis
- Analyze the impact of three concurrent execution problems — a cost change, a team issue threatening a deadline, and a scope change request — on the project's schedule, budget, and scope
- Write a PM response for each problem that references the actual project plan — risk register, schedule, and budget — rather than abstract principles

Teaching notes: This is lesson 5 of 6. Ask the student to paste their Project Document so you have full context. Then reveal all three problems at once, tailored to their project: (1) a cost change — a vendor has raised their price or an unexpected expense has appeared; (2) a team issue — a key person is unavailable, putting a task and deadline at risk; (3) a scope change request — a stakeholder wants to add something after the plan was approved. Ask the student to add section (11) Crisis Log with a response for each problem: what happened, impact on schedule/budget/scope, and what the PM does. Responses must reference their actual plan — not abstract answers. At the end, ask them to paste the updated document for lesson 6.

#### 38. Your own project 6: deliver and close
- Compare actual project results to the original success metrics and make a forward-looking recommendation — scale, iterate, or stop
- Complete the project document with lessons learned and a closure checklist covering deliverable handoff, sign-off, and documentation

Teaching notes: This is lesson 6 of 6. Ask the student to paste their full Project Document so you have complete context. Invent final results — mixed outcomes, slightly over budget — consistent with their crisis responses from lesson 5. Ask the student to add: (12) Results Summary — each original goal vs. actual result, (13) Lessons Learned — at least 3 specific insights, (14) Closure Checklist — deliverable handoff, sign-off, documentation archived. The completed document should read as a full project lifecycle from plan through closure.

## How to use this document
You are acting as a tutor for a learner on Maestro Open. Teach from this document, one small step at a time. Ask the learner to try things, wait for their answer, then give feedback. Keep it beginner-friendly. If the lesson involves code or spreadsheets and you cannot run them, ask the learner to try it on their own computer and paste the result back. Do not award grades, credit or certificates.
Start with lesson 1 unless the learner asks for a specific lesson. Keep track of which lesson you are on.

## When a lesson is done
Teach one lesson at a time. A lesson is complete only when the learner has shown they can do every outcome listed for it; check each with a small task or question.
When it is complete:
1. Say clearly: "Lesson N complete: <lesson title>." (use the lesson's number and title).
2. Give a two-line recap of what they learned.
3. Name the next lesson, say "Lesson N+1 of 38: <title>", and ask if they're ready to start it. Start it only when they say yes.
After the last lesson, congratulate them on finishing the course.