Know Your Blind Spots: The Top Ten 10 Reasons Why Projects Fail, Plus How to Avert a Hot Mess in Your Upcoming Projects

Know Your Blind Spots: The Top Ten 10 Reasons Why Projects Fail, Plus How to Avert a Hot Mess in Your Upcoming Projects

We’ve all had that sinking feeling in a project when disaster looms ahead, a turnaround is nowhere in sight and we realize the only way out is to jump ship.

These failed projects so often begin innocently enough. The team and client set off buoyant and full of hope. Yet just even one fatal turn around a blind corner yields a battered team, a busted budget, and an outraged client.

So why do they fail? How is it that red flags are ignored and a project manager proceeds without the necessary resources, without stakeholder buy-in, without even a contract or scope document?

There’s a million reasons for project failure. And as it turns out, avoiding these dead ends means playing by all the rules. All those terms, concepts and processes they taught you in project management school exist for a reason. Network diagrams, scope and procurement documents, daily scrum, and risk management tools all serve to keep a project on its rails. If you want to avert capsizing a project, the surest path to success is to be that Captain No-No. Resist pressure to cut corners and gloss over details.

In this article, we’re going to cover some of the most common reasons for project failure with examples, and underscore the project management principles that avert these fizzles and disasters.

1. Stakeholders on the Fence

A project’s success hinges on stakeholder buy-in. It’s as fundamental to a project as pollen is to a bee. Even in a team of two, cooperation and assent are critical. Otherwise each member is pulling in an opposite direction, and they won’t be able to reach the goal.

The need for buy-in is especially clear with organizational changes such as an agile transformation. When upper management and other key players resist the change, it becomes impossible to disseminate new procedures or build a new culture. Rather than achieve change and growth, the organization instead flounders, squabbles and squanders resources.

The Fix

In order to gain buy-in, first of all it’s necessary to understand just who the critical stakeholders are. Generally, they include people both inside and outside the organization. Once identified, the next step is to persuade them. For a project to proceed smoothly, stakeholder buy-in is needed from the very first stages.

How to persuade? Buy-in is usually gained by disseminating the “why” behind the goal, rather than just the “what.” WIFM plays a huge part here as well. Once stakeholders understand how the objective benefits them, they’re far more likely to buy-into the vision.

2. More-Is-Better Thinking

Every project aims to deliver big on value and expand the boundaries of its current level of output. Excellence is part and parcel to success. A team that fails to strive delivers subpar or mediocre results. However, this principle can be taken to an extreme and leave teams caught up in a maze of offering more and more, squandering time and resources, without delivering on value. The truth is, sometimes reducing scope actually increases quality!

Consider the example of an instruction manual that accompanies a new sound system. In the interest of providing value, a project manager might set out to create an exhaustive manual that covers every detail of the product, down to the smallest minutia. The fact is that a lengthy manual of this sort may simply confuse buyers and leave them tearing their hair out wondering how to use the product. Far more valuable to the customer is a brief manual that covers the essentials with simple, easy to understand language.

The Fix

At the end of the day, customers are interested in value, not quantity. They want their problem solved as quickly as possible. Delivering value, then, means distinguishing between quality and scope. A project manager identifies and hones in on what’s going to add value, then cuts out those extras that don’t serve any purpose.

3. Foggy Scope

Scope is one of the three central constraints in a project. When properly defined, it’s easy for a project to work within the other constraints of budget and timeline. When the scope is unclear and hazy, however, a project is staged to go haywire.

Take the example of a credit union that is set up to receive payments and deposits by mail, but currently the customers want to pay automatically. In this project, the high level requirement, essentially, is to automate what was formerly a manual process. While this sounds simple enough, this project’s execution could introduce surprises. Perhaps in order to learn how to automate payments, the credit union has to hire outside consultants to look over the current system and offer advice. At this point, the credit union faces compliance and privacy regulations that need to be properly addressed. The scope turns out to be far larger than it seemed at the get-go. Addressing the compliance issues will add to the budget and timeline, and it may even preclude the project altogether.

