Build A Project Metadata Schema In Five Fields

Why This Is A Leadership Problem, Not An Ops Problem

Project metadata at the firm-portfolio level decides whether your firm can answer strategic questions about itself. That makes it a principal's job, not a junior coordinator's.

A schema is a thinking artifact. The questions you can ask of your firm are limited by the fields you've agreed to fill in. ProjectReady frames portfolio metadata as the layer that gives leadership "a day-to-day view of everything happening across projects"¹— and that visibility is what unlocks strategic decisions, not just file retrieval.

A clean schema lets you answer questions principals already ask:

• What's our market mix by client sector over the last three years?
• Which delivery methods do we have real, RFP-defensible experience in?
• What's our pursuit-to-win ratio in healthcare versus higher ed?
• Where are we capacity-constrained next quarter?

Delegate the schema downward without leadership commitment and it dies in a month. The principal owns it because the principal is the one who needs the answers. That's also why an honest AI strategy for professional services starts here— with the data substrate, not the tools.

Here's the schema.

The Five Fields At A Glance

A minimum viable project metadata schema for a $20M–$100M architecture firm is five fields: Project Type, Client Sector, Delivery Method, Project Status, and Location. Apply them to every project, past and present, and 80% of your reporting and RFP-search problems disappear.

We recommend five. Not three— three is too coarse to support BD targeting. Not twenty— twenty is what gets filled in for the first six projects and then quietly abandoned. Five fields, applied consistently, beat twenty fields filled in haphazardly.

This is opinionated, not "industry standard." But the four ProjectReady names as essential— name, discipline, status, location¹— and the type/client/location/status axes Deltek's Vision template uses out of the box² both sit inside this five. Now each field, with starter values.

Field 1 — Project Type

Project Type captures the building typology— what you designed. It's the field that answers "how many of these have we done?", the question every RFP shortlist turns on.

What it answers: Portfolio searchability for RFPs. Project Type is what makes your portfolio searchable to the people writing tomorrow's proposal. RFP-response platforms in the AEC space are built around exactly this kind of search— Flowcase notes that effective project search needs to work "by skill, project feature, location, or custom metadata"³. Project Type is the metadata that holds that search up.

Starter picklist:

• K-12
• Higher Ed
• Healthcare
• Medical Office Building (MOB)
• Multifamily
• Mixed-Use
• Civic / Government
• Workplace / Corporate Interiors
• Industrial
• Hospitality
• Religious
• Single-Family Custom

The most common mistake is nesting too deep on day one. Don't try to capture "K-12 / Elementary / Charter / Renovation" in a single field. Keep Project Type flat. Add a Sub-Type field later if your portfolio actually demands it.

What you built matters. Who paid for it matters too.

Field 2 — Client Sector

Client Sector captures who paid for the project, sorted into the categories your BD pipeline already tracks. It's the field that lets you answer "should we even pursue this?"

What it answers: BD targeting and pursuit-to-win analysis by sector. Client sector is the cleanest signal of where your firm actually wins work. Two firms with identical Project Type histories can have completely different sector exposure— and that's where the strategic decisions live.

Starter picklist:

• Public — Federal
• Public — State / Municipal
• Public — K-12 District
• Public — Higher Ed
• Institutional (healthcare system, religious, nonprofit)
• Private Developer
• Private Owner-Occupier
• Corporate
• Individual

The mistake we see most: collapsing Public and Institutional into one bucket. Don't. The procurement processes are different, the sales cycles are different, and the win patterns are different. Mash them together and you've hidden the most actionable signal in your BD data.

What you built and who paid only tell half the story. How the contract was structured tells the rest.

Field 3 — Delivery Method

Delivery Method captures the contractual structure of the project— Design-Bid-Build, Design-Build, CMAR, CM Multi-Prime, Integrated Project Delivery, or Public-Private Partnership. It tells you which project-delivery muscles your firm has actually built.

What it answers: Strategic capability tracking. When an RFP requires three references on CMAR projects, this field is the difference between a one-day shortlist response and a two-week scramble. Delivery method isn't trivia. It's the clearest record of which contracting muscles your firm has flexed.

The taxonomy isn't ours to invent— it's already canonical. The AIA-AGC Primer on Project Delivery⁴ lays it out, and the CMAA owner's guide⁵ independently corroborates it.

Starter picklist (canonical):

