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.