The Fix

Knowing the full scope of a project requires much research at the get-go. This means talking to all stakeholders and evaluating the project from a variety of perspectives. It’s necessary to set up a network diagram that lists every step of a project and the dependencies between tasks. Sometimes, it’s also helpful to look at documents from past projects, or to speak with someone who’s undergone something similar.

4. Flimsy Requirements

Requirements are all the criteria a project must fulfill in order to be successful. The requirements, then, must be carefully outlined before a project commences. Capturing requirements, however, can be tricky. While some are super clear, others are implicit and unstated.

Take the example of an artist who hires a designer to build a website to feature and sell her work. She says she wants her website to have several pages with images of her work, a contact page, an order page, and a bio page. Clear enough. What she doesn’t say, however, is that she wants the website to be ‘user-friendly’ and to reflect her brand. These later requirements are known as non-functional requirements. They’re difficult to quantify, and so it’s hard to tell whether or not they’ve been fulfilled.

The designer might build a website that includes all the pages the artist requests, only to find that the artist doesn’t like the end result at all. The colors and font don’t reflect her brand, and it provides such a poor UX that it doesn’t draw customers or promote her business.

The Fix

In order to avoid delivering a product that doesn’t meet the client’s specification, it’s necessary to capture a full understanding of all the requirements at the get-go, both functional and non-functional. One way to capture non-functional requirements is to treat them as constraints which define the boundaries of a project. It’s also a safe bet to check in with the client throughout the project and determine whether things are veering off track or staying the course.

5. A Pointless Product

Every project needs a market demand and business justification. Even if it seems like a great idea, unless there’s a need for the product, it will land with a dud. And unless the project makes good business sense, it spells financial trouble. Although this probably sounds like a no-brainer, it’s actually pretty easy for a team to get lost in a fantasy world of designing a product that doesn’t have a market, building a course that no one wants to take, or writing a book that no one wants to read.

Consider the example of New Coke, launched by Coca-Cola in 1985. Although the company believed it was delivering a new and improved recipe, it turns out that customers preferred the original Coke, and didn’t reach out for the new product featured on grocery store shelves. As a result, Coke lost millions.

The Fix

Knowing customer needs and preferences is a delicate science. That’s why there’s a profession dedicated to this job exclusively: the product manager. A product manager thoroughly researches the market and the customer, and understands just how to design a product that entices the target market.

It’s also necessary to outline the business case of a project from the get-go. Drill down into the numbers to determine if the project makes sense financially.

6. A Band of Fiefdoms

Projects are like an orchestra. They’re the fusion of people with entirely different skill sets performing entirely different tasks, coming together to create something wonderful. It’s only natural, however, for a large group to disband into small groups with similar workloads. This tendency can be so strong that the “orchestra” can separate off into individual fiefdoms who only listen and communicate amongst themselves. Without cooperation between all these factions, things can go awry.

Take the example of building a website. The software developers and the copywriters each have a distinct skill set and very different tasks to perform. Naturally, they would be inclined to work separately from one another. Without ongoing communication, however, it could come to pass that the copy intended for the website isn’t suited for final layout. It’s either too long or too short, and everything needs to be re-written. Or take the example of creating a video, where the costume designer works in silo from the writers and set designers. When they all come together, there could be a serious mishmash of styles, tones and aesthetics.

The Fix

The solution is to communicate, communicate, communicate. Develop a structure and system that keeps all stakeholders abreast of everything going on in the project. A transparent work culture that discloses key information to all members and holds regular skip level meetings fosters fluid communication. Getting everyone onto the same communication tool precludes scenarios where significant decisions are made without the knowledge or input from key players. Many teams nowadays depend on the daily scrum, where everyone comes together first thing in the morning to discuss progress and blockers. This keeps everyone on the same page and helps to avert disasters before they occur.

