How Badly Chosen Technology and the Lack of MVP Can Kill a Project

It would seem that a good choice of technology is the basis of a good project. It would also seem to be a simple choice. Nothing could be more wrong. Read on to see how you can go wrong and suffer from unnecessary costs through a lack of a proper and accurate analysis of business assumptions and MVP.

Poorly chosen technology leads to unnecessary costs

Let’s start with the fact that not all technology is suitable for every project. Suppose we want to integrate. We would have to choose the technology that works best for integration. On the other hand, if we want to write business logic, then the technology used for integration won’t necessarily be the same technology to use when implementing business logic. Of course, if you have access to specialists in a given framework, you can also benefit from their knowledge and experience. However, it is worth making sure they have experience in the technology they plan to write in.

Not unsurprisingly, there is no such thing as a universal technology that works for every system. Often, after some time you see that you have chosen the wrong solution. However, the further along the project is, the harder it is to stop and admit your mistake. Even when you realize the problem, and attempt to fix it, sometimes it just can’t be done when the technology is inadequate. The only option is to rewrite the code which would require another team of specialists to rewrite everything from scratch. And costs keep growing.

Hi, I need a needs analysis

When everything comes crashing down, there needs to be a scapegoat. Where did the disaster start? In all probability, the analysis of company needs was faulty or rather misinterpreted. We have already written on the importance of business analysis. The basis is to understand what the system is supposed to do. Whether we verified and discussed results of work with business on every step? Steps .. ? Did we have any steps? Did we prepare minimal value to verify with business periodically? Without defining these needs, the technology can’t be properly selected for the project. This leads to further errors, further rewriting, and of course – additional costs. The second guilty party is MVP, more specifically – the lack of it.

Don’t we already know everything about MVP?

Yes and no. What’s the point of knowing it all if you don’t put that knowledge into practice? We are scared to release imperfect products and so we are constantly working on product perfection. Too much and for too long. We don’t allow ourselves to release a product that has a few errors.

Let’s let customers get a taste of what we thought about and worked on for so long. Only when we place the system into the hands of users can we develop it. Sometimes, thanks to feedback, we can choose a different direction a lot earlier than we could have expected.

MVP (Minimum Viable Product) does not mean that the product is inferior. It is more an attempt to balance the right amount of effort (and money) into a product that can deliver value and satisfaction to customers, without being perfect, which they will be ready to pay for.

Why can a lack of MVP kill a project?

MVP is an amazing thing. You provide little value, but you still provide it. You get feedback, you know where to go and what to leave. All the while, the company sees activity. They know that the developer team will regularly provide them something new every two weeks.

When you start to create a system, you have to stop and think about it. Use MVP – make sure the system works. Write the system with the knowledge that if necessary you can start over from scratch. Prepare for such a risk in advance. This planned risk costs less than the detection of a serious error at a later stage. It’s a way to monitor business logic. Try out a few cases and check if the system works as it should. If not – start from scratch.

MVP is also necessary for systems that already work, to which you add a new feature. It is worth noting that what the client got was based on what they asked for. Why not let the customer verify if the product is what they wanted? By receiving feedback, you can keep working. Agile is a feedback loop.

Why could a lack of MVP lead to the death of a project? When you write, improve and hide your project from the world for a long time, don’t be surprised that nobody is interested in it. At least not enough to pay for it.