Creating custom software can be extremely complex—juggling evolving technologies, competing stakeholders, many types of users, etc. And that makes it risky, both for the company that funds the project and for the consultant who stakes their reputation on it.
In the modern Western world, we turn to software as the solution to most business problems — and rightly so. Software can be a fantastic tool to bring efficiency, consistency, and predictability to business processes.
However, I often see business leaders misunderstanding what technology can and can’t do for them. They look at the tough problems in their organization and assume that sprinkling on some technological magic will bring solutions. Although technology (and, by extension, software) is a fantastic tool, it isn’t a panacea.
Technology is a high-risk, high-reward option. Many thousands of technology companies and startups go out of business every year across the world. The risk of failure on any software or technology project is very real.
To help you avoid following suit, I’d like to share some areas of risk and some mitigation strategies that help to minimize those risks.
The key to succeeding in this arena is mitigating existing risk. There are many reasons a software or technology project can fail, but they all come down to feasibility, viability, and desirability.
Is the project technically feasible? Is it even possible to do what is necessary? Do the technology and data exist in a way that allows the project to move forward?
Many times, we see business stakeholders who are disconnected from the technical reality of their internal systems. They haven’t investigated thoroughly to see if what they want to do can be done. Sometimes, they don’t have internal personnel who have the necessary breadth and depth of experience to advise them.
New technology solutions that deliver value are often very expensive to implement. Will yours create enough return to justify the investment? Will it be financially viable?
We speak to more than 300 new companies every year who are looking for technical solutions to business problems. It’s surprising how many haven’t calculated what ROI they need to make a risky, expensive software venture worthwhile. This is essential work that must be done for a project to find success.
If a technical solution for a problem could be developed efficiently, but no one wanted to use it, it would have no value. Each technology project must find the intersection of business value and human interest.
Even enterprise solutions (whose users have no choice) need to worry about desirability. If people aren’t happy, they will find a better solution. As soon as humans aren’t interested in using a solution, that solution is now a target for market disruption.
There are many ways to mitigate these risks. Some of them are obvious, and some are specific to each business environment.
An easy and, perhaps, non-obvious mitigation strategy is to not use technology at all. I’ve seen many businesses try to use technology to solve a people problem. The inefficiencies in their business process were actually being introduced by inefficient, disengaged people.
In that situation, the cheapest and least risky solution is to solve the people problem directly. Leaders should be immediately empowered to find a people-focused solution.
Another way to mitigate these risks is to use off-the-shelf (OTS) technology. This is a great medium-term solution because you avoid the large capital expense of a novel invention and get most of what you need from an existing product. Someone else has already absorbed most of the risk by building the system and offering it to the market.
Using OTS tech will come with some compromises in your business processes, but in exchange, you get financial predictability. You know how much the solution costs to use, and you can incorporate that cost into your business plan and account for it with a high degree of reliability.
For example, you could use an OTS accounting system like Quickbooks instead of creating your own system from scratch. Quickbooks would cost you a monthly fee forever, but the cost is so low (compared to creating a new, custom accounting system) that it makes sense, over the medium term, to use the existing solution.
There are times when the ROI on new technology is adequate; building something new is financially viable. In these situations, you also want to make sure you build just enough technology to meet your needs — not more. Don’t fall in love with the idea of technology. Fall in love with what it can do for your business when used correctly.
You also need to be sure that you have the right team — one made up of proactive problem solvers who are experts in their field. They’ll make sure you don’t fail because of technical or human interest reasons. They’ll want to prove themselves a reliable ally and actually minimize the amount of technology used to accomplish your goals.
I saw a great example of this concept in the movie Ford v. Ferrari. It’s 1965, and a racing team sponsored by the Ford Motor Company is building a new car to race in the famed 24 Hours of Le Mans. They’re hoping to beat arch-rival Ferrari, the perennial champions.
During development, Ford engineers install sensors and a massive computer in the test cars to understand airflow and drag across the body of the car. They’re using technology to solve a problem, and they estimate it will take several weeks of test runs to gather enough data.
The racing team quickly gets fed up with the computer (extra weight) and the cables running to sensors on the car (impeding usability) and rip it all out. Instead, they tape short pieces of yarn all over the car to show how air is moving across the car as it circles the test track. Using their own expertise and smarts, they find the car’s design flaws in only a day. The Ford GT40 MkII goes on to place first, second, and third at the 1966 running of Le Mans.
Business leaders need to use technology in the right way at the right time, and they also need the right team to build and support it. Imagine if that racing team hadn’t had the right team of people to eyeball the yarn displaying airflow and drag on the Ford GT. They would never have created the solution they needed to win.
At Atomic, we aren’t in love with technology. We are in love with leveraging the right amount of technology to solve problems that result in business success. As part of our sales process, we will tell you if we believe you don’t need technology. We will point you toward an OTS solution if we believe it represents better value to your organization than custom software.
If it turns out that you really do need custom software, we’ll deploy a smart, curious team of experts on your project very akin to that racing team. They will make you aware of the feasibility and desirability risks associated with your technology project. They’ll come up with solutions to mitigate those risks. They’ll find ways to use less technology if it means the need can be met another way. (If that means ripping the computer out and replacing it with yarn and tape, they’ll do that too.)
At the end of the day, you can’t eliminate all risk, but Atomic works hard to mitigate it before a project even begins. We’ve been making custom software for almost 20 years, and we’ve observed a few patterns—a set of variables that either introduce risk or put a project on the path to success.
These observations have grown into our Common Project Considerations Worksheet, which we share with all prospective clients during our Pre-project Consulting phase (think “sales process,” but with more good advice).
Working through this worksheet with clients is a very powerful exercise. It reveals risk, helps us understand the client’s situation, and empowers us to start addressing potential problems—together.
When the client team is new to making software, it adds risk for miscommunication, confusion about responsibilities, etc. We can address this by helping the team learn and by tailoring our communication to their situation.
A successful project needs an experienced product manager, and reliable software needs someone in-house to maintain it. We can address this by sharing the product management responsibilities, and if necessary, helping them find additional team members.
Some languages are easier and cheaper to build with than others. Often, mature technologies have more resources and tools we can leverage to make development go faster, while obscure or cutting-edge technologies will require more effort for the same results. Identifying this risk early can help frame conversations about technology choice or build in a buffer for development.
Regulations such as HIPAA (for medical industry projects in the US), GDPR (for EU products), PCI Compliance (for credit card processing), or CE Certification can introduce extra considerations for user experience design, data storage, and development practices. It’s important to be aware of these early and discuss their impact on the project.
When we have control over the server and hosting environments for the applications we build, deployment is typically quick and easy. For our enterprise clients, deployment often involves working with their IT team in order to set up an environment, then following their deployment process when it’s time to release. It’s important to get IT involved early and add a buffer for the time it will take to coordinate with them.
When it comes to project stakeholders, having too many complicates things. One decision owner is ideal. When a large number of people need to be kept in the loop, we look to staff our project team with adequate support from a delivery lead in order to keep the conversations moving forward and keep the development team unblocked.
Any time one software application needs to send data to another software application, it introduces complexity for both applications. If the other application is a commercially available project with a documented API, the risk might not be very big. But if we need to integrate with another custom-developed system, it can be very costly and complex.
Every software project is a security concern. It seems like every day, another company is announcing a hack or a data breach. At Atomic Object, we have a security policy, and we strive to follow best practices for security for all projects.
However, some apps have more risk of being hacked than others. For applications that are at high risk, we will work with our customers on a security test plan that makes sense for the project (for example, engaging a third-party company to do security testing on the code we write).
Projects that span multiple platforms (for example, a wearable Bluetooth device that syncs with a phone and sends data to a cloud backend) are inherently more complex than single-platform projects. It’s important to discuss this aspect of the project and adjust estimates accordingly.
Importing data from an old system is typically costly—depending on what state the data is in, it can take several days to a few weeks. If the systems will run in parallel for any amount of time, the import gets even more complex.
If your business is incapable of functioning without the application we are building, and no fallback mechanisms exist, this will impose certain constraints and extra precautions around release planning, deployment, and technology choice.
While good software is never done (we find that there are always more features to be built and honed), some projects are very well-defined and tightly scoped, while others are more nebulous. If we expect hidden requirements, it’s important to build a buffer into the budget or stay laser-focused on release targets and save new ideas for future rounds of work on the product.
Nobody wants to invest significant money into a software project, only to discover that nobody wanted the thing in the first place. If we have concerns about product-market fit, we may suggest to our clients a smaller Research, Design, & Planning engagement to hone their product and validate product-market fit before moving forward.
If the product-market fit is validated, artifacts from the RDP engagement will directly inform how the app is built. If it’s not validated, we can continue iterating until we find a fit, or until the client decides that the idea isn’t worth pursuing anymore.
We believe our clients’ success is our success. Therefore, we don’t want them to spend time, energy, and money on projects that won’t bring value and contribute to their success. If we have concerns about a project’s value to the organization, we share them openly. This allows our client to address our fears head-on or reassess whether or not they want to do the project.
Reviewing common project considerations with our clients during the sales process helps drive alignment, expose potential risks and challenges, and take steps to mitigate them early on, before the project is even started.
We’ll send our latest tips, learnings, and case studies from the Atomic braintrust on a monthly basis.
