Recently, a potential client asked us a great question. She wanted to know what we have seen cause projects to go off the rails, and what we have learned from those experiences. I assumed she wasn’t talking about moving from Rails to Python and instead was asking what caused projects to fail.

It’s the first time I’ve been asked that and I thought it was such a great question. It led to a great discussion with this potential client, and really got me thinking. So, I decided to open it up to the rest of the Rocket crew to see what others have seen cause some projects to become a cluster, either at Rocket or elsewhere.

Here are the main things that I heard:

Not having a single source of truth: The lack of a single source of truth, or a primary decision maker, on the product side can cause a lot of challenges for a project. The lack of a leader often leads to analysis paralysis and an inability for the team to be able to move forward. Identifying whom in your product organization can make product-level decisions in any new project will help your team continue to move forward and gain momentum quickly.

Not defining a clear, initial “Minimum Viable Product”: We’re big fans of Minimum Viable Products (MVP) at Rocket, mostly because we’ve seen too many situations where a team does not define a clear MVP and ends up wandering in the dark and wasting a lot of time going back and forth between different approaches. Having a well-defined vision (designs are even better!) for the MVP will align the team and make sure everyone is moving in the same direction.

Not thinking iteratively: The inability to think iteratively often leads to an almost fear of releasing a product. The team will continue to build and build without releasing features and being able to capture feedback, learn and make improvements. We believe that product teams need to have a mindset focused on “launch, learn and iterate” in order to be able to move quickly but also deliver great products that customers really want.

Competing priorities: This is a common one, particularly in larger organizations. We’ve seen projects grind to a halt because of interdepartmental dependencies or competing priorities. These issues can also cause scope creep, where teams continue to add in new features throughout a project. A team can only be as fast as the slowest link! If there are any external dependencies outside of the team, the key is to identify these early and not delay in making progress on them.

Failure is part of the process sometimes

We are not here to point fingers or stand on a soap box (unless that soap box has wheels and a mattress attached to it). We are the first ones to point out the many times that we’ve failed. It happens, more often than any of us would like. But we always learn a lot when a project goes off the rails, and that’s all you can really ask.

Subscribe to Launch Pad