Software is going to be a huge part of your business in the future and if it already is, you can squeeze far greater returns. How? By knowing what to learn about and what to safely leave to one side.
Here’s what every CEO, MD, or business manager needs to ask about software development:
1. What value can my business genuinely expect to get out of the software?
There’s really only a couple of reasons for bothering with a software investment, and both of them are completely quantifiable in any currency:
-
- To save costs by improving the efficiency and performance of a business process
- To make more revenue by better engaging customers
It’s important to be really clear on which it is and precisely where you see software fitting in your business strategy. Once you’ve done that, you can crunch these numbers into a business case against the whole-life costs of developing and operating the software.
Many other leading businesses have been down the same path, investing to realise their business objectives and finding some unexpected benefits. Discover some of their stories here.
2. When is it better to buy software off-the-shelf vs. getting it developed especially for my business?
In some instances there won’t actually be a choice; the software you need simply doesn’t exist and you’re going to have to get it built.
But, in reality, it’s never as clear as that. That’s because considering any off-the-shelf software product for any purpose means entertaining some kind of compromise. Some compromises will be worth it, while others will not.
You work this all out by:
- Looking really closely at what it is you want, and the benefits you expect to achieve. Put a value on it.
- Getting the prices in front of you. Not just for obtaining the software, but for having all your users licensed (bespoke software of course doesn’t have the same per-user licensing considerations) over a long period of time, hosted and supported in a suitable environment, etc.
- Understanding how much of an off-the-shelf product you’re actually going to get value from. 10%? 50%? Note that the percentage value for a bespoke just-for-you software product will, by its very definition, be 100%.
- Considering the truth of how long it will take to get your hands on this software. A bespoke software development project obviously takes some time to develop, but don’t assume that ‘off-the-shelf’ literally means you can buy it off the shelf and install it. Inevitable systems integration, user training and infrastructure considerations often mean off-the-shelf implementations take longer.
- Coming to terms with the fact that people who make off-the-shelf software aren’t duty-bound to develop new features that benefit your needs in the future, let alone to continue supporting the product ad infinitum. In fact, if anything, they stand to lose by focusing on your individual needs; their commercial motivation comes instead from satisfying the largest possible cohort of customers (i.e. all of your competitors) with the smallest set of commonly desired features.
Decisions, decisions… this resource about choosing the right software approach for your company should help you weigh the pros and cons of your own situation in minutes.
3. How do I get across to technical software development nerds what I actually want this software to do for my business, when I’m not all that sure myself?
Writing a software brief… it’s like ordering sushi: even if you’ve done it before, you can still do it better. But if it’s your first time, you could feel completely lost in an alien world.
- Remember why you’re doing this. It’s all about the big picture; the big idea. You want to save money or make revenue, or possibly even both. Something has brought you to the point of seeing software as the answer. It’s OK to just tell that story and let the non-technical, not-very-software-related vision come out.
- Ignore the jargon. Who cares if you can’t tell your Apache from your Agile, or your Kanban from your Bootstrap? It’s baggage, a nice-to-have.
- Put lots of detail about your business objectives in there. Your tender / ITT / RFP should be at least 90% to do with the business plan, your goals, intended users and ROI projections, etc.
- The best technical detail you could provide would be a rundown of existing systems and processes.
- Be clear about who the software is for, and how they can be engaged in the software development process. It’s unlikely that you are who this is for, so – to a certain extent – you have to prepare yourself to get out of the way and let the process embrace the people that really are.
Download our new guide on writing a software brief to get practical hints and tips on confidently getting your software project off the ground.
4. Who do I choose to do this software development work when they all look pretty much the same?
You could do worse than to trust your instincts. No really…
That’s because you are buying people and not ‘technology’ whenever you commission software. Therefore finding the right supplier is a very human process so – assuming you are a human – you should listen to what your gut tells you.
This will actually make or break your project. You need to find the right people who you can work with on a very involved, fluid and strategically valuable software development process. And you need to reward them appropriately.
- Do your research on applicable software development companies. Ask around for recommendations.
- Do some background digging on their financial stability, client history, etc. Look for warning signs.
- Keep a big spreadsheet with loads of information about them. A lot of legwork can be done by someone junior with a clear brief on the criteria you have (turnover, number of employees, time established, credit score, legal actions).
- Check LinkedIn, Google, every last page of their website. Follow them on social media.
- Find out about their clients, ask to speak to their clients.
- Check out their policies on data disclosure, intellectual property and other legal policies so you can have peace of mind.
- This can be boring and tempting to overlook, but it’s worth it. Get as much done as possible before you even go and meet them…
- Meet as many people as possible and look them all in the eye.
- Be encouraged by their curiosity, questioning and challenging. Reject ones that just agree with you all the time.
- Give some thought to where they are located and how important is really is that they are only 15 minutes down the road. If it’s a company you love, and they are based 150 miles away, you’ll make it work.
Check out illumo digital’s software development manifesto to see what makes us tick.
5. How can I tell if – underneath the positive exterior – everything inside my software project is about to descend into chaos?
Software development nightmares happen all too often. Business meets software developer. Software developer proposes project. Business agrees. Project starts. Fast forward 12 months and the project still isn’t finished, the business is suffering, the users think the software stinks, the initial budget has quadrupled, and both parties are due in court because of a legal dispute…
But, by then, it’s too late. Here are some telltale signs that your software project is turning into a complete disaster area.
- There are disagreements about money between you and your software development provider.
- The key people who were involved at the start of the project have suddenly gone quiet or disappeared entirely.
- Your own people don’t like the software as much as you do.
- You know it will utterly paralyse your business if you decide to change developer mid-project.
- The vision has been forgotten and it doesn’t look like anybody is bringing the requisite technology leadership.
We’ve seen many accident zones in our time, in our self-styled role as the UK’s project rescue emergency service. Read up on this software project rescue guide to avoid the pitfalls and carry out rapid repairs.
Don’t be inhibited by anxiety or naivety
You’re the expert in what your business is, and what it aspires to be through software. The trick is to apply all that to the software development process because it’s lost without it.
There is certainly no such thing as a stupid question, at the outset or throughout any stage of the software development process.
Whatever level of technical software knowledge you have is going to plenty. Your experience should be a reassuring one, where you feel taken care of rather than trying to keep up during the process. It’s not your job to know about software, but it is your job to be thorough and responsive.
