Communications Pitfalls and Solutions from the Big Dig

Welcome to the Everyday PM Podcast, the podcast where we

discuss project management principles for your everyday life. My name is Anne Campia, I'm the host and founder of The Everyday PM, and I'm excited to connect with all of you about Lost in Translation, Communications, Pitfalls and Solutions from The Big Dig. I have with us a regular guest actually, that some of you may be familiar with Donna Gregorio, who has graced our podcast in the past talking about various topics, project management related. So Donna, I'm so excited to

welcome you back to the podcast. You actually came to me with this topic and it's a very interesting topic and we'll get into that in just a minute. But for folks who haven't met you through some of the other episodes you've guested on, please take a brief moment to introduce yourself to the audience. All right, great. Well, Ian, it's a pleasure to be back. Thanks so much for having me. My name is Donna Gregorio.

I am an experienced IT department head and a seasoned project manager, project manager, published author on the topic. Right now I'm an adjunct adjunct professor teaching project management at Northeastern University. And I'm also the vice president of professional development at the PMI Mass Bay chapter.

So all kinds of project management related activities going on and, and I'm happy to be here to talk about this, this new topic that I've recently been researching that's really been rather interesting for me to learn about. Me too, me too. I'm super excited. I do know about this project, which we'll get into in just a second. But what I will highlight is Donna, you are like my life Peg, in that I don't know if you ever heard that term life Peg, but you're no, I haven't.

OK. Your professional journey is something that I would want to emulate. And I think I've told you that time and time again, the times that we have gotten to meet is that it feels like you've got the career a few steps ahead of me that I kind of eventually

want to get into myself. And so for the years of experience you've spent in project management and technology, as well as the years that you've spent in the project management community, I just want to commend you and thank you again for taking time to talk to our audience today. So let's dig in to the Big Dig, no pun, maybe pun intended here, but let's start with what's the Big Dig.

Now I know what it is just because it's been used countless times in my project management upbringing as a example of a project that we can use as a use case. But why don't you explain to our audience what the Big Dig is? Yes. So thanks. I I think that using the Big Dig as a backdrop for this discussion on project management techniques and modern project management techniques is a great way for us to really see what can happen, both positive and negative, if we don't succeed.

And that's really why we're here. We really want to be irreplaceable as project managers. And I believe that the Big Dig did have some successes, but experienced A tremendous number of failures as well. So this is not intended to be a history lesson. It's really a lens to really see the power of good project management and the danger of getting it wrong. So the Big Dig was the most complex and controversial infrastructure project in U.S. history. There was a Central Artery that

and a elevated Hwy. that ran through Boston back in the 1950s. It was built and in the 1990s there was a decision that it needed to either be upgraded or, or or replaced with a series of tunnels and bridges. And that's in fact what the Big Dig was. And the idea to to get rid of that central artery that ran right through the middle of Boston and really was such an eyesore. I again, I remember it being born and raised in Boston, started in 1991, ended in 2006.

So it was a 15 year project that cost $14.8 billion. That's a huge number. The project was seven years late and $12 billion over budget. So you can see the schedule and the and the cost factors and the public was very upset about it at the time because there were some significant failures. In particular, a woman died going through the through one of the tunnels when the ceiling panel collapsed on her car.

And certainly there was significant project mismanagement that came out around that time. But the good part that came from it was that there is now, for those of you who are familiar with Boston, the Rose Kennedy Greenway is a beautiful replacement for the space that was taken up by the Central Artery and it really did

transform the Boston cityscape. The Zakim Bridge is also part of the Big Dig, beautiful bridge that is really iconic now in the Boston landscape that was never there before. So lots of good things came about the Seaport, South Boston, areas of the city that were never even considered to be part of the vibrant city that Boston was, because it really broke that Central Artery, broke the city in half.

So we're here really today to talk about what went wrong and really, was the project a failure or a success or, or was it both? I, I don't really know, but I think that with the backdrop of the Big Dig, we could talk about a lot of these positive things that we could have done had we been in their shoes. And I want to put a little personal touch on this. I listened to a podcast recently that really got me revved up about the Big Dig.

And for those of you who are podcast listeners, check out WGBH was it, which is a local TV station in Boston that created this podcast. It's a six episode podcast all about the Big Dig and very interesting, very, very well done and really jazzed me up about the whole topic. And that's why I'm here today. I love, I love this for so many reasons. I love that we're going to give our audience an opportunity to think through whether or not this was a success or failure as well.

