Execution 1 - Tracking, Status Reports and Change
Google Project Management Certificate · Course 4: Project Execution - Running the Project
Three courses of preparation are now behind us. The goal is set, the scope agreed, the stakeholders mapped, the charter signed, and the plan broken down into milestones, tasks, a schedule and a budget. Execution is where all of that stops being a document and becomes work people are actually doing.
The job changes shape here. In initiation and planning the project manager was mostly deciding things; in execution the project manager is mostly watching, reporting and unblocking. The question is no longer what should we do, but rather: where is this project right now compared with where the plan said it would be, and what do I do about the gap?
That question is the spine of the module. It runs from tracking progress, to reporting it honestly, to handling the risks that have stopped being hypothetical and the changes that follow. The two practical activities are writing a project status report and running a ROAM analysis on live risks.
What the execution phase involves
Section titled “What the execution phase involves”Execution is where planning pays off, but it is not passive. The instructor frames the phase around a set of running responsibilities: track and measure progress, manage quality and continuous improvement, handle risks that actually materialise, absorb changes and scope creep, use data to make and explain decisions, lead and influence the team, communicate and run meetings, and finally close the project properly. Planning covered risk mitigation in the hypothetical; execution asks what to do when a risk stops being hypothetical and becomes today’s problem.
Tracking, and why it matters
Section titled “Tracking, and why it matters”A deviation is anything that alters the original course of action, and it cuts both ways: finishing early because a technical problem turned out simpler than estimated is a deviation, and so is a natural disaster shutting down the testing team. Either way the project manager needs the real state of things, not the planned one.
| Tracking gives you | Why that matters |
|---|---|
| Transparency | Information is centralised so everyone sees the status of each part. Even strong project managers decide badly without context |
| Nothing forgotten | Projects carry an enormous number of small details, and tracking stops them slipping |
| Shared deadlines and goals | Team and stakeholders stay in touch with what is due when, from one plan that works for you and for them |
| Early risk detection | Issues surface in time for corrective action, and attention points at the areas genuinely at risk |
| Confidence | A current picture that the project will land on time, in scope and on budget keeps the team motivated |
What to track
Section titled “What to track”New tasks appear constantly once a project is underway, which is why tasks must be tracked as they progress rather than reviewed at the milestone. And even when you do not own the whole budget, you almost certainly own tasks and resources with budget implications, so costs stay on the list.
Choosing a tracking method
Section titled “Choosing a tracking method”Every project plan carries at least one tracking method, often more than one. The test is practical: choose something the whole team can understand, reference and keep up to date.
Gantt chart
Section titled “Gantt chart”The most common method of all. It measures tasks against time and also carries who owns each task and what order the tasks come in. Each task is a horizontal bar whose length reflects the time allotted; bars stack so the one above must finish before the one below can. Tracked sequentially the shape falls away like a waterfall, which is why Gantt charts belong to Waterfall project management. They live in the project plan and are updated as work progresses. Best for projects with many dependencies, tasks and milestones, for staying on schedule, and for large teams, because ownership is laid out visually.
Roadmap
Section titled “Roadmap”A roadmap tracks big milestones and shows a team or key stakeholders how the project should evolve over time.
A quarter is a three-month period on the company’s financial calendar. Most tasks map to a milestone due in the same quarter, but not all: some must finish early to unblock another team or a later milestone. In the worked example, product and engineering work through Q1 and Q2 so the refreshed online store can launch in Q3, while marketing and sales handle product testing and offering suggestions against the Q1 milestone of finalising holiday inventory. So the roadmap tracks both individual and project progress toward milestones.
Burndown chart
Section titled “Burndown chart”The most granular of the three, measuring time against work done and work remaining. The vertical axis is the number of tasks left, the horizontal axis is time, a dotted line shows expected progress based on the rate the team should close tasks, and a solid line shows actual progress. Tracking starts in the upper left and works down toward zero tasks and right toward the end date.
Its two jobs are keeping the team on top of targeted completion dates and making scope creep visible as it happens. Typically used by Agile Scrum teams, it must be displayed where everyone can see it and updated regularly. Beyond the current project it reveals how the team really works and what affects its ability to finish on time, which makes the next project easier to plan.
| If you need to… | Use |
|---|---|
| Communicate milestones to a large team, or show stakeholders how the project evolves | Roadmap |
| Run a project with multiple dependencies and many owners | Gantt chart |
| Track tasks tightly against a deadline, or catch scope creep | Burndown chart |
The project status report
Section titled “The project status report”What goes in one
Section titled “What goes in one”| Component | What it does |
|---|---|
| Project name | Specific enough that the goal is understood at a glance |
| Date | Reports go out weekly or monthly depending on stakeholder needs and project pace; the date is a reference point and builds a history log |
| Summary | Goals, schedule, highlights and lowlights in one place, usually grouped with the timeline summary and overall status |
| Status | Actual progress versus planned progress, commonly shown as RAG |
| Milestones and tasks | Condensed into key accomplishments (what has happened) and upcoming (the next big milestones), rather than the item-by-item not started / in progress / completed of the project plan |
| Issues | Current roadblocks and potential risks |
The issues section is where expectations get set. If the status is red or amber, say what is stopping you being where you planned to be, state the plan to get back to green, and ask for the resources or help you need to do it.
RAG status
Section titled “RAG status”| Status | Meaning |
|---|---|
| Red | Issues need resolution; the project may be delayed or go significantly over budget |
| Amber / Yellow | Potential schedule or budget issues, but likely resolvable with corrective action |
| Green | Schedule and budget are fine, the project is on track |
RAG can label the overall project status as well as individual milestone status.
Format follows audience. A complex project with many moving parts, reported to the team, is best as a spreadsheet; updates aimed at senior stakeholders are best as a slideshow carrying only the key points. Either way, status reports earn their place because they simplify communication across the team, keep stakeholders informed, give you a natural moment to request more resources or support, and record the status centrally.
Drafting an update with a gen-AI tool
Section titled “Drafting an update with a gen-AI tool”A gen-AI assistant can speed up routine reporting, such as a status update for a company newsletter on a packaging machine still in testing. The framework is TCREI - Thoughtfully Create Really Excellent Inputs:
| Step | What you add |
|---|---|
| Task | What you want, with a persona and a format preference. Starting deliberately thin shows you what is missing |
| Context | Target audience (technical or non-technical), level of detail, and tone (informative, cautionary, empowering) |
| References | An example, such as a previous status update that landed well, to steer the output |
| Evaluate | Is it accurate and unbiased? The right length? The right tone? Any jargon outsiders would trip over? |
| Iterate | Set a word limit, ask for bullets, require keywords, request placeholders for images, then repeat |
Risks becoming changes
Section titled “Risks becoming changes”A risk is a potential event that might occur and could affect the project - hypothetical by definition, which is why planning identifies and prepares for it. When a risk actually occurs, the consequence is a change.
A change is any variance from the plan against the triple constraint: priorities and scope, budget and resources, or the timeline. Measure it against the baseline estimates set from the original requirements, and expect knock-on effects when you move any one of them.
Types of change
Section titled “Types of change”Using the running bathroom remodel example:
| Type of change | Example |
|---|---|
| New or changing dependencies | The new sink cannot go in until the vanity and plumbing are in place |
| Changing priorities | The client’s in-laws move in, so the spare bedroom jumps ahead of the bathroom |
| Capacity and people available | The plumber has to be replaced after problems on site |
| New budget or resource limits | Electrical quotes come in high, so design costs must drop by 10 percent |
| Scope creep | The clients love the new tile and now want every bathroom retiled |
| Force majeure | An unforeseen crisis stops someone fulfilling a contract, such as a union strike or a pandemic halting production. Uncommon, but real |
The cautionary example is worth keeping: you budget to lift the carpet and refinish the hardwood beneath, then find the floors rotting. They need replacing, and both timeline and budget take the hit.
The change request process
Section titled “The change request process”Managing changing scope is the project manager’s responsibility, though rarely alone. Start from the Statement of Work and the RACI chart, then use whatever change request process the team or organisation has, creating one if it does not exist. Because people in many roles fill these forms in, a change request form must be self-explanatory and thorough. The template used here is a two-column, ten-row table covering:
| Block | Fields |
|---|---|
| Header | Project name; discussion owner, the person leading it from the team; discussion type, so the audience knows whether this is a risk, an opportunity or something else; teams involved |
| Timing and stakes | Target date for the discussion; which milestones or goals are impacted |
| Expected outcome | A change in priorities, a schedule change, or an official call on how to proceed |
| Description | The current situation, the change, and the difference from the plan of record - a before and after snapshot |
| Proposal | The in-depth proposal for the necessary changes, addressing trade-offs |
| Background | Shared context so everyone starts from the same understanding |
Dependencies
Section titled “Dependencies”Think of a line of dominoes: knock one over and it takes the next with it. A construction firm must name a foreman and a project manager before requirements, timeline and budget are signed off and the crew is picked - you would never put a crew to work before the job is scoped and the contracts signed.
| Type | What it means | Example |
|---|---|---|
| Internal | A relationship between two tasks in the same project | Foreman and PM chosen, then requirements signed off, then crew selected |
| External | Tasks reliant on outside factors such as regulators or other projects | Demolition waits on city approval. Often outside your control, but must stay visible |
| Mandatory | Legally or contractually required | Pour the foundation, then have the city inspect it before building continues |
| Discretionary | Defined by the team - things that could happen independently but were deliberately linked | Pour a test portion using a new supplier’s concrete to estimate the total needed |
-
Proper identification. Brainstorm every possible dependency with the team and categorise them.
-
Recording. Build a risk register, a table or chart listing risks and dependencies. For each dependency record a description, the date, and every activity or task it could affect.
-
Continuous monitoring and control. Schedule regular check-ins on the interrelated tasks, stay current on progress, and watch for changes that will hit other tasks.
-
Efficient communication. Keep the team and stakeholders updated, since that is what actually resolves dependencies and keeps momentum.
Defining dependencies clearly at the project outset, as in the foundation example, is what makes this manageable later.
Managing risks that have gone live
Section titled “Managing risks that have gone live”The highest-leverage move is indirect: manage changes and dependencies and manage scope creep, and most other risks become easier. Dependencies met on time keep the team on schedule; a tightly managed scope keeps the budget intact and the timeline from stretching.
Risk register and risk exposure
Section titled “Risk register and risk exposure”Brainstorming with the team is the most effective way to find risks, because teammates bring experience from earlier projects and spot repeats of old problems. Ask what could improve the outcome and what could hurt or hinder it, then record each one in the risk register as an if / then statement: if this event happens, then this is the impact.
To prioritise, calculate risk exposure - a way to measure the potential future loss from a specific activity or event. Build a matrix on two variables: risk impact across the top horizontal axis and probability down the side vertical axis, each marked high, medium and low. Plot every risk at the intersection of the two, and the ones needing immediate attention become obvious.
ROAM analysis
Section titled “ROAM analysis”No register catches everything, so unforeseen risks always arrive. ROAM is the technique for deciding what to do with a risk after it has materialised - it manages actions, not predictions.
- The risk has been eliminated and will not be a problem
- A team member is given ownership, entrusted to handle it, and monitored through to completion
- It has been agreed that nothing will be done about it
- Action has been taken that lowers either the likelihood or the impact
Case study: the missing cookie cutters
Section titled “Case study: the missing cookie cutters”The Paw Snacks puppy treat launch shows the chain working. Six weeks before launch the bakery tells the project manager, Naja, that the bone-shaped cookie cutters have not arrived, and baking must start the next day. Her teammate Abe finds the order delayed by a product shortage and now landing two days late. The launch cannot move, because marketing has already bought non-refundable advertising for launch day.
The save came from work done months earlier: the team had brainstormed risks, built a risk register with a probability and impact matrix, rated a cookie cutter delay as medium probability and high impact, and had Abe write a mitigation plan approved by the sponsor and stakeholders. It offered two options - raise the bakery’s daily output to recover the lost days, or bring in a second bakery - and they chose the first to avoid onboarding another supplier. Then came the step that is easy to skip: they brainstormed the risks of the new plan, judged that a slightly smaller order would only dent projected growth, decided to accept that risk rather than delay further, and took it to the sponsor for approval before acting.
| Term | Meaning |
|---|---|
| Mitigation plan | A planned risk response strategy, written early for known risks that threaten schedule, cost or scope |
| Contingency plan | Mostly funds held outside the planned budget, to support a risk response that runs over or to cover unforeseen risks during execution |
Escalation
Section titled “Escalation”Escalation sounds negative, but in project management it should be encouraged, used often and even celebrated. It is a checks and balances mechanism, it produces fast decisions, and an objective third party can settle what two teammates cannot. It also encourages participation, since inviting others to solve or own a problem builds trust and shared responsibility.
Set escalation standards before work begins, agreed between the project manager, the team and the sponsor: who issues are raised to, how they are raised, and the forum for the discussion. Then escalate at the first sign of a critical problem - anything hitting the triple constraint of time, budget and scope.
Escalation exists to head off two specific failures:
| Problem | What it looks like |
|---|---|
| Trench wars | Two peers or groups cannot agree and neither will give ground, so the project stalls and progress slips |
| Bad compromises | Both sides settle on a so-called solution but the end product still suffers. Compromise while keeping the larger project goals in view, and be ready to help people make a hard choice for the greater good |
Writing an escalation email
Section titled “Writing an escalation email”| Practice | How it reads |
|---|---|
| Keep a friendly tone | The instinct under pressure is to get straight to the point, but you are asking for help. Open with goodwill, describe the issue without blame, close by thanking them |
| State your connection to the project | One sentence with your name, role and relationship to the project, so the reader knows why you are writing |
| Explain the problem | State clearly what needs solving, with enough context and no more. Dense paragraphs invite skimming |
| Explain the consequences | Be specific about how it is hurting the project now, or will hurt it later in the timeline |
| Propose a course of action and make a request | The central piece: offer a solution and say exactly what you need from the recipient |
In the worked example, a project manager whose supplier delivered 3,000 of 5,000 candles, many damaged, names the risk to customer satisfaction, quantifies the consequence as a three-week launch delay plus 20,000 dollars of extra cost, then proposes two vetted backup suppliers and asks for a meeting the next day. Brief, blameless, impossible to misread.
Communicating change to the team
Section titled “Communicating change to the team”Even small changes matter to someone, and all of them should be communicated. Tailor the channel to the subject and the recipient.
| Situation | Channel |
|---|---|
| A small change affecting one person | Email. Give a heads up and set a meeting time; avoid emotional topics or anything needing depth |
| A big change affecting more than one person, likely to move budget, deadline or scope | A team meeting |
| Something needing quick agreement, or slightly sensitive | The instructor’s own habit: a quick coffee or hallway chat, then an email recording what was agreed |
Weekly meetings are not compulsory. If the agenda is thin, cancel and pivot to email, or move the topic to another forum.
Revision summary
Section titled “Revision summary”Next: Quality Management → - making sure what ships is actually right.