Transcript: Team Alignment on Complex Projects

The next generation's project delivery system or project operating system in our line of business that can bring a meaningful impact, provide serious changes in the way we deliver projects in terms of performance. That system has to be people-centered. The owner is going to set that tone to say, here's how we want this to work and here are the things that we're not going to accept in the process. We could never do that here because we need to change that mentality to be, okay, let's look at what they're doing and figure out how we can apply pieces or the best parts of what they're doing somewhere else to what we do here.

It is going to take some appetite for risk, taking that risk to say, hey, we're going to go through this a different way. Less around efficiency and much more around how does one add in a behavioral framework into the process that becomes consistent and so allows the entire team, the much wider project team or the team of teams to work as a coherent unit all focused on the same objective, working in the same direction. Hello and welcome to the Constructor Podcast, the future of the built environment.

Today is the 100th episode of the Constructor Podcast. This is a time for celebration. Matter of fact, we've been celebrating since episode 99, where I pulled together some of the best snippets from episodes where we talked about human centered design and integration with technology to support that. So if you haven't listened to that episode yet, check it out at Constructor.com slash EP 99. So that being said, I have to apologize.

I would be remiss if I didn't simply because I haven't released this episode, the 100th episode, as promised for a couple of weeks. And I must say that I've been wrapped up on a new project. Most of you know, I'm a senior project management consultant at Mace and right now I'm delivering a high profile retail project. Really can't say very much about it here, but it's been really taking a lot of my attention. So that being said, I'm looking to add to the Constructor team in the way of doing graphic design and report generation.

If you'd like to partner to create reports, we're already spearheading some, and that would be amazing if you could join the team. Please reach out to me at Brittany at Constructor.com. That's B-R-I-T-T-A-N-I-E at ConstructRR.com. After the Thanksgiving holiday, I will also be posting a link with more details on what we're looking for. So don't hesitate to reach out.

I want to continue to provide you, my audience, with continued valuable content, and I'm dedicated to doing that, but need some support to keep on going. In today's episode, we're going to continue the party by pulling together snippets from episodes where my guests talk about effective team building and the interpersonal connections that we make on a day to day basis and being intentional with them. There's a perspective of the market that we should be clear on before we get started, but I think both Olfa Hamdi, CEO of Concord Project Technologies and Todd Burns of Project and Development Services and General Contracting Units at JLL can speak about.

Olfa discusses the changing market for EPC companies here at the start of our discussion on standards for delivery. Currently, the EPC market is going through an extraordinary consolidation of global engineering construction markets. If we take a look at the second quarter of 2017 alone, the markets saw about 49 mergers and acquisitions with a value of over $20 billion. Jacobs Engineering acquired CH2M Hill or A. McPhoster Wheeler acquired by the Powerhouse, Wood Group.

So these are just examples of a long and growing list of those business ventures that are driving the engineering and construction markets. Now, these ventures have been driven by a business need of growing into different markets. So given a typical engineering and procurement and construction company, by going through these ventures, they've been able to expand to markets like war infrastructure, government work, transportation and so on, in addition to oil and gas and petrochemical construction. So by doing that, those companies are able to cover way bigger market scope.

However, on the practical project delivery side, that is creating new challenges in terms of actually executing projects in a standardized way across all those construction segments. New challenges of executing projects with diversification and starting the process from planning better upfront. Todd speaks of his observations on productivity and how using systems that support a project by planning in the beginning is better. It is obvious when you walk on just about any job site across the U.S., the construction industry is an industry that has not developed as fast as other industries.

But the piece within the field is kind of half the equation. We can shorten that cycle. Think about the front half of the design build equation process. So if we can take the front half, shorten that cycle and we can get better productivity there, we're able to shorten the second half because we're much clearer in what we have to build. So what can we do in order to get that?

To have that on the front half, clearly identifying design, budget, process, etc. So we can maximize that back half. Both Alpha and Todd provide some insight on how they believe it can be done. This is where I see the project management office of the future is heading. It has to run that function of integration of people and systems.

So it's not only about systems and it's not only about people, it's both. That practice has to be formalized, has to be developed, has to be built into an actual package of project integration practices that do cover the overall scope. There are some tools that are in the marketplace that I think are going to begin to take off and they're really collaboration tools. And if you think about some of the software that's in these portfolio project management systems, they are comprehensive tools that are really creating a community for the architect, the owner, the engineering firm, the audiovisual consultant, the civil engineer, etc.

All to be able to collaborate in a common space and to be able to share information faster and to be able to thus make decisions faster. I think that's going to help our industry and take some of the noise out of the system. The collaboration piece is going to be big over the coming years. This is relevant to both those large engineering, procurement and construction companies, but it is also relevant to the small and medium construction companies and even more relevant to the owner companies from the public to the private sector, as this is required from them who have stronger project management offices and project management capabilities to drive good project delivery.

How do we get that clarity of how we should be approaching work, whether private, public, industrial workplace, health care? Karen Martin, author of Clarity First, has some interesting compliments to the topic in the way of organizational leadership. We often have to go back to that purpose discussion with organizations before we do any kind of strategy deployment because they focus so much on the what. What they do is not purpose. Why you do it is purpose.

And if you stay focused on the noun, the what, instead of the verb, why you do it and what it does for your customers, then you're never going to make the kinds of business decisions and prioritization decisions that will enable you to really get where you want to go. So here's an example. Companies that are very clear about purpose include health care, social services, government to some extent is clear about what their mission is and what they're there to do in terms of how it helps someone.

When you get into things like construction, for example, manufacturing is another one, maybe even financial services. It gets a little murkier on what you're really doing. People will talk about making a safe structure for someone to work or live in or whatever it might be. You know, it's really not about that structure. It's about what that structure enables.

And that's the purpose. Last week, we talked about human centered design, but there's no difference in the need to have a clear strategy for the purposes of rolling out a construction project. And it starts with the owner. You know, you have clarity when things are easy to understand. So it's an ease of understanding and then you can take appropriate action.

