Project Management for Service Businesses

A service business sells time but bills outcomes. You quote a fixed fee for a website, an audit, a fit-out or a six-month retainer, then absorb whatever it actually takes to deliver. Months later the bank balance says the year was fine, yet nobody in the room can say with confidence which engagements paid for themselves and which quietly ate the margin. Closing that gap is the most useful thing project management does for a firm that sells expertise.

Why service work hides its own costs

A retailer knows what a sale costs because stock physically leaves the shelf. In a service firm, the equivalent of inventory is people's hours, and hours are invisible unless somebody deliberately writes them down. A designer stays late to redo a layout, a senior consultant sits in on a client call that was not scoped, an engineer spends two days untangling a client's old files. Every one of those is real cost, and none of it shows up anywhere by default.

Scope creep compounds the problem. Small accommodations are how good client relationships are built, so they rarely get argued about. The third round of revisions becomes goodwill, the extra site visit becomes goodwill, and by the time the final invoice goes out the team has delivered something noticeably larger than what was priced. Nobody objects because nobody has a number. The first job of project management in a service business is simply to make that consumption visible while there is still time to react.

Milestones turn a proposal into a plan

A proposal is a promise about an outcome. A milestone is that promise broken into checkpoints that each have a date, an owner and a definition of done. "Discovery complete," "draft submitted for client review," "user acceptance signed" — each one is something you can point at and say whether it happened, rather than reporting that a project is "around seventy per cent."

ERPat's Projects module is built around this shape: project plans with milestones, tracked across the teams doing the work. The practical benefit is early warning. When a milestone that was due on the fifteenth is still open on the twenty-second, you find out in the same week rather than at handover, and you still have room to reassign people, renegotiate a date, or tell the client honestly that a dependency on their side is holding things up.

Milestones are also the natural place to hang billing. If your contract releases payment on acceptance of specific deliverables, the same checkpoints that manage delivery also manage cash flow, and the two stop being separate conversations.

Timesheets are the only honest record of what a project cost

Hours are the cost base of a service business, so a project's cost is whatever your people logged against it. That makes timesheets less an administrative chore than the accounting record for delivery work. In the Projects module, timesheets sit alongside the plan they belong to, so effort is captured against the project it was spent on rather than in a general pool at the end of the month.

The discipline that matters is timing. Hours reconstructed on a Friday afternoon for the whole week are guesses, and guesses drift toward whatever feels reasonable. Hours entered daily, in short entries, are closer to the truth and take less time to record. Teams resist this when it feels like surveillance and accept it when it visibly does something useful — which is why the reporting loop matters as much as the collection.

Well-kept timesheets protect people too. A team that is consistently over-committed can prove it, and a manager arguing for another hire has evidence instead of an impression.

The daily layer beneath a milestone

Milestones move on a scale of weeks. Actual work moves on a scale of hours, and the distance between the two is where projects quietly stall. A milestone can sit at ninety per cent for a fortnight because one small unassigned task — a missing approval, a file nobody requested — was never anyone's job in particular.

That is the layer the Todo module covers: personal and team task lists that keep day-to-day follow-through visible. It is deliberately lighter than the project plan. Not every task deserves a place in a formal schedule, but every task that blocks a milestone deserves an owner and a place someone will actually look. Used together, the plan tells you where the project is going and the task lists tell you whether this week moved it.

Knowing whether a project actually made money

Once fees are on one side and logged hours on the other, project profitability stops being a matter of opinion. Take the contract value, subtract the cost of the hours recorded against it plus any pass-through expenses, and you have a result for that engagement. Divide the fee by total hours and you get an effective hourly rate you can compare against what you believed you were charging.

The single project is interesting; the pattern across many is where the money is. After a year of records you can usually see which service lines carry their weight, which client types consume far more revision cycles than they were priced for, and which team compositions deliver a given scope efficiently. That is what turns quoting from instinct into something closer to evidence — and it is often the difference between growing revenue and growing profit.

Where to start

You do not need to reorganise the whole firm to begin. Pick one live project, give it real milestones with owners and dates, ask the people on it to log hours daily for its duration, and at closeout compare fee against effort. That one comparison usually starts a more useful conversation about pricing and scope than a year of general discussion, and it gives you a template small enough to extend to the next project without anybody's cooperation running out.