7. The Fantasy Goal

The best projects are always stretch goals. They aim to improve on current processes and build something that’s more innovative with less resources and less time. However, this line of thinking can turn into “pie in the sky project management.” The team expends resources and energy only to discover that there is no pot of gold at the end of the rainbow.

Let’s consider the example of a toy manufacturing plant that seeks to improve its workflows in order to increase overall production. The project manager presents management with a plan that lists the required resources and time, and they in turn slash the budget and cut the timeline in half, without adjusting the overall objective.

The old axiom of garbage in, garbage out applies here. The project, more than likely, is poised for failure. Even if everyone on the project doubles their workload, the goal is unrealistic. Management instead sets the stage for employee burnout. Plus, the project manager’s reputation is on the line.

The Fix

A good project fuses stretch goals with some real thinking. By utilizing project management tools such as the work breakdown structure, the cost breakdown structure and a network diagram, it’s possible to gain a firm understanding of the work and time necessary to achieve a certain goal. When this is communicated effectively, it gets all stakeholders to agree to a certain budget, scope and timeline. And unless management agrees to live in the real world, the project manager doesn’t move forward into execution.

8. No Plan B, C or D

Risk management is part and parcel to any plan. This means knowing how and where things could go off track, and what to do when mishaps occur. It can be difficult, however, to dedicate time and resources to mitigate something that might happen. Many project managers would just as soon solve problems when and if they occur, and otherwise focus on the goal.

Without a solid risk management plan in place, however, a project is staged to go amok. Take the planning of a one-day event such as an outdoor Church rummage sale. On the day of the event, things need to fall right into place. There isn’t time to reflect and adjust. If the planning committee doesn’t account for contingencies such as the possibility of rain, the entire event could be a bust.

The Fix

The solution to averting risks is to anticipate curveballs and treat risk management not as an afterthought, but as a priority that’s consistently applied through all stages of the project. For any possible mishap, have a plan B, C or D in place so that when disaster occurs, things don’t go off the rails.

9. Non-Contractual Add-Ons (Gold-Plating)

The classic project constraints of budget, time and scope are just that–constraints. A successful project works within them. It’s all too common, however, to get so caught up in pleasing the client that a team goes above and beyond the initial agreement. However, agreeing to changes that aren’t included in the contract can escalate into a headache later on.

Take the project of creating an advertising campaign for a client. The initial requirements include an e-book, a short video and five blog posts. Mid-way through the project, however, the client says that she’d like some content for her social media account. The project manager could simply agree to this add-on, without adjusting scope or discussing price. When it comes time to deliver, the client might say that the social media posts aren’t up to snuff, and need to be rewritten. And then the team is on the hook to revise a task that it’s not being paid for to begin with.

The Fix

Avoiding scope creep and gold plating in a project can be tough. Some of the key strategies are to start the project with a clear scope document that clarifies all the functional and non-functional requirements. Close communication through a project’s execution, with both the client and within the team, ensures that everyone is working to the client’s requests, without adding on additional work.

10. A Black Box Approach

The goal of a project is to deliver a valuable product to the client. But it’s easy for a team to sign a contract, then become myopically fixated on fulfilling the contract, and ignore any relevant details that surface during execution.

This black-box thinking can be especially destructive in software development projects. Take the example of building an application. During the execution phase, while developers are writing and testing code, a competitor comes out with a nearly identical product. At this point, it would be wise for the team to tweak the original plan in order to distinguish the product from competition. Without ongoing communication with the client, and keeping abreast to goings-on in the outside world, a team would miss this sort of critical information that impacts the project’s success.

The Fix

This destructive black-box thinking is the reason software developers invented scrum and agile. These project management methodologies allow for course correction and demand continual, face-to-face communication with the client. An agile approach to a project means that teams work toward the real goal of pleasing the client with a good product, and don’t get caught up in simply fulfilling a contract.