The Upstream Series is an essay series where Dean Reed engages with the leading practitioners within the AECO community. The goal of the upstream series is to improve how design and construction projects are delivered by asking the question "what should be done upstream to make design and construction better?". In this series, each person will share a few ideas that the industry should adopt and use to make projects faster, safer, and better value for the money.

The design build industry revolves around managing experiences. We apply experiences from past projects to current projects. Without it, projects fail. When we try to acquire new projects, we do so by advertising our relevant experience from past projects to our clients. We are hospital builders, we know how to design laboratories, we do data centers. When we hire employees, we look for people with the relevant domain expertise to manage our projects. That's good, but it's also rather old school. "Why?", you ask? Because few firms are able to manage their experiences in a systematic manner. And that's a shame, given the importance.

So how should we learn from experience? I believe that experience in its most essential form manifests itself in being able to ask the important questions at the right time. Regardless of your role in a project, if you can ask the relevant questions when they should be addressed, you are adding value. Even better if you have answers.

Because the design build industry is so fractured, asking the important questions at the right time is not as easy as it sounds. The entire value creation chain from design through construction to operation can take years, with different firms serving only certain parts of this chain. As a result, it's hard to understand this chain and it's hard for knowledge to flow upstream, from operations and construction to design. The design phase in particular is difficult to understand. In the construction phase the dependencies between tasks are obvious - you can't paint a wall before it has been installed - and the quality of the end product is easily inspected. In the design phase the sequence of activities and the dependencies between the design trades are much less apparent, especially to the inexperienced. Also, it's relatively hard to tell if a product meets the quality required for the subsequent design phases.

So how is a Superintendent going to provide input to the design of a project that he'll perhaps be working on in two years, while he's currently trying to address issues on the current project now that they are coming hot and heavy? How is he going to ask these important questions at the right time?

How do you know at what point in the project a certain question should be asked? What's the right time? How do you make sure that these conversations happen reliably and are not left to chance? For this, I believe that you need a general process map that shows how design and construction works. This map needs to cover all phases of a project, from design through construction and commissioning and it must cover all participants in their respective swim lanes. This is important because you need to be aware of how your efforts fit in with those of other firms. Too many firms concentrate on their swim lane only.

How detailed does this process map need to be? At the top level, it should identify what decisions need to be made by when and by whom. At the next level it should identify what products are required to make these decisions, and what they require, so the decisions are sound. Finally, the process map needs to identify the tasks required to create these products and show the dependencies between products and tasks.

I like to compare this process map to the GPS navigation system your car uses. Instead of telling you which freeway exit to take or where to turn at the next intersection, your process map will tell you what decisions are upcoming, what products will be required, and what activities need to occur in preparation.

Most importantly, this process map allows you to identify when the important questions need to be asked. In other words, it allows you to connect your experiences with the process. Think again of the GPS system in your car: the roads represent the process; now we add the equivalent of the locations of the gas stations, the restaurants, etc. At each turn or intersection, we can tell you what questions should be addressed.

Now we don't necessarily need the Superintendent to be present and ask the important questions at the right time. Now we have a system in place that allows his questions to be asked when he's not around. We've developed a framework for upstream transparency!

No matter how you manage your expertise, ask yourself how you can apply it by systematically asking the important questions at the right time in your projects!

Why does this all matter? Can't we go on building projects like we always have, treating the occasional and reoccurring problems as a nuisance or even as part of doing business? Our industry is optimized to deal with these problems. We identify the culprits, we back-charge, we write a change order, we file a claim.

Maybe. But it has always bugged the hell out of me because it's both wasteful and avoidable, and because as professionals, we should have higher standards and strive for excellence. (Not to mention that we could reduce project costs by about 1.3% and cut fee erosion by a substantial percentage).

I became interested in these topics while working for a large general contractor just as the internet started to gain awareness. Initially, we collected best practices in Technical Bulletins and published those on an intranet. We spread good ideas throughout the company with a quality award program. It was fascinating to see how much knowledge really existed in the company. I had my go-to people if I needed to talk about innovation (there weren't that many; maybe a dozen in a company of about 1'000). I had my go-to people if I needed to talk about optimizing existing processes (there are many more of those than innovators). I learned that often seasoned Superintendents were much more interested in new ideas than young ones. I learned that trade contractors or suppliers act as pollinators for good ideas between general contractors, provided you asked them ("Let me tell you what I just saw on this other job site …"). I became fascinated with how knowledge was created and traveled around projects and companies, ferried around by people.

In the early 2000's I developed a software tool based on web pages, which allowed employees to gather and share experiences from projects in a structured manner with checklists for design and submittal reviews, as well as field quality, and items to look out for in estimates. I implemented several of the ideas described above, albeit in a somewhat clunky form. But at that time, it was hard to find investors who were interested in the construction industry and wanted to fund the development of this tool. I worked in the construction industry, because it was so hard to change, and because I felt like in my mind I had solved the problem that interested me with my knowledge sharing software, whose checklists were now in use by a few GC's.

I spent the next few years working in Switzerland, first for a large utility company, then for a large general contractor. I had walked away from knowledge management, but it was still following me: in our projects we weren't learning from our mistakes, we blamed unforeseeable circumstances or other firms when things went wrong. We just shrugged about how architects, trade contractors, owners, whoever, just don't get it. It's something you can't change. Yet it was obvious, and I knew that there was still a big problem waiting to be solved. I spent a few years mulling over possible solutions before deciding to re engage and take another crack at knowledge management.

This time I decided to work for a construction manager who interacted closely with architects and designers in the design phase. My goal was to understand what goes on upstream, where buildings are designed. I wanted to understand the challenges those firms face, that we had always complained about. Switzerland is a good place to do that, because architects see themselves as direct descendants of the old master builders, who act as the fiduciary of the owner and manage the project from design through construction. How well that works is debatable, but there is a thriving design industry in Switzerland.

After 20 years in managerial roles, I found myself managing a project again and being able to put to the test my notions about how knowledge management should work and trying out new ideas on my project. On the side, I hired a couple of software engineers to develop an updated version of the knowledge management software. Obviously, knowledge management had caught up with me and was again my passion.

As an outsider, coming to the design industry from construction, I was constantly asking questions. After I left my employer to concentrate on my startup, I organized a working group of professionals from all design disciplines (architecture, structural, MEP, building automation, fire protection, etc.) to map the ideal design process and create a production model for the design phase. We've been meeting regularly for the past 2.5 years and initially I was surprised to see how hard it was to reach an agreement about the sequence in which the design process should proceed. That's when I realized the importance of the process map that I described as a framework earlier in this article.

While I'm convinced about the importance of bringing structure to project management, I’m also aware of its limitations and what structure can’t do. Could my knowledge management software and a process model replace project management, like I initially wondered? No, because I now know that ultimately, it’s the human interactions that make a project successful. It’s satisfying to know that, and it's satisfying to be able to provide the tools to improve these human interactions.

If you want to learn more about the AppEx software, which is currently being used by owners, GC's, architects, and designers in Switzerland, and which enables the concepts described above, you can contact me at or visit Thanks!

add one

Dean is a long-time advocate, organizer and educator for Lean and Integrated Project Delivery at DPR Construction and throughout our industry. He is member #1 of the Lean Construction Institute and co-author of the book Integrating Project Delivery, along with Martin Fischer, Howard Ashcraft and Atul Khanzode.

Chris Marolf has been working on knowledge management issues with general contractors , owners, trade contractors, architects and CM firms in the Bay Area and Switzerland since 1994. He's the founder of Applied Experience LLC, a software provider and consultancy in the domain of knowledge and process management for the design and construction industry.