5 Project Failures
Failures are painful, but unexamined project failures are lost moments of reflection, insight, and lessons learned. And that means a failure you may experience again.
Understanding what is critical to your Project, looking for pitfalls, and knowing what to do if something goes wrong can mean the difference between a bump in the road and disaster.
Project Management is part science, part art, and lots and lots of good management. To control all of the Project's key attributes can be difficult (but it is doable).
This article will cover five failure points, why these points are important to virtually every Project, what can go wrong, and how to fix it.
These aren't examples. They are situations I experienced in my 25+ years managing programs and projects. I am a PMI PMP and have taught classes on Project Management. But I have had my share of failures. Most were fixable, some not. But looking back, I can see the mistakes more clearly and hope to help you avoid them.
Though some of these examples are from large projects, the ideas and issues are universal. Even if you are doing a project only for yourself, reflect on how each of these lessons learned may impact your Project's success.
Keep your project advocates involved and informed.
Stakeholders: are your key project advocates, voice to the organization. They can include the Steering group overseeing the Project's goal, approach, and scope.
Why it is important
Stakeholders include the business and financial backers of any project. Often included in a project steering committee is the owner of the final "product" following project completion. It is important they understand the project, agree to the goals and approach. And act as advocates to get the project what it needs to succeed.
What can go wrong
No one likes surprises, and Stakeholders are no exception. If you keep them in the loop, make them look good to the Organization, ensure they are ready to answer questions they may be getting. And they will be on the side of the Project.
If you have a change in management, Stakeholders (or the boss of a Stakeholder), be ready to address their questions and show that you listen to their advice. If they ask for additional information, make sure they have it and then follow up to ensure all is good.
If you have regular meetings set with Stakeholders (and you should), focus on your key contacts and make them your advisors. Before and after Stakeholder meetings, use your advisor to line up support, review how to share project update issues, and find out what is happening behind the scenes.
In some organizations, Stakeholders can be like politicians. If they start to feel the winds of change are coming, then their Project's backing may change as well. So keep your ear and eyes open to internal news.
How to fix it
If you have a change in stakeholders or political backing. Check-in with your Stakeholder advisor. Make sure they are tuned in with the political change. Ask for a special Stakeholder meeting to review the project status and find out what you can do to address concerns. Be open and listen carefully to their answers. Don't put anyone on the spot, but do follow up afterward if you sense tension or concerns from one of the Stakeholders.
If the Project is in trouble. Make sure you
let your Stakeholders know it
share it quickly (and disclose all the facts)
document the issue and the impact on time, cost, or quality
Then give one, two or three options for addressing the issue and be clear about the option you'd like to use. Be ready to back up with your reasons and data.
Agree to the timing to try the resolution. And agree to the next meeting to review the updated project status.
Ensure the Contract is fit for the type of work and maturity of the Solution and the Organization.
Contract: (or agreements) are put in place for every kind of paid work to confirm cost, time, materials, and Key Performance Indicators. Agreements are generally internal to an organization while contracts are with external parties (contractors).
Why it is important
The Contract may be a simple one-page document stating what will be done for what price. Or it can be much more complex and relate to conditions in a Master Agreement (umbrella agreement) that includes additional requirements, conditions, and more.
Either way, contracting at the start of the Project is always difficult. You may not know the client and so don't know if any additional considerations should be addressed. Or the Solution may be unknown. These issues leave changes in scope open to differences in understanding by both parties.
What can go wrong
During the initial contract review, there is often a certain amount of assumptions made by both parties about 'goodwill' decisions (both sides may think: we will do what is in the best interest of the Project).
But contracts are generally written as cause and effect statements. If you miss this date, then you will not be paid. Or sign-off approval is required at certain stages to allow the Project to proceed.
During contracting, the Project Manager needs to assess how the Contract relates to the Project and the Organization undertaking the work:
is the Organization ready
is the Scope Clear
is the Solution known
are Roles and Responsibilities
is staffing properly planned and funded
is timing clear, and does it allow for contingencies
is the contract payment structure fit for the Project (cost-plus, time and materials, fixed price)
Each of these points above can contribute to contracts that are not fit for the project situation. Be wary of rushing the contract process and not allowing for the time to "clearly look the sponsor in the eye," and make sure you both know what you are signing up for.
True words. Even more so, if the project manager finds themselves defending the Project in contractual discussions instead of running the Project.
How to fix it
Focus on the Contract at the creation of the Project:
what is known and unknown?
are key roles and responsibilities clear?
are project scope, approach, and reporting milestones documented?
does the payment schedule link to the project schedule?
are changes in project time, cost, and staffing discussed?
is the contract open for change if the situation needs it?
If the contract type is new to both parties, discuss who the final decision maker is for any assessments on scope or changes.
If the Solution is new, put in wording to allow for flexibility as more is known about the work.
Another approach is to contract for the work one phase at a time (as an example, plan, design, build, implement, hand over).
If the Contract is signed and work is underway, and there are issues, Stop the project if there is a major disagreement on the approach. Before the discussion gets contractual, go back to the pillars of the Project:
why - project purpose
what - scope, time, and outcome
how - schedule and staffing plan
who - skills required for the work
Figure out where the issue is and resolve it:
if there is conflict, resolve it or escalate it
if project leadership is at odds, review the agreed to responsibilities (RACI) model and reconfirm
if the staffing has a gap, fill it
if the Solution is not working, assess and redesign
Do not keep moving ahead when something is not working. Stop and address it.
Issues don't resolve themselves, but continuing to go down the wrong path will not solve your problem. Putting the Project on hold, even for a day, can allow the team to step back and assess how to work through issues effectively and efficiently.
The Solution is the reason for the Project, so make sure it is realistic, achievable, and measurable.
Solution: is fit-for-purpose for the requirements, scoped correctly, users are involved in the design, and Solution, as designed, is achievable.
Why it is important
The Solution, in essence, is the Project. So getting this wrong means that the Project will be in constant trouble throughout its (likely sad and short) life.
What can go wrong
Depending on the Project, you may need to document details in scope related to tools, product, and outcome, such as:
fundamental assumptions about data needed
user involvement in the testing and adoption of the Solution
processes, people, and role changes needed to implement the new way of working
technology infrastructure needed to implement a new application.
documentation needed for regulatory sign-offs
internal policy changes to align to any of the above requirements
If any of the above points are at issue, your Project may have problems. So be realistic and troubleshoot in advance.
How to fix it
Go back to the Project's Why - why is this Project being done? What are the components of the Solution to realize the project goals? Review with the key stakeholders and ensure you are clear on each point and what the needs are to achieve them.
Often the discussion will resolve the issues. However, by workshopping the topic, you can confirm where there are agreements and disagreements, so it is clear that the actual issue is.
If the issue is a gap in skills within the Project, bring in Subject Matter Experts (SME's) to quickly assess the problem and its outcome.
Don't try to solve problems before you understand the problem you are trying to solve. You may be seeing a symptom masquerading as a source. If this happens, you may make things worse.
Once you have solved the solution issue, update your documentation, ensure you've informed of any changes and that the new version of the plan, charter, and related documents reflect the changes or clarifications.
Skilled staff is the critical element to most projects. Make sure you have the right people.
Staff: Many projects are about technology or processes, but all projects include people. The quality of the Team will directly impact the quality of the Project.
Why it is important
What makes a project a project is often new, requires new skills, has several components to reach its objective. And projects need the right people to do that. Skill and skills mix is a significant reason for project failures.
But organizations are getting smarter about the skills gap as seen in the latest PMI Report.
PMI 2020 Pulse of the Profession
What can go wrong
When the skills, capabilities, experience, and attitude of the Team's members are not of high quality and/or not complementary. This makes Team have to work harder. This inefficiency has a cost to the entire Team which shows up as:
exhausted and demotivated staff
missed deadlines
mistakes and quality errors
staff turn-over
project stagnation
A Project Manager needs to address the situation quickly or risk losing their best people. Projects cannot afford massive re-work efforts, so the first-time-right quality levels are essential.
Project stagnation results in inertia when the Project no longer functions and cannot move forward until it is fixed.
As the Project Leader, the Project Manager's skills are more central to the overall project health. The PM needs to be capable and experienced to meet the communication, control, oversight, leadership, and technical knowledge to ensure project success from start to finish. These requirements are IQ plus EQ at work in the most fundamental way. Putting the wrong PM in charge can kill a project.
How to fix it
In your initial Project Plan, you made a staffing plan, review the plan, and identify skill gaps. Assess if it is one or more skills/staff at issue. It can be helpful to do this with a senior member of the Team or a trusted advisor. After the assessment, you may need to discuss certain roles and their impact with your Stakeholders or HR.
Analyze the corrective action needed:
short term staff training
add Subject Matter Experts to increase critical skills for a fixed period
change staff
or, all of the above
Staff training can be helpful deal with specific issues. Subject matter experts do the same with more hands-on assistance.
However, if you have the wrong person in the role, there is little that can be done except to change the person (it may not be their fault, they may have been asked to step up to a role where they lack experience).
I have also found the staff with the wrong attitude can be harder to address but more damaging to the Project. Move them off the Project. If you can't do that, put them into roles that better match their expertise area.
Changing staff can be hard, but it is important for the Team's long-term health.
Focus is a lack of alignment within the Organization or project team. When assessing root causes, always look at Focus as a potential problem.
Focus: If priorities shift, the Team or Organization has too many high-priority tasks, or staff time is based on multi-tasking them. You may have a focus issue.
Why it is important
Projects demand Focus—the ability to see work to the end. Focus is how projects create 'flow' to work together to achieve an outcome beyond expectations (as an example: design team moving work to the build team based on an integrated work style with the user in the center of the work).
What can go wrong
Distractions in project priorities, in leadership changes, or external factors (corporate job reductions). A project manager cannot control everything, but the answer to focus:
Clear communication
Balanced allocation of workload
Timing Follow up to slipping deliverables
How to fix it
When in doubt, go back to the Project Charter, which was in the intention and expectations. Review what has changed (people, process, systems, or something else).
Action to take is simple immediate and effective:
Address the issue with the Team by direct communication (tell them what is important)
Ask the Steering Committee for help (if the problem is in the organization)
Address the underlying issue (is someone over committed to other priorities)
All projects have limited resources of some kind, so address the key gap that is driving Focus.
Once the Project Manager has cleared the 'noise' that has impacted the Project. Review weekly for possible signs of continued problems. Reconfirm the corrective actions are in place or review the issue again for possible deeper root problems.
As mentioned, I have suffered some version of each of these project failures. PMI's 2020 Pulse indicates that others have as well.
PMI 2020 Pulse of the Profession
This report highlights the underlying symptom: Organizational Maturity. The cost to return on investment of a project undertaken too soon, without the right stakeholder, Contract, Solution, skills, stakeholder, or Focus, is evident by this graphic.
In Summary: Based on my own experiences, I would say that the underlying cause was some version of organizational maturity:
Stakeholders saying yes, but meaning no.
Contracts focus on cost only, not outcomes or organizational imperatives.
Solution underestimating technology or change difficulty is easy to do, (so always have a cynic help to review the plan).
Skills cannot be learned on-the-job without a cost, and the wrong PM can kill a project.
Focus is the long game, noise can disrupt the best team.
It is important to note that several of these factors occurring at once can trigger catastrophic failure. In the worst-case scenarios, the Project does not recover.
The good news is that Project's are like people, pretty resilient, and the Project's noted above all overcame the issues and met their objectives. Each lesson learned is experience earned.
Additional Resources on the Topic
PMI Pulse of the Profession (2020)
So what did you think? Have you experienced any of these project failures? How did it turn out?
I would appreciate your feedback and thoughts so we can all learn.
Would you like to have more content of this kind on the blog? If so, let me know! Thanks!