Only Reason Projects Fail

It was one fine afternoon in the middle of May, 2013 when I read this forwarded email. It was from a colleague of mine with a subject line “Top 5 reasons projects fail”. Usually, I would glance through such emails for few minutes and move on to the next topic. As I was about to go to my next email, I got this thought. What if I have to pen down my list of top 5 reasons? How different would they be from the lists that I keep seeing once in a while through such forwards?

So, before I started to list down my reasons, I went to Google and searched for the phrase “Top 5 reasons projects fail” and got 31,000,000 results in 0.18 seconds.

Wow, that many results in just 0.18 seconds? I wonder if search engines are actually searching anymore or they have predefined result sets for all common search strings. Guess, someone else is probably more qualified to write a post on this topic. So, let me move on to my genre.

Looking at those results, I was wondering, if so many articles have been written already (and I am sure the age of some of these articles would be at least 20 to 30 years), why can’t project teams learn from the mistakes and not repeat them.

I have browsed through some of those links and this is what I found.

Unclear Goals & Business Alignment	Scope Changes & Change Management	Staffing & Inappropriate Skills
Executive Support	A Lack of Resources	Project Plan Ignored
Stakeholders Not Involved Enough	Not Keeping on Top of Risks and Issues	Extremely detailed Project Plan
Poor requirements	Over-burdened Resources	Scope Creep
Right Stakeholders Not Involved	Issues/risk log, status reports are old school	Ineffective Change Control
Lack of User Involvement	Poor Testing	Poor or No Requirements
Long or Unrealistic Time Scales	Scope Creep	No Change Control System

What else to expect in this list?

If you just spend few minutes looking through this list, its not so difficult to realize that majority of these reasons would fall into the standard triple constraint paradigm namely Scope, Time, Cost, Quality and Risk. Okay, don’t ask me why I listed 5 elements under the bucket of triple constraint. Maybe, we shouldn’t call it triple constraint anymore. Maybe, we should refer these as Penta Constraint.

Nevertheless, the point is, these five constraints are the major reasons projects fail. Why are we even surprised? This is a known fact. That’s the very reason, these five elements are defined as project constraints, to start with. The job of a project team is to work through these constraints to deliver the project while the job of a project manager is to manage the influences of these constraints.

So, in spite of having a team and PM to manage these, if these are still the reasons for projects failure, isn’t this a direct indication that the team and the PM not doing their job properly?

Or, is there something else that’s causing the projects fail? Why do organizations and publishers continue to run after different reasons when the core underlying reason is something else?

Let’s look at one of the most common reasons namely “poor requirements”, which many authors have listed down as a reason for projects failure. Now, what does this mean?

Does it mean that the requirements collection process was poor? Or identifying all stakeholders was done poorly? Or capturing the expectations from the stakeholders was poor? Or translation of requirements into functional specifications was poor? Or the techniques that were used to capture the requirements were inadequate? Or change management of requirements was executed poorly?

In my opinion, “poor requirements” is not a reason. It’s just a symptom and so are the other reasons that you saw in the above table.

For managing each of these (penta) constraints, there does exit a well defined process. If there is well defined project management approach for managing all the project constraints, if the projects are still failing, it’s evident that, the PM and team is probably not able to do their job properly. Maybe the stakeholders are not easy to work with. Maybe the political factors are too complicated. I am sure such “not in my control” factors do play their role in ruining the projects.

Question is, are these “not in my control” factors are the ONLY reasons every time a project fails? Absolutely not! That brings us to the question of “Then, what’s making projects fail?”

Uncertainty is a nightmare

It’s a known fact that, project planning and execution happens amidst lot of uncertainties because the uncertainty is 100% when the project is initiated. Same is the case with risks in the project. That’s why we say a given project is in RED status on day one; not because the project team is doing a bad job but because of uncertainty.

The job of the project manager and the team is to work through these uncertainties and risks and move the project in the right direction (RED to AMBER to GREEN).

