Anatomy of a Failing Project: Patterns I've Seen

I was six months into my second project at SEQTEK when I realized we were building the wrong thing. We had stakeholders who barely talked to us, a team where nobody owned anything, and front-end developers drowning in complexity while I kept thinking: We're going to get fired.

We didn't get fired. But that project taught me something more valuable than success ever could: the anatomy of failure is predictable.

I've worked on projects that hit the brink more times than I care to count. Complete failures are rare. But projects that limp across the finish line, burn through trust, or solve the wrong problem entirely? Those I've seen plenty of. The warning signs are always there. You just have to know what you're looking at.

When Shared Accountability Becomes No Accountability

That second project had a fundamental problem: we never clearly defined roles and responsibilities within the team.

In an agile team, shared accountability can work beautifully. When people mesh well, when trust is high, when everyone's focused on getting the job done, you don't need rigid role definitions.

But sometimes shared accountability is just no accountability.

We had two back-end developers (me and a database guy) and two front-end developers struggling with a complex UI. Tons of data entry, tons of validation. We'd made some early architecture decisions that weren't forward thinking, and those decisions were catching up with us hard.

People were touchy about the things they were working on instead of just getting the job done. We weren't communicating enough with stakeholders. We weren't necessarily building exactly what they wanted, and it was clear that adoption was going to lag.

The specific mistake: we decided to write our own validation library and validation components. This is a solved problem. Everyone building a web app deals with input validation. There are mature, well-tested solutions. We decided to reinvent the wheel anyway.

What I do differently now: I focus on solving problems only we can solve. The problems that are specific to the client, that require us to be in the room gathering requirements and understanding their workflow. I don't solve problems that everyone solves. I don't build my own SMTP server to send emails. I don't build my own cloud hosting platform. I use AWS SES. I use AWS.

The problems you should solve are the problems only you can solve because you're there with the client. Everything else, let someone else solve.

The Pattern You Miss Until You've Seen It Three Times

Here's what I didn't understand early in my career: miscommunication isn't the problem. Miscommunication is the symptom.

The problem is that nobody actually verified that communication happened.

This shows up as rework. You build something, then rebuild it differently. Sometimes the client legitimately changed their mind. But most of the time? There was never a shared understanding of what they wanted in the first place.

On that same second project, we built ten versions of the same report. Ten. It was a volume accounting report for oil well drilling, and we kept reformatting it, restructuring it, changing the calculations. At the time, I thought: clients just change their minds constantly.

I was wrong.

What was actually happening: we didn't understand the problem they were trying to solve. They thought they wanted a report. What they actually needed was to track material usage differently across their entire workflow. Once we figured that out, we got it done.

But I didn't see it then. I saw it as client indecision, not as our failure to dig deep enough into the actual problem.

The pattern: when you see a lot of rework happening, when you're building something and then having to redo it in a different way, you're working on the solution without fully understanding the problem. And once you're locked into a paradigm, you get confirmation bias. Information that tells you you're solving the wrong problem gets forced into your current understanding. Until it can't fit anymore. Then the paradigm breaks and you do massive rework.

That's how projects fail. You estimated the work based on building it once. You didn't account for building it three times.

When The Product Owner Can't Get Stakeholders To Engage

A few years later, I worked on a different project that nearly fell apart for completely different reasons.

The client was a pipeline services company doing corrosion work. The job was straightforward: they had Excel spreadsheets for requests for quotes and requests for bids. They wanted to turn that into an app.

But the product owner couldn't get a meeting of the minds with the stakeholders. Later I found out these were genuinely difficult stakeholders to work with. But at the time, all I could see was that we weren't making progress.

The product owner would start a sprint with certain items. Those items would get completed. Then a day or two before the sprint ended, ten more items would show up. When the sprint ended: why aren't these ten items done?

I offered a compromise multiple times. We could work more informally, skip the formal sprint structure, and I'd build based on my working understanding of the product. Get something in front of the client faster, even without sophisticated requirements gathering. But he wouldn't meet in the middle on process.

