Turnaround Cases: Successful Strategies Against Project Chaos

Contents

It could be so beautiful: As a new team member, you turn to a software project, everyone knows what they have to do, the requirements are clear and understandable, and the team masters the technology (and not the other way around). If there are problems, dedicated roles take care of them and clear up the difficulties. The organization ensures that everyone can work in peace. In the end, one thing is certain: users or customers receive a product with real added value. That sounds too good to be true!

But isn't it often the case that as a new team member, you get involved in a software project, and not everyone knows what they have to do, and the requirements, as well as the technology, are unmanageable? You typically stand alone with the issues, customers, and users ultimately do not receive a product with added value, and the team only insufficiently achieves project goals.

Andreas Monschau

Andreas Monschau has been working as a senior IT consultant specializing in software architecture and development as well as team management at Haeger Consulting in Bonn for over 10 years and is currently working as a solution designer on customer projects. In addition to his project work, he also manages the company's extensive trainee program.

There are actually statistics like the Standish Group Chaos Report from the year 2020. The participants in the underlying surveys were predominantly IT executives from service providers in various industries such as banking, insurance, manufacturing, retail, healthcare, as well as public institutions at local, state, and federal levels. The report refers to the global market.

The figures indicate that 31 percent of all software projects are successful, meaning the projects stay within schedule, within budget, and ultimately deliver the aforementioned added value for users or customers. But what about the remaining 69 percent? Half of the projects have at least enormous problems of various kinds (including exceeding the budget), and 19 percent fail completely, meaning they do not come to a satisfactory conclusion and only incur costs.

This article focuses on precisely these projects, which belong to the 50 percent that have not yet completely failed, but are also not yet on the right track. In other words, turnaround cases that can be steered back in the right direction. And the right direction means: ultimately delivering a product with added value to the customers.

What factors lead to problems?

There are many factors that can lead to problems (not only) in software projects. In turnaround cases, one often encounters the following challenges, among others:

• Unclear Requirements: The customer is unable to articulate what they want, making requirements contradictory or unusable. Ever new special cases lead to the dreaded scope creep: the gradual expansion of the project scope, often without adjusting time, budget, or resources accordingly.
• Unrealistic Deadlines: Delivery dates for features are promised to customers without prior consultation with the development team. However, the team cannot deliver on time because there is too much to do. This leads to dissatisfaction, and in the long run, the quality of the software suffers, as the team constantly has to put out new fires on the side.
• Unstructured Agility: There is much talk of agile methods or agile transformations, but the implementation is frequently only half-hearted. Priorities change daily because one is working "agilely," and for the same reason, there is no long-term planning. Stakeholders begin to interfere in meetings and short-term planning because they feel they are losing control.
• Uncontrolled Escalating Technical Debt: For reasons of time, something is implemented quickly, and "we'll improve it later" is the mantra within the project. The number of workarounds and quick fixes increases, and at some point, developers spend more time cursing the code and the project than implementing new features. They are afraid of this anyway, as any code change can have unforeseen consequences.
• Politics and Power Struggles: There are many project stakeholders who have a say, which often leads to long decision-making processes because no one wants to be responsible for supposedly wrong decisions. There are different, sometimes contradictory, requirements from management, and features are developed or blocked for political reasons.

This list can be extended indefinitely and is only intended to give a small impression of the problems that are regularly encountered. However, it is often the case that these problems initially hide and are only noticed by new employees after some time in the project.

Real problems from real projects

What does practice look like? Two exemplary turnaround cases serve to illustrate this. They show how colleagues from the author's company who were deployed there dealt with the prevailing issues.

A disclaimer beforehand: Similarities with "living or dead projects" are purely coincidental – no one should be able to recognize themselves in any of the projects, content, and industries are disguised, some parts are exaggerated, others simplified. However, the underlying problems correspond to reality.

Buy, buy, buy – E-commerce

The first example leads into the e-commerce sector. The content concerns identity management. Basically, the SSO (Single Sign-on) functionality of Keycloak, an open-source software for Identity and Access Management (IAM), is to be enhanced with additional services. As a special bonus: the project is to start on a so-called green field – seemingly a stroke of luck for the colleague who acts as lead developer and is promised a new team. However, in this turnaround case, the problems became clearly apparent shortly after starting the project:

The promised development team consisted of three employees who, although from IT-savvy backgrounds, did not have a classic developer education. In fact, they were more or less hobby programmers who had never developed Java software before, and Java was the chosen language.

These three had already started implementing something, but it was unusable – both in terms of design and concrete code quality. Furthermore, the requirements turned out to be completely unclear. Different subject-matter experts provided different statements, which often even contradicted each other. Detailed knowledge of processes and use cases did not exist.

In the project, there was no one to take the few existing requirements and prepare and prioritize them for development – in agile projects, this would be a Product Owner.

Thus, the development team could initially only work based on the few known requirements, and when the current status was shown to the subject-matter experts, it often led to the development team having to go back to the code because (previously unknown) special cases were not considered.

Finally, there was no process model and no real project management. There was only the development team with a lead developer and some employees involved in the project who occasionally made statements about the requirements. Independently of this, there was of course management that wanted to see results but could not understand why the development team was not working properly.