How to Build a Staff Qualifications Database That People Will Actually Update

The Ghost Town Problem

Most staff qualifications databases at AEC firms become ghost towns within a year because the update task is divorced from the work that generates the data. The software is fine. The trigger is wrong. People architecture is the operating model that fixes that — it ties every qualifications update to a moment that already happens (a project closeout, a CE renewal, a proposal submission) so the data refreshes itself.

A staff qualifications database is the central record of every employee's experience, certifications, project history, and role narratives— used to staff pursuits, file SF330s, and plan capacity. Most firms still chase that data through email and dig through SharePoint when a deadline lands⁴, which produces exactly the version drift coordinators inherit on Monday morning.

"Buying Flowcase or OpenAsset doesn't solve the staleness problem. It relocates it."

Buying a tool moves the failure from email threads into a dashboard nobody opens. This article is about the operating model underneath the tool— who updates what, when, and why they bother— and the trigger redesign that makes the database stay alive. That's the problem operations leadership at growing firms actually has to solve, and it's the part vendor "ultimate guides" tend to skip.

If everyone knows this happens, why does it keep happening?

Why Databases Die — Adoption, Not Software

Staff qualifications databases die because updating them is decoupled from any work that already produces fresh data. The PM has no immediate payoff for spending Friday afternoon describing a project they wrapped six months ago, and no penalty for skipping it. So they skip it. Every time.

Three reasons adoption stalls:

• No payoff. The PM updates the database; the proposal coordinator gets the benefit. The economics are wrong from the first click.
• No trigger. "Update your profile quarterly" is a calendar event, not a work event. Calendar events lose to client deadlines forever.
• No context. A blank text box asking "describe your role on the project" months after closeout is harder than writing the closeout report was in the first place.

Independent commentary in the HR-tech world has been saying this for years. Upland put it bluntly: a skills inventory's value depends entirely on adoption, and without active internal promotion it becomes an expensive ghost town⁷. Flowcase, writing for AEC, reaches the same conclusion— the bigger variable is internal adoption, not the software⁴.

"The standard skills inventory asks employees to describe their expertise in a form, at a point in time, removed from the context that makes the expertise legible." — Pravodha⁸

That last line is the deepest diagnosis. When you ask someone to describe their expertise outside the moment they exercised it, you're asking them to do retrieval and writing at the same time. Self-reports drift toward whatever the form makes easy, and SkillCycle⁹ notes the obvious follow-on: self-assessments inflate, especially when tied to performance review. Tying updates to performance review imports a politics problem into a data problem.

The diagnosis is structural. No tool fixes a structural problem. But before tools, what's the data model actually trying to capture? This is part of building a culture that absorbs new tooling— get the model right, then layer the software.

The Data Model — System of Record + Modular Blocks

In AEC firms, the working pattern is Deltek Vantagepoint (or Unanet) as the system of record for employee and project data, with OpenAsset or Flowcase generating the resumes and proposal collateral on top. The canonical record stays in one place; the assembled outputs are produced on demand.

That arrangement matters because it determines what's authoritative and what's derivative. OpenAsset² is explicit about treating Deltek as the single source of truth for employee data— OpenAsset syncs from it rather than duplicating it. Full Sail Partners³, a Deltek integrator, calls Vision a legacy ERP and Vantagepoint the current platform for larger and more complex AE firms. If you're standing up something new, build on Vantagepoint.

Treat resumes as compositions, not documents. A single canonical employee record plus modular blocks gets assembled per pursuit— that's what lets one project narrative serve a federal SF330, a private RFP, and a capabilities deck without three different copy-paste cycles. Knowledge Architecture⁵ takes this further by composing Deltek, Unanet, and OpenAsset into one intranet surface staff actually visit.

The downstream consumer that disciplines all of this is SF330 Section E (Resumes of Key Personnel)⁶. If your data model can produce a clean Section E entry on demand, the rest of your pursuit collateral is mostly assembly. At minimum, every employee record needs:

• Name, role, professional registrations
• Education
• Years with current firm and total experience
• Relevant projects with date, role, scope, and outcome metric

That list is short on purpose. Discipline at the SoR layer means more flexibility above it.

The model only matters if it gets fed. The next question is when.

Design the Trigger, Not the Database

