What a Project Actually Cost

The cost of a piece of work is not the hours billed against it. It is all the effort it consumed, and most systems capture only the part that produced revenue.

What billing omits

Scoping and pitching, which happened before the matter existed.

Supervision and review, frequently by the most expensive people.

Rework, which is written off and therefore invisible in billing data.

Administration attached to the work: setup, reporting, closing.

Meetings about the work that nobody codes to it.

Support after completion.

Together these are commonly a substantial fraction of total effort, and a project that looks profitable on billed hours can be unprofitable on effort.

Getting it recorded

Make non-billable codes as easy to use as billable ones. Where recording unbillable time is harder, it will not be recorded.

Do not penalise it. An organisation with an individual billable-percentage target has instructed everyone not to record supervision, and then wonders why supervision is invisible.

Few enough categories to be usable, with the internal ones named the way people think about them.

Attribute internal work to the project where it belongs, rather than to a general overhead bucket, or the costing question cannot be answered.

Doing the analysis once, by hand

Take one completed project and reconstruct its true cost.

Interview the people involved about effort the timesheet missed.

Add supervision, rework, scoping, support.

Compare against the billed figure.

The gap is usually large enough to change how the organisation prices, and it is the single most persuasive piece of analysis available in this field. Do it before building any reporting.

Allocation choices

Direct effort is straightforward.

Shared effort — a manager across six projects — needs a rule, and the rule should be simple and stated rather than precise and disputed.

Overhead allocation is an accounting question, and importing it into the time analysis makes the operational finding harder to see. Keep effort and overhead separate.

Capitalisation of development effort has its own accounting requirements and its own definition of qualifying work, which is a reason to design project codes with that boundary in mind from the start rather than reconstructing it at year end.

What the analysis answers

Which work loses money, which is frequently not the work anyone suspected.

Where effort goes that nobody planned for, usually rework and coordination.

Whether a category of work should be priced differently, done differently, or declined.

What a proposal should actually assume, which closes the loop with estimates.

What to report

Total effort by project, split billable and not.

Effort by activity type across the portfolio: delivery, rework, supervision, administration, support.

Cost against revenue by project type.

The proportion of total effort that is unbilled, trended. A falling figure usually means it has stopped being recorded rather than stopped happening.

The one-project reconstruction

The most persuasive analysis available in this field and it requires no software.

Pick one completed project.

Ask everyone involved what they actually spent, including scoping, supervision, rework and support.

Add it up.

Compare with the billed or budgeted figure.

The gap is usually large enough to change pricing, and it makes the case for a system better than any vendor material.

Do it before building any reporting, because it tells you what the reporting needs to capture.

Keeping effort and overhead separate

A boundary that keeps the operational finding visible.

Direct effort is what people spent on the work.

Overhead allocation is an accounting exercise with its own rules and its own disputes.

Mixing them makes the operational question harder to see: whether this type of work takes more effort than assumed is a different question from how the rent is apportioned.

Report effort first, unallocated, then the costed view separately.

Both are needed; conflating them means neither conversation happens properly.

A useful implementation prompt

During configuration, time tracking for accountants can be used as a prompt for questions about fields, ownership and output. Confirm current capabilities with the provider and document any plan, integration or policy assumption behind the decision.