Project management for architects
How managing an architectural project differs from generic project management: stages, approvals, consultants, registers and drawings, and what a system needs to hold.
Project management as a discipline assumes a scope, a plan, and execution against it. Architectural projects violate that assumption immediately: the scope is discovered while doing the work, and the plan depends on decisions made by people outside the project.
That does not make architectural projects unmanageable. It means the management model has to be a different shape.
Stages are commercial, not organisational
In generic project management, phases are a convenience. In architecture, the stage is the unit of commercial entitlement, the unit of client approval, and the unit against which work is planned.
Software that treats stages as folders has thrown away the most load-bearing structure in the project.
The programme depends on people you do not employ
Approval timelines belong to councils and authorities. Consultant inputs arrive when they arrive. A programme is therefore a chain of dependencies where several links are outside the practice's control.
What a practice needs is not a plan that assumes control. It is visibility of what moves when one of those links slips.
Registers, not tasks
Architectural delivery runs on registers: RFIs, issues, decisions, actions, variations, risks and deliverables. They behave differently from one another and from tasks: different respondents, different obligations, different consequences.
A single task list with categories can hold them. It cannot behave correctly for them.
Drawings are the deliverable
The output of an architectural project is a set of drawings, issued on dates, revised, and depended upon by builders and consultants. Revisions matter. What changed between issues matters.
A project management tool with file attachments is not the same thing as a system that understands drawing sets and revisions.
What this means in practice
The practical consequence is that most practices using generic tools end up running two systems: the tool, and the spreadsheets that hold everything the tool cannot express.
The spreadsheets are where the fee structure lives, and the drawing register, and the resourcing plan. They are maintained by hand, they disagree with each other, and they are the reason nobody knows the practice's position until someone spends a week finding out.
Common questions
- How is project management for architects different?
- An architectural project is staged, and the stages have commercial and contractual meaning rather than being convenient groupings. It depends on approvals the practice does not control, involves consultants who are neither staff nor clients, and produces drawings issued in sets whose revisions matter legally. Generic project management handles none of these natively.
- What should an architectural project workspace contain?
- The programme, the fee position, the people allocated, the meetings and their actions and decisions, the RFIs, issues, risks and variations, the drawing sets and their revisions, the consultants and their scopes, and the deliverables with their dates. Crucially it should hold the relationships between them, not just store them side by side.
- Can I run an architectural project in a general task tool?
- You can, and many practices do. What it costs is the parts the tool cannot represent: the fee structure, the revision history and the consultant scope, which end up in parallel spreadsheets that have to be kept in step by hand.
Try it on a real project
Free for solo practices: one user, two projects, no card.