hello and welcome to lessen 17
the dirty dozen of project failure.
This is your instructor Cane.
This, uh, quote or the term dominant doesn't actually comes from
an article called Early Warning Signs of I T. Project Failure
and what I use the term Dirty Dozen. Because I liked the movie and I'm a big Lee Marvin van. But
in essence, what we're talking about today are from a quantitative steam
after reviewing many, many, many project failures.
What waas in order of quantitative,
or by order of the number of projects that had these issues,
what were the top 12 reasons why projects failed.
And so we're gonna go through these fairly briefly, but give you an idea of
how to really look at and develop some early warning,
metrics that you can use with within your project
if not prevented from failing help, recognize the signs and symptoms
that it could be failing
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
and that enterprise project requires a significant amount of political power within your organization,
you're gonna need top management support, and ideally, you would like to have unified top management support. So
if you are doing an enterprise project and there is any level of hesitation
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
and kind of work specifically within those senior managers.
Help them understand the importance of the project or what? Why, it's important for that project to be successful.
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.
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.
So an enterprise project, as we've learned through this course, is orders of magnitude more complicated
than a tactical level project
you really don't want to be placing.
newest or lease experience project manager
in that role. Now they made that you're most experienced person on that system or whatever
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
lower, no stakeholder involvement. The lower no stakeholder involvement really indicates that
the people who are going to be most affected or have the greatest amount of interest in the project
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
inclined to jump on board the very end of the project.
That's that's a fairly common occurrence. The other side of that coin is
you're trying to engage something where the business value is not there. So in addition to your top management support,
look at your stakeholder involvement and if you have
challenges and issues getting the stakeholders involved,
you might want to rethink your business case. A good business case, really get help guarantee that your stakeholders are gonna be involved.
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,
or that they don't themselves see the value in the benefit in performing the project.
That's a recipe for disaster.
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
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,
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,
don't just keep pushing ahead and thinking to yourself that you'll figure it out when you get there. Go ahead and
invest in the appropriate resource is that have the knowledge and skills that you need within the project.
The next one and this is really, really common
is that your Assamese air overscheduled? So when you're doing an I T project
and you have a limited number of really knowledgeable subject matter experts.
You can't assume that your throughput for the whole project
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.
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.
Sign off on the requirements documentation test the system as it's being built, so on so on. So if you've only got
one or two folks that are a true asa me within your project,
then you're through puts gonna be limited. So make sure you take that into account. In addition,
if you're s Emmys, if the project's schedule
on the requirements gathering
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,
a lack of documented requirements.
He has won a lot as well.
If you don't have business process
documentation for an enterprise project,
then you need to spend the time and energy to make that a part of your projects to document the as is functionality.
Before you'd look at trying to create the to be or the desired functionality of the system.
really, really important, because
the institutional knowledge of
S Amis that don't have documentation is going to be very high on the old system or the item that you're replacing.
They're not gonna have 10 20 in some cases, 30 years of experience
with the new system. So if you don't document what's currently set up,
it's going to be very difficult to properly train and document
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
do a good job of creating an agreement between the project team, the project manager and your stakeholders and your governance,
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.
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,
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
change control pop process
If you have ineffective schedule planning and management,
this really has more to do with the the
overly aggressive schedule.
You will see a lot because people
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
and that you're managing that schedule and keeping your
governance and your stakeholders and aware of what the schedule performances.
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
unresolved conflicts. And then those can lead to project failure
management by emergency.
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
and in the last one, which hopefully you'll resolve
fairly early on in the project is just no business case for the project. You're
you're doing some sort of major work,
some enterprise level project, but there's no R a Y. That's why I talked about before treating this like an investment.
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,
you probably really shouldn't go ahead and abandon it fairly early on in the planning process
that concludes today's lesson on the dirty and or dominant dozen of project failures.