Phases and milestones
The phase model forms the backbone of the project. It subdivides the life cycle of the project and creates the conditions for the project participants' common understanding of the course of the project. The HERMES phase model in Figure 16 consists of four phases:
The project starts with the initiation phase with the project initiation order milestone and ends with the end of the deployment phase with the project closure milestone.
The end of each phase is defined by a milestone which highlights the decision on how to proceed. These milestones correspond to quality gates where the project status and the quality of project planning and execution are checked. This also involves coordination with the overarching strategies and objectives of the core organization. The achievement of the milestones is checked with the checklist, which is supplemented with project-specific criteria. In addition to the milestones at the end of each phase, there are scenario-specific milestones as further quality gates, e.g. for architecture and security.
Throughout the phases and milestones, reporting is carried out according to the core organization's specifications with regard to content and frequency.
The phase model also forms a basis for the financial steering of the project. In the case of phase release, the resources (financial, personnel, infrastructure) are released by the project sponsor for the next phase.
The next section describes the phases and their respective focus.
Description of the phases
Phase model and requirements
The definition of requirements and system development are carried out throughout the phases.
The requirements are roughly worked out for the first time as part of the study in the initiation phase. They are fleshed out in the subsequent phases according to the principle "from rough to detailed".
Figure 17 provides a schematic view of the outcomes of the definition of requirements and system development for an IT system as the project unfolds.
During the initiation phase, the objectives are defined in the study and the requirements are worked out in sufficient detail for options to be developed and evaluated. The project order is created on the basis of the option selected.
In the concept phase, the rough requirements documented in the study are fleshed out and completed as system requirements. Project-specific solution concepts are designed in detailed studies. They form part of the system architecture. This describes the system with its processes, functionality, system components and their integration into the system environment via interfaces.
Based on the system architecture, the detailed specifications are created and the system is developed according to those. This also includes testing as a prerequisite for the decision on preliminary acceptance.
In the deployment phase, the system is activated and then the decision on acceptance is made.
The specification and implementation of the IT system can be flexibly steered with the agile development module.
This process also applies in a similar way to service/product development.
Decision-making process in general
Decisions have to be made when carrying out projects. Decisions are defined as tasks in the modules. Tasks that lead to a decision end with a milestone.
HERMES distinguishes between decisions made at the steering level and decisions made by the project management and specialists. For example, phase release is carried out by the project sponsor (steering), while acceptance of the system architecture is carried out by someone responsible for the architecture (compliance specialist in the core organization).
At the end of a phase, steering checks whether the necessary specialist decisions have been made. If this is not the case, the next phase is not released. Consequently, steering never makes any decisions for which it lacks the necessary expertise.
The decision-making tasks in HERMES and the decision-making processes are supported by the checklist.
Figure 18 shows as an example the decisions made at the steering level and at the management and execution level in the customized IT application scenario.
At the steering hierarchy level, decisions are made by the project sponsor, who decides on project release, phase releases and project closure. If necessary, he is supported by other roles such as the steering committee, which provide guidance.
Project release decision
Project release takes place at the end of the initiation phase. The decision is made jointly by the project sponsor and the core organization within the framework of project portfolio management.
It is decided if
the initiation phase is completed or whether further outcomes need to be achieved
the project is to be released
the project is not to be released for the time being and is to be requested again at a later date
the project is not to be released and is terminated
Phase release decision
For each phase release, the objectives of the project are coordinated with the organization's strategies and specifications, and the project's objective orientation and economic efficiency are checked.
It is decided if
the phase is completed or whether further outcomes need to be achieved before the phase can be completed
the next phase is to be released
the project is to be terminated
At the end of the phase, the project sponsor checks whether the necessary acceptance of the outcomes has been provided by the controlling and compliance bodies and technical specialists, and whether the outcomes of the phase meet his expectations.
Figure 19 shows a typical decision-making process using the example of the release of the implementation phase.
Figure 19 also shows that the phase report is accepted at the steering hierarchy level and the concept phase is completed. Prior to this, the project outcomes are aligned with and checked by the controlling and compliance bodies at the management and execution hierarchy level. If the prerequisites are met, the project sponsor releases the implementation phase.
Project closure decision
At the end of the deployment phase, the project sponsor makes the decision to close the project.
It is decided if
the project is completed or whether further outcomes need to be achieved before the project can be closed
the project organization is to be dissolved
Management and execution decisions
Decisions on project outcomes
The review and acceptance of technical outcomes are carried out at the management and execution level, i.e. by the respective specialists for the corresponding topic.
The project manager plans the decision-making tasks, taking into account the specifications of the controlling and compliance bodies of the core organization.