Do not appreciate employees, underestimate complexity or rely on myths. If these and other factors are taken into account, your project is guaranteed to fail.
Do you know that? For weeks and months, the project manager reports on his project. Of course, the classic status lamps should not be missing. And this is constantly on the green: everything ok. But one day the traffic light suddenly changes to red! Consequently, a very unpleasant processing process begins for those responsible. Most of the time the first question applies to the culprit, the second the causes, and then one is only devoted to the possible solutions.
Below are 7 typical factors that almost guarantee failure.
Factor 1: disregard the human factor
In many years as a developer, project manager, coach, and crisis manager, I have found that interpersonal tensions are the greatest obstacle to implementing IT projects. Conversely, the chemistry between the employees is correct and there is an open, fault-tolerant climate, solutions can be found for all difficulties – even in critical situations.
It is in the nature of man to avoid conflicts. And so it is only natural if people (e.g. the project manager) completely ignore or look away for too long. But conflicts usually do not dissolve on their own. Research is required, as moderation and at least the perspective on change or solution.
Sometimes it is the little things that have a big impact, such as a new job for an employee. However, larger expenses are often necessary, such as the reorganization of teams, to bring peace to the project again. However, the worst alternative is disregarding the human factor.
Factor 2: Think too big or make too small
Some companies take over a project. They underestimate the complexity, the risks, and the immense personnel and material effort. Is – regardless of the costs – my organization even able to manage a project with 100 employees? Do we have enough jobs, meeting rooms, network capacity, development server, etc.?
Is the company able to meet the requirements of a large agile development team to a development and test track including Continuous Integration/Delivery? Predicted such questions, the business case should have been realistically calculated. I have seen several times that it only became clear shortly before the start of a gigantic project that the resulting system was actually not needed because it did not fit into the company’s business model. Unfortunately, nobody had noticed that before.
Another recognizable pattern: A protagonist absolutely wants to realize an SW, e.g. for prestige reasons or to utilize employees, and calculates the costs as negligible. If the later project manager is not strong enough to present the discrepancy in the context of decision-making bodies, this creates high crisis potential.
Factor 3: rely on estimates and planning 100%
A widespread myth is the reliability of estimates and planning. The concept of the project is defined by its uniqueness. Perhaps there were already similar projects, but in principle, a company is entering new territory with every project. This means that estimates can only be as good as the creators’ experiences and their adaptation skills regarding the current project.
However, plans can never include spontaneous events, changes in terms of requirements, technologies, or the entry of non-expected 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 system help to prevent or relieve possible crises.
Factor 4: The magical PM triangle consistently disregarded
Studied computer science, first semester, first lecture project management: “The magical PM triangle“. The person interested in management tasks is introduced to the laws of this triangle very early on. These say that the change in one of the three parameters inevitably leads to the consequences of at least one of the other parameters.
However, these laws are only too happy to ignore in practice. As already mentioned in the context of estimate and planning, a project is somewhat unique and the likelihood of unplanned influences is exceptionally high. That is why sooner or later it is necessary for almost every project that those responsible react to these influences. However, if all parameters are fixed, i.e. the customer continues to demand compliance with time, budget, and content, the failure is only a matter of time.
Factor 5: Documentation of everything
Free after Franz Beckenbauer: “We call it a classic!” Although more and more companies are relying on agile procedures (mostly scrum), organizations and projects are still being found, which give extensive documentation greater importance than the software to be created. This is a high risk, especially in large projects. Often, a hunt from consultants and department experts on thousands of pages have often worked for months or even years, which will later be translated by another team in SW.
The more extensive the documentation, the longer the realization time and the less likely it is that the SW corresponds to the actual requirements of the users. Reactions to changes in the market are not possible or only possible with great effort and temporal concessions. A document offers a basis against which the product can be removed. Unfortunately, what is written is not necessarily clear and the result is differently thought than originally thought. How many times have I heard the sentence from department staff and end users: “Oh, I imagined it very differently!”.
Factor 6: Just no balanced project organization
A team of 20 developers and 1 technical contact? There is no need for expert knowledge to recognize that this construct will fail sooner or later. At the beginning of a project, whether a waterfall or agile, it may still work because the developers are busy with frameworks or setting up the environments. But very soon the employees will ask questions – need intensive professional support.
A single subject expert can never withstand this temporal and emotional pressure and requires support, both in terms of personnel and through the implementation process. However, it is a very bad idea to counter the personnel bottleneck with the restriction of communication.
Also a popular idea and very front on the scale of the typical management errors: an employee collects the questions of the developers, discusses them with the technical contact person, and returns the answers. In this way, you create a bottleneck par excellence, trigger an extremely high error rate, and delayed the development significantly.
Factor 7: Heat the frog slowly
Do you know this story? If you put a frog in a saucepan with water and continuously heat it up to cooking, the frog does not attempt to escape. If you throw it directly into hot water, it jumps out immediately.
One of my most important knowledge of me in recent years is that employees of IT projects expire with increasing duration of increasing blindness. Once established processes are perhaps questioned in retrospectives, but rarely really being drastic. The ability of people to react to changes disappears in a proportional way to the duration of a project.
Therefore, sporadic lighting (Health Checks) is recommended by (huge) projects by an external, previously not involved consultant in order to discover the leak out, potentially non-targeted paths. At the latest after recognizing a full-blown crisis, it is almost impossible to create the turnaround with the existing staff alone.
So it can be possible
The typical management errors described are only a small selection of my personal hit list of behavior patterns, which prevent or even prevent the successful completion of SW development projects. From a distance, the impression could arise that it is easy to recognize the problems and correct them in the early stages of the projects. But supposedly immovable framework conditions and the blindness mentioned often make it difficult to make the right decisions. The statistics of the Standish Group said at the beginning demonstrate this year after year.
If a project is in trouble, it is strongly recommended that an external crisis manager can analyze and act objectively, free from sensitivities and without the ballast of project history. The only participation of an expert who listens to people in the project can already cause positive effects. The selection of suitable measures also succeeds in transformation and finally the turnaround.
