In a perfect situation no projects would fail. They would all finish within the budget and time allotted to it but in real world this is not the case. Whatever may be the reason but projects generally do not tend to complete within the given time and budget. It is very common that projects fail. Even in cases when projects meet the budget and time allotted but even in that case one can ask whether the project met the results and quality that was expected of it. Thus, a true project success should be scaled on all these parameters.
There are several projects that fail due to one or the other reasons. There are several small reasons that could lead to failure of a project. However, all these reasons could be categorized under these categories – time overrun, budget overrun, failure to meet the results and quality expected.
Here are some of the main reasons why projects fail:
The wrong business requirements have been addressed
If your project is set up to deliver the “ wrong thing,” it may be considered a failure even if everything is delivered on time, within budget, and to the required quality. This seems harsh. But if your project doesn’t deliver what the organization really needs, this will inevitably negatively affect how it’s perceived. This is why it’s so important to conduct a thorough business requirements analysis.
It’s not possible to deliver the business case
If your business case can’t be delivered, then you have an impossible task. To make things worse, after the business case is approved, delivery of other things then becomes dependent on your project. This makes changing your project’s deadlines, budgets and expectations more difficult.
For example, once you’ve promised to deliver a new airport baggage management system, airlines may schedule additional flights for shortly after the system’s launch, so that they can take advantage of the new capacity. If the baggage system doesn’t work, or if it has major problems during testing, it may be hard to convince senior managers to allow the project to be delayed, because they will have to give up promised increased revenue.
When you write your business case, make sure you think through the project requirements in detail, and identify what’s needed to ensure that you can deliver those requirements. Don’t just list assumptions – make sure you explore them thoroughly. Review other, similar projects, so that you don’t forget any major items. If you’re delivering a new system, review your hardware and interface requirements. If you have major risks, include sufficient contingency resources (people, budget, and time) to manage those risks appropriately. Remember that implementing change is hard!
Be realistic, and be ready to have some difficult conversations. For instance, your CEO may be disappointed that he can’t have what he wants before the year end, or key users may say that they really need a fully featured product at the end of phase one. However, it will be a lot harder to have these conversations at a future date, when your project is in trouble!
In many cases, business case documentation is written before a project manager is assigned. If you’re the incoming project manager, make sure you don’t simply accept these documents as they are!
You’re responsible for delivering the project, so be sure to review the business case. Validate assumptions, and identify any gaps or areas that need more detail. If difficult conversations are needed, have them now. Once deadlines, requirements, and budgets are set, expectations are much more difficult to change!
Governance is poor
Few projects ever start without a sponsor. This is the person who has identified the need for change in an area of the business, and who is committed to making that change happen. He or she plays a vital role in ensuring the project’s success. A good sponsor can make a mediocre project fantastic, and a poor sponsor can delay and frustrate a fantastic project team.
The project sponsor is supported by the project’s governance bodies, usually in the form of a steering group. These governance roles are essential: they provide direction, guidance, and critical review of the project and its progress. As project manager, you’re involved in the day-to-day running of the project, but governance groups can take a step back and look at the project from a different perspective. They can ask difficult questions about progress and performance. They may see things that you’ve overlooked. However, they can also support you by providing contacts and insights that help you get things done, and by providing “ political cover” when you need it.
Project managers don’t usually have any influence over who their project sponsor is. Sponsors either self-select, or they’re chosen because of their position in the organization. However, you often have more influence over who is in your steering group. As such, if you know that your project sponsor lacks passion for the project, or if the sponsor doesn’t like to say no to people who keep trying to expand the project scope, then make sure you balance this with tougher or more engaged steering group members.
Implementation is poor
If you deliver your project competently, you’ll avoid poor implementation – right? Unfortunately, it’s not that clear. Delivery can be complex. You need to manage risks, issues, and scope; manage your team; and communicate with stakeholders.
Delivering change is hard, and not everything is in your control. Therefore, being competent isn’t enough for good implementation, but it’s a good start! There are a lot of tools available to help you. Take our quiz on your project management skills to get started.
People lose focus on the project’s benefits
Projects are based on a list of benefits that must be delivered. For example, you may need a faster customer service process, you may need to produce products more cheaply, or you may need to improve the quality of your service. These benefit statements should be refined so that they’re clear, concise, and quantified.
From these benefit statements; a set of “ things to do” is generated. For example, you may need to consult customers, redesign products, or implement a new system. The outcome of this is a business case document that analyzes the project in terms of costs, and of the benefits will be delivered.
The project team then focuses on detailed planning, and on delivering the line items in the project plan – building a new system, developing training packs, mapping out new processes, and so on. At this stage, the team may forget about the benefit requirements.
This often results in a project deliverable that’s well built, but doesn’t provide the necessary benefits. For example, if the project plan focuses on designing and building a system, you could get a fantastic system, but one that’s not being used by the business.
To avoid this problem, adopt a benefits management approach throughout the life of the project, and remember the need to deliver the required benefits when you’re planning and delivering your project.
The environment changes
This is probably the trickiest area. If the business’s needs change, then your business case can become outdated before you’ve actually completed the project. You may have to review your original requirements and goals partway through the project to decide how to proceed, and this may result in changing the scope of your project – or even canceling the project altogether!
If you’re working in an environment that’s changing fast, you can help reduce the risks by doing the following:
Making timely decisions:
If the project is clearly not going to be able to deliver the revised requirements, don’t ignore this. The sooner you communicate this, and the sooner you make a decision about the project’s future, the better.
Considering smaller projects:
It’s more difficult to change direction in a large cruise ship than in a tugboat. So, think about whether a proposed project’s scope and delivery timeline are appropriate within your business environment. Delivering projects in smaller pieces is not always appropriate, but it’s worth considering.
Managing expectations:
Just because you cancel a project does not automatically mean that the project is considered a failure. This depends on many factors, including how you manage the involvement of key project stakeholders in the decision-making process.
Steps taken to prevent project failure
Define the Project Purpose
What will the project do for the Company?
How much will be spent to achieve the results?
Develop a project purpose statement for the team’s mission.
One of the primary goals should be to increase probability of success
Organize the Project Team
Who are the project stakeholders?
Who will contribute value?
Identify each member of the team, their specific roles, responsibilities and duties
Charter the Project
Serves as historical document, touchstone and formal start
Provides a formal approval mechanism
Describes the business need, overall purpose, scope & project deliverables
Preliminary analysis of the ROI and Risk assessment
1st Formal Deliverable Elements include:
Project Name
Project Manager
Propose Team Members
Background on the situation driving the project
Area where project is to be implemented
Project description and scope
Estimated capital cost and return (ROI or NPV)
Rough Schedule
Assumptions
Approval list and Signatures
Aligning the Project Team
The Alignment Meeting and Problem Definition Methodology is not just a team building exercise.
Excellent communications are a prerequisite if the Team is to work together & effectively at all times.
Interviews stakeholders and Organizes collected data into Categories:
Goals
Facts
Concepts
Needs
Issues, and other items as required
Problem definition, systematic gathering & organizing information
Finally, share the results and
Solicit additional comments & other input
Plan the Detailed Pro -“ To fail to plan is a plan to fail”
Work Breakdown Structure (WBS) includes:
Hierarchal organization of tasks and elements:
Staff assignment
Scope of work
Technical requirements
Activity Duration
Estimate total hours to complete each activity
Activity Sequencing
Establish logical dependencies between tasks
Create network diagram
Define the critical path – longest duration of dependent activities
Schedule Development
Generate the project schedule
Publish schedule daily
Cost Budgeting to create a cost baseline estimates prior to final budget approval
Measure performance
Allocate costs to activities
Allocate costs to work packages
Risk Management and Cost Contingencies
Control the Project’s Processes
Project procedures are not glamorous, but they play a key role in starting the project off quickly, efficiently and correctly.
Further align the team
Spread the start-up of the project
Quickly formalize working relationships
Maintain project Communications
Document Key decisions
Create Standard Operating Procedures (SOP)
Review and determine applicability
If required, add supplemental procedures, deletions or revisions as exceptions
Provide a copy to each Team Member for review
Possible components of project procedures might include:
Progress Report: Status, Schedule, Action items, Concerns
Communications Records: Documentation of key meetings, conference calls, conversations, emails
Documentation Standards Methods used to maintain & organize key docs & deliverables.
Action Item Lists: Managed list of key tasks required of each member
Communication Procedures: A list of what each TM receives and the ITS format
Risk Plan: Formal documentation of anticipated risks and actions for consideration
Quality Control & Audit: Techniques used to judge quality of work standards, client satisfaction, surveys, documentation control
Project Plan Review: Periodic analysis and review sessions
Formal Deliverables Sign-off: A list of key deliverables with sign-offs by vendors, contractors, etc.
Scope Change Control: Processes for identifying, documenting and controlling scope of work changes.
Apply Systems Thinking
After project initiation, teams often consider new and sometimes very different concepts and ideas which many times are important, but…experienced leaders know it is important to seamlessly integrate new designs to avoid failure.
The experienced team asks how the project outcomes will affect and be affected by:
Company culture and norms
Installed technology
Management systems
Organization structure
Human Systems: employees, recruiting, retention, compensation, training, etc.
Outside stakeholders
Company financial structure
Customer and sales/marketing systems
Assess Project Risks
At the beginning of a project – risk is high, but the ability to mold outcome is also high.
Most assessments of risk are informal and not documented or communicated well.
It is important to ask formally:
What could go wrong with our plan?
What are we missing? Where are the holes in the plan?
What problems are we seeing now, but are not reacting to properly?
A more formal way to assess risk is the use of Failure Modes & Effects Analysis or FMEA
Team assigns numeric values to each to Failure Mode, Effect and Detect-ability
An Occurrence # for how likely is it to happen
A Severity # for the magnitude of the effects
A Detect-ability # for how likely it will be caught and prevented before it happens
Multiple the (3) numbers together to arrive at the RPN or Risk Priority Number.
Higher RPN’s mean higher risks
Anticipate it by envisioning alternative scenarios
Listen for early indications of abnormalities
Respond quickly to minimize damage
Avoid Analysis Paralysis
More projects start off too slow – many times due to analysis paralysis.
It is a trap to think to assume one must collect all the data on all aspects of the project.
During Step$4, decide what data is important and what can be ignored.
Ask these two similar questions:
How is this information going to help me address my project purpose?
Will this information lead to identifying, selecting and implementing a project solution?
Other reasons might include
Overly developed attention to detail
Internal politics and approvals
Lack of internal resources
Personal likes and dislikes
Project Manager must recognize this take corrective action.
The management team has to use experience to judge how fast is just right.
Control Scope Changes
Many projects start with ‘ fuzzy’ scopes of work, which lead to ‘ scope creep’.
Steps #3 and #5 help turn fuzzy scopes into clear work plans.
Break the project into manageable phases or sub-projects with specific time windows
Control the number of hours and people that can charge to a project.
Insist that each phase be given a fixed price estimate or sub-divide the phase.
Review each phase a separate deliverable.
Formal reviews to ensure that scope of work is being managed to completion.
Review Charter at the conclusion of each Phase.
Create a formal Scope Change Control Document for review at Key Meetings.
If the SCCD becomes too long, the PM should reevaluate the Charter and the management techniques the team is using to control the project.
CONCLUSIONS
Each project should start with a solid economic justification
Careful planning of the return on investment (ROI) as the project starts and monitoring during execution is an important component of good project management.
Operations Associates has found that typical projects focus on one of the following value goals:
Reduced costs
Reduced Inventory/Increased Turns
Improved Capacity
Improved Customer Service
Reduced Order Lean Time
Improved Quality Lead Time
Improved Quality
Improved Safety
Increased Working Capital Turns
