What Breaks Between the Proposal, the Project and the Invoice.
Updated: 3 days ago
A services firm, whether it sells consulting, engineering, design, legal work or implementation, produces three documents for every engagement. A proposal, which prices the work. A project, which records the work. An invoice, which bills the work. They are written by three different people in three different systems, and the unit in all three is time.
Nothing carries the time from one document to the next. The proposal estimated hours; the project consumed hours; the invoice billed a milestone or a month. Whether the engagement made money is the difference between the three, and in most firms of twenty to two hundred people that difference is computed once a year, by the accountant, for the firm as a whole, and never for a project.
This is the mechanism behind the category the software industry calls professional services automation. The category is real. The products are fine. But what a firm actually needs is three joins, and this post is about what breaks without them and what they look like when they exist.
The three documents.
The proposal prices the work.
It lives in the CRM, or a proposal tool, or a document. It has a scope, a set of deliverables or phases, an estimate of hours by role, a rate by role and a price, which is either the hours times the rates or a fixed number derived from them with a margin on top. The estimate is the most important number the firm produces, because every later number is measured against it, and in most firms it is never stored as data. It is a table in a document.
The project records the work.
It lives in the project tool: Zoho Projects, Jira, Asana, a spreadsheet. It has tasks, assignments, dates and, if the firm is disciplined, timesheets. The hours recorded here are the actual cost of the engagement, at whatever loaded rate each person carries. The project tool does not know the estimate, because the estimate was a table in a document, so it cannot say whether the project is over or under until someone builds a spreadsheet.
The invoice bills the work.
It lives in the accounting system. For fixed-price work it bills milestones; for time and materials it bills hours, which someone exports from the project tool and retypes; for retainers it bills a month. The invoice does not know the estimate either, and it knows the actual hours only as an export. So the accounts receivable person is reconciling a document against a spreadsheet against a memory of what was agreed.
What breaks.
Projects that lose money invisibly. A fixed-price project runs twenty percent over the estimated hours. Nobody sees it, because the estimate is in a document and the hours are in the project tool. The invoice goes out for the agreed price and the loss is absorbed into the firm's margin, where it is indistinguishable from every other loss.
Write-downs at invoicing. A time and materials engagement accumulates hours the client did not expect. At invoicing, the partner looks at the number, anticipates the argument and writes the hours down. The firm did the work and chose not to bill it, and the decision left no trace.
Scope creep that is never priced. The client asks for one more thing. The team does it, because the project tool has a place for tasks and no place for the question of whether the task was in the proposal. Three small things later, the project is a different project at the original price.
Utilisation nobody trusts. The project tool reports hours by person. The accounting system reports revenue. Dividing one by the other requires the join that does not exist, so utilisation is computed quarterly in a spreadsheet, and argued about.
Estimates that never improve. The one thing that would make the next proposal better is a comparison between the last estimate and the last actual, by phase and by role. Since neither is data in the same place, the comparison never happens, and the firm estimates the same way it did five years ago.
We saw all five in an IT services firm we worked with, and the first thing that changed when the joins existed was not the software. It was that a partner could see, in the second week, that a project was going to lose money, while there was still time to do something about it.
The three joins.
Proposal to project: the estimate becomes the budget.
When the proposal is won, the estimate, by phase and by role, is written into the project as its budget, as data, not as an attachment. This is one join and it is the one that changes everything after it, because from that moment the project tool can compare consumed hours against estimated hours for every phase, every week, and show the partner the projects that are drifting. If your proposal tool cannot hold the estimate as structured data, that is the first thing to fix, and it is usually a small change to the CRM; we have written about what the CRM has to hold for a services firm for exactly this reason.
Project to invoice: the hours become the bill.
Approved timesheets and completed milestones flow to the accounting system as draft invoice lines, at the rates on the proposal, without an export. For time and materials, the invoice is the hours; for fixed price, the invoice is the milestone and the hours are the cost behind it; for retainers, the invoice is the month and the hours are the utilisation. Either way, the write-down, when the partner chooses to make one, is a recorded decision on a recorded number rather than a quiet edit to an export.
Invoice back to the estimate: the actuals close the loop.
When the project closes, the actual hours by phase and role, the invoiced amount and the write-downs go back against the original estimate, so that the firm has, for every finished engagement, the estimate, the actual and the gap. That is the data the next proposal should be built from. It is the join firms build last and the one that pays for the longest, because it is how the estimates get better.
Why the category is a distraction.
Professional services automation products bundle the three documents into one system so that the joins are built in. That is a fair answer for a firm that is willing to move its CRM, its project tool and its billing into one product. Most firms are not, because the CRM is where the sales team lives, the project tool is where the delivery team lives, and the accounting system is where the accountant lives, and each has reasons to keep the tool it knows.
For those firms, the joins can be built between the tools they have. On Zoho, that is the CRM holding the estimate, Projects holding the budget and the timesheets, and Books holding the invoices, with the three joins between them; we have written about how the CRM and Books connect as one of them. On other stacks, the same three joins through different products. The category is the three joins. The product is optional.
How we start.
A no-risk discovery: a few days to take the last quarter's closed projects, put the estimate, the hours and the invoice side by side for each, and show the partners the margin by project that the firm has never seen. That number decides the conversation. Then a written plan and a guaranteed estimate for the joins in the order above, on the tools you have. We run our own firm on these joins, and every retainer client of ours has a project plan for the same reason: the estimate is the budget, and the budget is visible every week.
The short version.
A services firm's proposal, project and invoice are three documents about the same hours, and nothing carries the hours between them. The result is projects that lose money invisibly, write-downs that leave no trace and estimates that never improve. Build the three joins: estimate to budget, hours to invoice, actuals back to estimate. The category name does not matter. The joins do.
Find out what one connected Zoho system would change in the way you run.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
Comments