Delivering on the promise of expertise-driven design requires a carefully planned approach that not only manages project information throughout the organization but also extends the value of this information by sharing compelling stories with internal and external consumers.
My article in the May/June 2010 issue of DesignIntelligence, “IT for Strategic Advantage,” describes one way that strategic investments in IT software and infrastructure can begin to support a method for creating, capturing, and sharing corporate information on a routine and highly structured basis.
Here, I’ll extend those ideas, sharing thoughts about how to capture corporate information for robust rediscovery and how to craft “digital project stories” that drive continual learning throughout a design and engineering organization.
A brief recap of my three-year Create/Capture/Share IT strategy is a convenient place to begin illustrating how my firm, Einhorn Yaffee Prescott Architecture & Engineering, works with design information. Certain technology solutions tend to specialize on design authoring for a specific project, while other solutions, focused more on capturing project workflows, can capture and present information across multiple projects. Still other solutions enable collecting, presenting, and representing content gathered from diverse sources. All of these solutions play an important role in an organization’s overall IT strategy. The selection of a particular technology solution brings with it an underlying decision framework that embraces certain functionalities while disregarding others.
Regardless of your specific technology solutions selection, critical to the digital project story approach is the need to build stories in a dynamic and cumulative manner so that information is created automatically as a part of the daily project workflow.
The case for the digital project story
The digital project story concept was born from issues facing an expertise-driven practice. In our case, given EYP’s corporate mission to deliver expertise-driven design to clients, the need for easy, meaningful access to information and corporate-wide project experience has never been greater. IT can support this objective three ways. First, it can remove barriers that might otherwise prevent our experts from finding what they need. This is accomplished by creating, capturing, and sharing our historical expertise as meaningfully and seamlessly as possible.
Second, projects are increasingly accomplished through teams across multiple office locations. This trend will continue as project teams become ever more diverse and distributed and are required to work in ever more integrated fashions. As the lines between project teams blur, it becomes even more important for IT organizations to understand the contributions and expertise they can bring to an integrated and collaborative team.
Third, given the sheer quantity of applications required of modern design and engineering practice, is it reasonable to think that the average practitioner is able (or even has time) to learn the rich complement of applications required to drive the business? I suspect that 100 or more applications are used throughout a typical organization. Typically, no single person is facile with the full array of design, engineering, finance, process, and imagery applications at use in a firm. And if such an individual exists, does he or she also have the practice experience sufficient to extract and aggregate appropriate information from each application to create a complete project story? I suspect that few people are capable of this, especially at the managerial or executive level where this type of information could support high-level corporate decision making. If you have one such person in your organization, consider yourself lucky.
Doers and Viewers
It is from the vantage of this last observation that I have started to think hard about roles within our organization—what I refer to as the doers and the viewers. The truth is we are all doers for some tasks, and we are all viewers for others. Some applications we use on a daily basis, while others we may use only a couple of times a month, if that. Many mainstream applications developed for the architecture/engineering/construction industry are really designed for doers with little attention given to the needs of viewers. So in an integrated practice, the viewers are at the mercy of the doers when it comes to accessing key project information.
Here is an opportunity for software developers to grow the total addressable market in existing client-install bases by taking better advantage of the rich information that building information modeling, enterprise resource planning, project information management, and digital asset management has to offer, specifically to the viewing and consuming audience. But even if leading A/E/C technology providers were to develop specific applications for their viewing consumers within the next few years, the intricacies of professional practice requirements would need to be addressed from within the design organization. We would still need to craft our own digital project stories.
Project Views vs. Project Stories
As I began to share the concept of digital project stories with select partners within and outside of EYP, it became clear that I needed to provide visual diagrams of how this might work. Conveying these ideas through discussions of technology alone was just not going to cut it. In fact, the EYP partners I needed to engage were often those who, while closest to our project work, were least adept with the technologies. Such individuals constitute the very group that digital project stories are intended for. The device of the digital project story provides a handy conceptual framework and conversational bridge between technology investment and business strategy.
There are many ways to carry this process forward. At this early stage, I simply need to develop rough visual concepts that can engage and stimulate more in-depth discussions with key stakeholders. To that end, I began looking at Web sites that embodied some of the traits I would want for our story structure. Ultimately I discovered Infragistics, a company that is creating what it calls “presentation layer development tools.” I liked the look of its presentation tools, and the model of layering rich presentation graphics on top of database-driven applications seemed to be in line with my Create/Capture/Share content management strategy. I was specifically drawn to Infragistics Faceout (Figure 1), which demonstrates the rich visualization functionality of Microsoft’s Silverlight tools (requires download).
Thinking that I might end up using the Infragistics presentation layer tool set to build some of our own design ideas, I proceeded to use Infragistic’s Faceout prototype site as a template for developing three conceptual views of project stories appropriate to our business. Again, reflecting back to our point of departure, as the corporate mission statement is the driving force, I quickly drafted three ideas for project views: expert (Figure 2), customer (Figure 3), and project (Figure 4). In each case, information could theoretically be pulled from a variety of sources, including Microsoft Active Directory, Microsoft Office Sharepoint Server, Deltek Vision, Axomic OpenAsset, Newforma Project Center, and Knowledge Architecture’s Nexus Database. Amazingly, simply constructing and sharing these very crude concepts with various internal and external partners was enough to spawn more detailed conversation about what we might really want to do and how we might evolve these ideas into dynamic digital project stories rather than static views of our project work.
New Form Factors
As the world changes, options for how and when we work evolve. For example, with the release of Apple’s iPhone, iPod, and iPad, we can think about our work (and more specifically how we execute and view our collective work efforts) in innovative ways. These devices have been highly successful in addressing the consumer market.
So far, I’ve really just shown examples of project views; what I really want to get to are project stories. What’s missing? Or what might be added to the existing concepts to make them more story-like? Context.
The real objective is not just to capture discrete moments in time (or views) and not just to compare data from across projects and develop new analytics and intelligence from those comparisons (although these are all wonderful and necessary ). We also want to capture how we got to this moment in time and what happened to us along the way. What was—and is— the experience of participants in and users of the project? Doing so will also help us better understand our own processes and procedures: How do project teams present their design ideas, make decisions, and collaborate to achieve their final results? It will help us gauge whether or not a building is performing as intended. Did we achieve the expected results? If not, why? How can we do better next time? How we can conveniently deliver this content to devices that our consumers are using?
Thinking and Knowing
Capturing not only the design solution but also the journey of discovery and creativity along the way is challenging but worth the effort.
Human beings are curious, especially about where things come from. The added value of the project story is how it reveals the process of inspiration and creativity that transforms knowledge and experience into design. I think of this process as similar to how designers evolve design ideas over time by overlaying drawings with tracing paper. Layer after layer of tracing paper allows the designer to generate ideas that inform, modify, transform, and refine ideas over time. Drawing becomes a decision-making process. It’s a mode of thinking that helps designers develop increasingly refined conclusions and better understand the trajectory of their creativity.
The overlay trace process is a convenient mechanism for sharing the final design intent as well as the path that delivers a particular conclusion. In design school, design critics and jurors often want to see not only the final deliverables but also how the thinking evolved along the way. Perhaps this is a case of what’s old being new again. There are lessons to be learned from traditional design process models, models that can help us capture our thinking and knowing processes over time.
Actions, Attitudes, and Artifacts
To explore this approach further, which modern means and methods might inform the way designers have been working for decades? Are there more efficient and accurate methodologies and technologies that can provide better, more accessible information all along the way? I think so. Adding a digital project story approach to the designer’s arsenal allows more time to focus on what really matters. Digital format also opens up another realm of options for quickly capturing still images as well as ideas in motion, ideas through sound, etc. A much richer design palette can be readily available at the very point of design decision making. At the same time, design iteration can be made more efficient and meaningful as we develop ways to deliver higher-quality content and less clutter.
Careful consideration of our actions, attitudes, and artifacts helps us focus attention on what is important from a business perspective. It’s about how we choose where to spend our time; what our thinking is at any given moment during the process; and how we evolve our ideas into a final design solution. There are countless examples — from Stonehenge and the great cathedrals of Europe and beyond. Hundreds (if not thousands) of great architectural and engineering works throughout history resulted from the efforts of large groups of people highly focused on delivering significant artifacts. In each case, the artifact is just one portion of the more interesting and informative story that speaks to why it is as it is.
When it comes to telling the compelling project story, it’s not simply where we landed or what the final design solution was that matters but also the journey and process that got us there.
Pioneers and Performances
We can’t capture every single thing we do or every detail of our efforts. So how do we decide what’s worth capturing? We begin by circling back to what is important for achieving the firm’s mission. In our case, EYP needs to deliver expertise-driven design. We can start to capture what’s worthwhile by considering our organization’s pioneers and game changers, i.e., our experts. What do they do differently from others? How do they achieve success on a regular basis? What do they feel they’ve learned along the way, and how that impacts future project efforts? How did their clients perceive and experience the project and the process?
It may be that the best ideas in your organization are not coming from those who have been in the firm or in the industry for the longest time. Although there are plenty of examples where experience yields great ideas, some of your firm’s best ideas may come from recent graduates or intern architects and engineers. Often it’s easier for those who are not close to project work, even those who are not formally trained practitioners, to come up with fresh perspectives on the problem at hand. One thing I like about working in a multidisciplinary A/E firm is the variety of perspectives from which problems can be solved and solutions tested: Project work can be explored from many different angles of expertise, not just from an architectural viewpoint. This multi-faceted approach enriches the process and results alike.
Capturing the ideas of your experts is only one aspect of the equation. How we share and deliver our ideas and values is of equal importance. How is our message conveyed? How is the performance received? How do we execute on our values and, by the way, who is actually listening? Performance is always a critical issue. How did the project manager guide the project team? How did the team collaborate with partners outside the organization? How are our design ideas and values received when we present them to project stakeholders?
Ultimately, the questions that you ask are probably as important as the answers that you receive. All of these should correspond to the firm’s mission and tie directly into the firm’s attitudes about actions, attitudes, and artifacts.
Interpreting and Evaluating Your Story
At this stage in EYP’s quest for the digital project story, there are many more questions than answers, but that shouldn’t stop us from moving forward and making decisions based on the best information available today. In fact, that process itself will help us learn more and create better digital project stories going forward. My ultimate goal is to capture our processes and ideas to the degree that it makes sense for our business; to present this information in a format that is efficient, meaningful, and compelling to consumers; and to enrich our digital project stories with ideas that matter.
There are many sources of inspiration around us, but the A/E/C story is unique. Our designs, our engineering, our construction, our craft, our users of the built environment — all of these should directly inform and inspire how we create, capture, and share our stories. I anticipate that every firm’s story will uniquely reflect its work and organizational values. I could go on ad infinitum about digital project stories (the topic is truly vast), but at this juncture I’ll sign off with one final and important question that I think that every firm needs to ask itself.
What’s my story?
Brad Horst is a principal and chief information officer at Einhorn Yaffee Prescott Architecture & Engineering . He is responsible for driving the technical and strategic vision of the firm’s IT organization. Before joining EYP, he was a product marketing manager for architectural solutions at Autodesk, where he was responsible for marketing the Revit Architecture software application. Horst earned his Master of Architecture degree from The Ohio State University and is an NCARB-certified architect.