Project or Process?

September 15, 2008

I’m wrestling with a problem of which is more important, the project or the process.

At first glance the answer seems obvious; the project is most important because it is ostensibly why we are in business. Clients come to us (or we to them in the case of an RFP) and we help them realize their projects. If we stopped working on projects we’d stop getting clients and we’d all be out of a job. Certainly then the project is critically important.

So what of process? If all else is secondary to the project why bother working the process? Why not stick with what’s working? Certainly makes some sense, particularly when we focus on the immediacy of this project and the next. Who has time to bother with process when there are projects to complete?

The ugly truth is that your process is more important than your project.

I should clarify here that my use of the word process is in no small way a placeholder for something more than “a series of actions, changes, or functions bringing about a result”.  To my mind it includes just about everything we do that’s not directly related to the project.  Office culture, standards manuals, email policies, marketing tactics and company moto are all things that have just as much and more important than the project.  It’s what gives us whatever edge we may have in the market place… in addition to any awards we might have won as well of course.

Process is what allows us to grow and change with the evolving world and business climate around us.  If we continue to hold onto outdated processes and insist on working the same methods the market will bypass us and find other ways to achieve its goals.  The only way through this is to accept continual change and work on process.

So process is important too.  More important than the project because process is about growing the company, the industry and yourself.  The project is about a completion date and a set of expectations.  It has an end and an outcome that is focused on the now with little to say about what comes next.  Process is the next and the in-between and the before and the during.

Projects are what allow us to work on the process.



May 29, 2008

About a year ago I found a program for building performance analysis, Ecotect, and its sister website/wiki devoted to training and learning. Complicated program, at least for my ignorant dumb ass, but the wiki is great. My favorite part? The organization of the training based on a series of Levels of Achievements.

Beginning with simple viewing and navigating the application at level 1 and going all the way up to being innovative in the use of the program (essentially untrainable), the Level of Achievements they’ve implemented covers a lot of ground and gives clear signs to know where you are and how to get to where you want to go.

So what if we applied that same thinking to training Revit? Here’s what I came up with:

Level 1 – View

Sufficient skill level for Partners and non-technical Project Managers.

At this level you should be able to move around and through the model in order to acquire and print the information you need without going through another person.

This level focuses on View Tab in the Design Bar.

Specific skills include being able to; navigate through the Project Browser, create additional views to show you what you want (including Visibility Graphics and View Properties settings), and print views and sheets.

Level 2 – Assist

What first time users, resistant AutoCAD geeks, SketchUp kings, interns and more than a few designers I know need to be capable of.

At level 2 you should be able to help others on the project modify existing model content and add annotations. New object creation should be limited to what is specifically “redlined” and previously discussed with Producers and/or Managers. You should also be able to create sheets and place views and have a an understanding of how to create basic schedules.

This level focuses on Drafting and Room and Area Tabs in the Design Bar.

Level 3 – Produce

This is where the majority of work is done and, as such, Project Architects and some Managers may need to be at this level.

At this point you should be creating and modifing projects with all required model components as well as know how to create basic families in either 3D or 2D and create and edit more complex Schedules.

Level 4 – Manage

Here, the power users, the Revit geeks, the computer savvy Project Architects and those highly skilled in AutoCAD making the transition may soon find themselves.

Skills at this level include; creating and managing Design Options and Phasing, creating and managing parametric families that are both 3D and 2D with appropriate levels of detail, understanding the differences between modeling for Design Intent and Construction and how to move from one to the other during the design process, as well as being able to create and edit interrelated Schedules and Schedule Keys.

Level 5 – Innovate

Who knows. How do you define or describe innovation? I think you’ll know it when you see it.

So the question I want to pose is how far down (or up if you prefer) this list do you think is far enough?

I haven’t thought about how this would apply to AutoCAD though I’m confident that, while the specifics would change, the underlying structure and rationalization would stay the same. Nearly everyone I’ve ever worked with is a Level 3 and there are always technical problems that those of us who are Level 4s (and occasionally 5s) have to spend an inordinate amount of time to correct and resolve.

That’s not good enough. Not by a long shot.

Perhaps it would help to explain if I pointed out that the steps between these levels is not geometric, it’s exponential. Each step up the ladder is at least twice as complicated, requires at least twice as much effort and at least twice as much commitment than the one before. Getting to that Level 4 or 5 is not easy. Most people give up when they’ve got enough knowledge and skills to get the job done – about Level 3.

Level 3 is mediocre, average. Level 3 is a “C”. Not good enough.

