The Real Reasons Projects Fail

by

businessman rolling a giant stone

As 2014 draws to a close, I find myself mulling through the various Top 10 lists that hit my inbox from LinkedIn groups like ProjectManager.net, Agile, Agile PMP, etc.  These groups are great for information sharing and making new connections.  But, as far as lists, it would seem that everyone is essentially carrying the same arsenal of lessons learned that got us burned in prior projects.  Don’t get me wrong, lists are great, I particularly like these two:      

Top Mistakes in Project Management
SOURCE:  http://www.projectmanagers.net/i/top-mistakes-in-project-management/

Top 10 Reasons Why Projects Fail
SOURCE:  http://www.slideshare.net/MariannaAlmakaieva/10-reasons-why-projects-fail-or-common-mistakes-to-avoid

But sadly, this year’s lists are no different than last year’s, and frankly they’re no different than the year before that.  Actually, I think the list from 1914 looked relatively the same, too.  This is telling me that the basic reasons for project failure haven’t changed, therefore we’re not doing our part to move the needle forward.  I am reminded of a quote that I often revert back to: 

”If you want something you’ve never had before, you have to be willing to do something you’ve never done before.”   Bob Beaudine, The Power of WHO

The good news is that projects are failing at a much lower rate.  According to the 2011 CHAOS Manifesto from the Standish Group, Waterfall projects fail an average of 29% of the time, while projects using Agile methodologies fail only about 9% of the time. 

