Change Management – The 5 biggest mistakes in IT projects and how decision makers can avoid them

Avoiding 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 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?

Avoid perfectionism

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?

  • Extension and adaptation of the database. It may be necessary to adjust existing tables, which entails further adjustment in functions completely independent of the task.
  • The designer for the project needs to be brought in to figure out how best to represent the feature. Consultation and consultation between developer, designer and client necessary.
  • Implementation of the design in the frontend on code level (responsiveness / usability of the components)
  • Implementation of logic (inclusion of text, title, image, adjustment of image size, correct display and calculation of visual representation for participants, rating, etc.).
  • Creation of a backend in which events can be deleted, edited and created (Three completely new and independent functions)
  • Interfaces 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 user to accept / reject
  • Testing the functionality at different locations and with different scenarios
  • Possibly even integration into existing authorization concept in the management of events (which admin / backend user is allowed to do what)
  • Possible integration into a language system
  • Design customization for iOS and Android

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 in focus

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!

Your contact person:
Daniel Brokmeier
Mail: [email protected]
Direct line: 0160 979 60482
Linkedin: Daniel Brokmeier

Prizes, success stories and a deeper look behind the scenes can also be found in advance on Ailio.