I guess we've all seen a horror project before. One where pretty much everything went wrong: the costs were too high, the features were full of bugs and the submission was way too late. In the end, everyone was dissatisfied: the client, the staff, and of course the project manager.
The inherent causes of this dissatisfaction also lie in the classic definition of SAP BI project success. The magic triangle of project management describes the parameters scope, costs and time. The closer we get to the end of the original planning, the more successful the project was.
However, this approach poses a major problem. It is assumed that the scope is known and fixed at the beginning of the project. In order to define the scope, the requirements are first recorded in detail and written down in specifications. Nevertheless, the requirements are never really complete. There are many reasons for this.
The business department simply cannot imagine what a solution should look like in the end. If the user interface is not defined clearly enough, at the end of the project the famous "But I imagined it differently" comes up.
So the business department is overwhelmed to formulate its wishes in requirements. On the one hand, critical functionalities are not mentioned at all. On the other hand, many optional "nice-to-have" functionalities are squeezed into the specifications. In the classic waterfall project management methodology, the department only has one possibility to express its wishes. In this way, it puts as much as possible into the waterfall. Often the requirements are only spongy.
If the author of the specifications does not have the necessary skills, does not hack into them and does not question the requirements, the disaster is complete. Often the requirements are also created by a management consultancy and the IT consultancy should then implement it. In doing so, you can actually kick it in the bucket and start anew. I have already had a requirement specification from a renowned management consultancy in my hands, which literally said "This problem must be solved somehow".
Often, the customer also does not want to pay for the preparation of a detailed specification and the associated phase for the inclusion of the requirements. This is how we begin to simply develop blindly from scratch. But if you don't know where you want to go, you shouldn't be surprised when you arrive somewhere else. This was already known in Mark Twain's day.
Moreover, software development is simply too complex to predict all eventualities down to the last detail from the outset. Many questions only become apparent during implementation. How should the software behave if case X or Y occurs? The answers to these questions may bring new requirements to the surface.
Once the requirements have been defined, the costs and time required are estimated. Apart from the fact that it is always just an appraisal, we always pretend that the budget is carved in stone. In reality, however, the actual expenditure usually deviates upwards. Then detailed project plans are drawn up, which are actually obsolete after the first day of the project. If changes occur during development, disputes arise. Because then either more project members are necessary to keep the deadline, or the deadline has to be postponed.
The project manager needs to block all changes and say no. "No, that's a change request," "No, that wasn't specified," and so on. In these trench warfare, the toughest project managers are worn down and the relationship with the customer suffers.
But if the project manager does not have the necessary assertiveness, the dreaded scope creep occurs. The scope grows more and more, while the budget and deadline remain the same. The lack of planning is carried out on the developers' backs. However, it turns out that sleepless nights during the death march don't exactly brighten the mood in the project team. The project members quickly resign - "we won't be able to do that anyway". In addition, errors creep in due to the revision.
Under time pressure and with endless overtime, some functionalities are completed. However, many features are deleted without replacement in order to be able to meet the (possibly several times) postponed deadline. Developer tests and documentation must also be postponed until, because the project must quickly enter the stability phase. But hey, postponing isn't over, right? After all, extensive testing takes place during the test phase. Since development took many months, there is also a lot to test, which makes a long test phase with many testers necessary.
And indeed, the first tests show that the features developed under time pressure don't work. The development begins to mend. Now and then crutches are built to make the software work. The fact that such solutions multiply the costs of maintenance in the future is either not considered or tacitly accepted.
It quickly turns out that some of the already finished functionalities still have considerable shortcomings. The progress of the project has always just existed on paper.
There is a dispute about every bug entered. The developers argue that everything behaves as specified. The testers disagree. Due to time pressure, the developer has implemented the specification as he understands it. Asking questions would only keep him from his work and put the project plan at risk. Often, however, the developer's understanding does not coincide with that of the author of the specification. And certainly not with the actual wishes of the customer.
Unfortunately, even when the requirements were recorded, often no one questioned whether the respective specification really made sense. Unavoidable misunderstandings come to light many months later.
Regrettably, some of the reported errors turn out to be conceptual problems. It's unfortunately much too late for a clean solution, because otherwise the already postponed deadline could not be kept. So more, larger, crutches will be built for making the individual components work together.
Such workarounds and troubleshooting take an unnecessary amount of time. The developers have already completed the respective functionality several months ago and now have to familiarize themselves with the details again. Unfortunately, there is no documentation that could help. This was postponed to "later" due to time pressure.
At the end the delivered application resembles a rag rug and the customer is still dissatisfied. He had to do without many features and the delivered features do not work as he had imagined.
And also the project team members are completely on the ground and close to burnout. They spend inhuman hours and have very few design options. Usually the project manager specifies which tasks the individual developer has to complete and how much time he has for this. This leads to a natural defensive attitude - "I'll never make it in five days". Since the estimation does not come from the developer himself, he does not feel obliged to keep to the schedule. However, if you had asked the developer himself, he would often have appreciated less. And would do anything to keep his promise.
It quickly turns out that some of the already finished functionalities still have considerable shortcomings. The progress of the project has always just existed on paper.
There is a dispute about every bug entered. The developers argue that everything behaves as specified. The testers disagree. Due to time pressure, the developer has implemented the specification as he understands it. Asking questions would only keep him from his work and put the project plan at risk. Often, however, the developer's understanding does not coincide with that of the author of the specification. And certainly not with the actual wishes of the customer.
In capacity planning, the tasks are sometimes randomly distributed to the employees. Especially when the project team is composed of different departments, the project manager simply does not yet know the strengths and preferences of individual departments. However, while one task is an atrocity for one person, another is happy to take it on.
What insights can we gain from the problems described? In classical project management, problems are discovered far too late. If we manage to make problems visible earlier, we can take better countermeasures. Because the problems will always occur.
There is no point in wasting your time creating unnecessary documents and detailed project plans to satisfy any process. Direct communication brings more and more clarity and avoids frustration.
Finally, we also need to empower project members to evolve from stupid recipients to independent project participants who are motivated to achieve the project goal.
In the next article I would like to show you some ways in which we can do this.
Picture sources:
Photo by energepic.com from Pexels, CC0 License
Photo by bruce mars from Pexels, CC0 License
Photo by rawpixel.com from Pexels, CC0 License
