News headlines are grim. Ignoring the grimmest headlines of all and focusing purely on the economics, the inflation rate has fallen to 0.5% and millions of jobs are at risk as we face a recession. The Organisation for Economic Cooperation and Development (OECD) has estimated that £3,833 is the cost per person in the UK of the Coronavirus pandemic, in terms of lost output. Collectively, this amounts to £253 billion, or to put it another way, 11% of all goods and services sold in the UK.
So it seems futile for us to tell you that every penny within your business counts. Or to highlight that there will be more scrutiny that ever over where company budgets are used. There is no doubt about it, it’s time to batten down the hatches.
But then what?
Recessions are classified in letter-terms, the shape of the letter reflecting the likely economic curve. Experts have suggested that this looming recession could be a V, which means a quick decline followed swiftly by a sharp recovery. So for your businesses to be in the healthiest position possible, as we already look towards recovery, you simply can’t stop. Stop chasing the tails of competitors, stop improving customer service, stop attracting new customers and stop enabling employees.
This is where software can really help. SaaS has many uses from automating processes to allowing customers to self-serve. This means it has the power to dramatically improve output, whilst reducing the cost needed to deliver services. So it’s perhaps not surprising that Frank Della Rosa, research director for SaaS and Cloud Software at IDC is seeing companies look to SaaS to help them at this rocky time.
So if you’ve identified a need or an opportunity for new software within your business, either before or as a result of the Covid-19 pandemic, we urge you not to put this on hold. Instead, think about how you can deliver it as cost-effectively as possible. How can you make sure you see a return on investment in the shortest amount of time? How you can limit risk? Because evidence suggests that if you can continue to develop at this time, then you’ll be in a much stronger position once we’re out of the, predicted to be short, recession. Widening the gap between yourself and the competition.
We at ACS, have been running software development projects for eleven years for a huge variety of clients in industries ranging from healthcare to sports. We’ve also worked with businesses of all shapes and sizes from dynamic start-ups to enterprises. But at their core, across this kaleidoscope of projects, there are the same crucial steps that you can take to ensure your project is as cost-effective as possible. This report shares these key steps in detail because we understand the pressures of undertaking a software development project in the current climate, it’s never been more important to get it right first time. Some steps might seem obvious, but read on because we find a lot of people think they’re covering these steps, but in reality they’re looking at it from the wrong angle.
Have a clear, documented and inclusive goal
It feels a little cliched saying this, how do you know what success looks like if you don’t know what you want to achieve etc etc, we’ve all heard it before. But the reason it’s a cliche is because it’s so true, yet still so often overlooked. Or if not overlooked, it’s driven by one team or department and opportunities elsewhere are missed.
Often software developments touch many different departments. It’s important that you work closely with all key stakeholders to ensure a design that will meet everyone’s requirements in the immediate and longer-term. But, and this is the step that’s often missed, we also recommend you speak to departments that you may not think are going to be impacted by the project. When we first start scoping a project with a client, there are often quick wins that have never been considered. Perhaps functionality is being designed for one department and could easily be applied to another to bring enormous benefit…but they’ve simply never had the conversation. Sometimes it takes an ex-ternal partner to see this, but by far the most cost-effective projects are the ones that consider eve-ryone from the very start, looking at the whole business to weave in multiple cross-department wins.
Even when there aren’t wins per say, the information that departments, teams or even individual people hold can often vastly improve areas of the design. For example it’s easy to think customer service know everything about the customer, but speaking to marketing, sales and even finance can bring a different perspective to create a much fuller picture.
Having buy-in across the company also prevents any bottle necks or delays down-the-line. Nothing will waste more time, or blow your budget quicker, than batting things that should have been decided in the beginning back and forth between departments during the project. So once you have your vision, you need to document it so everyone involved has a reference point that they can refer back to.
And in this document, bring your goals down from the sky to set realistic and calculated measurements. How will you measure success? Be this financial, reduced time and admin, more customers or happier customers. You need to understand these measurements to track ROI. You also need to know the bare minimum of what needs to be achieved in order to at least break even. And ROI shouldn't only be considered if you are using an external partner, if you have an internal team working on this, their time is still money.
Having this clear, documented goal, with details on what the software must achieve as a bare minimum and what you would like it to achieve on top of this, will help you get a much clearer and more honest estimate if you’re looking to use an external partner to deliver it. They could even break their quote into essentials and extras and you can deliver the work to this structure.
Our final piece of advice in this section is something we touched upon earlier. It’s imperative that you consider immediate needs as well as longer-term needs if you want your project to be at all cost-effective. It is always more expensive to add things on then to consider them from the start, assuming they can be added and you don’t have to start again! But understand that technology changes quickly, so your goal needs to allow for this. You need to plan for the unknown e.g. how easily can whatever you produce be expanded upon or integrated into something else down the line? Your lead software developer, either internal or external, should be able to offer valuable advice on this. Consider this now, and you can build something that allows updates and expansion more easily later on. even if it’s years later. This can make a big difference to the Total Cost of Ownership (TCO) on large projects.
Choose the right development team
IBM list their number one credential for successful software development projects as “Recruit skilled and experienced people.” Which won’t be mind-blowing to anyone, you’d expect this right? Yet this is still so often overlooked. People either verge towards availability over experience or they hire a team without knowing who’s actually going to be doing the work. And how do you know who the best people for your project are anyway? And should they be in-house or an external team?
Sometimes there is no option but to use an external partner but even if you have a strong in-house team, using the right external partner can have many benefits.
- Experience of similar projects (please note that when it comes to software, industry experience isn’t as relevant as software experience.)
- Specialist experience
- An objectivity that can’t be achieved in-house.
- Reduced risk
- Up-skilling your in-house team
- Saving you money
Saving you money? Yes. If your project is going to make a significant difference within your business, then the better the quality, and the sooner you can get it live better, as you can start to enjoy that ROI.
If you work with an experienced external partner your project should be delivered significantly quicker. Even if you have a very experienced in-house team, they’re likely to have their day-to-day work to complete on top of the project. We’ve had clients approach us midway through a project because it’s either proved too challenging for their in-house team or it’s simply taking up too much of their time, causing it to drag on and disrupting business as usual. This is not a cost effective way to run your project as you repeat phases, you waste time on-boarding a new partner and you miss out on the value they could have added from the start. Plus if your team have really grappled with the project before handing it over, then lots of their time has been wasted. An external partner should set milestones and deadlines in the initial stage so you’ll have a roadmap to hold them accountable to and your project will retain focus and drive.
But of course the above assumes you choose the right partner. We appreciate this isn't easy and can feel quite daunting. Especially given choosing the right partner is likely to have the biggest impact on the cost effectiveness of your project.
So where do you start?
Most people start in the sensible place of case studies. Find out if they have happy customers and if their previous project have been successful. Alarm bells should ring if their case studies don’t mention any metrics. But we recommend you also ask if you can speak to previous clients. What’s on the website was written by the team but speaking to clients will give you the real inside scoop.
Next, what’s their technical experience? Do they use trusted technologies such as Microsoft and are they proficient in a number of areas?
Do they have solid, proven processes? An ISO 9001 certificate will let you know that they have had their processes audited by an official global body. It’s essentially a big tick that they’ll follow a quality formal process and have a healthy aversion to risk. It also covers areas such as data protection and how robust their business is.
And when you’re actually speaking to companies you need to ask yourself:
- Do they ask the right questions and provide fresh approaches?
- Do they understand our business?
- What’s their attitude to risk?
- Do we get along and could I work with them?
- Who specifically within their business will be leading the project and what happens if they leave? Make sure you’re not sold the dream by the director, for their most junior team member to do the work with little or no input from the senior team.
- How much does my project mean to them? This is especially important if they’re a big firm.
Of course, there’s also the small matter of costs, but this shouldn't be the main driver as getting it right first time will ultimately save you a lot of money in the long run. But yes of course, what do they charge?
A final note on choosing a partner, make sure they use appropriate, open, standards-compliant code. Then you’re not locked in to using them forever as whatever they produce is entirely yours to do with as you please. Of course you hope it doesn’t come to that, as retaining a good software development team for servicing and any future projects saves a great deal of on-boarding time. And hey, if they’re good, like a good plumber, you don’t want to lose them! But make sure you have this option to leave if you wish.
Understand how your software development team work
If you’re working with a partner it can be very tempting to hand over your project and step away from any kind of detail. But you should understand the basics of how your development team plan to de-liver your project. How and when will things be tested? How will they limit risk? When is user experi-ence carried out? When will you see work? Who specifically is working on your project? Is it one person or a team?
With the wrong answers to the above you could wait months then be delivered something completely unusable. This is when projects don’t become less cost-effective, they become financially disastrous. Even if you’re paying a fixed price, delayed projects prevent you from seeing the ROI sooner and the way a project is delivered will hugely impact quality.
Below, I’ve outlined the basics of our development process at ACS, simply to show how this process can really impact the cost effectiveness and quality of a project. We’re not saying every project has to be delivered like this, but it is crucial that you’re not having huge chunks of work without seeing anything, or any testing. And if your team can work in short spurts, they remain agile and can pivot and shape the project with very little waste. Without this, your budget is very likely to skyrocket and you won’t know until it’s too late.
We start all projects with a workshop to understand requirements, from this, we map out what the project is likely to look like, and use our experience to make recommendations on where our client can deliver it more effectively, or make quick wins.
Once we have a clear idea on what is to be achieved, we carry out rapid prototyping to deliver a working prototype that the client can use, test, explore and feedback on. This is an explorative phase for us and working this way prevents long, expensive period of development where things either don’t work or aren't suitable. And the client, very quickly, has something that will give them a much clearer picture on the look, design and functionality.
Before we do any work, we give set costs for the prototype and an indication of what the entire project is likely to cost. Costs for the whole project can’t be fixed until the prototype has been made as it’s impossible to know the scope and complexity of work required. But we recommend you always get an estimate for the whole project before you spend a penny. Otherwise, you could be left with a prototype and no budget to deliver the rest.
From the prototype, we can give a fixed cost for the project. We also share exact timescales with milestones and phases, our roadmap for delivery and roles and responsibilities. And we highlight any risk areas, or missing elements and we produce a Project Backlog. This Project Backlog contains all the features that are to be built, in priority order. We can’t stress enough the importance of the Project Backlog, you must make sure you see one and have the chance to input into it. This is basically the scope of the project, and without it you could be left with gaping holes in your software.
The reason these features are prioritised is, we work through these in order to get to a Minimal Viable Product (MVP) as quickly as possible, so clients don’t have to wait for everything to be completed before they can start using the software in a live environment, so they start benefiting asap. An added benefit, is that, god forbid, you run out of budget, then all the important features will be built first.
In terms of how we work through these features, we work in two to four week sprints. This means we pick the feature or features that we’re going to work on in that chunk of time. At the end we use, test (both manually and automatically) and refine. This way of working is very agile and flexible and means that the project is continually being tested and the work is only ever a short period ion time ahead of what the client can see. This is an extremely efficient and risk averse way to run a project as issues are immediately evident and solved. Plus, as the client, you’re always in the loop with work developed and you can see, use and test it yourselves.
Understand how your budget is being spent and work out an appropriate payment plan
This ties in with the above, if you know when the phases, milestones or even sprints are within your project then this should give you an indication of when you should pay. The more you can align your payments to these key dates, the more profitable your project will be because you’re paying for work that’s been done, tested, quality controlled and is yours to own in completion.
If you pay 50% upfront then 50% at the end for example, then the first half of the project is very risky, and you may the most complicated build elements are all at the beginning. Then you’ve paid for work that’s far in advance and have no idea what that work will look like. Plus, a lot can happen in your business, or your development partner’s business over the period of a larger project. If you pay in short bursts, then should the project fail to meet completion for a multitude of reasons, you still have all the work you’ve paid for and you can take this elsewhere if you need to.
You may be familiar with the accounting practise of revenue recognition, where you only recognise work that you have completed in each month’s profit and loss reports. Well think of this as not only recognising work that has been done, but only paying for work that has been done.
Up-skill your team for free
We understand that not all companies choose to use an external partner because they don’t have an in-house team. They may use an external company to save time or perhaps because the in-house team are too busy with their day-to-day work. But more often than not people come to us because they need more specialist experience then their in-house team can offer. If this is your scenario then this presents a great opportunity to up-skill your internal team for free.
You’ve hopefully chosen a partner that you get along with, so they shouldn’t mind working with your in-house team to increase their knowledge. Ask how involved your team can be. Can they ask questions? Can they perhaps spend a day a week in your development partners office? This is essentially free training and we recommend that you really push this from the start.
Plus, the more your team learn about the project build, then the more valuable an asset they’ll be once the new software is live as they can limit the amount of external support needed post-launch.
Continually refer to you goal to check you’re on-track
No matter how meticulously planned your project is, there’s likely to be a few surprises. Any developer telling you they know exactly how the project will play out, is either telling porkies, or isn’t deeply considering your business and your unique needs. They may be assuming your project will be cookie cutter version of one they’ve already developed. These surprises have the ability to cause no issues, move things in a slightly different direction or completely morph your project. So it’s safe to say they can carry a degree of risk. After all, surprises are by their very nature unexpected. But the amount of risk they pose is somewhat down to you and your chosen development team.
An experienced software developer should be able to offer invaluable guidance, from a development perspective when something unexpected happens and you have to veer slightly off course, or take a different approach. But, coming full circle to our first step in this guide, this is where your goals document becomes invaluable. Between you and your development team you need to be looking in black and white at what you set out to achieve. Your goals document outlines this, so it will help you make these directional decisions in a measured way. You can look at your goals and measurements (remember ROI might not be just financial) to anticipate how each of the options available to you will impact this and therefore, the project’s success. This can save vast amounts of money once the project is completed, as there’s no backtracking or adding to the piece in a clunky way when you realise it’s radically changed direction and doesn’t fit your basic needs.
And we urge you not to only do this when there are potential hiccups or unexpected paths to choose from. If you continually look at your goal, against where the software is headed, then you always have a clear picture on how closely the two are aligned. It might not be possible to track return on investment until your project is live and perhaps even some time after that, but your project will be more cost effective if you evaluate anticipated ROI throughout. This is another benefit of working in sprints. Short sharp bursts give you time to test, measure and reflect, it’s a great way to keep the project and goals aligned.
Note from Craig Morrall, Co-Founder of ACS
I hope this guide has given you some food for thought and perhaps even the confidence to take the plunge with your desired software project. The truth is, if you’ve identified a need or opportunity, then in all likelihood you’ll see real benefits from implementing it. It’s very rare that someone conceives software for the sake of it, it’s usually born out of a genuine and pretty sizeable opportunity to work smarter and/or retain and attract more customers.
But I also understand it is a scary time to undertake any new, potentially expensive, business change. Most companies suffer through for some time before making the plunge. So if you want to talk through your project, with absolutely no sales pressure whatsoever, just for a second opinion and perhaps some clarity and direction, then please do get in touch. It’s about helping each other out for the sake of the industry at the moment so I’m more than happy to talk.
And of course, the very best of luck with your project.
Craig Morrall, Co-Founder ACS
A quick tip before we go. To complement your development project, Microsoft Power BI is a deeply advanced reporting tool that pulls together information from disparate systems to help you gain a complete picture and understand, with fact, where your business should be headed. The specific reporting metrics are tailored to your needs, but it’s the only system that enables you to see what’s going on within your business, whist providing a benchmark against what’s going on externally in the wider market place. You'll understand how to target your most lucrative customers, how you can capitalise on opportunities and future proof your business, where trends are headed and when you might saturate your current market or specific locations. As we all pivot to stay afloat never has this data been more crucial. Make sure you pivot in the right direction. Talk to us about Microsoft Power BI. We’ve successfully implemented the reporting software across a number of businesses and we offer a FREE consultation including a workshop, to help you understand how Microsoft Power BI can really help you.