Abstract image with coloured lines wound around nails on a board.

True Value through True Costs

The importance of Total Cost of Ownership in Social Housing Technology

Over the years, my team and I have carried out many procurement and software selection exercises of very expensive housing systems for landlords. One thing we have seen is that very often you will come across terms and questions such as ‘We would expect to see true Value for Money from your software’. Or ‘You must demonstrate how we would see VFM or cost savings’. What we don’t hear very often is ‘What is our Total Cost of Ownership for this particular system?’

The big problem here is that what value means for the organisation is rarely qualified and quantified in the procurement itself, or even afterwards as those implementing seek to find out what the total cost is and what return they will get to justify their (over)spend.

For as long as I can professionally remember, I had it drummed into me that, as an IT leader, Total Cost of Ownership (TCO) is the most important thing you can get right in relation to cost and budget management. TCO is the total of ‘all’ costs related to and incurred through the use of software and is a critical part of ensuring you get Value for Money (VFM) and any reasonable Return on Investment (ROI). They are all kind of related.

But, and it’s a big but (and I cannot lie), the housing sector does not use TCO properly. In fact, I only see it used on very few occasions. This is a real shame, as technology costs a lot. The big question therefore is, if you want to consider the true potential value of a product, why does the sector not make more of an effort to work out he real costs?


How to start looking at your TCO in three simple steps

Step 1: Classify your software solutions

The first exercise you may consider is classification of your software solutions. At present, software you have will fall under one of three categories:

  1. Off-the-shelf software. Typically runs on-premises or a hosted data centre. Think of your current Housing Management System.
  2. Cloud, SaaS software you lease/subscribe to. Think 365, Salesforce or the likes.
  3. Bespoke/custom software developed by a third party, an internal team of developers or a partner organisation.

Step 2: Classify the types of costs associated with each of your software solutions

The second exercise is to consider the types of costs applied to the software types you have above.

Generally speaking, most people will break down these costs into three categories. These categories follow the life cycle of a system within the organisation:

  1. Commissioning costs
  2. Operational costs
  3. Retirement costs

Personally I would argue there is also a fourth, procurement, but I will leave that out of the overview right now, as otherwise I might as well write a book. As the plural of ‘costs’ probably gives away, each of these categories can also be broken down into various categories. This brings us to step 3.

Step 3: Classify and quantify the types of costs associated with each life cycle

The third and final step is to break down the activities and elements involved at any of these stages per sofware solution. This ranges from any hardware needed to run the solution to ongoing training needs for your staff and making sure your data are protected.

The list can be very long, and that might be scary. But, if you want to start to understand what value your systems are bringing to your organisation, you will also need to know what they are costing you; to the very last penny!


You can only see and talk about the value of things you are honest with yourself about Total Cost of Ownership

This has been one of those articles that was meant to be a quick overview of the importance of Total Cost of Ownership and the value of software. However, I got a bit carried away, and could have kept going.

It’s a subject DTL Creative know a lot about, and I feel it is one of those areas that, while it is  incredibly important, it is often underplayed in the sector.

Software is complicated in its entirety. It is complex in its architecture, maintenance and all the costs involved with that. However, it being complicated is not an excuse to glance over it or hold up a wet finger in the wind when setting budgets, writing procurement proposals and reporting on the value a system has brought to the organisation. Indeed, your IT set-up can and should be seen as one of the most important assets you have; so why would you not put in the effort and measure its total costs and the value it brings to not just you, but also your stakeholders.

In the end, IT is about serving customers. These customers are not always the systems users as some would expect. It is about the end customer and in the case of Social Housing, it’s the tenant that needs to see the benefit. It is the tenant that must benefit, to be safe, to be warm and to be confident that somewhere down the line the housing provider is using software to improve their lives.


Getting Started: Common costs you need to know to understand Total Cost of Ownership

The following sections discusses per category from step 2 the most common costs associated with each life-cycle. This list is, of course, not exhaustive. So, if you know there’s even more to it, add that to your spreadsheet as well!

Commissioning Costs

Costs in this category are all the costs incurred when implementing new software. These include initiation and start-up costs. I don’t like to teach folks to suck eggs, but it is worthwhile listing just some of the basics here.

Software.

Software such as housing management systems usually have an up-front software cost plus user licenses, based on assets, users, etcetera. But make sure you understand them fully.

Hardware.

