Top Ten Reasons For Project Failure - PMP Webinar

© Whizlabswww.whizlabs.com
Top Ten Reasons Why Projects Fail
Jim Stewart, PMP
JPStewart Associates

Learning points
• Learn to recognize the ten project failure signs in
your organization
• Discover some possible solutions for each problem
• Understand what commonly used solution is not
necessarily a solution at all
2

A survey of companies was done
Number of Respondents: 163
• Roles of Respondents:
• C-Level
• VP or Director-Level Business Management
• VP or Director-Level Program/Project Management
• Head of PMO
• Program/Project Manager
• Size of Organization:
• Large (39%)
• Mid-sized (25%)
• Small (36%)
Industries included Professional & Technical Services, Manufacturing, Information, Finance & Insurance, Healthcare &
Social Services, Utilities, Public Administration,
Source: PM Solutions report, “Strategies for Project Recovery,” 2011
3

The nature of the problem
• According to the report based on this survey, firms manage $200M in
projects each year. During that time they will realize that $74M (almost
40%) of their projects are at risk of failing
• Many companies can successfully recover projects given senior
management’s willingness and the right PM
• Firms with a standard PM methodology for managing their projects had
fewer than half as many project failures
• Almost all organizations surveyed (92%) rated the skill and knowledge of
the project manager very important (64%) or important (28%) to the
success of the recovery
• But despite that, the average dollars lost due to project failures per firm is
a staggering $24M
4

Why projects fail
• There are many reasons that projects fail
• I’ve been speaking for some time about Top Ten reasons why
projects fail based on my own observations
• However the reasons given in the report dovetail nicely with
mine
• I’ve highlighted the top 5 given in the report which we’ll look
at in more depth
5

Reason # 1- Requirements
• Requirements are ambiguous, unclear and not prioritized
• The process of collecting them may not even be well understood
• It is your job (business analyst, project manager) to elicit customer
requirements, not tell him what he wants
• Agile was designed in part to deal with ever-changing requirements.
Sprints are two-to-four weeks long allowing the product owner to
change her mind or tweak the “potentially shippable product
• Solution is to have requirements expert apply rigor to the gathering
of requirements using interviews, job shadowing, context diagrams,
prototypes and other techniques
6

Reason # 2 - Scope creep
• Project scope is the sum total of all the work you are going to
do (and not do) on the project.
• It is important, first, to define all the work via some
mechanism, so Work Breakdown Structure, scope statement,
etc.
• This is best done in a meeting with the entire team. It serves,
at least, two purposes: having a meeting of the minds on
deliverables and getting team buy-in.
• Solution is to have rigidly defined scope up front and a
rigorous change control process in place.
7

WBS example – developing scope
8

Reason # 3 - Resources
• Resources of the human kind are frequently over-allocated. No one
in the organization seems to know who is working on what at any
given time.
• Since resources are the heart and soul of any endeavor, the
schedule is only as good as your faith in resources being able to
show up and work as expected.
• Another problem is that many schedules are created which show
serious over-allocation on specific projects. It is not uncommon to
see resources scheduled 24 hours per day!
• One solution is to have managers gather each week and, using
spreadsheets, plan resource needs.
9

Over allocated resources in Project
10

Reason #4 - Communications
• The Project Management Body of Knowledge dedicates an entire
Knowledge Area to Communications.
• It’s my contention that the average person is not a very good
communicator. They either don’t answer emails or only answer half
of the questions asked.
• You should insist on getting team members trained in
communications so they are connecting at a very high level.
• You might also consider the creation of a Communications
Management Plan which details which stakeholders will get what
information when and by what means.
11

Communications Management Plan
Sponsor PowerPoint Weekly Status update
Team Email Weekly Status; action items Meetings should be
held face-to-face.
Senior management PowerPoint Monthly Status; action items
Steering committee PowerPoint; status
reports
Quarterly Status; action
items; go/no go
report
Stakeholder Method Frequency Type Notes
12

Reason # 5 - Stakeholder Management
• A stakeholder has a vested interest in your project for good
or for ill.
• The first step in this process is identifying stakeholders
according to their power, influence, and interest.
• Once you know who your stakeholders are, you can
develop a strategy for dealing with each one. This leads
somewhat back to the previous Communications
Management Plan.
• Keep stakeholders informed before and during the project.
13

