A Change Impact Assessment that normally took about a week was completed in roughly two days on a recent engagement. The time savings are interesting, but they are not the story. The real change is that the faster version achieved deeper insight because the hours freed were reinvested into analysis rather than administration.
What follows is how that happened, the unglamorous prerequisite most AI stories leave out, and what it changed about the deliverable at the end.
Most of the time went to handling data, not analyzing it
A Change Impact Assessment is not a document you generate out of thin air. It starts with the list of changes a program is making, then goes through stakeholder interviews to uncover what those changes mean on the ground: what shifts for each team, what they need to hear and when, which risks need mitigation, and who will resist and why.
The valuable part of that work is interpretation. The expensive part was everything around it. Transcribing interviews. Normalizing what people said into comparable categories. Mapping responses back against the change list. Rolling all of it into trend views and risk views by group.
That handling layer consumed the schedule, which meant depth got rationed. You went one or two passes deep because that was what the calendar allowed, and you called the third pass a nice-to-have. Anyone who has run this work knows the third pass is where the useful findings live.
The prerequisite: one dataset, entered once
Before any AI assistant touched the analysis, the data had to stop being scattered.
The rebuild was mundane. A set of linked workbooks where the change list gets entered once and flows into every interview template, and every completed interview flows back into a single master dataset. No re-keying. No reconciling four versions of the same list. No analyst spending Thursday afternoon working out which spreadsheet is current.
This is the step most AI adoption stories skip, and it is usually why the story ends badly. An assistant pointed at inconsistent, half-structured, manually re-entered data produces confident nonsense. Pointed at a clean master dataset, it produces analysis that holds up in a room full of stakeholders. Ultimately, AI amplified the quality of the underlying data. When the inputs were consolidated into a single dataset, the outputs became significantly more useful. The technology mattered, but the structure around it mattered first.
The analysis that used to get cut for time
With the structure in place, the analysis layer became a repeatable set of prompts run against the master data, alongside a standing report outline. Executive key messages. A cascade kit so leaders have something concrete to carry into their own team meetings. Trend analysis by group and by change type. Risk interrogation from several angles rather than one.
The prompts were not used to replace analysis. They encoded the questions experienced change practitioners ask during every assessment:
- Where are the adoption risks?
- Which groups disagree?
- Which themes appear repeatedly?
- Which comments contradict executive assumptions?
- Which findings deserve escalation?
That distinction matters. The goal was never to automate judgment. The goal was to make repeatedly asking the right questions inexpensive enough that the analysis could go deeper. More importantly, it ensured those questions were asked against the entire body of interview evidence every time, rather than only the subset an analyst had time to review manually.
Before, there was rarely enough time to explore the same dataset from multiple angles. Once the evidence was structured, those questions could be applied repeatedly and consistently. The result was not machine-generated insight. It was a faster path to evidence that practitioners could challenge, test, and interpret.
None of those outputs were new ideas. They were the things that always belonged in a thorough analysis and were always the first casualties of the schedule. What changed is where the hours go. Traditionally, consulting scales by adding people. More interviews require more analysts, more spreadsheet consolidation, and more manual synthesis. Once interviews are captured in a common structure, portions of the analysis become repeatable. A consultant can review the same body of evidence from multiple perspectives in hours rather than days.
The benefit is not simply speed. It is a different allocation of expertise. Experienced practitioners spend less time assembling information and more time interpreting it, challenging assumptions, and identifying the actions that matter most.
The report started solving a different problem
Every change practice eventually has the same internal argument, and ours had it over a change impact report that ran to well over a hundred pages.
You’ve lost your mind giving them all this information.
The instinct behind that objection is sound. Nobody reads a report that size cover to cover, and page count has never been a proxy for insight.
The counter-argument is simpler. Organizations pay for those interviews, and employees give up their time to participate. The value is not in filtering the evidence down to a consultant’s interpretation. The value is in making the evidence accessible enough that leaders can explore it themselves.
Before, conclusions often depended on an analyst’s synthesis. Now every recommendation can be traced directly back to the interview evidence that produced it. Leaders can move from a summary finding into the underlying comments, contradictions, and supporting observations.
At some point the report stopped being the deliverable. The structured evidence became the deliverable, and the report became a way of navigating it.
That changed the nature of the conversation. The question was no longer whether leaders agreed with the consultant’s opinion. The question became whether they agreed with what their own organization was telling them.
The result was a live action list rather than a document in a shared drive, and something less expected came with it. Change impact data gathered at that depth does not only describe how teams will react to a program. It exposes the governance questions the program itself has not settled: which KPIs it is accountable for, who owns which decision, where the responsibility model sits. Questions like those drift around hallway conversations for months at almost any large organization. Written down with evidence attached, they become an agenda item.
That is the difference worth noticing. A summary tells a leadership team what an outside adviser thinks. A complete, navigable record puts their own organization’s words in front of them, and that is much harder to defer.
One caution. This only works when volume is a side effect of coverage rather than a goal. Padding is still padding, however fast it gets produced. A report earns its length when every section is navigable and points somewhere.
Next: turning creation into validation
Migrations rhyme. An organization moving off spreadsheets onto a PLM platform faces a recognizable set of changes, impacts, and affected groups, and so does the next one.
So the next build is narrower and more useful than a general-purpose assistant: a model seeded with our own project data, organized by migration archetype. Describe the situation, where a company is coming from and what it is moving to, and get back a first draft of the likely changes and the likely impacted groups. Not an answer. A starting point to react to.
That distinction carries a practical payoff for the people on the receiving end. Subject matter experts inside a transformation do not have five spare hours a week to sit with an analyst and build a change list from nothing, and asking for that time is what stalls most impact assessments into a multi-week back-and-forth. The same person can review a draft in forty minutes. Turning a blank-page exercise into a validation exercise is the whole compression.
Building it on project history rather than public data is the point. A general model will list every change that could theoretically occur in a transformation. Real project history shows which ones actually show up, in what order, and which groups feel them hardest.
Key takeaways
- Time savings only matter if they create deeper analysis. AI is valuable because it shifts effort from administration to interpretation. A faster report is nice. A more insightful report is what clients actually buy.
- Structure beats technology. The breakthrough started with shared data, connected templates, and a single source of truth. AI amplified that foundation.
- Ask for evidence, not just conclusions. Executive summaries remain valuable, but their credibility increases when every finding can be traced back to the comments, themes, and observations that produced it. The report should be a navigation layer over the evidence, not a substitute for it.
- The future belongs to validation, not creation. Experts rarely have time to build from scratch. Starting with a credible first draft turns weeks of back-and-forth into a focused review process.
- Consulting scales differently when evidence is structured. Consulting has traditionally scaled by adding people to collect, consolidate, and analyze information. Structured datasets change that equation. The repetitive work becomes more repeatable, allowing experienced practitioners to spend more time applying judgment, testing assumptions, and interpreting findings. The result is not fewer experts. It is more leverage from the experts you already have.