It’s quite common for musicians to source vintage instruments and music technology to use to make new sounds. If done right, the resulting music gets celebrated as fresh takes on music crafted from old tools of the trade. It’s equally common to find musicians like Kraftwerk pushing the envelope of music technology as aides to their quest in producing entirely new and highly-disciplined sounds. There’s a freedom to how one produces music and what they use in that prodiction no matter what approach one takes. This is where it gets funny to cross-reference technology in production versus the result produced between music and architecture.
The musicians don’t make money from the creative process of the studio, but rather the resulting music itself (and mostly touring that music, of course). They could maybe lose a little money if the production process takes too long, but that’s all mitigated by ongoing album streams/sales, touring, merch, and even dropping the quick single or remix to supplement cash flow in between the big releases, or even doing production for another artist’s album.
The common business model of architecture is to charge for the production rather than the resulting building. Here’s where you quickly realize that any romanticism for manual drafting or even CAD must to be brushed aside for newer technologies that allow production to go faster with less labor and yield even better buildings. Architects don’t have royalties to lean on if production drags on too long, and when was the last time you saw merch from a firm that you considered paying for? Never! That’s why we give that shit away, it’s just not that cool.
Now is about the time that I started thinking more seriously about the ripples within the architecture industry concerning new business models. Concepts like building royalties have come up. There’s also been talk of outcome-based contracts alongside outcome-based design. So I’m not breaking any new ground here, but rather arriving at a similar conclusion from a different perspective.
Obviously the music business isn’t perfect. Things like royalties and tour proceeds have caused many musicians to get screwed out of hard-earned dollars. The music industry makes it all too easy for emerging artists to get exploited too. Musicians go their own way, with their own labels, and even build their own management companies to keep from getting robbed by the big companies (there’s a scary analogue for cranking out projects and making the firm rich versus becoming a sole proprietor too).
“These record labels slang our tapes like dope You can be next in line and signed and still be writing rhymes and broke”
Dead Prez
Here’s the parallax of those incredible bars from Dead Prez… These developers slang our designs like dope You can be next in line and signed and still be making BIMs and broke
I’m hoping the first architect that became their own developer said that shit — or at least they will in the movie version of their story.
There are definitely lessons to be learned before architects dive into new business models that are inspired by or adjacent to those of the music business. But it’s certainly worth thinking about seriously. I thought I was satisfied with the realignment I did to make the value of phases in my contract align with the BIM Curve, but my current thinking is to blow up everything and devise a new business model with a more sustainable cash flow aspect to it.
We architects aren’t the only ones with business models feeling outmoded by the 21st century economy. If we circle back around to the technology itself, software developers everywhere are going to subscription-based models as a way to cash flow and continue to innovate their products. If you’re an architect that’s reluctant to think new business models could work, remember that the next time you cough up that software subscription dough, just like you did the year or month before.
For every time an architect has found themselves redesigning something based on limitations brought forth by an engineer or feeling frustrated about what they got back from an engineer after a conversation that the architect thought went well, I can all but guarantee that the engineer is even more irritated with the situation than the architect. The engineers, just want clear guidance and boundaries so they can do their design work and be done; and the smaller the budget or the tighter the schedule, the more all of this rings true.
We architects can do better if we know what to be thinking about as we develop that initial schematic design. We can do better if we know what to ask as we design, or if we know how to explain our design intent in the language of mechanical and electrical engineering. Here’s some ideas…
Think Ahead, and Know the Systems Involved
Think about MEP systems continuously as you develop a schematic design, and the lower the project budget, the more things like ducts, conduits and plumbing should be occupying your early design thoughts. Use this boring stuff that architects don’t like to think about to your advantage and make it live harmoniously with your design.
Of course, all this requires you to know something about how MEP systems work, and if you don’t know, you’ll need to educate yourself. One thing a wise and talented engineer who runs a firm where all of the staff handle both mechanical and electrical engineering work told me was that he sought out great mechanical engineering professionals and then taught them electrical engineering. He explained that this was because mechanical engineering was much more complicated compared to electrical engineering, so adding electrical to the repertoire of mechanical engineers was the easier way to go. This is an important consideration for architects looking to learn enough about MEP systems to be able to guide their schematic design — you’ll pick up what you need to know about electrical quickly, so the focus for your learning needs to be on mechanical.
How does one learn? That depends a lot on how you like to learn (self-guided versus being taught by someone). I like to figure out as much as I can myself and then talk about what I learned with an engineer to refine my knowledge. Like so many things, the engineered systems that serve buildings are always evolving, but the basics haven’t changed much since Willis Carrier invented air conditioning and Thomas Crapper made the modern…well, uh crapper possible and Thomas Edison was fiddling with light bulbs. This is good because the basic knowledge will serve you well and doesn’t change over time. I think internet-based research is great for learning about MEP systems, and back when I didn’t know anything, I learned from the Architectural Graphic Standards, which are still a great resource — especially if you can get access to several different editions as content changed over the years and some go into more detail than others. You need to know this shit to pass the ARE anyway, so dive into it and enrich yourself!
Here’s a quick overview of what kind of MEP knowledge an architect needs to have in order to integrate MEP systems from the start of schematic design:
🌬 Mechanical Knowledge
Understand HVAC systems relevant to your particular line of work:
Know the components of each system and what kind of design scenario each system is appropriate for
Understand how the system gets attached to the building/site
Have awareness of any plumbing or electrical utilities that must connect to these systems
Know how the system gets fresh air and exhausts stale air
Understand what in the system needs service access and how to get to the system for access
Think about supply and return duct paths/distribution and understand rough duct sizing
Be aware of supplemental HVAC systems like exhaust fans/hoods, air doors, perimeter heating systems, etc. and know when you need to plan for them
Have a general understanding of what’s expensive when it comes to HVAC and what about that stuff makes it expensive — know what people do to save money too
🔌 Electrical Knowledge
Understand the basics of how electricity flows safely, as this is the main way to understand everything else about electrical infrastructure
Know the general dimensional requirements of switch gear and all of the related distribution equipment for your particular line of work, also know the code requirements around placement/spacing of this gear
Think about conduit paths to unusual parts of your design that need electricity for things like lights, such as canopies and interstitial spaces
Know what kind of gear is the most expensive and what makes it that way, also know how to be economical when placing primary and secondary conductor runs as these can get expensive too
🚽 Plumbing Knowledge
Understand slope requirements for the various types of sewer lines and be aware of how much height this sloping will require in your design
Think about where pipes will stack as they travel vertically through your design and have general knowledge about the size of those pipes relative to the purpose they serve
Know the plumbing infrastructure that accompanies automatic fire sprinkler systems and the code and local ordinance requirements around its placement in the building
Understand the basics of how hydronic plumbing serves certain HVAC systems and how that impacts HVAC system selection and infrastructure needs
Know how to estimate drainage needs for the kinds of roofs you use in your work
Know how to make plumbing expensive — and don’t do that stuff
It’s important to gain an understating of the different types of HVAC systems, or more specifically what makes them different from one another. When you have an understanding of the different HVAC systems you can make design suggestions for your engineers up front based on the program and your desired design objectives. After some conversation with the engineer, your selection may not be right for the project, but it goes a very long way to getting your engineer on the same page as you relative to what’s important to respect about your design and what needs to be accomplished to satisfy the program.
As an example, if your project is a build-out of the ground level shell of a multistory building, what did they leave you to start with for HVAC systems? Because you’re going to need to work with and around that equipment. Understanding the basics what that system is and how it works will help you deal with an existing condition that will impact the aesthetics of whatever you come up with in your schematic design. What if there is no existing HVAC structure? What if you know that there’s nowhere to place HVAC equipment except inside this ground level space? What if you understood that any HVAC getting used in this space needs both fresh air intake and return air exhaust? These are all things that aren’t a big deal to integrate from the start if you understand the basics. Integration of engineering elements into your design from the start can definitely help keep a handle on construction costs too. This is just one tiny example of why it’s important to design with MEP in mind.
Your Design Actions Have Consequences
As alluded to above, your earliest design decisions have (financial) consequences. Forcing an MEP engineer to work around your design because you didn’t consider the needs of other building systems can be directly attributed to increased construction costs. Tightly integrating MEP systems with the architecture is not only a beautiful thing from a purely aesthetic point of view, but it usually means you’re helping save money on the project too by being efficient with these expensive and laborious systems. The first people on the project team to thank you for all of this will be your engineers and the most grateful will be the client.
Few forms of design draw sneers from the chin-strokers of the architecture community like chain restaurant design. It’s mostly deserved, but a bit of irony is that few types of architecture inspire normal people to write about them like chain restaurant design. I’m always surprised by the amount of material on the web dedicated to this topic.
I found some notes from old design studies where I explored the landscape of chain restaurant design and thought it would be a good exercise to organize those notes into a (hopefully) coherent list of what I see as the main typologies. There’s a bit of history here, and the other thing is that chains are constantly evolving their designs if they aren’t tearing them up and starting over, so this is very much a reflection of a moment in time, though I think there will always be a half dozen or so principal design motifs for chains.
It’s important to understand that amongst restaurant chains there are leaders and followers. The leaders are at the top of their market segment and take the majority of the revenues, some of that trickles down to architectural R&D, which is notable because it explains how they’re able to set new design standards for the rest to follow — the followers just don’t have the budget to develop new design concepts like the leaders, so they’ll usually just copy. I’ll let you sort out who’s who as you move through this article, it’s pretty easy to see.
Origins
Let’s start with a brief history of restaurant chains — really brief, because I want to get into the present. Here in the US, the restaurant chain as we know it today began with White Castle in 1921 in Wichita, Kansas. I deeply admire the authenticity of White Castle’s original mission, which was to present a clean, safe, friendly burger joint at a time when Upton Sinclair scared the shit out of people by telling the truth about the meatpacking industry of the day. White Castle’s design responded to its founders wishes with a shiny, white, regal castle filled with stainless steel and white enameled steel paneling. It was an enormous contrast to the typical diner of that time and quickly became a huge success. When restauranteurs ask me what I think makes for great restaurant design, I tell them authenticity is most important — that what the design does has meaning to it and a true story behind it that resonates with people. A lack of authenticity is what makes so much chain restaurant design laughably bad. I think there’s some correlation between many of the most beloved and successful chains and the authenticity of their design too. I’ll be writing more about my design approach another time, but I wanted to plant this seed before getting into the exterior design typologies we’ll be looking at in this article.
Fast forward to the 1970s and 1980s, which were decades when the modern day restaurant chains that were around then really started to become the brands as we know them today. Let’s take a quick look at what I regard as the first typology to emerge, the Shingled Hut, a mostly if not exclusively fast food design approach…
I’ve included Shingled Huts from McDonalds, Burger King, Dairy Queen, and Pizza Hut here. The parti for this one is take a simple, low single-story box form and clad it in wood battens or face brick, then put a mansard or Dutch hip roof on it. It was simple and fast, like the food being served out of them.
Provincialism
With our brief history lesson complete, we need to talk about Provincialism, which is the design typology that really serves as a bridge between the mostly fast food Shingled Hut and the variety of design approaches today’s chains use. As casual dining chains emerged, they needed to find their own design language to help them differentiate their offerings from the fast food spots. Early on, that approach was to mimic the architecture of the places where the type of food they served originated from…with uh, varying degrees of success. This is an unsophisticated approach, but that’s okay, the food is often simple, guilty pleasures and Provincialism provides an efficient way to bang people over the head with the kind of food to expect…
There’s a veritable world tour here with Steak & Ale, Red Lobster, Olive Garden, Romano’s Macaroni Grill, Texas Roadhouse, and Cheesecake Factory. That list is in a loose chronological order of innovation. Steak & Ale is extinct, but as an early casual dining chain, I think their elaborate half-timbered whatever it is was both iconic and a trend setter. It’s important to note that some of Provincialism is hyper-specific and I think both Red Lobster’s New England by way of Disney seafood thing and Texas Roadhouse’s don’t mess with our Lincoln Log fort are great examples of specificity. Fun fact: Texas Roadhouse landed an article in Architect a while back — I loved it, a brief detour into the architecture of the 99 percent!
Parapets & Lit Awnings
Nearly parallel to the chronology of Provincialism comes Parapets & Lit Awnings, the domain of family dining (and it’s worth mentioning THE go-to standard for pretty much all one-off sit-down restaurants). I don’t think there’s any design approach as common as this one, and we all know it well: start with a box or assemblage or boxes, add really tall parapets with variation in both height and cornice/coping treatments, then make sure every window band has an awning over it, and of course every awning has to have a tidy row of gooseneck light fixtures over it to make all that canvas pop after the sun sets…
I’ve got three absolute classics for Parapets & Lit Awnings here: Applebee’s, Fuddrucker’s, and Chili’s. All those parapets are the stuff of nightmares for every structural engineer and also the poor sap who has to detail the flashings, but “they really help it look like a village instead of just a boring box”…says every citizen on every planning commission ever! 😂
Theme Architecture
It came on strong in the 1990s and hasn’t disappeared entirely, but is certainly an endangered species at the moment. The approach is simple, pick a theme for your restaurant and force every last aspect of your business to vigorously express that theme, including the exterior of your building. The one-off restaurants that employ Theme Architecture are popular go-tos for TV shows that present “weird and wild” destinations. The chains who adopt themes are steadily shrinking, especially when it comes to exteriors, but I think this all-encompassing design will make periodic comebacks because people never learn…
The Gloria Gaynors of Theme Architecture: Rainforest Cafe and Medieval Times, bravo!
Retro-Googie-Nostalgia
Adjacent to Theme Architecture in both (tacky) taste and endangered species status is Retro-Googie-Nostalgia. This is when a brand hops into the Wayback Machine, mining their storied history for a look from the past; and if you don’t have a distant past, well, just make up some shit, it’s all good. Chains that recently embraced Retro-Googie-Nostalgia only did so for a hot minute and are actively going back and introducing these old-fashioned looks to the business end of a modern day bulldozer…
Gotta have that throwback McDonalds in there, and Sonic too. This is a typology made for fast food and drive-ins. But we’re over it, and so are the chains.
Eyebrows on the Rocks
When a new class of casual dining chain emerged at the start of the 21st century, one whose menus have dishes like rotisserie chicken next to sushi, it was time for a new design typology — and it’s sticking! Eyebrows on the Rocks is the look of these classy destination restaurants that aren’t afraid to go big when it comes to menus, dining rooms, vaulted ceilings, bars, patios, and everything else. So we’re cladding the exterior in faux rock veneers and mixing in some eyebrow canopies in a variety of materials to signal our intentions to the world…
The standard-bearers of Eyebrows on the Rocks are Redstone American Grill and Kona Grill. I can see this look spreading like wildfire (which also happens to be the name of a mini-chain that uses elements of this design). You’ll see a lot of tired casual dining chains looking to Eyebrows on the Rocks as a part of their revitalization plans, kind of like when aging celebrities get plastic surgery and try to pass it off like they’re drinking more smoothies or something.
McCentury Modern
The current design iteration of the fast food chains was pioneered by McDonalds making a hard turn towards modernism with their latest look. The rest of fast food soon fell in line. McCentury Modernism is defined by the asymmetrical massing of brands’ bright colors contrasted with neutral brick or EIFS backdrops. Hard canopies are often inserted onto these facades and no, you don’t even need windows under those canopies! I can see this popular new typology already merging with Brandchitecture, which is next on my list. The boundary between these two is quickly blurring…
Super-sized modernists McDonalds, Wendy’s, Taco Bell, and Jack in the Box are all here and let me tell ya, god is in the details.
Brandchitecture
The new hotness is Brandchitecture. We’re starting to see this everywhere. Brandchitecture is mostly driven by branding agencies who claim it’s data-driven and responsive, which I fully buy for stuff like menu design and branding itself, but architecture isn’t those things. There’s an old saying in graphic design, “will it fax?” that comes from a time when logo designers were pressed on that question by their clients who held myopic concern about new logos not transmitting clearly in the preferred communication tool of the day. Today, I imagine clients asking their branding agencies, “will it building?” And that’s one of the salient concerns I have about this movement, it concludes that every logo is also a building, for badder or worse. The saddest part of Brandchitecture for me is seeing White Castle, who started this article and was the first of all chains, move in this direction with their latest locations.
Your big three of Brandchitecture are Panda Express, Dunkin’ (had to do a double shot of Dunkin’ — it’s glorious — extra points for branded door pulls), and Buffalo Wild Wings. There’s…a lot going on in these exteriors.
Kentucky Taco Hut
Pictured at the top of this article is an example of cotenancy: the Kentucky Taco Hut. Not a distinct typology per se, but rather a forceful coming together of two or more chain’s architectural identities. It’s extremely common for franchised concepts, and rarer to find for corporate-owned restaurants where it comes into play on unusual real estate deals that brokers finagle for really expensive land or tenant spaces. We’ll probably see more of this if real estate costs keep increasing to ridiculous new heights like they have been for the last decade.
How Do We Get These Looks?
When it comes to the aesthetics of the exterior of restaurants, it’s extremely common for the final decision-maker to be someone in the organization that isn’t an architect but is deeply involved in matters of design. These individuals have very strong points of view and there’s frankly not enough effort invested by the design professional in getting to know the decision-maker and really work though their vision with them, a lot of that effort is tied to budget constraints that I mentioned at the beginning of this article. Also, as I mentioned, some brands have no money for this stuff and just have an architect knock off a look of someone else.
Then there’s branding agencies. I do love the great ones, who are both essential and a joy to work with — but it’s important to clearly define roles and understand that branding isn’t architecture, but rather architecture can help express the ideas of a brand.
It’s worth noting that municipalities force a lot of change onto exterior designs through appearance review committees, planning commissions, and their detailed ordinances. It’s not uncommon for brands to walk away from any attempt at using their own design just to appease the design whims of a municipality because its such a great location for business and they’re willing to compromise to get the thing open.
This is a good place to mention remodeling. It’s a continuous occurance in the chain restaurant world because customers are fickle and concepts need to evolve to suit new tastes. Any brand I’ve mentioned in this article that’s been around for more than a decade has had to remodel to stay competitive. We may get new typologies or see abandoned ones reappear because of this change cycle.
That’s all for my look at chain restaurant exterior design. I have more old notes on interior design, so you can count on an Interiors Editions in the future.
PS Now you can identify the type and vintage of the recently uncovered McDonalds at Gitmo. Check it out…
This series covers how architecture professionals managing the rollout of multiple locations at a time for chain concepts can manage that process through Smartsheet, the web-based tool based on internet-connected spreadsheets.
In Part 1 I introduced the concept of using Smartsheet for tracking the development of multiple projects simultaneously for a chain concept doing rollout development. We continued with Part 2, where I explained how my build works to support this effort and how it’s all interconnected to form a database using Smartsheet’s Control Center add-on.
For Part 3, I’ll wrap up my thoughts on this system by covering how the building of this database works with Smartsheet and their staff and I’ll touch upon what else architects can use Smartsheet for in their work.
How the Build Works
When a Smartsheet user/organization decides to add on the Control Center package to their service, Smartsheet will assign that organization a Customer Success Manager as a resource to help guide that organization though maintenance and changes to their Smartsheet database. Smartsheet also brings staff members who specialize in standing up new Control Center installations on board to help the organization get their new Control Center up and running. I’ve found these specialists to be a great resource as they’re quite skilled at converting a vision for a system into reality and they possess deep knowledge of all of Smartsheet’s features and formulas.
It’s important for the organization to identify a point person to interact with Smartsheet and organize the goals for Smartsheet into a clear vision that can be communicated to Smartsheet’s specialists. This person will need to be on-call in the early days of the build to react to things the specialists are setting up and to even help modify some of that work to help provide direction to Smartsheet for the Control Center configuration.
Updates & Changes
Change is inevitable with this kind of system and it’s pretty easy to manage with a setup based around the Control Center add-on. Depending on the desired changes or updates, you may just need to go into a template sheet and fix something or adjust a setting in your Control Center Blueprint (any updated sheets also need a quick refresh in the Blueprint too). I’ve also added on new sheet templates and new sheets to aggregate data for Dashboards to existing Control Center Blueprints and that’s not difficult either. I’ve found the Blueprint to be pretty flexible and reliable in managing change over time.
This is a good spot to point out a couple of Smartsheet’s admin features that are relevant to updates and changes. The Groups feature I covered in my previousarticles is a good way to set up an admin Group. That admin Group should be the only Group with write access to the folder containing your Control Center sheet templates. Another part of Control Center is that it has its own super complex sheet (don’t worry, you’ll never need to do anything with it) that should be in this same restricted admin folder. Your aggregator sheets also go here. It’s a good idea to keep a subfolder of old drafts or abandoned sheets in this same spot.
What Else Can Architects Do with Smartsheet?
I’ve mentioned that Design Criteria is a part of the Development Hub I created in Smartsheet, and that’s a topic I’ll be writing about in more detail soon. But know that Smartsheet is an outstanding tool for architects to organize and disseminate a chain concept’s Design Criteria, or even their own firm’s standards.
I’ve recently begun experimenting with taking data roundtrip between Smartsheet and my BIM authoring tool, ARCHICAD. I’ve found a process for this that I’ll write about soon. This is an area of Smartsheet that has big potential for architects though — imagine coordinating data in the BIM with a vendor online via Smartsheet, and using Smartsheet’s push notifications for calls to action in managing updates between the data in the sheet and the data in the BIM — cool!
Final Thoughts
I ❤️ Smartsheet! This tool has huge potential as architects enter the age of information-driven design. I think Smartsheet’s blank canvas approach is something that architects in particular will embrace. Everything I’ve covered in this series could be replicated for firms wanting more control over the management of all of their work or for organizing office standards. Smartsheet’s great licensing model means that it’s also a value-added service that architects can provide their clients, like giving them a Dashboard to check in on their project’s progress. I hope you feel inspired to give Smartsheet a try!
After I wrote this and built the chart below, it occurred to me that one could simply file a dummy permit application way before the real one needs to be filed and then wait for the AHJ to come back and explain everything wrong — a rough-shot yet surefire way to get it right once it’s time for the real deal! 😩
As I’ve mentionedinpreviousarticles, thoroughly researching permitting requirements is vitally important to the success of any project — not just that, but doing the research in the very beginning when you’d rather just get on with the design. Everyone in the architecture industry has a first time they hit the wall that is the building permit process, and they usually hit that wall while attempting to do their research, or when they first file that permit application.
Everyone I’ve ever taught permitting research to goes through the same motions of hitting that wall and saying it can’t be done, no one knows anything and no one will help them. This is when I tell them that’s correct, you’re actually doing it right! Welcome to dealing with a government agency! With these frustrations in mind, I thought I would chart the building permit process, perhaps this will be a handy guide for your next building permit shitshow adventure with your local AHJ (authority having jurisdiction).
PS I would be remiss if I didn’t also mention that there are some really great jurisdictional authorities out there that do an outstanding job of preparing the people who prepare the permit applications, I just wish there were a lot more of them.
This series covers how architecture professionals managing the rollout of multiple locations at a time for chain concepts can manage that process through Smartsheet, the web-based tool based on internet-connected spreadsheets.
In Part 1 we reviewed why I like Smartsheet as a tool for tracking project delivery for chain concepts doing rollout development, and we saw the basics of what I’ve built. Here in Part 2, we’ll take a close look at the various trackers and Dashboards that power this Development Hub.
Development Hub Dashboard
This is the heart of the beast: an outward-facing Dashboard that gets used by the organization’s C suite and other departments/teams outside of the real estate, architecture, and construction professionals on the development team. The Development Hub Dashboard aggregates all of the data from all of the other trackers we’ll look at here in Part 2.
Before we look at all of the things in the Dashboard an important concept to understand about Smartsheet is that its Dashboards are like scrapbook pages for other sheets’ data. With the Control Center plugin we discussed in Part 1, a feature you get is the ability to have a sheet aggregate data from columns in other sheets that you specify. That aggregated data can then become a Report that gets pasted into the Dashboard and live updates. The Reported data is focused and abbreviated for the intended audience, which in our case are busy executives that want to see that shit’s getting built on time and on budget. With that in mind, let’s take a look at this big, centralized Dashboard…
Sample Development Hub Dashboard
Trackers
Next, we’ll look at all the various tracking sheets that our Control Center Blueprint (explained in Part 1) spins up for us when it’s time to start a new project.
Schedule Tracker
This is the main tracking sheet. Smartsheet can automatically create Gantt charts and has you use a special sheet template to start them. This is the sheet template that was used to create our Schedule Tracker, which in turn becomes a template in our Control Center Blueprint. This is important to mention because Smartsheet’s Gantt chart sheets have the built in ability to recognize predecessors (in columns) as you assign them, which lets you connect milestones (in rows) to each other, something that has obvious benefits for scheduling project delivery. Let’s take a look…
Sample Schedule Tracker
Budget Tracker
You’ve got to track both time and money, so the Budget Tracker follows the money for us. The planning for this sheet requires coordination and buy-in from the organization’s accounting folks, as the goal here is to report on budget relative to schedule. Smartsheet has APIs that could be useful in connecting the budget numbers to accounting software, though I haven’t gone there yet with my work. There’s a whole conversation to be had during the planning stage as to how many line items you want to follow and how you want to track it all in Smartsheet. This Budget Tracker captures the original budget established by the development team and then compares it to the running total once the project goes live. Here’s a look…
Sample Budget Tracker
Vendor Trackers
Every chain has vendors they work with to supply fixtures, furnishings, equipment, and finishes to their construction sites. All of these vendors need to be able to forecast orders from the chain and receive live updates on delivery dates, so this tracker uses links to the Schedule Tracker discussed earlier to do its work. Smartsheet has the ability to push notify users of changes to sheets, and we use that feature here to send an email update to any vendor whose delivery dates have changed. It’s important to note that there are multiple versions of this tracker tailored to each vendor and I use Smartsheet’s Groups feature to grant read access for each vendor to the appropriate tracker. A typical vendor tracker looks like this…
Vendor Tracker Sample
Project Assessment Summary
This sheet is used during the Project Planning phase at the beginning of new projects to capture any issues or concerns identified from the regulatory and premises assessments. It also becomes the place where follow up on those issues or concerns to make sure they all get addressed. Like the Vendor Tracker, I use push notifications to send out requests for follow up action to the appropriate team members. Here’s the setup for this sheet…
Project Summary Image
File Organizer
The File Organizer’s name says it all. As Smartsheet allows you to attach files to rows in sheets and even to version track them, I leverage that feature to provide a place to organize the deliverables and other documents that the organization needs to collect and archive for each project like so…
File Organizer Sample
Inspections & Licenses Tracker
This tracker performs two functions. First, it establishes a list of all the inspections and licenses a project requires (so it’s customized from the template for each specific project), and then it reports on the status of those inspections and licenses. As with some of the other trackers and sheets, we can push notify team members any time an issue pops up that needs special attention.
Inspections & Licenses Tracker Sample
Franchisee Project Dashboard
When a project is franchisee-owned, this Dashboard aggregates data from the sheets discussed above to produce a concise high-level view of the project’s development details for the franchisee. The Dashboard is organized like this…
Project Dashboard Sample
Setting Up Who Sees What
Smartsheet’s Groups allow admins to create groups of users and set their read/write privileges. I create Groups for each department in the organization as well as for the contacts at each consultant and vendor firm. These Groups get assigned access to all the sheets one time in the Control Center Blueprint so that as new projects get spun up, the appropriate people are already connected to them, plus you can tweak those assignments on a project by project basis if needed. Each franchisee is a Group too.
Other Parts of Development Hub
Smartsheet’s Dashboards can also provide links to other sheets, and I use this feature to provide links to development-related resources that other departments in the organization might need. It all ends up being very specific to the organization in terms of content.
One piece that becomes a resource for every organization is the Design Criteria. I’ll be writing a more detailed article another time about disseminating Design Criteria through Smartsheet, but for now, know that all of the stuff I wrote about here a few years back gets organized and distributed through Smartsheet and linked back on the Development Hub Dashboard, among other places. These resources are shown in the Development Hub Dashboard image near the top of the article.
Coming Up in Part 3
Next time, we’ll wrap up our look at Smartsheet as a development tracking tool. We’ll discuss how the building of all this works and look at what else I use Smartsheet for.
As certain generations embrace algorithmic design for pre-BIM ideation, for certain other generations the handoff of a quick floor plan sketch created by a senior-level staffer or principal to a production person for headlining is a long-standing architectural tradition. I’ve experimented with a modern take on this important sketch-based task to facilitate BIM workflows.
In an earlier article, I explained that I’m fine with either approach to early design work, but if you sketch, at least make sure you do it digitally — however, even sketching with pen and paper will still work with the guide I’m introducing in this article, it’s just…clunkier.
I came up with this workflow, which I refer to as Building Information Sketching, after seeing enthusiastic production staff get hung up on the Z-axis of the BIM while the designer was only working on the X-Y plane. None of that Z-axis was a concern in the CAD days, and it’s a good thing that it’s an issue today, because it makes us better designers. It all made me want to feed the production staff information for building the BIM that was relevant to the kind of data input the BIM authoring tool was looking for and still make that quick and easy for me to do. Of course there are workarounds for that production person aside from anything we cover here, but that often leads to a mess to clean up in the BIM at a less than ideal time during a later phase of project delivery. So why not embrace The BIM Curve when doing pre-BIM design? Let’s do this. Here’s how…
The Workflow
BIM authoring tools want you to tell them all sorts of details about walls when you are laying out a floor plan, so the designer can provide some guidance on walls via simple wall section sketches — not too much is needed here if you don’t want. For exterior walls, just give thickness, height, and if you’re designing elevations at this time, any information on relief in the exterior face of the wall is helpful. For interior walls, I’ll just provide a height to start with and leave it at that.
For multi-story buildings, you can provide a simple, diagrammatic wall section to explain the story heights or annotate them on each floor plan.
Doors, windows/storefront/curtain walls, fixtures, furnishings, and equipment are handled by letting the production person know which elements from the BIM template you want them to use. If there’s not a good fit in the library, then just let them know the basic parameters so they can place something, they’ll know what to use based on the parameters you specify. This requires the designer to know the content of the BIM template, which can be done by printing out the choices and their names for the paper-centric types or by giving them a PDF to reference if they’re a more digital designer. Having concise naming for BIM elements in the template is important to this workflow to make things fast for the designer.
If the designer is doing exterior elevation sketches, not much changes from what they’re probably used to providing the production staff as long as the designer is providing the wall section sketches noted above.
If you’re the designer about to do a sketch, and you’re in a time crunch and feeling the pressure, don’t be tempted to just sketch the floor plan. Resist temptation and get yourself into a habit of at least providing the diagrammatic wall section sketch(es) too. It really isn’t more than an additional couple minutes of time to get done, and it makes for a big time efficiency improvement on the BIM side of things.
Here’s what that BIM-aware sketch might look like…
This quick sketch captures enough to inform the production staff of design intent and BIM construction — it comes together quick!
You Just Made a Building Information Sketch!
That’s all there is to it! Nothing too difficult here, but it makes a big difference to the production staff in setting up their BIM for success as the project moves forward. Go forth and foster love between design and production staff.
This series covers how architecture professionals managing the rollout of multiple locations at a time for chain concepts can manage that process through Smartsheet, the web-based tool based on internet-connected spreadsheets.
Smartsheet is an amazingly powerful tool. It’s also intimidating because when you start using this spreadsheet-based SaaS, you begin with a literal blank page, which I love and find empowering, but I totally get that it might be a real turn off for some (they do provide templates and can build custom sheets for you too).
Before I learned about and started using Smartsheet, I worked in many other SaaS tools for management of chain rollout development. Every single one of those other solutions had the same shitty things that held them back:
They force you to fall in line with their own vision of management workflows. You redesign your processes to fit their workflows in order to make it work, and get mixed results.
They require someone behind the green curtain managing it all full time to make sure people input data so the machine has something to show in return, which never works well because it’s way too much data to wrangle that way.
The companies behind these other solutions never had enough capital to continually improve their UI and update it to comply with the latest web technologies, so they all end up looking and functioning like AOL circa 1996.
Because they come assembled, they have to have features for everyone and everything on by default — it’s too much clutter and too hard to make it go away. When you boil down what development teams actually want, it just ain’t that much.
Some are built on dated technology that doesn’t allow for use on mobile devices (or only extremely limited use), or on non-Windows computing platforms. Some are even browser specific, all of which is nuts in the 21st century.
We’ll be walking through what I’ve built using Smartsheet to manage rollout development for a restaurant chain that’s building both corporate-owned and franchisee-owned restaurants nationwide. As we do this, I don’t want this to become an overly technical article, so I’ll defer to Smartsheet for the really specific nitty gritty how-tos of using their software (another thing I like about Smartsheet is that they have great resources for learning to use their tools). To that point, here’s a great overview from Smartsheet of what their tools can do.
The Setup
The solution I’m reviewing here uses Smartsheet’s Business level plan with their Control Center add-on. Control Center is really amazing, it allows admins to create what Smartsheet calls Blueprints, which are really a set of spreadsheet templates that are pre-linked to each other as well as to other sheets designed to compile data from all of these templates once they get spun up into real projects. After you create a Blueprint, users can launch it to spin up new locations for the chain where they get fill-in-the-blank type screens for stuff like the city, state, building metrics, and so on — really as many inputs as you need for whatever you need, it’s totally customizable, and you can control what kinds of data go into each prompt to prevent people going off standard. From there, Control Center inputs that data into the templates (maintaining all the links) and organizes all of it into folders and sub-folders specific to the new location. User access/assignments and dashboard reporting are all automatically deployed at this time based on the templates you create as well. It really is magical and a huge time saver.
Smartsheet is accessed via web browsers and they have apps for mobile devices so you can get to your data from anywhere on any device, though complex edits are more cumbersome on mobile devices. You can also export your sheets as XLS and PDF files if needed. Backups can be automated to protect your data as well.
There are always going to be weirdo projects that have one-off needs within management systems like this, so another thing Smartsheet does really well is that it allows you to improvise on these kinds of projects by adding stuff or changing stuff within project folders, even altering links to Dashboards, all without breaking the well-oiled machine.
What I Built & What it Does
I named my creation Development Hub, as it tracks all development activity and then reports it out to Dashboards and sends push notifications out to project team members. I think the best way to explain how I make it all work is a mind map showing the connections, so here it goes…
What’s shown above is for corporate-owned projects, so there’s an additional layer to all of this to track development for franchisee-owned projects too, and that works like this…
What’s shown above is for corporate-owned projects. Franchisee-owned projects are tracked in much the same way, but everything above works behind the scenes from the franchisee’s point of view. A franchisee-specific Dashboard is generated from this data for them to see and interact with for their projects, which looks like this in the mind map…
One of the reasons that I like Smartsheet for this work so much is that its database works the same way a BIM database does in that you want to push information to the highest level in the database so that if that information changes (which it always does, right?) then you just change it in one place and it flows down through everything else in the database — no errors or omissions this way!
Up Next
In Part 2 we’ll take a close look at the trackers spun up for each individual project and see how the data in them informs the development process.
In 1932 Charles Ramsey and Harold Sleeper published the first edition of the Architectural Graphics Standards. A look through its pages shows that a lot of things haven’t changed much since then about how we use graphics to document design intent. I don’t think that’s necessarily a bad thing, but I also think that since the technology we use to create the designs and document them is completely different now, we should be making changes to our architectural graphics to leverage that technology.
The idea for a new set of guidelines around architectural graphics has been rolling around in my head for a while. I began altering my thinking on this topic when I started transforming the way I do my job with new software about 15 years ago. That new software made me rethink workflows first, which was challenging and made me question the wisdom of changing software in the first place, but it ultimately paid off when I could see that my work had gotten better from all of these changes. Once I was at that point, I started owning up to the idea the the way we graphically represented things could change too. Colleagues had a big influence on my thinking, and not just peers, but younger people with less experience had refreshing ideas and challenges to the graphics status quo too. Here, I’ll organize my own guidelines into The 21st Century Architects Graphics Manifesto.
Annotation
Using BIM properly means changing a lot of dated ways of documenting buildings. For the documentation and the graphical annotations that go with it, the priority needs to be on using BIM’s smart linkages and ability to intelligently recognize model elements as opposed to manually annotating things as we did with CAD and manual drafting. Rethink schedules. Rethink markers. Rethink noted call-outs. Rethink it all. Ask yourself: if it ain’t automated, then what do you need to do to make it automated? Whatever the answer to that question is what 21st century annotation looks like. And what it looks like is often different from how it was done in the past, and that’s just fine. Making these kinds of changes surprised me when it came to the resiliency of contractors and vendors, who took documentation that looked a lot different and ran with it successfully.
Lineweight & Hatching
This is another place where BIM causes a rethinking of the old ways. Software developers have improved their offerings and added features to automate lineweights, but for those trying to force CAD-based thinking onto BIM, those features won’t be enough. And when those same people are in charge, it sends the production staff into a tailspin of budget-breaking hours and QA lapses trying to get an elevation or something like that too look “just so.” There are questions to ask yourself with this topic too: since BIM expands our capabilities with regard to hatching and customizing linework display based upon specific views, how can that improve the reading of the drawn elements? This is a good time to review the lineweights you use and simplify them. I was surprised how much better the drawings looked than the CAD days with these kinds of changes — things appeared simpler, cleaner and easier to understand. If you want, save your complex lineweighting for details, which haven’t changed much since the CAD days in terms of drafting, but the automated BIM elements need the new set of rules and thinking.
Color
Color is very much connected to the points I made on lineweights and hatching. I’ve been slowly introducing color into my deliverables. Color has pretty much always been a part of my design phase deliverables, but now I’m starting to include it in CD phase deliverables too. I think color in CDs has huge potential and it doesn’t have to be over the top either. Just using some subdued hues in restrained ways within the documentation really helps the information pop. Think not just of coloring materials, but of color coding spaces or elements using highlighter-type colors to help explain design intent. Color schedules to make them easier to read, color call-outs to make them stand out, color code things instead of using call-outs to reduce clutter. Remember, with BIM, color can be automated too.
3D Representation
In the early days of BIM adoption (and sometimes even today) you’d see a drawing in a sheet or even a whole sheet dedicated to an isometric view of the BIM. No annotation or anything else, just that 3D view. Then and now it’s still common to see a perspective view of the BIM on a cover sheet as well. These are nice, but 3D views of the BIM can be so much more. When assembling CDs in the BIM era I’m always thinking about what in the documentation is easier and more clear to show in 3D instead of the usual orthographic views — and not just as an isometric either because sometimes a perspective view is helpful for conveying design intent in the CDs. Combine all of this with color as mentioned earlier and now you’ve really got some powerful documentation. Use all three dimensions of your BIM regularly in your CD deliverables.
Sketching (if applicable)
I’ve tried many apps and Linea Sketch is the best!
The design phase has quickly bifurcated into the algorithmic design and sketch design camps. They’re both fine by me. The algorithmic camp has tools to connect their design work directly into the BIM authoring tools though, and sketching doesn’t. This doesn’t mean we need to avoid sketching, I just think that we need to use different sketching tools now. All sketching should be done digitally with a stylus on a tablet. These digital tools bring new ways to iterate, new effects to explain ideas, and some even let hand drawing get translated into vector-based linework for importation into the BIM. Just having a native digital copy of the sketch that imports nicely even without vectors is helpful in turning sketches into models. Added bonus: no graphite or ink all over the edge of your hand (left-handers know the pain).
Modernizing the CDs
All of these efforts made me realize that a lot of the graphic standards I’d used for years were looking kind of dated in the digital world. This part of the manifesto is strictly personal preference, but I found it made a refreshing difference in the visual quality of deliverables. Specifically, I left behind any fonts or hatches that were skeuomorphic representations of hand drafting. Probably super controversial in some circles, but there’s no good reason to do either the old timey look or the modern look, so I’m going modern, just like the technology I used to make it. Logic!
I’ve saved the best for last! Imagine a world where all architects use a single set of standards for their architectural graphics and sheet layout. I know that’s a real stretch because very few things seem to divide us more than how shit should look on paper, but just imagine it for a second. Next, imagine all the amazing things that software developers could do if they could focus less on customization tools for their their users to infinitely tweak the appearance of something like a section marker and instead pour that energy into making a single section marker that was super intelligent and feature-packed. Imagine that same kind of change for all the other stuff that we all do slightly differently from each other, but mostly the same. Next, imagine spending less time training new staff since everyone everywhere uses the same standards — also think about the quality of everyone’s work improving because the standards are a constant rather than a confusing moving target from firm to firm.
Does this imagination exercise help you become less clingy to your special and unique and clearly-the-best-in-your-opinion way of doing architectural graphics? No? Okay. Fine. You probably hate this whole article anyway. 😤 Neeeeext!
“We are kept from our goal not by obstacles but by a clear path to a lesser goal.”
Robert Brault
It’s time to wrap up our look at Precision Development Scheduling…
In Part 1 we looked at how different members of the project team view development schedules and how those views inform their priorities and, in turn, inform the outcomes for the project.
In Part 2 we broke down Precision Development Scheduling to see how it works and why it’s successful at reduce both the time it takes to deliver a project and the overall spend in getting to that completed project.
In Part 3 we put Precision Development Scheduling up against a client’s DIY approach on a specific building typology (a restaurant) to see how it saves time and money.
👇🏻 This is Super Important!
The key takeaway I would want everyone to learn from the workflows behind Precision Development Scheduling is that you have to move through all of the high-level phases every single time and you have go through those phases in order every single time. Any deviation from this process will cause problems, and the severity of the problems is connected to how early in the schedule the deviation(s) occurred. We saw this over and over in every example of a development schedule that wasn’t a Precision Development Schedule.
As we discussed in Part 2, those early phases of project delivery are the most important, if not the most glamorous, and maybe that’s why so many architects stray from the process. We’re wired to be thinking about the design and solving that problem (i.e. drawing and iterating and all that sexy architect-y stuff), which is vitally important, for sure — but if you don’t do the tough grunt work to make sure you understand the path from the idea in the client’s mind to built reality, you haven’t fully designed the project, even if you have a pretty building drawing that everyone is in love with and excited about.
Embrace Being the Generalist of the Project Team
No one else on the project team — no one — understands as much about everybody’s roles and the connection of those roles to the process of making an idea into reality than the architect. Embrace being the generalist of the project team and take control using Precision Development Scheduling. Resist it when members of the team want to rush into a different phase or skip over some milestones — hell, resist it when you want to do that too!
For me it helps to remember that all of the phases of project delivery are an opportunity to design something, even if it isn’t a building or space, and there’s real joy to be found in just designing solutions in general.
This is the ALL CAPS edition of the A to Z. Enjoy!
A = Autodesk
The evil empire. The good news is that there are plenty of resistance cells you can join if you have a virtuous heart.
B = BIM
The Information in Building Information Modeling will set you free.
C = CAD
This is an unnecessary and outdated technology thanks to B.
D = Disto
Hey, if you don’t have the budget to laser scan, then you have to laser distancemeter. You need M too.
E = Excel
Excel, and spreadsheets in general (I’m big on Smartsheet now), have massive potential for helping architects parse out the Information in their BIMs.
F = F**k!
The most uttered word in the studio during crunch time.
G = GC
The good ones are truly invaluable members of the project team. 🙌🏻
H = HSWs
The grind for these never ends, does it?
I = Internet
Because of the internet, we don’t need S anymore.
J = Jargon
Jargon, archispeak, call it whatever. Don’t be that architect.
K = Koh-I-Noor mechanical pencils
My go-to writing device these days is an Apple Pencil, but come on, Koh-I-Noors were the best back in the day.
L = Lineweights
Embracing BIM will cause you to view these differently than you ever have before.
M = Mite-R-Gage
Used in conjunction with D when your project is too poor for laser scanning.
N = NIMBY
They’re fun to laugh at until they show up to a planning/zoning hearing for your project.
O = Omissions
Why do so many of us avoid putting workflows in place to stop these?
P = Pocket Ref
Technically, made obsolete by I, but I still love using this little book as a design resource.
Q = qc
As in heat loss calculations. Both qc = U(A)∆T and qc = U(A)24DD are seriously underrated tools for architects to inform early stage envelope design decisions.
R = RFI
If G is bad, you spend the entire CA budget shuffling these damn things across your desk and responding like, “actually this isn’t an RFI as defined under General Conditions” and saying F as you hit the send button.
S = Sweets Catalogs
You don’t need this 300-pound collection of hardcover books anymore because of I.
T = Technology
If you leverage it wisely and with great discipline it will reward you with another T, time.
U = Undo
The most important BIM command when trying out design options.
V = Value Engineering
The kind of “engineering” that makes architects hate engineering. Precision Development Scheduling can help avoid this kind of thing.
W = Water
No matter what form it’s in water will destroy your building, so you better detail things properly!
X = XREF
Whether it’s CAD or BIM, make sure you bind these damn things before sharing them with someone else — and only send the ones they really need.
Y = Yesterday
This is when the clients need those drawings.
Z = Z-Axis
Designing in this axis from the beginning of your project changes everything for the way the client understands your design and helps avoid so many headaches later on in the project.
In this series of articles about a subject that I consider vitally important to getting anything done (and done well) as an architect we’ll discuss the creating of a schedule for the development of your project. For our purposes, we’ll be focusing on development for small and medium private sector projects using design-bid-build project delivery* in the good ol’ US of A. Your specific experiences may vary with other project types, methods of project delivery, places around the globe, and how insane your project team is but generally the issues we deal with as architects in driving development scheduling are the same.
*We’ll have a couple examples of other types of project delivery in here too, but mostly design-bid-build delivery.
“Everybody has a plan, until they get punched in the face.”
Mike Tyson
There’s a barricaded storefront in my neighborhood that I walk by regularly. It’s been this way for months now, maybe even a year. Most days there’s little activity there. Someday, it will become a restaurant, which I know because the local media told me so — it’s a big story in the restaurant scene here as this restaurant will be from a popular, award-winning local chef. When you do what I do for a living, it’s especially painful to see a project like this moving at a glacial pace. Hold this thought…
For those following the restaurant industry, there’s been no shortage of reporting on the seismic shifts happening to it, such as: delivery trends robbing in-store sales, waning interest in fine dining, surplus capital causing too many restaurants, rising labor costs, et cetera. A couple of recent articles go into a ton of detail with their own takes of why things are changing (or need to change) in the business of restaurants here and here. I point out these two in particular because they sum up very complex social behaviors and economic factors impacting small operators’ restaurants especially well.
I can’t help but think about how all of this impacts architects who design restaurants — how we can help. While there are plenty of things to talk about with adapting the design of the restaurants to changing times, my thoughts and reactions to all this change first went to something a bit more technical, the development path they take from concept to grand opening, and of course now that we’re in Part 3, I thought of Precision Development Scheduling!
Two Divergent Paths
The way that big restaurant chains develop their hundreds (or thousands) of restaurants and the way that individual restauranteurs (including the small franchisees of the big chains) develop their one or two restaurants have long been diametrically opposed. The large operators have a team of professionals carefully planning and analyzing real estate, design, and construction all while cross-referencing their findings with each other and, more importantly, their organization’s financial analysts to make sure every part of the development pencils nicely in the pro forma to yield the desired ROI and earnings. Schedules and budgets are met or heads roll. Conversely, small operators opening a single restaurant will find their own way, reluctantly hiring consultants only after they’ve determined that there’s no other way through the regulatory process and/or construction obstacle they’ve encountered, and they do so in a manner that definitely prioritizes saving money over saving time. Both paths eventually lead to a restaurant opening, and while I’m a strong advocate for the formal development process we covered in Part 2 and the value that architects in particular bring, I long ago stopped arguing with small operators about their approach. I appreciate the financial limitations of opening a first restaurant on your own, and when you have so much personal capital on the line you want to be in total control of everything — that drives the DIY ethos of the small operator. I get it. But still, it could be so much faster and cheaper overall, and I think it needs to be due to the changing times and the immense challenges that confront restauranteurs trying to make a viable business. Unfortunately, the restaurant boom of the last decade has made the small operators even more determined to “just figure it out” and manage their development themselves and I think it’s costing them.
A Precision Restaurant Development schedule brings two big things to a project that the meandering DIY approach doesn’t get you: speed and a lower overall spend on the project. Getting your restaurant open faster has all sorts of obvious benefits, and spending less before you open helps preserve capital at a time when you need it to float the operations of your new eatery when customers are just starting to discover your new joint. This type of development can also help avoid or at least reduce (for those instances when your landlord drives a hard bargain) paying rent on a space that’s costing you money as a construction site rather than earning you money as a restaurant, a dreaded phenomenon known as dead rent. Here’s an example — a tale of two projects really:
We can see that time and money are flying out the window as stress levels go through the roof, much as we discussed in Part 1. It’s a damn mess.
Here, Precision Development Scheduling caps both time and money and provides planning of the entire development process from the beginning — a process that can be easily replicated for one-off development projects as covered in Part 2. We’re on a gravy train with biscuit wheels!
A lack of momentum can be deadly to a new concept trying to get open, and small operators definitely get that every day they’re not open costs them money. It takes a better understanding of the benefits of Precision Development Scheduling to appreciate that you should spend up front when things are cheap to save big later when things are crazy expensive, that’s a massively under appreciated big picture. It’s nothing to spend a couple grand on researching regulatory requirements and conditions of the premises then translating that research into a critical path plan for getting open as quickly as possible compared to losing tens of thousands of dollars on a surprise halting of a job site full of laborers for days and getting stuck with shipments of construction materials you can no longer use but still have to pay for (these two in particular happen ALL the time, but all sorts of things foul up construction). We’re talking a four-digit spend to prevent a five- or six-digit catastrophe. Rely on a great architect that practices Precision Development Scheduling to help you sort out real budget and schedule contingencies up front before you get started. Bring an experienced architect with you when shopping for land or tenant spaces, they’re your mechanic to look under the hood before you buy that used car. The cost of a person overseeing the planning of your restaurant and using their experience of having been through the process hundreds of times to drive performance easily pays for itself. We won’t even go into the better design outcomes you get from the pros, that’s a whole other article!
Small operators (especially the chef-led ones) are a stubborn lot and may not (actually, they probably definitely for sure won’t) buy any of this, but I would be remiss I didn’t bring it up given the current changes happening to this, my beloved industry.
Now What?
We’ll wrap up our thoughts on Precision Development Scheduling in Part 4. I bet you can’t wait!
On “The Brady Bunch” Mike Brady was an architect that worked for some unnamed firm where Mr. Phillips was his boss. In the show, we saw that the firm’s office had wood paneling typically reserved for basement rec rooms and Mr. Philips was doing pretty good, because he made enough dough to afford a boat big enough to accommodate at least 9 guests, or maybe less a boat and more like a yacht.
Here’s the other thing, though. Mike was bringing home the bacon too. He was the sole earner in a house with a wife, a live-in housekeeper, 6 kids, a dog, a sedan, and a station wagon. On top of all that, he could afford to take the whole group on vacation to tropical destinations like Hawaii. Mike was about 38 at the time, and probably had around 15 years of experience, a common milestone for transitioning into middle management at a firm (but still not using your boss’s first name apparently).
It’s a noble goal indeed for all architects to be making that kind of cheddar and that led me to think about Mike’s earnings in today’s dollars. I think of this exercise as a new way to quantify what architects should be paid if Hollywood were in charge of the payrolls at design firms, and a fun spreadsheet to dork out on as well. 🤓 We’ll confer upon Mike the title of Senior Project Manager and use that title as a point of reference for the ALL CAPS Mike Brady Architect Compensation Index™️.
I enjoy data analysis, and what I did for this one was quick and dirty, but that’s probably alright since if you were to precisely calculate for each variable in Mike’s enormous family enterprise it would take forever and be super boring number crunching (at least for me). So, with that in mind, here’s a summary of my approach. Let me know if you think there should be changes.
USDA’s 2015 analysis modified slightly, as they didn’t extrapolate to 6 children, but did find economies of scale when multiple children were in a family.
Full time live-in housekeeper
Used an average from Home Advisor’s cost range
Mortgage
Assumed 2,500 SF in LA County and used average price/SF in that area, then 80% LTV, 30-yr. term, 3.92% APR, 0.59% taxes, $2.2K insurance
Utilities
Used federal statisics on water electricity usage combined with LA County rates, added in typical costs for family phone plan, streaming services, and internet
Vehicles
Used full-size sedan and station wagon base model MSRPs, 80% LTV, 8% tax, 2.5% APR, 48-mo. term, $150/mo. ea. insurance
I suppose we could continue this exercise with other TV architects: On “Family Ties” Elyse Keaton’s earnings may reinforce our findings, but on “How I Met Your Mother” Ted Mosby would almost certainly throw off TV architect earnings as it seems like he didn’t make as much, though it was still probably way more than a sole proprietor architect/college professor would earn in their twenties. Maybe those can be future updates to this article. Should we look at annual updates to adjust for inflation too?
Does your Compensation fall short on this new index? Might be time for a heart to heart with your Mr. Phillips. Bring him a nautical gift when you meet to help butter him up for a tough talk, I hear he likes boating.
In this series of articles about a subject that I consider vitally important to getting anything done (and done well) as an architect we’ll discuss the creating of a schedule for the development of your project. For our purposes, we’ll be focusing on development for small and medium private sector projects using design-bid-build project delivery* in the good ol’ US of A. Your specific experiences may vary with other project types, methods of project delivery, places around the globe, and how insane your project team is but generally the issues we deal with as architects in driving development scheduling are the same.
*We’ll have a couple examples of other types of project delivery in here too, but mostly design-bid-build delivery.
“Do the difficult things when they are easy and do the great things while they are small. A journey of a thousand miles must begin with a single step.”
Lao Tzu
I love the development process. It’s deeply satisfying to plan out a project from its inception all the way to a completed building or space and check off milestones as you go. The planning of the development process is also a great place for architects to be the generalists that they are trained to be and pull together a disparate cast of characters on the project team. Let’s look at the basic road map I use.
With any development process my goal is to figure out the regulatory protocols and entitlements, integrate those with what I figure out about the site (and existing building, if the project isn’t ground-up construction), and then convert that knowledge into a critical path schedule. When doing this, I always keep in mind that the most important contribution I can make to the project team when scheduling is to set us up so that we’re making the big, cost-driving decisions early on when it’s cheap to decide on these things. Everything in design that goes unresolved past the Design Development phase costs more money, and the later it’s decided, the more it’s going to cost (more on this in a bit). The schedule can also then help inform the client’s spending by forecasting cash flow, among other things. I mention these budget tie-ins because schedules, like budgets, need contingency built into them, so the last thing I do when assembling a development schedule is add in time contingencies based on the team’s collective thoughts and risk tolerance.
Let’s take a look at an example of Precision Development Scheduling at a high level for a generic project, that’s the best way to explain the benefits and the places for an architect to provide big time value to the whole project team.
How It Works
Our bible for project delivery, which is what development schedules attempt to well…schedule, is the CSI Project Delivery Practice Guide, which provides a comprehensive overview of the process. I kinda pretty much use the same terminologies as this book in my work. What we’ll look at in this series of articles is the highest level steps, or phases, in project delivery, but know that proper Precision Development Scheduling should document every other smaller step, or milestone, within each of the phases, and those steps will often be very particular to the individual project. Here’s a quick summary of the top-level phases:
Preliminary Planning: This includes project conception, which unlike human conception, can be done with as little as one person, and site selection, which the architect may or may not be a part of — sometimes the client picks a site and then hires an architect and other consultants. There’s also some loose discussion of project budget at this time, and as with site selection it may happen with our without the architect, it all depends.
Project Planning: In our bible, Preliminary Planning activities are lumped in with Project Planning. But I separate these because my Project Planning phase is usually when the full project team comes on board and begins participating (kind of typical for small and medium projects). In this phase the project team conducts an assessment of the regulatory conditions that will impact the project, which is ultra important to the success of the project as a whole — I can’t emphasize this point enough. If you don’t thoroughly assess and investigate everything that can happen with the authorities who have jurisdiction over your project, you are going to have major pain and suffering later on from a budget and schedule perspective because codes and regulations aren’t something you can just skip past, you’ll deal with them one way or another or they’ll deal with you. This is also when you would conduct an assessment of the existing conditions, be it a site, a building, or both. The existing conditions assessment is the equivalent of having a mechanic look at a car before you buy it, which brings me to my next point. Do all this assessing stuff BEFORE the client executes a purchase agreement or lease agreement — or at least figure out the basics and big items if time doesn’t permit a full investigation prior to people signing their names and dropping cash. The other massively important activity to happen at this time is the programming of the building or space. It’s critical to completely program everything during Project Planning — things can evolve from the program a bit as the design gets sorted out in the next phase, but get the program settled now, and in sufficient detail before moving into the next phase.
Design Development: The phase most people think of when they imagine architects…architecting is Design Development. This is when the project is designed — but not just by the architect, but by the entire team, everyone has something to design right now to help everything run smoothly down the line. It’s also a time to weigh design decisions not only against the program, but against budget and schedule. For projects using something other than design-bid-build delivery, the construction team and their vendors can get involved now to help drive smart decision making with regard to budget and schedule (a construction advisor can help for other project delivery types). Projects where the local jurisdiction may have pre-permit entitlement processes for the project to go through will take care of that red tape during this phase as well. Negotiations with the construction team will start now for projects not doing design-bid-build delivery and continue through subsequent phases leading up to Construction Administration.
Construction Documentation: Only after the design receives a final approval from the client (and the jurisdiction where pre-permit entitlements are involved) do the architect and engineers prepare construction documents for the approved design. This is also a time to prepare permitting materials and bidding materials
Permitting, Bidding/Negotiation, Procurement:Permits get applied for and go through their plan review processes now. Bidding starts at some point as determined by the team during this phase as well. This is also a time for any procurement to occur for materials and equipment being paid for directly by the client (and/or the construction team for non-design-bid-build delivery).
Construction: Build, build build! And verify, verify, verify! If you did all the prior phases properly, that’s nearly all there is to Construction; and if you didn’t follow a process, this is where ungodly amounts of time and money get thrown away, people start yelling at each other, and you hate your life. It amazes me how many architects masochists who’ve been though development a zillion times before willingly subject themselves to this crap every time — fix your development scheduling, people!
Notice how there’s a lot more to explain in those early phases and that the explanations get shorter as you go? It’s not a coincidence. The early phases aren’t the work most people think of when they think of architects, but it’s the most important work of the project delivery cycle as they lay the groundwork for a success down the line. It’s those later phases that the big bucks get spent, so the more effort you spend preparing before you get there, the less likely you’ll be to waste money (more on that in part 3).
Now, bring the activities of these phases together with some rules about how to proceed through them in a linear manner and here’s all of those considerations turned into a Precision Development Schedule:
Baseline vs. Actual
What we looked at in the example above is how the baseline development schedule is made and how it works for the team. In addition to that, you’ll want to run a parallel development schedule that has live dates to show the actual progress. The baseline is frozen in time and the actual schedule is a living record. The two work together to provide you a picture of how the project’s development is progressing and allow the team to see when things are falling behind or running ahead of schedule. Formulas can be made from milestones identified in the baseline to drive future dates. For example, if a part of your development schedule baseline identified a regulatory process like a plan review that always takes 5-weeks to finish, your actual schedule can use a formula that adds 5-weeks to the actual start date you enter once your project hits that milestone and be further adjusted as you go, while the baseline stays put for a comparison.
How Schedule Drives Budget
As mentioned, the earlier that design decisions are made, vetted, and approved, the less it will cost overall. This means it’s vitally important to lock in design decisions BEFORE you start Construction Documents. When design continues past Design Development, it costs more money and takes more time (and time is also money). Yes, revisions are reality, but it’s important to follow a process for making revisions and, to the extent it’s possible, handle as many as possible before the project is bid. The lowest pricing you’ll ever get from a GC is when they’re competitively bidding your project. After they’re awarded the project there’s far less incentive for them to sharpen their pencils as they price revisions, so avoid doing that if you can and build the milestones of your Permitting, Bidding/Negotiation, Procurement phase to reflect this workflow — don’t stray from this path!
Automate This!
Just like you have a BIM template, you’ll want a template for building your development schedule. You can create this in whatever software you like, but you’re probably seeing from everything discussed so far that the ability to program formulas is a critical feature. Microsoft Project is a big player in this type of work, but on my projects my favorites for this work are Microsoft Excel and the web-based tool Smartsheet. I especially like how these two play nice with other software to connect the development schedule to other parts of the project. Smartsheet, in particular, is almost magical in its ability to automate scheduling and connect it to other parts of project delivery.
Another thing that can be done specifically for chain concepts who prototype and then rollout en masse is that the entirety of a development schedule with all the individual milestones can be templated in great detail. Specific projects can easily add or take away individual milestones, but all the hard work of mapping it out is already done once, and done well for repeated use.
Here’s an example of a chain concept’s project development schedule template set up in Smartsheet — all this complexity and even built in automations behind it were made once and then used repeatedly for each new project the chain built.
In this template excerpt, Smartsheet’s formula and linking capabilities were leveraged to make creating a baseline schedule and then updating the actual schedule as you go completely automated. This kind of automation is vitally important once a project team is in the midst of delivery on a project as it pushes out schedule changes that won’t happen for weeks or months now, as they’re impacted by current events. There is high-level tracking of phases along with individual milestone tracking that expands from under each phase. All of the milestones are linked out to other trackers in Smartsheet that drill down into even more detail for project team members who need that kind of reporting. This makes technology an invaluable resource in Precision Development Scheduling.
I’ll be writing about how to use Smartsheet for project delivery in more detail in future articles, so if you like what you see, there’s more content on the way.
Next Up…
In Part 3 we’ll look at a project-specfic example of Precision Development Scheduling in action and see how both time and money get spent when the client DIYs it versus when Precision Development Scheduling is used.
As ALL CAPS gets rolling I’ve been digging into my work journals for reminders on my past research. Going through a journal is a wormhole just like YouTube, Wikipedia, and everything else on the internet. I relive different times of my career when I read those old entries and I’d be lying if I said that it didn’t bring on all sorts of feels.
I started journaling my architecture career in 2013 and quickly realized that I wished I’d started much earlier. I remember I was motivated to journal from somebody at Harvard Business Review talking about how they journaled and how it helped them grow. I don’t remember the specific article or podcast, but they have a ton of good material on journaling that I still reference from time to time.
My journal setup is for weekly entries using a template for each entry because I figured out early on that’s what worked best for me. Both the template setup and the software I’ve used to journal (it’s always been a digital endeavor) have evolved over the years. It’s important to note that the template evolved because I wanted to evoke more thoughtful reflection from myself as I journaled. The software evolved strictly for convenience and functionality.
My current template has a heading where I enter the dates at the beginning and end of the week. Then three sections below that for my thoughts on the week:
Successes/Accomplishments
Failures/Things to Learn From
Experiences
Those sections are self-explanatory, except maybe Experiences. That section is where I get into my feelings on the first two sections and anything else salient that happened that week, good or bad. This is the therapeutic section of my journal. The first two sections are more practical reflections.
This is what my journal template looks like.
This effort started in a run-on text document because that was easy at a time when I just wanted to get it going. Then I divided that text into volumes by year and employer. Later the text moved to journaling apps. It’s all searchable to help quickly find specific topics or entries too.
Doing all this has undoubtedly made me a better architect, businessperson, and manager. Journaling has helped me improve my customer service skills and my technical skills by being open and honest with myself through writing, which is super difficult, but also very powerful.
Something else I found was that journaling using the format I describe here helped me immensely with the quality of my self-assessments during annual reviews with my past employers. Journals like this make it easy to remember everything you accomplished and what you need to work on improving. Before the journal it was really frustrating to try and remember a whole year’s worth of highlights (and lowlights).
ALL CAPS 