Most architects learn project management the same way: by watching how the person above them did it, adopting their habits, and figuring out the rest through trial and error. The result, across most firms, is a wide range of PM quality: even within the same organization.
This isn't a criticism. Architecture schools don't teach project management. The focus is on design, and rightly so. But the design phase doesn't just need good designers. It needs a system. A way of organizing work, tracking progress, managing information, and keeping clients aligned — that holds up from the first kickoff meeting through the last coordination set.
This is that framework. It's built around the three phases most firms work through on a standard design contract: Schematic Design, Design Development, and Construction Documents. The principles apply regardless of project type or size.
Before You Start: The Project Setup Phase
The most common reason design projects run into trouble mid-phase isn't a design problem. It's a setup problem — something that should have been established at the start wasn't.
Before schematic design begins, every project should have:
A scope baseline, what services are in the contract? What isn't? This needs to be documented and shared with the full project team, not just the PM. When a client asks for something that's outside scope, the team needs to recognize it as such immediately, not six weeks later.
A project schedule. Not a perfect schedule: schedules change. But a baseline that establishes key milestones: SD completion, DD completion, 50% CD, 100% CD, permit submission. Without a baseline, you have no way to know if you're on track.
A project directory. Who's on the project team? Who are the consultants? What's their scope? Who's the primary client contact? This sounds basic. It gets skipped constantly.
A communication protocol, how does the team communicate? Where do decisions get documented? How does the client receive information? Establishing this at the start prevents a lot of ambiguity later.
Schematic Design: Structure Before Creativity
The goal of SD is to establish the design direction, massing, layout, program, materials — and get the client aligned on it before you go deeper.
The PM role during SD is to create the conditions for good design work, not to manage the design itself. That means:
Protecting the team's time. SD is when the design is most fluid and the team is most vulnerable to scope creep. A client who asks for "just one more option" during SD isn't being unreasonable but that request has a cost, and the PM's job is to make sure it's recognized and addressed.
Running productive design reviews. A design review without a clear agenda and a clear decision goal is a brainstorming session in disguise. Each SD review should have specific questions to answer and leave with documented decisions. See our piece on [tracking design decisions] for the mechanics.
Managing consultant engagement. Consultants need to be in the loop during SD, even if their scope is limited at this phase. Late consultant engagement during SD creates coordination problems in DD that are expensive to fix.
SD deliverables to track:
- Program confirmation from client
- Massing and site plan options (usually 2-3)
- Preferred option development
- Preliminary code analysis
- Outline specifications (often)
- SD cost estimate
The SD phase is complete when the client has formally approved the design direction. Get that approval in writing. The number of DD phases that have to circle back to re-litigate SD decisions because the approval was verbal is significant.
Design Development: The Hard Work Phase
DD is where the design gets detailed, the systems get coordinated, and the project either holds together or starts to unravel.
The PM role during DD shifts from setting conditions to active coordination:
Drawing set management. By DD, you have a live drawing set that's being updated constantly. Who has the current set? What was issued and when? This is where version control discipline pays off or where the lack of it starts causing problems. (See our guide on [drawing version control] for a full treatment.)
Coordination between disciplines. Structural, MEP, civil: they all need to be working from the same architectural base. A coordination meeting cadence established at the start of DD (weekly or biweekly, depending on project complexity) is more effective than trying to resolve conflicts at the end.
Scope management. Clients add things during DD. Sometimes it's appropriate — designs evolve. Sometimes it's scope creep that needs to be addressed with a fee proposal. The PM needs to be tracking what was in the original scope and what has been added, consistently.
Client check-ins. DD shouldn't be a black box. Regular check-ins: even brief ones, keep the client informed and prevent the "I didn't expect this" moment at the DD presentation.
DD deliverables to track:
- All discipline drawings at DD level
- Outline specifications updated to DD
- Code review complete
- Updated cost estimate
- Major equipment selections confirmed
- Client approval of DD set
Construction Documents: Execution Under Pressure
CDs are the phase where the pressure is highest and the tolerance for error is lowest. Every detail has to work. Every note has to be accurate. Every specification has to be coordinated with the drawings.
PM priorities during CDs:
Milestone tracking. 50% CDs and 100% CDs are the standard checkpoints, but many projects benefit from more granular internal milestones, discipline leads hitting specific sheet counts by specific dates. This requires a detailed production schedule, not just the contract dates.
Coordination reviews. A formal coordination review at 50% CDs: where all disciplines review each other's work and identify conflicts, is one of the highest-leverage things a firm can do to reduce field issues. It takes time. It prevents expensive problems.
Specification coordination. The drawings and specs have to agree. Conflicts between drawings and specs are a major source of bid alternates, RFIs during construction, and contractor claims. Assign someone ownership of keeping them aligned.
Permit set management. If the permit set is a subset of the CDs, track what's been submitted, what comments have been received, and what needs to be revised. Permit review cycles have their own schedule risk.
CD deliverables to track:
- 50% CD internal review complete
- All consultant drawings coordinated
- Specifications complete
- 100% CD set issued
- Permit submission made
- Bid set issued (if applicable)
The Thread That Runs Through All Three Phases
Three things make the difference between a design phase that holds together and one that doesn't, regardless of phase:
Visible accountability. Every task has an owner and a due date. Not just the major deliverables, the intermediate tasks too. When something slips, it's visible before it becomes a crisis.
Documented decisions. Design decisions made in SD need to be findable in CDs. If they live in someone's head or a buried email thread, they're not really documented.
Regular team alignment. A fifteen-minute weekly check-in with the project team. Not a long meeting, just a structured check, surfaces problems early. By the time a problem becomes obvious without a check-in, it's already expensive.
None of this is complicated. The firms that execute the design phase well aren't doing anything exotic. They're just doing the basics consistently, on every project, regardless of whether it's a $50M civic building or a tenant improvement.
