Top Ten Reasons For Project Failure - PMP Webinar

© Whizlabswww.whizlabs.com

Top Ten Reasons Why Projects Fail

Jim Stewart, PMPJPStewart Associates

http://www.whizlabs.com/


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 doneNumber 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 scope8



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 Project10



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 playerWeekly updates

Monthly presentations

Keep informed periodically Bi-Weekly updates

Power/influence of stakeholders

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 Matrix18



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


Education

Top Ten Reasons For Project Failure - PMP Webinar