Dear reader,
A few years ago, as IT Manager at a leading association, I designed and built an intranet spanning 30 connected sites. From the outside, that's a technical project. Site structure, permissions, navigation, the usual list.
From the inside, it taught me something the technical list doesn't capture at all: the software was never the risky part. The risky part was everything that lived in people's heads instead of in the system.
The workaround nobody wrote down
Every association has a version of this. A particular way of pulling a report that only makes sense if you know why it's done that way. A number someone just remembers rather than looks up. A process that technically exists in a document somewhere, but that everyone actually does slightly differently, because the document was written once and the reality moved on without it.
None of this shows up as a problem day to day. If anything, it looks like the opposite of a problem. Things get done, deadlines get met, the organisation runs. That's exactly what makes it dangerous. A gap that never gets tested doesn't announce itself. It just sits there, quietly becoming the thing the organisation actually depends on, right up until the person holding it leaves, goes on leave, or gets busy with something else.
Building out those 30 sites meant sitting with a lot of individual staff members and asking, in effect, "how do you actually do this?" More often than I expected, the honest answer wasn't in any manual. It was a workaround someone had built, quietly, because it worked, and because nobody had ever asked them to write it down.
Why this is a governance problem, not just an IT one
It's tempting to treat this as a systems issue, something a better platform or a tidier folder structure would fix. It isn't, or at least, not primarily. Associations run on small teams and volunteer boards, and small teams under real pressure will always adapt faster than documentation gets updated. That's not a failure of discipline. It's what happens when a handful of people are covering a workload that would reasonably need more of them.
Which is exactly why it's a governance question rather than a purely technical one. A board making decisions about resourcing, succession, or a platform change is making those decisions on the assumption that the organisation's processes are what the documentation says they are. When the two have quietly drifted apart, the board is working from a picture that's already out of date, often without anyone realising it.
What's worth mapping before you buy another tool
If any of this sounds familiar, the useful next step usually isn't a new system. It's a genuinely honest audit of where the gaps between "documented" and "actual" already exist. A few practical places to start:
The processes only one person can run. Not the ones that would be inconvenient if they left. The ones that would actually stop, or need to be reverse-engineered from scratch, if they weren't available for a month.
The reports nobody remembers how to rebuild. If a number gets pulled the same way every quarter but the method lives in one person's memory rather than a written step, that's worth capturing before it's needed under pressure.
The workarounds that exist because the "official" way stopped fitting. These aren't failures. They're usually evidence someone adapted sensibly to a real gap. But an adaptation that's never fed back into how the organisation actually documents its own process is knowledge the organisation doesn't really have, it's knowledge one person has, on the organisation's behalf.
The lesson from those 30 sites
The technical build was the visible part of that project. The more useful part, the thing I still carry into every intranet and systems project since, was learning to treat "who actually knows how this works" as a real question worth asking early, not a detail that surfaces later when something breaks.
Good systems don't remove the need for people to understand how their organisation runs. But they can make that understanding something the organisation actually holds onto, rather than something it's quietly borrowing from whoever happens to remember it this year.
If this sounds like your association's intranet, or the systems sitting underneath it, get in touch and we can talk through what's actually worth mapping first.
Until next week,
Brock