“Cost of doing business”

Writing blog posts about design technology leadership
continues the discussions from previous Summits. One of the topics often brought up is that of how other firms estimate the cost of BIM above and beyond what the firm usually delivers. Where does the line fall between the “cost of doing business” and “additional services”, and how much of this answer is dependent on the client?
Rather than provide answers that aren’t necessarily relevant to your firm or in your local, I open this thread to your input. Email the [email protected] and I’ll add it here.

Translating Technology

In doing research for his recent book, Jay Conger identified one particular set of talents that resonated with me, that of “technology translation”.  It’s the ability to absorb large amounts of data, discern its essence, understand different perspectives and stakeholders, and come up with a simple, strong message that’s tailored properly to the intended audience.


Jay’s example centered around software companies and their customers – namely, that there might be some feature changes that would impact enterprise customers.  A technology translator would bee able to understand those changes, and find the most salient points and build explanations for different audiences:  the software company CEO, the board, the marketing heads, and so on.


I’ve found these skills especially useful in our line of work too.  Technology can mean many things to many people, and how I’d explain something to a firm’s partner could be pretty different than how I’d explain it to a first-year graduate.  Design-minded folks will respond differently than technically-minded ones, Construction Admin experts will have different needs than interior designers and urban planners.  Engineers will find yet a different set of priorities to focus on.  You get the picture.


How have you been able to use these techniques to your advantage?  Have there been times when you’ve found the messages more convergent?  And some that are less convergent?  Have you found some principles to be ‘universal’, or do they always depend on the audience? I’d love to hear your thoughts, hopefully at DTS this summer.  Please apply to join the conversation!


Image Copyright © glasslewis.com


The Future of Automation: How far should we go?

Automation seems to be all around us, from the everyday ATMs, to the evolving self-driving cars, but the question remains: just because we can automate, should we?


We all would love to find that extra hour in our days—whether it be at work or at home, the allure of finding a way to make a repetitive task automatic is definitely attractive. Automating tasks essential to healthy living—brushing teeth, taking medication, homework (though that would take some doing) would be a big step toward a healthy, happy, productive life. We do not think about most of these tasks, we just get up and do them, but trying to mechanically automate such personal experiences does not seem practical. So how do we start automating a design process that engages everyone at an individual level?


The design process starts with the program, or the idea of a space is where design begins. In this phase, we, as designers, evaluate, analyze, anticipate every ounce of data we can gather to try and predict the needs that will arise tomorrow, ten, fifteen, even 20 years in the future. With sensors being an evolving product, the ability to automate the gathering of space usage information could be the next exciting starting point for automation.


After programming phase is complete, this is where automation could continue to benefit the design team. Computational design has given us the ability to twist, turn, push or pull so many variations, before running analysis on each to determine the most desired option. Where is the architect’s influence? Have we taken the pen out of their hands?


Now the design has been determined and documentation must take place, or does it? The idea of “modeling more and documenting less” was a point that stuck with me as I left the 2017 DTS conference, and now a year later, still sticks with me.  Modeling becomes the new documenting and by adding the data into the spaces, we could start to allow technology to produce model components based on desired specifications.


Can we automate the process of producing documents for compliance in the different jurisdictions? 


Can we automate the process to go from design, straight to construction robotics?


We can automate and most of us agree we should, but how do we humanize automation and how does it integrate coherently with the designers?


Despite all those questions and their answers, automation was the beginning of an industrial revolution and could be the tool to transform the construction industry as we move towards a better delivery method as designers.

Using the Past for the Present and Future: DTS Position Statements

Without further adieu we present our position statements as a result of our DTS 2017 discussions. 


Over the past twenty five years, the architecture, engineering and design professions have changed significantly.  Demands are greater.  Deliverables are more detailed.  Timelines are shorter.  There are increasing numbers of specialists involved in our projects, adding to the complexity of a deeper level of coordination, and requiring familiarity with a wider range of subject matter.   


Historically, technology has assisted us incrementally with these challenges, but, as the pace of change increases, so must our willingness to evolve how we work, and the pace at which we do so. 


We believe the AEC industry is poised for modernization.  The pressures and expectations placed on firms have reached a critical threshold.  Technology has successfully assisted other parties in the AECO team, and it has the capacity to assist us as well, in significant ways.    


As practitioners and technologists, we have often been the ones called on to help our organizations find opportunities to modernize.  DTS brings us together to share our experiences and knowledge, and identify opportunities to improve.  It is from this background- and in this spirit – that we offer five areas of consideration that can positively impact practice:  


