Project monitoring: indicators, tracking table and rituals

Project monitoring means comparing, at a fixed cadence, what has actually been done with what was planned — dates, effort, budget, quality — and then deciding what changes. It is not paperwork imposed on the team: it is the mechanism that lets you see a drift while correcting it is still cheap. This guide covers the indicators to track, a sample weekly tracking table, the rituals, a status report template, and the point where a spreadsheet stops being enough.

Project monitoring and control: a definition

Three notions are constantly confused. Monitoring measures: it collects progress, time spent, expenses and risks. Control compares those measurements with the approved baseline and triggers corrective action. Reporting describes the situation to someone else — the sponsor, the steering committee, the client. An indicator that has never caused a re-sequencing, a reallocation or a scope decision is a reporting indicator: it belongs in the monthly pack, not in the weekly review. Monitoring is only worth what the decisions it produces are worth.

Monitoring assumes a baseline: the schedule, effort and budget approved at launch. Without a baseline there is no variance, only a plan that quietly rewrites itself to match reality — which is how a project arrives six weeks late having always been “on track”.

Project monitoring indicators

Six families of indicators cover the essentials. Each needs a clear formula or source, a threshold that triggers an action, and a reading frequency. An indicator without a threshold is just a number.

Earned value fits in one sentence: an SPI of 0.8 means the project has produced 80% of what it should have produced by now; a CPI of 0.8 means every euro spent has produced only 80 cents of value.

Remaining effort or percent complete?

Progress measured as “percentage of time elapsed” tells you nothing — it advances on its own whether or not anyone works. A percentage declared by the contributor is hardly better: tasks sit at 80% for weeks because nobody knows what the last 20% is worth.

The remaining-effort method turns the question around. Instead of asking “how far along are you?”, you ask “how many days are left?”. A contributor who has spent 12 days and still sees 10 has just told you the estimate was 22, not 15. Progress is then computed as spent / (spent + remaining) — 55% in this example, against 80% if you divided spent by the original estimate. Collected task by task at every weekly review, that single figure is the earliest and most reliable warning a project produces.

Example of a weekly project tracking table

The tracking table is the tool of the weekly review. It fits on one page, one row per task in progress or due within two weeks, and takes ten minutes to read. Example for a time-tracking tool migration project:

Three columns set this apart from a plain schedule: remaining effort (a number, not a deduction), a four-value status (done, in progress, at risk, late) and a “decision / action” column added as meeting notes. The data migration is late: 9 days of work remain for a due date 7 working days away. That row, and that row alone, calls for a decision in the meeting.

Monitoring rituals: weekly review and steering committee

Monitoring relies on meetings at a fixed cadence, each with defined participants and a defined output. Mixing the operational level with the decision level produces a meeting that is too long for the team and too detailed for the sponsor.

Setting up project monitoring in 6 steps

1. Freeze the baseline: schedule, effort per task, budget and milestones approved at launch, dated and unchangeable without a decision.
2. Choose 5 to 8 indicators, each with a source, a threshold and an owner. Anything more is reporting.
3. Organise collection: time logged every week, remaining effort re-estimated at the weekly review, expenses recorded as committed from the order date.
4. Hold the rituals at a fixed cadence, even when everything is fine — it is precisely when they are skipped that drift sets in.
5. Close the loop with corrective action: every variance beyond its threshold gets a dated decision (re-sequence, reallocate, cut scope, revise the estimate), an owner and a verification date.
6. Check the effect at the next ritual and close the action, or escalate it to the steering committee if the variance persists.

Four small corrections spread over a quarter cost far less than one replanning exercise at the end. The projects that fail are rarely the ones that drifted; they are the ones where the drift was visible and nothing followed.

Project status report template

The status report (also called a flash report or progress report) is the one-page document produced for the project committee and the steering committee. It takes thirty minutes to fill in from the tracking table and keeps the same structure from one month to the next, so readers can compare at a glance. Typical content:

• Header: project name, project manager, sponsor, report date, period covered.
• Project status: one overall green, amber or red indicator, plus one per dimension (schedule, effort, budget, risks, quality), with the trend since the previous report.
• Highlights of the period: three to five lines — deliverables accepted, milestones reached or slipped.
• Indicators: progress, milestone variance, spent and remaining effort, committed budget and estimate at completion, each with its value, threshold and colour.
• Risks and points of attention: the three main risks with their response plan, new alerts.
• Decisions requested from the committee: phrased as closed questions, with the recommended option and its cost.
• Next steps: milestones and deliverables for the next four weeks.

