Following on from my last two ROI articles, Planning Horizon and Planning Horizon – An example, I wanted to close this with a discussion of concrete affects it should have on planning.
As we saw in the Example article, a Software Product can have a very long lifetime – and to get the best ROI, we need to align our mind-set to that kind of thinking.
In this article, I take a high level visit of previous articles with this longer term mind-set.
Short term; its expensive and time consuming for Developers to learn. Its not our responsibility to train them.
Longer term; training, self-learning time, access to resources, etc are an incredibly good investment.
The more skilled our people are, the better the solutions they produce.
I cover this in more detail in these articles:
Short term; investment in newer/ better equipment and tools seems a waste.
Longer term; you only need a modest uplift in productivity to realise ROI on the upfront investment.
I’ve previously argued this case for providing everyone in the business (not just developers) two screens. For < £100 of investment per person, it is easy to expect a 5% productivity improvement – just simply from avoiding screen switching. I’ve found very few people that don’t benefit from a second screen.
Within software development; a good machine and appropriate tools are essential. Without them productivity goes down rapidly (I can personally testify to this when moving from aging equipment, to more performant systems – this is why I’ve “overspent” for my personal equipment).
I cover this in more detail in this article:
Short term; we tell the development team what to do
Longer term; we invite the development team into the business. The better the development team understand a business – the better they can utilise their problem solving skills to handle challenges and provide innovation.
This also talks to putting in place proper motivation. Yes you need to reward them appropriately (money and benefits), but on top of that, they need to have that sense of purpose that comes from real engagement.
These are very clever people. Let them see the problem and let them do what they do best – solve problems.
I cover this in more detail in these articles:
Short term; we just tell them to do it. And/ or we insist on concrete commitments. We don’t have time to “waste” improving the way we work.
Longer term; we get them to focus on their processes and practices to make them the best they can be. We trust them to do the best work they can and rely on their professionalism rather than wasting time in inappropriate requests and/ or value-less exercises.
I cover this in more detail in these articles:
Short term; we tell the development team what we expect to want in the future
Longer term; we focus the development on what we need now. We create theories and use scientific measurements to establish if our theory was correct. We use that feedback to influence what we do next.
This might seem at odds with my overall message when I’m advocating thinking about the longer term. The important take away here is that you have to consider the longer term of all those features that are added because “you think you’ll need them”. A considerable amount of code is developed (at a cost) and then has to be maintained (at a cost) but never fully utilised.
Only build what you need and prove that it needs to be there. If code doesn’t provide value, then consider destroying it – otherwise it will be incurring some form of cost to maintain.
I cover this in more detail in these articles:
Short term; we’ll worry about security when we have a problem
Longer term; we ensure that security is baked into any solution from the start. We understand the risk to our business, our customers, and our reputation from doing it wrong.
Security needs to be promoted within the Development teams – training and external assistance is likely to be required. The Development team will need to be encouraged to be secure “by default”.
It is too easy for security to either left to the last minute in a project or skipped completely. This puts the business at a huge level of risk.
I cover this in more detail in this article:
Short term; failure is punished
Longer term; failure is accepted as a learning process. Failure is encourage as it incentivise the Development Team to innovate and push their own boundaries.
We have a fear of failure baked into us at an early age. This fear of failure can be incredibly restrictive in pushing beyond what we believe to be safe. And without pushing beyond then improvement becomes difficult.
Failure should be something that is controlled within a scientific theory, measurement, feedback process to keep it safe.
I cover this in more detail in this article:
Short term; the dev “superhero” will get us the job done quickly.
Longer term; we use the team to avoid silo situations. We make the team stronger than the individual and avoid all the risks associated with putting all our eggs in one basket.
I cover this in more detail in this article:
Short term; we know best. Just do as we ask.
Longer term; they are professionals in their craft … don’t second guess them. Software Development is a complex and complicated activity with many best practice activities specifically related to the activities. We should expect the Development Team to know (see training) and use them.
I cover this in more detail in these articles:
Short term; we can’t afford that.
Longer term; understanding the difference it can make to the business. Understanding that those same skills are differentiators for our competitors and every other business out there. Understanding that, yes it can be a cost, but it is an essential one which should be seen as a benefit rather than a drain.
I cover this in more details in these articles:
I hope this summary has been useful in terms of providing examples of how a mind-set can shift when considering the longer term ROI of Software.
While many business decisions today are taken with a very short horizon in mind – monthly/ quarterly targets for example – so much of our Software value is achieved over a much longer period.