And just to ground us before I get to my first question with you, Donna, it's interesting that that you called out right at the beginning, it was over budget and it was overtime. And so traditional project management foundational thinking is that we're built around, but the Iron Triangle, right of are we on time? Are we on cost and of quality or resources, whichever 1 you want to swap out for that third

element here. And as we get into 2025, the idea of how project management value is assessed now has evolved as well. And I think it's important to call that out for project managers and those that aren't close to the profession to understand there's metrics that we have to be accountable to in this position. And I think during that time frame, obviously things like cost, things like time are all going to spin your project out a side of that scope outside of that delivery and that value.

But now bringing this conversation into this light, into this current environment where Project Management Institute Institute has come out and said value is realized a different way now. It's not necessarily just all of the iron triangle elements. There's a little bit more around how that value comes back to the organization.

I think it's interesting to consider what you're about to present to us today in the context of what were we being measured upon as project managers back then versus how do we see value and the benefit realization of projects in

today's landscape and how does the Big Dig fit into that? So all of that to say, I think my first question to you is around, I think we want to talk about what the potential pitfalls are of the project. So if you could walk us through the most critical communication failures that occurred during the project and how they specifically contributed to the

delays and cost overruns? So I think there was a major player in this, and that was the Bechtel Parsons Brinkerhoff organization that was contracted to run the project, and they were the project managers. They did not have a lot of oversight by the government entities in Massachusetts at the time, the Mass Turnpike Authority and the Mass Highway that were really running this project and coordinating with the federal government to get funding for this project.

So basically they got the funding and then they handed it off to Bechtel Parsons, Brinkerhoff to run the project. And they, they kept their fingers crossed and hoped that all would go well. Many times the, the, the various government entities would present about the project and they'd say, oh, everything's great and we're on schedule and this project is going to cost us X amount of money, which was always less than what it ended up costing.

They're very positive and always, always trying to shine a bright light on the project as being a great project for Boston. And at the same time, Bechtel was cycling project managers through every six months. So they never had a consistent project manager running on the projects throughout. And, and we didn't find out about this until when there was some investigation done.

There was a lawsuit brought against Bechtel Process Brinkerhoff at the end of the project in 2006, because when the woman died, someone had to be blamed and they turned to Bechtel and sued them not only for the ceiling tile falling on the car, but also there were tunnel leaks. Right after the tunnel opened, one of the tunnels opened, there was a major leak that there was a flood in the tunnel that that was caused by in incorrect and insufficient concrete that was

poured to to form the tunnel. So they were sued for both of those things and they settled for $458,000,000. So you can imagine how much money we're talking about. This is a huge project. As I said, billions of dollars were being spent, taxpayer money and for them to settle for 458, they didn't want to have to get dragged through any sort of lawsuit that would expect audit and look at all the materials that they had put together. So they just settled.

But you know, really, why did this happen and why, why these problems occurred? So first of all, I think there was significantly poor stakeholder communication. There were so many stakeholders involved, so complex, so many contractors, mass highway, mass Turnpike authority, government, the governor changed so many times throughout the time that this project was running, you know, and, and the governor was very involved in what was happening.

The reporting, I'm I mentioned the reporting, everything was always try to be positive and, and especially with the public who was living this every every day, the construction right under their feet. There was minimal oversight. As I said, there were no, no performance metrics at all that were created and I don't think there was there was even a thing back then with the Institute of PMI, introduction of PMI and all of the and people say, oh, we have to follow all these things.

But you know, there's a reason why all these things are put in place, metrics and objectives and key results and all that. So I think the objectives and key results are really the first key piece that we'll talk about today. What could they have done in terms of that to make things better? So that's number one. The second piece is when they had technical issues, they had problems resolving them largely because they didn't have a, a very good organizational structure.

So there was no place, one place to go if there was a problem. Who do I, who do I talk to? Do I go to the governor? Do I go to the mass highway? Do I go to mass Turnpike or who do I talk to? And, and, and there's construction engineers and there's inspectors that are out

at the field. And so there's so many people involved, it's almost hard to get through all that red tape to figure out who to speak to. They also had inconsistent status reporting, again, saying, oh, yeah, everything's going well, when in reality, it wasn't. And how many times have you experienced that?

