Fixing the operating model before building software

The situation

What was going wrong

• 01

  Rapid growth had left ownership of key processes genuinely unclear.

• 02

  Delivery teams and sales worked from different definitions of a 'confirmed' engagement.

• 03

  Leadership had no reliable view of margin until well after invoicing.

• 04

  The assumption was that a new system would resolve all of the above.

Our approach

What we did, and why

1. 01

   Mapped the process as it is actually run

   We followed live engagements end to end and documented the real path, including the workarounds people had quietly invented to keep things moving.

2. 02

   Quantified the cost of the friction

   Rework, chasing, and duplicate entry were measured in hours and converted to cost, which turned a vague frustration into a prioritised list with numbers attached.

3. 03

   Redesigned ownership and definitions first

   Clear stage gates, single named owners, and one shared definition of engagement status removed a substantial share of the friction with no software at all.

4. 04

   Scoped only the software that was still needed

   With the process fixed, the genuine system gaps were narrow: margin visibility and resource forecasting. We scoped and costed those, and recommended against the rest.

The outcome

What changed

Proposed build scope reduced by roughly 60%, with the savings redirected into change management and training. Leadership now sees engagement margin during delivery rather than after invoicing. The client's own summary was that they had been about to spend a large budget automating a process that did not work.

−60%

Software scope required

9 → 4

Handoffs per engagement

Live

Margin visibility, was post-invoice