HERMES 5.1 for projects of different sizes
HERMES 5.1 for projects of different sizes
29. November 2022
HERMES 5.1 is a methodology for the management and execution of IT projects primarily in use in the Swiss federal administration. It is based on various scenarios which, depending on the size and characteristics of the respective project, combine the correspondingly necessary tasks and results in modules. But how do you choose the right scenario and set up an effective project structure? These are precisely the questions I will address in this article.
First things first: Before a project can be classified as large or small, this term must be concretized. A large project is not defined exclusively by the number of people in the project organization, but above all by the goals to be achieved, the associated results and necessary tasks, their risks, costs and the maturity of the respective content - keyword: complexity.
The background is easily explained: If you introduce a new tool in the organization, which is only intended for a specific team, the number of stakeholders and also the project organization (depending on the software and process) is manageable. Nevertheless, it requires a lot more documentation, planning and adaptation of the organization than updating an existing software. Conversely, a software update may require a large project organization, since various instances, customers and roles may be affected, but the scope of documentation, planning and controlling does not increase linearly.
This premise is the starting point for applying HERMES 5.1 to projects of different sizes.
Approach to the initialization of the project
The general procedure within HERMES 5.1 provides for the following steps during the initialization of a project:
1. Selection of scenario
2. Selection of modules with the thematically associated tasks, results and roles
3. Asignment of roles
4. Implementation of the project according to the selected scenario on the basis of the project order
After selecting the modules, I always add an intermediate step: the adaptation approach. Behind this is the sensible combination of the individual results, depending on the project size and complexity. This results in the Qudits approach:
Adaptation of the HERMES approach on the part of Qudits
In the following chapters, I will explain the recommended scopes of results and related documentation for projects of different sizes and show how they support efficiency, effectiveness and the achievement of the project goal. In addition, I will show how HERMES 5.1 can be well adapted to projects of different size and complexity and with different objectives by choosing the right scenario. On the other hand, I will not look at role assignment, since in my opinion this is well regulated in the HERMES 5.1 Reference Manual. I would like to emphasize two passages from it: "It takes into account the experience required in the project, the capacity required and the availability of the role holders" and "One person can perform several roles, provided that the role permits multiple occupation". This gives the project management the necessary leeway to design the role allocation and staffing efficiently and effectively.
Tailoring the scope of results to the project
The figure below shows the minimum results per module according to the HERMES 5.1 Reference Manual. Based on this list, it can be illustrated below where there is potential for increasing efficiency and effectiveness by combining results.
Minimum results per module according to HERMES 5.1 Reference Manual
The very first step in the process is a crucial point for effectively setting up the project - scenario selection. Due to the uncertainty as to which scenario is applicable, there is a tendency to assemble an individual scenario. The result is often that more results to be achieved are defined within the modules than would actually be necessary. This leads to losses in efficiency and effectiveness.
Let me use some practical examples from our projects to illustrate this and assign them to the respective standard scenario of HERMES 5.1:
Implementation of a canton-wide monitoring system
Project description: Canton-wide harmonization through the introduction of a standard software, which is largely known and contains many requirements as well as stakeholders, but the implementation can be done in the standard
Scenario: IT standard application
Introduction of digital workplaces
Project description: Provision of the infrastructure for the introduction of digital workplaces according to a uniform cantonal standard; the entire infrastructure is to be outsourced to a virtual work environment
Scenario: IT infrastructure
Digitalization of the application process
Project description: Digitalization of the application process of a new law, which is why it is not possible to access existing or known, in addition there is the individual development of the tool, where the requirements can only be clearly defined in the course of the project
Scenario: IT individual application agile
Once the scenario is defined, the number of modules and the deliverables required with them are also automatically better defined and project execution can be more efficient and effective as a result.
Next, I would like to focus on the results that should always be created, regardless of the project size/complexity. First of all: The project decisions control as well as management and execution are elementary in order to make the right decisions on the right level and are therefore not explained in the following. For the sake of simplicity, the minimum results are considered per phase.
Initialization
The project order represents the binding project basis and is the justification for the necessity of the project, additionally it provides the analysis of the initial situation.
The project initiation order is necessary for the project management to demonstrate that it understands the order and that it intends to carry it out as summarized.
Concept
The implementation concept is important to show how the organization or the process will look after the change. It describes the procedure for the change and the measures.
The system requirements, the product backlog or a process description lead to the respective implementation or procurement and is essential for the detailed definition.
Realization
The operation/user manual presents all information relevant to operation/application so that software, product or service can be used/operated effectively.
The acceptance protocol at the end of the realization ensures that all requirements have been covered before the implementation.
Implementation
The acceptance protocol ensures that everything has been implemented before the operational start-up (see also: Realization).
Phase-independent
The project management plan is the central deliverable. It maps the framework conditions and creates transparency about the timing, all activities and the associated results.
The change status list is often underestimated, especially for small projects, but changes can have a big impact on the framework and/or goal achievement, so they need to be evaluated and documented.
The project status reports are absolutely helpful in keeping all stakeholders updated and involved on a regular basis.
The phase reports are important results to review the project in each case with the objective, legal basis, economic viability, and further planning.
The project completion assessment serves as an instrument for the project management and organization to show what has been achieved, by what means, in what time, and whether the overall objective has been met. Alternatively, the result is equally important when a project has been stopped to show the reasons, criteria and deviations that have arisen in the project assignment.
These minimum results, critical in my experience, can be combined with additional results to scale to project size and complexity. Here are a few examples:
The stakeholder list could be integrated into the project management plan, as it contains, among other things, the communication plan, which should show how contact with various stakeholders is planned.
The studies for the protection requirements and legal basis analysis can already be included in the project initialization order and do not necessarily have to be prepared separately.
The implementation concept can also be combined with the business organization concept and the product concept. It should generally not only describe the steps for the introduction, but also provide a view of the result, so that this document can be expanded very well.
These are only a few approaches, but there are many possibilities that make HERMES 5.1 well applicable for projects of different sizes - with more or less results/documentation, respectively. The complexity aspect also comes into play at this point. Projects with a challenging goal need additional deliverables to build on each other or to further develop the project. Furthermore, these deliverables can support tracking and show in more detail what needs to be done to achieve the project goal.
From theory into practice
In the following, I would like to present the three above-mentioned projects, which we carry out according to HERMES 5.1, in a little more detail and give you an insight into why we have classified them accordingly. Let's start with the key data:
Implementation of a canton-wide monitoring system
Project organization: 6 persons
Complexity: Low (implementation takes place in the standard)
Size classification: Small
Introduction of digital workplaces
Project organization: 15 people
Complexity: Medium (requirements are known and can be planned well, but a large number of stakeholders and a large project organization are present)
Size classification: Medium
Digitalization of the application process
Project organization: 9 people
Complexity: High (no standard, requirements must be developed in an agile manner)
Size classification: Large
The scope of the HERMES 5.1 results varies in these projects according to the project size and the selected scenario. For example, the project "Implementation of a canton-wide monitoring system" contains only the results that are minimally relevant for us. The reason is that a standard software is introduced, which is already known to a large extent (the project also has a harmonization background) and the requirements to be implemented are many in number, as are the stakeholders, but the implementation can be done in the standard. Due to the lower complexity as well as the manageable project organization, the classification is made as a smaller project and the definition of the deliverables was reduced accordingly.
Based on this, the scope of the results for the medium as well as large project is expanded accordingly. The project "Digitalization of the application process" is highly complex, is classified as large and accordingly includes the largest number of deliverables. For example, a situation analysis, a detail specification, a supplier agreement or even prototype documentation must also be created. The scope of results and the complexity are due to the fact that the law whose application process is to be digitized is completely new. As a result, it is not possible to fall back on existing or known documentation. Added to this is the individual, agile development of the tool, where the requirements can only be clearly defined in the course of the project.
The "Introduction of digital workplaces" project deals overall with the provision of virtual workplaces, but in the sub-project relevant to us it relates primarily to the digitalization/automation of the ordering process and the provision of clients to the respective users. Accordingly, the non-digital process and thus the requirements are known, which is why the (sub)project is less complex than the " digitalization of the application process" described above. Furthermore, the tool for order processing is already available and only needs to be adapted. The project becomes complex primarily due to the necessary size of the project organization and the various instances, customers and roles involved. Accordingly, the planning effort does not increase linearly compared to the above-mentioned "Implementation of a canton-wide monitoring system", but the useful documentation and controlling scope increases here.
As these concrete examples show, HERMES 5.1 can be flexibly adapted to the complexity (size) in order to make sense of project execution. What is important here is the right combination of deliverables with the right mix of documentation and focus on the actual activities. However, there are opportunities and risks associated with any tailoring. To make the best use of the opportunities of tailoring, you need good preparation within the initialization, appropriate documentation of results and minimization of risks through transparent communication, empathy and knowledge transfer. This will ensure the sustainable success of your projects.
Author
Julia Heumos
Julia's consultancy focus lies on establishing effective organizations, developing high-performance teams and strengthening their results orientation. In doing so, she leads programs and projects to success and drives the digital transformation of her clients.