I know I have. When I hear in the hallway a project is going South. Yet when I'm in a status reporting management meeting, everyone says, oh, it's green, everything is green, and all is well. And you know, that is not the way that we want to be as project managers. We need to be transparent.

We need to have this project charter in place that says this is what we're building and why this is the reason we're building it. And if there are problems, we'll raise those up at at whenever we can at these gates, what that we put in place, these milestones that we put in place, I don't think they had milestones of any kind. I think they didn't have any gates that they had to go through to make sure that things were going well.

So that the second piece of this is around problem framing and what do you do when you run into a problem and, and there are quite a few people involved that need to solve that problem, but you're in charge. You need to make that, you need to make that decision that some sort of brainstorming session needs to take place and you need to run that meeting. And how do you do that? So we'll talk about that.

And then the third thing is the overly optimistic schedules, not just the status reports, but the schedules that people put together. And so when you, when you have a problem framing activity that that results in actions, those actions need to be put in a plan. And that's really why we're, we're here as project managers is to develop a plan that can be executed. And if you can't develop a plan that can be executed, then then

you're, you become irrelevant. You become just part of the landscape and, and not the leader that you really, really should be. So I think in general that that there's so many issues and I tried, I'm trying to simplify things because there's so much to talk about with this topic. But I think that's where we'll really focus our energies on objectives and key results, problem framing and then also the road mapping that is the result of the actions that we

developed. It sounds good to me, Donna. I mean, let's let's get into the first one. So object objectives and key results. So for those project managers who may not understand what that means for an organization, can you just briefly describe how you've used OK Rs in the past? So, OK, Rs in my organization were critical when you're proposing and starting a project, it's part of the project planning activity.

So we put these objectives together that says here's what we're planning to build and and here's here is how we will measure our progress. So these are not tasks. This is really a key point I want to make is that objectives and key results are not tasks to be placed on a schedule. They are measurements that you're putting in place to track

your progress. So for example, in the case of building a huge tunnel that's miles and miles long, imagine that you're building a tunnel of, of, let's just say that's 5 miles long. Did you finish the first mile? Did you finish the second mile? Did you finish the third mile? Did you finish, et cetera. That's a very, very basic, very, very basic metric to track your progress. Well, where are we? Are we, are we done? Have we finished the fifth mile or are we still on mile one?

Because when you're building a tunnel, especially at this this kind, you're not digging the whole trench and then you're not laying the whole thing and you're not putting in the pieces once you know you're doing it a little at the time, one mile at a time, one half a mile at a time or whatever. So I think that that's an example of, you know, extreme example of a metric that gives you an idea of some transparency into the progress of the project.

If you're building an application and you're developing it, you know, writing code, how many lines of code have you written? Did you do 5 or did you do 500? And how many tests have you run? If you're doing 25 tests, have you done 2 or have you done 20 and you're almost done, You know, so these are the metrics that we're talking about. This is not tasks that we're putting on a schedule, and they're the most effective when you're at the initiative or the

work breakdown structure level. So if you said in this an example of the Big Dig, oh, we're going to take the Central Artery, we're going to knock it down, we're going to build the tunnel to replace it. That is way too big of an objective. That's not measurable. There's so many pieces to that. So you need to talk about how to build the tunnel, the various parts, pieces and parts of

building the tunnel. And then once the tunnel is completed, how do you connect that tunnel to other roadways? And then once that's completed, how do you actually dismantle the essential artery that's existing? And there's so many parts within each of that. So it's really the important part of an OK R is that it needs to be developed at the initiative level so that it makes sense to the people that you're working with.

So you need to be quantifiable numbers, especially important, you need to stretch the team so you know as quickly as you can complete these 25 tests. Did you do them in a month? Did you do them in two months? Did you do them in six months? That should be part of your OK R And then they can be used as early warning signals, which there were no early warning signals in the Big Dig. Everything was good. We're all good, everything's fine, you know, leave us alone.

We're doing just great. And then all these problems come out at the end, and unfortunately someone has to die because of it to really make us pay attention and say, you know, something really went wrong here. So you, you, I I know you've done a lot of thinking around OK Rs and how effective an OK R would have been for the Big Dig. Do you have a specific OK R you would have written in hindsight? Yes, you do. I knew you would. OK. So two. OK, go for it. Yeah.

So the first one is objective. The objective would be to ensure the structural integrity and safety of all tunnel components to prevent failures and ensure public confidence. And public confidence was a piece that was really lacking. And that that was definitely proven true many times