You can make appropriate decisions, et cetera. And the opposite of clarity is ambiguity. And so ambiguity becomes the fog that prevents organizations and people from reaching higher levels of performance. And clarity is important because without that, we don't have enough information to make good decisions and to take appropriate action. And so without clarity, there's a lot of wasted effort.

There's a lot of frustration. There frankly are horrendous decisions that are made based on what people perceive as being facts, but they aren't the full story. And then there's everything from performance. What does good look like for a functional area or for a division or for the whole organization? How do you know you're healthy or not healthy?

Getting clear on how you measure success. That's often not clear at all. Processes, how to do the work, that's often not clear. So a new hire comes on board and there's this very long learning curve that is incredibly frustrating because it's not crystal clear how the work should be done. Lack of clarity has a lot of tentacles and a lot of pretty high stakes outcomes, as well as just simply being a morale dragger.

And to boost morale, you need to be able to operate with greater clarity because clarity feels good. It may be painful to learn the truth in some ways, but it's liberating to know it and to not be dragged down by not knowing. So the fog drags us down and clarity lifts us up, even if it's not wonderful news. It can be tiny little things where people don't know in an organization who to go to to get a decision made. And I could go on.

There's just there's all these different I call the five P's, purpose, priorities, process, performance and problem solving. Those are the five areas that the biggest offenders in organizations where there's excessive ambiguity and not nearly enough clarity. You also hear from Thomas Cox, lean leadership coach and blockchain governance expert. Said a lot of the kabuki dancing planning that we were doing where you'd make the plan, try to guess in well in advance, like what was going to happen or what was going to be needed in your heart.

You knew that you didn't know. And in fact, that you couldn't know the future. So you ended up making what I now see as waste, which these elaborate plans. Somebody was described it as, you know, imagine you're climbing a mountain and write out a project plan and you wouldn't write on day 72, I will need my ice axe. You don't know where you're going to be on day 72, dude.

Come on. And I was always amazed that other people didn't share my fascination with that. It's like instead of planting more cabbage, what if we got fewer heads of cabbage to rot on the way to market? Right. Then you'd be growing fewer cabbages, but feeding more people.

It's it's incredible. It's like you lower your costs and you increase your value delivery. How are you not excited? And of course, I obviously was. You can tell that inner sort of childlike delight and fascination with making things better, qualitatively better by changing your thinking, changing the way you look at things has always been there for me.

And lean was a natural progression of that thought process, particularly how to get software people to do work well in teams and have their leaders be effective leaders of those teams. Software is a particularly pernicious problem because so many of us are engineers in our mindset and engineers just don't understand people typically. For few of us do. We try to engineer our way out of our people problems and it doesn't work. And I found over decades of doing this kind of work with businesses now that if you drill everything down to one primary root cause of organizational performance, slacking and lagging and not as high as it could be, in my view, is lack of clarity.

So when I wrote The Outstanding Organization, clarity, focus, discipline and engagement were the four fundamental behaviors or conditions that organizations really need in order to have peak performance. When that book was released, clarity became the one area that I've got the most emails from. I had more organizations saying, hey, please come help us with this. And it frankly had the most emotion around it. I even had one male engineer that had a client that wasn't prone to show emotion at all.

Write me an email and say that he was in tears realizing how much the lack of clarity was dragging him personally down and his organization. I'm going to admit to you in preparation of what I wanted to share with you in this episode, Epic 100, I had a little bit of lack of clarity. I, myself and Marcus, my business partner and husband, battled this question. We wanted to be clear on the purpose of what we wanted to communicate. We had a lot of info around financing, setting up standards.

And we'll get to some of that, actually, because they are critical components to the success and delivery of projects. But all in all, we said, what is the story that we want to tell? We actually reviewed why we got started with the podcast in the first place. And we remembered that this team perspective is really close and personal and the core vision of what we're doing in the first place. It's really working with others on projects, doing it the best way, making the greatest impact.

We realized we wanted to focus on the story of team, of connection, of intention. And actually, when all of these things are clear, you can take the next steps about budget and systematic experiences and make decisions about those much more easily if you have the people side right. So that being said, let's pull in the perspective of Tony Llewellyn, collaboration director at Resolex, for setting up the project the right way. Step one is about assessing the project environment. In terms of the question around, OK, what are the determinants?

What are the things that are important in terms of creating positive behavioral norms? It's really interesting how the research on effective teams comes back over and over and over again to three key elements. One is a shared vision of what we're trying to do. And the key word there is shared. Second one is having clear roles.

And the third one is an agreed set of rules and engagements. The governance to me is one of the crucial elements. I look at success in a project as working around three core components, which are a technical intelligence, i.e. those things that we do. That's what we're paid to do.

That's what we know. What we learn at university. We're taught in our career. But there's then also the commercial component, because the money and risk and those processes that every organization has to manage, whether it's financial risk or reputational risk, those things are also important. But there's a third element which is critical to project success, and that is the social intelligence element.

And that's the one that's normally regarded as, you know, people call it, you know, it's the soft skills. It's almost as if it's too difficult to learn and too imprecise. And therefore, we can't spend an awful lot of time dealing with it. But I would argue is the other way. But actually, it's the third component.

There are social processes. When you look at them, they make perfect sense. There's no reason why we wouldn't do them other than most people don't. And therefore, they're rushed through. Karen has a view on why we don't spend the time focusing on that social construct.

And Thomas will also speak on improvement work. First of all, there's a lot of organizational noise. And so being clear about priorities helps you get rid of some of that organizational noise. When you've got a lot of noise in the environment, it's very difficult to know what matters and what you should focus on. And clarity just becomes that much more difficult to achieve when there's noise.

The next thing is that there's two fundamental mindset and value systems that are key for clarity, and that's humility and curiosity. And curiosity is woefully lacking in many leaders and in many organizations, not through any intentionality of ours, but because it's been kind of beaten out of us. And I talk in the book about how as children, we were born very curious souls and we ask, why, mommy, why, daddy, and why not, and when, and what if. And we ask all those questions and then we meet well-meaning parents that are impatient and tired and they get impatient with those questions.

And then we meet teachers that don't want to have to answer the questions for some reason or another. Then we meet bosses who are threatened by those kinds of questions. I've experienced all of the above there. And so it gets tamped down. And so then you get this whole workforce of people that have been kind of smacked around as children and then young adults and been taught that clarity doesn't matter and that curiosity is bad.

If someone, you know, they're saying, let's be curious, let's pursue things. And then one person says, hey, I'm wondering why we're doing it that way. And someone smacks them down, then, you know, it's not going to work. So it takes this, that's the tenacity. It takes this absolute commitment operating that way.

And it starts with that conversation. Out of the lean approach for me was this sort of humble acceptance that, of course, there's a better way out there. Let's look for it. And that, that is when I started noticing the resistance that other people and sometimes even me would have to improvement work. It would be emotionally threatening.

Sometimes I literally had somebody who were proposing doing some consulting work for this architecture firm to help them lead their people better. They knew they had morale problems. And one of them objected right out loud in front of us. So, well, if we hire you guys, then we're admitting we don't know. Like, okay, okay.

And, and, and you say that like it's a bad thing. All right. And it wasn't, I mean, I just, I didn't know what to say to the guy. It took me two or three days of just chewing on that statement to realize that what was going on is he was worried about his status and his standing. And when you live in a culture you've created, or you've, you've walked into, or you are living in a culture where admitting ignorance lowers your status.

You've essentially got a culture where lean is not possible. If admitting a mistake lowers your status, then you have to choose between maintaining or enhancing your status or making the system better, but you can't do both. It's like, why don't we just get rid of those values and replace them with other values where admitting a mistake is virtuous, but that requires leadership. It requires the leaders to be actively engaged in admitting mistakes and asking for help and admitting they don't know all the things that we don't do if we're not sure it's safe to do it.

We have to reign, ignite all of that. And it's a, it's a heavy lift for an organization. So you have to be very intentional on wanting clarity and understand that there's psychology to be had here. You can't just, we have to actually unpack all that tamping down. And then humility goes along with it.

And humility, you know, we think of humility as being just not arrogant, you know, in the way that we, we operate and talk, but humility is much deeper than that. Humility is not believing that you know the answer before you really do know the answer. And many, many leaders have gotten promoted because they were star performers and they're known for making decisions and doing what we have to do is kind of help them unlearn that doing and get clearer on what's really going on so that they make even better decisions and can be even higher performers and, and understand that humility means the ability to say, I don't know, but I'm going to find out.

Most leaders don't know the answer and they think they do when they're presented with a problem initially, proper discipline problem solving, which Lene has been great at bringing to the table, allows a leader to really truly know the facts, not what they think or wish the facts were. Asking questions, being curious, admitting mistakes, is that leadership? So co-creating is a key to that. Michael Carr, you haven't heard from yet in this episode, president at MoCA's software division, they speak on what that looks like and the behavior existing and some of the limitations to changing it.

They'll talk from different perspectives, Tony on the high level owner leadership side and Michael on the project site, GC perspective. We've slipped into this idea. We have a team charter. Team charters are a more common part of a project manager's toolkit these days, but they tend to be ineffective. Either they have too much information in them, mainly they're not co-created.

And what I mean by co-creation is back again to it's a discussion that says, okay, guys, when we're together, how are we going to work together? When we meet, how are our meetings going to work? You know, it's the mundane stuff around what's a good meeting? Is it acceptable to turn up 10 minutes late? Is it acceptable to sit down and flip open your laptop and start reading your email?

Is it acceptable to send a substitute in without telling anybody? The point is, as human beings, if we feel we have made or contributed to the making of the rules, we tend to be very good at making sure that they're then implemented. But if we don't feel, if we feel rules are imposed on us, then we can quite often go to extraordinary lengths just to gently subvert them, just to make a point. And it's when we come back to this point around behavioral norms, behavioral norms are the norms that a new person coming into a group will see that are different to those that he might've seen in other groups or projects he's working on.

But once he sees them and sees everybody following them, then that's what he does. So in that project set up process, you have this one shot opportunity as a project leader to set your behavioral norms. And if everybody has feels that being part of their creation, they've started to become embedded and then they continue to roll. In the same token, bad behaviors work in just the same way. And therefore not paying attention to getting a set of clear rules of engagement.

You can see a lot of bad behaviors just, well, nobody seemed to worry about this. So I'll just continue to work this way. It's all in the setup. The really cool thing about the last planner system is that it involves those, those people that are actually responsible for getting the job done. It brings them into the process.

So they put together a plan. It's usually a better plan than what one person can do on their own. The other thing that happens is, well, it's their plan. And so there's some ownership, there's pride of ownership there. And that actually drives up everybody's accountability to one another.

It's like, well, yeah, I said I could do it. I'm going to do it. And when that happens, a really amazing thing happens. Things start on time because work that was scheduled to be done is done on time. And so one of the big issues that, but this is traditional execution, not last planner system, in construction.

And I was talking to a mechanical trade contractor a few months ago and they were saying, look, well, 30% of the time I show up at the job site and it's not ready for me. And he's the mechanical guy. He's the, he's putting in the duct work, which is one of the first things that goes in the, on the floor. But if 30% of the time he's showing up and he can't start because something's in his way, then think of the poor souls that are, you know, later in the process behind them, it's only going to get worse.

So the main thing that happens is these trades are making commitments to each other. And the byproduct of that is they're, they're feeling responsibility to one another. You know, they're finishing their bits on time, which allows for the, the immediate start as planned. That just pulls that whole schedule in and keeps everybody kind of flowing and working together. Another big thing about the last planner system is, is there's a big emphasis on looking ahead and kind of clearing out like all them constraints or blockers.

