RevampBank: Mobile Banking Transformation Initiative

Project Overview

Engaged as the Business Analyst supporting the Digital Experience Team, I led the project initiation and stakeholder analysis activities for RevampBank's mobile banking transformation initiative. I established a clear understanding of the business problem, identified key stakeholders, defined governance and communication structures, prioritized business needs, and created the decision-making framework required to guide the discovery phase.

Working closely with business and technology stakeholders, I facilitated the early analysis needed to align project objectives, evaluate stakeholder influence and expectations, identify high-value business capabilities, define success measures, and establish accountability through a RACI framework.

RevampBank, a mid-size digital bank operating in the UK, was losing customers because its mobile app failed at the basics: slow logins, confusing navigation, no real-time spending alerts, and no budgeting tools. The impact was measurable: a 15% increase in customer churn, a spike in support tickets, and an estimated $2M in annual revenue at risk.

The engagement objective was to ensure the organization had a shared understanding of the problem, the right stakeholders engaged, and a structured governance approach before solution design and development activities commenced.

---

Contents

1. Project Overview
2. Tools & Methods Applied
3. Key Takeaways
4. Methodology & Assumptions
5. Problem Statement
6. Rationale: Why This Engagement Mattered
7. First Activity After Understanding the Business Problem
8. Stakeholder Register
9. Power-Interest Matrix
10. Communication Plan
11. High-Impact Features: Prioritization
12. Performance Measurement Framework
13. RACI Matrix: Project Initiation & Discovery Phase
14. Proposed Solution & BA Recommendations
15. Engagement Outcome (Conclusion)

---

Tools & Methods Applied

Area	Tools / Methods Used
Stakeholder Analysis	Stakeholder Register, Power-Interest Matrix
Governance & Accountability	RACI Matrix
Communication Planning	Stakeholder-tiered Communication Plan
Requirements Prioritization	Impact mapping against business drivers (churn, revenue, support cost)
Performance Measurement	Objectives, KPI, Target, CSF framework
Documentation	Microsoft Excel, Microsoft Word, Microsoft PowerPoint

---

Key Takeaways

This engagement briefly:

• The problem: A mobile banking app that fell behind customer expectations: slow logins, confusing navigation, no real-time alerts, no budgeting tools, driving a 15% churn increase and an estimated $2M in annual revenue at risk.
• The first move: I conducted stakeholder identification and analysis before any requirements work, because authority, expertise, and impact were not yet mapped.
• The governance: I built a 9-role stakeholder register, a power-interest matrix separating who to manage closely versus monitor, and a RACI matrix establishing accountability before design began.
• The priority call: Login speed and navigation were prioritized first as they touch every session, with budgeting tools positioned as a competitive-parity feature rather than an urgent churn fix.
• The outcome: I delivered a governance and problem-framing foundation that prevented a costly, partially scoped fix and positioned the $2M exposure as solvable rather than recurring.

---

Methodology & Assumptions

The engagement followed a structured discovery approach: problem diagnosis, stakeholder analysis, governance design (RACI, communication plan), requirements prioritization, performance measurement.

Each phase was sequenced deliberately. Governance and stakeholder alignment were established before requirements work began, not alongside it, for the reasons set out below.

Two figures anchor this engagement and are worth making explicit rather than treating as given:

• The $2M annual revenue-at-risk figure was taken as provided by RevampBank leadership.

  Working it back to source assumptions: a 15% increase in churn against a digital banking customer base in the tens of thousands, at a typical UK retail banking customer lifetime value in the low hundreds of pounds annually, lands in the same order of magnitude as the $2M figure. This was accepted as directionally sound rather than independently re-derived.

  In a live engagement, the next step would be requesting the underlying churn cohort size and average revenue per user from Finance to validate this figure to the pound. That validation was flagged as an open action rather than assumed complete.

• The 30% support-cost reduction target I treated as an aspirational, not guaranteed, outcome. It is contingent on the root-cause fixes (not just symptom fixes) discussed in the Problem Statement below actually shipping in the first release.

Where information was not available at this stage of discovery, I called it out explicitly rather than filled it in silently, consistent with how a live stakeholder-facing deliverable should flag unknowns rather than paper over them.

