In architecture, a project rarely keeps its first name. It often starts as a plot number, a street name, or an internal site reference. Something practical, not permanent. As the project evolves, branding changes, public identities emerge, and the original working title is replaced.
For firms with large teams and thousands of historical projects, this is not a one-off correction. It becomes a constant background task that quietly consumes time every week from people whose actual job is something else entirely.
The fix is not more discipline or tighter spreadsheets. It is a master record where you update once and the change propagates everywhere the project is linked.
What’s in this article
- Why project renames create operational CV risk
- Why manual CV management fails at enterprise scale
- What a master record actually looks like
- Filtering projects for an RFP is not AI, it’s metadata
- The design-firm wrinkle: InDesign and visual delivery
- A practical checklist before you change your CV workflow
- Frequently asked questions
- Final Thought
Why project renames create operational CV risk
A new opportunity often begins with very little structure: a parcel of land, an internal reference, or a temporary project label. Teams move forward anyway with planning and concept work using whatever identifier is available.
Later, the project evolves. A formal identity is introduced, branding is defined, and the working name is replaced.
That’s when the real administrative burden starts.
Someone has to track down every CV, project sheet, and internal profile that still uses the old name. Every reference needs to be updated. Every record has to be checked to avoid duplicate entries under both identities. And every team, from HR to business development to marketing, needs to stay aligned. Multiply this across years of project evolution and hundreds of name changes, and the issue becomes structural rather than occasional.
“Then I have to go back and check every single person who’s that was on to make sure that the name is changed correctly and we’re not duplicating the same thing. It’s just a lot of data and a lot of manual labor.”
And this is just one person, on one project.
The same pattern repeats across scope changes, role updates, client rebrands, and project handovers. The CV is not static, it is constantly being rewritten in fragments across the organisation.
Why manual CV management fails at enterprise scale
CV maintenance is rarely anyone’s full-time responsibility. It is usually a small fraction of someone’s job: a coordinator or marketing lead updating a master spreadsheet and manually copying changes into individual CVs.
On the surface, the process appears functional. But over time, a gap emerges between the central truth of project data and the CVs that actually go into proposals.
Senior consultants may carry 100+ projects. Leadership teams may represent thousands. The maintenance burden exceeds what any individual can realistically control.
Why don’t firms just hire more CV editors?
Because the problem is not a labour shortage. It is a data structure problem dressed up as a labour problem.
Adding a second or third person to the CV team gives you faster manual updates, but it also multiplies the risk of inconsistency. Multiple editors working across disconnected files create multiple versions of the same information. The structural fix is to remove the manual step entirely, not to staff up around it.
What a master record actually looks like
The idea is simple: each project exists once, is linked to the people involved, and is maintained from a single source of truth. When project information changes, every connected CV reflects it automatically.
In a well-structured CV management system, each project exists as a master record containing its core data: client, location, scope, timeline, certifications, and supporting documents. Consultants are linked to that record with role-specific data, while the shared project information remains centralised.
What “assigning a project to multiple people in one go” actually means?
It means creating the project once and attaching it to multiple consultants in a single action, instead of duplicating descriptions across Word files.
If the project later gains certifications, testimonials, or case studies, those attach to the same master record. Every linked CV updates automatically without reopening individual files.
The same structure extends to certifications, registrations, academic degrees, and publications: all of which are typically scattered across folders, spreadsheets, and inboxes.
Centralising them removes the constant cycle of “do we have the PDF?” requests.
Filtering projects for an RFP is not AI, it’s metadata
RFP requests often sound like AI problems on the surface: “We need hospitality projects in Mexico. Pull the 10 most relevant projects from this consultant’s CV.”
If every project has structured attributes, industry, geography, scope, then “hospitality projects in Mexico” is not a generative task. It is a query. The reason firms default to AI language here is because their data is not structured. Projects exist as narrative blurbs in Word files, without consistent tagging behind them.
“So like our team has to sort through every single blurb that he has to pick the best one. So I guess in a perfect world for us it would be like okay the master sits in a cloud and AI depending on what the RFP says helps us pull.”
Once structured, the workflow becomes trivial: select consultant, apply filters, export results. What used to take hours becomes minutes. This is the same logic that drives the time savings described in our breakdown of how consulting companies can reduce time-to-submission by 10x.
| Task | Manual workflow today | Master record workflow |
|---|---|---|
| Project rename across linked CVs | Open each file, find and replace, check duplicates | Update the master project once, every linked CV inherits |
| Adding a new project to 10 people | Write in 10 Word files | Create one master project, link 10 consultants in one action |
| Selecting projects for an RFP | Read 124 blurbs manually | Filter by industry and country, export the matching subset |
| Storing certificates and registrations | Scattered PDFs and Excel tracking | Linked to master project or consultant record |
| Maintaining consultant CVs | One person at less than 1% of their job function | Distributed, with consultants reviewing their own profile |
The design-firm wrinkle: InDesign and visual delivery
For architecture and design firms, there is a specific complication that most CV tools ignore. RFP responses are not simple documents. They are InDesign packages with custom layouts, embedded visuals, and a level of design control that reflects a design-led practice.
A consultant CV is rarely sent on its own. It is one section inside a 100-page proposal that includes scope, fees, project experience, and visual case studies. The team needs the resume content to flow naturally into the broader InDesign document, not to arrive as a standalone PDF that has to be screenshotted and pasted in.
Can a CV system export directly to InDesign?
It can export a file that will be 100% compatible with InDesign, since Indesign can convert docx easily. A structured Word export that maps cleanly into a predefined InDesign template solves the problem in practice. The key is not the final file type, it is consistency of structure upstream.
The realistic workflow for most design firms is to define the InDesign template once, then generate structured Word outputs that flow into it without reformatting. Any adjustments happen at the template level, not at the level of individual CV edits. For more on how template behaviour drives this, our CV templates page walks through how custom layouts get built from a blank Word document in around two hours.
This is the kind of red line that distinguishes a design-led practice from a typical consulting firm. It is not a nice-to-have. It is the difference between a workflow the team will adopt and one they will quietly route around. If a system cannot deliver into the format the proposal team actually uses, the rest of the value is theoretical.
A practical checklist before changing your CV workflow
- Identify who maintains CVs and how much of their role it represents
- Review how many project name changes occurred in the last two years
- Measure how long recent RFP selections actually took
- Define required structured fields (industry, geography, scope, dates, role, team size)
- Map where certifications and credentials currently live
- Plan structured migration instead of manual rebuilding
For consulting and architecture firms going through this question for the first time, the checklist in this CEO-level checklist on whether you need an enterprise CV manager is a good companion read. It pressure-tests the operational case before any vendor conversation.
Frequently Asked Questions
No. Most CV and RFP workflows fail because the underlying data is unstructured. The core issue is metadata and system design, not AI capability.
Not necessarily. In most firms, CV maintenance is a small fraction of someone’s role. The problem is that manual ownership does not scale and introduces inconsistency.
Yes, but only if projects are stored as a master record and linked to consultants. Without that structure, updates must be done manually across individual files.
Adding more people increases speed but also increases inconsistency. Multiple editors working across disconnected files create conflicting versions of the same information.
No. In design-led practices, output formats like InDesign remain essential. The key is structuring data upstream so it can feed existing templates cleanly.
The biggest cost is not time spent updating files, but the accumulation of inconsistencies: outdated project names, duplicate entries, and missing or misaligned credentials across documents.
Final Thought
If project name changes still require manual updates across individual files, skilled people are being used to maintain data that should maintain itself.
The cost is not only time, it is inconsistency: duplicate records, missing credentials, outdated project histories, and proposals that quietly drift away from the firm’s actual experience.
The real shift is structural: from disconnected documents to a single source of truth that feeds everything else.
If this reflects what your team is dealing with today, it can be useful to map it against your current workflow. Book short session with Sprint CV to review how your CV and project data is currently structured and where the manual work is actually coming from.
