Navigating Uncertainty

In business, as in life, navigating uncertainties is part of the game. If you can call it a game. You make plans, then plans get upturned by events unforeseen. Wars break out, and pandemics. Children get ill. Lives overturned. All is precarious.

I was 7. It was my birthday. We were on our way back from a visit in our Commer van with a load of apples for the shop. Then something happened to cause the van to tip over and crash. Last thing I remember was the little Commer emblem on the dashboard tilting at a crazy angle.

No-one was seriously hurt but after we got home and everyone was taken care of, I had this realisation that anything could happen, at any moment.

I remember that moment vividly. That feeling has never left me. Defines me to this day.

In business, the general consensus is that uncertainties are to be avoided. Here in Europe we have contract-based societies and we are very lucky to have them. And of course, combatting uncertainty is what contracts are all about. To come to an agreement the signing parties are going to be okay with, often takes a long time, and that's fine. Less fine though is if the contract states things that turn out differently in reality. Not storms, wars, pandemics. Just plain old missing requirements.

A contract is like predicting the future. Or, it is like a map. You draw a line on the map from where you are now to where you want to be. Generally okay if you are going to the next city. But what about cross-country from Amsterdam to Shanghai?

Google Maps actually makes a trip like this look easy. Tedious, but straightforward. But I think you get the point. The further you want to go, the more risk is involved. There will be issues.

(Yes, I investigated other routes than through Russia. Where you don't want to be. But then it's through countries like Iran, and the *stans, also no party. Not to mention that you would have to cross the deserts of China)

The map is not the territory. However meticulously planned the journey might be, when you get down to the actual hour by hour, mile by mile, it always turns out that the map is off. Sometimes by a bit, sometimes by a lot.

Is planning useless? No. Of course not. We must try to gain some knowledge about the future. We must try to plan ahead. To navigate uncertainty.

However. When, in business, companies enter into a contract, there must be a mutual understanding that the contract is to the outcome as the map is to the territory. One of the parties delivers the budget, the other delivers the goods, and if both come away satisfied, that's it. No nitpicking over details.

We are in custom software development. What the word "custom" means is that most of what we do, we do for the first time. Not as in new programming languages and such. Obviously not, we are all very experienced in our domain. But new as in every single time we are fitting our solutions into a new environment, with new constraints, new goals.

Let's say you are a new client to a certain software company -- maybe that's us -- to do a project. To be specific, you are a travel company that wants to automate their booking process in order to free up valuable employees to focus more on marketing. You have talked to this new company and have agreed on an approach. But you know the travel world and you realise full well what the problems are. So even though the company you wish to engage with has a lot of experience in travel, you are uncertain if this approach will deliver what you expect from it.

One way of navigating this uncertainty is to negotiate a proof of concept. That would work something like this:

Scenario: You're considering automating the booking process of your travel application

Goal: Verify that the agreed approach delivers x% automation.

1. Create a minimal application. This application will be completely separate from your existing travel platform.
2. Implement basic transaction features. Don't get into details like payment processing and refund. Just implement the flights API and the hotels API and create cache. No user interface.
3. Testing: Simulate a sales flow and measure success rate. Maybe create a human-readable output in the form of a report and graphs. Do that x times.
4. Analysis: Discuss the results. Are they near enough x to continue?

Obviously, a proof of concept should be tightly managed:

• Objective: Clearly define what you aim to prove.
• Scope: Limit to essential features to keep the POC manageable.
• Timeline: Set a short timeframe to maintain focus and urgency.
• Evaluation Criteria: Determine how success will be measured.

Choosing to do a proof of concept is one way of navigating uncertainty. That won't mean that it is clear sailing from here. The actual implementation still needs to happen, including the full cycle of integrations into the current system. There will be struggles, failures. But at least these struggles and failures can be met with the view that success is possible.

Point is, however hard we try to prepare and predict, the outcome is not likely to be exactly what was planned. Always off. Sometimes by a bit, sometimes by a lot.

As a company creating custom software solutions, we have created a number of systems with which we navigate uncertainty. One of which being the proof of concept. But there is always going to be a level of uncertainty. Whatever contract there is, and again, contracts are good, there must be this mutual understanding that the contract cannot cover every eventuality, that the map is not the territory.

Yes, anything can happen, anytime. But we -- both of us, you as a client, we as a software development company -- we are prepared.