throughout. But you know, imagine if they had a key result that said, inspect 100% of the ceiling panels, the anchor systems that are holding those ceiling panels in place, and the critical hardware across all tunnel segments within within 90 days, miles of tunnels, thousands of ceiling tiles that are being installed. How many tiles have been installed? Where are we with respect to percentage? Or if we have 100% of tiles, are we 30% done?

Are we 75% done? All of those things around integrity and safety, a communications plan, maybe a website, which of course that didn't exist in the 90s, but could there have been a website for public consumption that kept people up to date on regular basis of what significant actions were happening? All of those things could have helped in tracking and, and you notice those things are not activities. Those things are measures. Those things are ways to be transparent and ways to keep

track of the progress. And these can be used, you know, as gates as you go through. So imagine they said, you know, when we're when we're at 50% of the ceiling tiles, we're going to get together, we're going to have a meeting and we're going to walk through lessons learned. We're going to have a retrospective, right? We do those today retrospectives. What have we learned? How, what can we apply going forward to the remaining 50% of the tiles? What could we, what should we

fix? What's what's worked well, what didn't work well? You know, all those things that we've learned in the last 20 years and we've gotten very good at. You can see on a project of this size how important those kinds of questions would be if we had those questions at the time. And maybe Bechtel, Parsons, Brinkerhoff did some of that. But they certainly didn't communicate it well with their government entities and didn't want to, you know, raise any red flags for fear of of people

panicking. And then they didn't want the public certainly to panic over what was being built. So I think that was one example. A second example is around the leaky tunnels. I mentioned that part of the the lawsuit involved the tunnel leaks. The second objective could be eliminate water infiltration in all tunnel systems by improving construction quality assurance

and material integrity. And the material integrity specifically that was a problem here was around the concrete that they were using to pour the tunnel walls. Some of the some of the concrete was dirty. In other words, it was mixed in with concrete not on purpose, but by accident because of the way the soil was and the way they pour the concrete. It wasn't clean in many cases. The other integrity problem was that you can't imagine how much concrete was used to build these tunnels.

And they often couldn't get enough concrete at the time that they needed to. So they just used old concrete that was leftover from a previous job. And they, again, they found this out later, there was a whistleblower. And again, I, I, you know, I've had whistleblowers on my projects.

And because I'm approachable and I'm empathetic and people come to me and say, look, this person isn't doing or that person isn't doing or this isn't working or that test failed or whatever, which wouldn't necessarily come up in a big meeting with all of these managers and VPS and CIOs, you know, in a meeting, it wouldn't come up. But they're willing to come to me because they know that I'm part of that management chain,

right? So if there is no management chain that's really well documented, people don't really know who to go to. There was a whistleblower, but they couldn't, they didn't know who to, who to really go to in in this case. And, and so I think that that can be a problem as well. The key result in that case, a real time materials tracking and verification system for all the concrete pours. Again, miles of tunnels, thousands of concrete pours. How many, how many trucks did

they have delivered? And I'm not a construction expert, I'm not an infrastructure expert. My background is in IT, but I still found this fascinating the, the size of the project, the complexity of the project. I have never worked on anything even close to this level of complexity. And, and I'm, I'm sure that many of your listeners also have not worked on a project of this complexity, but, you know, take it down to your level and say, where, where can I apply these to my project?

And how can I make these key results and metrics that we know, we keep talking, we talk about metrics, we talk about, you know, can we make the user happier? How much happier can we make them? How much can we improve our reaction time, our, our, whatever it is we're building? I think that there's, sometimes it's hard to measure those things, those kinds of things almost, you almost think in a construction project, it's easier to measure those, those kinds of things.

How many miles have we finished? How many concrete pours have we done in a software development activity in an IT organization? It's, it's harder to measure, but still we have to, we have to dig, dig deep and find out how we can measure those things and

it can be done. So I mean, in general, I think I would say that OK, ours are very powerful, helping to make your goals measurable and making them, using them as early warning signals to really help you in managing your project and measuring your, your, your progress as you go along. It definitely takes. Oh, go ahead, Donna. I. Was going to say it.

I think that, you know, as you go along and you run into problems and your, your, your metrics are not coming out the way that you expect them to, then you maybe have a problem. And that's our next, the next, that's the segue into the next section. Yeah, absolutely.

