The work described here comes from my role at a university, not from a BriefDesk engagement. It is my own record, and I share it because it shaped how I approach review and integration work.
Most organizations I’ve worked with don’t have a quality problem. They have a duplication problem.
Different units get reviewed on different timelines by different teams using different templates. Each review produces its own report, its own recommendations, and its own follow-up tracker that somebody maintains for six months before it quietly dies in a shared drive. Meanwhile, the next review cycle starts from scratch as if the last one never happened.
I spent the better part of two years helping lead a committee tasked with fixing exactly this at a multi-campus university. The mandate was straightforward on paper: take all the separate entity reviews, programme reviews, and accreditation requirements and merge them into one integrated framework. In practice, it meant nine versions of a report, hard conversations about who owns what, and a final position that looked nothing like where we started.
Here is what I learned.
Fragmentation is not an accident
Nobody wakes up and decides to create five overlapping review processes. It happens gradually. A new accreditation body requires a self-assessment. A board requests an entity-level review. A quality assurance unit introduces programme audits. Each one is reasonable on its own. But over time, the people being reviewed are filling out forms that ask the same questions in slightly different ways for slightly different audiences, and nobody is connecting the findings.
The cost is not just time, though the time cost is real. The bigger cost is that gaps fall between the cracks. When findings live in separate documents owned by separate offices, nobody sees the full picture. A staffing issue flagged in one review and a curriculum gap flagged in another might actually be the same problem, but they get treated as unrelated because they were surfaced through different processes.
Integration is a governance problem, not a technical one
When we started, I assumed the main challenge would be designing the right framework. Figuring out the domains, the indicators, the reporting templates. That part was hard, but it was the kind of hard you can solve with drafts and revisions.
The real challenge was getting people to agree on ownership. Who convenes the review? Who maintains the gap tracker after the committee disbands? Who reports to the board? These are governance questions, and they are where most integration efforts stall.
We stalled there too. More than once.
What eventually worked was being specific about the handoff. Instead of saying “the quality assurance function will manage ongoing tracking,” we named the unit, named the reporting line, and named the body it would report to. Ambiguity is where accountability goes to disappear.
Start with what you are already doing
One temptation with any integration project is to build something entirely new. A fresh framework, new domains, new language. It feels cleaner. But it also means nobody recognizes themselves in the output, and adoption drops.
We took the opposite approach. We mapped what already existed: the self-assessment reports, the programme-level reviews, the accreditation standards. Then we looked for where they overlapped. It turned out that about 70% of what different review processes were asking for was the same information packaged differently. The remaining 30% was genuinely unique to each context and needed to stay that way.
The integrated framework we landed on covers eleven domains across all entities, with a single five-year review cycle. Accreditation-specific requirements slot into the relevant domain rather than running as a parallel process. It is not perfect, but it is one process instead of five, and that alone changes how people engage with it.
The gap tracker matters more than the report
Reports are important. They document findings, assign responsibility, set timelines. But I have watched enough reports get submitted, acknowledged, and forgotten to know that the report is not where change happens.
Change happens in the follow-up. Specifically, it happens when someone is responsible for maintaining a live record of what was found, what has been addressed, and what remains open, and when that record is visible to people with authority to act on it.
We built this into the framework from the start: a permanent gap tracking repository, maintained by the quality assurance unit, with regular reporting to a standing committee. The tracker doesn’t reset between review cycles. Unresolved gaps carry forward. That continuity is the whole point.
Nine versions is normal
I want to be honest about this part. The framework took nine major revisions. There were points where the direction changed significantly, including a full reset directed by senior leadership after they reviewed an earlier version and decided the scope needed to shift. That felt discouraging at the time. Looking back, it was the process working as it should.
Governance frameworks that survive contact with reality are the ones that get stress-tested before launch. Every version that got challenged, reworked, or sent back was a version that taught us something about what the institution actually needed versus what we assumed it needed.
If you are leading a similar effort and you are on version four and feeling like progress is slow, it probably means you are doing it right.
What I would tell someone starting this work
Keep the committee small enough to make decisions and senior enough that those decisions stick. Document every assumption, because assumptions are what come back to haunt you in version six. Build the tracking mechanism before you finalize the framework, not after. And accept that the final product will not satisfy everyone equally, because integration means some units lose autonomy over their own review process, and that is a real trade-off, not a minor detail.
Institutional quality is not about how many reviews you run. It is about whether the findings connect, whether someone owns the follow-up, and whether the whole system learns from itself over time.
That is harder to build than another audit template. But it is worth it.
First published on LinkedIn on 11 June 2026. Read the original.