Getting transformation done right; observations from the field.

As deeply entrenched in customer transformation projects as we are, we get the opportunity to observe both the triumphs and troubles that accompany a project that we are called into assist. From the highs of successful implementations to the lows of projects gone wrong, over the years the A-Team has been operating we have gained some invaluable insights.

Throughout our engagements, clients have entrusted us with ‘saving the day’ when projects are teetering on the brink of failure. Although there is a degree of pressure to get it done right, we do get a front-row seat to the myriad reasons why transformations struggle, and in some cases, falter altogether.

Over the years, I have observed patterns that have emerged, revealing recurring themes that transcend projects into struggle, or even failure.

In this blog, I will attempt to discuss these patterns, sharing the behaviours and expectations that initiate and contribute to a smooth deployment.

I’m going to park methodologies and project management, these are obvious and, are table stakes in any project. If people don’t adopt at least the latter, then there is little to no hope in making a success of any project.

Instead, I would like to focus on the obvious, which is not always obvious: behaviour, mindset, approach, and alignment.

Why IT transformation projects fail?

In the realm of IT transformation failure, and when I say IT transformation, I am referring to the movement from on-premise IT service/infrastructure to platform and software as a service primarily, as this is where we work.

Failure is an all too familiar (at some level) occurrence even the most meticulously planned projects. And to level set, when I say ‘failure is an all too familiar…’ the A-Team is most often brought in when there is a significant failing somewhere.

At the heart lies a combination of factors, each contributing to the downfall of what initially seems like a promising plan.

The following sections are listed as observations. They are not intended to be a complete list, merely the key themes I have seen.

After each observation I provide an anonymised example of the most memorable situation that encompasses each observation. My intention is to bring my point to life, adding context to what we experienced, the impact and what was done as an alternative.

Observation 1. Lack of alignment.

One of the primary reasons is often a lack of clear strategic alignment between the IT Initiative and the overarching business objectives. ‘That’s obvious!’, you may say, but you will be surprised. What is said, and what is done can differ greatly. Time, misunderstanding, skills, people moving off and on the project team, all cause the evolution of the situation, intentionally or not!

Without a cohesive vision that ties IT initiatives directly to the organisation's mission and priorities, projects can easily veer off course, leading to wasted resources; creating ‘technical debit’; and missing opportunities for value creation.

Example: We were asked to support the system integrator in optimising performance for the customisations written in PaaS which was to be deployed against SaaS, as the customer had very specific processes/workflows that they wanted the application to support. We were asked to review the configuration and architecture with a goal of increasing performance. The processes involved required multiple steps through a complicated workflow.

The project was severely delayed, as the processes were not fully documented, and only as the project moved forward the system integrator discovered the idiosyncrasies surrounding the way the customer operated their organisation.

When my team looked at the architecture and workflows, we could provide a perspective on optimising the process rather than developing complex customisations.

We spoke with the CIO and delivered our findings during one of the steering board committee meetings. We asked why the processes were set in this way, and would they be open for us to provide recommendations on how they could be optimised, which would intern simplify the complexity of the customisations.

We were told the processes that were in place had always been that way. They hadn’t really looked at, or thought they needed to optimise them.

They were very open for us to provide constructive feedback and we built a set of recommendations, with the majority being accepted.

The key point here is: Aligning IT to deliver for the business is one thing, but aligning the business processes to meet the current operating environment should also be done in parallel.

Observation 2. Lack of stakeholder engagement.

Another significant challenge is inadequate stakeholder engagement and communication. Effective transformation requires buy-in and collaboration across various levels of the organisation, from the C-suite to frontline employees. When key stakeholders are not sufficiently involved or informed about the goals, progress, and implications of IT initiatives, resistance can emerge, derailing even the most well-intentioned projects.

Furthermore, the complexity inherent in many IT transformation endeavours often leads to a lack of clarity regarding scope, timeline, and resource requirements. Ambiguous project boundaries and unrealistic expectations can create confusion and frustration among team members, making it difficult to maintain momentum and achieve meaningful progress. Additionally, the failure to adequately address technical debt and legacy systems can impede progress, as organisations struggle to reconcile past investments with future technological imperatives.

Example: The requirement was to support high volume extraction architecture as part of their ETL strategy. The head of operations was requesting near real time extraction to meet specific business objectives around compliance reporting.  

When we engaged the team, we change the conversation to better understand the business reasons surrounding this request, moving the discussion from a technical conversation to a one that centred on business-risk.

We worked with the head of compliance to further understand their needs. It turned out that they didn’t need near real time extraction, in fact, they needed to satisfy the respective governing bodies within a defined period, and the SLA was 24 hours. This didn’t require near real-time, that was far too much of a solution for their needs.

It then transpired that the IT department were not fully appraised on the exact requirements. The cost implication of near real time extraction versus a timed extract is quite considerable, and after the holistic business looked at the cost versus risk element. They decided to go for out recommendation, that was to adopt the more cost-effective timed-based extract route.

Observation 3: Lack of change control.

I know, I said in my opening remarks, I wouldn’t talk about project governance, but I simply can’t help myself with this one; change control is so important! Documenting what you are intending to do, and the iterative changes, with timelines and justification create historical log of what decisions were made, and why. We see too often the lack of documenting alterations as the project moves forward when something new as learnt.

To this, inadequate change management practices represent yet another stumbling block for IT transformation projects. The human dimension of change is often underestimated, resulting in resistance, scepticism, and morale issues among the project team. Without effective change management strategies in place to address shifts, skill gaps, and organisational dynamics, even the most innovative technological solutions are doomed to falter.

Example: A customer wanted understand why their PaaS consumption was growing exponentially and above the forecasted spend rate. We worked with various stakeholders; from the CIO to the project team to better understand their needs and use case, incluive reviewng all active services.

