How to measure the value of software?

Here’s an important concept. Read this article if you are considering purchase or development of a software product for your company.

Amidst all the talk about start-ups, disruption and scaling up, one can lose sight of a critical quality of software. As any other machinery, it is an asset that depreciates in value over time.

I’d go with an even bolder statement. A software on its own has no inherent value. A businessperson that understands this key concept well is less prone to failure when it comes to digital transformation & acceleration.

Curiously, it is also a factor of aligning IT and business teams. BizDevOps (making fusion teams out of business people and software developers) has been growing for some time now, and I support that movement wholeheartedly. From my experience, a software developer that is out of touch with business context will cause you more trouble a few years down the line than you’re able to imagine today.

And trust me, software developers ain’t cheap for such mistakes to be made.

What do I pay for?

At the beginning of this article, I compared software to machinery. Think of any machine present on a production line in a factory. What does a machine need to add any value to a business?

1. It needs to be constantly performing and be controlled by an operator.
2. It needs maintenance and servicing.
3. When it stops serving its purpose, it needs to be replaced with something functionally similar.

It’s a common mental model. We intuitively understand how machines operate.

And like a miracle, many people think that software does not conform to the same rules. But it does.

Now ask yourself – why would you buy a machine for your production line? The answer might be along the lines of these examples: “to make a certain part”, “to combine parts together”, “to paint something in a specific color”.

Note that you don’t buy the machine for its own inherent value. It’s never the machine.

The same is with software. You are paying for the ability to perform a certain function faster, cheaper or more reliably. It’s never the software.

Software assets do depreciate in value

Why does nobody expect a machine to have the same performance on day 1000 of its operation without maintenance as on day one and yet – they do so for software?

There are three reasons for that:

1. The perceived invisibility of the software. In our minds it doesn’t belong to any physical form but to the world of ideas.
2. Previous experiences with desktop applications. You open Microsoft Word and… it’s here. It’s not going anywhere. It doesn’t become spoiled with time.
3. The overarching premonition that copying documents and files on a computer is free.

The truth is that as users, we are typically oblivious to how the software we are using came to be. Updates and maintenance look free to us – it’s just a progress bar, sometimes a change in the license agreement to accept.

A gap exists between our experience of using software and actually owning its development life cycle. A gap that we’ll close in the remainder of this article.

When you hold ownership of the software and its development life cycle, you are responsible for:

• staying up to date with operating systems (desktop applications), Web browsers (web applications)
• fixing bugs, including security bugs
• staying up to date with development tools
• staying up to date with the technologies used to make the software, including software libraries used in the project
• keeping development and test environments ready so that developers can start working and be able to test application at a moment’s notice
• removing obsolete parts of the software to fit real use by the end users
• keeping the infrastructure needed for production and testing purposes
• checking whether the software is performing it’s business function

And the crucial component: You are solely responsible to train, ask for feedback and help people with using this software. You won’t get any value out of software if nobody uses the software itself or anything produced by this software, nor if anybody exploits the software to its full potential.

And thus, a mobile application, web application or any other system becomes a lot more similar to a physical machine in a factory that needs to be used, maintained and fulfill its purpose or be replaced.

The cost to operate such a software is closely related to the idea of Total Cost of Ownership.

Software assets have no inherent value

Can you liquidate a custom-made machine made specifically for your factory?

I guess you could sell it to a scrap yard. If you are really lucky, someone might have a similar need and repurposing your machine for their needs could be cost-effective.

The same is with software. If it’s licensed, you most likely cannot resell it. If it’s custom-made, it probably does not fit any other company or at least needs to be repurposed for their business goals.

Until the software performs its function as intended, there are only costs to owning software. 

I like to think that the value of software is exactly zero at launch. From that point, a system or an application can slowly start adding value (in the form of data accumulated or function performed) that offsets the costs incurred for its development, and with time the investment will pay off.

Now let’s combine this and the previous statement. If software starts with no value at launch and loses its value with time, then if it’s not used, what you effectively have is a liability that requires regular repayments for no real returns on it.

In consequence, just as with the machine example, it’s not enough for software to be ready for operation at launch. You need software to be operated in full capacity from day one. That requires careful planning of the software release schedule and the training schedule so that your employees will be able to use the software and customer adoption plan if the software is going to be used externally.

Here machines and software differ. Software development allows teams to iteratively collaborate on a product during the development phase. You can teach your users and operators how to use the software before it’s complete, during the beta or alpha release. The feedback you gather from real usage of the software is the biggest contributor to reducing the risk of the software not being adopted by its intended users.

You can engage people even earlier, using interactive prototypes to test multiple possibilities at once and choose one that is most suitable for the target audience.

All the time it’s good to have the end goal in mind – when the system becomes fully operational, it also means that it will be operated in full capacity.

Summary: A new way of thinking about software

It’s not really a new way, but I hope that such a perspective will become common among all businesspeople in the future.

To sum it up in a few points:

1. Software is like a machine.
2. An application needs to realize a purpose, perform constantly and requires service and maintenance.
3. Software’s value starts at zero and depreciates over time.
4. The added value comes from using software, its output or data accumulated as a result of its operation.
5. If an application requires employees to operate it, train them before the first full release is published.
6. If operation requires customers, prepare an adoption plan and set goals to reach in the future.
7. If the system reaches full operating capacity on the day of its official launch, the deployment can be considered successful.

That’s where we’ll be stopping for now. Understanding software development as a special case of installing a complex machinery in your business can be very useful for planning and scheduling all the process and organizational changes that need to happen around the software necessary to start using it productively.

It helps mitigate risks that are associated with poor training and adoption of a system by the people it was designed for, including mismanagement between their needs and capabilities of the system.

It helps to start building an intuition of what you can and cannot expect from software, either custom-made or purchased and integrated into your company.

In the end, it serves as a starting point for more elaborate methods of digital transformation and acceleration, such as transforming into a composable architecture. In such methods there will be a lot of cooperating systems and people, but the basis for each individual piece of software is the same as here.

That’s it for today.