15.1 Preventing Enterprise Project Failure 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:00
Hello and welcome back to Enterprise Project Management Lesson 15.
00:05
Preventing enterprise project Failure
00:09
This is your instructor a cane,
00:11
and this is one of those really interesting subjects that I wish
00:16
I could give you, some sort of prescriptive
00:19
brought to go down that guaranteed 100% of time that you won't have a project failure. And again, if I could, I would be a very, very wealthy man. Unfortunately, projects fail for a myriad of different reasons, and there's no
00:37
100% prescriptive way to prevent it.
00:41
What we can do is look at the elements within a enterprise project
00:47
and look at some of the things that might end up causing project failure,
00:54
so preventing a project failure.
00:56
The first thing that I want to talk about is the project Charter, and the Project charter is key
01:02
to preventing project failure because it is, as we said before the project's constitution. So if you have a hard and fast rule that says if it's not in the Constitution, we can't do it, which is very similar to our legal system.
01:18
Then
01:19
when things come up, it becomes less of an issue of discussing
01:23
whether or not, We will or won't
01:26
do certain things because again, every thought in the charter then the answer is no
01:33
by default. And then, of course, you could modify the charter via change management and all that kind of stuff. So
01:41
you don't want to be, you know, the negative Nancy in your
01:46
organization. But
01:49
part of your role as an enterprise project manager is to be
01:53
Maur of the realists in some ways to kind of say, Hey,
01:57
I know that we want to do this and it will be great if we could, but we need to modify the charter. So let's go back, meet with the PSC, look at doing a formalized change request so that we can add the X, Y and Z that you want to your project. So that's kind of what I mean by the by the charters key. If we go by the charter, then we will prevent
02:15
a lot of issues that lead to enterprise project failure.
02:22
In addition to that,
02:23
you want to build
02:25
and maintain
02:27
a level of organizational tension
02:30
within your enterprise project, and I've said it before a previous video. But this is not a bad thing you don't want conflict. You don't want,
02:39
uh, people to be running away and bureaucracy used to take over and stuff get out of control. That's not what I'm trying to say.
02:46
What I'm trying to say is that you want a certain amount of organizational tension because each person for each group
02:53
focus is a little bit different. So, for example, if you're the project manager, you're focused on scope, schedule, budget, scope, schedule, budget scope, schedule, budget
03:04
and anything outside of that,
03:07
you're gonna kind of want to run the red flag like hope. This is outside of my existing scope, schedule and budget,
03:14
and therefore I don't want to do it. So that creates a little bit of tension between you and say, the customer or the sponsor.
03:21
Because
03:23
again, you're kind of being captain. No, in the sense of we have a we need to engage the formalized process
03:30
with which to do this. So that's the beginning of some organizational attention.
03:35
The PSC, which is made up of your
03:38
mid two senior managers,
03:40
have
03:43
have to be able to put
03:45
their project blinders on a little bit and continue to ask themselves, Is this best for the project. So when these change requests come up and these other issues and thinking get delayed and life happens, they just need to continually look at okay,
04:00
what is best for the project
04:02
That's going to be the primary decision that I'm going to make.
04:08
Um,
04:09
a good example of that. This is Ah, real world example from one of my previous PSC
04:15
memberships.
04:16
We had a change request come in. That was gonna de scope the project, meaning it was gonna take things out of scope
04:23
in order to bring the project in on time. Otherwise, the project was gonna be late.
04:29
The vendor, the developer
04:30
was not going to get ah, a discounted price. Meaning the vendor was going to get a full
04:38
paid
04:39
contract
04:40
even though we took a significant chunk of the scope out of the project
04:45
that you might say, What? That's terrible idea. Why would you pay for less than what you agreed to So on so on. And that is a very, very valid argument. However, remember, within the PSC, we're putting our project blinders on, and we're saying,
04:59
is this best for the project and the driver for that project was the go live date. So we made the determination that by de scoping the project, we would end up with
05:11
they go live date That was within our parameters. So that's an example of kind of how the PSC views things.
05:16
So while the PSC is interested in what's best for the project, I e getting the project delivered on time, even if we had to de scope it,
05:27
the E S C is going to be focused on Maura of the organization and less about the project. So the PSC puts their blinders on. They make a recommendation that says yes, we need to de scope this project,
05:40
that decision, if it's above the threshold that you previously set up, gonna get escalated to the E S C and the D s ees and ask the question. Well,
05:49
this is good for the project. But is this the best decision for the organization? And if the answer to that is yes, then even though
05:58
the vendor is getting paid full price for functionality that they're not gonna deliver,
06:04
it's still the best decision for both the project and the organization. So they go ahead and approve it so That's kind of a real world example of something that happens
06:13
within the enterprise project environment
06:16
as a result of the organizational tension. So again, it's not
06:20
acrimonious. It's not outright hostile environment. It's just different groups of people that have a different primary motivation. So the primary motivation of the PSC is to be loyal to the project, make good project decisions.
06:34
The primary focus of the E S C is to be loyal to the organization and make organization wide decisions that are best for the organization. And then finally, you have the project sponsor, which may or may not be a member of the S E. But the project sponsor, of course, is the consumer of the final product,
06:53
and therefore they may have their own view of what's best for the product
06:58
or project
07:00
in the regards of
07:01
the delivery phase. So
07:04
what you don't want to do is the line off when you do want to do with line the goals of the P, M. P s, C, E. S. C, and sponsor to the goals of the organization. But what you don't want to do is allow
07:16
any body within those four groups or individuals
07:20
to have
07:21
a veto power, if you will, because what you end up with is what's called gold plating. So
07:28
if you allow the project sponsor to kind of run amok
07:32
without any kind of accountability to the project Team P, S C or D SC, then they're going to want
07:40
as many things as they can all the time
07:44
delivered right away. Money is no object, because why not there? If nobody is telling them? No, it's in their own best interest
07:54
to ask for as much as possible. So again, if you're building a house
07:58
and you could get a pool and a deck in a hot tub and all these things,
08:03
why would you not ask for them left in your own best interest? So people tend to kind of behave in their own best interests.
08:09
So gold plating
08:11
really is causes. What's called runaway spending and runaway spending is
08:18
one of the primary reasons why projects fail, because if you spend too much money, then you no longer get a positive our ally,
08:26
and it makes the project a bad investment. So how do we prevent runaway spending? Well, first, what you need to do is treat projects as investments.
08:33
If a project is an investment, it's not a thing that you're going to get at the end of it.
08:39
Then do you really care what it looks like? How you do it is to use things that nature.
08:45
I understand that as a consumer you do here. But as an investment,
08:48
I don't really care if it's built on the latest greatest technology. So on someone, what I care about is is my investment going to return me value
09:00
in excess of what I could earn if I just take that money and put it in the stock market.
09:05
So if you treat a project as an investment, then you tend to look at things differently than if you treat a project as a new cool thing that I'm gonna get on the back end.
09:16
You also want to think about agile, so agile has a time constrained development process that's designed to bring value to the organization sooner, which is great.
09:26
But
09:26
a lot of times the visibility into how much your project is costing the organization isn't there, so you want to develop systems for that,
09:35
and finally, you want to think about your enterprise changed tolerance. So if you're
09:41
unable to change the culture and the enterprise and the organization
09:46
as quickly as you want to develop your enterprise project and deliver that value than that, value is kind of going to waste.
09:54
So all of those things can cause runaway spending. And you want to think about those things in terms of
10:01
how much am I spending? What value am I getting? Can my enterprise take advantage of that value? Because if the answer to that any of those three is no, then you kind of want to curtail that project
10:13
that concludes the video. Look for the rest of the lesson in the following video.
10:18
Thanks again. Have a great day.
Up Next