Past mainframe COBOL transformation project mistakes haunt the organizations that make them and become cautionary tales for organizations faced with similar COBOL dependencies and the desire to lessen their COBOL cost and business risk.
In general, large IT projects ranging from ERP and CRM implementation, and digital transformation initiatives, to innovation projects have a failure rate of over 75%. Likely those project failures are related to significant mistakes, like scope problems, management decisions, and the inability to align organizational culture. If you doubt culture plays a huge role in your successful projects, find references to the quote attributed to Peter Drucker, “culture eats strategy for breakfast,” and you’ll better understand.
Mainframe COBOL cost reduction projects also fail for similar reasons, including poorly defined business cases and the inability to mitigate disruptions to mission-critical applications.
These project mistakes can be widely reported and infamous. Take, for example, TSB, where over $500 million was invested in a mainframe transformation project that resulted in almost 2 million customers being locked out of their accounts. While most mistakes are internalized and not reported, they are probably why 77% of mainframe-dependent organizations have started but failed to complete at least one modernization program.
Mission-critical, highly valuable COBOL applications remain on the mainframe due to the fear of transformation or rewrite project failure. Successful transformation is possible if you identify and prevent common mistakes.
5 Preventable Mistakes
Mistake 1: Incorrectly Constructing Your Business Case
When developing the business case for COBOL cost reduction projects, it’s a mistake to strictly focus on spreadsheet or ROI calculator numbers. Taken by themselves, those numbers are not the business case, as they ignore the critical aspect of your project’s success.
Modernization projects are often sold with a business case that concentrates on anticipated ROI. These business cases downplay and offset significant upfront investments with an illusion of near-term ROI. The reality is ROI typically takes two years, and that’s after the three to six years project required to replace or decommission legacy systems.
To prevent this mistake, focus on the replatforming project costs and benefits, the impact on internal business cycles, optimal timing for transforming individual COBOL applications, and a realistic time necessary to achieve your ROI expectations. The case should also include the strategy and approach to transformation employed to mitigate risks and increase the probability of success.
Mistake 2: Disrupting Mission-critical Business Processes
The mistake of disrupting mission-critical business processes isn’t exclusively related to the COBOL business application code. This mistake arises during big-bang replacement projects when decisions are made to “improve” processes that impact and disrupt downstream system processes. The resulting chain reaction and correction/adoptions lead to scope creep and longer delays. Both increase the risk of project failure. This mistake is accurately described in the article: Mainframe Modernization Antipatterns.
Prevention of this mistake requires understanding the COBOL application and existing integrations, dependencies, and interactions. Assessing the interdependencies will help identify potential disruptions and their mitigation or corrective actions. The comprehensive understanding of the ecosystem of the application will also help prioritize transformation projects that deliver business value with relative investment and risk.
Mistake 3: Investing Dollars to Get Dimes
The return of a dime for every dollar invested is an obvious mistake. This mistake doesn’t always occur because of cost overruns related to poor project management and execution. It can also happen because of the inability to retire legacy systems due to an unexpected need for both the old and new system to coexist, or increases in complexity and scope (often referred to as Second System Effect) where cascading new needs and requirements are discovered necessitating a resolution during the replatforming of the application compute.
The prevention of the dimes-for-dollars mistake is based on two elements. The first is to understand the conditions that must be met to retire the legacy system and remove its cost. The second prevention element is the rigor to limit scope and business process disruption, preventing the Second System Effect.
Mistake 4: Not Limiting Scope
If your COBOL compute cost reduction project has an unlimited scope – it’s a significant mistake. Due to the potential impacts of disrupted downstream business processes and the before-mentioned Second System Effect, the ability to tightly control scope is essential. An unlimited scope is terrible for any project, but for replatforming projects, a more precise and concise scope leads to success. Increasing scope in complex areas like application coexistence and master data management (MDM) increases the likelihood that this mistake will cause your project to fail.
To prevent the mistake, organizations should minimize or eliminate changes to system processes and data. Concentrate the scope on replatforming to a less expensive environment using automation for code generation and testing. A predetermined process to evaluate scope increases will also help institute the rigor necessary to deliver a successful project.
Mistake 5: Losing Control Due to Vendor Lock-in or Outsourced “Big Bang” Projects
Losing control of your COBOL compute cost reduction project can lead to failure. The failure may come in the form of unrecognized vendor lock-in where dependencies were unknown or ignored until the point of no return was reached. Loss of control could also result from a vendor or third party attempting to execute a mega-scoped, independently developed, and tested big bang implementation. Both situations put your project at risk.
Loss of control is preventable. Control is accomplished with comprehensive planning, managing the high-risk aspects of your project (code quality, testing, etc.), and taking an incremental approach.
Don’t make the problem worse.
Every large IT project is a high risk, and there are many opportunities to make mistakes that lead to negative impacts. Understanding the likely mistakes and how they are prevented can significantly enhance your prospects for a successful mainframe COBOL compute cost reduction or replatforming project.
Image: Pargon, CC BY 2.0