Help! My Project is Failing

But why does this happen so often? Why do so many projects go off the rails?

After a decade in business, I have some ideas.

First, let's kill a few false narratives.

• The programming language is bad
• The CMS is terrible
• The dev shop doesn’t know what they’re doing

My answer to those? Nope, doubtful, and unlikely.

Tools are just tools. They were designed and built by people who care and work hard to make them good. Dev shops are the same way. They have a vested interest in doing good work so they can keep getting more business. It's fair to say some niche languages may be better suited to certain projects. But a majority of the time, the programming language isn't the decisive factor in a project's success. Nor is the agency using the tools. There are a combination of factors that go into taking a project off track. Let's dive in.

So, what could the problem be?

1. Inexperienced people

Building (and launching) software is hard. After all, there's so much to consider. You've got a lot to think about data sets, application flows, background processes, user interface details, and a whole lot more.

Working with people or teams who don't have experience in building complex Laravel applications or CMS sites don't have the know-how to guide to a successful launch. More than likely, they’re doing their very best to deliver for you. Their strengths may not be highlighted by this type of work; in short, they’re in the wrong seat on the bus.

Tip to avoid this pitfall:
Vet your software team before you hire them. Ask them to walk you through complex solutions they've built in the past. Get a reference or two to chat with.

2. Undefined scope

When software is built without an end goal or scope, you're at high risk for a dud project. It's like building a house on sand; if you don't understand the foundations of your project, it's destined to crumble.

An undefined scope comes with an uncertain budget and a muddy timeline. Yikes! If you're going into a project with only a loose idea of what you want, be prepared for a rough ride because things will change as you start to understand the project scope.

Tip to avoid this pitfall:
Try to identify the job(s) your project needs to do and make them as focused as possible. At the beginning of the project, you need to be able to communicate what success looks like at the end of the project if you hope to be satisfied. If you need help, we often recommend engaging in a discovery project to help you better understand the problem being solved and potential solutions.

3. Communication issues

I don't know about you, but my wife and I always communicate perfectly. Like, there's never been even one misunderstanding. *eye roll* Yeah, right. Humans have a hard time communicating, which can be exacerbated by the complex and often abstract ideas that accompany software dev.

Developers like to talk about code and architecture; business folks like to talk about features, customer success metrics, and ROI. While these aren't wholly incompatible languages, finding common ground to communicate on is critical.

Tip to avoid this pitfall:
Written communication after a meeting helps reaffirm what was discussed. Often, we'll turn features into 'user stories' to ensure each party grasps what will be built.

Now that we know why projects fail, what are the options for moving past that failure?

Phase 1. Stop the project

Depending on your relationship with the development team, there are two ways to do this. I recommend asking for a pause to evaluate where the project went wrong and if it can be remedied with the current team. If the relationship has soured to the point of no return, your only choice is to let them go.

The most important thing is the project itself stops changing. No more dev, no more feature requests, no more releases. Changes need to halt so you have a static thing to evaluate.

Phase 2. Assess the damage

Now that the project has stopped, assess what's finished. What’s more than 95% complete? Anything? Most of it?

If you’ve reached the point where most of it is almost complete, you probably have project fatigue — hang in there! After all, the last 20% of a project represents 80% of the work. Reset your expectations, communicate what needs to be finished and when, and push forward.

Phase 3. Salvage what you can

If you look at the project and can't see anything that’s finished, it's time to bring someone else in to evaluate the situation. The goal in an external evaluation is to gain a third party's perspective and answer a few questions: How was the application built? Did the dev team follow best practices? Are there any critical architecture flaws? These are just a few of the questions a code review should be able to answer. Depending on project size, you can typically get a code review with recommendations for under $10,000.

Keep learning

If you made it this far, you might be dealing with a failed project or have dealt with one in the past. I'm sorry, that’s not a fun place to be. I've gone through this personally and have walked through the process with others. If you need a second pair of eyes on your project, reach out to our team and we’d be happy to see how we can help.

And remember, if your project has indeed failed, recognize it, learn the lessons, and move forward.