Enterprise IT Technology Failures: Which of People, Process or Technology is the culprit?

Why is it that big companies fail when the technology changes? It happens in every industry, so what’s the pattern? What are they all doing wrong?Jesse Schell

Technology platforms are introduced into enterprises with large fanfare and quick wins. Over time, this incredible momentum slows until eventually the platform has failed the enterprise and replacement technologies are vetted at great cost. How does this happen? If the cornerstones of IT are People, Process and Technology then where should root cause investigation begin? While it is far less painful to attribute blame either Technology or People, the true root cause will be found in the Process. The process was built on a foundation of assumptions and treated as an immutable document. When reality failed to match the assumptions, the process remained unchanged and stopped efficiently serving the business.

To avoid this situation, a feedback mechanism needs to be created. Here, stakeholders and implementors can identify pain points and brainstorm solutions. Management needs to dedicate time to implement these proposals. If there’s no ability to provide formal feedback to someone who will take action, then a cycle of failing technology will be created as processes continually fail to evolve.

Introduction

When a new technology is introduced to an enterprise, there is energy, optimism and enthusiasm surrounding the new capability and how it will turn the painful business problems of today into the successes of tomorrow. The destination set, a roadmap is defined and the journey towards an improved future begins. Sometimes, something goes wrong. Very wrong. After a few years, progress when has derailed and the view of the technology changes from a beacon of hope into a noose around the enterprise’s neck. Suddenly its stifling productivity and negatively impacting everything it touches. How does this happen? Architects who were singing songs of praise are now assembling the pitchforks and torches in order to burn it to the ground.

If the trinity of IT is People, Process and Technology then the problem should be primarily attributable back to one of these components. Which one is the most likely culprit?

Technology

This is the idea that technological innovation has occurred at such a rapid pace that the infrastructure has suddenly become too outdated to perform its tasks. Think about this. We live in a world where businesses are still scrambling to re-leverage COBOL processes written decades ago. We’ve learned the folly of discarding working systems for the sake of rewriting them from scratch in cool new technologies without business justification. Suddenly now, in the span of a few years, a technology has been rendered completely ineffectual from the original roadmap? I doubt it. It can still perform the job. It hasn’t changed.

Blaming technology is common to hear, but it is a red herring. It only addresses the symptoms of a problem that lies deeper in the enterprise. Failure is tough to address if the culture of the enterprise doesn’t ‘celebrate’ it. If failure is tightly correlated to negativity, then addressing failure degenerates into a game of three card monty. Distraction and sleight of hand are tools used to quickly address symptoms in lieu of performing the difficult introspection required to determine true root cause. The path of least resistance is to push political blame onto something that inherently can’t defend itself, like technology. The problem is that by ignoring true root cause, problems are swept under the rug and ignored, only to re-emerge on other projects. This ingrains a vicious and substantially costly cycle of failure. Systematic derailment continues over and over until the frustration level between business and IT reach critical levels and drastic actions are taken.

If technology isn’t the root cause, the problem must lie somewhere between People and Process.

People

This is the idea that the people on the teams managing the technology were solely responsible for the derailment. As an outsider, it’s easy to naively assume that the team was deliberately, maliciously, or passively incompetent. If only they worked harder, then there wouldn’t be any problems. I only they cared more they could have recognized and addressed issues before they become disasters. If only the solutions were higher quality then production wouldn’t be constantly on fire. If only the resources were senior, then issues would have been discovered sooner. If only there was more innovation in solutions then delivery would be faster. If only the team was easier to work with then there wouldn’t be so much back-and-forth. If only, If only. We can deconstruct each of these as excuses hiding true root cause:

• Working ‘harder’: What exactly does this mean? Longer hours hasn’t been proven to be a benefit in the long term. We need to move beyond quantity to what drove the allegation that they weren’t working hard enough? Were there too many projects? Too many unfulfilled promises? Were the platform SLA’s out of touch?
• Caring more: I’ve yet to meet anyone in my career that didn’t care about what they were doing. Everyone is professional and putting in their best effort to complete their work on time and budget. The ones that don’t aren’t in the industry after they flame out, so your chances of working with a team of these people is slight.
• Higher Quality: I’ve also yet to meet someone who intends from the outset to create low quality work. Quality is usually dictated by the amount of time the project dedicates towards the development effort. A project with tight deadlines will tend to be lower quality as critical phases of development (i.e. testing or governance) are treated as nice-to-haves instead of requirements.
• More Senior Resources: This is a failure of training and not providing adequate resources to the team to gain required skills.
• Lack of Innovation: Was the team given scheduled time to work on the big picture or was the workload so urgent and plentiful that no time was assigned? It’s nice to champion innovation in C-level presentations, but if the only time allocated is after a 40 hour workweek then it’s championed on the back of the employees work-life balance.
• ‘Easier’ to work with: This is a core symptom of an overstressed team. If every project is urgent, red, regulatory and required yesterday then it completely destroys employee morale. Pleasantries are usually the first to go. The question should shift to how project prioritization occurs and how the resources of the team match the workload. Massive gaps will usually be found.

