6 hours 23 minutes
Welcome back to Enterprise Project Management
Lesson 16 where we go over various case studies
in Enterprise Project Management We're gonna do to case studies
one that did not work out so well and one that did work very well
for the first case study is going to be about the Airbus A 3 80
Uh, you look at the link here on the video and the link should be available to you down below in the comment section.
Go ahead and take 15 20 minutes to read about the Airbus A three. Hit your project and then we will go over it.
Now that you've had a chance to read over the Airbus A 380
let's talk about various lessons learned.
So the project was a success in the sense that they didn't produce an aircraft,
but they had a lot of painful lessons that they had to learn.
So what was the first lesson they learned?
They learned that they had to integrate and take
enterprise wide decisions. So when the two different offices between France and Germany started arguing about the version of the cans off where they were going to use
the leadership of the organization did not
make and enforce an enterprise wide decision.
So one of the things that you could take away from this case study is the fact that
if you're in the Enterprise Project,
uh, game, if you will,
you have to make enterprise project decisions. You can't advocate your authority
and allow disparate groups to behave in a manner that's going to hinder the enterprise project execution. If you recall the total cost of the delay from the failure to integrate
the two systems was north of $5 billion. So how many organizations do you know
that we're gonna be able to withstand a $5 billion hit?
The answer is not too many.
Even within government. You can't make a $5 billion mistake and get away with it. Typically,
they also failed to unify the project team so early on in the project, they did not bring all of the appropriate stakeholders into the group
to really unify the efforts. And it has less to do with the technical side of the House and and more to do with
the strategic alignment of the projects to the organization. They did not
really in Call Kate
we were going to do this large aircraft development project. We're gonna build this new aircraft the largest, the temperament built.
That's the primary goal. Not her protecting not, you know,
keeping your countries
factories going, all that kind of stuff. It was. You really want to do this once in a lifetime, never before been done
project. And we need your help. So by failing to unify the project team,
the project team itself was not looking for solutions to the problems that they faced
kind of go along the same thing. So in addition to unifying the project team and creating one team and one team environment, they also did not align
the organization and enterprise project to the strategy of the organization.
So one of the things that you'll see with infighting and infighting tends to happen.
You have a dis alignment of the organization, the project team organization strategy.
When we don't have a higher calling than ourselves, are
division or our work group or whatever.
You tend to find yourself in those types of conflicts where
I don't necessarily care what's best for the organization. I care what's best for my division,
not fully understanding that what's best for your
division is dependent on what's best for the organization the organization goes out of business. Well, then
you're out of a job. So it is really matter what your division is doing. So they did not align
the organization as a whole and the project and the project team to the strategy of what the organization was trying to do
in regards to building this Airbus A three.
They also failed to
really put in place a good configuration management database, or CMB, be
so they did not fully appreciate
the importance of the CME to be understanding their information technology universe, as we talked about in a previous video,
really be able to drill down and understand what conflicts might occur if, in this case, you have two different can systems
that were being used one in France, one in Germany and then lo and behold, all of a sudden when you were trying to actually build the airplane, all your wires were too short.
It sounds sort of comical, but the reality is is that is a huge issue. Knowing your eye universe,
knowing what you have on board
is critical to understanding why or why not. You have various problems. So as soon as the prototype was being built
and the wire started coming up short,
ideally, the CMD be manager or the C M D B director should have been able to drilled out of that problem and realize, Hey, the French team and the German team
are using two different types of CAD software or two from versions whatever,
and we need to fix it. So let's get us all on the same page.
Failing to do that led to months and months of delay,
which actually ended up causing the organization a significant amount of money.
Five point something $1,000,000,000.
That is not a small amount of money. And I think the delay waas
six months or more. It was a substantial. So
not having a good C M D B
added to the problems at the project team faced.
the last element we're gonna look at from this case study
is that the schedule itself
potentially was too aggressive. Now,
in high inside, you can say, Yeah, it was too aggressive at the time. It's hard to make that argument necessarily. It's hard convincing we make the argument because
you don't know what you don't know. But
when you have a very, very aggressive schedule,
a soon as you have something that tends to trip up that schedule,
it's imperative that you are the one as the project manager to kind of raise a red flag to the organization and say, Hey, look,
we have extremely aggressive schedule. The timing is very, very tight, And yet we have this issue,
which maybe could have been fixed in a couple of days. In reality, that did not happen.
So when you're
you have multiple iterations, multiple dependencies of very, very complex enterprise project
with an aggressive schedule that creates a lot of,
We talked about the old Iron Triangle well, the Iron Triangle
So we have a very, very high level off
performance criteria, a very, very high level of schedule dependencies,
and not that
the project had a limited budget, but the budget was more flexible. But in that environment, when you have these issues were all of a sudden you're scheduled starts to slip.
There's a lot well, there should be a lot of organizational priority to fix the schedule.
If you don't have the organizational priority than what you have is the sort of decision making
CMD be conflicts, project team conflicts, et cetera. They just wanna hang out and fester for months and months and months on end.
And before you know it, five plus $1,000,000,000 has gone down the tubes. So I think that if, uh the Airbus A three game project
had been Maur unified as a project team had been Maur integrated and had made effective enterprise wide decisions early on in the project, like what version of the,
cam's offer that we're gonna use
that would have prevented some moral project issues. In addition,
when the project team is more worried about her protecting than they are about supporting the organization and the project that creates issues
failing to forsee
the conflict between the different cad uh, Softwares
is really a failure in the CME dee bee world, where if you had a good CMD manager, they would have voiced up very early that Hey,
we've got different versions. We have to resolve this issue, and then when you pile all of that onto an aggressive schedule.
Those types of delays that come from building the prototype Having the wires up too short
causes huge schedule issues, which is always gonna be a problem. But it becomes a much more significant problem when that schedule is very, very, very aggressive
right from the onset. So you don't have any slack built into that schedule to absorb the problems that you're facing. So you not only have a failure, too,
predict the problem and a failure to understand your iittie universe. But you also have a schedule doesn't give you any leeway to address those kind of issues when they happen.
So that's the first case study where kind of things went wrong in our next case study. In the next video, we'll look at where things went
The end degree
Thank you. Have a great day