October Meeting

Attendees: Dave Bleiman, Mario Guttman, Bruce Madsen, Marla Ushijima

The group was really stoked after the presentation last month from Doug Childs on Lean Design, so we continued the topic in our informal discussion this month.

We all agreed that Lean faces resistance from the design community, which generally views it as a manufacturing-focused methodology. Marla proposes that the specialized terminology of Lean can be off-putting to those adverse to Lean Design, but that the specific words aren't critical to following Lean principles. Those principles are in line with generally-accepted best business practices—listen to what the client wants, don't waste time on activities that don't advance those goals, and learn from past experience—so if project managers jettison the terminology they can still advance Lean principles and tools on a project basis. Mario feels that the ritual derived from more overt implementation is important for organizational implementation.

We discussed dangers of ritual as well, and the difference between theoretical and actual benefits. We likened it to LEED certification, which can sometimes lead to an emphasis on getting points rather than effective sustainability. Dave questioned the appropriateness of the new Google headquarters' LEED Platinum rating, Mario questioned the slavish reliance on photometrics and Ecotect analysis vs. innovative approaches to getting effective lighting. Dave pointed out the irony of daylighting when shades are positioned to prevent glare but left in that position indefinitely by occupants who then turn on the lights.

How does Lean benefit an organization? Design professions are all about getting the work, doing the work, and getting paid for the work. Lean is mostly about doing the work. Its value in getting the work—marketing—is debatable. Bruce questions whether clients care whether or not you're using Lean; Mario questions whether a firm should try to sell Lean to a client or just let attitudes and performance speak for itself. He suggests that using Lean Design shows a serious commitment to QA, which could be of value in marketing. Added client value and potential marketing opportunities could be a selling point for management buy-in, which Bruce feels is critical for follow-through on whole-office implementation. Dave says that competitive advantage speaks volumes, and compares it to the implementation of BIM. As a demonstration, Mario suggested choosing the most disliked process in the office—such as doing dishes or processing reimbursables—and use a Lean process to improve it.

If internal opposition to Lean is expected, Marla suggests stealth implementation by a committed project manager on an individual project—to start small and demonstrate the value of Lean processes. Bruce and Dave agree that any change represents risk to an organization, so a pilot project must be used for evaluation before spreading it to the broader organization.

Dave is hopeful that Lean would reduce the need  for staff to stay late for a crush at deadline time, through more effective project planning. As an aside, Mario praised sheet lists as remaining of value in the BIM process to identify, plan, and track the work effort. We all agreed that knowing when to NOT do something is the right thing to do—such as when there's insufficient information to proceed effectively. Dave points out that the creative instinct sometimes fights against such efficiency.

Marla asked Dave about PopIcon for Architecture, which is apparently in its beta 3 version. Dave says they're facing a conundrum because they've made the library folder structure rigid to prevent mistakes, but the lack of flexibility creates a problem for architects. Dave is concerned that if they provide more flexibility, PopIcon would become a scapegoat for the resulting user errors. He asked for additional feedback from the beta users.

Mario brought up library management issues with BIM. Perkins+Will has a well-defined nomenclature for family file names, but the folder structure is more difficult to police. Mario thinks it's important for family creators to take ownership of their families and is promoting a structure in which folder names indicate the author, software version, and the unit type (imperial vs. metric). Bruce commented that the person at HOK who was responsible for creating their library of custom content was laid off as an expendable overhead cost. The result is a well-crafted collection of families being overtaken by content created ad-hoc by various designers. Bruce is concerned that the legacy standards—which are really good—will degrade over time.

We discussed the idea of using Omniclass vs. folder structure to classify families and tie them into e-spec. Mario notes that currently specs are typically based on prototypes; Omniclass tends to be either too obvious or too obscure and the middle ground is too small for value. Marla suggested polling our Linked In group to see who's using e-specs.