There is an underlying theme developing. The team is working within the confines of enterprise IT and management process, but core pieces of these processes are either ineffective, don’t exist or are immediately sacrificed when the project is under duress. If people were the true root cause, then the technology could never have been successful out of the gate.

People is generally another red herring. Poor process is what turns viable vibrant platforms into steamy swamps hiding the worst monsters from your childhood nightmares.

Process

This is the idea that the derailment wasn’t caused by the technology, nor the people. It sits squarely with the process. Process is the glue that binds people and technology together in the enterprise. Without it, projects would be impossible to estimate, gaps in roles and responsibilities would form and duplication of effort would occur leading to exorbitant IT costs. Enterprises require process and employees are paid to follow that process. Many processes. Like a design process, development process, deployment process, change management process, incident management process, etc. If these processes are of critical importance and employees follow the designated process to the letter, why do successful platforms suddenly fail? To understand this problem, we have to look back at how the process was established.

The process is initially created alongside the introduction of the technology. This is a time when information on the actual usage of the platform does not exist. Assumptions are made to fill in the gaps. It’s similar to creating a walkway through a field between two buildings under construction. There’s a set of principles based on core assumptions that dictate where the path should be placed. In the same way, the initial process is the approximation of what is required to move a project from point A to point B in the project plan. Over time, the team becomes very efficient at working within this process as it’s seen as the only acceptable path to take. But what happens when the base assumptions don’t match reality?

In our case, lets say the pathway was designed to link the front doors of the buildings, only to discover over time that most traffic leaves the path half-way through to cut across the grass to walk to the side doors. The path has started to fail its intended purpose. There appears to be a needs for a feedback mechanism in order to decide that that a new path extension is required. In an enterprise process this can manifest itself in requests for information that are irrelevant, intake documents that ask for more information than the process implementor actually requires, and regular rejection of intake documents for minor reasons.

The initial process built on assumptions haven’t evolved and doesn’t meet the current reality of the platform yet it is still treated as authoritative and immutable. This leads the platform team to continue to work very hard, but their efforts are to drag projects kicking and screaming to the designated front door when they’d prefer a more relevant destination (the side door).

Eventually, the projects get fed up and seek alternatives with a bias to new technology. This new technology starts off with quick big wins, just like the current ‘old’ technology because their processes are new and designed to meet the current need. The new technology has built the path from the front door to the side door just like the projects want. Of course, the devil is that the new technology is just as doomed to failure in a few years as it equally fails to evolve its shiny new processes. The circle of systematic derailment is complete.

Recommendation

Ask the following questions about the enterprise processes:

• Does it provide a feedback mechanism?
• Is there someone tasked to action the feedback?
• Are the employees empowered to propose change?
• Does management reward fresh ideas?
• Does management supply the person-hours to brainstorm/discuss/implement the change?
• Are the process benefits measured against expectations in a tangible way?

In failure scenarios, the answer to these questions is no. There’s no feedback mechanism. Recommendations rise to the first few layers of management where they die. Employees are expected to stay heads down and complete the project work that comes. When they take it upon themselves to attempt to improve the situation they’re  chastised for it or met with management indifference. The initial process at birth is the process that used at death. Innovation and improvement will never exist in these conditions. Without those two, the platform is doomed to costly derailment.

The solution is that all processes have to be treated as living entities. Anyone who is involved or impacted by the process should have an open forum for bringing forward improvement. Management needs to understand that dedicating a few hours a week today towards improvement can result in massive productivity gains tomorrow. Process should be reviewed on a regular basis between all the stakeholders, and pain points should be encouraged to be brought out into the open.

Conclusion

People, Process and Technology are the three prongs of IT. When technology platforms go wrong, instead of expending effort trying to determine how Technology or People have failed, look first at Process. It is here where you will find the true root cause of failure.