Lightweight Interfaces 
Our future employees and even the youngest generation in practice now are acclimated to touch based, intuitive interfaces and applications that are generally geared to specific tasks or functions. These modern tools and user experiences must also be prepared to be used with display and interaction technology which only today is being explored, researched and experimented with. 


Full Adoption of Model Based Workflows 
The elimination of traditional documentation or processes (ie drawing based delivery and quantification) will not come overnight nor; do we expect that it will be easy. We do believe that there are many avenues that design and technology companies can increasingly explore that can help the industry move in the direction of a true model based design, delivery and construction workflow. 


 Knowledge Capture, Management & Dissemination Platform 
While there are a variety of platforms available for knowledge management we have yet to see the development of something that easily captures latent knowledge and provides useful, contextual information. While “web” technologies have streamlined access to information and knowledge, and videos make it easier to disseminate and consume, the reality is that knowledge capture and dissemination is still rooted in the same techniques that were used to write manuscripts and books. In the same way that more people are becoming comfortable with the concept of an AI assistant at home like Alexa or Google Assistant we need similar learning assistants in our workplaces. Intelligent assistants that can learn our routines and ingest our design and business data to provide useful feedback will be the next major shift in how knowledge is captured and managed. 


Technology for improved quality of life (of designers and end users) 
Often times it is easy for all of us, including technology companies, to focus on improving workflow and information exchange; while pains may be taken to ensure the user interface and experience are improved, those advancements do not necessarily translate to improvements in the users’ quality of life. We advocate greater emphasis on improving day-to-day experiences, either directly through a tool, or as a result of it. 


Application Behavior/Performance 
Design applications must provide fluid and dynamic performance for our end users. This includes taking advantage of advancements in processing power– for example, multi-threaded, multi-core Central Processing Units and Graphical Processing Units. And as mobile technologies become increasingly pervasive in the office and on the job-site, cloud storage and processing options should be at a minimum as reliable and robust as local or server based storage. 


If any of these statements resonate with you and you would like to be a part of the discussion, please register your interest in the event to be approved to attend! We can’t wait to see you there.

In with the old and out with the new?

Some of you George Harrison, Beatles, and PBS fans might know that PBS has been rebroadcasting the 2002 “Concert For George” recently.   Led by Eric Clapton, it served as a celebration of George’s life and music, and was held one year after his death.  I may be a bit biased, but I recommend watching it.  He was great, and the concert is great too.   


I’m inclined to look at everyone’s instruments and playing styles during every live performance I watch.  While watching this one, I paid particular attention to Clapton’s guitar, and, as guitar players are wont to do, paid particular attention to his pickups.  For those who aren’t intimately familiar with how guitars work, pickups “pick up” and convert the physical vibration of strings into an electric signal that gets amplified through amplifiers, signal processors, recording consoles, and the like.  Basically, they convert a vibrating string into an electric signal that can be sent through a cable.  


What I noticed in particular was that after using some high tech “noiseless” pickups for some time, Clapton had switched back to seemingly “low tech” vintage-style pickups.  I wondered why, after all these years, why Clapton would have gone from a “superior” solution to an “inferior” one.  Perhaps Clapton simply preferred the sound of the old pickups, flaws and all.  I was reminded of a recent quote from the CEO of Gibson guitars:  “[The industry is] stuck in a time warp, and the ‘purists’ have a very loud voice…”.    


When it comes to guitars, I’m one of those “low tech”players.  Most of my guitars are old.  I’ve had them for a long time, and I don’t see any need to replace them with newer ones.  And I like that they offer a window into another time and place, before I was alive.  It’s a way to keep some level of perspective on what and how I play.  


I can’t help but draw comparisons to the sometimes-dire forecasts of architecture firms, and how the industry must update our technological strategies if we want to stay relevant.  Yet many firms prefer to stay “old-school”.  Are their motivations similar to those of Clapton’s?  Does efficiency matter?  If so, in what way, and how is it defined?  Where and how can we begin to distinguish an old guitar from old design software, and when might we be able to learn from what came before, and apply lessons to today’s practice?


Is this the sort of conversation you’d be interested in joining? If so, please submit your Expressions of Interest for this year’s Design Technology Summit. Registrations open the 21st of March. The sooner you apply, the sooner you can be approved, and participate in what I think will be a very insightful event.