UNIVERSITY OF CALIFORNIA, BERKELEY
BERKELEY • DAVIS • IRVINE • LOS ANGELES • MERCED • RIVERSIDE • SAN DIEGO • SAN FRANCISCO SANTA BARBARA • SANTA CRUZ
TELEPHONE: (415) 710-5531 DEPARTMENT OF CIVIL & ENVIRONMENTAL ENGINEERING
ENGINEERING & PROJECT MANAGEMENT PROGRAM
E-MAIL: ballard@ce.berkeley.edu 215-A MCLAUGHLIN HALL
BERKELEY, CALIFORNIA 94720-1712
DESIGN PLANNING WORKSHOP #2
SEPTEMBER 29, 2011
The second in a series of workshops on design planning and control was held at DPR’s Redwood
City office featuring a presentation by Jamie Hammond of Adept Management.
The objective of the workshop series is to bring together the best people, learn from one another,
and emerge with agreement on what practices to recommend be used to plan and control work
during the design phase of construction projects. The recommendations will be captured in a
P2SL process benchmark, together with a description of research needed to go beyond the
benchmark.
Workshops will be held at DPR’s Redwood City office, 1450 Veterans Blvd.—thank you for
that, Dean Reed and DPR. Doodle polls will be used to select the next meeting time when the
most members of the group can attend. The next workshop will be held before Christmas and
will feature a presentation by James Choo of Strategic Project Solutions.
Current members of the group are invited to recommend others who could contribute to the
conversation, but we do not want to be distracted by having to explain what we’re talking about
to those who do not have the relevant experience. Spreading the word is also vitally important,
but the purpose of this workshop series is to define the current frontier of knowledge regarding
design planning and control.
ATTENDEES
Joe Ales, Walter P. Moore, jales@walterpmoore.com
Bill Andrews, Walter P. Moore, bandrews@walterpmoore.com
Glenn Ballard, UC Berkeley, 415-710-5531, ballard@ce.berkeley.edu
Sandra Beck, UCSF, Sandra.Beck@ucsf.edu
Casey Bell, Cal State East Bay
David Bleiman, Rutherford & Chekene, dblieman@ruthchek.com
Jason Bredbury, Skanska, Jason.bredbury@skanska.com
James Choo, Strategic Project Solutions, jchoo@spsinc.net
Digby Christian, Sutter Health, 916-826-9791, ChristD2@sutterhealth.org
Sean Collins, HGA, scollins@hga.com
Septarshi Desai, Turner Construction Co., sdesai@tcco.com
P2SL.BERKELEY.EDU 1
UNIVERSITY OF CALIFORNIA, BERKELEY
BERKELEY • DAVIS • IRVINE • LOS ANGELES • MERCED • RIVERSIDE • SAN DIEGO • SAN FRANCISCO SANTA BARBARA • SANTA CRUZ
TELEPHONE: (415) 710-5531 DEPARTMENT OF CIVIL & ENVIRONMENTAL ENGINEERING
ENGINEERING & PROJECT MANAGEMENT PROGRAM
E-MAIL: ballard@ce.berkeley.edu 215-A MCLAUGHLIN HALL
BERKELEY, CALIFORNIA 94720-1712
Martin Fischer, Stanford, fischer@stanford.edu
Sepide Gholami, UC Berkeley – P2SL
Mark Gilligan, MKG Consulting, 510-548-8029, mark@gilligan.name
Daniel Gonzales, DPR, 510-290-1595, danielg@dpr.com
Tony Groce, Boiled Architecture, info@boiledarchitecture.com
Jamie Hammond, Adept Management, jamie.hammond@adeptmanagement.com
John Haymaker, DPI, 415-290-2738, john.haymaker@gmail.com
Bob Hazelton, Herrick, BOBH@HerrickSteel.com
Gernot Hicketier, UC Berkeley – P2SL, gernot.hickethier@gmail.com
Mike Jones, DPR, 650-868-6117, mikej@dpr.com
Atul Khanzode, DPR, 650-474-1450, atulk@dpr.com
Hyun Woo Lee, UC Berkeley – P2SL, hyunwoo@berkeley.edu
Baris Lostuvali, Herrero Contractors, BLostuvali@herrero.com
Gregory Mantz, DPR, 415-782-3700, gregorym@dpr.com
Tim McClenahan, J.W. McClenahan, tj@jwmcclenahanco.com
Patrick McGee, UCSF, Patrick.McGee@ucsf.edu
Ron Migliori, Buehler & Buehler, 916-443-0303, RMIGLO@BBSE.com
Gary Nelson, UCSF, Gary.Nelson@ucsf.edu
Layne Olson, Harris Rebar, lolson@harrisrebar.com
Rob Purcell, Herrero-Boldt, 415-265-5536, rpurcell@herrero.com
Jim Soule, Harris Rebar, jsoule@harrisrebar.com
Linas Stempuzis, Linas Stempuzis Architect, linas@lsarch.com
Mark Tiscornia, HGA, mtiscornia@hga.com
Patricia Tillman, UC Berkeley – P2SL, patriciatillmann@gmail.com
Iris Tommelein, UC Berkeley, 510-643-8678, tommelein@ce.berkeley.edu
Robert Van Kirk, Mazzetti, RobertV@mazzetti.com
Oscia Wilson, Boiled Architecture, osciawilson@gmail.com
Charles Zuckerman, Herrero Contractors, czuckerman@herrero.com
TAKEAWAYS
‐ Plan work is part of doing work
‐ Can’t manage what we can’t see
‐ Team empathy improves performance
‐ Building empathy within the team
‐ Process assessment at any time
‐ Not getting info is not an excuse
‐ Similar problems throughout the world
‐ Look ahead planning critical/lacking
‐ Early risk discussion
P2SL.BERKELEY.EDU 2
UNIVERSITY OF CALIFORNIA, BERKELEY
BERKELEY • DAVIS • IRVINE • LOS ANGELES • MERCED • RIVERSIDE • SAN DIEGO • SAN FRANCISCO SANTA BARBARA • SANTA CRUZ
TELEPHONE: (415) 710-5531 DEPARTMENT OF CIVIL & ENVIRONMENTAL ENGINEERING
ENGINEERING & PROJECT MANAGEMENT PROGRAM
E-MAIL: ballard@ce.berkeley.edu 215-A MCLAUGHLIN HALL
BERKELEY, CALIFORNIA 94720-1712
‐ Don’t jump into design
‐ Task identification informs sequence
‐ Don’t recreate the wheel
‐ Embrace complexity
‐ Review PPC means you review dependency
‐ Define your predecessor not your outcome
‐ All disciplines need to compromise with each other
‐ Benefits to analyze what is truly vital vs. nice to know
‐ Design process is not a magical black box
‐ Behavior matters most
‐ Understand systems
‐ Production control does work for managing design
‐ People and behavior matter
‐ Need a single plan, not several
‐ The plan needs to be built by the team that will execute it
‐ Managing iterations
‐ Define success
QUESTIONS
How is non-design team involved in the process?
We suggest a ‘project characteristics’ kick-off workshop. This is a 4 hour session, split in to two
halves. We recommend that non-design team members are part of this workshop. The first part
of the workshop is a ‘Design Risk’ exercise, where participants work alone to define as many
risks and issues that they are aware of in relation to the design. In addition, we also encourage
lessons learned to be identified too (after all there is a lot of experience in the room). Non-
designers tend to raise different issues, and in some cases we find that owners define
expectations. The team feed back their list of risks and issues, explaining each one to the whole
group. This generates a lot of important discussion. The 2nd part of the workshop involves the
different project disciplines working in their group (or silo!). They work together to build a
framework that explains what systems they will design, and what work they typically need to
complete in order to design those systems. The non-designers undertake a similar exercise, but
we ask them to define what management processes are required. These are important processes
that will need to be incorporated in to the whole design process. A good example is the
Reviewable Design Data process: it is a process that defines the owner / user preferred process to
review fabric, finishes and FF&E. This needs to be defined and carefully ‘stitched’ in to the
design process.
P2SL.BERKELEY.EDU 3
UNIVERSITY OF CALIFORNIA, BERKELEY
BERKELEY • DAVIS • IRVINE • LOS ANGELES • MERCED • RIVERSIDE • SAN DIEGO • SAN FRANCISCO SANTA BARBARA • SANTA CRUZ
TELEPHONE: (415) 710-5531 DEPARTMENT OF CIVIL & ENVIRONMENTAL ENGINEERING
ENGINEERING & PROJECT MANAGEMENT PROGRAM
E-MAIL: ballard@ce.berkeley.edu 215-A MCLAUGHLIN HALL
BERKELEY, CALIFORNIA 94720-1712
During the production control phase, any person that has ownership of a task (whether it is a
design task or a management task) is part of the look ahead and weekly work planning process.
How can I implement this on smaller and simpler projects without scaring the client?
Good question and it depends upon the definition of small. I prefer to try to categorize the project
in terms of its complexity, rather than on dollar value. If it is deemed to be a complex project
(technically), with a lot of owner, user and regulatory interface, then defining the design process
(as a whole) and managing it is a risk management proposition.
What is the risk register and how do you use it?
The Risk Register is a collection of design project issues that are identified from the very
beginning of the project. As the project moves forward, more risks are identified, and therefore
added to the register. We like to keep it simple, therefore, risks are noted, mitigation defined and
ownership assigned. All decisions and assumptions made during the tearing workshops are added
to the risk register, and it becomes a record of what decisions were made by whom, and very
importantly, it provides the rationale for why we were able to ‘tear’ a dependency between two
designers (a negotiation around what information is needed and what can actually be provided).
We use it throughout the entire design process, and it is a schedule that should be referred to as
part of a design team meeting.
How does complexity evolve when trade partners come on board?
In my experience, complexity reduces when trade partners come on board because they bring a
lot of answers to the questions that create some of the complexity in the first place. All too often
it is too late! During the tearing workshops, some iterative loops can be resolved by bringing a
trade to the discussions.
When do durations get specified in the planning process?
We find it best to ask an owner of a design task about durations at the same time that we are
asking what information they need from others.
P2SL.BERKELEY.EDU 4
UNIVERSITY OF CALIFORNIA, BERKELEY
BERKELEY • DAVIS • IRVINE • LOS ANGELES • MERCED • RIVERSIDE • SAN DIEGO • SAN FRANCISCO SANTA BARBARA • SANTA CRUZ
TELEPHONE: (415) 710-5531 DEPARTMENT OF CIVIL & ENVIRONMENTAL ENGINEERING
ENGINEERING & PROJECT MANAGEMENT PROGRAM
E-MAIL: ballard@ce.berkeley.edu 215-A MCLAUGHLIN HALL
BERKELEY, CALIFORNIA 94720-1712
Last time we talked about VSMs to lay out dependencies, now we are talking about DSM.
What is the best way to capture dependencies?
Value Stream Mapping is a great tool for mapping a relatively low number of dependencies
between entities. A model is at least the next level in terms of detail, and we know there to be
many to many relationships between each entity. Therefore to visualize and subsequently
analyze this level of detail, we use DSM.
Have you found that the industry has a problem having a common definition of what a
completed design is?
Yes. It is made more complicated since we have found different design disciplines have different
opinions, as do owners, lawyers, and even estimators. We try to encourage the team to agree
what level of fixity is required in order to know when the team passes from one phase in to the
next phase of design. This fixity can be easily defined in the design process. But whatever the
definition is, it must be consistent and fully understood by everyone engaged on that particular
project. This discussion usually takes place as part of the project characteristics workshop.
Does the PDCA cycle apply to lean design or not?
Yes. Our design management approach is a PDCA cycle.
Are you using the opportunity to simulate alternative futures and use that… to what extent
are teams taking advantage of that opportunity?
Yes. Since there is a greater understanding of the whole design process, it is relatively simple to
undertake ‘what – if’ scenarios. We often find this to be the case when integrating the design
process with the procurement and construction process, since it is rarely the case that they are
aligned. We have experienced the design team demonstrating to the General Contractor that a
late change to save money in construction will have a significant cost implication in design (fees,
schedule, inter-dependent design systems).
What is the relation between an informational dependency vs the dependency between
activities?
P2SL.BERKELEY.EDU 5
UNIVERSITY OF CALIFORNIA, BERKELEY
BERKELEY • DAVIS • IRVINE • LOS ANGELES • MERCED • RIVERSIDE • SAN DIEGO • SAN FRANCISCO SANTA BARBARA • SANTA CRUZ
TELEPHONE: (415) 710-5531 DEPARTMENT OF CIVIL & ENVIRONMENTAL ENGINEERING
ENGINEERING & PROJECT MANAGEMENT PROGRAM
E-MAIL: ballard@ce.berkeley.edu 215-A MCLAUGHLIN HALL
BERKELEY, CALIFORNIA 94720-1712
In our model, they are exactly the same. A dependency in the design process model, and
therefore in the DSM is information being requested / pulled from another designer.
Where do you take resource constraints into consideration? You consider sequencing and
duration,… H2 introduce capacity constraints?
We have the ability to capture effort in the DSM tool. The design process model can be exported
in to a scheduling tool (such as P6) then resource can be calculated. However, our preferred
approach is to rely upon the initial conversation during the development of the design process
model and then identify resource constraints as part of the look ahead process. We seek a
commitment to provide the right level of resources, and as soon as failures arise due to resource
constraints, the correct discussion can happen as part of the overall design team meetings. This
happens all of the time and is exposed very quickly.
.. if yes, what was the lesson learned?
Designers tend to over promise, and under resource (sorry). We try to flush this out as early as
possible. Our use of PPC and lookahead planning is our best approach to deal with the challenge
(so far).
Does SBD have any relevance to the DSM approach? Does SBD have implications on
managing iterations?
I think so, however there is more investigation required. At the latter stages of design, the DSMs
show multi-disciplinary systems to be designed and coordinated. I believe that the definition of
that system (by the tasks that come together in the iterative loop) can be an opportunity to define
the boundary condition for the set. I am not too sure if this is the best use of SBD, as it is quite
late in the process (more coordination rather than negotiation). More research is needed.
How do you define scope for DSM analysis?
The design work in the iterative loop is the starting point. The first analysis results in a large
number of design activities being part of one large iterative loop. As the team ‘tear’ the iterative
loop, the number of tasks in the loop reduce. It is critical that the team review and agree the
characteristics of the loop by looking at what tasks are part of that loop. Eventually we find that
P2SL.BERKELEY.EDU 6
UNIVERSITY OF CALIFORNIA, BERKELEY
BERKELEY • DAVIS • IRVINE • LOS ANGELES • MERCED • RIVERSIDE • SAN DIEGO • SAN FRANCISCO SANTA BARBARA • SANTA CRUZ
TELEPHONE: (415) 710-5531 DEPARTMENT OF CIVIL & ENVIRONMENTAL ENGINEERING
ENGINEERING & PROJECT MANAGEMENT PROGRAM
E-MAIL: ballard@ce.berkeley.edu 215-A MCLAUGHLIN HALL
BERKELEY, CALIFORNIA 94720-1712
the team knows when to stop tearing because the loop makes sense. The remaining iterative loop
tends to be a multi-disciplinary system that requires intense collaboration and coordination.
The analysis must continue to include a team discussion on how they plan to manage the
iteration. This is what we call a design management strategy, and can include agreeing lead
coordinators, clustering, co-location, planned iteration with defined outcomes etc etc.
Thinking of design as progressive specification, is there a different way to structure plans in
each phase?
I think there is. ADePT is an approach that works in the structured part of the design process (say
from Schematic Design onwards). But we do not use it in conceptual design. It will be great to
learn from others that have developed effective ways to manage concept design.
PLUS
‐ Good topic
‐ Well prepared
‐ Great content
‐ Open interaction
‐ Good attendance
‐ Some owners were here
‐ Keep focused on objective – to add to knowledge
DELTA
‐ Speaker comes on time
‐ Microphone
‐ Start setting goals from what we’re learning
‐ Earlier interactive interlude – too long to sit on questions and comments
P2SL.BERKELEY.EDU 7