• rm@rmbastien.com

Abused Excuses for the IT Mess

Abused Excuses for the IT Mess

Technology Changes Rapidly

The first excuse for the mess in corporate IT pertains to the fast pace of technology changes. Information technologies slowly get into your organization.  Yes, you read that right: slowly. You might wonder: Isn’t the information technology fast and furiously changing? Not really.  It is actually a slow evolution. The technology changes that make your applications obsolete take years before it gets into your operational IT platforms.  Are you excited as you are about artificial intelligence (AI) and its potential applications to business? I should tell you that AI was part of my master’s thesis back in 1988. That’s pretty slow!

It’s A Long Process

Technologies slowly find their way through research centers, whether in innovative, small start-ups or big IT companies.  They gradually materialize into immature products and their subsequent versions.  They increasingly get adopted through success stories for the brave and horror stories for the brave as well.  Articles are written, then books, and years later the technology may be taught in standard IT school curricula. 

No Need to Rush

So yes, new technologies appear on the market, offering possibilities that did not exist before and making the current technologies gradually obsolete. 

New technologies do not appear with such speed that your IT team needs to rush it without taking the time to manage the overall complexity.

Do not confuse adopting a newer technology and planning the obsolescence of an old one with adding yet another one on top of the pile.  The existence of newer technologies does not justify the multiplicity of IT assets. Having too many hinders your business agility. Those who make the decisions concerning new technologies should be accountable for the global impact not just the immediate benefit for a given project.

Mergers and Acquisitions Create Complexity

The second excuse pertains to the M&A myth. In my career, I have lived through one start-up, three acquisitions and a half-dozen acquisitions. I also experienced one de-spin-off, that is working in a spin-off that went back to the mother company.  And that’s a pretty smooth ride. I know IT people that were in a continuous fury of acquisitions for 15 years in a row.

Each M&A Could Double Your IT Portfolio Size

If your organization has grown through acquisitions, then each takeover, assuming the overtaken company runs a similar business, means inheriting an IT portfolio of about the same complexity as yours.  At the very least, you would be doubling your portfolio with each expansion.  That’s unless you do something about it.  Hence several projects will be launched to unite the IT assets. 

If Rationalization Fails Complexity Spurs

Complexity is sometimes such an issue that, out of urgency or because of the sheer cost of the task to complete the integration, some organizations will decide to keep running applications that they should have decommissioned. 

Now, if you repeat this scenario for a dozen applications, you will end up keeping too much applications.  Repeat this again for five or 10 acquisitions. You now have a genuine pile of overlapping and quasi-identical business applications to maintain. In a way, the why and wherefore of complexity, rationalized to the miseries of M&A, is not untrue at all. 

Casual Business Changes

Putting all the blame on mergers and acquisitions is an easy way out and a fallacious one at that.  After all, an acquisition or a merger is a normal business change.  Such changes are new customers, new employees, a new organizational chart, new markets, new products, new distribution channels, new brands, new assembly lines, new buildings, new production means, etc.  Isn’t all of this normal business change that any system should be able to handle?

Mergers and acquisitions are not a cause for the multiplication of similar IT components.  The true reason is the inability of the systems to sustain business changes. It’s a quality issue.

Why existing IT assets, and especially data and applications, aren’t more flexible in the face of change?   The blunt answer is that they most likely haven’t been designed and built to sustain much change.

No More Time, No More Money

The third excuse is urgency. Resource or schedule issues are over-abused justifications for short-sighted decisions that spread unnecessary complexity.

With IT-based business solutions, you are now aware that there is always a way to make things work.  Worse, many of the cheaper options look about the same from the outside.  Very often, the shoddy stuff is hidden under the hood.  Supplement this with a customer who doesn’t even know how to lift that hood.  Add also that quality is in many areas undefined and uncontrolled.  That’s why budget and urgency become compelling arguments for cutting corners. The main issue with that excuse is that it is always brought in the context of a single project or a single phase within a project.

I cannot count the number of times these projects ended up delayed, despite the shortcuts taken to save time.  Nor can I count the number of times these projects could have managed, if given more time, to design and build the solution properly anyway.  From a budget perspective, these projects were part of a bigger program that ended up, over the next few years, spending tens of millions of dollars. That single project’s budget increase for the right solution was in the end just a drop in the ocean anyway.  Too often, wrong design decisions are made because of immediate project schedule constraints without properly communicating to the business sponsor the consequences for the years to come.

Budget constraints are not the true reasons behind your overly complex and inflexible IT portfolio: short-sighted technical decisions are at fault. 

Is It a Resource Issue or a Planning Problem?

If a project doesn’t have the resources to build your solutions the right way, is it really a resource issue or a planning issue? Most of the time, it’s because the budget did not account for the time to do it correctly. Had it been accounted for in the first place, there wouldn’t be any resource issue. Learn more about the state of the estimation practice here.

Follow me: