Do you know that? The project manager reports on his project for weeks and months. Of course, the classic status light should not be missing. And this stands up constantly Green: everything OK. But one day the traffic light changes suddenly Red! Consequently, a very unpleasant reappraisal process begins for those responsible. Most of the time, the first question is about the guilty, the second about the causes, and only then is one devoted to the possible solutions.
Using the statistics from the Standish Group from 2015, this is exactly the scenario that occurs every day in the conference rooms of IT operations around the world. Because just 29% of all software development projects are successful, the rest fail completely (19%) or only went live with restrictions (52%). More than 2/3 of all projects do not achieve their planned goal: diverse optimization options!
Below are 7 typical factors that almost guarantee failure.
In many years as a developer, project manager, coach and crisis manager, I have found that interpersonal tensions are the biggest obstacle in the implementation of IT projects. Conversely, if the chemistry between the employees is right and there is an open, fault-tolerant climate, solutions can be found for all difficulties – even in critical situations.
It is human nature to avoid conflict. And so it is only natural if people implicitly or explicitly responsible for personnel management (e.g. the project manager) completely ignore bad moods or look away for too long. But conflicts usually don’t resolve on their own. Research into the causes, moderation and at least the perspective of change or solution are required.
Sometimes it’s the little things that make a big impact, like a new job for an employee. However, larger efforts are often necessary, e.g. the reorganization of teams to bring the project back to calm. The worst alternative, however, is disregard for the human factor. 1st place.
Some companies undertake with a project. They underestimate the complexity, the risks and the immense human and material effort. Regardless of the costs, is my organization able to manage a project with 100 employees? Do we have enough workplaces, meeting rooms, network capacity, development servers etc.?
Is the company able to meet the requirements of a large agile development team on a development and test track including continuous integration / delivery? The business case should have been calculated realistically before such questions. I have seen it several times that it was only shortly before the start of a gigantic project that it became clear that the resulting system was actually not needed because it did not fit into the company’s business model. Unfortunately, nobody had noticed this before.
Another recognizable pattern: a protagonist absolutely wants the realization of a software, e.g. for reasons of prestige or to utilize employees, and calculates the costs small. If the future project manager is not strong enough to present the discrepancy within the framework of decision-making bodies, this leads to high potential for crises. Place 2.
A widespread myth is the reliability of estimates and planning. The concept of the project is defined by its uniqueness. Perhaps there have already been similar projects, but a company is basically breaking new ground with every project. This means that estimates can only ever be as good as the experience of the creators and their adaptability with regard to the current project.
However, plans can never include spontaneous events, changes in requirements, technologies, or the occurrence of unexpected risks. Ultimately, estimates and the plans based on them are nothing more than a bet on the future! Accepting this fact is a first step forward. Discipline, courage and systematic help prevent or alleviate possible crises. Place 3.
Studied computer science, first semester, first lecture on project management: “The magic PM triangle”. Those interested in management tasks are introduced to the laws of this triangle at a very early stage. These state that changing one of the three parameters time, budget or content (quality) inevitably leads to consequences for at least one of the other parameters.
In practice, however, these laws are only too happy to be ignored. As already mentioned in the context of estimation and planning, a project is something unique and the probability of unplanned influences is extremely high. Therefore, sooner or later it is necessary in almost every project for those responsible to react to these influences. However, are all parameters fixed, i.e. the customer continues to demand compliance with time, budget and content; failure is only a matter of time. 4th place.
According to Franz Beckenbauer: “We call it a classic!” Although more and more companies rely on agile procedures (mostly Scrum), organizations and projects can still be found that give extensive documentation greater importance than the software to be created. This is a high risk, especially in large projects. Often, a host of consultants and departmental experts work for months or even years on thousands of pages of descriptions that are later translated into SW by another team.
The more extensive the documentation, the longer the implementation time and the less likely it is that the software will meet the actual requirements of the user. Reactions to changes in the market are not possible or only possible with great effort and time concessions. A document offers a basis against which the product can be accepted. Unfortunately, what is written is not necessarily clear and the result is different than originally thought. How often have I heard the phrase from department employees and end users: “Oh, I imagined it to be very different!”. 5th place.