Project Cost Tracking: What to Track Before, During and After Client Work

Why cost always arrives late

On client work, cost is mostly people. People do work, the work gets recorded, somebody checks it, and then at some point money moves. Each of those steps has a lag, and the lags stack.

By the time a cost figure exists, it is describing something that finished weeks ago. That is fine for pricing the next job and useless for saving this one.

So the goal is not faster reporting. It is a different question. Instead of asking what a project cost, ask what the work already underway is going to cost if it goes through as it stands. That number is available immediately, because the work has already happened, and it is the only cost figure you can still act on.

Before: what to set up

Four things have to exist before a single figure means anything. None of them is difficult; all of them are commonly skipped.

1. A unit that cost attaches to

Cost has to belong to something. Pick the level you actually agree prices at, which for most service businesses is the engagement rather than the individual task. Work belongs to an engagement, the engagement carries the agreed value, and cost rolls up to it.

2. The agreed value, recorded

Cost without revenue is trivia. If you do not know what you agreed to be paid for this piece of work, you cannot tell whether the cost is a problem. Record it as a number on the engagement, not as a line in a proposal document.

3. Rates, per person, per kind of work

What does an hour of this person cost you? What does one of these deliverables cost? Write it down before the work starts. A rate agreed after the fact is a negotiation, not a cost.

4. A definition of done

Cost becomes real at a specific moment, and you have to choose which one. The most useful answer for client work is approval: when somebody with authority accepts the work, it becomes payable. Before that it is provisional.

Cost is not always hours

Almost every cost tracking tool assumes hours times rate. Plenty of service businesses do not work that way, and forcing them to invent hours produces a precise-looking number with nothing behind it.

The models that actually turn up:

• Per unit. So much per item, per page, per record processed. Common in back-office and data work.
• Per hour. Where time genuinely is the measure.
• Per task. A flat amount for a piece of work regardless of how long it takes. Common with freelancers.
• Per period. Weekly, fortnightly or monthly. Somebody is simply on the team.
• Per engagement. One fixed amount for the whole thing.

A single project can carry three of these at once. What matters is that each piece of work knows which model applies to it, and that the total is arithmetic rather than estimation.

One honest limitation applies to per-period costs. If somebody is paid monthly and works across six engagements, allocating their cost to individual pieces of work requires an assumption, and any assumption you pick will be wrong in a specific way. It is usually better to report period costs at the level they were incurred than to spread them by a formula that looks precise and is not.

During: the three numbers

While work is running, track three figures separately. Blending them is the single most common failure, because the blended number hides the only part that is still moving.

Pending

Work that has been logged or started but not approved. It is what you would owe if everything in flight went through as it stands. It moves every day, it is provisional by definition, and it is the number that gives you warning.

Approved

Work that has been accepted. You owe this whether or not you have paid it. This is what most systems mean by cost.

Paid

Money that has actually left the business. This is the one your bank agrees with, and it is usually the smallest of the three.

Note what pending is not. It is not a forecast, a risk weighting or a model. It contains no prediction. It is the arithmetic consequence of work that has already been done, priced at rates that already apply. If nobody logs work, it does not move.

Catching cost creep

Projects rarely fail on the work that was quoted. They fail on the accumulation of small unquoted additions, each of which is too minor to escalate.

The mechanism that catches it is embarrassingly simple: when work is created, record whether it was planned or not. Not later, not in a review, at creation, by whoever created it.

Two things follow. First, unplanned work becomes a list rather than a feeling, with a cost attached. Second, the conversation with the client changes, because you are showing what was added rather than arguing about whether anything was.

Keep the operational record separate from the commercial decision. Logging additional work should never automatically increase what the client owes. If your system does that, your team will stop logging things.

After: closing the loop

When the work is finished, three questions are worth answering while the details are still fresh.

• What did it actually cost, against what we assumed? Not to assign blame, but because next quarter's pricing depends on it.
• How much of the total was unplanned? A project that came in at 30 per cent over on additional work has told you something about your scoping, your client, or both.
• Where did the estimate go wrong? Usually one stage, and usually the same stage every time. Review cycles are the most common answer.

This is also the moment to check that cost and cash agree with each other, and to notice if they do not. An engagement can be finished, profitable and still owed money in both directions.

Do not let history move

Rates change. When they do, everything you previously calculated must not silently re-price itself, because a historical cost that moves is not a record of anything.

Two rules keep this straight:

• Snapshot the rate onto the work. When a piece of work is approved, record what it cost at that moment. Do not calculate it later by looking up the current rate.
• Correct by adding, not editing. When something has to change, add a correcting entry linked to the original. Both stay visible. Anyone asking why a figure changed gets an answer.

This is the difference between a cost record and a cost estimate that happens to be stored. The test is simple: can you reproduce last quarter's number today, exactly? If not, you have the second thing.

Five ways this goes wrong

1. One cost number. Blending pending, approved and paid produces a figure that is never wrong and never useful.
2. A tracker somebody maintains. Anything that requires a person to remember to update it is accurate for one month.
3. Assuming hours. Inventing hours for people you pay per deliverable gives you precision without accuracy.
4. Confusing profit with cash. A project can be profitable and leave you short. Report both, separately.
5. Letting scope changes edit the past. If renegotiating an engagement rewrites its earlier figures, you lose the ability to see that it was renegotiated at all.