Change Management – The 5 biggest mistakes in IT projects and how decision-makers can avoid them
Avoid mistakes through constructive change management
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 experienced a project where the project owner has not completely removed or significantly adjusted requirements that were discussed several times. Depending on what dependencies exist and how individual components of the project are structured (database, backend, frontend), this can lead to extensive disruptions. In general, the more dependency there is between components and building blocks of a project, the more likely it is that planning changes can involve a lot of effort. A lot of effort is usually associated with a lot of costs or nerve-wracking discussions that are rarely productive.
The result is that the developers either get (significantly) more money and the project budget is exceeded (if this is even financially possible), the developers give in and are completely demotivated for the rest of the project, or the project fails and, in the worst case, a legal dispute breaks out, the outcome of which no one can predict. The additional costs incurred for experts and the like can quickly even exceed the actual project budget. Therefore, it is always advisable for both parties to reach an amicable agreement. But how should you actually deal with changes to the requirements?
Avoid perfectionism
Perfectionism can be a useful trait in many situations in life. For IT projects, it is a good guide to help you avoid bankruptcy as easily as possible. The important thing to remember is that every additional feature and customization, even if it seems small, can involve 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 the consequence of it?
- Expansion and adaptation of the database. Existing tables may need to be adjusted, which entails further adjustment in functions that are completely independent of the task.
- The designer for the project needs to be consulted to consider how best to present the feature. Consultation and consultation between developer, designer and client is necessary.
- Implementation of the design in the frontend at code level (responsiveness / usability of the components)
- Implementation of the logic (inclusion of text, title, image, adjustment of image size, correct display and calculation of the visual representation for participants, evaluation, etc.)
- Creating a backend in which events can be deleted, edited and created (three completely new and independent functions)
- Interface connection to Facebook or other platforms to get current data
- Logic that prevents edited and deleted events from being overwritten again by the crawler that fetches the data from other platforms.
- Function for users to accept/reject
- Testing functionality in different places and with different scenarios
- Possibly even integration into the existing authorization concept in the management of events (which admin / backend user is allowed to do what)
- Possibly integration into a language system
- Adaptation of the theme for iOS and Android
If you think about it more closely and have a technical overview, you quickly come to a lot of points that are connected to such a simple function. In this example it is still possible to install the function independently of other parts of the app. If you now imagine that existing components still need to be rewritten, you can easily invest over a month of development time into such a feature. This is accompanied by a later launch, possibly broken agreements, more costs and much more.
Now you should think very carefully about whether you really need this function here and now, right from the first launch of the app, or whether the users can live well without it for the time being and can look forward to an expansion of the app later
The magic word here is MVP (minimal viable product) - unless you are blessed with extensive resources to maintain a multi-person development team over a long period of time without any concerns, but rather rely on income from the project or investors. You should always think about where things can be streamlined, which features are really necessary at the current time and what impact a change will have on the course of the project.
Software architecture in focus
In my experience, software architecture is the point at which 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 project, which is absolutely the same in terms of functionality, can be implemented for €10,000 and €30,000 and the €30,000 is not an overpriced price, but simply because you take enough time to do it sensibly.
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 they lack the technical know-how. You can't blame him for this at all. The result, however, is that serious problems arise at the latest when complex errors, new functions that were not even considered at the beginning or changes to existing functionalities occur. As a rule, you can't get this under control unless you restart the whole project. One could say: Better an end with horror than a horror without end.
However, the client usually makes the decision to patch up the broken sofa and keep it together for years instead of buying a new one. This happens and causes significant financial expenditure that could be better invested and almost always has a negative impact on the schedule. You become sluggish and expensive. Such projects are particularly common in large corporations.
If you would like to learn how you can avoid catastrophic** mistakes in your IT projects, then get free our white paper with proven best-practice solutions. With regular content that will make your day-to-day project life easier.
Daniel Brokmeier
Head of New Business Development
Would you like to work with us to bring the potential in your data to life? Then we should talk!
Use cases for the use of AI in industry, manufacturing and mechanical engineering
Concrete numbers for costs, ROI, scope and duration for the use of AI and data science.
continueHow do I recognize a good software service provider?
How digital pioneers scale AI - and why traditional industries are often more successful at sustainable operationalization
How digital pioneers scale AI - and why traditional industries are often further ahead As AI transformation accelerates, this is no longer an issue for many companies
Aleksander Fegel May 6, 2026
Digital pioneers in the AI race: Why scalable operationalization is still the key to success
AI in practice: Why digital pioneers still have some catching up to do when it comes to scalable AI. The integration of artificial intelligence into companies is one of the central challenges
Aleksander Fegel May 6, 2026
In plain language on AI scaling: Why traditional companies are ahead of digital natives when it comes to operationalization
Plain text on AI scaling: Why digital natives are ambitious, but traditional companies are ahead when it comes to operationalization Artificial intelligence (AI) and data science are far from a thing of the future
Aleksander Fegel May 6, 2026
German
English (English)