I know we're going to get into problem framing, but I, I, I appreciate your summary of OK Rs for those project managers or those, again, casual listeners of the podcast who may not be familiar with it. And the one thing you said that I want to call out is all of this what Donna shared, even though the Big Dig is such a big project, this is certainly

scalable. I'm just going to reiterate that part of what Donna just mentioned, all of the things that surround clear OK, Rs, you can create those for a project as big as the Big Dig and as small as a daily project that you might be working on. So just remember that this is

all scalable. So hopefully you're finding some value in understanding why even as difficult as it may be, as Donna called out in her previous profession of technology and trying to put metrics around something as agile as like a software or platform, it's still all doable. So you have to consider how that applies to something that you might be working on today. So let it let us transition

though to problem framing because this is actually a new term for me as well. So I'll be learning alongside our audience here. So, Donna, why don't you walk us through what problem problem framing is and how this could have been useful in the Big Dig project? Yes. So I had a project recently that I worked on where we had a big problem and we had to pivot. And how many of in your listening audience have probably had a similar situation where they've they've been on a

project? And you know, the project I was on, we, I was working on it for a year and there were people on it before that. So it, this project had gone on, we were moving our, our, our identity management system from one technology to another. And I won't bore you with the details of what we were going from one to another. The fact of the matter is part way through, we decided we were having too many issues and we needed to shift to a different

technology. And I'm not an expert in this cybersecurity in logging in and, and how to, how to make sure people are, are getting identified correctly, multi factor authentication. I, I'm not an expert in that at all. So what I had to do was partner with the technology experts and they look to me to run the project and I look to them for their tech technology expertise because how can I put a schedule together or plan together if I don't really know the technology?

I and I think that obviously in the big situation of the Big Dig, I don't know anything about construction, I don't know anything about cybersecurity, but I'm supposed to be in charge and I'm supposed to be making decisions and people are looking to me to make those decisions. And so I feel very responsible for my team to make sure they're, they're gainfully employed and they're actively working on something every day. And we're we're, we're working towards the same goals.

So problem framing is really a technique that people can use to ask the right questions so that you better understand the problem before you jump to a solution. And in the case of the Big Dig, for example, we can talk about the issues that came about as a result of the ceiling panel failure. So that's really where I want to give give you an example there. But we want to have a brainstorming session that includes all the stakeholder

groups. And I did this in, in, in my, when we had my problem that we talked about. And you need to take responsibility and schedule this meeting yourself. And then you need to run the meeting yourself. You can't sit back and expect magic to happen without being a part of that magic and, and, and really stimulating that magic to get it underway. And, you know, a lot of project managers I've worked with over the years, they, they wait for someone else to do it.

They think someone else will take the responsibility. And, you know, I, I just want to stress more, as more much as I can, the fact that if you want to be irreplaceable as a project manager, then you need to make sure that you're doing these kinds of things. You're setting up these meetings and you're, you're running them and making sure that you're understanding, you know, and you're, you're evaluating any issues and you're documenting it all.

Otherwise, it's a missed opportunity and the actions should be coming out of this problem framing situation. So let's just talk about the ceiling panels for a moment. You know, they were needed for air ventilation. Imagine a big tunnel. They all have the ceiling that's on the top. Next time you go through a tunnel, check it out. You'll see it. It's for air ventilation. It's for fire safety. So if there's a fire in the tunnel, then there's air that comes in into the tunnel from outside.

It's for for sound dampening. So it could be really loud in a tunnel. So that's that's also why it was there. The issues came about because of the ceiling tiles were really heavy. They were 3 tons each and they knew that when they put them in, they said, why are these tunnels, Why are these panels so heavy? We can we do this with lighter panels? And they said, well, they've all been ordered. So you know, that's going to delay the project if we have to reorder new tiles.

So let's just put these up. OK, we'll just put these up. And then they use this epoxy that they tested and it held, but over a period of time, the epoxy dried out and cracked and it didn't hold. So that was what caused the the problem. But so there were red flags, there were warning signs, vectors saw that there were problems. The construction people said this is kind of stupid. Why are we doing it this way?

But yet they proceeded and there were no, no whistleblowers around at the time that could really, you know, raise a red flag. And again, Vectel Parsons was kind of running the show and they were left to their own devices and they weren't raising any red flags either. So imagine that they did have some sort of a problem framing activity. The kinds of questions that they would ask include things like what's the problem that we have?