---

Problem Statement

RevampBank's mobile banking app had become a liability rather than an asset. Through initial discovery, I identified four recurring pain points customers were reporting:

• Slow login times: friction at the first touchpoint of every session
• Confusing navigation: users could not find core functions without trial and error
• No real-time spending notifications: customers were flying blind on their own balances
• No personal budgeting tools: a feature competitors now treat as table stakes

The business consequence was concrete: a 15% increase in user churn and a spike in support tickets, both pointing to the same root cause: the app no longer met the baseline expectations of digital banking customers.

What business problems were we actually solving?

Stripping away the feature list, I identified the real problem as this: RevampBank's mobile experience had fallen behind customer expectations to the point where it was actively driving customers to competitors and away from self-service.

This in turn drove up support costs and eroded the bank's digital-first value proposition. Login speed and budgeting tools were symptoms; the underlying problem was a digital channel that had not kept pace with the market it competes in.

This distinction mattered for scope. Treating this as "fix four bugs" would have shipped four fixes and still lost customers, because the underlying experience gaps, speed, clarity, visibility, control, were systemic, not incidental.

---

Rationale: Why This Engagement Mattered

Driver	Business Impact
Revenue protection	Prevents an estimated $2M in annual revenue loss tied directly to churn caused by app frustration
Competitive parity	Competitors already offer real-time alerts and budgeting tools; without parity, RevampBank risks further market share loss
Cost efficiency	A 30% reduction in UX-related support costs is achievable by eliminating the avoidable complaints driving ticket volume

I used these three figures, $2M, churn rate, and the 30% support-cost target, as the spine of the engagement. Every deliverable I produced (KPIs, feature prioritization, RACI) ties back to moving these numbers, not to shipping features for their own sake.

---

First Activity After Understanding the Business Problem

BA Methodology Decision: I determined that stakeholder identification and analysis, not requirements gathering and not solution design, was the correct first activity once I understood the business problem.

Once I understood the problem at the level above, I did not move to requirements gathering, nor to solution design. I moved to stakeholder identification and analysis.

The reasoning is procedural, not arbitrary. I cannot run discovery interviews, prioritize features, or scope an MVP without first knowing whose input is authoritative, whose approval is required, and whose day-to-day work will be disrupted by the change.

Skipping this step is how projects end up re-scoping three weeks in because Compliance was not consulted on a "fast login" change that touches authentication, or because Customer Support, who hears every complaint firsthand, was never asked what they are actually hearing.

Stakeholder analysis answers three questions that everything else depends on:

1. Who has the power to approve or kill this initiative?
2. Who has the operational knowledge required to define the right solution?
3. Who will be affected by the change and needs to be managed, not just informed?

This is why I established the Stakeholder Register, Power-Interest Matrix, and Communication Plan before any feature discussion, both in this deliverable and in the actual sequencing of the engagement.

---

Stakeholder Register

I mapped the full landscape of internal and external parties relevant to the mobile app revamp. Each entry captures the stakeholder's goals and concerns by role, because two people in the same department can have different stakes in the outcome. Note: functional columns use role titles rather than individual names to ensure the register remains valid if personnel change.

#	Name (Reference)	Role / Title	Department	Goals	Concerns
1	—	Chief Digital Officer	Executive Leadership	Protect the $2M revenue at risk; position RevampBank as digitally competitive	Project timeline slipping past the next board review; underestimating the scale of the UX problem
2	—	Head of Digital Experience	Digital Experience Team	Deliver a measurably better app within the quarter; own the success of this initiative	Being held accountable for a scope that depends on IT and Compliance delivery timelines not within her control
3	—	Head of Customer Support	Customer Support	Reduce ticket volume and call-handling time tied to app complaints	Being excluded from requirements gathering despite holding the most direct customer pain-point data
4	—	Compliance & Risk Officer	Compliance	Ensure any change to login/authentication meets FCA and PSD2 regulatory requirements	Faster login being pursued in a way that weakens authentication security or audit trail
5	—	Lead Mobile Engineer	Engineering / IT	Build a technically sound, maintainable solution within a realistic timeline	Vague or shifting requirements forcing rework; being handed a deadline before scope is fixed
6	—	Head of Marketing	Marketing	Use the revamp as a retention and brand-loyalty story; reduce churn-driven customer loss	App relaunch happening without a coordinated communication plan to existing customers
7	—	UX/UI Design Lead	Design	Design an interface that resolves the navigation and clarity complaints	Being brought in after requirements are locked, with no room to influence the experience design
8	—	Data & Analytics Lead	Data/Analytics	Ensure the new app captures the right usage data to measure success post-launch	KPIs being defined without analytics input, making post-launch measurement unreliable
9	—	End Users (Retail Banking Customers)	External	Faster, clearer, more useful mobile banking; visibility and control over their money	Continuing to experience the same frustrations if the fix does not address root causes
10	—	Board of Directors	Governance	Confidence that the $2M revenue risk is being actively managed	Lack of visibility into project progress between formal reporting cycles
11	—	App Store Reviewers / Public	External	N/A (passive stakeholder)	Public app ratings directly affect new customer acquisition and brand reputation

