In a consultancy, money is made at the level of a single engagement, not the annual report. A partner usually knows intuitively which projects carry the result and which eat into it, except that this knowledge lives in people’s heads and in spreadsheets, not in one consistent view. So consulting analytics does not start with charts but with a question: do we actually know what a specific engagement really costs and really earns.
In our experience, the hard part is not drawing a dashboard but getting project, people and contract data into a state where the numbers add up. We do not have a ready case study to show here, but we do have what matters most in this kind of project: data engineers, BI architects and ML specialists we place into the client’s team so that this foundation gets built and maintained.
Why does a consultancy need its own engagement analytics?
Because the consulting business model is sensitive to several variables at once: the rate, consultant utilisation, delivery against the hours budget, and revenue recognition over time. Let one of them slip and the project margin disappears, often before anyone notices it in the monthly close.
Standard systems don’t show this as a whole. The ERP knows invoices, the time-tracking tool knows hours, the CRM knows the pipeline, and HR knows people costs, but none of them joins this into a picture of a single engagement’s profitability. A dedicated analytics layer is where those worlds meet, and where a managing partner stops steering by feel.
How do you design a data warehouse for consulting engagements?
The foundation is a data model that describes how the firm actually works, not how it looks in theory. We usually build it around a few key entities:
- the engagement / project as the central unit, with its contract type (fixed price, time & material, retainer),
- the consultant and role, with cost, sell rate and availability,
- the timesheet, tied to a project and a task,
- the contract and budget, with planned revenue and cost,
- the client and industry, for portfolio analysis and benchmarking.
On top of this we put a classic dimensional model (facts and dimensions), because it lets you compute the same measures across different cuts, from a single consultant to a whole business line, without rewriting the logic for every new question.
How do you build margin and utilisation dashboards?
This is the heart of the solution, because the COO and partners look here daily. Margin and utilisation dashboards should answer operational questions faster than it would take to assemble them by hand:
- margin by project and by client, split into planned and realised,
- utilisation per consultant, team and practice, separating billable and non-billable hours,
- budget burn of hours and cost against the schedule (similar to a burn/EAC metric),
- effective rate versus the rate card,
- revenue recognition and work in progress (WIP) on projects billed in stages.
The key is that these measures are computed once, in one place, with a single definition. Otherwise two departments bring two different margins to the meeting, and the discussion turns into whose Excel is the real one.
How do you create libraries of benchmarks and estimates?
Benchmarking is the moment when past data starts earning in future proposals. From project history we build libraries of benchmarks and estimates, that is, structured knowledge of how long and how much repeatable types of work actually take and cost.
In practice this means parameterising projects by type, industry, size and team composition, and then computing distributions of actual effort against the original estimates. Sales stops quoting “by feel”, and a new manager gets a reference point instead of a blank page. It is also the most honest way to name the projects that consistently fail to close out, and to understand why.
How do you forecast pipeline and capacity?
A consultancy sells people’s time, so pipeline and capacity forecasting is essentially matching two curves: demand from the pipeline and supply from the team’s schedules. Look at them separately and you always get either overheating or a bench.
So we combine the weighted pipeline from the CRM with planned allocation and consultant availability, to surface future capacity gaps and surpluses weeks or months ahead. That view turns board conversations from reactive to planning: instead of firefighting a people shortage next quarter, you can start recruiting earlier, move a team, or deliberately slow sales in an overloaded area.
How do you keep source data quality and consistency?
The finest dashboard loses to one mis-assigned timesheet, which is why we treat source data quality and consistency as a separate part of the project, not an afterthought. The typical problems are predictable:
- hours logged late or to the wrong project,
- different definitions of the same concept (what counts as billable) across departments,
- a mismatch between the contract in the CRM and the actual scope of work,
- gaps in cost data for consultants and subcontractors.
So we build data validations and tests into the loading pipelines, alerts for gaps, and a clear measures glossary. The point is not perfect data from day one, but errors that are visible and fixed at the source before they reach a partner’s screen.
When is it worth reaching for ML forecasts?
When simple rules and averages stop being enough, and there is already enough history for patterns to show. ML forecasts don’t replace dashboards; they add a layer of prediction where a person cannot weigh up every dependency.
In consulting this most often makes sense for predicting an opportunity’s probability of closing in the pipeline, predicting a project’s budget overrun from early signals, and forecasting team utilisation in the coming periods. This is a real competence we provide, though we say it plainly: ML only makes sense on clean data, so it is usually a later stage, not the first.
Which skills do we provide for this kind of project?
We shape the team around the specific work, not “just in case”. On analytics projects for professional-services firms these are usually:
- a data engineer building the pipelines and warehouse (ELT/ETL, modelling),
- a BI architect / analyst owning the measures model and the dashboard layer,
- an analytics engineer guarding definitions and transformations,
- an ML specialist where forecasts come in,
- a DevOps / data platform specialist for deployment, security and maintenance.
This setup lets a team take real ownership of the data layer, not just deliver a single report and disappear.
How do we do it at RITS?
We do it as a nearshore partner from Poland that places data, BI and ML skills into the project, even when it is your team that sets the direction:
- we augment the team with specific specialists whose skills we verify before the start,
- we design the data model of the consultancy before the first chart exists,
- we join the sources (ERP, time tracking, CRM, HR) into one maintainable warehouse,
- we add the ML layer only where the data is ready for it, with no promises we can’t back.
We don’t pretend to have a finished rollout to show in this area; we bring the people and the approach that make such a rollout happen at your firm and stay maintained.
Where to start with consulting engagement analytics?
Start from one decision you want to make better, for example “should we take this project with this team”, and from the question of what data that needs. This defines the scope of the first warehouse iteration, the set of measures and the roles you need. One trustworthy margin dashboard beats ten that nobody believes. We covered the differences between engagement models in our article on IT engagement models.
Building analytics and benchmarking for consulting engagements? Let’s talk - we’ll match a data/BI/ML team and an architecture to your firm.
Build analytics and benchmarking for consulting engagements with us