Tag Archives: architecture

June 15, 2015 · 5:47 pm

The Future of AEC

Teaching the second year undergraduate construction sequence of courses is challenging.

Students, already smitten with studio, see required tech courses as unnecessary evils.

They have had so few architecture courses at that point, it’s like teaching students how to put a car together before teaching them how to drive.

While the courses serve as a wake-up call that there’s more to architecture than the making of form, not everyone is happy about it.

So, how best to spark and engender a lifelong love affair with building technology?

One model is mutual mentoring.

In this model, emulated from practice, senior team members (TAs, the course instructor) work with emerging professionals (students) on building technology, while the emerging digital natives (students again) share what they discover in their digital models.

In a perfect world, this is how things would work.

Due in part to the 2008 economic downturn, when many senior firm members were let go, this model doesn’t materialize as often as one might expect.

In class, I play the surrogate seasoned firm member – the technology principal – teaching my students building technology in lecture.

Ideally, students incorporate what they learn in lecture in the lab section of the class.

The teaching assistants redline their work, the students pick up redlines, and in doing so some facsimile of the office workflow is recreated.

The problem with this model is that there is no evidence that students – let along emerging professionals – always understand what the redlines mean.

So, this past semester, I tried an experiment.

What if students learned building technology at the same time that they learned to work in BIM?

What if, in other words, these two activities occurred simultaneously?

The convergence of building technology and digital technology

Each student was provided with a set of architectural and structural CAD documents to work from.

By the end of the semester, over 100 students, mostly sophomores no older than 19 years old, each completed a 30pp set of BIM documents of a 16-story high-rise under construction near campus – a student apartment building with duplex units.

This was no drafting exercise in construction documentation: students had to think, and make critical decisions, every step of the way.

The course’s fabulous teaching assistants offered in-class tutorials, and Lynda.com was made available to students.

Revit Architecture was offered free to students from Autodesk’s education community.

By the end of the semester, our students

  • compared/contrasted the CAD documents with those produced from their BIM models;
  • visited the construction site, met with the architect and contractors, wrote a field observation report and compared as-built conditions to their BIM model;
  • redesigned portions of the façade; they redesigned the tower’s units;
  • learned how to collaborate in BIM, create BIM standards and families, and how to leverage BIM as a searchable database.

Most importantly, they demonstrated that they learned how to put a large-scaled, complex building together as they were still learning the digital technology, bridging the lecture/lab divide along the way.

Did students really need to produce 28-30 sheets of documents to demonstrate that they learned how to put a building together?

If they were drafting in pencil or in CAD, then the answer would be “no.”

But with BIM, the question is irrelevant, because the documents are merely snapshots of the model, slicing it this way or that.

This in itself was a revelation for many students.

As the instructor, my motivation in conducting this experiment was

  • To teach students how to put a large, complex building together
  • To help them to learn from each other
  • To help them recognize the benefits of just-in-time learning
  • To encourage them to ask questions
  • To have them understand how BIM differs from other tools
  • To have them create a set of BIM documents

As demonstrated in their work, students learned

  • the difference between BIM and CAD tools
  • that BIM is not just a super-charged version of SketchUp
  • that in BIM, unlike CAD, a wall knows it’s a wall
  • that you must know what wall type you are modeling and why
  • that a change in one place is a change everywhere
  • that the model it is a searchable, mineable database
  • that the higher uses of BIM are where the spoils are
  • that you cannot fake it in BIM the way you can in other tools
  • BIM standards and the value of clear communication
  • that they are capable of accomplishing a lot in a short period of time

What about collaboration? Why didn’t students work on teams? Teamwork is critically important, starting in school. But in terms of learning the fundamentals early in their architectural education, I felt it was important to assess each student individually.

Doing so teaches students self-sufficiency so that teamwork and collaboration becomes a strategic choice, not a crutch to lean on due to a perceived weakness in one area or the other.

The ultimate goal is collaboration.

The general wisdom goes something like this: due to increasing complexity of buildings, no one person can possibly know it all.

Or can they?

With this experiment, I decided to find out.

5 Comments

Filed under Uncategorized

Tagged as , , , , , , ,

January 30, 2014 · 10:53 am

Too Complex and Fast? Slow Down, But Don’t Oversimplify


To lead our collaborative future, architects need to decentralize or risk being further marginalized.

Architects know that they need to collaborate to succeed. But how will they go about doing it? How, in other words, will they make collaboration happen? As importantly, how will architects make the changes necessary to become not only more collaborative, but leaders of this effort, amidst disruptive change?