The term would be like, make ready is something you might hear them say. The whole purpose there is to identify issues or the things or blockers out in the future that need to be taken care of now, like getting a submittal approved or a response to a question answered, or getting a permit material delivery scheduled, getting that thing dealt with now so that when the time comes to do the work, it's planned, we're ready to go. The last kind of cool thing about the whole system is it's intended to be a continuous learning process.

So just because we might get it wrong the first week in terms of our coordination, our estimate on how long it's going to take to do something doesn't mean that we can't next week fix that. And so the whole idea is, you know, if I said I was going to be done on Tuesday and oh my goodness, something happened and it looks like I'm going to be, you know, I finished on Wednesday. This is our first go around. Okay. I missed.

And that means everybody behind me is going to start a little late and we got a bit of a problem there, but we can work together to figure out how to, how to solve it. But if I'm going to do that same scope of work, if you will, on a different floor next week, well now I know. And I can either bring extra crew to make sure I don't miss next week, or I can just tell everybody, you know what, it's going to be a day later, every time from now going forward.

And let's just plan around that. They can do that right now as opposed to months and months go by and we think we're on track. And then suddenly, my goodness, we're a month late. It goes without saying that, that if you've got people that are making commitments to one another, that you just feel you don't want to let them down. You don't want to let the team down.

It's really collaborative planning and it's working together maybe for the benefit of the project and recognizing that when we all pull together, we actually get further along than if we're just trying to kind of take care of our own silo and make sure our own team is busy all the time or what have you. It's, it's, it's, it's remarkable. We know this to be true. How many times have I watched, you know, sports games and then, and the announcer says, well, this is a good team.

They work together as a team. This one's got a team of individual contributors. And so, you know, they might pull one off here, but the team is, is the more consistent. And so we always rally around, you know, that the better team is going to have the better results. It goes without saying that that's, that's, that's true here as well.

I mean, think about a project that was going poorly, that did have a problem, like crazy bad problem. What did they do? They stop and they pull everybody together and they say, we've got to figure this out as a team. So, so they default to it when things get really bad. And I think the whole idea of the last five is you don't need to wait till things get really bad to do it.

Just do it. You want to make all problems visible. That's the primary reason for all of this. And we need to get, you know, many more visual boards up in small work teams, larger work efforts and companies, entire companies about how it's performing and being more transparent about that so that you can actively seek solutions to problems instead of putting them under the rug and pretending they don't exist. They exist, whether you acknowledge them or not, they exist.

And so I would much rather see organizations at least acknowledging them and then actively taking some measures to solve those problems. At the strategic level, things like Hosh and Conry, also known as strategy deployment or policy deployment is another name for it. Those kinds of approaches also are there to get clarity around the priorities of an organization. And, and so, you know, the list goes on and on. There's not one lean principle practice or tool that's about masking the truth.

You know, it's all kind of truth telling serum. It took me a long time to see that common thread. Now that I see it, it's like, wow, you know, we've got it there. All we have to do is use it. Imagine if we could set up a new team exactly the right way.

Like, I mean, do everything right, but still have that monkey wrench thrown into the mix where we do have to respond to a change. A utopian perspective is that nothing will change, but we know that by living, the only consistent thing that we can rely on is change, particularly on construction projects. Maybe from the owner or a non-ferstee condition, et cetera, et cetera. So how do we manage a difficult situation that side swipes the best of teams? Resilience is an interesting word.

One of the words of this decade, you know, one sees resilience in individual resilience and corporate resilience, resilience in the built environment. And of course, what we're talking about is how do we respond to difficulty? How do we respond to problems, to challenges, but really actually it's how do we respond to substantial change? And in a world where one can quickly find oneself continually over-committing, becoming stressed. Team resilience, in some ways is quite distinct from individual resilience.

Individual resilience is that ability to cope, that sort of grittiness, quite a lot of research being done into individual resilience, the different traits that we each of us have. But team resilience is more interesting to me because all teams will go through a period of pressure and some people will respond well to it and some people won't. Teams that do very well tend to create an environment where they're supporting each other. I look at team resilience as a leadership challenge and it starts before the team is under extreme pressure.

So it's almost like looking at, how do I build a team? I know at some stage in the future, as I look at this project, there are going to be difficult times. There are going to be storms. There's going to be changes. There's going to be things that make us uncomfortable individually and collectively.

How do we anticipate that? How do we keep an eye out, keep a watch on the horizon for those kinds of events coming? And how do I as a team need to prepare my team to be able to cope with those things? It ties back to where we started in terms of how were the relationships formed? To what extent by the time the turbulence hits, are the team started to build those interdependent relationships where they trust each other, where they're prepared to take a risk in terms of somebody suggests a solution rather than deferring it and delaying it or looking for somebody else to confirm it going, yeah, I trust you enough.

Let's try that. Let's just try and see. There's also then that leadership element. That's not necessarily from the leader himself or herself, but from that comes from within the team where one has a team of leaders and that different people take on responsibility and take on the role of support at different times as the project progresses. So that when things do get difficult, the team starts that individuals help each other.

So the concept of psychological safety has been understood by people looking at groups and effective communication with groups. But it was just really useful to look at what Google did because in that Project Start at Aristotle initiative, they created something that suddenly project managers couldn't ignore those words. The word psychological doesn't appear in a lot of project management training and yet it now will. And yet the concept is fairly simple. It's just those groups that feel that they can talk to each other openly and honestly without fear of ridicule or punishment tend to be far more successful than those groups that don't.

And then the question is, okay, well, if that's an accepted fact, what does that mean in reality? And where does technology play a role in potentially in that? I think how to establish psychological safety tends to come through behavioral norms and those rules of engagement, because it's the norms that have, in the end, they set the culture of the team. One of the ways of thinking about culture is culture is the things that we feel we can or can't talk about. And so again, setting the right norms, going through the process that creates the norms and then training your leaders and your managers to be highly competent in that process is going to be the way that one builds psychological safety.

John Gordon, author of The Power of Positive Leadership, talks about sustainable team building here. I've had a lot of successful teams do this where each person goes around and shares a defining moment in their life that helped them become who they are today. So they share their story. And once you understand someone's story, you get to know them a whole lot better. But you can also do the Triple H exercise, which is hero hardship highlights.

So each person shares who their hero is, a hardship they faced, and then a highlight, Triple H. And I had an Australian rules football team read my book. They did this exercise. They won the championship this year for the first time in 36 years. I was hearing from people from Australia.

They sent me a magazine article about this team and they all talked about like this exercise, the Triple H that they read in my book, this American, John Gordon, they were laughing at saying this American and they did this exercise, but they were saying how powerful it was, like these big, strong, tough guys sharing their stories, breaking down and then really becoming a strong team because they got to know each other. And that connection led to a greater commitment. Good friend of mine is with the Navy SEALs and he's actually a former Navy SEAL, still works with them a little bit.

And he just talked about how what makes them truly bond together is their selflessness and their ability and their willingness to give themselves up. For their team members. But that happens because they get to know each other because they have this bond of brotherhood that leads to that. You don't get that without the brotherhood. I often joke with them that they do these team building exercises that they take teams in the water.

And I said, listen, I don't think you have to drown together to become a strong team. I said, I do other exercises like these vulnerability exercises. I actually think these are more powerful because you get to the heart. We joke around about that. Here's another team building exercise from an organizational workflow perspective from Karen.

Value stream maps are the blueprint of an organization. And so being able to constantly look at that and get clear on how work is flowing or more commonly doesn't flow. For example, as a tool to enable conversations about future state design across many, many functions, that is about as clarity boosting as it is. Now part of this is choosing to do the work on yourself, which Mike Petruski podcast host of the workplace innovator podcast. He speaks on that.

It's really hard to stop and listen and really concentrate on what other people are saying without trying to insert our agenda. We're human beings. We want to get our point across. We want to share. And we have that kind of selfish bent.

We all do. So muting that voice inside of you that wants to insert yourself and just really listening and understanding. That's what podcasting has done for me. I'm self aware. I know I'm not perfect at it.

Obviously. I still interrupt people and get excited and I want to share something, but if we could promote that idea to both the service providers and also the people inside organizations, when they communicate with each other and collaborate with each other, the people in one department may look across at the people in another department and tell them what they should do or put their ideas out instead of asking questions. Why are we doing it this way? What is the technical reason for this solution not working in that one working for us?

Or what are you looking for, madam IT executive? What do we need to do? Or Mr. Corporate Real Estate person, how are we planning to change our portfolio in the future? And what projects we have on the horizon that we need to consider for taking care of the occupants of our facilities, the occupants of our buildings.

So there's so many people with different expertise and understanding, but they don't often communicate with each other. And that's what makes change so difficult. Damon Hernandez, founder of the AEC Hackathon, speaks on collaboration and solving with SaaS solutions as teams. Collaboration is not bad. It's not a sign of weakness asking someone, hey, can you help here?

Can you provide some value? Another thing it requires is that you actually share all the data. One woman shared that, you know, she had been in the industry for years and this was her first chance to actually sit down with GC and the structural engineer and other people that are in the process and just have open dialogue. Anyone can be the proud parent and talk about how great their kid is. But when other people bring up the value that they find in something, that's what resonates.

And the way that the hackathon is crowd wise is the way that the industry needs to go. When people come in, there is no affiliation. Like we don't say what company, we're just you. And it's the value you bring to the team. And it doesn't matter if you're 14 or you're 90, if you're black, white, yellow, green, it doesn't matter male, female.

And so I think that's the thing that's awesome is that it's people of multiple different generations, multiple different races, backgrounds, and all of that stuff. And everyone else is respecting everyone else's opinion. I think that's that shift that the industry needs to be because I'm tired of seeing people of any age that are put off by the people who embrace technology or they say, I don't understand where the young people are. So I'm not going to hang out with them or I don't understand where the old people are and I'm not going to hang out with them.

I think breaking down all of those walls to where it's just like, you know what? You're a good human. I'm good human. We care about this. We want to solve that.

Let's go for it. I think as we get older, we lose that ability to fail, especially in work. You can't do that. But iteration and especially when it comes to improving systems is about iteration and failure and versions. So definitely to provide people that opportunity to explore and fail.

And then some of the most interesting hacks are ones where they said, hey, you know, we just spent the entire Saturday trying to get this one thing to work and it didn't at all. And then at 10 30 p.m., when the judging is the very next day, we came up with this whole different idea and we worked overnight. Failure, I think, is another one of those key things that great about the event is that it makes it safe, but still kind of related to your profession context.

Tony echo Damon's sentiments. I use games and have used games quite a lot in the past as a learning methodology. What I like about that gamification process is a way of encouraging people to explore something that otherwise they would avoid because they would immediately assume a risk based position. No, I'm not going to do that because it's not been done before. I've not seen it done before.

So using gamification, that game element to say, well, we could try this and take a chance, see what happens. But it's in a safe environment. And certainly when one comes to think about lean, I really see the lean to work in construction in particular, the environment where people feel safe to take risks is absolutely crucial. It can be intimidating to be that open, but knowing self, opening up your eyes to the realization that each one of us has value is so key. I believe the biggest challenge that all of us face and what I've learned over these past many years is to not worry about what other people think.

And I know that's hard to do, worry less about what other people think. I think we all have a default setting. And I talk about this all the time. We fill our heads with the negative for me. And I'm sure for many of us, if you don't hear back from someone, you leave a message and they don't reply, you automatically fill in that gap, that no information with negativity, they must not like that.

