Another important point in the implementation of IT projects is the handling of change requests during the ongoing project phase. In recent years, I have not seen a project where the project owner did not completely remove or significantly adjust requirements that had been discussed multiple times. Depending on which dependencies exist and how individual components of the project are structured (database, backend, frontend), this can lead to extensive distortions. Generally speaking – the more dependency there is between components and building blocks of a project, the more likely planning changes can involve a lot of effort. A lot of effort is then usually associated with a lot of expense or nerve-racking discussions that are rarely goal-oriented.
The result is that the developers either get (significantly) more money and the project budget is exceeded (if this is financially possible at all), the developers fold and are completely demotivated for the rest of the project, or the project fails and, in the worst case, a legal dispute arises, the outcome of which no one can foresee. The ancillary costs alone for experts and the like can quickly exceed the actual project budget. Therefore, it is always advisable for both parties to come to an amicable agreement. But how should you actually handle changes to requirements now?
In many situations in life, perfectionism can be a useful trait. In IT projects, it’s a good guide to drift into insolvency as easily as possible. It is important to know that each additional feature and customization, even if you seem small, can entail extensive work. For example, as a client, I want users to be able to see local events in a local app for cities. Not a wild thing in itself, but what is actually the consequence of this?
If you think about it more carefully and have a technical overview, you will quickly come up with a lot of points that are connected to such a simple function. In this example, it is still possible to include the function independently of other parts of the app. If you now imagine that existing components still have to be rewritten, you can quickly spend over a month of development time on such a feature. This goes hand in hand with a later launch, possibly broken agreements, more costs and much more.
Now you should consider very well whether you really need this function here and now right now for the first launch of the app or whether the users can live well without it for now and can be happy about an extension of the app later.
The magic word here is MVP (minimal viable product) – as long as you are not blessed with extensive resources to maintain a team of developers over a long period of time without concerns, but are dependent on income from the project or investors. You should always think about where you can streamline, what features are really needed at the current time, and what impact a change will have on the course of the project.
Software architecture is the point where, in my experience, savings are most likely to be made, and with fatal consequences. I can set up a project sloppily without the user even noticing. That’s why the same project can be realized for 10.000€ and for 30.000€ and the 30.000€ is not an overpriced price, it’s just because you take enough time to make it reasonable.
However, since the client cannot see or touch this and this often results in phases in which nothing new that is directly visually recognizable can be presented, savings are often made here. Often because the client simply has no understanding of the consequences and differences, because he lacks the technical know-how. One cannot reproach him for this at all. The result, however, is that serious problems arise at the latest when complex errors occur, new functions are added that were not even considered at the beginning, or changes are made to existing functionalities. You usually can’t get a handle on them unless you restart the whole project. One could say: Better an end with horror than horror without an end.
However, the client usually makes the decision to patch up the broken sofa for years and keep it together instead of buying a new one. This happens and causes significant financial expenditures that could be more wisely invested, and almost always has a negative impact on the schedule. You become sluggish and expensive. Such projects are commonplace, especially in large corporations.
If you want to learn how to avoid catastrophic mistakes in your IT projects, get our free whitepaper with proven best practice solutions . With regular content that makes your day-to-day project work easier.
Do you want to work with us to bring the potential in your data to life? Then we should talk!
Concrete figures for costs , ROI, scope and duration for the use of AI and data science.
In the chemical industry, the development of new products is at the heart of technological progress. A key method in this area is Chemical Product
In the world of data analysis and big data management, Azure Synapse Analytics and Databricks are two prominent names. Both offer powerful tools for processing
The implementation of Databricks, a leading platform for big data analytics and artificial intelligence, is a crucial step for companies looking to improve their data
