Why Tech Projects Fail: The Case for Change Management in Banking

The banking industry spends billions of dollars every year on technology. New core banking systems, AI-driven CRM platforms, automated reconciliation engines. Yet, the statistics on the success of these projects are grim. Studies consistently show that 70% of digital transformations fail to achieve their stated goals.

Why? It is rarely because the software didn't work. The code usually compiles. The servers usually run. The failure happens because the people didn't use it.

In banking, this often manifests as a new, expensive platform that sits unused ("shelfware"), while the operations team secretly goes back to their old, comfortable spreadsheets. This is a failure of Change Management.

The "Build It and They Will Come" Fallacy

Engineers and Project Managers are often trained to focus entirely on the "Technical Go-Live".

• Is the code deployed? Yes.
• Did it pass UAT? Yes.
• Is the server up? Yes.
• Project Status: Green / Complete.

But for the business, the project isn't "live" until value is being realized. This is the "Business Go-Live". If the users don't adopt the tool, or if they use it incorrectly, the ROI is zero. In fact, it's negative, because you've added the cost of the new system to the cost of the old inefficient process.

The Psychology of Change: The ADKAR Model

Change is hard. It triggers fear—fear of incompetence ("I won't know how to use it"), fear of redundancy ("The robot will take my job"), and fear of the unknown. To navigate this, we advocate for the Prosci ADKAR model, a structured framework for individual change.

1. Awareness (The "Why")

Do the users know why we are changing?

• Bad: "We are rolling out System X on Monday."
• Good: "Our current system is 20 years old and crashes weekly, causing us to stay late. We are moving to System X to fix this stability issue."
• Insight: You must sell the problem before you sell the solution.

2. Desire (The "WIIFM")

Do they want to change? What's In It For Me (WIIFM)?

• Change is personal. A manager might want the change for "efficiency," but the user needs a personal motivator. "This new tool will automate the data entry so you can finish on time and go home to your kids."

3. Knowledge (The "How")

Do they know how to change?

• This is where training comes in. But not just a 100-page PDF manual sent via email. Interactive workshops, "sandbox" environments, and floor-walking support are essential.

4. Ability (The Execution)

Can they actually implement the change?

• Do they have the right login access? Is the new process compatible with their other duties? Is the helpdesk ready to support them?

5. Reinforcement (The "Stickiness")

Does the change stick?

• This is the most skipped step. Once the project team leaves, human nature is to revert to the old way (muscle memory). You need reinforcement mechanisms: removing access to the old system, celebrating wins, and tying KPIs to the new process.

The "Valley of Despair"

Every change curve has a dip. When you first go live, productivity will actually drop. This is the Valley of Despair. Users are learning, things are slower, and frustration is high.

• Poor Change Management: The project team panics, blames the users, or rolls back the change. The project dies in the valley.
• Good Change Management: The team anticipates the dip. They provide extra support (hyper-care), manage expectations ("it will be slow for 2 weeks"), and coach the users up the slope to the "New Normal" where productivity is higher than before.

Practical Steps for Leaders

1. Identify Champions: Find influential users in the ops team—not necessarily the managers, but the "opinion leaders" that others listen to. Get them on board early. If they say the system is good, the team will follow.
2. Communicate Early and Often: Don't wait for UAT to show the screen. Involve users in requirements gathering. "Co-creation" builds ownership.
3. Burn the Boats: Eventually, you must cut off the retreat. Make the old system Read-Only. If the spreadsheet is still an option, they will use the spreadsheet.

Conclusion

Change management isn't "fluffy HR stuff." It is risk management for your project investment. It is the difference between a deployed system and a adopted solution. In the complex, high-pressure environment of banking, you cannot command people to change; you must lead them through it.