Well, the heavy panels, they've got these epoxy anchor problems. There's not great oversight. So that's really what the problem is. And how can we address that? So why haven't we solved it yet? That would be the second question that you could ask. Well, we've, we've got fragmented project ownership. We have resistance to revisiting core issues because we're under a stringent schedule and there's a lot of people paying attention to our schedule.

Imagine the ceiling, the ceiling panels went in last, of course, after the tunnel was built. So now you're already over schedule, you're already over budget. And you really want to add more schedule and more budget to an already troubled project so that that you know, the chances of that happening were unlikely. Who else has this problem? So who else has a ceiling panel problem? So we should look at other states.

Who else is building tunnels? It turned out that at one point the team flew to Japan because there was a tunnel being built in Japan similar to the one in Boston because it was on the water on the waterfront in the harbour. And they had similar problems. So they, they got some, some, some tips from the people in Japan. But that, you know, why didn't they do that earlier? They should have done it earlier. This was something that they should have done sooner.

How are we part of the problem? Well, we trust the contractors to do the right thing. We also underestimate the risks. Are we doing risk management? Probably not with deprioritizing, quality assurance and testing. And there was not a lot of testing done on the epoxy. I mentioned that they tested it immediately. Yeah, it looks like it holds it. It's good. But they didn't do any long term testing, especially for these three ton ceiling tiles. What assumptions are we making?

We're assuming that the inspectors will catch problems and they'll let us know about the problems. Well, the inspectors probably did catch problems, but they weren't speaking up for whatever reason. Oh, and once it's built, it's safe unless proven otherwise. And why wouldn't you think that? You spent billions of dollars to build these tunnels? Why wouldn't you think that? Well, it must be OK, right? It's done. Why do we need to? Why? Right. And who's been left out?

Well, the public has been left out because they have no voice in safety concerns. They're just recipients of whatever they're being told. And then who benefits if the problem is solved? Well, the public benefits because they get a safer infrastructure system. Taxpayers benefit because you're spending less money if you're doing it right the first time. So that's what that would be a step by step process to go through a problem framing

exercise. And as you walk through these questions and imagine you have them on the board somewhere and you're filling out, you're you're filling out a template maybe online or you're doing it, you know, with yellow stickies or however you decide to choose, choose to do it. You do breakout sessions, you have one group talk about each problem and figure out, and we've done it different ways whenever we have these storming sessions and you come out of it

with a set of actions. So we need more training. We need to establish better governance. We need a pet public statement and make sure we're communicating with the public. We need to new tunnel safety protocols or maintenance. Whatever the actions are, you need to collect those actions and fold them back into the plan because that's a real missed opportunity. If you skip that step, and I've been in meetings with that step is skipped and, and that's, that's, that's kind of too bad.

We talk about it after the fact that say, did we come up with any action items from that meeting or do we, do we document what we decided we wanted to do as a result of that session? So and, and, and in fact, you may want to have these on your calendar as you're going through a big project like this. So you say, where are the checkpoints along the way? We're going to bring in a red team.

And we've done this. We'll bring in a red team to examine the projects process and how successful are we at this checkpoint, especially for a project that's multi year, that's the multi, you know, multi millions, millions of dollars and even Bill this one is billions. But even if it's a multi $1,000,000 project, you know, let's let's put in some gates so that we can check on ourselves.

I think an agile development process has those gates kind of built in. But some of these projects that this certainly wasn't an agile project, that's for sure back in the 90s. But imagine a big project that is not an agile project because many big projects really cannot be done using agile. It's just imagine a government contract where you're building a radar or you're building an aircraft carrier or you're building a drone.

These are huge projects and the government has spending, you know, millions of dollars to build these things and agile doesn't work. And, you know, not in all cases. I mean, so now you have to build those, those checkpoints in yourself. You're the project manager, you're in charge. You have to be putting these things in place. No one else will. And if you don't do that, you know, you could be replaced. And I've, again, I've been on projects where project managers

have been replaced. That's happened to me, that's happened to colleagues of mine where they don't feel the project is being managed carefully enough, with enough rigor, with sometimes they put a team of project managers in place instead of just one person. They put a group of people in place and, and they have a Direct Line to, you know, the VP that's in charge because it's a

