Delivering software

In software development, we talk about deliveries. A delivery is what happens when a piece of software is taken into use by a customer. This is when the software can start producing value for the customer, by improving work processes, or generating new income.

Many software projects are first described by a business that has problems that need a technical solution. The description of the project, often in the form of a requirements specification, is then published or sent to potential contractors who can bid on how to build the project. (There are many issues with requirements specifications, and we generally recommend avoiding them when possible.) Once the contractor has built something that lives up to the requirements set forth in the specification, it is delivered to the business, which can then take it into use.

This model is what is often called a "big bang" delivery, where the software is delivered all at once. The business goes from having no software to having a fully functioning system in an instant.

The alternative to the "big bang" model is delivering in small increments. In this model, the contractor will make software available to the business as it becomes ready, building one functional part at a time. As soon as the first part is delivered, it starts providing value to the business.

Delivering in small increments is the perferable model. It provides more total business value, even if the overall project takes longer to complete, and it allows for natural feedback to occur between business and contractor, and even allows for a changing of priorities mid-way through development. The rest of this explainer covers these benefits (and how they occur) in more detail.

You get more business value

Business value is a measure of how much something is worth to your business. It is a general term that encompasses money you make or money you save. Concretely, when talking about software projects, business value is a measure for how much money a piece of software helps you make or save. In the end, the two are interchangeable.

For example, a piece of software may help automate some tedious work processes, which frees up employees to do other work, and catch up on things that have been left for later. The business value of that piece of software is the cost of the time it saves.

Whether a piece of software saves you time or helps you make more money is the same from the perspective of business value. Both help you create room in your budget, as more money becomes available to you. The room created in your budget is what we call business value generated by the software.

When undertaking software projects, it is common to investigate how long it will take for the software to earn itself back. Often, a five year period is deemed acceptable. That means that the software has to save or earn enough money over five years to cover the cost of development. Of course, earn-back periods vary from business to business.

Software is an interesting type of product, because it costs money to build, but not to keep running. Of course there might be maintenance work related to a project, but compared to manufactured goods, a relatively larger chunk of investment goes into the initial design than continued operation. In other words, software keeps accumulating value for a business after you stop investing in development.

For example, the value generated by software can be measured in monthly increments. One piece of work automation software could save 10000 DKK every month, by automating work processes. After two months, the accumulated value would be 20000 DKK, and after three months it would be 30000 DKK.

The number 10000 DKK here is the value generation rate of the software. The total amount of money saved for a business is the total accumulated value from the software.

Below, we will use some more abstract graphs to illustrate how "big bang" deliveries compare to smaller deliveries in terms of value generation rate (purple on the graphs) and total accumulated value (green on the graphs).

Instead of using concrete units of value (such as thousands of Danish Kroner) on the vertical x-axis, we use some abstract value from 0 to 50. Instead of using a concrete unit of time (such as months) on the horizontal y-axis we use an abstract time unit. The points made regard the mathematical effect of early deliveries, and apply to any concrete situation, any time scale and any monetary scale.

Concretely, the first two graphs show how early deliveries consistently result in more total accumulated business value, even if a project is finished later than it would otherwise be (more on this below).

The first graph shows a "big bang" delivery, where all of the software is delivered in one chunk, and then starts generating value. This means that value accumulation starts relatively late.

Conversely, with early deliveries, the software starts generating value very early on (once the first value-generating feature is delivered), and then keeps ramping up. The total value accumulated is significantly greater than in the first case. The longer a project's development time, the more pronounced this effect will be.

The graph showing early deliveries shows each time unit resulting in the same improvement in value generation. This isn't really realistic. In the real world, some features generate more value than others. We call such features, that generate a lot of value, high-impact. A feature is even higher impact if it can be delivered quickly. By stacking high-impact features at the start of a project, their value generation gets to run for longer, thus accumulating more total value.

For example, we might implement a better user interface that saves a minute of employee time per day, and takes a week to implement. Over time, this feature will pay for itself, but it makes sense to start with a rough version of a new feature that will generate a lot of new sales every week, and only takes half a week to implement.

Such an approach shown in the following graph, where high impact features are delivered in the first two time units, resulting in an even higher total accumulated value.

