Time
5 hours 53 minutes
Difficulty
Intermediate
CEU/CPE
6

Video Transcription

00:00
hello and welcome to lessen 17
00:03
the dirty dozen of project failure.
00:06
This is your instructor Cane.
00:09
This, uh, quote or the term dominant doesn't actually comes from
00:14
an article called Early Warning Signs of I T. Project Failure
00:19
and what I use the term Dirty Dozen. Because I liked the movie and I'm a big Lee Marvin van. But
00:26
in essence, what we're talking about today are from a quantitative steam
00:32
after reviewing many, many, many project failures.
00:37
What waas in order of quantitative,
00:41
um,
00:42
or by order of the number of projects that had these issues,
00:46
what were the top 12 reasons why projects failed.
00:51
And so we're gonna go through these fairly briefly, but give you an idea of
00:56
how to really look at and develop some early warning,
01:00
um,
01:02
metrics that you can use with within your project
01:06
to help,
01:07
if not prevented from failing help, recognize the signs and symptoms
01:11
that it could be failing
01:12
fairly shortly.
01:15
So the 1st 1 is lack of top management support, so that seems fairly self explanatory. What we're talking about here is, if you're trying to build an enterprise project
01:26
and that enterprise project requires a significant amount of political power within your organization,
01:34
you're gonna need top management support, and ideally, you would like to have unified top management support. So
01:41
if you are doing an enterprise project and there is any level of hesitation
01:48
or distrust wherever the case might be, one identify that early as you can, usually while doing your stake holder analysis and your racy matrix
01:57
and kind of work specifically within those senior managers.
02:02
Two.
02:04
Help them understand the importance of the project or what? Why, it's important for that project to be successful.
02:10
Um, the next thing you want to look at is whether or not your project manager is experienced enough and they use the term week in the article.
02:19
You could kind of make the argument. Either way. I'm not gonna dwell on too much of the personal leadership qualities, but let's just talk about inexperience.
02:27
So an enterprise project, as we've learned through this course, is orders of magnitude more complicated
02:34
than a tactical level project
02:37
you really don't want to be placing.
02:39
You're
02:42
newest or lease experience project manager
02:46
in that role. Now they made that you're most experienced person on that system or whatever
02:52
that that's great to have them involved. But the actual project manager. You want to either outsource a very confident one or, if you have confident ones in house, use an experienced project manager
03:05
lower, no stakeholder involvement. The lower no stakeholder involvement really indicates that
03:10
the people who are going to be most affected or have the greatest amount of interest in the project
03:17
are not being involved. So one of two things is going to happen. You're either going to have a product or system that nobody uses because they were involved in that. They don't understand the importance of it. Therefore, they're not
03:30
inclined to jump on board the very end of the project.
03:34
That's that's a fairly common occurrence. The other side of that coin is
03:38
you're trying to engage something where the business value is not there. So in addition to your top management support,
03:47
look at your stakeholder involvement and if you have
03:52
challenges and issues getting the stakeholders involved,
03:54
you might want to rethink your business case. A good business case, really get help guarantee that your stakeholders are gonna be involved.
04:02
Same kind of true of the project team. If the project team doesn't really commit to it, either because of the way of organization is set up,
04:10
or that they don't themselves see the value in the benefit in performing the project.
04:15
That's a recipe for disaster.
04:17
It's also why it's helpful to either make project short or break up big enterprise projects and to maybe multiple iterations or phases to try to keep
04:27
keep it from feeling like your new inevitable. We're always gonna be doing this thing and actually get some value. Get some wins. Early on in the project,
04:35
team members lacked the knowledge and skills. That's a a good indicator that you want to look at outsourcing If you're trying to bring in a system and you don't have anybody within your organization that is an expert in that system, where that business process, whatever the case may be,
04:51
don't just keep pushing ahead and thinking to yourself that you'll figure it out when you get there. Go ahead and
04:59
invest in the appropriate resource is that have the knowledge and skills that you need within the project.
05:05
The next one and this is really, really common
05:09
is that your Assamese air overscheduled? So when you're doing an I T project
05:13
and you have a limited number of really knowledgeable subject matter experts.
05:17
You can't assume that your throughput for the whole project
05:23
will stay the same if you're s IMI number is very small. So what I mean by that is it becomes a choke point.
05:30
So you can on Lee develop requirements as quickly as you can schedule the s A means to actually sit down and talk about what the business processes.
05:39
Sign off on the requirements documentation test the system as it's being built, so on so on. So if you've only got
05:46
one or two folks that are a true asa me within your project,
05:50
then you're through puts gonna be limited. So make sure you take that into account. In addition,
05:55
if you're s Emmys, if the project's schedule
05:59
on the requirements gathering
06:01
becomes
06:03
delayed due to S IMI overscheduling, you also really want to think about the testing side of the house and making sure that those estimates were still accurate because you're not going to get new s amis most likely between the requirements building and the testing part of the project,
06:18
a lack of documented requirements.
06:20
He has won a lot as well.
06:24
If you don't have business process
06:27
documentation for an enterprise project,
06:30
then you need to spend the time and energy to make that a part of your projects to document the as is functionality.
06:40
Before you'd look at trying to create the to be or the desired functionality of the system.
06:46
That's
06:46
really, really important, because
06:49
the institutional knowledge of
06:54
S Amis that don't have documentation is going to be very high on the old system or the item that you're replacing.
07:02
They're not gonna have 10 20 in some cases, 30 years of experience
07:09
with the new system. So if you don't document what's currently set up,
07:14
it's going to be very difficult to properly train and document
07:18
the
07:19
requirements process or the document the requirements for the new system. In addition, all that there's a contractual piece here to where if you don't document your requirements effectively and you don't
07:31
really
07:33
do a good job of creating an agreement between the project team, the project manager and your stakeholders and your governance,
07:41
then you creates a lot of wiggle room for either gold plating or various levels of discontent because people assume that they're getting something that they don't They're not going to get or vice versa.
07:54
So you really want to make sure you take your time, the document, all your requirements. We talked about scope, creep in the change control process,
08:03
school creep, and failure of that process leads to many project failures. You can't control spending if you can't control scope and you can't control schedule if you can't control scope. So you gotta have some sort of formalized
08:15
change control pop process
08:18
If you have ineffective schedule planning and management,
08:20
this really has more to do with the the
08:24
overly aggressive schedule.
08:26
You will see a lot because people
08:30
and we all do it in our personal lives as well. People assume something is only gonna take half an hour hour and end up taking all day. Well, that's the same kind of thing that happens in enterprise project management. So you need to make sure your refining that schedule continually
08:43
and that you're managing that schedule and keeping your
08:48
governance and your stakeholders and aware of what the schedule performances.
08:54
Communication breakdowns among stakeholders. If your state colors can agree and there's no process within the governance structure to resolve a particular issue that can create
09:05
unresolved conflicts. And then those can lead to project failure
09:11
management by emergency.
09:13
Another common one, especially with your enterprise projects that are usually longer in duration. Something happens. It's higher priority. Yankel. The resource is off that project. That it kind of dies on the vine
09:24
and in the last one, which hopefully you'll resolve
09:26
fairly early on in the project is just no business case for the project. You're
09:31
you're doing some sort of major work,
09:33
some enterprise level project, but there's no R a Y. That's why I talked about before treating this like an investment.
09:39
I don't care that I'm getting some cool new toy out of the deal. I care that it's going to return value to the organization. So if you don't have a business case for the project, especially an enterprise project,
09:50
you probably really shouldn't go ahead and abandon it fairly early on in the planning process
09:56
that concludes today's lesson on the dirty and or dominant dozen of project failures.
10:03
Thank you

Up Next

Enterprise Project Management

In this Enterprise Project Management (EPM) training course, students will learn the fundamentals of managing projects at an enterprise level, including connecting previous project management knowledge to leadership’s vision and mission for the project.

Instructed By

Instructor Profile Image
Kane Tomlin
Executive Consultant at FDOT, Professor
Instructor