Foundations of Business Analysis

01 · product roadmap

The Trust Bank: planning a new mobile app

The situation

The Trust Bank Inc. had an old, hard-to-use web-based mobile app, and new features took four to six months to ship. The bank wanted native iOS and Android apps built side by side, rolled out in three stages (internal testers, a customer pilot, then everyone) before retiring the old app. As the BA working with the Product Lead, my job was to turn a long feature list into a clear two-year roadmap.

Prioritization · Release planning · Agile roadmapping · Stakeholder goals

Click the roadmap to see it full size · Download the PDF

How I prioritized

I chose 20 features and grouped them into five themes, then ordered the themes by what a customer needs first. Each one builds on the one before it:

1. Secure access
2. Money movement
3. Self-service
4. Insights
5. Lending

You can't move money until you can sign in and see your accounts, and there's no point in spending insights before people trust the app with their everyday banking. Investments and loans come last because they carry the most risk, so they launch once the app has proven itself with real customers.

Key decisions

• Seven small releases, not three big ones. Splitting each stage into releases gives testers something new every few months and lets the team adjust after each one.
• The old app stays live until the very end. Customers are never left without a way to bank. It is only retired in the last release, once everything has moved over.
• Lending kept simple. Investment and loan pages share information and link out to apply, so the two-year plan stays realistic.

What I learned

The hardest part wasn’t choosing features, it was choosing what to leave for later. On a banking app almost everything feels essential, so I kept coming back to two questions: what can a customer truly not do without, and what has to exist before something else can work?

I also learned that a roadmap is a starting point for conversation, not a promise. Writing my assumptions down showed me which dates depended on things I couldn’t know yet. Next time, if I had a team I was working with, I’d test the priority order with the Product Lead and a few real customers before locking anything in.

02 · process modelling

The Stream: taking orders online

The situation

The Stream sells CO₂ refill cylinders, and almost every order came in by phone, which meant long hold times, rising staff costs and mistakes in emailed orders. They wanted an online order form. My task was to model the future-state processes for placing an order and fulfilling it, from the customer's first click to the order being marked complete.

BPMN · Process modelling · Swimlanes · Business rules

Place Order

How a customer orders online: logging in, creating an account or continuing as a guest, then entering order details, choosing a delivery date and paying. The order system checks each step, creates the order and lets the Fulfillment team know right away.

Fulfill Order

What happens once the order arrives: Fulfillment prints it and assigns a driver, the driver delivers and collects any empty cylinders, and the order is marked complete.

Click a map to see it full size

Key decisions

• Guest checkout as an option. Customers can log in, create an account or just continue as a guest, so nobody is turned away by a sign-up form.
• Catch mistakes before the order is placed. The system checks the order details and the payment, and sends the customer back to fix anything wrong. That replaces the errors that used to come from emailed orders.
• Business rules built in. The delivery date is worked out automatically from a 2 pm cutoff, and customers can only pick a later date, never an earlier one.
• No more phone tag. Every new order automatically notifies Fulfillment, and the order's status moves from New to On Delivery to Complete, so everyone can see where it is.

What I learned

Mapping a process forces you to answer questions nobody thinks to ask out loud: what happens if the payment fails, what if the customer has no account, who actually tells the driver? Every decision point on the map was a question I had to answer.

I also learned that a good process map is as much about what it leaves out as what it shows. Splitting the work into two maps, one for the customer and one for the team behind the scenes, kept each one readable while still showing how they connect.

03 · software testing

Amazon.ca: writing test cases

Before a new release goes live, someone has to prove it works. As the BA on the Amazon.ca launch, I am writing 20 step-by-step test cases for creating an account, searching, and viewing and editing the shopping cart, including what should happen when people enter the wrong thing.

04 · course project

North Beaufort Hospital: planning the analysis

A new Ontario regulation requires hospitals to define and track health care performance indicators. North Beaufort Hospital, with three campuses and over 5,000 staff, needs one system to report on them. Our team is writing the BA Plan: who we need to talk to, every analysis task in order, and the techniques, people and time each one needs, from requirements through vendor selection to go-live.