AEC leaders already do a great deal to encourage collaboration amongst their teams, providing vision, collaboration-conducive work environments, collaboration technology, and by removing obstacles – including themselves –when necessary, gladly getting out of everyone’s way. They encourage diversity, discussion – even disagreements – as a basis for moving the project forward. By telling their collaboration stories, leaders paint a picture of what collaboration looks like when it is done well. Most importantly, AEC leaders make sure every team member is making the same project. But AEC leaders cannot assure this happens in every meeting on every project. Who, then, on the team will lead the day-to-day collaboration challenge?

Barriers to Collaboration

We know collaboration is hard and takes time — to build relationships, to clear-up misunderstandings, to listen and to get things done. Past experience can hold teams back, and one of the barriers to collaboration remains organizational silos.

Brand erosion is also an impediment to collaboration. For a designer whose singular voice is her expression through her work, collaboration is equated with joint authorship, to some the antithesis of creative expression, muddying the message of the work, dispersing and diluting the voice and design intent of the creator. This thinking is of course mistaken, as leaders need to make clear. One only needs to compare a Beatles tune with any of the band member’s solo efforts to recognize that teams make better decisions – and importantly, results – than individuals. The real fear in collaborating is that we – and our work – will be mediocre, a race toward the lowest common denominator, and with it, irrelevance: we will be seen as just one more designer among designers.

The truth, of course, is by not collaborating architects become marginalized. Not knowing how to effectively collaborate will lead to their irrelevance.

Complexity and Speed

Of the trends impacting our new world of work – including digital tools, collaborative work processes with attendant blurring of roles and responsibilities, working remotely and together earlier – two trends have made all the others a necessity: complexity and speed. Our technology has an impact on the anticipated speed of decision-making. When still hand-drafting, while facing a construction-related question or dilemma, architects would say: We’ll work it out in the field. This was the architect’s go-to VIF: where the contractor on the architect’s behalf would be expected to Verify In Field. Later, working in CAD, architects would say: We’ll work it out in shop drawings. With little bim: We’ll work it out in CDs. And today, with social BIM, We need to work it out NOW!

In the face of increased project speed, we will be tempted to slow down. And we are well advised to do so. Studies show to make decisions that stick, we’re better off delaying choices for as long as practically possible. According to Frank Partnoy in Wait: The Art and Science of Delay, the best professionals understand how long they have available to make a decision, and then, given that time frame, they wait as long as they possibly can: “we are hard-wired to react quickly. Yet we are often better off resisting both biology and technology.” Since our current technology and integrated work process does not accommodate our waiting – in fact, it discourages it – leaders need to make it safe for their teams to make assured, unrushed decisions.

Likewise, despite construction being wickedly complicated, we should not be tempted to oversimplify. We need to take the complex and make it seem simple – without oversimplifying – resisting the temptation to treat a complex task as simpler than it is, potentially leading to oversights and mistakes.

Decentralize or be Marginalized

Architects continue to see themselves as central to decision-making, whether at the top of the project pyramid or a prominent point of the team triangle. Contracts notwithstanding, architects are not the point. For collaboration to work, architects need to get off the pyramid and go wherever and whenever they are needed.

Decentralization implies the transfer of authority from central to local offshoots who represent the firm and serve as its public face, whether as project manager, project architect or project designer – sometimes any two, or all three. These offshoots – like starfish arms – contain the complete DNA and trust of the organization.

Although collaboration requires the architect to decentralize, it has to start at the top, where firm leaders entrust employees to lead teams. What will it take for architects to decentralize? Successful collaboration requires facilitative leadership. For the architect to take on this role, they must play the part of process facilitators over content creators, becoming in essence co-creators. When each teammate contributes as a co-creator, no single person has to carry the load, including the leader. Decentralization allows architects to join the project – and be immediately effective – midstream. Ideally, the architect is called in before the owner even considers undertaking a building project, but the reality is – due in no small part to their own making – the architect is often called upon when the project is already well underway.

Given the collaborative nature of today’s project teams, consideration needs to be given to the firm representative’s leadership and communication style. As proxy stand-ins for the firm, each team leader needs to be able to communicate effectively at all times, with all in the room. Architects’ often-unconscious communication habits will be increasingly scrutinized and decreasingly tolerated in these tight-knit groups. Architects, working more closely with others from every facet of practice, will need to become more familiar with their communication style, paying particular attention to the ability to adjust one’s style to those of others from other work cultures and walks of life.

