Projects Fail Because Project Managers Are Doing the Wrong Project

Projects Fail Because Project Managers Are Doing the Wrong Project
By John Gough

It is all a bit much ranting and raving about the state of project management, without offering solutions. Too many project managers are not very good, too many are not tough enough, but too many end up taking the wrap for a failing project which is clearly outside their control. It is a bit of a project oxymoron: management and lack of control. So it is worth an examination of how it comes about.

Projects start as ideas, and the idea is worked into a proposal or proposition by the business. As the proposal is developed, business requirements are defined and a business case built. The business sign off on the business case, capital is allocated, and the project commences with the appointment of a project manager. At this stage, two of the points on our project management triangle: scope and resource are firmly hammered into the ground.

Does this sound familiar? We are being set up to fail, not because we are doing the project wrong, but because we are doing the wrong project. We are doing a project that has not been designed to be doable, but one that has been designed by the business to attract scarce capital resource. Consequently the business case will have described a proposal rich in features, that can be built at minimum cost, to an aggressive timescale. As a result the project is impossible to deliver.

This is why according to Standish, two thirds of all projects fail. Projects fail because project managers are not doing the right project. The work of the business has now been largely achieved. They have analysed the problem, issue or opportunity and developed a solution. Gained agreement to a proposal, and taken it to the Board and obtained funding. Job done. That is not to say they are not interested in the results, but there are now other priorities, new problems, issues and opportunities. The business has moved on.

The Project Manager is left now to get on with it. Project managers that are not good enough or not tough enough, plough immediately into the detail, raise project documentation, organise governance and lose themselves in MSProject. However this is the time, to get in there, stamp some authority on the project and reshape it. We think the best technique to use is benefit mapping.

Get back to the business, re-engage with the team who developed this proposal. Let them know that maybe the project could be implemented for less cost, and more quickly, if the benefits could be prioritised. This makes business sense. They will listen.

Using short workshops with the business, work with them to properly define the benefits. Then working backwards define the capability required to deliver those benefits. Consider then the outcomes / requirements that will deliver that capability. Redefine the vision and objectives of the project to meet those outcomes. Vision is now aligned with benefits. The scope of the project is now aligned with the benefits. Resourcing and planning can follow.

Go back to the business, with a new plan which delivers their business priorities. Perhaps it now cannot be completed in less time or less cost, but they threw you a curved ball. Now is the time to pitch it back.

John Gough works with major organisations in both the public and private sector to make change happen. John is the Principal Consultant & Director of iJounery, a Project Management consulting company.

PMHut Team

PMHut Team

PMHut.com is a website dedicated to providing PM articles, detailed project management software reviews, and the latest news for the most popular web-based collaboration tools.

5 Responses

  1. Avatar Shim Marom says:

    Once you base your argument on the Standish Report you’re walking on shaky ground. This report is misleading and is based on assumptions which are entirely incorrect. See my post titled ‘Projects failure rate – the conventional wisdom is wrong!’ addressing this issue in http://quantmleap.com/blog/?p=607.

  2. Avatar Atul says:

    Hi John,

    Thanks for the excellent analysis, it certainly resonates well with me. I believe your analysis holds true irrespective of whether one agrees with the Standish report.

    I also like your suggested approach towards a solution. I try as many variants of it as my circle of influence permits me. More often than not, it brings good results.

    Thanks again for sharing.

    — Atul

  3. Avatar Atallah chamieh says:

    I strongly agree with you John,doing the wrong project is certainly lead us to fail.
    Take care,
    Atallah Chamieh.

  4. Avatar PM Hut says:

    Hi Shim,

    Thanks for your comment. I had the chance to read your take on the subject (as well as the comments). The thing is every single entity in our profession is “for profit”, even PMI. Having said that, it doesn’t mean that something can be profitable and honest at the same time. I don’t understand why Standish would go through the trouble of creating a false/inaccurate report, I don’t understand as well what would be their benefit? Would they sell more copies at a $1000 each?

    As for their numbers, 32% success rate is actually very reasonable in the software industry, and I think the definition of success is delivering a product that is useful to the business within budget and schedule (it can go reasonably above budget and above schedule). Challenged projects are those that go way beyond budget or schedule. Failed are projects that never get finished: killed, indefinitely postponed, etc… In my company, I can tell you that out of 3 projects we work on, one of them makes it (so that’s like 33%, sometimes less). This is the current nature of the software industry, lots of ideas, lots of projects going on, and eventually you will kill the projects that will not bear fruits and you will pamper the ones that will increase the company’s ROI. As you see, the heart of the problem is in deciding which projects to go for.

  5. Avatar Matt Shore says:

    Interesting piece, which rings very true. I’ve been thinking a lot about honesty in project management, too (wrote about some of it here: http://bit.ly/c3vsuJ). However in our case, part of the problem had to do with unforeseen complexity — the project took way longer to complete than initially planned. So much so that, as you say, the business moved on. Of course this is hindsight, but reconsidering the project parameters from the standpoint of the business would have definitely been beneficial.

Leave a Reply