Transformation, Technical Debt and Toxicity... Episode 1

Episode 1 - Transformation

For the past number of years, I have been assisting companies with large technical transformation & change projects. Here are a few insights I have gained from these multiple companies, operating in radically markets and with diverse business models. Despite being very different organisations, common themes crop up again and again. This is because at its core, a company is its people (both past and present) and by implication it's culture. Their actions (or inaction) have both caused the need for a transformation and are the solution to achieving a successful one.

Why Transform? - scenario 1

Large scale transformations are usually thrust upon a company due to some inflection point in their business model. It could be as radical as an acquisition (or being acquired) or as mundane as loss of market share in a mature business. Sometimes it is seen as a "single event" that changes the focus of senior management (the proverbial "Come to Jesus" moment). These events, that demand a company transform to survive get business focus a little like Hemmingway's bankruptcy insight.

“How Did You Go Bankrupt? Two Ways...Gradually and Then Suddenly.” - Ernest Hemingway (The Sun Also Rises)

The rapid onset of an inflection point forcing a transformation on a company is a fallacy. They just build slowly and then break to the fore. Acquisitions do not happen overnight; market share decline happens over years and "sudden events" are usually the last domino to fall after a series of past decisions. Perfect storms buffeting a sector do not cause business weakness or opportunity, they simply expose them.

Transformation is not something companies set out to do in the normal course of their business, it is thrust upon them. Transformations are a huge disruption to normal business operations. The need to transform may be the key to help the business survive, get on a sustainable path or find its purpose within a larger group.

They offer the promise that a to be state of a business will be better than the current as is. The promise of a better tomorrow. However; transformation is a hard messy business full of toil, tears and sweat and not something any incumbent leadership team volunteers to do.

It's not the technology

In the grand scheme of things, successful technological transformations have really little to do with technology. Moving from technology X to technology Y or from "on-prem" to cloud is simply a matter of time and money that can be forecasted/budgeted beforehand. Once a decision has been made to transform it becomes almost mechanical.

Consultants (people or firms) with specialist technical knowledge can be hired to bootstrap or architect the transformation for a finite period, upskilling of in-house staff on this technology along the way is a defined process. All this just takes time, money and willingness to achieve. - Just remember that Hofstadter's Law[1] as always, comes into play.

Of the three elements (in ascending order of importance), to succeed with a transformation are:

1. Money to transform
2. Time to transform
3. Willingness to transform

Money to transform

While obvious, any transformation needs a justifiable business case. This comes down to articulating how much to spend and for what benefit. This may be a newly acquired company's systems being digested into a larger group or the refresh of a known set of IT assets that are no longer fit for purpose. At this point it is vital that a realistic cost-benefit analysis has been completed to set expectations for the organisation before commencing a transformation. This analysis is fundamentally the why of doing the transformation. How else can you judge the final level of success, failure or even the ongoing progress of the transformation.

A realistic cost-benefit analysis must be completed and communicated to set expectations for the organisation before commencing a transformation

The common factor here is that these are run of the mill project accounting methods that are already used in the Business As Usual (BAU) operations of your organisation. They are simply being applied to a new set of projects. The seeds of success or failure in the perception of the transformation's progress are sown here. Failure, or a failing transformation programme, can be judged and quantified in terms of cost and time overruns throughout its lifecycle.

The hard truth is many transformation projects fail or do not meet expectations in terms of their return of investment to the organisation. Either bad analysis or bad execution (or both) cause this. This is unfortunately a very common result with transformation projects. So much so, that an analysis of over 5,000 large[2] IT projects, showed that on average, these overran their budgets by 45%. Yes, almost half again of the initial budget was spent. It gets even worse! just under a fifth (17%) go so bad they threaten the very existence of the company[3].

In all probability you will blow your budget by 45% and there is a significant chance a large transformation will destroy your organisation

This sobering thought should be realised before you contemplate any large transformation project.

Time to transform

Once the accurate budgets have been approved and you realise the fallibility of this planning process, it is time to start transforming. Estimates of when it will be done & how much it will cost have been given to senior management and the SteerCo meetings start. There are at least 2 competing factors here. Maintaining your current business while simultaneously transforming it. This is the infamous "changing the engine while flying" mode of operation.

Kill what you can, double everything else

A somewhat neglected aspect of transformations is that is should first be seen as an opportunity to clean up what you have already before you transform. A like for like transformation of current systems and processes, the veritable lift and shift is a recipe for failure. The need for technical transformation is, in all probability, driven by a lack of discipline with managing incumbent systems and the inevitable spectre of Technical Debt[4].

There will be undoubtedly be some systems lurking in the organisation that are not essential and are a drag on the business. These need to be found and de-commissioned before a transformation. The benefit here is twofold as a) it will make the business more cost efficient immediately and b) make the size of the transformation smaller; a win-win. It is also important that as the transformation progresses, anything that can be de-commissioned due to the transformation should be retired as soon as possible. Don't "lift and shift", "clean first, lift, shift and kill".

Don't forget BAU

Technical transformation projects are usually seen as the "cool" work for the development, project and infrastructure staff. Who doesn't want to work on a green field project with shiny new toys. No support calls, no endless debugging and a chance to demonstrate deep architecture skills and have a real impact. If doing a transformation from an existing pool of staff, remember that all resources devoted to transformation are removed from your Business As Usual capability. BAU ultimately pays for any transformation and should not be downsized so much as to materially impact your existing revenue.

