Semantics

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.

Why?

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.


Ego?

February 7, 2008

That last post got me thinking – it isn’t really what I was trying to say. My head is still buzzing about the subject (a sure sign I’m leaving stuff out). Then it hit me… I wasn’t writing a post about other people’s egos I was writing a post about my ego! <shock-horror-shock>

It’s probably documented somewhere in some study done by some university or another how much people disdain change but I like to pretend that study was never done. I like to believe that all people need is convincing of the brilliance of a new idea, strategy or process. And when they don’t see the light I, like many I suspect, become a wee bit frustrated at it all.

Thing is… nobody cares about what you think is so damn important and hopping up and down all day screaming about it (metaphorically of course) isn’t going to change that.

It’s a hard thing to remember and harder still to do something about. I know intellectually that, to succeed, you have to find products for your customers instead of customers for your products (or in Architecture speak… ideas for your clients instead of clients for your ideas). You have to know what they want and need and work to find ways to give it to them. Sometimes I think they know what they’re looking for… most of the time they don’t. They’re happy in their ignorance.

I have what I am sure is a tremendous idea about how we could start to change the process. How we could produce better work and be more fulfilled in our careers. Only do what you absolutely want to do… outsource or hire for the rest. You love designing? Great… go design… leave the contracts, documentation and specification writing to someone else. Spending less time on these other areas that you’re not as interested in (read: not passionate about, not focused on, not good at) will allow you to spend more time working on what you are interested in (read: passionate about, focused on, good at).

It may be hard to believe that there are others out there that want, really want, to do what you don’t. It may be difficult to find them and they may occasionally be a little more expensive than you’re prepared for. It may hard to believe but this is exactly what you need to do today to have success. Look to other industries and companies for guidance… Apple doesn’t build their computers… and Toyota doesn’t make the parts in their cars… someone else does. What makes these companies remarkable is their ideas not the work they do or the things they make (okay… so maybe that last bit is a little off cause they do sell things we buy… but they don’t make them, that’s the point).

So if I can’t get this idea across to my compatriots it’s my fault for not trying hard enough… not working at the sell. Maybe I should outsource the grunt work behind my idea? Maybe I should take my own advice… nah…. <jk>


Ego

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.


Revit Experience

February 3, 2008

Revit is essentially a database and as a fellow Revitter has written, “you can’t accidentally create a database”.

I’m afraid that there is very little anyone can do to “save” a project in Revit. Just today I had a virgin user ask me how to remove the Level tags from a View… was it okay to delete them? Luckily for me he asked… if he had deleted them the project would have been screwed and there would have been almost nothing I could do to fix the problem (short of recreate a large portion of the model).

The only way that I can be confident this sort of mistake doesn’t happen is to have a certain level of confidence in those working in the model. I think we’ve all seen and experienced how this can negatively impact a project in AutoCAD… not imagine that multiplied 10 times.

One ignorant user (and I use that word without malice) can absolutely ruin a project to the point where little, if anything, can be done. How someone obtains the experience necessary to know what to do and what not to do is another question… my personal opinion is that they gain that experience someplace other than on the project.