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.

Table 16: Overview of outcomes - documents
Documents
minimum required documents = X minimum required documents = X
Acceptance report X List of management project decisions X
Change request X List of steering project decisions X
Change status list X Solution requirements X
Offer X Solution architecture X
Tender report Migration concept
User manual Quote request X
Work order Organizational requirements X
Tender documentation X Organization description X
Procurement analysis Organization concept X
Operating manual X Phase report X
Operating concept X Product documentation X
Acceptance checklist Product concept X
Migration acceptance checklist Lessons learned
Tender checklist Project initiation order X
Launch of operation checklist Project management plan X
Execution release checklist Final project evaluation X
ISDP concept checklist Project status report X
Solution architecture checklist Minutes
Phase release checklist Prototype documentation
Closure phase release checklist Process description X
Product concept checklist Review report
Project discontinuation checklist Publication X
Project closure checklist QA and risk report X
Project initiation release checklist Legal basis analysis X
Release checklist Release report X
Preliminary acceptance checklist Protection needs analysis X
Next steps checklist Service level agreement
Contract award checklist Situation analysis X
Detailed specifications X Stakeholder interests
Execution order X Stakeholder list X
Deployment concept X Study X
Evaluation report X System concept
Business model description X Test concept X
Integration and installation instructions Test report X
Integration concept X Agreement
ISDP concept X

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:

  1. Description
    creates a fundamental understanding of the outcome.
  2. 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 .
  3. Relationships (online only)
    show how the outcome relates to modules, roles, and tasks.
  4. 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

  1. Acceptance report
  2. Change request
  3. Change status list
  4. Offer
  5. Tender report
  6. User manual
  7. Work order
  8. Tender documentation
  9. Procurement analysis
  10. Operating manual
  11. Operating concept
  12. Detailed specifications
  13. Execution order
  14. Deployment concept
  15. Evaluation report
  16. Business model description
  17. Integration and installation instructions
  18. Integration concept
  19. ISDP concept
  20. List of management project decisions
  21. List of steering project decisions
  22. Solution requirements
  23. Solution architecture
  24. Migration concept
  25. Quote request
  26. Organizational requirements
  27. Organization description
  28. Organization concept
  29. Phase report
  30. Product documentation
  31. Product concept
  32. Lessons learned
  33. Project initiation order
  34. Project management plan
  35. Final project evaluation
  36. Project status report
  37. Minutes
  38. Prototype documentation
  39. Process description
  40. Review report
  41. Publication
  42. QA and risk report
  43. Legal basis analysis
  44. Release report
  45. Protection needs analysis
  46. Service level agreement
  47. Situation analysis
  48. Stakeholder interests
  49. Stakeholder list
  50. Study
  51. System concept
  52. Test concept
  53. Test report
  54. Agreement

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.

  1. Acceptance checklist
  2. Migration acceptance checklist
  3. Tender checklist
  4. Launch of operation checklist
  5. Execution release checklist
  6. ISDP concept checklist
  7. Solution architecture checklist
  8. Phase release checklist
  9. Closure phase release checklist
  10. Product concept checklist
  11. Project discontinuation checklist
  12. Project closure checklist
  13. Project initiation release checklist
  14. Release checklist
  15. Preliminary acceptance checklist
  16. Next steps checklist
  17. Contract award checklist

States

  1. Legacy system removed
  2. Operation activated
  3. Operating infrastructure realized
  4. Operating organization realized
  5. Deployment measures carried out
  6. Deployment measures realized
  7. ISDP concept transferred
  8. ISDP measures realized
  9. Migration carried out
  10. Migration procedure realized
  11. Organization activated
  12. Organization implemented
  13. Product activated
  14. Product developed or adapted
  15. Prototype realized
  16. Interfaces realized
  17. System activated
  18. System developed or parameterized
  19. System integrated
  20. Test infrastructure realized
  21. 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.

  1. Acceptance milestone
  2. Migration acceptance milestone
  3. Tender milestone
  4. Launch of operation milestone
  5. Execution release milestone
  6. ISDP concept milestone
  7. Solution architecture milestone
  8. Phase release milestone
  9. Closure phase release milestone
  10. Product concept milestone
  11. Project closure milestone
  12. Project initiation release milestone
  13. Release milestone
  14. Preliminary acceptance milestone
  15. Next steps milestone
  16. Contract award milestone