I must have made them mad. There's something wrong here. That natural default setting, I call it as human beings, we all can relate to it in some way, shape or form only gets overcome by experience. And you learn through life that people are busy. People have their own issues.

It's not about you. It's not always about you. If I were to talk to my high school self, my college self, even my younger career self, even me yesterday, remind myself that it's not all about me. And be more confident in knowing that I do bring something of value to this situation, whatever it may be. My opinions may not be for everyone.

The advice I have to offer may not be taken, but I do have something of value to bring to the table. So confidence. I think the biggest thing I would tell myself is be more confident in who you are, but also be more aware of others and their perspectives. And I think that's the biggest thing I would tell myself is be more aware of others and their perspectives. See the world a little bit through their eyes, empathize with other people.

It's not all about me. It's not all about our selfish position, but look across the aisle at whoever that may be. And this is just life lessons, right? I teach my daughters and I've taught myself to be more understanding and aware of the perspectives of others. And that could be somebody from another country or just another part of our town or another background.

We all have different stories. We're all human though. We're all part of the same family in that regard and we're wired the same in many ways. So we just have to be more aware, more self-aware first, and then more aware of others' perspectives and be more empathetic. So that's what I would tell myself, because I think it would have saved me a lot of headaches and heartache over the years if I had known more about the truth of human nature.

And let us not forget the value of something so simple called emotional intelligence, which is really all encompassing when it comes to the subject of team, who we are and how we interconnect. W. Edwards Deming, the father of total quality management, that was one of his big things was we've got to remove that culture of fear and replace it with a culture of innovation and curiosity and wanting to experiment and wanting to take some risks. Many organizations aren't there yet today. Culturally here in the U.S., 2018 now, that safe space generally refers to a place where you won't be challenged because they don't know how to challenge respectfully.

They don't know how to be challenged respectfully and they don't know how to feel safe when they maybe don't know things or have to ask for help or have to admit a mistake. In the lean universes, we want a place where it's safe to be challenged, where challenges are done with love, with respect, with appreciation of the other and so on. And there's something that happens when you say out loud something about yourself. If you say, I am and I want to be a person of integrity.

And when you say that out loud, if you know that you kind of haven't been lately, it'll feel bad. And that's exactly what you want to create. You want to mine that cognitive dissonance that comes up when your words and actions don't match. I'll tell you, most of my career, when I had that mismatch, I would either ignore it or distract myself because I didn't like feeling bad. It's very much like we see in the workplace, right?

We know that things aren't going as well as they could and we could fix them. It's like, oh, but if we fix them, we'll have to confront Fred. And Fred is really defensive. And I don't like when I have that kind of kind of, you don't even listen to me anyway. What's the point?

I'll work around Fred. Okay. What did I just do? Well, I put my comfort ahead of systems improvement. And so I had to put my comfort second and put my improvement first.

And that required for me that this habit of having a saying, I would say to myself and making this game and a little scorecard for myself, which included journaling in the morning and journaling in the evening. And at the end of the week, I would look over my journal and just sort of summarize my week on about a half a page and share it with my wife. And she would share her week and I'd share my week and it would be our way of winding down on Fridays, which by the way, is a wonderful habit.

You're married, you have a partner or you'd like to be in a long term relationship with intimacy and self-revelation and increasing levels of self-disclosure. I highly recommend that. Anytime my wife mentions our Friday practice of sharing our weeks with each other, her girlfriends go, oh, they wish they had that gentleman. How do we set up that culture effectively? Is it leadership or management?

The difference between leadership and management leadership has to do with helping people face their fears, their inadequacies, their challenges and try the new thing. And then management consists of all the things that we do to manage complexity. So, for instance, a leader will make it exciting to visit the promised land and we're going to go to the promised land. It'll be hard work, but it'll be glorious when we get there. And then the management function is to go, OK, promised land.

What's the weather going to be like? Do we have the right clothing? What kind of crops will grow there? Do we have the implements we will need to farm those crops? Who will do that work?

Do we have the right mix of skills? We need some training. So the leader will get you there, but without management, you're just a tourist. You're going to have to go back home again because you're not prepared to settle because the complexities beyond you. And you'll see this with leadership heavy organizations that are full of vision and they try new things, but nothing sticks.

Leadership and management are like the yin and the yang or your left foot and your right foot. You need them both because you need the courage to try the new thing. And then you need to manage what the results of trying the new thing. Reason lean when it works is so effective is it unites those. Let's try something new, but in a methodical way.

Let's come up with an experiment. Try it out with heck, right? It's very safe to try something new in a lean environment. You're sort of expected to. If you've got a good lean coach, you're like, OK, what are you going to try?

Well, I'm trying something. Yeah, of course you're going to try something. Come on. Oh, OK. And so you're sort of expected to try stuff.

And then your coach also helps you with the reflection step. But the middle part where you OK, I'm going to plan out the new thing, and I'm actually going to do it, and then I'm going to check and see what happened. And then I'm going to adjust based on what I learned from reflecting on what happened. And so the structure of it is very management like it's dealing with the complexity. Otherwise, you'd like trying new things all the time, but you don't have any order or structure to it.

And you never write anything down. So you never learn anything or you learn through intuition, which is very slow or can be. So, yeah, we need leadership in ourselves and for each other to help us get over our fear, fear of trying something new, fear of failure, fear of admitting a mistake. And we desperately need good management to help us not lose the gains. And we need both.

We need both very, very much. So when I think about something like construction and block chain and some of the technologies that we've got that I think would benefit enormously from a lean mindset and from lean disciplines and lean practices, I now look for signs that the team that's involved will do something like handle a report of a problem, not with blame, but with curiosity. Right. Do they do the typical we're uncomfortable now. How do we make the discomfort go away?

We'll reinterpret the report of a problem as not a problem. Right. Or, well, we have a great team. We'll tackle it. Well, that's that doesn't show curiosity.

