What a project business really needs from a system: time recording people actually complete, milestones tied to billing, and budget versus actuals that updates in time.
Key takeaways
- A losing project is not discovered at the end but in week three - if you measure.
- Time recording that takes more than a minute a day will not be done, and then there is no data.
- A milestone not tied to billing is just a date.
- Budget versus actuals is the only metric that changes decisions mid-project.
In a project business, profit is not decided by the price but by the gap between what was quoted and what was delivered. So the three capabilities that matter are not task management but time recording people genuinely complete, milestones tied to billing, and a budget-versus-actuals picture that updates during the work rather than at the end.
What a project business needs from a system
| The need | What is actually required | What happens without it |
|---|---|---|
| Time recording | One screen, under a minute a day | Hours reconstructed at month end |
| Budget vs actuals | Per project and per phase | A loss discovered on the final invoice |
| Milestones | Tied to billing and customer approval | Cash flow delayed for no reason |
| Scope changes | Recorded and approved | Work delivered and never billed |
| Utilisation | How many hours are billable | Mispricing the next project |
Row four is the most common source of loss in a services business: the customer asked for a small change on the phone, someone did it, and nobody billed for it.
Why does time recording fail?
Because it is built for the report rather than for the person filling it in. A form with four mandatory fields, a project picked from a list of forty, and a free-text description guarantees it gets completed on a Friday from memory - at which point the data is wrong anyway.
What works: a short list of that person's active projects only, recording in quarter-hour blocks, and an optional description. From a phone if possible. The difference between daily and weekly completion is the difference between a number you can rely on and an organised guess.
It is also worth explaining to the team why you measure. Time recording perceived as attendance monitoring produces distorted data; time recording presented as the way to price the next project properly and avoid unpaid work gets cooperation.
Milestones connected to money
A good milestone answers three questions: what exactly is delivered, who approves it, and how much is billed as a result. A milestone answering only the first is a date in a calendar.
The structure that works on most projects: an advance at the start, a mid-point payment tied to a defined delivery, and a completion payment on acceptance. What matters is that the approval is recorded - an email, a signature or a status - because otherwise billing depends on two parties remembering differently.
How do you spot a losing project early?
- Actual hours passed 50% of budget while the deliverable is barely half done.
- Change requests passed two with nothing billed.
- A milestone slipped twice and nobody updated the plan.
- One person is absorbing most of the hours, and that was not the plan.
- The customer is late replying by more than a week on average.
The first two alone justify stopping to talk. That conversation, held in week three, is usually about scope; held at the end, it is about money - and that is a far harder conversation.
What about task management tools?
A work management tool is excellent for coordinating who does what, and it usually exists already. What it does not give you is the financial side: hours connected to a budget, billing by milestone, and utilisation. Those can be added by hand in a spreadsheet, and that works up to a point.
The practical limit is more than a handful of concurrent projects, or someone spending hours a month merging data manually. The general distinction between tool types is covered in Monday versus Priority for operations, and it applies here too.
What to test in a demo
- Record one hour against an existing project, and time how long it took.
- View budget versus actuals for one project without building a report.
- Add a change request and see how it affects the budget.
- Issue an invoice from a milestone.
- View one employee's utilisation for a month.
The first filters harder than the rest. A system where recording an hour takes more than a few taps will not be filled in, and a system that is not filled in supplies none of the other numbers.
What to do with the data after three projects
The real value accumulates after several similar projects, when comparison becomes possible. Three comparisons that change pricing:
- Estimate versus actual per type of work. If analysis always takes twice the estimate, that is not repeated failure - it is a systematic estimating error that is easy to correct.
- How many hours went into management and coordination. This is the line almost nobody prices, and it is often a fifth of the project.
- Which kind of customer generates the most hours beyond plan. Sometimes the answer leads to a business decision rather than a pricing change.
The most common pattern that emerges is that small projects are the least profitable - the same opening and closing work on a smaller amount. That is worth checking before deciding to grow specifically in small work.
Who holds the picture
A project business needs one person looking at budget versus actuals every week, even if that is the owner and it takes twenty minutes. Not the project manager alone - they are too close and tend to believe the delay will even out; and not the accountant - they see the picture two months too late.
The format that suffices is a short list: per active project, the percentage of hours used against the estimated percentage complete, and one line on what is unusual. When those two disagree, that is the only signal you need to know something warrants a conversation.
Sources
Frequently asked questions
What about fixed-price projects?
Time recording matters more there, not less. On fixed price the hours are not a billing basis but a pricing basis for next time: without knowing what it really took, the next quotation rests on a feeling, which is the most common way to lose money twice on the same kind of project.
How much detail is needed?
Project level, and phase level if necessary. Task-level detail sounds more precise and in practice lowers completion rates, which produces worse data. A coarse number recorded daily beats a detailed one recorded at month end.
How do we handle changes the customer asks for by phone?
With a short procedure: every change is logged as a request, given an hours estimate, and sent for approval - even when the approval is a one-line message. It sounds too formal for a small business and is in fact what prevents most project margin loss.
Do we need a dedicated project system?
Not necessarily. Some ERP systems include a projects module, and some work management tools include time recording. What decides it is whether the financial picture of a project exists in one place without manual work - a question worth testing on real data rather than in a slide deck.
Keep reading
Related service
MVP Development
Turn an idea into a validated product in weeks, not months.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build and I'll tell you the fastest reliable way to ship it.