Revealing the real costs of running technology systems – and why it makes sense to invest in improvements to avoid expensive glitches later on.
What technology costs should you include?
Many organisations don’t keep a proper track of all the long-term costs of running a complex IT system. They often cut corners and end up paying much more further down the line, for instance if the system falls over.
This is not just about keeping things ticking over. You also have to invest in regular improvements to keep the system in good shape. This should save you money in the long run and provide a better service for your customers.
Sustaining should never be thought of as just ‘maintenance’. Instead, a healthy service requires constant attention, and continued well directed-investment.
But what categories of costs should you include to sustain and run a technology system?
In this category, the demand is for work which brings value to the service.
Iteration is change that allows a service to adapt to new insights based on customer feedback, process, legislative or policy changes. It is continuous improvement of the experience.
Failing to iterate will increase the occurrence of workarounds and frustrated users.
Reacting to emerging vulnerabilities by patching components and libraries is a necessary activity to ensure services remain secure.
An activity to continuously modernise components.
If a database product is updated, then modernisation would be to move to the new version. A network must upgrade its components to support ever-growing bandwidth. Critical code libraries should be updated to the latest versions.
The choice to upgrade is a subjective one, and modernisation will not always be essential immediately after upgrades are available. However, is it inevitable that upgrades will be necessary eventually.
These relate to the essential costs of running of the service.
4. Running costs
The costs required to keep the service live and operational. A service will continuously use various products or services which incur a cost. This could include business continuity testing, help desk, hosting, IaaS, PaaS, software licenses, paper, ink or other physical consumables which may form part of the service.
5. User management
The administrative users, and all their associated overheads, should be considered part of the cost of the whole service.
Also user provisioning (and deprovisioning), password management, and role management are some of other activities in this area.
Often failure demand arises due to lack of investment in Value Demand. Poor quality services will generate more failure demand.
Under-investment in Value Demand can happen as a result of pressure to reduce costs. The mistake is that cost are then incurred later, often at a much higher price. Compounding this problem is justify spending on failure demand is easier, because it has an immediate impact on the operation of a service.
For example, consider a system that has consistently had funding cuts. At some point it will fail, and when it does, it is much easier to get funding to replace/ upgrade the system because there is an immediate, visible issue.
Failure Demand cannot be avoided entirely, but the strategy should be to invest in Value Demand in order to keep Failure Demand to a minimum.
6. Incident response
When an incident occurs, it is necessary to identify the problems, find a remedy, fix the issues to bring the service back online. In addition there will be other activities such as communicating status updates to the organisation, managing increased calls to the service desk, as well as retrospectives after the incident to find a solution to the root cause.
It is useful to include any loss of income/ reputational damage as a result of your service being offline e.g. if your ecommerce service goes down or banking platform is offline.
7. Security or compliance breaches
When a security or compliance breach occurs, costs are incurred to handle the breach. Additional internal and external communications, legal proceedings and investigations will all introduce costs.
Providing training should be considered the failure of intuitive design. Services should contain sufficient information such that only the correct domain expertise is needed to use a service.
9. User workarounds
When a service does not meet the users need, then user find workarounds. These extra steps make tasks take longer which cause waste and inefficiencies. Whilst this is hard to quantify it should be reflected in the cost of your service.
10. Higher running costs
As services accumulate technical debt and risk, the running costs increase.
For example, if the decision to replace licensed software with open source software is avoided due to the cost of making this change, higher running costs are incurred. Also running older versions of software often incur higher support costs from vendors.
If the system not maintained for a long time, there could be increased wages due to the niche skill set required to support system.
11. Higher change costs
For problematic services even the smallest changes can come at a high price. The need for extensive manual testing should be considered unnecessary as it can effectively replaced through test automation.
These are process and organisational costs that can be avoidable, or kept to a minimum with the right leadership. However these costs are rarely tracked so often go unnoticed in BAU budgets.
These extra steps cost often more, and the increase in cycle time of delivery which delays value to customers.
12. Governance and process
Excessive governance, reviews and sign offs can add a significant cost to your system and there are many models that show this can be avoided entirely. Governance should be compressed and deployment should automated as much as possible.
Meetings are a secret killer of productivity and carry very high cost, especially when there are lots of senior people present. If you have recurring, long meetings to talk about deployment, governance or other system related matters then this is an avoidable cost.
If your development is organised around component teams instead of features teams then the additional handoffs between teams will increase your time to delivery.
Also the work of a component team is valuable only after it has been integrated into the product by a feature team. This again is extra effort and time.
The costs involved in running a technology system are multiple and diverse. Many of the costs involved are not tracked and reported on, which obscures the true costs.
The key takeaways from this approach are to:
- Invest in Value Demand to keep Failure Demand to a minimum
- Use a continuous improvement approach to systematically cut out avoidable costs
- Build the entire lifetime costs of sustaining a service into more sustainable investment business cases
- Create processes which prevent systematic under-spending in areas of value demand
- Track Failure Demand and report this cost wastage as a key KPI
- Make sure every technology system has a product owner who is responsible for the roadmap, investment and prioritisation of investment