Some years ago I managed the SharePoint team at a large public sector organisation. We were asked to find every Microsoft Access database on the network. My team ran the search, and I reported what we found.
Access came bundled with Office, so it had been handed out to staff for years, usually with no training and no guidance on when it was the right tool.
We found around 4,500 of them. That was roughly one database for every three members of staff, in an organisation where many people worked on the front line and rarely sat at a computer.
What the search turned up
Some of the databases were in daily use. Many were not. They were copies left where someone had saved them before moving on, or backups taken just in case. Unused did not mean empty. Plenty of them still held the organisation's data, and nobody was looking after it.
Even more turned up as email attachments, forwarded between colleagues and kept in inboxes, where no search of the network would ever reach them. I wrote recently about why organisations find it so hard to let go of old information. This was the same problem, multiplied by every inbox.
What happened next
We did more than count them. The team assessed each one: whether it was still in use, what kind of data it held, and roughly what it would cost to move it into a system the organisation could manage properly. I took that assessment to the head of operations.
Cost was the sticking point. The databases that mattered most tended to be the least well built, and to all intents and purposes nobody could support them. That made them the most expensive to move. With no budget to do it, the organisation did the one thing it could afford: it took Access out of the standard set of software given to staff.
That stopped new databases appearing. It did nothing about the thousands already there, or the copies sitting in people's email. Removing a tool does not deal with what people have already built with it.
The same pattern, newer tools
Most Microsoft 365 licences now include Power Automate, which lets staff build their own automated processes: move a file when it arrives, send a form for approval, update a list every morning. It is useful, and it is in the hands of everyone with a licence. AI assistants that staff can set up for themselves are heading the same way.
The safeguards exist. Microsoft offers version history for these automations, and separate areas where they can be built and tested before anyone relies on them. But version history only works for automations kept in a managed area, which is not the default, and someone has to set that up. In many organisations an automation built on a Tuesday afternoon is in use by Wednesday, with no earlier version anyone could go back to.
And the oldest version of the story is still with us: the spreadsheet one person built to make their own job easier, which years later produces a figure in the board pack that nobody else fully understands.
How personal becomes critical
Nobody decides to make these things critical. A tool built to help one person gets shared with the team, and before long the team does the job no other way. By the time the person who built it leaves, it is part of how the organisation runs, without ever having passed through the checks applied to systems the organisation chose to buy. And the longer it goes unmanaged, the more it costs to put right.
One thing has changed since the Access days. Then, the organisation could take the tool away. Today's tools come with the licence and are part of the products staff use all day. Removing them is harder, and would lose real benefits. So the work has to happen earlier: knowing what is being built, and recognising when something has become important enough to be looked after properly.
What a board can ask
Which of our important processes depend on something a member of staff built for themselves, such as a spreadsheet or an automation?
If the person who built it left tomorrow, who could keep it running?
When one of these becomes important, who decides it should be brought under proper management, and is there money set aside to do that?
Do we know where copies of our data sit in files nobody uses any more, including in email?
The staff who built those 4,500 databases were solving real problems with the tool they had been given. What was missing was anyone whose job it was to notice when one of them started to matter, and a budget to act when it did.
