Seven Ways to Reduce Your Software Development Risk

Great potential comes with great risk.

Custom software is an amazing, powerful option to make your business more efficient and capable and to offer your customers power and novel ways to engage with you which bring them enormous value. However, a custom software project is an expensive and risky undertaking and a badly failed custom software project can end up producing nothing of value at great expense. Here are seven simple ways to reduce risk on a custom software project and make sure you end up with a viable, positive outcome.

1. Embrace the Unknown: Agility

A typical custom software project starts with an idea and maybe some requirements or an older system you want to upgrade and enhance. However, unless you have spent an enormous amount of time refining the requirements — probably more than a third of the final cost of the software — you don’t have a complete picture of what you want the software to be that you can hand off to a development team and forget.

The best way to deal with this problem is not to try and spend the effort to lock the project down on day one, but to embrace change in what is called an agile development process. That means embracing a process of taking small steps, learning from your progress so far and refining and changing project scope, budget and schedule to get the best outcome you can.

How it reduces risk:

Starting a custom software project with the idea you have an accurate, final picture of the features, cost and schedule of the project is not an honest view. By embracing this fact, you avoid locking into a process that can’t create an optimal outcome because it starts from a false assumption. By being willing to learn about your project as you go and use what you learn to refine the direction of your project you will typically get a much, much better final result.

2. Take Small Bites: Minimum Viable Product

As you start your project, consider what the minimum viable product that you can put in user’s hands is. That means picking out the least expensive useful set of features you can give to users. That isn’t necessarily a simple thing to pick out, but spending the time to carefully select a minimum viable product is well worth the effort.

You may even decide you have several levels of “minimum viable product”: perhaps a first level that you can give to internal users for feedback, a second level for a small group of trusted external users and a final wide beta product.

How it reduces risk:

Getting real-world feedback early means you have an opportunity to measure real response to your software and change the focus of your project or even cancel it if needed when you’ve only spent a small portion of the final project cost.

3. Identify and Address Technical Risks Early.

The reason you’ve decided on a custom software solution probably includes a desire to do something in a novel way or with a novel combination of elements. Aspects of these will probably include areas which present an unusual technical challenge and some undertainty of the viability, performance or capabilities of the resulting software.

Work with your development team to identify and address these early in the project. This may require research, design work or running proof-of-concept code to demonstrate there is a vialbe solution available.

How it reduces risk:

By verifying early that technical challenges are solvable, you greatly reduce the risk of large failures late in the project when you’ve made a large investment.

4. Make Sure Communication is Happening.

Effective communication among all the members and stakeholders for a software project is a must. An outsourced software project isn’t like ordering from a menu: it’s custom work with a lot of judgement and decisions involved. For most custom software projects the domain experts — the people who know what the software needs to accomplish at a business level — and the developers — the people who know how to make the software do what it needs — are two different groups.

Make sure these groups are communicating on a weekly basis. Communication should include both written discussion of project status and phone/video calls — possibly including screenshare demonstrations — to discuss the details in-person. If this isn’t happening the project will inevitably end up evolving in a direction that doesn’t fulfill the real needs.

How it reduces risk:

Custom software is an extremely flexible medium; it can be made to do almost anything you want if you’re willing to pay the cost. However, that flexibility is also a risk: when a project’s direction is not monitored week-to-week it means the project can end up far away from it’s actual goal quickly.

5. Trust but Verify: Release Frequently and Test Thoroughly

Extended periods with no new release while you wait for developers to perfect some particular feature are a clear sign of a troubled project. Work with the development team to find a way to break the work up into smaller, verifiable pieces. Arrange frequent releases to give everyone involved with your project a chance to review progress.

And when a release goes out, make sure that stakeholders take the time to check out the new build and review new features. Not only does this confirm that features are being built as expected, but it gives stakeholders a chance to see their vision in concrete terms and learn areas where their vision needs refinement sooner rather than later when the cost of changes is lower.

Also make sure your software team has a well documented process for doing quality assurance for your project and is actively following it. This should include testing on a day-to-day basis as well as formal testing of major releases and review of the source code quality.

How it reduces risk:

On the developer’s side, long periods of “we’re working hard, but haven’t completed anything” often mask serious issues with the project: technical challenges, poor project management, unclear requirements or a lack of testing. On the stakeholder’s side taking the time to run the software and review features as they’re being coded confirms that things work as expected to stakeholders understanding and also gives an opportunity to refine requirements sooner for a reduced final cost.

6. Engage Users Early and Often in Your Project.

Finding out what your users and potential users will want from your software is a critical part of your project. This should happen on a continuous basis.

Before or near the start of your project, ask potential users what they want. However note that using this type of feedback requires intelligence and care:

  • Users will tend to describe what they’re already used to, rather than what they really need. For example they may ask that your software export data into a comma separated text file. However, it turns out that file is then just manually imported into a spreadsheet which is used to generate a formal PDF report. The feature the user really wants is to have your software generate the PDF report directly.

  • Small but loud minorities of your users may skew your results by raising more concern about a particular issue than is warranted.

Later in the project, usability testing is well worth the effort. In this potential users sit down with the current version of the software and attempt to do a set of tasks while being observed. This doesn’t need to be a heavy process: testing with just a handful of users will gain a lot of insight into usability problems. And modern tools like screen sharing and video conferencing make this sort of testing easy to set up for many projects.

How it reduces risk:

There is no substitute for watching a user work through a task to find out areas where your UI is badly designed. Also watching and talking to users can gain new insights into particular features users do and don’t want in your software.

7. After You Release: Maintainability

You software project won’t end when you release your first public version. Users will report bugs, and ask for new features. Vendors will release new versions of the platforms you run on. You may decide to add a new platform to your product. Your developers may move on to other projects and need to be replaced with a new team.

Documentation on a custom software project is often neglected in favor of visible progress adding new capabilities to your software. However, this can have a long term cost, as eventually institutional memory of how your software was written will be lost. You should consider

  • End-user documentation: manual, help pages.

  • Requirements documentation from which the software was built.

  • High level documentation of the software architecture so a new developer can get an overview of its design.

  • Documentation on build and release process and tools used for development and testing to allow a new developer to understand the practical details needed to get productive.

  • Source-level documentation: thorough, clear code comments and probably an integrated documentation tool.

How it reduces risk:

Failing to document the software may not show up as a problem immediately for the project. However, later in the lifecycle you will pay a far higher deferred maintenance cost to try and recover the knowledge of how the software was originally built and why.