Published on
March 6, 2023

Why Projects Fail

After every Flywheel Studio project, we perform a retrospective. We've found two consistent reasons why technology projects fail and more importantly, how to prevent that from happening.

Why Projects Fail

Tech’s dirty secret is that it’s difficult and most projects fail.

“70% of projects go 70% over time and budget.” - McKinsey

At Flywheel, we say a good project is like the Anna Karenina Principle:

That a deficiency in any one of a number of factors dooms a project to failure. Consequently, a successful project is one for which every possible deficiency has been avoided.

As an agency, we’re always looking for ways to improve and sometimes those lessons are learned in hindsight through a retrospective. If you aren’t familiar with a retrospective, a good place to start is How to Perform Retrospectives by Atlassian.

We perform retrospectives on every project and we’ve found two consistent reasons why projects fail. These are interesting because they aren’t obvious and don’t feel like issues at the moment.

The Project Sponsor

A project sponsor, a single individual on the client side, is the project owner.

Asana states it like this:

The project sponsor is the person responsible for the overall success of the project, including appointing the project manager and team, defining success criteria, and ensuring the successful delivery of the project.

The lack of a true project sponsor manifests itself in several different ways.

  • No project sponsor at all means no leadership direction
  • Multiple project sponsors creates a committee instead of a final decision maker
  • Busy project sponsors can’t invest the time in the project to understand the decisions they’re making
  • A weak project sponsor means the team can lose their drive or go in an unacceptable direction

The interesting thing is that during a project, the lack of a project sponsor doesn’t become evident until it’s too late. Only when you look back do you realize the project went over time or there was ineffective decision making.

Change Management & Scope Creep

Scope creep is the famous silent killer. During a project it’s easy to change the scope as new requirements arise. You’ll hear things like “we have to have this to go live” and “if we have time, we should add this”. the changes are small, so they have little to no impact on the project timeline. Over time, they add up into significant time and cost overruns.

A change management process can help prevent scope creep. As new requirements are introduced, they go through a formal review and approval process that also includes documentation. This creates the important ability to look back and understand how and why changes were made, especially if someone challenges time or budget overruns.

In Closing

Ever project is unique and can “fail” for any number of reasons. From our experience at Flywheel Studio, the Project Sponsor and Scope Creep are the two most common. They’re also two of the easier issues to address if you spot them early enough.

In our industry, mobile application development, strong project management skills are more correlated with project success than technical knowledge and skills. Hence, our interest in it.

Hopefully, this can help you prevent your own project failures. We also recommend retrospectives on every project, successful or not, which will help identify your own project weaknesses.

Related Posts

No related posts.

We would love to hear from YOU.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Follow Us:
Follow Us: