Agile project management in R&D
Agile principles are currently in vogue. Quintessentially, they represent a transfer of lean management methods – known from the operations context – to explorative activities. Agile principles were first employed in software engineering. In several projects in the chemical industry, 3con has gathered experience with agile works.
The organisation of large development units as a competence organisation in the process industry has many advantages but also clear disadvantages. Agile project management offers approaches to address some of these disadvantages. An implementation oriented towards individual methods such as Scrum can achieve short-term successes, but the fundamental challenges based on organization and culture remain and limit the effectiveness of agile methods. A successful long-term orientation of project teams towards customer and market requirements, greater agility and improved control of innovation requires the anchoring of the customer perspective both in the organizational setup and in the project team's approach.
Large research and development departments in the chemical industry are classically set up as competence organizations. In other words, small specialist units are staffed by specialists who usually work on several projects at the same time. One of the project participants also assumes the role of project manager.
Each project team works largely independently within the framework of an agreed project and budget plan; feedback to the business units usually takes place only at large intervals. The business units often delegate the support of the R&D teams to their own technology unit.
This work organization and working method has various side effects:
- Transparent and resilient resource management is difficult for the project manager, as each project only looks at proportionate resources and there is no clarity as to what other obligations the respective employees have towards other projects.
- The research work as a chain of scientific questions growing out of itself leads to detours and wastage of time and resources, because due to a lack of orientation towards intermediate results and milestones in the sense of completed "packages", dead ends and side construction sites are recognized too late as such and also unnecessarily increase the complexity of the project.
- Beyond budget and project planning, there is no regular discussion of objectives, project setup and resources motivated by market events and interim results; undesirable developments or expensive "overdevelopment" are recognized too late, distressed projects are terminated too late.
- Resource and goal conflicts within the project teams that arise due to the different organizational allocation can hardly be resolved, since there is no common reporting path for a quick escalation and decision.
- In the context described, it is difficult to adequately involve senior management as decision-makers for important decisions. Steering groups are often characterised by too much detailed discussion of technical issues and information about work results. This leads to frustration and loss of trust in project managers and middle management in view of the fact that time and budget plans are regularly significantly exceeded.
Against this background, agile project management is increasingly coming into the focus of R&D units in the process industry. However, such initiatives are often only focused on the relatively simple introduction of methods (e.g. Scrum) and tools (e.g. Kanban boards or supporting software). Fundamental challenges for agile work in a highly specialized competence organization remain and, in our experience, limit the chances of success of an effective and sustainable introduction of agile elements.
From our point of view, there are four success factors to make the environment of research projects and the actual work of the project team much more agile. By agile we mean here: Market and result orientation, more effective and faster-reacting project management as well as improved division of tasks between work teams and management.
Winning the customer as a driver of change
In order to achieve a willingness to change among the project teams and the respective superiors in the R&D departments, it is necessary to win over the customer (business unit) for a changed approach. In typical teams with the challenges described above, without a clear, demanding attitude on the part of the customer, the necessity and thus the justification for a fundamental change in the way employees and managers work is lacking.
Bundling the customer perspective and carrying it into the project
The market view has to be integrated into the project through a unit that is directly in the market and measured by economic results (e.g. marketing for new developments, operations for process optimisation). This needs to be achieved at the level of the steering committee as well as at the level of the working project team by means of a physically present demand carrier success. The latter bundles the sometimes very different perspectives within a business unit (e.g. purchasing, supply chain management, strategy, marketing, technology) and communicates them to the project team as orientation and framework conditions.
Demand thinking in packages
From a market and customer perspective, expected (interim) results must be formulated as a package to the work team. The team can then develop the activities necessary to achieve the goals in a work phase and organize its work accordingly (planning and prioritization of laboratory and analysis capacities, for example). These packages can be prioritised at regular intervals and compared with the objectives of the project, the market environment and the framework conditions. Similarly, a rigorous comparison of the upcoming packages with the overall project plan, time and budget planning from a market perspective may help to identify currently unattainable work packages and to streamline the project in this way (reduction of complexity, relief of the budget, time saving).
Adapt the project framework
Driven by the user, the framework of an R&D project is also repeatedly questioned and, if necessary, adapted: if the framework conditions change, the user has to implement a rapid adjustment of budget, resources and schedule at the level of the steering committee or in the management of the business unit and in the R&D unit.
The concrete design and adaptation of a procedure for introducing agile working methods and management approaches should of course be adapted to the individual circumstances.
If you like, we will be happy to discuss it with you.