15.2 Preventing Enterprise Project Failure Part 2

00:01

hello and welcome back to Enterprise Project Management less than 15.

00:06

In the first part of the lesson, we talked about organizational tension and other things that we can do best practices

00:14

to prevent enterprise project failure. We're going to wrap this up in the second video,

00:20

looking at other items and

00:24

issues that can cause project failure and how to prevent them.

00:29

So

00:30

probably

00:32

one of the largest, if not the largest, reason why enterprise projects fail is you have various types of stakeholder conflicts. So

00:42

talking about stakeholders earlier

00:45

stakeholders can be anybody from the consumer of the good to the person financing the project or product.

00:54

And when they conflict,

00:56

it causes

00:58

quite a few issues. Um,

01:00

Innis.

01:03

I mean,

01:03

largest generation, you know, causes project failure if it totally gets out of control. And so

01:12

a big part of a project manager's role is to prevent those types of stakeholder conflicts

01:19

or manage them. Really, reading is hard because you have to foresee things that you really can't see.

01:25

But when they happen, you need to manage them

01:27

in order to create a positive end state.

01:33

So part of that

01:34

is the project governance, which we talked about with an organizational tension from the last video.

01:40

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

01:49

managing the project itself, is to manage those stakeholder conflicts so that

01:55

when conflicts arise, as they typically do,

02:00

the governance

02:00

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,

02:12

there's a set Siri's of steps and processes

02:17

that help manage those conflicts. So if the project manager wants to cut the project to the bone,

02:24

and the project sponsor wants everything under the Sun,

02:29

which are very normal things, and that's fine.

02:30

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

02:45

level of agreement within the various conflicting stakeholder groups,

02:51

so project governance is role is really there to help

02:54

develop a process by which we manage these conflicts. In addition, The project sponsor has a rule because the project sponsor is

03:05

the bill payer, which creates a certain amount of

03:07

power.

03:09

But they're also the consumer typically of the enterprise project product, so

03:15

their role is really too.

03:19

Be an advocate for whatever. The thing is that you're developing your building.

03:27

And so the sponsor is there to kind of help everybody keep

03:30

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,

03:42

gets hung up on the process a little bit and usually a little bit too much.

03:46

Whereas the product sponsor, the Project sponsor,

03:51

looks at the product, What's the thing that the organization is going to be able to do

03:57

after the conclusion of this project? So the sponsors vision is not so much focused on

04:03

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

04:15

that

04:17

advocacy changed champion whatever you wanna call it, but they're there to sort of remind everybody that

04:24

what we're doing is greater than the sum

04:29

off the parts. You know, we're doing something great in dynamic for the agency, for the organization. Whatever.

04:34

Ah, but

04:36

what that does tend to create is a project sponsor who is a maximum miser.

04:45

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

04:59

that they want everything under the sun

05:02

that can possibly be added. They want the gold plated stuff. They really want this great product

05:11

at the end of this project, and that's their role. And that's fine. That's way that this is supposed to be.

05:16

But when you have conflicts between various stakeholders, one of the problems that you'll have is a maximize er, like the project sponsor

05:27

will butt heads against the saddest the satisfied sir,

05:30

who is just trying to

05:34

determine the minimum requirements, the minimum to go live like What do we need to do

05:41

to complete this project? That's what I'm going to do, so you have to sort of look at

05:46

various stakeholders, identify as early as you can

05:50

Who are your maximize? Er maximize er's And who are your satisfy sirs,

05:56

so that when those conflicts arise, you kind of can play a role as sort of a middleman to say, Okay,

06:03

it would be great if we could do that.

06:06

But

06:08

to get the product live to get this project complete,

06:13

let's just meet the minimum requirements

06:16

and then have a face to a phase three enhancement cycles. All that kind of stuff, a lot of time, especially 19 projects,

06:25

your sponsor

06:27

or whoever you're stakeholder is as the maxim, Isar looked at this as their one shot

06:31

to improve the organization to get this thing right.

06:35

And so they become

06:38

greedy in the sense that they want everything that they can possibly get

06:43

wrapped up into the project as opposed to the product or the system that you're building

06:48

in order to get all the things that they want

06:51

to fix their

06:54

part of the ordination, their their view, what the organization is missing.

06:59

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

07:09

project, the perfect product, the perfect system.

07:13

At the end of this,

07:15

you may find yourself spending so much time and money

07:18

fixing these first perceived bugs

07:23

that may not actually be bugs

07:26

at all or they may be so minor is to not be worth the effort that you're putting into them.

07:30

So one of the things that you need to keep in mind is that as a project manager, especially,

07:38

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

07:46

product

07:48

for good reason, like you're a believer. You drank the Kool Aid and that's great.

07:53

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.

08:03

Perfection is very seldom, if ever, truly possible to execute.

08:09

So we've looked at

08:13

the different conflicts and where

08:15

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,

08:26

and so projects and kind of get away.

08:28

Hopefully, they don't. But if they do, you have a reel him back in,

08:31

and then we need to look at actually completing in closing the project. Projects

08:37

that get out of control tend to stay open

08:41

forever and ever and ever, and they never quite close out. They never quite call it good enough.

08:46

So within the idea of defining completeness again, what are the minimum things this

08:54

product or system has to do

08:58

in order to go into production

09:00

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.

09:11

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

09:22

based on, you know, documents like the charter and then sticking to it.

09:26

And then once you close the project, you really want to look at and document lessons learned.

09:31

You wanna have good documentation for your system itself,

09:37

and you want to provide training because again,

09:39

if you don't

09:41

If you produce the coolest thing ever since sliced bread and nobody uses it, then it's really no value to the organization. So

09:50

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.

10:07

So in summary,

10:09

we talked about preventing project failure through various means. Organizational tension, preventing gold plating.

10:16

Um,

10:16

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

10:26

when you have maximum misers as part of your stakeholder group versus Satisfy Sirs.