FOCI: Multiple-centered – not centerless – leadership

Architects – seeing that others have helped narrow their options significantly – narrow them further by opting to see themselves as single purpose entities. One example of this is described in Victoria Beach’s salvo in the newly published 15th edition of the Architect’s Handbook of Professional Practice where she asks architects to see themselves more as design-focused celebrity chefs and less as engineers assuring the health, safety and welfare of the public. For architects, it’s a both/and, not either/or, proposition.

In fact, architects in the coming years will be needed less as content providers of design intent than as facilitators, orchestrators, collaborators and integrators (or FOCI) of this information and process. Architects will have an opportunity to lead this process if they can learn to become better listeners, aggregators and refiners of the information that arises during the various stages of design and construction.

With the blurring of roles brought about by working collaboratively on integrated teams, the architect’s job is to keep decisions – often multiple decisions – in play. Collaboration and digital practice require a formwork on which to base multi-faceted decisions on increasingly complex projects. One such formwork is that of the rubric FOCI: in lieu of a singular central focus of the center, think of the multiple centers of the ellipse. A redefinition of decision-making that takes digital technology and collaboration into consideration creates such a formwork that will help the architect to communicate effectively with multi-disciplinary teams. To move from a circular to an elliptical model, the architect needs to decentralize.

To decentralize, architects also need to move away from the spotlight where they are the central focus. Many architects are introverts and would gladly succumb the spotlight to others. Architects don’t need to be the loudest one in the room to lead, just the one who listens best. To accomplish this, architects need to focus less, and FOCI more, by serving as project facilitators, orchestrators, collaborators and integrators. By decentralizing, the architect is no longer decision-maker so much as facilitator of project information and decision-making process. As facilitative leaders, architects can become experts in knowing how to find information as opposed to what the information is. When collaborating, it is not about how much any one person happens to know: projects today are too complex for any one person to know everything. Knowing from whom – and where – on the team to find information is more important than one’s ability to store and retrieve it. Architects will also serve as strategic orchestrators of large teams from the earliest stages, often made up with primary, secondary and even tertiary players. The C in FOCI is in flux: the C can represent collaborators or creators or controllers or coordinators. Architects, of course, are component and system integrators.

…

This post is an excerpt from Randy Deutsch’s article How We Can Make Collaboration Work: How architects can decentralize rather than be marginalized in the Jan-Feb 2014 Trends issue of DesignIntelligence journal.

Read and visit DesignIntelligence.

2 Comments

Filed under collaboration, construction industry, design professionals, people, process

Tagged as , , , , , , , , , ,

July 19, 2012 · 8:08 am

7 Reasons to Attend the Symposium on Technology for Design and Construction


Following the overwhelming success and enthusiastic feedback from the 150 plus participants and dozen vendors in the 2011 event, the 2012 symposium will feature even more timely subjects in the industry and provide more opportunities for networking, knowledge-building, and exposure to cutting edge developments.

7 Great Reasons to Attend this Year’s Symposium:

Reason 1: The real advantage in attending an event like this is to enhance your understanding of the current and future role of technology in design, construction, and facilities management from industry experts and those working at the cutting edge of their fields.

Reason 2: Included in the program will be such topics as augmented reality, legal insights on Integrated Project Delivery, GSA’s approach to facility management and technology usage in heavy construction. The assembly of world-class speakers promises to challenge your imagination.  Check out the schedule and presentation abstracts.

Reason 3: AIA continuing education credits will be available. Attend all three days and earn up to a total of 16 CEUs.

Reason 4: Professional discount extended for those who register by Friday, July 20. Architecture, engineering, construction, and facilities management students attend for just $25! Find complete registration fees here

Reason 5: The primary focus of this year’s Symposium is to improve project efficiency by reducing costs, accelerating delivery, improving quality, minimizing risks, and leveraging resources. In the spirit of the event, the presentations will be quick, short, and more concentrated with plenty of time for interactive Q/A.

Reason 6: Location. Chicago, on Northwestern University’s downtown campus on Lake Michigan, near Michigan Avenue. Here’s a map and list of nearby hotels.

Reason 7: All conferences boast the chance to rub shoulders with colleagues in an informal setting. The Symposium affords attendees the rare opportunity to network with researchers, academics, practitioners, software and building developers, vendors, IT professionals and university students working in architecture, engineering, construction, and facilities management – as well as leaders in the industry.

