Addressing 13 Types of Custom Software Risk

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 who funds the project and for the consultant who stakes their reputation on it.

You can’t eliminate this 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.

1. Organizational Software Development Experience/Capabilities

Is the client’s team familiar with the software development process?

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.

Do they have experience planning releases and supporting software products after they’re built, or will they need to hire people to do this?

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.

2. Legacy or Immature Technologies (Lack of Tooling Power)

Will we be required to write this application using particular programming languages? What other applications will it have to interact with, and what languages do those applications use?

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.

3. Regulatory Requirements

Are there regulations regarding any part of the end product?

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.

4. Complex and/or Regulated Deployment Process

Where will the final product live? How will people access it?

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.

5. Number & Alignment of Project Stakeholders

How many people/departments have a stake in this project? Do they all agree on its goals and features?

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.

6. Integrations with External Systems

Will this product share data and/or integrate with other software systems?

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.

7. Security Concerns

What data has to be secured? What are the security threats to that data?

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).

8. Number of Technology Domains

How many platforms will be involved (e.g. web, mobile, desktop, embedded)?

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.

9. Data Migration Needs

Will we have to import data from a previous version of software? Do the new system and the old system have to run at the same time?

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.

10. Criticality to Business Operations

How important is this software (and the software it’s replacing) to the day-to-day running of your business?

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.

11. Potential for Hidden/Emerging Requirements

How well do you understand what the software needs to accomplish to satisfy your different types of users?

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.

12. Product-Market Fit

How well do you understand the market for this 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.

13. Value of Project to Organization

What kind of value will this bring to your company?

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.