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.