98% of megaprojects experienced major cost overruns or schedule delays, with average cost growth of approximately 80% of original project value and average schedule slippage of 20 months, according to McKinsey's analysis of capital projects. For architects and engineers, the practical lesson isn't to build a bigger task list. It's to connect every design commitment to an accountable person, an approval and a delivery date.
Table of Contents
- Why Design Projects Slip and What Project Management Must Control
- The Design Phases and the Control Each One Needs
- Setting Information Rules Before Anyone Draws
- Meeting Cadence and Ownership for a 10-50 Person Firm
- How to Run a Closed-Loop Request Log
- Metrics That Show Whether a Project Is Under Control
- Confirm Your Controls Before Adding Automation
Why Design Projects Slip and What Project Management Must Control
A drawing set is a set of promises. The architect promises space and access, the structural engineer promises support, and the mechanical engineer promises systems that fit and perform. Project management is the operating model that makes sure named people resolve those promises before someone orders material or starts installation.
Project management for design professionals starts before production. During concept design, the team establishes assumptions about area, systems, budget and procurement. If those assumptions remain untested, the documentation team inherits decisions it can't safely make on its own.
A principal might approve a ceiling concept while equipment selection remains open. The drawings then advance around an assumed clearance, and the eventual equipment selection forces changes to structure, lighting and access panels. The missed control wasn't a reminder to finish the ceiling plan. It was an unresolved decision without an owner or deadline.
The controls behind the drawings
Organize the project manager's responsibility around these jobs:
- Scope definition. Record deliverables, exclusions, owner inputs and the process for authorizing additional services.
- Schedule control. Connect design releases to review periods, procurement dependencies and construction needs.
- Information flow. Make sure the receiving team knows which drawings, models and instructions are approved for its use.
- Risk and communication management. Assign unresolved assumptions, record decisions and escalate threats before they affect a committed release.
The practical priority is basic management capability, not reporting sophistication. A polished dashboard won't compensate for an undefined package scope or an owner decision that nobody has requested.
Practical rule: A deliverable isn't planned until someone owns it, someone can approve it and the receiving team knows when it will arrive.
Planning needs to connect the working documents to the people making those decisions.
The Design Phases and the Control Each One Needs
| Phase | Control to Run | Key Deliverable | Gate Before Moving On |
|---|---|---|---|
| Programming and feasibility | Scope, budget and owner decisions | Program brief and budget baseline | Owner signs program and budget |
| Schematic design | Concept options and early cost check | Schematic set and area schedule | Owner approves concept and areas |
| Design development | Coordination of structure, MEP and envelope | Coordinated models and outline specifications | Clash list reviewed and high-risk interfaces closed |
| Construction documents | Sheet index, model scope and issue control | Permit or bid set with revision log | Checks passed, revision status recorded, issue approved |
| Bidding and procurement | Addenda, bid questions and package scope | Addenda log and bid analysis | Scope frozen for each package |
| Construction administration | RFIs, submittals and change orders | Submittal log, RFI log and change register | Each change priced and approved before affected work proceeds, subject to contractual direction |
Design delivery works like a relay race. A phase ends successfully only when the receiving team can understand and use what it receives. Finishing drawings by a calendar date doesn't establish that readiness.
The phase sequence makes those handoffs visible.
Lock the schematic baseline
At schematic design, reconcile the program, area schedule and budget baseline. The owner should approve the selected concept with enough specificity that the team can distinguish design development from a change in requirements.
Suppose the owner approves a layout but hasn't settled the clinical equipment list. Record that exception, identify the affected rooms and assign a decision deadline. Don't describe the whole phase as complete while allowing that uncertainty to disappear into meeting minutes.
Scope creep often enters between design development and construction documents because unresolved owner choices look like ordinary drafting work. A revised room layout may in fact require additional engineering, a new cost check and a revised submission sequence.
Freeze the construction-document release
At the construction-document gate, establish the sheet index, model scope and coordination status. Record accepted exceptions explicitly, including who authorized them and which downstream activity they restrict.
A late change now affects drawings, model geometry, specifications, estimates and schedule dependencies together. The team must assess that combined effect before accepting the change, not after the drafting hours have been spent.
For complicated release sequences, construction scheduling support can help translate package dates into dependencies and review allowances. The project manager still owns the release decision.
No phase closes until its gate decision is written, dated and signed by the owner or authorized principal. Conditional approval is acceptable when the conditions are explicit. Silent assumptions aren't.
Setting Information Rules Before Anyone Draws
NIST estimated that inadequate interoperability imposed approximately $15.8 billion in annual costs on the US capital-facilities industry, including about $1.2 billion borne by architects and engineers, in its assessment of interoperability costs. Treat information exchange as a project control, not a software preference.
The failure chain is straightforward. Someone manually translates incompatible information, misses an attribute or shifts geometry, and another discipline proceeds using the altered information. The discrepancy then reaches procurement or installation before the team recognizes it.
Define the exchange protocol
Approve a short project information standard before production begins:
- Platforms. Identify the authoring tools, coordination environment and approved location for issued files.
- Exchange formats. Specify native and exchange formats, export settings and the receiving party's acceptance checks.
- Naming conventions. Include discipline, package, document identity and revision without relying on personal abbreviations.
- Coordinates. Establish the shared coordinate system, origin point and procedure for validating alignment.
- Element ownership. Assign responsibility for geometry and attributes, particularly at discipline boundaries.
- Revision status. Distinguish working, shared for coordination, approved and superseded information.
- Issue approval. Name the person who checks the package and the person authorized to release it.
Don't demand identical authoring software when a tested exchange meets the project's needs. Standardizing everything can impose unnecessary conversion work on a specialist consultant. Standardize the handoff and acceptance criteria first.
Shared digital information needs an agreed interpretation, not merely a shared folder.
Check what the receiver actually gets
Before issuing a package, validate coordinates in the receiving environment. Review unresolved clashes, sheet-to-model consistency and completeness of required parameters. Open the exported file rather than assuming a successful export message proves that the information transferred correctly.
Separate accepted exceptions from unresolved defects. An intentional clearance overlap with documented access provisions isn't the same as an unreviewed duct penetrating a beam. The coordinator records the distinction; the responsible designer approves the technical resolution.
Say a mechanical model exports with a different origin point. Its ductwork appears displaced against the structural frame, but the receiving team assumes the discrepancy is only a display problem. Without an exchange acceptance check, the team could carry that mismatch into installation instructions.
The useful control is simple: the receiving coordinator confirms alignment against agreed reference points before accepting the model for coordination.
Meeting Cadence and Ownership for a 10-50 Person Firm
| Cadence | Meeting | Purpose |
|---|---|---|
| Weekly | Design coordination meeting | Review clash aging, open RFIs and model exchange failures |
| Twice weekly | Overdue request review | Escalate items past their required response date by one level |
| End of each phase | Gate review | Obtain a written, dated gate decision from the owner |
Use this as a recommended operating rhythm, not an industry performance benchmark. UPG Solutions' discussion of connected construction workflows identifies organizational capability and complexity as technology-adoption barriers. A smaller firm needs clear authority before it needs another reporting platform.
Assign custody and approval separately
Give each data set a named custodian and identify who approves consequential changes:
- Model. The BIM coordinator maintains the federated record; discipline leads approve technical changes.
- Schedule. The scheduler or project manager maintains logic; the project manager authorizes baseline changes through the agreed approval process.
- Cost. The estimator maintains the cost plan; the principal or owner approves budget changes.
- Requests. The project administrator maintains RFI records; the responsible designer approves technical responses.
- Field progress. The designated field representative records observations; the construction lead validates reported completion.
Only the named custodian, or a formally designated delegate, changes record status. Preserve the previous value, reason, author and timestamp. Use a preconstruction team responsibility map to settle gaps between estimating, design coordination and scheduling.
Make escalation predictable
Use an escalation ladder from item owner to project manager to principal. Each item needs a response deadline, a project-manager decision deadline and a principal intervention deadline tied to the affected release or field activity.
Don't let an overdue item wait for the next scheduled meeting when it threatens work already underway. Meetings organize routine decisions; they don't suspend urgent authority.
A meeting produces control only when someone leaves with a decision, an owner and a deadline.
When platforms don't integrate, maintain a shared exception log and reconcile it through a weekly export. For distributed drafting and remote administration, every handoff should identify the file, required action, reviewer and acceptance condition. That discipline matters more than whether the team uses Procore, Monday or a spreadsheet.
How to Run a Closed-Loop Request Log
A construction-industry survey summarized in Aurigo's capital-project cost-control report found rework exceeded $31 billion annually, with nearly half associated with poor communication and project information. The project manager's job is to make unanswered questions visible before the field team has to guess.
The request loop needs both a written response and confirmation that the affected records have been updated.
Keep requests traceable from intake to closure
Assign a unique ID. Capture every RFI, submittal, drawing revision, design decision and change order. Separate record types, but connect related records so a design answer doesn't become detached from its cost consequence.
Name an owner and responder. The owner moves the item through the process; the responder supplies the authorized answer. An administrator can chase a structural response without having authority to approve it.
Set the required response date. Derive the date from the contractual review period and record the field need separately. If the request arrives too late for normal review, flag the conflict rather than silently shortening the reviewer's allowance.
Link the affected information. Attach the sheet, specification section, model element or cost line. Include the revision being questioned so the responder doesn't answer against a superseded detail.
Control the status. Use open, answered, superseded or closed. Don't close an item until the response is filed, receipt is confirmed and required document updates are complete.
Review overdue items twice weekly. Move overdue requests up the agreed authority ladder. Record the escalation and required decision, not just another reminder.
Flag repeated questions. A repeated question about the same element calls for a drawing or specification review. Sending the original answer again may leave the underlying ambiguity untouched.
Resolve the interface, not just the question
Say a contractor asks whether a sleeve can move around reinforcement. A reply approving the sleeve location may also require structural review, a revised penetration detail and an update to the coordinated model.
If the response arrives late, the installer may make an assumption to keep working. Correcting that assumption can then require revised drawings, a cost assessment and a resequenced activity. The request owner should identify those consequences before marking the record closed.
Use the following walkthrough to examine the request and response handoff.
Keep the performance measures on the project's shared control scoreboard rather than building a separate dashboard for every log.
The most common failure is an answer given by phone or email that never reaches the controlled record. Capture the answer, obtain confirmation from its author and notify affected parties. A conversation can resolve a technical question, but it doesn't automatically update the instructions others are using.
Metrics That Show Whether a Project Is Under Control
| Metric | How to Calculate It | Suggested Escalation Trigger |
|---|---|---|
| Overdue RFI rate | Open RFIs past their required response date divided by all open RFIs | Exceeds the project's agreed tolerance, or any overdue item blocks work |
| Average RFI response time | Total elapsed response days divided by answered RFIs | Exceeds the contractual review period |
| Repeat RFI rate | RFIs repeating an answered question divided by RFIs reviewed | Any repeat within the same sheet set |
| Submittal cycle time | Elapsed days from submission to returned action | Exceeds the contracted review period |
| Design changes after procurement | Count of changes affecting purchased packages during the reporting period | Any change after package award |
| Clash aging | Working days from identification to resolution for each open clash | Resolution threatens the planned issue date |
| Model exchange failures | Failed import or exchange attempts divided by exchange attempts | A repeated failure or an unusable accepted exchange |
| Estimate variance | Bid or outturn minus estimate, divided by estimate, expressed as a percentage | Exceeds the approved phase-gate tolerance |
| Rework hours by originator | Correction hours grouped by the party or discipline originating the issue | A sustained upward trend across reporting periods |
These are suggested starting triggers, not published industry benchmarks. Set tolerances with the principal and project team, then calibrate them against comparable completed work.
Measure control rather than activity
The number of RFIs issued measures activity. The overdue rate shows whether the team is meeting commitments, while repeat questions can expose unclear instructions. A low RFI count isn't necessarily good if contractors are proceeding without asking necessary questions.
Schedule and budget variance also arrive too late to explain every problem. Model exchange failures and aging clashes can expose a threatened release before anyone records a missed milestone.
Build the scoreboard from controlled records:
- Request timestamps supply issue dates, required dates, written-response dates and returned actions.
- Model issue records supply clash creation dates, resolution approvals and failed exchanges.
- Cost and time records supply comparable estimates, committed costs and correction hours.
For a hypothetical project, suppose 40 RFIs are open and 6 are overdue. The overdue rate is 15%. If that project has adopted a 10% tolerance, the project manager should escalate the oldest blocking items that day, rather than color the dashboard red.
Tie each signal to a decision
Keep estimate comparisons on a consistent scope basis. A bid for an expanded package isn't evidence of estimating error until the estimator reconciles the added scope. When assessing construction estimating capacity and cost, include responsibility for that reconciliation.
Group rework by originator to locate a coordination or review problem, not to create a blame ranking. Rising correction hours alongside changes to purchased packages call for an upstream decision review: what was released, what remained unresolved and who accepted the risk?
Confirm Your Controls Before Adding Automation
Automation makes a design professional less effective when it produces confidence without reliable inputs. A generated schedule can omit an approval dependency. A document summary can misstate a revision. A clash alert can be technically correct but operationally irrelevant.
The failure modes deserve explicit review:
- Incomplete BIM attributes can produce unreliable quantities or classifications.
- Weak change documentation can leave automated reports working from superseded instructions.
- Hallucinated summaries can introduce decisions nobody approved.
- Unreviewed code assumptions can bypass the responsible professional's judgment.
- Integration maintenance can shift work from administration into troubleshooting.
Test the whole workflow
The Aiden construction workflow automation benchmark claims RFI response times can fall from 5–7 days to 1–2 days and change-order processing time can fall by 70%. Those are vendor-reported benchmarks, not guaranteed outcomes for an architecture or engineering practice.
Record the baseline for RFI aging, submittal cycle time, estimate variance, drawing-revision hours, change-order recovery and rework. Compare similar packages with and without the proposed change, including the time spent checking outputs and repairing source information.
A faster draft response isn't a success if a senior engineer spends longer correcting it. Keep approval authority intact, and define where licensed-professional review remains mandatory.
Go or no-go: Automate a controlled process, not an unresolved responsibility gap.
Use readiness to choose the next step
Before a pilot, confirm that:
- Data owners are named and can explain their approval boundaries.
- The request log is in active use across comparable projects, not merely configured.
- Baseline performance is recorded with consistent definitions.
- Professional sign-off is defined for technical decisions and issued information.
- Pilot acceptance criteria are written for accuracy, total effort and project impact.
If the checklist fails, choose between hiring capacity, training an existing employee or adding remote project-management support. The right choice depends on whether the gap is workload, capability or coverage. Software won't resolve an authority problem.
If the checklist passes, pilot a narrowly defined workflow with a named reviewer and a rollback procedure. This week, have the principal and project manager complete the readiness check against a live project, then authorize either the staffing fix or the controlled pilot.
Our remote project managers work inside Procore, Buildertrend and Monday, overlap client working hours and can join client calls to help maintain the project controls your team defines. Visit HireArchitects to arrange a 20-minute call and specify the role, software and hours you need.