The right design question is not "what tool" but "what trigger"— what already-happening event in the firm produces fresh, structured people-data as a byproduct? Calendar-driven updates fail. Event-driven updates work because the work itself is the prompt.

This is the article's central reframe, and it's the place where most firms get stuck. People architecture lives or dies here.

The trigger menu:

1. Project closeout — primary. The data is freshest, the staff member is most motivated to claim credit, and the firm is already producing a closeout artifact that contains most of what a profile update needs.
2. Certification earned — PE, AIA, LEED, project-specific. HR already processes the paperwork; the trigger is free.
3. Role or title change — promotion, practice move, change of registration jurisdiction.
4. RFP staffing event — the moment a proposal coordinator pulls a profile and finds it stale is the moment to fix it.

"Calendar-triggered updates die. Event-triggered updates compound."

Practitioner observation, not a sourced study. From what we see across $20M–$100M AEC engagements, project closeout outperforms annual review as an update trigger because the data is freshest at closeout and the staff member is most motivated to claim credit. Frame and adopt accordingly.

The honest counter-argument: "but our closeouts already get skipped." Fair. If closeout discipline is broken, the database fix is downstream of fixing it— don't bolt a new task onto a dead ritual. For firms without a closeout culture yet, the pursuit-driven trigger (RFP staffing) is the workable backstop. Use the moment of pain to repair the data, then graduate to closeout once the practice exists.

The deeper incentive principle: 90 seconds of approval beats 30 minutes of authoring. The whole design goal is to make the staff member's part of the workflow shorter than reading their email. SkillCycle⁹ confirms what every operations lead has lived— participation moves with incentives and friction, and friction is the bigger lever.

Triggers solve when. AI solves who-writes-it.

Where AI Actually Helps — As a Drafter, Not an Interrogator

AI's most useful job in a people architecture is drafting proposed profile updates from internal documents the firm already produces— closeout reports, weekly status notes, project debriefs— so the staff member approves a draft instead of authoring from a blank page. Human judgment stays in the loop; the writing burden disappears.

This is where AI augments versus replaces existing workflows, and the distinction matters. AI is the drafter. The human approves. That's it.

"Your project closeout already contains 80% of a resume update. The job is to extract it, not to ask for it again."

A worked example, end-to-end:

1. Trigger fires. PM marks the project closed in Vantagepoint.
2. Retrieval. An LLM with retrieval-augmented access reads the closeout report, the proposal narrative the project was won on, and the last three weekly status notes.
3. Draft. The model proposes a profile update: project name, the staff member's role, scope, outcome metric, dates, two-sentence narrative in the firm's voice.
4. Approval. The staff member sees a diff next to their existing profile. One click to approve, edit, or reject.

The hard guardrails are non-negotiable:

• Never auto-publish. Refusal is a feature.
• The staff member always has final say— the AI is drafting their words.
• Every change is logged. The audit trail is the trust mechanism.
• The model never invents an outcome metric. If it isn't in the source document, it isn't in the draft.

What this doesn't replace is the judgment about what to claim, what to credit, and how to frame contribution. Two engineers on the same project will describe their roles differently, and they should— that's not a data problem, it's a human one. AI handles the writing. Humans handle the meaning.

This is emerging practice in AEC, not a documented case study yet. We're seeing firms pilot it; we are not yet seeing it published. Frame it accordingly when you bring it to your principals.

Knowing the pattern is one thing. The harder question is sequencing— what do you do in the first 90 days?

A 90-Day Rollout for a 100–500 Person Firm

Ninety days is enough to stand up a working people architecture in a 100–500 person AEC firm. Use the first 30 days to lock the system of record and resume layer, the next 30 to define triggers and the minimal data model, and the last 30 to pilot AI-drafted updates inside one studio or practice.

"Pilot before you proselytize. One studio with a working flow beats a firmwide rollout that nobody trusts."

Vendor-reported timelines align with this shape. Flowcase⁴ notes that smaller firms can be operational in a few weeks while larger organizations with extensive legacy data may need two to three months— treat that as a planning floor, not a ceiling. And confirm the sequencing against your firm's reality before you commit a budget; what works at 120 people doesn't always survive at 480.

What you measure on day 91 tells you whether it actually worked.

Metrics That Tell You It's Working

Three metrics tell you whether the people architecture is alive: median age of resume data on the day a pursuit is staffed, coordinator hours per SF330, and the percentage of staff with a profile touched in the last 90 days. Track all three; the first one is the truth-teller.

