Off the shelf software is faster to implement and cheaper than a bespoke system, right? Well, wrong.
There are two things to take into consideration when buying software: the direct cost to your business for implementing it, and the potential benefit to your business.
But it's also important to consider the potential downside. What if it goes wrong, and what if it doesn't work? What would you lose? How much would that cost your business?
When we speak to prospective clients, it's often the potential downsides that are front and centre, often because of a bad previous experience with software, whether off-the-shelf or bespoke. The potential uplift or benefit is often missed entirely. It's not an unhealthy approach, but it is a flawed one, particularly where bespoke software is concerned.
Bespoke software was traditionally procured by the business farming out a set of requirements off which suppliers would quote, and the cheapest won the job. The problem here is that most of the time the requirements are a set of needs based on existing systems and processes, which could be significantly different were they to be considered a different way: from the viewpoint of the user - the people who will actually use the system to enhance the business.
These days there are a growing number (including us here at Initforthe) of software consultancies who focus on building things using an Agile philosophy. The way we approach things here is to focus on the people who will ultimately use the system and work with them to develop a solution that fits their needs in their part of the business, helping management join the dots between departments or individuals. This approach by definition involves more people, but it doesn't mean that there are too many cooks. In fact, the more people in the business we can work with the better for a number of reasons:
- you get buy-in to the project sooner by more people, giving the project a much higher chance of success (it's rarely the system itself that is at fault, though bad systems are everywhere, we've found),
- you get a better picture of the processes the people in the business follow to get the job done,
- you get more input as to what could be improved and are able to make those improvements earlier in the project; and here's the bit for you commercially minded people:
- you can put more staff costs down on your R+D (Research and Development) tax claim.
We've talked to clients for years about R+D, so it's nothing new. However, it's the approach we take - the user-focused one - that allows our clients to maximise their claims at the end of the tax year. And we've got clients who are recouping almost all the direct spend they made with us through their claims.
Let's go back to that traditional way of doing things, and play out the differences. The owners/directors of the business procure a new system. Those directors most often pay themselves a small salary and top it up with a dividend because it's the most tax efficient means of moving cash from the business to the individual owners. The staff in the business are rarely involved save for a cursory "is there anything we've missed on this document?". The problem there is it's almost impossible to capture the actual processes and work on simplifying them from the top, because the top doesn't actually do them.
Worse, when it comes to an R+D claim, because you can claim 130% (at the time of writing) of staff salaries, and 65% of subcontractor costs against the corporation tax, enhancing any losses or reducing taxable profits. So those dividends are now worth diddly squat in your R+D claim, and because no one has been involved in procurement or delivery, your claim is pennies on the pound compared to what it could be if you involved your team.
Instead, let your staff take control of their aspect of the process, allowing you to benefit from their knowledge of their specific area of business (dispatch, finance, sales, repairs, or whatever the specific role is the individual does). Your team can focus then on improving their own processes to save time and reduce stress levels, both of which will have a direct positive net impact on the business profit and potential turnover.
At the end of the year, whether the project is an overall success or deemed a failure (which is highly unlikely), you're able to recoup those costs through an R+D claim, and in a large number of cases, these costs could be completely offset by your claim.
So what's to lose? You will learn about your business and its processes (and most likely simplify them), your people will feel better about working in it, and so work harder and stay for longer (your costs will drop through the floor just because you don't need to replace departing staff members), and you may (read will; our track record has delivered this 100% of the time) end up with a system that changes the game for you and puts your business head and shoulders above your competition.
And the risk? If the entire project is a failure (the Agile process mitigates against this by not trying to build the whole ship at once), you've potentially spent nothing on it, and have taken a huge amount of learning away from it, to try a different way next time.
Truth be told, it's not all sunlit uplands, and you will encounter elements of failure along the way, but if you stick to these basic principles, it's almost impossible to fail. Those failure points are really not failures at all, but tests. Some will work, and others won't quite so well, but you now know, instead of guessing at, what works and doesn't to improve your business and its processes. That's still no failure in my book, but a resounding success with its own return on investment.
You've read this far, so this probably doesn't apply to you, but if you're the kind of boss who just won't let the people in your team help you better the business, all of the above is for nothing. So in that case, don't bother starting. On the other hand, if you're the kind of boss who wants your people to thrive and to grow and to work with you to grow the business, then it's a bit of a no-brainer, don't you think?
