# Cutover Management

By Semyon Kuznetsov · Web version: https://semyonkuznetsov.com/projects/cutover-management.html

*Note: The project is under NDA, so unfortunately I can't share more details.*

A control room for the operation that switches a country onto a new ERP system:
hundreds of coordinated tasks, dozens of workstreams, several time zones, and a
go-live date that cannot move once it is committed.

A multi-year ERP transformation, rolling out a new platform country by country
in waves. Each wave ends in a cutover — legacy systems ramp down, a blackout
window migrates the critical data, the new system ramps up to full business
load.

1. Top 5 global pharma, revenue ~$50B
2. Markets in 155 countries
3. Enterprise UX for Business Services, streamlined processes in clinical trials & operations

| | |
| --- | --- |
| Domain | Pharmaceuticals |
| Role | Senior Product Designer |
| Team | Designer, BA, Backend Dev, Full-Stack Dev |
| Timeline | two weeks part-time in Aug 2026 |

## Problem

The client had been running its cutovers on a stack of Microsoft tools stitched
together by an earlier vendor. It worked — every wave had gone live — but the
people operating it had accumulated years of workarounds.

The task data lived across six or seven surfaces that didn't talk to each other:
a master plan in MS Project, assembled by hand from nine-plus separate files; a
SharePoint list with eighteen saved views; a separate exceptions dashboard that
one named specialist understood; a Power Automate flow nobody could see inside;
Power BI reporting on a three-hour refresh; a milestone tracker kept offline in
Excel because the tool had no milestone view; and Teams, where the actual
real-time coordination happened.

What that cost the people using it:

- **Reporting was three hours behind the room.** Most tasks close in the last hour or two before a status call. Only two or three admins could trigger a refresh, so a region with nobody available waited.
- **The most-used view was named after an email subject line.** Two of the three heaviest daily users of the Kanban Dashboard didn't recognize the term: "I didn't know it was a Kanban structure" and "I personally struggle with the Kanban one." Nobody moved cards. Everyone set one status field on a filtered grid.
- **Nothing forward was visible.** A task appeared only once it was due, so an owner with hundreds of tasks coming could see none of them.
- **Notifications were unreliable.** The most-cited complaint in the interviews, logged against four separate business requirements.
- **There was no audit trail,** which turned ordinary access questions into unanswerable ones.
- **The platform ceiling was already in view.** The SharePoint list tops out around 300 items, and the largest wave still ahead was the most complex the program would run.

The brief was to prove a rebuild was worth funding. The client lead running
cutovers heard the timeline and pushed back: "When I heard 'we'll get this done
in about two weeks with AI', I was thinking — really? I'll probably give you a
six-month roadmap from this conversation."

## Goal

A proof of concept is not a small version of the product. Its job is to turn
"we're not sure this is worth building" into a funded build. Every scope
decision had to answer one question: does this help someone with a budget say
yes?

Four things had to be proven:

- **Feasibility on the real constraints.** High task volume, multiple time zones, notification-critical, audit-critical, and cheap enough to deploy without a procurement cycle.
- **That the redesign fixes the named pain points.** A working answer to three-hour reporting, no audit log, and emails nobody trusts.
- **A believable production path.** What's a demo shortcut and what production requires, stated openly.
- **That a small team can move fast without cutting corners.** Most proofs of concept either move fast and look like a prototype, or look finished and take a quarter.

Six flows were locked as the spine: reporting, data input, email, task
completion, change requests, audit trail.

## Research & Synthesis

I owned everything user-facing: research and synthesis, information
architecture, the design system, UX writing, the UX sections of the technical
design document, and the pitch back to the client. A backend developer owned the
architecture, a full-stack developer built the app, and a BA worked the
requirements register with the client.

The starting material was two recorded walkthroughs and a 35-item requirements
register. One walkthrough was the cutover lead touring the current tool; the
other was two daily users doing the same thing on their own screens.
Transcribing both made them searchable, and the two findings that mattered most
came out of that reading. Neither was in the register: the Kanban view nobody
recognized, and the missing audit trail.

From there the sequence was deliberate. Every requirement and every complaint
went into one map with its source attached, so any design decision could be
traced back to who said it. The as-is diagram drew the six or seven disconnected
surfaces as a single picture, and that picture made the scope of the problem
legible on a call. The to-be diagram and site map followed. Only then did the
six flows get locked as the spine.

No visual design started until that was settled.

## Key Decisions

Four open questions shaped the product more than anything else. Each one got
settled with something built and reviewed.

