16.1 Case Studies Part 1

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or

Already have an account? Sign In »

Time
6 hours 23 minutes
Difficulty
Intermediate
CEU/CPE
6
Video Transcription
00:01
Welcome back to Enterprise Project Management
00:04
Lesson 16 where we go over various case studies
00:09
in Enterprise Project Management We're gonna do to case studies
00:13
one that did not work out so well and one that did work very well
00:18
for the first case study is going to be about the Airbus A 3 80
00:22
Uh, you look at the link here on the video and the link should be available to you down below in the comment section.
00:29
Go ahead and take 15 20 minutes to read about the Airbus A three. Hit your project and then we will go over it.
00:48
Okay,
00:50
Now that you've had a chance to read over the Airbus A 380
00:54
project,
00:56
let's talk about various lessons learned.
01:00
So the project was a success in the sense that they didn't produce an aircraft,
01:04
but they had a lot of painful lessons that they had to learn.
01:08
So what was the first lesson they learned?
01:11
They learned that they had to integrate and take
01:15
and make
01:17
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
01:26
the leadership of the organization did not
01:30
make and enforce an enterprise wide decision.
01:34
So one of the things that you could take away from this case study is the fact that
01:38
if you're in the Enterprise Project,
01:42
uh, game, if you will,
01:44
you have to make enterprise project decisions. You can't advocate your authority
01:49
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
02:04
the two systems was north of $5 billion. So how many organizations do you know
02:12
that we're gonna be able to withstand a $5 billion hit?
02:15
The answer is not too many.
02:17
Even within government. You can't make a $5 billion mistake and get away with it. Typically,
02:25
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
02:35
to really unify the efforts. And it has less to do with the technical side of the House and and more to do with
02:40
the strategic alignment of the projects to the organization. They did not
02:46
really in Call Kate
02:47
that
02:49
we were going to do this large aircraft development project. We're gonna build this new aircraft the largest, the temperament built.
02:58
That's the primary goal. Not her protecting not, you know,
03:04
keeping your countries
03:07
Airbus
03:08
factories going, all that kind of stuff. It was. You really want to do this once in a lifetime, never before been done
03:15
project. And we need your help. So by failing to unify the project team,
03:21
the project team itself was not looking for solutions to the problems that they faced
03:30
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
03:38
the organization and enterprise project to the strategy of the organization.
03:45
So one of the things that you'll see with infighting and infighting tends to happen.
03:50
Win.
03:51
You have a dis alignment of the organization, the project team organization strategy.
04:00
When we don't have a higher calling than ourselves, are
04:03
division or our work group or whatever.
04:06
You tend to find yourself in those types of conflicts where
04:13
I don't necessarily care what's best for the organization. I care what's best for my division,
04:18
not fully understanding that what's best for your
04:21
division is dependent on what's best for the organization the organization goes out of business. Well, then
04:28
you're out of a job. So it is really matter what your division is doing. So they did not align
04:32
the organization as a whole and the project and the project team to the strategy of what the organization was trying to do
04:41
in regards to building this Airbus A three.
04:46
They also failed to
04:49
really put in place a good configuration management database, or CMB, be
04:55
so they did not fully appreciate
04:59
the importance of the CME to be understanding their information technology universe, as we talked about in a previous video,
05:05
two
05:08
really be able to drill down and understand what conflicts might occur if, in this case, you have two different can systems
05:17
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.
05:27
It sounds sort of comical, but the reality is is that is a huge issue. Knowing your eye universe,
05:33
knowing what you have on board
05:38
is critical to understanding why or why not. You have various problems. So as soon as the prototype was being built
05:47
and the wire started coming up short,
05:50
then
05:51
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
06:02
are using two different types of CAD software or two from versions whatever,
06:08
and we need to fix it. So let's get us all on the same page.
06:12
Failing to do that led to months and months of delay,
06:16
which actually ended up causing the organization a significant amount of money.
06:20
Five point something $1,000,000,000.
06:24
That is not a small amount of money. And I think the delay waas
06:29
six months or more. It was a substantial. So
06:33
not having a good C M D B
06:38
added to the problems at the project team faced.
06:43
And finally,
06:45
the last element we're gonna look at from this case study
06:48
is that the schedule itself
06:50
potentially was too aggressive. Now,
06:55
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
07:02
you don't know what you don't know. But
07:05
when you have a very, very aggressive schedule,
07:09
a soon as you have something that tends to trip up that schedule,
07:13
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,
07:20
we have extremely aggressive schedule. The timing is very, very tight, And yet we have this issue,
07:28
which maybe could have been fixed in a couple of days. In reality, that did not happen.
07:32
So when you're
07:33
you have multiple iterations, multiple dependencies of very, very complex enterprise project
07:43
with an aggressive schedule that creates a lot of,
07:46
you know,
07:46
competing
07:48
priorities.
07:49
We talked about the old Iron Triangle well, the Iron Triangle
07:53
appliance, everybody.
07:55
So we have a very, very high level off
07:58
performance criteria, a very, very high level of schedule dependencies,
08:05
and not that
08:07
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.
08:16
There's a lot well, there should be a lot of organizational priority to fix the schedule.
08:24
If you don't have the organizational priority than what you have is the sort of decision making
08:31
CMD be conflicts, project team conflicts, et cetera. They just wanna hang out and fester for months and months and months on end.
08:39
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
08:48
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,
09:01
uh,
09:03
cam's offer that we're gonna use
09:05
that would have prevented some moral project issues. In addition,
09:09
when the project team is more worried about her protecting than they are about supporting the organization and the project that creates issues
09:18
failing to forsee
09:20
the conflict between the different cad uh, Softwares
09:24
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,
09:33
we've got different versions. We have to resolve this issue, and then when you pile all of that onto an aggressive schedule.
09:43
Those types of delays that come from building the prototype Having the wires up too short
09:48
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
10:01
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,
10:11
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.
10:22
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
10:28
bright, too.
10:31
The end degree
10:33
Thank you. Have a great day
Up Next
Course Assessment - Enterprise Project Management
Assessment
30m