In this episode I want to talk about how to think about investing in software development. I see too many people thinking that software development is an activity with one outcome – success. And with that I see funding being made to that software development with the expectation that it will deliver specific anticipated benefits. I want to take you through why I think that mindset is incorrect and how you should be thinking when investing in software development.
Or listen at:
Published: Wed, 31 Jul 2019 15:33:26 GMT
Links
Transcript
I find that traditional software development is treated like a long term investment.
The expectation is that an amount of money will be invested in the work, a known period of time will elapse and the software will have produced a significant return to justify the original investment.
You could think about this in a similar way to a fix term savings account (if the UK, something like an ISA). You invest in a plan that has a fixed period, with a known return - say for example 2 years at 5%. With something like that you can have an absolute level of confidence of when you will see you return and how much it will be.
And as I say, I see many executives thinking in that same way when they consider software development investment. They talk to IT about what they want and arrive at a schedule and cost. They decide if that gives a good return based on the outcome they expect. And, if all good, they give the work the green light and then wait the allotted period for the expected results.
Unfortunately, the analogy doesn't hold true in the real world.
There is simply too much variability for it to be so simple.
Any schedule and cost for software development should only every been seen as an estimate - an estimate that can be considerably different from the actual. Too often executives will treat an estimate as a commitment. They will expect to hold the team to those commitments - with any failure to achieve those commitments as being a failure within that team.
In the last podcast I talked about why software development is so complex. And like any complex problem, an accurate estimate can be difficult to achieve.
I've actually written three articles on how estimates can be bad for ROI - I'll provide links in the show notes.
The key take away however is that the estimates should be treated as guesses - not commitments.
So we have variability in how long the work will take and cost, but it doesn't stop there.
There will be variability in the anticipated outcome.
If, for example, you are asking for a change to your website which you expect to increase orders by 10%. That is not a guaranteed outcome.
I many organisation, if that change increases the orders by 8%, the initiate will still be deemed a failure because it didn’t reach the expected outcome.
There is of course no way of accurately predicting the outcome. It like the schedule and cost are an estimate.
Or rather you are proposing a theory. If we do X, I expect Y to happen.
You may have a variety of sources to backup your theory - anything from prior first hand experience, to industry studies - or you may just be making an educated guess. However you arrive at it, its a theory until it can be actually proven.
So we have variability in how long the work will take and cost, and the anticipated outcomes, but there is still more variability.
The actual details of the work may need to change as time progresses. This is generally because greater understanding of the problem is "discovered" as the work is being done. Or it maybe due to changes from an external market or some compliance/ regulatory change.
This will generally be referred to as "scope creep" and is often talked about in quite negative connotations. Personally I don't like the term or the negativity around it – it is simply a reaction to the changeable environment we all find ourselves in.
So where does this leave us?
We have mental model of treating software development as fixed term investment with a known return for a given investment - that is fundamentally flawed in pretty much every possible.
So what's the alternative?
What other mental model could you use when the problem being solved is changeable? When the results are theoretical? When the timelines are unknown?
To me, that sounds much more like investing in volatile stocks.
You have no guarantee over which direction a market will go, or how rapidly. Sudden rapid losses are very possible - but then again so are rapid gains - and everything in between.
Which certainly doesn't discount it as a valuable investment device; may fortunes are made (and lost) investing in volatile stock.
To invest in it however however represent an entirely different risk profile. And as such, an entirely different strategies to a fixed term savings account.
To be successful it encourages the investor to play close attention to the market, to be reactive to fluctuations in conditions. It encourages the investor to think carefully about how much they are willing to gamble on those fluctuations. It even encourages the investor to, mentally at the very least, prepare to lose money.
This is a far cry from the fix term savings account which is a sure thing.
Ok, so what has this to do with software development?
The moral of this somewhat laborious tale is that software development is subject to many unknowns - and as such it cannot be treated like a fixed term activity with known costs, timescales and benefits.
The world simple changes to fast to allow you to tell a team what you want, give them the agreed investment, and them comeback in a years time to reap some anticipated benefits. Expecting the world to work that way will be simply unrealistic.
So rather, think about software development like that volatile stock - think about how you keep your risk low, but position yourself to take advantage of situations as they arrive high.
Start to think in terms of keeping your software changes as small as possible, as targeted as possible, as experimental as possible.
And that word experiment is perfect for this digital age.
You have a theory, you want to test it. If you are right, maybe you can go further with it - invest more. If you are wrong, maybe you cut your losses and make a course correct - invest in something else.
Today's successful software development industry is made up of small changes happening as quickly as hourly, with rapid feedback cycles on what is working and what isn't, with subsequent changes being educated by that feedback.
You need to be thinking about your software development is being quick experiments, which you prove or, possible importantly disprove, as quickly as possible.
So in this podcast I talked about how thinking of software development as a fixed term, known investment is the wrong midset for achieving the best ROI.
Better to consider that software development as volatile experiments that should be managed as such.