• Design-Bid-Build (DBB)
• Design-Build (DB)
• Construction Manager at Risk (CMAR)
• CM Multi-Prime
• Integrated Project Delivery (IPD)
• Public-Private Partnership (PPP / P3)

"But we only do DBB." Fine. The schema still earns its keep, because the moment a CMAR opportunity walks in, you know exactly how much real experience you can put on a qualifications page. Pursuing a new method is a strategic decision. The schema makes that decision visible instead of accidental.

What, who, and how. That leaves where the project lives now and where it sits geographically.

Field 4 — Project Status

Project Status captures where each project sits in the firm's lifecycle right now— pursuit, active, on hold, complete, or archived. It's the field that drives weekly resourcing decisions.

What it answers: Capacity, pipeline reporting, resourcing. Status is the field that makes capacity planning possible without a separate spreadsheet. ProjectReady names status as one of the four essential metadata fields¹ for exactly this reason: without it, the rest of the data is a museum exhibit.

Starter picklist:

• Pursuit
• Active
• On Hold
• Complete
• Archived

Common mistake: confusing Status with Phase. Status is operational state— is this project alive, paused, or done? Phase (SD / DD / CD / CA) is the design lifecycle of an Active project. Keep them in separate fields. Phase belongs only to projects whose Status is Active.

Last field. Where on the map.

Field 5 — Location

Location captures city, state, and region for every project. The reason it's a field rather than a free-text address: regional rollups are how principals see their actual market footprint.

What it answers: Market reporting, RFP geographic filtering, regional capability claims. Address is data. Location is intelligence. The same logic shows up in RFP-response tooling— Flowcase explicitly highlights location as a primary search axis for past-project retrieval³, and ProjectReady names location as one of the four essentials¹.

Starter picklist for Region:

• Northeast
• Mid-Atlantic
• Southeast
• Midwest
• Mountain West
• Pacific Northwest
• Southwest
• West Coast
• International

Adjust the regions to your firm's reality. The mistake to avoid is relying on free-text street addresses for everything— they break sort, they break filter, and they make "show me all our Southeast healthcare work" a manual job again.

Five fields. Now: what they're not.

