After 25 years in architectural practice, I’ve learned that the difference between having a process and actually following one can determine how successfully a project is delivered. From drawing checklists and mentorship to project scheduling and resource planning, the challenge isn’t simply creating better procedures. It’s making them part of how we work.
Every architectural firm has its own way of doing things. There are drawing standards, quality assurance procedures, project schedules, review milestones and checklists developed over years of practice. Some are carefully documented, while others exist largely in the memories of experienced employees. We invest considerable time creating these systems because we understand their importance. They help establish consistency, reduce errors and give people a framework for delivering increasingly complicated projects. Yet despite all that effort, there is a question worth asking: how many of those processes are actually being followed?
I’ve spent approximately 25 years working in architecture, and one thing I’ve noticed is that having a process doesn’t necessarily mean people will use it. I’ve seen drawing checklists that are incredibly detailed, yet rarely opened. I’ve seen carefully prepared schedules that become outdated almost as soon as a project begins. I’ve also seen experienced staff members spend considerable time explaining procedures that have already been documented somewhere on the office server. The information exists, the intention is good, and everyone understands that quality matters. Somewhere between establishing the process and completing the work, however, the connection gets lost.
This isn’t necessarily because people don’t care. Architectural offices are busy environments, with competing deadlines, consultant coordination, client expectations and the inevitable interruptions that come with delivering buildings. When someone is trying to complete a drawing package before a deadline, searching through a shared drive for the correct checklist can feel like another task competing for their attention. The easier option is often to rely on memory and experience, particularly when they’ve completed similar work before. The problem is that memory isn’t always reliable, and experience doesn’t guarantee that every requirement has been considered. A process that requires people to go out of their way to follow it will always struggle against the pressures of everyday practice.
A checklist built from experience
My relationship with drawing checklists goes back to the early years of my career. At one of the firms where I worked, we had a relatively simple checklist that helped guide the preparation of drawing packages. It wasn’t particularly elaborate, but it established a useful principle: before issuing drawings, there were certain things that needed to be reviewed. Later, when I operated my own independent drafting practice, I began developing a checklist of my own. As I worked through different projects and encountered new challenges, I continued adding to it. What started as a straightforward reminder gradually became a more detailed record of the things I had learned.
When I joined CHP, which later became Station One Architects, I brought that checklist with me. One of my colleagues had developed a similar document independently, and we decided to combine the two. That collaboration was particularly valuable because we approached drawing production from different experiences and perspectives. There were things on my list that weren’t on theirs, and things on theirs that I hadn’t considered. By bringing those ideas together, we developed a much more comprehensive checklist that could guide drawing production through different project stages. It wasn’t a document created by management simply to satisfy an administrative requirement. It was something built by people who had spent years preparing drawings and dealing with the consequences when something was missed.
The most valuable part of that process was that the checklist never really stopped evolving. Every project presented an opportunity to learn something. Perhaps a detail wasn’t coordinated properly, a dimension was overlooked or a construction issue revealed that something could have been communicated more clearly. Take a parapet, for example. If you’ve ever encountered a situation where a parapet wasn’t designed to the appropriate height, you understand how something that appears relatively minor on a drawing can become a significant problem during construction. Depending on the circumstances, correcting that oversight could result in a substantial additional cost. It’s the kind of experience that makes you think, I’m not going to let that happen again. The important next step is making sure the lesson doesn’t remain only in your own head. It needs to become part of the process so that someone else can benefit from it.
This is where I believe checklists become much more valuable than simple reminders. They represent accumulated experience, including the mistakes, conversations and lessons that have shaped how a firm works. A junior architectural technologist preparing their first building permit package hasn’t necessarily encountered the same problems as someone who has spent two decades reviewing drawings and administering construction contracts. They may understand how to model a wall assembly or prepare a building section, but they might not yet recognise the coordination issues that can arise between disciplines or the implications of an incomplete detail. A good checklist helps bridge that gap. It doesn’t replace mentorship or professional judgement, but it gives less experienced staff access to knowledge they haven’t yet had the opportunity to develop themselves.
A well-developed process preserves lessons learned and makes them available to the next person preparing the work. Conceptual illustration.
Of course, none of this matters if the checklist isn’t being used. You can spend years refining a document, involve experienced staff in its development and make it available to everyone in the office, but that doesn’t guarantee anyone will open it. I’ve seen how easily people can overlook something that’s sitting in a folder on the server, particularly when they feel confident in their own approach. This creates an interesting contradiction. We recognise the value of quality assurance, but the tools intended to support it can become disconnected from the work itself. It made me start thinking about a much simpler question: what if the problem isn’t the checklist, but how we’re asking people to use it?
Sometimes the problem is simply too much friction
I have a somewhat unusual example of this, and it involves washing my Mustang. When I first bought the car, I enjoyed keeping it clean, but washing it was a surprisingly frustrating experience. Before I could even start, I had to pull out the pressure washer, find the hoses, get the buckets ready, connect everything and arrange the cleaning supplies. None of those tasks was particularly difficult, but together they created enough inconvenience that I’d sometimes look at the car and decide I didn’t feel like dealing with it. The actual washing wasn’t the problem. It was everything I had to do before I could begin.
Eventually, I decided to build a dedicated car-detailing station. I ran the plumbing to the location I wanted, connected the pressure washer to a hose reel, arranged the electrical supply and positioned a water connection at a convenient height for filling my two-bucket washing system. The pressure washer gun was ready to go, the hoses were organised, and everything had a place. Instead of spending twenty minutes preparing the equipment, I could pull the car into the driveway, grab the hose and get started almost immediately. It was a relatively simple improvement, but it completely changed how often I washed the car. Because the process was convenient, I found myself doing it regularly.
Removing the preparation work made washing the car a simple, repeatable routine rather than an inconvenient chore. Conceptual illustration.
After moving, I still had the same equipment, but I no longer had that dedicated station set up. Suddenly, washing the car involved pulling everything out and connecting it again. The additional effort returned, and so did some of the reluctance. Nothing had changed about my ability to wash the car or my desire to keep it clean. The difference was entirely in how easily I could get started. It’s a small personal example, but I think it illustrates something important about the way people approach recurring tasks. When the necessary tools are already in place, we’re more likely to use them. When getting started requires several additional steps, even something we know is worthwhile can become easy to postpone.
I see the same principle in architectural practice. If someone is assigned to prepare a building permit drawing package and the relevant checklist is buried somewhere on the office network, they’re being asked to interrupt their workflow to find it. They have to remember that it exists, locate the current version, interpret which items apply and keep track of what they’ve reviewed. But imagine if those checklist items were already part of the project tasks, organised according to the stage of work and assigned to the appropriate people. The checklist would no longer feel like a separate administrative obligation. It would become part of the process of completing the drawings.
This thinking has influenced how I’ve approached Project Arc. Rather than expecting everyone to remember where procedures are stored, the intention is to bring those procedures into the environment where the work is already happening. A drawing checklist can inform the tasks associated with preparing a permit set. Those tasks can be connected to milestones, responsibilities and the broader project schedule. The goal isn’t to introduce more administration into an already busy office. It’s to make the things we know are important easier to incorporate into everyday work. When the process becomes convenient, following it has a better chance of becoming a habit.
There is an important distinction here, however. Making a process easier to follow doesn’t guarantee that people will perform the work correctly. Someone can still check a box without completing the underlying task, just as someone can sign off on a drawing review without noticing an error. Convenience improves the likelihood that a process will be used, but quality still depends on professional judgement, accountability and a willingness to review the work carefully. The objective should be to remove unnecessary friction while preserving the responsibility that makes the process meaningful.
One project, several ways of seeing the work
Another lesson I’ve learned is that not everyone wants to manage their work in the same way. Some people are perfectly comfortable with a list of tasks. They want to open a project, see what’s assigned to them, understand when it’s due and check it off when they’re finished. There’s a certain satisfaction in working through a list and watching the outstanding items disappear. Other people prefer a visual board, where tasks move from one stage to another. Dragging something from In Progress to Complete gives them an immediate sense of accomplishment, and the layout helps them understand how work is progressing without having to read through a long list.
Project managers often need a different perspective. They’re thinking about dependencies, consultant submissions, review periods and the relationship between one milestone and the next. A Gantt chart can help them see how the project fits together over time, particularly when a delay in one activity affects several others. Firm principals need to look even further ahead. They’re not necessarily interested in whether someone has completed a particular drawing note that morning. They need to understand whether projects are on track, where major deadlines are approaching, and whether the firm has enough people available to meet its commitments. Each of these perspectives is legitimate, and each serves a different purpose within the same practice.
The difficulty arises when those views are maintained independently. A project manager might have a detailed schedule in one application, while the production team tracks its tasks somewhere else. Drawing checklists may live on a shared server, consultant coordination happens through email, and staffing commitments are recorded in another spreadsheet. Each system may work reasonably well on its own, but the information becomes fragmented. Someone can complete a task without the project schedule reflecting that progress, or a principal can make a staffing decision without seeing how much work is already committed to upcoming deadlines. The challenge isn’t simply managing more information. It’s maintaining a reliable connection between the information people are already using.
This is one of the ideas behind Arc’s approach to project management: different people should be able to understand the same underlying work through the view that makes the most sense for their responsibilities. A task list, a board and a Gantt chart shouldn’t represent three different versions of a project. They should offer different perspectives on the same project information. When work progresses, that progress should be visible to the people who depend on it. The architectural technologist can focus on the next drawing task, the project manager can monitor the approaching submission, and the principal can understand how that project fits into the firm’s broader commitments.
A connected view of project schedules and milestones helps teams understand individual responsibilities and firm-wide commitments. Illustrative concept with sample data.
This visibility also changes the conversation around accountability. When responsibilities and deadlines are clear, people spend less time trying to determine who was supposed to do something or whether it was completed. That doesn’t mean every task needs to be monitored constantly, and it certainly doesn’t mean management should become an exercise in watching employees move items across a screen. The purpose is to establish a shared understanding of the work. People should have enough independence to do their jobs, while the rest of the team has enough visibility to coordinate effectively. Good processes create clarity without requiring everyone to work in exactly the same way.
A checked box is not the same as a completed review
There is another side to accountability that deserves attention, particularly in architecture, where the consequences of incomplete work can extend well beyond the office. Anyone who has reviewed a redlined drawing set will recognise the frustration of marking up an issue, receiving the revised drawings and discovering that the correction was never made. Perhaps a fire hydrant location needed to be coordinated, a dimension required adjustment or a detail was missing information. The markup was crossed off, the task was marked complete, and everyone assumed the issue had been resolved. Yet when the drawing was reviewed again, the original problem was still there.
It’s easy to respond to these situations with frustration. After all, someone was asked to make a correction, and they indicated that it had been completed. But I think there’s a more productive way to approach the conversation, particularly when we’re working with less experienced staff. Instead of immediately asking why they didn’t do what they were told, we can begin by asking them to explain their understanding of the issue. What requirement were they reviewing? How did they interpret the markup? What did they change, and why did they believe that change addressed the concern? Those questions can reveal whether the problem was a simple oversight, a misunderstanding of the technical requirement or a breakdown in how the task was communicated.
This is where mentorship and quality assurance become closely connected. If someone doesn’t understand why a particular dimension matters or how a building-code requirement affects the design, simply telling them to fix the drawing may resolve the immediate problem without improving their understanding. Taking a few minutes to discuss the underlying issue can have a much greater long-term benefit. The next time they encounter a similar condition, they’ll have a better understanding of what to look for and why it matters. Over time, those conversations can also reveal where the firm’s checklists and standard procedures need to be improved. The process becomes stronger because the people using it are continually learning.
I see considerable potential in connecting this approach with drawing and specification review tools. Arc Review, for example, helps teams identify potential coordination issues and requirements that deserve closer attention. It connects review findings with the relevant drawings, project responsibilities and supporting documentation. But an automated review should never be treated as a substitute for professional judgement. A flagged issue may require further investigation, and the applicable code requirements will depend on the project and jurisdiction. The value is in creating another opportunity to identify concerns, ask better questions and improve the quality of the work before those concerns become construction problems.
What interests me most is the possibility of completing the feedback loop. A problem is identified during a review, the team investigates it, the drawings are corrected, and the lesson informs future work. Perhaps the checklist needs another item, or an existing task requires clearer instructions. Perhaps a junior employee needs additional guidance on a particular technical issue. Instead of treating every mistake as an isolated event, the firm can use those experiences to improve how it operates. That’s how a process becomes something more valuable than a document that gets updated once every few years. It becomes part of the firm’s collective knowledge.
The schedule starts before the drawings
Processes don’t begin when someone opens a drawing file. In my experience, some of the most important project management decisions happen before the design team has even started its work. When we were preparing proposals, one of the first questions was whether we could realistically deliver the project within the client’s required timeline. We would look at when the building needed to go to tender, when construction was expected to begin and what had to happen before those milestones could be achieved. From there, we worked backwards through the design stages, establishing building permit dates, 30%, 60% and 90% reviews, consultant coordination meetings and the other activities needed to move the project forward.
That exercise did more than produce a schedule. It forced us to think carefully about the work before committing to it. If a client expected a tender package by January, we needed to understand what that meant for the design team in the preceding months. When would consultants need to provide their information? How much time would be available for coordination? When would the owner review the drawings, and how would those review periods affect the remaining design schedule? These are the questions that can become difficult to answer once a project is underway and deadlines are approaching. Addressing them early doesn’t eliminate uncertainty, but it gives the team a much stronger starting point.
By the time we reached the first consultant kickoff meeting, the objective was to have the major dates established and communicated. Everyone should understand when their information was required and how their work related to the rest of the project. We also encouraged consultants to upload their drawings ahead of coordination meetings, using shared file systems such as Dropbox, so that the team had an opportunity to review progress before sitting down together. This made the meetings more useful. Rather than spending the entire session discovering what everyone had been working on, we could focus on coordination, outstanding issues and decisions that needed to be made. The schedule provided the structure, while the shared information made the conversations more productive.
A Gantt chart can be particularly useful in this environment because it illustrates the relationships between activities. A consultant submission isn’t simply a date on a calendar; it may be necessary before another discipline can complete its work. A delayed review can affect the next submission, and a late design decision may create additional pressure as the tender deadline approaches. When these relationships are visible, the team has a better opportunity to recognise problems early and adjust its approach. The chart itself doesn’t manage the project, of course. People still need to communicate, make decisions and take responsibility for their work. But a well-maintained schedule gives those conversations a common reference point.
There is a simple analogy I often think about when considering large projects. Imagine standing at the edge of a hundred-acre field that needs to be harvested. Looking across that enormous area, it’s easy to feel overwhelmed by the amount of work ahead. You can spend a great deal of time thinking about the size of the task without actually making progress. But suppose you pick up a stick and throw it as far as you reasonably can. Instead of worrying about the entire field, you focus on working toward that stick. When you reach it, you pick it up, throw it again and continue. After enough repetitions, you turn around and realise how much ground you’ve covered.
Breaking an overwhelming undertaking into manageable stages makes progress easier to understand and sustain. Conceptual illustration.
I think the same principle applies to preparing a building permit package. For someone who hasn’t done it before, the complete set of architectural drawings can be intimidating. There are plans, elevations, sections, details, schedules, code considerations and coordination requirements that all need to come together. Simply telling someone to prepare the permit set doesn’t necessarily give them enough direction to begin. But when the work is divided into clear stages, with defined tasks and review milestones, the next step becomes much easier to understand. Complete this portion, review it, coordinate the next requirement and continue. Eventually, the work that initially seemed overwhelming becomes a series of achievable responsibilities.
This is also where the value of a well-developed process extends beyond project management into staff development. A junior employee doesn’t need to understand every aspect of a complex building on their first day. They need to understand what they’re responsible for, what information they require, where to find guidance and who can help when they encounter something unfamiliar. As they work through the process, their understanding grows. Over time, they begin to recognise the relationships between tasks and develop the judgement needed to anticipate issues independently. The checklist and schedule provide the structure, but the experience of completing the work provides the education.
Can we actually take on another project?
There is one final aspect of this discussion that becomes increasingly important as an architectural firm grows: resource planning. When a new opportunity comes through the door, the first reaction is often excitement. Perhaps it’s a project the firm has been pursuing for some time, an opportunity to work with a new client or a building type that aligns particularly well with the team’s experience. But before committing to the work, there is a practical question that needs to be answered. Can we actually deliver it?
It’s a question that sounds simple until you begin looking at everything already happening across the office. One project may be approaching its building permit submission while another is preparing to go to tender. A third may require significant consultant coordination, and several others may be dealing with construction administration issues that weren’t anticipated when their schedules were first established. The people needed for the new project may already be committed to those deadlines. Without a clear understanding of the firm’s existing workload, it’s surprisingly easy to make commitments based on an incomplete picture of available capacity.
This is where I believe project scheduling and resource planning need to be considered together. Looking at a single project’s Gantt chart tells you when that project’s activities are expected to happen. Looking across all the firm’s projects begins to reveal where those activities overlap. Adding an understanding of who is assigned to the work provides another level of information. A principal can see that a particular technologist is heavily committed to an upcoming permit submission, while another employee may have capacity opening up after a tender package is issued. A project manager can recognise that several deadlines are converging and begin discussing whether priorities or assignments need to change. The information doesn’t make the decision automatically, but it allows the decision to be made with a better understanding of the circumstances.
A shared view of commitments creates space for better conversations about workload, deadlines and the next opportunity. Conceptual illustration.
This firm-wide perspective is an important part of the thinking behind Project Arc. The objective is to connect the everyday work of individuals with the larger commitments of the practice. Tasks, milestones, project schedules and resource information should contribute to a shared picture of what the firm is doing and what it has the capacity to take on. A principal shouldn’t need to assemble information from several disconnected spreadsheets simply to understand whether the team is approaching a difficult period. Equally, an employee shouldn’t have to guess which of several competing assignments deserves attention first. Better visibility gives people the opportunity to have those conversations before the pressure becomes a crisis.
Resource planning is not simply about keeping everyone busy, either. A firm operating at full capacity on paper may have very little room to respond when something unexpected happens. Construction issues arise, client priorities change, consultants deliver information late and projects rarely progress exactly as originally scheduled. A realistic understanding of workload needs to account for the fact that architectural practice involves uncertainty. If every available hour has already been committed, even a relatively minor disruption can affect several projects. Knowing where capacity exists, where it is constrained and where deadlines are approaching can help firms make more considered decisions about staffing, scheduling and new opportunities.
Ultimately, I think this brings us back to the original question of whether people are actually following the processes their firms have established. A checklist, a task board, a Gantt chart and a resource plan might appear to serve different purposes, but they’re all trying to accomplish something similar. They make the work more understandable. They clarify expectations, help people recognise what comes next and provide a way to communicate progress and responsibility. When those systems are disconnected or difficult to use, they can become additional administrative burdens. When they’re thoughtfully integrated into the way a firm operates, they have the potential to make the work itself more manageable.
After 25 years in architecture, I don’t believe the answer is to create increasingly complicated procedures or expect people to remember every lesson that has ever been learned. The more useful approach is to build on practical experience, make that knowledge accessible and establish systems that people can realistically use. Good processes should evolve as teams learn, projects change and new challenges emerge. They should support professional judgement rather than attempt to replace it, and they should make it easier for experienced staff to share what they know with the people coming after them. Most importantly, they should help everyone understand how their individual contribution fits into the larger effort of delivering a building.
Start with one process your team already knows could work better. Make the next step clear, put the guidance where the work happens, and build from there.