That shows a desire to not feel scared. How about, huh, we have a problem. Cool. Tell me more. That's what I want.

We know we have PDCA or PDSA. Plan, do, study, adjust is what I prefer. That's what Deming actually preferred. DMAIC, 8D, TBP. There are many, many problem solving models out there.

OODA. And I feel like they all have shortcomings. And I have felt this from the beginning that the words plan, do, study, adjust, while they're more intuitive than plan, do, check, act, they're still not clear. Like plan, for example, has a lot to it. So as I've been working with people for now two decades on problem solving, well, two decades just within lean on problem solving, many decades beyond that in operations management, problem solving.

I discovered that people don't answer questions that are important questions because plan doesn't really give them questions. So clear problem solving is a question based approach. You can overlay it onto any problem solving model. And it's just getting very, very clear on the questions that need to be answered every step along the way as you're solving a problem. The other thing that we see happening is, you know, problem solving, people sometimes think about it's all about getting to a solution, but there's a lot of, again, psychology to getting to a solution that's at least sustainable.

And one of them is selling people on the fact that a problem is even a problem so that we're solving the right problems and the biggest problems, not the silly problems that maybe one part of the organization is concerned about, but the rest of the organization isn't. And it robs resources if you're not focused on the right things. So just even things like, how do we know it's a problem? How big of a problem is it? How do we know, you know, that it's that big?

And answering those kinds of questions, help people get the support they need to then move forward in solving the problem and getting that support and getting people all aligned around the fact that something is even a problem is the first step. And it's missing a lot in PDSA. So we have to think about the stories that we're telling. We have to present the challenges that we're facing in order to solve the right problems and not get caught up in solving the wrong ones. So it's identifying potentially where you're maybe lacking.

Is it within leadership or is it within management? Which tools do you use in order to address that challenge? I kind of like compare projects to a Breitling Pilot Watch. All the moving parts in the projects need to be precisely aligned from day one so that the whole thing can work and get to the predictable outcome and give you the actual timing that's accurate. But this is a difficult task.

Product managers can tell you about it. They kind of like get absorbed into so many moving parts that the actual job of aligning things sometimes gets out of hand. Taking a look at the project execution plan as a central document, a central deliverable that is built and kicked off from day one of the project and then updated and serving as a central single source of truth for the entire project team and project stakeholders. That's an alternative that can provide a sense of alignment in a project that is lasting many months or sometimes many years.

Some projects last over 10 years. I had the chance to work on petrochemical complex, you know, mega multi-billion dollar projects that do involve many companies, many public organizations, many private organizations, many people from many countries that are working toward one goal. Well, people leave and come back, turnover happens. So how do you keep everybody aligned? You can't rely on the project manager to have all the time in the world to be able to align everybody at any single point in time.

You need that common system and common framework where everybody can go to and see the latest in terms of scope definition, in terms of safety procedure, in terms of roles and responsibilities, in terms of risk. All those pieces have them in one single place to serve as a single source of truth. We know that the single source of truth is going to really help, but we have to get it set up right the first time. So I love Tony's perspective on this. In a planned and complicated environment, it's nothing wrong with complicated.

Complicated, we can control, we can manage complicated. But as we move into complex and there are so many moving variables, that idea that one can distill a production process down to a series of sequential activities becomes much more tenuous. And of course, therein lies the challenge with blockchain, which is that it has somehow rather than it's got to take into account the fact that we don't know all the variables at the beginning, but I don't necessarily see that as a problem. I think that's just a way of how the system will evolve and how it will be designed.

More crucially, however, is the way that the technology might be used to start to require the role of the leader to shift so that if the role of the project leader in the past, based around that command and control paradigm where all knowledge sits at the top of a hierarchy and it's just a matter of requiring people further down the hierarchy to do what they're told to do. Now, modern management thinking is continually exhorting managers to let go of command and control, of course, all the comfort that comes with that and to accept the world we live in now is much more Rans-Sense and React.

So if that leadership skill needs to shift and it takes on board, not just, as I said before, the commercial and the technical, but also recognizes that social element, then the requirement is what are the activities and processes that are known to have a positive impact on behavioral norms so that you are creating a team that is able to sense and react, to look at the information they've got, make decisions around where they stand at a particular time. But then as information changes or as the environment changes, they're able then to quickly adapt and keep the project moving forward.

What I've found in the research that I have been doing and continue to do into effective project teams is that before a team to work effectively as a group, there are three components that need to be in place. One is that the resources need to be there. Essentially say is the money's got to be right. Any team that goes into a project where they're hoping that the money will turn out right, it's not going to work because in any kind of commercial enterprise, if you're not going to make the profit or indeed you're going to make a loss, that is going to affect a commercial team will behave.

The second one is that the project requires a level of leadership that is able to move the team through these processes that are often ignored or they're treated as a sort tick-box exercise, which have been found to make a difference. And then the last component is that one has a sponsor or a client who is competent enough to make the decisions to set the brief and continue to develop the brief along with the project team. I say that because we can then follow the framework or a model to the letter.

But if those three components aren't in place, then a team has a problem. And to me, that information is valuable because I would say as a project leader, you don't go forward until you've got those three elements bottomed out. And of course, that's in an ideal world. There'll be plenty of your listeners sitting there saying, we don't have a choice. This is just, you know, we are where we are.

So in an ideal world, that would be how I would try and control my project environment. And we'll have to set up the systems in place to respond to the change. But having that protocol written down is really helpful. And managing that change might be an industry at large change that we have to manage. Listen in to Opha and Todd talk about the different ways they think we should be approaching that.

What is the major challenge that has traditionally prevented this integration from pre-construction to project delivery and project closeout? The main challenge has been the way our business model works. So if you take a look at construction in general, typically in the early days of the project, not all the team members are already staffed. The project is still not confirmed to be perceived, not fully funded. The natural way of looking at things is to try to minimize spending in the beginning and then keep spending after the decision to fund the project has been made.