These are also the right metrics for measuring AI program success inside an AEC firm, because they tie directly to revenue motion (pursuits won) rather than vanity engagement. Logins per month tells you nothing. Median data age on staffing day tells you everything.

These metrics outlive any tool decision. Which is the deeper point.

Your People Data Is the Substrate for Everything Else AI Will Do

Whatever else your firm does with AI in the next two years— pursuit qualification, capacity planning, knowledge management, automated proposal drafting— runs on the same substrate: structured data about your people and your projects. People architecture is the foundation that decides whether the rest of it works.

The pattern across firms that succeed with AI is unglamorous and consistent. Get the operational data structured first. Put models on top of it second. Firms that skip the first step end up paying for clever pilots that can't reach production because the data underneath is a swamp.

"No matter the question AI is going to answer at your firm, your people data is the answer underneath the answer."

People are the answer. Your people-data is the substrate beneath every AI answer your firm will produce. Get that right, and the rest of the program has somewhere to stand.

If the trigger-redesign question feels like the right one for your firm, this is the kind of decision a fractional AI officer is built to compress. Dan Cumberland Labs helps AEC firms map exactly these decisions— including which AI patterns to deploy first against your existing operational data.

Frequently Asked Questions

What is people architecture in an AEC firm?

People architecture is the data model and update system for employee qualifications— resumes, certifications, project history, role narratives— that feeds proposals, SF330s, and staffing decisions. It treats staff qualifications data as a firm operating system, not a marketing-ops file cabinet. The architecture is what survives a tool change; the tool is what executes the architecture this quarter.

Why do staff qualifications databases go stale?

Because updating is decoupled from the work that generates the data. Without a natural trigger and an immediate payoff for the person updating, the task drops to the bottom of every PM's queue and stays there. Independent commentary in the HR-tech space⁷⁸ consistently identifies adoption— not software— as the binding constraint.

Should we use Deltek, OpenAsset, or Flowcase?

Use Deltek Vantagepoint (or Unanet) as the system of record for canonical employee and project data, then layer OpenAsset² or Flowcase for resume generation and proposal collateral. Knowledge Architecture's Synthesis⁵ can compose those into a single intranet surface if your firm wants one front door. The decision is layered, not exclusive.

What's the best update cadence?

Event-triggered, not calendar-triggered. The strongest events are project closeout, certification earned, role change, and RFP staffing— moments where fresh data is already being produced as a byproduct of the work. Annual or quarterly reminders compete with client deadlines and lose every time.

How long does a rollout take?

Vendor-reported timelines⁴ run a few weeks for smaller firms and two to three months for larger firms with legacy data. A pragmatic 90-day plan covers system-of-record confirmation, data model and trigger design, and a single-studio AI-drafter pilot before any firmwide rollout.

References

1. OpenAsset, "Generate Employee Resumes in Minutes" (2024) — https://openasset.com/blog/generate-employee-resumes-at-the-click-of-a-button/
2. OpenAsset, "Deltek Vision Integration for OpenAsset DAM" (2024) — https://openasset.com/integrations/deltek-vision/
3. Full Sail Partners, "Resume and Project Information Management Using Deltek Vantagepoint" (2024) — https://www.fullsailpartners.com/fspblog/resume-and-project-information-management-using-deltek-vantagepoint
4. Flowcase, "Internal Database for AEC Firms: Complete Guide for 2026" (2026) — https://www.flowcase.com/blog/internal-database-for-aec-firms
5. Knowledge Architecture, "Integrations" (2024) — https://www.knowledge-architecture.com/integrations
6. OpenAsset, "What is the Standard Form 330?" (2024) — https://openasset.com/resources/standard-form-330/
7. Upland Software, "How to Create a Skills Catalogue (And Why You Need One)" (2024) — https://uplandsoftware.com/psa/resources/blog/how-to-create-a-skills-catalogue-and-why-you-need-one/
8. Pravodha, "Your Employee Skills Inventory Is Built on the Wrong Data" (2025) — https://pravodha.com/blogs/your-employee-skills-inventory-is-built-on-the-wrong-data
9. SkillCycle, "Skills Inventory: What It Is, Why It Matters and Examples" (2024) — https://www.skillcycle.com/blog/what-is-a-skills-inventory/