The real problem: he wasn't communicating about how much he was struggling to gather requirements and get decisions made. He would just make up a bunch of stuff. We would build it. Then the very next time around, we'd do something completely different. It was chaotic.

We ended up replacing that product owner. The new guy admitted upfront how difficult it was working with the stakeholders.

But he was professional about it.

What Actually Fixed It

What the new product owner did differently: he made himself a nuisance. He told them directly (but tactfully): you have to meet with me, you have to answer these questions, or we will not get this done.

He knew that what they told him was likely incomplete or wrong, so he kept pulling them into rooms and making them make decisions. When we worked together, I understood why the first product owner had struggled. These were genuinely difficult stakeholders.

But the new product owner had something the first one didn't: he was willing to put the screws to them when necessary. The first guy was a people pleaser. Super nice, very personable. But in a product owner role, being nice isn't enough when the client won't engage.

That project didn't completely fail. But it did fail in what we wanted it to accomplish. We'd hoped to be the beginning of an ongoing technology partnership. Instead, the struggles of the project turned us into more of an ad-hoc consultant group. The dysfunction changed the nature of the relationship.

The One Thing I Watch For Now

When I start a new project, I do not want to talk about technology until we completely understand the actual problem we're trying to solve.

When you start talking technology first, you end up with a solution in search of a problem. That's backwards.

The customer only knows they're in pain. They have a feeling of dissatisfaction. Maybe they're really smart and really self-aware, and maybe they've correctly diagnosed what's causing the pain. But I'm still going to do the tests.

It's like going to the doctor. You tell the doctor your side hurts, you think it's a kidney stone. The doctor doesn't just schedule you for the procedure. He runs tests. He gathers information. He confirms whether your understanding of the pain matches the reality of what's causing it.

Customers think they know what they want. They usually don't. That's not an insult. It's just that they're often not the end users. They're higher up in the organization, speaking for people who do the actual work. Or they understand the strategic problem but not the tactical friction. Or they understand the tactical pain but can't see the strategic issue causing it.

What the conversation actually looks like: you start with whoever engaged you. You ask open-ended questions, get them talking about the problem. Then you ask: who does this day-to-day? Who's directly affected? Then you go talk to that person. Sometimes they're not the final person you need either. You recursively work down the chain until you reach the actual end user.

Then you roll it all up. You understand the problem from the end user's tactical point of view. The friction they feel, the data they copy-paste between systems, the manual work that eats their time. Then you understand how their manager sees it, how their manager's manager sees it. You get both the tactical and strategic view.

Then you can see where the right place to solve the problem is. Sometimes you just need to reduce tactical friction, automate data flow between systems. Sometimes you need to solve the strategic issue and the tactical problem disappears because you don't need that process anymore.

Sometimes you have to solve the tactical first to build trust, so they believe you understand what's going on. Then you can go solve the strategic issue.

What Failure Actually Looks Like

Projects rarely fail completely. They fail in degrees.

They fail when you get a month or two in and realize you didn't understand the problem space. Then you redo a bunch of work. Then you blow your timeline and your budget.

They fail when shared accountability becomes no accountability and nobody owns the hard conversations.

They fail when the product owner is too nice to make stakeholders uncomfortable, so you build based on incomplete information.

They fail when you reinvent solved problems instead of focusing on the problems only you can solve.

They fail when you start talking about technology before understanding what you're actually building.

The warning signs are always there. Excessive rework. Miscommunication that keeps happening. Stakeholders who won't engage. Teams where nobody owns anything. Early architecture decisions made without thinking through maintenance and complexity.

You just have to know what you're looking at.

I've been wrong about plenty of things. I've been wrong about details constantly. But in these situations, when I see these patterns and raise concerns, what I say is going to happen usually does happen. The trajectory is predictable.

The hard part isn't spotting the patterns. The hard part is getting people to act on them before the project is already off the rails.