In short, software delivered in small increments results in shorter earn-back periods and more overall value generated. That is the main reason for us to recommend this approach over "big bang" deliveries.

Of course, earn-back periods also depend on how much the software cost to develop, so it is entirely appropriate to ask if software in small deliveries costs more.

The short answer is no. In our experience, it is often the other way around, and projects with short term deliveries often end up being cheaper for value produced.

One big reason for this is that small deliveries force the contractor to deliver regularly, so they know how to deliver, and do so consistently. With "big bang" deliveries, the team doesn't have to figure out how to actually deliver the software until the very end, which can then lead to all sorts of complications. There may be challenges with the software deploying to the infrastructure you wish to run it on, or subtle bugs that are only revealed with use may be identified. Delivery is hardest to do the first time, but once a system of delivery of software has been established, it is relatively easy to maintain.

Similarly, large deliveries are much harder to test and verify the functionality of. They are also harder to take into use for the employees of your business, as there are more features to learn how to use.

Finally, a big reason for savings with small deliveries is that each little bit of software delivered changes and informs the way you do business. And that may change your requirements, or bring clarity to what your actual business needs are, which means you can build better and more appropriate software. This means you can use your contractor's time much more efficiently, building software that generates much more value. This feedback cycle has larger implications, so we will spend the next section diving deeper into it.

Everything changes all the time

A major disadvantage of "big bang" deliveries is the lack of chances to course correct. While a project is being developed, and before anything has been delivered, it is hard to make changes to the project.

While the project cannot be modified, the inverse is true for your business: nothing can stop it from changing. Your business is made up of living people who constantly change the way they work in small ways. This potentially has an impact on what the best software for your business looks like, but with a "big bang" delivery there is no obvious way to account for these changes.

The contractor buliding the "big bang" delivery, meanwhile, may be working on flawed assumptions, or may be drifting from what you originally agreed. This can be down to miscommunication or a sense of living up to the letter rather than the intention of your agreement for the software project. Either way, there is no easy way of knowing if this is happening.

(Many approaches to solving this problem focus on prototypes and interactivity tests, but they are all fraught, primarily due to the disconnect between prototypes and real software.)

All of these problems go away with small deliveries. Every time a delivery of a working feature is made to your business, you get to see concrete evidence of how well your assumptions for the project fit the contractor's.

Each software delivery gives you a natural opportunity for giving feedback and adjusting direction. Your employees will naturally notice if their practices have or are drifting from what is supported by the software, and can let the contractor know.

At the same time, the new software also modifies your business. No software exists in a vacuum, and all introduction of new software requires an adjustment of work practices, as the software replaces or supports some work task.

As the changes to your business take effect, your needs or priorities for future software may change. Some software may make a different bottleneck painfully obvious, or it may remove the need for software you thought you needed as entire work practices restructure.

With small deliveries, your business situation continuously informs software decisions, and the software continuously affects and changes your business.

Small deliveries naturally establish a feedback loop between your business needs and the software being built. This feedback loop is vital for clean communication, and helps ensure that the software being built actually helps your business.

Significantly, the communication happens over time and with concrete implementations to discuss. This makes assumptions on both sides visible, and ensures that they are confirmed or corrected. For this communication to happen efficiently, it has to take the form of conversations, as the nuance of business issues and technical decisions are often lost in writing. (This is another reason that requirement specifications should be avoided.)

There is one more factor to consider when assessing the usefulness of continuous feedback in software development. Change is not limited to your company. The whole world is changing, all the time.

As other businesses interact with the world, and as new inventions see the light of day, the basis for your business changes. You do not always have control over what changes and when. New markets open up, and old markets close. To stay succesful as a business, you must be able to respond to these changes in a way that is beneficial to you.

Your business interaction with the world can also come in the form of building software that is directly used by your customers. As your customers use your software, their usage patterns and contact with customer service provide feedback to your business nad how you design software. This, too, can lead to better decisions regarding what software to build.

Your business is a part of a bigger system, so as much as you may try you cannot stop the need to change. And the need for change in your business means changing priorities for software to support it. Fortunately, small deliveries support making these changes.