Bruce asked whether Lean is anathema to design? Architects are typically not interested in "process." Marla points out that certain tasks in the design professions are amenable to process improvement, others not so much. Bruce mentioned "optioneering," a methodology to systematically explore a large number of design options using parametric design tools. Mario pointed out that staffing realities can mess with a balanced work flow. Bruce wonders if Lean can shorten the timeline of a project; Mario wonders whether it can improve accuracy.

Bruce asked us how many manufacturers we think are providing Revit-specific content. Mario guessed twenty are making good content, plus about 500 others. Bruce said there are over a thousand.

Mario says he's developed a batch processor for in-house use at Perkins+Will to create 3D and plan previews, drawn from defined views within the BIM file. Marla asked whether parameters are included in the preview information; Mario doesn't see that as a high priority, and thinks a notes field would be of more value. He wonders whether he could mine the parameters in a family to populate a notes field.

There are several industry events coming up: Arcadia and Greenbuild will both be held in San Francisco, as will AIA|CC's Now • Next • Future conference. Autodesk will be in Las Vegas; both HOK and P+W will be sending speakers only.

Dave proposes a future meeting focusing on the Lean A3 document; he thinks it's really valuable. Marla would like to further examine the ties between Lean, BIM, and IPD. Bruce has a great interest in all the things required for successful BIM use that aren't part of the software package. He believes those things are a hundred times as expensive as the software itself. He has offered to host next month's meeting at HOK on the subject of BOB—BIM Outside the Box.

September Meeting

We had a great presentation on Lean Design from Douglas Childs of TAYLOR this morning. He has been kind enough to allow us to post the slides from his presentation; you may find them here.

James McKenzie and Eric Davis of Swinerton generously hosted the presentation in their well-equipped conference room with stunning views!

And here are a summary and the supplemental notes I promised:

Attendees: Dave Bleiman, Annalise Chikhale, Doug Childs, Eric Davis, Mario Guttman, Will Henderson, Damon Hernandez, Bruce Madsen, Nancy McClure, Karen Thomas, Dan Tsui, Marla Ushijima, Andrew Wolfram

Step 1 - Identify value
Doug started his presentation with demonstrating the first step of Lean processes, by asking the goals of his customers (each person present), and identifying the value they hoped to derive from attending the meeting.

He then explained the premise of What Lean Is and Isn't. Lean originated in Japan by Toyota as an approach to manufacturing excellence, but can be advantageously applied to any kind of process. It is commonly equated with miscellaneous tools such as Last Planner, A3, Six Sigma, Value Stream Mapping and the construction industry specific of IPD. None of these define Lean, but rather can be used to facilitate Lean processes.

Lean is a way of thinking and management targeted at maximizing value to a customer through continually improving processes.

2. Map the Value Stream
After identifying the value as defined by the customer (whosever needs are being addressed by a process, whether a client, building department, boss, etc,), the second step is to map the value stream, which is that set of all actions required to bring a product or process from concept to finished product. The purpose is to analyze the value of each step in the process, and to eliminate all steps which don't add value as defined by the customer. In Lean terminology, this step addresses the concept of the Japanese word muda, or superfluousness, a waste of time and effort.


3. Create Flow
In order to demonstrate the concept of flow, Doug had us do an exercise using the example of inventorying a bag of miscellaneous items.

We split into smaller groups with the purpose of each group individually taking inventory, and seeing how long it took for all groups to complete their separate inventories. The first method was for each group to execute a large chunk of work - to inventory all the objects - and then pass on the objects to the next group, who then did all of their work, and so forth. This resulted in each group having a short period of activity, and long periods of waiting for other groups to execute their tasks. We then tried a process of the first group inventorying a small number of objects and then passing them on to the next group so they could get started while the first group proceeded with successive small sets of objects, passing them on in small chunks. This method resulted in a much more efficient ratio of waiting time to active time, and a much shorter overall time.

4. Establish Pull

