6 hours 23 minutes
hello and welcome back to Enterprise Project Management less than 15.
In the first part of the lesson, we talked about organizational tension and other things that we can do best practices
to prevent enterprise project failure. We're going to wrap this up in the second video,
looking at other items and
issues that can cause project failure and how to prevent them.
one of the largest, if not the largest, reason why enterprise projects fail is you have various types of stakeholder conflicts. So
talking about stakeholders earlier
stakeholders can be anybody from the consumer of the good to the person financing the project or product.
And when they conflict,
quite a few issues. Um,
largest generation, you know, causes project failure if it totally gets out of control. And so
a big part of a project manager's role is to prevent those types of stakeholder conflicts
or manage them. Really, reading is hard because you have to foresee things that you really can't see.
But when they happen, you need to manage them
in order to create a positive end state.
So part of that
is the project governance, which we talked about with an organizational tension from the last video.
Uh, what the PM does the PSC, The SC does all those air part of project governance, but they have a role, and their role in addition to
managing the project itself, is to manage those stakeholder conflicts so that
when conflicts arise, as they typically do,
role is there and is pre established to manage them. So when the stakeholder disagrees with the project manager about a particular issue within the project,
there's a set Siri's of steps and processes
that help manage those conflicts. So if the project manager wants to cut the project to the bone,
and the project sponsor wants everything under the Sun,
which are very normal things, and that's fine.
But the government is really there, look at again what's best for the project at the PSC level, what's best for the organization at the E S C level, and through that process, the idea is that we can get to a
level of agreement within the various conflicting stakeholder groups,
so project governance is role is really there to help
develop a process by which we manage these conflicts. In addition, The project sponsor has a rule because the project sponsor is
the bill payer, which creates a certain amount of
But they're also the consumer typically of the enterprise project product, so
their role is really too.
Be an advocate for whatever. The thing is that you're developing your building.
And so the sponsor is there to kind of help everybody keep
their eye on the prize a little bit, if you will. Because in any bureaucracy in project management, especially at the enterprise level, tends to create its own bureaucracy,
gets hung up on the process a little bit and usually a little bit too much.
Whereas the product sponsor, the Project sponsor,
looks at the product, What's the thing that the organization is going to be able to do
after the conclusion of this project? So the sponsors vision is not so much focused on
the process of building. Whatever the thing is, it's more about what this thing is going to do for us once it's live. So the project's sponsors roll is really surrounding
advocacy changed champion whatever you wanna call it, but they're there to sort of remind everybody that
what we're doing is greater than the sum
off the parts. You know, we're doing something great in dynamic for the agency, for the organization. Whatever.
what that does tend to create is a project sponsor who is a maximum miser.
And there's a link there, which will be available below this video that talked about satis satis fication versus maximization. But the sponsor is the Maxim miser in the sense we talked about it in the last video
that they want everything under the sun
that can possibly be added. They want the gold plated stuff. They really want this great product
at the end of this project, and that's their role. And that's fine. That's way that this is supposed to be.
But when you have conflicts between various stakeholders, one of the problems that you'll have is a maximize er, like the project sponsor
will butt heads against the saddest the satisfied sir,
who is just trying to
determine the minimum requirements, the minimum to go live like What do we need to do
to complete this project? That's what I'm going to do, so you have to sort of look at
various stakeholders, identify as early as you can
Who are your maximize? Er maximize er's And who are your satisfy sirs,
so that when those conflicts arise, you kind of can play a role as sort of a middleman to say, Okay,
it would be great if we could do that.
to get the product live to get this project complete,
let's just meet the minimum requirements
and then have a face to a phase three enhancement cycles. All that kind of stuff, a lot of time, especially 19 projects,
or whoever you're stakeholder is as the maxim, Isar looked at this as their one shot
to improve the organization to get this thing right.
And so they become
greedy in the sense that they want everything that they can possibly get
wrapped up into the project as opposed to the product or the system that you're building
in order to get all the things that they want
to fix their
part of the ordination, their their view, what the organization is missing.
So the old saying is, the enemy of good enough is perfection, and what that means is, you know, if you focus so much on getting the perfect
project, the perfect product, the perfect system.
At the end of this,
you may find yourself spending so much time and money
fixing these first perceived bugs
that may not actually be bugs
at all or they may be so minor is to not be worth the effort that you're putting into them.
So one of the things that you need to keep in mind is that as a project manager, especially,
you want to be a satisfied sir. You do not want to be a maximize er, and that's hard. It's really, really hard to do because you're invested in this new
for good reason, like you're a believer. You drank the Kool Aid and that's great.
But now I want to come when it comes time to execution. How do you fit that into what's realistically possible? So good enough is what's realistically possible.
Perfection is very seldom, if ever, truly possible to execute.
So we've looked at
the different conflicts and where
projects kind of get out of control a little bit because you've got Maxim iron maximize er's. You don't have the level organizational tension that you probably should have,
and so projects and kind of get away.
Hopefully, they don't. But if they do, you have a reel him back in,
and then we need to look at actually completing in closing the project. Projects
that get out of control tend to stay open
forever and ever and ever, and they never quite close out. They never quite call it good enough.
So within the idea of defining completeness again, what are the minimum things this
product or system has to do
in order to go into production
and what those are or what they are? And if they're in the charter, hopefully they are. Then you just define them. You stick to it and this is no doing this extra thing. That's an enhancement. That's an enhancement. That's enhancement.
I'm doing what's in the charter, and then I'm going live. So that's kind of really important. Key to preventing project failure is really defining completeness
based on, you know, documents like the charter and then sticking to it.
And then once you close the project, you really want to look at and document lessons learned.
You wanna have good documentation for your system itself,
and you want to provide training because again,
if you don't
If you produce the coolest thing ever since sliced bread and nobody uses it, then it's really no value to the organization. So
closing a project of the very challenging thing. But you really want to focus on those areas that are often overlooked lessons, learned documentation and then end user training. And if you focus a lot of time and energy on those things, you will have a successful enterprise project.
So in summary,
we talked about preventing project failure through various means. Organizational tension, preventing gold plating.
looking at project governance rules. The sponsors rules things of that nature. We also talked about closing project and some of the challenges that you'll find
when you have maximum misers as part of your stakeholder group versus Satisfy Sirs.
So thank you so much and I will look forward. I look forward to seeing you in the next video