When we first started using AutoCAD, it was an asset. We used it intelligently where it made sense and only the geeks took control of the computer. Now AutoCAD is a liability. The senior staff who were trained and practiced in creating documents by hand are constantly amazed at how long it takes to get drawings created and modified compared with what it took them when they were responsible for making the drawings.

We have a chance to learn from our mistakes with AuotCAD and keep Revit from turning into a liability. The first step is having the right people, the Level 4 and 5s, working the program. We have to keep mediocrity out of the process. The 4s and 5s cannot spend half their time fixing mistakes based on ignorance. Let the 4s and 5s go as far and as fast as they’re able. Keep them in the design process and feed them what they need to make things happen in Revit.

Let the 3s and 4s focus on something else that will benefit the project, the company, the industry and themselves. Let them focus on their own 4s and 5s instead of settling for a 3.

Everyone can be remarkable. Nobody has to settle for mediocrity.

Widget Cranking

April 16, 2008

We all know what it is. We sometimes call it being a CAD Monkey, drafter or some other, similar term to imply a task or series of tasks involving little brain work. A friend of mine recently suggested that perhaps the individual projects we work on are really another form of widget cranking. ZOINKS! I never thought of that way before but you know… I think she’s on to something!

What if we were to consider the idea that our real work, the work that makes a real difference to the company, to the industry, to ourselves and yeah, even our clients, isn’t the successful completion of a project? How would an industry-centric view of our careers change what we do from day-to-day? How would it change the widget cranking tasks we all occasionally loathe?

I think that the more widget cranking tasks you perform, the worse off everyone becomes. You get no pleasure, the company doesn’t grow and so, naturally, the industry stays put. But the project must move forward. After all, without the projects we’d have nothing to do! So we continue to make things. Specifically we continue to make drawings, and specifications, and models, and meeting notes, and renderings – all the stuff that’s need to get the project done. How does any of this help us beyond the short-term goal of getting the project done, out the door and built?

Our real work, the stuff that we should really be doing, the stuff that would make a real difference to our clients, to our offices, to our industry and most importantly to ourselves has little to do with the making of stuff to make other stuff. Our real work is design, insight, problem solving and marketing. How does focusing on the project accomplish these things for anything other than the successful completion of the project? We use them all within the framework of the project but what role do they have outside the project? If we only use them for projects then the project must be what is most important.

Is it?

If we were working on goods and services (widgets) that had a wide range of appeal or need, then using those talents to improve the quality of the widget would absolutely be the right thing. Those talents would help us make a better, more remarkable, widget which would in turn attract more people to our widget and all would be good and right with the world. But we are involved in a very different sort of business. Our industry, at least the public sector that I’m involved with, doesn’t rely on remarkability as a determining factor of success or failure. In fact I’ve seen the opposite. The more remarkable the Architecture the less likely it is to appeal to the groups of bureaucrats that make up the majority of the selection committee. Remarkable Architecture, the sort that catches your attention and invites you to engage with it and remark on it (whether the comments are positive or negative isn’t the point right now) scares the hell out of bureaucrats. They’d much rather create a building that didn’t even attempt to challenge or engage anyone lest they meet them at their next public meeting. Better to play it safe than risk annoying members of the community.

The problem is that the Request for [Blank] system that is required in public work doesn’t reward or even acknowledge remarkability. It is political. It is designed to find the average, the easy, the cheap. It is the antithesis of the free market economy that we’re used to in other industries. The middle, the average, the safe is no longer appealing to the masses in the way it once was. We either want the very best we can afford if we care about and are passionate enough to search it out, or we want the cheapest thing that will get us by until something else comes along. Take a look at how you decide to purchase goods and services. The research you do to find the best product that meets your individual and specific needs for the goods and services you care about. The comparison shopping you might do to find the lowest price for the rest. Which one of these sound most like the typical public work procurement process we’ve all grown to despise?

If you were in charge and were passionate about having the best Architecture you could find, how would you approach the process? How would you find the right Architect for you? Would you put a notice in the newspaper and weed out the obviously undesirable in order to interview the remaining and choose from among them, a process not unlike comparison shopping between Target, Wal-Mart, Best Buy, and Amazon? Or would you look around at the very best, most remarkable buildings, find out who designed them and then start a conversation, a process more akin to searching out the small, independent shops in your area and online for the exceptional products and services?

If we continue to focus on the project, the widget, then we’re destined to be a participant of the public process for the remainder of our careers. And, if we’re lucky, we might find success.

On the other hand, if we think of the project as a means to another end perhaps we can start thinking about how to use our design, insight, problem solving and marketing skills in different ways. To promote our industry, to educate the interested and uninformed about what we have to offer, to find new markets.

