Common Problems of Failed Projects

Project Management Solutions

Do you see failing projects in your organization? Maybe you’re on a failing project right now? Read on to see what the five most common problems are and our steadfast solutions to fixing them. We cover communication; stakeholder overload; creepy scopes; business drivers that don’t stay still and people that are either too good or no good in your project team. What are the five most common problems in failed projects?

Communication? Hello, Anyone listening?

This one sounds like a no brainer huh? Well of course, duh! Then why so often is it either not done at all or not done well or often enough? This is the number one thing we see not done well and is the cause of many failed or less than successful projects. Remember, your job as a Project Manager is to make sure that everyone is on the same page, all the time through changing and challenging business drivers, scope, schedule, budget and others.

Solution: Have a communications plan and guess what, ACTUALLY USE IT! Have a MARCOM (Marketing and Communications Plan) and follow previous advice on its use. Constantly validate and revalidate with owners, stakeholders and your customers. This may sound crazy but from time to time your management team might change direction, change their minds, and frequently forget exactly what it was your “project widget” was to look like and do. Rule: You can NEVER communicate scope, schedule and budget enough so make it part of your weekly regiment. Test: you should have everyone in the know so much that if asked about the projects, they could regurgitate the scope, some of the major milestones and other key factors on the project.

Remember that communicating doesn’t have to be about the project – walk the floors and chat to your team, your peers, your Steering Committee. Building relationships is a critical success factor for any Project Manager; it’s a lot easier to ask someone to put in a 16 hour day to re-write a critical piece of code on short notice if you have a relationship with them. I spend a good 20% of my day walking the floors; it pays huge dividends in the long run.

Too many chefs

This ever happen to you? You end up in a kickoff meeting and its standing room only? It seems like everyone in the organization wants to provide input into your scope, project approach and or deliverables? Many failed projects suffer from the “too Many Chefs in the Kitchen” syndrome. This is one problem you had either better fix quick or prepare for one heck of a nasty ride.

Solution: Create a team matrix and a stakeholder matrix and get it signed off of by your Executive Sponsor. Manage this matrix! If you see it ebbing and flowing, nip it in the bud quick. And yes, this means you will have to sometimes walk down that hallway to the Sr. Vice Presidents office to share your concerns, ask for a meeting and get him/her involved. Be careful of the word stakeholder – it means something different to you and to me, so expect it mean something different to everyone you meet. If you use the word, define it. To the whole team. Then when you use the word stakeholder, everyone will know what you are getting at. Don’t be afraid to not use the word at all, it’s sometimes a lot easier! Rule: You should have one person that you can go to that ultimately makes decisions. Test: If you find that you have a committee of people that make the decisions, some of whom actually argue and disagree, well then, go back to step one and get that paired down to a manageable number.

Creepy scope

Scope creep, the ultimate killer. Scope creep happens on just about every project in the world from aerospace, construction and especially software. This will manifest itself in the form of simple scope creep where items of scope are politically, accidentally or otherwise inserted into your project without evaluating the effect on budget or schedule. Then there is the executive “creative interpretation” of project scopes. This usually happens when the executive team identifies something they’d like to add so they “creatively” ask that this is included without additional budget or schedule. Fun huh?

Solution: Preemptive, write a tight scope! I cannot stress enough that if you’re given the opportunity to write or take part in the development of a SOW, take your time to write it well. Interview engineers, ask questions, identify future problems and if possible solve them in the SOW or at the very least, call them out as risks with a possible cost implication. Reactive, if the scope wasn’t written, this project was just thrown at you, get it under control by gaining consensus on the inclusion and exclusions from the project scope. Next, implement your change control process and negotiate with your executive team. Yup, negotiation is another responsibility you have as a PM.

Changing business landscape

Have you ever delivered a project only to find the business need changed between inception and project close? Yep, we’ve been there too! Businesses change, following the market (or not, depending on how the CEO did in his game of golf), and that means your project must be strategically aligned. The business won’t stand still until your project is complete, so be aware that while your project is the most important thing today, it may not be tomorrow. Chevron has spent $6Bn on a project only to find that two years in it’s not in line with the company direction, and closed the project.

Solution: Chat with you Project Sponsor. Your Project Sponsor is not someone that you should avoid in the corridors just in case they ask you to provide the latest budget numbers or a presentation on productivity increases – instead, your Sponsor is someone that can help keep you in the loop with strategic direction and you can both work together to ensure your project remains the highly anticipated ‘thing’ in your organization. On short projects you may not need to check for alignment, on longer ones you absolutely will. If the project is pitched as the ‘savior of our company’ regardless of duration, check frequently!

Personnel

How many times have you been given a project with estimates already completed for you, but based on the best resource in the Company? Who’s not available to work your project? And you have the junior guy as your development lead? So guess what, your estimate is out of whack before you have even started.

Solution: Grab a calculator and your sponsor and sit them down. Go back to basics. If Guru A can do something in 10 hours, and Junior B is 50% as productive, it will take him 15 hours. 15 is bigger than 10, so you need to ask your sponsor for more time. Not rocket science is it?

Next, explain the importance of estimating using the ‘middle of the road’ resources and not your best resource who finds it easy to do everything…once you the sponsors and PMO are onboard with correctly estimating then you are good to go…now how do you accurately estimate? That’s for another newsletter!

Also recognize that while you may not be able to teach the junior guy how to code, you can coach him and mentor him to being more productive – perhaps he or she isn’t confident in their work but is a genius in the making, wouldn’t it be great to be the one to find that out? How do you do that? Go back and read the answer to communication!

For more information or questions, please contact

Chris Marr: chris.marr@cprime.com or Von Holbrook: von.holbrook@cprime.com.

Other Frequently Viewed Articles

Agile & Project Management Resources: cPrime project management resourses, books and recommendation readings.

Risk Management Made Simple: An Overview of Project Risk, Risk Management Objectives, Benefits and Rules.

Work Breakdown Structures: WBS the Forgotten Best Practice of Preparation, Facilitation, Documentation.

Rational Unified Best Practices (RUP): A Primer for the Project Manager and Methodology.

Agile Development & Scrum Meets the PMP: Agile Development and How it Compares and Contrasts to the PMI’s Methodology.

Roadmap for PM Success: Aligning Projects with Organizational Strategy.

The 5 Most Common Problems in Failed Projects: Identifying the 5 Most Common Problems with Solutions.