We found that the IT team responsible for the services deployed, were spinning up additional PaaS services to test and evaluate. There was no documentation in terms of what they were doing, and they were doing it; simply put, they were playing with technology. Now you may be reading this and thinking, that’s a great way to learn, and it is. However, they were not spinning down the services after their use. They left them online. This was expensive especially when they spun up multiples of ‘extreme performance’ database services. We identified the services were not in operation, and once they were spun down, so was did the cost.

Observation 4: Technology investments need to deliver value back to the business.

It is crucial to recognise that technology investments should always aim to generate incremental business value. However, there have been situations we have been brought into, where the customer has requested heavy customisation of SaaS, via the use of PaaS to ‘shoehorn’ the service to deliver on existing organisational processes.

In these situations, the focus of transformation had adopted an incorrect mission of forcing a by-product to happen. Whereas in all cases the original requirements were to update existing services to deliver an incremental benefit to the organisation; the two most common being financial management and operational efficiency.

This erosion of the mission during transformation shouldn't just be about preserving the status quo; it should also stimulate the question of “…are we doing things right; what could we change to be more efficient and agile?”

You should always ask these questions and if necessary, overhaul outdated processes to drive efficiency, innovation, and ultimately, greater value for the organisation.

By ensuring that technology initiatives are closely aligned with strategic business objectives and accompanied by corresponding process improvements, companies can unlock the full potential of their investments in Cloud and stay ahead in today's rapidly evolving landscape.

Example:  We often see a positive use of PaaS to extend SaaS, such as bringing in new organisational capability to enhance the employee experience. One noticeable example was for an organisation,  where the requirement was to develop a mobile app to allow the timekeeping of their workforce. This was a positive change of process to enhance a way of managing timesheet.

However, the converse to this has been organisations that are rigid in their approach of how they like to operate. There was just one example where the CIO had such a legacy mindset in terms of how they wanted to manage the cloud data. They transitioned to the cloud for financial management reasons, but thereafter wanted to completely extract all information, and move it back into their on-premise data centres, so they could manage and control downstream operations which were, mostly in the cloud. This extract, transform and then re-upload was a costly and complex initiative, but this is the way they’ve always done it.

Providing a holistic review of the end-to-end architecture, we could provide suggestions on how further use of platform services could assist in removing the need to go to on premise systems, which were, effectively re-routing data back into cloud services. There was one process for all data. Building out an architecture and compass multiple solutions, gave the organisation greater agility and delivered on their overall objectives. Sometimes people are so invested in what they’ve created. It’s hard to look at what the alternatives could be.

Observation 5: Having the right people, with the right skills in the right roles.

A people-focused strategy lies at the heart of successful transformation project, as it supports the delivery and for creating and delivering value. Central to this strategy is the recognition that the skills and abilities of individuals within the project team will define success or failure; people are the most valuable asset to an organisation; by leveraging your employee talent pool, organisations can harness the full potential innovation, adaptability, and sustainable growth.

However, sometimes organisations do not have the required skills to transform. They may be good at running the operational aspect but transforming the environment for the business processes to run against, maybe beyond their skill set.

This is when turning to the vendor for help or engaging a qualified partner/system integrator can add value. A third party can greatly add to the project by bringing specific skills and experiences to the table, that will allow organisations to accelerate the project.

In an ideal world, organisations would use the opportunity to get their people to shadow external consultants during the transformation project, to develop new skills and abilities. Having this shadow approach baked into the contract can provide additional coverage to the project and facilitate knowledge sharing. Investing in employee development, training, and upskilling initiatives not only enhances individual capabilities but also cultivates a culture of continuous learning and improvement, essential qualities in today's dynamic business environment.

Utilising a consulting organisation will allow organisations to embrace a diverse set of experiences and perspectives that taps into tacit knowledge. Tacit knowledge encompasses the implicit understanding, insights, and intuitions that individuals accumulate over time through their unique experiences and interactions. By tapping into this collective wisdom, organisations can uncover innovative solutions, anticipate challenges, and navigate complexities with greater agility and effectiveness.

In essence, focussing specifically on a people-focused strategy as part of the project that prioritises skills development and embraces diversity of experiences not only enhances project agility and resilience but also serves as a cornerstone for creating and delivering enduring value through the transformation journey.

Example: Not having a clear people strategy in relation to the project, is something we don’t often find; though there have been a few instances where this is occurred. Once such situation was for a customer that wanted to develop new ETL pipelines for new services, specifically for Big Data and WebLogic. They had experience with managing data integration but lacked the ability of understanding design/configuration specifics in relation to these new services. Although, the service question was ODI, and it has pre-built connectors for seamless integration, they didn’t possess tacit knowledge needed to effectively provide an optimal design for the pipelines and workloads.

They came unstuck and ran into challenges, and because we’d work with them for previously, they reached out directly to us for help. My team quickly mobilised and provided the necessary support, allowing them to design, build and deploy the connectors for their use-case.

Although small example, it still highlights the need to effectively understand the skills required to deliver. Technology supports a business process or operation, and if incorrectly deployed will have a potential impact to the end operation in question.

Conclusion.

In conclusion, the landscape of IT transformation is fraught with challenges and pitfalls that can derail even the most well-conceived projects. By addressing issues related to strategic alignment, stakeholder engagement, change management, and adaptability, organisations can mitigate the risk of failure and pave the way for successful transformation journeys.

Transformation projects are an ideal opportunity to look at not only the technology landscape that you used to operate, but also the way that your organisation functions. Vendors and system integrators have a wealth of tacit knowledge that could be tapped into to help optimise all aspects.

We’re not just here to deliver services; we provide a very useful vantage point on how to effectively optimise both process and service.