Functions and compromise
In many cases - you want to fulfil a generic business function such as payroll or OCR or anti-virus, for example - there’s already an app (or thousands of apps) for that. But often these involve compromise.
Your chosen off-the-shelf payroll system may not be able to cope with the complexities of the multi-tiered, service length multiplied by previous quarter’s performance divided by peer review percentage algorithm that you decided was the fairest way to apportion bonuses oh so many years ago. You may be able to force your processes to fit around the tools you’ve chosen, and often this will be a compromise that you can live with.
Delivering user benefits
But what about when start thinking about investing in a piece of software that needs to deliver real user benefits? Whether these users are your customers, and you want to give them a great experience, or your staff that you want to make more efficient, in these cases it’s not going to benefit you to shape them around the software.
So it’s at this point you’ll want to start doing things like finding out requirements, and when you start going down the requirements route you’re most likely getting into building bespoke software. You may find something already on the market that ticks most of the boxes, but they’ll almost certainly be some knocking of edges off, whether through incremental compromises or large ticket prices.
Bespoke software partners
If you chose a partner that’s able to invest in getting to know your organisation you can take advantage of their experience in terms of design and domain knowledge. They should take responsibility for understanding your unique business needs, taking your requirements and translating these into a specific piece of software for you, so you know that what gets delivered will solve your problems and maximise user benefits, which will hopefully turn into company benefits.
Of course, this approach is likely to have greater initial costs than off-the-shelf, but you’ve got to remember that with these kinds of existing products you’re usually paying for lots and lots of features you don’t need, support areas you’ll never use, and the profits of a producer who may have a “timeboxed" profit window.
Commercial off-the-shelf products are built to maximise their profitability before competition overtakes it, meaning that their focus isn’t always on long-term scalability or reacting to changing market conditions.
While a bespoke software partner is also going to be profit-driven (unless they’re exceptionally altruistic), in these situations profit is derived from the longevity of the relationship. At Box UK our Agile way of working supports this - the way we work means that even if your requirements change during the build, they be addressed and built in to the production schedule. This helps minimise waste, and we won’t slip because we’ve gone too far down a cul-de-sac.
Closely related to these considerations is that of control. If you consider the lifecycle of a software product, first there is the seed which responds to a market demand.
Then follows market research and other feasibility exercises, before the solution begins to be planned and designed (hopefully using an iterative development methodology that reduces time to market through a minimum viable product that can be improved and extended with further releases). Then what? IPO? Acquisition? Decommission?
It may seem like years away, but software that is static is heading towards joining all decommissioned software on the scrapheap. To be valuable to businesses, suppliers need to adapt their solutions to a changing world, as clients become thinner, primary screens become smaller, user input becomes touch, consumers become more sophisticated, etc.
Of course, it would be generalising to say that all off-the-shelf products are static – look at the version histories of Microsoft Word, Adobe PhotoShop, Symantec Norton Anti-Virus, which are continuously changing and reacting.
But when was a feature you, or your users, requested implemented in any of these products? (Note to advertising agency Crispin Porter and Bogusky: Windows 7 was their idea? I don’t believe you.)
If you can think of a request that was implemented then it’s probably either a massive coincidence, or I’ll wager that a different compromise was absorbed simultaneously. And what if your provider decides to change the direction of the product, or remove support for your version? Depending on how important a role that piece of software plays in your organisation, it could cause massive problems.
If you go bespoke you’re in charge of the roadmap - you make decisions about what goes on there, how it should be extended or updated, and when and if it should be deprecated. What you’ve got is a base to start with that you can build on - and you can do that very cost-effectively if you plan it in time.
At Box UK we build products. And we write bespoke software. And we create bespoke functionality on top of products. Are we conflicted? Not at all. The right solution may be on the shelves of Best Buy or it may be in the head of our team. It depends on what function the solution needs to fulfil, how far you’re prepared to compromise, and how integral it is to your business processes.
If you are going to go with something that’s pre-written, make sure that you work with a supplier that gives you a direct line into that roadmap. You don’t want to be the millionth customer (there’s no prizes), but being customer number 10 is a good place to be, because you’ve got a product that works but also have a voice and are big enough to affect change.
If you want a solution that delivers value, rather than simply enabling a process, a dedicated software partner can deliver this. However, choosing the correct company is still a fundamental element of success - they need to have the experience, commitment and approach that best fits with your organisation and be able to sustain a long-term relationship.