Sponsored by the Northwestern University Master of Project Management Program http://www.mpm.northwestern.edu/, and the newly created Executive Management for Design and Construction program, the 2012 Symposium on Technology for Design and Construction will assemble design and construction researchers, academics, and practitioners to discuss the present state-of–the-art and the prospects for future advancements in this field.

Check out the Symposium brochure.

Detailed information about the Symposium is at www.techforconstruction.com or inquiries can be sent to me, Randy Deutsch, at randydeutsch@att.net.

One last thing: Northwestern University’s School of Engineering would greatly appreciate your mentioning this content-laden Symposium to your colleagues.

Thanks!

…

The facts: Symposium on Technology for Design and Construction

August 15-17, 2012

Northwestern University, School of Law

Thorne Auditorium

375 East Chicago Avenue, Chicago

www.techforconstruction.com

Again, if you have any questions, feel free to contact me, Randy Deutsch, via email randydeutsch@att.net

Leave a comment

Filed under Uncategorized

Tagged as , , , , , , , , , ,

March 15, 2010 · 11:38 am

My So-Called Parametric Life

This life has been a test. If this had been an actual life, you would have received instructions on where to go and what to do.                                                                                                         Angela in “My So-Called Life” 1994

Is it just me or has life gone totally parametric? Perhaps only a BIM evangelist, BIMhead or BIMaholic would propose BIM as a metaphor for life. (Guilty as charged.) So, what does it mean to live a parametric life?

It is not, of course, that you are a Revit model or are about to become one. While that is for some a distant possibility, your story – the one you are putting out there, not your life but your so-called life – has become a Revit model. Have you noticed?

Ask yourself this: At any time in your previous life (BB = Before BIM, AC = After CAD) did you ever dream in CAD? Those who used to work in CAD would recognize the scenario where you go home at the end of a long day at the monitor and dream in CAD – dreaming that you are living in a 2D drawing – in a CAD world.

Living a Parametric Life

I am not asking what it means to dream in BIM or what it means to have BIM dreams. To work so hard and for so long in BIM that we start dreaming in…3 dimensions? We already do that and have for millennia. Little more than wearing 3D glasses to bed.

But living in BIM? That’s something else altogether. Living in BIM is something that we’re only now getting around to doing. We find ourselves living in BIM

  • because in some ways we’re well ahead of the technology, processing information and anticipating next moves that leaves the software – however well-intentioned – in the dust.
  • because we recognize some of the amazing things the process accomplishes and we want to model the behavior in our own lives.
  • because we know in our bones that BIM is the future – we get it – and we want to be part and parcel of this future.

We’re told over and over that the software thinks just like us – architects, contractors, whoever. But most of us have discovered, some the hard way, that we have come, over time, to think like the software. Revit doesn’t think like us – we’re thinking like Revit. That’s living in BIM.

I offer these 14 Rules for Living In, Out and Around BIM not as failsafe rules we need to follow – but to bring to our attention things we’re already doing right, right now, and ought to build on as we move forward. In other words, behavior – not buildings – that we ought to be modeling.

