How to fuck up a project in 2025

Here we go again.

It’s 2025, and the playbook to failure is more or less the same.

If someone does this for a bit, the signs are often similar. And if a meeting with all the staff is called on short notice to “discuss the past quarter”, in an environment that was not so great on overall communication, then it is pretty clear that something is going down. But let’s dial back to what is this about.

There are the base ingredients: an actual nice idea for a product. “Nice”, because it is not from a boring (at least for me) topic and it is a copy cat from an already existing, but not really scalable, product. So failure-points are already known, and we would have to do “only” reengineering.

The environment itself is a challenge: a pretty clear goal, not so clear technical roadmap. Resources are planned in, but not really available because of a mismanaging project management in other projects. The existing team worked officially in an “agile” process, but didn’t really use it. It was more or less an excuse for meetings.

The time goal was challenging. Not many people actually thought we could pull it off. As more time goes by, and promised resources were still not available, the doubt grown a bit.

But that was a reason i was asked to join. Because I do like product development. And i do not really care about roles in an company. Only the purpose and goals matter.

So we start to streamline the concept- and development process to. Implemented an actual scrum process only for that project.

Started creating and measuring stories to have an indication where we’re heading during the upcoming months. Having a monitoring to react to implications that were expected to happen.

And also having a more or less clear indication, based on facts, to say after a couple of months if our timed goals where archivable or not.

We modified existing development- and qa-process so that they match more a rapid-engineering approach instead of an very, very, very stable “already existing application”-approach.

We identified external technical risks and created strategies to handle them, so we could keep our performance without the risks that external services weren’t as fast as we are.

2 months in of preparations, planning, concepting, talking, and we were at a point that this company wasn’t before: we had an overview over the whole ecosystem, a technical concept strategy of the product and (mostly) everything that it touched.

And we had a clear, provable and scalable way to see where we are during the upcoming months. And if our milestones are archivable.

So we started to put together all the puzzles.

3 months in we reached a point where we assumed, based on our then known knowledge and the amount of work we already put in that we could archive our main goal probably in 2/3 of the time that was initially projected.

3 days later a meeting for the next day was called. And the project was cancelled.

Why was it cancelled? Well, as the exact same product will be done by another part of the company, some would say the fault is solely to find at the management of our part of the company.

Why? Because the product itself seems good enough to be done by “better” people. And it seems our management lacks the ability to sell products that are outside of our historically main core competence, to our stakeholders.

Also, fun fact. Another reason was, even with the originally projected timeline, we were too fast for our stakeholders.