General Area of Professional Practice (ARE): Pre-Design

Topic: Day in the life of an Architect - During the Programming Phase

Recently, I was asked to consider what a typical day is like for an architect. As I thought about this, I quickly concluded that really, no two days are the same. It is constantly changing. This constant change has made for a very interesting and challenging career for me personally, and I have to say, that the time seems to fly by when each day brings new problems, analysis, and solutions.

As I thought more about how to describe a typical day for an architect, I decided that perhaps the best way to proceed is to progress through the different phases of a project. So, this first view of "a day in the life of an architect" is through the lens of the Programming Phase (or Pre-Design).

First, what is programming as it relates to the practice of architecture? Early-on in my career, I learned to think of architectural programming as the phase when an architectural problem gets defined. After all, it is very difficult (and extremely inefficient) to try to problem solve without knowing as much as you can about the problem itself. Too often, architects rush to design solutions for problems that are not fully explored, and the result is that the problem gets exposed in "slow-roll" fashion throughout the project, resulting in a great deal of back and forth and redesign. I'm sure that this phenomenon is at least partly why architects struggle to be consistently profitable in their businesses.

Through my experiences, I'd say that a day in the life of an architect during the Programming Phase is always very interesting. It's when the architect works with the client team to define the project in broad terms. Often, this begins with developing a solid understanding of the big picture goals for the project. As an example, in a recent fire station project (which was a full replacement of an existing fire station), the high-level goal was to get a new station funded. Without funding, there would be no project. To get funding, voters had to approve and pass a bond measure, which means they had to support the project so much that they were willing to vote to increase their own property taxes. That challenge required a unique strategy to programming, one that engaged the community from the beginning, so that there would be an opportunity to develop a strong sense of buy-in for the project.

This programming process began by sitting down with the client and mapping-out how and when to engage the community, then develop a project schedule so that each touch point was identified and coordinated with our overall programming efforts. We then evaluated the current fire station for overall status of conditions, noting how it stacked-up against today's essential facility standards, and developing opinions on life expectancy of various building and system components. We also developed a cost estimate to remodel the current fire station and complete with seismic and other essential facility upgrades to bring it up to current standards.

At this point, we held our first meeting with the community to share our findings, including our estimate of costs to remodel the current station. We held an "open house" at the fire station and invited the community in for a presentation. We began by sharing our findings, and then conducted tours through the station so that people (voters) could get the best understanding possible regarding the need to either upgrade the current facility or replace it altogether.

Next, we worked with a diverse team of Fire District staff to develop typical program criteria including identifying space needs, adjacencies, and high-level site criteria for a full replacement fire station. Armed with this, we could develop very preliminary "block" site and building plans. We then held our second public forum at the existing fire station and invited in the community once again. At this meeting, we presented our preliminary block plans (pre-design plans) and engaged the audience in a discussion about aesthetics for public buildings in their community. This was not a detailed discussion, but enough to provide an opportunity for the community voices to be heard.

Based on the feedback we received in the second community meeting, we then developed conceptual level plans and renderings for a new fire station and produced a full project cost estimate. This was all presented at a third public meeting, and by then, we could see from responses we were receiving that support for replacing the current fire station with a new one was growing strong.

A few months later, the project was on the local ballot, and the bond measure for the design and construction of a new fire station was passed with an 80% approval rating!

Now, back to that idea of a "day in the life of an architect". If you consider that every project has it's own unique properties including the type of project, who will use the project when it is completed, and how it will be funded (among many other variables), it is safe to say that no two days are quite alike, and all are very interesting indeed!