The Very Big Spreadsheet
How I helped turn the US Oncology risk register at AstraZeneca from a messy spreadsheet into an app a whole team could build, test and launch.
Map of the town
Follow the road from the big spreadsheet to launch day. Each stop has a short story, the real things I made, and a flap with the proof. A runaway envelope hides at every stop. See if you can find it.
- The big spreadsheetBefore I cameEmail, spreadsheets, slides by hand
- The libraryAug to Sep 202558 screenshots, 17 diagrams
- The workshopSep to Oct 2025Data entry first, chatbot later
- The rule bookNov 202530 features, 11 versions
- Town hallDec 2025One pack, one red pen
- The test washJan to Feb 20265 changes traced, 8 to-dos
- Launch dayMar 2026Live March 2026, built by ECS
- Lost and foundApr 2026“Late” became “missing”
- Passing the batonMay 2026Handed over in May
- What nobody measuredThe end?No usage numbers yet
The drawings are new. Every screenshot, slide, diagram and video is from the real project, with sample data.
Once upon a time, there was a very big spreadsheet.
The Compliance team kept a list of business risks for the US Oncology Business Unit. The list lived in a spreadsheet. Updates came in by email. Every quarter, someone built the leadership slides by hand.
It was hard to see who owned each risk. It was hard to see what had changed. And when auditors asked for proof, everyone went digging.
(opens full size in a new tab)
(opens full size in a new tab)Lift the flap for the proofdates, counts and sources
- The team named four problems: the work was manual and scattered, it was hard to see, it was hard to audit, and it was a lot of work for the people filling it in. Source: the team’s project overview deck, page 3.
- Compliance made the spreadsheet templates in May 2024 and June 2025, before I joined.
First, I went to the library.
I didn’t start by drawing screens. I started by learning how the work really happened. In my first weeks I took 58 screenshots and drew 17 flow diagrams.
I also made copies of the spreadsheets filled with made-up data. That way the team could design with real fields and no real records.
On 22 September 2025 I wrote a design document. It listed six goals and four groups of people. For each group I wrote what they needed, what hurt, and what success would look like.
Needs: An easy way to update their risks.
What hurts: Too many spreadsheets. Unclear who owns what.
Business owners
Needs: To see every risk and its history.
What hurts: Chasing people by email. No record of edits.
Compliance
Needs: Trends at a glance, and detail when they want it.
What hurts: Waiting for slides made by hand.
Leaders
Needs: Proof they can export and trust.
What hurts: Slow exports and a fuzzy history.
Auditors
Lift the flap for the proofdates, counts and sources
- 58 screenshots and 3 screen recordings, dated 27 August to 29 September 2025. 17 Mermaid diagram exports, dated 16 to 25 September 2025. Counted from file names in the project archive.
- Mock-data copies of both Compliance spreadsheets, last saved by me on 17 September 2025.
- My design document: 20 slides, created 22 September 2025. The success measures in it were goals. Nobody measured them.
Then I built fast, with an AI helper.
With the goals written down, I used Figma Make, an AI design tool, to build clickable prototypes. I gave it my goals and my four groups of people. I didn’t take its first try. I asked it to grade its own work, told it the pieces needed serious rework, and had it rebuild them on a shared design system.
I also helped design a team idea, an AI assistant that could answer questions about risks. But on 16 October 2025 we made a call. Getting data in comes first. The chatbot could wait. A risk register nobody can fill in doesn’t need a chatbot yet.
Try my risk register prototype(opens Figma in a new tab)
(opens full size in a new tab)
(opens full size in a new tab)
(opens full size in a new tab)
(opens full size in a new tab)
(opens full size in a new tab)Lift the flap for the proofdates, counts and sources
- My Figma Make files for the assistant were created on 1 and 2 October 2025. The register prototype reached version 33.
- Meeting minutes, 16 October 2025: “Priority is given to the data entry phase.” The chatbot was put off, and ECS would run support.
- The assistant work was a team proposal. I added design ideas to it. It was never released.
I wrote the rule book.
A prototype shows an idea. A builder needs rules. On 14 November 2025 I wrote version 1.0 of the requirements document. I was the only author, and I kept it up to date for five months.
It said who can do what, what each screen must do, and what an auditor would check. Two of my favorite rules:
Cancel a risk, keep the finished work.
Unfinished plans get canceled too. Work that is done stays in the record.
Sent for review? Hands off.
Sending a plan for review locks it. Nobody can review their own work.
(opens full size in a new tab)
(opens full size in a new tab)
(opens full size in a new tab)Lift the flap for the proofdates, counts and sources
- Version 1.0: 14 November 2025, author “SB”. Last version: 1.10 on 27 April 2026. That is 11 versions.
- By version 1.10 it had 30 features: 18 for the first release, 11 for Phase 2, and one policy-exception workflow in its own section, waiting for approval.
- It had 11 security, 7 data-integrity and 5 privacy requirements. I filled those in from AstraZeneca’s template and from reviews other teams ran.
- 10 user roles, 7 use cases, and a chart that gives each of 12 actions a clear owner.
- The approval signature boxes are blank in every copy I have, so I don’t claim a formal sign-off.
I got everyone looking at the same thing.
Before ECS started building, I made one reference pack. It put four things side by side: the old spreadsheets, the Power BI demo, my Figma screens, and ECS’s first wireframes.
Now we could point at real buttons instead of guessing. The business owner took a red pen to ECS’s wireframe. Click Q1, she wrote, and show that quarter’s progress, without going into edit mode. ECS confirmed the change, and she approved the wireframes with one fix.
(opens full size in a new tab)
(opens full size in a new tab)
(opens full size in a new tab)Lift the flap for the proofdates, counts and sources
- The reference pack and ECS’s wireframe are both PDFs from December 2025.
- 18 December 2025 working session: the Admin is the only one who can delete a risk. Deleting a plan needs a written reason for the record.
- January 2026 sessions: two owner roles were merged into one, and exports became PDFs with their history.
We tested, fixed, and tested again.
In January the business asked for 5 screen changes. Before any of them reached the build, I traced each one back to the rule book or to the person who asked. None of them changed how the data was stored, so the build date could hold.
Then came testing. I planned when it starts, when it’s done, and how each role gets tested. The business owner found the problems and ECS fixed them. On 19 February I sent everyone 8 clear to-dos.
We also moved one rule, the one that flags late work, to Phase 2. A steady first release mattered more. The app still launched later than the first plan, because we kept adding requirements.
(opens full size in a new tab)Lift the flap for the proofdates, counts and sources
- 28 January 2026: my traceability memo lists 5 change requests. It says there was no data-model impact and the 13 February build target “remains intact”.
- Version 1.1, 9 February 2026: new canceled status, user permissions and quarter tracking. The dashboard moved to Phase 2.
- 18 February 2026, my email: “Overdue Rule logic has been officially deferred to Phase 2.”
- 19 February 2026, my testing recap: 8 numbered action items and 2 parked items.
Liftoff! ECS launched the app.
ECS built the risk register in Power Apps, and it went live in March 2026. That was about four and a half months after my first draft. To be clear, I wrote the rules. ECS built the app.
Then real use taught us something. The business owner needed each quarter’s progress in her committee report, and the app couldn’t include it. I sketched a way to pick which fields go in the report, and wrote year and quarter filters into the rules. She said picking the fields was exactly what she needed.
(opens full size in a new tab)
(opens full size in a new tab)Lift the flap for the proofdates, counts and sources
- On 23 April 2026 the business owner said the app “got launched end of last month”. That proves the month, not the day.
- The report sketch was a proposal. The record shows she liked it. It doesn’t show that it shipped.
The day “late” became “missing”.
For Phase 2 I wrote a plain-language deck. The rule book was long, and the team was spread across time zones. So I used short words and one idea per slide. If we agreed on it there, nobody could say later they didn’t know.
On 21 April my deck said a task was late if nobody touched it for a set number of days. Two days later, the business owner stopped me. The work might be done, she said. Someone just hadn’t written it down yet.
She was right. Calling finished work “late” would leave a bad mark in the audit history. So I rewrote the rule around missing updates instead.
21 April
Late
Nobody touched it for a set number of days.
23 April
Missing
This quarter’s update is blank. It shows up in My Tasks until someone records it. No red, no blame.
(opens full size in a new tab)
(opens full size in a new tab)
(opens full size in a new tab)
(opens full size in a new tab)
(opens full size in a new tab)
(opens full size in a new tab)Lift the flap for the proofdates, counts and sources
- Plain-language deck, 21 April 2026. Page 6 has the old “late” rule.
- 23 April 2026 walkthrough: “missing” was chosen over “overdue” to avoid a bad mark in the audit trail. The team had already removed the red warning color on 2 April.
- Rule book versions 1.7 and 1.8, same day: blank updates for this quarter appear in My Tasks, older gaps stay until recorded, and future quarters stay out until they start. Reminder emails open My Tasks directly.
- 16 April 2026: the Global register was approved. ECS planned to build Phase 2 in three pieces, one at a time. That is a plan, not a finish line.
- The policy exception workflow had its own section, waiting for a separate Compliance committee sign-off.
I passed the baton.
In early May I walked a teammate through the Phase 2 rule book and started handing the register over. Then I moved on to the next big job: an AI Workbench prototype, one shared app for five workflows and four teams. That’s a different book.
Try my policy exception prototype(opens Figma in a new tab)
Lift the flap for the proofdates, counts and sources
- 5 to 7 May 2026: handover started. I haven’t seen a final sign-off that it finished, so I call it started, not done.
- The Workbench was a prototype on sample data. Teammates owned the backend and the know-how behind each workflow.
The part nobody measured.
Here is the honest page. There is no record of how many people used the app, or how much time it saved. We pushed the dashboard for tracking results by role to Phase 3. I asked ECS for a weekly view of requested, active and done work. By May, ECS still hadn’t started using it.
Next time, I’d set up the numbers on day one. How many owners update on time? How long does the quarterly report take? How many updates go missing? A story is nice. A number is proof.
Lift the flap for the proofdates, counts and sources
- No adoption count, time saved, KPI result or survey exists in the project record.
- The role-based KPI dashboard moved to Phase 3 in the 21 April 2026 deck.
- 5 May 2026: I asked ECS for the weekly requested, active and done view. The record says it hadn’t been adopted.