Technical debt – when the bank really can’t help you out

Not long ago I had a brief 2hr session with a client who were looking at implementing a collaboration platform (read: SharePoint) to support their massively growing business. The discussion as usual went around platform/product capabilities and as usual the topic slowly venture into requirements and different scenarios that the client wanted the system comply.

Due to the growth of the business, all internal systems had soon been left behind and simply couldn’t cope with the expansions – this is often the case for companies that doesn’t factor IT into their business model. Luckily for the client, most of the OOTB capabilities of the product supported directly what they needed, but a few didn’t. These were for the client seemingly extremely important and a custom solution would most likely be needed.

If you’ve ever spent any time in a meeting with a sales representative, you’ll know that the general consensus is to sell – yeah, go figure. But as a consultant there’s always areas that you really need to be careful of entering into – and this is where you need to have an open and honest discussion about the impact a system can have to a business.

Picking a solution (No, you are not given a choice)

Naturally most companies employ consultants because they know that it’s not their core business. So looking at the reasons to adopting a system (any system), from the business perspective, there’s:

  1. The need to increase productivity, or
    • The need to decrease deficiencies in current system
    • The need to cut cost of productivity
  2. The need to introduce controlled/improved processes
  3. The need to expand, or match a shifting market, or finally
  4. The need improve on system quality

It’s a very broad non-specific and/or descriptive list but covers the various models used by management consultants (including PI-MDD, which from a consulting perspective is my personal favourite – that quite often goes against the grain, especially since I’m predominantly a SharePoint consultant). I’m not going to into the how and why of modelling these things, because I don’t have any formal “Consulting” education (can you even get that?) – but i digress – the needs and context needs to be detailed, which is where many smaller corporations don’t see any value – “We know our business and don’t want to pay YOU to tell us about it” – so they find a budget, which rarely actually has any foundation in either context or need, but a “This is our budget, get it done” perspective. The next step is then to either find a solution provider or a product.

The model here is pretty cost higher than budget.

Double-click, Next, Next, Next, Finish

Once a solution provider has presented a “choice” which matches the “budget”, the time comes to integrate the solution. A short stint from an onsite specialist and you’re up and running. Some time allocated to “Power training” and the business now has a Best In Breed solution. Exit stage left.

At this stage there’s already conflicting ties between the Need and Context. Initially there’s a drop in productivity because most users are having to learn on the job, perhaps mistakes even occur? orders are lost, tasks are left incomplete – and this is were human ingenuity kicks in and the proactive folks simply circumvent the system till such a time as the system can be “fixed”.

What occurs in this instance is a dramatic drop in ROI – the system is not doing what it’s meant to do and staff are either slipping back and using what they previously used or are making up new processes in order to meet their KPIs or deadlines. After all, business must go on and the outcome is “the system doesn’t work”.

Utopia doesn’t exist

Most platforms seems to have a lifecycle that spans over 5 to 7 years before being replaced/upgrade.image

In the period between introduction and end of life – the utopian fantasy with software is that there’s no cost involved with it. Once it’s bought and installed, everything takes care of itself.

Ok, realistically most have an idea that software does need to grow, so storage, backups and servers are all part of the “natural” life of having a software platform.

The decisions to adapt a platform is far more intricate than that. oh, vendors will sell “support and maintenance agreements” to you at a % price. For that you’ll upgrades/updates, patches and an offshored support email that you can use to contact them if you do need some assistance.

But mostly the vendor relies on partners and/or solution providers to take care of that for them.

It’s here that technical debt comes into play and it’s where vendors or solution providers doesn’t want to go. Yes, I’ve just sold you on the idea that you should by my services or product, at a concise price, why can’t I declare all the costs to you right now?

There’s a natural increase in cost associate with a software platform – it comes in the form of both financial and resource efforts and it could increase the investment figures by up to 20% per annum, of the initial purchase cost, very easily.

Technical debt can be calculated – but it’s very complex so I tend to use an analogy to explain that adopting a platform is much like having kids – there’s an initial phase of excitement, followed by a sense of dread because the project is taking a long time and concluded with the reality that it’s a never ending cost that didn’t just stop when the kids left home.

When decisions matter

It’s always hard to sell a software platform/solution based on a high upfront cost, hence why most don’t do it, whilst there’s a seemingly ignorant belief in the fact that off the shelf packaged software doesn’t carry the debt as well.

Most have heard that a bespoke solution is too risky – hiring some developers to slap a system together and then call it a solution is risky, especially when approached like that.

Can you quantify the exact cost for any system? for most, no – there simply isn’t that much tangible proof to state what that figure is. Like with anything else, there’s a risk involved with the business having to change too frequent, which leads to either an out dated solution or a high cost in retrofitting it to meet the new needs.

Yes of course there’s a banging good approach that’ll be offered when this happens – lets go agile!!! For seemingly unknown reason, companies has now decided that agile is risk free. But it still doesn’t eliminate the technical debt that’s accruing – of course not, since the changes to the system is going to cost money and effort.

In conclusion

The only decision that really matter is an informed decision. Go into the adoption process with both eyes open and on the prize. Be aware of all facets of solution adoption and be realistic. The fact is, if your budget cannot sustain the system it needs in order for the business to prosper, then your business model is wrong.