Someone on your side of the table while the implementation runs
We hold scope against the original business case, test what was promised rather than what was built, and surface problems while they are still cheap to fix. Whether the build is ours or somebody else's.
The status report is green until the month it is red
Implementation partners are not villains. They are commercially rational. They build what the statement of work says, they raise change requests when it does not cover something, and they report progress against their own plan.
What is missing is anybody checking that plan against the thing the board actually approved. Scope moves one change request at a time, each one reasonable on its own. Testing gets compressed because it sits at the end. The people who sold the project moved on to the next one.
We sit on your side of that. Not to be adversarial with the partner, but to make sure someone in the room can read a technical design document and a business case, and can tell when the two have quietly stopped matching.
What the work covers
Scope control against the business case
Every change request assessed for what it does to the outcome the board approved, not just for its price. A log of what has moved, cumulatively, in language a non-technical board can read.
Independent acceptance criteria
Written before build starts, from the requirements rather than from the design. Testing against what you asked for, not against what was built.
Risk and issue management
A risk log that names owners and dates, is reviewed on a fixed cadence, and escalates on its own terms rather than when somebody feels brave enough.
Data migration assurance
Migration is the most common cause of a delayed go-live and the least likely thing to be tested properly. We check reconciliation, volumes and the exception handling before cutover weekend, not during it.
Go-live readiness review
A structured assessment against defined criteria, with a real recommendation attached. Sometimes that recommendation is to delay, and it is worth having someone who can say so.
Handover and benefit tracking
Documentation, training and support arrangements checked before the partner leaves. Then a look back at whether the business case is actually being delivered.
What you end up holding
Named artefacts, handed over. Not a slide deck summarising them.
- Acceptance criteria mapped to the original requirements
- Cumulative scope movement log, business case impact stated in plain terms
- Risk and issue register with named owners and escalation triggers
- Data migration reconciliation and exception reports
- Go-live readiness assessment with a go or no go recommendation
- Handover checklist and post go-live benefit review
When to call us
Any one of these is enough. You do not need a defined project first.
- The project is reported as on track but the go-live date has moved twice.
- Change requests keep arriving and nobody can tell you what they add up to.
- Your team is being asked to sign off on designs they do not have the background to assess.
- User acceptance testing is scheduled for two weeks, right at the end, and it has already been shortened once.
- The people running the build are not the people who sold the project.
An assessment, not a proposal
Two to four weeks at a fixed price, delivered as a decision document. You own the output whether or not you carry on with us.
Start with an assessmentWe are an independent consulting firm. Software vendors do not pay us, so our recommendations come with the scoring behind them.