A single spreadsheet works fine until it doesn’t. Here’s what actually breaks as a GC scales from a handful of active projects to dozens, what a real multi-project compliance architecture needs to replace it, and how to know when you’ve already outgrown the one you’re running now.
What contractor management software handles complex hierarchies?
The software built for complex hierarchies treats the organization, not the individual project, as the unit the system is built around: one shared vendor and document record across every project, a portfolio-level dashboard that rolls project data up into a single view, and role-based access so what a person sees depends on who they are, not which project they happen to have open. A tool built to manage one project at a time, no matter how good it is at that one job, cannot represent an organizational hierarchy, because it was never built to hold more than one project’s worth of relationships and documents at once.
That is the real dividing line in contractor management software. Some tools are project tools: strong inside a single job, with no real model of the company running many jobs at once. Others are built with the hierarchy as a first-class concept: a project sits inside a company, a vendor sits across many projects, a person’s access sits at a level in between. The second category is what “handles complex hierarchies” means in practice, a structural choice made early in how the software models its data, not a feature added on top of a single-project tool later.
For a growing general contractor, this distinction stops being theoretical the moment the firm is running more than a few active projects with overlapping subcontractors. The rest of this guide covers what breaks first, what a real architecture needs to replace it, and how to tell when your firm has already crossed that line.
What breaks when a GC scales from a handful of active projects to dozens?
Three things break, usually in this order: the spreadsheet-per-project model stops rolling up into anything a leader can read at a glance, one person’s manual tracking hits a ceiling nobody saw coming, and the same subcontractor’s risk on one project goes invisible on every other project they’re also working. None of these breaks on a single dramatic day. They break quietly, and the firm usually finds out from a missed renewal or a coverage gap discovered after the fact, not from a warning.
The pattern is consistent across firms that scale this way. Compliance tracking that worked fine at a handful of projects was never really a system, it was a habit that worked because one person could hold the whole picture in their head and in one spreadsheet. Growth removes exactly the two things that habit depended on: enough time for one person to check everything personally, and a small enough number of moving parts to fit in a single tab. Neither comes back once the firm has grown past them. The next three sections take each break in turn.
Why doesn’t a spreadsheet-per-project model roll up into a portfolio view?
A spreadsheet built for one project has no relationship to the spreadsheet built for the next one, so there’s no view that shows both at once without someone manually combining them, and that combination is stale the moment it’s finished. Each project’s tracker is its own island: its own tabs, its own version of a subcontractor’s insurance status, its own definition of what “compliant” means on that job. Ask a leader which of our projects have a compliance risk right now and the honest answer, in a spreadsheet-per-project world, is “let me open a dozen files and get back to you.”
This is not a formatting problem a shared template fixes. Even identical spreadsheet templates across every project still store each project’s data separately, so rolling them up into one number still requires a person to open every file, read the current state, and reconcile it by hand, on a cadence that is only as current as the last time someone did that work. A portfolio view built this way is never live. It’s a snapshot, already aging the moment it’s assembled, and it depends entirely on someone remembering to assemble it in the first place.
Why does manual compliance tracking hit a hard ceiling as project count grows?
One person’s capacity to manually track compliance doesn’t scale linearly with project count, because each new project doesn’t add one more line item to check, it adds a whole new set of subcontractor relationships and documents layered on top of everything that admin is already carrying. There’s no fixed number where the ceiling arrives, only a point where it arrives sooner than the firm expects.
The work compounds in a way project count alone doesn’t capture. A firm running three projects with the same five subcontractors on each has a very different manual workload than a firm running three projects with forty different subcontractors spread across them. What actually determines the ceiling is the number of vendor relationships and documents one person has to keep current at once, not project count on its own. What’s consistent across firms, wherever the ceiling actually sits, is that it rarely announces itself. It shows up as a certificate that expired without anyone noticing, a subcontractor who was flagged on one job and quietly still active on another, or an admin who, honestly asked, admits they’re no longer confident in the number they’d give you if you asked who’s compliant right now.
Why does cross-project vendor risk become invisible at scale?
Cross-project vendor risk goes invisible because most compliance tracking is organized by project, not by vendor, so a subcontractor’s status only exists inside the project where someone happened to check it, and nothing connects that status to the same subcontractor’s other active jobs. A sub who is flagged, expired, or non-compliant on Project A can be sitting on Projects B, C, and D with nobody aware the same risk applies there too.
This is the sharpest version of the spreadsheet-per-project problem, because it doesn’t just cost time, it hides risk exactly where it matters most. Subcontractors don’t work one project at a time for a growing GC, they work several, and their compliance status doesn’t change by project, it changes by policy expiration, by license status, by their own operations. A tracking model organized around the project instead of the vendor is structurally unable to see that the same risk is showing up in five places at once, because it never asked the question of where else that subcontractor is active in the first place.
What does a real multi-project compliance architecture need?
A real multi-project compliance architecture needs three things a spreadsheet-per-project model cannot provide: a shared vendor and document record that exists once and is referenced across every project, a portfolio-level dashboard that rolls project-level status up into a single live view, and role-based access so a project manager sees their project while leadership sees the whole portfolio, all drawn from the same underlying data.
- A shared vendor and document record. Each subcontractor, and each document tied to them, exists once, not once per project. When that sub’s certificate lapses, every project they’re active on reflects it, instead of the status existing only in the one project where someone happened to check.
- A portfolio-level dashboard. Project-level status rolls up automatically into a single view leadership can read without opening each project’s tracker individually. The project-level view doesn’t disappear, it’s still there for the people running that job. The portfolio view sits above it.
- Role-based access. What a person sees depends on their role, not which login they happen to be using. A PM sees their project. A compliance admin sees what they’re responsible for reviewing. Leadership sees everything. All three views draw from the same record, so nobody is maintaining a separate tracker to get a role-appropriate picture.
| What the firm needs at scale | Spreadsheet-per-project | Portfolio compliance architecture |
|---|---|---|
| Rolls up into one company-wide view | No, someone has to assemble it by hand | Yes, live |
| Vendor status shared across every project | No, re-checked separately per project | Yes, one record |
| Cross-project vendor risk visible | No | Yes |
| Role-based views (PM vs. leadership) | Whatever the spreadsheet owner sets up manually, if anything | Built into the system |
| Scales past a handful of active projects | Breaks down | Designed for exactly this |
| Audit trail across the whole portfolio | Reconstructed by hand when asked | Maintained automatically |
The honest read of that table: a spreadsheet-per-project model can be made to look organized for a while. It cannot be made live, shared, or role-aware, because those aren’t formatting choices, they’re structural ones, and a spreadsheet’s structure is one file per project by default.
How does the ingest, validate, route, archive model change when it runs across a portfolio instead of one project?
It doesn’t change in its steps. Ingest, validate, route, and archive still describe what happens to every document. What changes is what the record connects to. Applied to a single project, that model tracks one project’s documents through their lifecycle. Applied to a portfolio, the same four steps run for a document tied to a subcontractor who is active on multiple projects, and the record they write to is the vendor’s shared record, not a project-only file, so the same ingest, the same validation, and the same archived history are visible from every project that subcontractor touches, instead of being repeated and re-checked separately in each one.
Concretely: when a subcontractor’s certificate of insurance is ingested on Project A, validated against the coverage requirement, and archived with its history, that’s the same record Project B and Project C reference too, because it’s the same subcontractor. Nothing about the model changes. What changes is the scope the record is built to represent: one project’s worth of documents, versus a company’s worth of vendor relationships across every project that company runs. That’s the difference between a document system and a compliance architecture. The second one is built to hold the whole hierarchy from the start, not stretched to cover it after the fact.
How do you know your firm has outgrown per-project compliance tracking?
You’ve outgrown it if leadership can’t answer which of your active projects carry compliance risk right now without someone spending real time assembling the answer, and if the same subcontractor’s status has to be re-checked separately on every project they’re active on. Run down this list honestly.
You likely have it if:
- Answering which projects have a compliance issue right now takes more than a few minutes and involves opening more than one file.
- The same subcontractor is tracked separately, and sometimes inconsistently, on every project they’re working.
- Leadership’s view of compliance is a rollup someone assembled by hand, not something they can see live.
- A PM can see their own project fine, but there’s no clean way for leadership to see everything without asking every PM individually.
- The person who just knows the current state across every project is a single admin, and the firm has quietly become dependent on that person not leaving or being out sick.
- Adding a new project means building a new tracker from scratch instead of the new project simply joining a system that already knows the company’s vendors.
If most of that is true, the firm has already scaled past what a spreadsheet-per-project model was ever built to do, whether or not anyone has said so out loud yet.
How does Contracts Connected support compliance across multiple projects?
Contracts Connected is built around the vendor and the document, not the individual project, so a subcontractor’s record, and everything tied to it, exists once and is visible on every project they’re active on, with a portfolio-level view for leadership and project-level access for the teams running each job. The same ingest, validate, route, and archive process that runs on a single certificate of insurance runs the same way across every project a firm is managing, because the underlying record is built to represent the company’s whole set of vendor relationships from the start, not stretched to cover more projects after the fact.
That matters most for a GC in the specific window this guide is about: past the size where one spreadsheet and one admin can hold the whole picture, but still running compliance the way a smaller firm does. The architecture doesn’t ask a growing GC to rebuild its process from scratch. It asks the system to finally do what the spreadsheet never could: show the same subcontractor’s risk the same way, everywhere that subcontractor is working, the moment it changes. Built by people who ran the document chain by hand across a real portfolio of federal projects before building the system meant to replace the spreadsheet.
Frequently asked questions
What contractor management software handles complex hierarchies?
The software built for complex hierarchies treats the organization, not the individual project, as the unit the system is built around: one shared vendor and document record across every project, a portfolio-level dashboard that rolls project data into a single view, and role-based access so what a person sees depends on their role, not which project they have open. A tool built to manage one project at a time cannot represent an organizational hierarchy, because it was never built to hold more than one project’s relationships at once.
How many projects can one person manually track compliance for?
There is no fixed number. It depends on subcontractor count and document volume per project, not project count alone. But every firm that tracks compliance manually hits a ceiling earlier than it expects, because each new project adds a full new set of vendor relationships and documents, not a single new line item. The ceiling rarely announces itself. It shows up as a missed renewal or a gap discovered after the fact, not as an obvious breaking point.
What is a shared vendor and document record across projects?
It is a single record for each subcontractor and each document tied to them, referenced across every project that vendor works on, instead of a separate entry re-created in every project’s own spreadsheet or folder. If a subcontractor’s certificate of insurance lapses on one project, the same record reflects that status on every other project they are active on, rather than the risk staying invisible until someone happens to check that one project’s file.
What is a portfolio-level compliance dashboard?
A portfolio-level dashboard rolls compliance status across every active project into one live view, so leadership can see which projects and vendors carry risk without opening each project’s individual tracker. It sits above the project-level view rather than replacing it. Project teams still see their own project in detail, but the roll-up answers the question a spreadsheet-per-project model cannot: how is the whole portfolio doing right now.
How does role-based access work in multi-project compliance software?
Role-based access means what a person sees depends on their role, not on a shared login everyone uses the same way. A project manager sees the compliance status for their project. A compliance admin sees what they are responsible for reviewing. Leadership sees the full portfolio. All three views draw from the same underlying record, so nobody has to maintain a separate tracker to get a role-appropriate picture.
Does the ingest, validate, route, archive model still work across a full portfolio?
Yes, and it has to work the same way at any scale for the model to hold. Each document is still ingested tied to its project and source, validated against what is required, routed to whoever acts next, and archived with its history. What changes at portfolio scale is that the same vendor’s ingest, validation, and archive events across different projects reference the same underlying record, instead of running as separate, disconnected processes in each project.
Related reading
- Construction compliance dashboard software
- Document chain of custody in construction, explained
- AI COI review for general contractors
- Redlines inside the contract
- Subcontractor risk tier scoring rubric
- Subcontractor annual prequalification renewal checklist
- Project document index template
See what compliance looks like across your whole portfolio, not just one project.
Contracts Connected keeps one vendor and document record across every project you run, with a portfolio-level view for leadership and role-based access for your teams. Built by people who ran the document chain by hand across a real portfolio of federal projects before building the system meant to replace the spreadsheet.