Phases

Introduction

Project life cycle

With its phase model, the HERMES project management method supports both the traditional and the agile approach. The phase model for projects is based on the life cycle of the project. For all project participants, it creates the prerequisite for a common understanding of the project process. The phases determine the project structure.

Figure 12 shows the HERMES project life cycle.

Figure 12: HERMES project life cycle
Figure 12: HERMES project life cycle

The HERMES project life cycle is divided into project start, solution development, and project end:

  1. The project start is where the envisaged project is aligned with visions, needs, and objectives. Not infrequently, the focus is on both an urgent need for action as well as external influences (legislators, policymaking and politics, international agreements, association rules, etc.) or superordinate entities (core organization, program, or portfolio).
  2. The solution development according to the traditional or agile approach is carried out on the basis of the execution release.
  3. The project end concludes the current project in organizational and formal terms and prepares the transition to the application organization.

Project start

The initiation phase is always situated at the project start. Figure 13 shows the initiation process with the most important outcomes.

Figure 13: Outcome diagram of the initiation phase
Figure 13: Outcome diagram of the initiation phase

During initiation, the requisite project-specific foundations and the possible solution options are elaborated, compared, and evaluated. The choice of solution option includes the decision as to whether the development approach should be agile or traditional. This decision must be justified in terms of the subject matter and process and should not merely follow current trends. The proposed approach is derived from the premises available to the project and is shaped by the selected solution option.

Solution development

The solution development process differs depending on whether a traditional or agile approach is adopted. Most of the method components are almost identical under both approaches; what differs is the project organization and the structure of the project, and consequently the development process and ultimately also the specialist and formal content of the outcomes.

In agile development management, changes are a fundamental part of the development process. The development team follows the given and desired impact and proactively responds to changing requirements instead of following a fixed plan. Development and deployment are iterative and incremental. A phase structure does not make sense under this approach. For that reason, the execution phase cannot be further subdivided.

Depending on which approach is selected, the solution development of the project after execution release is either

  1. traditional
    with the phases of concept , implementation , and deployment , or
  2. agile
    solely with an execution phase

and then concluded with the closure phase, irrespective of the approach taken. * Hybrid approaches are discussed as a special case in Section 7.

The interfaces to the core organization remain largely the same, as do the documents required at project closure.

Project end

The closure phase is always situated at the project end. It is the last phase of each project, during which the project is conclusively brought to completion. The closest attention during this phase is paid to the project documentation, which is checked accordingly and supplemented and structured as necessary, especially from a formal point of view. The organizational and administrative transition from the project organization to the application organization is also set out during this phase; legacy systems are deactivated or removed, all project data is archived in accordance with the provisions of the core organization and, if necessary, responsibility for the solution is transferred.

The purpose of the closure phase is, in particular, to ensure that the organizational and administrative handover and transition interfaces of the project (vis-à-vis the core organization, the program, the portfolio, the application organization, if necessary the operating organization, etc.) remain identical regardless of the approach selected.

Phase overview

HERMES phase model

Because different types of projects in different core organizations at various hierarchical and decision-making levels may be carried out using both the traditional and agile approaches, the HERMES phase model must be able to handle a correspondingly high level of requirements. Figure 14 illustrates the phase model for projects with traditional and agile approaches.

Figure 14: HERMES phase model for traditional and agile approaches
Figure 14: HERMES phase model for traditional and agile approaches

The phase model

  1. always reflects the same project structure vis-à-vis the core organization and provides uniform interfaces,
  2. covers the common controlling and reporting requirements of management,
  3. fully integrates into a traditional or agile core organization, regardless of the approach chosen,
  4. makes use of synergies and avoids any redundancies, and
  5. is easy to apply.

The table shows the phase model using traditional and agile development processes:

Table 1: HERMES phases for projects with traditional and agile solution development
HERMES phases Traditional development Project life cycle HERMES phases agile development
Initiation Project start Initiation
Concept Solution development Execution
Implementation
Deployment
Closure Project end Closure

Uniform project structure

The first and last phases of the project are always common to all projects. A project begins with the initiation phase and ends with the closure phase. This ensures the uniformity of the project structure and the project life cycle. The project interfaces to the core organization, controlling, program, portfolio, etc. are kept the same regardless of the approach. The transitions to the application organization and operating organization are channeled in a uniform way.

The project structure is supported additionally by the milestones described in Section 4. Over the course of the project, they mark important decision outcomes of project steering and management. As shown in Figure 15, milestones are at the beginning and end of each phase. With each phase release, the (financial, personnel, infrastructure) resources are released for the next phase by the sponsor. Under the agile approach, interim releases can be defined and approved on an optional basis as milestones during the execution phase.

Figure 15: Milestones at the beginning and end of each phase and approval of interim releases
Figure 15: Milestones at the beginning and end of each phase and approval of interim releases

These milestones defined in terms of the project structure correspond to quality gates, before which the outcomes and the procedure are decided. Compliance with the requirements and the conformity of the project with the strategic objectives of the core organization are checked.

Phase progression

The initiation phase provides a basis for planning and steering the project. The initiation phase is followed by solution development, either with the traditional phases of concept, implementation, and deployment or with the agile phase of execution. The execution phase covers the agile development process and serves to embed any agile development method within the HERMES framework.

The closure phase provides space for all necessary measures in connection with the removal of the replaced legacy product or system environment, including the infrastructure that is no longer required, and for the systematic shutting down of the project, including all administrative and organizational measures.

Along the phases, further decisions are made with corresponding specific milestones that determine the successful progression of the project. These milestones vary depending on the nature of the project. As an example, Figure 16 shows the steering and management milestones for traditional and agile IT development projects.

Figure 16: Milestones for traditional and agile IT development projects
Figure 16: Milestones for traditional and agile IT development projects

For the next steps milestone, but also for other milestones, achievement of the sustainability goals (see Section 7) is also taken into account as an assessment criterion.

Over the course of the entire project, reporting is carried out in accordance with the requirements of the core organization in terms of the content and, to the extent feasible, the frequency of the reports (see Section 7).

Explanation regarding the phase description

For each phase, a phase description is provided that is always structured in the same way:

  1. Description of the phase as a whole, highlighted
  2. Enumeration of important points and rough description of what needs to be done over the course of the phase
  3. Description of the phase closure, highlighted

Explanation of the phases

Project start

  1. Initiation

Traditional solution development

  1. Concept
  2. Implementation
  3. Deployment

Agile solution development

  1. Execution

Project end

  1. Closure