---

Power-Interest Matrix

I positioned stakeholders by their power to influence the project's direction or outcome, and their interest in its success. This determined how I engaged each group:

• Manage Closely (High Power, High Interest): Chief Digital Officer, Head of Digital Experience, Compliance & Risk Officer
• Keep Satisfied (High Power, Lower Interest): Board of Directors
• Keep Informed (Lower Power, High Interest): Head of Customer Support, Lead Mobile Engineer, UX/UI Design Lead, Head of Marketing, Data & Analytics Lead, Retail Banking Customers
• Monitor (Lower Power, Lower Interest): App Store Reviewers / Public

I placed the Compliance & Risk Officer in "Manage Closely" despite that role not being the headline owner of this project, because this role holds veto power over anything touching authentication, and authentication is the single most-cited complaint.

I placed the Head of Customer Support in "Keep Informed" rather than "Manage Closely" because this role has high interest and valuable input, but no formal authority over scope or budget decisions.

---

Communication Plan

I built the communication plan directly off the Power-Interest Matrix. Each quadrant received a distinct cadence and format rather than a single broadcast channel for everyone.

Stakeholder Role	Quadrant	Communication Method	Frequency	Owner
Chief Digital Officer, Head of Digital Experience, Compliance & Risk Officer	Manage Closely	Steering committee meeting + written status report	Weekly	Business Analyst
Board of Directors	Keep Satisfied	Executive summary memo	Monthly / per reporting cycle	Head of Digital Experience
Head of Customer Support, Lead Mobile Engineer, UX/UI Design Lead, Data & Analytics Lead	Keep Informed	Working session + shared requirements doc	Bi-weekly	Business Analyst
Head of Marketing	Keep Informed	Marketing sync ahead of any customer-facing milestone	As needed, minimum monthly	Business Analyst
Retail Banking Customers	Keep Informed	In-app survey / feedback prompt; no direct project visibility	Ongoing (passive)	Marketing
App Store Reviewers / Public	Monitor	Passive monitoring of app store ratings and reviews	Continuous (automated tracking)	Marketing / Data & Analytics

I gave stakeholders with veto power (Compliance, Executive Leadership) direct, frequent, two-way engagement.

I gave stakeholders with operational knowledge but no formal authority (Support, Engineering, Design, Analytics) structured working sessions where I captured their input, not just announced decisions to them.

I monitored passive stakeholders (public sentiment) rather than managed them directly; engaging them at this stage would have been a waste of project bandwidth.

---

High-Impact Features: Prioritization

I mapped each proposed feature back to the specific churn driver it addresses, rather than treating all four complaints as equally weighted:

Feature / Change	Addresses	Expected Impact
Biometric / streamlined login	Slow login times	Highest impact: login is the first touchpoint in every session; friction here compounds across all other complaints
Simplified navigation / IA redesign	Confusing layout	High impact: directly reduces support tickets tied to "I can't find X"
Real-time spend notifications	Lack of visibility into spending	Medium-high impact: addresses a trust and control gap, key to reducing churn among security-conscious users
In-app budgeting tools	No personal finance features	Medium impact: competitive parity feature; drives engagement and digital adoption rather than directly stopping churn

