Compare the current and desired states, write a gap analysis with actions, and sketch the to-be process.
Why it matters
By now you know how the process works today (the as-is map), what the business needs (requirements and priorities) and what the system must do and remember (use cases and data model). A gap analysis puts these side by side: where are we, where do we want to be, and what exactly has to change to get there? It turns a pile of analysis into a plan that a sponsor can approve and a team can deliver.
The structure of a gap analysis
A gap analysis answers four questions:
- Current state (as-is): how does it work today, with evidence?
- Future state (to-be): how should it work, and how will we measure it?
- Gap: what is the difference?
- Actions: what will close each gap, who owns it, and when?
The gaps are not only about software. They can be in process (steps, hand-offs), people (skills, roles, training), technology (systems, data, integrations), policy (rules) and data (missing or poor-quality information).
Worked example: Riverside Library
Goal agreed with the sponsor: cut double bookings to zero and staff phone time on bookings by 75% within three months of launch.
| Area | Current state | Future state | Gap | Action | Owner |
|---|---|---|---|---|---|
| Availability | Members must phone; only staff see the diary | Members see availability online 24/7 | No public view of bookings | Build availability page (FR-01) | Dev team |
| Double bookings | About 1 per week; two staff write in one diary | Zero; system refuses overlaps | No single source of truth | Online booking with overlap check (FR-02, FR-03) | Dev team |
| Confirmation | Phone call back, often forgotten | Automatic email on booking | No automated notice | Confirmation email (FR-04) | Dev team |
| Staff time | About 6 hours a week on booking calls | Under 1.5 hours a week | Manual handling of every booking | Online self-service; staff handle exceptions only | Head librarian |
| Skills | Staff use the paper diary | Staff manage bookings and rooms in the system | No training | Two 1-hour training sessions before launch | Analyst + head librarian |
| Policy | Booking rules exist only in staff memory | Rules published and enforced by the system | Rules not written down | Write booking policy; sponsor approves | Head librarian |
| Data | Existing bookings only in the paper diary | All future bookings in the system at launch | Migration needed | Enter the next three months of bookings by hand | Front-desk staff |
Two things to notice. First, several gaps have non-software actions: training, a written policy, a manual data migration. Leave those out and the system launches into a library that is not ready for it. Second, every future state is measurable, so you can check after launch whether the gap really closed.
The to-be process
The to-be map shows how the process will run once the gaps are closed. Draw it with the same lanes and notation as the as-is map so the differences jump out:
Lane: Member
(start) Member wants a room
View availability online
Choose room and time
Lane: System
<gateway> Slot free and within rules?
no -> Show conflict and next free slot -> back to Member: choose again
yes -> Save booking
Send confirmation email
Lane: Member
(end) Arrive for meeting, room is free
Lane: Librarian
Handle exceptions only (phone bookings for members without internet, cancellations with a reason)
Compare it with the as-is map: the phone call, the paper diary, the forgotten call-back and the double-booking check have gone, and a new System lane does the checking. Keep one path for members who cannot or will not book online. Designing them out is a common and costly mistake, and for a public library it is also an accessibility and fairness issue.
Turning gaps into a recommendation
Sponsors want options, not just problems. A short recommendation usually covers:
- Options considered: for example (A) a shared online calendar with clear rules, (B) an off-the-shelf room booking product, (C) a custom build. Give the cost, time, risk and fit of each.
- Recommended option and why, linked to the goals.
- What stays out of scope (the Won't haves).
- How success will be measured after launch and when you will check.
For a three-room library, an off-the-shelf product may close most gaps faster and cheaper than a custom build. Saying so is part of the analyst's job, even when it means less work for the IT team.
Common mistakes
- Only technology gaps, ignoring training, policy and data.
- Unmeasurable future states ("better booking experience").
- A to-be map in a different notation, so nobody can compare it with the as-is.
- No owner or date on actions, so gaps stay open.
- Never checking after launch whether the gap actually closed.
Quick recap
- A gap analysis compares current and future states, names each gap and assigns actions with owners.
- Look for gaps in process, people, technology, policy and data.
- Draw the to-be map in the same notation as the as-is so the changes are visible.
- Recommend an option, define success measures and check them after launch.
Try it
Open the Do tab and write a gap analysis and to-be map for the process you have analysed through this course.