As far as hardware is concerned,the cost of servers and applicable, dedicated, storage to run the software is obvious, but what about and other costs like backup and disaster recovery.

Integration.

These days, very few systems work in isolation. This means they require interfaces to other systems to reap the overall benefit. You will be very likely at some point have to pay to get one system to talk to another. This could be from a third party asking for development time or internal need to assign resource, contractor, or to buy some development tools. Everything is always possible here, but at a cost, and it’s not always straight-forward.

Training.

Sometimes forgotten, the cost of training users applies to all types of software, with varying degrees of need. The training may be internal costs if you haver built it yourself or external costs from suppliers.

Customisation.

Different landlords have specific ways of doing things, so account for this in any customisation you may need to off-the-shelf solutions. It may simply come down to a few small tweaks, but perhaps it is a larger more bespoke adaptation. Whatever it is, it should be calculated in the TCO.

Project & Implementation.

The cost of building and testing software is one thing, but remember the actual resource needs to be accounted for. You may backfill, employ specialist skills or consultancies. There are also costs of setting up things like backups, contingency plans, backups and so on.

Data migration.

Data is a big one. We know that a great deal of suppliers will only help you part of the way in data migration. The cost of moving data from the legacy system to the new system can soon add up and increase your Total Cost of Ownership.

Operational Costs.

Costs in this category are all the costs incurred in the day to day running, maintaining and using of any systems and applications you have, both hardware and software.

Software maintenance & support.

This obviously does not apply to cloud software. However, for software products you have bought off-the-shelf you will have signed up to support agreements that may or may not include patches, version releases and bug-fixes. The small print is the important aspect here. Know what you get and what you don’t get and cost accordingly in your TCO.

I won’t go into Escrow agreements here, but you should know if you have one or not. I’m personally not a fan in case you are remotely interested.

Licenses.

For off-the-shelf software, as the number of users grows in the company, new licenses must be purchased. If the number of users decreases, there are no refunds. For cloud software, licenses are typically priced per month, although they usually require an annual contract. Note that if the number of users increases, this cost increases. If the number of users decreases, this cost may decrease but often only when the contract is renewed.

Ongoing Support.

No matter how it is provided, helpdesks and administration is a must. You may have analysts and developers the system as well. One option here is to calculate costs based on user numbers, and factor in the costs of managing them either all-in or as department service costs.

Ongoing Training.

From time to time, you will have new users, new starts, or perhaps something bigger like a merger where hundreds of new users find themselves with new software at their fingertips. They will need trained, so where you can budget, where you can’t add it in during the years spend.

Adaptations and Enhancements.

Things change, it’s a matter of fact. Sometimes it can be regulatory things such as Decent Homes, it could be a new control such as GDPR or perhaps some company restructuring. Whatever it is, it will more than likely require some software changes.

Upgrades/Version releases.

Off-the-shelf software will have upgrades over its lifetime. They can be time-consuming, risky but also costly.

Disaster recovery & Business Continuity.

The provision and cost of a backup strategy is one thing but so are things like testing. Have you a strategy and cost plan in place?

Environment & Sustainability.

What about electricity/power, environment and sustainability? The costs of running the software in your server room like power, cooling and floor or rack space. You can add on security, alarms, suppression systems and so on here as well to calculate how the systems you use affect the environment.

Depreciation.

Your finance/accounting department will love that you do this. Writing off the capital cost of the software and the hardware it runs on is very important but often overlooked. You obviously can’t do this in cloud-based services.

Security.

The costs of keeping your systems secure is not just in the code and the permissions of users but also applies to how you manage cost apportionment to firewalls, anti-virus etc. What about penetration testing. Have you thought of that in your TCO model?

Retirement Costs.

From time to time, you will cease to use some software. A fancy word for this is retirement. There are costs incurred when retiring software that will add to the Total Cost of Ownership. However, as well as the costs in transitioning to a replacement, some companies do not take into consideration that retired systems can still incur ongoing costs.

Accessing and Storing Historical Data.

As mentioned, data is a specific area where you may find it expensive to migrate data out your old and into the new system. While you may have decided against migrating specific (often transactional data) directly into your new application to save costs, there are various reasons to keep those historical data available somewhere else, not in the least for legal and regulatory and compliance purposes, but also to ensure that any ongoing chased debts are not lost.