What ISO 19650 Is (And Why It Doesn't Replace This)

ISO 19650 is the international standard for information management on built-environment projects, and it specifies metadata for each information container in a Common Data Environment: State, Status code (suitability), Revision, and Classification⁶. It governs documents inside a project, not projects inside a firm.

The standard is structured in six parts— concepts, delivery, operational phase, information exchange, security, and health & safety⁷— and is genuinely useful at the project-delivery level. But it's not a portfolio schema and was never meant to be.

ISO 19650 manages information containers within a project. The five-field schema manages projects within a firm. Both are true. All of it matters.

If your firm runs ISO 19650 on its CDE, keep doing that. If you don't, that's a separate decision with separate ROI. Either way, the AEC project metadata that lets you answer "how many K-12 design-build projects have we completed in the Southeast?" lives one level up from anything ISO 19650 covers. They don't conflict. They don't substitute. Run both.

If standards aren't blocking you, software isn't either.

Where The Schema Lives (And The 30-Day Rollout)

The schema lives wherever your project list already lives— Deltek, Monograph, Newforma, OpenAsset, or even a maintained Airtable. You don't need new software. You need one named owner and 30 days.

Project Information Management (PIM) platforms like Deltek's are "designed specifically for architecture and engineering firms"⁸ and hold these fields by default. So does Monograph. So does a disciplined Airtable. External RFP tooling like Flowcase reads the same fields you'd build in any of them³. The schema is platform-agnostic. The best schema is the smallest one your team will fill in every time.

The 30-day rollout:

1. Days 1–3 — Owner and picklists. Name one human owner (BD/marketing director or ops lead). Approve the picklists for all five fields in writing. No committee. No platform RFP.
2. Days 4–10 — Retrofit recent work. Backfill the last 24 months of projects against the five fields. This is the slice that drives 90% of active RFP responses.
3. Days 11–20 — Backfill older work as time allows. Move into months 24–60. Accept incompleteness. Anything beyond this window is a bonus, not a blocker.
4. Days 21–30 — Lock and integrate. Lock the picklists. Bake the five fields into your project intake checklist so every new pursuit and active project gets tagged from day one.

The "good enough" threshold:

• 100% completion on projects ≤24 months old
• 70% completion on projects 24–60 months old
• Anything older is a bonus

The most common rollout failure is trying to retrofit ten years of work before going live. Don't. Recent projects do most of the BD work; old projects can be cleaned up incrementally once the discipline is in place.

Once the schema is clean, what it actually unlocks is bigger than RFPs.

What This Unlocks Next — AI On Your Own Project History

A clean five-field schema is the prerequisite for using AI on your own project history— drafting RFP responses, summarizing capability sets, forecasting capacity. AI can only augment what's already structured for humans.

With clean metadata in place, AI starts earning its keep:

• Draft initial RFP project narratives from past records filtered by Type + Sector + Delivery Method
• Produce sector-specific capability summaries on demand
• Flag capacity conflicts before they become resourcing fires
• Surface pursuit patterns— where you actually win versus where you keep showing up

AI doesn't fix unstructured project records. It amplifies whatever discipline you already have. Done right, it's intellectual augmentation— the principal stays decisive and central, and the firm's accumulated experience finally becomes searchable to the people who need it on a Tuesday at 9pm.

If mapping the right AI workflow to your specific project records feels like a project of its own, that's exactly the kind of problem AI implementation services for founder-led firms at Dan Cumberland Labs are built to solve. No more 9pm Slack pings. Just answers, on the first ask.

FAQ

What is project metadata for an architecture firm?

Project metadata is the structured set of fields— like Project Type, Client Sector, Delivery Method, Status, and Location— that describes each project so the firm can search, report, and reuse the information across BD, RFPs, and internal reporting. It's not file storage. It's the index layer that makes the firm's accumulated work findable along multiple axes without duplicating files.

What are the most essential project fields for an AEC firm?

Project Type, Client Sector, Delivery Method, Project Status, and Location cover roughly 80% of internal reporting and external RFP needs at a $20M–$100M architecture firm. They're the smallest set that answers the strategic questions principals actually ask: capability mix, market mix, capacity, and pursuit-to-win. Adding more fields rarely adds clarity; it usually adds abandonment.

Do architecture firms have to follow ISO 19650?

ISO 19650 governs information-container metadata in a Common Data Environment during project delivery— it's about documents inside a project, not projects inside a firm⁶. It's not a prescription for firm-level portfolio metadata, and a portfolio schema can run alongside it without conflict. Whether to adopt ISO 19650 is a separate decision with its own ROI.

What's the difference between a metadata schema and a folder structure?

A folder structure stores files in one hierarchy and forces every retrieval question through that single path. A metadata schema lets the same project be found along multiple axes— by type, client, delivery method, status, location— without duplicating files or rebuilding folders. In practical terms, a folder structure answers "where is this file?"; a schema answers "which projects match this set of conditions?"

References

1. ProjectReady, "The Power and Importance of Metadata on an AEC Project" (2023) — https://project-ready.com/the-power-and-importance-of-metadata-on-an-aec-project/
2. Deltek, "Vision 7.3 — Project Fields Based on a Project Template" (2020) — https://help.deltek.com/product/Vision/7.3/pro_Project_Fields_Based_on_a_Project_Template.html
3. Flowcase, "Essential Features When Evaluating RFP Technology" (2024) — https://www.flowcase.com/blog/12-features-to-look-out-for-when-evaluating-rfp-technology
4. AIA & AGC Joint Committee, "Primer on Project Delivery, 2nd Edition" (2011) — https://www.agc.org/sites/default/files/Files/Programs%20%26%20Industry%20Relations/AIA-AGC_Primer_on_Project_Delivery_2nd_Edition-FINAL.pdf
5. Construction Management Association of America, "An Owner's Guide to Project Delivery Methods" (2012) — https://www.cmaanet.org/sites/default/files/inline-files/owners-guide-to-project-delivery-methods.pdf
6. Autodesk, "ISO 19650, the Common Data Environment, and Autodesk Construction Cloud (eBook)" (2022) — https://damassets.autodesk.net/content/dam/autodesk/www/pdfs/common-data-environment-iso-19650-ebook-en.pdf
7. 12d Synergy, "The Ultimate ISO 19650 Guide for AEC Professionals" (2024) — https://www.12dsynergy.com/iso-19650-guide/
8. Deltek, "Project Information Management Software for AE Firms" (2024) — https://www.deltek.com/en/architecture-and-engineering/project-information-management