Ask a principal at most architecture firms about project management, and you'll get some version of the same answer: the architects who are good at it are valuable, and the ones who aren't are a challenge. The implication is that project management is a talent question, some people have it, some don't.
That framing misses the real problem.
Architecture firms don't struggle with project management because architects lack the aptitude for it. They struggle because the profession has systematically failed to teach it, reward it, or build systems for it. A Procore-commissioned IDC survey found that 75% of project owners were over budget and 77% were behind schedule, with projects averaging 70 days late. The firms using digital project management tools consistently outperformed those relying on manual methods.
The Education Problem
Architecture school trains students to design. This is appropriate. Design is the core skill the profession requires. But a five or six year architectural education typically includes almost nothing about how to run a project: how to manage a budget, write a scope of service, track deliverables, manage a team, or navigate the client relationship.
The outcome: that every architect who becomes a project manager essentially learns on the job, from whoever happened to manage projects above them. The quality of that education varies enormously depending on the firm, the mentor, and the project type. And the skills learned are often highly specific to that context, what worked at a healthcare firm might not translate to a higher education client.
This is a structural education gap, not an individual aptitude problem.
The Promotion Problem
In most architecture firms, the path to project management runs through technical excellence. You're a strong designer, you're reliable, you show initiative — and you get more responsibility. Project management responsibility included.
The problem is that being a good architect and being a good project manager are related but distinct skills. Technical competence is a necessary but not sufficient condition for PM success. The skills that make someone an excellent designer — attention to detail, willingness to explore options, aesthetic judgment — don't automatically transfer to the skills that make someone an effective PM: clear communication, proactive risk management, client relationship management, and the willingness to have uncomfortable conversations about scope and schedule.
Firms that promote almost exclusively on technical merit end up with project managers who are technically strong but often underprepared for the management side of the role.
The Incentive Problem
Most architecture firms reward design quality. The project that wins an award, the firm's work in design publications, the rendering that draws clients in, these are visible and celebrated.
Project management quality is largely invisible. The project that comes in on scope, on schedule, and on fee, with a client who stays for the next project, is the most valuable thing a PM can deliver — but it rarely generates the same recognition as a project that gets published.
The result is a subtle but persistent signal that design is what the firm values, and management is a necessary overhead. This makes it harder to attract architects into PM roles, harder to retain them once they're there, and harder to build the institutional investment in PM quality that would actually change outcomes.
The Systems Problem
Even firms with talented project managers often lack the systems that would make good project management reliable rather than heroic.
When project management quality depends on the individual PM, their personal system, their habits, their relationships — the quality is inconsistent across projects. A PM who leaves takes their system with them. A junior PM assigned to a project above their current skill level doesn't have institutional tools to fall back on.
Systematic project management: where the process is documented, the tools are consistent, and the PM's job is to execute a reliable system rather than invent one from scratch on each project: is rare in architecture. Most firms are one or two levels of process maturity below where they could be, not because they don't care, but because they've never prioritized building the infrastructure.
What Actually Fixes This
None of this is insurmountable. The firms that manage projects well have typically done some combination of the following:
Treated PM as a discipline worth training. Deliberate investment in PM skills — not just exposure, but actual training, mentorship, and feedback. Develops project managers faster and more consistently than the sink-or-swim approach.
Built systems that don't depend on individuals. Document control processes, task tracking protocols, client communication templates, the system should survive staff changes. When the PM leaves, the project should keep running.
Recognized PM quality explicitly. If the PM who delivered three projects on scope and on schedule doesn't get the same recognition as the PM whose project got published, you're reinforcing the wrong incentives.
Invested in tools built for the actual workflow. Generic project management software requires more configuration than it returns for most architecture firms. Purpose-built tools — ones that understand the terminology, the document workflows, and the collaboration model of design projects, reduce the friction of doing PM work well.
The goal isn't to turn architecture firms into process-heavy bureaucracies. It's to give talented architects the systems and support that let them spend their energy on the work, design and client relationships, rather than on reinventing project management from scratch on every project.