14 Rules for Living In, Out and Around BIM

  • Be the interoperability you want to see. The old words don’t apply – learn the new vocabulary and make sure that everyone you speak with understands how you are using these terms. You want to be speaking the same language, make sure you are working on the same page. Until the time comes when models talk with each other, and software speaks fluidly with complete comprehension, take it upon yourself to make sure you are speaking the same language with those you work with, no matter their role on the team. How can we expect our software to be interoperable if we aren’t?
  • A change anywhere is a change everywhere. You get the concept: Work you do in one part impacts the others. Parametrics, of course, is a distinguishing quality of building information modeling (BIM.) As with bidirectional associativity, a change anywhere is a change everywhere. There’s no escaping it – a change made in one place – compartment, area, phase – of your life impacts all the other places of your life. So be careful about what you change – whether your work habits, the way you communicate or how you operate within the team. Whatever you change about yourself will have repercussions throughout. Being parametric implies you’re consistent, you stay on-story, and you’re building not just a model but a brand. No matter how they cut you, you’re the same through and through.
  • Your space-keeper and workaround is someone else’s obstruction. The choices and decisions we make must have integrity because they will be repeated everywhere. What’s worse, you will be judged by the integrity of your information. If you are awaiting information and need to plug something in just to keep the ball moving – notify the team – especially contractors who view missing data as roadblocks, no matter your good intentions or justification. And don’t make a habit of it. Your goal ought to be to see how long you can keep the plates spinning.
  • You can’t step into the same model twice. A model is more like a river than a thing. Your contribution to the building of the model has more to do with the communication of information than the rock-solid enclosure you consider your domain. We’re not designing objects or things (and never really were) – but flows, communicating information to others. The model you jump into and help out on today is not the same model you worked on yesterday – especially if you’re working on an integrated team. The more you can think in terms of systems and flows the better off you’ll be.
  • Run an internal clash detection of your team before starting on the project. Look for supportive personalities, learners, those who are passionate and excited to work, those who enjoy what they do and for whom working in BIM – and ideally on this particular project – was a choice. And weed out the devil’s advocates and other contrarians – unless the criticism is constructive, regularly leading to decisions and action, offering alternatives when one course is shot down.
  • Consistency is king. Aim for an inherent consistency to everything you do. Take LOD. Make sure your team knows what level of detail (LOD) you are modeling to. That each part of the model has the same level of detail. Think of detail in terms of levels – as in levels of detail – that are built upon. A conceptual model ought to have conceptual level of detail throughout the model. Same with a model used for energy analysis, for quantity take-offs and estimating, for fabrication. And so on. Like roughing out a sketch – you start with the basic shapes, then you fill in detail, until the image is fleshed out. So too with the consistency of the information you impart. If you are job hunting – don’t, under your “Reading on Amazon” widget – have the 4-Hour Work Week as your recommended book. It undermines your message. Use LinkedIn’s book section to reinforce your message or let others know what you’re reading – but stay on-message. That goes for your work both in the model and on your team. Don’t say one thing and do another. That’s so CAD.
  • What you see is what you get. Your model is only as good as the information that you put in it. Garbage in, garbage out. There’s no hiding anymore. So be real. There’s no faking it either– who we are and what we do are expected to be real, so be real. Hemingway had what he called a built-in bullshit detector. All the best writers have this. You need to develop or acquire this talent for yourself. And be aware that those working but upstream and downstream from you have their turned up on high.
  • Decisions are consequences. We’re no longer designing objects or things, but courses of action. Our decisions impact others – we need to be aware of the consequences for our courses of action on every facet of  the team and process. Look at every decision you make in terms of whom it impacts both upstream and downstream.
  • While you model the building, model your behavior. Think of each team and project you are on as an opportunity to put in an exemplary performance. You are serving as a role model for others whether you are aware of it or not. And as with raising kids, your behavior – the way you act and perform – is worth 10X the impact of your words.
  • Perform an expectation audit. How you see the model/what you do might be different from how others see it – ask them how they plan on using the model – then try as best you can to accommodate them. Ask the contractor early on how they plan on using the model, what level of detail they would like to see in the model, then try to accommodate them. If money is an issue, discuss being compensated or remunerated with the owner.
  • Play well with others even if your software doesn’t. Another way of saying get in the habit of behaving as though the software does what you want it to do – because the time will come, soon – when it will. You want to be ready for when the day arrives. Better the technology plays catch-up, not you.
  • Your model doesn’t limit itself to 3D. Why should you? Don’t limit yourself to 3 dimensions. What about a 4D you and a 5D you? If you are doing your job and even doing it well you might be selling yourself sort – by a dimension or two. Look for ways you can be contributing beyond your title and role. Because when you work on an integrated team, you are more – much more – than these labels. Yes, you need to perform and do the work that has been assigned to you, your teammates are relying on you for this. Your model isn’t limited to 3D – nor are you. What would the 4D version of yourself look like? But the true value of working collaboratively is the way you keep others – and their focus – in your peripheral vision – just of your own cone of focus. Look for ways to cut time – and save money – for others, and be prepared to make these suggestions before the subjects come up. Always keep an eye on the horizon – and the topic of the next team meeting.
  • Ask yourself: If I was the model what else would I do? What else can I provide that others may need? Your original intention for your model may have been to use the model for one thing – but what if you also used it for a rendering? For an animation? As a database to run energy applications? Similarly – ask yourself: what else can you do or provide that others may need? How else can you push the envelope on yourself in terms of what you can add in the way of value at this time, for these team members, on this project?
  • Are you leveraging the technology of your team? Look around you – at those seated at the table. Do they have certain skillsets, experience or resources that you could leverage to help you to meet and even surpass your goals? You leverage the deep capability of the software and virtual model – why not leverage these same attributes and qualities in those you count on every day to come through for you?

Your turn: Can you think of Rules for Living In, Out and Around BIM that are missing here, that you might add or rules you see that clash with this model?

7 Comments

Filed under BIM, BIM expert, collaboration, modeling, process, workflow

Tagged as , , , , , , , , , , , ,