Zoho Projects Is Not a PSA: The Four Things a Services Firm Bolts On Before It Can See Margin by Project.
Updated: 4 days ago
Zoho Projects is a good project management tool. It holds tasks, milestones, dependencies, assignments, timesheets and a Gantt chart, it connects to the rest of Zoho, and for the price it is hard to argue with. A services firm that adopts it gets a delivery team that knows what it is doing this week.
What the firm does not get is the thing the partners actually wanted, which is margin by project. Zoho Projects is not a professional services automation system, and nothing on its feature list pretends otherwise. The four things a firm needs before margin by project exists are outside the product. This post says what they are, in the order to add them, and why adding them is a better answer than buying a PSA.
What Projects holds and what it does not.
Projects holds the work: what is to be done, by whom, by when, and how long it took, if people fill in timesheets. That is the actual side of a services engagement, the cost side, and Projects holds it well.
It does not hold the estimate that the proposal was priced on, except as a number someone types into a budget field. It does not hold the rates the client is billed at by role, or the loaded cost rates of the people doing the work. It does not raise the invoice; Books does, and the link between the two is a setting, not a flow. And it does not report margin, because margin is revenue minus cost and it has neither as data.
We wrote the general version of this in a companion piece, What Breaks Between the Proposal, the Project and the Invoice, and Projects is the middle document of the three. This post is about what to attach to it.
Bolt-on one: the estimate, from the CRM, as the budget.
The proposal was priced on hours by phase and by role. Those hours are the budget the project should be measured against, and they need to arrive in Projects as data when the deal is won: a task list or milestone structure that mirrors the proposal's phases, with the estimated hours on each.
That means the estimate has to exist as structured data in the CRM first, which for most firms is the real first step. We have written about what the CRM needs to hold for a services firm, and the estimate table is the centre of it. Once it exists, the join from a won deal to a new project with a budget is a small piece of Deluge, and from that day the project tool can show consumed hours against estimated hours for every phase, every week. This one bolt-on is what turns a project that is quietly losing money into a project that a partner can see drifting in week two.
Bolt-on two: rates, by role, in one place.
Margin needs two rates per hour: what the client is billed and what the person costs. Projects has a place for a billing rate per user, which is the wrong shape for a firm that bills by role and staffs by person, and no place for cost rates. So the rates live in a small custom module, in the CRM or in Creator, with the bill rate by role per client and the cost rate by person, with effective dates, because both change.
Every hour on a timesheet is then valued twice, once at each rate, and the project's revenue-to-date and cost-to-date exist as numbers. This is a small build and it is the one most firms skip, which is why their margin figure, when they finally compute it, is hours times an average rate and wrong by an amount nobody can name.
Bolt-on three: the join to Books.
Approved timesheets and completed milestones have to become draft invoices in Books without an export. Zoho's native link between Projects and Books does part of this for time and materials work, and it is worth turning on. What it does not do is handle fixed-price milestones alongside time and materials, apply the rates by role from bolt-on two, or record a write-down as a decision. So most firms build the join: a flow that takes approved hours or completed milestones, values them at the client's rates, and creates the invoice in Books with the project reference carried, so the payment can be matched back.
The CRM-to-Books join is the general shape, with the project in between. When it exists, the invoice matches the project because it came from it, and the partner's write-down is a recorded number rather than a quiet edit.
Bolt-on four: the reporting layer.
With the estimate in the project, the rates in a module and the invoices linked, margin by project is computable and still not visible, because it lives across three applications. The last bolt-on is the view: Zoho Analytics, joined to Projects, Books and the rates module, showing estimate against actual by phase, revenue and cost to date, margin by project, by client, by partner, and utilisation by person. We have written about what Analytics does and when to use it; this is the case where it earns its place, because the alternative is a spreadsheet built quarterly by whoever drew the short straw.
The order, and why.
The estimate first, because without a budget nothing can be measured and the other three have nothing to compare against. Rates second, because valuing hours is what turns time into money. The Books join third, because it needs the rates and because it is where the invoicing effort goes away. Reporting last, because it is a view of the other three and a view built before the data exists is a view of nothing.
A firm that does the first two has margin by project on a spreadsheet within a month. A firm that does all four has it on a dashboard every Monday, and its estimates get better every quarter because the actuals close the loop.
Why not buy a PSA.
A PSA product bundles the four bolt-ons into one system, and if your firm is willing to move its CRM, its delivery tool and its billing into that system, it is a fair answer. Most firms of this size are not willing, because the sales team lives in the CRM, the delivery team lives in Projects and the accountant lives in Books, and each of them has reasons to stay. A PSA bought to escape the four bolt-ons produces a fifth system that needs three joins to the other three, which is the problem in a new coat.
The four bolt-ons are the product. Projects stays. Books stays. The CRM stays. Whether the middle two are built in Creator or inside the existing applications is a design choice with a small cost either way.
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 the firm has never seen. Then a written plan and a guaranteed estimate for the four bolt-ons in order, on the Zoho applications you have. We run our own delivery on this shape, and our retainer clients have a project plan each because the estimate is the budget and the budget is visible every week.
The short version.
Zoho Projects holds the work and not the money. A services firm bolts on four things before margin by project exists: the estimate as budget, rates by role, the join to Books, and a reporting layer. Add them in that order, keep the applications you have, and do not buy a PSA to escape a join problem.
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