You’re an Amateur Buyer, They’re a Professional Seller. How Do You Not Get Screwed Over?
Buying an IT system of any complexity is very hard. And it’s not necessarily for the reason you think. Yes, they can be hard to specify, cost, or manager, but those are more properly described as symptoms and the root cause is much more simplistic.
The underlying issue with any sort of IT systems procurement is that the sellers are professionals, whereas the buyers are amateurs.
And the risks are huge. It’s possible for even modest businesses to blow hundreds of thousands of pounds on failed or failing IT systems, and for such errors to have career-limiting impacts on the staff involved.
Coming back to this “amateur buyer” idea, as any business grows, it will build out its management team by establishing and growing a board. That board typically will have people responsibility for operations, finances, and sales/marketing, ultimately with someone sitting over them as CEO. As such, typical starter boards for a business looking at a baseline level of maturity comprises a CEO, COO, CFO, and CMO.
If that company isn’t specifically a technology business, the board initially won’t have an “IT director”-type — i.e. the chief information officer (CTO) or chief technology officer (CIO) role will be missing until much later in the business’ life.
When the business is at a scale where it has a sensible non-technical board, you start to see a mismatch where the business has to make investment in IT systems before it makes investment in IT personnel. For example, you might be a manufacturing business turning over £10m a year and need an enterprise resource planning (ERP) system to oversee that process, but you may well not have a requirement to bring on a £120k a year CIO or CTO as there isn’t enough other stuff to do in the business and all your day-to-day IT is outsourced to an MSP. You now have a major problem as you have to spend something like £250k on a computer system to run your £10m business, but you as a business don’t know how to do this because you have no specialist staff.
More specifically — you are an “amateur buyer”. You have to buy this thing in a mode where you’re trying to work out the process as you go along.
There’s an inherent unfairness here, because the seller you’re ultimately going to buy this thing from is not an amateur. They are a “professional buyer” — they’ve done this before, and have got so good at it that they’re able to convince perfectly sensible £10m turnover businesses to write them £250k cheques, and to do this with some ease.
This isn’t a piece about the obvious solution, which is that you need to add a CIO or CTO to your board. (That’s way too easy for me to say, and as I said above you may well not be able to make a justification for that.) Rather I want to talk about how you reframe this problem.
You’re ultimately going to choose a supplier to deliver this system, and we know that there isn’t a professionalised IT function within the business overseen by a C-level technical person. We can also assume that we’re in a world where the supplier isn’t going to try to intentionally rip you off — suppliers nearly always want a win-win. We want to have this project be delivered in a way that delivers good value. We want the initial price to be right, we don’t want the cost to overrun, and we don’t want the time to overrun. Time overruns can be particular insidious because it’s not the “ticking off the clock on the wall” that’s the problem — the danger of time overruns is paying people to waste time compensating for delivery failures when they have better things to do.
One issue that we do carefully want to avoid in this scenario is overreliance on the supplier. If you as a customer are amateur, and they as a supplier are professional, you want to avoid leaning into that. Through osmosis, you want to “bleed” some of that professionalism over to us and make you better buyers in a more sustainable way.
It’s very dangerous to assume that the supplier you have commissioned to do the work knows what they are doing. That may seem counterintuitive in that you obviously will have done your best to commission someone who does know what they are doing. However, any project design will come with mistakes, no matter how well that design is done. It is those mistakes that are the synthesis of project failure — i.e. any failure point in the project will always be traceable back to mistakes the original design.
In order to avoid any mistakes getting hold, there must be someone within the business who is chiefly responsible for delivery of the project. That person has to be properly resourced and trusted by the business. (That might seem obvious, but it is quite common for businesses to give IT projects to someone the business doesn’t rate that highly, even if it’s spending a *lot* of money.)
That person then needs to adopt a very specific mindset — one that is all about enquiry as to what is going on, with a measure of believing the technical team know what they are doing, but that sometimes they’re going to screw things up.
What you do not want to do is the equivalent of having a new driveway laid and just letting the contractors get on with it because you’re trusting them to do it. This tends to be a common way that delivery is done of IT systems — the supplier is left to get on with it.
Problems are only detected in that scenario either on delivery, or when the cold dread of fear starts to set in because the business is doing the equivalent of looking out of the front room window to see this two-day driveway project still isn’t done, two months have gone past and it’s nearly Christmas.
Essentially you have to foster collaborative working, where one of you (i.e. you) don’t know enough about what’s going on and need to get the other side (the supplier) to train you up. In practice this means balancing out asking “stupid” questions — remembering that some people don’t like to look like they don’t know things, so that will guide the choice in your team as to who is doing the liaison — with together with a sort of healthy mistrust. Remember, you are looking to detect mistakes before they get out of hand. Mistakes will have been made both in the original design and as execution is performed, you just have to detect them. That means both sides have to be open to the reality that there are undetected mistakes that need detecting.
If you do all that — i.e. assume you’re not working on a simple project where a trusted professional contractor can “just get on with it”, and that mistakes will have been made (which are no one’s fault) — you can balance out the amateur buyer/professional seller problem.