Whatever the reason, if you don’t migrate it, you may have to pay to access it. Like all the specific areas in this article, there are more details to consider, but as you will see it is a large and important area worth serious consideration. Because, well, let’s be honest, how often have you seen existing suppliers be helpful in such areas. You have just gone to their competitor, so why would they ensure the data from their old systems will remain available to you for free? So, decisions need to be made and some of these will cost money that should be included perhaps in the TCO model for the new software.

Parallel Running of Legacy System(s).

Another example is a situation where legacy software may have to run in parallel to the new system for a set period, which, while often forgotten about, must also be costed.


Application strategy roadmaps plot your business journey

Application strategy: what #ukhousing leaders need to know

Application strategy: the most exciting #ukhousing topic? Maybe not, but it’s key to aligning your IT tools with business objectives and improved data intel.

Who needs an application strategy, anyway?

The case for an application strategy starts at executive level. Social housing professionals often ask how technology can help them achieve their business objectives. You might want to:

  • Better mitigate risk 
  • Expand your digital offer to customers
  • Be more proactive with reporting and governance
  • Improve value for money.

Many housing associations aspire to achieve an omnichannel service delivery model. This is where customers get consistent service, no matter which channel they use. Someone might apply on a website, then switch seamlessly to an app. But if a problem occurs, they can also phone the housing provider and speak to a person who can chat about their contact history.

These aspirations are not easy to achieve for many housing organisations. For example, if you previously procured a payments portal, then developed separate repairs web functionality later, the two systems may not talk to each other or share data. This can lead to a disjointed customer experience. The more standalone bolt-ons you implement to satisfy immediate needs, the harder it gets to create seamless services.

Clues to look for

Many housing providers have developed a sprawl of applications over time. That’s not surprising. When you’re running services day-to-day and fixing problems, it’s not easy to stick to a long-term plan; service delivery often takes top priority. Adding in the cultural challenge of trying to change systems that colleagues know (and even sometimes love!) can be tricky.

Sometimes you need an external trigger – perhaps a contract ending, or advance warning that software will not be supported in future, will prompt change. These events focus activity on selecting replacement options.

So what clues can help you spot possible challenges? The spreadsheet trail is a good place to start. It’s almost a ‘given’ when I start any review, that I’ll find teams who have lots of spreadsheets that supplement other systems (asbestos, gas certificates and anti-social behaviour are common).

Another clue involves understanding whether your data can help you achieve your long-term vision. One recent housing client wanted to remove barriers which were preventing their team delivering great services at first point of contact. They found that data conflicts between applications in their service centre, and staff having to jump between various applications, was causing bottlenecks.

In a time-limited, resource-constrained world, many housing professionals still work on a tactical basis. With reporting, monthly traffic light systems are good to track ongoing performance, but they don’t help with the bigger question of how services could be delivered more efficiently. And they don’t help you predict how doing X instead of Y might affect your business, or its customers. That’s where an application strategy can make a big difference.

Two key elements

There are two key elements you need to focus on to have an effective plan for your applications:

Application strategy

The process starts with your business plan and organisation values. It’s your ‘why’ and sets guiding principles to follow. Like any strategy, you need a clear vision and a clear picture of what a good result looks like. Think strengths, opportunities, aspirations and desired results.

By the end of this step, you’ve mapped all your current applications. We call this the ‘as is’ map. Now you can see where systems overlap or conflict and spot gaps to address. 

You might have aspirations to use predictive analytics and modelling. If 50 per cent of your customers pick up the phone, but you could encourage half of them to self-serve, how much could you reinvest in other services? Or, if you have data system and service silos, how can you change that and explore how cross-service links affect complaints?

Now it’s time to create a future state diagram; the ‘to be’ model. This should be more streamlined than the first example. It’s where you’ve removed overlaps, improved integrations, retired unnecessary applications and so on. It might also introduce new layers, such as customer relationship systems, a knowledge base or improved reporting functionality.

Application roadmap

Armed with a clear strategic direction, it’s time to look at your planned journey and build the roadmap. This builds a series of steps and a timeline, with costs to show how you’ll get from A to B.

Your choices will depend on past decisions, application availability and available resources. If you’ve recently implemented a new housing management system, you probably don’t want to rip it up and start again. But any systems due for replacement will be high on your list of priorities. The same goes for any systems that won’t be supported in future.

An application roadmap takes time to deliver. Two or three years is common for many housing organisations. The trick is to stay focused on your overall business objectives and keep track of progress. As each system comes up for replacement, you can then change things with your ultimate goal in mind. And if the unexpected happens (in other words, always!), you can adjust your strategy to reflect changing business and customer priorities.