Efficient Drawings

March 3, 2008

A few weeks ago we were talking in the office about how much wasted effort is involved in doing our work. I wasn’t sure the Powers-That-Be were really getting what we were talking about and I knew that the over-drafters wouldn’t follow the discussion well either (if they could, would they still be drafting for the sake of drafting?) so I decided to run a test on a drawing that I knew was overdone.

The original drawing contained nearly 2,000 objects. After thinking it through a bit and re-creating it (I traced over an Xref to make my job easier) I got it down to about 200 objects… just 10 percent of the original. I printed it out and showed it around and everyone started to understand even if they’re not sure yet how to get there.

I made a PowerPoint out of the example for grins and posted it up over at slideshare as part of a brief exploration of that site. I also embedded it below.

I am continually amazed at the potential of the internet to make connections. In the short time it’s been on the site it’s been viewed over 30 times and downloaded once. Not big numbers to be sure and some of them are likely people I’m working with but not all. It’s amazing that with so little effort you can start to influence people you have never and likely would never meet.

Think about what would be possible if you tried.

Off topic rant… sorry ’bout that.

If you’re going to use a 2D CAD program to create drawings I think it’s important to look backwards to when drawings were produced by hand with pencil and pen. The width of the pencil lead or pen tip was a determining factor in the level of detail you could place in a drawing. As was the understanding of how long it would take you to erase and recreate the work should it change.

A parapet, for example, in a building section at 1/8″ = 1′-0″ might be nothing more than a 3 lines. In a 3/4″ wall section you might add a bit more information (enough to suggest the metal parapet cap). And you weren’t likely to see much more detail than this until you got down into the 1 1/2″ = 1′-0″ details. Changes to the detail usually didn’t necessitate changes to the building or wall sections thus making these changes was quick and easy.

One common method of using CAD is to place as much detail as possible into the building or wall sections and to simply zoom into them for the details. Sounds reasonable and is certainly easy to initially implement; after all, once the parapet is drafted in the first section it’s simple to copy the section to use a start for other drawings. A lot of ink is placed on the sheets in a short period of time and gives the illusion of work and thought. But what happens when the parapet detail needs to be changed under this methodology?

Well, if you’re going to do it correctly you need to find each of these sections that were copied from the original and make the appropriate change to each of them. What took the pencil drafter an hour or so might take the CAD operator an entire day… or more!

We need to get better at managing change. If our processes don’t acknowledge and allow for change easily then we are not managing change, the change is managing us.


February 18, 2008

Laura Handler, author of bim(x), posted a comment on the idea of an IDEO like practice in Architecture. Her suggestion of bringing in other design/construction disciplines into the process earlier forced me to examine my initial negative reaction to the idea.

Intellectually I think including these people on the team is important. Emotionally I cringe at the idea.


I think a lot of it has to do with semantics and my experiences with the consultants I’ve worked with on previous projects.

I remember clearly when I first realized my consultants and I weren’t speaking the same language. I asked a Mechanical Systems Engineer to Design the HVAC system for a building we were working on together. It was coming up on our Schematic Design Submittal so we needed something that would be helpful in furthering the conversation. What I was getting wasn’t what I was hoping for – too much text, too vague, dependent upon too many assumptions. When I pressed for more they responded by metaphorically throwing up their hands in dismay; did I really expect them to design a system in schematic design? Well yeah, of course. What I came to realize was that when I was saying Design they were hearing what I would have meant by Engineer. Once we understood the distinction, that all I needed was a simple one-line diagram with approximate sizes of ducts and units, they were able to produce what was needed for the submittal.

So, Design isn’t Design to everyone. To some, Design is Innovation; to others it’s Engineering. If we’re talking about Design as Innovation then, is it helpful to include those who think in terms of Engineering? My gut tells me no. Oddly, if the conversation is about Design as Engineering then I absolutely do think that the Innovators should be included… I’d go so far as to say they HAVE to be there.

I don’t like the term Engineering here… it’s too loaded. Maybe it’s enough to use right brain, left brain thinking. Certainly gets me out of the hot-seat with my consultants! <grin>

There is danger, I think, in bringing in left brain thinking into the process too early. During the earliest parts of the Design process, left brain thinkers supply the wrong sort of input and typically play Devil’s Advocate during the process (and I don’t think he/she/it needs any help).

Tom Kelley says it well in his book The Ten Faces of Innovation;

“What’s truly astonishing is how much punch is packed into that simple phrase. In fact, the Devil’s Advocate may be the biggest innovation killer in America today.

