Agile project management in the process industry
"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.
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.