Application strategy: in-house, or consultancy support?

Many housing associations and local authority housing teams already have their own IT specialists. You may wonder, do you really need external support for this task?

The answer is (drumroll…) it depends!

With a large technical team, you may have scope to reallocate resource away from day-to-day work – assigning dedicated IT professionals to conduct a market assessment and build the strategy and roadmap.

But few housing providers have this luxury, and that’s typically when people turn to housing technology consultants like DTL Creative. Consultancy support can bring in much-needed market knowledge. And that’s critical if you want to understand:

  • What is considered best practice in the housing sector
  • Which applications the leading IT providers are working on
  • What emerging technologies are on the horizon, but not yet implemented
  • How other providers with similar challenges are facing application challenges. 

Bringing consultancy experts in can ‘extend your workbench’. This complements in-house skills and provides more hands on deck.

Final thoughts

Building an application strategy is not about technology in isolation. It’s about how IT supports your business plan and business objectives. Like any strategy, a big part of this process involves consulting with service managers, to make sure people are on board and clear about future direction.

It’s also a great catalyst to explore what value systems are bringing to your organisation. For example, if you’re only using 10 per cent of a system but paying for 100 per cent, does this suggest an opportunity to get better value for money? And what potential is there to use emerging technologies to improve customer service?

Mapping this route takes time, but it’s worth the investment if you want to bring about lasting change in your business.

Fancy a chat?

If you’d like to know more about application strategy support, please contact our consultancy team for an informal conversation.

Further reading

Management consultancy services

Recent case studies

A story of data and perseverance

Let me tell you a story about data. Why? 

Well, I (and many others) believe that story telling is important in business as it gives a real-life insight into how things come about, uses less business jargon, and can bring to life a specific journey without the need for a presentation or anything other than a story. Of course, the story must be true.

A long, long time ago…

This story begins 4 years ago late in the evening in a hotel bar in Aberdeen. I was with my rugby club’s mini’s youth tour. I was a coach and a so-called responsible adult. Hmmm. Our kids were running about causing havoc in the hotel when some of us parents were sipping an orange juice.

There were two other parents that I had not met before and I got talking to, and as luck would have it, we had hit upon the specific topic of data after we got to that moment when someone says: ‘What do you do?’. 

‘I have worked in IT and Systems for the last 3 decades’ I told them, and now own a business delivering consultancy in the social housing sector.

They both owned a data science company that had grown considerably and was delivering great projects for a wide range of companies worldwide, all in the private sector of retail, banking etc. 

Some great customers there I said and jokingly (those who know me, will know I can just blurt things out in the moment) asked if they have ever done work on data in the public or third sector. 

They hadn’t, but there in lay the challenge.

‘Why not?’ I asked.

Our first steps in #ukhousing

This was four years ago, give or take a few months, so those reading this from a social housing track will know that although some were looking at data analysis, reporting (yuk), even a dashboard or two, it wasn’t by any means top of the social landlord’s agenda. 

‘It never hit our radar’ they said, and ‘nobody has ever asked from that sector’ they supplemented. 

I know I used to be a lot more critical back then. I was after all still a young pup in my forties, albeit my late forties, but I did say that one of the issues with the social housing sector, and still is to a degree, is that they are very insular and don’t look for solutions or best practice from the outside. 

So, was there a way we could join forces to look at data solutions for the sector by using my consultancies knowledge of the sector and their specific expertise in data science and engineering?

You bet there was. 

We designed some services that brought data analytics and Power BI dashboards to several landlords, and it worked well. However, in business some things throw you off-piste. In this case, they were acquired by a large American company and were taken in some different directions that meant our dream of saving the social housing worlds data-based problems through data science, engineering and problem solving was off the table.

And that was that.

Let’s try again!

Until that is the founders of that business, the two I bumped into that night recently brought up the subject of trying again. They now had a new business full of talented data scientists, engineers, analysts, and problem solvers.

And so, we did try again. This time it’s even better, and it’s now a service that is about to make some serious in roads to helping landlords with their data-based problems. 

We both love that joining of forces where we can bring some of the UK’s leading minds in data, working alongside my own company that is so determined to make a difference and create change in the sector, this time with one of your most valuable assets, and you could argue, perhaps over that late night orange juice, your most important asset. Data!

Find out more and get in touch about our brand new Data Improvement Services.