Why Enterprise IT Plans Rarely Succeed

There are five factors why successful implementation of most enterprise programs is almost impossible. Factor 1 – Lost in Translation We all know the major steps in a software development life cycle (SDLC): Step 1 – Identifying Strategic Direction and Imperatives Step 2 – Creating Business Requirements Step 3 – Developing Technical Architectures Step 4 – Developing Technical Designs Step 5 – Code Construction Each step in an SDLC represents an interpretation of a prior step's deliverables into this step's deliverables. But it’s almost like translating from English into Mandarin Chinese. There will be gaps in this translation. Every step is, we hope, conducted by people who know their own step very well, yet they have a limited knowledge of the prior or the next step. Subject-matter experts (SMEs) writing requirements more often than not have a very limited understanding of all the current market needs, and even less of an understanding of future market trends. They for sure have no idea about underlying architecture. By the way, making strategists write requirements produces the same result. So let’s not even ask BCG or Bain to create requirements. Unfortunately, there is no magic button we can use to verify the created requirements’ compliance with the strategic direction, or how well architecture satisfies strategy or even business requirements. And the issue applies to every SDLC step. Let’s assume we are very good at what we do. Let's say we improperly translate only 10% of what was created by a prior step. This means that the probability of delivering something useful to a target market and to our internal business just dropped to below 60%! And this even before we take into consideration the budget and time overruns. So, at least 40% of objective market needs are not satisfied because they are lost in translation. And this is the best possible case. Factor 2 – Implementation Time Is Our Enemy These steps represent our subjective interpretation of what’s required by the target market players and by our internal business. So, the only objective entity here is our target market. And this market changes much faster than we suspect. While CIOs can ask or even demand during long-running programs to freeze changes to business requirements, we can’t ask the same from our markets and customers. Our target markets do not wait for us to complete software development. See also: Expanded Role for Alternative Capital   It is not uncommon for an enterprise program in insurance to last around 36 months. Let’s assume that one of the success factors is defined as not having a need for significant changes to the production code for the first 24 months after deployment. I even quantify a significant change as a change requiring 15% of the cost of initial implementation. That means that our strategy team must identify market needs with almost absolute accuracy for the next 60 months. Futuristic analysis like that is impossible for one simple reason – there are too many factors influencing consumer behaviors in a market, especially for such a long period. The longer we take to implement, the more likely it is that our understanding of objective market needs will change, and therefore the less accurate the initial assessment was. That means that by the time we deliver, we are already too late. What we deliver will be functionally outdated and must be immediately changed. We can certainly refresh our strategy every year. But what to do with the requirements that have already been implemented? And how to deal with new upstream and downstream process dependencies? DevOps approach, gaining popularity now, due to internal architectural dependencies of most legacy and even more modern off-the-shelf products, produces very limited success. Factor 3 – Measuring Success at the Wrong Spot When we measure success of the core systems implementations (and this kind of projects represents the majority of enterprise-sized programs), we count numbers, but the best way to measure success is to measure our internal users’ satisfaction. Right? No, not right. Remember the only objective entity? The only true measure of success is our target markets. If our work does not increase market penetration and does not result in revenue and cost improvements, then it doesn’t matter how good our organization feels about new, modern applications. It is that simple. So why do we so seldom measure the effects of our work on the markets? Because so often our business case is not really based on market needs and does not measure the effects of new systems and processes on our consumer. Factor 4 - The Wrong Reasons for the Program In my experience, as much as 70% of all programs represent a replacement of legacy systems by more modern applications. That’s the only business case. In some cases, my clients were losing vendor support, and in some cases teams that developed their legacy systems left the company. A true story: I was on an engagement for a client who wanted to have new tech so that she could move it to the cloud and save about $25 million in annual support cost. To do that, she was willing to spend around $200 million on core system replacement. There was no return on investment (ROI). She was not an exception. It’s amazing how often insurance companies get into long-term projects to replace one technology with another technology – without targeting or achieving any revenue increase, and without opening any new markets. Maybe it’s less expensive to train your people on older technology and keep supporting this old technology on your own while developing a real business case for replacement? Just saying. Factor 5 – Hero Worshiping One of the first questions I’m asked by my clients is what other insurance firms are doing. This question makes me very uncomfortable for many reasons. For one thing, I can’t disclose confidential information. But another reason is even more important. As a matter of fact, it is fundamental. Just because a perceived industry leader does something does not mean you should follow in his steps. Doing so relegates you to the position of a follower. Do you really want to be No. 2 or number ”anything except 1?“ Second, even leaders make mistakes. The difference is – big companies can mask their losses, but, if you work for a mid-size insurance firm, you can’t afford to fail. You have no billion- dollar budget to mask a $20 million loss. Finally, just because a leading insurance firm does something, that doesn’t mean that it does it right. Besides, a market leader’s customer profile can be vastly different from yours. So please do not jump from this roof because someone your worship jumps. It is bad idea for them, and it is an even worse idea for you. See also: Pulse Check: How Do You Approach Risk?   Conclusion There are only two events in the life of a modern Information technology organization that result in mass firings of executives. One of them is a security breach. Another one is the almost hopeless journey to implementing core system replacement and any large enterprise program. Before you embark on this journey, think about the real chances of your success, and think long and hard about what success really means to you. Are there simpler and less expensive ways to deliver value to your customers? Is doing nothing better than doing something? Are there better places to spend money? Try answering these questions before starting an enterprise program.