Have you been part of a project that failed? Why do you think that happened?

One of the most frustrating experiences I've had as a software developer is to be part of a project that's doom to failure.

Some of the reasons for the failures I've witnessed are:

1. The business model of the software company doesn't allow for the flexibility needed to build the right software and have profit.
2. Lack of feedback from the real-world.

I think Reason 1 is most common when working with fixed quotes. What happens is that a client says he wants an app that does X, and the software company says it will cost Y$. But the truth is that the client doesn't know what X should do, with enough detail, to solve the problem they want to solve. This is perfectly normal since software development is a discovery process, and therefore we'll never know all we'll need before starting. The result is a quote that soon enough stops making sense, but that bounded both parties to building something useless. This creates a rigid environment that makes changing the course of a project so it can be useful and feasible extremely hard, since changing scope has financial implications. The renegotiations tend to drag so much and be so hostile that the project gets canceled.

I've seen reason 2 happen when there's a lack of feedback from the end-user of the app. In situations like this, the client is not the end-user but assumes the role. The problem is that the client can't faithfully represent the user and doesn't communicate with him/her nearly enough. The result is building something that isn't useful to the user, or the client gets analysis paralysis and can't decide on what needs to be developed. Either way, the budget runs out before something useful is ever produced.

Have you been in a project that failed? Why do you think it failed?

Comments

[Hoshi Holiday]

That's a very useful insight. If what is demanded is arbitrary, we work with realities, not the unspoken dreams in other's heads. I haven't experienced this to the same extent, but clarity is a crucial component to the creative process.

[Alain D'Ettorre]

People want feature F but they also decide they want it in time T and must cost less than C. All without asking any developer first.

[EDIT] Then they complain about developers not being able to do their job. And they change their mind about the feature too.

[João Forja 💭]

Yeh, a lack of communication between development and business is frustrating. Not even sure that separation should exist.

[Glenn Stovall]

I've worked on multiple projects where the main reason the project failed was the hesitance on the part of the stakeholders to launch earlier.

They built an idea in their head of what the initial launch would be, to the point where nothing could match those expectations. I was talking to a friend on my podcast the other day and he said it well: "the more time between when a project starts and when it goes live, the less chance it has of ever succeeding at all."

Instead of testing with users, getting feedback, and iterating, they want to get it right on the first try. Or they try to solve the whole problem at once. For example, a medical client wanted to re-build their backend service, add new tools their employees could use to manage data, and integrate it all with a customer-facing iPad app, and they didn't want to launch until all of them were done. Instead of trying to launch all of them once, we could have done one or more of the following:

• launch an iPad app that integrates with the current backend service.
• build a separate service to add new features for internal customers, instead of building them into a legacy application, we wanted to scrap.
• find a way to replace the backend service one piece at a time.

Instead, the project languished and eventually died. Money and energy ran out on the stakeholder's side.

[João Forja 💭]

"the more time between when a project starts and when it goes live, the less chance it has of ever succeeding at all." - So true. And unfortunately, it's tough to make a client understand that. Especially, as you said, when they want to build a monopoly and want to build it all at once.

[Peter Ellis]

Yes, and the reasons were varied, three that spring to mind are.

1. By the time we finished development, business priorities have changed, code was completed but never made it into production. (Annoying but understandable.)
2. We were forced to use inadequate tools for internal corporate political reasons. After several years(!) of the project not producing anything useful, the plug was mercifully pulled.
3. Constant reorganisations meant that the code asymptotically tended towards completion but never quite reached it due to the increasing overhead of handovers and new teams' tendency to rewrite everything to their personal taste.

[Deni]

I see your projects and raise this to a company.

The company realized its main project was failing and decided to take on a few projects requested by some clients. These project had some crazy deadlines giving them 3 months to finish (all of it in parallel and the last month was for testing).

9 out of 10 seniors voted against such deadlines but 1 hero unicorn voted for. Management decided to let the unicorn take the lead on these client projects. He was confident for a full month and then decided to leave the company (dat seniorship). The company never recovered after that stunt.

To be clear, the blame is on management, if most of your seniors tell you the deadlines are impossible to meet then listen to the majority vote.

[João Forja 💭]

Ouch! Just reading that hurt!

[spiritupbro]

for me it was lack of experience of myself and my team and maybe boringness come along the way when a project is so long and doesnt end and even doesnt make profit or if its a non profit project it doesnt make impact to the community