The first method was an example of traditional "push" scheduling, wherein a start date is established and each step is executed consecutively one after another. The second method emulated the Lean approach of "pull" scheduling, in which the overall scheduling goal is identified and then the schedule is developed backward to determine what smaller chunks of information are needed when to meet that goal, keeping all team members working concurrently as efficiently as possible. Doug described a common method of pull planning in which a team gathers in one room and collaboratively develops the schedule using color-coded post-its on the wall for each task in a process, identifying its duration, what's needed from upstream actors to perform the task, and constraints.

5. Seek Perfection

The last principle of Lean is the endeavor to continually improve the process, to strive for perfection - meaning the complete elimination of all activities that don't provide value for the customer. It's an ongoing cycle described as PDCA (Plan, Do, Check, Act) which requires transparency and feedback from all, especially customers of the process. One tool to accomplish this is a "plus-delta" check after completion of a process, to revisit the original goals and evaluate what was done well (plus) vs. what could be done better (delta), and to use that input to improve the process next time. Post-occupancy evaluation, anyone?

Doug then addressed some of the objections that are expressed in regard to Lean: that it's just a fad, it's not necessary, there's no time for it, effort should be directed at producing results rather than improving the process, and there's no return on the effort—in large part a lack of understanding and fear of the unknown. Doug addressed those concerns by identifying some of the key differences of Traditional vs. Lean Production and Management—a focus on results vs. customer value, an individual vs. team approach, free-form vs. defined methods, and carrot and stick vs. managed expectations, building consensus and trust—and the resulting benefits:

• for the customer: greater value—faster, lower cost, better quality
• for the designer: happier clients, fewer fire drills and happier staff, and greater profit
• for staff: less stress, greater job satisfaction, happier work environment

Dave Bleiman raised some issues that hinder implementation of Lean. Often outside entities disrupt the process, such as OSHPD or Building Department review; or the entire hierarchy of a team is not on board with the concept; or time-engrained habits resurface at crunch time. He postulates that Lean is easier to implement on a firm basis rather than a project basis. For successful implementation, buy-in and motivation must occur from both the top down and the bottom up.

Doug next reviewed one of the trademark tools of Lean processes, the A3. It's so-called because it uses a single page of paper of Japanese size A3, roughly equivalent to 11x17. It's used to track an issue and the Lean process approach to it. It's composed of a statement and explanation of the issue, analysis—ask why 5 times!—and decision on how to resolve the issue, the specific steps necessary to achieve that resolution, and an evaluation of whether the issue is resolved and how well.

To complete Doug's presentation and demonstration of Lean principals, he solicited plus/delta feedback from everyone in the room on his presentation. Everyone's goals seem to have been met, and we all agreed that Doug did a very nice job of presenting the material. We also agreed that more discussion—which was curtailed during the presentation due to time constraints—would have been helpful.

Those of us who could afford the time stayed on to continue the conversation. Nancy pondered the question of how to implement Lean. Marla pointed out that Lean prescribes a way of thinking that's not dependent upon specific tools or even language, and that a leader could overcome potential resistance to the "Lean" brand by avoiding the catch phrases.

Nancy and Dave think that stress breaks down the Lean process, which Marla points out is ironic as the process is intended to relieve stress. Firmly-ingrained dysfunctional behaviors burden implementation of any kind; the iterative cycle of continuous improvement should eventually overcome that burden.

Dave stated that a critical aspect of Lean is learning how to make proper requests and realistic promises. We all agreed that communication is the most important thing, not the formal tools and terminology of Lean. As Karen noted, it's the job of a project manager to set the tone and create a Lean environment starting at the project kick-off meeting. Dave thinks that it's the project managers who are most resistant to process change. Upper management hears all the benefits and gets on-board with the program but don't directly implement it; and junior staff have no established processes to conflict with the change. Dan thinks one difficulty is the difference between cash flow and profit vs. value creation. It's necessary to figure out how to spread risk across the entire firm rather than burdening a particular project. Damon states there's often interest initially, but when the rubber hits the road, it's pushed off to down the road, on to the next project.

