Preventing Project Failure

Ahhhh, the LIM Man oh man did I have a great time at the PMI Leadership Information Meeting (LIM). The LIM occurs every year just prior to the PMI Global Congress and it’s a gathering of all the PMI leadership from the branch on up. I went as a leader in the Washington, DC Chapter’s Outreach committee.  First of all, the congress was held at the fabulous, beautiful, glorious Gaylord Palms. I can’t say much for the rest of Orlando because I never saw it. Staying at the Palms with its 7 story high glass enclosed atrium complete with gator ponds (don’t feed the gators), 3 pools and as many or more bars, lounges and restaurants, and an indoor type venetian strollway, was quite enough for me. It was like being on a cruise on one of the massive ships, and the food was fabulous..really wow!  I should ask the Gaylord to pay me for this.

And there is nothing I love more than meeting people as I’m a bit of a an extroverted geek.  Like.. my team really couldn’t understand that I would actually be happy meeting advanced PM practitioners and talking all hours into the night about project management.  They thought I was going to head for the beach after sessions.  Not.  To me there’s nothing better than reaching across a table and saying “Hey, I’m Michiko from the DC Chapter” and they go “Hi/Hello I’m Ahmed/Karesh/Bea/Lyssa/Judy from the Arabian Gulf/Mumbai/Arkansas/South Africa/Tampa Bay” chapter.  And I miraculously kept meeting the right people.  Like the woman from the Tampa Bay chapter who I just happen to sit next to who is running an awards program like I am (her’s is way cooler so I told her already I’m copying her), or the woman who is starting her consultancy just as I am or..and this is the focus of this blog…someone who I had admired who turned me on to even more fantastic research for me to read.

Cause I’m a Geek – yea, yea, yeah Poor John Estrella, we were just chatting after a session; standard where are you from stuff, I mention I have a blog, he mentions he’s got a book and then I stop and say ‘what is your name? again (because he had told me but ya know, in one ear out the other) and he goes John Estrella and I’m like John ESTRELLA – OMG I so knowyou!Isatthroughyourfinancialservicessigswebinar and yourbooksoundsfascinating and I’msogoingtogogetit and the poor guy. I guess I don’t look like a geek anymore. I look kind of normal now so there are no indicators that I will go off on overly excited tangents about fantastic datasets and their application to the practice, so I think I sort of scared him.

Anyhow – went and bought the book – yes, downloaded it and read it during off hours at the conference. I have earned my geek wings so this should be no surprise to you.  And the great thing about his book is that he has real data to back up him theory of what he believes are the key reasons for software failure.  I know, so exciting!   Sure there’s lots of theory out there, but his is quantitative data.

Oh Goodie!  A Growing Data Set! For his PhD, John also conducted a fairly definitive review of the literature and theory, approaches, methods and models in project failure analysis.  I mean, its all there.  Remember that it’s a PhD dissertation so the reading is a bit dry for the average reader but if you want to understand all the theory in project failure analysis and how models interface and interact with each other, Identifying Software Project Risks in the Canadian Financial Services Sector is the book to read.

So that part was cool.  But what’s really great about John’s research is that through this work, he is confirming trends that exist across countries and adding to the body of data which indicates that across cultures, sectors and countries, when it comes to preventing software project failures there are indeed a set of top risk factors that appear again and again.

Why is this valuable?  Well, it suggests that you, IT PM, can start off with that theoretical basis of understanding built right into your project, from the beginning.

Manage for these risks and you have statistically increased your chances for success. And this isn’t just theory anymore kids, its based on hundreds of interviews of real IT PMs like you.   I know, I know – get to the data already. BTW – John calls these ‘Project Risk Factors’ but for ease of understanding, I’m going to call them ‘Reasons for Project Failure’.   Here ’tis:

Top 16 Reasons for Project Failure(Canadian)

Misunderstanding of the requirements

Failure to manage end user expectations

Unclear/misunderstood scope/objectives

Scope creep

Lack of dedicated, full time project resources

Lack of frozen requirements

Bad estimation

Not managing change properly

Lack of top management commitment to the project

No planning or inadequate planning

Lack of available skilled personnel

Lack of effective project management skills

Improper Definition of roles and responsibilities

Failure to identify all stakeholders

Changing Scope/objectives

Poor Risk Management

Now these are the top factors for Canada, particularly the financial services sector.  John provides a chart where, using this same elicitation technique, researchers in Hong Kong, Nigeria, Finland and the USA, had similar risk factors but slightly different rankings, indicating that there are more prevalent reasons for project failure depending on the context.

But what about the top 6 reasons for Project Failure advocated by the UK NAO that you talked about last week Michiko?  I knew you were going to ask that. Here is how I see the relationship.  I’ve taken the NAO’s top reasons for project failure and correlated them to Johh Estrealla’s top reasons for project failure.  Here’s what I think it looks like:

UK NAO Reasons for Project Failure	Canadian Data Set Reasons for Project Failures
intent	Unclear/misunderstood scope/objectives
sponsor	Lack of top management commitment to the project
design/definition	Misunderstanding of the requirements
design/definition	Bad estimation
design/definition	No planning or inadequate planning
communications	Failure to manage end user expectations
supplier/vendor	Lack of dedicated, full time project resources
supplier/vendor	Lack of available skilled personnel
supplier/vendor	Improper Definition of roles and responsibilities
project discipline	Scope creep
project discipline	Lack of frozen requirements
project discipline	Not managing change properly
project discipline	Lack of effective project management skills
project discipline	Failure to identify all stakeholders
project discipline	Changing Scope/objectives
project discipline	Poor Risk Management

Conclusions and a Free Gift Three conclusions here:

A good many of these reasons for project failure are in the hands of project managers.    This means that good application of PM methods has a real measurable impact to the success of a project.

Alignment of theory suggests truth. The NAO UK grouping incorporates the Canadian samples project failure reasons even while the Canadian sample is more explicit about project failure reasons.  But there is an alignment here that a researcher should explore in more depth.

Commonality across cultures/context suggests truth. Studies in Canada, Finland, Nigeria, the UK, the USA are suggesting similar reasons for project failures.  This suggests that there are reasons that should be considered standard things to mitigate against during a software build.

This blog is all about making this useable. So I have created a sample risk register with key questions sourced from this theory.  This is a tool you can download and use right away on your project.

Your Free Gift >> The Making Theory Usable Theory Based Risk Register

Next Steps for the Outstanding PM Ask the questions of yourself and your projects.  Rank the impact and probability and then take action by thinking about a mitigation strategy for these risks.

• • Comments [8]
  • Tags [Risk Management]
  • Categories [Making Theory Usable Series, Managing Risks]