Requirements for a Process Integration Platform
Reid Senescu
CIFE, Stanford University
Y2E2 Bldg, 473 Via Ortega, Rm 292
Stanford, CA 94305-4020 USA
rsenescu@stanford.edu
John Haymaker
CIFE, Stanford University
Y2E2 Bldg, 473 Via Ortega, Rm 292
Stanford, CA 94305-4020 USA
haymaker@stanford.edu
ABSTRACT
Despite the influx of building information modeling and advanced building simulations, design processes
remain similar to the pre-computer era. This paper investigates the extent to which interactive, collaborative
design process models improve design process efficiency and effectiveness. We present case study processes
and a survey of practicing engineers that illustrate shortcomings in practice, and review relevant points of
departure to develop an ethnographically and theoretically founded set of requirements for a collaborative
process modelling platform that enables improved communication of processes. We use a hypothetical
narrative to explain its use and establish a method for evaluating the platform.
Keywords: Process Integration Platform, Design Process, Interoperability.
1
INTRODUCTION
To some, Building Information Modeling (BIM) is a process [1]. To many others, BIM at the very least changes the
design process [2, 3]. We define processes as a dependency-based description of information flow. The association
of BIM with process change pervades the Architecture, Engineering and Construction (AEC) industry. Yet, little
commercial development of BIM is process-centric, and none of the major BIM tools provide explicit support for
defining and sharing processes. 3d object-oriented modeling is still mostly a set of static tools, none of which aid the
design team in explicitly defining, improving, and sharing design processes. Despite the rhetoric that BIM is a
fundamental shift in the design process, the industry generally still plugs in new BIM tools into a design process that
predates computers. Software with parametric capabilities offer one possible exception as they do formalize a new
process, but parametric tools are used principally to manage geometric processes, and lack collaboration methods
and transparency, limiting their potential for broader process change. While the capabilities of simulation and
modeling tools expand, order of magnitude increases in design process efficiency and effectiveness remain elusive.
This paper uses two examples from current practice to demonstrate how current limitations in communicating
processes limit BIM’s promise to drastically improve design process efficiency and effectiveness. The paper then
summarizes results from a survey of engineers. The case studies, survey, and a literature review lay the foundation
for a theoretically founded set of requirements to enable process sharing in a Process Integration Platform (P.I.P.).
While the potential impact of P.I.P. on current design practices is broad, the paper focuses on how the proposed
platform catalyses continuous improvements to the design process through incentivizing and visualizing the
development and sharing of design processes. The paper then uses Narratives [4] to formally model and to illustrate
the sharing behaviors defined in our requirements.
1
2
BIM OPPORTUNITIES LOST
2.1 DESIGNING LOUVERS FOR OPTIMAL DAYLIGHTING
With the goal of informing the design team’s decision regarding the quantity and size of louvers on the south façade
of the new Stanford Graduate School of Business Library, engineers created video simulations of sunlight moving
across a space during different days of the year. Prior to 3d object-oriented architecture models, engineers created
the geometry for such analyses from scratch, but the resulting visualizations were crude. Looking to improve the
realism of the output, the lighting engineers used the architect’s Revit model as the basis for their geometry. The
engineers were confident in the science behind their analysis tool, Radiance, and did not have the time to learn and
validate other programs. Through trial and error, they discovered that they could use Revit Architecture, AutoCAD,
3D Studio Max and Radiance to create an improved day lighting simulation (Figure 1). The process required much
manual manipulation of geometry and materials to reformat the information so that each new software package could
interpret the data representing the building. The design team did not formally represent the process, which we list in
Table 1.
The engineers run these processes several times per month. The process described in Table 1 takes about 24 manhours to provide feedback to the architects. About 16 man-hours are spent on non-value added tasks, such as
cleaning up geometry or reassigning materials in AutoCAD layers that were already differentiated in Revit. The
engineers felt that elimination of the 16 hours of non-value added time would either increase the number of options
that the architect could consider or increase the company’s profit. The engineers believed that with improved
efficiency, they could further explore the design space and discover a better solution. At some point, the return from
expanding the options considered would diminish, and engineers would just spend less time producing the same
quality design, improving company profit. Despite the obvious benefit of an improved process with improved
interoperability between Revit and Radiance, no one was developing a solution to meet the needs of the lighting
engineers.
Figure 1. Snapshot of a QuickTime video. The lighting engineers use this video to show the architects how different
louver configurations affect day lighting in the Stanford Graduate School of Business Library.
The first author attempted to find an improved solution. Asking for an improved process on the engineering
firm’s intranet forum revealed suggestions for similar processes, but no solutions that matched the project’s given
input and desired output. An internet search of blogs and forums reveal that other companies had similar problems
trying to go from Revit to Radiance [5, 6], but no one had posted an improved solution. An interview with Revit’s
developers revealed they are interested in improving links between their object oriented 3d building software and
analysis programs, but development toward improving the direct link between Revit and Radiance was not planned.
One potential alternative is to go from Revit to IES to Radiance, but the lighting engineers were once disappointed
with this option and did not have the time to try again. The lighting engineers were simply too busy to invest time in
improving their process. Their supervisors, software developers, and their clients had no methods for understanding
how an improved process could increase profits or design quality.
The first author intervened by approaching some principals in the firm to explain the inefficiency of the current
process, and they committed funds to improving the process. With about 16 hours of research, the first author cut
step 3 and 4 to a few minutes, eliminating six hours of tedious, non-value adding time from the process. With an
2
investment of roughly $2400, we hypothetically added $32,400 of value annually, assuming 6 hours x 3
iterations/month x 12 months x $150/hour. Three other documented case studies at the firm suggest that this
opportunity for improving process efficiency is prolific across disciplines. For a company of 3000 engineers,
extrapolating this case would result in lost profit or value passed on to clients of $97 million annually. McGraw Hill
extrapolates from other reports that lack of interoperability costs the global AEC industry $138 billion annually [7].
In summary, the current tools provide an opportunity to improve the efficiency and effectiveness of the lighting
design process. Yet, without intervention, designers do not capitalize on this opportunity. The individual engineers
are not incentivized to invest their time in improving the process through interoperability solutions. Their tools do
not track their process (and the resulting inefficiency), place them in a small peer community to improve the process
together, nor provide transparent access to other processes that could form the basis or a module for improvements.
Also, managers lack a transparent method for understanding the inefficiency and therefore, lack a monetary
justification for encouraging their employees to develop alternatives.
Table 1. The steps taken to produce day lighting videos. The steps in the process and time for each step were not
documented until the authors intervened. Much time is spent filtering and transferring previously defined information
(e.g. Steps 3, 4, 7, and 10)
Step #
1
2
3
4
5
6
7
8
9
10
11
12
13
Task
Software
Create Revit Model
Revit Architecture
Import 3d .dwg with 3d shapes
AutoCAD 2007
Clean up geometry
AutoCAD 2007
Set layers to match materials
AutoCAD 2007
Import 3d .dwg with 2d surfaces and layers
AutoCAD 2005
Identify holes
Radiance
Import 3d .dwg
3D Studio Max
Remesh geometry
3D Studio Max
Import 3D Studio Max Rendering
AutoCAD 2005
Import 3d .dwg
Radiance
Set sunlight properties, material reflectivity, etc.
Radiance
Create video
QuickTime
Discuss lighting video with architect and create new design
concept.
Discussion
Time Spent Per
Step (hours)
N/A
0.3
4-6
1.5
0.2
2-3
1-2
0.2
0.5
1-2
4
8
2-3
2.2 DESIGNING WITH ENVIRONMENTALLY RESPONSIBLE MATERIAL USE
Owners’ interests in environmentally sustainable business practices have skyrocketed in recent years [8]. For the
design of the Stanford Graduate School of Business campus, stakeholders used MACDADI [9] to explicitly
communicate the importance of material responsibility when choosing structural systems. The first author, while
working as an engineer on this project, created schematic Revit Structure models of steel and concrete options for
one building on the project. The model was used to support a visual understanding of the two systems, as well as
some structural and cost analysis. Many tools (e.g. Athena, BEES, LCADesign) aim at assisting designers in making
environmentally sustainable material decisions. The engineering firm had recently purchased Athena, software that
uses a database to output the environmental impact of building materials. Despite a 3d object oriented model
(containing a database of structural materials and quantities), a database of the environmental impacts of those
structural materials, and a clear desire by the stakeholders for the designers to consider material responsibility in
their design recommendations, the author did not conduct a formal environmental impact analysis comparing the
concrete and steel options. Given the time and budget constraints, the first author was not able to find or create a
process that would allow the team to effectively use the information available to further inform the team’s structural
system decision with information on material responsibility.
As was the case with the lighting design, there is a clear demand for an improved process. Unlike the lighting
example where an improved process was non-existent, the first author recently discovered similar processes being
3
employed internal to the company and externally at the time of the structural design [10]. However, there was no
simple mechanism to quickly search for existing processes and build on them to develop new processes. These cases
illustrate that designers need a process that enables them to more easily collaboratively improve and share
interoperable design processes.
3
SURVEY AFFIRMS GENERALITY OF CASE STUDIES
In the winter 2008 we conducted a survey of 74 engineers from a global engineering firm that belonged to a group
interested in virtual design. The employees had on average 11.4 years of experience working in the AEC industry
and they currently worked in North America (24%), Europe (57%), Asia (6%), and Australia (14%).
Half of respondents felt they should increase the amount of virtual design information that they disseminate to
others. The top three barriers to sharing information were “Lack of time”, “Not knowing where information was
kept”, and “Lack of communication.” One engineer commented, “So many times you accidentally find out that
someone somewhere has been doing something for ages that you didn't know about. We are currently all a bit too
busy to spend time telling each other what we're doing.”
We then asked respondents to describe desirable characteristics of an intranet site for sharing information about
virtual design. We coded the responses with 43 adjectives each with its own definition. Table 2 shows the top five
responses. 82% of respondents thought that “absolutely” the site should be “A repository of project information
relevant to virtual design (software used, processes, people involved, etc.).”
Table 2: Five most popular descriptions for a new virtual design intranet site.
Adjective
Number of
Respondents
User-Friendly
20
Crowd-sourcing
Information
Referencing
18
11
Broad
10
Searchable
10
Adjective Definition
No time to understand, easy to navigate,
easy to find, intuitive, good GUI
Open, wiki-like, anyone can add content
Reference other sites, linking to other
already existing things.
Appeal to everyone at all positions,
expertise, or all disciplines, comprehensive
in topics.
Ability to enter in text and find the right
information
The survey reveals that designers want better ways of sharing information and capturing process knowledge
learned from other projects, but that knowledge sharing methods must not take up user time. Broad, crowd-sourcing,
and information referencing suggest that engineers do not want a system dependent on rigorous management, nor do
they want details. Rather, they want a tool that allows everyone to participate in the exchange of information mostly
by referencing information that already exists, but is not necessarily widely available. The survey confirms the case
study observations.
4
POINTS OF DEPARTURE
The examples in Section 2 demonstrate how the lack of formal platforms for communicating and developing
processes fundamentally limit BIM’s impact on AEC. The cases and surveys support our intuition that the industry
requires a process modeling and sharing tool. We next review related work in defining and sharing design
information and processes. We find only partial requirements and solutions for a P.I.P.; suggesting that a unifying
framework for process modeling and sharing is needed.
4
4.1 INTEGRATED PROJECT DELIVERY
Integrated Project Delivery is a project delivery approach that integrates people, systems, business structures and
practices [11]. While attempting to define the requirements for integrated design processes, these approaches fall
short of formalizing the information and processes. They specify milestones in a design process, and specific
considerations and people who should be involved in those processes, but do not formalize the information and tools
needed to ensure effective interoperable processes.
4.2
DATA SCHEMA
Interoperability evokes the possibility of a single database of building information organized in a single data schema
[12]. Researchers continue to develop improved methods for developing standards for specific applications [13].
These standards are powerful, but other strategies such as Application Programming Interface (API), customized
commercial software links, and simple user-written mapping scripts will continue to be a vital part of AEC
interoperability efforts. Many of these efforts lack an explicit representation of process, and methods to dynamically
generate and share these processes.
4.3 DESIGN RATIONALE
Design rationale research develops methods for better understanding the design process and ideas for improving its
current state. Moran and Carroll [14] list several definitions of Design Rationale, all of which refer to the notion of
finding the reasons behind the creation of a particular artifact. Some methods, such as Conklin and Yakemovic’s, use
Issue-Based Information Systems (IBIS) and process tracking to better understand and track reasons behind design
decisions [15]. MacLean et al’s (1991) Questions, Options, and Criteria methodology ignores the chronological
aspects of the process and focuses exclusively on reasoning [16]. Design Rationale systems are not often
implemented in practice, because designers struggle to document their rationale when performing design. The
requirements proposed in this paper include sharing of computable information. Therefore, the process models focus
on the how of design (the process) rather than on the why behind a design (the reason).
4.4 PROCESS MODELING
Lee et al. [13] use process models to improve product data models – a formal and structured definition of product
information such as IFC’s. Lee identified several drawbacks to the ISO STEP product modeling method, including:
they are built as single generic models to represent idealized industry-wide processes preventing local variations; are
thus high-level and lacking in detail; are defined more as archives of data instead of as support for strategic workflow
processes; and do not well support the developmental and evolutionary aspects of product development. They argue
that product models must have a closer linkage with workflow and that mapping between processes and the product
model data should become an explicit part of the definition activity. Whereas Lee et al. share our intuition that
process models are key to design integration, Lee et al. see the use of process models in aiding the development of
future product data models. The authors do not attempt to develop such a standard, instead relying on a web of
individual interoperability solutions, some of which no doubt will evolve through Lee and Eastman’s work.
Information Delivery Manuals (IDMs) are an integral component of the International Alliance for
Interoperability’s (IAI) buildingSMART initiative and Industry Foundation Classes (IFC) development effort [12].
The purpose of IDMs is to provide a human-readable integrated reference identifying “best practice” design
processes and the data schemas and information flows necessary to execute effective model-based design analyses.
However, current process modeling approaches are formulated at an abstract level to define general data exchanges,
processes, and design team requirements, and have limited value as a project-specific design guidance and
management tool. That is, software developers, not designers, use these process models, and they are therefore not
intended to be transparent, usable, and searchable tools used by project teams.
Several CIFE methods have advanced the design of process models for use by AEC professionals in practice.
Geometric Narrator [4], enables a designer to build a scalable, computable process from sub processes, but lacks an
5
intuitive visual interface and mechanisms to easily share and collaborate with these processes. Narratives are formal,
visual descriptions of the design process that include representations, reasoning, and their interrelationships [4].
Narrator addresses the communication deficiencies of Geometric Narrator, but at the expense of its integration
power. Decision Dashboard [17] improves transparency by clearly communicating options, alternatives, and criteria,
and it contains some preliminary ability to compute values associated with these process nodes from information
contained in related nodes. However DD is a single user tool that does not easily support multi user sharing and
collaboration. MACDADI [9] further communicates the people, tools, goals, preferences, options, analyses, and
decisions associated in design, and contains some mechanisms for collaborative modeling. However, like these other
current CIFE tools, MACDADI is not well integrated into BIM-based design and analysis tools, limiting its
computable power.
4.5 KNOWLEDGE SHARING
Conklin [18] explains a “project memory system” to explicitly define informal knowledge and make it available to
others. He observes that the system is necessary, because organizations lack the ability “to represent critical aspects
of what they know.” Conklin and the authors share a similar focus on the “design of project memory as an
evolutionary stepping stone to organizational memory.” However, Conklin (1996) generally applies this system to
capturing knowledge from meetings, whereas we focus on capturing design process information.
4.6 OPEN SOURCE
Software, media, internet companies, and even academia open up their domains and turn to the crowd to tackle huge
challenges in their industries. Successes include Wikipedia and Linux, but there has also been open-source successes
in highly technical and specialized fields in AEC (e.g. The Pacific Earthquake and Engineering Research Center
developed the Open System for Earthquake Engineering Simulation, OpenSEES) [19]. These crowd-sourcing open
source movements transcend traditional organizational science explanation for why people innovate. Hippel and
Krogh [20] propose that the open source movement falls in a new category of the innovation model called “PrivateCollective.” The “private investment” model assumes that the innovator receives returns from private goods and
efficient intellectual property protection. The alternative “collective action” model assumes that when the market
does not deliver a desired result, innovators collaborate to produce for the public good. In the proposed privatecollective model, Hippel outlines the following characteristics:
• Contributors must learn from the experience to contribute.
• Contributors should profit from networking effects of sharing or at least, not lose any money by sharing.
• Contributors must receive “selective incentives,” such as a sense of ownership or enjoyment of the
process.
The development of a process modeling tool and sharing methodology and tool can learn from open source and
crowd sourcing success stories. This paper proposes an analogous approach to capitalizing on BIM through many
individual interoperability solutions.
5
REQUIREMENTS FOR A PROCESS SHARING PLATFORM
The case studies demonstrate how a lack of interoperability process development and sharing impact the efficiency
and effectiveness of the design process. Motivated by the cases and the survey, we define several requirements for a
web-based collaborative and interactive Process Integration Platform.
5.1 TRANSPARENT
A transparent design process is quickly and accurately understood by those not involved in the design. AIA Vice
President Norman Strong states the perfect vision of Integrated Practice includes “a world where all communication
6
throughout the process are clear, concise, open, transparent, and trusting: where designers have full understanding of
the ramifications of their decisions” [21]. The AIA released a Working Definition – Integrated Project Delivery with
seven essential principles. Based on feedback, the AIA committee issued supplemental information emphasizing that
“Interoperability exists on the human level through transparent business exchanges” [22]. Ballard also predicts that
“transparency of the design process” from a particular perspective of process is conducive to the successful outcome
of design from that perspective [23]. Kunz in his discussion of the benefits of IBIS, also stresses the importance of
its ability to increase transparency [24].
In the first case, the lighting engineers’ process is hidden from software companies, managers, architects, and
other lighting engineers. No individual fully understands the opportunities for improving the process and so, no one
works together to improve the process. For the structural engineer, even if a search revealed that others in the
company wanted to use a building model for environmental impact analysis, no formal documentation of that process
exists, and so, it would be very time consuming for the engineer to find the appropriate interoperability solution for
his needs.
5.2 USABLE
Most engineers do not have the time to extensively document their design processes. They rarely have time to learn
how to use new tools. The user-interface for process modeling and searching must be intuitive and not require
significant training or tutorials. We include usable as a requirement due to the concern for user-friendliness
expressed in the survey (Table 2). Strategies for product implementation also stress the importance of a customer
focus (e.g. Six-Sigma [25], Quality Function Deployment [26], and Agile Development [27]).
5.3 INCENTIVIZED
In Section 4.6, we used Hippel and Krough’s explanation of the open-source model [20] to explain why designers
require incentives to use process modeling and to develop interoperability solutions. These incentives may be
embedded in the tool, and/or in the company organization. To be successful, the first user of P.I.P. must find value in
its use even when no other processes or interoperability links exist. The first user is incentivized to use P.I.P. to:
1. Align stakeholder goals with design decisions.
2. Document the reasons behind design decisions to reduce revisiting previous decisions, to better transition
between team members.
3. Search project information.
4. Manage design versions.
5. Assist managers in assessing the current state of the project.
6. Understand the impact of changes on other disciplines.
7. Create a gateway to a central project information database.
8. Audit projects and conduct design reviews.
A detailed explanation of these features is beyond the scope of this paper, but many of these advantages are
discussed in Design Rationale research [14].
Once in use, P.I.P. can also incentivize the development of interoperability solutions by:
1.
2.
3.
4.
5.
6.
7.
Identifying the large cost of non-value added time due to poor interoperability.
Bringing users of similar processes into small communities where co-development can occur.
Rewarding developers with recognition for their work.
Ensuring that the impact of development is widespread
Identifying the processes where returns on investment in interoperability solutions will be greatest.
Allowing developers to start from mixing and matching existing solutions rather than starting from scratch
Providing a plethora of case studies on which to base solution development.
7
5.4 SEARCHABLE
Users must be able to search for processes under multiple criteria, and the searching algorithms must be intelligent
enough to understand multi-discipline and multi-cultural users and their context. Conklin points out that you cannot
preserve organizational knowledge by simply “capturing lots of information,” but that it must be managed in ways
“that create and preserve coherence and ‘searchability’” [18]. For example, when searching for “material
responsibility,” the search engine should ask the user if he wants to also search for “material sustainability” or
“embodied energy.” Also, the search engine should learn that a structural engineer searching for a “wall” wants
processes involving the structural design of a structural wall, whereas an architect may want to look at designs
involving partition walls.
5.5 MODULAR
The solution must allow users to combine several parts of other processes into a new process. It should also allow
geographically separated engineers to work on different parts of an interoperability solution and then combine their
work. This modularity does not suggest a specific data schema or software standard, but rather recognizes that a
universally accepted standard may never exist.
Modularity can also be viewed as the ability to use old processes as the basis of new processes. The development
of new design processes is a creative design process in itself. Organizational scientists view modularity as important,
because, “creative solutions are built from the recombination of existing ideas” [28].
5.6 SCALABLE
Designers must be able to choose how to scale their products and processes. For example, a structural engineer may
perform one process on concrete beam section, a different process on the concrete beam, and an entirely different
process on the entire building. Fischer explained that product models must exist at different levels of detail [29].
Representations of the processes that create various detailed levels of the model must also exist at different scales.
The process modeling must permit interoperability solutions developed for any level of detail.
5.7 COMPUTABLE
The platform must allow designers to automate processes, so that users can drive processes from the process
integration platform. Haymaker [4] explains how automating narratives improves multi-disciplinary design
processes.
6
A NARRATIVE SCENARIO FORMALIZING THE CASE STUDY PROCESSES
We have given two examples of current challenges faced by engineers and validated the generality of these examples
with a survey. We proposed seven characteristics for a successful P.I.P. and explained previous attempts at
improving design processes. Now, we use a narrative to formalize the case design processes and assess this Narrative
for the seven characteristics of the P.I.P.: Transparent, Usable, Incentivized, Searchable, Modular, Scalable, and
Computable.
6.1 DESIGN SCENARIO
It is early Scheme Design for a new library on the Stanford Graduate School of Business. Through the use of
MACDADI, the stakeholders have communicated their relative value for, among other objectives, a design solution
with good lighting and reduced energy consumption. The design team is considering two geometric options for the
library atrium.
8
9
Figure 2. (a) Lighting consultant adds Day Light node to analysis process to the library project. (b) Designer searches for appropriate Day Light
analysis processes.
10
Figure 3. (a) Designer browses search results; (b) looks at process info; finds two appropriate processes. (c) Working with
the user community, (d) he automates one process.
11
Figure 4. (a) Designer drags and drops two process modules from other projects into this project, (b) saves project’s analysis files to the process model,
follows automated and manual steps; (c) and produces analysis results.
A meeting between the architect and the engineering team produced some sketches for an atrium option that
extends in part to the basement and one that stops at the ground floor. The architect creates a Revit Architecture
model using those sketches and has just saved the model as a node in the web-based process model shown in Figure
2. The engineers then begin using that model as the basis for their individual analysis. The lighting engineer wants to
create a video of the daylight moving across the space, so the architect can see the different aesthetics of the two
options. He also wants to calculate the total energy required to light the basement for the two options, so that the
mechanical engineer can use this information for a preliminary energy analysis.
The lighting engineer opens P.I.P. in his internet browser. He searches for “Input: Revit Architecture,” “Output:
Lighting Energy Use” (Figure 2 (b) ). The search results display various projects that meet these criteria. He sees in
the Process Info window (Figure 3 (b) ) that the process for the E Cubed Laboratory project has just been used twice,
but that various links in the process have been copied into other projects 31 times. On average the process takes 22
hours to complete. Thinking that the process could easily be more efficient, the lighting engineer asks the community
of users (Figure 3 (c) ) whether they want to pool resources and invest in automating the process (indicated by the
green arrows). The lighting engineer selects the process from a previous project and copies just the process (not the
information) into the Stanford GSB project (Figure 4).
The lighting engineer finds another process used on a different project to produce day lighting movies, but does
not attempt to automate it. He selects just the applicable parts of the process and again copies it into the Stanford
GSB project (Figure 4).
He then connects the new processes to the existing Revit Architecture model. The P.I.P. automatically runs
software on the desktop computer to produce lighting energy output, which can then be used by the mechanical
engineer for energy analysis simulations. The video making process is not automated and so, the engineer goes
through each step in the process using the appropriate software. While not automated, the information created is
saved to the process map, so it is easily accessible (if security privileges are granted) and understood by the entire
project team.
Results (shown in Figure 4 (c) ) are directly linked to the processes that produced them, so users can quickly
compare options and understand the processes producing the results. The lighting analysis results can be taken by
the mechanical engineer as inputs to his energy analysis as shown in Figure 2.
7
EVALUATING NARRATIVES FOR P.I.P. PROCESS SHARING REQUIREMENTS
Do P.I.P. designers use more efficient and effective processes? In this section, we describe how we intend to test
P.I.P. first with student charettes and then, on real projects with professional designers. In Phase 1, we observe
current design processes. In Phase 2, we introduce P.I.P. to the same group of students or designers and again
observe design processes.
Based on observations of several student and professional design processes we have broken down design into the
tasks shown in Table 3. We ask designers to track their design processes and categorize their tasks according to this
list. From this list, we determine the percentage of time spent on value added tasks, which will permit the
measurement of process efficiency, defined as:
Efficiency = Value Added Time / Total Process Time
(1)
From this equation, we will compare the relative efficiency of various processes currently in practice and will
measure whether P.I.P. improves efficiency.
The effectiveness of the process is more difficult to measure. We take three approaches.
1. Design Options Considered: We presume wider exploration of the design space increases the likelihood
of finding a better design solution. Processes that permit wide design space exploration are more
effective.
2. Designer Review: We will interview designers about the quality of the results produced by the processes
they follow. This interview will allow us to compare the effectiveness of various processes.
3. MACDADI: Effective processes should result in designs that better meet the goals of the designers. We
will use MACDADI to score the quality of the designs produced by various processes.
12
Table 3: Breakdown of design tasks. The efficiency of the design process is evaluated based on these tasks and their
corresponding assessment of value.
MODEL
PLAN
Task Type
1
search
look for best practice process
and modeling methods.
2
attain
obtain software, models,
geometry, drawings, codes, etc.
3
strategize
4
develop
5
translate /
filter
identify design goals,
constraints, and context and
decide appropriate modeling
process.
create new tools and methods to
faciliate design process with the
intent of reuse.
redefine information in a new
format; simplify, regroup, or take
a subset of information.
6
generate
define a model of the physical
world for the first time.
7
setup /
preprocess
8
calculate
give instruction to the computer
about how to analyze the model
you generated.
converting inputs to outputs
according to formulas, tables,
graphs, etc.
9
interpret and
validate
10 troubleshoot /
POST-PROCESS
Definition
fix
11 document
understand results and assess
whether the simulation results
are reasonable.
find problems with the model,
correct the problems.
communicate results and design.
results &
design
12 document
process
13 other
communicate design tasks and
assumptions.
a task that does not fit above
Examples
Ask people in your office who
has performed similar tasks.
Google "how to perform lighting
analysis using a Revit model."
Look around the office for the
current drawings or the CD with
the right software. Ask the
architect for the latest drawings.
Sketch a simplified analysis
model. Write out design of
experiments for your
simulations.
Writing scripts, wrappers, or
spreadsheet templates.
Export model as .dwg. Import
model. Select part of a building
or a subsystem for export,
change 3d to 2d.
Assigning a beam size, a window
type, defining louver
configurations, defining building
loads, assigning mechanical
zones.
Setting time steps, analysis
algorithms, describing desired
output, meshing.
Performing hand calculations,
using Excel spreadsheets,
Mathcad, looking up values in
tables.
Comparing model results with
quick calculations to check
whether numbers are reasonable.
Searching for the reasons behind
error messages, adjusting the
model to eliminate errors
Take screenshots, write reports
describing the final design,
creating sketches, drawings, or
models based on interpreting
results.
Write a report to your client
explaining your design
assumptions. Track your steps,
so you remember the process in
the future.
N/A
Value
Added?
No
No
Yes
Yes
No
Yes
Yes
No
Yes
No
No
No
N/A
13
By combining these three measurements, we can determine the relative effectiveness of processes with similar input
and output, but different information flows. Again, we will measure effectiveness before and after the introduction of
P.I.P.
8
CONCLUSION
This paper described studies where engineers are not drastically improving the efficiency and effectiveness of their
design process despite the availability of a 3d object-oriented model. A lighting engineer failed to develop an
improved interoperability solution and a structural engineer failed to find an interoperability solution already in use
by others. To increase the development and sharing of design processes, we develop a Process Integration Platform
(P.I.P.) according to a framework of characteristics: Transparent, Usable, Incentivized, Searchable, Modular,
Scalable, and Computable. We explain how this framework is used to develop a web-based collaborative process
modeling tool that will allow AEC to better develop and share design process solutions. We then propose a novel
method for evaluating P.I.P.’s ability to improve the efficiency and effectiveness of design processes.
9
REFERENCES
[1] Eastman, C. (2007). Building information modeling. . What is BIM? Georgia Tech, AEC Integration
Laboratory. November 2007. Available Online: http://bim.arch.gatech.edu/content_view.asp?id=402
[2] Autodesk Revit Building Information Modeling: Transitioning to BIM. Available Online:
http://images.autodesk.com/adsk/files/transitioning-to-bim_jan07_1_.pdf
[3] Government Services Agency (2007). GSA BIM guide overview. Available Online:
http://www.gsa.gov/gsa/cm_attachments/GSA_DOCUMENT/GSA_BIM_Guide_v0_60_Series01_Overview_05-14-07_R2C-a3-l_0Z5RDZ-i34K-pR.pdf
[4] Haymaker, J. (2006). Communicating, integrating and improving multidisciplinary design narratives. Second
International Conference on Design Computing and Cognition, Springer Netherlands, pages 635-653, 2006.
[5] Toast (2004). Questions about dxf import code for a revit-to-blender tool. BlenderArtists.org. September 27,
2004. Available Online: http://blenderartists.org/forum/showthread.php?t=30227
[6] McGrew, J. Revit to radiance (via an expensive translator...). Because We Can. Available Online:
http://www.becausewecan.org/node/190
[7] Young, N.W., Jr.; Jones, S.A.; Bernstein, H.M. (2007). Interoperability in the construction industry,
SmartMarket Report: Design & Construction Intelligence. McGraw Hill Construction. 2007 Interoperability
Issue.
[8] Yudelson, J. (2007). LEED-ing the way. Building Sustainability. Builder Group. October 23, 2007. Available
Online: http://www.building.co.uk/sustain_story.asp?sectioncode=747&storycode=3098129&c=3
[9] Haymaker, J.; Chachere, J. (2006). MACDADI: A methodology for systematically & transparently achieving
breakthrough quality. Center for Integrated Facility Engineering, Stanford University, TR 10-1-2006.
[10] Tobias, J.; Haymaker, J. (2007). Model-based LCA on Stanford's Green Dorm. International Life Cycle
Assessment Conference. Portland, Oregon. October 2, 2007.
[11] American Institute of Architects (2007). Integrated practice. Available Online: http://www.aia.org/ip_default
[12] International Alliance for Interoperability. Available Online: http://www.iai-international.org/
[13] Lee, G.; Eastman, C.M.; Sacks, R. (2007). Eliciting information for product modeling using process modeling.
Data & Knowledge Engineering, Vol. 62, pages 292-307, 2007.
14
[14] Moran, T.P.; Carroll, J.M. (1996). Design rationale: Concepts, techniques, and use. Lawrence Erlbaum
Associates, 1996.
[15] Conklin, E.J.; Yakemovic, K.C.B. (1991). A process-oriented approach to design rationale. Human Computer
Interaction, Vol. 6, pages 357-391, 1991.
[16] MacLean, A.; Young, R.; Bellotti, V.; Moran, T. (1991). Questions, options, and criteria: Elements of a design
rationale for user interfaces. Human Computer Interaction, Vol. 6, pages 201-250, 1991.
[17] Kam, C.; Fischer, M. (2006). Decision breakdown structure: management of decision basis to enhance decision
making in the building industry, Joint International Conference on Computing and Decision Making in Civil
and Building Engineering. Montréal, Canada, pages 2334-2343, 2006.
[18] Conklin, J. (1996). Designing organizational memory: Preserving intellectual assets in a knowledge economy.
CogNexus Institute. Available Online: http://cognexus.org/dom.pdf
[19] Peng, J.; Law, K.H. (2002). A prototype software framework for internet-enabled collaborative development of
a structural analysis program. Engineering with Computers, Vol. 18, pages 38-49, 2002.
[20] von Hippel, E.; von Krogh, G. (2003). Open source software and the “private-collective” innovation model:
Issues for organization science. Organization Science, Vol. 14, pages 209-223, 2003.
[21] Broshar, M.; Strong, N.; Friedman, D.S. (2006). Report on Integrated Practice. American Institute of
Architects.
[22] American Institute of Architects (2007). Integrated project delivery - a working definition. McGraw Hill
Construction. May 15, 2007.
[23] Ballard, G.; Koskela, L. (1998). On the agenda of design management research. Proceeding IGLC, Guaruja,
Brazil. 1998.
[24] Kunz, W.; Rittel, H. (1970). Issues as elements of information system. University of California at Berkeley,
Institute of Urban and Regional Development.
[25] Pheng, L.S.; Hui, M.S. (2004). Implementing and applying six sigma in construction. Journal of Construction
Engineering and Management, Vol. 130, pages 482, 2004.
[26] Chan, L.K.; Wu, M.L. (2002). Quality function deployment: A literature review. European Journal of
Operational Research, Vol. 143, pages 463-497, 2002.
[27] Ramsin, R.; Paige, R.F. (2008). Process-centered review of object oriented software development
methodologies. ACM Computing Surveys, Vol. 40, No. 1, Article 3, February 2008.
[28] Hargadon, A.B.; Bechky, B.A. (2006). When collections of creatives become creative collectives: A field study
of problem solving at work. Organization Science, Vol. 17, pages 484, 2006.
[29] Fischer, M.; Froese, T. (1996). Examples and characteristics of shared project models. Journal of Computing in
Civil Engineering, Vol. 10, pages 174-182, 1996.
15