There was a little discussion at the end on some other topics. Eric says that gaming will change our industry, because they're solving the problem of processing huge amounts of data. Our industry just doesn't have an income stream sufficient to tackle it. Dan says game designers reduce polygons to a bare minimum, which is not feasible for AEC. When he can't load an entire model, Damon loads just what's necessary. Dan notes that elements to be loaded can be selected based on location within the building or distance from the viewer.

Damon championed Twitter; he's discovered that using it to post complaints is an extremely effective method for getting a response from a company—they really don't want problems out there, searchable, in cyberspace.

Dave has sworn off multi-tasking, he thinks it just doesn't work. He likes using his iPad because then he can do only one thing at a time.

July Meeting

Attendees: Dave Bleiman, Todd Henderson, Bruce Madsen, James McKenzie, Dan Tsui, Marla Ushijima

We started off with a discussion of Lean Design and it's relationship to BIM. Currently there are cases of remodeling due to the use of multiple software and difficulties with interoperability. Structural engineers prefer Tekla, architects typically use Revit, but there are problems with the IFC interface between them, such as beams that get flipped when they're translated into Revit. In response, Todd notes that Boulder Associates has learned how to model in Tekla, but this is prohibitive for most architects. Dave made a presentation at Autodesk University on the two programs, the interface between them, and the shortcomings of Revit for fabrication. Tekla has provided a "crazy amount" of support on the issue, but not so much from Autodesk. Fabricators use Tekla because it identifies every piece of rebar on a project - necessary for shop-fabrication - but that doesn't work in Revit. That problem was resolved in Revit 2013, but by that point fabricators had already committed to Tekla. James postulated that issues might arise from the fact that Autodesk hasn't developed a product in-house since AutoCAD 20+ years ago, with the exception of Inventor. They've bought all their signature software in recent years.

Next up was the topic of construction accuracy. James referenced GPS control of earth-moving equipment, facilitated by topo models with all underground utilities located. Todd noted that at Kaiser Oakland Hospital, McCarthy Construction developed an in-house scanning team that creates topo maps of floor slabs to measure their levelness to 1/10 of an inch, and to check locations of rebar and stub-ups. They overlay the laser scan onto the Revit model for QA/QC. Can construction methods really meet the new expectations for construction tolerances? Swinerton uses Get the Point software with Total Station to identify hole locations in slabs, and also uses laser scanning for QA/QC. James notes that they receive no additional compensation, and they're not taking advantage of it for marketing purposes.

Dave brought up the issue of cloud computing. At the recent Revit Technology Conference there was a demonstration of BIM9, which provides private BIM clouds with a separate server behind a firewall that firms locate in their own server room. It provides BIM authoring software via remote desktop access for either local or remote use by any device connected to the internet. Cheap computers can be used for modeling as long as they have a good graphics card. Even ipads can be a viable modeling tool if they've got a mouse. Todd mentioned experience with Log Me In for remote access, which was slow and doesn't give server access to consultant engineers in China. Bruce noted that HOK is using Citrix successfully for cloud computing.

For cloud storage, James mentioned Pogo, which is a cheap device that acts as a private server. It's not secure but it is easily deployed. Todd said that security concerns led Sutter Health to negotiate a special contract for Buzzsaw that guarantees that none of their data would be stored outside the country. We questioned the need for this, as info gets out anyway via bid documents. Todd likes Buzzsaw, Dave notes that Dropbox is popular but not as robust.

There are several solutions that marry team-sharing of information and project management. Constructware is designed to work with Buzzsaw. Horizontal Glue has been bought by AutoDesk; it facilitates the RFI process and works with CMIC for job-cost accounting, similar to Deltek but more robust. Dan's experience with Horizontal Glue is that it's navigation is slow, with cloud-based streaming. James noted the need for untethered access to information when an internet connection is unavailable. Vela Systems caches information for off-line access. Dan and Bruce are both familiar with 360 Glue, which is another Autodesk product similar to Horizontal Glue. They thought it worked well. Dan used it at Modulus Consulting for cloud rendering, which was fast, impressive, and freed up their in-house servers. His client loved it, asking for more and more renderings - include it in the contract as an add service so both the client and you benefit.