A technology spaghetti situation (and how to fix it)
A 9-step framework to streamline technology systems in your organization
Hello to the 1,679 subscribers who read Consulting Intel!
One of the clients I am dealing with is the divisional CIO (Chief Information Officer) of a large retail bank. The institution he works for employs over 40,000 people and generates revenues of over $18bn annually.
This is a reasonably large bank, looking to curtail costs by reducing the number of technology systems it utilizes.
For reference, if you are unfamiliar with the industry, in your average “big bank” you can easily have more than 3,000 IT applications running. The older the bank, the more disjointed these applications will be, and the risk of duplication becomes practically a reality.
Let me make it even more straightforward.
You will have IT systems that do the same thing, bought at different times by different individuals, and are now eating up company money in OPEX and inefficiencies.
This is what I call a technology spaghetti, one that - unlike my favorite Italian pasta - you cannot fix by adding tastier tomato sauce.
My CIO client wants to create an agile and efficient tech environment aligned with his organization’s strategic business goals, and he talks with me to understand how to reach this objective economically.
Let me start with a few caveats.
His job here is really hard.
When you are a technology executive in a large corporation, your business counterparts always tell you that everything is essential and all applications are mission-critical. You can’t eliminate them, nor can you re-engineer your business processes to consolidate multiple apps into one - this is what they all say.
The division, led by my client, will have to make tough, unpopular, and fast decisions, which data won’t necessarily back. Talk about taking a risk…
You may be wondering how the organization got here.
Well, it’s not at all uncommon.
Many companies evolve over time through both organic growth and acquisitions.
They keep adding functionalities piecewise without a long-term vision or care for consolidated architecture. You do this long enough (hint: it takes only a few years), and eventually, you end up with an unwieldy, tangled mess that is expensive and hard to maintain.
CIOs inherit outcomes of decisions taken decades before their time.
They have to live with them and work around the challenges, leveraging the knowledge capabilities they have in-house (which are often sub-optimal) and the consulting partners they trust.
Of course, no bank will have knowledge of all required technology skills available in-house, because that’s not their core business.
After all, they are supposed to be a bank, not an IT company!
You could argue that all organizations these days are tech organizations, just in different verticals. You wouldn’t be too wrong, but you must remember that each firm has its history and DNA: you won’t change that with your 18-month project…
I hope that, by now, I have convinced you this is indeed a tough job, but that’s why we’re here, aren’t we?
For the tough jobs!
And so, how should we approach a Tech Simplification project?
The 9-step Framework to streamline technology systems in your organization
These are the 9 steps we are following to get our heads around it.
1) Define objectives
We kick off the program of work by setting clear, measurable objectives with our clients.
Typical questions we ask include:
What are the critical pain points?
What outcomes does the business aspire to achieve through this simplification?
What dimensions do we maximize to hit “success” (e.g., cost, number of apps, number of processes, etc.)
Establishing these goals upfront guides our entire project strategy.
2) Engage stakeholders
Effective change requires consensus and commitment.
To assess the personnel and rate of transition, we engage a broad spectrum of stakeholders - from senior executives, to daily tech users, to business and technology architects. A comprehensive census ensures everyone across the hierarchy plays a role in shaping the project vision based on their insights, challenges, needs, and requirements.
This approach also helps us mitigate resistance:
If you’ve been involved in the process, it’s unlikely you’ll complain about its outcomes.
In this phase, it is imperative to balance theory and practice: you will hear about many “non-negotiables” that are, in fact, wholly negotiable and often flat-out ignorable.
This is also the moment when you are going to engage with people who might need to push their retirement plans by a year or two because they are the only ones who understand this or that specific application!
3) Gather data
We meticulously collect data on current technology utilization, user satisfaction, system performance, and many more points.
This step helps us identify inefficiencies and align the tech stack with user needs and business operations.
You will also need this data when you attempt to back your case in front of an executive committee. Anecdotes or previous experience need to be supported by hard evidence.
Unfortunately, you will never have all the data, but the stronger your case is, the more chances your recommendations will be approved.
4) Choose tools (the right ones)
Using the right tools is essential for managing complex projects. Tools must be simple to manage, flexible to access, cheap to maintain and easy to scale.
In this type of projects, discovery phase teams are typically small and skewed towards higher seniority: 4-5 expert team members who work largely independently.
We equip our team with robust project and content management software (usual suspects include MS Project, Trello, Confluence, Jira), advanced analytics tools and dynamic visualization software (from PowerBI to Tableau) to streamline our efforts and enhance decision-making.
(BTW: what apps do you use day-to-day for these purposes? Let me know in the comments!)
5) Plan the project
With a comprehensive understanding of the landscape and the tools in place, we outline a detailed project plan. This plan includes specific milestones, clear deadlines, and designated responsibilities.
We strive for transparency and accountability while retaining the flexibility required to ensure we can react if unknown variables arise.
I prefer to keep a weekly showcase to present progress and raise issues with the Steering Committee (a mini-board of client executives internally responsible for delivering the work’s outcomes). This way, we ensure the exercise doesn’t become a black box but a collaborative team effort based on a constant feedback loop.
What about you? How do you create a collaborative environment in your projects?
6) Analyze
Our analysis dives deep into the collected data to identify bottlenecks and redundancies.
We look for opportunities where simplification can enhance performance and user experience, directly supporting the predefined objectives.
We weigh certain dimensions more heavily than others, giving priority to what ranks higher in the client organization strategy (such dimensions change at each company), to develop specific recommendations per the client’s objectives.
7) Report findings
We synthesize our analysis into a concise report articulating our findings and framing our strategic recommendations.
This document is tailored to resonate with all stakeholders engaged initially, providing them with a clear rationale for proposed changes.
This is my favorite step, as we get to advocate for change via storytelling that has to be persuasive and factual. If you are interested, in this article I wrote tips on how to build a compelling presentation.
8) Collect feedback
As mentioned in Step 5, feedback is a gift that we actively seek.
Engaging stakeholders with our preliminary findings allows us to refine our recommendations and ensures the proposed strategies are practical and grounded in the operational reality of the business.
We listen to everybody, and then we adjust our story accordingly...
9) Support implementation
I’m a “consultant”, not a “con-sultant”, so I always like to stick around to implement our recommendations.
The execution involves overseeing several technology deployments, facilitating the decommissioning of legacy systems, re-engineering a selected set of processes, upgrading specific pieces of tech, and conducting training sessions to ensure a smooth transition.
What else?
A key point that doesn’t get enough attention (thanks to
for pointing this out) is about defining the underlying cultural and behavioral norms that you must change in the organization to avoid a technology spaghetti take #2 as soon as the executive team shifts or the attention to this theme fades away, replaced by new priorities.In the comments, via mail, Discord, or X I would like to know what you think the client firms can do to avoid recreating similar tangled technology situations in the future.
If you follow this framework, you should reach a point where you can confidently say you know what actions to take to reap the most extensive benefits for the organization.
The analysis, data gathering, and even the regular reporting and feedback loop are all vital for progress.
In cases where the client organization is not receptive - or the work environment is particularly unhealthy and political - you might walk a torturous path to meeting the deliverables successfully, but the 9 steps mentioned above should allow to curate a collaborative environment to drive long-term change.
Eventually, it is necessary to understand the proof is in the pudding, and execution is all that matters.
✍ The Management Consultant
PS: If you like this newsletter, I have one huge favor to ask.
Share it around with friends, family and colleagues.
This is the most effective way to support me (…and to keep me motivated to continue writing 😁).
Thank you 👇👇👇
🎯 INTERESTING SH*T
A few things I found on the internet that you may like…
- wrote a post that caught my attention, How to be More Agentic:
“Most subject matter is learnable, even stuff that seems really hard. But beyond that, many (most?) traits that people treat as fixed are actually quite malleable if you (1) believe they are and (2) put the same kind of work into learning them as you would anything else.”
This is a phenomenal talk that
gave 10 years ago. Still very relevant: we can all improve in the way we handle rejection!
🚨 SPONSORSHIP
Consulting Intel is read by more than 1,600 consultants globally.
The readers include management consultants from McKinsey, BCG, Bain, Deloitte, EY, EY-Parthenon, KPMG, PwC, Accenture, Oliver Wyman, PA Consulting, and various boutique consultancies worldwide.
Many corporate employees and independent consultants are regular readers of Consulting Intel.
If you think your products or services could resonate with this audience, get in touch!
👀 JOIN THE DISCORD SERVER
If you like this newsletter, you will love our Discord Server.
In there, you will find a tight-knit community of more than 90 management consultants from all over the world discussing real-life challenges, giving each other support and recommending the good stuff to keep our knowledge top notch.
These projects are low in the glamour stakes, a hard slog, and their value underappreciated. But untangling the technology into up-to-date, composable lego blocks to make IT change easier in the future, is a "no brainer" foundation to almost any company in an incumbent industry.
Is the goal to turn it the messy spaghetti into neat and tasty little tortellini?
P.S. Thank you for the shout out on your edited version of this.
This is really interesting, and having been on a long journey to nowhere in my organisation, I think I'd start by having written organisational commitment at the highest level to get this done. If it's the CIO leading the project, do they have the CEO or the Chair or the Board's written support to do it (even better all of them). Because if you have a BIG project that takes a LONG time to implement, and a change of personnel happens during that time, they might simply change their minds!! 😭