Stalled Projects? How to Find the Root of the Problem

Depending on the situation, you could probably make an argument for all of the above, but I’d like to suggest that the biggest challenge is, well, bigger. It’s something that determines the direction and velocity of every project, regardless of the languages, tools, or frameworks you’re using.

The biggest challenge in programming is the part that involves people – because let’s face it, code is a little more cut-and-dry than human beings with different thoughts, feelings, and experiences.

Managing people and projects effectively often comes down to your team structure and your product strategy. If these veer away from an optimal setup, you’ll start to see symptoms throughout your projects, potentially mistaking them as indicators of other problems and solving for non-issues.

To illustrate how I learned this, I’d like to tell you a story.

Ending the Neverending Project

When I first graduated with my computer science degree, I was hired full-time working for a regional enterprise. My first project was working with another team within the organization to build an analytics dashboard that collected data from many different data sources. Some of the data the team needed to report on could not be automatically obtained, so it had to be entered manually.

The end product needed to be a simple web app with custom SQL queries to pull the data to calculate the necessary metrics – not generally a heavy lift from a development perspective.

But this project went on forever.

The challenge, I soon realized, wasn’t the code itself, but continually shifting requirements delivered by the product owners, who were having a hard time nailing down what calculations needed to be included in the product. This made it appear that my team wasn’t delivering when in reality we were trying to hit a moving target and were not aligned on project goals.

The neverending project finally ended when I spoke to my manager about the problem, and she brought in a business analyst to help us hold the product owners to their requirements. We started meeting deadlines, and we got all of our work done on time or slightly ahead of time because we had reliable requirements and could give accurate estimates.

Since then, I’ve had a lot more experience managing products and projects myself, and there were quite a few things that we could have done differently from the outset that would have provided a more desirable outcome from the start:

1. Start Your Project Off Right

Something we didn’t have at the beginning of the neverending project was a clear plan that helped us understand what the product and the users needed to accomplish.

We needed something like the Strategy Sprints we do at Very, where we work to define the business needs, the end-users, and the solution we’re bringing those users. While the end result of a Strategy Sprint is a phased product roadmap, having a definite plan doesn’t mean we can’t be agile or adapt to necessary changes. In fact, it helps us to make sure every step we take and every hour that we bill is driving towards the right goals.

During the Strategy Sprint, we ask a lot of questions that may seem relatively basic, but we ask them because we can’t make assumptions. Making assumptions might be easier and faster in the short term, but in the long term, it will more often result in products that don’t meet the needs of the users or the business.

If we’d started off our project with a Strategy Sprint at my first job, it would have saved us a lot of time, effort, and sanity.

2. Document Your Knowledge and Processes

Another major challenge we encountered during the neverending project was that there was little to no documentation of important knowledge or processes. Because so many people had been at the company for 10 years or more, there was a lot of hidden tribal knowledge that, as a green developer and new employee, I just didn’t know.

My advice here is this: remember that your best developers won’t be around forever and that the future of your organization depends on some of the most junior in your company. If a junior programmer is underperforming, ask why. Are they set up for success now and in the future?

In addition to not having robust documentation of knowledge and processes, our team working on the neverending project also wasn’t documenting all of the changing requirements. We had no reliable record of how the product was progressing.

The takeaway here, of course, is to write things down. It’s a simple piece of advice, but it makes all the difference.

3. Look at Your Team Structure

In our case on the neverending project, the best solution was to bring in a business analyst to handle the gathering of requirements and maintain accountability with the product owners. That’s because we had only one or two people doing everything – requirements gathering, developing, and more. The team structure wasn’t set up to make people successful, so things were slipping through the cracks.

If we had been more thoughtful about team structure and individual responsibilities upfront, we likely would have turned out a better version of the product faster. This doesn’t always mean hiring someone new or outsourcing work – it could just mean shifting your team’s priorities to make sure the highest-impact tasks get done.

4. Get Close to the Users

At one point in the neverending project, when miscommunication was at an all-time high, I moved my desk to the other side of the company’s five-building complex to physically sit with the team who needed the product, to watch them work and understand what they were really looking for.

It can’t be overstated how important it is to really understand what users need in a product, and that often requires actually talking to those users and observing their day-to-day activities.

Sure, we can gather requirements from the person who’s managing the users, but managers often only have a high-level view of what’s really going on. (They made a whole show about this called Undercover Boss.)

At Very, we’ll often send product managers and developers directly into our clients’ offices to observe and have these critical conversations, resulting in products that feel intuitive and drive results.

Your Next Project

This list encompasses just a few of the major project inhibitors I’ve encountered, and how we proactively address them at Very. Overall, we choose to believe that every person is doing their best given the tools and information available – so we work to make sure that everyone is set up to do their best work.

If you’re looking for a development team who’s been there, done that, let’s chat about your next project.