(SOURCE:  http://www.onedesk.com/2013/01/waterfall-vs-agile/)

Standish Pie ChartsFrom an outright project failure standpoint, I think we can safely say that we have moved the needle by pushing our organizations to abandon the poorly performing Waterfall methodology.  However, as these charts show, there is still some work to be done to address “Challenged” projects (projects which were delivered late, over budget and/or with less than the required features and functions). 

So, what happens in these “Challenged” projects?  In my experience, what happens is that the executive falls asleep at the wheel while the project team death marches to the end.  When they wake up, they realize that what they asked for wasn’t what they meant or what they meant wasn’t heard correctly, or they don’t mean what they meant anymore because something changed.  If the project team runs into this issue this far into the delivery process, then clearly some fundamental aspects of project management and project leadership were overlooked. 

What dictates the quality of project delivery is the level of involvement.  Leave a bunch of engineers to concoct their ideal widget and they will… they will develop the ideal widget for them.  Leave a team to self-organize, self-select, self-rule… and they will perform these tasks in their best interest.  Leave anyone in any situation to their own devices and they will exercise their own judgment.  If the executive comes back in during the 11th hour and finds that they don’t like the result, well then who’s to blame?  The team that built what they thought they were asked to build, or the executive that felt it better to prioritize something else rather than provide guidance and oversight to the team to make sure they built what they wanted?

So, how do we address this proactively?  In my view, project managers or the project management teams needs to review a quick checklist to tell them if their project is in danger of being challenged.            

  1. Is there a sponsor? Need this be said?  If you don’t have a sponsor, the project team needs to be disbanded (released) immediately.  Delete the project plan.  Step away from the keyboard.  You do not have a project and you should know better.  Even that pesky pyramid project of ancient Egypt had a business sponsor. 
  1. Is your sponsor engaged? It’s nice to have someone who is willing to fund the project, but it’s imperative that the person writing the check and accepting the deliverable is actively engaged in the project.  If they can’t be actively engaged, they need to empower a proxy to own the deliverable.  If they can’t do that, then call a spade a spade.  This project isn’t important.  Fold it up.  And, stop for a second.  If you get this far into the checklist and already have a series of goose eggs, then you need to take a pause and question the initiative and moreover your place in it.   The rest of my checklist consists of basic PMI tenets that it seems people overlook.  But risk, change and quality management mean nothing unless an engaged business team is leading the effort.  We are project managers.  We are there to get the job done.  We rarely have the fortune, nor the business background for that matter, to question whether the initiative we are asked to lead is the right one.  That is the sponsor’s job and if you cannot locate one or there isn’t one already established and leading the charge, then you should know in your heart and your gut that this project is on the path to train wreck status.  
  1. What is the process for managing change? Change is inevitable. I can’t think of a single project where all was knowable at the onset of the project and nothing changed in terms of requirements or specifications during the course of the project.  Because of this, a project without a sound change management processes in place is simply a project waiting for trouble to happen. 
  1. Is traceability in place? I can’t really stress enough the importance of traceability in deliverable design. Traceability is largely used for technical implementations, but from my view, whether the deliverable is a product or a service, quality is reviewed based on the adherence of the final output to the original specification.  I asked for the product to be able to calculate X and produce Y.  Does it do that?  If an unforeseen issue is detected in the quality control phases, you may need to be able to map back to the original requirement in order to figure out how to best resolve it without forsaking the originally intended functionality.  You might even need to go back to the originator of that requirement and review the understanding and assumptions that requirement lead to.  If you can’t trace your test cases back to the specification and the specification back to the original requirements then you have orphaned requirements.  Not good.  Why are you building a function that has no business requirement?  This is Project Management 101.  Don’t make this mistake.    
  1. How are approvals captured? I recently engaged with a client of ours to take on a late stage deliverable for a key software implementation they are rolling out.  When the person who was leaving the firm transitioned his documents to me, I noticed that one of the documents had recorded approvals of his content.  “Awesome!” I said, “Where is the evidence of the approval?”  “Oh!” He said.  “It was all verbal.”  Um… sorry… we don’t do verbal approvals in Project Management-land.  I don’t care how much you trust your business users.  Treat verbal approvals as an excuse to follow-up with said business user with an e-mail saying something to the effect of: 

Dear <Business User>: 

During our meeting today you verbally approved 

<list out what they approved> 

Please confirm that I have captured this correctly.  

Your Friendly Project Manager

If you don’t do this, your project will successfully reach the end zone only to be thwarted by some business user with convenient amnesia.  This may sound like a skeptical distrustful view of the world… but… well, it’s not that I don’t trust people, I just don’t believe they’ll remember what they said!  

  1. Where’s the Quality Plan? No, no. Not your test cases.  This is the plan that provides the strategy for preventing defects (Quality Assurance) and detecting defects (Quality Control).  If the answer is, “our business users perform QC for us”, then please turn in your PMI card immediately, and grab a “Project Failure” sticker on your way out the door.  Quality is paramount to deliverable acceptance.  If you are not building quality into your process, you can’t expect quality to come out. 
  1. What degree of confidence do you have in your team’s estimates? This isn’t a dig on your team.  I’m sure they are wonderful people.  However, the reality is that some people are better at estimating than others and you can rarely take in estimates without adding in some buffer.  If you have that rare breed that gets it right all the time, awesome, set their discount rate to 0%, but in general I would add a 10% – 15% buffer to the estimates.  Make it higher for some of the more junior members of your team. 
  1. Has this project ever been done before?  And as a corollary, what is the company’s history of fostering innovative projects?  Businesses embark on completely new endeavors all the time.  This is good!  That means they are innovating.  But, it’s also risky because there are no experts to lean on.  PMI calls this “Expert Knowledge” or “Expert Judgment”.  These are the advisors you can go to in order to gain insight into how long it will take to build something, they are part of the decision framework that needs to be in place in order to ensure that the right choices are made.  But, they don’t exist in this environment.  Different tools and techniques are required because you don’t have large swaths of expert knowledge to draw on.  That being said, it might be a good idea to ask the executive team what happened to the project team on the last innovative project the company embarked upon.  This will give you some insight into how the company approaches innovation and what their tolerance is for the precarious nature of research and development.  If there is a scorched effigy of the last project manager hanging around the office you might want to pass on this opportunity… 

As I stated earlier.  In order for us to achieve something we haven’t achieved before, we are going to have to do something we haven’t done before.  We are a culture of people pleasers and consensus builders.  This has made us liked by our project teams, but unsuccessful in the board rooms.  We need to push on our executives harder when projects are going off the rails and we need to demand a project environment conducive to success.

Let’s make 2015 the year that the right side of those pie charts became a smaller sliver!

Happy New Year!

Regards,

Jonathan P. Goldstein

McKinney, TX

 

READ MORE

Shifting Perspectives: 3 Learnings From a 3-Day Training

Shifting Perspectives: 3 Learnings From a 3-Day Training

About a week ago, I completed the second live (virtual) training in the process of becoming a Certified Professional Coach through iPEC. Once again, my mind was blown! It reinforced for me that virtual workshops can, and do, work, and, in a lot of ways, I prefer them...

read more
Finding My Work-Life Balance

Finding My Work-Life Balance

In my previous post, I told the story of how I got back into consulting after becoming a mom. All of the diverse experiences I had during that journey have helped me to find my work-life balance by… Defining Boundaries “Go home,” my first boss said 12 years back —...

read more
How I Got Back to Work After Being a Full-Time Mom

How I Got Back to Work After Being a Full-Time Mom

I Landed My Dream Job Throwback to 2014, I had completed my MBA, landed my dream job as a consultant, and was hoping that my new consulting career would exponentially ramp up my career growth for the next 5 years. This would position me to take on critical decision...

read more
Self-Awareness is Key to Belonging

Self-Awareness is Key to Belonging

In August of this year, as part of our annual company meeting, our team at Thought Ensemble participated in the foundational session of Diversity, Equity, and Inclusion (DEI) training led by Dr. Nika White, IOM, CDE (she/her/hers). One of the most meaningful moments...

read more
Finding Your Organization’s Magic Pixie Dust

Finding Your Organization’s Magic Pixie Dust

It is often said that organizational culture is like a fog — it is all around us; it impacts our ability to see, to move quickly, and to deliver; but we cannot quite put our finger on it. Indeed, some organizations see their culture as a byproduct of operations,...

read more
We’ve Refreshed Our Brand!

We’ve Refreshed Our Brand!

Why have we refreshed our brand, you ask? Well, as we have grown and matured as an organization, we felt that our previous brand elements no longer represented us as well as they could. You see, we founded Thought Ensemble back in 2008 to help companies better compete...

read more
Thought Ensemble’s Purpose — Inspired in 2020

Thought Ensemble’s Purpose — Inspired in 2020

I recently wrote about how company purpose is being tested and inspired by all the events of 2020. This topic is very real for us at Thought Ensemble. We’ve been thinking a lot about what really matters as we’ve navigated the...

read more
How 2020 Is Testing and Inspiring Corporate Purpose

How 2020 Is Testing and Inspiring Corporate Purpose

In August 2019, the Business Roundtable rewrote their statement of corporate purpose. I followed this with significant interest being that I have never forgotten the debates about corporate purpose in business school almost two decades ago. We were taught that the...

read more
Why Purpose-Driven Organizations May Struggle With Change

Why Purpose-Driven Organizations May Struggle With Change

I love working with companies who really want to make a difference, beyond just making money for their shareholders. I mean, making money is fun and all, but it is even more rewarding to join in on a just cause. Plus, as this HBR article explains, companies who have...

read more