The Five-Solution Problem: Why Standardisation isn't Boring, It's Smart Risk Management

A few years back, one of my clients, a government department with around fifty staff, ended up with a backup system that was completely wrong for them. Not because anyone was lazy or careless. Because I made a judgement call based on the wrong information, and it cost that client money, time, and a fair bit of our credibility.

Here's what happened. We had another client, a much bigger one, who'd already committed to a particular enterprise backup platform. It was a solid product, no argument there, but it was genuinely complex. When the opportunity came up to refresh backups at the smaller government client, I thought, well, we need to know this platform properly anyway, so let's roll it out here too. It made sense on paper. We'd build internal capability, kill two birds with one stone.

What I didn't do was ask the only question that actually mattered: what does this particular client need?

The answer was nothing like what we installed. The big client had an internal IT staff member managing their system day to day, so the complexity was somebody else's problem most of the time. The smaller government client had no such person. We were managing everything, including a monthly tape rotation that turned into an ongoing nightmare. Someone had to build an inventory of tapes, get the right cartridge into the drive, get the right one out, and log it all for offsite storage. One of our engineers was burning four to five hours a week just producing reports and coordinating tape swaps with end users who, understandably, kept grabbing the wrong tape.

We were in constant pain. Not because the product was bad, but because it was the wrong product for that environment, and the skill required to run it well never transferred properly from the vendor to my engineers. The vendor rep supporting it was genuinely good at his job. That skill just didn't land with my team the way I'd assumed it would.

Eventually we pulled it out and replaced it with a straightforward cloud based backup and disaster recovery appliance. The difference was immediate. No more tapes. No more monthly inventory battles. What used to take an engineer four to five hours a week dropped to about five minutes a day of checking that everything ran overnight. All up, we got back around fifteen hours a month that had previously gone into managing a system that was never right for that client in the first place.

The real lesson wasn't about backup software

It would be easy to read that story and think the takeaway is "cloud backup beats tape." That's true, but it misses the bigger point. The real mistake was how the decision got made in the first place.

I justified that choice using a reason that had nothing to do with the client sitting in front of me. I was solving for my own business, capability building across the team, and dressed it up as a client solution. The client needed something simple and reliable. What they got was something built for a completely different environment with completely different support structures around it.

At the time, across our client base, we were running five different backup solutions. Five different platforms to maintain, five sets of quirks to remember, five ways for something to go wrong at 2am when nobody on shift has touched that particular system in months. Eventually I standardised everything down to one type of appliance, and that decision did more for our risk profile than almost anything else we did in the business.

Here's the distinction that matters, and it's one a lot of IT leaders miss. Backing up data and being able to restore it quickly are two different problems. Plenty of solutions will happily back things up every night without complaint. The real test comes when something breaks and you need it back fast. I've seen situations where restoring meant sourcing special hardware first, which is not something you want to discover mid crisis. Standardising down to one appliance meant I could look a client in the eye and say, with total confidence, your data is backed up offsite and we can recover it within a defined number of hours. That's not a technical detail. That's the whole point of having backup in the first place.

Standard where you can, flexible where you have to be

None of this means every client needs to run identical infrastructure. Plenty of successful MSPs run genuinely bespoke tech stacks and do very well, because what they've standardised isn't the hardware, it's the framework and the way they operate. We were similar in some respects. Most of our clients had already sunk real money into on premise infrastructure, so we couldn't walk in and rip everything out on day one.

What we did have was a default. Preferred switches, preferred wireless access points, preferred firewalls, preferred backup hardware. Whenever the opportunity came up to change something, whether through natural refresh cycles or a new project, we moved that client toward our standard unless there was a genuinely good reason not to. It wasn't about forcing uniformity for its own sake. It was about knowing that every time we deviated from what we'd properly tested and understood, we were taking on risk we hadn't fully accounted for.

Where the real due diligence needs to happen

If there's one practical change I'd tell any MSP owner to make after living through that government client mess, it's this. Have the conversation with your technical leads before your sales team goes anywhere near a client with a proposed solution.

In that original example, I gave the vendor a basic list of business size details and left it there. I didn't get them to properly scope what that specific site actually needed, what the client's internal capability looked like, or how support would realistically work day to day. That gap in due diligence is what caused most of the pain that followed. It wasn't the technology. It was the process that led to choosing it.

Good IT decisions don't start with a product. They start with genuinely understanding where a business is going, what it can support internally, and what happens on the worst day, not just the average one. Get that picture clear first, and the right technology tends to become obvious. Skip it, and you end up paying for the decision twice, once to install

Connect

Clarity + Focus = Results

© 2026. All rights reserved.