Professional Services ERP

The firm had outgrown its existing systems and had a budget approved for a major ERP programme. What it did not have was a way to sequence the work. Requirements came in from every practice area, each one urgent in isolation, none of them mapped to the others. The leadership team needed to commit to scope before they committed to a vendor, and they needed the scope to be defensible to the board.

We started with the operating model, not the modules. Every requirement got traced back to the workflow it was meant to serve and the decision it was meant to support. That exercise alone removed roughly a third of the original ask, not because the requirements were wrong but because they were already met by an existing system the requesting team did not realise was capable of it.

The next pass was ERP module mapping. Each surviving requirement got placed against the candidate platform's native capability map. Where native covered it, we said so. Where native covered most of it with a documented configuration path, we said so. Where the requirement needed custom development, we flagged it explicitly and put a cost and a risk score against it. The deliverable was a single page the executive could read and challenge.

GAP analysis came next. For each gap we wrote the smallest credible solution: a configuration change, a third-party module from the vendor marketplace, a custom build, or a process change that removed the gap entirely. Every option carried an effort estimate in business-readable terms, not consultant-readable terms. The board pack had numbers it could defend.

MVP definition followed naturally from the prioritisation. The first phase delivered the workflows that unblocked the most downstream work: the master data foundation, the project lifecycle, the time and expense capture. Subsequent phases stacked on top. Each phase had its own go or no-go gate, with explicit data migration and adoption checkpoints.

The governance plan ran in parallel. Data migration is where most ERP programmes go wrong, and the worst migrations are the ones that get treated as a final step. We set up the data cleansing workstream in phase one, with named owners by entity and a weekly steering review. By the time the first phase went live, the data was already trusted.