high priority project. You know, imagine there's some sort of a cyber event and you've got to get your systems back up and running and, and the CIO is being questioned by the CEO. What's going on? Where are we, you know, that might be a project where, you know, there's a daily meeting and there's there's all kinds of criticality and it's critical issues and people are really scurrying around.

You could that's similar kind of project to what we're talking about here where it's like serious stuff. If it doesn't, if it's not right, then there's a problem. I imagine something in the healthcare industry, same thing if it's not right that there could be a serious problem. So these are the things that we're talking about that that you really need to get outside of your comfort zone.

You really need to be looking at yourself critically and how how well you can, you know, run these projects. Are you collaborating well enough? Are you coordinating with all the players? I mean, all the players, not just your favorites, all of them. Are you, are you inviting third party people in to critically examine what's happening? And do you respect those people? Not you're not just bringing your buddy in who's gonna say, yeah, you're doing a great job.

You know, you're looking for real criticism from people you respect to come in and take a look at what you're doing. And how well are you communicating with not only your team, 'cause I'm really good at communicating with my team. I'm a team builder. That's kind of my strength. But how well am I communicating up to my management team and how well am I communicating with other parts of the project? Because often there's more than one part of the project.

I know on the project I mentioned earlier where we were doing multi factor authentication and all that, there were multiple players and Infosec was one of them. And I was really good with them and not as good with the Microsoft Azure people of the cloud people, although I needed to talk to them too because that was part of what we were doing. I wasn't as good at talking with them, but I was really good with Infosec. I was in, you know, in good with them. So you know, how well are you

and be critical of yourself. Like how, how, how am I doing here? We're in a, we have a problem situation. We need to solve it. And it's that's, I always say, you know, when things are good, things are good. But when the chips are down and the chips are down, we really see who's the good player and who's, who falls aside or who falls apart or who falls to the wayside. And it goes in the background. Who really comes to the front and says we need to fix this?

And how do we fix it? And I'm here to help and I'm here and I can be a critical resource here.

And that should be you. Yeah, yeah, absolutely. I can't help but go back to when we started the conversation and how you mentioned that project management on this particular project turned over multiple times throughout the course of

the project. And how a lot of these potential solutions you brought forth, communication, clarity, the OK Rs, the problem framing and sprinkling that throughout your process flow, having those often, those conversations often and understanding who your stakeholders are, all of that.

I feel like the turnover of the PMS also carries weight into all of those potential solutions that you brought forward into how this project could have been executed a little bit differently and maybe more successfully. But have you had any thought as we kind of get to the main takeaways of of what could have been better avoided or successes of the Big Dig? Have you had any thought, Donna, on how much of that played into it?

Was it A? Was it the perspective of the companies that they just didn't understand the role of project management and the value that it was supposed to bring to this project is I think that's what I'm more curious about and if you've had any thoughts on that. So, so Bechtel Parsons Brinkerhoff is an organization that has built many huge infrastructure projects for the government.

They built embassies, for example, and part of the lawsuit that they had against them was to disbar, disband the company. And the government said that's that's a non starter. We, we can't, we can't do without Bechtel. They have too much history, too much knowledge of how to build these huge infrastructure projects. We can't, we can't live without them. So I, I don't think that I don't know that they took the big Dig as seriously as they should have.

I, I think the, the original, so the very first tunnel that was built was the Ted Williams Tunnel. And that is a tunnel that that connects South, southern, the southern part of Massachusetts, Quincy, Braintree, the parts South of Boston to the airport, which is in, in East Boston. So the Ted Williams tunnel was the first tunnel that they built. And it was the easiest, absolute easiest tunnel that they built because why? There's nothing in the water between those two places.

Not there's no, no subway, subway tunnels. There was no sewer, sewer pipes. There was no electricity or cable or, or any other infrastructure items underneath that water at all. They built the tubes somewhere else, They sunk them in the water. They connected them together and they had a big party because it was on time, on schedule, and everybody was happy. Problem was it wasn't connected to anything.

It was just laying in the bottom of the of the water there and you could drive in it, but you, it was not easy to get to like you cut, you had to. I don't even know how they drove in it, to be honest. I think they probably put a car in the water somehow. I don't know. Anyway, it was building the connectors through these weird

spots that was the hard part. And I think when they saw how easy it was to build the Ted Williams tunnel, I guess they probably thought, oh, this is going to be easy. But it was not interesting. One part of the tunnel. And again, I could talk for hours about the Big Dig, but there was one part of the tunnel that was so hard. It took, I think, five years to build this one stretch. It takes you 10 minutes to drive through that one particular part

