Where do the biggest challenges and difficulties currently lie in the implementation of HERMES 2022?

What has emerged more and more in terms of trends is the agile way of working. This already existed in the past, it was just called something else. What I mean by that is this: "We don't have a fixed plan where we know exactly that A has to be done first, B then builds on it, and so on." Today, that's often not very palpable. Most project management frameworks, on the other hand, are relatively rigid compared to what can be planned in advance. This rigidity, on the one hand, and today's prevailing style of development, on the other, no longer fit together. This, in combination with the persistent myth that a project management framework must always be applied one-to-one, creates a field of tension, but that is not at all necessary. You can - and should - adapt the roles and the scope of documentation to the project's specific needs.

What will also be the big challenge for HERMES 2022 in practice is the fact that development teams in Agile work independently. This means that there is a project goal that is known and is to be achieved, for example the implementation of software. However, the path to this goal is not known and is determined by the project team iteratively or just agile from sprint to sprint. As a general rule, a sprint lasts four weeks. The development team independently determines what it can achieve within this interval, which brings the project one step closer to the final goal. In other words, it defines an interim goal. However, this goal can only be achieved if the team can work continuously on it during these four weeks. In reality, however, team members are usually working on several projects at the same time and also have their daily business. The line organization that prevails in most organizations usually only supports the efficiency of projects to a limited extent, for example by superiors making additional demands, setting other priorities – or, quite classically, by vacations only being coordinated with the superior and not with the project team. In order for the theory to really work in practice, a matrix organization would be needed, as well as composed teams that really work in a focused manner on only one or at most two projects.

Another challenge is that product owners from Scrum or user representatives (German: Anwendervertreter) from HERMES are not necessarily trained in their role. In their function, they are responsible for channeling the complete backlog of specified requirements so that the development team can work on the interim results in a structured manner. However, regulations often play a role, especially in public administration, or, as mentioned earlier, the line organization. However, the product owner does not have an overall view, i.e., he primarily has an eye on the respective sprints, not the entire project. What happens politically around it is also not the responsibility of the product owner according to the role definition. Theoretically, the Scrum Master is responsible for keeping the team's back free so that it can work smoothly, but here too there is no responsibility for what happens in the organization at a higher level. HERMES 2022 has solved this problem well, in that the user representative has a hand over the development team, while the project manager keeps the higher-level view and takes care of exactly these (political) issues, but also considers regulatory aspects, dependencies, timelines and so on.

You've already touched on it. Theory dictates that the project manager must not interfere with the development team during the implementation phase because this is the responsibility of the user representative, who in turn reports to the project manager. How can this work in practice?

I can imagine that this works quite well if the profile of the user representative is sharpened and the roles and responsibilities are defined in the classic way at the beginning of the project, so that everyone really knows what is expected of them. Similarly to a setup with a project manager and a subproject manager, the user representative is then effectively the subproject manager for development with responsibility for results, who plans the use of resources and reports risks back to the project manager in good time. However, this requires that the project manager has confidence in the user representative and that the user representative really communicates everything that could be a problem for the project, and does so in a timely manner. In reality, however, many project managers find it immensely difficult to hand over responsibility because they bear the overall responsibility, although they should learn to do so anyway.

So this will be a challenge in implementation, but I actually believe that it is not so far-fetched, because the user representative understands much better from theory what the requirements of the users are and can communicate these directly to the development team. Another difficulty here, however, is that if the project manager is really strictly not allowed to intervene, the user representative must also have the necessary know-how, assertiveness and capacity to do so. In practice, this is not always the case and is often not required of this function in everyday work.

Your last project for a public administration was carried out in an agile manner according to HERMES. What did the project organization look like?

For transparency's sake: We carried out the project under HERMES 5.1, but chose a setup that actually corresponds exactly to what is also recommended under HERMES 2022. We used the classic framework for the initialization phase and the conceptual design, but carried out the implementation in an agile manner. In other words, we had a hybrid approach. From the beginning of the project, we knew our phases and the overarching timeframe. We knew what decisions we needed to make beforehand so that the project would go in the right direction or so that there would be enough time and budget. We documented these thought processes, conducted studies and the goals to be achieved accordingly. During the implementation, we held sprints every week and iteratively developed our application, evaluated these intermediate results and then started the next sprint based on them. As a result, we were always able to deliver something quickly, which is also an advantage of the agile way of working.

What would you like to share with those who are in the process of switching to HERMES 2022?

For one thing, not everything has to be done Agile. Just because the term is in everyone's mouth and you supposedly deliver results faster, that doesn't mean it makes sense for every project. Don't let yourself be pushed into something, instead always ask yourself which approach is the right one for your use case. This involves characteristics such as the complexity of the result, but also the speed at which interim results should be delivered. (More about the initiation phase and HERMES for projects of different sizes)

On the other hand, I would like to urge everyone to give it a try. I think - and this is also being confirmed by clients - that the new HERMES really does bring a lot of good approaches in which the real world is better incorporated than it has been up to now. I also think that you shouldn't be put off by the fact that a major change is now coming your way, where you initially think that the changeover could be complicated. That's usually the first prejudice you encounter with major innovations. However, you should never forget that a framework is not a default, but rather a guideline. That means: Take the best that is applicable for you in your everyday work and follow it. Then you will have gained a lot with the update to HERMES 2022.

Thank you for your time and this insightful glimpse into your project work.