Agile project management in the process industry

Dr. Eva Rosenbaum

 Senior Manager

learn more

"After losing sight of the goal, we doubled our efforts" - this is a feeling that almost all project managers are familiar with. In times of changing framework conditions and complex project environments, they desperately try to manage the balancing act between the framework conditions regarding quality, time and costs on the one hand and a project result that meets current requirements on the other hand.

For a while now, agile project management has been considered the answer to this challenge. The classical project management assumes to be able to define a clear goal at the beginning of a project and then to achieve this goal by means of detailed planning in a linear process. In contrast, agile project management sees time, costs AND the project result as variable variables that are increasingly narrowed down in the course of the project with the help of an iterative process.

In our experience, agile project management has become the industry standard in the IT sector and many projects in the process industry can also benefit from agile project management. However, agile project management is not the panacea it is often portrayed as. On the one hand, there are certainly project types that can be handled excellently with classic project management. In these cases - most construction projects are mentioned here as an example - there is no reason to change the project management: If it ain't broke, don't fix it. On the other hand, the scope of introducing agile project management goes far beyond a simple change of the project management tool. Behind the agile principles are some almost ideological basic assumptions.

Agil project management with scrum


The following basic assumptions should be discussed and actively affirmed in the organization before implementation, so that agile project management can develop its full potential:

  • Employees want to do good work of their own accord and are motivated if they are given freedom, responsibility for their work and are challenged. In agile project management, this is reflected in work in autonomous, self-determined teams that organize their work independently during a sprint, make decisions and solve problems. In addition to the demands placed on the individual team members, managers are also required to trust the team and give it room to work. Micro management is not compatible with Agil.
  • The primary task of management is not to tell employees in detail what they have to do and then control this, but to create the conditions for them to do a good job. An agile project team that works well needs management above all to remove obstacles (impediments) that cannot be solved within the team.
  • Normally, the desired result cannot yet be precisely defined at the beginning of the project. Therefore, changes should in no way be regarded as annoyances that could have been avoided with better planning or by more competent staff. On the contrary, a continuous incorporation of new requirements or the adaptation of existing requirements is firmly anchored in the core of the agile approach and ensures that the result brings maximum added value for the customer.
  • Mistakes, misunderstandings and wrong decisions happen. It is important to recognise them as quickly as possible, to correct them and to learn from them. The iterative procedure helps to make undesirable developments visible at an early stage. At the same time, an atmosphere of openness and trust is essential, in which all those involved can discuss even difficult situations without being put on the defensive or under pressure to justify themselves. When using Scrum it is the primary task of the Scrum Master to create this atmosphere. However, even the best Scrum Master will fail in this task if he does not receive support from the management.

Furthermore, there are some challenges in the transfer from software development to the process industry and its questions.

In a conventional large-scale corporation, the clash between a hierarchical and work-sharing line organization and agile project teams is pre-programmed.

  • Classical hierarchies offer security for employees: Employees who have consciously decided to work in a group because of this security or who have become accustomed to this security over the course of time feel overwhelmed by the independent work or shy away from responsibility.
  • The demands on management/hierarchy are changing: just like employees, managers can be overwhelmed by the new demands or perceive their new role as a loss of power and status.
  • A completely self-sufficient project team is difficult to implement, interfaces to special units remain (specialist units, construction, analytics, etc.): cooperation across these interfaces is a constant challenge for both the agile project team and the special units. Controlling these interfaces becomes a regular task for the management.
  • Finding a suitable product owner is critical to success and difficult: the end customer often is very far away from the project team (organization based on division of labor, B2B, ...). Persons within the organization who can meet the requirements of the Product Owner are often so high up in the hierarchy that it is not possible for them to fill the role within the time available.

The decisive challenge when implementing agile approaches is therefore always to ensure that the agile setup can be adapted to the conditions of the large corporation.

One success factor is not trying to transfer the perfect world from the teachings of an agile guru one-to-one, but adapting the agile methods - radically if necessary. This adaptation is not trivial, because it must always be based on the needs and challenges of the project, without submitting to the conveniences of the existing organization and corporate culture. On the one hand, this adaptation requires a good understanding of the basic idea of agile working, which goes beyond the knowledge of individual tools, and on the other hand, it requires a departure from the idea that the agile setup is ever "ready". Just like working towards the project goal, setting up an agile work mode is an iterative process that reacts constructively to changes in requirements and conditions.

The introduction of agile project management is therefore a change project, which in terms of effort and complexity goes beyond the training of a new tool.

Insight: Development projects in the process industry
When implementing agile project management for development projects in the process industry, an additional challenge is that there are points of no return from which project decisions can only be reversed at high cost, such as ordering large quantities of material. This fundamentally distinguishes these projects from software development where every line of code can be adapted at any stage of the project. To take this requirement into account, we have had good experience with two-day decision workshops. The goal of the workshop is to thoroughly review a decision that represents a point of no return and to obtain the commitment of all stakeholders to the decision. In addition to all members of the project team, the Product Owner, together with other representatives of customers / users, important decision makers in the organization and, if necessary, experts for similar issues who do not belong to the project team should participate. On the first day of the workshop, the project team will present the options for the decision without evaluation and what experience they have gained in the course of the project regarding the options. On the second day, the participants jointly evaluate the options on the basis of prepared criteria such as investment, costs in ongoing operations, reliability, flexibility, etc. Through the joint discussion, a common preferred option almost always emerges. In the event of difficulties in the further course of the project, this procedure results in much less friction due to blame. If it is not possible to agree on an option in the workshop, this is a clear sign that not enough information is available to make the decision. In this case the decision workshop will result in new tasks for the project backlog.