Skip to main content
Top Project Failure Points and How to Avoid Them
While every project is unique, the triggers of project bombs are common place. Understanding these fault lines and how to avoid them will allow you to take a proactive step toward achieving project success regardless of the scope or timeline presented. Poor Planning Every project that goes down in flames starts with poor planning - I challenge you to find one that didn't. If you don't know your client, know their needs and know your capabilities up-front, you won't be planning the project your client has in mind. Avoid these poor planning mistakes: - Selling the project without doing your research - Not bringing in the right stakeholders before the contract is finalized - Collecting incomplete or incorrect assets from the client (marketing, technology, etc) - Spending little to no time talking with the client and internally with your project teams about possible solutions - Not explaining the importance of using discovery Vague Scope of Work What is the Scope of Work? It's what clients and project teams should consistently be referencing so that everyone is on the same page with what to expect upon delivery. It also outlines budget and timeline which is just as important to your client as technical specifications are to your programmer. Don't let these mis-steps slip into your Scope of Work: - Goals are not clearly outlined with corresponding deliverables - Deliverables outlined are worded in vague "marketing speak" and don't clearly tell clients or teams what is needed in layman's terms - Scope is defined but only at a 30,000 foot level - details are not described - A timeline with milestone meetings is not outlined along with major delivery points Weak Project Management "He who has never learned to obey cannot be a good commander." ~ Aristotle If you have weak team leadership from a Project Manager, you cannot expect your project team to do much better. If your project manager does any of these, they need a reality check: - Doesn't keep track of the team's hours and check that deliverables are being met on a daily and weekly basis as-needed - Doesn't hold the client responsible for taking an active role in making decisions and understanding the project process and delivery points - Doesn't address and handle scope changes - Allows clients to direct project when tough situations are presented to them Lack of Resources Remember that planning stage that is so crucial? Once a project has been approved, a contract is signed and you're ready to get into build. Avoid these traps when picking your project team: - Assigning a project to a team that doesn't have the skills to match the goals (ie: your best mobile web team is working on eCommerce) - Not understanding the current project load of your team before giving them another assignment - Picking a team that has the skills but not enough people to get the job done in the time promised to the client Miscommunication The best way to keep open and clear communication is to practice it...Communication - the ACT of communicating and conveying information. Ask yourself if you or your Project Managers carry the calling cards of good project communication? Do you or your PM: - Keep daily to weekly communications with the client about the progress of the project - Setup meetings for milestones such as design review - Let your client or your team know about scope changes - Communicate for understanding If your client asks "how do you get people to go online?" then you should reevaluate your plan to talk about SEO and Analytics and start with the basics of why you're launching a new Web site.  You can't assume team members or clients know what you know. Cascading Problems We've all heard of the term "vicious circle" and it can crop up in projects, ruining what you thought was going to be a huge success. Watch out and break the reinforcing loop of instability if you hear this from your team: "It's not my fault! Programming doesn't meet the needs... because the designers didn't vet out that form page... because strategy never created a wireframe for it... because the project brief was unclear". Why do "because" excuses crop up? - Requirements are not clearly defined in the scope of work - Poor technical design inhibits programming - Testing is not thorough and quality assurance falls off the radar While this list provides a good starting point to make sure you're not doing any of the above, what habits lay the path to project glory: - Defining Clear Project Goals - Developing a Detailed Scope of Work - Assigning Appropriate Project Managers & Resources - Scheduling Client Briefings & Project Team Meetings with Clients - Documenting Everything and Requiring Client Participation