Dear reader,
A few years into my time as IT Manager at a peak body, we went to market for a new intranet. Behind the scenes it was a genuine mess: file shares everywhere, no consistency, and a small staff team supporting a much bigger organisation, board members, committees, and volunteer groups, all needing some kind of access to information, just not the same access.
A polished proposal, with one blind spot
One of the proposals came from a large consulting firm. The structural analysis they produced was genuinely good, good enough that we ended up keeping and adapting parts of it later. But the overall approach was scoped the way you'd scope a standard commercial project: understand the requirements, design the ideal end state, build it in one go.
What it didn't properly account for was volunteers. Board members, committee members, group members, people who weren't staff but who absolutely needed access to parts of the system. That wasn't really a technical failure. It was a scoping failure, nobody had asked, early enough, who actually needed to use this thing beyond the people on the payroll.
Some of that was on us too
I'll be upfront: part of the gap was our own doing. We hadn't fully worked out what we needed before going to market. It's easy, when you're deep in the day-to-day as staff, to under-represent the wider structure sitting above and around you. But that's exactly where a good vendor should earn their fee, not by arriving with the most polished answer, but by asking the questions that help a client figure out what they actually need in the first place.
What we ended up building
In the end, I took the parts of that analysis that were genuinely strong, adapted them to how the organisation actually worked, and built the intranet in-house. It saved the organisation somewhere in the vicinity of $50,000 in implementation costs.
I don't raise that to suggest I did a better job than a large firm could. I raise it because the reason it worked wasn't cleverness. It was that I understood the governance structure from the inside, the boards, the committees, the volunteers, because I lived inside that structure every day.
Why this matters beyond one project
Associations aren't run like standard businesses. Decisions move through boards and committees. Staff often report to a volunteer president rather than a single decision-maker. A project scoped like a normal commercial engagement, jumping straight from nothing to the ideal solution, tends to miss the people who aren't in the building every day but still need to be part of the system.
So if you're about to scope a website, an intranet, or a membership system, it's worth asking a more basic question before anyone talks about the ideal solution: who actually needs a seat at this table, not just staff, but across your whole governance structure? Getting that answer right matters more than any feature list.
Until next week,
Brock