5 Takeaways from Failed Projects

Projects fail. It’s a painful reality, but they do. And we can either learn from them or keep repeating them.

Unfortunately, we often repeat our mistakes a few times before we realize they are mistakes and may be the underlying causes of the failures. For me, this list of five is a good start in realizing what I needed to learn and change about mine and my teams’ project delivery processes. As you read my list of five, please consider what your list might look like.

1. Always Conduct Lessons Learned

This one is hard, I realize. A 2010 survey I conducted with project managers and their teams indicated that 57% either never conducted lessons learned sessions or performed them on fewer than 10% of their projects. People move on to their next assignments, and it just isn’t enough of a priority to make these sessions happen. That is unfortunate because another survey I conducted indicated that 46% of project leaders felt future project failures could have been avoided if they had been conducting lessons learned sessions rather than avoiding them.

2. Peer Reviews of Deliverables Are Important

I once had a project fail almost entirely because we weren’t conducting peer reviews on project deliverables. You may be saying to yourself, ”peer reviews..why?” Well, here’s why. My very skilled and experienced but also very thinly stretched (across 3-4 projects) business analyst on the project was producing a

Functional Design Document (FDD) – an important document on a complex technical project Not a huge project, but not a small one either…about a $350,000 implementation. Because of a glitch in the PDF program, he was using; we sent 3 error-prone documents to a very frustrated client before we got it right. Then we peer-reviewed every deliverable after that and on every project I’ve managed since then. Small oversights can lead to big client frustrations. Your customers start to think of you as sloppy and question what the overall end solution is going to look like. Don’t give them a reason like this to start lacking confidence in the delivery team’s abilities to get things right.

3. Communication is at The Forefront of Project Success

Miscommunication can sink a project quickly. Communication is Job One for the project manager. Poor or lacking communication leads to misinterpreted requirements, re-work, gold-platting (over developing a solution thus costing extra money beyond what’s budgeted for the task), and poor decision making. All of these can cause projects to fail in mid-project or to cause the rollout of a solution that the end users can’t use properly. Or it may cause a solution to go to user acceptance testing (UAT) that isn’t really ready for UAT. Trust me, the last thing a project manager, business analyst and tech team want to endure is a very painful customer user acceptance testing experience. It’s no fun. It’s costly. It causes great customer frustration, dissatisfaction, and a quick loss of client confidence. “Back to the drawing board” is not a phrase that the project team wants to hear. And your senior management won’t be too happy either. It is a big fail.

4. Make Sure Your Chosen Tool or Tools Can Do The Job

Make sure the project management tools you are using can get the job done. Some projects require heavy bug/issue tracking. That’s great if a spreadsheet can do the job, but if it can’t you need to tie change orders and pricing into it – then you may be running the project with inadequate project management and reporting tools. As you and your team assess the landscape of the project – including the requirements for managing the budget, the issues, the changes and scope, and the risks. Be thinking about what reports are going to be needed and what your current project management tool can handle. You may need to research some new options and chose a different direction for managing this particular project. Spending a little more money or taking the time to use the right tool can mean the difference between success and failure or at least on time and on budget delivery both of which tie into customer satisfaction and a successful project delivery.

5. Balance Customer and Senior Leadership Input When Making Decisions

What the customer thinks they need or want may not actually be the solution to their project needs. That’s why planning is critical, and you may have to tell the customer “It’s bigger than you think.” Step back with your team and assess what the business processes are and whether or not this “need” from the customer is the real problem or just a symptom of some bigger project that needs to happen.

The same goes with your own senior management who may sometimes give you direction on a project or how to handle a customer or key decisions. Do not blindly follow. I did on two occasions, and it ended up costing us two projects worth a combined $3 million. It was painful. Had I openly questioned my PMO Director’s direction on the projects and the decisions he made for these two projects, then we might have been able to save them. Hindsight is 20-20, indeed. But I’ve always been a customer-first kind of project manager and those two projects really confirmed why I am that way. If you are the project manager in the trenches with the customer and team on a daily basis, you are likely in a better position to make good decisions that will benefit the project the most. You see all angles, not just the best interests of your organization. Consider everything and don’t blindly follow. If something doesn’t feel right, say it then and not later when it’s too late.

Summary

Project failure happens. It isn’t always a complete failure. Take that project mentioned above where my team and I delivered the error-prone Functional Design Document three times before getting it right. We eventually handed off a solution to the client. But they weren’t excited about it, it was late, and they never ended up fully utilizing the technical solution. It went about 6 months and $150,000 over-budget. It was for a major airline and could have been a great success story. That one deliverable certainly wasn’t the reason for the failure, and it rested on both sides – with my delivery organization and with improper customer expectations, training, and planning. Still, I would not consider it a success.

What about our readers? What would you add to the list as some key causes of project failures or behaviors that can result in poor project delivery? Please share your thoughts and experiences.