Why Projects Fail

& The 5 Steps to Ensure Success


There are two kinds of projects, the kind you can’t wait to start and the kind you dread having conceived of in the first place.

The funny thing is, both have an equal chance of being a great success or utter failure.

Why? The outcome boils down to three things:

  • Vetting viability
  • Managing expectations
  • Controlling scale

If any one of these components are out of sync, things tend to unravel and you end up with a lemon. By understanding the anatomy of successful projects, you can avoid these pitfalls and make “lemonade” from every project.

To begin, projects tend to breakdown into 5 stages: vetting, development, testing & editing, implementation, measuring & review.

Below is a quick guide to each stage and leading questions to help you select the best ideas and execute on any project. Note: It probably took me longer to write this article than it will take you to run through each exercise. Enjoy!

Step 1. Vetting Your Idea

A shiny new project always sounds exciting. However, taking a step back before you get too far down the rabbit hole is really important.

Ideas are cheap. Implementation is expensive.

As my mother always says, “ideas are cheap.” Implementation is where things get expensive. So when a great idea comes along that gets everyone excited, ask yourself, What does this idea solve?

If the answer comes easily and you still like the idea, run a SWOT (Strengths, Weaknesses, Obstacles, and Threats) analysis.

Is the objective attainable within your current circumstances?
If yes, move on to step 2.

If no, stop here and ask, why not? If the answer is simple and easily solvable (i.e. won’t cost much time or money), you might be able to move forward. If not, shelf the idea.

Step 2. Developing a process

Utilizing the outcomes from your SWOT analysis, you can begin to outline a solid plan. This section will walk you through 4 components: research, budgeting, securing talent, and setting a timeline. It’s a bit tedious, but things pick up after this, promise!

A. Research

Research tends to be challenging for a lot of people. It can be time consuming, but it certainly doesn’t have to be. Here are two questions to simplify the process for you:

Q1: What do you know?

Have similar projects been done before either internally or by another company?

Chances are yes.

You can use this quick spine (below) to layout the information and from each example.

Basic Case Study Outline:

  • Objective: 2-3 sentences outlining the initial scope of the project
  • Approach: A summary of how the project executed
  • Outcome(s): Bullet out the results from the project
  • Major learnings: Taking the full picture into account, what were the strengths, weaknesses, or surprises? What should be changed if the project were to be done again?

Q2 .What do you need to learn?

Make a punch list of all of the outstanding questions or items you need to understand better. Give yourself a week and reach out to people who can help you answer these questions, gather quotes from service providers you might need, and read up online.

B. Budget

Most budgets tend to over generalize and don’t provide enough detail.

The budget is the backbone of any project.

A total stranger should be able to look at your line items and understand what the priorities and goals are for your project. So, don’t skip out on the details!

  • How much can you afford to spend?
  • How many individual line items will the project have?
  • How much will implementation cost for the “dream” scenario versus the “economic” version?
  • What are the estimated maintenance costs in year one? Can they be covered in this initial budget?
  • How much income will this project potentially generate (include high and low estimates)?

Note: The number of line items will give you a sense of how many places the budget can run off course. It’s good to inflate line items by 10-20% to account for incidentals.

This is also a good time to think about the overall financial impact of the project. People often forget that spending doesn’t always end with a project deadline. Here are some questions to consider:

  • How much financial gain will come from the “dream” versus “economic” version?
  • Which version will cost more to maintain in the long run?

This is another exit point.

As mentioned in section one, if things aren’t lining up, take a step back and strategically look at the situation.

If the answer is simple and easily solvable (i.e. won’t cost much time or money), you might be able to move forward. If not, shelf the idea.

C. Talent

Every project is unique because of the people implementing it. If members of your team change from project to project, you’ll have to deal with different variables based on the individual strengths and weaknesses of each person.

For example, some people might take more time, but can deliver completed items on the first pass. Others might need to go through multiple reviews to deliver.

Both styles are great as long as you understand how people work.

  • Who will serve as the project manager?
  • Which internal team member(s) do you need to implement and complete this project?
  • If any, what additional talent will need to be hired?
  • What responsibilities will be delegated to each person?
  • How will each person be held accountable for the portions they are responsible for?
  • Who will be in charge of communications to each team member?

For many people, it’s easier to follow in a visual layout. This is where creating a project matrix in a Google.doc or making a mind map can be really helpful.

D. Timeframe

Building off of the last section, you now know the talent you’ll be working with, so take into account their individual strengths and weaknesses when it comes to timely deliverables. If you know your deadline, it’s easiest to work backwards from there.

  • What is the overall timeframe available to execute the project?
  • What are the major milestones?
  • How long will each component take?
  • Which areas are most likely to go overtime / undertime?
  • Has any one person been delegated to many items to juggle in the allotted timeframe?
  • How much time do you actually have for implementation?
  • At what points can you adjust the timeline if changes need to be made?
  • Where can time be used more strategically?
  • Are there any indications that the budget needs to be revisited due to changes made above?

Step 3. Testing + Editing

Most people think this part is overkill. It might be for small projects, but for large scale projects, I think it’s crucial. For example, would you ever produce a multi-day conference for several hundred people without having done an event before?

Probably not.

You would most likely host a half-day or one day event with 50 or so people first.

So, whatever your project is, do a small scale test first. At the end, you can form a case study that can serve as the base for the larger implementation.

Step 4. Implementation

If you have truly followed steps 1-3, you should have a pretty good sense of what will happen when you’re heads down in the trenches.

If things are working, you have a plan and the most important thing is to keep an even momentum going to keep things in proportion.

The work is in the “doing.”

If things for any reason fall off track, determine why and how to fix it. Ask, will it work itself out at another stage of the plan or does it need immediate attention?

Step 5. Measuring + Review

This is probably the hardest part of any project.

By the end everyone is exhausted and SO thankful it’s all over. No one wants to sift through the data and do a “review,” but it’s an essential part of the process.

The best format is to schedule a 90 minute meeting and follow the case study spine from section 2A. It’s quick and can be a great asset for your marketing or internal training materials.

No really, why bother?

Even if the tone is encouraging, how often have you felt like regular project communications are the end of a whip cracking?

I was talking with a friend who works in customer service for an e-retailer the other day about how challenging it can be to review employee performance when it’s based on customer feedback.

You usually only hear from people when they aren’t happy.

He tells his team that “you” don’t send a customer follow-up email for the sole purpose of making sure the customer received the proper order, you do it because it’s a chance to hear positive feedback.

He takes this feedback into team meetings, gives everyone a chance to share how they can improve their individual performance and ideas on how the team can work better together. He has found this method boosts individual employee morale and overall engagement as a team.

To me, it’s a really interesting metaphor for how teams should wrap projects.

People get so stuck in their individual piece. A group wrap-up gives everyone a chance to take a breath, put everything on the table and look their contribution to the bigger picture.

Most importantly, it allows room for everyone to have closure so they move on to the next thing with a clear head.


Brady Hahn (@bradyhahn) is the founder of Hug Development, a holistic consultancy focused on positioning organizations to scale through strategy and experience design facilitation.