Why SAP BI Projects Fail (Part 2/2)

In an earlier article, you learned what problems lurk in classical SAP BI project management. In this article I would like to show you ways how we can do better. We don't have to reinvent the wheel, but can orient ourselves on agile methods like Scrum.

We have found that classical approaches such as the magic triangle in the case of software development need to be questioned. With the classical approach, we assume that the scope of the project remains known and fixed. In reality this is not the case. The actual scope is only roughly outlined and is constantly changing.

Therefore agile project management methods like Scrum take a radically different approach. It is recognized that the scope is constantly changing. Therefore the costs and time are fixed, the scope is variable. As a result, the customer gets the best possible product with the given time and money resources.

An iterative approach is chosen. Instead of a big fat bang introduction after months of development, several, smaller, intermediate releases are made at each iteration. The time is also limited - after a maximum of four weeks a working feature has to be delivered. This prevents the development from being protracted indefinitely.

After each release, the developed features are presented to the customer. In this way we receive immediate feedback from the customer. Often the customer can only get an idea of a feature if he can actually see and touch it. He also gets ideas for new features that make the entire application simpler and more user-friendly.

The frequent intermediate releases thus ensure that we do not develop without the customer's actual requirements in mind. It is determined early on whether changes to the original requirements are necessary. General assumptions about the solution are also checked. I heard about applications that had to be written off as total loss after six months of development. With the iterative approach, undesirable developments would be noticed after just a few weeks. Thanks to the early feedback, we can take appropriate countermeasures at an early stage.

The customer is involved in the development process and takes the lead. He has the choice of whether a certain functionality should be retained or newly developed. In the latter case, the customer has the choice of foregoing other features in order to meet the delivery date, or to increase the project duration and thus also the costs. In the end, however, a tailor-made solution is created that is actually used and not boycotted by users.

With the traditional waterfall approach, the customer usually does not get what he expects. They are not allowed to try the product until the end of the project, after months of development and testing. At this point it is usually already too late to make any changes. The customer is dissatisfied and the users know nothing to do with the solution.

All activities are completed within each iteration: Development, testing and documentation. We remember - with the waterfall model, the tests are only carried out at the end of the development phase. However, in order to identify conceptual problems and possible deviations between expectations at an early stage, we have to carry out the tests earlier.

In Scrum each feature is tested directly after development. The early detection of errors makes it possible to eliminate conceptual problems right from the start. Any corrections are also easier, since the developer still knows all the details. This saves the need to re-introduce the code, which was created a long time ago. In addition, there is no need for excessive documentation, since the transfer to the tester takes place promptly and personally.

Continuous testing means that a long test phase is no longer necessary at the end of the project. However, you should still schedule a short phase for system integration, load, and performance tests. All in all, this increases the quality of the delivered software.

The successfully tested features can be regarded as actually finished. Accompanying documentation avoids technical debts. Progress is therefore not only made on paper and we get a much more accurate overview of the status of the project.

Through short iterations, continuous milestones are defined. The team does everything in its power to achieve the goal set for the next iteration. And if you overdo it and don't reach the goal, it's no big deal. One learns through mistakes. And the Scrum methodology forces you to reflect on your mistakes at most every four weeks. Thus the project plan always remains realistic and the death march at the end of a project is avoided.

Overall, the satisfaction (and thus the performance) of the employees also increases. Instead of stupid task recipients, Scrum relies on self-determined, self-reliant employees. While in classical project management the project manager distributes the tasks, in agile projects a pool of tasks is provided. From this pool, the employees are then allowed to help themselves.

So the employees can play out their strengths and preferences. This accelerates the processing of tasks and increases motivation. In addition, possible conflicts with unpleasant tasks are defused. In addition to the independent distribution of tasks, the team also estimates the time required. And if the employees themselves appreciate the effort, they also feel responsible for adhering to it.

I think these are all powerful arguments to consider agile methods like Scrum. Have you already tried Scrum in your projects or are you thinking about it? Share your experiences in the comments.

Images:
Photo by bruce mars from Pexels, CC0 License
Photo by rawpixel.com from Pexels, CC0 License