A status report without a “decisions requested” section is a newsletter. It steers nothing.

Excel tracking table or project monitoring software?

An Excel tracking table is the right tool to start with: one project, a team of fewer than ten people, a weekly read. Its strength is freedom; its limits show quickly.

• Multiple projects: the same contributor is scheduled in three files that do not talk to each other, and nobody sees that they are at 140% workload next month.
• Shared resources: real capacity (part-time staff, leave, recurring support) is neither known nor consolidated.
• Time spent: hours are logged in one tool, tracking is done in another, and remaining effort is retyped by hand — so it is rarely up to date.
• Budget: committed and actual figures come from accounting a month late; the estimate at completion is recalculated manually.
• History: without a stored baseline, variances are invisible; without traceability, each version of the file overwrites the previous one.
• Reporting: the portfolio dashboard is rebuilt every month by copy and paste.

Project monitoring software solves these points by holding schedule, time, workload and budget in one repository: progress is computed from actuals and remaining effort, workload is consolidated across all projects, the dashboard reads in real time. The switch is justified as soon as you track more than three projects sharing resources, or the monthly consolidation takes more than a day.

Common project monitoring mistakes

• Declared progress: a percentage given off the top of the head, with no quantified remaining effort. Symptom: tasks at 90% for a month.
• Monitoring without decisions: indicators presented, discussed, then nothing. Every alert must leave the room with an action, an owner and a date.
• Indicators without thresholds: 62% spent says nothing until someone has written down the point at which it becomes worrying.
• The self-rewriting plan: baseline dates are updated with current dates, and the variance disappears by construction.
• Too many indicators: beyond eight, nobody reads them and the weekly review turns into a table reading.
• Tracking costs through invoices: the budget drifts long before the invoice arrives; tracking commitments (orders placed, days reserved) warns one to two months earlier.
• Tracking dates only: a project “on schedule” that burns 30% more effort is a project in trouble that the schedule does not show.
• Skipping the ritual “because everything is fine”: it is precisely the week you stop measuring that the drift begins.

Project monitoring in FoxPlan

FoxPlan computes each task’s progress from the actuals logged in timesheets and the remaining effort re-estimated by contributors, rather than from a declared percentage. Budgets distinguish committed from actual spend, per envelope and per expense type, to give an up-to-date estimate at completion. Project status is recorded in a dated status report, and risks, actions and decisions are attached to the project with an owner and a due date. Portfolio dashboards consolidate this data across all projects, so a decision taken on dates immediately shows its consequences on workload and budget.

See how to do it in the FoxPlan documentation ↗

Frequently asked questions

What is project monitoring?

Project monitoring is the regular comparison of what has actually been done — progress, time spent, expenses, risks — with the approved baseline. Combined with control, it triggers corrective actions while a drift is still cheap to fix. It relies on a few thresholded indicators, a weekly tracking table and fixed-cadence rituals.

What are the key project monitoring indicators?

Physical progress, milestone variance, effort spent and remaining, committed budget and estimate at completion, earned value (SPI and CPI), open risks and quality defects. Each indicator needs a formula, an alert threshold and a reading frequency; five to eight well-chosen indicators are enough for a single project.

How do you track project progress?

Ask each contributor for the remaining effort on their tasks rather than a percentage, then compute progress as spent / (spent + remaining). Compare the result with the planned progress at the same date; a gap of more than 10 points, or a milestone slipping by more than a week, calls for a decision at the next review.

What is the difference between project monitoring and project control?

Monitoring measures: it collects progress, time, costs and risks at a fixed cadence. Control compares those measurements with the baseline and decides on corrective action — re-sequencing, reallocating, cutting scope. Monitoring without control is reporting; the two together form the project monitoring and control loop.

How often should a project be monitored?

Weekly for the operational level: a 30-minute team review updates the tracking table and the remaining effort. Monthly, or at each milestone, for the decision level: the steering committee rules on budget, scope and milestone dates from a one-page status report. Risks are reviewed every two weeks.

How do you build a project tracking table in Excel?

One row per task in progress or due within two weeks, with six columns: task, owner, progress, remaining effort in days, due date and a four-value status (done, in progress, at risk, late). Add a decision or action column filled in during the weekly review. Excel works for one project and a small team; beyond three projects sharing resources, dedicated software becomes necessary.

Go further with FoxPlan

• Dashboards and project reporting
• Resource management and timesheets
• The steering committee
• Project risk management