Outcomes

Introduction

The HERMES project management method is outcome-oriented; outcomes as the most important method components are at the heart of HERMES.

Two types of outcomes are distinguished. An outcome may be:

1. a document that is drafted where possible on the basis of an existing document template such as an execution order, a study, a checklist, or a process description;
2. a state that is newly achieved, such as operating infrastructure realized or also a milestone that is the direct consequence of a decision.

Boundaries

The outcome of an entire project (the actual finished solution) or a part thereof (the increment) are not HERMES method components. This solution may include products, services, IT applications, infrastructures, changed or new operating organizations, new or merged core organizations, or individual organizational units. The project outcome may also consist of trained users and the activated organization with its processes. At the end of a successful project, the outcome is a solution, an overall system, consisting of one or more activated elements.

Overview of outcomes

Standard outcomes

Standard documents

The following table lists all standard documents. HERMES also provides a corresponding document template for each document.

The minimum required documents marked with an X are required to meet governance requirements. These include not only those outcomes that must be checked by the auditors, but also all those that must be produced in a module as a "must have".

The minimum required documents are the safeguards for ensuring the project's success and reflect a general project situation without addressing the specifics of individual projects. The preparation of the minimum required documents is mandatory. If a module is not relevant for the project, the minimum required documents defined in it are also dropped. They are likewise dropped if, under certain circumstances, their use is not foreseen in the module (e.g. in the case of traditional/agile). The minimum required documents can also be adapted to the specific needs of the core organization in accordance with its governance provisions.

Standard states

The following table lists all the standard states.

Customized outcomes

Supplementing the standard documents and states, it is possible to integrate further specialist, organization-specific, or project-specific outcomes in one's own modules. This is supported by HERMES online and is especially relevant when new modules with new tasks are developed. Examples of customized outcomes can be core organization-specific reports or a completed consultation.

Explanation regarding outcome description

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

• Description
  creates a fundamental understanding of the outcome.
• Content (for documents only)
  describes the proposed content of a document (see document templates below).
  Where applicable, each content note is marked with "A" for agile or "T" for traditional .
• Relationships (online only)
  show how the outcome relates to modules, roles, and tasks.
• Templates (online only)
  A document template is available for all documents. The template is a concrete aid for deeper understanding of the application of HERMES documents. The document templates can, however, be adapted to the needs of the organization or replaced by adequate tool-supported solutions (see Section 7).

Description of the outcomes

Documents

• Acceptance report
• Agreement
• Business model description
• Change request
• Change status list
• Deployment concept
• Detailed specifications
• Evaluation report
• Execution order
• Final project evaluation
• ISDP concept
• Integration and installation instructions
• Integration concept
• Legal basis analysis
• Lessons learned
• List of management project decisions
• List of steering project decisions
• Migration concept
• Minutes
• Offer
• Operating concept
• Operating manual
• Organization concept
• Organization description
• Organizational requirements
• Phase report
• Process description
• Procurement analysis
• Product concept
• Product documentation
• Project initiation order
• Project management plan
• Project status report
• Protection needs analysis
• Prototype documentation
• Publication
• QA and risk report
• Quote request
• Release report
• Review report
• Service level agreement
• Situation analysis
• Solution architecture
• Solution requirements
• Stakeholder interests
• Stakeholder list
• Study
• System concept
• Tender documentation
• Tender report
• Test concept
• Test report
• User manual
• Work order

Checklists

Description

Checklists are part of the documents. They are used to support decision-making. They represent lists of monitoring and review steps which must be executed systematically and completely within the scope of a decision preparation. This reduces the probability of wrong decisions, given that all essential aspects are taken into account.

Each checklist is tailored to a specific decision and specifies the necessary review points with outcomes, release criteria, evaluation, those responsible, and review date. The checklists must be supplemented with further project-, core organization-, and solution-specific criteria in the context of decision preparation.

• Acceptance checklist
• Closure phase release checklist
• Contract award checklist
• Execution release checklist
• ISDP concept checklist
• Launch of operation checklist
• Migration acceptance checklist
• Next steps checklist
• Phase release checklist
• Preliminary acceptance checklist
• Product concept checklist
• Project closure checklist
• Project discontinuation checklist
• Project initiation release checklist
• Release checklist
• Solution architecture checklist
• Tender checklist

States

• Deployment measures carried out
• Deployment measures realized
• ISDP concept transferred
• ISDP measures realized
• Interfaces realized
• Legacy system removed
• Migration carried out
• Migration procedure realized
• Operating infrastructure realized
• Operating organization realized
• Operation activated
• Organization activated
• Organization implemented
• Product activated
• Product developed or adapted
• Prototype realized
• System activated
• System developed or parameterized
• System integrated
• Test infrastructure realized
• Test infrastructure transferred

Milestones

Description

Milestones are states and are always the consequence of a decision. They mark and define a specific point in time reached in the course of the project.

Milestones serve as envisaged and achieved decision outcomes for project steering and management, give the project a structure, and mark important points in the course of the project at which decisions are made on next project steps.

• Acceptance milestone
• Closure phase release milestone
• Contract award milestone
• Execution release milestone
• ISDP concept milestone
• Launch of operation milestone
• Migration acceptance milestone
• Next steps milestone
• Phase release milestone
• Preliminary acceptance milestone
• Product concept milestone
• Project closure milestone
• Project initiation release milestone
• Release milestone
• Solution architecture milestone
• Tender milestone