This is counterintuitive, knowing that the early decisions you make in a project do have a really big impact. You need to think of investing early on in the project so that you can increase the chances of the project succeeding in execution. But this is not the way the business model is. So there is a misalignment between the life cycle of funding of projects and the proper way of delivering projects and ensuring that projects do achieve good performance in terms of cost, schedule, safety, quality and operability as well.

I do think there has to be some work that's done in how we price projects. And when I say that, we put a lot of pressure on our design and construction communities, our architects and our engineers. We monetize them to some extent, as well as our general contractors. And I think the whole supply chain work needs to be looked at from our material suppliers, through our installers, our subcontractor trades, through our general contractor. I think looking at that and how then you price around that is going to help the industry to some extent as well.

When we begin to get that right, begin to move much more towards the products that become more persistent. And I think you'll see much more modular work being done because product is specific, it's complete. Putting structures in for more collaborative tools can certainly help. And Michael DeLacy speaks on that. From a design bid build perspective, the owner or CM or owner's rep takes a lot of the responsibility and they go out and they hire a design team that is tasked with generating construction documentation, typically with very little input or no input from the construction team or the subcontractor team around constructability and BIM execution plan or the BEP.

That BEP is going to be developed typically as primed by an architect. The architect will have a template and they'll get input from the collaborating engineers and such. It's all really geared to what is the contractual requirement of the design team and that is to deliver construction documents and potentially a quote unquote conflict-free building information model that will be then distributed to a series of contractors for bidding. The contractors, in many cases, don't get the building information model during the bidding phase. They only get the drawings.

They review the drawings, they put their bid in and the awarded contractor will receive the model as a courtesy and they'll start picking apart the model to figure out what they want to do with it. Hopefully the contractor will put together their own BEP with their subcontractors to go about executing the shop drawing process and figure out how their actual equipment is going to go into the building and redevelop the model around that specific equipment and then go about the construction process. So the BEP is still very important in design bid build environment.

It's important that the design team have a well detailed BEP identifying who's responsible for what, what versions they're going to use, when things are going to be delivered, what level of detail they're developing to and even more specifically what does that actually mean when we talk about level of detail around specific components or specific areas of the building. Same thing on the construction side, having a well detailed BIM execution plan to guide the subcontractors on what their responsibilities are. But I think when we go into design build, potentially a very different world where we have the contractor and maybe some of the primary subcontractors on the team very early, which means that we can start incorporating much more detailed or constructability information into the model much earlier in the process.

So a BEP in a design build environment is actually a single document that's encompassing all participants in the project, meaning the entire design team, potentially the entire construction team, or at least the major subcontractors that are going to be putting equipment into the building. And I think it should compact the schedule and potentially save a tremendous amount of rework, certainly significantly shorten the shop drawing process. Everybody's on early, hopefully everybody's working in the model early. I think it improves subcontractor education in the BIM process and understanding why it is we're going through this modeling process and this conflict detection or coordination process.

And I think it's even going to facilitate better installation by having those people participate in the process much earlier on. You know, subcontractors are going to understand that there's a reason that they're installing things in the places they're installing them. And it kind of starts to alleviate that first in wins mentality around going in and installing equipment in a building. There's so much information available today. I mean, the world has changed a lot where there is so many metrics that they can use.

We know at an actual fair price to build an asset. We've seen this happen over the years now, negotiated fees and negotiated contract values. So there is some precedent and some room for that. But to sit down as a team and say, you know, here's how we're going to separate the responsibility and here's how we're going to be willing to pay for those responsibilities. We can get there.

Setting up the structure in order to support the more collaborative, more transparent, more team focused connectedness approach seems to be the common theme. Tony Llewellyn will also add to that with a little flavor of his perspective of how blockchain can support that. The idea of smart contracts and how they could be used to coordinate and to add a dimension to the technical and commercial process of development by refining the detail and connecting the client or the project sponsor more directly with the supply chain of those guys who are delivering it.

So it really sounds like it comes down to having clarity about what the organization wants to do about making sure that you have collaborative, transparent teams and having the technology to support that. At the end of the day, we all have businesses that we have to run. But when you think about it, we all are serving someone as a result of the business existing in the first place, no matter what role you hold. And that's something that I think Karen really sums up well. Listen in.

Probably the biggest indicator of revenue drain is customers. It's fascinating to me, the more we work with organizations and ask very pointed questions, we ask a lot of questions, the more we ask questions and get vague responses, the more we understand that many, many businesses don't know their customers and they don't know what their customers value. And so understanding the customer becomes critical. Providing customer value, we always think about that as us doing it to some external customer. In organizations, everyone's a customer to something.

And so always going to the customer and saying, is this clear enough? Is my email clear enough? Do you understand what it means or am I writing vague? And again, it's self-awareness and it's training. It's little by little learning that you really aren't as clear in your emails as you could be.

And I really don't know why we're at this meeting. I really don't know our purpose. I really don't know how we're performing. All those things just help little by little move that needle from, you know, avoidance or blindness. The whole organization benefits.

The whole organization, the whole project, any team benefits from looking at this process holistically. So with that, I want to thank you for being a long-time listener or being a first-time listener, but nevertheless, being part of the journey with me to episode 100. If you liked this episode, connect with me on Twitter at Brittany underscore C-T, LinkedIn, or email me at Brittany at Constructor.com. That's B-R-I-T-T-A-N-I-E at ConstructRR.com. Next week, we will be recapping the LCI 2018 Orlando, Florida Congress.

I'm looking forward to sharing my learnings from my time there last month. I also did a presentation on how the integrated project delivery model can be adopted more easily and more often by using blockchain. I'll be happy to share those episodes with you in the next coming weeks. If you haven't subscribed to the podcast, do so at your favorite podcast player. I look forward to continuing the journey with you next week.