When a new system is live and the project dashboard is green, I would ask a different question: what work has actually changed? In my public LinkedIn writing, I used the example of a CRM dashboard that leaves field managers maintaining a parallel spreadsheet. The spreadsheet may be risky. It may also reveal a requirement the design missed.
Here is a practical 30-day check for a transformation team. It is an illustrative approach, not a description of an employer project.
Days 1–5 — Walk the work
Choose two or three representative roles and ask them to demonstrate a common task from start to finish. Record every system, spreadsheet, approval and manual transfer involved. Compare the current process with what the business case said would change.
Output: a workflow map showing steps added, steps retired and parallel processes that remain.
Days 6–10 — Classify the friction
For each workaround, ask: what job does it perform, what risk does it create, and what would make it unnecessary? Classify the cause as workflow (missing step or information), structural (unclear ownership or decision rights), or capability (skills, support or capacity). Address any immediate privacy, data, patient or compliance risk through the appropriate governance route.
Output: a prioritized friction register with severity, owner and proposed action.
Days 11–20 — Fix one important break
Select a friction point that materially affects work and is feasible to resolve. Bring together users, process owner, technology and relevant control functions. Test a revised workflow. If the problem is local, decide whether it merits an approved exception or a change to the common design.
Output: a tested change, clear ownership and an agreed retirement condition for the old workaround.
Days 21–30 — Verify that work changed
Observe the process again. Did duplicate entry stop? Is the required information available in the approved system? Are decisions clearer? Do people still use the spreadsheet? If so, why? Record what remains unresolved instead of turning the project status green by default.
Decision: accept the revised workflow, continue the targeted fix, escalate a structural decision or stop a risky practice.
Worked example: the shadow spreadsheet
Field managers maintain a spreadsheet with three missing fields: a customer commitment, a pending medical follow-up and the next planned action. Do not simply add three columns without checking permissions, responsibilities and process design. First confirm the business need and risks. Then identify where the information belongs, who may access it and what handoff is required. Test the approved solution and retire the spreadsheet only when the job it performs is covered.
What to report to the steering committee
Keep project milestones, but add five operating measures: important tasks retired, duplicate steps still in use, workarounds by risk level, unresolved decisions and evidence that the new process is usable. Show a named owner and due date for each material exception.
When to resist local customization
Some workarounds reflect a genuine market need; others preserve habits or introduce unacceptable risk. The team should not automatically institutionalize every workaround. Evaluate customer value, enterprise standards, local constraints and the cost of maintaining an exception.
A transformation is not complete because the new system exists. The useful milestone is when the intended work can be done reliably without the old parallel process.
Follow the decision
What work disappeared after the launch? This question connects to two other parts of the operating model:
Illustrative diagnostic based on my public writing on workarounds, market co-design and program governance. The views I share are my own and do not represent those of my employer.
Put this into practice
Transformation must remove an old step—not add another layer.
Use the Transformation Friction Register to identify shadow processes, owners and the evidence that the new workflow has replaced the old.
Open the Transformation Friction Register