Bi-Weekly updates
Key player
Weekly updates
Monthly presentations
Keep informed periodically Bi-Weekly updates
Power/influenceofstakeholders
Interest of stakeholders
Stakeholder quadrant

Reason # 6 – Estimates
• There is more art than science when most team members make
estimates of time for tasks.
• When asked for an estimate, they will usually pull a number out of
the air based, perhaps, on the last time they did a similar task.
• Many project managers on hearing the estimate, will add some
‘fudge factor’ based on their knowledge of the team member.
• A solution here is to keep historical data for all estimates.
Ultimately you will have and maintain a database that will keep
your estimates more accurate.
15

Some common estimating techniques
• Historical – keep records of all estimates and use them as
reference for future projects.
• PERT – (Optimistic + (4XMost Likely) + Pessimistic)/6
• Three point (Optimistic + Most Likely + Pessimistic)/3
• Best case or worst case estimate
You will have to determine what works in your environment.
16

Reason # 7 - Risk
• Many project managers do not manage their risks or even know
what they are.
• The process of risk management is not very difficult. What tends to
be more challenging is keeping at it over a period of time.
• Another challenge is that you may have to sell risk management to
senior management. They are often skeptical of doing tasks and
spending money in advance for something that may never happen.
• A solution is to do risk management on a smaller, less impactful
project to see its benefits.
17

Probability/Impact Matrix
18

Risk response options
• Avoid – Remove the possibility of the risk occurring
by removing the task or item that causes the risk.
• Transfer – Move the risk over to some third party
either by insuring or subcontracting
• Mitigate – Reduce the probability or impact of the
risk’s occurrence by taking proactive steps.
• Accept – Do nothing.
19

Reason # 8 – Unsupported project culture
• Many people do not even know what project
management is or what a PM does.
• This lack of knowledge sometimes transfers over to
corporations who fail to understand the role.
• Consequently, projects are not treated seriously
enough. Schedules are handed off to junior people or
secretaries, sometimes without the proper tools.
• The only solution here is education, especially at the
senior management level.
20

Reason # 9 – The Accidental PM
• Similar to the unsupported project manager, this takes it a step
further.
• In this instance, an accomplished person is promoted to project
manager. He may have been successful in, say, a technical role, but
it does not mean he will be successful in a PM role.
• The technical role may have had him relating to machines. The PM
role will require that he perform the delicate balance of
interpersonal skills.
• As in the previous reason, the only solution here is education of
both management and PM.
21

Reason # 10 – Monitoring and Controlling
• M&C is all about setting baselines, monitoring for variance and, if
need be, taking corrective action.
• Many people don’t record actuals and hope that the schedule
doesn’t run over.
• Merely using % complete in your schedule won’t tell you how the
actuals have affected the schedule.
• You should be thinking about how to measure completeness. For
one example, you can use milestones to measure progress.
• This is a lot better than asking the team member for how “done” he
is. How would she measure that?
22

Bonus reason # 11- Fixing the wrong problem.
• Sometimes managers, on realizing that their projects are out of
control, reach for a quick fix.
• Often, they start sending people out for certifications or other
training thinking that this will somehow solve the preceding
problems. But while certification is good, in and of itself it won’t
solve the problem.
• You have to get to the root cause of the problem to determine if it
makes sense to get people trained, certified, etc.
• Often the fix is not in training PM’s but rather in having a culture
that sets realistic deadlines with the right number of resources.
23

Actions going forward
• A journey of a thousand miles begins with a single step. –
Chinese proverb
• Don’t try to solve every problem all at once. Prioritize and
attack.
• One way to do this is to tell your boss you want to improve
process. Then add a process improvement challenge to
your quarterly objectives. So, I will incorporate change
management into the company by Q2.
• And if you don’t get it by Q2, keep going anyway.
Persistence will get you there.
24

Thank You 

Top Ten Reasons For Project Failure - PMP Webinar

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (18)

Similar to Top Ten Reasons For Project Failure - PMP Webinar

Similar to Top Ten Reasons For Project Failure - PMP Webinar (20)

More from Whizlabs

More from Whizlabs (20)

Recently uploaded

Recently uploaded (20)

Top Ten Reasons For Project Failure - PMP Webinar