Pick few project managers in your organization and interview them with the below listed questions:

• You need to setup milk collection centres in 250 villages that have at least 500 buffaloes. You have an hour to provide time and cost estimates. What will be your approach in getting those estimates?
• Your company is planning to change its name. If this would be a project, what would be the phases of the project life cycle according to you?
• A project is initiated to cleanup a highly polluted lake and you are appointed as project manager. You are given the task of identifying the risks in an hour that need to be presented to the project committee. What would be your approach?

And see how many of them come up with convincing solutions for these. Going by my interactions with several managers in last few years, not many of them could impress you with the answers.

On the surface, none of these questions are actually complex. We do read about scenarios like these in news papers almost every other day. But the interviewees struggle. Those are the same set of folks who do well for other questions which are in their domain. The moment, you step out of their comfort zone, they find it difficult. The reason is quite simple. They can’t face uncertainty.

It’s the project managers’ inability to work in uncertainties that actually causes the failure of projects. And the uncertainty comes in because the budding project managers are not given enough exposure to different areas. Point to be noted, my lord!

This probably answers part of the problem. If you just look around, I am sure you would agree that, projects that are in their comfort zone also fail on many occasions.

Lack of knowledge and Skills

Lack of good competencies, skill and project leadership is the cause for such failures. You pick few project managers in your organization and ask them the below listed questions and see how many of them could actually answer meaningfully and spontaneously:

• What is your approach to identify requirements efficiently?
• List down 5 effort estimation techniques that you are very comfortably with
• How do you define quality plan for a project?
• What will you include in your change management approach?
• What’s your stakeholder management strategy?
• How do you identify who is the right resource for a given activity?
• How do you measure the effectiveness of a peer review?
• If the objective of your IT project is to migrate 475 crystal reports into equivalent SSRS reports, list down three metrics that would define the success of the project

If you carefully observe, answers to the above listed questions have direct association to several reasons mentioned at the beginning of this article.

Lot of guys would struggle to answer all of these questions, meaningfully. Not because they are not smart, but because, they are not provided enough opportunities to learn or experience all facets of a project life cycle.

If you look around the IT organizations, you would find a dedicated testing team, dedicated database team, dedicated operations team, dedicated development team, dedicated middleware team, dedicated deployment team, dedicated release management team and a dedicated project management team.

So, when in the world, would I accumulate good overall experience? Either I am growing to be a developer or a tester or an operational guy but very rarely I will get to understand the intrinsics of all facets of the project.

So, project management is no longer being treated as an “overall discipline”. It has become one of the specialities. Then, why the hell are we blaming project managers when the projects fail? Hang on….why in the world project management is just one another specialized team? Shouldn’t they be the “owners” of the projects?

Project Management is air conditioned

If you just look around, majority of the project managers work form an air conditioned room with an audio/video conference facility. Project management has been restricted to working through the documents and tools. For many PMs, requirements phase is about filling a template.

While I was writing this blog, I asked 6 PMs who work for large MNCs on how many occasions, have they visited their users’ facility to understand how they use the systems or the process that they follow day to day, before putting together any requirements for the projects. The response was only twice in the last 18 months. Between all of them, they have executed 16 projects and only twice they had actually met users at their site. Rest of the times, requirements discussion only happened in a conference room.

It’s a known fact that, running a business successfully involves multiple systems, multiple process and multiple projects. If as a PM, my concentration is only around the project that I am trying to execute and don’t expand my horizon to understand the user/customer’s entire process, I am making my project vulnerable to the influences or changes in rest of the process/projects. Hence, a chance of failure shoots up.

Lack of overall perspective

If you look at the resumes of professionals who started their career in 80s and 90s in services based or projects based organizations, you would find that they would have played different roles in their career starting from entry level engineer to systems analyst to requirements specialist to project leader to quality engineer to database consultant to 1000 other roles. Working with such variety of jobs/roles would have given them different perspectives, ability to work in different contexts, command and comfort with different facets of entire project.

