I occasionally muse about turning my ROI articles into a book. As part of the musing, I keep coming back to what would I use for Chapter 1. And I always arrive at “time” as a factor in ROI.
Way too often the wrong kind of time is being used in Software Development – we focus on the time to create it – not its full lifetime – thus leading us into short term focused practices – thus leading us away from long term focused practices.
And given very few Software project have a short life, we are bound to get poor ROI from them.
So what drives this thinking? For me it is length of our Planning Horizons.
"Horizon - the limit or range of perception, knowledge, or the like." Dictionary.com
"The planning horizon is the amount of time an organization will look into the future when preparing a strategic plan" Wikipedia
I’ve included the two definitions above as I think that “horizon” is such a great term to think about when considering any tactical or strategic work. It’s an easy metaphor to understand – you can only see as far as the horizon.
When applied to business; I find that there is likely to be an over focus on short term horizons (tactical thinking) which is very much about the here and now;
And when a business is focused on the short term horizon, then there is a drive throughout the organisation to focus on that to the exclusion of almost everything.
You find that the executive team will push for those short term objectives, the project management will push for those, and the development teams will be expecting to work to them. I’ve seen it get to such a point where professional developers will actively not follow industry best practice due to the perceived notion that the business want them to “get it done”.
The problems with the “get it done” mantra is that no one is considering the full lifecycle of the software being created. Everyone is focused on getting it over some imaginary line – not about its long term wellbeing.
By changing how we consider the length of the Planning Horizon, it changes how we consider the fuller lifecycle of the software.
I’ve heard before that 80% of the cost of a Software project comes AFTER the creation.
While I’m unable to find the source of this figure, I would consider it be a very conservative estimate depending on the software system. Many software systems will operational for years – with many subsequent changes being made over its full lifetime.
Doesn’t this indicate that we should be thinking about its longer term life rather than any short term goal?
I really do think that having that longer term horizon mind-set will help greatly in understanding many of my recommendations in the ROI series.
I can easily understand how some of my recommendations will make little sense to anyone thing in short (< 3 month) horizons.
As I say above – any software you create is likely to have a much longer life that 3 months – as such you need to consider that when thinking about how that Software is developed for better ROI over the long term.
There will certainly be times where it is correct to consider the short term only.
There may well be a specific business changing event that needs to be hit with very short timescales. These events happen – although with much greater rarity than most would be willing to admit.
If you believe you have one of these events, then go into it with your eyes open – understand that by taking a short term view you will be incurrent a burden for the future (see my article on Technical Debt). And this maybe the correct choice – in exactly the same way that taking on a financial debt maybe appropriate if there is a sustainable method of paying off that debt.
Unfortunately, I generally find it way to common that once the “short term win” card is played, it is played over and over again – with limited effort to pay of that mounting technical debt. I’ve certainly seen business become effectively unable to innovate and struggling to maintain any market share once that technical debt becomes too high.
I’d personally be concerned if the card was played more than once a year. It would give me grave concerns that the business model simply wasn’t sustainable. Constantly having to rob Peter to pay Paul is not an effective business model.
In the converse, I wouldn’t advocate over analysis.
I’m not suggesting that mountains of up front planning should be made at the start of project – mapping out the entire life of the Software.
Mainly due to this being a complete waste of time and effort. You simply won’t know what a Software product will look like in 6, 12, 18, 24 months’ time. Thus don’t waste the effort.
The key is to understand the best practices for long term ROI and implement them.
And probably key amongst those is letting the professionals you have employed get on and do their professional best.
They should be encourage, training and empowered to work in those best practices. They should, by default, be doing all those good things which will produce long term ROI.
Only on those rare exceptions should they be being asked to cut professional corners. And when they are asked, it should be widely acknowledged that this is the case. Everyone should feel a mingle of sadness and shame when this happens. They should all be desperate to put it right.
This will need to be a mind-set that encompasses the entire organisation.
Having an awareness that you could be doing it wrong is a great place to be. The fact you are considering it means that there will be changes in behaviour.
Training is a great place to continue that work. I’ve written previously about just how important it is that your development team are well educated and up to date with current technologies and practices.
I provide my ROI articles to help with that aim.
And of course, I’d be doing myself a disservice if I didn’t advise bringing external expertise in to help (see my Services).
I’m certainly not that only person out there that could help (but I like to be able to pay my mortgage).