Imagine that a few weeks ago you bought an outdoor theatre ticket for $100. You wake up on the day of the concert and it’s raining, with a storm due later, you’re feeling ill. On top of this, your car is in the repair shop, so you’ll need to take three different buses to get there. Yet, despite the fact that the current drawbacks outweigh the benefits, you still choose to go to the show.

This is known as the Sunk Cost Fallacy.

In simple terms, the Sunk Cost Fallacy is the phenomenon where “a person is reluctant to abandon a strategy or course of action because they have invested in it, even when it is clear that abandonment would be more beneficial.”

A point of research in behavioural economics and psychology for many years, it can also be applied to delivering software.

The crucial part of the definition above is this:

“even when it is clear that abandonment would be more beneficial.” 

The key question is, why do we keep falling for the Sunk Cost Fallacy? 

The Experts at Massachusett Institute of Technology (MIT) provide three hypotheses for this behaviour:

1. We don’t want to appear wasteful
2. We want to stick to our plans
3. We don’t want to accept any loss at all, so we follow through.

So whilst building software, how do you know if changing course would be more beneficial?

Stop, Start, Continue is often used when giving feedback. And it can also be used to apply to decision making in these situations. The principles are as follows. 

• Stop – stop doing what you are doing and abandon with no alternative 
• Start – start a new course of action to reach the goals but pivot away from the original solution 
• Continue – continue on the path you are already on. 

In these decision making situations, the first, and important point, is to take emotion away from the behaviour. This can be done simply by digging deeper into the cause and effects of stopping starting and continuing, and attributing a business value in terms of $ to each. 

By calculating the Net Value for each option, you will have a data-driven approach to making a decision (a different result for Stop, Start and Continue). 

However, when doing this it is important to remember that you don’t count the money you have already put in. This is now sunk cost. You can’t get it back no matter what you do, so the only important point, and all you can do at this stage, is look at which option will get you to your optimal goal, starting from now.

There are four clear steps to a data-driven answer.

Step 1.  Make sure your goal is still valid.  

Firstly it is crucial to revalidate the goal that has been set initially. 

• Is the original goal clear
• Does the initial goal still stand 
• And does your goal have clear measures of success so you know at what point you can say you have achieved it?

Step 2. Articulate the Business value for Stop, Start and Continue.

(STOP) Articulate the business value and costs if you were to stop. The likelihood is, in this situation, not only will you get no business value, but also no costs (if not including what is already sunk). However, you also need to be aware that not doing something could also result in loss of customers, revenue or increase in penalties, so ensure you think about the negative value that could also occur. 

 (START) Articulate the business value and costs for a different solution. Knowing what the costs would be in a new solution and when you would articulate that value (and even if the profile of the value is likely to change) will help you work out if you should start anew.

(CONTINUE) Articulating the business value and costs if you were to continue on the same path (ignore what you have paid in already, this is already sunk ), it is essential to understand what you still have left to pay and when you will get the business value at this rate. 

Step 3. Calculating the Net.

To calculate the net, use the following formula: Total Revenues – Total Expenses. 

Total Revenues (over a set period, usually 1 year)

• Sales revenue 
• Saving in operational costs

Total Expenses (over the same set period as revenue)

• Build costs
• Ongoing support costs 

Step 4. Compare the Results.

The net result that gives you a higher rate of return is the result to pursue from a business value perspective. That is because it will provide the most value over the duration. 

Some of the common pitfalls you will need to avoid.

So far it is pretty straightforward, right? OK, now we need to address some of the behaviours I have seen before. Some common, and other less common, traps that could derail a project.

Redesign at the expense of the immediate value.

One trap I have seen in clients is that solutions are abandoned weeks or even days before launch to re-architect, or change the technology stack. This is equally dangerous, as you could be willing to sink more costs for no added benefit. In this scenario, ensure you have looked at the business benefits based on where you are now.

Ruling out double development with no evidence of the impacts of that against value. 