…innovation is the lifeblood of all organizations, and the Devil’s Advocate is toxic to [its] cause.”

So my knee-jerk negativity then stems from too much of this. Too much negativity. Too many instances of “yeah, but…”

I’ve known a few left brainers who can hang out with and challenge the right brainers. They’re few and far between and worth anything they ask. If these are the type of people Laura wants to include then that sounds like a fantastic team… one I can’t wait to join.


February 7, 2008

Does it seem to anyone else that Architecture is full of Ego? I’m not talking about the egoism that you might have from being great at what you do… no, I’m talking about the know-it-all egoism that surrounds me. Nobody wants to ask for help. Nobody wants to try new things. Nobody wants to admit what they don’t know.

I’ll go first. I’m not a Designer. There… I said it… again.

I also don’t know much about contracts or specifications and I’m really not the guy you want in front of your clients (I tend to say what’s on my mind more than might be appropriate sometimes). I’m also not the guy you want making your presentations or your graphic materials or your renderings. I know a thing or two about codes though… and I think I know how to put a building together (I tend to give the contractor a lot more credit than many in our profession). If there was one thing I am better at than almost anyone I know it’s how to use AutoCAD, ADT and Revit (though less of the first two than the last lately)… and I know a fair bit about a lot of the other digital tools we might use.

Of course I too have an ego… and not just about the tools. I know a little about a lot of subjects in the field… enough to know when someone else professing to know is wrong. Does that mean I’m a know-it-all too? Maybe some would see it that way… I know those-who-think-they-know-but-don’t think I am.

What’s critical is that we acknowledge the ideas and skills of others. Even if we might have more years in the profession than they, we need to hear them out and see what else they might be bringing to the conversation. If we start the conversation with the assumption that we’re right and they’re wrong we’re doomed.

So maybe Ego’s not the problem… maybe it’s rampant closed-mindedness.

What if we started every conversation with the assumption that the person we’re talking to might be right and we might be wrong? Just for the span of this discussion of course… let’s not get carried away! What’s the worst that could happen?

Macro vs. Micro

February 4, 2008

Where do we focus our design efforts? Why is it that Architecture seems to so often exist only at the Macro?

We spend an awful lot of time working out and worrying over what are little more than massing studies in the design process. Weeks, even months, may be spent on tweaks that most people outside of the design process would likely consider to be pretty darn subtle. I have to wonder if the effort really matches the results…

I know I didn’t always think this way. At my last firm we teamed with a local designer on a community center for Maryvale, Arizona. First time I saw the project on paper I was unimpressed… two shiny metal boxes sitting on top of glass walls. I didn’t get it. And then I did. I went there with a friend of mine, Jenell Bass, who worked on the interiors and my eyes where opened. The attention to detail and subtlety of the design at the human scale was really impressive. My favorite move was how the exterior walls around the basketball court leaned out slightly in order to prevent glare from interrupting your view into the space. Brilliant!

What I now believe was that the decision to simplify the Macro allowed them to focus on the Micro.

I have seen some of this level of thinking in the traditional Macro-focused designs of course. The Designers I’ve worked with typically bring this level of thinking late in the design process. I guess this is okay… if you’re talented enough to have been considering these issues during the earlier phases of the design. And if you’re working under a traditional Design-Bid-Build contract then, as long as it’s in the documents at the end of the bid, you’re fine.

It’s in this newer Construction Manager at Risk (CMaR) contracting type we’re seeing a lot of lately where the problems with this late entry method start to show up.

If the CMaR is working with you as the contract method intends they are providing you with pricing and construction alternates during the design phase… and they can only price what they can see in the documents (or possibly read in a design narrative). If we don’t have something in the project specifically described the CMaR can only assume that we’re not concerned about its design or construction and will price whatever method they think is appropriate. And when we don’t describe and document the Micro of our designs until the end of the project the CMaR, caught off guard and unaware, has no choice but to add cost to the project (likely on the edge of being over-budget anyway) and then we’re left with a big mess and a lot of redesign to get the project back in budget.

The move towards Revit and BIM only seems to shed more light on this problem… though it could and should just as easily be the solution.

Instead of seeing Revit and BIM as an opportunity to play at the Macro level more, confident in the ability to produce the bulk of the documentation in short order, we should use the extra time to start focusing on the Micro sooner and more thoroughly. The shape of the building is not nearly as important as we Architects would like it to be… at least not to our clients and ultimate users of the project. They’re more concerned about that finer level of coordination and detailing that we routinely push off until later.

If we can trust our initial design impulses at the Macro we can use Revit and BIM to allow us more time to focus on the Micro.