Which Project Reports to Request from Your Contractor
Practice4 minInnovialabs editorial team
In short
Ask for a regular progress report with a demo, a burndown chart, budget burn against plan, a risk register and time logs — and look at trends and mismatches between them rather than at single numbers.
In short: the reports you need
To keep control of a project without digging into the code, five kinds of reports are enough:
- Progress report — what is done, what is in progress, what comes next.
- Burndown — how much work is left and whether the team is on track.
- Budget burn — how much has been spent compared with the plan and with what is done.
- Risk register — what could go wrong and what is being done about it.
- Time logs — where exactly the hours went.
Agree on the set and frequency of reports at the start and record them in the contract or project plan.
Progress report
Usually weekly or at the end of each sprint. A good report contains:
- completed tasks linked to features you can check;
- tasks in progress and expected dates;
- blockers, especially those that depend on you: access, texts, decisions;
- the plan for the next period.
How to read it: the key question is whether you can see the result. A report without a demo or a link to a test version is a reason to ask to see the work live. A warning sign is the same tasks sitting "in progress" for weeks.
Burndown
A burndown chart plots time on one axis and remaining work on the other. The ideal line goes down to zero by the end of the sprint or phase.
How to read it:
| What you see | What it may mean |
|---|---|
| The line stays close to the ideal | The team is on schedule |
| The line is flat | Work is not being closed or tasks are too large |
| The line goes up | New tasks are being added to the scope |
| A sharp drop at the end | Tasks are closed in a batch, possibly without proper checks |
A rising line is a frequent sign of scope creep. Ask who added the tasks and why.
Budget burn
For time-and-materials projects this is the key report. It compares three values:
- the planned budget as of today;
- the actual spend;
- the value of completed work — what the finished part should have cost according to plan.
How to read it: if a lot has been spent but little completed, the project is getting more expensive. Spending less than planned is not always good news: the team may simply be slower, and the delay will show up later. Look at the trend over several periods, not at a single point.
Risk register
A simple table: risk, likelihood, impact, mitigation, owner. For example: "the payment provider's API is unavailable in test mode", "a key developer is on vacation".
How to read it: be suspicious if the register is always empty or has not changed for months — every project has risks. It is a good sign when risks get closed or turn into tasks with a clear solution.
Time logs
A breakdown of hours by task and specialist. Especially important with hourly billing.
How to read it:
- are there tasks that took much longer than estimated;
- do many hours go to vague categories like "meetings" or "other";
- does the distribution match the plan — for example, testing should not disappear from the logs.
The goal is not to catch an extra minute but to understand where the project loses time.
How the reports connect
The most useful conclusions come from comparing them:
- burndown is flat but hours are being logged — work happens but does not finish;
- progress looks good but budget burns faster — estimates were too low;
- no risks are listed but deadlines slip — risks are not being recorded.
When you see a mismatch, ask for a short call and a recovery plan, not just an explanation.