Issue 1-Overview: Why Projects Fail & What We Can Do to Reduce the Risks
How does one know when and why a project has failed ?
This is the first issue in a series of Why IT Projects Fail & What We Can Do to Reduce the Risks. If you are an experienced project manager like myself, you’ve been on or led projects that have failed. Com’on every project manager has had at least one failed project under their belt to some degree.
First, let me ask a question if I may. How does one know when and why a project has failed ? Here’s the best definition I’ve found: A project is considered a failure when it has not delivered what was required, in line with expectations. A project must deliver to cost, to quality, and on time; and it must deliver the benefits presented in the business case.
This initial issue in the series will provide an overview of reasons Why Projects Fail. Later blogs will focus on the details behind each reason for failure and provide suggestions on either eliminating or reducing the risk. This is in no way an exhaustive list of reasons for project failure. This is where you, the reader, come in. I encourage you to post more reasons or even debate the failure risks in this blog.
Ready? Ok, Here we go:
1) Balancing the Triple Constraint
PMI Certified and experienced project managers realize that cost, schedule and scope (the Triple Constraint) are not the only critical factors for a successful project. Stakeholder and Quality management are now seen as an extension of the triple constraint.
2) Unrealistic estimates
When it comes to underestimating the required resources, requirements gathering may be the issue. Typically in software development projects, I ask technical team members to provide the detailed estimates for the activities and tasks for which they are responsible. I’ve found that developers (I was one early in my career) can be too optimistic in estimating complex requirements. On the other hand, there maybe a person who overestimates. Call it ego, trying to save the organization money or buying time, it happens and it’s a problem. In a consulting or commercial service environment, sales people sometimes underestimate resource requirements or project timelines in order to win an account or project.
3) Lack of dependencies created during project initiation
I’ve often seen contractors and sub-contractors begin design and development for their piece of a project only to find they have to revisit both due to other dependent items that must be completed prior to the contractor’s design and development effort. Even if no technical dependencies are established, the contractors cannot start testing until other pieces of the puzzle are completed. This results in either unnecessary time spent (=$) by the contractor or added costs to the client, not to mention delays to the project.
4) Objectives stated in technical terms, rather on the business benefits
Technology team members should not work in isolation.I’ve always felt that bridging the gap between IT and business will solve many of the problems on IT Projects. Remember, the IT solution is owned by the business in which it benefits.
5) Choosing the RIGHT Project Manager
I’ve seen organizations implement ERP systems with a huge price tag but skimp on the costs for project managers. Placing the same value on the project manager as the complexity of the IT project is often overlooked by leadership. Soft skills that are needed to be a successful project manager. Project Management is a skill set in itself and a major risk in the success of an IT project.
6) Failure to review documentation published before PM is assigned
The Project Charter and other documentation are sometimes completed before a PM is assigned. You, as the PM are responsible for delivering the project. It behooves the PM to review the business case, charter, etc thoroughly, validate assumptions, and identify any gaps or areas that need more detail. This is the time those hard communications are needed and ensure you have them now. After deadlines, requirements, and budgets are set, expectations are much more difficult to change.
7) Part-time team members on your project
How debilitating it is when your key team members have full time jobs outside the project. This often creates battles between the project and the functional manager who “lends” the resource.
8) Changes in the environment
If there are changes in the environment, then your business case and solution will become obsolete before you’ve actually finished the project. You may have to review your original requirements and goals at some point in the project to decide how to proceed. This may result in tremendously changing the scope of your project or canceling the project. This is probably the trickiest area resulting in project failure
9) Incorrect business requirements have been implemented
Being set up to deliver the “wrong thing” may be considered a failure even if everything is delivered on schedule, within budget, and to the quality requirements defined in Planning. If the project doesn’t deliver what the organization really needs, this will negatively affect how the project is perceived. Conducting a thorough business requirements analysis may be the most important thing on a project.
10) The possibility that the IT solution chosen will not solve the business case
You won’t recognize this problem early in the project. After the goals and objectives for the project are approved, delivery of other things then becomes dependent on your project. If the technology solution does not work, or if it has major problems during testing, it may be hard to convince your executive sponsor to allow the project to be delayed. Consequently, changing your project’s deadlines, budgets and expectations more difficult.
11) Poor Project Sponsorship
Few projects ever start without a sponsor. This is the person who’s identified the need for change, usually in their area of the business. The sponsor is committed to making that change happen. The sponsor plays a essential role in ensuring the project’s success. A good sponsor can make a project fantastic. Nonetheless, a poor sponsor can delay and frustrate everyone on the project team.
12) Out of Control Scope
Finally, the project management 101 rule. A Change Control Board (CCB) must be established to review and approve/disapprove changes, big or small, to the project scope. This CCB should include but not limited to the project manager and sponsor.
I’m looking forward to your comments!
Thanks for reading!
Maria Bodkin