**The Kanban that wasn't.** Two daily users didn't recognize the name of the
view they use most. It turned out to be a filtered list wearing a name inherited
from an old email subject. So I stopped treating it as a question of taste and
built all three layouts — list, cards, matrix — then judged them against the
documented requirements and against what the transcripts showed people actually
do: open an item, set one field, export to Excel.

**A third recipient class.** The existing emails knew two audiences, owner and
backup, and gave both the same action buttons. A client analyst described a
third group in passing: people who need to know whether a task is closed but
aren't the ones closing it. Give that group an action button and the audit trail
can attribute a closure to the wrong person. The redesign added a third class
with no buttons, just a status link.

**A fake "late" status, rejected.** The backlog asked for it, but lateness is
already computed from elapsed time against planned time. A manual status would
create a second, hand-entered version that drifts. What people mean when they
reach for that button is either *I'm working it but won't make the window* or
*I can't start*. Both need somewhere to record why. That became a **Report a
problem** action: category, comment, optional revised estimate. It deliberately
doesn't silence the escalation ladder, because a manager should keep seeing an
open problem rather than watch it disappear into a label.

**Scanner-safety over one-click.** The client asked whether the emails could be
more interactive. A plain link won't do it: corporate mail scanners prefetch
links, so a mutating link would close tasks nobody completed. The spec puts four
options on the table — the mutating link, rejected; a safe confirmation page,
the one we built; Outlook Actionable Messages, true one-click but gated behind a
tenant security assessment that has taken this client five to six weeks before;
and Teams adaptive cards, technically the strongest, since the transcripts show
Teams is where these teams actually read things. The demo got the safe option
and the roadmap got the ambitious one, priced.

## What Got Built

### The design system

We took the company's existing UI kit and reworked it into markdown files
optimized for AI tooling to read. The front end got generated from those files,
which cut the build time enough to fit a two-week PoC.

### New notification system

The brief asked for five sample templates. It ended up as a full system:
recipient classes, an escalation ladder, change-request approval and result
flows, seven templates with final copy and layout, and a roadmap for making them
interactive. Three of the seven had no coverage in the user-story backlog at
all, including the pre-go-live reminder and the escalation ladder. Those are the
two templates that most directly answer *why doesn't anyone reply to our
emails*. It went back to the product owner as a finding.

### Design documentation

I co-owned the technical design document and wrote its UX-facing sections: the
six flows, the data rules, the demo script and the acceptance checklist. Writing
the acceptance criteria as the designer meant the standard the build got
measured against traced straight back to the interviews. It went through two
architecture-board reviews before the client saw it.

## Iteration & Feedback

Nothing here was designed once. The work went through two to three rounds of
revision. Most came from inside the team, usually a developer reading a flow and
finding a state I hadn't specified. The rest came from showing unfinished work
on calls: stakeholders and the client's cutover managers reacting to screens
that were visibly mid-build, while changing them was still cheap.

Before the demo we asked several of the client's cutover managers to spend time
with the application. It was deployed by then, so they could walk every flow end
to end. These are the people who run the operation the tool is for; their time
is expensive and they gave it anyway. What came back went into the build before
the presentation, so by demo day the people most likely to push back had already
seen their changes made.

The measured targets were verified twice in rehearsal: a committed change
visible on the dashboard within five seconds, timed on screen, and timezone
correctness across four zones. The demo script mapped every step to an
acceptance criterion from the client's own brief.

## Results

- **Stakeholders singled out the interaction and visual quality,** calling it beyond what they expected from a proof of concept. The client lead who opened by predicting a six-month roadmap saw working software two weeks later.
- **Every named pain point has a demonstrated answer:** three hours to five seconds on reporting, an audit row on every change, a notification system with real recipient logic, and an architecture reviewed against a 20,000-task ceiling instead of a 300-item one.
- **The limitations became the funding ask.** Every shortcut is paired with what production requires: SSO instead of seeded users, a real mail provider, multi-AZ, a formal accessibility audit. That table is the investment case, itemized.

The funding decision for the full build sits with senior client management.
Program outcomes and commercial figures are under NDA.

## How This Got Done

Two weeks of elapsed time, part-time alongside other projects. Seventeen hours
of my time in total, calls included — the alignment meeting, the walkthroughs,
the feedback sessions and the demo rehearsals all sit inside that number. The
build and the rest of the team's work sit alongside it.

AI tooling handled the volume — the pain-points map, the design document, the
email system, the design system spec. Every actual decision stayed a judgment
call: the three recipient classes, the manual "late" status, which of four
interactivity options to recommend.

---

Previous case: [Supply Chain Platform](https://semyonkuznetsov.com/projects/pharma-supply-chain.md)
· Next case: [Ketcher — Molecule Sketcher](https://semyonkuznetsov.com/projects/ketcher.md)