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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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:
Before and After: A Real Zoho Implementation at an IT Services Firm (article)
Zoho CRM Role Hierarchy vs Territories: Which Controls What Reps See? (article)
Professional services automation software combines, in one product, the pieces a services firm needs to run engagements as money as well as work: the estimate and budget, resource planning and rates, time capture, invoicing and project profitability reporting. A project management tool holds the work; a PSA holds the work and its economics. Firms move to a PSA when they need margin by project and their current tools hold the pieces in separate places.
Yes, natively. The link lets approved time and expenses on a project flow into Books as invoice lines, which covers time and materials billing. It does not handle fixed-price milestones alongside hourly work, apply billing rates by role, or record a write-down as a decision. Firms that need those build a small flow that values approved hours or completed milestones at the client's rates and creates the invoice with the project reference attached.
Zoho Projects holds a billing rate per user, which suits a firm that bills by person. A firm that bills by role per client and staffs by person needs a rates module outside Projects, in the CRM or in Creator, with bill rates by role per client, cost rates by person and effective dates. Each timesheet hour is then valued at both rates, which is what makes revenue to date and cost to date exist as numbers.
Margin by project needs three things Projects does not hold: the estimate as the budget, rates by role and the invoices joined back to the project. With those in place, Zoho Analytics joined to Projects, Books and the rates module shows estimate against actual by phase, revenue and cost to date, margin by project, client and partner, and utilisation by person. Without the inputs, a dashboard is a view of nothing.
It is a fair answer if the firm is willing to move its CRM, delivery tool and billing into the PSA. Most mid-sized firms are not, because sales lives in the CRM, delivery in Projects and the accountant in Books. A PSA bought to avoid building the joins becomes a fifth system that needs three joins of its own. Adding the estimate, rates, Books join and reporting to the existing apps keeps everyone where they are.
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
