We bought the software eighteen months ago and half the business still works off spreadsheets.
Implementation is a change problem wearing a technology costume. We specify what the business actually needs, hold the vendor to the contract, and stay until it is being used. Most failed implementations were decided before the software was chosen. The requirement was a wish list gathered in one meeting, the demonstration was persuasive, and the contract was the vendor’s order form with a discount written on it. What follows is a project with no agreed definition of done, run by people whose actual job is something else, against a supplier whose obligations were never written down. The client side of that purchase is a job. Somebody has to decide what the business is buying, hold the supplier to what was sold, and stay in the room until the old way of working has actually been switched off.
Dinmore Bell runs the client side of a systems purchase: specifying what the business needs, running selection, negotiating the contract and service levels, and managing delivery to landing. Technical build and integration are delivered by specialist implementation partners, procured and managed by Dinmore Bell against the contract.
How we own it
Specify before you buy
What the process is now, what it should be, and what the system must do. Written down before a demo is booked. A requirement written after the demonstration is a description of the software. It is the single most reliable predictor of an implementation that overruns, because every later argument about scope is decided by whoever has the clearer document, and that will not be you. The specification that works is unglamorous: the process as it actually runs today including the workarounds, the process as it should run, the data that has to move, the integrations that must exist on day one, and the handful of things that would make the business reject the system outright. Separating the last group from the wish list is most of the value. A business that cannot say which three requirements are non-negotiable will be sold the ones the vendor finds easiest to deliver. Selection then becomes a comparison rather than a preference. The same scenarios are put to each vendor, the same questions are asked about migration and support, and the shortlist is scored against the specification rather than against the quality of the presentation.
Hold the vendor
Statement of work, acceptance criteria, milestones tied to payment, and the data-migration obligations in writing. The order form is not the contract, and the proposal is not the specification. What binds a supplier is the statement of work, and what makes it enforceable is acceptance: a written test the system either passes or does not, agreed before the work starts. Payment milestones follow acceptance rather than elapsed time. A supplier paid on dates has no commercial reason to finish; a supplier paid on acceptance has every reason. Where a licence fee starts on signature, the negotiation to have is when it starts rather than how much it is, because twelve months of subscription on a system nobody is using is a real cost with no benefit attached. Migration is the obligation most often left vague. Whose job is it to extract, cleanse, map and reconcile the data, who signs off that the balances match, and what happens if they do not. Those four answers belong in the contract, because the cost of getting them wrong falls on the business regardless of who caused it.
Land it
Configuration signed off, data migrated and reconciled, people trained, and the old process switched off — which is the step everyone skips. A system that runs alongside the spreadsheets has not been implemented. It has been bought. The parallel period is meant to be short and deliberate, with a date on which the old process stops, and somebody senior enough to enforce it. Training is usually treated as an event when it is a phase. People need the new process explained in the language of their own job, not the vendor’s, and they need somewhere to take the questions that arise in week three when the trainer has gone. Adoption is measurable: who is logging in, which steps are being bypassed, and where the manual workaround has quietly survived. The last piece is the handover. Who owns configuration changes, who holds the administrator accounts, what the support route is, and what happens at renewal. An implementation that ends without those four answers has simply moved the dependency from a spreadsheet to a supplier.
What the contract has to say
Service levels with a remedy attached, not a promise in a marketing page. A service level with no service credit and no termination right is a statement of intent. Four clauses decide how a software relationship behaves once the relationship is no longer new. Exit and data return: in what format, within what period, at what cost, and with what assistance. Price on renewal: whether increases are capped and to what index, because an uncapped renewal on a system now embedded in the business is a negotiation you have already lost. Intellectual property in the configuration and any bespoke development, which is frequently owned by the supplier by default. And the right to audit or at least to see what is happening to your own data. Security and data protection terms belong in the same conversation. Where the system holds personal data, the processing terms, the sub-processor list and the breach notification period are contractual questions rather than an appendix nobody reads.
When it has already gone wrong
Most of the work we are asked to do here starts eighteen months late, with a system half-configured, a supplier invoicing and a business that has lost confidence in the project. The first step is a position rather than a plan: what was actually promised, what was actually delivered, what has been paid, and what the contract says about the gap. That assessment usually narrows the options quickly, because the leverage available is a function of the paperwork rather than the strength of feeling. From there the choices are ordinarily three. Reset the project on a written, accepted scope with the supplier. Re-procure, with the migration obligations of the outgoing supplier enforced. Or recover, where the amounts justify it. Each is a commercial decision with a cost attached, and it is better made with the contract read than with it assumed.
Where specialists come in
Technical build and integration work is delivered by specialist implementation partners, procured and managed by us against the contract.
Related results
All results →Sectors we run this for
Related insights
All insights →Where nine per cent of your revenue goes
Contract value rarely leaks in a single expensive event. It leaks quietly, through renewal dates nobody owns.
Your break clause is a deadline, not an option
Most break clauses fail on a condition nobody read, not on a decision anyone took.
- We already have a vendor lined up. Is it too late to do this?
- No. The period between selecting a supplier and signing is where most of the value sits, because the specification, the acceptance criteria and the payment milestones are all still negotiable. After signature the same conversations happen with less leverage.
- Do you build the system yourselves?
- No. Technical build, configuration and integration are delivered by specialist implementation partners. Dinmore Bell runs the client side: specification, selection, contract, acceptance and delivery management, with the partner procured and managed against that contract.
- Our implementation is already overdue and the supplier is still invoicing. What can we do?
- Start with the contract and the record. What was promised, what was delivered, what has been paid, and what the agreement says about the shortfall. That determines whether the realistic route is a reset, a re-procurement or a recovery, and it is a short piece of work.
- How long should an implementation take?
- It depends far more on the number of processes changing than on the software. The useful discipline is not a total duration but a dated point at which the old process is switched off, agreed at the start and enforced.
- Who owns the data and the configuration if we leave?
- Whatever the contract says, which by default is often less than a business expects. Exit terms covering data format, extraction assistance, timescales and cost, and ownership of bespoke configuration, are negotiated before signature because they are close to unobtainable afterwards.
- What is the difference between this and hiring a project manager?
- A project manager runs the plan. This role also owns the commercial and contractual side: what was bought, what acceptance means, what happens when a milestone is missed, and what the renewal looks like. Those are the levers that decide the outcome.
- Can you take over a project part-way through?
- Yes, and that is how most of this work starts. The first stage is establishing the contractual position and the state of delivery, which usually takes days rather than weeks and changes what the sensible next step is.
- Does this cover AI tools as well as traditional software?
- The same discipline applies and the contract questions get sharper: what the supplier may do with your data, what happens when the model changes, and who carries the risk when an output is wrong. Those are negotiated rather than accepted as standard terms.