Improving Knowledge Flow: The AEC Lessons Learned Pipeline | Christopher Parsons of KA

Okay, I have the pleasure of introducing our next speaker. I've been working on this thing this year, and I want to share it with you guys. So those of you that are on the Twitter or on the LinkedIn saw me share my first slide yesterday. And this is how it is, right? Nobody objects to the idea that sharing lessons learned is a good idea, but where firms struggle is on the execution or they feel guilty. They feel like they're not doing it well enough. And that's a consistent theme. As I've talked to firms about lessons learned over the years that I've been both in practice, but then also at knowledge Architectures. This is one that people feel guilty about and they feel anxiety about, and they feel like we should be doing this better. And so that was one of the big things that drove me to want to work on this project and that I'll introduce to you and tell you about. So at the end of KConnect last year, I asked folks, what are the three to five topics or themes that you want us to explore at KConnect 2018? And I said, roughly, use the periodic table of elements as a guideline, right? And so I gave them this tool and said, tell me what the big things are. And really loudly. What I heard back was, lessons learned is important. That's the thing we want to learn about in 2018. So that was a data point. Many of you in this room know this. But for those of you that don't, we have another community called Kadvance, which is for our clients to help them use synthesis better. And that's a little bit more focused on intranet specifically and not as kind of widely focused on knowledge management. And in the preparation for our fall workshops, which we do three of them across the country in the fall focused on synthesis, we sent a similar questionnaire. What do you guys want to hear about? What are your top priorities? What do you want to learn about this fall? And for that example, we used the Internet maturity model that we've developed, and we said, tell us your top priorities here. And again, lessons learned ranked high in terms of the priorities people wanted to learn about. So four or five dentists agree that this is a topic that everyone wanted to hear about. This made our work really easy in terms of prioritizing agenda for Kaconnect 2018. So those of you that were here last year or saw my talk from last year might remember our friend the badger, the spirit animal of knowledge management. And that was me, right? It's like, great. The path is clear. Here's what I need to learn about. It's time to start digging into this issue and learn as much as I can learn about lessons learned. Those are tricky sentences to string together, but so far I haven't tripped over it. So wide ranging research. So I wanted to look very, very broad like I do when I want to tackle one of these things for K Connect. And so I started outside of AEC and I started by looking at what organizations like APQC have done. So for those of you that don't know apqc, they do a lot of research and development of best practices for knowledge management kind of in general. Right. For the whole world across very large organizations mostly. So Fortune 500, the government, the military, big non profits. They've got a much different lens on knowledge management, but a lot of the ideas still translate. I looked at kind of leading best in class organizations like NASA who as Nick mentioned this morning, is very open about how they work and it makes it really easy to learn some of their processes. I also found Nick and so had the great pleasure of learning Nick reading his book and him agreeing to come share with us. So that started outside the industry and then I turned inside the industry and I was lucky enough to find 30 firms that were doing something. They were self identified, but I kind of asked around and they're like, yeah, we're doing something we think is interesting. It might not be perfect, but we've made some progress against lessons learned. We don't think we're a total failure. And I'd be happy to talk to you and share what's working and what's not, how we've overcame some of those barriers. So over the course of the fall and the spring, I interviewed over 30 firms, some of them a couple times to go into more depth about what they were doing in terms of knowledge. And the key for me was I wanted it to be a very diverse set of firms. So small firms, large firms, architects, engineers, single discipline, multidiscipline, single office, multi office. Because that's the unique, interesting challenge in our industry is you guys are all, here we go, I'm going to contradict it. You guys are different and you approach this, your practices approach it differently and you're different because you have different priorities, you have different cultures and you've got different systems that are already in place. And so I learned that no firm is doing this the same way. But there are some general pieces that we can pull out out of that research. I was lucky to identify the folks that you saw on the stage this morning, but then also some folks who are going to share with you tomorrow some of the work that they're doing. Finally, I got lucky enough to speak at two roundtables full of CEOs in February and run kind of a 90 minute session with each of them just talking about lessons learned, kind of wide ranging. I did about 10 minutes, put some concepts on the board, and we really went around the table saying, what's working, what's not, why is this a priority? And it was immensely helpful. And then some of the folks in this room also spent some time in focus groups with me. So I got to dig really deep. So the question is, what did I learn? And there was a series of questions that really kept coming out, and one of them was, well, why does. Let's take a step back because I think we all kind of assume that we want to do lessons learned, but really, let's try and get a little bit more specific about why firms want to do it. So one of the reasons why, and we've touched on this a couple ways this morning, is to expand that learning that happens on project teams to the overall organization. So you guys have, and depending on the nature of your firm, you have a dozen projects going concurrently, hundreds, thousands for some of the firms in this room. And each day, on every one of those dozens, hundreds of thousands of projects, lessons are happening, right? People are learning things, they're making mistakes, they're doing things better for the first time. And it's just going on and on and on and on and on. And so the worry, right, is that project Team A steps on a rake, makes a mistake, and then six months later, project Team B comes and does the same thing. So at the heart of it, it's this. We want to learn faster and better than just one project at a time. We want to learn as an organization. So how does it benefit a firm? This is, again, I think one of the things that I learned in talking to people is we just take it for granted that this is a good idea. But we're not always as specific about how this improves the business. If we share lessons, then what actually happens that's good, other than improvement, kind of generally. And so there actually are a wide. There's not one answer. This is why I think it's such a compelling topic for people, because there's a wide variety of business outcomes that getting better at sharing lessons can help you with. So for those of you that were here last year or saw last year's talk, I introduced a tool. It's Common business goals in AEC firms that are supported by knowledge. And they're roughly broken out around winning new work, right? Doing the work, managing talent, running the business, and designing the business. So when you have a KM tactic or an intranet tactic, you want to accomplish something. This is a tool to help you map it back to something that the business cares about to help show and create value. And so I went through this exercise about halfway through the interview process and learned that lessons learned maps back to a bunch of different things that the business cares about. So if you're looking at doing the work right, I highlighted delivering projects faster or improving quality or improving profitability of projects in the managing talent. Right. It's getting novices up to speed faster, transferring critical knowledge, improving employee engagement and retention because it feels good to work in a place that's sharing knowledge and getting smarter. And you could probably make an argument for any of these business goals that sharing lessons could help you. So it's clear that this can help improve your company if you get better at it. So that being said, right, this sounds really valuable. So every AEC firm, it follows, must have a lessons learned program if it's so valuable, right? Show of hands. Does your firm have a formal knowledge lessons learned program? Uh oh, right. So why is that true? Why is it that everyone knows that this matters and everyone knows it can help. So why is it so why is it so infrequent that you find a formal program? And I think one of them is, one of the reasons is we see these ad hoc and informal levels done. And so why they don't have it is it's too overwhelming. Right? There's that problem I mentioned. There's too many projects going on, too much lessons happening, and firms aren't sure where to get started because it is somewhat of a complex process and they don't know where to get started and they're busy. All of your firms are very, very busy right now. That's what I hear day in and day out. And so it's, it's this thing where it's like, we know it's important, but we're super busy and how do we do it better? And so what I feel like is it doesn't have to be like this. I hope that some of the things you learned this morning will help you see a path forward to improving the way your firm works with lessons. And I've been working on some things that I hope can help you too. We like building tools at Knowledge Architecture. Some of them are software tools. But Some of them are best practices that you can help. And so this is the beginning. I wouldn't call this a best practice now, but this is the beginning of a tool that we think is going to help firms think through lessons learned. We hope it'll help improve the knowledge flow in your company and can help you diagnose, design, and troubleshoot lessons learned. So my metaphor is a pipeline. We talked about a supply chain earlier, so I'm close. And they both kind of suggest this idea that you move in a somewhat linear fashion, starting with identifying lessons learned all the way through improving the company. Now, it may be overly linear and overly simple, and that was by design. I wasn't trying to come up with something that was the perfect process diagram and fully flexible for every firm size and discipline. What I wanted to do was create a tool that could help us have a conversation about lessons learned and be broad enough and simple enough. They could help us say, where's this breaking down? It's here. Are we doing this piece of it? So as I take you through, keep in mind, it's meant to be simple and it's meant to be kind of linear, but you can take it and make it as complicated or not as you like. So I'm going to walk you through each of the eight steps. Then I'm going to take you through an example to kind of illustrate it, and then I'll dive in deep into each one of the areas to share some of the tactics that I've seen firms do along each stage of the journey. Okay, so we'll start with identifying lessons. We've talked about that a lot today. How do you find out in the first place that these things are happening on projects that there are opportunities to learn? The next step is sharing the lessons learned. So sharing them maybe broadly with the whole organization, but the most important audience is sharing them with the people that can help do something with those lessons to help improve the business. Those folks are going to go through a prioritization exercise, so they're going to figure out which one of these lessons learned we want to operationalize as a company. So you're going to operationalize those lessons learned as new process, updated process as knowledge assets. Once you've done that and created things like checklists and best practices and standards and training classes, you'll want to advertise that there's new knowledge available. People need to know that there's new things that they can take advantage of. Of course, none of that matters if people don't use it or reuse that knowledge. So, so that's the sixth step. Step seven is measuring activity and outcomes. And so when I say measuring activity, that's more like, are lessons being identified, Are they being shared? If they were operationalized, are they being used? So you're measuring, are people doing the things that we hope that they're doing to help improve knowledge flow in the company? Measuring outcomes. Right. Is more measuring the things that business cares about. So did we improve profitability? Did we drive down rework? Did we drive down RFIs and change orders? And the last step is continuous improvement. Right. So then continue to take all that feedback and improve processes and knowledge assets. Okay, so let's go through an example. And I've created a fictitious firm. My apologies if any other firm is named CJP Design in the industry. That wasn't my intention. So My fictitious firm, CJP Design, is a multidiscipline integrated design firm. 400 employees with 12 offices. So they have some challenges. They have an emerging data center practice area, and the knowledge in that practice area is largely in the heads of senior principals and project managers. Their projects are staffed with designers and engineers who are brand new to the project type. They've never worked on data centers before, and they've got sucked in because they've got a bunch of work all of a sudden. So as in existing conditions, they've got a lessons learned that are shared in project team meetings through the buy and buy of project team meetings, but they've also got a monthly data center practice area meeting. So what do they want to do? First, they want to identify and share more lessons earlier on in the project life cycle. So they don't want to wait for projects to be done. They want to get into those projects earlier and share lessons. Second, they want to develop a training guide for new data center designers. So they want to bring them up to speed on the core issues of the building type as quickly as possible. And they also want to publish a data center design guide, and they want to do it by the end of the year. This is. They feel like they're really struggling. They feel like they're inefficient, people are burned out. They really want to focus on this knowledge. So what could that look like? So I'm going to show you some different techniques. So one of the things they could do is do a Q and A process on their intranet and just let some of these young designers and engineers know that if they've got a question, they can post on their intranet. And the right people are Going to see it and can give them answers across those 12 offices doesn't have to be just for the junior designers. So in this example, David had a question about what ups should we use in a data center with a certain voltage and asked for advice on some different choices. Right. And he got some answers back from some of the more senior designers. It could be that they choose to pull a process like we saw from arup, right? A knowledge review. So they might use a set of questions like this. They might use a set of questions like Andrew's to get into Those projects every 90 days or in a project phase or whatever the right cadence or rhythm for that project is. So once those are identified, the core audience that they want to route these lessons back to is their practice area leaders for the data center. I want to make sure that those people see it in their weekly meeting or their monthly meeting, however often they're meeting and they can review those and prioritize which one of those is important to learn. So if there were eight new ones that came in this meeting, they were going to know through practice and through trends and through their project works, which are the three that they really need to take action on. So the ways they want to operationalize this, they want to do a data center design guide. As I mentioned before, they also want to develop a Data Center Design 101 class and teach it through their corporate university. So they'll advertise it. The new version of the data center design guide's available. Grace Cohen writes a post and lets people know there is new knowledge available for you to use. They also have that monthly webinar series I told you about. So they advertise, this new design guide's available. Please use it on your projects. But they don't rely on people just happening to start using it. They identify some pilot projects to use and reuse that knowledge. So they find three project teams working on these and they get into them and they deploy the new knowledge assets. They put them through the training class and then they stay very close to the projects to see how that new knowledge is working or not working for them. So they want to measure, is this working? So they can use Internet analytics, Right. They can say, are questions being asked? Are people getting answers? They can use analytics to see, are people using and downloading this content in the first place? Are people searching for it? Right. So there's some analytics that can help, you know, if you're on the right path. But there's still qualitative interviews, right? So they could go and interview some of those key people who went through the training class or who are on that project and say, how is this working for you? So for our friend here, the data center checklist is awesome. It filled in some holes in his understanding for another person. Hey, this let me put concepts that I got in the class right away at my work. So it was the right knowledge at the right time for somebody. Or you might get a more critical review. It's like, it's great that we're doing a Datacenter 101 class, but really it was a bit basic. And I would like to really know more about the equipment that we should be specifying more about safety issues and less just kind of about the basics. So that's all great feedback that they can incorporate into going forward. And finally, if they're paying attention or if they kind of invest the work. I know it takes a lot of work to measure these things, but they've been able to say, like, hey, we. We're driving down the amount of rework we have to do because we've got junior inexperienced people designing these projects, and they've been able to drive it down 20%, 27%. Okay. So the final step is improving that knowledge in the first place. So we've got the data center practice area leaders together again, and they build a version 2 of the data center design guide, and then they develop a 201 class for data center design. Right. It's that simple. That's all you have to do. And you guys can manage lessons learned just like CJP design. Cool. I'm done. See y'. All. Right, so yes, it's overly simple, but this, I think, at a high level is the broad moving parts. Right? And so if your process is breaking down, you can use this to help figure out where it's breaking down. You can use it to help design a new program, audit your existing program to understand what it really looks like, and then troubleshooting existing programs. So where are the blockages? Right. Where are the leaks? Where are the bottlenecks? Anyone else have any pipeline metaphors? I think I'm good with those three. So let's kind of go step by step and talk about how you would kind of diagnose a pipeline and figure out where there's opportunity for improvement. I'll warn you up front that this one is going to be the longest one, but they'll get faster after this. So what I did is I synthesized a lot of the things I heard back in the research I was doing into some of the more common tactics that people use at each stage along the pipeline. So in terms of identifying the first two were individuals reflecting and being aware that this is the thing I learned, people should know about it. I don't want my colleagues to step on the same rake or project teams are already having meetings or staff meetings or office meetings. Some of the firms have this as an agenda on those meetings. These are kind of normal in the flow of work things. These are ways that lessons get identified. The next group of things are kind of more formal committees. So a practice area, whether it's around a market sector or a building type or an engineering discipline, whatever it might be, are getting together and they're talking and saying, what are we seeing across our projects? And let's identify some of those top lessons to do something about. You've got design reviews, technical reviews, peer reviews, whatever your firm calls them, quality reviews that are flagging issues on a regular basis. And so these things are happening, right? You've got technical and quality committees who get together, and maybe you've got multiple. Like I learned a lot of the engineering firms, you'll have a technical committee, you know, in each one of the disciplines or in the architecture firms, maybe it's in the market sector. Whatever it is, folks are getting together and they're seeing trends and they're identifying lessons. This is already happening, but if it's not happening, this might be a place where you can gather more lessons. If part of your problem is a supply problem, this might be a way technology can help. Intranet questions and answers, email questions and answers. Whatever it is, there's a mechanism for people to reach out and say, I've got a problem. I'm looking for help. Have you done this before? Can somebody in the firm help me? There's a reactive mode. So a lot of you have something like an as. So an ad service log or RFI request for information, log change order logs, and you're tracking when you know, kind of along the project. The drawings weren't clear, the design wasn't quite thought through, that we had to spend extra money or ask the client for more money to fix it. So a lot of you log those things, and those can be good sources for recurring things that show up. And those might be good lessons worth developing. Some of you have projects every once in a while that goes south, and you end up in a claim or litigation. So a lot of times firms, when this happened, do a pretty deep dive in a postmortem. But again, these are kind of reactive. So it Was fun to see Eric and Andrew talking through his process for those more proactive knowledge reviews earlier today. Pre and post occupancy evaluations are something that a lot of the firms in this room are doing. So this is another source of lessons learned. And a lot of firms these days are doing more formal client feedback programs. And clients love sharing lessons learned with you. Right. They like telling you where you could have improved. If you ask the question, you really listen. They really like telling you, here's what they don't like. When they tell you what you could fix and you don't fix it. So that's a danger with these things. If you're gonna put those into the pipeline, you gotta make sure there's a way to operationalize it and not have them have to tell you that again. Okay, there are more ways to do this. This is just a big kind of starting list. And this is stuff I heard over and over again. Talking to firms and asking them how they identify lessons. So sharing, so and you're going to see practice areas, community practice show up over and over again. These are a lot of the places where this happens. Right? So those lessons get shared again in a presentation done to a practice area or a cop or in minutes. Same thing with a technical or quality committee. That could be a project write up. So a lot of firms are doing project write ups at the end of the project, what went well, what went, didn't. So they're getting shared. But you need to make sure those get routed again to people who can do something about it, not just sit in the project file like we talked about before. People can share lessons learned on the Internet. They can email them whatever it is. They can build a lessons learned database repository. There's a lot of tools for kind of again, getting them away from the project into more people in the organization, the right people. So prioritizing again, there's that group. And I'm sorry if this seems repetitive. It is kind of when you step back and you look at it, you realize that a lot of the infrastructure is already there, but you might not be using it or seeing it exactly this way. And it took me a while, maybe I'm slow, but it took me a way to see it. But I kept hearing the same process over and over and over again. It's like these core people help us figure out which things are the top priorities. Because they're embedded in lots of projects, because they have lots of conversations across the organization, they're able to synthesize very quickly and tell you what matters. So those practice area people and technical and quality people are gold. They're really the kind of the linchpins that hold this thing together. There's this other person Persona that I surfaced, though, that this one kind of surprised me. And it's kind of a knowledge broker role. So it's somebody that might be a knowledge manager, maybe it's an operations person. It's somebody that sits in a lot of meetings that are very diverse in nature and they just pick up things. We talked about weak signals before. Right. So they're hearing this is an issue. And then a week later I go to a meeting and I'm hearing the same thing, but slightly differently. So these knowledge brokers see, and they sit across different boundaries in the organization. So they might cut across disciplines or they might cut across practice areas or departments. So they're really key to a lessons learned pipeline because they can tell you a lot of what's important and what's why. So once they've done that, the operationalization, this is the part that firms are actually pretty good at, divorced from a lessons learned program. Right. So I'll take you through that and I'll explain what I mean. So ways to operationalize lessons learned standards. We talked about qa, QC checklists earlier, or design guides and templates. Right. Or details and specifications. These are all good homes for lessons learned to end up in, so the firm learns. Increasingly, firms are putting a lot of these lessons into software. They might be scripts like Rhino or Dynamo. They might be families in Revit. They're building custom software, whatever it is, they're building technology to help them operationalize this knowledge. They might be client specific. Right. You might have a repeat client. You work with a lot. You might build guidelines for working with this client. How they like their drawings put together, how they like to be brought into the project, and when. So you might develop some of these tools, a lot of ways to put this into training. So teaching people best practices, developing some of the teachable case studies. We saw a good example from Andy this morning. And then a knowledge base by topic. So this might be a wiki example where you build a knowledge base around certain pieces of equipment or certain key phases of the project. So when I said firms are pretty good at this, how many of your firms are doing these things today? Yeah, all of you guys are doing some of these things today. And so one of the things that was interesting is when I was talking to the firms and said, okay, how are you doing lessons learned? And they'd say, like, we Are, but not really doing it that well. What I would do is start here, I'd be like, okay, do you have standards? Right. Do you have specifications? Do you have best practices? Yes, we have those things. Okay, how are those developed? Right. So how do they know what when they're gonna issue a new specification? Or how do they know when there's a new item to go on the QA QC checklist? How does that item get there? They're like, well, we have this technical group who gets together once a month. Great. How do they know what the core issues are? And you can kind of follow it backwards. And you realize they actually have a somewhat informal, maybe ad hoc process for getting lessons from projects into standards, but they're not necessarily looking at it that way. And I think one of the great things you can do is make this pipeline more visible. And when it's visible, you can manage it. Right. And you can improve it. And so that would be a tip if you're trying to kind of audit your program to see are we doing this in the first place is work backwards from some of these ways that you're already operationalizing knowledge and find out how you do that. Okay. Once you've done all that, then you want to advertise again through meetings, these different groups of meetings we looked at before state staff or office meetings, posting it on your intranet, just emailing it out to people, letting it know it exists. But you don't want to rely just on the advertisement. You actually want to put processes in place to help you assure that things are getting used and reused. So some things I saw pilot projects, this came up again and again. I was glad to see it as a theme today. So what can happen? There are a lot of reasons pilot projects are good in general for anything. But what was good in lessons learned is a lot of times I'm trying to think of the most politically correct way to say this. A lot of times these groups that write the standards have the political authority to say, this is the standard. And they can tell people what to do. And that lets them not have to go through the process of making it user friendly or something that people want to adopt because they can say, this is the way we do things. This is the standard. And what I saw, you saw this loud and clear in the Boulder story, but is they spent a lot of time making this be something that was useful to people that they wanted to use voluntarily before coming behind along with a stick. And so the pilot projects help you create value for those teams and make the thing better, right. So it drives you towards what I would say is more user centered design around some of these standards and best practices. One of the key tricks is putting knowledge assets in the flow of work. We talked about the reason why those lessons learned repositories generally don't work is, is it's another place I have to go to see if someone messed up something similar to what I'm working on in the past and then come back to my work. And so you want to put it in their path in terms of the way they work. And we saw good examples this morning. Making these assets findable, whether that's through search or navigation or people know where to find things, is important. Of course it doesn't hurt to train people on new processes and knowledge assets to let them know they're there and eliminating alternatives. So there comes a point in time where we've gone through a pilot, we validated that this is a good thing to use and we take away the old way of doing something. So these are some of the common things I heard from folks in terms of how they go after adoption of new knowledge and new processes. This one I'm not going to spend a lot of time on because it's basically each step in that process identifying are those lessons being learned? Are those, sorry, being identified? Are they being shared? Are they being prioritized? Are we doing operationalization? Are we advertising? Is usage of these things happening? So there's different ways to measure that activity. It's to point out that activity is good. It gives you a sense that we're creating things that are valuable or we're doing the things we said we were going to do. And then on the outcomes there's a lot. I just tried to pick a couple of the ones that I heard the most. So this eliminating rework during design phases, reducing RFIs and change orders, improving project profitability, getting novices up to speed faster and transferring critical knowledge to the next generation. So the final area in terms of improvement, again, this is where those practice areas come in handy again. Right. So they're gonna take that feedback and figure out how to make a version 2 or something or tweak a process, continuing to maintain like we talked about before, same thing with your technical and quality groups. There are a whole range and I'm not going to go into all of those now. Right from the fields of product management or continuous improvement around improving things. So I think you guys know where to find those and a lot of your firms are already thinking that way. So there's a variety of techniques there. So this is the lessons learned pipeline. This is the tool I've been working on. I hope that it's helpful for you. I hope it helps you break down what's going on with lessons learned in your company. And I hope that it helps you improve knowledge flow. And I hope that after today, you guys say something more like this when you go home. True. Maybe. We'll see. Okay, so that was a brief introduction. I want to spend some time taking questions. And then what we're going to do is have you guys have some time to talk about this, share your experiences with lessons learned, and then come back together as a group and have one last conversation. So with that, thank you. And I'll take some questions.