of the tunnel. It's a 10 minute thing that caught, it's the most expensive tunnel in the United States, that one little chunk, because it was so complicated because there was a subway tunnel under it and there was another tunnel somewhere. It was just very complex. So anyway, the fact of the matter is, I think the fact that they turned over project managers over and over again is largely because they probably said, well, we need someone who

has this, this domain expertise. We need this, this domain expertise. We need that domain expertise. Oh, we now we need that domain expertise. Do you know how to build a bridge? OK, now we need a bridge person. Oh, now we need a tunnel person. Oh, now we need a, a cement person. So they maybe they were, they're switching that around and, and that I've seen that happen where I work. So you, we need someone who knows a lot about HR, for example, we're putting an HR system together.

We need that domain. Oh, we're doing in, we're doing a networking system. Who knows about net? What project management has manager has done a networking project before. Let's put that person on there. And so we, we start to develop like you start to develop some domain expertise and then you're known for that. And so they put you on that until things don't go well and they put somebody else on it. So I, I do think it's a problem

of turnover. But again, if you think about an agile project, you've got a scrum master, you have a project, you have a product owner and you have, you know, a lot of team members and you've kind of got each other's backs, right. But in this case, you know, when you you're in charge of the whole thing, it's one what person responsible for the success or failure. It's a it's a heavy load and you've got to be up to the challenge on it. I think this subject alone,

because you said there's a podcast that that's six episodes long. I agree with you, Donna. I think this is fascinating for so many reasons, in particular for project managers to listen to and learn from. So do you have any other key takeaways that you want to share with the group before we say goodbye to everybody today? Yeah, I mean, I just, if I were to summarize, I think the you, you did a nice job of summarizing just a moment ago.

And you know, you've got the OK Rs to really define what success looks like. The problem framing techniques that really should be put in place to uncover root causes and and establish some new actions as a result. Those are almost a, a form of retrospectives, a form of lessons learned. We are really digging into one particular area and not doing those kinds of things can be a

missed opportunity. And then using Rd. maps and and plans to put in place to really track all of those solutions and make it relatable and scalable. But you know, again, putting myself in your shoes of the shoes of your audience members and really trying to relate this to their own work, what can we learn? It's to be proactive and not

reactive. And, and you've heard that before, but with the backdrop of the big dig, it really it really, you know, it really, it really is true that you really do need to be proactive. You need to build systems of

transparency and accountability. So when you get that phone call from your VP and he says where are we with this project, you can make data-driven decisions based on the fact that you're collecting metrics, you're collecting data and you have some, some, you have some sense of where you're at because as the project manager, you're responsible and you're the one who knows a little bit about what everyone's doing.

You don't know everything. You're not the cyber expert, you're not the infosec expert, you're not the construction or concrete expert, but you know a little bit about what everything everybody is doing and where we are with respect to percent complete and where we are with respect to the schedule. And then focus not just on delivering the project, but how you deliver it. And the public is very interested in that in this case. And I think that makes a big

difference as well. I think ask better questions, plan for quality and never assume success without verification from someone that it's successful. So I think that that's really the the real lesson from the Big Dig is do better with clarity, honesty and real structure around your projects. This has been extremely

insightful, Donna, that was such a great summary and can be applied to almost any project, right? So thank you for that. If folks want to continue the conversation, I am itching to keep talking to you about this, but I know we have limited time today. If folks want to continue the conversation with you about the Big Dig or just learn more about what Donna's up to these days,

where can they find you online? Yeah, I have a great website, itsdonnagregorio.com and reached out to me and LinkedIn as well. I'd be happy to continue the conversation with with anybody that has any sort of project management questions at all. And I want to say thank you to you Ann for continuing with your everyday PM podcast. It's a, it's a great resource and I hope your audience recognizes it's a, it's a lot of effort to keep it going and I'm proud of you for all you do.

So thank you. Well, thank you so much, Donna. I appreciate it. So definitely reach out to Donna if you want to chat with her further. You can follow me on LinkedIn as well at and Campia. And I look forward to hearing your theories on how the Big Dig could have been more successful or maybe you found that it is successful. I mean, it's, it's your take based on what you've learned today. So that will do it for Donna and I for this installment of the

Everyday PM podcast. Thank you all for joining us and listening in. And until next time, take care.