 |
Modeling Language Spotlight
Design Build Use
March 16, 1997 |
Like the other models of the MG Taylor Modeling
Language, the Design Build Use Model is protected by copyright.
You can use it only by meeting these
four conditions.
The Traditional Model
 The most common approach to designing, building or using
most anything is linear. In its extreme incarnations, not only is there
no feedback between stages, but the individuals involved in each stage
are different as well and do not communicate across the boundaries between
stages. In construction there are cases where the architect creates the
plans and hands them off to the builder who executes the plans, making
modifications on his own. When the builder has finished erecting the structure,
the user or occupant takes over. Sometimes they never meet.
Actually the user--as a user--plays no role of any significance in the
traditional model at all. Even though the future occupant may engage with
the architect and the builder during design and construction, he or she
is engaging not as a user (the space is not finished, so how could it
be in use?), but as a co-designer. This is a task for which most users
are ill-suited. Once the building is occupied, the only viable means for
feedback to the process usually come wrapped in lawsuits. Because of the
cost and time involved, the user is stuck with all the things that don't
work--that couldn't possibly have been foreseen, but which cannot not
be modified. The user now begins a gut-wrenching lifelong process of accomplishing
the work of the enterprise, while fighting the space that her enterprise
inhabits!
The traditional approach generates static, non-living artifacts which
can only be torn down in response to a wide range of demands upon their
flexibility.
Life becomes an unending compromise.
The Design/Build Method
 Over the past several decades the construction industry
has moved to a more feedback-driven model. Here the architect and builder
work as a team from the early stages of design through the completion
of the structure. The user is involved as well, but again, not as a true
user and occupant but as an unskilled co-designer. All too often the user's
ignorance of the technical issues renders him something of a nuisance
to be tolerated rather than a collaborator to be engaged with.
There are certainly a number of exceptions to this bleak assessment of
the current situation, however a casual glance at the majority of the
cities that we occupy only confirms that whatever process is being employed
is inadequate to the challenge. We live and work in graceless, unforgiving,
unyielding structures that only seem to frustrate our ambitions and attenuate
our visions.
Adding All of the Feedback Loops
The model below illustrates the requisite relationship between design,
build and use.
The designer and the design process is connected to both the user
and the builder. The builder and the building process is connected to
the user and designer. The user and the processes employed by the user
in the conduct of the business of the enterprise is connected to the designer
and builder. These interconnecting feedback loops imply that the designer,
builder and user remain connected throughout the lifespan of the enterprise.
It also requires that the products of this collaboration be stable enough
to provide day-to-day integrity and flexible enough to allow radical,
rapid redesign to fit the changing needs of the user over time. It means
that the environment is never "finished" and that it is constantly
able to provide a "just enough, just in time" solution. Things
that are "finished" in our emerging world are dead.
It's important to reemphasize that not only must the three different
entities communicate and collaborate, but their processes must dovetail
as well. That means that the design, build and using processes should
not inhibit each other or create confusion. For the user it indicates
a mental shift in understanding that a design and build capability occupy
a permanent part of the larger web of the enterprise. It also changes
the way that equity, debt and cash flow are treated within the value web
between the builder, designer and user.
| glyph info |
Element |
Description |
 |
Design |
Create sketches, models, plans, schedules, and budgets to convey
a sense of the scope of the project in many different dimensions.
This is not done merely at the beginning of the project, but as
a sort of continuous process throughout the life of the building.
The design takes into account past and present work process requirements,
and the uncertainty associated with the future as well. |
 |
Build |
There must be a process for rapid execution of the design that
allows frequent adjustments to the realities of a build-out and
the changing perceptions of the user as the design unfolds. The
process and the product (space) must provide for this speed throughout
the occupancy so that the enterprise of users does not have to waste
time and talent in reconfiguring itself to meet changing conditions. |
 |
Use |
As the environment is used, it will change the processes that
take place within it. These changes, in addition to events in the
external environment will drive a demand for the work space to adjust
its function, and to do so rapidly. The design and build capacities
must always be readily at hand. |
Management Center Applications
It should be obvious that a Management Center® environment must follow
this model in a strict fashion. The environment is often radically redesigned
within a matter of minutes--walls, workstations, tools and equipment all
must move to accommodate changes in the process. One area that supported
clusters of teams one minute will have to support a large group session
of a hundred or more in theater seating the next. And yet the environment
must not have a look of disarray about it, for this will adversely affect
the processes taking place within it. This rapid flexibility and integrity
of the space is a primary feature that allows the users of Management
Center environments to radically compress the time required to invent
and deliver new enterprises and new products.
DesignShop® Applications
Design Build Use is also a powerful model to use when designing an event,
even though we frequently employ Scan Focus Act as the standard template.
When using Scan Focus Act, it's common to assign the stages to successive
time periods of the event: Scan is day one, Focus day two and Act day
three. Design Build Use calls for a slightly different, non-linear approach.
Of course, day one could be Design; day two Build and day three Use. But
this misses the point, and also destroys the feedback loops.
Upon the completion of any module of work during a DesignShop event,
the participants and KreW must be able to engage with the product as designers,
builders and users--not as designers only. Successive modules iterate
the design, the building and the use. This means that every activity must
have some output and that the output of one activity is designed to feed
into the activities to come.
Other, Non-Architectural Applications
Any type of work that calls for rapid prototyping, production, evaluation
and iteration should employ this model. Remember to not separate the designer,
builder and user from each other or from direct feedback of how the work
of one affects the others.
 
copyright © 1997, MG Taylor Corporation.
All rights reserved
copyrights,
terms and conditions
19970316235127.web.bsc
|