If you have a lot of excess capability in your BAU organisation, this is less of an issue (and may be the reason you need to transform). If you don't, you need to hire subject matter experts or external vendors (on a temporary basis) to at least bootstrap the transformation. A note on sourcing external vendors: If at all possible, negotiate a fixed price contract for a well-defined scope of work. Time and Materials contracts place all delivery risk on the organisation, not the vendor and should be avoided if possible.

Remember when you are doing a transformation, your technical and operations organisations could be doing double the normal workload, both running the business and changing the business. Towards the end of a technical transformation the business will in effect be operating double of many things, the current and future systems. Everything will be doubled; costs, support overhead and maintenance. This needs to be accepted, scoped and planned for.

Similar to the track record on budgeting described above, large transformations also have a long history of failure in terms of time overruns. The same study revealed that time overruns average at 7% of initial project length. For software transformations, this balloons to 33% longer. This is the proof of Hofstadter's Law in action. Compounding this failure was also the finding that the average large transformation programmes deliver ~50% less benefits to an organisation than initially anticipated.

The more complex the transformation the more inaccurate the time estimate becomes. The longer the estimate is to completion, the higher the chances of an overrun.

Hofstadter's Law - It always takes longer than you expect, even when you take into account Hofstadter's Law

As a transformation progresses, the time to completion becomes a constant...always X [days | weeks | months] away

Willingness to transform

Hopefully pitfalls of underestimating the time and money required to complete a transformation are avoided. It is not all plain sailing however and the unknown unknowns (things that are not only not considered, but are so unexpected they cannot be considered) will then come into play. Most importantly they spring from organisational culture and the willingness of staff to transform the organisation. But people hate change; or rather they want things to stay the same but get better. Cultural transformations are far harder to implement than any technical book of work. To paraphrase Upton Sinclair:

Never argue with a man whose salary depends on not being convinced

Getting an organisation's people to embrace change means they have to be convinced that the transformation is good for the company and themselves. Top-down edicts will not work. Any time spent communicating the need to transform the organisation is time well spent. Badly communicated transformation programmes will result in a loss of morale, an exodus of staff (with the invariable loss of institutional knowledge) or worse still can initiate an active undermining of your technical transformation. Turning your culture toxic[5] is not a transformation you want occurring. These factors will impact your BAU functions first.

Senior leadership should also make an honest appraisal of their current staff's capability to execute and absorb a transformation. Wishing does not make it so. If a transformation is seen only through the lens of a new delivery objective without regard to the current capabilities of the company, (with or without consultant backfill), stability and cost control will suffer. The transformation will become a death march, increase toxicity in the organisation and hasten staff departures.

Staff working on the transformation who embrace the opportunity will be less of a flight risk, so choose which in-house staff to be seconded to help the transformation with care. Technical skills play a part but also their current level of knowledge of the company and an ability to navigate processes effectively are just as useful to the eventual success of any transformation. This is where you will find unexpected help from staff whose softer skills you may not have realised. All your staff should be given an opportunity to make the transformation work.

A transformation programme, as mentioned already should seek to "clean first, lift, shift and kill". The "clean" and "shift" parts of the process is also a great opportunity to undertake knowledge transfer. That is getting institutional knowledge out of people's heads and disseminated more widely across the company into corporate wikis and knowledge bases. This reduces any "key man dependencies" that may have built up over time in current platforms. Transformed systems should break with any documentation bad habits of the past.

Why transform? - scenario 2

Finally, what should not be fully discounted is the effect of new senior management driving transformations early in their tenure. This is most prevalent where the transformation is post-acquisition of a company or where a new senior leadership team is hired en-masse. While it is only natural for new leadership teams to try and have an immediate impact on the business they have been tasked to manage, (indeed that is how many reached this management level in the first place). Is this well-intentioned desire to have an immediate positive impact best for the business itself or for the good of their own career?

Sometimes doing nothing before a transformation is a wise option. This is a diametrically opposing view of the "first 100 days" style of management common nowadays. Doing nothing does not mean learning nothing. By observing the "steady state" of the business (even if in decline) over an extended period will give an even greater insight into what really needs to transform and makes it more targeted. It removes traces of vanity from transformation decisions and I believe increases the chances of the transformation being a success.

Transformations are important, you should justify not only the "why?" but also the "why now?"

In Summary

The average transformation costs 45% more than you thought, takes 33% longer and delivers 50% less than you expect

Transformations should never be embarked upon lightly and:

• Could finally destroy the organisation you are trying to save
• The transformation will cost more than you planned
• The transformation will take longer than you think
• The transformation program will underperform in benefits realised
• The full extent of your current technical debt will be revealed
• You will lose staff during a transformation and hidden gems will be revealed
• You should know the ability or your staff to execute and absorb change
• Cultural transformations are harder than technical ones
• Is the transformation for the business or leadership vanity?

[1] - Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

[2] - Large IT project in this context is a technical project with an initial budget in excess of $15m.

[3] - 17% of large IT projects overran by more than 200% and in some cases 400% of the initial budget, these black swan projects destroyed the company attempting the transformation.

[4] - Technical debt is the subject of episode 2

[5] - Toxicity in business culture is the subject of episode 3