Overcoming the Silo and Perceived Data Problems

So far in this series I’ve made the case for collaborative capital planning across smaller public sector organizations and then knocked down the most common objections I hear when I suggest it.  

This post tackles what people assume is the hardest part — the data.  I say “assume” because most of the data concerns I hear about collaboration turn out, on closer inspection, to be solving problems that don’t actually exist. 

The Silo Problem

Somewhere along the way, public sector organizations decided that what they do is so unique to their sector that they have nothing meaningful in common with their neighbors. Hospitals look at school boards and see a different world. Municipalities look at universities and see a different world. School districts look at long-term care facilities and see a different world. 

I understand why. The programs are different. The funding models are different. The regulatory environments are different. The people you serve are different. 

But the buildings? The buildings are not that different. 

A roof is a roof. A boiler is a boiler. An electrical distribution panel is an electrical distribution panel. The roof on a hospital and the roof on a high school are subject to the same weather, the same materials science, the same failure modes, and the same contractor market. The HVAC system in a city hall and the HVAC system in a community college are made by the same handful of manufacturers, installed by the same handful of contractors, and maintained on the same general schedules. 

If you can get past the idea that your sector is fundamentally different from the one next door — at least when it comes to the physical assets you steward — the door to collaboration opens. If you can’t, it doesn’t, and the rest of this post is academic. 

What Collaboration Actually Requires

Here’s the thing I want to clear up, because I think it’s where a lot of the data anxiety comes from. 

I am not suggesting that you and your neighbor merge your datasets, harmonize your FCA scales, agree on a shared EUL methodology, or run your CMMS platforms in lockstep. I am not suggesting you show each other your asset inventories or expose your condition data to outside scrutiny. 

What I am suggesting is much simpler. Each organization independently identifies the projects it wants to do in a given year. Then you sit down with your neighbors and either bundle complementary projects into a shared procurement — pool the roofs — or sequence things so you’re not all competing for the same trades in the same year. 

The unit of collaboration is the project, not the dataset. 

Your FCA can say the roof is in poor condition. Your neighbor’s gut feel can say their roof needs to go. A third partner can have a brand new condition assessment from a different firm using a different scale. None of that matters at the point of collaboration, because what you’re putting into the shared procurement is not a condition rating — it’s a project. “30,000 square feet of EPDM roof replacement, accessible from grade, to be completed between May and September of next year.” That’s procurement language, not asset data. 

The Perceived Data Problem

So if you don’t need shared data to collaborate, why am I writing a post about data at all? 

Because you do need good internal data — defensible, consistent data inside your own organization — to be a credible partner to anyone. And this is where a lot of organizations get stuck before they ever get to the collaboration conversation. 

If you cannot confidently commit to “yes, this roof, this year, at this scope” then you cannot put it into a shared tender with your neighbor. Not because your data needs to match theirs. Because your data needs to be good enough that you can stand behind the commitment. 

That is the work that has to happen, and it is the same work I’ve been writing about for years. Consistent and defensible data. A desired dataset that lets you make capital planning decisions you can defend to your CFO, your Board, and your auditors. Whether you ever collaborate with a neighbor or not, this work has to get done. 

The collaboration conversation just makes the cost of not doing it more obvious. If your capital plan is a wish list rather than a defensible commitment, you can’t credibly bring it to a table with three other organizations. They will figure that out fast. 

Above-the-Line and Below-the-Line

The way I think about this is in terms of what has to be consistent across organizations and what doesn’t. 

Above the line — the things that need to be agreed between partners — are at the project and procurement level. Shared technical specifications for the tender. Aligned timelines. A common contract structure. Agreed allocation of cost. Agreement on who leads the procurement and how decisions get made. 

Below the line — the things every organization can absolutely keep their own way — is everything else. Your CMMS platform. Your fiscal year. Your asset numbering conventions. Your internal cost codes. Your condition rating scale. Your FCA methodology. Your reporting structure. 

Most organizations assume collaboration means harmonizing everything. It doesn’t. It means agreeing on what has to be above the line — at the project level — and leaving what is below the line alone. 

This is exactly the gap that cooperative procurement agreements are built to bridge. They give you a contractual framework that can hold multiple parties with customized scopes inside a single procurement, without requiring anyone to give up the autonomy of how they run their own shop. 

Where This Leaves Us

The barrier to collaborative capital planning isn’t shared data. It’s defensible internal data, in each organization, well enough developed that they can each bring real commitments to the table. 

That isn’t a collaboration problem. It’s a data quality problem each of us has on our own, whether we ever talk to our neighbors or not.  Collaboration just rewards the organizations that have done the work, and exposes the ones that haven’t. 

In the next post I’ll wrap up the series with where to start if you want to actually try this — the smallest possible first step from “good idea” to “we did it.”