You look at the resume of the folks who have entered the industry in early 2000s, you would see vast difference. The experiences of most of these folks throughout their career would be similar. Similar technology, similar circumstances, similar work, similar domain, similar organizations and similar clients. So, how would even they absorb anything else?

I am not suggesting, anyone from 80s and 90s is by default a good project manager. Rather my point of view is, if I didn’t have enough experiences, it’s difficult for me to become a good project manager.

If I never really did requirements gathering myself, how could I define a good requirements collection process or even review the process assuming someone else defined it.

If I haven’t done much of complex estimation before, how can I validate the estimates that my team is bringing to me?

If I don’t understand how to identify critical paths of my project, how can I even monitor them? By the way, I am not talking about identifying critical paths in a PMP exam book, but in a real time project.

You might say, “Sekhar, I don’t think a project manager needs to have all the skills, he should be able to identify right guys to do the right job.”

Maybe you are right. Let me ask you something. If I don’t have expertise or knowledge about a particular activity (like estimation or requirements or risk identification), how can I even identify who is the right guy to do that job other than depending on others’ opinion.

A project manager is like a movie director. He may not have to do the work of all the departments, but he certainly needs to know how to extract the best from everyone to ensure the movie is a hit. If I don’t know what ingredients a good screenplay should have, then, I can’t verify a script writer’s work. I just have to take it on the face value and might end up burning my movie.

When this gets coupled with Halo effect, the situation gets worse. Because I have been doing well in my technical or functional roles, I would get promoted to become a project manager. I am expected to perform well but no one has time to help me get acquire necessary skills and competencies.

Review is NOT checking what I know

Let me ask you three questions. How many guys in your team can do a review? How many guys in that lot can do an effective review? How many guys from this sub-lot can do world class review?

I can bet my job, the responses for the above three questions would vary drastically and perhaps, the response for last question would be less than 5, if, in fact, it is more than zero.

For most of the folks, review of an artifact is about “let me apply my knowledge and see how I would have done this better” and not about “how far is this artifact from being the best in the world”

Now, I can review a given artifact or work efficiently and effectively only if I am a very effective reviewer or I have enough information and handy tools that can help me understand the best way of executing that artifact or the piece of work.

If I give you a project plan that describes the schedule, Gantt chart, critical path diagram along with quality plan and risk management plan, how many guys on your team would you trust to do an effective review?  If effective reviews are not happening regularly, it has direct implication on quality of the deliverables.

If I just summarize:

• We are not finding many project managers who have good project management competencies and skills and who can provide good leadership for executing projects
• Not many guys are carrying all-round skills
• Effective review is fast becoming a lost art and might soon be found in “American Museum of Project Management”

By the way, I am not saying these are the reasons for project failures. Just like how I quoted earlier that penta constraints shouldn’t be attributed for project failures, same way, the aforesaid three bullet points should also be considered as challenges.

Why project managers are struggling to manage the penta constraint?

Why project managers don’t really have enough skills and competencies?

Why project managers are not getting translated into good reviewers?

There is only one answer to all these questions and that answer is the only reason the projects fail!

Only reason projects fail

The real reason lies in the leadership and management of the organizations. How many organizations are actually investing in developing good project managers? How many organizations are identifying right project management talent and groom them in a planned and systematic way over a couple of years? How many organizations define reviewers’ pool and groom them to be world class? When would organizations stop thinking that sponsoring a PMP or PRINCE certification is a way of developing project managers? How many organizations differentiate between project manager and a project administrator? How many organizations believe that a project managers’ only job is NOT to create tasks in a time sheet entry tool and approve the time sheets? How many organizations believe that project managers’ job is not to fill documents?

If the organizations develop good project managers in old school way and simultaneously develop a pool of world-class reviewers, projects failure would automatically stop. End of the day, projects fail because the penta constraints are not managed properly. And if you have good project managers and effective reviewers, such failure would start coming down fast…very fast!