Consulting results should be measured by useful changes in the business, as well as by delivery of the agreed work. A report can be complete while the intended benefit remains unrealised. This article explains how to establish a baseline, assign ownership and test the value of a consulting engagement without attributing every improvement to the consultant.
Separate deliverables, outcomes and benefits
A deliverable is an agreed product of the engagement, such as a redesigned approval process. An outcome is a change in practice, such as fewer incomplete requests reaching an approver. A benefit is the value that follows, such as less paid overtime or more usable processing capacity. These are connected, but they are different things to measure.
Benefits realisation is the work of turning intended value into observable results. UK government project-delivery guidance treats benefits as something to define, own and follow through. The practical approach below adapts that principle to a consulting assignment; it is not a claim that a public-sector method is mandatory for every company.
Agree the starting point before work begins
A baseline is a documented picture of performance before the change, used as a reference for comparison. A target is the level you want to reach afterwards. Agree both before work starts, including when the benefit should appear and how you will verify it.
Write a benefit statement that names the process, the affected population, the measure and the comparison period. Replace “improve efficiency” with “reduce paid overtime caused by correcting incomplete service requests”. Record the current overtime cost, request volume and main causes. Keep the source records so another reviewer can reproduce the baseline.
Check whether the baseline represents normal operations. A holiday period, unusual customer mix or temporary vacancy can distort it. When historical records are weak, collect prospective data before estimating savings. Mark missing information explicitly. An uncertain baseline cannot support a precise claim about improvement.
Give each benefit an operational owner
A benefit owner is the person accountable for achieving the benefit and tracking its evidence. The consultant may design the method and help analyse evidence. Someone inside the organisation must own implementation after the engagement. That person needs authority over the process and access to the relevant data. Finance should review financial benefit calculations, while operational owners confirm that the change actually occurred.
| Record | What to agree |
|---|---|
| Benefit | Specific value expected from the change |
| Owner | Person accountable for achieving and reviewing it |
| Measure | Definition, source, baseline, target and review date |
| Dependencies | Training, adoption, data and other required changes |
Hypothetical example: available time is not automatically cash savings
This is a hypothetical example for illustration, not an ATMACSS result or a forecast for a client. A company spends AED 30,000 on consulting and AED 10,000 on implementation and training. Implementation costs include the staff time charged to this project. The example assumes no additional excluded costs. The agreed evaluation period is 12 months after implementation.
Suppose records support AED 24,000 in avoided overtime and AED 20,000 in reduced external correction charges during that period. The example assumes unchanged workload, request mix and prices, with no separate change explaining the savings. Financial benefits total AED 44,000 against costs of AED 40,000, leaving a net benefit of AED 4,000.
Using the simple engagement calculation, return on investment (ROI) = (benefits − costs) ÷ costs × 100 = 10%. The example excludes tax and the time value of money. A longer or more complex investment may need discounted cash-flow analysis. Time value means that money today has a different value from the same amount received later. In a real project, include any necessary operating, subscription or maintenance costs within the evaluation scope.
Suppose staff also report 200 hours saved. Do not add a salary-based value for those hours if the same overtime reduction already captures it. If normal salaries remain unchanged, report usable capacity separately unless there is evidence of an additional financial benefit. Time released has value, but it is not necessarily money removed from the budget. Explain how the available hours were used, such as clearing a backlog, and provide evidence. If you estimate their financial value, report it separately from actual cash savings.
Test what else changed
Compare periods with consistent definitions and examine other explanations. Did demand fall? Did prices increase? Was a separate software upgrade introduced? A before-and-after difference shows change; it does not establish how much the consulting engagement caused. Use a comparable process or phased introduction when practical, while recognising their limitations.
Record implementation timing. A change adopted halfway through the period should not receive credit for earlier improvements. Distinguish observed benefits from projected benefits and avoid adding them together. Where attribution remains uncertain, report a reasonable range with explicit assumptions rather than claiming false precision.
Review adoption and adverse effects together
Set review dates that match the process. An early review can check whether people use the new method; a later review can examine results. Track unintended effects too. Faster approvals may increase errors, shift work to another team or weaken an essential control. A local saving that creates a larger cost elsewhere is not a net organisational benefit.
- Confirm that the agreed deliverable meets its acceptance criteria.
- Check adoption using actual work samples.
- Validate costs and realised benefits over the same period.
- Record remaining actions, owners and the next review date.
Make the benefit claim reproducible
Before accepting a benefit in a report, bring its definition, measurement period, source and calculation into one record. Identify who prepared and reviewed the calculation, and link the evidence explaining the change in spending or performance. If two departments share the same benefit, agree where to record it so the organisational total does not count it twice. Keep reasons for excluded items alongside the final total.
When actual results differ from the estimate, do not silently replace the original figure. Record the estimate, result and explanation, such as delayed implementation, changed workload or failure to use the new process. The review may lead to improved implementation, a revised forecast or withdrawal of an unsupported claim. The benefit owner remains responsible after the consulting report is delivered. Set a follow-up date and retain evidence showing whether the agreed action had an effect.
Close the engagement without closing accountability
At handover, retain the baseline, calculation method, evidence links, assumptions and benefit owners. Decide which benefits are realised, which remain in progress and which are no longer credible. Close obsolete claims explicitly. Continuing to report an unsupported benefit creates misleading management information.
Start by choosing one intended benefit from a current engagement and completing its record. Use the ROI explanation for financial interpretation and operational performance analysis to investigate process results. ATMACSS business and operations modelling can help connect process changes with measures and accountable implementation.