6 hours 23 minutes
Hello and welcome back to Enterprise Project Management Lesson 15.
Preventing enterprise project Failure
This is your instructor a cane,
and this is one of those really interesting subjects that I wish
I could give you, some sort of prescriptive
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
100% prescriptive way to prevent it.
What we can do is look at the elements within a enterprise project
and look at some of the things that might end up causing project failure,
so preventing a project failure.
The first thing that I want to talk about is the project Charter, and the Project charter is key
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.
when things come up, it becomes less of an issue of discussing
whether or not, We will or won't
do certain things because again, every thought in the charter then the answer is no
by default. And then, of course, you could modify the charter via change management and all that kind of stuff. So
you don't want to be, you know, the negative Nancy in your
part of your role as an enterprise project manager is to be
Maur of the realists in some ways to kind of say, Hey,
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
a lot of issues that lead to enterprise project failure.
In addition to that,
you want to build
a level of organizational tension
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,
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.
What I'm trying to say is that you want a certain amount of organizational tension because each person for each group
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
and anything outside of that,
you're gonna kind of want to run the red flag like hope. This is outside of my existing scope, schedule and budget,
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.
again, you're kind of being captain. No, in the sense of we have a we need to engage the formalized process
with which to do this. So that's the beginning of some organizational attention.
The PSC, which is made up of your
mid two senior managers,
have to be able to put
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,
what is best for the project
That's going to be the primary decision that I'm going to make.
a good example of that. This is Ah, real world example from one of my previous PSC
We had a change request come in. That was gonna de scope the project, meaning it was gonna take things out of scope
in order to bring the project in on time. Otherwise, the project was gonna be late.
The vendor, the developer
was not going to get ah, a discounted price. Meaning the vendor was going to get a full
even though we took a significant chunk of the scope out of the project
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,
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
they go live date That was within our parameters. So that's an example of kind of how the PSC views things.
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,
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,
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,
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
the vendor is getting paid full price for functionality that they're not gonna deliver,
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
within the enterprise project environment
as a result of the organizational tension. So again, it's not
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.
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,
and therefore they may have their own view of what's best for the product
in the regards of
the delivery phase. So
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
any body within those four groups or individuals
a veto power, if you will, because what you end up with is what's called gold plating. So
if you allow the project sponsor to kind of run amok
without any kind of accountability to the project Team P, S C or D SC, then they're going to want
as many things as they can all the time
delivered right away. Money is no object, because why not there? If nobody is telling them? No, it's in their own best interest
to ask for as much as possible. So again, if you're building a house
and you could get a pool and a deck in a hot tub and all these things,
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.
So gold plating
really is causes. What's called runaway spending and runaway spending is
one of the primary reasons why projects fail, because if you spend too much money, then you no longer get a positive our ally,
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.
If a project is an investment, it's not a thing that you're going to get at the end of it.
Then do you really care what it looks like? How you do it is to use things that nature.
I understand that as a consumer you do here. But as an investment,
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
in excess of what I could earn if I just take that money and put it in the stock market.
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.
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.
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,
and finally, you want to think about your enterprise changed tolerance. So if you're
unable to change the culture and the enterprise and the organization
as quickly as you want to develop your enterprise project and deliver that value than that, value is kind of going to waste.
So all of those things can cause runaway spending. And you want to think about those things in terms of
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
that concludes the video. Look for the rest of the lesson in the following video.
Thanks again. Have a great day.