Login and navigation were prioritized first because they affect every single session, not just specific use cases. Fixing them has the broadest reach across the user base.

I positioned budgeting tools as strategically important for competitive parity, but affecting engagement and retention over a longer horizon rather than immediately stopping the churn bleeding.

---

Performance Measurement Framework

Objective	KPI	Target	Critical Success Factor
Reduce customer churn	Monthly churn rate	Reduce from current 15% increase back to baseline within 2 quarters post-launch	Login and navigation fixes ship in the first release, not a later phase
Improve app usability	Average login time	Under 5 seconds	Biometric/streamlined login implemented and stress-tested before launch
Reduce support burden	UX-related support ticket volume	30% reduction within 2 quarters post-launch	Root-cause issues (not symptoms) are fixed in the first release
Increase digital adoption	% of customers actively using budgeting/alerts features	40% adoption within 6 months of launch	Features are genuinely useful, not checkbox additions; validated via user testing pre-launch
Protect revenue	Revenue at risk from churn	Recover the $2M annual exposure	Churn and support KPIs above are both trending positively by quarter 2
Improve market perception	App store rating	Increase by at least 0.5 stars within 6 months	Public-facing improvements are visible and communicated by Marketing

I anchored every KPI to one of the three rationale drivers: revenue, competitive parity, or cost. A KPI that does not move one of those three numbers does not belong on this dashboard.

---

RACI Matrix: Project Initiation & Discovery Phase

I structured this RACI around roles, not individuals, so accountability remains valid regardless of personnel changes. Roles: Responsible (does the work), Accountable (owns the outcome, signs off), Consulted (input sought before decisions), Informed (kept up to date).

Activity	Business Analyst	Head of Digital Experience	Chief Digital Officer	Compliance & Risk Officer	Head of Customer Support	Lead Mobile Engineer	UX/UI Design Lead	Data & Analytics Lead
Define problem statement	R	A	C	I	C	I	I	I
Stakeholder identification & analysis	R	A	I	I	I	I	I	I
Draft communication plan	R	A	I	I	I	I	I	I
Conduct discovery interviews	R	C	I	I	R	I	C	C
Define requirements (login, nav, alerts, budgeting)	R	A	C	C	C	C	C	C
Compliance/regulatory review of auth changes	C	I	I	R/A	I	C	I	I
Define KPIs & success measures	R	A	C	I	I	I	I	C
Build RACI & power-interest matrix	R	A	I	I	I	I	I	I
Sign off on discovery phase to proceed	C	A	A	A	I	I	I	I

I placed the Compliance & Risk Officer as R/A on the regulatory review row specifically. This role is the only one with the authority and expertise to approve authentication changes, so accountability sits there alone on that row, even though that role is only Consulted everywhere else.

I structured the final sign-off as a joint A across the Chief Digital Officer, Head of Digital Experience, and Compliance & Risk Officer, because all three can independently block the project from moving forward, and a single-owner sign-off would understate that reality.

---

Proposed Solution & BA Recommendations

Based on my analysis of the problem, the stakeholder landscape, and the feature prioritization above, I recommended the following solution approach to address RevampBank's UX failures and reverse the churn trend.

---

Engagement Outcome (Conclusion)

I established three things before any design work began: the real problem (a digital channel that had fallen behind customer expectations, not four isolated bugs), the roles that could authorize or derail the fix, and the numbers the entire engagement would be judged against ($2M revenue, 15% churn, 30% support cost reduction).

The next phase, requirements definition and solution design, inherited this foundation directly. I prioritized features against the churn drivers I identified here, and every stakeholder role already had a defined accountability before the design phase introduced its own set of decisions and deadlines.

The business value of this phase is easy to understate because it produced no shipped feature. Its real value was risk avoidance: without the stakeholder and governance groundwork I built here, the most likely outcome was a faster-login fix shipped without Compliance sign-off, requiring costly rework once flagged in audit, or a redesign that addressed visible symptoms while leaving the churn-driving root cause untouched.

By establishing governance, stakeholder alignment, and clear business priorities before solution design began, this engagement reduced delivery risk and positioned RevampBank to address the root causes of customer churn rather than simply responding to its symptoms.