Some projects are in a position where you are migrating to a new technology stack (or cloud provider). You may be unwilling to do work in the old world and the new world because it is deemed “wasted effort”. Although this may sometimes be the case, it is all relative to the value that work will bring. Apply these same principles when deciding if to do the job twice or wait. 

Assuming that this will demotivate engineering teams.

Here’s the facts as we see it, time after time. Most engineering teams that we have worked with ultimately want to be building something that will be used and add value. By changing course often, assumptions are made that this will demotivate the engineering teams. In my experience, this isn’t the problem.  The demotivation occurs because there hasn’t been the upfront and honesty around why there is a change of direction with the data that backs this up.  What you will find by doing this exercise and providing the data to your teams is it will result in motivated teams wanting to do what’s right because they see value in it.

***

The truth of the matter is, the Sunk Cost Fallacy is a natural tendency. But it is one that can be avoided by simply following a few principles, procedures and by recognising and avoiding the pitfalls. As soon as you recognise that the end result will benefit from your decisions at this stage, this approach becomes obvious to you, and everyone you need to convince to change. Because no-one wants to be the software delivery equivalent of someone who goes to the concert, and ends up standing alone, sick, cold and stranded in a muddy field.

As a technical architect at Equal Experts, I’m fortunate to work with clients at the start of their decision-making process for new, large-scale IT projects. One of the questions I’m often asked is: “Should we buy, or should we build?” Not surprisingly, I have views, and am always happy to share them.

Recently, a client gave me a novel take on this subject that I hadn’t considered before. He likened the costs associated with building software to making a chicken sandwich. Specifically, he told me the story of Andy George, who made a documentary series following his mission to make a chicken sandwich from scratch – and I do mean from scratch. He harvested wheat, ground flour, milked a cow, made cheese and butter, boiled sea water to make salt…you get the idea. At the end of his journey, he’d spent $1,500 and 6 months creating a single chicken sandwich, which he could have bought the same day from a local store, for less than $5.

It’s a fascinating story (you can watch the videos if you have time), but having considered it for a while, I don’t believe it’s a valid comparison.

We don’t need to make our own salt

Here’s the thing. When we build software, we don’t build it from scratch. We assemble all the base ingredients (common services, third-party libraries, databases, etc.), and then we build the important stuff: the business-specific functionality that makes your software different.

Returning to the chicken sandwich analogy, building custom software is like buying the ingredients (bread, mayo, chicken, salt, etc.) and then making the sandwich in the way that you want.

This is the gist of my argument. It’s rarely a question of build or buy; in most cases we build and buy.

If all you need is a cheeseburger, buy a cheeseburger

So, now I’m on a roll with the food analogies, let’s look at one of my own relating to buying commercial off-the-shelf (COTS) software.

When buying a COTS solution (for example, SAP or Salesforce), my view is that it’s like going to McDonald’s for a cheeseburger. The cheeseburger is fine (there’s nothing wrong with it), but you can’t customise it. At best, you might be able to ask for a different type of bun, or to leave out the sauce, but you can’t ask for Brie instead of cheddar, or to add a fried egg. If something isn’t part of the standard offering, then sorry, but you can’t have it.

This is perfectly good if all you want is a cheeseburger, you don’t need your cheeseburger to be different, and the cheeseburger in question fulfils your exact needs.

The same principle applies to software. If a COTS solution does what you need without customisation, and you don’t need it to differentiate your organisation from all the other organisations that are using it, then go the COTS route.

Of course, there are situations where this is the best approach – typically for internal, non-customer-facing systems (e.g. accounting systems).

A few tips for buying software

• Try before you buy. No matter how slick a software company’s demo is, always try before you commit to anything. Even if the vendor has no official trial offering, negotiate one (six months, if you can).
• Avoid long-term tie-ins (I recommend no more than one year).
• Go for a module-based product and only buy what you need.
• Don’t customise. Use the product out of the box and build additional features around it.
• Ensure that the product follows your architectural standards and patterns (e.g. integration via RESTful APIs, event handling or scales on load).

Principles for when to build or buy

My key principles for the decision-making process:

• Build what differentiates you. If something is core to your business and represents who/what you are, don’t rely on someone else to provide it.
• Software developers can be very keen to develop everything from first principles! But if something isn’t core to your business and it’s not a differentiator, buy it.
• Do what delivers value the fastest but maintain flexibility so you can make changes as requirements change/grow.
• If you’re still not sure which way to go, build first, then test and reassess. This will clarify requirements and if it’s not what you want, you’ll have a better idea of what you need to buy.

What is a differentiator?

Gone are the days when software was something in the background that took care of the boring stuff and couldn’t be a differentiator. Now, software solutions are so often the thing that improves business processes, enhances customer experience and ultimately drives revenue generation.

So what qualifies as a differentiator?

• If something is core to your business (i.e. important enough to be in your business plan or part of your business strategy), then it’s a differentiator.
• If customers come to (or stay with) you because you do something that your competitors don’t – or you do it better – then it’s a differentiator.
• If it’s a missing or poorly performing feature that might prompt customers to move to a competitor, then it’s a differentiator.
• If something generates direct revenue, it’s a differentiator.
• If the business is willing to change its processes to align with a software product, then it is probably not a differentiator.

Costs (and super powers)

One of the points I stress to clients is that we don’t build software or move to the cloud because it’s cheaper – often, it’s not. We do these things because they provide the freedom to be innovative, fast, and better than our competitors.

Of course, costs must be considered – but so too must value.

Total Cost of Ownership

During budgetary discussions, clients often focus on the cost of buying software licenses and support but neglect many items that impact Total Cost of Ownership (TCO).

I advise considering the future costs associated with:

• Ongoing maintenance after the initial license period ends.
• What would the cost be if you need to customise for a specific feature?
• Upgrades of customised solutions. Once a standard product is customised, it’s often very tricky and thus costly to upgrade.
• If you can’t make changes to your solution quickly and easily, you’ll be slow to market and risk missing opportunities.
• Product switching. Committing to a large, upfront license fee can make switching solutions, in the future, prohibitive
• Contract negotiations. Never underestimate the time and effort it takes to negotiate a contract with a major supplier. Once the lawyers get involved it can really stretch your delivery timelines.

True Value of Ownership

People are generally very familiar with return on investment (ROI) – invest £10m and get £12m back; it’s monetary and, therefore, very straightforward.

But value isn’t always reflected in direct revenue; it’s about other things – customer satisfaction, agility, innovation, etc. This is where building your own software can really come into its own.

In fact – not to be overly dramatic – but I’d argue that building software is a real-life super power. It’s where you can absolutely achieve far more value over buying a solution.

We don’t deliver software like we used to. Continuous Delivery makes the whole process fast and lean. So, when you choose to build:

• Value is realised sooner. The bones of an idea can become fully-formed reality, incredibly fast – as fast as you want it to be. And of course, the sooner you get your solution to market, the sooner you’re realising value.
• You only need to build what you need. Often, people buy huge, expensive systems for features they think they need, but actually never use.
• You only need to build what is valuable.
• Your only limit is imagination; you’ll never be constrained by someone else’s framework or roadmap.
• You can build differentiators. If you can buy COTS software that does great things, so can your competitors – any potential differentiators are gone.
• It’s your Intellectual Property (IP). If you’ve bought a solution and you ask the supplier for a customisation which adds value to their core product, it’s likely that they will offer it to other customers – you have no control over this.
• Change is easy. As the context surrounding your business changes, your software follows suit.

Conclusions

In my conversations with clients, I completely understand when they say this:

“Of course, you’re going to say ‘build over buy’. You work at Equal Experts. That’s what you do.”

Yes, we’re in the business of building software, but we do this because we think the final solution will make your organisation unique, agile, successful and simply more effective.

Ultimately, this isn’t about diametrically opposing views. As I said way back at the start of this post, it’s not a question of whether to build or buy; almost invariably it’s how to build and buy.

When you consider what you need to build and where best to source standard functionality, it should always be in the context of maximising value – this is where greatness lies.