Skip to main content

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.

  1. The big spreadsheetBefore I cameEmail, spreadsheets, slides by hand
  2. The libraryAug to Sep 202558 screenshots, 17 diagrams
  3. The workshopSep to Oct 2025Data entry first, chatbot later
  4. The rule bookNov 202530 features, 11 versions
  5. Town hallDec 2025One pack, one red pen
  6. The test washJan to Feb 20265 changes traced, 8 to-dos
  7. Launch dayMar 2026Live March 2026, built by ECS
  8. Lost and foundApr 2026“Late” became “missing”
  9. Passing the batonMay 2026Handed over in May
  10. 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.

Original current-state swimlane showing business owners, Compliance, leadership and Audit exchanging risk updates, reminders, reports and evidence.(opens full size in a new tab)
Made by the teamThe old way. Updates, reminders and proof went from person to person by hand.
Original Excel mitigation tracker mock-data template with owners, action plans, target dates, and quarterly progress columns.(opens full size in a new tab)
Made by the teamThe spreadsheet itself: one row per plan, with owners, dates and a column for each quarter. This is my copy, filled with made-up data.
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.
LIBRARY58 screenshots

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

Made by the teamThe team’s Power BI demo, which I studied first. Filters change the counts and charts. Silent, 18 seconds, sample data.
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.
WORKSHOPTRY AGAINz zLATER!

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)

Original Figma prototype showing a compact risk register with search, risk categories, status, and priority alongside collapsible navigation.(opens full size in a new tab)
I made thisMy risk register prototype. Every risk in one list you can search.
A risk detail panel opens from the right while the register remains visible behind it. Overview, Mitigations, and Audit Trail organize the record.(opens full size in a new tab)
I made thisOpen a risk and a side panel slides in, so you never lose your place in the list.
Compact mitigation table with an action plan and separate quarterly progress indicators for each row.(opens full size in a new tab)
I made thisThe plans to fix each risk, with a progress dot for every quarter.
Team idea, my designsAn early assistant prototype I recorded, September 2025. Pick a question, get a short answer. Silent, 18 seconds. The answers are made up.
A risk register assistant with a chat history rail on the left, a welcome card stating how data access and audit traceability work, ten recommended action chips covering risk posture and mitigations, and an ask field with an oversight notice beneath it.(opens full size in a new tab)
Team idea, my designsThe assistant’s front door: ten ready-made questions and a clear note about who can see what.
Original Compliance Assistant proposal showing a linked mitigation and a Confirm Updates card with Confirm Changes, View Changes and Reject Updates.(opens full size in a new tab)
Team idea, my designsThe assistant never changes a record on its own. You check its change, then say yes or no.
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.
THE RULES

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.

I made thisMy prototype in action. Open a plan, pick Q2, then jump to the empty Q4 update. Silent, 18 seconds.
Original mitigation prototype with Evidence selected, one attached file, its metadata, and preview, download and delete controls.(opens full size in a new tab)
I made thisProof gets attached right next to the update it belongs to.
Original Figma prototype showing an Audit Trail with sample update events.(opens full size in a new tab)
I made thisA history tab, so anyone can see who changed what, and when.
My Work prototype showing a personal queue of assigned risks and mitigations with status tabs and target dates.(opens full size in a new tab)
I made thisMy Work is your own to-do list. This early version still shows “overdue”. Keep reading.
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.
TOWN HALL

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.

Business owner's red annotation circles Q1 on an ECS mitigation card and points to the quarterly progress summary.(opens full size in a new tab)
Business owner’s noteThe red pen. Clicking Q1 should open that quarter’s progress. My favorite piece of feedback all year.
ECS wireframe showing mitigation cards with owners, due dates, and quarter selectors.(opens full size in a new tab)
Made by ECSECS’s first wireframe, from my reference pack.
Figma dashboard exploration with a risk heatmap, status overview, priority list, and distribution charts.(opens full size in a new tab)
I made thisMy dashboard idea, in the same pack, so we could compare them side by side.
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.
TEST WASHtest

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.

Original Mermaid diagram separating the business owner's testing and issue documentation from ECS reproduction, requests for more information, fixes, and retesting.(opens full size in a new tab)
I made thisMy testing loop diagram. Log it, fix it, test it again, until it’s clean.
Original US OBU delivery schedule covering requirements, wireframes, access, testing, migration, training and go/no-go.(opens full size in a new tab)
Made by the teamThe release plan: requirements, access, testing and training on one schedule. These were target dates.
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.
RISK REGISTERECS

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.

Original export requirements slide specifies PDF, CSV and Excel, year and quarter filtering, and contextual report headers.(opens full size in a new tab)
I made thisMy report rules: PDF, CSV or Excel, filtered by year and quarter, with a header on every file.
Original support routing diagram separating business issues from IT issues through Compliance, Enabling Systems, ECS, Power Platform and Microsoft.(opens full size in a new tab)
Made by the teamWho to call after launch. Business questions and tech problems go down different roads.
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.
LOST + FOUNDQ2 updateNOT LATE.JUST MISSING.USGLOBALone app

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.

Original slide explains using shorter words and pictures to discuss a long specification across distributed teams.(opens full size in a new tab)
I made thisPage one of my plain-language deck says why it exists.
Original April slide comparing shared login, app code and workflow patterns with separate US and Global records, permissions, mailboxes, reminders and audit entries.(opens full size in a new tab)
I made thisOne app, two lists. The Global team got its own register, with its own records and permissions.
Original slide comparing one reviewer, two sequential review stages and two concurrent approvers, with their tradeoffs. One name is blurred.(opens full size in a new tab)
I made thisThree ways to run an approval, with the good and bad of each, so ECS could choose.
Figma policy-exception concept with an inbox on the left, submission context in the main column, and a smaller decision-entry column on the right. A demo-only banner identifies fictional data.(opens full size in a new tab)
I made thisMy policy exception prototype. The request gets most of the room, the decision gets the rest. Fake data, clearly marked.
The same sample request is Under Review in Cycle 2. The audit trail retains the original submission, a request for information, and the resubmission event.(opens full size in a new tab)
I made thisSend it back, fix it, send it again. The request keeps its number and its whole history.
Original April scope slide separates Phase 3 deferrals from items removed from the proposal.(opens full size in a new tab)
I made thisWhat we put off and what we cut. Saying no was part of the job.
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.
SPECAI WORKBENCHRISK REGISTER

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.
?NEXT TIME:MEASURE FROM DAY ONE

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.