Referenzhandbuch HERMES-Projektmanagement 2022 de

HERMES
REFERENZHANDBUCH – Projektmanagement
Ergebnisorientierte Projektmanagementmethode
für verschiedene Arten von Projekten
Ausgabe 2022
HERMES-PROJEKTMANAGEMENT AUF EINEN BLICK:
Referenzhandbuch
 Dieses Referenzhandbuch dokumentiert die Methode und ist als Druckaus-
gabe sowie online verfügbar;
 Es wird in der Ausbildung eingesetzt, eignet sich für das Selbststudium und
kann als Nachschlagewerk dienen;
 Es bildet die Referenzgrundlage für die Zertifizierung.
Online
 Szenarien und Planungsunterlagen können heruntergeladen werden;
 Dokumentvorlagen und Checklisten ermöglichen eine rasche und einheitli-
che Planung und Dokumentation;
 Individuell anpassbares Sizing passt den Dokumentationsaufwand an
die Komplexität des Vorhabens an.
Ausbildung und Zertifizierung

 Kurse helfen, HERMES kennenzulernen und seine Anwendung aus-
zuprobieren;
 Themenspezifische Vertiefungskurse unterstützen die Professionali-
sierung;
 Zertifikate einer unabhängigen Stelle bescheinigen die Fähigkeiten.
Erfahrungsaustausch
 Veranstaltungen regen Austausch und Networking an;
 Newsletter und Social Media informieren über Neues;
 HERMES-Anwender lassen ihre Erfahrungen und Wünsche in die
Weiterentwicklung einfliessen.
Standardisierung
 Neue Entwicklungen werden durch eCH standardisiert;
 eCH ist das Standardisierungsgremium für E-Government;
 Die Anwender sind in der HERMES-Fachgruppe vertreten.
Vorwort
HERMES-Evolution
Die HERMES Projektmanagementmethode ist ein Erfolgsprodukt, dass sich sukzessive dem
Zeitgeist anpasst und die jeweils geltende Evolutionsstufe des Projektverständnisses reflek-
tiert.
Der grösste Teil der Weiterentwicklung betrifft die Überarbeitung der agilen Vorgehensweise.
Dennoch können Projekte auch weiterhin klassisch abgewickelt werden, wie aus HERMES 5
bekannt ist; es galt den bisherigen Erfolg von HERMES zu sichern und zugleich Neues einflies-
sen zu lassen.
Die Überarbeitung der Methode hat uns zu neuen Erkenntnissen verholfen, wie z. B. die Ab-
koppelung von Projekt- und Entwicklungsmanagement. Dazu kamen nicht nur die längst
überfälligen Anforderungen unserer Anwender, wie z. B. der Ruf nach einer prominenteren
Platzierung des Beschaffungsprozesses, sondern auch die Frage, wann ein Projekt beginnen
und wer wann welche Rolle besetzen soll.
Um betriebswirtschaftliche Aspekte mehr in den Vordergrund zu rücken, haben wir einige
Rollen angepasst und nicht zuletzt die Wichtigkeit der Stakeholder und Fachverantwortung
hervorgehoben.
Wir haben erkannt, dass es immer wichtiger wird, dass die Stammorganisation weiss, was sie
will und sich auch entsprechend zur Geltung bringt. Es ist schliesslich ihr Projekt, es ist ihre
Lösung, die da entsteht, und es sind ihre Finanzen, die das alles ermöglichen. So soll das neue
HERMES den Fachbereichen helfen, selbst zu bestimmen, wie das eigene Produkt abzuwickeln
ist.
Um auch im Entwicklungsbereich flexibel und aktuell zu bleiben, haben wir diesen so in das
gesamtheitliche Projektmanagement eingeflochten, dass eine klassische wie auch eine agile
Entwicklung für die Lösungsentstehung ausgewählt und problemlos nebeneinander abgewi-
ckelt werden kann.
Wir sind bestrebt, die Projektmanagementmethode fortlaufend an die aktuellen Bedürfnisse
anzupassen und nehmen die Anliegen unserer Anwender sehr ernst.
Wir unterstützen Sie gerne bei Fragen über den Aufbau der Projektorganisation oder zum
Ablauf von Projekten via E-Mail (siehe Impressum).
Ich bedanke mich bei allen, die uns geholfen haben und immer noch helfen, diese Methode
weiterhin aktuell, einfach und klar zu gestalten und wünsche viel Erfolg beim Anwenden.
André Bürki
Verantwortlicher HERMES-Methode,
Bundeskanzlei BK
Digitale Transformation und IKT-Lenkung
www.bk.admin.ch
«Mit der neuen HERMES-Version konnten die Erfahrungen aus der Abwick-
lung von agilen Vorhaben übernommen werden. Dies ermöglicht die opti-
male Steuerung und Führung von komplexen agilen Vorhaben wie SUPERB».
Patrik Riesen, Programmleiter SUPERB
1 / 200
Impressum
Herausgeber
Bundeskanzlei BK, Digitale Transformation und IKT-Lenkung DTI
Gesamtverantwortung
André Bürki, Verantwortlicher HERMES-Methode, Digitale Transformation und IKT-Lenkung DTI
Urheberrechte und Vorbehalt

HERMES ist ein offener Standard der schweizerischen Bundesverwaltung. Die Schweizerische Eidgenossen-
schaft, vertreten durch DTI, ist Inhaberin der Urheberrechte. Die Verwendung zum Eigengebrauch richtet
sich nach Artikel 19 des Bundesgesetzes über das Urheberrecht und verwandte Schutzrechte (Urheber-
rechtsgesetz, URG, SR 231.1).
Die vorliegende Ausgabe kann Mängel oder Inkonsistenzen enthalten. Die Haftung für Schäden und die
Gewährleistung für Mängel seitens der Schweizerischen Eidgenossenschaft ist unter Vorbehalt anderslau-
tender zwingender gesetzlicher Bestimmungen des anwendbaren Rechts ausgeschlossen. Irrtümer, Prob-
leme oder Änderungsvorschläge können dem Herausgeber über HERMES online hermes.admin.ch mitge-
teilt werden.
HERMES-Projektmanagementmethode / Dokumentvorlagen
Libor F. Stoupa, Stoupa & Partners AG, Autor;
Michael Halfar, Stoupa & Partners AG, Coautor, Sizing;
Claude Eisenhut, Datenmodellexperte, Eisenhut Informatik AG;
Expertenteam agil: Daniel Aeschbacher, avega IT AG; Patrik Riesen, couniq consulting AG; Tobias Durrer,
kiwi Consultants AG;
Kathrin Schmidt, Berner Fachhochschule – BFH, Manuskriptbegutachtung und Kohärenzprüfung;
Michael Kammerbauer, Schweizerische Bundeskanzlei, Lektorat
Hinweis zur sprachlichen Gleichbehandlung

Das vorliegende Handbuch verwendet aus Gründen der besseren Lesbarkeit und Verständlichkeit Rollen-
und Personenbezeichnungen, die unabhängig vom Geschlecht einer Person und von Stellen einer Orga-
nisation sind. Diese Formulierungen schliessen alle anderen Geschlechter in ihrer jeweiligen Funktion expli-
zit mit ein.
Typografische Gestaltung, Grafiken und Druckvorstufe

Stoupa & Partners AG, Münsingen
Online-Tool
ICTpark AG, Allenwinden
Support und Unterstützung

E-Mail: [email protected]
E-Government Standards
eCH Standard 0054
Bezugsquelle
Vertrieb:
BBL, Verkauf Bundespublikationen, CH-3003 Bern
www.bundespublikationen.admin.ch
Art.-Nr. 104.500.D
ISBN 978-3-906211-83-1
Ausgabe / Auflage
Ausgabe 2022 / 1. Auflage, 02/2023
2 / 200
Prolog
PHASEN
«Kleine Taten, die man ausführt, sind besser als grosse, die man plant.»
(Peter Marshall)
Agile Methoden haben sich in unserer schnelllebigen Zeit vielerorts als den traditionellen An-
sätzen überlegen erwiesen. Es ist daher folgerichtig, dass sie auch von den Behörden häufiger
eingesetzt werden und in HERMES ihren Niederschlag finden. Die Erfahrungen der Eidgenös-
sischen Finanzkontrolle EFK zeigen allerdings, dass die konsequente Anwendung einer Me-
thode leider kein Garant für eine erfolgreiche Projektdurchführung ist. Wichtig sind auch wei-
SZENARIEN
tere Aspekte. Wir ermuntern Sie daher, Folgendes im Auge zu behalten:
Vergegenwärtigen Sie sich, dass der Kulturwandel bei Veränderungen zentral ist.
Machen Sie allen Beteiligten von Beginn an bewusst, dass Innovation nicht alleine durch Tech-
nologie getrieben wird, sondern beim einzelnen Mitarbeitenden beginnt. Fördern Sie die Di-
alogbereitschaft, lernen Sie mit Unsicherheiten zu leben, stellen Sie Tabus infrage und lassen
Sie Fehler zu. Eine Null-Fehler-Kultur ist – nicht nur, aber vor allem – für die agile Welt fatal.
Stellen Sie das Geschäft und den Endnutzer in den Fokus.
MODULE
Steuern Sie als Auftraggeber das Vorhaben, indem sie den erwarteten Geschäftsnutzen ins
Zentrum stellen und die Berichterstattung konsequent danach ausrichten. Definieren Sie z. B.
über Meilensteine, wann Sie welchen Nutzen realisiert haben wollen und überlassen Sie die
Projektdurchführung primär dem Projektteam.
Zögern Sie nicht im Hinblick auf die Transformationsvorhaben der Verwaltung, bestehende
Organisationen und Prozesse zu hinterfragen. Motivieren Sie die Beteiligten, die Lösung zu-
sammen mit den Nutzern zu kreieren. Im Falle der Verwaltung sind das beispielsweise Bürger,
ERGEBNISSE
Unternehmen, Subventionsempfänger aber auch Kantone und Gemeinden. Wagen Sie es, alle
Beteiligten zur Zusammenarbeit aufzufordern, sodass am Ende ein durchgängiger End-to-
End-Prozess entsteht.
Setzen Sie in Ihrem Vorhaben die Puzzleteile lückenlos zusammen.
Orchestrieren Sie Ihre Vorhaben in einer Weise, dass sie vereint einen wertvollen Beitrag zur
Erreichung Ihrer strategischen Ziele leisten. Schicken Sie Architektur-, IKS-1 und Sicherheits-
Verantwortliche früh ins Rennen, damit ihre Anforderungen tatsächlich berücksichtigt werden.
Und überzeugen Sie sich letztlich davon, dass ausreichend explizite Testfälle für die internen
AUFGABEN
Kontrollen und Sicherheitselemente vorliegen und diese möglichst automatisiert durchgeführt
werden.
Statten Sie Ihre Organisation mit Kompetenzen aus.
Sichern Sie sich rechtzeitig und nachhaltig die Schlüsselressourcen und bestätigen Sie unmiss-
verständlich deren rollenspezifische Verantwortlichkeiten. Achten Sie darauf, dass der Anwen-
dervertreter (Product Owner) sowohl über das Fachwissen wie auch die nötigen Entschei-
dungsbefugnisse verfügt und starten Sie nie ohne ein ausgereiftes Qualitäts- und Risikoma-
ROLLEN
nagement.
Wir werden bei unseren Prüfungen in der Bundesverwaltung auf diese Aspekte achten und
freuen uns, zusammen mit allen Anwendern, diese neue Welt zu entdecken. Falls Sie Fragen
haben, wenden Sie sich an uns: [email protected].
Eidgenössische Finanzkontrolle EFK

www.efk.admin.ch
HINWEISE ZUR
ANWENDUNG
1 Das interne Kontrollsystem (IKS) der Bundesverwaltung, das zwischen 2007 und 2008 eingeführt wurde.
3 / 200
4 / 200
HERMES im neuen Kleid
(Libor F. Stoupa, Autor HERMES-Projektmanagement, Ausgabe 2022)
Die vorliegende Ausgabe 2022 von HERMES-Projektmanagement reflektiert das sich in den
letzten Jahren wandelnde Projektverständnis und die Erwartungen der Anwender an ein fort-
schrittliches Projektvorgehen. Einerseits sollte das agile Entwicklungsvorgehen im HERMES-
Projektmanagement an die aktuellen Bedürfnisse der Organisationen angepasst werden. Hier-
bei sollte die bereits vorhandene agile Vorgehensweise optimiert und in das Phasenmodell
eingebunden werden. Und dies unter Berücksichtigung der Governance, eines einheitlichen
Vorgehens in den Projekten und der bereits bewährten Schnittstellen zu der Projektumge-
bung. Anderseits sollten Aspekte wie Organisation und Geschäftsorientierung stärker ins Ge-
wicht fallen und die IT-Lastigkeit weiter verringert werden.
HERMES unterscheidet zwischen klassischem und hybridem Projektmanagement. Mit dem
hybriden Projektmanagement erlaubt es nun diverse agile Entwicklungsmethoden einheitlich
einzubinden. Ansonsten bietet HERMES die gleiche Struktursystematik und die gleichen Me-
thodenelemente wie bis anhin. Auch die Methode blieb in den Grundzügen gleich strukturiert,
nur die Ergebnisse stehen nun mehr im Zentrum, was zur Anpassung der Kapitelreihenfolge
mit zum Teil neuen Überschriften führte.
Die eigenständige HERMES-Terminologie blieb unabhängig vom Entwicklungsvorgehen weit-
gehend unverändert. Das klassische Entwicklungsvorgehen entspricht der heute breit ange-
wandten Praxis, das Business bzw. Fach stärker ins Zentrum zu stellen. Bei der agilen Entwick-
lung ist neu eine mögliche Releasefreigabe vorgesehen, die dem Auftraggeber eine zusätzli-
che Gelegenheit gibt, analog einer Phasenfreigabe den nächsten Schritt zu bestimmen und
dadurch zusätzlich die Governance zu sichern.
Weitere wichtige Anpassungen:
 Die Projektphasen berücksichtigen die Anforderungen der agilen Welt.
 Im Vordergrund steht das Projektmanagement, das agile Entwicklungsmanagement ist als
Methode untergeordnet und wird, ohne näher auf sie einzugehen, als eine Blackbox inte-
griert.
 Das Projekt beginnt bereits mit einer schlanken Phase Initialisierung, die Szenariowahl
kommt erst beim Entscheid Weiteres Vorgehen zum Tragen.
 Der Beschaffungsprozess wird bereits in der Initialisierung geplant und vorbereitet – so
ermöglicht er die Szenarien mit Adaption.
 Die Steuerungsfunktion der Meilensteine ist verstärkt. Die Meilensteine sind neu als Me-
thodenelemente greifbar und gelten unabhängig der gewählten Vorgehensweise.
 Neu ist bei den Aufgaben definiert, welche vorliegenden Ergebnisse die Voraussetzung
für ihre Durchführung bilden.
 Minimal zu besetzende Rollen sind Auftraggeber, Projektleiter und Anwendervertreter, die
zwingend durch die Partnergruppe Anwender zu besetzen sind.
 Die Führungs- und die fachliche Kompetenz sind klar und eindeutig geregelt und rollen-
spezifisch voneinander getrennt. Der Projektleiter braucht kein Fachwissen mehr, dafür
umso mehr entsprechende Managementkenntnisse und -fähigkeiten. Er kann somit von
der Partnergruppe Anwender auch extern rekrutiert werden. Die Rolle des Anwenderver-
treters hat dafür an Bedeutung gewonnen; sie besitzt die fachliche Produktverantwortung
(klassisch und agil). Dementsprechend steigen auch die Anforderungen an den Rollenin-
haber.
Das vorliegende Handbuch stellt analog den vorherigen Ausgaben eine Grundlage für eher
grössere Projekte dar. Allerdings wird eine vorhabenbezogene Anwendung der Methode er-
wartet (Tailoring). Der Umfang der zu erstellenden Dokumente wird online mit dem individuell
anpassbaren Sizing erreicht. Ziel ist es, die Komplexität des Vorgehens so tief wie möglich zu
halten und die Anwenderfreundlichkeit des HERMES-Projektmanagements weiter zu steigern.
Wir hoffen, dass das neue HERMES Ihren Erwartungen entspricht und freuen uns auf Ihre
Feedbacks.
HERMES ist ein Erfolgsprodukt und so soll es auch in Zukunft bleiben.
5 / 200
A Methodenüberblick
A.1 HERMES-Projektmanagement – Big Picture
Das Ergebnisdiagramm (Abbildung 1) zeigt den groben Gesamtzusammenhang der Ergebnisse
des HERMES-Projektmanagements.
Projektsteuerung Projektgrundlagen
Projektführung
Projekt-
initialisierungs-
auftrag
Initialisierung
Stakeholder-
liste
Rechts- Schutzbedarfs- Beschaffungs-
grundlagen- Studie
analyse analyse analyse
Projektmana-
gementplan
Durchfüh-
rungsauftrag
Projektsteuerung
Projektführung Organisation Produkt IT-System
Phasenunabhängig Situations- Situations- Situations-

analyse analyse analyse
Projekt- Organisations- Lösungs- Lösungs-

management- anforderungen anforderungen anforderungen
Konzept
plan
Organisations- Produkt- System-
Stakeholder- konzept konzept konzept
liste
Geschäftsmod.-
Projektstatus- beschreibung
bericht Iteration Iteration
Prozess- Organisations- Lösungs- Integrations-
Phasenbericht beschreibung beschreibung architektur konzept
Umsetzung
Detail- Detail- Detail-

spezifikation spezifikation spezifikation
Releasebericht
Prozess- Organisations-
beschreibung beschreibung
Realisierung
QS- und Produkt System Schnittstellen

Risikobericht entwickelt/ entwickelt/ realisiert
angepasst parametrisiert
Integrations-
Änderungs- Organisation Anwendungs- Anwendungs- und
antrag umgesetzt handbuch handbuch Installations-
anleitung
Änderungs-
statusliste
Organisation Produkt System

Vereinbarung
Einführung
aktiviert aktiviert aktiviert
Projekt-
entscheide
Abschluss
HERMES-Phasenmodell für klassische und agile Projekte
Abbildung 1: Gesamtbild der HERMES-Module und der wesentlichen Ergebnisse entlang der Phasen
6 / 200
HERMES ist eine ergebnisorientierte Vorgehensmethode; die Ergebnisse stehen im Zentrum.
Das Gesamtbild zeigt die wesentlichen Ergebnisse der einzelnen Module entlang der Phasen
sowie die groben Abhängigkeiten und Zusammenhänge. Die roten ovalen Iterationspfeile
versinnbildlichen den Kern der Iteration, den treibenden Charakter der Module Produkt und
IT-System während der agilen Entwicklung. Die Ergebnisse der anderen Module werden im
gleichen Takt iterativ-inkrementell miterarbeitet.
Beschaffung Tests Einführungs- IT-Migration IT-Betrieb ISDS

organisation
Ausschrei- Betriebs-
bungs- konzept ISDS-Konzept
unterlagen
Evaluations- Service Level
bericht Testkonzept
Agreement
Einführungs- Migrations-
Vereinbarung konzept
konzept
Test- Einführungs- Detail- Betriebs- Betriebs- ISDS-

infrastruktur massnahmen spezifikation infrastruktur handbuch Massnahmen
realisiert realisiert realisiert realisiert
Migrations- System Betriebs-

Testprotokoll integriert ISDS-Konzept
verfahren organisation
realisiert realisiert
Testkonzept
Abnahme-
protokoll
Einführungs- Migration Betrieb ISDS-Konzept

massnahmen durchgeführt aktiviert überführt
durchgeführt
Abnahme-
protokoll ISDS-Konzept
Altsystem
Testkonzept entfernt
Testinfrastruk-
tur überführt
7 / 200
A.2 Was ist HERMES-Projektmanagement?
HERMES-Projektmanagement ist die gesamtheitliche Managementmethode für das Durch-
führen von Projekten und Programmen verschiedener Art in vielen Tätigkeitsfeldern, wie in
der Anpassung der Organisation, der Informatik oder der Entwicklung von Dienstleistungen
und Produkten. Wie die Abbildung 2 zeigt, sind HERMES-Portfoliomanagement, HERMES-
Projektmanagement und HERMES-Anwendungsmanagement gleichwertige Methodenele-
mente und bilden gemeinsam die HERMES-Methode.
HERMES-Methode
HERMES- HERMES- HERMES-

Portfoliomanagement Projektmanagement Anwendungsmanagement
Abbildung 2: Die drei obersten Methodenelemente der HERMES-Methode
HERMES-Projektmanagement unterstützt die Steuerung, Führung und Ausführung von Vor-

haben und begleitet die Weiterentwicklung von organisatorischen Strukturen, Produkten und
Dienstleistungen, IT- und Logistiksystemen, Infrastrukturen u. ä. unterschiedlicher Charakte-
ristiken und Komplexitäten. Ein Projekt kann in Teilprojekte gegliedert werden, die unter-
schiedliche Aspekte desselben Projekts bearbeiten (z. B. Teilprojekte Anwender, Ersteller, Be-
treiber für Organisation, IT, Rechtsgrundlagen). Lange dauernde oder komplexe Vorhaben
müssen nicht zwangsläufig als Programm strukturiert werden. Sie können als Projekte mit Re-
alisierungseinheiten durchgeführt werden.
HERMES-Projektmanagement hat eine klare, einfach verständliche Methodenstruktur mit ge-
meinsamer Terminologie für alle Beteiligten, ist modular aufgebaut und erweiterbar. Es wird
laufend aktualisiert und weiterentwickelt.
Auf die anderen zwei, gleich positionierten Methodenelemente Portfoliomanagement und
Anwendungsmanagement, wird im HERMES-Projektmanagement nicht näher eingegangen.
A.3 Durch HERMES unterstützte Projektgrössen

Um die Vollständigkeit der Information und der Methode an sich zu gewährleisten, ist das
HERMES-Projektmanagement durchgehend für grössere Projekte mit höherer Komplexität
angelegt. Dies passt jedoch nicht zu jedem Vorhaben. Mit der im HERMES-Online bereitge-
stellten Sizing-Funktion werden die Standardszenarien gemäss der ermittelten tatsächlichen
Projektwertigkeit angepasst. Diese wird aus einer Kombination von beispielsweise Durchlauf-
zeit, Grösse des Projektteams, Stakeholder-Struktur oder politische Brisanz ermittelt, die sich
auf die Komplexität der zugrundeliegenden Lösungsvariante gemäss Studie bezieht. Aufgrund
der ermittelten Wertigkeit des anvisierten Vorhabens stellt die Sizing-Funktion dem Projekt-
leiter das gewählte, entsprechend zugeschnittene Szenario samt angepassten Dokumentvor-
lagen bereit.
Die in HERMES-Online eingestellten Projektgrössen/-wertigkeiten sind als generelle Standard-
annahmen zu verstehen. Sie können durch die Projektleitung oder die Stammorganisation
ihren eigenen Bedürfnissen angepasst werden.
8 / 200
A.4 Nutzung des HERMES-Projektmanagements in der Praxis
Die HERMES-Projektmanagementmethode unterstützt zwei Vorgehensweisen: Das traditio-
nelle klassische phasenweise Vorgehen nach Systems Engineering2, nachfolgend "klassisch"
genannt, und das iterativ-inkrementelle Vorgehen3, nachfolgend "agil" genannt. Sie liefert ein
Framework, das es erlaubt, unterschiedliche Vorgehensweisen und folglich auch die jeweils
projektspezifisch eingesetzten Methoden einheitlich einzubetten.
Die Abbildung 3 zeigt den funktionalen Einsatz der HERMES-Projektmanagementmethode,
veranschaulicht die Voraussetzungen für die Projektrollen zur Projektbearbeitung und zeigt
auf, wie die Anwendung der Methode eine entsprechende, anderweitige methodische Aus-
bildung oder zumindest fundierte Projektpraxis voraussetzt: Die Projektmanagementmethode
kanalisiert verschiedenen Orts erworbenes Wissen, erweitert dieses durch HERMES-spezifi-
sche Elemente und Terminologie und bietet allen Vorhaben einen homogenen Rahmen.
Projekte
Klassisches Agiles Entwicklungs-
Projektmanagement Erfahrung & Praxis management
------ ------
Ausbildung Ausbildung
Praxis
Erfahrung
Projektmanagementmethode
Projektmanagement Know-how
HERMES
Handbücher / Online
Agiles Know-how
Dokumentvorlagen
Ausbildung / Zertifizierung
HERMES Projektmanagement im Einsatz
Tagesgeschäft
Abbildung 3: Die Funktionalität von HERMES-Projektmanagement in der Praxis
HERMES-Kurse und Zertifizierungen festigen die geforderte Kompetenz und Know-how.

Dadurch wird sowohl projektintern wie auch gegenüber der Stammorganisation gleichartig
rapportiert und kommuniziert und zeitgleich werden die flankierenden Rahmenanforderun-
gen des HERMES-Projektmanagements (siehe Kapitel 7, z. B. Governance) erfüllt. Somit kön-
nen Projekte aller Art in der Stammorganisation einheitlich verankert werden und weisen un-
abhängig der gewählten Vorgehensweise die gleiche Integration in die betrieblichen Abläufe
auf.
Die Projektteams werden darin unterstützt, die für das Vorhaben gewählte Vorgehensweise
anzuwenden und die von der Projektmanagementmethode verlangten Ergebnisse auf
schlanke Art zu liefern. Insofern werden die klassischen und agilen Methoden nicht beschnit-
ten, es werden aber hinsichtlich der Rollen, der Aufgaben oder der Ergebnisse zusätzliche
Methodenelemente definiert, die als verbindliche Anforderungen notwendig sind. Das HER-
MES-Framework legt über die gewählte Vorgehensweise eine Struktur, die extern ein einheit-
liches Bild aller Projekte liefert und intern allen Projektbeteiligten die gleiche Sprache vermit-
telt. Dadurch wird das gewählte Projektvorgehen in sich völlig autonom und kann in jede
Organisation integriert werden.
2 Das klassische Vorgehensmodell des "Systems Engineerings", ETHZ, Walter F. Daenzer

3 In Anlehnung z. B. an Extreme Programming oder SCRUM: Vorwiegend zur agilen Softwareentwicklung ge-
nutzte Entwicklungsmethoden. Der Entwicklungsprozess steht im Mittelpunkt, spezifische Projektmanage-
mentaspekte sind nicht vorgesehen.
9 / 200
Unabhängig von der Projektart oder der Vorgehensweise erfolgen sowohl die Planung als
auch das Controlling weitgehend auf die gleiche Art und Weise. Dies gilt auch für durch HER-
MES prinzipiell unterstützte Methoden wie SAFe4, oder den prozessualen Optimierungsansatz
DevOps5.
A.5 Die Schnittstellen des HERMES-Projektmanagements

Das HERMES-Projektmanagement deckt den gesamten Projektlebenszyklus ab und ist ergeb-
nisorientiert. Es garantiert die Kompatibilität seiner standardisierten Schnittstellen innerhalb
des Projekts und mit der Stammorganisation, wie z. B. Reporting, unabhängig davon, ob die
Entwicklung klassisch oder agil durchgeführt wird.
Die HERMES-Terminologie garantiert die gemeinsame Sprache und ein gemeinsames Ver-
ständnis zwischen der Stamm- und Projektorganisation, zwischen dem Projekt und dem Pro-
gramm, zwischen dem Projekt-, Anwendungs- und Portfoliomanagement.
Innerhalb der Projektorganisation sind der Auftraggeber, Projektleiter und Anwendervertreter
jene Rollen, die für das Funktionieren der Schnittstellen, aber auch für das gesamte Projekt
unentbehrlich sind. Der Auftraggeber steuert das Projekt und hat die Gesamtverantwortung
für das Vorhaben sowie für das Erreichen der Ziele. Der Projektleiter führt und koordiniert das
Projekt und bestimmt dessen Ablauf. Der Anwendervertreter verantwortet die Lösungsentste-
hung.
A.6 Agiles Entwicklungsmanagement mit HERMES

Die HERMES-Projektmanagementmethode ist eine Projektvorgehenshülle, in die eine spezifi-
sche agile Entwicklungsmethode wie eine Blackbox eingefügt werden kann. Auf das so einge-
kapselte Entwicklungsvorgehen geht HERMES nicht weiter ein, es definiert aber aus Steue-
rungs-, Führungs-, Kommunikations- und Reporting-Gründen entsprechende Schnittstellen.
Dies sind entsprechende Ergebnisse und bestimmte Rollen.
Das klassische und das agile Entwicklungsvorgehen haben von der Führung der Rollen der
Hierarchieebene Ausführung ein grundsätzlich unterschiedliches Verständnis. Während die
klassische Vorgehensweise davon ausgeht, dass der Projektleiter Arbeitsaufträge erteilt, wird
bei agiler Vorgehensweise die Arbeit des Entwicklungsteams durch den Anwendervertreter
über die Lösungsanforderungen gesteuert, und das Team organisiert seine Arbeit selbststän-
dig. Der Projektleiter führt sein Projekt, er darf jedoch nicht in die Selbstorganisation des agi-
len Entwicklungsteams eingreifen. Der Anwendervertreter ist als Vertreter des agilen Entwick-
lungsteams der Ansprechpartner für den Projektleiter.
Die Begriffswelt innerhalb der agilen Entwicklung ist nicht vorgeschrieben, sie richtet sich nach
der jeweils eingesetzten Entwicklungsmethode. Festgelegt sind lediglich die Ergebnis-Schnitt-
stellen und die Begrifflichkeiten im Rahmen des Projektmanagements.
Das HERMES-Projektmanagement gibt dem Vorhaben seine einheitliche Struktur und einen
ebensolchen Rahmen. Der Projektlebenszyklus steht im Vordergrund, das jeweilige agile Ent-
wicklungsmanagement bildet als eingekapselte Methode eine Blackbox. Das agile Entwick-
lungsmanagement regelt die Organisation und die Steuerung des Entwicklungsteams und
steuert autonom, in einem vorgegebenen Rahmen, die Lösungsentstehung. Die methoden-
spezifischen Rollenmodelle, Prozesse und Rituale können – Konsens innerhalb der Stamm-
und Projektorganisation vorausgesetzt – ungehindert gelebt werden.
4 SAFe ermöglicht die Anwendung von skalierter Agilität im breiten Unternehmensumfeld und im grossen
Massstab. HERMES mit agilem Entwicklungsmanagement ist mit SAFe bis zum «agile release train» kompatibel
(z. B. Essential SAFe).
5 Bei DevOps (Development/Operations) steht der ganzheitliche LifeCycle eines Produkts, oder eines Systems,
im Vordergrund – wird infolgedessen auch von HERMES-Anwendungsmanagement unterstützt.
10 / 200
A.7 Positionierung Programmmanagement
In Organisationen mit weitreichenden und umfassenden Veränderungen benötigt man ein
gesamtheitliches Managementsystem, um die Zielerreichung mit einer Gruppe von zusam-
menhängenden Projekten schlank und koordiniert erreichen zu können. Dieses Management-
system heisst Programmmanagement und ist eine Erweiterung des Projektmanagements. Im
Programmmanagement werden die Projekte in einem Programm zusammengefasst.
In einer Stammorganisation können Projekte und Programme nebeneinander geführt werden.
Die Abbildung 4 zeigt beispielhaft ein mögliches Portfolio mit klassisch und agil geführten
Projekten und einem Programm, das weitere Projekte beinhaltet. Die Darstellung legt dar,
dass ein Projekt eigenständig oder Teil eines Programms sein kann. Ein Programm enthält
mehrere Projekte. Projekte und Programme können in einem Portfolio zusammengefasst wer-
den.
Initialisierung Konzept Realisierung Einführung Abschluss
Programm- Programm-
Programmdurchführung
initialisierung abschluss
Projekt 1 Initialisierung Konzept Realisierung Einführung Abschluss
Projekt 2 Initialisierung Umsetzung Abschluss
Projekt n Initialisierung Konzept Realisierung Einführung Abschluss
Initialisierung Umsetzung Abschluss
Programm Projekte mögliches Portfolio

Abbildung 4: Gleichzeitiges Führen von Projekten und Programmen in einer Stammorganisation
HERMES-Projektmanagement schafft ein gemeinsames Verständnis zum Projekt- und Pro-

grammmanagement. Es wird jedoch vorausgesetzt, dass die im Programmmanagement ein-
gesetzten Projektpartner über die notwendigen Fähigkeiten verfügen, damit sie ihre Rolle er-
folgreich wahrnehmen können. Die Erweiterung des Projektmanagements durch das Pro-
grammmanagement wird im Anhang zum vorliegenden Referenzhandbuch thematisiert.
A.8 Hinweise zur Anwendung

Die Hinweise zur Anwendung beschreiben spezifische Aspekte von HERMES-Projektmanage-
ment. Sie bilden die Basis für ein vertieftes Methodenverständnis, beispielsweise in Bezug auf
Governance und Nachhaltigkeit. Sie zeigen zudem auf, wie HERMES in spezifischen Situatio-
nen angewendet werden soll und helfen, Interpretationsraum zu reduzieren, beispielsweise
bei der hybriden Entwicklung oder der Anwendung von Realisierungseinheiten.
11 / 200
B HERMES-Projektmanagement-Methodenelemente
B.1 Phasen
Das HERMES-Phasenmodell für Projekte bildet das Rückgrat jedes Projekts. Es schafft die Vo-
raussetzung für das gemeinsame Verständnis aller Projektbeteiligten. Dies ist eine wichtige
Voraussetzung für die erfolgreiche organisationsübergreifende Abwicklung der Projekte.
Das Phasenmodell baut auf dem Lebenszyklus eines Projekts auf. Die Abbildung 5 zeigt den
HERMES-Projektlebenszyklus sowie das Phasenmodell für die klassische und agile Vorgehens-
weise; die Phase Initialisierung am Anfang und die Phase Abschluss am Ende des Projekts sind
beiden Vorgehensweisen gemeinsam, sie schliessen die Phasen der Lösungsentstehung ein.
klassisch
Konzept Realisierung Einführung
Initialisierung Abschluss
agil
Umsetzung
Projektbeginn Lösungsentstehung Projektende

Projekt
Abbildung 5: HERMES-Projektlebenszyklus mit Phasenmodell für klassische und agile Vorgehensweise
Die Projekte werden somit entweder in fünf oder in drei Phasen abgewickelt. Das Projekt beginnt
mit der Phase Initialisierung und endet am Schluss der Phase Abschluss. Die Phase Initialisierung
entspricht einer strukturierten Orientierung für ein fokussiertes Vorhaben. Sie formuliert, welche
möglichen Lösungen es gibt und welcher Weg zu nehmen ist. Die Phase Abschluss beendet das
Vorhaben und regelt organisatorisch und administrativ den Übergang von der Projekt- zur An-
wendungsorganisation6.
Die zwischen der Initialisierung und Abschluss eingeschlossenen Phasen sind in der klassischen
Vorgehensweise die drei Phasen Konzept, Realisierung und Einführung, in der agilen Vorge-
hensweise hingegen nur die Phase Umsetzung.
Will die Stammorganisation eine mögliche Lösungsvision prüfen, startet sie das Vorhaben mit
der Phase Initialisierung, deren Ergebnisse auch darüber entscheiden sollen, ob das Entwick-
lungsvorgehen mit klassischer oder agiler Vorgehensweise angegangen wird. Diese Entschei-
dung muss fachlich und vorgehenstechnisch begründet sein. Es ist möglich, dass im Rahmen
eines Programmes einige Projekte klassisch, andere agil abgewickelt werden.
B.2 Szenarien
In einer Stammorganisation werden unterschiedliche Projekte durchgeführt. Die Projekte kön-
nen sich bezüglich ihres Inhalts und der Komplexität stark unterscheiden. Um der Vielfalt der
Projekte gerecht zu werden, bietet HERMES-Projektmanagement Szenarien an. Ein Szenario
wird im Projekt für das zwischen der Initialisierung und Abschluss eingeschlossene Entwick-
lungsvorgehen bestimmt, also bei der klassischen Vorgehensweise für die Phasen Konzept,
Realisierung und Einführung und bei der agilen Vorgehensweise für die Phase Umsetzung.
Ein Szenario ist auf die Durchführung von Projekten mit einer spezifischen Charakteristik aus-
gerichtet. Das Szenario beinhaltet diejenigen Methodenelemente von HERMES, die für die
Entwicklung der Lösung von Bedeutung sind. Dadurch ist HERMES-Projektmanagement rasch
und einfach anwendbar. Die Abbildung 6 zeigt beispielhaft mehrere Vorhaben einer Stam-
morganisation mit den dazu passenden Projekten samt Szenarien.
6 Die Anwendungsorganisation ist analog der Projektorganisation eine temporäre Organisation, die in enger
Beziehung zur Stammorganisation steht. Sie ist system- oder produktspezifisch und endet am Ende des Life-
Cycles eines Produkts oder eines Systems (der Anwendung).
12 / 200
Vorhaben Projekte einer Stammorganisation mit Szenarien
Beschaffung Projekt 1 Initialisierung IT-Adaption Abschluss

GEVER-System
Projekt 2 Initialisierung Dienstleistung/Produkt Entwicklung Abschluss

Service public
"Guichet Virtuel"
Projekt 3 Initialisierung IT-Entwicklung Abschluss
Infrastruktur
Hosting Services Projekt 4 Initialisierung IT-Entwicklung Abschluss
Fusion der
Bereiche A & B Projekt 5 Initialisierung Organisationsanpassung Abschluss
Rechtsetzung Projekt n Initialisierung Individuelles Szenario "abc" Abschluss
Abbildung 6: Projekte einer Stammorganisation mit Szenarien
In der Phase Initialisierung wählt der Projektleiter die geeignete Lösungsvariante und mit ihr
auch das für das Entwicklungsvorgehen passende Szenario aus. Auf seiner Grundlage plant er
das konkrete Vorgehen und die Entwicklung der Lösung. HERMES bietet eine Auswahl von
möglichen Standardszenarien an, beispielsweise für eine Organisationsanpassung oder für die
Entwicklung einer Dienstleistung/eines Produkts.
Die Anwender von HERMES können Standardszenarien an die Bedürfnisse ihrer Organisation
anpassen und so eigene, individuelle Szenarien erstellen.
B.3 Module
Module sind wiederverwendbare, den Phasen zugeordnete Bausteine zur Erstellung von Projek-
ten und Szenarien.. Thematisch zusammengehörende Ergebnisse und die mit ihnen verknüpften
Aufgaben bilden ein Modul (s. Abbildung 7).
Projekt
Szenario

Umsetzung
Modul A
Modul B
Modul N
Ergebnisse
Aufgaben
Abbildung 7: Modul setzt sich aus Ergebnissen und Aufgaben zusammen
Der Projektleiter kann zusätzliche Module erstellen und in individuellen Szenarien integrieren.
B.4 Ergebnisse
Wie die Abbildung 8 mit Auswahl von einigen Ergebnissen je Phase zeigt, stehen sie im HER-
MES-Projektmanagement im Zentrum.
Für jedes Ergebnis gibt es eine Ergebnisbeschreibung. Für alle Dokumente gibt es Dokument-
vorlagen, die den in den Ergebnissen aufgeführten Inhalt detaillierter beschreiben. Jedem Er-
gebnis sind Aufgaben und Rollen zugeordnet. Die Rollen geben einen Hinweis darauf, wie die
Verantwortung für Ergebnisse und die Beteiligung bei der Ergebniserstellung geregelt ist.
HERMES definiert minimal geforderte Dokumente (Ergebnisse), um die Anforderungen an die
Projekt-Governance zu erfüllen.
13 / 200
Projekt

Umsetzung
System
Ergebnisse
Studie Lösungsanforderungen Organisation

entwickelt/parametrisiert
Projekt- Organisationskonzept aktiviert Altsystem
Organisation
managementplan Systemkonzept System aktiviert entfernt
umgesetzt
Durchführungs- Lösungsarchitektur Abnahmeprotokoll
Anwendungshandbuch
auftrag
Nutzung
Abbildung 8: Ergebnisse stehen im Zentrum von HERMES
Die Abbildung 9 zeigt, dass zu Beginn und am Ende der Phasen Meilensteine stehen. Sie ent-
sprechen Quality Gates, an denen über Ergebnisse und das Vorgehen entschieden wird. Dabei
erfolgt auch die Abstimmung mit den strategischen Zielen und Vorgaben der Stammorgani-
sation. Analog zur Phasenfreigabe kann bei agiler Vorgehensweise optional eine Releasefrei-
gabe als erforderlich verlangt werden, was zu zusätzlichen Meilensteinen führt.
Durchführungs- Phasen- Phasen- Phasenfreigabe
Projekt-
freigabe freigabe freigabe Abschluss Projekt-
initialisierungs-
freigabe abschluss

Release 1 Release 2 Umsetzung Release n
Releasefreigabe Releasefreigabe
(optional) (optional)
Abbildung 9: Phasen und Releases mit Meilensteinen als Quality Gates
Alle Meilensteine sind Ergebnisse, die im Projektverlauf die Entscheidungspunkte markieren.

Jede Entscheidungsaufgabe endet somit mit einem Meilenstein. Je nach Modul gibt es ver-
schiedene Entscheide und folglich auch verschiedene weitere Meilensteine.
B.5 Aufgaben
Die Aufgaben dienen der Erarbeitung von Ergebnissen. Thematisch zusammengehörende Er-
gebnisse samt zugeordneten Aufgaben bilden Module.
Für jede Aufgabe gibt es eine Aufgabenbeschreibung. Sie definiert das generelle Vorgehen
und die Aktivitäten, die unternommen werden, um die Ergebnisse zu erarbeiten. Die Rollen
geben einen Hinweis darauf, welcher Rolle die Verantwortung für eine Aufgabe zugeordnet
ist.
B.6 Rollen
HERMES-Projektmanagement unterscheidet zwischen den Rollen der Stammorganisation und
Rollen der Projektorganisation, beschreibt jedoch ausschliesslich die HERMES-Rollen der Pro-
jektorganisation. Für jede Rolle gibt es eine Rollenbeschreibung mit Verantwortung, den Kom-
petenzen und den benötigten Fähigkeiten sowie mit ihren Beziehungen. Jede Rolle ist einer
der Hierarchieebenen Steuerung, Führung oder Ausführung zugeordnet. Es sind unterschied-
liche Rollen definiert, die nach Bedarf verwendet werden können.
In der Projektorganisation sind die Partnergruppen Anwender, Ersteller und Betreiber ver-
treten. Jede Rolle ist einer oder mehreren Partnergruppen zugeordnet.
14 / 200
Die Abbildung 10 zeigt eine Projektorganisation mit den minimal zu besetzenden, grau dar-
gestellten Rollen Auftraggeber, Projektleiter und Anwendervertreter.
Stammorganisation
Projektorganisation
Steuerung Auftraggeber
Führung Projektleiter
Ausführung Anwendervertreter
Abbildung 10: Minimal zu besetzenden Rollen Auftraggeber, Projektleiter und Anwendervertreter
B.7 Projektmanagement
HERMES-Projektmanagement (vgl. Kapitel A.2) ist eines der drei Methodenelemente der
ganzheitlichen HERMES-Methode.
15 / 200
C Datenmodell HERMES
Das konzeptionelle Datenmodell HERMES beschreibt die Daten und Informationen aus me-
thodischer Sicht und formuliert deren Struktur. Die Abbildung 11 zeigt das Diagramm des Da-
tenmodells. Das universell verwendbare Open-Source Datenmodell kann von jedermann frei
bezogen und für eigene Tools genutzt werden.
Method
1 Name[1]
Description[1] 1
Scenario
Name[1]
Unstructured[0..1] 1..* 1 Role
Applicability[0..1] Name[1]
PhasesAndMilestones[0..1] Unstructured[0..1]
Modules[0..1] 1..* Description[0..1]
Tasks[0..1] Phase Responsibility[0..1] RolePartner
Results[0..1] Competences[0..1] isMinimal[0..1]
Subchapter[0..1] Name[1]
Unstructured[0..1] Skills[0..1]
Focus[0..1] Hierarchylevel[0..1]
0..* Notes[0..1]
Description[0..1] 0..* Relationships[0..1]
Subchapter[0..1] 0..*
isMinimal[0..1] Partner
0..* Subchapter[0..1] Name[1]
1..* 0..* Description[0..1]
Module
Name[1]
Unstructured[0..1] 0..*
0..1 0..*
Purpose[0..1]
WhatToDo[0..1] 0..* ModuleTaskResult
Tasks[0..1]
Subchapter[0..1] 1..*
0..* 0..*
Task
Result
Name[1] 0..1 0..1
Unstructured[0..1] Name[1]
Purpose[0..1] Unstructured[0..1]
BasicIdea[0..1] isMinimal[0..1]
HERMES_specific[0..1] Description[0..1]
Basics[0..1] Descision[0..1]
Activities[0..1] 0..* 0..* Information[0..1]
Results[0..1] +basedOn Content[0..1]
Relationships[0..1] Relationships[0..1]
isDecision[0..1] DocumentTemplate[0..1]
Subchapter[0..1] Subchapter[0..1]
The HERMES data model

only exists in English
Abbildung 11: Diagramm des Datenmodells HERMES
Das Datenmodell wurde mittels INTERLIS7, einer bundeseigenen konzeptionellen Datenbe-

schreibungssprache erarbeitet. Mit diesem Datenmodell wird die HERMES-Kohärenz, d. h. die
einheitliche Struktur der Daten in einem Methodenelement festgelegt (z. B., jede Aufgabe ist
einem Modul zugeordnet). In einem Tool implementiert, erlaubt das INTERLIS Datenmodell
die Methoden-, aber auch die effektiven Projektdaten im entsprechenden Detailierungsgrad
speichern, anzeigen und auch generieren zu können.
Mit Hilfe des Datenmodells HERMES und der Beschreibungssprache INTERLIS sollen die an-
gestrebte Weiterentwicklung von neuen Methodenelementen, aber auch der Ausbau beste-
hender Methodenelemente, wie z. B. des vorliegenden Projektmanagements, vorangetrieben
werden.
7 INTERLIS ist eine Beschreibungssprache, mit der die langfristige Kompatibilität unter verschiedenen Systemen
gewährleistet werden soll. INTERLIS ist software- und systemunabhängig. INTERLIS 2 ist offiziell als Norm
SN 612031 publiziert.
16 / 200
1 Phasen
PHASEN
1.1 Einleitung
1.1.1 Projektlebenszyklus
Die HERMES-Projektmanagementmethode unterstützt mit ihrem Phasenmodell sowohl die
klassische als auch die agile Vorgehensweise. Das Phasenmodell für Projekte beruht auf dem
Lebenszyklus des Projekts. Für alle Projektbeteiligten schafft es die Voraussetzung für das ge-
meinsame Verständnis des Projektablaufs. Die Phasen bestimmen die Projektstruktur.
Die Abbildung 12 zeigt den HERMES-Projektlebenszyklus.

Umsetzung
Projekt
Abbildung 12: HERMES-Projektlebenszyklus
Der HERMES-Projektlebenszyklus wird unterteilt in Projektbeginn, Lösungsentstehung und

Projektende:
 Der Projektbeginn gilt der Ausrichtung des anvisierten Vorhabens nach Visionen, Bedürf-
nissen und Zielvorstellungen. Nicht selten stehen sowohl dringender Handlungsbedarf als
auch der Einfluss externer Einflüsse (Gesetzgeber, Politik, Staatsverträge, Verbandsregeln
usw.) oder übergeordneter Instanzen (Stammorganisation, Programm oder Portfolio) im
Fokus.
 Die Lösungsentstehung nach klassischer oder agiler Vorgehensweise erfolgt basierend auf
der Durchführungsfreigabe.
 Das Projektende schliesst das laufende Projekt organisatorisch und formell ab und bereitet
den Übergang zur Anwendungsorganisation vor.
1.1.2 Projektbeginn
Umsetzung
Im Projektbeginn ist stets die Phase Initialisierung angesiedelt. Die Abbildung 13 zeigt den
Ablauf der Initialisierung mit den wichtigsten Ergebnissen.
Projektsteuerung
Projektführung Projektgrundlagen
Projekt-
initialisierungs-
auftrag
Stakeholder-
liste
Rechts-
grundlagen- Schutzbedarfs- Beschaffungs-
Studie analyse analyse
analyse
Projektmana-
gementplan
Durchfüh-
rungsauftrag
Abbildung 13: Ergebnisdiagramm der Phase Initialisierung
17 / 200
In der Initialisierung werden die notwendigen projektspezifischen Grundlagen und die mögli-
chen Lösungsvarianten erarbeitet, verglichen und evaluiert. Die Wahl der Lösungsvariante be-
PHASEN
inhaltet auch den Entscheid, ob das Entwicklungsvorgehen agil oder klassisch abgewickelt
werden soll. Diese Entscheidung muss fachlich und vorgehenstechnisch begründet sein und
soll nicht bloss aktuellen Trends folgen. Der Vorgehensvorschlag wird aus den dem Projekt
vorliegenden Prämissen abgeleitet und durch die gewählte Lösungsvariante geprägt.
1.1.3 Lösungsentstehung
Umsetzung
Die klassische und die agile Vorgehensweise unterscheiden sich im Bereich der Lösungsent-
stehung durch das Entwicklungsvorgehen. Die Mehrzahl aller Methodenelemente ist in beiden
Vorgehensweisen annähernd identisch; unterschiedlich sind die Projektorganisation sowie die
Struktur des Projekts, folglich auch das Entwicklungsvorgehen und letztlich teilweise auch der
fachliche und formelle Inhalt der erarbeiteten Ergebnisse.
Im agilen Entwicklungsmanagement sind Änderungen ein fundamentaler Teil des Entwick-
lungsprozesses. Das Entwicklungsteam folgt der vorgegebenen und gewünschten Wirkung
und reagiert proaktiv auf die sich ändernden Anforderungen, anstatt einen fixen Plan zu ver-
folgen. Die Entwicklung und die Einführung erfolgen iterativ-inkrementell. Eine Phasenstruktur
macht in diesem Vorgehen keinen Sinn. Deshalb kann die Phase Umsetzung auch nicht weiter
unterteilt werden.
Je nachdem, welche Vorgehensweise gewählt wird, wird nach einer Durchführungsfreigabe
die Lösungsentstehung des Projekts entweder
 klassisch
mit den Phasen Konzept, Realisierung und Einführung, oder
 agil
mit der Phase Umsetzung fortgesetzt
und unabhängig der Vorgehensweise8 mit der Phase Abschluss beendet.
Die Schnittstellen zur Stammorganisation bleiben weitgehend die gleichen, ebenfalls die beim
Projektabschluss benötigten Unterlagen.
1.1.4 Projektende
Umsetzung
Im Projektende ist stets die Phase Abschluss angesiedelt. Es ist die letzte Phase jedes Projekts
in der das Projekt endgültig beendet wird. Das wichtigste Augenmerk gilt der Projektdoku-
mentation, die entsprechend geprüft und insbesondere aus formeller Sicht, sofern ange-
bracht, ergänzt und geordnet wird. Zudem werden in dieser Phase der organisatorische und
administrative Übergang von der Projektorganisation zur Anwendungsorganisation geregelt,
die alten Systeme werden deaktiviert oder entfernt, sämtliche Projektdaten gemäss Bestim-
mungen der Stammorganisation der Archivierung zugeführt und ggf. die Verantwortung für
die Lösung weitergegeben.
Die Phase Abschluss verfolgt insbesondere den Zweck sicherzustellen, dass die organisatori-
schen und administrativen Übergabe- und Übergangsschnittstellen des Projekts (gegenüber
der Stammorganisation, dem Programm, dem Portfolio, der Anwendungsorganisation, allen-
falls der Betriebsorganisation usw.) unabhängig der gewählten Vorgehensweise identisch blei-
ben.
8 Hybride Vorgehensweise wird als Spezialfall im Kapitel 7 thematisiert.
18 / 200
1.2 Übersicht der Phasen
PHASEN
1.2.1 HERMES-Phasenmodell
Da verschiedene Arten von Projekten in unterschiedlichen Stammorganisationen auf diversen
Hierarchie- und Entscheidungsebenen mit klassischer und agiler Vorgehensweise zum Einsatz
kommen, ist das HERMES-Phasenmodell auf entsprechend hohe Anforderungen ausgerichtet.
Die Abbildung 14 stellt das Phasenmodell für Projekte mit klassischer und agiler Vorgehens-
weise grafisch dar.
klassisch
agil
Umsetzung
Abbildung 14: HERMES-Phasenmodell für klassische und agile Vorgehensweise
Das Phasenmodell
 reflektiert gegenüber der Stammorganisation stets die gleiche Projektstruktur und ermög-
licht einheitliche Schnittstellen,
 deckt die gängigen Controlling- und Reportinganforderungen des Managements,
 fügt sich unabhängig der gewählten Vorgehensweise vollständig in eine klassisch oder
agil organisierte Stammorganisation ein,
 nutzt Synergien und vermeidet jegliche Redundanzen und
 ist einfach anwendbar.
Die Tabelle zeigt das Phasenmodell mit klassischem und agilem Entwicklungsvorgehen:
HERMES-Phasen Projektlebenszyklus HERMES-Phasen
klassische Entwicklung agile Entwicklung
Initialisierung Projektbeginn Initialisierung
Konzept
Realisierung Lösungsentstehung Umsetzung
Einführung
Abschluss Projektende Abschluss
Tabelle 1: HERMES-Phasen für Projekte mit klassischer und agiler Lösungsentstehung
1.2.2 Einheitliche Projektstruktur

Die erste und die letzte Phase des Projekts haben alle Vorhaben stets gemeinsam. Ein Projekt
beginnt mit der Phase Initialisierung und endet mit der Phase Abschluss. Dadurch wird die
Einheitlichkeit der Projektstruktur und des Projektlebenszyklus gewährleistet. Die Projekt-
schnittstellen zur Stammorganisation, Controlling, Programm, Portfolio usw. werden unge-
achtet der Vorgehensweise gleichgeschaltet. Die Übergänge zur Anwendungs- und Betriebs-
organisation werden einheitlich kanalisiert.
Die Projektstruktur wird zusätzlich durch die im Kapitel 4 beschriebenen Meilensteine unter-
stützt. Sie markieren im Projektverlauf wichtige Entscheidungsergebnisse der Projektsteue-
rung und -führung. Wie in Abbildung 15 ersichtlich, stehen am Anfang und am Ende jeder
Phase Meilensteine. Bei jeder Freigabe werden die Ressourcen (finanziell, personell, Infrastruk-
tur) für die nächste Phase durch den Auftraggeber freigegeben. Optional können für die agile
Phase Umsetzung weitere Meilensteine für die Releasefreigabe festgelegt werden.
Durchführungs- Phasen- Phasen- Phasenfreigabe
Projekt-
freigabe freigabe freigabe Abschluss Projekt-
initialisierungs-
freigabe abschluss

Release 1 Release 2 Umsetzung Release n
Releasefreigabe Releasefreigabe
(optional) (optional)
Abbildung 15: Meilensteine am Beginn und am Ende jeder Phase und bei der Releasefreigabe
19 / 200
Diese projektstrukturbezogenen Meilensteine entsprechen Quality Gates, vor deren Errei-
chung über Ergebnisse und das Vorgehen entschieden wird. Dabei werden die Einhaltung der
PHASEN
Vorgaben sowie die Übereinstimmung des Projekts mit den strategischen Zielen der Stam-
morganisation überprüft.
1.2.3 Phasenverlauf
Die Phase Initialisierung bildet eine Grundlage für die Planung und Steuerung des Projekts.
Im Anschluss an die Phase Initialisierung folgt die Lösungsentstehung, entweder mit den klas-
sischen Phasen Konzept, Realisierung und Einführung oder mit der agilen Phase Umsetzung.
Die Phase Umsetzung umfasst das agile Entwicklungsvorgehen und dient der Einbettung einer
beliebigen agilen Entwicklungsmethode in das HERMES-Framework
Die Phase Abschluss bietet Raum für alle notwendigen Massnahmen in Verbindung mit der
Entfernung der alten abgelösten Produkt- oder Systemumgebung inklusive der nicht mehr
benötigten Infrastruktur und für das systematische Herunterfahren des Projekts samt allen
administrativen und organisatorischen Massnahmen.
Entlang der Phasen gibt es weitere, einen erfolgreichen Verlauf bestimmende Entscheide mit
entsprechenden spezifischen Meilensteinen. Diese Meilensteine variieren je nach der Art des
Vorhabens. Die Abbildung 16 zeigt als Beispiel die Meilensteine der Steuerung sowie der Füh-
rung für klassische und agile IT-Entwicklungsprojekte.
Steuerung
Projekt-
Durchführungs- Phasen- Phasen- Betriebs- Phasenfreigabe Projekt-
initialisierungs-
freigabe freigabe freigabe aufnahme Abschluss abschluss
freigabe
Weiteres Lösungs- ISDS- Vorab- Abnahme

Abnahme
Vorgehen architektur Konzept nahme Migration
klassisch Führung
Steuerung
Projekt-
Durchführungs- Releasefreigabe Releasefreigabe Phasenfreigabe Projekt-
initialisierungs-
freigabe (optional) (optional) Betriebs- Abschluss abschluss
freigabe
aufnahme
Initialisierung Release 1 Release 2 Umsetzung Release z Abschluss
pro Release
Weiteres Release n
Vorgehen
Lösungs- ISDS- Vorab- Abnahme

Abnahme
architektur Konzept nahme Migration
agil Führung
Abbildung 16: Meilensteine für klassische und agile IT-Entwicklungsprojekte
Beim Meilenstein Weiteres Vorgehen, aber auch bei weiteren Meilensteinen, wird die Errei-
chung der Nachhaltigkeitsziele (vgl. Kapitel 7) als Bewertungskriterium mitberücksichtigt.
Entlang des gesamten Projektverlaufs erfolgt das Reporting im Einklang mit den Vorgaben
der Stammorganisation bezüglich des Inhalts und soweit machbar auch bezüglich der Fre-
quenz der Rapporte (vgl. Kapitel 7).
20 / 200
1.3 Erläuterung der Phasenbeschreibung
PHASEN
Für jede Phase gibt es eine Phasenbeschreibung, die stets gleich aufgebaut ist:
 Umschreibung der Phase, hervorgehobene Schrift
 Aufzählung wichtiger Punkte und grobe Beschreibung dessen, was im Verlauf der Phase
zu erledigen ist
 Umschreibung des Phasenabschlusses, hervorgehobene Schrift
1.4 Beschreibung der Phasen

1.4.1 Projektbeginn
1.4.1.1 Initialisierung
Umsetzung
Die Phase Initialisierung wird unabhängig von der späteren Vorgehensweise in jedem
Fall durchgeführt. Sie schafft eine definierte Ausgangslage für eine mögliche Lösungs-
entstehung und den darauffolgenden Projektabschluss. Sie stellt sicher, dass die gesetz-
ten Ziele mit den Vorgaben der Organisation abgestimmt sind. Die Projektgrundlagen
und der Durchführungsauftrag werden erarbeitet.
 Auf der Grundlage des Projektinitialisierungsauftrags gibt der Auftraggeber die Ressour-
cen für die Phase Initialisierung frei. Er beauftragt den Projektleiter mit der Durchführung
der Phase Initialisierung.
 Die Phase Initialisierung wird aus Projektmanagementsicht stets klassisch abgewickelt.
Dennoch können auch agile Werkzeuge zum Einsatz kommen.
 Die Studie wird erarbeitet.
o Die Arbeiten starten mit einer ersten Standortbestimmung, Zielen und groben Anfor-
derungen.
o Die Lösungsvarianten werden erarbeitet. Die Beschreibung der Lösungsvarianten er-
folgt so detailliert, dass sie nachvollziehbar und transparent bewertet werden können.
o Unter anderem werden auch die Projekt- und Betriebsrisiken ermittelt.
o Parallel zur Studie werden die Rechtsgrundlagenanalyse und die Schutzbedarfsanalyse
erarbeitet und in die Entscheidung einbezogen.
o Zusätzlich wird festgelegt und nachvollziehbar dokumentiert, wie im Rahmen jeder
Lösungsvariante weiter vorgegangen wird: entweder klassisch oder agil.
o Der Entscheid Weiteres Vorgehen wird getroffen.
 Für die allfällige Beschaffung eines Produkts bzw. eines Systems wird parallel zur Studie
eine Beschaffungsanalyse durchgeführt.
 Das für die Lösungsentstehung passende Szenario wird ausgewählt und bei Bedarf indivi-
dualisiert.
 Auf der Basis der gewählten Variante und des Vorgehens werden der Projektmanage-
mentplan und der Durchführungsauftrag erarbeitet und mit den Strategien, Vorgaben und
übergeordneten Zielen der Stammorganisation abgeglichen. Die Stakeholderinteressen
werden analysiert und Zielkonflikte bereinigt.
 Bei anvisierter agiler Vorgehensweise wird festgelegt, ob der optionale Entscheid Relea-
sefreigabe treffen im Projekt als erforderlich vorgeschrieben ist.
 Der Entscheid Durchführungsfreigabe wird getroffen und der Durchführungsauftrag un-
terschrieben. Die Freigabe erfolgt durch die Stammorganisation und den Auftraggeber.
Am Ende der Phase Initialisierung wird geprüft, ob es sinnvoll ist, die Fortsetzung des
Projekts freizugeben und sofern ja, wird der Entscheid Durchführungsfreigabe getroffen.
Mögliche Gründe für eine Beendigung sind fehlende Wirtschaftlichkeit, zu hohe Risiken,
keine Realisierbarkeit, rechtliche oder politische Bedenken, fehlende Übereinstimmung
mit den Zielen, Strategien und Prioritäten der Organisation.
21 / 200
1.4.2 Lösungsentstehung klassisch
PHASEN
1.4.2.1 Konzept
Umsetzung
Die in der Phase Initialisierung gewählte Variante wird konkretisiert. Die Ergebnisse wer-
den so detailliert erarbeitet, dass die Projektbeteiligten die Lösung auf einer verlässlichen
Grundlage planen, offerieren und realisieren können.
 Basierend auf der gewählten Variante sowie der ersten Standortbestimmung aus der Stu-
die werden die Situationsanalysen durchgeführt.
 Gestützt auf die Erkenntnisse aus den Situationsanalysen werden die Anforderungen aus
der Studie konkretisiert und vervollständigt und neu als Lösungsanforderungen festgelegt.
 Bei Organisations- und IT-Projekten oder wenn durch die Lösung Geschäftsabläufe oder
-strukturen tangiert werden, sind in jedem Fall die Organisationsanforderungen und an-
schliessend das Organisationskonzept zu erarbeiten.
 Die Lösung wird konzeptionell erarbeitet. Die Machbarkeit, allenfalls nur einzelner Lö-
sungskomponenten, wird z. B. mit Prototypen überprüft.
 Zur Vorbereitung der Einführung wird das Einführungskonzept erarbeitet.
 Je nach Szenario werden Testkonzept und Migrationskonzept erarbeitet.
 In IT-Projekten werden zudem die Lösungsarchitektur und das Betriebskonzept erarbeitet.
Der Entscheid Lösungsarchitektur wird getroffen.
 Ist eine Lösung zu beschaffen, werden die Ausschreibung durchgeführt, die Angebote be-
wertet sowie das ausgewählte Produkt oder System beschafft.
 Bei Systemen wird das Integrationskonzept erarbeitet.
 Der Entscheid über die Freigabe der Realisierung wird getroffen (Entscheid Phasenfreigabe
treffen).
o Die Projekt- und Betriebsrisiken müssen identifiziert, analysiert und bewertet sein.
o Die Realisierbarkeit der Lösungsentstehung muss weiterhin nachgewiesen bzw. bestä-
tigt sein.
o Die Ressourcen für die nächste Phase werden aufgrund des konkretisierten Projekt-
managementplans und der vorliegenden Angebote freigegeben.
Am Ende der Phase Konzept wird geprüft, ob es sinnvoll ist, das Projekt zu realisieren.
Mögliche Gründe für eine Beendigung sind Unwirtschaftlichkeit, zu hohe Risiken, feh-
lende Realisierbarkeit, fehlende Übereinstimmung mit den Zielen und Strategien der Or-
ganisation.
1.4.2.2 Realisierung
Umsetzung
Das Produkt bzw. das System wird realisiert und getestet. Die nötigen Vorarbeiten wer-
den geleistet, um die Einführungsrisiken zu minimieren.
 Das Produkt bzw. das System wird entwickelt oder, sofern es beschafft wurde, parametri-
siert bzw. angepasst.
 Die Organisation wird umgesetzt.
 In IT-Projekten wird das System in die Betriebsinfrastruktur integriert.
 Die Vorabnahme wird durchgeführt.
 Die Betriebsorganisation wird realisiert und die Dokumentationen erarbeitet.
 Die Einführung wird auf der Grundlage des Einführungskonzepts vorbereitet.
 Je nach Szenario werden Tests durchgeführt und die Migration vorbereitet.
 Der Entscheid über die Freigabe der Einführung wird getroffen (Entscheid Phasenfreigabe
treffen). Er basiert auf dem Entscheid Vorabnahme. Die Ressourcen für die nächste Phase
werden aufgrund des konkretisierten Projektmanagementplans freigegeben.
Am Ende der Phase Realisierung müssen die Einführungsrisiken beurteilt werden und
vertretbar sein. Andernfalls kann die Einführung nicht erfolgen.
22 / 200
1.4.2.3 Einführung
PHASEN
Umsetzung
In der Phase Einführung wird der sichere Übergang zum neuen Zustand gewährleistet.
Der Betrieb wird aufgenommen.
 Die Einführungsmassnahmen wie Anwenderschulung usw. werden durchgeführt.
 Je nach Szenario wird eine Migration durchgeführt.
 Das Produkt bzw. das System sowie die Organisation werden aktiviert.
 Der Betrieb wird aktiviert.
 ISDS-Konzept wird überführt.
 Während der ersten Betriebszeit zwischen der Betriebsaufnahme und der Abnahme des
vollständigen Systems oder Produkts unterstützt das Projekt die Problemanalyse und die
Problembehebung (danach beginnt die Gewährleistung und damit der reguläre Betrieb).
 Der Entscheid Phasenfreigabe Abschluss wird getroffen. Die Ressourcen für die Phase Ab-
schluss werden aufgrund des nachgeführten Projektmanagementplans freigegeben.
Am Ende der Phase Einführung wird nach erfolgreicher Betriebsaufnahme der Entscheid
Abnahme getroffen und die Phase wird abgeschlossen.
1.4.3 Lösungsentstehung agil

1.4.3.1 Umsetzung
Umsetzung
Die in der Phase Initialisierung gewählte Variante wird iterativ-inkrementell umgesetzt.

Die Projektorganisation wird inklusive Entwicklungsteam etabliert. Die Lösungsanforde-
rungen werden weiter aufgeteilt, verfeinert und konkretisiert. Die Anforderungen wer-
den aktualisiert und priorisiert und nach absteigender Priorität abgearbeitet (entwickelt,
realisiert und in Betrieb genommen), wobei die Prioritäten kontinuierlich aktualisiert und
den Projekterkenntnissen entsprechend angepasst werden.
 Basierend auf der gewählten Variante sowie der Standortbestimmung aus der Studie wer-
den die Situationsanalysen durchgeführt.
 Mit den Erkenntnissen aus den Situationsanalysen werden die Anforderungen aus der Stu-
die konkretisiert und vervollständigt und neu als priorisierte initiale Lösungsanforderungen
festgelegt.
 Werden durch die angestrebte Lösung Geschäftsabläufe oder -strukturen tangiert, sind
zwingend die Organisationsanforderungen zu erarbeiten.
 Ist eine Lösung zu beschaffen, werden die Ausschreibung durchgeführt, die Angebote be-
wertet sowie das ausgewählte Produkt oder System beschafft.
 Mit jeder Iteration wird ein weiterer Teil der Lösung – das Inkrement – erstellt, das sich mit
dem bereits erstellten Umfang der Umsetzungsergebnisse nahtlos verbinden lässt.
Iterativ-inkrementelle Durchführung:
o Die einzelnen Anforderungen der Lösungsanforderungen werden laufend konkreti-
siert, verfeinert, vervollständigt und soweit aufgeteilt und priorisiert, dass sie in abstei-
gender Priorität abgearbeitet werden können.
o Es wird das Organisationskonzept erarbeitet und die sukzessive entstehende Organi-
sation realisiert und dokumentiert.
o Die Projekt-, Betriebs- und Einführungsrisiken werden identifiziert, analysiert, bewertet
und beurteilt. Die Realisierbarkeit wird überprüft.
o Das Produkt wird entwickelt oder angepasst bzw. das System entwickelt oder para-
metrisiert.
o Begleitend werden die Betriebsorganisation und alle anderen Ergebnisse der restlichen
Module sukzessive erarbeitet, realisiert und dokumentiert.
o Bei Systemen wird das Integrationskonzept erarbeitet und der Entscheid Lösungsar-
chitektur getroffen.
23 / 200
o Bei Systemen werden Tests konzipiert und durchgeführt, die Migration vorbereitet und
durchgeführt und das System in die Betriebsinfrastruktur integriert.
PHASEN
o Das Einführungskonzept wird erarbeitet sowie die Vorabnahme, die Einführungsmass-

nahmen wie Anwenderschulung usw. und die Betriebsaufnahme durchgeführt.
o Die Organisation, der betreffende Teil der Lösung (ein oder mehrere Inkremente) so-
wie der Betrieb werden aktiviert.
 Während der ersten Betriebszeit bis zu der Abnahme des Teils der Lösung unterstützt das
Projekt die Problemanalyse und die Problembehebung (danach beginnt die Gewährleis-
tung und damit der reguläre Betrieb).
 Falls im Projektmanagementplan so festgelegt, wird der Entscheid über die Freigabe des
nächsten Release getroffen (Entscheid Releasefreigabe treffen).
 Der Entscheid Phasenfreigabe Abschluss wird getroffen. Die Ressourcen für die Phase Ab-
schluss werden aufgrund des nachgeführten Projektmanagementplans freigegeben.
Nach abgeschlossener Betriebsaufnahme inklusive der Abnahme des letzten Release
werden der agile Teil des Projekts und somit die Phase Umsetzung abgeschlossen und
das Entwicklungsteam in der Projektorganisation aufgelöst.
1.4.4 Projektende
1.4.4.1 Abschluss
Umsetzung
Die Phase Abschluss bietet eine Struktur für das systematische Herunterfahren eines Pro-
jektes. Die Projektdokumentation wird geprüft und je nach Bedarf ergänzt. Der Projekt-
abschluss wird vorbereitet.
 Die Phase Abschluss wird aus Projektmanagementsicht stets klassisch abgewickelt. Den-
noch können auch agile Werkzeuge zum Einsatz kommen.
 Die Ergebnisse werden auf Vollständigkeit geprüft und insbesondere aus formeller Sicht
ergänzt.
 Die Projektschlussbeurteilung wird geprüft und ggf. genehmigt.
 Die Projektorganisation wird aufgelöst. Vor der Auflösung kann geprüft werden, ob Teile
der Projektorganisation sinngemäss in die Anwendungsorganisation übernommen wer-
den können.
 Die Ergebnisse, Dokumentationen usw. werden an die Stammorganisation z.H. der An-
wendungs-, Betriebs- und Wartungsorganisation übergeben. In IT-Projekten betrifft dies
beispielsweise auch die Testinfrastruktur samt Testkonzept und die Hilfsmittel.
 Die Dokumentation der Projektabwicklung inklusive der Vorgehensergebnisse usw. wird
gemäss den Ablagevorschriften der Stammorganisation archiviert.
 Das Altsystem wird je nach Szenario ausser Betrieb gesetzt und unter Berücksichtigung
der Vorgaben inklusive der alten, nicht mehr benötigten Infrastruktur entfernt, die alten
Daten werden archiviert oder vernichtet.
Am Ende der Phase Abschluss wird der Projektabschluss durchgeführt. Die Projekt-
schlussbeurteilung wird erarbeitet. Offene Punkte werden an die Stammorganisation so-
wie an die Anwendungsorganisation übergeben. Das Projekt wird abgeschlossen und die
Projektorganisation aufgelöst.
24 / 200
2 Szenarien
2.1 Einleitung
In einer Stammorganisation werden verschiedenartige Projekte durchgeführt. Die Projekte
können sich bezüglich Inhalt und Komplexität stark unterscheiden.
Um der Vielfalt der Projekte gerecht zu werden, bietet HERMES unterschiedliche Szenarien
an. Ein Szenario ist auf die Durchführung von Projekten mit einer spezifischen Charakteristik
SZENARIEN
ausgerichtet, beispielsweise für die Entwicklung oder Adaption einer IT-Lösung.
Wie die Abbildung 17 zeigt, bildet ein Szenario die komplette Lösungsentstehung eines Pro-
jekts ab und unterstützt den Projektleiter bei der Durchführungsplanung. Die Erkenntnisse der
Studie sind ausschlaggebend für die Auswahl des passenden Standardszenarios. Die Phasen
Initialisierung und Abschluss sind kein Bestandteil eines Szenarios.
Lösungsentstehung
Weiteres Szenario 1
Vorgehen
oder
Szenario 2
? oder
Initialisierung Szenario 2 Abschluss
oder
Szenario 5
oder
Szenario x
Abbildung 17: Wahl und Anwendung des für das Projekt geeigneten Szenarios
Ein Szenario beinhaltet standardmässig diejenigen Methodenelemente, die üblicherweise für

Projekte der jeweiligen Charakteristik von Bedeutung sind. Dadurch ist HERMES rasch und
einfach anwendbar.
Der Projektleiter kann Standardszenarien an die Bedürfnisse der Stammorganisation sowie
des konkret vorliegenden Projektes anpassen und weitere individuelle Szenarien erstellen.
2.2 Übersicht der Szenarien

2.2.1 Aufbau der Szenarien
Szenarien basieren auf Modulen mit thematisch zusammengehörenden Aufgaben und Ergeb-
nissen. Die Abbildung 18 zeigt, wie mit Hilfe der Module B und N sowie eines Teils des Mo-
duls A ein Szenario gebildet werden kann.
Szenario

Umsetzung
Modul A
Modul B
Modul N
Ergebnisse
Aufgaben
Abbildung 18: Mehrere Module mit Aufgaben und Ergebnissen als Basis für ein Szenario
25 / 200
Die Szenarien sind auf die Entwicklung von Lösungen mit einer spezifischen Charakteristik
ausgerichtet und nutzen daher diejenigen Module, die für die Lösungsentstehung relevant
und geeignet sind. Dabei kann ein Modul in mehreren Szenarien verwendet oder, weil ein
Modul umfassender sein kann als ein Szenario, in einem Szenario nur zum Teil genutzt wer-
den. Und da sich die Module aus den entsprechenden Aufgaben und Ergebnissen zusam-
mensetzen, liegt je Szenario eine abgestimmte Lösungsentstehungsvorlage inklusive der not-
wendigen Dokumentvorlagen vor.
Ein Szenario beschreibt ausschliesslich die Lösungsentstehung; die Phasen Initialisierung und
Abschluss befinden sich ausserhalb des Szenarios.
SZENARIEN
2.2.2 Standardszenarien
HERMES bietet fünf Standardszenarien für Projekte mit verschiedenen Charakteristiken an:
 Dienstleistung/Produkt Entwicklung
 Dienstleistung/Produkt Adaption
 IT-Entwicklung
 IT-Adaption
 Organisationsanpassung
Die nachfolgende Tabelle zeigt pro Szenario die verwendeten Module kontextgerecht auf. Die
ersten vier Szenarien können sowohl für das klassische, als auch das agile Entwicklungsvorge-
hen gewählt werden. Das Szenario Organisationsanpassung ist als ein klassisches Szenario
angedacht. Will man es agil verwenden, muss das Szenario mittels Tailoring 9 entsprechend
erweitert werden.
Projektführung
Einführungsor-
Module
Projektsteue-
Organisation
IT-Migration
Beschaffung
ganisation
IT-System
IT-Betrieb
Produkt
Tests
rung
ISDS
Szenario
Dienstleistung/Produkt Entwicklung X X X X X
Dienstleistung/Produkt Adaption X X X X X X
IT-Entwicklung X X X X X X X X X
IT-Adaption X X X X X X X X X X
Organisationsanpassung X X X X
Tabelle 2: Standardszenarien für Projekte verschiedener Charakteristiken samt Modulen
Das Angebot der Standardszenarien ist nicht abschliessend. Die Nachfrage bezüglich neuer
Szenarien wird periodisch überprüft und bei Bedarf werden weitere Standardszenarien bereit-
gestellt.
2.2.3 Individuelle Szenarien

2.2.3.1 Anpassung der Szenarien
Es besteht die Möglichkeit, ein bestehendes Szenario anzupassen oder sein eigenes, individu-
elles Szenario zu erstellen. HERMES bietet dazu zwei Möglichkeiten, die in folgender Reihen-
folge kombiniert angewendet werden können:
 Sizing
 Tailoring
9 Die Auswahl von neuen, oder das Weglassen von vorhandenen Aspekten und Komponenten, die im konkreten
Vorhaben benötigt bzw. nicht benötigt werden. Auf das Projektmanagement übertragen bedeutet es hier das
manuelle fach- und inhaltspezifische Erweitern oder Zuschneiden des Projekts.
26 / 200
2.2.3.2 Sizing
HERMES-Projektmanagement ist als Grundlage für Projekte mit hoher Wertigkeit angelegt,
um die Vollständigkeit der Information und der Methode an sich zu gewährleisten. Diese
Breite passt allerdings nicht zu jedem Vorhaben. Da viele Stammorganisationen vorwiegend
nur mittlere und kleine Projekte führen, sollte deshalb die Anwendung der Methode an die
Grösse des Vorhabens angepasst werden. Da Tailoring, das manuelle fach- und inhaltspezifi-
sche Zuschneiden des Projekts, nach einer Dimensionierung selten zum gewünschten Ergeb-
nis führt, bietet HERMES-Online die Funktionalität Sizing an. Der Einsatz von Sizing soll die
Komplexität des Vorgehens und den Umfang der Dokumentation so tief wie möglich halten
SZENARIEN
und die Dokumentationsaufwendungen auf das absolute Muss reduzieren.
Sizing richtet sich nach der "Grösse" des anzugehenden Vorhabens oder dessen Wertigkeit.
Die Wertigkeit wird aus einer Kombination von Durchlaufzeit, Aufwand oder Kosten, Grösse
des Projektteams, Stakeholder-Struktur, politischer Auswirkung, Vertraulichkeitsstufe, rechtli-
cher Relevanz usw. ermittelt. Sie zeigt die Relevanz des Vorhabens oder nur eines Teils des
Vorhabens gegenüber anderen projektierten Vorhaben und den daraus resultierenden An-
spruch an den Detaillierungsgrad der Dokumentation. Dies unabhängig davon, ob diese Pro-
jekte z. B. in einem Programm zusammengefasst oder Teil eines Portfolios sind.
Entsprechend der in der Initialisierungsphase ermittelten Wertigkeit werden umfangreiche
oder reduzierte Szenarien sowie die dazugehörige Dokumentation generiert. Diese online-
tool-gestützte Anpassung garantiert die Methoden-Kontinuität und -Kohärenz und erlaubt
alle Vorhaben entsprechend schlank abzuwickeln.
Eine anschliessende manuelle Anpassung der "redimensionierten" Szenarien an die jeweiligen
Projektbedürfnisse mittels Tailoring ist danach immer noch möglich.
2.2.3.3 Tailoring
Mit dem Tailoring werden Standardszenarien oder bereits durch die Sizing-Funktion erstellte
individuelle Szenarien an die jeweiligen Projektbedürfnisse angepasst und weiter individuali-
siert. Dies kann auch mittels HERMES-Online erfolgen.
Es gibt dazu vier grundlegende Möglichkeiten, die kombiniert angewendet werden können:
1. Module aus einem bestehenden Szenario entfernen:
Nicht benötigte Module werden entfernt.
 Beispiel:
In einem Szenario mit Modul Beschaffung das Beschaffungsmodul deaktivieren.
2. Aufgaben und Ergebnisse entfernen:
Der Inhalt eines Moduls kann mit Ausnahme von minimal geforderten Dokumenten um
Ergebnisse und dazugehörige Aufgaben wahlweise reduziert werden.
3. Ein zusätzliches, fachspezifisches Modul im bestehenden Szenario integrieren:
Es wird ein eigenes Modul mit fachspezifischem Inhalt – mit bestehenden oder mit neuen
individuellen Aufgaben und Ergebnissen – erstellt und in ein Szenario integriert.
4. Aufgaben und Ergebnisse hinzufügen:
Der Inhalt eines Moduls kann erweitert werden. Neue individuelle Aufgaben und Ergeb-
nisse können erstellt werden.
Mit diesen Möglichkeiten lassen sich weitere individuelle, projekt- oder organisationsspezifi-
sche Szenarien einfach abbilden. Abbildung 19 zeigt, wie mehrere Projekte einer Stammorga-
nisation mit unterschiedlichen Szenarien gleichzeitig nebeneinander abgewickelt werden kön-
nen.
27 / 200
Vorhaben Projekte einer Stammorganisation mit Szenarien
Beschaffung Projekt 1 Initialisierung IT-Adaption Abschluss

GEVER-System
Projekt 2 Initialisierung Dienstleistung/Produkt Entwicklung Abschluss

Service public
"Guichet Virtuel"
Projekt 3 Initialisierung IT-Entwicklung Abschluss
Infrastruktur
Hosting Services Projekt 4 Initialisierung IT-Entwicklung Abschluss
SZENARIEN
Fusion der
Bereiche A & B Projekt 5 Initialisierung Organisationsanpassung Abschluss
Rechtsetzung Projekt n Initialisierung Individuelles Szenario "abc" Abschluss
Abbildung 19: Anwendung von Standard- und benutzerdefinierten Szenarien
Individuelle Szenarien können untereinander mit anderen HERMES-Anwendern ausgetauscht

oder für alle Anwender zur Verfügung gestellt werden. Weitere Informationen dazu enthält die
HERMES-Website.
2.3 Erläuterung der Szenario-Beschreibung

Für jedes Szenario gibt es eine Szenario-Beschreibung, die stets gleich strukturiert ist:
 Anwendbarkeit
beschreibt konkrete Projektkriterien, für die sich das Szenario eignet.
 Module
zählen auf und stellen graphisch dar alle Module des Szenarios entlang der Lösungsent-
stehung – das Modul Projektgrundlagen sowie Teile anderer Module, die ausserhalb der
Lösungsentstehung zum Einsatz kommen und somit in keinem Szenario vorkommen, sind
weiss schattiert dargestellt.
2.4 Szenarien-Verzeichnis
2.4.1 Dienstleistung/Produkt-Szenarien
2.4.1.1 Dienstleistung/Produkt Entwicklung
Anwendbarkeit
Das Szenario Dienstleistung/Produkt Entwicklung unterstützt die Durchführung jener Projekte,
in denen eine Dienstleistung oder ein Produkt entwickelt und bereitgestellt wird.
Beispiele:
 Entwicklung von Ausbildungsunterlagen und Lehrgängen zu einem bestimmten Thema
 Entwickeln eines internen Standards
 Aufbau eines Lieferdienstes
Module
Das Szenario Dienstleistung/Produkt Entwicklung basiert auf folgenden, in der Abbildung 20
aufgeführten Modulen:
 Projektsteuerung  Produkt
 Projektführung  Einführungsorganisation
 Organisation
28 / 200
klassisch Konzept Realisierung Einführung
agil Umsetzung
Steuerung Projektsteuerung
Führung Projektführung
Ausführung Projektgrundlagen
SZENARIEN
Organisation
Produkt
Einführungsorganisation
Abbildung 20: Module im Kontext des Szenarios Dienstleistung/Produkt Entwicklung
Bei Bedarf kann das Modul Tests ebenfalls im Szenario eingebettet werden. Dadurch wird die
Organisation und Durchführung des Testens von Lösungen ermöglicht.
2.4.1.2 Dienstleistung/Produkt Adaption

Anwendbarkeit
Das Szenario Dienstleistung/Produkt Adaption unterstützt die Durchführung jener Projekte,
in denen ein im Markt verfügbares Produkt oder eine Dienstleistung beschafft, angepasst und
in die Organisation integriert wird.
Module
Das Szenario Dienstleistung/Produkt Adaption basiert auf folgenden, in der Abbildung 21 auf-
geführten Modulen:
 Projektsteuerung  Organisation
 Projektführung  Produkt
 Beschaffung  Einführungsorganisation

agil Umsetzung
Beschaffung
Organisation
Produkt
Abbildung 21: Module im Kontext des Szenarios Dienstleistung/Produkt Adaption
Bei Bedarf kann das Modul Tests ebenfalls im Szenario eingebettet werden. Dadurch wird die
Organisation und Durchführung des Testens von Lösungen ermöglicht.
29 / 200
2.4.2 Informatik-Szenarien
2.4.2.1 IT-Entwicklung
Anwendbarkeit
Das Szenario IT-Entwicklung unterstützt die Durchführung jener Projekte, in denen eine neue
IT-Lösung für die spezifischen Bedürfnisse eines oder mehrerer Fachbereiche oder auch or-
ganisationsübergreifend (Anwenderbedürfnisse) entwickelt oder eine bestehende IT-Lösung
weiterentwickelt und sowohl technisch als auch organisatorisch integriert wird.
SZENARIEN
Module
Das Szenario IT-Entwicklung basiert auf folgenden, in der Abbildung 22 aufgeführten Modu-
len:
 Projektsteuerung  Einführungsorganisation
 Projektführung  IT-Migration
 Organisation  IT-Betrieb
 IT-System  ISDS
 Tests

agil Umsetzung
Organisation
IT-System
Tests
IT-Migration
IT-Betrieb
ISDS
Abbildung 22: Module im Kontext des Szenarios IT-Entwicklung
2.4.2.2 IT-Adaption
Anwendbarkeit
Das Szenario IT-Adaption unterstützt die Durchführung jener Projekte, in denen eine im Markt
verfügbare IT-Lösung (z. B. Standardsoftware oder IT-Infrastruktur) beschafft, angepasst und
sowohl technisch als auch organisatorisch integriert wird.
Module
Das Szenario IT-Adaption basiert auf folgenden, in der Abbildung 23 aufgeführten Modulen:
 Projektsteuerung  Tests
 Beschaffung  IT-Migration
 Organisation  IT-Betrieb
 IT-System  ISDS
30 / 200
agil Umsetzung
SZENARIEN
Beschaffung
Organisation
IT-System
Tests
IT-Migration
IT-Betrieb
ISDS
Abbildung 23: Module im Kontext des Szenarios IT-Adaption
2.4.3 Organisation-Szenarien
2.4.3.1 Organisationsanpassung
Anwendbarkeit
Das Szenario Organisationsanpassung unterstützt die Durchführung jener Projekte, in denen
neue Organisationen aufgebaut oder bestehende durch Restrukturierungen und Innovatio-
nen, neue Geschäftsfelder, In- und Outsourcing, Übernahmen, Verschmelzungen und Tren-
nungen, Liquidationen, (internationale) Expansionen usw. angepasst werden.
Beispiele:
 Umzug, Anpassung oder Schaffung einer Organisation
 Fusion von Organisationen
 Outsourcing von Dienstleistungen in ein Service-Center
Module
Das Szenario Organisationsanpassung basiert auf folgenden, in der Abbildung 24 aufgeführ-
ten Modulen:
 Projektsteuerung  Organisation

agil Umsetzung
Organisation
Abbildung 24: Module im Kontext des Szenarios Organisationsanpassung
31 / 200
3 Module
3.1 Einleitung
Module enthalten thematisch zusammengehörende Aufgaben und Ergebnisse. Sie sind Bau-
steine zur Erstellung von Projekten und Szenarien.
Die Abbildung 25 zeigt im Gesamtkontext alle Module, die verwendet werden können und
teils sogar verwendet werden müssen. Ergänzend können eigene Module erstellt werden.

agil Umsetzung
MODULE
Beschaffung
Organisation
Produkt
IT-System
Tests
IT-Migration
IT-Betrieb
ISDS
Abbildung 25: Standardmässig verfügbare HERMES-Module im Gesamtkontext
3.2 Übersicht der Module

3.2.1 Standardmodule
Die Tabelle führt alle bereitgestellten Standardmodule kontextgerecht auf und zeigt, in wel-
chen Projektphasen sie vorkommen können.
klassisch agil
Projektphasen
Einführung
Abschluss
Initialisie-
Realisie-
Konzept
Umset-
zung
rung
rung
Module
Projektsteuerung X X X X X X
Projektführung X X X X X X
Projektgrundlagen X
Beschaffung X X
Organisation X X X X
Produkt X X X X
IT-System X X X X
Tests X X X X X
Einführungsorganisation X X X X
IT-Migration X X X X X
IT-Betrieb X X X X
ISDS X X X X
Tabelle 3: Standardmodule den Projektphasen zugeordnet
32 / 200
Damit die Projekt-Governance eingehalten werden kann, müssen folgende Module zwingend
in jedem Projekt vorkommen:
 Projektsteuerung (alle Phasen);
 Projektführung (alle Phasen);
 Projektgrundlagen (Phase Initialisierung).
3.2.2 Individuelle Module

Ergänzend zu den standardmässig verfügbaren Modulen besteht die Möglichkeit, eigene
fach-, organisations- oder vorhabenspezifische Module mit bestehenden oder neuen indivi-
duellen Aufgaben und Ergebnissen zu entwickeln und diese in eigene Projekte oder Szenarien
zu integrieren. Dies wird auch durch HERMES-Online unterstützt.
Beispiele von fachspezifischen individuellen Modulen, die selbst entwickelt werden können,
sind beispielsweise Marketing, Immobilien, Kommunikation, Personalentwicklung, Rechtset-
zung, Ausbildung, Strategieentwicklung oder Einführung einer Geschäftsverwaltung.
3.3 Erläuterung der Modulbeschreibung
MODULE
Für jedes Modul gibt es eine Modulbeschreibung, die stets gleich strukturiert ist:
 Zweck
definiert den Verwendungszweck des Moduls.
 Was ist zu tun
umschreibt die Modulaufgaben im Gesamtkontext des Moduls.
 Aufgaben und Ergebnisse
listet tabellarisch auf
o die Modulaufgaben im Gesamtkontext, wobei die Entscheidungsaufgaben farblich
(pink) hervorgehoben sind;
o die aus den Aufgaben abgeleiteten oder durch die Aufgaben angepassten, den ent-
sprechenden Projektphasen zugeordneten Ergebnisse.
3.4 Beschreibung der Module

3.4.1 Module zur Steuerung und Führung
3.4.1.1 Projektsteuerung
Zweck
Das Modul Projektsteuerung sorgt für die gesamthafte und organisationsübergreifende Steu-
erung des Projekts und stellt die Erreichung der gesetzten Ziele sicher.
Was ist zu tun
 Das Projekt initialisieren, kontinuierlich steuern und die Übereinstimmung mit den über-
geordneten Zielen und Vorgaben der Stammorganisation sicherstellen.
 Anliegen der Stakeholder berücksichtigen und integrieren, Entscheide zu Risiken treffen.
 Entscheide zur Steuerung treffen.
 Das Projekt abschliessen, eventuell vorzeitig abbrechen.
33 / 200
Aufgaben und Ergebnisse
Aufgabe Ergebnis Phasen
I K R E U A
Entscheid Projektinitialisierungsfreigabe treffen Checkliste Projektinitialisierungsfreigabe X
Projektinitialisierungsauftrag X
Meilenstein Projektinitialisierungsfreigabe X
Liste Projektentscheide Steuerung X
Entscheid Durchführungsfreigabe treffen Checkliste Durchführungsfreigabe X
Durchführungsauftrag X
Meilenstein Durchführungsfreigabe X
Projekt steuern QS- und Risikobericht X X X X
Liste Projektentscheide Steuerung X X X X X X
Entscheid Phasenfreigabe treffen Checkliste Phasenfreigabe X X
QS- und Risikobericht X X
Meilenstein Phasenfreigabe X X
Liste Projektentscheide Steuerung X X
Entscheid Releasefreigabe treffen Checkliste Releasefreigabe X
MODULE
QS- und Risikobericht X

Meilenstein Releasefreigabe X
Entscheid Projektabbruch treffen Checkliste Projektabbruch X X X X
Projekterfahrungen X X X X
Projektschlussbeurteilung X X X X
Meilenstein Projektabschluss X X X X
Liste Projektentscheide Steuerung X X X X
Entscheid Phasenfreigabe Abschluss treffen Checkliste Phasenfreigabe Abschluss X X
Meilenstein Phasenfreigabe Abschluss X X
Entscheid Projektabschluss treffen Checkliste Projektabschluss X
Meilenstein Projektabschluss X
Tabelle 4: Aufgaben und Ergebnisse Modul Projektsteuerung
3.4.1.2 Projektführung
Zweck
Im Rahmen des Moduls Projektführung erfolgt die Planung, Führung und Koordination des
Projekts zur Erreichung der Projektergebnisse und der Vorgehensziele sowie die Durchfüh-
rung aller notwendigen flankierenden Massnahmen.
Was ist zu tun
 Das Projekt planen, führen und gemäss den definierten Rahmenbedingungen (Termine
und Kosten) mit dem geforderten Ergebnis zum Ziel bringen.
 Stakeholder für das Projekt gewinnen und informieren.
 Risiken managen, Probleme bewältigen und Erfahrungen berücksichtigen.
 Leistungen vereinbaren und steuern, das Änderungsmanagement und die Qualitätssiche-
rung führen.
34 / 200
I K R E U A
Projekt führen und kontrollieren Projektmanagementplan X X X
X X X
Arbeitsauftrag X X X
X X X
Projektstatusbericht X X X
X X X
Protokoll X X X
X X X
Lösungsanforderungen X
Detailspezifikation X
Stakeholder managen und informieren Stakeholderliste X X X X X X
Stakeholderinteressen X X X X X X
Projektmanagementplan X X X X X X
Projektmanagementplan erarbeiten Projektmanagementplan X
Durchführungsauftrag erarbeiten Durchführungsauftrag X
Änderungen managen Änderungsantrag X X X
Änderungsstatusliste X X X X
Projektmanagementplan X X X X
Lösungsanforderungen X X X
MODULE
Leistungen vereinbaren und steuern Offertanfrage X X X X
Angebot X X X X
Evaluationsbericht X X X X
Vereinbarung X X X X
Probleme behandeln und Erfahrungen nutzen Projekterfahrungen X X X X X
Qualitätssicherung führen Projektmanagementplan X X X X X
Prüfprotokoll X X X X X
Risiken managen Projektmanagementplan X X X X
Projektstatusbericht X X X X
Phasenfreigabe vorbereiten Phasenbericht X X X X
Releaseabschluss vorbereiten Releasebericht X
Projektmanagementplan X
Projektstatusbericht X
Projektabschluss vorbereiten Projekterfahrungen X
Projektschlussbeurteilung X
Tabelle 5: Aufgaben und Ergebnisse Modul Projektführung
3.4.2 Module zur Ausführung

3.4.2.1 Projektgrundlagen
Zweck
Das Modul Projektgrundlagen schafft eine konkrete, fundierte Ausgangslage für eine mögli-
che Lösungsentstehung und den darauffolgenden Projektabschluss.
Was ist zu tun
 Die Studie erarbeiten, damit der Entscheid Weiteres Vorgehen getroffen werden kann.
 Die Rechtsgrundlagen klären und den Schutzbedarf analysieren.
 Eine Beschaffungsanalyse durchführen, sofern eine Beschaffung mit anschliessender
Adaption geplant ist.
 Die Voraussetzungen schaffen, um den Projektmanagementplan und den Durchführungs-
auftrag zu erarbeiten.
35 / 200
I K R E U A
Rechtsgrundlagenanalyse erarbeiten Rechtsgrundlagenanalyse X
Schutzbedarfsanalyse erarbeiten Schutzbedarfsanalyse X
Beschaffungsanalyse erarbeiten Beschaffungsanalyse X
Studie erarbeiten Studie X
Stakeholderliste X
Prototyping durchführen Prototyp realisiert X
Prototypdokumentation X
Entscheid Weiteres Vorgehen treffen Checkliste Weiteres Vorgehen X
Studie X
Meilenstein Weiteres Vorgehen X
Liste Projektentscheide Führung X
Tabelle 6: Aufgaben und Ergebnisse Modul Projektgrundlagen
3.4.2.2 Beschaffung
MODULE
Zweck
Das Modul Beschaffung dient einer gezielten Beschaffung mittels offenem oder selektivem
Verfahren eines im Markt verfügbaren Systems, Produkts oder einer verfügbaren Dienstleis-
tung.
Was ist zu tun
 Beschaffung mit offenem oder selektivem Verfahren und öffentlicher Publikation, alle an-
deren Fälle von Beschaffungen werden im Modul Projektführung abgewickelt.
 Abgrenzung:
Die Erarbeitung der Beschaffungsgrundlagen wie Bedarfs- und Marktanalyse, Abklärung
des korrekten Verfahrens mit Beschaffung/Einkauf, Sicherstellung der rechtlichen Aspekte
oder Verfahrenswahl finden bei der Erarbeitung der Beschaffungsanalyse im Modul Pro-
jektgrundlagen statt.
I K R E U A
Ausschreibung erarbeiten Ausschreibungsunterlagen X X
Entscheid Ausschreibung treffen Checkliste Ausschreibung X X
Meilenstein Ausschreibung X X
Ausschreibung durchführen Angebot X X
Ausschreibungsunterlagen X X
Angebote bewerten Evaluationsbericht X X
Angebotsprotokoll X X
Entscheid Zuschlag treffen Checkliste Zuschlag X X
Publikation X X
Meilenstein Zuschlag X X
Vereinbarung erarbeiten Vereinbarung X X
Tabelle 7: Aufgaben und Ergebnisse Modul Beschaffung
3.4.2.3 Organisation
Zweck
Das Modul Organisation unterstützt den lösungsspezifischen Aufbau oder Anpassung der Or-
ganisation und deren Umsetzung oder liefert die organisatorisch-fachlichen Grundlagen für
den Aufbau der jeweiligen Lösung.
36 / 200
Was ist zu tun
 Organisation mit Geschäftsmodell, Aufbau- und Ablauforganisation anpassen oder neu
konzipieren, umsetzen und aktivieren.
 Die Interessen der Stakeholder kontinuierlich weiter in Erfahrung bringen und analysieren.
 Die Stakeholder in die Lösungsentstehung einbeziehen.
I K R E U A
Organisationsanforderungen erarbeiten Situationsanalyse X X
Organisationsanforderungen X X
Stakeholderinteressen vertreten Stakeholderinteressen X X X X
Organisationskonzept erarbeiten Organisationskonzept X X
Geschäftsmodellbeschreibung X X
Prozessbeschreibung X X
Organisationsbeschreibung X X
Organisation umsetzen Prozessbeschreibung X X
MODULE
Organisation umgesetzt X X
Organisation aktivieren Organisation aktiviert X X
Tabelle 8: Aufgaben und Ergebnisse Modul Organisation
3.4.2.4 Produkt
Zweck
Das Modul Produkt dient der Entwicklung eines Produkts oder einer Dienstleistung.
Was ist zu tun
 Das Produktkonzept erarbeiten und das Produkt entwickeln oder anpassen.
 Die Lösungsanforderungen verfeinern.
 Die Detailspezifikation erarbeiten.
 Die Interessen der Stakeholder kennen und sie ggf. an der Lösungsentstehung mitwirken
lassen.
I K R E U A
Lösungsanforderungen erarbeiten Situationsanalyse X X
Lösungsanforderungen X X
Produktkonzept erarbeiten Produktkonzept X X
Prototyping durchführen Prototyp realisiert X X X
Prototypdokumentation X X X
Entscheid Produktkonzept treffen Checkliste Produktkonzept X X
Meilenstein Produktkonzept X X
Liste Projektentscheide Führung X X
Produkt realisieren Detailspezifikation X X
Produktdokumentation X X
Anwendungshandbuch X X
Produkt entwickelt oder angepasst X X
Produkt aktivieren Produkt aktiviert X X
Tabelle 9: Aufgaben und Ergebnisse Modul Produkt
37 / 200
3.4.2.5 IT-System
Zweck
Das Modul IT-System dient der Entwicklung eines Systems.
Was ist zu tun
 Die Lösungsanforderungen verfeinern, die Lösungsarchitektur erarbeiten und die Mach-
barkeit überprüfen (allenfalls mit Prototypen).
 Das System realisieren bzw. integrieren und dokumentieren.
 Die Detailspezifikation erarbeiten und das System und die Integration realisieren.
 Die Interessen der Stakeholder kennen und sie an der Lösungsentstehung mitwirken las-
sen.
I K R E U A
MODULE

Lösungsarchitektur erarbeiten Systemkonzept X X
Lösungsarchitektur X X
Prototyping durchführen Prototyp realisiert X X X
Prototypdokumentation X X X
Entscheid Lösungsarchitektur treffen Checkliste Lösungsarchitektur X X
Meilenstein Lösungsarchitektur X X
Integrationskonzept erarbeiten Integrationskonzept X X
System realisieren Detailspezifikation X X
Systemkonzept X X
System entwickelt oder parametrisiert X X
Systemintegration vorbereiten Schnittstellen realisiert X X
Integrations- und Installationsanleitung X X
Detailspezifikation X X
System aktivieren System aktiviert X X
Tabelle 10: Aufgaben und Ergebnisse Modul IT-System
3.4.2.6 Tests
Zweck
Das Modul Tests dient einer systematischen und effizienten Organisation und Durchführung
des Testens von Lösungen.
Was ist zu tun
 Die Testinfrastruktur realisieren und überführen.
 Die Tests vorbereiten, durchführen und protokollieren.
38 / 200
I K R E U A
Testkonzept erarbeiten Testkonzept X X
Testinfrastruktur realisieren Testinfrastruktur realisiert X X
Test durchführen Testprotokoll X X X
Testkonzept X X X
Testinfrastruktur überführen Testkonzept X
Testinfrastruktur überführt X
Protokoll X
Tabelle 11: Aufgaben und Ergebnisse Modul Tests
3.4.2.7 Einführungsorganisation
Zweck
Das Modul Einführungsorganisation unterstützt die Schulung und Einführung der neuen Lö-
sung bzw. den Übergang zum neuen Zustand.
MODULE
Was ist zu tun
 Einführungskonzept erarbeiten.
 Einführungsmassnahmen und die Einführungsorganisation realisieren und durchführen.
 Vorabnahme und Abnahme durchführen.
 Organisationschangemanagement durchführen.
I K R E U A
Einführungskonzept erarbeiten Einführungskonzept X X
Projektmanagementplan X X
Einführungsmassnahmen realisieren Einführungsmassnahmen realisiert X X
Entscheid Vorabnahme treffen Checkliste Vorabnahme X X
Abnahmeprotokoll X X
Meilenstein Vorabnahme X X
Einführungsmassnahmen durchführen Einführungsmassnahmen durchgeführt X X
Entscheid Betriebsaufnahme treffen Checkliste Betriebsaufnahme X X
Meilenstein Betriebsaufnahme X X
Entscheid Abnahme treffen Checkliste Abnahme X X
Meilenstein Abnahme X X
Tabelle 12: Aufgaben und Ergebnisse Modul Einführungsorganisation
3.4.2.8 IT-Migration
Zweck
Das Modul IT-Migration dient der Überführung der Daten in das neue System sowie der Aus-
serbetriebssetzung und Entfernung des Altsystems.
Was ist zu tun
 Die Migration konzipieren, planen, vorbereiten und durchführen.
 Abnahme der Migration durchführen.
 Das Altsystem ausser Betrieb setzen.
39 / 200
I K R E U A
Migrationskonzept erarbeiten Migrationskonzept X X
Migrationsverfahren realisieren Detailspezifikation X X
Migrationsverfahren realisiert X X
Migration durchführen Migration durchgeführt X X
Entscheid Abnahme Migration treffen Checkliste Abnahme Migration X X
Meilenstein Abnahme Migration X X
Altsystem ausser Betrieb setzen Altsystem entfernt X
Tabelle 13: Aufgaben und Ergebnisse Modul IT-Migration
3.4.2.9 IT-Betrieb
Zweck
Das Modul IT-Betrieb dient der Konzeption und Realisierung der Betriebsorganisation beim
MODULE
Betreiber sowie der Aktivierung des Betriebs.

Was ist zu tun
 Den Betrieb mit Infrastruktur und Betriebsorganisation konzipieren und realisieren.
 Das System in den Betrieb integrieren.
 Den Betrieb aktivieren.
I K R E U A
Betriebskonzept erarbeiten Betriebskonzept X X
Service Level Agreement X X
Betrieb realisieren Betriebshandbuch X X
Betriebsinfrastruktur realisiert X X
Betriebsorganisation realisiert X X
System in Betrieb integrieren Betriebshandbuch X X
System integriert X X
Betrieb aktivieren Betriebshandbuch X X
Betrieb aktiviert X X
Tabelle 14: Aufgaben und Ergebnisse Modul IT-Betrieb
3.4.2.10 ISDS
Zweck
Im Modul ISDS (Informationssicherheit und Datenschutz) werden die erforderlichen Schutz-
massnahmen betreffend die Informationssicherheit und den Datenschutz bei der Nutzung
und beim Betrieb der IT-Lösung definiert.
Was ist zu tun
 Anforderungen an ISDS ermitteln, Risiken bewerten und Massnahmen zur Erfüllung der
Anforderungen konzipieren und umsetzen.
 Das ISDS-Konzept erarbeiten und die Ergebnisse laufend dokumentieren.
40 / 200
I K R E U A
ISDS-Konzept erarbeiten ISDS-Konzept X X
Entscheid ISDS-Konzept treffen Checkliste ISDS-Konzept X X
Meilenstein ISDS-Konzept X X
ISDS-Konzept realisieren ISDS-Massnahmen realisiert X X
ISDS-Konzept X X
ISDS-Konzept überführen ISDS-Konzept überführt X X
ISDS-Konzept X X
Tabelle 15: Aufgaben und Ergebnisse Modul ISDS
MODULE
41 / 200
4 Ergebnisse
4.1 Einleitung
Die HERMES-Projektmanagementmethode ist ergebnisorientiert, die Ergebnisse als die wich-
tigsten Methodenelemente stehen im Zentrum.
Es werden zwei Arten von Ergebnissen unterschieden. Ein Ergebnis kann
1. ein Dokument sein, das möglichst auf der Basis einer vorhandenen Dokumentvorlage er-
arbeitet wird, wie beispielsweise ein Durchführungsauftrag, eine Studie, eine Checkliste
oder eine Prozessbeschreibung;
2. ein Zustand sein, der neu erreicht wird, wie beispielsweise Betriebsinfrastruktur realisiert
oder auch ein Meilenstein, der die direkte Folge eines Entscheids ist.
Abgrenzung
Das Ergebnis eines ganzen Projekts, die eigentliche fertige Lösung, oder auch ein Teil davon,
das Inkrement, sind keine HERMES-Methodenelemente. Diese Lösung können beispielsweise
Produkte, Dienstleistungen, IT-Anwendungen, Infrastrukturen, geänderte oder neue betrieb-
liche Organisationen, neue oder fusionierte Stammorganisationen oder einzelne Organisati-
onseinheiten sein. Das Projektergebnis kann auch aus ausgebildeten Anwendern und der ak-
tivierten Organisation mit ihren Prozessen bestehen. Am Ende eines erfolgreichen Projekts
resultiert also als Ergebnis eine Lösung, ein Gesamtsystem, bestehend aus einem oder meh-
reren aktivierten Elementen.
4.2 Übersicht der Ergebnisse

ERGEBNISSE
4.2.1 Standardergebnisse
4.2.1.1 Standarddokumente
Die folgende Tabelle listet alle standardmässig vorgesehenen Dokumente auf. Für jedes der
Dokumente stellt HERMES eine entsprechende Dokumentvorlage zur Verfügung.
Dokumente
minimal geforderte Dokumente = X
Abnahmeprotokoll X Organisationskonzept X
Änderungsantrag X Produktdokumentation X
Änderungsstatusliste X Produktkonzept X
Angebot X Projekterfahrungen
Angebotsprotokoll Phasenbericht X
Anwendungshandbuch Projektinitialisierungsauftrag X
Arbeitsauftrag Projektmanagementplan X
Ausschreibungsunterlagen X Projektschlussbeurteilung X
Beschaffungsanalyse Projektstatusbericht X
Betriebshandbuch X Protokoll
Betriebskonzept X Prototypdokumentation
Checklisten Prozessbeschreibung X
Detailspezifikation X Prüfprotokoll
Durchführungsauftrag X Publikation X
Einführungskonzept X QS- und Risikobericht X
Evaluationsbericht X Rechtsgrundlagenanalyse X
Geschäftsmodellbeschreibung X Releasebericht X
Integrations- und Installationsanleitung Schutzbedarfsanalyse X
Integrationskonzept X Service Level Agreement
ISDS-Konzept X Situationsanalyse X
Liste Projektentscheide Führung X Stakeholderinteressen
Liste Projektentscheide Steuerung X Stakeholderliste X
Lösungsanforderungen X Studie X
Lösungsarchitektur X Systemkonzept
42 / 200
Dokumente
minimal geforderte Dokumente = X
Migrationskonzept Testkonzept X
Offertanfrage X Testprotokoll X
Organisationsanforderungen X Vereinbarung
Organisationsbeschreibung X
Tabelle 16: Ergebnisübersicht – Dokumente
Die mit einem X markierten minimal geforderten Dokumente werden benötigt, um die Anfor-
derungen der Governance zu erfüllen. Dazu gehören u. a. nicht nur diejenigen Ergebnisse, die
von den Revisionsstellen überprüft werden müssen, sondern als «Muss» auch all jene, die
zwingend in einem Modul zu erstellen sind.
Die minimal geforderten Dokumente sind die Leitplanken für die Sicherstellung des Projekter-
folges und widerspiegeln eine allgemeine Projektsituation, ohne auf die Besonderheiten der
einzelnen Projekte einzugehen. Die Erarbeitung der minimal geforderten Dokumente ist ob-
ligatorisch. Ist ein Modul für das Projekt nicht relevant, entfallen auch die darin definierten
minimal geforderten Dokumente. Sie entfallen ebenso, wenn unter gewissen Umständen ihre
Verwendung im Modul nicht vorgesehen ist (z. B. im Fall klassisch/agil). Die minimal gefor-
derten Dokumente können auch stammorganisationsspezifisch gemäss deren Governance-
Bestimmungen angepasst werden.
4.2.1.2 Standardzustände
Die folgende Tabelle listet alle standardmässig vorgesehenen Zustände auf.
Zustände
Altsystem entfernt Organisation aktiviert
ERGEBNISSE
Betrieb aktiviert Organisation umgesetzt
Betriebsinfrastruktur realisiert Produkt aktiviert
Betriebsorganisation realisiert Produkt entwickelt oder angepasst
Einführungsmassnahmen durchgeführt Prototyp realisiert
Einführungsmassnahmen realisiert Schnittstellen realisiert
ISDS-Konzept überführt System aktiviert
ISDS-Massnahmen realisiert System entwickelt oder parametrisiert
Meilensteine System integriert
Migration durchgeführt Testinfrastruktur realisiert
Migrationsverfahren realisiert Testinfrastruktur überführt
Tabelle 17: Ergebnisübersicht – Zustände
4.2.2 Individuelle Ergebnisse

Ergänzend zu den standardmässig bereitgestellten Dokumenten und Zuständen besteht die
Möglichkeit, weitere fach-, organisations- oder vorhabenspezifische Ergebnisse in eigenen
Modulen zu integrieren. Dies wird durch HERMES-Online unterstützt und kommt insbeson-
dere dann zum Tragen, wenn neue Module mit neuen Aufgaben entwickelt werden. Beispiele
von individuellen Ergebnissen können stammorganisationsspezifische Berichte und Rapporte
oder eine abgeschlossene Konsultation sein.
4.3 Erläuterung der Ergebnisbeschreibung

Für jedes Ergebnis gibt es eine Ergebnisbeschreibung, die stets gleich strukturiert ist:
 Beschreibung
schafft das grundlegende Verständnis des Ergebnisses.
 Inhalt (nur bei Dokumenten)
beschreibt den vorgeschlagenen Inhalt eines Dokuments (s. weiter unten Dokumentvor-
lagen).
Falls erforderlich, wird jede Inhaltsangabe mit "A" für agil, respektive mit "K" für klassisch
gekennzeichnet.
 Beziehungen (nur online)
zeigen den Bezug des Ergebnisses zu Modulen, Rollen und Aufgaben.
43 / 200
 Vorlagen (nur online)
für alle Dokumente steht eine Dokumentvorlage zur Verfügung. Sie ist ein konkretes Hilfs-
mittel für ein tieferes Verständnis der Anwendung von HERMES-Dokumenten. Die Doku-
mentvorlagen können jedoch an die Bedürfnisse der Organisation angepasst oder durch
adäquate toolsgestützte Lösungen ersetzt werden (vgl. Kapitel 7).
4.4 Beschreibung der Ergebnisse

4.4.1 Dokumente
4.4.1.1 Abnahmeprotokoll
Beschreibung
Das Abnahmeprotokoll wird bei den Entscheiden Vorabnahme, Abnahme und Abnahme Mig-
ration erstellt. Es dokumentiert die Erfüllung der Vereinbarung über die Lösungseigenschaften
(Produkt/Dienstleistung/System) und bestehende Mängel. Es ist ein rechtlich verbindliches
Dokument.
Inhalt
 Abnahmegegenstand
 Abnahmebeteiligte
 Grundlagen
 Abnahmeverfahren
 Abnahmekriterien mit Mängelklassen
 Lieferergebnisse und Mängel inkl.
ERGEBNISSE
o Massnahmen
o Verantwortlichkeiten und
o Terminen
 Abnahmeergebnis
 Unterschriften
4.4.1.2 Änderungsantrag
Beschreibung
Der Änderungsantrag kommt ausschliesslich bei klassisch geführter Lösungsentstehung zum
Tragen und bildet die Grundlage für eine inhaltliche Änderung. Er umfasst die Änderungsbe-
schreibung mit dem Antrag, das Vorgehen, um die Änderung durchzuführen, und den Lö-
sungsvorschlag, um die Änderung umzusetzen. Der Änderungsantrag hat Anforderungscha-
rakter und spezifiziert die durchzuführende Änderung im Detail.
Inhalt
 Identifikation Änderungsantrag
 Antragsteller
 Änderungsbeschreibung
 Angaben zur Ausführung
 Lösungsvorschlag
 Beurteilung der Auswirkungen
o Aufwand
o Kosten
o Termin
o Risiken
44 / 200
4.4.1.3 Änderungsstatusliste
Beschreibung
Die Änderungsstatusliste dient zur Aufzählung und Überwachung der Änderungen sowie der
Dokumentation aller hinzugefügten, gelöschten oder geänderten Funktionen oder sonstiger
durchgeführter Modifikationen. Sie unterstützt die Nachvollziehbarkeit des Projektverlaufs
(Governance) und gibt einen Überblick über deren Bearbeitungsstatus und – falls die Ände-
rungen erfolgen – den Status der Änderungen.
Inhalt
Je Änderung: (K=klassisch, A=agil,)
 Verantwortlich K
 Eingangsdatum K A
 Identifikation Änderungsantrag K
 Änderung/Kurzbeschreibung A
 Entscheidungsverantwortlicher K
 Status K A
 Änderungsdatum K A
 Änderungsverantwortlicher K
 Aufwand K
 Kosten K
Zudem:
 Total Aufwand und Kosten aller bewilligter Änderungsanträge K
4.4.1.4 Angebot
ERGEBNISSE
Beschreibung
Das Angebot spezifiziert die vom Ersteller/Betreiber angebotene Leistung oder das Produkt.
Weiter umfasst das Angebot alle kommerziellen Elemente wie Aufwand, Kosten, Gewährleis-
tungen, Garantien, Rechte an Ergebnissen usw. Das Angebot beschreibt Vorgehen und Ver-
fahren zur Erbringung der Leistung und/oder zur Installation und Integration von Produk-
ten/Systemen.
Inhalt
Der Aufbau des Angebots richtet sich nach den Vorgaben der Beschaffungsstelle.
4.4.1.5 Angebotsprotokoll
Beschreibung
Bei öffentlichen Beschaffungen wird nach Ablauf der Eingabefrist ein Protokoll der Angebots-
öffnung erstellt. Fallweise werden auch alle beschaffungsrechtlichen und bewertungsrelevan-
ten Punkte protokolliert.
Inhalt
 Beschaffungsgegenstand
 Datum
 Anbieter/Angebot
 Sachverhalt
 Traktanden
 Pendenzenliste (Anhang)
4.4.1.6 Anwendungshandbuch
Beschreibung
Das Anwendungshandbuch enthält alle Informationen, die der Anwender eines Produkts/Sys-
tems braucht, um es ordnungsgemäss zu bedienen und im Fall von Problemen richtig reagie-
ren zu können.
45 / 200
Inhalt
 Übersicht
 Funktionen
 Detailbeschreibungen zur Anwendung
 Mängelbehandlung
4.4.1.7 Arbeitsauftrag
Beschreibung
Der Arbeitsauftrag enthält alle relevanten Informationen zur Erledigung einer gestellten Auf-
gabe. Der Projektleiter verwendet ihn, um den Projektmitarbeitern Aufträge im Rahmen der
Projektplanung, -führung, -information und -kontrolle zu erteilen. Arbeitsaufträge können in-
tern oder extern vergeben werden. Allfällige lösungsspezifische Aufträge müssen mit dem
Anwendervertreter im Voraus abgestimmt sein.
Inhalt
 Arbeitsziele
 Ergebnisse
 Abgrenzung
 Voraussetzungen und Abhängigkeiten
 Liste der Aktivitäten mit
o Bezug auf die Ergebnisse
o Aktivität
o Verantwortlichen/Mitwirkenden
o Planstunden
ERGEBNISSE
o Terminen
o Status
 Ressourcenbedarf
 Ergebnisdarstellung
 Qualitätssicherung
4.4.1.8 Ausschreibungsunterlagen
Beschreibung
Die Ausschreibungsunterlagen umfassen alle Informationen, die im Rahmen einer Ausschrei-
bung publiziert werden. Dazu gehört in erster Linie das Lastenheft (in der Schweiz auch Pflich-
tenheft genannt) samt Kriterienkatalog, das ein unabdingbarer Teil der Ausschreibungsunter-
lagen ist.
Zu den Ausschreibungsunterlagen gehören weiter der Vertragsentwurf, die allgemeinen Ge-
schäftsbedingungen der Stammorganisation, der Ausschreibungstext und weitere Beilagen
zum Lastenheft. Werden in einer öffentlichen Ausschreibung Fragen beantwortet, sind die
Fragen und Antworten ebenfalls Teil der Ausschreibungsunterlagen, die anschliessend allen
Anbietern zugestellt werden.
Inhalt
 Lastenheft mit
o Ausgangslage mit
 Einleitung, Zweck des Dokuments
 Grund für die Ausschreibung, Handlungsbedarf
 Beschaffungsgegenstand
o Situationsbeschreibung mit
 Organisation
 Stärken und Schwächen
 Mengen und Häufigkeiten
 Umfang und Preis
o Soll-Zustand mit
 Zielen und Anforderungen
 Muss- und Kann-Kriterien
46 / 200
 Umfang (Scope)
 Preis (Rahmen)
o Terminen
o Aufbau des Angebots
o Administrativem
o Kriterienkatalog mit
 Eignungs- und Zuschlagskriterien
 Gewichtung
 Punkten
 Anhänge wie
o Allgemeine Geschäftsbedingungen
o Vertragsentwurf
o Ausschreibungstext
o weitere Ausschreibungsunterlagen
4.4.1.9 Beschaffungsanalyse
Beschreibung
Die Beschaffungsanalyse beschreibt u. a. den konkreten Handlungsbedarf, was durch wen und
wann beschafft werden soll, wie sich der Markt präsentiert, welche anderen Rahmenbedin-
gungen zu beachten sind und welches Beschaffungsverfahren zum Tragen kommt. Die Ana-
lyse wird mit den Controlling- und Vorgabestellen für das Beschaffungswesen abgestimmt.
Die Beschaffungsanalyse bildet als Ergänzung zur Studie die Grundlage für die Entscheidung,
ob die Projektfortsetzung freigegeben wird oder nicht. Ebenso ist sie die Voraussetzung für
die Erarbeitung des Projektmanagementplans und des Durchführungsauftrags.
ERGEBNISSE
Inhalt
 Grund für die Beschaffung, Handlungsbedarf
 Beschaffungsinhalte mit
o Beschaffungsbedarf
o Beschaffungsgegenstand mit Art, Zustand und Qualität
o Verfügbarkeit auf dem Markt
 Anbieter und Lieferanten mit
o Mögliche Anbieter und Lieferanten
o Bestehende Lieferanten
o Bestehende Verträge und deren Laufdauer
o Anforderungen an die Anbieter
o Auswahl potenzieller Anbieter
o Gewünschte Vertriebsart
 Rollen und ihre Verantwortung mit
o Aufgaben und Verantwortung Projektleiter
o Aufgaben und Verantwortung Projektteam inklusive Ansprech-/Koordinationsstelle für
Anbieter und Lieferanten
o Aufgaben und Verantwortung Beschaffungsabteilung/Einkauf
 Terminliche Aspekte
 Finanzielle Aspekte
 Approximative Vorkalkulation/Wirtschaftlichkeitsvorschau
 Beschaffungsrechtliche Aspekte
 Standards der Beschaffung:
o Welche Dokumente werden bei der Beschaffung benutzt?
o Wie sind die Prozessschritte bei der Beschaffung gestaltet?
 Vertragsformen:
o Welche Vertragsformen kommen zur Anwendung?
 Abstimmung der Prozesse:
o In welcher Weise werden die wechselseitigen Abhängigkeiten zwischen dem Prozess
der Beschaffung und anderen vor- oder nachgelagerten Prozessen gemanagt?
o Unterscheidet sich die Beschaffung je nach Lösungsvariante aus der Studie?
47 / 200
 Beschaffungsplan
 Ausschreibungsverfahren
 Vorgehen bei Fragen zur Ausschreibung, zu den Unterlagen
4.4.1.10 Betriebshandbuch
Beschreibung
Das Betriebshandbuch liefert alle Informationen, die der Betreiber benötigt, um das System
ordnungsgemäss betreiben und im Fall von Problemen richtig reagieren zu können. Alle für
den Betreiber betriebsrelevanten Informationen sind im Betriebshandbuch dokumentiert.
Während der agilen Lösungsentstehung wird das Betriebshandbuch mehrmals, pro Itera-
tion/Release, entsprechend der Aktivierung eines vollständigen Teils der Lösung aktualisiert.
Inhalt
 Systemübersicht
 Aufnahme des Betriebs
o Voraussetzungen für die Betriebsaufnahme
o Ablauf der Betriebsaufnahme
o Qualitätssicherung nach Betriebsaufnahme
o Vorgaben zur Abnahme des Systems
 Durchführung und Überwachung des Betriebs
 Unterbrechung oder Beendigung des Betriebs
 Supportorganisation mit
o Supportprozessen
o Organisation mit Rollen
ERGEBNISSE
 Changemanagement mit
o Changemanagement-Prozess
o Changemanagement-Organisation mit
 Rollen
 Kontaktinformationen
 Sicherheitsbestimmungen
 Anhänge
o Betriebskonzept
o Integrationskonzept
4.4.1.11 Betriebskonzept
Beschreibung
Das Betriebskonzept beschreibt die Betriebsorganisation mit der Aufbauorganisation und den
Betriebsprozessen des Betreibers. Das Betriebskonzept bildet die Grundlage für die Erarbei-
tung des Betriebshandbuchs und der Organisation beim Betreiber.
Inhalt
 Anforderungen an den Betrieb
 Systemtechnik
o IT-Infrastrukturkonzept
o Systeme, eingesetzte Komponenten, Versionen
o Netze
o Datensicherung
o Archivierung
 Organisation
o Aufbauorganisation
o Betriebsprozesse
 Systembetrieb mit
o Normalbetrieb
o Systemüberwachung
o Arbeitsvorbereitung
48 / 200
 Behandlung von Störungen
 Beschreibung der Sicherheitsaspekte
 Anforderungsabdeckung
4.4.1.12 Checklisten
Beschreibung
Checklisten gehören zu den Dokumenten. Sie werden zur Unterstützung bei der Entschei-
dungsfindung genutzt. Sie stellen Kataloge von Kontroll- und Prüfungsschritten dar, die im
Rahmen einer Entscheidungsvorbereitung systematisch und vollständig durchgeführt werden
sollen. Dies verringert die Wahrscheinlichkeit von Fehlentscheiden, da so alle wesentlichen
Aspekte berücksichtigt werden.
Jede Checkliste ist auf einen konkreten Entscheid abgestimmt und nennt die notwendigen
Prüfpunkte mit Ergebnis, Freigabekriterien, Bewertung, Verantwortlichen und Prüfungsdatum.
Die Checklisten sollen im Rahmen der Entscheidungsvorbereitung mit weiteren projekt-,
stammorganisations- und lösungsspezifischen Kriterien ergänzt werden.
 Checkliste Abnahme
Die Checkliste Abnahme beschreibt generelle und projektspezifische Prüfpunkte und Kri-
terien, die für den Entscheid Abnahme relevant sind.
 Checkliste Abnahme Migration
Die Checkliste Abnahme Migration beschreibt generelle und projektspezifische Prüf-
punkte und Kriterien, die für den Entscheid Abnahme Migration relevant sind.
 Checkliste Ausschreibung
Die Checkliste Ausschreibung beschreibt generelle und projektspezifische Prüfpunkte und
Kriterien, die für den Entscheid Ausschreibung relevant sind.
ERGEBNISSE
 Checkliste Betriebsaufnahme
Die Checkliste Betriebsaufnahme beschreibt generelle und projektspezifische Prüfpunkte
und Kriterien, die für den Entscheid Betriebsaufnahme relevant sind.
 Checkliste Durchführungsfreigabe
Die Checkliste Durchführungsfreigabe beschreibt generelle und projektspezifische Prüf-
punkte und Kriterien, die für den Entscheid Durchführungsfreigabe relevant sind.
 Checkliste ISDS-Konzept
Die Checkliste ISDS-Konzept beschreibt generelle und projektspezifische Prüfpunkte und
Kriterien, die für den Entscheid ISDS-Konzept relevant sind.
 Checkliste Lösungsarchitektur
Die Checkliste Lösungsarchitektur beschreibt generelle und projektspezifische Prüfpunkte
und Kriterien, die für den Entscheid Lösungsarchitektur relevant sind.
 Checkliste Phasenfreigabe
Die Checkliste Phasenfreigabe beschreibt generelle und projektspezifische Prüfpunkte und
Kriterien, die für den Entscheid Phasenfreigabe relevant sind.
 Checkliste Phasenfreigabe Abschluss
Die Checkliste Phasenfreigabe Abschluss beschreibt generelle und projektspezifische Prüf-
punkte und Kriterien, die für den Entscheid Phasenfreigabe Abschluss relevant sind.
 Checkliste Produktkonzept
Die Checkliste Produktkonzept beschreibt generelle und projektspezifische Prüfpunkte
und Kriterien, die für den Entscheid Produktkonzept relevant sind.
 Checkliste Projektabbruch
Die Checkliste Projektabbruch beschreibt generelle und projektspezifische Prüfpunkte und
Kriterien, die für den Entscheid Projektabbruch relevant sind.
49 / 200
 Checkliste Projektabschluss
Die Checkliste Projektabschluss beschreibt generelle und projektspezifische Prüfpunkte
und Kriterien, die für den Entscheid Projektabschluss relevant sind.
 Checkliste Projektinitialisierungsfreigabe
Die Checkliste Projektinitialisierungsfreigabe beschreibt generelle und projektspezifische
Prüfpunkte und Kriterien, die für den Entscheid Projektinitialisierungsfreigabe relevant
sind.
 Checkliste Releasefreigabe
Die Checkliste Releasefreigabe beschreibt generelle und projektspezifischen Prüfpunkte
und Kriterien, die für den Entscheid Releasefreigabe relevant sind.
 Checkliste Vorabnahme
Die Checkliste Vorabnahme beschreibt alle generellen und projektspezifischen Prüfpunkte
und Kriterien, die für den Entscheid Vorabnahme relevant sind.
 Checkliste Weiteres Vorgehen
Die Checkliste Weiteres Vorgehen beschreibt generelle und projektspezifische Prüfpunkte
und Kriterien, die für den Entscheid Weiteres Vorgehen relevant sind.
 Checkliste Zuschlag
Die Checkliste Zuschlag beschreibt generelle und projektspezifische Prüfpunkte und Kri-
terien, die für den Entscheid Zuschlag relevant sind.
4.4.1.13 Detailspezifikation
Beschreibung
In klassisch geführter Lösungsentstehung beschreibt die Detailspezifikation die funktionalen
und qualitativen Lösungseigenschaften. Sie basiert auf den Lösungsanforderungen und auf
ERGEBNISSE
dem Produktkonzept bzw. bei IT-Projekten auf dem Systemkonzept und der Lösungsarchi-
tektur. Sie wird inhaltlich und planerisch so detailliert erstellt, dass sie eine verlässliche Grund-
lage für die Realisierung (Entwicklung und Anpassung bzw. Entwicklung und Parametrisie-
rung) der Lösung bildet. Die Detailspezifikation bildet die Grundlage für die Erstellung von
detaillierten Testfallbeschreibungen.
In agil geführter Lösungsentstehung entspricht die Detailspezifikation weitgehend einem
"Sprint Backlog", dient jedoch aus Projektmanagementsicht nur der Dokumentation der je-
weiligen aktuellen Planung jener Anforderungen, die das Entwicklungsteam selbstorganisiert
ausgewählt hat und die innerhalb der jeweiligen Iteration zu erledigen sind. Sie wird im Rah-
men der Aufgabe Projekt führen und kontrollieren iterativ-inkrementell fortgeführt, sodass die
bereits im Dokument erledigten Anforderungen vorheriger Iterationen jeweils um ein neues
Kapitel ergänzt werden.
Inhalt
In klassisch geführter Lösungsentstehung ist der Inhalt der Detailspezifikation abhängig vom
Realisierungsgegenstand und der eingesetzten Methode zur Spezifizierung. Ergänzend ist fol-
gende Spezifikation möglich:
 Detailanforderungen mit
o Anforderungen der Organisation
o Funktionalen Anforderungen
o Qualitätsanforderung, Rahmenbedingung
In agil geführter Lösungsentstehung hingegen ist der Inhalt durch die zum Einsatz kommen-
den agilen Entwicklungsmethoden geprägt.
50 / 200
4.4.1.14 Durchführungsauftrag
Beschreibung
Der Durchführungsauftrag bildet den Rahmen und die verbindliche Grundlage für die Lö-
sungsentstehung sowie den darauffolgenden Projektabschluss und autorisiert die Projektfort-
setzung. Er beinhaltet alle wesentlichen lösungsspezifischen Angaben sowie Hinweise betref-
fend das Vorgehen in den nächsten Phasen. Es handelt sich um eine verbindliche Vereinba-
rung zwischen dem Auftraggeber und dem Projektleiter.
Inhalt
 Ausgangslage und Handlungsbedarf
 Ziele
o Lösungsziele
o Vorgehensziele mit
 klassischer/agiler Vorgehensweise
 Szenario
 weiteren Zielen
o Rahmenbedingungen & Abgrenzung
 Zusammenfassende Lösungsbeschreibung
 Strategiebezug und Umsetzung von Vorgaben
 Rechtliche Grundlagen
 Investitionsbedarf
 Ressourcen- und Hilfsmittelbedarf
 Kosten/Nutzen/Wirtschaftlichkeit (Vorschau)
 Planung und Organisation
ERGEBNISSE
 Vorgehensweise (Entwicklungsmanagement)
 Risiken
 Konsequenzen
 Verbindlichkeiten
4.4.1.15 Einführungskonzept
Beschreibung
Das Einführungskonzept beschreibt die Massnahmen für die Lösungseinführung und die Ein-
führungsorganisation. Dazu gehören u.a. die Massnahmen des Organisationschangemanage-
ments zur Unterstützung des Übergangs zum neuen Zustand, das Ausbildungskonzept, die
Planung der Abnahmen samt Abnahmekriterien sowie die Freigabekriterien der Betriebsauf-
nahme.
Inhalt
 Ausgangslage
 Betroffenheitsanalyse
 Einführungsvorgehen
 Einführungsmassnahmen mit
o Organisations-Transition /-Changemanagement
o Notfallmassnahmen und Notfallorganisation
 Ausbildungskonzept mit
o Anforderungen
o Ausbildungsvorgehen
o Ausbildungsunterlagen
o Ausbildungsinfrastruktur
 Einführungsorganisation
 Einführungsplanung
 Planung der Vorabnahme und der Abnahme mit
o Abnahmekriterien
 Freigabekriterien der Betriebsaufnahme
51 / 200
4.4.1.16 Evaluationsbericht
Beschreibung
Der Evaluationsbericht fasst die Ergebnisse der Angebotsbewertung zusammen. Er bildet die
Grundlage für den Entscheid Zuschlag.
Inhalt
 Ausgangslage
 Vorgehen bei der Evaluation
o Mitglieder des Evaluationsteams
o Ablauf der Evaluation
 Ausschreibung, Fragen und Angebotsöffnung
 Ergebnisse der Evaluation mit
o Eignungskriterien
o Technischen Spezifikationen
o Zuschlagskriterien
o Bewertungsverfahren
o Beurteilung der Angebote (Leistungswert/Wirtschaftlichkeit)
o Vergleich der Angebote
o Auswahl und Begründung
 Empfehlung mit
o Geeignetstem Angebot (Leistungswert)
o Wirtschaftlichstem Angebot (Kosten/Nutzen)
o Bestem Angebot (Leistungswert/Wirtschaftlichkeit)
 Anträge
 Anhänge mit
ERGEBNISSE
o Ausgefülltem Kriterienkatalog
o Bewertung
o Weiteren Beilagen
4.4.1.17 Geschäftsmodellbeschreibung
Beschreibung
Die Geschäftsmodellbeschreibung beinhaltet alle organisatorischen Aspekte, die für die Lö-
sung relevant sind und die durch die Lösung beeinflusst werden können und gibt den Rahmen
für die Ablauf- und Aufbauorganisation vor. Sie orientiert sich an den Elementen des Ge-
schäftsmodells einer Organisation, verstärkt die ganzheitliche Sichtweise auf die Organisation
und umfasst eine Auswahl von Komponenten wie z. B. die Kundensegmentierung oder die
Kundenbeziehungen.
Inhalt
Der Inhalt ist stark durch das Projekt und die Vorgehensweise sowie durch die Stammorgani-
sation geprägt.
 Kundensegmente
 Wertangebote
 Kanäle
o Kommunikationskanäle
o Distributionskanäle
o Verkaufskanäle
 Kundenbeziehungen
 Schlüsselaktivitäten zu
o Wertangeboten
o Märkten
o Kundenbeziehungen
 Schlüsselressourcen
o Physische
o Finanzielle
52 / 200
o Intellektuelle
o Personelle
 Schlüsselpartnerschaften
 Einnahmequellen
 Kostenstruktur
o Kostenorientiertes Geschäftsmodell
o Wertorientiertes Geschäftsmodell
4.4.1.18 Integrations- und Installationsanleitung

Beschreibung
Die Integrations- und Installationsanleitung beschreibt, wie das System in der Betriebsinfra-
struktur integriert und installiert wird.
Inhalt
 Produktbeschreibung
 Voraussetzungen
 Durchführungsanleitung
 Integrationsplan
 Qualitätssicherung und Test
 Mängelbehandlung
 Support
 Abnahme
4.4.1.19 Integrationskonzept
ERGEBNISSE
Beschreibung
Das Integrationskonzept beschreibt, wie das System im Umfeld integriert wird. Es beschreibt
ebenfalls, wie der Transport von einer Systemumgebung in eine andere erfolgt und wie das
Konfigurationsmanagement und die Qualität sichergestellt werden. Bei einer Einführung mit
Realisierungseinheiten (klassisch) oder schrittweiser Integration mit Releases (agil) ist die Pla-
nung der Realisierungseinheiten bzw. die Releaseplanung gemäss Projektmanagementplan
ein Bestandteil des Integrationskonzepts.
Inhalt
 Systemübersicht und Integrationsobjekte
 Schnittstellen
 Integrationsumgebungen
 Integrationsvorgehen und Integrationsschritte mit Massnahmen
 Rahmenbedingungen und Abhängigkeiten
 Integrationsorganisation
 Planung der Realisierungsabschnitte
 Transportkonzept und Transportprozesse
4.4.1.20 ISDS-Konzept
Beschreibung
Das ISDS-Konzept bildet die Grundlage für die Festlegung der Massnahmen für Informations-
sicherheit und Datenschutz (ISDS). Es zeigt die Restrisiken auf, die mit dem Betrieb des Sys-
tems und der Organisation verbunden sind.
Inhalt
 Verzeichnis der sicherheitsrelevanten Dokumente
 Einstufung aufgrund der Schutzbedarfsanalyse
 Sicherheitsrelevante Systembeschreibung
 Risikoanalyse mit Restrisiken
53 / 200
 Notfallkonzept
 Bearbeitungsreglement
 Einhaltung/Überprüfung der Schutzmassnahmen
 Test/Abnahme der Informationssicherheitsfunktionen
 Liquidation
4.4.1.21 Liste Projektentscheide Führung

Beschreibung
Die Liste Projektentscheide Führung dokumentiert die Ergebnisse der Entscheidungsaufgaben
der Hierarchieebene Führung. Die Liste wird während der ganzen Dauer eines Projekts ver-
wendet.
Inhalt
 Entscheid
 Meilenstein erreicht ja/nein
 Zugrundeliegende Dokumente
 Entscheidungsträger der Hierarchieebene Führung und/oder Ausführung
 Datum
4.4.1.22 Liste Projektentscheide Steuerung

Beschreibung
Die Liste Projektentscheide Steuerung dokumentiert die Ergebnisse der Entscheidungsaufga-
ben der Hierarchieebene Steuerung. Die Liste wird während der ganzen Dauer eines Projekts
verwendet.
ERGEBNISSE
Inhalt
 Entscheid
 Meilenstein erreicht ja/nein
 Zugrundeliegende Dokumente
 Entscheidungsträger der Hierarchieebene Steuerung
 Datum
4.4.1.23 Lösungsanforderungen
Beschreibung
Die Lösungsanforderungen beinhalten als massgebendes HERMES-Ergebnis die fachlichen
und technischen Anforderungen, aber auch weitere Elemente wie Eigenschaften, Funktionen,
Optimierungen und Mängelkorrekturen, rechtliche sowie lösungsrelevante und regulatorische
Vorgaben, die das künftige System oder Produkt erfüllen soll. Sie umfassen beispielsweise die
in die Lösung unmittelbar einfliessenden Geschäftsanforderungen, Betriebsanforderungen,
Supportanforderungen oder Sicherheitsanforderungen.
In klassisch geführter Lösungsentstehung werden die Lösungsanforderungen in der Phase
Konzept auf der Basis der Studie und der Situationsanalyse im endgültigen Detaillierungsgrad
erarbeitet und während der Lösungsentstehung bei Bedarf über das Änderungsmanagement
sukzessive nachgeführt.
In agil geführter Lösungsentstehung werden die Lösungsanforderungen auf der Basis der Stu-
die und der Situationsanalyse in der Phase Umsetzung erstmalig in der Art eines massgeben-
den "Initial Product Backlogs" erarbeitet. Sie entsprechen einer Liste eindeutig priorisierter
Anforderungen, bei Bedarf unterteilt in Releases, die nach geschäftsspezifischen oder anderen
für das Vorhaben wichtigen Aspekten und logischen Abhängigkeiten geordnet sind. Im Rah-
men der selbstorganisierten agilen Entwicklung werden sie kontinuierlich aktualisiert. Als HER-
MES-Ergebnis werden sie iterativ-inkrementell nachgeführt und haben in der Folge nur noch
einen informativen und dokumentarischen Charakter.
54 / 200
Inhalt
Der Inhalt ist stark durch das Projekt und die Vorgehensweise geprägt.
Möglicher Inhalt:
 Übersicht aller Aufträge (evtl. unterteilt nach Releases)
 Releases
 Allgemeine Beschreibung
o Geschäftlicher und systemischer Kontext
o Wirkung/Nutzen
o Anwendungsfall (Use Case)
 Anforderung mit
o Priorität
(z. B. gemäss Anforderungsart, Gesamtkontext, Wichtigkeit, Dringlichkeit, usw.)
o Bezeichnung/Titel
o Auftrags-/Identifikationsnummer
o Produkt-/Systemübersicht
o Zu erreichendes Ziel
o Fachlicher Beschrieb
 Freier Text
 Organisation, Funktion, Qualität, usw.
 Beim System:
Anforderungen zum Betriebskonzept, zur Lösungsarchitektur, zur Datenarchivie-
rung, zum Migrationskonzept, aus dem ISDS-Konzept
 Erwartungshaltung des Anwenders
 Absprache mit dem Anwender
o Funktionsbeschrieb
ERGEBNISSE
o Nutzen/Mehrwert
o Geschäftsrelevanz
o Akzeptanzkriterien
o Product Compliance
o Realisierungstermin
o Geschätzter Aufwand
o Testkriterien
o Weitere Aspekte und Kriterien
4.4.1.24 Lösungsarchitektur
Beschreibung
Die Lösungsarchitektur basiert auf dem Systemkonzept und gliedert das System in Subsys-
teme und ihre Komponenten. Sie beschreibt die Systemstruktur und die Schnittstellen. Die
Lösungsarchitektur erlaubt eine umfassende Sicht auf das System. Je nach Projektergebnis
und Umfang enthält es mehrere Architekturelemente und -modelle, beispielsweise das Ge-
schäftsprozessmodell, das Funktionsmodell (z. B. mit Use Cases/User Stories), die Datenarchi-
tektur/das Datenmodell, die Sicherheitsarchitektur. Sie enthält auch die IT-Dokumentation
bzw. verweist auf die Dokumentation des Erstellers. Die Ergebnisse des Systemkonzepts wer-
den in einem Anhang zur Lösungsarchitektur zusammengefasst.
Die Lösungsarchitektur berücksichtigt die Vorgaben der Controlling- und Vorgabestellen.
Inhalt
 Systemstruktur
o Übersicht über das System
o Subsysteme und Komponenten
o Lösungsarchitekturen/Modelle
 Schnittstellen und Abgrenzung
o Schnittstellen zu Umsystemen
o Hinweis auf Integrationskonzept
o Abgrenzung
55 / 200
 Machbarkeitsbeurteilung
 Konformität mit Vorgaben
 Anforderungszuordnung und -abdeckung
 Ergebnisse des Systemkonzepts
4.4.1.25 Migrationskonzept
Beschreibung
Das Migrationskonzept beschreibt die technischen und organisatorischen Anforderungen an
die Migration und enthält das Konzept der Migrationsverfahren. Das Migrationskonzept be-
legt die Machbarkeit und zeigt die Migrationsplanung auf. Neben den technischen und orga-
nisatorischen Anforderungen sind auch die Anforderungen der Revision sowie des ISDS be-
rücksichtigt.
Inhalt
 Ziele der Migration
 Anforderungen an die Migration
 Migrationsobjekte
 Datenanalyse
 Migrationsverfahren
 Migrationsplan
 Machbarkeit
 Archivierung und Ausserbetriebssetzung Altsystem
4.4.1.26 Offertanfrage
ERGEBNISSE
Beschreibung
Mit der Offertanfrage werden Angebote für verschiedene organisationsinterne und -externe
Leistungen eingeholt. Die Angebote bilden die Grundlage für die Leistungsvereinbarung, wie
in der Aufgabe Leistungen vereinbaren und steuern beschrieben ist. Die Vorgaben an die
Offerte erlauben es, die Angebote zu vergleichen und zu bewerten.
Inhalt
 Auftraggeber
 Ausgangslage
 Auftragsgegenstand
 Termine
 Bedingungen
 Vorgaben an die Offerte
 Administrativer Ablauf der Beschaffung
4.4.1.27 Organisationsanforderungen
Beschreibung
Die Organisationsanforderungen definieren, ob es ein neues oder aktualisiertes Geschäftsmo-
dell braucht oder ob die Aufbau- oder Ablauforganisation ändert. Sie beinhalten jene kon-
textbezogenen, betriebswirtschaftlichen und organisatorischen Anforderungen, die die in-
terne Organisation im Rahmen der künftigen Lösung stärken und der Lösung selbst einen
höheren Wirkungsgrad ermöglichen.
Sie umfassen neben den klassischen aufbau- und ablauforganisationsspezifischen Aspekten
auch die Anforderungen an die Wirtschaftlichkeit, Effektivität und Effizienz sowie die Ziele der
Stammorganisation und die aus den Zielen abgeleitete Organisationsstrategie, oftmals mani-
festiert in einem Geschäftsmodell, das den Rahmen vorgibt, in den die neue Organisation
eingepasst werden muss.
56 / 200
Inhalt
Der Inhalt ist stark durch das Projekt und die Vorgehensweise geprägt.
 Ausgangslage
 Stossrichtung des geplanten/geänderten Geschäftsmodells
 Stossrichtung der geplanten/geänderten Aufbauorganisation
 Stossrichtung der geplanten/geänderten Ablauforganisation
 Anforderungskatalog
4.4.1.28 Organisationsbeschreibung
Beschreibung
Die Organisationsbeschreibung beschreibt die Aufbauorganisation mit dem detaillierten Or-
ganigramm, den Funktionsbeschreibungen und Personalanforderungen. Sie bildet die Grund-
lage für Stellenbesetzungen.
Inhalt
 Organigramm
 Organisatorische Schnittstellen
 Funktionsbeschreibungen
 Personalanforderungen
4.4.1.29 Organisationskonzept
Beschreibung
Das Organisationskonzept vertieft die in der Studie beschriebene und gewählte Lösungsvari-
ERGEBNISSE
ante aus organisatorischer Sicht. Es basiert auf den Organisationsanforderungen, ggfs. er-
gänzt durch die Erkenntnisse aus den Lösungsanforderungen und beschreibt die relevanten
Geschäftsmodellaspekte sowie Aufbau- und Ablauforganisation (Geschäftsprozesse) für die
Geschäftsabwicklung und den Support. Es zeigt auf, welche neue Organisation erstellt wird
und welche Änderungen an Bestehendem vorgenommen werden.
Inhalt
 Ausgangslage
 Organisationsanforderungen
 Geschäftsmodell mit
o Kundensegmentierung und Werteangebote
o Kundenberührungspunkte und Kundenbeziehungen
o Schlüsselaktivitäten und Schlüsselressourcen
o Schlüsselpartnerschaften
o Einnahmequellen und Kostenstruktur
 Aufbauorganisation mit
o Organisationsprinzipien und -varianten
o Grober Organisationsbeschreibung
o Organigramm
 Ablauforganisation mit
o Prozesslandkarte
o Ist-/Soll-Beschreibung
o Zu unterstützenden Prozessen
o Grober Prozessbeschreibung mit
 Kernprozessen
 Führungsprozessen
 Supportprozessen
 Übersicht der Veränderungen
57 / 200
4.4.1.30 Phasenbericht
Beschreibung
Der Phasenbericht bildet die Grundlage für den Entscheid über die Freigabe der nächsten
Phase und für die Aktualisierung des Projektstatusberichts. Er fasst die Ergebnisse und Ent-
scheide der aktuellen Phase zusammen und zeigt die Organisation der nächsten Phase auf.
Inhalt
 Ausgangslage
 Strategiebezug, Erfolge und Umsetzung von Vorgaben
 Nutzen und Wirtschaftlichkeit
 Rechtliche Grundlagen
 Planung und Organisation
 Prognose der Zielerreichung und Lösungen
 Risiken
 Anträge
 Fazit
4.4.1.31 Produktdokumentation
Beschreibung
Die Produktdokumentation ist die technische Dokumentation des Produkts. Alle im Entwick-
lungsprozess definierten Dokumentationen bilden zusammen die Produktdokumentation. Sie
ist eine Voraussetzung für die Wartung und Weiterentwicklung des Produkts.
Inhalt
ERGEBNISSE
Der Inhalt der Produktdokumentation ist abhängig von den im Entwicklungsprozess definier-
ten Ergebnissen.
4.4.1.32 Produktkonzept
Beschreibung
Das Produktkonzept vertieft die in der Studie beschriebene und gewählte Lösungsvariante. Es
basiert auf den Lösungsanforderungen, ggfs. ergänzt durch die Erkenntnisse aus den Organi-
sationsanforderungen und beschreibt das zu erstellende Produkt. Je nach Produkt und Kom-
plexität der Lösungsanforderungen variieren die Struktur und der Detaillierungsgrad.
Inhalt
 Ausganslage
 Anforderungen
 Abgrenzung
 Verwendungszweck
 Produktklassifizierungen
 Varianten mit
o Übersicht über das Produkt mit
 Beschreibung
 Produktstruktur
 Komponenten
 Bezug zu den Geschäftsprozessen
o Abgrenzung
o Anforderungsabdeckung
o Konformität mit Vorgaben
o Machbarkeitsbeurteilung
 Variantenvergleich
 Gewählte Variante
58 / 200
4.4.1.33 Projekterfahrungen
Beschreibung
Die Projekterfahrungen werden systematisch gesammelt und als Projekt-Rückblick laufend
dokumentiert. Sie unterstützen den kontinuierlichen Verbesserungsprozess im Projekt und in
der Stammorganisation. Sie liefern wertvolle Informationen für den weiteren Projektverlauf
und mögliche Anhaltspunkte für nachfolgende Projekte, indem positive Aspekte erkannt und
übernommen und negative Aspekte möglichst vermieden werden.
Inhalt
 Kontakt
 Themengebiet
 Datum
 Erfahrung: positiv/negativ
 Relevanz: mögliche Bedeutung für das eigene oder für andere Projekte
 Mögliche Ursachen
 Empfehlung; Hinweise für die Stammorganisation
4.4.1.34 Projektinitialisierungsauftrag
Beschreibung
Der Projektinitialisierungsauftrag bildet die verbindliche Grundlage für die Freigabe der Phase
Initialisierung. Es handelt sich um eine Vereinbarung zwischen dem Auftraggeber und dem
Projektleiter für die Phase Initialisierung.
Inhalt
ERGEBNISSE
 Ausgangslage
 Ziele
o Ziele der Phase Initialisierung
o Rahmenbedingungen
 Ressourcenbedarf mit
o Personalaufwand
o Sachmittel
o Kosten
 Termine
 Projektorganisation und Personal
 Kommunikation
 Risiken
4.4.1.35 Projektmanagementplan
Beschreibung
Die erstmalige Ausarbeitung des Projektmanagementplans wird durch den Varianten- und
Vorgehensentscheid in der Initialisierungsphase geprägt. Insbesondere der Vorgehensent-
scheid, ob klassisch oder agil, beeinflusst die Ausführung der Aufgaben und die Struktur und
Inhalt der Ergebnisse.
Der Projektmanagementplan beinhaltet die Gesamtplanung des Projekts und die wesentli-
chen Regelungen zu Methoden, Techniken, Rollen und Hilfsmitteln, die projektspezifisch fest-
gelegt werden. Der Projektmanagementplan dient als einheitliche Handlungsgrundlage für
alle Projektbeteiligten. Im Rahmen der Projektorganisation stellt er sicher, dass die Verant-
wortlichkeiten und die Aufgabenteilungen zwischen Leistungsbezügern, internen Leistungs-
erbringern und ggf. externen Lieferanten ausreichend klar geregelt und dokumentiert sind. Er
wird im Projektverlauf nach dem Prinzip der rollenden Planung und Steuerung kontinuierlich
konkretisiert und nachgeführt.
59 / 200
Bei agiler Lösungsentstehung wird der Terminplan für die Phase Umsetzung mit dem (agilen)
Releaseplan kombiniert. Dieser Releaseplan gibt den Umfang der Releases an und wann der
Betrieb pro Release aktiviert wird. Ferner wird festgehalten, ob der (optionale) Entscheid Re-
leasefreigabe treffen im Projekt vorgeschrieben ist oder nicht.
Bei Phasenabschluss wird der Projektmanagementplan zur Abwicklung der nächsten Phase
den veränderten Bedingungen angepasst. Bevor die Phase Abschluss freigegeben wird, wird
der Projektmanagementplan für den Projektabschluss zusätzlich entsprechend vorbereitet
und angepasst.
Inhalt
 Projektbeschreibung
o Zusammenfassung
o Phasen und Meilensteinen (klassisch) oder Releases (agil)
o Releasefreigabe ja/nein (agil)
 Szenario mit Durchführungsstrukturplan
 Durchführungsorganisation mit
o Projektorganigramm
o Rollen in der Stamm- und Projektorganisation
o Besetzung der Rollen (einschliesslich des Entwicklungsteams (agil))
 Projektergebnisstruktur
 Qualitätsziele und -vorgaben (für die Durchführung)
 Prüfplan (QS)
 Durchführungsplanung mit
o Terminplan
o Releaseplan (agil) mit
ERGEBNISSE
 Releases
 Abhängigkeiten und Voraussetzungen
 Organisation
 Terminen
 Kostenplan/genehmigtes Budget
 Ressourcenplan
 Beschaffungsplan
 Kommunikationsplan
 Stakeholdermanagement (projektspezifisch)
 Reporting
 Vorgaben, Methoden, Arbeitsinstrumente und Werkzeuge
 Änderungsmanagement
 Risikomanagement
 Eskalationsvorgehen
 Dokumentenmanagement
4.4.1.36 Projektschlussbeurteilung
Beschreibung
Die Projektschlussbeurteilung bildet die Grundlage für den Entscheid zum Projektabschluss.
Sie informiert den Auftraggeber über den Soll-Ist-Vergleich bezüglich der sachlichen, termin-
lichen und finanziellen Projekt- und Vorgehensziele. Die Inhalte des Ergebnisses Projekterfah-
rungen sind zusammenfassend dokumentiert. Inhalt und Termine der Projekterfolgskontrolle
sind bestimmt.
Inhalt
 Ausgangslage
 Beurteilung der Zielerreichung
 Wirtschaftlichkeit
60 / 200
 Soll-Ist-Vergleich
o Kosten/Nutzen
o Aufwand
o Termine
o Ergebnisse
 Projekterfahrungen
 Pendenzen und Massnahmen
o Direkt aus dem Projekt mit
 Offenem Punkt
 Massnahme
 Verantwortlichen
 Umsetzungstermin
o Weitere Massnahmen nach Projektabschluss mit
 Massnahme
 Verantwortlichen
 Umsetzungstermin
 Antrag
4.4.1.37 Projektstatusbericht
Beschreibung
Der Projektstatusbericht dient zur periodischen Berichterstattung über den Projektstand, den
Projektfortschritt und die Prognosen zum weiteren Projektverlauf. Die Art und Weise der Be-
richterstattung ist im Projektmanagementplan geregelt. Vorgaben der Stammorganisation
bezüglich Inhalt und Frequenz des Reportings werden berücksichtigt.
ERGEBNISSE
Inhalt
 Übersicht Projektstand
 Prognose der Zielerreichung (agil: Burn-Down-Diagramm)
 Soll-Ist-Vergleich und Prognosen mit
o Kosten/Nutzen
o Aufwand
o Termine
o Ergebnisse
 Probleme und Massnahmen
 Risiken
 Ausblick
4.4.1.38 Protokoll
Beschreibung
Das Protokoll dokumentiert einerseits die Entscheide und Aufträge, die in einer Besprechung
getroffen bzw. erteilt werden, anderseits wichtige Führungs- und Ausführungsprozesse, die
später bei Bedarf nachvollzogen werden müssen. Wichtige Diskussions- und Handlungs-
punkte werden festgehalten. Im Protokoll festgehaltene Aufträge werden in einer Pendenzen-
liste verwaltet.
Generell:
Die Sammlung aller Protokolle dient der Nachvollziehbarkeit von Entscheiden und Abläufen
bzw. Prozessen.
Inhalt
 Sitzungsart/Thema
 Datum
 Teilnehmer
61 / 200
 Traktanden mit
o Protokollpunkten
o Verantwortlichen
o Endtermin
 Pendenzenliste (Anhang)
4.4.1.39 Prototypdokumentation
Beschreibung
Die Prototypdokumentation bildet die Grundlage für die Erstellung und Auswertung des Pro-
totyps. Sie hält die Ziele, Anforderungen, Ergebnisse und Schlussfolgerungen des Prototy-
pings fest.
Inhalt
 Ausgangslage
 Rahmenbedingungen
 Anforderungen
 Konzept
o Konzept des Prototyps
o Benötigte Infrastruktur
 Zusammenfassung der Testergebnisse
o Hinweis auf Testkonzept
o Liste der Testfälle
o Zusammenfassung der Testprotokolle, Testbericht
 Schlussfolgerungen
 Empfehlungen
ERGEBNISSE
4.4.1.40 Prozessbeschreibung
Beschreibung
Die Prozessbeschreibung ist eine bis auf Prozessebene ausdetaillierte Ablauforganisation, sie
beschreibt die einzelnen Prozesse mit den eingesetzten Hilfsmitteln.
Inhalt
 Prozessbezeichnung
 Prozessverantwortlicher
 Prozessbeteiligte
 Prozessziele
 Prozesskennzahlen/Messgrössen
 Kritische Erfolgsfaktoren
 Prozessbewertung
 Prozessdiagramm mit
o Input
o Output
o Aktivitäten
o Hilfsmitteln
4.4.1.41 Prüfprotokoll
Beschreibung
Das Prüfprotokoll hält die Befunde aus Prüfungen fest und dokumentiert die Umsetzungsent-
scheide zu den Befunden sowie den Entscheid zum Status des Ergebnisses.
Inhalt
 Zu prüfendes Ergebnis
 Prüfdatum
 Prüfer
 Befund
62 / 200
 Entscheid zum Ergebnis
 Entscheid zum Befund
4.4.1.42 Publikation
Beschreibung
Die Publikation informiert über die Zuschlagserteilung in der betreffenden Ausschreibung.
Form und Inhalt der Publikation werden durch die Controlling- und Vorgabestellen bzw. die
Beschaffungsstelle vorgegeben.
Inhalt
 Betroffene Ausschreibung
 Beschaffungsstelle
 Zuschlagsempfänger
 Rechtsmittel
4.4.1.43 QS- und Risikobericht

Beschreibung
Der QS (Qualitätssicherungs)- und Risikobericht informiert aus unabhängiger Sicht über die
Qualität und die Risikosituation des Projekts. Der Inhalt des QS- und Risikoberichts ist abhän-
gig von Auftrag und Abgrenzung sowie von den eingesetzten Methoden.
Inhalt
 Auftrag und Abgrenzung
 Vorgehensweise
ERGEBNISSE
 Gesamtbeurteilung mit Projektstatus
 Qualitätsbeurteilung
 Risikobeurteilung
 Empfehlungen
4.4.1.44 Rechtsgrundlagenanalyse
Beschreibung
Die Rechtsgrundlagenanalyse beschreibt die für das Projektergebnis bestehende bzw. gel-
tende Rechtsgrundlagen und den allfälligen Bedarf für deren Änderung. Ein besonderes Au-
genmerk gilt den kommunalen, kantonalen, nationalen und allenfalls auch den internationalen
rechtlichen sowie produktrelevanten und regulatorischen Vorgaben, die die anvisierte Lösung
samt ihren Auswirkungen auf die Umsysteme, einhalten muss (Product Compliance).
Inhalt
 Bestehende Rechtsgrundlagen
 Bevorstehende Änderungen
 Identifizierte Lücken
 Vorschläge zur Schliessung von Lücken
 Hinweise betreffend Product Compliance
 Beurteilung der Konsequenzen
 Empfehlungen
4.4.1.45 Releasebericht
Beschreibung
Der Releasebericht liefert die Übersicht über den bisherigen Projekterfolg und bildet die
Grundlage für die Erstellung des Projektstatusberichts sowie, je nach Bestimmung im Projekt-
managementplan, auch für den Entscheid über die etwaige Freigabe des nächsten Release. Er
fasst die Ergebnisse und Entscheide des aktuellen Release zusammen und zeigt eine Übersicht
über den noch zu leistenden Aufwand im Projekt.
63 / 200
Inhalt
 Ausgangslage
 Strategiebezug und Erfolge
 Nutzen und Wirtschaftlichkeit
 Inhalt des Release
 Bekannte Fehler
 Burn-Down-Diagramm
 Risiken
 Fazit
4.4.1.46 Schutzbedarfsanalyse
Beschreibung
Die Schutzbedarfsanalyse, auch ISDS-Analyse genannt, dokumentiert die Anforderungen an
die Informationssicherheit und den Datenschutz.
Inhalt
 Anforderungskategorie
 Anforderungsbeschreibung
 Anforderungszuordnung
4.4.1.47 Service Level Agreement

Beschreibung
Ein Service Level Agreement (SLA) ist eine Art von Vereinbarung zwischen dem Betreiber und
ERGEBNISSE
dem Anwender, vertreten durch den Auftraggeber und den Anwendervertreter. Das SLA
nennt die Dienstleistungen, die der Betreiber zu erbringen hat, definiert deren Service Level
(Güte der Dienstleistung) und formuliert etwaige Massnahmen und Sanktionen bei Nichtein-
haltung. Die vereinbarten Dienstleistungen und deren Service Level sind in der Regel kosten-
pflichtig.
Wird der Betrieb outgesourcet, können die SLAs ein wichtiger Faktor bei der Evaluation des
möglichen Betreibers sein.
Inhalt
Der Inhalt eines SLAs wird durch die Stammorganisation vorgegeben. Bei einem externen
Provider kann bereits ein vorgefertigtes SLA vorliegen. Das SLA kann unter anderem die fol-
genden Punkte beinhalten:
 Präambel mit
o Gegenstand
o Ziele
o Partner
 Geltungsbereich
 Inkrafttreten, Laufzeit, Kündigung
 Dienstleistungen
 Vergütung mit
o Verrechnungspreisen
o Rechnungsstellung
o Zahlungsmodalitäten
 Berichtswesen mit
o Service-Level-Berichte (Standardberichte)
o Weitere Berichte (ggf.)
 Konsequenzen bei Abweichung von vereinbarten Service-Levels
 Regelungen zur Kontrolle des SLAs (SLA-Audits)
 Regelungen zur Änderung des SLAs
 Regelung zur Lösung von Konflikten
 Datenschutz
64 / 200
 Haftung und Gewährleistung
 Schadensersatz
 Anwendbares Recht
 Gerichtsstand
 Schiedsgerichtsverfahren
 Vertraulichkeit, Geheimhaltung und Veröffentlichung
 Teilnichtigkeit von Regelungen
 Unterschriften
 Beilagen
4.4.1.48 Situationsanalyse
Beschreibung
Die Situationsanalyse beschreibt und analysiert die gegenwärtige Situation und die zukünfti-
gen Entwicklungen und ergänzt bzw. vertieft die grobe Standortbestimmung aus der Studie.
Zur Bestimmung des Untersuchungsbereichs wird der gesamtheitliche Lösungs- und Einfluss-
bereich der in der Phase Initialisierung gewählten Variante herangezogen. Neben der Zusam-
menstellung der wesentlichen Mengen und Häufigkeiten geht die Situationsanalyse insbeson-
dere auf die Mängel und Schwachstellen ein, die mit der künftigen Lösung möglichst beseitigt
werden sollen, und definiert die vorhandenen Stärken, die erhalten werden sollen. In der Si-
tuationsanalyse wird geprüft, ob das Modul Organisation relevant ist.
Die Situationsanalyse bildet die fachliche Basis für die Definition der vom Projektergebnis zu
erfüllenden Lösungs- und Organisationsanforderungen. Sie ist ziel- und lösungsneutral und
umfasst alle für die Lösung relevanten Aspekte.
ERGEBNISSE
Inhalt
 Einleitung
 Ist-Organisation (falls relevant) mit
o Geschäftsmodell/geschäftlicher Sichtweise
o Aufbauorganisation/Strukturen
o Ablauforganisation/Prozesse
 Beschreibung, sofern vorhanden, der bestehenden Lösung (Ist-System/Ist-Produkt)
o Ziel und Anwendungszweck, Funktion
o Dokumentationen zur bestehenden Lösung wie
 Ursprüngliche Lösungsbeschreibung/Lösungskonzept
 Rahmenbedingungen und Vorgaben
 Anwenderdokumentation
 Betriebshandbuch
 ISDS
 Schnittstellen und Umsysteme (organisatorisch/technisch)
o Betriebskosten
 Mengen und Häufigkeiten
 Stärken-, Schwächen- und Ursachenanalyse
 Beschreibung des Ist-Gesamtkontexts
 Fazit und Handlungsbedarf
4.4.1.49 Stakeholderinteressen
Beschreibung
Die Stakeholderinteressen bilden die Grundlage für die Information der Stakeholder und für
die direkte Zusammenarbeit mit ihnen. Die Analyse der Stakeholderinteressen wird getrennt
von der Stakeholderliste geführt. Diese Analyse ist eine subjektive, projektinterne Einschät-
zung und kein öffentliches Ergebnis. Die Stakeholderinteressen werden für die Kommunika-
tion und für die Zusammenarbeit mit den Stakeholdern benötigt und werden regelmässig
nachgeführt..
65 / 200
Inhalt
 Stakeholder-Positionierung
 Stakeholder-Beschreibung
 Erkannte Interessen- und Zielkonflikte
4.4.1.50 Stakeholderliste
Beschreibung
Die Stakeholderliste wird erstmals in der Phase Initialisierung erarbeitet und bildet die Grund-
lage für das Managen der Stakeholder, für die direkte Zusammenarbeit mit ihnen und für die
Kommunikationsplanung. Sie wird im Projektablauf kontinuierlich weitergeführt.
Inhalt
 Stakeholder
4.4.1.51 Studie
Beschreibung
Die Studie beschreibt die angestrebte Lösung, indem sie basierend auf der Standortbestim-
mung die groben Ziele definiert, mögliche Lösungsvarianten und das vorgeschlagene Vorge-
hen aufführt und diese anschliessend bewertet. Sie entspricht dem ‹Business-Case› und zeigt
den Geschäftsnutzen sowie den Bezug zur Strategie und den Zielen der Stammorganisation.
Alle Aspekte, die einen Einfluss auf die geplante Lösung haben oder die von der Lösung be-
einflusst werden können, werden in der Studie erwähnt. Darüber hinaus wird das passende
Szenario (vgl. Kapitel 2 Szenarien) ausgewählt, allenfalls ein individuelles Szenario erstellt und
es wird geschätzt, welche Wertigkeit das Projekt haben wird.
ERGEBNISSE
Die Studie wird nur soweit detailliert, dass die Stossrichtung des anvisierten Projekts klar er-
sichtlich ist und der Entscheid Weiteres Vorgehen getroffen werden kann. Die straffe Vorge-
hensweise trifft insbesondere auf die Standortbestimmung zu, um die Initialisierungsphase
nicht unnötig zu verlängern.
Der in der Studie dokumentierte Entscheid über das weitere Vorgehen bildet die Grundlage
für die Entscheidungsvorbereitung, ob ein Projekt fortgesetzt wird oder nicht. Die Studie ist
die Voraussetzung für die Erarbeitung des Projektmanagementplans und des Durchführungs-
auftrags.
Inhalt
 Ausgangslage
 Standortbestimmung aus geschäftlicher Sicht mit
o Mengen und Häufigkeiten
o Informationssicherheit und Datenschutz
o Stärken-, Schwächen- und Ursachenanalyse
o Lösungskontext und Abgrenzungen
o Analyse und Bewertung
 Ziele
 Rahmenbedingungen
 Grobanforderungen
 Lösungsvarianten mit
o Variantenübersicht
o Beschreibung je Variante inkl. vorgeschlagener Vorgehensweise
o Analyse und Bewertung mit
 Zielerreichungsgrad
 Anforderungsabdeckung
 Kosten/Nutzen/Wirtschaftlichkeits-Betrachtungen
 Risikobeurteilung (Projekt- und Betriebsrisiken)
 Weiteren Kriterien wie Nachhaltigkeit usw.
66 / 200
 Vorschlag Weiteres Vorgehen inklusive Begründung mit
o Lösungsvariante
o Szenario
o Vorgehensweise
o Projektwertigkeit
 Entscheid Weiteres Vorgehen bezüglich
o Lösungsvariante
o Szenario
o Vorgehensweise
o Projektwertigkeit
 Planung und Termine
o Szenario und Module
o Projekttermine, Meilensteine
o Geplanter Nutzungszeitraum
4.4.1.52 Systemkonzept
Beschreibung
Das Systemkonzept vertieft die in der Studie beschriebene und gewählte Lösungsvariante. Es
basiert auf den Lösungsanforderungen und zeigt auf, wie sie mit der Lösung erfüllt werden.
Das Systemkonzept kann mehrere Systemvarianten beschreiben und beurteilen.
Es kann mehrere Systemkonzepte zu verschiedenen Themenbereichen geben.
Inhalt
 Ausgangslage
 Anforderungen
ERGEBNISSE
 Lösungskonzept mit
o Systemvarianten
 Beschreibung
 Anforderungsabdeckung
 Machbarkeitsbeurteilung
 Variantenvergleich
 Empfehlung
4.4.1.53 Testkonzept
Beschreibung
Das Testkonzept beschreibt die Testziele, Testobjekte, Testarten, Testinfrastruktur sowie Test-
organisation. Es umfasst ebenfalls die Testplanung und die Testfallbeschreibungen. Für jeden
Testfall wird eine detaillierte Testfallbeschreibung erstellt. Diese stellt die Spezifikation des
Tests dar. Die Testplanung legt den logischen und zeitlichen Ablauf der Tests fest. Das Test-
konzept bildet die Grundlage, auf der die Testorganisation und die Testinfrastruktur bereitge-
stellt und die Tests durchgeführt werden. Tauchen neue Erkenntnisse auf, wird das Testkon-
zept nachgeführt.
Inhalt
 Testziele
 Teststrategie und Teststufen
 Testobjekte
 Testarten
 Testabdeckung
o Übersicht Testfälle
o Beurteilung Testziele und Testabdeckung
 Testrahmen mit
o Testvoraussetzungen
o Mängelklassifizierung
o Start- und Abbruchbedingungen
 Testumgebung
67 / 200
 Testfallbeschreibungen
 Testplan
 Testorganisation und Zuständigkeiten
 Testinfrastruktur mit
o Testsystem
o Testdaten
o Testhilfsmittel
4.4.1.54 Testprotokoll
Beschreibung
Das Testprotokoll hält die Testergebnisse fest. Die Testergebnisse werden gemäss den im
Testkonzept definierten Mängelklassen bewertet.
Inhalt
 Übersicht der Testfälle/Testdurchführungen
 Testfall
o Testfallbeschreibung
o Testdatum, Tester
o Mängelklasse (Testergebnis)
o Mängelbeschreibung
4.4.1.55 Vereinbarung
Beschreibung
Die Vereinbarung regelt die Zusammenarbeit zwischen den verschiedenen Projektbeteiligten,
ERGEBNISSE
vorwiegend zwischen Anwender (Auftraggeber) und Ersteller. Die Vereinbarung kann für eine
oder mehrere Phasen abgeschlossen werden. Vereinbarungen werden unterschieden nach
Projektvereinbarung oder Vertrag.
Inhalt
Der Inhalt von Vereinbarungen wird durch die Stammorganisation vorgegeben. Die Verein-
barung kann unter anderem die folgenden Punkte beinhalten:
 Einführung
 Geltungsbereich
 Leistungsumfang und Ergebnisse
 Eingesetzte Personen
 Mitwirkungspflichten
 Qualitätssicherung und Abnahme
 Gewährleistung
 Datenschutz und Datensicherheit
 Änderungsmanagement
 Rapportierung
 Aufwand und Kosten
 Unterschriften
 Ergänzende technische Normen
 Reglemente
 Weisungen
4.4.2 Zustände
4.4.2.1 Altsystem entfernt
Beschreibung
Die alte Systemversion sowie das Altsystem sind unter Berücksichtigung der Vorgaben abge-
baut bzw. entfernt. Die Ausserbetriebssetzung umfasst ebenfalls die Vernichtung oder Archi-
vierung von Daten.
68 / 200
4.4.2.2 Betrieb aktiviert
Beschreibung
Der Betrieb des aktivierten Systems ist aufgenommen und erfolgt mit der im Betriebskonzept
definierten Betriebsorganisation. Die im Betriebshandbuch festgelegten Aktivitäten werden
ausgeführt. Das Betriebspersonal nimmt die Betriebsaufgaben wahr. Die Voraussetzungen für
die Messung und Einhaltung des SLAs sind gegeben.
4.4.2.3 Betriebsinfrastruktur realisiert

Beschreibung
Die Betriebsinfrastruktur umfasst alle für die Erstellung und den Betrieb eines Systems benö-
tigten Infrastrukturen mit den verschiedenen Systemumgebungen (Entwicklung, Test, Produk-
tion usw.) und allen ihren Komponenten. Zur Betriebsinfrastruktur gehören auch die für die
Betriebsüberwachung nötigen Komponenten wie Monitoring und Alarmierung, Statistikwerk-
zeuge usw.
4.4.2.4 Betriebsorganisation realisiert

Beschreibung
Die im Betriebskonzept definierte Betriebsorganisation mit der Betriebsaufbauorganisation
und den Betriebsprozessen des Betreibers sind realisiert. Das Betriebspersonal ist ausgebildet
und kann die Betriebsaufgaben wahrnehmen.
4.4.2.5 Einführungsmassnahmen durchgeführt

Beschreibung
ERGEBNISSE
Die im Einführungskonzept beschriebenen und realisierten Massnahmen sind durchgeführt.
Die Umsetzung der Massnahmen ist überprüft und deren Qualitätssicherung durchgeführt.
Beispielsweise ist die Anwenderschulung durchgeführt worden und es liegen Kursbeurteilun-
gen der Teilnehmer für die Qualitätssicherung vor.
4.4.2.6 Einführungsmassnahmen realisiert

Beschreibung
Die im Einführungskonzept beschriebenen Massnahmen und die für die Einführung nötige
Organisation sind realisiert. Beispielsweise sind die Superuser rekrutiert und ausgebildet, die
die Anwender bei der Einführung unterstützen, oder die Ausbildungsunterlagen sind realisiert,
damit anschliessend Schulungen durchgeführt werden können.
4.4.2.7 ISDS-Konzept überführt

Beschreibung
Das ISDS-Konzept wurde aktualisiert, durch die Controlling- und Vorgabestelle geprüft und
von der Projektorganisation in die Stammorganisation überführt.
4.4.2.8 ISDS-Massnahmen realisiert

Beschreibung
Die ISDS-Massnahmen wurden auf der Grundlage des ISDS-Konzepts realisiert. Sie stellen si-
cher, dass die Anforderungen an den Schutzbedarf gemäss ISDS-Konzept erfüllt werden.
4.4.2.9 Meilensteine
Beschreibung
Meilensteine gehören zu den Zuständen und sind immer die Folge eines Entscheides. Sie
kennzeichnen und definieren einen erreichten konkreten Zeitpunkt im Projektverlauf.
69 / 200
Meilensteine dienen als anvisierte und erreichte Entscheidungsergebnisse der Projektsteue-
rung und -führung, verleihen dem Projekt eine Struktur und markieren im Projektverlauf wich-
tige Punkte, an denen über die weiteren Projektschritte entschieden wird.
 Meilenstein Abnahme
Der Meilenstein wird erreicht, wenn der Entscheid Abnahme getroffen wird . Die Lösung wird
definitiv in die Anwendungs- und allenfalls auch in die Betriebsorganisation überführt. Da-
nach beginnt die Gewährleistung und damit der reguläre Betrieb.
 Meilenstein Abnahme Migration
Der Meilenstein wird erreicht, wenn der Entscheid Abnahme Migration getroffen wird. Die
Nutzung des neuen Systems kann für die Anwender freigegeben werden (Entscheid Be-
triebsaufnahme).
 Meilenstein Ausschreibung
Der Meilenstein wird erreicht, wenn der Entscheid Ausschreibung getroffen wird. Die Aus-
schreibung kann publiziert werden.
 Meilenstein Betriebsaufnahme
Der Meilenstein wird erreicht, wenn der Entscheid Betriebsaufnahme getroffen wird. Die
Lösung kann in Betrieb genommen werden.
 Meilenstein Durchführungsfreigabe
Der Meilenstein wird erreicht, wenn der Entscheid Durchführungsfreigabe getroffen wird.
Die Arbeiten starten gemäss dem Durchführungsauftrag.
 Meilenstein ISDS-Konzept
Der Meilenstein wird erreicht, wenn der Entscheid ISDS-Konzept getroffen wird. Die Rea-
lisierung der ISDS-Massnahmen kann an die Hand genommen werden.
 Meilenstein Lösungsarchitektur
ERGEBNISSE
Der Meilenstein wird erreicht, wenn der Entscheid Lösungsarchitektur getroffen wird. Dies
bildet die Voraussetzung für die Entwicklung oder Adaption von Systemen.
 Meilenstein Phasenfreigabe
Der Meilenstein wird erreicht, wenn der Entscheid Phasenfreigabe getroffen wird. Die Ar-
beiten in der nächsten Phase können gestartet werden.
 Meilenstein Phasenfreigabe Abschluss
Der Meilenstein wird erreicht, wenn der Entscheid Phasenfreigabe Abschluss getroffen
wird. Die Leistungserbringung im Rahmen der Lösungsentstehung ist beendet. Die Arbei-
ten in der in der Phase Abschluss können gestartet werden.
 Meilenstein Produktkonzept
Der Meilenstein wird erreicht, wenn der Entscheid Produktkonzept getroffen wird. Das
Konzept ist die Voraussetzung für die Entwicklung oder Adaption von Produkten oder
Dienstleistungen.
 Meilenstein Projektabschluss
Der Meilenstein wird erreicht, wenn der Entscheid Projektabschluss getroffen wird. Das
Projekt ist beendet.
 Meilenstein Projektinitialisierungsfreigabe
Der Meilenstein wird erreicht, wenn der Entscheid Projektinitialisierungsfreigabe getroffen
wird. Das Projekt wurde formell ins Leben gerufen. Die Arbeiten starten gemäss dem Pro-
jektinitialisierungsauftrag.
 Meilenstein Releasefreigabe
Der Meilenstein wird erreicht, wenn der Entscheid Releasefreigabe getroffen wird. Im Rah-
men der agilen Vorgehensweise können die Arbeiten am nächsten Release starten.
 Meilenstein Vorabnahme
Der Meilenstein wird erreicht, wenn der Entscheid Vorabnahme getroffen wird. Dies bildet
die Grundlage für die Durchführung der Einführungsmassnahmen und die Betriebsauf-
nahme.
70 / 200
 Meilenstein Weiteres Vorgehen
Der Meilenstein wird erreicht, wenn der Entscheid Weiteres Vorgehen getroffen wird. Dies
bildet die Grundlage für die Erarbeitung des Projektmanagementplans sowie des Durch-
führungsauftrags.
 Meilenstein Zuschlag
Der Meilenstein wird erreicht, wenn der Entscheid Zuschlag getroffen wird. Der Entscheid
kann publiziert und die Vertragsarbeiten mit dem Zuschlagsempfänger gestartet werden.
4.4.2.10 Migration durchgeführt

Beschreibung
Die Migration vom alten auf das neue bzw. weiterentwickelte System ist durchgeführt und
gemäss den Vorgaben der Controlling- und Koordinationsstellen dokumentiert. Die Nachvoll-
ziehbarkeit der Migration wird sichergestellt. Die erfolgreich durchgeführte Migration ist die
Voraussetzung für deren Abnahme und den Entscheid Betriebsaufnahme.
4.4.2.11 Migrationsverfahren realisiert

Beschreibung
Das realisierte Migrationsverfahren ist durch den Entwickler bzw. den Tester des Erstellers ge-
testet worden. Er erbringt den Nachweis seiner Tests. Sie bilden die Voraussetzung für die
Vorabnahme.
4.4.2.12 Organisation aktiviert

Beschreibung
ERGEBNISSE
Die neue Organisation ist aktiviert. Sie führt ihre Prozesse gemäss den Prozessbeschreibungen
durch.
Wird die neue Organisation im Rahmen einer klassischen Lösungsentstehung aktiviert, ist dies
die Voraussetzung für die Aktivierung des Produkts oder des Systems. Bei agiler Lösungsent-
stehung wird nur der entsprechende Teil der Organisation aktiviert.
4.4.2.13 Organisation umgesetzt

Beschreibung
Die im Organisationskonzept definierte Organisation ist umgesetzt.
Auf Grundlage der Prozessbeschreibung und der Organisationsbeschreibung wurden die
Massnahmen realisiert, um die Organisation ins Leben zu rufen (Stellenbesetzungen, Perso-
nalanstellungen usw.).
4.4.2.14 Produkt aktiviert

Beschreibung
Das aktivierte Produkt wird den Anwendern für die Nutzung zur Verfügung gestellt.
4.4.2.15 Produkt entwickelt oder angepasst

Beschreibung
Das entwickelte und/oder angepasste Produkt ist durch den Entwickler bzw. den Tester des
Erstellers getestet worden. Es wird für die Tests und die Vorabnahme an den Anwender über-
geben.
4.4.2.16 Prototyp realisiert

Beschreibung
Mit dem Prototyp wird die Machbarkeit oder das Verhalten eines Systems bzw. eines Produkts
in einer bestimmten Situation geprüft. Mit Prototypen werden Risiken bewertet und reduziert.
71 / 200
Im Projektverlauf können zwecks Überprüfung der Machbarkeit mehrere, verschiedene Pro-
totypen realisiert werden. Es kann zwischen Wegwerfprototypen und wiederverwendbaren
Prototypen unterschieden werden.
4.4.2.17 Schnittstellen realisiert

Beschreibung
Die realisierten Schnittstellen stellen den Datenaustausch zwischen dem System und den Um-
systemen sicher.
Die Schnittstelle ist durch den Entwickler bzw. den Integrator und den Tester des Erstellers
getestet worden. Sie wird dem Betreiber für die Integration in die Betriebsinfrastruktur über-
geben.
4.4.2.18 System aktiviert

Beschreibung
Das aktivierte System wird den Anwendern für die Nutzung zur Verfügung gestellt.
4.4.2.19 System entwickelt oder parametrisiert

Beschreibung
Das entwickelte und/oder parametrisierte System ist durch den Entwickler bzw. den Integrator
und den Tester des Erstellers getestet worden. Es wurde dem Betreiber für die Integration in
die Betriebsinfrastruktur übergeben. Die Entwicklung und die Integration können in mehreren
Schritten bzw. Releases erfolgen.
ERGEBNISSE
4.4.2.20 System integriert

Beschreibung
Das integrierte System steht den Testern des Anwenders für die Tests und die Vorabnahme
zur Verfügung.
Nach den Entscheiden Vorabnahme und Betriebsaufnahme wird das System aktiviert.
4.4.2.21 Testinfrastruktur realisiert

Beschreibung
Für die Durchführung der Tests wird eine Testinfrastruktur bestehend aus Testsystem (darun-
ter sind alle Systeme zur Testdurchführung zu verstehen), Testdaten und Testhilfsmitteln ver-
wendet. Sie wird gemäss Testkonzept bereitgestellt. Je nach Testmethode werden unter-
schiedliche Anforderungen an die Testinfrastruktur gestellt. Folgend können auch unter-
schiedliche Testsysteme benötigt werden.
Die Testinfrastruktur richtet sich nach der Infrastruktur des Produktionssystems, also nach der
realisierten Betriebsinfrastruktur. Das Testsystem muss soweit dem Produktionssystem ent-
sprechen, dass die Testfallbeschreibungen unter realistischen Bedingungen durchgeführt wer-
den können.
Werden für die Tests als Testdaten nicht anonymisierte Kopien von produktiven Daten ver-
wendet, müssen die Anforderungen an ISDS erfüllt sein.
4.4.2.22 Testinfrastruktur überführt

Beschreibung
Die gesamte Testinfrastruktur inklusive des Testkonzepts wurde in die Stammorganisation
überführt.
72 / 200
5 Aufgaben
5.1 Einleitung
5.1.1 Aufgabenpositionierung
In HERMES stehen die Ergebnisse im Mittelpunkt. Sie werden mit den Aufgaben erarbeitet.
Eine Aufgabe besteht aus mehreren Aktivitäten. Aktivitäten dienen der Erarbeitung eines oder
mehrerer Ergebnisse sowie der Sicherstellung der Qualitätsanforderungen.
Es wird zwischen zwei Arten von Aufgaben unterschieden:
 Entscheidungsaufgaben, die zu einem Entscheid führen und mit dem Ergebnis Meilenstein
enden. Sie werden weiter unterteilt in
o Entscheidungsaufgaben der Steuerung und
o Entscheidungsaufgaben der Führung.
 Sonstigen Aufgaben, die den Projektverlauf begleiten, der Ergebnis- und Lösungserarbei-
tung dienen und die Qualität sicherstellen bzw. erhöhen.
Aufgabenbeschreibungen ersetzen nicht die Kenntnisse der anzuwendenden Methoden und
Praktiken und eine entsprechende Ausbildung.
5.1.2 Entscheidungsaufgaben
5.1.2.1 Generell
Im Projektverlauf müssen Entscheide getroffen werden. Aufgaben, die zu einem Entscheid
führen, sind als Entscheidungsaufgaben definiert. Sie enden mit einem Meilenstein.
HERMES unterscheidet zwischen Entscheiden, die durch die Projektsteuerung, sowie Entschei-
den, die durch die Projektführung getroffen werden. So erfolgt beispielsweise der Entscheid
Betriebsaufnahme durch den Auftraggeber (Steuerung), während der Entscheid Lösungsar-
chitektur durch den Projektleiter (Führung) erfolgt.
Die Steuerung prüft am Ende einer Phase (klassisch), ggf. eines Release (agil, falls der Ent-
scheid Releasefreigabe treffen im Projekt vorgeschrieben ist), ob die benötigten Fachent-
scheide vorliegen. Fehlen diese, wird die nächste Phase bzw. das nächste Release nicht frei-
AUFGABEN
gegeben. Die Steuerung kann so Entscheidungen treffen, ohne selbst über die notwendige
Fachkompetenz zu verfügen.
Entscheidungsaufgaben werden mit einer Checkliste unterstützt.
5.1.2.2 Entscheide der Steuerung

Auf der Hierarchieebene Steuerung entscheidet der Auftraggeber. Er entscheidet über die
Projektinitialisierungsfreigabe, Durchführungsfreigabe, Phasenfreigaben, ggf. Releasefreiga-
ben und den Projektabschluss, allenfalls Projektabbruch sowie über wichtige Weichenstellun-
gen wie eine Ausschreibung auslösen, einen Zuschlag entscheiden oder eine Betriebsauf-
nahme bewilligen. Bei Bedarf wird er durch weitere Rollen, wie z. B. den Projektausschuss, den
Projektleiter oder den Anwendervertreter beraten und unterstützt.
5.1.2.3 Entscheide der Führung

Entscheide der Führung sind Entscheide des Projektleiters zu Projektergebnissen.
Prüfung und Abnahme von technischen Ergebnissen erfolgen zuhanden der Führung durch
die Ausführung, d. h. durch die jeweiligen Spezialisten für das entsprechende Thema. Je nach
Vorgehensmodell planen der Projektleiter oder Anwendervertreter die Entscheidungsaufga-
ben. Sie berücksichtigen die Vorgaben der Controlling- und Vorgabestellen der Stammorga-
nisation.
73 / 200
5.2 Übersicht der Aufgaben
5.2.1 Standardaufgaben
Die Tabelle zeigt die Zuordnung aller bereitgestellten Aufgaben samt entsprechender Ergeb-
nisse zu Projektphasen, wobei die Entscheidungsaufgaben farblich (pink) hervorgehoben sind.
I K R E U A
Altsystem ausser Betrieb setzen Altsystem entfernt X
Änderungen managen Änderungsantrag X X X
Änderungsstatusliste X X X X
Lösungsanforderungen X X X
Angebote bewerten Evaluationsbericht X X
Angebotsprotokoll X X
Ausschreibung durchführen Angebot X X
Ausschreibungsunterlagen X X
Ausschreibung erarbeiten Ausschreibungsunterlagen X X
Beschaffungsanalyse erarbeiten Beschaffungsanalyse X
Betrieb aktivieren Betriebshandbuch X X
Betrieb aktiviert X X
Betrieb realisieren Betriebshandbuch X X
Betriebsinfrastruktur realisiert X X
Betriebsorganisation realisiert X X
Betriebskonzept erarbeiten Betriebskonzept X X
Service Level Agreement X X
Durchführungsauftrag erarbeiten Durchführungsauftrag X
Einführungsmassnahmen durchführen Einführungsmassnahmen durchgeführt X X
Einführungsmassnahmen realisieren Einführungsmassnahmen realisiert X X
Einführungskonzept erarbeiten Einführungskonzept X X
Projektmanagementplan X X
Entscheid Abnahme Migration treffen Checkliste Abnahme Migration X X
Meilenstein Abnahme Migration X X
AUFGABEN

Entscheid Abnahme treffen Checkliste Abnahme X X
Meilenstein Abnahme X X
Entscheid Ausschreibung treffen Checkliste Ausschreibung X X
Meilenstein Ausschreibung X X
Entscheid Betriebsaufnahme treffen Checkliste Betriebsaufnahme X X
Meilenstein Betriebsaufnahme X X
Entscheid ISDS-Konzept treffen Checkliste ISDS-Konzept X X
Meilenstein ISDS-Konzept X X
Entscheid Lösungsarchitektur treffen Checkliste Lösungsarchitektur X X
Meilenstein Lösungsarchitektur X X
Entscheid Phasenfreigabe Abschluss treffen Checkliste Phasenfreigabe Abschluss X X
Meilenstein Phasenfreigabe Abschluss X X
Entscheid Phasenfreigabe treffen Checkliste Phasenfreigabe X X
Meilenstein Phasenfreigabe X X
74 / 200
I K R E U A
Entscheid Produktkonzept treffen Checkliste Produktkonzept X X
Meilenstein Produktkonzept X X
Entscheid Projektabbruch treffen Checkliste Projektabbruch X X X X
Projekterfahrungen X X X X
Projektschlussbeurteilung X X X X
Meilenstein Projektabschluss X X X X
Liste Projektentscheide Steuerung X X X X
Entscheid Projektabschluss treffen Checkliste Projektabschluss X
Meilenstein Projektabschluss X
Entscheid Durchführungsfreigabe treffen Checkliste Durchführungsfreigabe X
Durchführungsauftrag X
Meilenstein Durchführungsfreigabe X
Entscheid Projektinitialisierungsfreigabe treffen Checkliste Projektinitialisierungsfreigabe X
Projektinitialisierungsauftrag X
Meilenstein Projektinitialisierungsfreigabe X
Entscheid Releasefreigabe treffen Checkliste Releasefreigabe X
Meilenstein Releasefreigabe X
Entscheid Vorabnahme treffen Checkliste Vorabnahme X X
Meilenstein Vorabnahme X X
Entscheid Weiteres Vorgehen treffen Checkliste Weiteres Vorgehen X
Studie X
Meilenstein Weiteres Vorgehen X
Liste Projektentscheide Führung X
Entscheid Zuschlag treffen Checkliste Zuschlag X X
AUFGABEN
Publikation X X
Meilenstein Zuschlag X X
Integrationskonzept erarbeiten Integrationskonzept X X
ISDS-Konzept erarbeiten ISDS-Konzept X X
ISDS-Konzept realisieren ISDS-Massnahmen realisiert X X
ISDS-Konzept X X
ISDS-Konzept überführen ISDS-Konzept überführt X X
ISDS-Konzept X X
Leistungen vereinbaren und steuern Offertanfrage X X X X
Angebot X X X X
Evaluationsbericht X X X X
Vereinbarung X X X X
Lösungsarchitektur erarbeiten Systemkonzept X X
Migration durchführen Migration durchgeführt X X
Migrationskonzept erarbeiten Migrationskonzept X X
Migrationsverfahren realisieren Detailspezifikation X X
Migrationsverfahren realisiert X X
75 / 200
I K R E U A
Organisation aktivieren Organisation aktiviert X X
Organisation umsetzen Prozessbeschreibung X X
Organisation umgesetzt X X
Organisationsanforderungen erarbeiten Situationsanalyse X X
Organisationsanforderungen X X
Organisationskonzept erarbeiten Organisationskonzept X X
Geschäftsmodellbeschreibung X X
Prozessbeschreibung X X
Phasenfreigabe vorbereiten Phasenbericht X X X X
Probleme behandeln und Erfahrungen nutzen Projekterfahrungen X X X X X
Produkt aktivieren Produkt aktiviert X X
Produkt realisieren Detailspezifikation X X
Produktdokumentation X X
Produkt entwickelt oder angepasst X X
Produktkonzept erarbeiten Produktkonzept X X
Projekt führen und kontrollieren Projektmanagementplan X X X X X X
Arbeitsauftrag X X X X X X
Projektstatusbericht X X X X X X
Protokoll X X X X X X
Lösungsanforderungen X
Detailspezifikation X
Projekt steuern QS- und Risikobericht X X X X
Liste Projektentscheide Steuerung X X X X X X
Projektabschluss vorbereiten Projekterfahrungen X
Projektschlussbeurteilung X
Projektmanagementplan erarbeiten Projektmanagementplan X
Prototyping durchführen Prototyp realisiert X X X X
Prototypdokumentation X X X X
AUFGABEN
Qualitätssicherung führen Projektmanagementplan X X X X X

Prüfprotokoll X X X X X
Rechtsgrundlagenanalyse erarbeiten Rechtsgrundlagenanalyse X
Releaseabschluss vorbereiten Releasebericht X
Projektmanagementplan X
Projektstatusbericht X
Risiken managen Projektmanagementplan X X X X
Schutzbedarfsanalyse erarbeiten Schutzbedarfsanalyse X
Stakeholder managen und informieren Stakeholderliste X X X X X X
Stakeholderinteressen X X X X X X
Projektmanagementplan X X X X X X
Studie erarbeiten Studie X
Stakeholderliste X
System aktivieren System aktiviert X X
System in Betrieb integrieren Betriebshandbuch X X
System integriert X X
System realisieren Detailspezifikation X X
Systemkonzept X X
System entwickelt oder parametrisiert X X
76 / 200
I K R E U A
Systemintegration vorbereiten Schnittstellen realisiert X X
Integrations- und Installationsanleitung X X
Detailspezifikation X X
Test durchführen Testprotokoll X X X
Testkonzept X X X
Testinfrastruktur realisieren Testinfrastruktur realisiert X X
Testinfrastruktur überführen Testkonzept X
Testinfrastruktur überführt X
Protokoll X
Testkonzept erarbeiten Testkonzept X X
Vereinbarung erarbeiten Vereinbarung X X
Tabelle 18: Zuordnung aller Aufgaben samt entsprechender Ergebnisse zu Projektphasen
5.2.2 Individuelle Aufgaben

Ergänzend zu den standardmässig bereitgestellten Aufgaben besteht die Möglichkeit, neue
fach-, organisations- oder vorhabenspezifische Aufgaben in eigene Module zu integrieren
und diese anschliessend mit Ergebnissen zu erweitern.
Dies wird durch HERMES-Online unterstützt und kommt insbesondere dann zum Tragen,
wenn neue Module entwickelt werden. Beispiele von individuellen Aufgaben können ein er-
weitertes, stammorganisationsspezifisches Reporting oder ein projektspezifisches Risikoma-
nagement sein.
5.3 Erläuterung der Aufgabenbeschreibung

Für jede Aufgabe gibt es eine Aufgabenbeschreibung, die stets gleich strukturiert ist:
 Zweck
definiert den Sinn und Zweck der Aufgabe.
 Grundidee
schafft das grundlegende Verständnis der Aufgabe.
 HERMES-spezifisch
beschreibt, wie HERMES die Aufgabe konkret unterstützt.
AUFGABEN
 Grundlagen/Voraussetzungen
listen die Ergebnisse, die für die Ausführung der Aufgabe, sofern relevant, notwendig sind.
Bei den Aufgaben während der Lösungsentstehung variiert die Liste je nach Szenario. Bei
Bedarf sind die Ergebnisse mit "A" für agil bzw. mit "K" für klassisch gekennzeichnet.
 Aktivitäten
beschreiben, wie die Aufgabe ausgeführt wird. Nach Möglichkeit sind die Aktivitäten chro-
nologisch aufgeführt. Bei Bedarf sind die Aktivitäten mit "A" für agil bzw. mit "K" für
klassisch gekennzeichnet.
 Beziehungen (nur online verfügbar)
zeigen den Bezug der Aufgabe zu anderen Methodenelementen.
 Ergebnisse
zeigen auf, welche Ergebnisse aus der Aufgabe entstehen. Bei Bedarf sind die Ergebnisse
mit "A" für agil bzw. mit "K" für klassisch gekennzeichnet.
77 / 200
5.4 Beschreibung der Aufgaben
5.4.1 Entscheidungsaufgaben der Steuerung
5.4.1.1 Entscheid Ausschreibung treffen
Umsetzung
Zweck
Der Entscheid Ausschreibung schafft die Voraussetzung für die Publikation.
Grundidee
Nach dem Entscheid Ausschreibung erfolgt die Veröffentlichung oder, bei einem Einladungs-
verfahren, der Versand der Ausschreibungsunterlagen.
HERMES-spezifisch
Der Entscheid Ausschreibung erfolgt durch den Auftraggeber, ggf. unter Mitwirkung der Aus-
schreibungsstelle der Stammorganisation. Der Auftraggeber stellt die Abstimmung mit der
Stammorganisation sicher.
Grundlagen/Voraussetzungen
 Ausschreibungsunterlagen
 Projektmanagementplan
Aktivitäten
 Checkliste Ausschreibung mit weiteren Kriterien ergänzen.
 Ausschreibungsunterlagen mit der Checkliste Ausschreibung überprüfen.
 Überprüfen, ob übergeordnete Strategien, Standards und Vorgaben eingehalten sind und
Bestätigungen der zuständigen Stellen vorliegen.
 Entscheidung mit der Stammorganisation abstimmen.
 Formellen Entscheid Ausschreibung treffen.
Ergebnisse
AUFGABEN
 Checkliste Ausschreibung
 Liste Projektentscheide Steuerung
5.4.1.2 Entscheid Betriebsaufnahme treffen

Umsetzung
Zweck
Der Entscheid Betriebsaufnahme bildet die Voraussetzung für die Aktivierung des Produkts
oder des Systems (mit anschliessender Aktivierung des Betriebs) und für die produktive Nut-
zung der Lösung.
Grundidee
Der Auftraggeber entscheidet auf Antrag des Projektleiters oder des Anwendervertreters über
die Betriebsaufnahme.
HERMES-spezifisch
Der Entscheid Betriebsaufnahme des Auftraggebers basiert auf den Entscheiden Vorabnahme
und Abnahme Migration, auf der Durchführung der Einführungsmassnahmen und auf weite-
ren, z. T. projektspezifischen Freigabekriterien gemäss Einführungskonzept.
78 / 200
 Einführungskonzept
 Einführungsmassnahmen durchgeführt
 ISDS-Konzept überführt
Aktivitäten
 Checkliste Betriebsaufnahme mit weiteren Freigabekriterien ergänzen.
 Freigabekriterien beurteilen und Einführungsrisiken einschätzen und präsentieren.
 Formellen Entscheid Betriebsaufnahme treffen.
 Nutzung für die Anwender nach erfolgreicher Betriebsaufnahme freigeben.
Ergebnisse
 Checkliste Betriebsaufnahme
5.4.1.3 Entscheid Durchführungsfreigabe treffen

Umsetzung
Zweck
Der Entscheid Durchführungsfreigabe setzt das Projekt mit der nächsten Phase fort und startet
die Lösungsentstehung. Er schafft die Voraussetzung für die Arbeiten in der Phase Konzept
bei klassischer Vorgehensweise und in der Phase Umsetzung bei agiler Vorgehensweise.
Grundidee
Auf der Grundlage des erarbeiteten Durchführungsauftrags überprüft der Auftraggeber, ob
das Projekt den Zielen der Organisation dient und ob die nötigen Ressourcen freigegeben
werden können.
Mit der Durchführungsfreigabe beginnt die Lösungsentstehung und die entsprechend ange-
passte Projektorganisation wird in Kraft gesetzt. Die für die nächste Phase benötigten Res-
AUFGABEN
sourcen werden freigegeben.
HERMES-spezifisch
Die Durchführungsfreigabe erfolgt am Ende der Phase Initialisierung. Der Entscheid wird
durch den Auftraggeber in Abstimmung mit der Stammorganisation getroffen, evtl. im Rah-
men eines bestehenden Portfolios. Vor der Durchführungsfreigabe werden der Durchfüh-
rungsauftrag und der Projektmanagementplan mit den übergeordneten Vorgaben der Stam-
morganisation abgeglichen.
Der Projektmanagementplan und die angepasste Projektorganisation werden entschieden
und in Kraft gesetzt. Bei agiler Vorgehensweise wird das Entwicklungsteam in der Projektor-
ganisation formell etabliert.
Mit der Durchführungsfreigabe wird die Lösungsentstehung eingeläutet, die bei klassischer
Vorgehensweise mit der Phase Konzept, bei agiler Vorgehensweise mit der Phase Umsetzung
startet.
Es wird entschieden, ob
 die Phase Initialisierung abgeschlossen wird oder ob weitere Ergebnisse zu erarbeiten sind
und, sofern die Phase Initialisierung abgeschlossen werden kann, ob die Projektfortsetzung
 freigegeben wird,
 zurzeit nicht freigegeben wird und später nochmals beantragt werden soll oder
 nicht freigegeben und das Vorhaben beendet wird (stellt keinen eigentlichen Projektab-
bruch dar, vgl. Entscheid Projektabbruch treffen).
79 / 200
 Durchführungsauftrag
Aktivitäten
 Checkliste Durchführungsfreigabe mit weiteren Kriterien ergänzen.
 Überprüfung des Durchführungsauftrags mit der Checkliste Durchführungsfreigabe durch
den Auftraggeber.
 Ressourcen (personell, finanziell, Infrastruktur) für die gesamte Projektdauer sicherstellen.
 Ressourcen für die nächste Phase freigeben.
 Durchführungsauftrag den Entscheidungsträgern zustellen.
 Projektorganisation wird gegenüber Stammorganisation und Stakeholdern kommuniziert.
 Entscheidung in der Stammorganisation abstimmen.
 Formellen Entscheid Durchführungsfreigabe treffen.
 Bei positivem Entscheid:
o Durchführungsauftrag unterschreiben;
o Ressourcen für Lösungsentstehung (Phase Konzept bzw. Umsetzung) freigeben;
o Stakeholder über Entscheid informieren.
Ergebnisse
 Checkliste Durchführungsfreigabe
 Meilenstein Durchführungsfreigabe
5.4.1.4 Entscheid Phasenfreigabe Abschluss treffen

Umsetzung
Zweck
Der Entscheid Phasenfreigabe Abschluss beendet die Leistungserbringung im Rahmen der
Lösungsentstehung und schafft die Voraussetzung für die Arbeiten in der Phase Abschluss.
AUFGABEN
Grundidee
Die Ergebnisse der gesamten Lösungsentstehung werden geprüft sowie abgenommen oder
zurückgewiesen. Die Phase wird abgeschlossen und die Phase Abschluss sowie die dazu be-
nötigten Ressourcen werden freigegeben.
HERMES-spezifisch
Am Ende der Phase Einführung oder Umsetzung werden der Phasenbericht und zusätzlich in
der Phase Umsetzung auch noch der letzte Releasebericht abgenommen. Der Auftraggeber
entscheidet über das Ende der Lösungsentstehung sowie über die Freigabe der Phase Ab-
schluss.
Erfolgte die Lösungsentstehung agil, wird das Entwicklungsteam aufgelöst.
Es wird entschieden,
 ob die Phase abgeschlossen wird oder ob vor dem Phasenabschluss weitere Ergebnisse
zu erarbeiten sind oder
 ob die Phase Abschluss freigegeben wird.
 Phasenbericht
 Releasebericht
80 / 200
 Projektstatusbericht
Aktivitäten
 Checkliste Phasenfreigabe Abschluss mit weiteren Freigabekriterien ergänzen.
 Formellen Entscheid Phasenfreigabe Abschluss treffen oder Ergebnisse zurückweisen.
o Ressourcen für nächste Projektphase freigeben.
o Betroffene über Entscheid informieren.
Ergebnisse
 Checkliste Phasenfreigabe Abschluss
 QS- und Risikobericht
5.4.1.5 Entscheid Phasenfreigabe treffen

Umsetzung
Zweck
Der Entscheid Phasenfreigabe schafft im Rahmen der klassischen Vorgehensweise die Voraus-
setzung für die Arbeiten in der nächsten Phase.
Grundidee
Die Ergebnisse der Phase werden geprüft sowie abgenommen oder zurückgewiesen. Die lau-
fende Phase wird abgeschlossen und die nächste Projektphase sowie die dazu benötigten
Ressourcen werden freigegeben. Können die gesetzten Ziele nicht erreicht werden, wird das
Projekt beendet (siehe Entscheid Projektabbruch treffen).
HERMES-spezifisch
Am Ende der laufenden Projektphase wird der Phasenbericht abgenommen und über den
Abschluss der Phase entschieden. Anschliessend entscheidet der Auftraggeber über die Frei-
AUFGABEN
gabe der nächsten Phase.
Vor der Phasenfreigabe werden der Phasenbericht und der Projektmanagementplan mit den
übergeordneten Vorgaben der Stammorganisation abgeglichen. Dabei werden neue Erkennt-
nisse berücksichtigt.
Anpassungen des Projektmanagementplans und der Projektorganisation werden entschieden
und in Kraft gesetzt.
Wenn im Projekt spezifische Stellen für Controlling und QS/Risikomanagement beauftragt
wurden, erstellen sie einen Bericht zuhanden des Auftraggebers.
 Phasenbericht
Aktivitäten
 Checkliste Phasenfreigabe mit weiteren Freigabekriterien ergänzen.
 Ziele, Machbarkeit und Nutzen der anvisierten Lösung aufgrund neuer Erkenntnisse kri-
tisch überprüfen und mit den Zielen der Stammorganisation abstimmen.
81 / 200
 Überprüfen, ob übergeordnete Strategien, Standards und Vorgaben eingehalten sind und
Bestätigungen der zuständigen Stellen vorliegen.
 Sicherstellen, dass die benötigten Ressourcen (personell, finanziell, Infrastruktur, Wissen
und Erfahrung) für die gesamte restliche Projektdauer rechtzeitig und ausreichend zur
Verfügung stehen.
 Phasenbericht, Projektmanagementplan und phasenspezifischen Ergebnisse prüfen und
genehmigen oder zurückweisen.
 Formellen Entscheid Phasenfreigabe treffen oder Ergebnisse zurückweisen.
o Ressourcen für nächste Projektphase frei geben.
 Können die gesetzten Ziele nicht erreicht werden:
o Entweder Korrekturmassnahmen festlegen, oder
o Entscheid Projektabbruch treffen und Beendigung des Projekts beantragen.
Ergebnisse
 Checkliste Phasenfreigabe
 Meilenstein Phasenfreigabe
5.4.1.6 Entscheid Projektabbruch treffen

Umsetzung
Zweck
Mit dem Entscheid Projektabbruch wird die vorzeitige Beendigung eines Projektes beschlos-
sen, noch bevor die gesetzten Ziele erreicht worden sind. Die Projektorganisation wird aufge-
löst und das Projekt geordnet beendet.
Grundidee
Ein Projektabbruch ist ein nicht geplanter Schritt, der höchstens dann als mögliche Handlung
AUFGABEN
vorgesehen werden kann, wenn z. B. ein Pilotprojekt, ein Forschungsprojekt oder ein Projekt
unter erschwerten kritischen Bedingungen angegangen wird.
Der meist unpopuläre Schritt eines Projektabbruchs liegt vollumfänglich in der Kompetenz
und Verantwortung des Auftraggebers. Der Abbruch soll möglichst reibungslos und ohne
«Kollateralschäden» erfolgen. Die Auflösung der Projektorganisation wird analog einem Pro-
jektabschluss durchgeführt. Die Projektbeteiligten werden offiziell aus den Projektverantwort-
lichkeiten entlassen.
Die Dokumentenablage wird bereinigt und die vorhandene Projektdokumentation an die
Stammorganisation übergeben. Die Projektabbruchgründe werden zusammengetragen und
dokumentiert. Eventuell offene relevante Pendenzen und unerledigte Punkte werden an die
zuständigen Personen in der Stammorganisation übergeben. Allfällige rechtliche Aspekte, die
sich aus nicht erfüllten Verträgen ergeben, gehen an die Rechtsabteilung der Stammorgani-
sation.
HERMES-spezifisch
Ein Projektabbruch ist nur im Rahmen der Lösungsentstehung möglich, also nach dem Ent-
scheid Durchführungsfreigabe und vor dem Entscheid Phasenfreigabe Abschluss. Er stellt ei-
nen vorzeitigen, nicht geplanten, evtl. auch abrupten Projektabschluss mit dem Meilenstein
Projektabschluss dar. Der Entscheid wird durch den Auftraggeber getroffen.
Eine Beendigung des Projekts während der Phase Initialisierung stellt keinen eigentlichen Pro-
jektabbruch dar, weil die Initialisierung einer strukturierten Orientierung für ein fokussiertes
Vorhaben dient und die allenfalls ausbleibende Freigabe der Durchführung mit anschliessen-
der Beendigung des Vorhabens zu den im Voraus einkalkulierten möglichen Schritten zählt.
82 / 200
Dies gilt auch für Beendigung des Vorhabens im früheren Verlauf der Initialisierung. Eine for-
melle Beendigung des Vorhabens ist nicht vorgesehen, dennoch können bei Bedarf einige
Aktivitäten dieser Aufgabe die Beendigung unterstützen.
Es ist darauf zu achten, dass die bereits erbrachte Wertschöpfung erhalten werden kann und
so der projektabbruchbedingte Schaden begrenzt bleibt.
Da die Aufgabe Projektabschluss vorbereiten im Falle eines Projektabbruchs nicht durchge-
führt werden kann, müssen zusätzlich vor dem Entscheid die Projekterfahrungen und die Pro-
jektschlussbeurteilung samt Abbruchhinweis erarbeitet werden.
Die Projektschlussbeurteilung der Projektleitung wird durch die Projektsteuerung geprüft und
genehmigt bzw. zurückgewiesen. Der Auftraggeber leitet wichtige Erfahrungen aus dem Pro-
jekt an die relevanten Stellen weiter.
Der Auftraggeber stellt sicher, dass die Anforderungen der Controlling- und Vorgabestelle
sowie der Governance an einen geordneten Projektabbruch erfüllt sind.
Es wird entschieden,
 dass das Projekt abgebrochen wird.
wurden, erstellen sie einen eigenen Schlussbericht.
Alle Projektmitarbeiter, alle betroffenen Stakeholder sowie alle am Projekt beteiligten internen
Stellen und externen Dienstleister werden orientiert.
Aktivitäten
 Checkliste Projektabbruch mit weiteren Kriterien ergänzen.
 Dokumentenablage bereinigen.
 Bereits entstandene Wertschöpfung, wenn möglich sichern.
 Laufende Arbeiten daraufhin prüfen, ob sie sofort abgebrochen werden sollen oder besser
bis zum fertigen Ergebnis fortzusetzen sind.
 Sicherstellen, dass die Abschlussarbeiten vollständig erfolgt sind; entsprechende Prüfun-
AUFGABEN
gen durchführen bzw. beauftragen.
 Nicht benötigte Ressourcen (Infrastruktur usw.) an die Stammorganisation zurückgege-
ben.
 Zugriffsberechtigungen aufheben, die spezifisch für das Projekt erteilt wurden.
 Aufwanderfassungssysteme, die Projektbuchhaltung, das Reporting usw. abschliessen.
 Offene Pendenzen aus dem Projekt an verantwortliche Personen in der Stammorganisa-
tion übergeben.
 Entscheidung den Controlling- und Vorgabestellen sowie dem Projektteam kommunizie-
ren.
 Vorhaben im möglichen Portfolio löschen lassen.
 Schlusssitzung des Projektausschusses durchführen.
 Formellen Entscheid Projektabbruch treffen.
 Projektorganisation auflösen.
 Betroffene und Interessierte über Entscheid informieren.
 Projekterfahrungen um die Erfahrung des Projektabbruchs ergänzen und an relevante
Stellen weiterleiten.
 Rechtliche Aspekte wie Streitfragen betreffend Vereinbarungen, Rückabwicklung, Mitver-
schuldung, Honorare, Schadendersatzansprüche u. ä. in einem separaten Auftrag samt
Unterlagen an die Rechtsabteilung der Stammorganisation weiterleiten oder die Juristen
direkt beiziehen.
83 / 200
Ergebnisse
 Checkliste Projektabbruch
 Projektschlussbeurteilung
5.4.1.7 Entscheid Projektabschluss treffen

Umsetzung
Zweck
Mit dem Entscheid Projektabschluss wird die Projektorganisation aufgelöst und das Projekt
beendet.
Grundidee
Der letzte Schritt des Projektabschlusses ist die Auflösung der Projektorganisation. Sie liegt in
Kompetenz und Verantwortung des Auftraggebers. Die Projektbeteiligten werden offiziell aus
den Projektverantwortlichkeiten entlassen.
HERMES-spezifisch
Der Entscheid Projektabschluss ist der letzte ordentliche und formelle Entscheid im Projekt.
Der Auftraggeber prüft, ob alle Ergebnisse formell korrekt dokumentiert und für weitere Nut-
zung und für die Anwendungsorganisation geordnet bereitgestellt sind. Er stellt weiter sicher,
dass die Anforderungen der Controlling- und Vorgabestelle sowie der Governance an den
Projektabschluss erfüllt sind. Er prüft die Projektschlussbeurteilung der Projektleitung, geneh-
migt sie oder weist sie zurück. Wichtige Erfahrungen aus dem Projekt leitet er an die relevan-
ten Stellen weiter.
Ferner prüft er, inwieweit die aufzulösende Projektorganisation während der Nutzungsdauer
des Lösungssystems als Anwendungsorganisation Verwendung finden könnte und wenn ja,
ob dies im Rahmen der Stammorganisation möglich bzw. machbar sei.
Der Auftraggeber entscheidet,
AUFGABEN
 ob das Projekt abgeschlossen wird oder ob vor dem Projektabschluss weitere Dokumen-
tation der Ergebnisse zu erarbeiten ist; und
 ob die aufgelöste Projektorganisation unter einer anderen Bezeichnung teilweise oder
vollständig an die Nachfolgeorganisation übergeht oder nicht.
wurden, erstellen sie einen eigenen Schlussbericht.
 Testinfrastruktur überführt
 Altsystem entfernt
Aktivitäten
 Checkliste Projektabschluss mit weiteren Kriterien ergänzen.
 Sicherstellen, dass die Abschlussarbeiten vollständig erfolgt sind. Entsprechende Prüfun-
gen durchführen bzw. beauftragen.
 Projektschlussbeurteilung und weitere Entscheidungsgrundlagen den Entscheidungsträ-
gern zustellen.
 Entscheidung mit den Controlling- und Vorgabestellen abstimmen.
 Schlusssitzung des Projektausschusses durchführen.
84 / 200
 Projektschlussbeurteilung genehmigen (oder zurückweisen).
 Formellen Entscheid zum Projektabschluss treffen.
o Projektorganisation auflösen;
o Betroffene und Interessierte über Entscheid informieren;
o Projekterfahrungen an relevante Stellen weiterleiten.
Ergebnisse
 Checkliste Projektabschluss
5.4.1.8 Entscheid Projektinitialisierungsfreigabe treffen

Umsetzung
Zweck
Mit dem Entscheid Projektinitialisierungsfreigabe wird das Projekt ins Leben gerufen und es
startet mit der Phase Initialisierung.
Grundidee
Mit der Projektinitialisierungsfreigabe beginnt formell das Projekt. Die initiale Abklärung einer
möglichen Weiterverfolgung der anvisierten Lösung wird gestartet.
In der Auftragserteilung werden die Punkte geklärt, die für die erfolgreiche Projektinitialisie-
rung wichtig sind.
HERMES-spezifisch
Der Entscheid Projektinitialisierungsfreigabe ist der erste ordentliche Entscheid im Projekt, mit
dem das Projekt formell ins Leben gerufen wird. Der Entscheid wird allein durch den Auftrag-
geber im Namen der Stammorganisation, evtl. im Rahmen eines bestehenden Portfolios ge-
troffen. Es wird entschieden, dass das anvisierte Vorhaben mit der Phase Initialisierung auf
Projekttauglichkeit und -würdigkeit geprüft werden soll.
AUFGABEN
Zur Erarbeitung des Projektinitialisierungsauftrags, die noch ausserhalb der möglichen künf-
tigen Projektstruktur erfolgt, beauftragt der Auftraggeber einen Projektleiter. Dieser muss
nicht zwingend die Projektleitung für die folgenden Phasen übernehmen. Solange der Ent-
scheid Projektinitialisierungsfreigabe nicht getroffen ist, ist das Projekt noch inexistent.
Die Projektorganisation für die Phase Initialisierung, die zumindest aus dem Auftraggeber so-
wie dem Projektleiter/Anwendervertreter (in Personalunion) besteht, wird in Kraft gesetzt. Die
für die Initialisierung benötigten Ressourcen werden freigegeben.
 Projektinitialisierungsauftrag
Aktivitäten
 Ausserhalb der möglichen künftigen Projektstruktur:
o Checkliste Projektinitialisierungsfreigabe mit weiteren Kriterien ergänzen.
o Überprüfung des Projektinitialisierungsauftrags durch den Auftraggeber anhand der
Checkliste Projektinitialisierungsfreigabe.
o Ressourcen für die Phase Initialisierung sicherstellen.
 Im Rahmen des Projekts
o Formellen Entscheid Projektinitialisierungsfreigabe treffen.
o Projektinitialisierungsauftrag unterschreiben.
85 / 200
o Ressourcen für die Phase Initialisierung freigeben.
o Stammorganisation orientieren und Vorhaben im eventuell vorhandenen Portfolio ein-
tragen lassen.
Ergebnisse
5.4.1.9 Entscheid Releasefreigabe treffen

Umsetzung
Zweck
Der Entscheid Releasefreigabe schafft im Rahmen der agilen Vorgehensweise die Vorausset-
zung für die Arbeiten im nächsten Release.
Grundidee
Die Ergebnisse des Release werden geprüft sowie abgenommen oder zurückgewiesen. Das
laufende Release wird abgeschlossen und das nächste freigegeben. Können die gesetzten
Ziele nicht erreicht werden, wird das Projekt beendet (siehe Entscheid Projektabbruch treffen).
HERMES-spezifisch
Ob der optionale Entscheid Releasefreigabe im Projekt zwingend durchgeführt wird oder
nicht, richtet sich nach dem entsprechenden Vermerk im Projektmanagementplan.
Am Ende des aktuellen Release wird der Releasebericht abgenommen und über den Ab-
schluss des Release entschieden. Anschliessend entscheidet der Auftraggeber über die Frei-
gabe des nächsten Release.
Vor der Releasefreigabe werden der Releasebericht und der Projektmanagementplan mit den
übergeordneten Strategien und den Zielen der Stammorganisation oder eines allenfalls über-
geordneten Programms abgeglichen. Dabei werden neue Erkenntnisse berücksichtigt.
AUFGABEN
Wenn spezifische Stellen für Controlling und QS/Risikomanagement beauftragt wurden, er-
stellen sie einen Bericht zuhanden des Auftraggebers.
 Releasebericht
Aktivitäten
 Checkliste Releasefreigabe mit weiteren Freigabekriterien ergänzen.
 Überprüfen, ob übergeordnete Strategien, Standards und Vorgaben eingehalten werden
und Bestätigungen der zuständigen Stellen vorliegen.
 Releasebericht, Projektmanagementplan und weitere Entscheidungsunterlagen den Ent-
scheidungsträgern zustellen.
 Sicherstellen, dass die benötigten Ressourcen (personell, finanziell, Infrastruktur, Wissen
und Erfahrung) für die gesamte restliche Projektdauer rechtzeitig und ausreichend zur
Verfügung stehen.
 Releasebericht, Projektmanagementplan und releasespezifische Ergebnisse prüfen und
genehmigen oder zurückweisen.
 Formellen Entscheid Releasefreigabe treffen oder Ergebnisse zurückweisen.
86 / 200
 Können die gesetzten Ziele nicht erreicht werden:
o Entweder Korrekturmassnahmen festlegen; oder
o Entscheid Projektabbruch treffen und Beendigung des Projekts beantragen.
Ergebnisse
 Checkliste Releasefreigabe
 Meilenstein Releasefreigabe
5.4.1.10 Entscheid Zuschlag treffen

Umsetzung
Zweck
Der Entscheid Zuschlag schafft die Voraussetzung für die Publikation des Zuschlags und die
Erarbeitung des Vertrags mit dem Zuschlagsempfänger.
Grundidee
Nach dem Entscheid Zuschlag werden die Anbieter über das Ergebnis der Bewertung infor-
miert. Der Zuschlag wird publiziert.
HERMES-spezifisch
Der Entscheid Zuschlag erfolgt durch den Auftraggeber.
Die Aktivitäten richten sich nach dem Kapitel Beschaffungsplan im Projektmanagementplan.
Hierbei sind etwaige Vorgaben der Stammorganisation zu beachten.
 Evaluationsbericht
 Angebotsprotokoll
AUFGABEN
Aktivitäten
 Checkliste Zuschlag ergänzen.
 Evaluationsbericht den Entscheidungsträgern zustellen.
 Entscheidung mit der Stammorganisation und den für das Beschaffungswesen verantwort-
lichen Controlling- und Vorgabestellen abstimmen.
 Evaluationsbericht genehmigen oder zurückweisen.
 Bei Genehmigung des Evaluationsberichts:
o Formellen Entscheid Zuschlag treffen;
o Zuschlag publizieren, z. B. auf www.simap.ch;
o Absagen den nicht berücksichtigten Anbietern zustellen;
o Bei Bedarf Anbietergespräche durchführen;
o Evtl. weitere Aktivitäten nach spezifischen Vorgaben der Stammorganisation.
Ergebnisse
 Checkliste Zuschlag
 Publikation
87 / 200
5.4.2 Entscheidungsaufgaben der Führung
5.4.2.1 Entscheid Abnahme Migration treffen
Umsetzung
Zweck
Der Entscheid Abnahme Migration zeigt auf, dass die Migration erfolgreich war und bildet
eine der Voraussetzungen für die Betriebsaufnahme.
Grundidee
Werden die Qualitätskriterien für die Migration erfüllt, wird die Nutzung des neuen Systems
für die Anwender freigegeben (Entscheid Betriebsaufnahme).
HERMES-spezifisch
Der Entscheid Abnahme Migration setzt den Entscheid Vorabnahme voraus und erfolgt vor
dem Entscheid Betriebsaufnahme.
 Migration durchgeführt
Aktivitäten
 Checkliste Abnahme Migration mit weiteren Kriterien ergänzen.
 Erreichung der Qualitätskriterien überprüfen.
 Migration abnehmen, oder zurückweisen.
o Formellen Entscheid Abnahme Migration treffen;
o Migration formal abschliessen und nachvollziehbar protokollieren;
o System freigeben.
Ergebnisse
 Checkliste Abnahme Migration
 Abnahmeprotokoll
AUFGABEN

 Liste Projektentscheide Führung
5.4.2.2 Entscheid Abnahme treffen

Umsetzung
Zweck
Der Entscheid Abnahme beendet die Leistungserbringung im Rahmen der Lösungsentste-
hung und schafft die Grundlage für den Entscheid Phasenfreigabe Abschluss. Die Lösung wird
inklusive der erforderlichen Dokumentation definitiv in die Anwendungs- und ggf. in die Be-
triebsorganisation überführt.
Grundidee
Die Abnahme erfolgt zwischen Auftraggeber und Ersteller bzw. Lieferant und Betreiber der
Lösung, wobei bei einem Produkt der Betreiber in der Regel der Anwender ist. Die Abnahme
regelt, wie offene Verpflichtungen gehandhabt werden und wie die Leistungserbringung ab-
geschlossen wird.
88 / 200
HERMES-spezifisch
Die Abnahme erfolgt nach der Betriebsaktivierung und der ersten Betriebsperiode der Lösung
bzw. eines Teils der Lösung, in der die Nutzung – z. B. gemäss Produktkonzept – erfolgen
kann und etwaige Mängel identifiziert werden.
Die Abnahme wird durch alle Beteiligten zeitgerecht geplant.
Mit der Abnahme der Lösung wird die Entwicklung/Parametrisierung des Systems, die Ent-
wicklung/Anpassung der Dienstleistung/des Produkts oder die Umsetzung der Organisation
definitiv abgeschlossen und die Leistungserbringung im Rahmen der Lösungsentstehung be-
endet.
Bei Bedarf werden unterschiedliche Abnahmen (zwischen Ersteller und Betreiber, zwischen
Ersteller und Anwender usw.) durchgeführt.
 Organisation aktiviert
 Betrieb aktiviert
 Produktdokumentation
 Anwendungshandbuch
Aktivitäten
 Organisation und Rahmenbedingungen für die Abnahme festlegen.
 Checkliste Abnahme mit weiteren Kriterien ergänzen.
 Abnahme technisch und organisatorisch vorbereiten.
 Abnahmeprozess durchführen und Befunde protokollieren.
 Formellen Entscheid über die Abnahme und das weitere Vorgehen treffen.
 Befunde analysieren und klassieren (z. B. nach Mängelklasse, neue Anforderungen).
Ergebnisse
 Checkliste Abnahme
5.4.2.3 Entscheid ISDS-Konzept treffen
AUFGABEN
Umsetzung
Zweck
Der Entscheid zum ISDS-Konzept bestätigt, dass alle ISDS relevanten Punkte erkannt und re-
alisiert werden können.
Grundidee
Mit dem Entscheid ISDS-Konzept wird die Konformität mit den Vorgaben der Stammorgani-
sation bestätigt.
HERMES-spezifisch
Vor dem Entscheid wird das ISDS-Konzept durch die zuständigen Controlling- und Vorgabe-
stellen geprüft.
Im Falle einer Beschaffung (d. h. nicht bei einer Individualentwicklung) eines Systems wird das
ISDS-Konzept nach der Evaluation überprüft. Dies, weil das gewählte Angebot einen massge-
benden Einfluss auf das ISDS-Konzept hat.
 ISDS-Konzept
89 / 200
Aktivitäten
 Checkliste ISDS-Konzept mit weiteren Kriterien ergänzen.
 ISDS-Konzept durch die zuständige Controlling- und Vorgabestelle prüfen lassen und
Stellungnahme einholen.
 Schutzmassnahmen und Restrisiken durch den Auftraggeber zur Kenntnis nehmen lassen.
 Formellen Entscheid ISDS-Konzept treffen.
Ergebnisse
 Checkliste ISDS-Konzept
5.4.2.4 Entscheid Lösungsarchitektur treffen

Umsetzung
Zweck
Der Entscheid zur Lösungsarchitektur bildet die Voraussetzung für die Entwicklung oder Pa-
rametrisierung von Systemen.
Grundidee
Mit dem Entscheid Lösungsarchitektur wird die Konformität mit der IT-Architektur der Stam-
morganisation bestätigt.
HERMES-spezifisch
Vor dem Entscheid wird die Lösungsarchitektur durch die zuständigen Controlling- und Vor-
gabestellen geprüft.
Im Falle einer Beschaffung (d. h. bei einer Adaption) eines Systems wird die Lösungsarchitektur
vor und nach der Evaluation überprüft. Dies, weil das gewählte Angebot eine Anpassung der
Lösungsarchitektur zur Folge haben kann.
 Lösungsarchitektur
AUFGABEN
Aktivitäten
 Checkliste Lösungsarchitektur mit weiteren Kriterien ergänzen.
 Lösungsarchitektur durch die zuständige Controlling- und Vorgabestelle prüfen lassen
und Stellungnahmen einholen.
 Formellen Entscheid Lösungsarchitektur treffen.
Ergebnisse
 Checkliste Lösungsarchitektur
5.4.2.5 Entscheid Produktkonzept treffen

Umsetzung
Zweck
Der Entscheid Produktkonzept bildet die Voraussetzung für die Entwicklung oder Adaption
von Produkten oder Dienstleistungen.
Grundidee
Mit dem Entscheid Produktkonzept wird die Konformität der konzipierten Lösung mit den
Anforderungen und Bedürfnissen der Stammorganisation bestätigt.
90 / 200
HERMES-spezifisch
Vor dem Entscheid wird das Produktkonzept durch die zuständigen Controlling- und Vorga-
bestellen geprüft.
Im Falle einer Beschaffung (d. h. bei einer Adaption) eines Produkts oder einer Dienstleistung
wird das Produktkonzept vor und nach der Evaluation überprüft. Dies, weil das gewählte An-
gebot eine Anpassung des Produkts zur Folge haben kann.
 Produktkonzept
Aktivitäten
 Checkliste Produktkonzept mit weiteren Kriterien ergänzen.
 Produktkonzept durch die zuständige Controlling- und Vorgabestelle prüfen lassen und
Stellungnahmen einholen.
 Formellen Entscheid Produktkonzept treffen.
Ergebnisse
 Checkliste Produktkonzept
5.4.2.6 Entscheid Vorabnahme treffen

Umsetzung
Zweck
Die Vorabnahme schafft die Grundlage für die Durchführung der Einführungsmassnahmen
sowie die anschliessende Betriebsaufnahme mit vertretbaren Risiken.
Grundidee
Für die Vorabnahme werden vorgängig qualitätssichernde Massnahmen wie Tests und In-
spektionen durchgeführt. Die Vorabnahme gibt Anwendern, Entwicklern und Betreibern die
Sicherheit, dass die Überführung der Lösung in den neuen Zustand mit hoher Wahrschein-
AUFGABEN
lichkeit erfolgreich verlaufen wird.
HERMES-spezifisch
Die Vorabnahme wird durch alle Beteiligten frühzeitig geplant. Dabei werden die Abnahme-
kriterien gemäss Einführungskonzept gemeinsam vereinbart.
 Einführungsmassnahmen realisiert
 Geschäftsmodellbeschreibung
 Prozessbeschreibung
 Organisationsbeschreibung
 Organisation umgesetzt
 ISDS-Konzept
 ISDS-Massnahmen realisiert
 System integriert
 Testprotokoll
Aktivitäten
 Organisation und Rahmenbedingungen für die Vorabnahme festlegen.
 Realisierte Einführungsmassnahmen und Notfallorganisation prüfen.
 Checkliste Vorabnahme mit weiteren Kriterien ergänzen.
91 / 200
 Vorabnahme technisch und organisatorisch vorbereiten.
 Vorabnahme durchführen und Befunde protokollieren.
 Befunde analysieren und klassieren (z. B. nach Mängelklasse, neue Anforderungen).
 Formellen Entscheid Vorabnahme treffen.
Ergebnisse
 Checkliste Vorabnahme
5.4.2.7 Entscheid Weiteres Vorgehen treffen

Umsetzung
Zweck
Der Entscheid Weiteres Vorgehen schafft Klarheit über die Wahl der Lösungsvariante, des
Szenarios, der Vorgehensweise (ob klassisch oder agil) und der Projektwertigkeit. Er bildet die
Voraussetzung für die Erarbeitung des Projektmanagementplans sowie anschliessend des
Durchführungsauftrags.
Grundidee
Der Entscheid Weiteres Vorgehen treffen ist richtungsweisend für die Durchführungsart der
Lösungsentstehung, für den späteren Betrieb und für den erzielbaren langfristigen Nutzen.
Zeigt sich, dass der erwartete Nutzen nicht erreichbar ist, wird die Arbeit zu diesem Zeitpunkt
gestoppt und die Erkenntnis für Interessierte festgehalten.
HERMES-spezifisch
Der Entscheid Weiteres Vorgehen wird nur dann getroffen, wenn eine Projektfortsetzung sinn-
voll ist. Wenn ja, wird bei der Vorgehenswahl erstens sichergestellt, dass eine nachhaltige Lö-
sungsvariante gewählt wird. Entsprechend wird die vorgeschlagene Variante nochmals aus
diesem Blickwinkel überprüft. Dazu werden die verschiedenen Stakeholder in den Entschei-
dungsprozess einbezogen. Der Projektleiter entscheidet sich nach Konsultation des Auftrag-
gebers und weiterer Stakeholder für eine Lösungsvariante. Die Entscheidung basiert auf den
AUFGABEN
in der Studie erarbeiteten Variantenbeschreibungen und -bewertungen sowie den Empfeh-

lungen der an der Studie Beteiligten sowie weiterer Stakeholder.
Zweitens wird entschieden, wie die Lösungsentstehung abgewickelt werden soll. Hier gilt es
zu wählen, ob die Lösungsentstehung klassisch oder agil angegangen wird. Diese Wahl ist pro
Projekt zwingend, da jedes Projekt andere Charakteristika aufweist. Sie kann nicht im Pro-
gramm oder Portfolio vorgeschrieben werden und soll entsprechend nachvollziehbar sein.
Drittens wird ein passendes Szenario (vgl. Kapitel 2 Szenarien) ausgewählt und je nach Bedarf
die Projektwertigkeit ermittelt.
Die Studie wird gemäss den getroffenen Entscheiden ergänzt.
Kommt man beim Entscheid Weiteres Vorgehen zum Schluss, dass eine Projektfortsetzung
wenig Sinn macht, wird das Projekt abgeschlossen.
 Studie
 Beschaffungsanalyse
Aktivitäten
 Checkliste Weiteres Vorgehen mit weiteren Kriterien ergänzen.
 Überprüfen, ob Aspekte der Nachhaltigkeit berücksichtigt sind.
 Überprüfen, ob die Stossrichtung der Studie und der Beschaffungsanalyse kongruent ist.
92 / 200
 Auf der Grundlage der Variantenbeschreibung und -bewertung in der Studie Empfehlun-
gen einholen.
 Die geeignete Vorgehensweise für die bevorzugte Lösungsvariante prüfen und entschei-
den.
 Entscheid mit Auftraggebern und Stakeholdern abstimmen.
 Formellen Entscheid zum weiteren Vorgehen treffen.
Ergebnisse
 Checkliste Weiteres Vorgehen
 Studie
5.4.3 Sonstige Aufgaben

5.4.3.1 Altsystem ausser Betrieb setzen
Umsetzung
Zweck
Nach der produktiven Einführung des neuen oder des weiterentwickelten Systems werden das
Altsystem oder die alte Systemversion ausser Betrieb genommen.
Grundidee
Das Altsystem oder die alte Version des weiterentwickelten Systems werden so ausser Betrieb
gesetzt, dass die Anforderungen an die Datensicherheit und den Datenschutz erfüllt sowie die
Vorgaben von Controlling- und Vorgabestellen eingehalten sind.
HERMES-spezifisch
Die Ausserbetriebssetzung des Altsystems oder der alten Version des weiterentwickelten Sys-
tems basiert auf dem im Migrationskonzept definierten Vorgehen.
Die im Migrationskonzept eventuell berücksichtigten Datenarchivierungsanforderungen und
jene betreffend die Datensicherheit und den Datenschutz (gemäss Lösungsanforderungen)
AUFGABEN
werden umgesetzt.
 Migrationskonzept
 Lösungsanforderungen
Aktivitäten
 Altsystem oder alte Systemversion ausser Betrieb setzen.
 Altdaten gemäss Migrationskonzept behandeln.
 Altsystem abbauen und entsorgen oder die alte Systemversion (Software) entfernen.
 Nicht mehr benötigte Infrastruktur entfernen, bauliche, technische oder sonstige Mass-
nahmen je nach Bestimmung der Stammorganisation rückgängig machen, ISDS-Massnah-
men und Bestimmungen ausser Kraft setzen bzw. aufheben.
Ergebnisse
 Altsystem entfernt
93 / 200
5.4.3.2 Änderungen managen
Umsetzung
Zweck
Das Änderungsmanagement stellt sicher, dass neu erkannte oder veränderte Anforderungen
klassisch geführter Lösungsentstehung identifiziert, beurteilt und entschieden werden.
Und es stellt weiter sicher, dass Änderungen aller Projekte, unabhängig der Vorgehensweise,
dokumentiert werden.
Grundidee
Das Änderungsmanagement ermöglicht es, bei Änderungen von Zielen, Umfang, Anforde-
rungen, Rahmenbedingungen usw. die Kontrolle über die Entwicklung der Lösungsentstehung
zu behalten und Auswirkungen auf die spätere Nutzung und den Betrieb zu erkennen. Der
Projektleiter stellt sicher, dass der Änderungsprozess konsequent eingehalten und dokumen-
tiert wird.
Bei klassischer Lösungsentstehung werden die Durchführungsplanung und die Ergebnisse
aufgrund der genehmigten Änderungen angepasst.
Bei agiler Lösungsentstehung werden lediglich die Änderungen in der Änderungsstatusliste
dokumentiert.
In der Phase Initialisierung gibt es kein formales Änderungsmanagement, da die Organisati-
ons- und Lösungsanforderungen sowie die Lösungsziele noch nicht definiert sind. Gibt es Än-
derungen z. B. in Bezug auf den Projektinitialisierungsauftrag, entscheidet der Auftraggeber
darüber.
HERMES-spezifisch
Die Änderungen werden im Rahmen der Lösungsentstehung gemäss Projektmanagement-
plan gemanagt.
Bei klassischer Vorgehensweise werden bewilligte Änderungen in den Lösungsanforderungen
nachgeführt.
Bei agiler Vorgehensweise wird die Dokumentation der wesentlichsten Änderungen aufgrund
AUFGABEN
der nachgeführten Lösungsanforderungen erstellt.

Die Änderungsstatusliste führt über alle behandelten Änderungen Buch und liefert eine Über-
sicht über deren Status.
Grundlagen/Voraussetzungen (K=klassisch, A=agil)
 Lösungsanforderungen K A
 Änderungsantrag K
Aktivitäten
 Änderungsanträge der klassischen und die wesentlichen Änderungen der K A
agilen Lösungsentstehung in der Änderungsstatusliste erfassen und nachfüh-
ren.
 Änderungsanträge analysieren und bewilligen/ablehnen. K
 Bewilligte Änderungen planen, umsetzen und überprüfen. K
 Projektmanagementplan aufgrund der Änderungen ggf. anpassen. K A
Ergebnisse
 Änderungsantrag K
 Änderungsstatusliste K A
 Projektmanagementplan K A
 Lösungsanforderungen K
94 / 200
5.4.3.3 Angebote bewerten
Umsetzung
Zweck
Die vorliegenden Angebote werden protokolliert und gemäss den Bewertungskriterien be-
wertet.
Grundidee
Nach Ablauf der Eingabefrist werden die Angebote geöffnet und ein Angebotsprotokoll er-
stellt. Danach werden sie bewertet. Grundlage für die Bewertung sind der vom Anbieter aus-
gefüllte Kriterienkatalog und die Angaben des Anbieters im Angebot.
HERMES-spezifisch
Der Eingang sowie die Öffnung der Angebote werden im Angebotsprotokoll festgehalten.
Sofern Anbieterpräsentationen durchgeführt werden, werden alle beschaffungsrechtlichen
und bewertungsrelevanten Punkte im Angebotsprotokoll festgehalten und allenfalls Nachof-
ferten eingeholt.
Wenn Verhandlungen mit Anbietern durchgeführt werden, werden alle beschaffungsrechtli-
chen und bewertungsrelevanten Punkte im Angebotsprotokoll festgehalten.
Der Evaluationsbericht enthält die konsolidierten Ergebnisse der Bewertung und den Antrag
der mit der Bewertung beauftragten Personen.
 Angebot
Aktivitäten
 Angebote öffnen, formal prüfen (rechtzeitig, vollständig) und Protokoll erstellen.
AUFGABEN
 Angebote inhaltlich bewerten.
 Aktivitäten gemäss Beschaffungsanalyse durchführen (z. B. Anbieterpräsentationen durch-
führen und protokollieren, Verhandlungen durchführen und protokollieren).
 Evaluationsbericht erstellen und Antrag erarbeiten.
 Evaluationsbericht mit den für das Beschaffungswesen verantwortlichen Controlling- und
Vorgabestellen abstimmen.
Ergebnisse
 Angebotsprotokoll
5.4.3.4 Ausschreibung durchführen

Umsetzung
Zweck
Die Ausschreibung wird nach einem bestimmten, transparenten Ablauf veröffentlicht.
95 / 200
Grundidee
Mit der Publikation der Ausschreibung wird ein uneingeschränkter Kreis von Anbietern infor-
miert und zur Bewerbung aufgefordert. Bei Bedarf werden etwaige weitergehende Ausschrei-
bungsunterlagen bereitgestellt, Fragen beantwortet und die eingehenden Angebote gesam-
melt.
HERMES-spezifisch
Die Ausschreibung wird auf der Plattform simap (www.simap.ch) publiziert. Die Antworten zu
den Anbieterfragen werden festgehalten. Sie werden allen Interessenten in neutralisierter
Form zur Verfügung gestellt und sind Teil des Ausschreibungsverfahrens.
Aktivitäten
 Ausschreibungsunterlagen publizieren oder Interessenten einladen.
 Aktivitäten gemäss Beschaffungsanalyse durchführen (z. B. Fragen der Anbieter beantwor-
ten).
Ergebnisse
 Angebot
5.4.3.5 Ausschreibung erarbeiten

Umsetzung
Zweck
Die Erarbeitung der Ausschreibungsunterlagen erlaubt eine formal korrekte Ausschreibung
durchzuführen, vergleichbare Angebote einzuholen und eine nachvollziehbare und vergleich-
AUFGABEN
bare Bewertung der Angebote zu ermöglichen.

Grundidee
Die Ausschreibungsunterlagen werden so detailliert erstellt, dass die Angebote nachvollzieh-
bar bewertet werden können. Dazu werden im Kriterienkatalog die Fragen zu den Bewer-
tungskriterien festgelegt.
Um die eingegangenen Angebote miteinander vergleichen zu können, wird ein Lastenheft
erstellt. Das Lastenheft (auch Pflichtenheft genannt) beschreibt die Anforderungen an die zu
beschaffenden Leistungen (Güter, Dienstleistungen usw.) und das Vorgehen für die Beschaf-
fungsdurchführung. Bei der Erstellung des Lastenhefts wird man sich bewusst, was wirklich
benötigt wird, der Anbieter wiederum erkennt, was der Kunde will. Es zwingt den Anbieter
aber auch, zu Fragen Stellung zu nehmen, denen er vielleicht lieber ausweichen möchte, fer-
ner, das Angebot in geforderter Struktur abzugeben. So wird eine klare einheitliche Bezugs-
basis geschaffen.
Der Vertragsentwurf bildet die Grundlage für den Vertragsabschluss und ist Teil der Ausschrei-
bungsunterlagen.
HERMES-spezifisch
Die Ausschreibungsunterlagen beruhen auf der Beschaffungsanalyse und richten sich nach
ihr. Sie bestehen aus verschiedenen Dokumenten. Sie umfassen das Lastenheft, den Kriterien-
katalog, den Vertragsentwurf, den Ausschreibungstext und weitere Dokumente. Der Kriteri-
enkatalog muss alle Eignungskriterien, Technischen Spezifikationen, Zuschlagskriterien und
das anzuwendende Bewertungsmodell enthalten.
96 / 200
Bei einer öffentlichen Ausschreibung müssen die Ausschreibungsunterlagen die formalen und
beschaffungsrechtlichen Anforderungen (gemäss Beschaffungsanalyse) erfüllen.
Die in anderen Modulen erarbeiteten Ergebnisse wie Lösungs- und Organisationsanforderun-
gen, Konzepte usw. sind, soweit relevant und vorhanden, ein integrierender Bestandteil des
Lastenhefts.
 Schutzbedarfsanalyse
 Studie
Aktivitäten
 Ausschreibungsunterlagen mit Lastenheft, Kriterienkatalog, Vertragsentwurf, Ausschrei-
bungstext und weiteren Unterlagen erstellen.
 Ausschreibungsunterlagen mit den Controlling- und Vorgabestellen abstimmen bzw.
durch diese prüfen lassen.
Ergebnisse
5.4.3.6 Beschaffungsanalyse erarbeiten

Umsetzung
Zweck
Mit der Erarbeitung der Beschaffungsanalyse werden alle beschaffungsrelevanten Informati-
onen und Vorgaben zusammengetragen, der Ausschreibungsprozess vorbereitet und die
Grundlage für die Wahl der Verfahrensart erstellt. Es wird sichergestellt, dass die Beschaffung
mit der Durchführungsplanung abgestimmt ist.
Grundidee
AUFGABEN
Die Beschaffungsanalyse dient der rechtzeitigen und vollständigen Bereitstellung von Infor-
mationen, was durch wen beschafft werden soll, wie sich der Markt präsentiert, welche ande-
ren Rahmenbedingungen zu beachten sind, ob eventuell beschaffungsrechtliche Anforderun-
gen zu erfüllen sind und welches Beschaffungsverfahren zum Tragen kommt. Die Beschaf-
fungsanalyse wird mit den Controlling- und Vorgabestellen für das Beschaffungswesen abge-
stimmt.
Ausschreibung, Evaluation und Beschaffung werden aus fachlicher und rechtlicher Sicht vor-
bereitet, der grobe finanzielle Rahmen wird abgesteckt.
In der Beschaffungsanalyse werden grundsätzliche Vorgehensfragen geklärt wie:
 Wie begründet sich die Ausschreibung, wie ist der konkrete Handlungsbedarf?
 Was soll genau beschafft werden, in welcher Menge und in welcher Qualität?
 Wie gestaltet sich die derzeitige Marktsituation, wie ist das allgemeine Angebot?
 In welchem Markt bewegt man sich?
Mit wie vielen Anbietenden ist zu rechnen?
Welche Anbieter und Lieferanten kommen in Frage?
Bestehen bereits Verträge und wie lange ist deren Laufdauer?
Welche sind die Anforderungen an die Anbieter?
 Wer ist im Projekt wofür zuständig?
Wer erstellt die Ausschreibungsunterlagen, wer evaluiert und bewertet, wer erstellt den
Evaluationsbericht, usw.?
Wie läuft der Entscheidungsprozess ab?
97 / 200
 Mit welchen Kosten ist für das Beschaffungsobjekt zu rechnen?
 Wann soll beschafft werden?
Welcher ist der geplante Zeitraum/Nutzungsdauer?
Wie ist die zeitliche Abstimmung mit dem Projekt?
Wie sieht der konkrete Beschaffungsplan aus?
 Ist die Finanzierung für das gesamte Beschaffungsvorhaben gewährleistet, inkl. Folgekos-
ten?
 Wie gestaltet sich der gesamte Beschaffungsablauf betreffend Standards und Vertragsfor-
men?
 Welches Ausschreibungsverfahren wird angewendet?
 In welcher Form werden Fragen zu den Ausschreibungsunterlagen beantwortet?
Sind Anbieterpräsentationen vorgesehen?
Die Beschaffungsanalyse berücksichtigt interne und gesetzliche Vorgaben, Abläufe und Fris-
ten.
HERMES-spezifisch
Die Erarbeitung des Vergabeverfahrens soll so früh wie möglich, also bereits in der Phase
Initialisierung, gestartet werden. Das Projekt soll unter keinen Umständen durch die für eine
Ausschreibung notwendigen Abklärungen und Abstimmungen verzögert werden.
Wird im Rahmen der Erarbeitung der Studie erkannt, dass in einer oder mehreren Varianten
die Lösungsbeschaffung vorgesehen ist, muss eine Beschaffungsanalyse erarbeitet werden.
Bei der Erarbeitung der Beschaffungsanalyse gilt, dass sie und die Studie aufeinander abge-
stimmt sind. Dies gilt insbesondere für den Beschaffungsplan.
Die Ausschreibung selbst findet erst nach der Durchführungsfreigabe statt.
 Studie
Aktivitäten
 Bedarfsanalyse und Marktanalyse durchführen und Informationen zu möglichen Lösungen
(Produkte, Services usw.) beschaffen.
 Kickoff-Sitzung in die Wege leiten.
AUFGABEN
 Verfahrensart aufgrund der Charakteristik der Beschaffung, der Vorgaben der Stammor-
ganisation und den gesetzlichen Grundlagen festlegen.
 Aufgaben, Aktivitäten und Ergebnisse konkretisieren und die Vorgaben der Stammorga-
nisation und der gesetzlichen Grundlagen berücksichtigen.
 Beschaffungsplan aus terminlicher und finanzieller Sicht erstellen und soweit bereits mög-
lich, mit der Planung aus der Studie abstimmen.
 Anforderungen zur Projektorganisation formulieren.
 Personelle und finanzielle Ressourcen für die Beschaffung planen.
 Beschaffungsanalyse mit den für das Beschaffungswesen verantwortlichen Controlling-
und Vorgabestellen abstimmen.
Ergebnisse
5.4.3.7 Betrieb aktivieren

Umsetzung
Zweck
Die Aktivierung der neuen Betriebsorganisation gibt das System für die erste Nutzung und
spätere Abnahme frei.
98 / 200
Grundidee
Das aktivierte System, die Hilfsmittel des Betriebs und die Betriebsprozesse werden in Kraft
gesetzt, damit es der Anwender produktiv nutzen kann.
HERMES-spezifisch
Auf der Grundlage des Entscheids zur Betriebsaufnahme wird der Betrieb aktiviert. Die Akti-
vierung und die anschliessende Nutzung des Systems durch die Anwender können einmalig
erfolgen; im Rahmen der agilen Lösungsentstehung können sie aber auch mehrmals ange-
gangen werden. Hierbei kommen immer weitere Teile der Lösung zum Tragen, die aufeinan-
der aufbauen. Der Betreiber stellt den Betrieb gemäss SLA sicher.
Anwender und Betreiber werden durch das Projekt in der ersten Zeit bis zu der Abnahme des
Systems aktiv unterstützt.
 System aktiviert
 Betriebshandbuch
Aktivitäten
 Betrieb aktivieren.
 Erste Zeit der Nutzung durch die Projektorganisation begleiten.
 Funktionieren der Systeme und Prozesse überwachen und Erfüllung der Vereinbarungen
überprüfen.
 Auftretende Probleme analysieren und Massnahmen ergreifen oder vorschlagen.
 Bei Bedarf Stabilisierungsmassnahmen analysieren und umsetzen.
 Betriebshandbuch mit den gemachten Erfahrungen aktualisieren.
Ergebnisse
 Betrieb aktiviert
5.4.3.8 Betrieb realisieren

AUFGABEN
Umsetzung
Zweck
Die Betriebsinfrastruktur und -organisation werden auf Basis des Betriebskonzepts soweit re-
alisiert, dass die Integration des Systems erfolgen kann.
Grundidee
Auf der Basis des Betriebskonzepts werden die Betriebsinfrastruktur, die Betriebsorganisation
und die für den Betrieb benötigten Hilfsmittel realisiert.
HERMES-spezifisch
Alle im Betriebskonzept definierten Komponenten und Massnahmen werden umgesetzt und
mit geeigneten qualitätssichernden Massnahmen überprüft. Der Betreiber testet die Betriebs-
infrastruktur soweit, dass die Integration erfolgen kann. Er erstellt eine erste Version des Be-
triebshandbuchs.
 Betriebskonzept
 Service Level Agreement
Aktivitäten
 Betriebsinfrastruktur realisieren und Tests durch den Betreiber durchführen.
 Betriebshandbuch erstellen.
99 / 200
 Hilfsmittel gemäss Betriebskonzept realisieren.
 Spezifische Sicherheitsmassnahmen realisieren.
 Betriebsorganisation realisieren.
 Übergabe von der Projekt- an die Betriebsorganisation vorbereiten.
 Prüfung und Abnahme durch die zuständigen Stellen des Betreibers vornehmen.
Ergebnisse
 Betriebsinfrastruktur realisiert
 Betriebsorganisation realisiert
5.4.3.9 Betriebskonzept erarbeiten

Umsetzung
Zweck
Die zukünftige Betriebsinfrastruktur und Betriebsorganisation werden beschrieben, und das
Vorgehen für ihre Realisierung wird festgelegt.
Grundidee
Das Betriebskonzept zeigt auf, wie die Anforderungen an den Betrieb organisatorisch und
technisch erfüllt werden.
HERMES-spezifisch
Auf der Basis der Lösungsanforderungen und der Lösungsarchitektur werden die Betriebsor-
ganisation mit der Aufbauorganisation und den Betriebsprozessen, die Betriebsinfrastruktur
und die Hilfsmittel zum Betrieb des Systems festgelegt und im Betriebskonzept festgehalten.
Die Vorgaben des Betreibers fliessen in das Betriebskonzept ein.
Die Erarbeitung des Service Level Agreement steht in Beziehung zur Aufgabe Leistungen ver-
einbaren und steuern. Mit ihr wird das SLA abgeschlossen und die Leistung gesteuert. Aller-
dings geht die Leistungssteuerung über die Laufzeit des Projekts hinaus und muss durch die
nachfolgende Anwendungsorganisation weitergeführt werden.
AUFGABEN
Aktivitäten
 Analyse der in den Lösungsanforderungen definierten Betriebsanforderungen durchfüh-
ren.
 Den Bedarf an benötigter Betriebsinfrastruktur (Räume, Hardware, Software, Kommunika-
tionsmittel usw.) und Hilfsmitteln zum Betrieb des Systems erheben.
 Analyse der Sicherheitsanforderungen durchführen.
 Betriebskonzept erarbeiten.
 Abstimmen mit den Vorgaben des Betreibers.
 Betriebskosten festlegen.
 Beim Outsourcing des Betriebs im Voraus Angebote bei externen Betreibern einholen.
 Entwürfe der SLAs erarbeiten.
 SLAs mit den Controlling- und Vorgabestellen abstimmen bzw. durch diese prüfen lassen
und danach abschliessen.
 Betriebskonzept mit den Stakeholdern abstimmen.
100 / 200
Ergebnisse
 Betriebskonzept
 Service Level Agreement
5.4.3.10 Durchführungsauftrag erarbeiten

Umsetzung
Zweck
Mit der Erarbeitung des Durchführungsauftrags werden die Voraussetzungen dafür geschaf-
fen, den Entscheid Durchführungsfreigabe treffen zu können und damit das Projekt mit der
Lösungsentstehung fortzusetzen.
Grundidee
Die Erarbeitung des Durchführungsauftrags basiert auf der Studie, einer nachvollziehbaren
Durchführungsplanung im Projektmanagementplan, der Rechtsgrundlagenanalyse, der
Schutzbedarfanalyse, ggf. auch auf der Beschaffungsanalyse und je nach lösungsspezifischer
Ausprägung auch auf der Stakeholderliste.
HERMES-spezifisch
Die in der Phase Initialisierung erarbeiteten Ergebnisse bilden die Grundlage, um den Durch-
führungsauftrag zu erarbeiten. Die relevanten Informationen aus der Studie und den anderen
Ergebnissen werden weiter konkretisiert und im Durchführungsauftrag festgehalten. Der Fo-
kus liegt dabei insbesondere bei den Zielen, den Umsetzungsvorgaben, den Risiken und der
Planung. Die Verbindlichkeiten werden erarbeitet und zwischen Auftraggeber und Projektlei-
ter vereinbart. Der Durchführungsauftrag wird mit den Vorgaben der Stammorganisation ab-
gestimmt.
Nebst dem Projektmanagementplan ist der Durchführungsauftrag die Voraussetzung für die
Steuerung und Kontrolle des Projekts durch den Auftraggeber.
 Studie
AUFGABEN
 Rechtsgrundlagenanalyse
 Stakeholderliste
Aktivitäten
 Relevante Ergebnisse aus der Studie, der Beschaffungsanalyse und dem Projektmanage-
mentplan in den Durchführungsauftrag übernehmen.
 Durchführungsauftrag mit Auftraggeber, Stakeholdern, Projektbeteiligten und Control-
ling- und Vorgabestellen verifizieren.
Ergebnisse
5.4.3.11 Einführungskonzept erarbeiten

Umsetzung
Zweck
Mit der Erarbeitung des Einführungskonzeptes werden alle relevanten Aspekte hinsichtlich der
späteren Einführung zusammengetragen und konzeptuell soweit erarbeitet, dass sie an-
schliessend realisiert und durchgeführt werden können.
101 / 200
Grundidee
Das Einführungskonzept legt fest, wie die Einführung gestaltet wird:
 Einführungsvorgehen:
Eine stichtagartige oder stufenweise Einführung wählen und Planung festlegen;
 Einführungsorganisation:
Rollen der Einführungsunterstützung definieren;
 Einführungsmassnahmen:
Ausbildung entwickeln, Unterlagen vorbereiten.
HERMES-spezifisch
Auf Basis der Lösungs- und Organisationsanforderungen sowie der Konzepte verschiedener
Module wird das Einführungskonzept erarbeitet.
Zur Erarbeitung des Konzeptes gehören auch die Analyse und Planung der Massnahmen des
Organisationschangemanagements zur Unterstützung des Übergangs zum neuen Zustand,
die Ausarbeitung des Ausbildungskonzeptes, die Regelung des Vorgehens für die Abnahmen
samt den Abnahmekriterien sowie die Festlegung der Freigabekriterien für den Entscheid Be-
triebsaufnahme treffen.
Wird eine Lösung beschafft, bringt der Ersteller die Erfahrung aus ähnlichen Projekten in die
Erarbeitung des Einführungskonzepts ein. Das Einführungskonzept wird in diesem Fall nach
der Beschaffung erstellt und die Abnahmekriterien werden zum Zeitpunkt des Vertragsab-
schlusses zwischen den projektbeteiligten Organisationen festgelegt.
Bei der Ablösung eines bestehenden Systems steht das Einführungskonzept inhaltlich in Be-
zug zum Migrationskonzept. Sie können sich gegenseitig beeinflussen.
 Produktkonzept
 Organisationskonzept
 ISDS-Konzept
AUFGABEN
Aktivitäten
 Einführungskonzept unter Berücksichtigung der Einführungsrisiken erarbeiten.
 Einführungsplanung in den Projektmanagementplan übernehmen.
 Ausbildungsbedarf bei Anwendern und Betreibern erheben und Ausbildungsmassnahmen
im Einführungskonzept festhalten.
 Einführungskonzept mit den Stakeholdern abstimmen.
 Abnahmen planen und samt den Abnahmekriterien regeln.
 Freigabekriterien für die Betriebsaufnahme festlegen.
Ergebnisse
102 / 200
5.4.3.12 Einführungsmassnahmen durchführen
Umsetzung
Zweck
Die Durchführung der realisierten und vorbereiteten Einführungsmassnahmen schafft eine der
Grundlagen für die Betriebsaufnahme und die spätere Nutzung des Systems.
Grundidee
Die realisierten Einführungsmassnahmen werden durchgeführt. Dazu gehört beispielsweise
die Durchführung der Anwenderausbildung. Die Durchführung der Einführungsmassnahmen
kann sich über die Dauer der Einführung bis zum Entscheid Betriebsaufnahme erstrecken.
HERMES-spezifisch
Die Durchführung der realisierten und im Rahmen des Entscheides Vorabnahme überprüften
Einführungsmassnahmen erfolgt auf der Grundlage der im Einführungskonzept erarbeiteten
Einführungsplanung. Im Rahmen der agilen Lösungsentstehung kann sie auch mehrmals an-
gegangen werden.
Aktivitäten
 Durchführen der realisierten Einführungsmassnahmen.
 Wirksamkeit der Einführungsmassnahmen überprüfen.
Ergebnisse
 Einführungsmassnahmen durchgeführt
5.4.3.13 Einführungsmassnahmen realisieren

AUFGABEN
Umsetzung
Zweck
Auf der Grundlage des Einführungskonzeptes werden die Einführungsmassnahmen realisiert.
Grundidee
Die Einführungsmassnahmen sowie die Einführungsorganisation werden realisiert.
 Ein Beispiel für die Realisierung einer Einführungsmassnahme ist die Entwicklung einer
Ausbildung; die Durchführung der Ausbildung erfolgt im Zuge der Aufgabe Einführungs-
massnahmen durchführen;
 Ein Beispiel für die Realisierung der Einführungsorganisation ist die Ausbildung von Super-
usern, die die Einführung unterstützen; sie werden jedoch erst während der Einführung
aktiv.
HERMES-spezifisch
Die im Einführungskonzept festgelegten Notfallmassnahmen und die Notfallorganisation wer-
den realisiert. Im Rahmen der agilen Lösungsentstehung kann die Realisierung auch mehrmals
angegangen werden.
Die realisierten Einführungsmassnahmen und Notfallorganisation werden in der Aufgabe Ent-
scheid Vorabnahme treffen geprüft.
103 / 200
Aktivitäten
 Einführungsmassnahmen und -organisation realisieren (inkl. Notfallmassnahmen und -or-
ganisation).
Ergebnisse
5.4.3.14 Integrationskonzept erarbeiten

Umsetzung
Zweck
Mit der Erarbeitung des Integrationskonzepts werden alle relevanten Aspekte hinsichtlich der
späteren Integration des Systems in die Betriebsinfrastruktur zusammengetragen und kon-
zeptuell soweit erarbeitet, dass die Systemintegration vorbereitet werden kann.
Grundidee
Damit das System im Zielumfeld integriert werden kann, muss die Integration konzipiert wer-
den.
HERMES-spezifisch
Die Integration, die in der Lösungsarchitektur definiert wurde, wird weiter konkretisiert. Die
Schnittstellen zu Umsystemen sowie die Übergaben von einer Betriebsumgebung (z. B. Ent-
wicklung, Test, Integration, Schulung) an eine andere werden spezifiziert.
Die Systemintegrationsplanung wird erarbeitet und im Integrationskonzept festgehalten.
Wird die Beschaffung eines Systems durchgeführt, erfolgt die abschliessende Erarbeitung des
Integrationskonzepts nach dem Zuschlag.
Aktivitäten
AUFGABEN
 Systemintegration in die Umsysteme festlegen, Spezifikation der Schnittstellen erarbeiten

und im Integrationskonzept festhalten.
 Integration in die Betriebsplattformen festlegen.
 Übergang von Software, Daten usw. zwischen den Betriebsplattformen konzipieren.
 Integrationsplan erarbeiten und im Integrationskonzept festhalten.
 Bedarfsweise Integrationskonzept mit Prototypen (Testinstallationen) verifizieren.
 Integrationskonzept mit Stakeholdern abstimmen.
Ergebnisse
 Integrationskonzept
5.4.3.15 ISDS-Konzept erarbeiten

Umsetzung
Zweck
Das ISDS-Konzept schafft die Voraussetzungen dafür, dass die Anforderungen an die Infor-
mationssicherheit und den Datenschutz realisiert und überführt werden können.
104 / 200
Grundidee
Im ISDS-Konzept werden die Anforderungen an die Informationssicherheit und den Daten-
schutz vervollständigt. Darin enthalten ist eine detaillierte und vertiefte Risikoanalyse. Die
Schutzmassnahmen werden definiert.
HERMES-spezifisch
Die Grundlagen zum ISDS-Konzept bilden einerseits die in der Initialisierung erarbeiteten Er-
gebnisse Studie und Schutzbedarfsanalyse, anderseits die beiden Ergebnisse Organisations-
und Lösungsanforderungen. Es muss nach den Vorgaben der Stammorganisation betreffend
den Informationsschutz behandelt werden.
 Studie
Aktivitäten
 Systembeschreibung mit den sicherheitsrelevanten Komponenten erstellen.
 Risikoanalyse erstellen, Risikoabdeckung mit übergeordneten Konzepten aufzeigen und
Restrisiken identifizieren.
 Das Notfallkonzept und das Bearbeitungsreglement erstellen und im ISDS-Konzept fest-
halten.
 ISDS-Konzept mit den Controlling- und Vorgabestellen abstimmen.
Ergebnisse
 ISDS-Konzept
5.4.3.16 ISDS-Konzept realisieren

Umsetzung
Zweck
AUFGABEN
Die im ISDS-Konzept definierten Schutzmassnahmen werden realisiert. Die realisierten
Schutzmassnahmen sind Voraussetzung für die Vorabnahme.
Grundidee
Durch die Realisierung des ISDS-Konzepts werden Voraussetzungen für das Austesten des
Systems sowie für den Betrieb geschaffen.
HERMES-spezifisch
Die Realisierung der im ISDS-Konzept definierten Schutzmassnahmen erfolgt in den entspre-
chenden Modulen, beispielsweise im Modul Organisation und Modul IT-System. Im Rahmen
der agilen Lösungsentstehung kann die Realisierung auch mehrmals angegangen werden.
Im Modul Einführungsorganisation werden die Ergebnisse der realisierten technischen Schutz-
massnahmen vor der Vorabnahme mit der Aufgabe Entscheid Vorabnahme treffen geprüft.
 ISDS-Konzept
Aktivitäten
 Realisierung der Schutzmassnahmen begleiten.
 Stand der Realisierung im ISDS-Konzept dokumentieren.
105 / 200
 Beurteilung der Restrisiken im ISDS-Konzept nachführen.
 ISDS-Konzept mit den Restrisiken durch den Auftraggeber genehmigen.
Ergebnisse
 ISDS-Konzept
5.4.3.17 ISDS-Konzept überführen

Umsetzung
Zweck
Das ISDS Konzept wird aktualisiert, geprüft und von der Projektorganisation in die Stammor-
ganisation überführt. Dies ist eine der Voraussetzungen für den Entscheid Betriebsaufnahme.
Grundidee
Der Auftraggeber muss sich mit dem aktualisierten und geprüften ISDS-Konzept identifizieren,
dieses gutheissen und gegenüber der Stammorganisation vertreten sowie die Restrisiken ak-
zeptieren können.
HERMES-spezifisch
Durch die Genehmigung und Überführung des ISDS-Konzepts akzeptieren der Auftraggeber
sowie die Leitung der Stammorganisation die ISDS-Restrisiken. Im Rahmen der agilen Lö-
sungsentstehung kann die Überführung auch mehrmals angegangen werden.
Mit dem nachfolgenden Entscheid Betriebsaufnahme übernimmt somit der Auftraggeber die
Verantwortung für die Risiken des Betriebs.
 ISDS-Konzept
Aktivitäten
 Stand der Realisierung im ISDS-Konzept nachführen.
AUFGABEN
 Beurteilung der Restrisiken im ISDS-Konzept nachführen.

 ISDS-Konzept durch die zuständige Controlling- und Vorgabestelle prüfen lassen und
Stellungnahme einholen.
 ISDS-Konzept mit den Restrisiken durch den Auftraggeber und die Leitung der Stammor-
ganisation genehmigen.
Ergebnisse
 ISDS-Konzept überführt
 ISDS-Konzept
5.4.3.18 Leistungen vereinbaren und steuern

Umsetzung
Zweck
Mit der Leistungsvereinbarung entsteht eine klar geregelte Beziehung zwischen dem Projekt
und den (internen oder externen) Dienstleistungserbringern einerseits und zwischen der Pro-
jekt- und der Stammorganisation anderseits. Abweichungen während der Leistungserbrin-
gung werden identifiziert und behandelt.
106 / 200
Abgrenzungen:
 Wird im Rahmen der Initialisierungsphase festgestellt, dass das ganze Vorhaben lediglich
eine Beschaffung darstellt und sonst keine Projektaktivitäten mehr anfallen, geht die Be-
schaffung direkt an den Einkauf der Stammorganisation über und das Vorhaben wird be-
endet. HERMES unterstützt keine blosse Beschaffung.
 Umfassende Beschaffung mittels offener oder selektiver Verfahren und öffentlicher Publi-
kation (z. B. eine öffentliche Ausschreibung) werden im Fall von Produkt- oder Systema-
daption mit dem Modul Beschaffung durchgeführt, ansonsten ausserhalb der Projektor-
ganisation direkt durch den Einkauf der Stammorganisation.
 Eine Vereinbarung über den Bezug von betriebs- und wartungsspezifischen Dienstleistun-
gen während der Nutzungsphase des Systems zwischen dem Anwender und dem künfti-
gen Betreiber des Systems, das Service Level Agreement (SLA), wird im Modul IT-Betrieb
erarbeitet.
Grundidee
Das Projekt bezieht verschiedene organisationsinterne und -externe Leistungen, die verein-
bart und gesteuert werden müssen. Leistungen, die vom Projekt bezogen werden, sind z. B.
Mitarbeiterleistungen (Personalressourcen), Räume, IT-Mittel, Ausbildung usw.
Der Bedarf an Leistungen wird identifiziert und analysiert und ggf. eine Marktuntersuchung
durchgeführt. Hierbei werden folgende Fragen geklärt wie:
 Rechtfertigt sich eine Ausschreibung, wie ist der konkrete Handlungsbedarf?
 Welche Ressourcen sollen beschafft werden, in welcher Anzahl und bei Personalressour-
cen z. B. mit welcher fachlichen Ausrichtung?
 Wie gestaltet sich die derzeitige Marktsituation, wie ist das allgemeine Angebot?
 In welchem Markt bewegt man sich?
Mit wie vielen Anbietenden ist zu rechnen?
Welche Anbieter und Lieferanten kommen in Frage?
Bestehen bereits Verträge und wie lange ist deren Laufzeit?
Welche sind die Anforderungen an die Anbieter?
 Wann und für welche Einsatzdauer soll beschafft werden?
 Ist die Finanzierung gewährleistet (Projektbudget)?
Darauf basierend werden Angebote eingeholt und Vereinbarungen abgeschlossen.
AUFGABEN
Wird allerdings im Rahmen der Bedarfs- und Marktanalyse festgestellt, dass eine umfassende
Beschaffung mittels offener oder selektiver Verfahren und öffentlicher Publikation notwendig
ist, wird die Ressourcenbeschaffung mit dem Modul Beschaffung durchgeführt.
Die Leistungen werden periodisch auf Übereinstimmung mit der Planung und den Vereinba-
rungen hin überprüft.
HERMES-spezifisch
Mit dieser Aufgabe werden folgende vier Fälle abgewickelt:
1. Bezug interner Leistungen ohne Leistungsverrechnung.
2. Bezug interner Leistungen mit Leistungsverrechnung.
3. Bezug externer Leistungen: freihändiges Verfahren (mit einer oder mehreren Offerten).
4. Bezug externer Leistungen: Einladungsverfahren (mit mehreren Offerten und Evaluations-
bericht).
Die vier relevanten Fälle werden folgendermassen abgewickelt:
 Fall 1 und Fall 2
Bezug von internen Leistungen der Stammorganisation (d. h. ohne Gerichtsbarkeit im
Streitfall) wird mit Projektvereinbarungen sowie Projekt-SLA für den Betrieb während der
Projektphasen geregelt.
Die Projektvereinbarung regelt die Leistungen für die Projektabwicklung. Das Projekt-SLA
regelt den Betrieb des Systems (z. B. das Testsystem) für den Betrieb während der Pro-
jektphasen.
107 / 200
 Fall 3
Bezug von externen Leistungen im freihändigen Verfahren wird über Offertanfragen und
Verträge sowie leistungserbringerspezifische SLAs geregelt.
 Fall 4
Bezug von externen Leistungen im Einladungsverfahren wird über Offertanfragen und
Verträge sowie leistungserbringerspezifische SLAs geregelt. Für die Bewertung der Offer-
ten wird beim Einladungsverfahren ein Evaluationsbericht erstellt.
Projektvereinbarungen, Projekt-SLAs, leistungserbringerspezifische SLAs und Verträge wer-
den nach den Vorgaben der Stammorganisation erarbeitet. HERMES bezeichnet diese Ergeb-
nisse als Vereinbarung.
Während der Leistungserbringung und bei Abschluss derselben wird eine Leistungsbeurtei-
lung durchgeführt und mit den Projektbeteiligten besprochen. Sie bildet die Grundlage für
allfällige Steuerungsmassnahmen. Abweichungen von den vereinbarten Leistungen oder vom
benötigten Bedarf werden analysiert und über die Aufgabe Änderungen managen behandelt.
Änderungen werden rechtzeitig initiiert, damit die Einhaltung der Vorgaben (z. B. der rechtli-
chen Grundlagen) gewährleistet ist. Massgebende Probleme werden über die Aufgabe Prob-
leme behandeln und Erfahrungen nutzen gelöst.
Aktivitäten
 Basierend auf den geplanten Aufgaben und Ergebnissen die benötigten Rollenprofile (An-
forderungen an die Fähigkeiten) sowie den Kapazitätsbedarf für Personalressourcen erhe-
ben und als Bedarfsanforderung festhalten.
 Den Bedarf an benötigter Infrastruktur (Räume, Hardware, Software, Kommunikationsmit-
tel usw.) erheben.
 Die internen Projektvereinbarungen und SLAs erstellen.
 Offertanfragen für externe Leistungen und Services erstellen, Angebote einholen und be-
werten. Bei Einladungsverfahren einen Evaluationsbericht erstellen.
 Vereinbarungen mit den Controlling- und Vorgabestellen abstimmen bzw. durch diese
prüfen lassen und anschliessend abschliessen.
AUFGABEN
 Leistungen während der Leistungserbringung und bei deren Abschluss beurteilen.

Ergebnisse
 Offertanfrage
 Angebot
 Vereinbarung
5.4.3.19 Lösungsanforderungen erarbeiten

Umsetzung
Zweck
Alle relevanten Anforderungen an die Lösung, ihre Einführung, den Betrieb, die Nutzung usw.
werden erarbeitet.
In klassisch geführter Lösungsentstehung bilden die Anforderungen die Grundlage für die
Erarbeitung der Lösungsarchitektur bzw. des Produktkonzepts.
108 / 200
In agil geführter Lösungsentstehung sind die konkretisierten und priorisierten Anforderungen
der Grundstein für deren sukzessive Weiterführung und Abarbeitung.
Grundidee
Es werden die folgenden Ergebnisse erarbeitet:
 Die Situationsanalyse vertieft die Standortbestimmung aus der Studie und zeigt den Hand-
lungsbedarf.
 Die Lösungsanforderungen bauen auf den Zielen aus der Studie und aus dem Durchfüh-
rungsauftrag auf, konkretisieren die groben Anforderungen aus der Studie und erweitern
sie aufgrund des in der Situationsanalyse erkannten Handlungsbedarfs.
Die formulierten Lösungsanforderungen sind lösungsneutral.
HERMES-spezifisch
Die Lösungsanforderungen werden inhaltlich und planerisch so detailliert erstellt und priori-
siert, dass sie eine verlässliche Grundlage für die Entwicklung oder Beschaffung des Systems
bilden. Im Falle einer Beschaffung fliessen sie in das Lastenheft ein.
Bei klassischer Lösungsentstehung werden bei Bedarf die abgenommenen Lösungsanforde-
rungen nur noch mittels Änderungsmanagement nachgeführt.
Bei agiler Lösungsentstehung variiert die Detaillierungstiefe der initial erstellten Lösungsan-
forderungen je nach Kritikalität eines Systemelements. Sie werden anschliessend im Rahmen
der Aufgabe Projekt führen und kontrollieren fortwährend aktualisiert.
 Studie
Aktivitäten
 Rahmenbedingungen aus dem Durchführungsauftrag kritisch hinterfragen und Einflüsse
auf den Projekterfolg analysieren.
AUFGABEN
 Die Standortbestimmung aus der Studie umfassend ergänzen und vertiefen.
 Anforderungen konkretisieren, als Lösungsanforderungen dokumentieren und eindeutig
priorisieren.
 Lösungsanforderungen mit den Stakeholdern abstimmen.
Ergebnisse
 Situationsanalyse
5.4.3.20 Lösungsarchitektur erarbeiten

Umsetzung
Zweck
Mit der Lösungsarchitektur wird die Grundlage für die Realisierung des Systems geschaffen.
Grundidee
 Das Systemkonzept
schafft Grundlagen für die Lösungsarchitektur und ergänzt diese. Es beschreibt Lösungs-
konzepte für spezifische Themen (z. B. Benutzerverwaltung und Zugriffsrechte, Archivie-
rung).
109 / 200
 Die Lösungsarchitektur
beschreibt das System mit seinen Komponenten und seinem Aufbau sowie den Schnitt-
stellen zu den Umsystemen. Die Lösungsarchitektur beschreibt auch den Bezug der IT-
Architektur zu den Geschäftsprozessen.
Im Systemkonzept werden mehrere Lösungsansätze erarbeitet und bewertet. Die ausgewähl-
ten Ansätze werden in der Lösungsarchitektur zu einer gesamthaften Lösung zusammenge-
führt.
HERMES-spezifisch
Das Systemkonzept basiert direkt auf den Lösungsanforderungen, auf allfälligen Organisati-
onsanforderungen und auf der Studie. Es vertieft die in der Studie beschriebene und gewählte
Lösungsvariante. Es können mehrere themenspezifische Systemkonzepte mit jeweils verschie-
denen Lösungsansätzen erarbeitet werden.
Die Lösungsarchitektur basiert auf dem Systemkonzept und bildet die Grundlage für den Ent-
scheid Lösungsarchitektur. Sie wird im Zuge der Lösungsentstehung weiter konkretisiert.
 Studie
 Prototyp realisiert
Aktivitäten
 Systemkonzepte erstellen.
 Lösungsarchitektur erarbeiten.
 Systemkonzepte in die Lösungsarchitektur einfliessen lassen bzw. als Beilagen referenzie-
ren.
 Bei Bedarf die Lösungsarchitektur mit Prototypen überprüfen.
 Ergebnisse mit den Stakeholdern abstimmen.
Ergebnisse
 Systemkonzept
AUFGABEN
5.4.3.21 Migration durchführen

Umsetzung
Zweck
Die Migration vom alten auf das neue System wird durchgeführt.
Grundidee
Die Migration wird mit den ausgewählten Migrationsverfahren durchgeführt. Nach der Mig-
ration wird die Qualität der Migration überprüft. Notwendige Bereinigungen werden vorge-
nommen.
HERMES-spezifisch
Eine erfolgreiche Migration ist die Voraussetzung für die Abnahme der Migration.
 Detailspezifikation
 Migrationsverfahren realisiert
110 / 200
Aktivitäten
 Migration mit den Migrationsverfahren gemäss Migrationskonzept durchführen.
 Qualitätssichernde Massnahmen durchführen.
 Notwendige Bereinigungen durchführen.
Ergebnisse
 Migration durchgeführt
5.4.3.22 Migrationskonzept erarbeiten

Umsetzung
Zweck
Das Migrationskonzept schafft die Grundlage für die Überführung des alten in das neue Sys-
tem sowie für die Ausserbetriebssetzung des Altsystems.
Grundidee
Der Schwerpunkt der Systemmigrationen ist die Migration der Anwendungsdaten, die Daten-
migration. Migrationen können technisch (maschinell) oder organisatorisch (manuell) erfol-
gen.
Das Migrationskonzept berücksichtigt die Mengen, Häufigkeiten und Qualität der Daten im
Altsystem und ihre Integration ins Zielsystem. Mögliche Migrationsszenarien werden analy-
siert und beurteilt, sodass die geeigneten Migrationsverfahren bestimmt werden können.
In die Migrationsüberlegungen fliessen Aspekte der Machbarkeit, der Wirtschaftlichkeit, der
Qualität und des zeitlichen Ablaufs einer Migration ein.
Mit der Datenmigration müssen auch die Fragen der Archivierung von alten Daten und des
Systemabbaus beantwortet werden. Die Aspekte Datensicherheit und Datenschutz werden
dabei berücksichtigt.
HERMES-spezifisch
Die Einführungsstrategie im Einführungskonzept bestimmt die Migrationsstrategie (eine stu-
fenweise Einführung erfordert z. B. eine stufenweise Migration).
AUFGABEN
 ISDS-Konzept
Aktivitäten
 System- und Datenanalyse durchführen.
 Migrationskonzept auf der Grundlage des Einführungskonzepts erarbeiten.
 Auswirkung auf das Einführungskonzept überprüfen.
 Abbau des Altsystems konzipieren und bei Bedarf Datenarchivierung klären.
 Machbarkeit überprüfen.
 Migrationskonzept mit den Stakeholdern abstimmen.
Ergebnisse
111 / 200
5.4.3.23 Migrationsverfahren realisieren
Umsetzung
Zweck
Die Migrationsverfahren werden soweit realisiert, dass die Migration ins produktive System
durchgeführt werden kann.
Grundidee
Je nach Verfahren werden unterschiedliche Realisierungsschritte ausgeführt.
HERMES-spezifisch
Auf der Grundlage des Migrationskonzepts wird die Detailspezifikation erarbeitet. Die Qualität
einer Migration hat einen wesentlichen Einfluss auf den Betriebsstart des neuen Systems. Ent-
sprechend haben die qualitätssichernden Massnahmen einen hohen Stellenwert.
Die Migrationsverfahren werden gemäss Testkonzept getestet. Dies erfolgt mit dem Modul
Test.
Aktivitäten
 Detailspezifikation für Migration und Abbau des Altsystems erstellen.
 Testinfrastruktur realisieren.
 Vorgaben bezüglich Archivierung und Datensicherheit und Datenschutz berücksichtigen.
 Migrationsverfahren realisieren.
 Migrationsverfahren dokumentieren (z. B. mit Checkliste).
 Migrationsverfahren mit dem Modul Tests überprüfen.
Ergebnisse
 Migrationsverfahren realisiert
AUFGABEN
5.4.3.24 Organisation aktivieren

Umsetzung
Zweck
Mit der Aktivierung wird die neue Organisation in Kraft gesetzt. Die Mitarbeitenden arbeiten
in ihren neuen Rollen gemäss dem neuen Geschäftsmodell und nach den neuen Prozessen.
Grundidee
Der Business Analyst aktiviert die neue Organisation, damit die Anwender in ihren neuen Rol-
len gemäss dem neuen Geschäftsmodell nach den neuen Prozessen arbeiten können.
HERMES-spezifisch
Nach dem Entscheid Betriebsaufnahme erfolgt die Aktivierung der neuen Organisation durch
den Business Analysten. Die neue Organisation tritt in Kraft und es wird in Übereinstimmung
mit ihr gearbeitet.
Die Projektorganisation begleitet und unterstützt die Organisation in der ersten Zeit der Nut-
zung.
112 / 200
Sobald die Nutzung gemäss neuem Geschäftsmodell, neuer Prozessbeschreibung und neuer
Organisationsbeschreibung problemlos erfolgen kann, wird der Entscheid Abnahme getrof-
fen.
Aktivitäten
 Stakeholder frühzeitig informieren.
 Organisation aktivieren.
Ergebnisse
5.4.3.25 Organisation umsetzen

Umsetzung
Zweck
Die Organisation wird vollständig realisiert. Die organisatorischen und personellen/stellenspe-
zifischen Voraussetzungen werden soweit geschaffen, dass die neue Organisation aktiviert
werden kann.
Grundidee
Die relevanten Elemente des Geschäftsmodells, die Aufbauorganisation mit allen personel-
len/stellenspezifischen Aspekten sowie die Prozesse mit allen Hilfsmitteln werden soweit rea-
lisiert, dass die neue Organisation aktiviert werden kann.
HERMES-spezifisch
Basierend auf dem Organisationskonzept werden die Geschäftsmodell-, die Prozess- und die
Organisationsbeschreibung realisiert sowie die entsprechenden Massnahmen umgesetzt.
AUFGABEN
Die Geschäftsmodellbeschreibung umfasst die geschäftliche Sichtweise und legt den Rahmen
für die Prozess- und Organisationsbeschreibung fest. Die Prozessbeschreibung formuliert die
Prozesse mit den eingesetzten Hilfsmitteln. Die Organisationsbeschreibung definiert die Auf-
bauorganisation mit dem detaillierten Organigramm, den Funktionsbeschreibungen und Per-
sonalanforderungen. Aufgrund der Geschäftsmodell-, Prozess- und Organisationsbeschrei-
bung werden die Massnahmen realisiert, um die Organisation ins Leben zu rufen (Kommuni-
kationskanäle, Distributionskanäle, Rollenbesetzungen, Personalanstellungen usw.).
Im Modul Einführungsorganisation werden die Ergebnisse der realisierten Organisation vor
der Vorabnahme mit der Aufgabe Entscheid Vorabnahme treffen geprüft.
Aktivitäten
 Geschäftsmodellbeschreibung realisieren/fertigstellen.
 Prozessbeschreibung realisieren/fertigstellen.
 Organisationsbeschreibung realisieren/fertigstellen.
113 / 200
 Massnahmen definieren, um die Organisation ins Leben zu rufen und diese umzusetzen.
 Etwaige neue, sich ergebende Anforderungen an die Lösung (Produkt, System) oder deren
Betrieb über das Änderungsmanagement einfliessen lassen.
Ergebnisse
 Organisation umgesetzt
5.4.3.26 Organisationsanforderungen erarbeiten

Umsetzung
Zweck
Alle relevanten Anforderungen an die Organisation werden erarbeitet.
Grundidee
 Die Situationsanalyse vertieft die Standortbestimmung aus der Studie und zeigt den Hand-
lungsbedarf auf.
 Die Organisationsanforderungen bauen auf den Zielen aus der Studie und aus dem
Durchführungsauftrag auf, konkretisieren die groben Anforderungen aus der Studie aus
organisatorischer und geschäftlicher Sicht und erweitern sie aufgrund des in der Situati-
onsanalyse erkannten Handlungsbedarfs.
Die formulierten Organisationsanforderungen sind lösungsneutral.
HERMES-spezifisch
Die Organisationsanforderungen werden inhaltlich und planerisch so detailliert erstellt und
priorisiert, dass sie eine verlässliche Grundlage für die nötigen Anpassungen an der bestehen-
den Organisation und ggf. für die Entwicklung oder Beschaffung der Lösung bilden. Im Falle
einer Beschaffung fliessen sie in das Lastenheft ein.
Die Organisationsanforderungen stellen die Grundlage für die Erarbeitung des Organisations-
konzepts und – je nach Relevanz – auch für alle anderen Konzepte im Projekt dar.
AUFGABEN
 Studie
Aktivitäten
 Rahmenbedingungen aus dem Durchführungsauftrag kritisch hinterfragen und Einflüsse
auf den Projekterfolg analysieren.
 Die Standortbestimmung aus der Studie aus geschäftlicher Sicht umfassend ergänzen und
vertiefen.
 Anforderungen konkretisieren, als Organisationsanforderungen dokumentieren und ein-
deutig priorisieren.
 Organisationsanforderungen mit den Stakeholdern abstimmen.
Ergebnisse
 Situationsanalyse
114 / 200
5.4.3.27 Organisationskonzept erarbeiten
Umsetzung
Zweck
Im Organisationskonzept wird die neue Organisation beschrieben und das Vorgehen für ihre
Realisierung festgelegt.
Grundidee
Im Organisationskonzept werden das Geschäftsmodell sowie die Aufbau- und die Ablaufor-
ganisation (Prozesse) für die Geschäftsabwicklung beschrieben. Es wird aufgezeigt, wie die
neue Organisation gestaltet wird und welche Änderungen an Bestehendem vorgenommen
werden. Die Prozessbeschreibung umfasst die Kernprozesse, die Führungsprozesse und die
Supportprozesse. Bei Bedarf können verschiedene Organisationsvarianten beschrieben und
beurteilt werden.
HERMES-spezifisch
Das Organisationskonzept basiert direkt auf den Organisationsanforderungen, auf allfälligen
Lösungsanforderungen (reine Organisationsprojekte haben keine Lösungsanforderungen)
und auf der Studie. Sämtliche organisatorischen Aspekte werden aus geschäftlicher Sicht zu-
erst in der Geschäftsmodellbeschreibung und dann in der Aufbau- und in der Ablauforgani-
sation konzeptuell entwickelt. Die Geschäftsmodellbeschreibung legt hierbei den Rahmen für
die Aufbau- und Ablauforganisation fest. Die Aufbauorganisation gibt Auskunft über die
neuen oder angepassten Strukturen in der Stammorganisation, in der Ablauforganisation wer-
den das Prozessmodell erstellt und die entsprechenden Prozesse identifiziert und dokumen-
tiert.
Basierend auf dem Organisationskonzept und den groben Teilergebnissen können anschlies-
send je nach Projektart und Möglichkeit, insbesondere in Verbindung mit allfälligen parallelen
Aktivitäten der Module Produkt und IT-System, die detaillierte Geschäftsmodell-, die Prozess-
und die Organisationsbeschreibung in Angriff genommen werden.
 Studie
AUFGABEN
Aktivitäten
 Organisationskonzept erarbeiten mit
o Grobem Geschäftsmodell,
o Grober Aufbauorganisation sowie
o Grober Ablauforganisation samt Prozesslandkarte und grober Prozessbeschreibung.
 Auswirkungen auf die Organisation analysieren und auf Machbarkeit prüfen.
 Organisationskonzept mit den Stakeholdern abstimmen.
Ergebnisse
115 / 200
5.4.3.28 Phasenfreigabe vorbereiten
Umsetzung
Zweck
Für die Phasenfreigabe werden die Ergebnisse für die Entscheidungsträger zusammengefasst
und die nächste Phase geplant.
Grundidee
Am Ende einer Projektphase wird über den weiteren Projektverlauf entschieden. Dazu werden
die benötigten Entscheidungsgrundlagen aufbereitet. Insbesondere der Phasenbericht muss
darüber Aufschluss geben, dass alle notwendigen Ergebnisse in der erforderlichen Qualität
vorliegen.
HERMES-spezifisch
Die Gesamtplanung des Projekts wird überprüft und die Detailplanung für die nächste Phase
erarbeitet. Der Projektmanagementplan wird nachgeführt.
Die Genauigkeit der Planung erhöht sich im Projektverlauf kontinuierlich dank vertiefter
Kenntnisse über das Projekt und die erwarteten Ergebnisse.
Der Phasenbericht mit den Anträgen wird erstellt. Er bildet die Grundlage für den Auftragge-
ber, um über die Freigabe der nächsten Phase zu entscheiden.
 Projektstatusbericht K A
 Änderungsstatusliste K A
 Projekterfahrungen K A
 Releasebericht A
Aktivitäten
 Nächste Phase detailliert planen.
 Gesamtplan verifizieren.
AUFGABEN
 Ergebnisse des Projektverlaufs, inklusive von Änderungen, im Phasenbericht zusammen-

fassen und hinsichtlich der Qualität beurteilen.
 Projektmanagementplan nachführen und mit allen Beteiligten sowie den Controlling- und
 Projektstatusbericht als Beilage zu Phasenbericht aktualisieren.
 Weitere Voraussetzungen für die Phasenfreigabe schaffen (z. B. angepasste Projektorga-
nisation und Ressourcenverfügbarkeit sicherstellen).
 Anträge zur Abnahme von Ergebnissen, zum weiteren Vorgehen, zu den freizugebenden
Mitteln und Ressourcen usw. stellen.
 Entscheide bei der Projektsteuerung initiieren.
Ergebnisse
 Phasenbericht
116 / 200
5.4.3.29 Probleme behandeln und Erfahrungen nutzen
Umsetzung
Zweck
Die stufengerechte Bearbeitung von Problemen hilft, die gesetzten Ziele zu erreichen. Mit der
Nutzung der Erfahrungen wird die kontinuierliche Verbesserung im Projekt und in der Stam-
morganisation unterstützt.
Grundidee
Das frühzeitige Erkennen und Lösen von Problemen ist eine wichtige Voraussetzung für das
Erreichen der Meilensteine und Ziele. Ist die Problemlösung durch den Bearbeitenden nicht
oder nicht rechtzeitig möglich, wird das Problem umgehend innerhalb der Projektorganisation
eskaliert.
Erkenntnisse aus Problemlösungen sind als Erfahrungssammlung im weiteren Projektverlauf
wie auch für andere Projekte von Nutzen. Die Erfahrungssammlung und -nutzung ist Teil eines
kontinuierlichen Verbesserungsprozesses im Projekt und in der Stammorganisation. Sie findet
nicht erst am Schluss des Projekts statt.
HERMES-spezifisch
Der Eskalationsprozess wird im Projektmanagementplan projektspezifisch geregelt. Die Erfah-
rungen werden im Ergebnis Projekterfahrungen gesammelt. Die Auswertung der Erfahrungen
ist eine Teamaufgabe.
Die Projekterfahrungen inkl. der identifizierten Massnahmen zu Problemlösungen fliessen in
die Aufgaben Projekt führen und kontrollieren, Phasenfreigabe vorbereiten und Releaseab-
schluss vorbereiten ein.
Aktivitäten
 Probleme identifizieren und bewerten.
AUFGABEN
 Massnahmen definieren und den Projektverlauf überwachen.
 Eskalationen initiieren, führen und Deeskalationen ausführen.
 Beteiligte über Lösung informieren.
 Erfahrungen aus dem Projektverlauf und aus Problemsituationen regelmässig analysieren
und Verbesserungsmassnahmen für die weitere Projektabwicklung identifizieren.
 Erfahrungen im Ergebnis Projekterfahrungen laufend dokumentieren und an den Auftrag-
geber (zu Handen Stammorganisation) weitergeben.
Ergebnisse
5.4.3.30 Produkt aktivieren

Umsetzung
Zweck
Die Produktaktivierung gibt das Produkt für die erste Nutzung und spätere Abnahme frei.
117 / 200
Grundidee
Der Entwickler aktiviert das Produkt, damit es der Anwender produktiv nutzen kann. Es um-
fasst alle Komponenten, die für den Betrieb notwendig sind.
HERMES-spezifisch
Nach dem Entscheid Betriebsaufnahme erfolgt die Aktivierung des Produkts durch den Erstel-
ler und die anschliessende Nutzung des Produkts durch die Anwender.
Anwender und ggf. auch Betreiber werden durch das Projekt in der ersten Zeit der Nutzung
bis zu der Abnahme des Produkts aktiv unterstützt.
 Produkt entwickelt oder angepasst
Aktivitäten
 Stakeholder frühzeitig informieren.
 Produkt aktivieren.
Ergebnisse
 Produkt aktiviert
5.4.3.31 Produkt realisieren

Umsetzung
Zweck
Das Produkt wird entwickelt oder angepasst, sodass es die Lösungsanforderungen erfüllt und
für die Vorabnahme bereit ist.
Grundidee
AUFGABEN
Basierend auf den Lösungsanforderungen und dem Produktkonzept wird die Detailspezifika-
tion erarbeitet. Das Produkt wird realisiert:
 Es werden alle für die Nutzung relevanten Elemente realisiert bzw. bereitgestellt.
 Bei der Beschaffung eines Produkts wird das beschaffte Produkt angepasst und es werden
Produkterweiterungen entwickelt.
 Bei der Individualentwicklung eines Produkts wird dieses entwickelt.
 Die Produktdokumentation und das Anwendungshandbuch werden erarbeitet.
Vor der Betriebsaufnahme werden das Produkt und die Dokumentation qualitätsgeprüft.
HERMES-spezifisch
HERMES beschreibt nicht, wie das Produkt realisiert wird. Das hängt stark vom Produkt ab.
Im Anschluss an die Entwicklung oder Anpassung des Produkts werden die Produktdokumen-
tation sowie das Anwendungshandbuch erarbeitet.
Für die Durchführung der qualitätssichernden Massnahmen kann die Aufgabe Qualitätssiche-
rung führen im Modul Projektführung und/oder das Modul Tests genutzt werden.
 Produktkonzept
118 / 200
Aktivitäten
 Detailspezifikation erarbeiten.
 Produkt entwickeln oder anpassen.
 Produktdokumentation erarbeiten.
 Anwendungshandbuch erarbeiten.
 Qualitätssichernde Massnahmen vorbereiten und durchführen.
Ergebnisse
 Produktdokumentation
 Produkt entwickelt oder angepasst
5.4.3.32 Produktkonzept erarbeiten

Umsetzung
Zweck
Mit der Erarbeitung des Produktkonzepts wird die Grundlage für die Realisierung des Produkts
geschaffen.
Grundidee
Im Produktkonzept wird das Produkt mit seinen Komponenten und mit seiner Struktur, evtl.
auch mit seinem Bezug zu den Geschäftsprozessen beschrieben. Bei Bedarf können verschie-
dene Produktvarianten beschrieben und beurteilt werden.
HERMES-spezifisch
Das Produktkonzept basiert direkt auf den Lösungsanforderungen, auf allfälligen Organisati-
onsanforderungen und auf der Studie. Im Produktkonzept werden die Anforderungen und
die Beschreibung der in der Studie gewählten Lösungsvariante in Form einer Spezifikation
konkretisiert. Das Produktkonzept wird inhaltlich und planerisch so detailliert erstellt, dass es
eine verlässliche Grundlage für die Realisierung (Entwicklung oder Anpassung) des Produkts
bildet.
AUFGABEN
Das Produktkonzept bildet im weiteren Projektverlauf die Grundlage für die Abnahme des
Produkts.
 Studie
Aktivitäten
 Anforderungen aufgrund der gewählten Variante verfeinern.
 Die Beschreibung der gewählten Variante im Produktkonzept konkretisieren.
 Bei Bedarf das Produktkonzept mit Prototypen überprüfen.
 Produktkonzept mit den Stakeholdern abstimmen.
Ergebnisse
 Produktkonzept
119 / 200
5.4.3.33 Projekt führen und kontrollieren
Umsetzung
Zweck
Während der gesamten Projektdauer werden die Projektbeteiligten koordiniert und geführt.
Der Projektstand wird laufend überprüft, die Planung aktualisiert und entsprechende Informa-
tionen an die Projektsteuerung kommuniziert.
Grundidee
Die Führung und die Kontrolle des Projekts basieren auf der Planung. Sie beschreibt, wie die
gesetzten Ziele erreicht werden (Soll).
Die in der Planung definierte Aufgaben und Ergebnisse konkretisiert der Projektleiter mit Ar-
beitsaufträgen. Dadurch werden die Arbeitsprozesse transparent und die Gefahr von Missver-
ständnissen reduziert. Lösungsspezifische Anliegen regelt er bei klassischer Vorgehensweise
über den Anwendervertreter und stimmt sie mit ihm ab, bei agiler Vorgehensweise fallen diese
weg. Der Projektleiter sorgt für eine funktionierende, den jeweiligen Umständen entspre-
chende Projektorganisation, führt und unterstützt die Projektbeteiligten und koordiniert die
Abhängigkeiten zwischen den Arbeiten.
Auf der Grundlage der Planung und dem Fertigstellungsgrad der Ergebnisse wird der Projekt-
fortschritt periodisch überprüft. Der aktuelle Projektstand (Ist) wird erhoben und mit der Pla-
nung verglichen (Soll-Ist-Vergleich). Die Aufwände, Kosten und Termine für den weiteren Pro-
jektverlauf werden geschätzt und als Prognose abgebildet. Bei aufgetretenen oder prognos-
tizierten Abweichungen von der Planung leitet der Projektleiter, unterstützt vom Anwender-
vertreter, Massnahmen ein, damit die gesetzten Ziele erreicht werden. Die Wirkung der Mass-
nahmen wird laufend beurteilt.
Die Informationen zum Projektstand und zur Prognose werden durch die Projektführung er-
hoben und zusammengestellt und über das Reporting an die Projektsteuerung kommuniziert.
HERMES-spezifisch
Der Projektinitialisierungsauftrag bildet die Grundlage für die Führung und Kontrolle des Pro-
jekts während der Phase Initialisierung.
AUFGABEN
In den nachfolgenden Phasen werden die Informationen zur Projektführung und -kontrolle
sowie zur Regelung des Reportings im Projektmanagementplan festgehalten. Das Reporting
besteht aus dem Berichtswesen und Projektsitzungen. Zum Berichtswesen gehören der Pro-
jektstatusbericht sowie die in anderen Aufgaben erstellten Phasen- und Releaseberichte. Je
nach Vorgaben der Stammorganisation werden weitere Berichte benötigt.
Die Arbeitsaufträge werden basierend auf den Rollen den verantwortlichen Projektmitarbei-
tenden im Voraus zugeordnet.
Die Lösungsanforderungen, die Detailspezifikation sowie der Releaseplan (im Projektmanage-
mentplan) werden während der agilen Lösungsentstehung fortwährend aktualisiert bzw.
nachgeführt.
Sind massgebende Projektänderungen erforderlich, werden sie über die Aufgabe Änderungen
managen behandelt.
 Projektinitialisierungsauftrag K A
 Durchführungsauftrag K A
 Projekterfahrungen K A
 Lösungsanforderungen A
 Detailspezifikation A
120 / 200
Aktivitäten
 Während der Phase Initialisierung ermittelte Änderungen in Bezug auf den Projektinitiali-
sierungsauftrag durch den Auftraggeber genehmigen lassen.
 Nach Durchführungsfreigabe Projektmanagementplan laufend nachführen.
 Kickoff-Sitzung mit Beteiligten durchführen und Projektkultur gestalten.
 Infrastruktur bereitstellen.
 Aufgaben, Ergebnisse und Ressourcen planen und beauftragen.
 Rahmenbedingungen und Vorgaben für das Reporting ermitteln, dieses mit Berichtswesen
und Projektsitzungen im Projektmanagementplan festlegen und mit Auftraggeber verein-
baren.
 Projektstatusberichte gemäss Vorgaben erstellen und Sitzungen vorbereiten, durchführen,
nachbearbeiten und Protokolle erstellen. Entscheide festhalten.
 Projektablauf und wichtige Erkenntnisse laufend mit dem Auftraggeber abstimmen.
 Projektmitarbeitende führen sowie die Zielorientierung und gemeinsames Verständnis in
Bezug auf Vorgehen und Ergebnisse sicherstellen.
 Arbeitsaufträge erstellen und wenn notwendig mit dem Anwendervertreter abstimmen,
Abhängigkeiten zwischen Aufträgen koordinieren.
 Fortschrittskontrolle durchführen (inklusive QS-Massnahmen und Risiken), dazu Ist-Werte
mit Plan-Werten vergleichen und Prognosen erstellen, Abweichungen von der Planung
analysieren und Massnahmen einleiten.
 Während der agilen Lösungsentstehung Lösungsanforderungen, Detailspezifikation und
Releaseplan (im Projektmanagementplan) nachführen.
Ergebnisse (K=klassisch, A=agil)
 Arbeitsauftrag K A
 Projektstatusbericht K A
 Protokoll K A
 Lösungsanforderungen A
 Detailspezifikation A
5.4.3.34 Projekt steuern

AUFGABEN
Umsetzung
Zweck
Während der gesamten Projektdauer wird das Projekt auf der Basis des Reportings und ggf.
weiteren Informationen überwacht und die Erreichung der gesetzten Ziele durch adäquates
Risikomanagement und das Treffen rechtzeitiger Entscheidungen gesichert.
Grundidee
Der Auftraggeber steuert das Projekt und ist verantwortlich für den Projekterfolg. Er wird
durch die weiteren Rollen der Projektsteuerung in seiner Aufgabe unterstützt. Zeigt sich, dass
der Projekterfolg nicht erreicht werden kann, beendet er das Vorhaben mit dem Entscheid
Projektabbruch.
Damit der Projekterfolg sichergestellt werden kann, kontrolliert der Auftraggeber regelmässig
den Projektfortschritt aufgrund der von der Projektleitung erstellten Berichte.
Der Auftraggeber kann ein übergeordnetes Risikomanagement des Projekts beauftragen. Da-
für benennt er eine unabhängige Stelle, die direkt an ihn rapportiert. Diese führt das Risiko-
management aus der Managementsicht durch und entscheidet über Massnahmen.
Im Interesse einer effizienten Projektdurchführung stellt der Auftraggeber rasche Entschei-
dungen sicher. Er plant und steuert die Entscheidungsprozesse in Zusammenarbeit mit dem
Projektleiter und bei Bedarf mit weiteren Stellen. Er integriert die Entscheidungsträger in das
Projekt.
121 / 200
Der Auftraggeber regelt und überwacht das Reporting, das die formal standardisierte Infor-
mation zwischen Projektführung, Projektsteuerung und weiteren Stellen sicherstellt.
Probleme, die durch die Projektführung nicht gelöst werden können, werden als Eskalationen
an die Projektsteuerung weitergeleitet. Die Projektsteuerung behandelt diese mit der nötigen
Priorität und Dringlichkeit.
HERMES-spezifisch
Der Auftraggeber legt die Anforderungen an das Reporting fest und prüft den Fortschritt an-
hand des Projektmanagementplans und des Projektstatusberichts des Projektleiters.
Er entscheidet über bedeutende Massnahmen und damit verbundene Anpassungen des Pro-
jektmanagementplans, Änderungsanträge und risikominimierende Massnahmen.
 Phasenbericht
 Releasebericht
Aktivitäten
 Fortschrittskontrolle durchführen.
o Projektmanagementplan und Projektstatusbericht einfordern.
o Soll-Ist-Vergleiche durchführen, Prognosen beurteilen, Abweichungen analysieren
und Handlungsbedarf identifizieren.
o Massnahmen treffen.
 Risikomanagement
o Projekt- und Geschäftsrisiken aus Projektstatusbericht mit weiteren identifizierten Risi-
ken ergänzen.
o Risiken analysieren.
o Entscheide zu Massnahmen treffen.
o Massnahmenumsetzung und Wirkung überprüfen.
o Unabhängiges Controlling, QS/Risikomanagement und/oder Projektreviews und -au-
dits beauftragen.
AUFGABEN
 Entscheidungen
o Entscheidungsprozesse planen und steuern.
o Projektentscheide fällen, kommunizieren und durchsetzen.
o Stakeholder einbinden.
o Entscheide zu Änderungsanträgen fällen.
o Eskalationen behandeln.
Ergebnisse
5.4.3.35 Projektabschluss vorbereiten

Umsetzung
Zweck
Im Rahmen der Vorbereitung des Projektabschlusses werden alle abschliessenden Aktivitäten
und Massnahmen aus formaler, organisatorischer und administrativer Sicht durchgeführt und
dokumentiert, die offenen und die künftigen Pendenzen festgehalten sowie alle notwendigen
Dokumente und Ergebnisse an zuständige Stellen weitergeleitet, sodass der Entscheid zur
Auflösung der Projektorganisation und Beendigung des Projekts getroffen werden kann.
122 / 200
Grundidee
Die Dokumentenablage wird bereinigt, und die Projektdokumentation wird an die Stammor-
ganisation übergeben.
Die Projektabwicklung und die Ergebnisse werden beurteilt.
Alle offenen Pendenzen aus dem Projekt werden an die zuständigen Personen in der Stam-
morganisation übergeben.
Bemerkung:
 Zur Projekterfolgskontrolle sollte einige Zeit nach dem Projektabschluss (z. B. durch die
Anwendungsorganisation) überprüft werden, ob die erwartete Wirkung aus Sicht des Auf-
traggebers eingetreten ist. Dazu gehören z. B. die vertiefte Überprüfung der Zielerrei-
chung oder eine Nachkalkulation.
HERMES-spezifisch
Die Dokumentation der Projekterfahrungen wird abgeschlossen. Die Projektschlussbeurtei-
lung wird erstellt.
Aktivitäten
 Dokumentenablage bereinigen.
 Die für Betrieb, Wartung und Weiterentwicklung relevante Systemdokumentation an die
Stammorganisation übergeben und die Dokumentation der Projektabwicklung (Projekt-
pläne, Protokolle, Verträge, Phasenberichte usw.) gemäss den Ablagevorschriften der
Stammorganisation archivieren.
 Nicht benötigte Ressourcen (Infrastruktur usw.) an die Stammorganisation zurückgege-
ben.
 Zugriffsberechtigungen aufheben, die spezifisch für das Projekt erteilt wurden.
 Aufwanderfassungssysteme, die Projektbuchhaltung, das Reporting usw. abschliessen.
 Projektschlussbeurteilung erstellen.
AUFGABEN
 Projekterfahrungen abschliessen.
 Als Pendenz festlegen, was im Rahmen der Projekterfolgskontrolle untersucht werden soll,
welche Massnahmen dazu vorzusehen sind und wer diese ausführen soll.
 Alle offenen Pendenzen samt erforderlichen Massnahmen aus dem Projekt an die Stam-
morganisation (z. B. zu Handen der Anwendungsorganisation) übergeben.
Ergebnisse
5.4.3.36 Projektmanagementplan erarbeiten

Umsetzung
Zweck
Mit der Erarbeitung des Projektmanagementplans werden auf der Basis der Planung und der
Termine aus der Studie die Gesamtplanung des Projekts und die wesentlichen Bestimmungen
und Regelungen festgelegt sowie die Voraussetzungen dafür geschaffen, den Durchführungs-
auftrag zu erarbeiten.
123 / 200
Grundidee
Mit der Erarbeitung des Projektmanagementplans werden noch vor der Freigabe der Durch-
führung die erstmalige Gesamtplanung der Lösungsentstehung sowie die wesentlichen Rege-
lungen des weiteren Projektablaufs festgelegt.
Die Planung und Abwicklung der verschiedenen Vorhaben hat sich nach den organisations-
spezifischen Vorgaben der Stammorganisation zu richten.
HERMES-spezifisch
Die Stakeholderliste, ggf. die Beschaffungsanalyse und die Studie mit dem Entscheid Weiteres
Vorgehen bilden die Grundlage, um den Projektmanagementplan zu erarbeiten. Der Projekt-
managementplan ist die Voraussetzung für die Steuerung und Kontrolle des Projekts durch
den Auftraggeber und für die Abstimmung des Projekts mit den Vorgaben der Stammorga-
nisation.
Der Projektmanagementplan bildet die Grundlage für die Führung und Kontrolle des Projekts
durch die Projektleitung. Er wird gemäss dem Entscheid Weiteres Vorgehen ausgerichtet und
legt u. a. fest, wie das Risikomanagement oder das Änderungsmanagement durchgeführt
oder die Qualitätssicherung der Ergebnisse und Prozesse/Aufgaben sichergestellt werden.
Im Projektmanagementplan wird bei geplanter agiler Vorgehensweise festgelegt, ob die an
sich fakultative Releasefreigabe im Projekt zwingend vorgeschrieben ist oder nicht. Diese Ent-
scheidung obliegt dem Auftraggeber.
Vor der Freigabe der Durchführung wird nach dem Prinzip der rollenden Planung ein Gesamt-
plan erstellt, und die nachfolgende Phase, Konzept oder Umsetzung, detailliert geplant. Je-
weils am Ende einer Phase bzw. eines Release wird die nächste Phase/das nächste Release
detailliert geplant und der Gesamtplan überprüft. Dies erfolgt mit der Aufgabe Phasenfrei-
gabe vorbereiten bzw. Releaseabschluss vorbereiten.
Ist das Projekt in einem Programm eingebettet, hat der Programmmanagementplan Vorrang.
Projektbestimmungen des Projektmanagementplans dürfen dem Sinn und Geist der entspre-
chenden Programmbestimmungen nicht zuwiderlaufen. Die Ausnahme, die diese Regel be-
stätigt, ist die Wahl zwischen der klassischen oder agilen Vorgehensweise für die Lösungsent-
stehung. Diese muss zwingend für jedes einzelne Projekt individuell geprüft und in der Studie
dokumentiert werden.
AUFGABEN
 Studie
Aktivitäten
 Informationen über das Projekt und sein Umfeld beschaffen.
 Projektmanagementplan erarbeiten und insbesondere:
o Prozess des Risikomanagements und Metriken zur Bewertung der Risiken festlegen;
o Änderungsprozess festlegen und bekannt machen;
o Qualitätsziele für die Durchführung festlegen;
o Prüfverfahren für die Ergebnisse und Prozesse/Aufgaben festlegen und im Kapitel
Prüfplan festhalten;
o Prüfmethoden der Qualitätssicherung festlegen;
o Beschaffungsplan aus der Beschaffungsanalyse übernehmen, prüfen, mit Studie ab-
stimmen, soweit notwendig anpassen und festhalten;
o Bei agiler Vorgehensweise explizit festhalten, ob der Entscheid Releasefreigabe treffen
zwingend vorgeschrieben ist;
o Durchführungsorganisation festlegen
 Projektorganisation inklusive Entwicklungsteam (agil)
 Rollenbesetzung Stamm- und Projektorganisation
124 / 200
Ergebnisse
5.4.3.37 Prototyping durchführen

Umsetzung
Zweck
Mit dem Prototyping können vereinfachte, jedoch weitestgehend funktionsfähige Lösungsan-
sätze erstellt und ausprobiert werden. So können die Machbarkeit oder Brauchbarkeit der
fokussierten Lösung, allenfalls auch deren Nützlichkeit und Akzeptanz, geprüft werden. Nebst
den technischen und funktionalen Kriterien können insbesondere beim Produkt auch das Aus-
sehen oder die Masse und die Proportionen, bei Dienstleistungen die visualisierte Idee begut-
achtet werden.
Grundidee
Die Erstellung eines Prototyps, bei Produkten vielleicht nur eines Modells, ist eine risikomini-
mierende Massnahme. Prototyping kann je nach Projektsituation in verschiedenen Phasen
einmal oder mehrmals erfolgen. Ein Prototyp kann wiederverwendbar sein oder Wegwerfcha-
rakter haben. Abhängig von den Erkenntnissen wird das weitere Vorgehen festgelegt.
HERMES-spezifisch
Das Prototyping wird je nach Bedarf während des Projektverlaufs einmal oder mehrmals
durchgeführt. Die hierfür notwendigen Grundlagen/Voraussetzungen sind bedarfsbedingt
und abhängig vom Projektstand.
Die Ziele und das Konzept sowie die Ergebnisse des Prototyps werden in der Prototypdoku-
mentation festgehalten.
Der Prototyp wird entwickelt und die Ergebnisse aus dem Prototyping werden ausgewertet.
-
Aktivitäten
AUFGABEN
 Ziele, Konzept und Methodik für den Prototyp erarbeiten.
 Prototyp erstellen.
 Prototyp auswerten.
 Ergebnisse und Schlussfolgerungen dokumentieren und in die weitere Planung einfliessen
lassen.
 Prototyp vernichten oder Wiederverwendbarkeit sicherstellen.
Ergebnisse
 Prototypdokumentation
5.4.3.38 Qualitätssicherung führen

Umsetzung
Zweck
Mit der Qualitätssicherung wird sichergestellt, dass die im Projektablauf erarbeiteten Ergeb-
nisse die geforderte Qualität aufweisen.
Grundidee
Grundsätzlich wird bei der Qualitätssicherung zwischen ‹Prüfen› und ‹Testen› unterschieden:
125 / 200
 Prüfen umfasst beim System oder beim Produkt die inhaltliche und formale Überprüfung
von Dokumenten und die Einhaltung vereinbarter Prozesse/Aufgaben;
 Testen umfasst die Überprüfung der Erfüllung der Lösungsanforderungen und der An-
wendbarkeit der Prozesse am laufenden System.
Die Qualität eines Ergebnisses entsteht während der Erarbeitung. Um die geforderte Qualität
sicherzustellen, werden während der Erarbeitung oft mehrere QS-Massnahmen durchgeführt.
Das Prüfen bzw. das Testen am Ende des Erarbeitungsprozesses dient der Abnahme bzw.
Genehmigung eines Ergebnisses und bestätigt die Erfüllung der Qualitätsanforderungen an
das Ergebnis.
HERMES-spezifisch
Die Aufgabe Qualitätssicherung führen umfasst das Prüfen.
Das Testen ist hingegen Gegenstand des Moduls Tests.
Die Prüfung von Ergebnissen wie Vernehmlassungen, Reviews, Audits usw. erfolgt gemäss
Projektmanagementplan. Er enthält auch den Prüfplan mit den Ergebnissen und ihren Prüf-
verfahren sowie Angaben, welche Rolle welche Prüfaufgaben bei klassischer oder bei agiler
Vorgehensweise zu erfüllen hat.
Die Prüfungen werden als Aktivitäten im Arbeitsauftrag zur Erarbeitung des entsprechenden
Ergebnisses aufgeführt.
Die Ergebnisse einer Prüfung werden im Prüfprotokoll festgehalten.
Der Auftraggeber kann eine Qualitätssicherung der Projektführung beauftragen. Dafür be-
nennt er eine unabhängige Stelle, die direkt an ihn rapportiert. Diese Massnahme erfolgt im
Modul Projektsteuerung mit der Aufgabe Projekt steuern.
 Arbeitsauftrag
Aktivitäten
 Qualitätsziele für die Projektphase bzw. das Release – abgeleitet von den zu erreichenden
Zielen – im Projektmanagementplan festlegen.
 Prüfverfahren und Abläufe gemäss Projektmanagementplan im Arbeitsauftrag festhalten
AUFGABEN
und sicherstellen, dass bei allen Projektbeteiligten ein einheitliches Verständnis besteht.
 Prüfungen (delegieren und) durchführen (lassen) und Ergebnisse im Prüfprotokoll festhal-
ten.
 Zweckmässigkeit der Wirksamkeit der Qualitätssicherung bewerten und nötigenfalls An-
passungen vornehmen.
Ergebnisse
 Prüfprotokoll
5.4.3.39 Rechtsgrundlagenanalyse erarbeiten

Umsetzung
Zweck
Mit der Analyse der Rechtsgrundlagen wird sichergestellt, dass die rechtlichen Voraussetzun-
gen für das Projekt gegeben sind oder die Massnahmen definiert sind, damit diese geschaffen
werden können.
Grundidee
Die rechtlichen Grundlagen müssen in jedem Projekt eingehalten werden. Sie bilden eine un-
verrückbare Restriktion für ein Projekt.
126 / 200
HERMES-spezifisch
Die Projektleitung stellt sicher, dass abgeklärt wird, ob eine ausreichende Rechtsgrundlage
besteht.
Hierzu wird mit der zuständigen Stelle (in der Regel ein Rechtsdienst oder eine Dienststelle,
die für die Rechtsetzung zuständig ist) Kontakt aufgenommen. Fehlt eine ausreichende
Rechtsgrundlage, so gilt es – wiederum in Zusammenarbeit mit den zuständigen Stellen – zu
klären, ob und wie die nötigen Anpassungen der rechtlichen Grundlagen erarbeitet werden
können.
Aktivitäten
 Bestehende Rechtsgrundlagen im Hinblick auf das künftige System dokumentieren.
 Bevorstehende Änderungen der bestehenden Rechtsgrundlagen analysieren.
 Mögliche Lücken bei den Rechtsgrundlagen identifizieren und mit den zuständigen Stellen
Vorschläge zur Deckung der Lücken erarbeiten.
 Auswirkungen auf die Studie und die Projektabwicklung beurteilen.
 Rechtsgrundlagenanalyse mit den Stakeholdern abstimmen.
Ergebnisse
5.4.3.40 Releaseabschluss vorbereiten

Umsetzung
Zweck
Für den Abschluss eines Release werden im Rahmen der agilen Vorgehensweise die Ergeb-
nisse zusammengefasst und für das Reporting bereitgestellt.
AUFGABEN
Grundidee
Am Ende eines Release werden Informationen zum Projektstand und zur Prognose über das
Reporting an die Projektsteuerung geliefert. Muss gemäss Projektmanagementplan ein Ent-
scheid Releasefreigabe getroffen werden, werden die Informationen von den Entscheidungs-
trägern für die Entscheidungsfindung benötigt.
HERMES-spezifisch
Der Releasebericht wird erstellt. Der Gesamterfolg des Projekts wird überprüft, das zu Ende
gehende Release beschrieben, der Nutzen hervorgehoben und auf bekannte Fehler hinge-
wiesen.
Der Releasebericht bildet die Grundlage für das Reporting und ist für den Auftraggeber die
Entscheidungsgrundlage für die eventuell vorgesehene Freigabe des nächsten Release.
Der Projektmanagementplan wird nachgeführt.
 Änderungsstatusliste
Aktivitäten
 Nächstes Release gemäss Releaseplan (Projektmanagementplan) identifizieren.
 Durchführungsplan verifizieren.
127 / 200
 Projektmanagementplan nachführen und mit allen Beteiligten sowie den Controlling- und
 Ergebnisse des Release, inklusive von Änderungen, im Releasebericht zusammenfassen.
 Projektstatusbericht als Beilage zu Releasebericht aktualisieren.
 Entscheide bei der Projektsteuerung initiieren.
Ergebnisse
 Releasebericht
5.4.3.41 Risiken managen

Umsetzung
Zweck
Mit dem Risikomanagement werden Risiken frühzeitig identifiziert und Massnahmen festge-
legt, um den Projekterfolg sicherzustellen.
Grundidee
Risiken sind mögliche künftige Ereignisse, die bei Eintreten ein Problem darstellen. Projektri-
siken betreffen den Projektablauf. Betriebsrisiken betreffen die Nutzung der Projektergeb-
nisse.
Risiken werden identifiziert, analysiert und bewertet. Abhängig von der Bewertung eines Risi-
kos werden die Strategie (z. B. Vermeidung, Verminderung, Auslagerung, Akzeptanz) und die
Massnahmen zum Umgang mit dem Risiko festgelegt.
HERMES-spezifisch
Die Risiken werden im Rahmen der Lösungsentstehung gemäss Projektmanagementplan ge-
managt.
Bei klassischer Vorgehensweise jeweils am Ende der Phase, bei agiler Vorgehensweise am
Ende jedes Release findet eine vertiefte Risikoüberprüfung statt, damit die Entscheidung zur
Freigabe der nächsten Phase bzw. des nächsten Release getroffen werden kann. Die effektiven
AUFGABEN
Risiken werden je nach Projektlauf im Phasen- bzw. Releasebericht und im Projektstatusbericht

festgehalten.
Die Risikobeurteilung wird im QS- und Risikobericht festgehalten.
Der Auftraggeber kann im Rahmen der Aufgabe Projekt Steuern ein übergeordnetes Risiko-
management des Projekts beauftragen.
 Phasenbericht
 Releasebericht
Aktivitäten
 Risiken identifizieren und in Risikobereiche gruppieren. Risiken analysieren und Eintritts-
wahrscheinlichkeit sowie Schadensausmass der Risiken beurteilen und im Projektstatusbe-
richt dokumentieren.
 Im Projektstatusbericht für jedes Risiko die Strategie (z. B. Vermeidung, Verminderung,
Auslagerung, Akzeptieren des Risikos) definieren und die Massnahmen festlegen, beauf-
tragen und überwachen.
 Beurteilung der Risikosituation mittels Projektstatusbericht periodisch an die relevanten
Stellen und Personen kommunizieren.
128 / 200
Ergebnisse
5.4.3.42 Schutzbedarfsanalyse erarbeiten

Umsetzung
Zweck
Mit der Schutzbedarfsanalyse werden die Anforderungen an die Informationssicherheit und
den Datenschutz erhoben.
Grundidee
Bei jedem Informatikvorhaben ist eine Schutzbedarfsanalyse durchzuführen. Mit ihrer Erarbei-
tung wird gewährleistet, dass die ISDS-Aspekte von Anfang an berücksichtigt werden.
HERMES-spezifisch
Zeigt die Schutzbedarfsanalyse, dass ein erhöhter Schutz nötig ist, muss während der Lö-
sungsentstehung ein ISDS-Konzept mit einer vertieften Risikoanalyse erarbeitet werden.
Aktivitäten
 Informationssicherheit und Schutzbedarf analysieren.
 Risikoanalyse durchführen.
 Anforderungen bezüglich Informationssicherheit und Datenschutz prüfen und Auswirkun-
gen auf die Studie, die Projektabwicklung und die anvisierte Lösung beurteilen.
 Schutzbedarfsanalyse mit den Controlling- und Vorgabestellen abstimmen.
Ergebnisse
AUFGABEN
5.4.3.43 Stakeholder managen und informieren

Umsetzung
Zweck
Die Stakeholder werden identifiziert, kontaktiert, für das Projekt gewonnen, deren Grundinte-
ressen analysiert und Massnahmen festgelegt, um den Projekterfolg zu sichern. Mit dem In-
formieren wird der institutionalisierte Informationsfluss zwischen dem Projekt sowie seinem
Umfeld sichergestellt. Zum Informieren gehört auch das Projektmarketing.
Grundidee
Projektleiter und Auftraggeber identifizieren und analysieren alle Personen oder Gruppen, die
ein berechtigtes Interesse am Projektverlauf haben oder für die es aufgrund ihrer Interessen-
lage von Bedeutung ist, wie sich die künftige Lösung verhält. Die Interessen, Erwartungen und
Ziele dieser betroffenen Stakeholder werden zusammengetragen, analysiert und auf mögliche
Diskrepanzen und Konflikte untersucht. Um die Erfolgschancen zu erhöhen, müssen erkannte
Diskrepanzen oder Konflikte soweit möglich bereinigt werden. Bei Bedarf werden Entschei-
dungsprozesse geplant und Entscheide vorbereitet.
129 / 200
Die Kommunikationsziele und Kommunikationsmassnahmen werden geplant bzw. durchge-
führt, und die Wirkung wird regelmässig überprüft. Die Kommunikation berücksichtigt die
Zielgruppen und die Stakeholderinteressen.
HERMES-spezifisch
Die Aufgabe obliegt grundsätzlich dem Projektleiter. Sie ist projektspezifisch im Projektma-
nagementplan festgehalten.
Der Projektleiter erstellt zusammen mit dem Auftraggeber die Stakeholderliste und zusam-
men mit dem Anwendervertreter die Stakeholderinteressen.
Die Identifikation der Stakeholder samt Stakeholderliste und die Stakeholderinteressen wer-
den erstmals in der Phase Initialisierung erstellt und im Projektablauf kontinuierlich weiterge-
führt.
Der institutionalisierte Informationsfluss wird im Kommunikationsplan als Teil des Projektma-
nagementplans festgelegt.
 Stakeholderinteressen
Aktivitäten
 Rahmenbedingungen und Vorgaben für die Kommunikation ermitteln.
 Stakeholder identifizieren und analysieren, Stakeholderliste und Stakeholderinteressen er-
stellen bzw. nachführen.
 Geeignete Stakeholder als potenzielle Mitglieder des Projektausschusses identifizieren
und dem Auftraggeber vorschlagen.
 Stakeholder kontinuierlich managen.
 Auftraggeber, Anwendervertreter und weitere berechtigte Stakeholder laufend informie-
ren.
 Kommunikationsziele festlegen, Kommunikationsmassnahmen planen und mit Auftragge-
ber abstimmen. Massnahmen umsetzen und Wirkung messen. Kommunikationsplan im
Projektmanagementplan laufend nachführen.
 Entscheidungsplanung erstellen, mit Auftraggeber abstimmen und in die Kommunikati-
AUFGABEN
onsplanung integrieren.
Ergebnisse
5.4.3.44 Stakeholderinteressen vertreten

Umsetzung
Zweck
Bei der Lösungsentstehung spielen die Stakeholder eine zentrale Rolle, da sie die Anforde-
rungen und die Anwendersicht in die Entwicklung einbringen und somit den Entstehungspro-
zess direkt beeinflussen. Die Vertretung der Stakeholder und ihrer Interessen bei der Lösungs-
entstehung fördert die Akzeptanz und den Erfolg der neuen Lösung.
130 / 200
Grundidee
Die identifizierten und informierten Stakeholder werden soweit in das Projektgeschehen ein-
gebunden, dass die Lösungsentstehung von ihren Kenntnissen direkt profitieren kann und die
Stakeholder die Projektergebnisse als ihre eigene Lösung erkennen. Die Einbindung der Sta-
keholder kann entweder durch deren Vertretung im Projekt erfolgen oder deren direkte Mit-
wirkung an der Lösung als Fachspezialisten erzielt werden.
HERMES-spezifisch
Die Aufgabe obliegt dem Anwendervertreter.
Die Impulse und Funktionsanforderungen der Stakeholder fliessen bei klassischer Vorgehens-
weise via Änderungsmanagement ein, bei agiler Lösungsentstehung im Rahmen der agilen
Entwicklung.
Die erstmals in der Phase Initialisierung erstellten Stakeholderinteressen werden im Projekt-
ablauf kontinuierlich weitergeführt und analysiert.
Aktivitäten
 Stakeholder angehen, sie interviewen, zusammen mit ihnen fachliche und lösungsspezifi-
schen Fragen und Problemstellungen behandeln, Meinungen aus der Geschäftspraxis ein-
holen.
 Anregungen und Wünsche der Stakeholder entgegennehmen und sie in das Projekt ein-
fliessen lassen.
 Interessen der Stakeholder im Projekt vertreten oder die Stakeholder direkt an der Lö-
sungsentstehung mitwirken lassen.
 Stakeholderinteressen nachführen.
Ergebnisse
5.4.3.45 Studie erarbeiten
AUFGABEN
Umsetzung
Zweck
Mit der Studie werden u.a. die Ziele gesetzt, Grobanforderungen definiert sowie Lösungsva-
rianten erarbeitet und evaluiert, so dass der Entscheid Weiteres Vorgehen getroffen und in
der Studie dokumentiert werden kann.
Grundidee
Ein Projekt muss mit den Vorgaben (Strategie und Ziele) der Stammorganisation übereinstim-
men. Es muss die Rahmenbedingungen berücksichtigen und seine Wirtschaftlichkeit muss ge-
währleistet sein.
Die Studie wird soweit konkretisiert, dass eine für den Projektzeitpunkt angemessene Pla-
nungsgenauigkeit für Termine, Kosten und Aufwand erreicht wird. Die Risiken und die Wirt-
schaftlichkeit müssen umfassend beurteilt werden können.
HERMES-spezifisch
In einem ersten Schritt wird im Rahmen der Standortbestimmung und der darauf basierenden
Erarbeitung möglicher Ziele geprüft, ob es eine (neue) Lösung überhaupt braucht und somit
eine Weiterführung des Projekts als notwendig erscheint. Mit fortschreitender Konkretisierung
der Studie inklusive aller flankierenden Ergebnisse wird stets weitergeprüft, ob eine Projekt-
fortsetzung Sinn macht. Ist dies nicht der Fall, wird die Phase Initialisierung und somit das
Projekt abgeschlossen.
131 / 200
Die Erkenntnisse aus der Rechtsgrundlagen- und aus der Schutzbedarfsanalyse werden über-
nommen.
Die gesetzten Ziele und Anforderungen bilden die Grundlage für die Erarbeitung von Varian-
ten. Die Ziele werden abschliessend festgelegt. Die Anforderungen werden so beschrieben,
dass der Projektinhalt und der Projektumfang klar sind und die Beurteilungskriterien festge-
legt werden können. Die Anforderungen werden im weiteren Projektverlauf konkretisiert.
Auf der Basis der Ziele und Anforderungen werden die Varianten in der Studie beschrieben.
Typische Varianten sind die Individualentwicklung auf der einen, die Beschaffung einer im
Markt verfügbaren Lösung auf der anderen Seite.
Für die Erarbeitung der Varianten, die eine Beschaffung vorsehen, werden allfällige Erkennt-
nisse (z. B. aus dem Marktumfeld) aus der parallel zur Studie zwingend zu erstellenden Be-
schaffungsanalyse herbeigezogen. Die Beschreibung der Varianten erfolgt so detailliert, dass
sie bewertet werden können. Für die Beurteilung der Varianten werden die Beurteilungskrite-
rien festgelegt. Dazu gehören Zielerreichungsgrad, Anforderungsabdeckung und weitere Be-
urteilungskriterien wie die Einhaltung der Vorgaben, die Machbarkeit, die Risiken und der
Nutzen. Je Variante wird die Vorgehensweise definiert, ob klassisch, oder agil.
Die Bewertung wird nachvollziehbar dokumentiert und zeigt den Wissensstand auf, der zum
Zeitpunkt der Entscheidung herrscht.
Vor der Planung und Terminierung wird das für das Entwicklungsvorgehen passende Szenario
(vgl. Kapitel 2 Szenarien) ausgewählt und bei Bedarf angepasst.
Aktivitäten
 Standortbestimmung erarbeiten und in der Studie festhalten.
 Lösungsziele und Anforderungen erarbeiten, mit Stakeholdern abstimmen, Stakeholder-
liste anpassen und in der Studie festhalten.
 Zielkonflikte erkennen und mit dem Auftraggeber bereinigen.
 Marktabklärungen und Informationen aus der Beschaffungsanalyse in die Studie integrie-
AUFGABEN
ren.
 Erkenntnisse aus der Rechtsgrundlagenanalyse und der Schutzbedarfsanalyse in die Stu-
die integrieren.
 Lösungsvarianten einzeln beschreiben.
 Beurteilungskriterien und ihre Gewichtung festlegen.
 Lösungsvarianten aufgrund der Beurteilungskriterien bewerten.
 Passendes Szenario auswählen, allenfalls individuell weiter anpassen, Projektwertigkeit er-
mitteln und die Vorgehensweise (klassisch/agil) festlegen.
 Auswirkung des Entscheids Weiteres Vorgehen auf das Projekt beurteilen.
 Projekt und Termine grob planen, grobe Eckpfeile (Meilensteine) definieren
 Studie fertigstellen.
 Studie mit Auftraggeber und Stakeholdern inklusive der Controlling- und Vorgabestellen
abstimmen.
Ergebnisse
 Studie
132 / 200
5.4.3.46 System aktivieren
Umsetzung
Zweck
Die Systemaktivierung ist die Voraussetzung für die Aktivierung des Betriebs.
Grundidee
Das System wird aktiviert, damit anschliessend der Betrieb aktiviert werden kann.
HERMES-spezifisch
Nach dem Entscheid Betriebsaufnahme aktiviert der Ersteller das System.
Aktivitäten
 System aktivieren.
 Erste Zeit der Nutzung begleiten.
 Auftretende Probleme analysieren, Massnahmen festlegen und entscheiden (Bugfixing).
 Bei Bedarf Stabilisierungsmassnahmen treffen.
Ergebnisse
 System aktiviert
5.4.3.47 System in Betrieb integrieren

Umsetzung
Zweck
Die Integration des Systems in die Betriebsinfrastruktur schafft die Voraussetzungen für die
Durchführung der Tests und für die Vorabnahme.
AUFGABEN
Grundidee
Das realisierte System (entwickelt oder parametrisiert) wird:
 technisch und organisatorisch in die Betriebsinfrastruktur integriert; und
 getestet.
HERMES-spezifisch
Auf der Basis des Integrationskonzepts wird lediglich das System in die Betriebsinfrastruktur
integriert. Das Testen erfolgt im Modul Tests. Die Anbindungen zu Umsystemen werden akti-
viert.
Gemäss Integrationsplan im Ergebnis Integrations- und Installationsanleitung kann die In-
tegration des Systems in mehreren Schritten erfolgen.
 Betriebsorganisation realisiert
 Testinfrastruktur realisiert
 Integrations- und Installationsanleitung
 System entwickelt oder parametrisiert
 Schnittstellen realisiert
133 / 200
Aktivitäten
 Integrationsschritte gemäss Integrations- und Installationsanleitung ausführen und doku-
mentieren.
 Übergang von einer Betriebsplattform (z. B. Entwicklung, Test, Schulung, Produktion) auf
die andere implementieren und sicherstellen.
 Erfahrungen aus Integrationsprozess für die spätere Wartung und Weiterentwicklung im
Betriebshandbuch dokumentieren.
 Ergebnisse Betriebskonzept und Integrationskonzept als Anhänge dem Betriebshandbuch
hinzufügen.
Ergebnisse
 System integriert
5.4.3.48 System realisieren

Umsetzung
Zweck
Das System wird so weit entwickelt oder parametrisiert, dass es die Lösungsanforderungen
erfüllt und für die Integration bereit ist.
Grundidee
Basierend auf den Lösungsanforderungen des Systemkonzepts und der Lösungsarchitektur
wird die Detailspezifikation erarbeitet. Das System wird realisiert:
 bei der Beschaffung eines Systems werden das beschaffte System parametrisiert und die
Systemerweiterungen entwickelt;
 bei der Individualentwicklung eines Systems wird dieses entwickelt;
 das Anwendungshandbuch wird erarbeitet.
HERMES-spezifisch
Der Entwickler testet das System während der Realisierung, bevor die erste Auslieferung an
den Anwender und Betreiber erfolgt.
AUFGABEN
Die Tests nach der ersten Auslieferung werden mit dem Modul Tests unterstützt. Die bisher
erarbeitete Dokumentation, insbesondere das Systemkonzept sowie die Lösungsarchitektur
werden ggf. nachgeführt und das Anwendungshandbuch erarbeitet.
 Systemkonzept
Aktivitäten
 Detailspezifikationen erarbeiten.
 System entwickeln oder parametrisieren.
 Qualitätssicherung und Tests durch den Ersteller durchführen.
 Dokumentationen nachführen.
 Anwendungshandbuch erstellen.
 Lösungsarchitektur nachführen.
Ergebnisse
 Systemkonzept
134 / 200
 System entwickelt oder parametrisiert
5.4.3.49 Systemintegration vorbereiten

Umsetzung
Zweck
Die Systemintegration wird durch den Ersteller vorbereitet, damit der Betreiber das System in
den Betrieb integrieren kann.
Grundidee
Die nötigen Detailspezifikationen für die Integration werden erarbeitet.
HERMES-spezifisch
Auf der Basis des Integrationskonzepts werden Schnittstellen zu Umsystemen und nötige An-
passungen an Umsystemen realisiert.
Auf der Basis des Betriebskonzepts und der Vorgaben des Betreibers wird die Integration in
den Betrieb vorbereitet. Die Integrations- und Installationsanleitung wird erarbeitet.
 Betriebskonzept
Aktivitäten
 Detailspezifikation erarbeiten.
 Schnittstellen entwickeln.
 Anpassungen an den Umsystemen koordinieren.
 Integration in den Betrieb vorbereiten.
 Integrations- und Installationsanleitung erstellen.
 Lösungsarchitektur aktualisieren.
AUFGABEN
Ergebnisse
 Schnittstellen realisiert
 Integrations- und Installationsanleitung
5.4.3.50 Test durchführen

Umsetzung
Zweck
Mit Tests wird die Erfüllung der an das System gestellten Anforderungen überprüft. Die Tests
werden durchgeführt, die Testergebnisse werden beurteilt und protokolliert.
Grundidee
Die erste Testdurchführung erfolgt auf dem Testsystem, sofern die Vorbedingungen dazu er-
füllt sind. Entsprechend muss vorher die Testinfrastruktur realisiert worden sein.
135 / 200
HERMES-spezifisch
Die Aufgabe Test durchführen umfasst:
a) das ordentliche Testen auf dem Testsystem der realisierten Testinfrastruktur;
b) das Testen des integrierten Systems im Zuge der Aufgabe System in Betrieb integrieren;
c) das Testen des realisierten Produkts im Zuge der Aufgabe Produkt realisieren;
d) das Testen des realisierten Migrationsverfahrens im Zuge der Aufgabe Migrationsverfah-
ren realisieren; und
e) das Qualitätstesten im Zuge der Aufgabe Qualitätssicherung führen.
Die Tests werden gemäss den Testfallbeschreibungen im Testkonzept durchgeführt. Bei Be-
darf werden sie weiter konkretisiert. Die im Testprotokoll eingetragenen Testergebnisse wer-
den anhand im Testkonzept definierter Kriterien beurteilt. Das Testprotokoll wird vor dem
Entscheid Vorabnahme geprüft.
Bei Bedarf wird die Testdurchführung mehrfach wiederholt, bis die Qualitätskriterien erfüllt
sind. Offene Punkte aus den Tests und das weitere Vorgehen diesbezüglich werden verbind-
lich vereinbart. Der Testplan im Testkonzept wird laufend aktualisiert.
 Testkonzept
 ISDS-Konzept
Aktivitäten
 Prüfen, ob die Testvorbedingungen erfüllt sind, um die Tests zu starten.
 Tests gemäss Testkonzept durchführen.
 Testergebnisse protokollieren und gemäss Kriterien im Testkonzept beurteilen.
 Ggf. Mängel beheben und Tests wiederholen.
 Vorgehen zu offenen Punkten vereinbaren.
Ergebnisse
 Testprotokoll
 Testkonzept
AUFGABEN
5.4.3.51 Testinfrastruktur realisieren

Umsetzung
Zweck
Die Testinfrastruktur wird vor Beginn der Tests bereitgestellt. Sie umfasst alle Elemente, die
für die Testdurchführung, die Sammlung und Bewertung der Testergebnisse notwendig sind.
Grundidee
Testinfrastruktur mit Testsystem, Testdaten und Testhilfsmitteln (z. B. Testverwaltungssystem
zur Sammlung und Bewertung der Ergebnisse) bereitstellen.
HERMES-spezifisch
Die Vorbereitung der Testinfrastruktur erfolgt gemäss den im Testkonzept definierten Zustän-
digkeiten. Die Testinfrastruktur wird mit qualitätssichernden Massnahmen auf ihre Bereitschaft
und Vollständigkeit hin überprüft.
 Testkonzept
136 / 200
Aktivitäten
 Testinfrastruktur gemäss Testkonzept bereitstellen.
 Qualität der Testinfrastruktur sicherstellen.
 Testinfrastruktur für die Tests freigeben.
Ergebnisse
5.4.3.52 Testinfrastruktur überführen

Umsetzung
Zweck
Nach Projektabschluss werden im Rahmen der Nutzungs- und Wartungsphase für Korrektu-
ren und für Weiterentwicklungen Tests durchgeführt. Deshalb muss die Testinfrastruktur in-
klusive des Testkonzepts in die Stammorganisation überführt werden.
Grundidee
Um die Pflege und Weiterentwicklung des Systems auch während der Nutzungsphase nach
Beendigung des Projekts zu ermöglichen, muss die Testinfrastruktur samt Testkonzept noch
vor dem Projektabschluss der Stammorganisation übergeben werden.
HERMES-spezifisch
Die Überführung des Testkonzepts und der Testinfrastruktur erfolgt nach der Abnahme, aber
vor Projektabschluss. Sie werden von der Projektorganisation an die für den Betrieb und die
Weiterentwicklung Verantwortlichen bei Anwender, Ersteller und Betreiber übergeben.
 Testkonzept
Aktivitäten
 Testkonzept mit Testfallbeschreibungen sowie Testdaten bereinigen bzw. mit Erkenntnis-
sen aus den Tests aktualisieren.
AUFGABEN
 Zuständige informieren und ausbilden.
 Übergabe formal vornehmen.
 Übergabe protokollieren.
Ergebnisse
 Testkonzept
 Testinfrastruktur überführt
 Protokoll
5.4.3.53 Testkonzept erarbeiten

Umsetzung
Zweck
Mit dem Testkonzept werden die Voraussetzungen für die systematische und effiziente Orga-
nisation und Durchführung der Tests gelegt.
Grundidee
Das Testen von Lösungen erfordert ein spezifisches Testmanagement. Dieses wird durch das
Testkonzept beschrieben.
137 / 200
Das Testkonzept mit dem Testplan und den Testfallbeschreibungen ist die Grundlage, auf der
die Testorganisation und die Testinfrastruktur bereitgestellt und die Tests durchgeführt wer-
den.
HERMES-spezifisch
Die Grundlage für das Testkonzept liefern einerseits die Lösungsanforderungen, anderseits
die entsprechenden Konzepte.
Die Erarbeitung des Testkonzepts bedingt die enge Zusammenarbeit zwischen Anwender,
Entwickler und Betreiber, da sie, ergänzend zu den Angaben aus den Grundlagedokumenten,
weitere wesentliche Beiträge zum Testen liefern müssen. Das Testkonzept muss gemeinsam
akzeptiert und anschliessend umgesetzt werden.
 Produktkonzept
 Systemkonzept
 Betriebskonzept
Aktivitäten
 Qualitätsmerkmale und -anforderungen erheben bzw., wenn bereits vorhanden, verifizie-
ren und im Testkonzept festhalten.
 Testziele und Testarten definieren und im Testkonzept festhalten.
 Testinfrastruktur mit Testsystem, Testdaten und Testhilfsmitteln beschreiben.
 Testobjekte, Testorganisation, Testfallbeschreibungen und Testplan als Teil des Testkon-
zepts erarbeiten.
 Testkonzept mit den Stakeholdern abstimmen.
Ergebnisse
 Testkonzept
5.4.3.54 Vereinbarung erarbeiten

AUFGABEN

Umsetzung
Zweck
Auf der Grundlage der Ausschreibungsunterlagen samt Anhängen wie Vertragsentwurf, All-
gemeine Geschäftsbedingungen und Angebot wird die Vereinbarung erarbeitet.
Grundidee
Eine Projektvereinbarung, ein Vertrag oder die Service Level Agreements (SLA) regelt die Zu-
sammenarbeit zwischen den verschiedenen Projektbeteiligten wie Anwender (Auftraggeber),
Ersteller und Betreiber und kann für eine oder mehrere Phasen abgeschlossen werden.
HERMES-spezifisch
Diese Aufgabe steht in Beziehung zur Aufgabe Leistungen vereinbaren und steuern. Mit ihr
wird der Vertrag abgeschlossen und die Leistung gesteuert.
Nach Abschluss der Vereinbarung werden die Leistungen periodisch auf Übereinstimmung
mit der Planung und den Vereinbarungen hin überprüft. Dies wird in der Aufgabe Leistungen
vereinbaren und steuern abgewickelt.
138 / 200
 Angebot
Aktivitäten
 Vereinbarung erarbeiten.
 Vereinbarung durch die Stammorganisation bzw. Controlling- und Vorgabestellen prüfen
lassen.
 Vertragsvollzug sicherstellen.
Ergebnisse
 Vereinbarung
AUFGABEN
139 / 200
6 Rollen
6.1 Einleitung
6.1.1 Rollenmodell
HERMES definiert ein Rollenmodell und beschreibt standardisierte Rollen, um ein einheitliches,
organisationsübergreifendes Verständnis zu schaffen. Dabei wird unterschieden zwischen ei-
genständigen Projekten und Projekten, die in einem Programm eingebettet sind. Sämtliche
beschriebenen Rollen sind ausschliesslich HERMES-Rollen.
Das Rollenmodell unterscheidet zwischen den Rollengruppen der Stammorganisation und
den Rollen und Rollengruppen der Projektorganisation. Die Abbildung 26 zeigt das Rollen-
modell einer Stammorganisation mit den Rollengruppen Leitung, Kompetenzzentrum Pro-
jektmanagement sowie Controlling- und Vorgabestellen und einer Projektorganisation (klas-
sisch/agil) mit den minimal erforderlichen Rollen Auftraggeber, Projektleiter und Anwender-
vertreter (grau schattiert). Nach Bedarf werden weitere Rollen verwendet.
Stammorganisation
Kompetenzzentrum Controlling- und
Leitung Projektmanagement Vorgabestellen
Projektorganisation klassisch Projektorganisation agil

(während Phase Umsetzung)
Führung Projektleiter Führung Projektleiter
Ausführung Anwender- Ausführung Anwender- Entwicklungsteam

vertreter vertreter
Schnittstelle zum Entwicklungsteam
Abbildung 26: Stammorganisation sowie Projektorganisation mit minimal erforderlichen Rollen (grau)
Die Rolle Anwendervertreter funktioniert in der agilen Projektorganisation als Schnittstelle

zum Entwicklungsteam. Der Rolleninhaber nimmt durch zusätzliche Übernahme einer ent-
sprechenden proprietären Rolle im Entwicklungsteam seine fachliche Verantwortung wahr
(gestrichelte Linie). Dies ist beim Aufbau der agilen Projektorganisation einschliesslich der Rol-
lengruppe Entwicklungsteam zu beachten.
ROLLEN
6.1.2 Stammorganisation
Die Stammorganisation ist die Organisation des Auftraggebers, in der das Projekt angesiedelt
ist und des späteren Anwenders, bei dem die Nutzung der Lösung stattfinden wird. Sie ist eine
rechtliche Einheit, die Strategien und Vorgaben für Projekte bestimmt. Die Stammorganisation
stellt die benötigten Ressourcen wie z. B. Infrastruktur, Finanzen und Personal für das Projekt
zur Verfügung.
Der Begriff der Stammorganisation wird in HERMES weit gefasst. Eine Stammorganisation
kann z. B. eine Verwaltung, eine Schule oder ein Institut, ein Verein oder eine Unternehmung
sein. Bei staatlichen oder grossen kommunalen Verwaltungen, bei Konzernen, komplexen Fir-
men usw. können auch einzelne Organisationseinheiten, oder sogar auch einzelne Abteilun-
gen die Rolle einer Stammorganisation bekleiden.
140 / 200
Wie die Abbildung 26 zeigt, sind für alle eigenständigen Projekte in der Stammorganisation
drei permanente Rollengruppen relevant:
 Leitung
Portfolio aus strategischer Sicht steuern, Projekte priorisieren und Infrastruktur sowie per-
sonelle und finanzielle Ressourcen dem konkreten Projekt zuweisen.
 Kompetenzzentrum Projektmanagement
Methoden, Hilfsmittel, Coaching und weitere Leistungen für das Projekt- und Programm-
management bereitstellen und weiterentwickeln.
 Controlling- und Vorgabestellen
Vorgaben definieren und die Einhaltung aus Sicht der gesamten Organisation prüfen. Sol-
che Stellen sind beispielsweise die Finanzkontrolle, die Revisionsstelle, das IT-Controlling,
und die zuständigen Stellen für die Lösungsarchitektur und für ISDS.
Je nach Stammorganisation sind die Rollen der aufgeführten Rollengruppen unterschiedlich
ausgeprägt.
6.1.3 Projektorganisation
6.1.3.1 Übersicht
Die Projektorganisation ist eine einmalige, temporäre oft interdisziplinäre Organisation, die in
enger Beziehung zur Stammorganisation steht. Sie wird mit dem Projektinitialisierungsauftrag
in Kraft gesetzt und spätestens mit dem Entscheid Projektabschluss aufgelöst.
Im Verlauf der Projektabwicklung, insbesondere mit dem Durchführungsauftrag, wird die Pro-
jektorganisation kontinuierlich an die Bedürfnisse des Projekts angepasst. Je nach Projektab-
lauf stossen weitere Projektbeteiligte dazu. Beispielsweise steht ein externer Anbieter eines
Produkts erst nach der Beschaffung fest und wird dann Teil der Projektorganisation. Die agile
Projektorganisation hat ihre Gültigkeit ausschliesslich während der Phase Umsetzung. In den
Phasen Initialisierung und Abschluss bleibt die Projektorganisation klassisch, was das Projekt-
team nicht daran hindert, für geeignete Aufgaben agile Techniken einzusetzen.
Die Projektorganisation besteht aus verschiedenen Rollen. Sie regeln Aufgaben, Kompetenzen
und Verantwortung der Projektbeteiligten. Jede Rolle ist mit einer Rollenbeschreibung spezi-
fiziert.
6.1.3.2 Partnergruppen
Jede Rolle ist einer oder mehreren Partnergruppen zugeordnet. In der HERMES-Projektorga-
nisation kommen die Partnergruppen Anwender, Ersteller und Betreiber vor:
 Anwender
Der Anwender ist der Eigner des Projekts sowie der Nutzer der Lösung und wickelt damit
seine Geschäftsprozesse ab. Er ist verantwortlich für die Definition seiner Anforderungen
an die Lösung, testet und nimmt das Produkt/System bzw. die Lösung ab.
 Ersteller
Der Ersteller als Dienstleistungserbringer entwickelt oder liefert und integriert die Lösung.
ROLLEN
Er ist verantwortlich für die Entwicklung bzw. Lieferung und Integration gemäss den Vor-
gaben bezüglich Qualität, Zeit und Kosten.
 Betreiber
Der Betreiber als Dienstleistungserbringer integriert die technische Lösung in die Be-
triebsumgebung, stellt die Betriebsorganisation sicher und betreibt das System. Er ist ver-
antwortlich für die Bereitstellung der Betriebsinfrastruktur, die Betriebsintegration, die Be-
triebsorganisation und den Betrieb gemäss den Vereinbarungen.
Die Projekte werden in der Praxis oft durch Lieferanten oder externe Dienstleister unterstützt.
Insbesondere die Rollen der Partnergruppe Ersteller werden oft durch externe Dienstleister
besetzt. Werden diverse Dienstleistungen der Stammorganisation outgesourct, können z. B.
auch die Betreiber, immer öfters sogar die Anwender (z. B. mittels Projektleiterpools), externe
Dienstleister sein.
141 / 200
Dessen ungeachtet haben die Rolleninhaber stets und ausschliesslich die Rollensicht ihrer
Partnergruppe zu vertreten, um jegliche Interessenkonflikte auszuschliessen. Dies ist insbe-
sondere dann von Bedeutung, wenn z. B. mangels Anwenderkompetenz oder ungenügenden
Projektressourcen bestimmende Rollen des Projekts durch Fachleute anderer Partnergruppen
wahrgenommen werden.
Die Vertretung im Projekt durch partnergruppenfremde Dienstleistungserbringer erfolgt in
eigener Kompetenz und Verantwortung der jeweiligen Partnergruppe der Anwender, Ersteller
oder Betreiber.
6.1.3.3 Hierarchieebenen
Jede Rolle ist einer der Hierarchieebenen Steuerung, Führung oder Ausführung zugeordnet:
 Steuerungsrollen
Projekt gesamthaft, organisationsübergreifend steuern und sicherstellen, dass die gesetz-
ten Ziele erreicht werden.
 Führungsrollen
Projektgrundlagen erarbeiten, Projekt und Mitarbeitende führen.
 Ausführungsrollen
Lösung erarbeiten und qualitätssichernde Massnahmen durchführen.
Die Abbildung 27 zeigt die Zuordnung der Rollen zu den gelb dargestellten Hierarchieebenen
in einer typischen klassischen und agilen Projektorganisation.
Projektorganisation klassisch Projektorganisation agil
(während Phase Umsetzung)
Steuerung Auftraggeber Projektausschuss Steuerung Auftraggeber Projektausschuss
Qualitäts- und Qualitäts- und

Risikomanager Risikomanager
Führung Projektleiter Fachausschuss Führung Projektleiter
Projekt- Projekt-
unterstützung unterstützung
Ausführung Ausführung
Anwender- Entwickler weitere Anwender- Entwicklungs-

vertreter Fachspezialisten vertreter team
Abbildung 27: Rollenzuordnung zu Hierarchieebenen einer klassischen oder agilen Projektorganisation
6.1.3.4 Projektrollen in Programmen

Projektsicht
Die Erweiterung des Projektmanagements durch das Programmmanagement wird im Anhang
zum vorliegenden Referenzhandbuch thematisiert. Die nachfolgenden Ausführungen be-
trachten das Programmmanagement aus der Projektperspektive.
ROLLEN
Programme
Das (dreiphasige) HERMES-Phasenmodell für Programme ist eine Voraussetzung für die In-
tegration der Projekte im Programm (s. Abbildung 28). Programme umfassen mehrere Pro-
jekte, die ein gemeinsames Ziel verfolgen und zeitlich überlappt durchgeführt werden. Das
Programm sichert die projektübergreifende Steuerung und Führung der Projekte. Das Pha-
senmodell für Projekte erleichtert die Koordination und Steuerung der Projekte in einem Pro-
gramm.
142 / 200
Programminitialisierung Programmdurchführung Programmabschluss
Abbildung 28: Projekte zu Programmen zusammengefasst
Der Programmauftraggeber steuert das Programm. Je nach Programmorganisationsform (vgl.

Abbildung 29) führt der Programmleiter das Programm und koordiniert die projektübergrei-
fenden Aspekte und die Abhängigkeiten zwischen den Projekten. Der Projektleiter führt sein
Projekt. Der Anwendervertreter definiert die Lösung.
Die Steuerung des Projekts kann über einen Projektausschuss (unter Leitung des Auftragge-
bers) und/oder übergeordnet durch einen Programmausschuss (unter Leitung des Pro-
grammauftraggebers) unterstützt werden. Aus Sicht der Controlling- und Vorgabestellen ist
jedes einzelne Projekt ein eigenständiges Controlling-Objekt mit Vorgaben bezüglich Kosten,
Zeit und Ergebnissen.
Die Programphase Programabschluss kann erst dann freigegeben werden, wenn alle Projekte
abgeschlossen sind.
Organisationsformen
Wird ein Projekt Teil eines Programms, muss die Projektorganisation in die Programmorgani-
sation integriert und verschiedene Rollen der Projektorganisation angepasst oder ersetzt wer-
den. Betroffen sind primär die Rollen des Auftraggebers und des Projektleiters. Je nach ge-
wählter Organisationsform für das Programm sind die Anpassungen unterschiedlich. Die Aus-
wirkungen spielen sich vorwiegend im Steuerungs-, Führungs- und Kontrollbereich ab.
Die für das Programm angepassten Rollenbeschreibungen werden im Projektmanagement-
plan aufgeführt.
Die Darstellung in der Abbildung 29 zeigt schematisch drei denkbare Organisationsformen:
eine als eigenständiges Projekt und zwei als Teile eines Programms.
Projektorganisation Programmorganisation 1 Programmorganisation 2
Stammorganisation
Programm- Programm- Steuerung
auftraggeber auftraggeber
Programmleiter
Steuerung Führung
Auftraggeber Auftraggeber Programmleiter
ROLLEN
Führung Projektleiter Projektleiter Projektleiter
Ausführung Anwendervertreter Anwendervertreter Anwendervertreter Ausführung

Projekt Projekt Projekt
Abbildung 29: Drei mögliche Grundvarianten der Projektorganisation
Die minimal zu besetzenden Rollen im Projekt sind grau dargestellt. Programmspezifische

Rollen sind blau umrandet und werden hier nicht weiter erläutert.
143 / 200
Die nachfolgende Beschreibung erläutert die drei in der Abbildung 29 dargestellten Organi-
sationsformen aus Projektsicht. Sie ist rudimentär und dient lediglich dem Allgemeinverständ-
nis.
Projektorganisation
Eine bestimmte Stammorganisation verantwortet den Erfolg des Projekts:
 der Auftraggeber ist verantwortlich für den Erfolg des Projekts und steuert das Projekt;
 der Projektleiter führt das Projekt im Auftrag des Auftraggebers;
 der Anwendervertreter verantwortet die Lösung.
Programmorganisation 1
Mehrere Stammorganisationen verantworten den Erfolg der ihnen zugeordneten Projekte:
 der Programmleiter führt und koordiniert das Projekt und den Projektleiter aus der über-
geordneten Programmsicht und stimmt sich mit dem Auftraggeber laufend ab;
 der Auftraggeber ist verantwortlich für den Erfolg seines Projekts, wahrt die interessen
seiner Stammortganisation, steuert das Projekt im Auftrag des Programmauftraggebers
und behandelt und löst mit ihm aufkommende Interessenkonflikte zwischen Programm-
zielen und denen seiner Stammorganisation;
 der Projektleiter führt das Projekt im Auftrag des Auftraggebers, führt die programmspe-
zifischen Anweisungen des Programmleiter aus und stimmt den Projektmanagementplan
mit dem Programmleiter ab;
Diese Art der Programmorganisation verändert die Rollen des Auftraggebers und des Pro-
jektleiters. Der Auftraggeber rapportiert sowohl der eigenen Stammorganisation als auch dem
Programmauftraggeber und muss im Rahmen seiner Entscheide beide Instanzen entspre-
chend berücksichtigen. Der Projektleiter wird durch den Programmleiter koordiniert.
Programmorganisation 2
Eine bestimmte Stammorganisation verantwortet den Erfolg des Programms und aller daran
beteiligten Projekte:
 der Programmleiter (aus der Sicht des Projektes in der Hierarchieebene Steuerung, aus
jener des Programms in der Hierarchieebene Führung) steuert das Projekt und führt (siehe
Rollenbeschreibung Auftraggeber) den Projektleiter, die Verantwortung für den Projekt-
erfolg obliegt hingegen dem Programmauftraggeber;
 der Projektleiter führt das Projekt im Auftrag des Programmleiters und stimmt mit ihm den
Projektmanagementplan ab;
Diese Art der Programmorganisation verzichtet auf der Projektebene auf den Auftraggeber
und ersetzt ihn durch den Programmleiter. Er übernimmt alle Aufgaben und Pflichten des
Auftraggebers innerhalb eines Projekts. Der Projektleiter ist somit einem Programmleiter un-
terstellt, der in der Projektorganisation der Hierarchieebene Steuerung, in der Programmor-
ROLLEN
ganisation der Ebene Führung zugeordnet ist.
6.2 Übersicht der Rollen

6.2.1 Standardrollen
Die folgende Tabelle listet alle standardmässig vorgesehenen Rollen auf und zeigt deren Zu-
ordnung zur Hierarchieebene und zur Partnergruppe.
144 / 200
Hierarchieebene Rolle Anwender Ersteller Betreiber
* = minimal zu besetzende Rollen
Steuerung Steuerungsrollen X X X
Auftraggeber* X
Projektausschuss X X X
Qualitäts- und Risikomanager X
Führung Führungsrollen X X X
Projektleiter* X
Teilprojektleiter X
Projektunterstützung X X
Fachausschuss X X X
Ausführung Ausführungsrollen X X X
Anwendervertreter* X
Betriebsverantwortlicher X
Business Analyst X X
Entwickler X
Entwicklungsteam X X X
ISDS-Verantwortlicher X
IT-Architekt X X X
Tester X X X
Testverantwortlicher X X X
Tabelle 19: Rollen und deren Zuordnung zur Hierarchieebene und zur Partnergruppe
Die mit einem Stern (*) markierten minimal zu besetzenden Rollen werden benötigt, um die
Anforderungen der Governance zu erfüllen. Die drei markierten Rollen sind für das Projekt,
ungeachtet der gewählten Vorgehensweise (klassisch oder agil), unentbehrlich und sind zwin-
gend in der Partnergruppe Anwender angesiedelt. Sie müssen in jedem Projekt besetzt sein:
 Der Auftraggeber hat die Gesamtverantwortung für das Vorhaben und das Erreichen der
Ziele.
 Der Projektleiter hat die alleinige Führungsverantwortung, bei agiler Lösungsentstehung
darf er jedoch nicht in die Selbstorganisation des Entwicklungsteams eingreifen.
 Der Anwendervertreter verantwortet die Produkt- beziehungsweise die fachliche Lösungs-
entstehung.
Weitere zwingend zu besetzende Rollen werden abhängig von den Projektanforderungen zu-
gewiesen.
Die Ausführungsrollen, in Organigrammen mit Ausnahme des Anwendervertreters summa-
risch auch als Fachspezialisten bezeichnet, sind zahlreich und nicht abschliessend aufgeführt.
Je nach Stammorganisation, oder der Art eines Vorhabens können weitere projektspezifische
Ausführungsrollen dazukommen.
Bei agiler Vorgehensweise werden während der Phase Umsetzung alle am Vorhaben beteilig-
ten Ausführungsrollen im Entwicklungsteam zusammengefasst. Die Rolle Entwicklungsteam
ist eine Rollengruppe.
ROLLEN
6.2.2 Individuelle Rollen

Ergänzend zu den standardmässig bereitgestellten Rollen besteht die Möglichkeit, eigene
fach-, organisations- oder vorhabenspezifische Rollen in eigene Projekte zu integrieren. Dies
wird durch HERMES-Online unterstützt und kommt insbesondere dann zum Tragen, wenn
neue Module entwickelt und mit neuen Aufgaben und Ergebnissen versehen werden. Bei-
spiele von individuellen Rollen sind Integrationsmanager, Logistiker, Immobilienverwalter, Ein-
käufer oder Facility Manager.
6.2.3 Rollenbesetzung
6.2.3.1 Allgemeine Erläuterungen
Für jede im Projekt benötigte Rolle wird die Rollenbesetzung festgelegt.
145 / 200
Die Rollenbesetzung erfolgt gemäss den Projektanforderungen. Sie berücksichtigt die im Pro-
jekt erforderliche Erfahrung, die benötigte Kapazität und die Verfügbarkeit der Rolleninhaber.
Die konkrete Projektorganisation und die Rollenbesetzung werden im Projektmanagement-
plan festgehalten.
Bei der Rollenbesetzung müssen die folgenden Grundsätze beachtet werden, damit die Pro-
jekt-Governance eingehalten werden kann:
 Eine Person kann mehrere Rollen wahrnehmen, sofern dadurch keine Interessenkonflikte
entstehen.
 Eine Rolle kann von mehreren Personen wahrgenommen werden, sofern die Rolle eine
Mehrfachbesetzung zulässt. Es gibt z. B. meistens mehrere Tester in einem Projekt, jedoch
nur einen Auftraggeber.
Nachfolgend sind Hinweise zur Rollenbesetzung einiger Rollen der Hierarchieebenen Steue-
rung, Führung und Ausführung aufgeführt.
6.2.3.2 Steuerung
Auftraggeber
 Der Auftraggeber muss beim Anwender angesiedelt sein.
 Der Auftraggeber muss eine einzige natürliche Person aus der Stammorganisation sein.
 Der Auftraggeber initialisiert, finanziert und steuert das gesamte Vorhaben.
 Der Auftraggeber muss das Projekt in der Führung der Stammorganisation und den Con-
trolling- und Vorgabestellen vertreten und in der Stammorganisation hierarchisch ent-
sprechend hoch angesiedelt sein.
 Der Auftraggeber stellt sicher, dass die für den Projekterfolg massgebenden, vom Projekt-
leiter identifizierten Stakeholder im Projekt vertreten sind.
 Die Rollen Auftraggeber und Projektleiter dürfen nicht durch dieselbe Person besetzt wer-
den.
Projektausschuss
 Der Auftraggeber bestimmt die Mitglieder des Projektausschusses.
 Für den Projekterfolg relevante Organisationen sind im Projektausschuss vertreten.
 Der Auftraggeber legt das Stimmrecht der Mitglieder des Projektausschusses fest.
Qualitäts- und Risikomanager
 Je nach Projektgrösse und Risiken beauftragt der Auftraggeber eine Stelle mit dem Qua-
litäts- und Risikomanagement. Sie rapportiert direkt an den Auftraggeber.
 Die unabhängige Organisation, die den Qualitäts- und Risikomanager stellt, übernimmt
keine weiteren Rollen im Projekt und muss die Unabhängigkeit des Mandats sicherstellen.
6.2.3.3 Führung
Projektleiter
ROLLEN
 Der Auftraggeber bestimmt den Projektleiter.

 Der Projektleiter muss beim Anwender angesiedelt sein und ausschliesslich dessen Inte-
ressen im Projekt vertreten. Dies gilt auch dann, wenn der Rolleninhaber organisatorisch
anderweitig unterstellt oder angesiedelt ist (z. B. externe Rekrutierung oder Poolorganisa-
tion). Auf eine Bereitstellung durch Partnergruppen Ersteller oder Betreiber sollte aufgrund
von potenziellen Interessenkonflikten sowie wegen der Sicherstellung der Governance
verzichtet werden.
 Der Projektleiter führt das Projekt und verantwortet den reibungslosen Projektablauf in-
klusive aller Teilprojekte.
 Der Projektleiter kann zugleich ein Teilprojektleiter sein.
 Übernimmt der Projektleiter zusätzlich eine Ausführungsrolle, muss durch den Auftragge-
ber sichergestellt werden, dass genügend Kapazität für die Projektleitung zur Verfügung
steht.
146 / 200
Teilprojektleiter
 Der Projektleiter bestimmt den Teilprojektleiter.
 Der Teilprojektleiter muss beim Anwender angesiedelt sein und ausschliesslich dessen In-
teressen im Projekt vertreten. Dies gilt auch dann, wenn der Rolleninhaber organisatorisch
anderweitig unterstellt oder angesiedelt ist. Eine Bereitstellung durch Partnergruppen Er-
steller oder Betreiber kann in Betracht gezogen werden (die Gesamtverantwortung obliegt
dem Projektleiter).
 Der Teilprojektleiter führt das Teilprojekt und verantwortet den reibungslosen Projektab-
lauf gegenüber dem Projektleiter.
 Übernimmt der Teilprojektleiter zusätzlich eine Ausführungsrolle, muss durch den Projekt-
leiter sichergestellt werden, dass genügend Kapazität für die Teilprojektleitung zur Verfü-
gung steht.
6.2.3.4 Ausführung
Generell
Die Verantwortung, Kompetenzen und Fähigkeiten aller Ausführungsrollen bleiben unabhän-
gig davon, ob die Rollen in einem Projektteam, oder in einem Teilprojektteam mitwirken, stets
unverändert.
Anwendervertreter
 Der Auftraggeber bestimmt den Anwendervertreter.
 Der Anwendervertreter muss beim Anwender angesiedelt sein. Auf eine Bereitstellung
durch Ersteller oder Betreiber sollte aufgrund von potenziellen Interessenkonflikten ver-
zichtet werden.
 Der Anwendervertreter verantwortet die fachliche Ausgestaltung der Lösung.
 Übernimmt der Anwendervertreter zusätzlich eine weitere Ausführungsrolle, muss durch
den Auftraggeber sichergestellt werden, dass genügend Kapazität für die Anwenderver-
tretung zur Verfügung steht.
 Richtet sich bei der Erarbeitung der Lösung nach den zugeteilten Ressourcen aus.
Business Analyst
 Der Business Analyst kann aufgrund seiner Kenntnisse zusätzlich die Rolle des Anwender-
vertreters übernehmen. Dies setzt jedoch fundierte Kenntnisse des betreffenden Fachbe-
reichs voraus, für den die Lösung erarbeitet wird.
Tester
 Jede im Projekt vertretene Partnergruppe (Anwender, Ersteller, Betreiber) testet in ihrem
Verantwortungsbereich.
Testverantwortlicher
 Jede im Projekt vertretene Partnergruppe (Anwender, Ersteller, Betreiber) kann in ihrem
Verantwortungsbereich einen Testverantwortlichen einsetzen.
ROLLEN
6.3 Erläuterung der Rollenbeschreibung

Die Rollen beschreiben die Verantwortung, die Kompetenz und die benötigten Fähigkeiten
der Projektbeteiligten. Sie bilden die Grundlage für ein gemeinsames Verständnis. Die Rollen
sind bestimmten Aufgaben und Ergebnissen zugeordnet.
Für jede Rolle gibt es eine Rollenbeschreibung, die stets gleich strukturiert ist:
 Beschreibung
vermittelt das Verständnis der Rolle.
 Verantwortung
beschreibt, sofern zutreffend, die Verantwortung der Rolle.
 Kompetenzen
beschreiben, sofern zutreffend, die Befugnisse der Rolle.
147 / 200
 Fähigkeiten
beschreiben, welche Kenntnisse eine Person benötigt, um die Rolle wahrnehmen zu kön-
nen. Bei der Beschreibung der Fähigkeiten wird bewusst nicht zwischen Kenntnissen und
Erfahrung unterschieden, da der Grad der benötigten Fähigkeiten stark vom Projekt ab-
hängig ist.
 Beziehungen (sofern relevant)
zeigen pro Modul, für welche konkreten Aufgaben die Rolle verantwortlich ist und welche
weitere Rollen an der Ergebniserstellung beteiligt sind. Hat die Rolle keine Aufgabenver-
antwortung, werden Beziehungen nicht aufgeführt.
o Die für die Aufgabe verantwortliche Rolle trägt auch die Verantwortung für die
Erarbeitung der Ergebnisse und für die Ergebnisse selbst.
o Die an der Erarbeitung beteiligten Rollen sind nicht abschliessend und müssen pro-
jektspezifisch festgelegt werden.
6.4 Beschreibung der Rollen

6.4.1 Steuerungsrollen
6.4.1.1 Auftraggeber
Beschreibung
Der Auftraggeber ist verantwortlich für die Ergebnisse des Projekts und die Erreichung der
gesetzten Ziele innerhalb der gesetzten Rahmenbedingungen.
Verantwortung
 Initiieren und Steuern des Vorhabens
 Gesamtverantwortung für das Vorhaben und das Erreichen der Ziele
 Abstimmung der Ziele mit den übergeordneten Strategien, Vorgaben und Zielen der
Stammorganisation
 Bereitstellen der Ressourcen und Sicherstellen des wirtschaftlichen Einsatzes (finanziell,
personell, Infrastruktur)
 Rechtzeitige Entscheidungen über Anträge und Massnahmen
 Bestimmen der Mitglieder des Projektausschusses und Führen des Projektausschusses
 Bestimmen und Steuern des Projektleiters, Festlegen seiner Kompetenzen
 Ausreichende Mitwirkung des Fachbereichs sicherstellen
Kompetenzen
 Entscheidungskompetenz im Rahmen der Kompetenzordnung durch die Stammorganisa-
tion
 Zuteilung finanzieller und personeller Ressourcen sowie der Infrastruktur für das Projekt
 Eskalation zur Stammorganisation
ROLLEN
Fähigkeiten
 Geschäftsverständnis und Kenntnisse im Fachbereich
 Kenntnisse der Vorgaben der Stammorganisation an das Projekt (z. B. für Beschaffungen,
Finanzierung, Controlling, Sicherheit), an die Projektsteuerung und an die Projektorgani-
sation
 Betriebswirtschaftliche Kenntnisse zur Sicherstellung des effizienten und effektiven Einsat-
zes der finanziellen und personellen Ressourcen
 Vertiefte Kenntnisse der Projektinitialisierung und Projektsteuerung
 Kenntnisse von HERMES, nachgewiesen durch einen Kursbesuch
 Kommunikationsfähigkeit, um das Projekt gegen innen und aussen zu vertreten, die Sta-
keholder zu managen und Konflikte zu lösen
 Entscheidungsfreudigkeit und Durchsetzungsvermögen
148 / 200
Beziehungen
Modul Aufgabe Ergebnis Beteiligt an der
Ergebniserstellung
Projektsteuerung Entscheid Projektinitiali- Checkliste Projektinitiali- Auftraggeber, Projektleiter
sierungsfreigabe treffen sierungsfreigabe
Projektinitialisierungsauf- Auftraggeber, Projektleiter
trag
Meilenstein Projektinitia- Auftraggeber, Projektleiter
lisierungsfreigabe
Liste Projektentscheide Auftraggeber, Projektleiter
Steuerung
Entscheid Durchfüh- Checkliste Durchfüh- Auftraggeber, Projektleiter, Qualitäts- und Risiko-
rungsfreigabe treffen rungsfreigabe manager
Durchführungsauftrag Auftraggeber, Projektleiter, Anwendervertreter
Meilenstein Durchfüh- Auftraggeber, Projektleiter, Projektausschuss
rungsfreigabe
Steuerung
Projekt steuern QS- und Auftraggeber, Qualitäts- und
Risikobericht Risikomanager
Liste Projektentscheide Auftraggeber, Projektleiter, Projektausschuss
Steuerung
Entscheid Phasenfrei- Checkliste Phasenfrei- Auftraggeber, Projektleiter, Qualitäts- und Risiko-
gabe treffen gabe manager
QS- und Risikobericht Auftraggeber, Qualitäts- und Risikomanager
Meilenstein Phasenfrei- Auftraggeber, Projektleiter, Projektausschuss, An-
gabe wendervertreter
Steuerung
Entscheid Releasefrei- Checkliste Releasefrei- Auftraggeber, Projektleiter, Anwendervertreter,
gabe treffen gabe Qualitäts- und Risikomanager
Meilenstein Releasefrei- Auftraggeber, Projektleiter, Projektausschuss, An-
gabe wendervertreter
Steuerung
Entscheid Projektabbruch Checkliste Projektab- Auftraggeber, Projektleiter, Anwendervertreter,
treffen bruch Qualitäts- und Risikomanager
Projekterfahrungen Auftraggeber, Projektleiter, Anwendervertreter
Projektschlussbeurtei- Auftraggeber, Projektleiter
lung
Meilenstein Projektab- Auftraggeber, Projektleiter, Anwendervertreter,
schluss Projektausschuss
Steuerung
Entscheid Phasenfrei- Checkliste Phasenfrei- Auftraggeber, Projektleiter, Qualitäts- und Risiko-
gabe Abschluss treffen gabe Abschluss manager
ROLLEN
Meilenstein Phasenfrei- Auftraggeber, Projektleiter, Projektausschuss, An-

gabe Abschluss wendervertreter
Steuerung
Entscheid Projektab- Checkliste Projektab- Auftraggeber, Projektleiter, Qualitäts- und Risiko-
schluss treffen schluss manager
Meilenstein Projektab- Auftraggeber, Projektleiter, Projektausschuss
schluss
Steuerung
149 / 200
Ergebniserstellung
Beschaffung Entscheid Ausschreibung Checkliste Ausschreibung Auftraggeber, Projektleiter, Anwendervertreter,
treffen Qualitäts- und Risikomanager
Meilenstein Ausschrei- Auftraggeber, Projektleiter, Projektausschuss, An-
bung wendervertreter
Steuerung
Entscheid Zuschlag Checkliste Zuschlag Auftraggeber, Projektleiter, Anwendervertreter,
treffen Qualitäts- und Risikomanager
Publikation Auftraggeber, Projektleiter
Meilenstein Zuschlag Auftraggeber, Projektleiter, Projektausschuss, An-
wendervertreter
Steuerung
Einführungsorga- Entscheid Betriebsauf- Checkliste Betriebsauf- Auftraggeber, Projektleiter, Qualitäts- und Risiko-
nisation nahme treffen nahme manager
Meilenstein Betriebsauf- Auftraggeber, Projektleiter, Projektausschuss
nahme
Steuerung
Tabelle 20: Aufgaben, die der Auftraggeber verantwortet und weitere an der Ergebniserstellung beteiligte Rollen
6.4.1.2 Projektausschuss
Beschreibung
Der Projektausschuss ist eine Rollengruppe. Die Mitglieder des Projektausschusses unterstüt-
zen den Auftraggeber in seinen Aufgaben und bringen die Anliegen der Organisation, die sie
vertreten, in den Ausschuss ein. Der Auftraggeber organisiert und leitet die Sitzungen des
Projektausschusses.
Verantwortung
 Beratung und Unterstützung des Auftraggebers in seinen Aufgaben
 Unterstützung und Verankerung des Projekts in der Organisation, die das Mitglied des
Projektausschusses vertritt
 Frühzeitiges Einbringen von Anliegen der vertretenen Organisation
 Mitwirkung bei der Erarbeitung von Problemlösungen
Kompetenzen
 Kann einen Projektreview oder ein Projektaudit beantragen
 Empfehlungskompetenz:
o Empfehlungen zu Abschluss und Freigabe von Phasen an den Auftraggeber
o Empfehlungen zu risikominimierenden Massnahmen (z. B. zur Einsetzung des Projekt-
controllings oder des Qualitäts- und Risikomanagers) an den Auftraggeber
 Kann alle für die Steuerung und Beurteilung des Projekts benötigten Informationen ein-
holen
ROLLEN
 Kann an Abstimmungen mitwirken, sofern er stimmberechtigt ist

Fähigkeiten
 Kenntnisse im Fachbereich
 Vertiefte Kenntnisse im Spezialgebiet, das vertreten wird
 Betriebswirtschaftliche Kenntnisse zur Sicherstellung des effizienten und effektiven Einsat-
zes der finanziellen und personellen Ressourcen
 Vertiefte Kenntnisse in der Projektsteuerung
 Kenntnisse von HERMES, idealerweise mittels eines Kursbesuchs
 Team-, Kommunikations- und Konfliktlösungsfähigkeit
150 / 200
6.4.1.3 Qualitäts- und Risikomanager
Beschreibung
Der Qualitäts- und Risikomanager unterstützt den Auftraggeber mit einer unabhängigen Be-
urteilung des Projekts. Er gibt Empfehlungen für Massnahmen zur Erreichung der Ziele ab.
Verantwortung
 Beurteilung der Einhaltung der Vorgaben der Stammorganisation
 Beurteilung des Vorgehens und der Ergebnisse des Projektmanagements, der Projektor-
ganisation und der Zusammenarbeit im Projekt
 Umfassende Beurteilung der Prozesse der Projektsteuerung, Projektführung und Projek-
tabwicklung bei allen Projektbeteiligten
 Beurteilung der Projektergebnisse aus qualitativer Sicht
 Beurteilung des Projektstands und der Prognosen
 Beurteilung der Risiken
 Empfehlung von Massnahmen zum Umgang mit Risiken und zur Erreichung der gesetzten
Ziele
 Transparente Berichterstattung an den Auftraggeber
Kompetenzen
 Empfehlungen zu Abschluss und Freigabe von Phasen an den Auftraggeber
 Empfehlungen zu Massnahmen an den Auftraggeber
 Kann alle für die Beurteilung des Projekts benötigten Informationen einholen (mit direk-
tem Zugang zu allen Projektbeteiligten)
Fähigkeiten
 Vertiefte Kenntnisse im Projektmanagement, im Besonderen in Bezug auf die Aspekte
Controlling, Qualitätssicherung und Risikomanagement
 Betriebswirtschaftliche Kenntnisse
 Vertiefte Kenntnisse von HERMES, nachgewiesen durch ein Zertifikat
 Gute schriftliche Ausdrucksfähigkeit, um z. B. Berichte zu erstellen
6.4.2 Führungsrollen
6.4.2.1 Fachausschuss
Beschreibung
Der Fachausschuss ist eine Rollengruppe, die beim klassischen Vorgehen den Projektleiter
durch die Beurteilung von Ergebnissen unterstützt.
Die Mitglieder des Fachausschusses bringen die Anliegen der Organisationseinheit ein, die sie
vertreten. Der Projektleiter organisiert und leitet die Sitzungen des Fachausschusses.
ROLLEN
Verantwortung
 Beratung und Unterstützung des Projektleiters bei der Beurteilung von fachlichen Frage-
stellungen und Ergebnissen
 Unterstützung und Verankerung des Projekts in der von ihm vertretenen Organisation
 Frühzeitiges Einbringen von Anliegen der vertretenen Organisation
151 / 200
Kompetenzen
 Empfehlungen zu Ergebnissen zuhanden des Projektleiters abgeben
 Empfehlungen zu qualitätssichernden Massnahmen zuhanden des Projektleiters abgeben
 Kann auf alle benötigten Informationen zugreifen
Fähigkeiten
 Vertiefte Kenntnisse im Fachbereich und im vertretenen Spezialgebiet
 Betriebswirtschaftliche Kenntnisse für die Bewertung und Priorisierung der Anforderungen
und die Beurteilung von Varianten sowie der Wirtschaftlichkeit
6.4.2.2 Projektleiter
Beschreibung
Der Projektleiter führt das Projekt im Auftrag des Auftraggebers. Er führt und koordiniert das
Projekt unabhängig von der fachlichen Ausrichtung der Lösung und des gewählten Entwick-
lungsvorgehens.
Verantwortung
 Führung des Projekts zur Erreichung der gesetzten Ziele (Zeit, Kosten, Qualität) und Vor-
gehensziele
 Wirtschaftlicher und nachhaltiger Einsatz der Ressourcen
 Führung des Berichtswesens und umfassende, regelmässige und situative Information der
Projektsteuerung, damit sie ihre Steuerungs- und Entscheidungsaufgaben wahrnehmen
kann
 Identifizierung von Stakeholdern, Rekrutierung dieser für das Projekt und Analysierung
deren Grundinteressen
 Führung des Qualitäts- und Risikomanagements
 Sicherstellung des rechtzeitigen Einbezugs von zuständigen Controlling- und Vorgabe-
stellen, damit ihre berechtigten Anforderungen erfüllt werden
 Regelung der im Projekt ergänzend zu HERMES einzusetzenden Methoden, Praktiken und
Werkzeuge und Sicherstellung ihrer Anwendung
 Umsetzen der Entscheide Steuerung und Führung
 Durchführung von Beschaffungen unter Einhaltung der Vorgaben
 Überprüfung der Einhaltung des SLAs (Dienstleistungsniveau Vereinbarung) durch die
Vertragspartner im Projekt
Kompetenzen
 Kann auf alle Projektinformationen zugreifen
 Kompetenz bezüglich des Einsatzes der freigegebenen Ressourcen
 Alleinige Projektführungsverantwortung und Anordnungskompetenz, ohne während der
agilen Vorgehensweise in die Selbstorganisation des Entwicklungsteams einzugreifen
ROLLEN
 Entscheidungskompetenz im mit dem Auftraggeber definierten Rahmen

 In Absprache mit dem Auftraggeber:
o Projekt in Teilprojekte aufteilen,
o Teilprojektleiter bestimmen und
o Führungsaufgaben delegieren.
Fähigkeiten
 Kenntnisse des Projektumfelds
 Kenntnisse der Vorgaben der Stammorganisation an das Projekt und an den Betrieb der
Anwendung (z. B. für Beschaffungen, Finanzierung, Controlling, Sicherheit) oder an die
Anwendung des Produkts
 Vertiefte Kenntnisse in Projektmanagement (Hauptkriterium)
 Gute Kenntnisse der im Projekt angewendeten Methoden und Praktiken
152 / 200
 Betriebswirtschaftliche Kenntnisse für die Beurteilung von Varianten und Wirtschaftlichkeit
sowie für die Sicherstellung des effizienten und effektiven Einsatzes der finanziellen und
personellen Ressourcen
 Führungskompetenz
 Kommunikationsfähigkeit,
o um das Projekt gegen innen und aussen zu vertreten;
o um die Stakeholder zu managen und Konflikte zu lösen;
o um stufengerecht kommunizieren zu können (z. B. bei Präsentationen im Projektaus-
schuss, vor Gremien der Stammorganisation, usw.)
 Gute schriftliche Ausdrucksfähigkeit, um z. B. Projektberichte zu erstellen
Beziehungen
Ergebniserstellung
Projektführung Projekt führen und kon- Projektmanagementplan Projektleiter
trollieren
Arbeitsauftrag Projektleiter, Anwendervertreter, Projektunterstüt-
zung
Projektstatusbericht Projektleiter, Projektunterstützung
Protokoll Projektleiter, Anwendervertreter, Projektunterstüt-
zung
Lösungsanforderungen Projektleiter, Anwendervertreter
Detailspezifikation Projektleiter, Anwendervertreter
Stakeholder managen Stakeholderliste Projektleiter, Auftraggeber, Business Analyst, Pro-
und informieren jektunterstützung
Stakeholderinteressen Projektleiter, Anwendervertreter
Projektmanagementplan Projektleiter, Auftraggeber
Projektmanagementplan Projektmanagementplan Projektleiter, Auftraggeber
erarbeiten
Durchführungsauftrag Durchführungsauftrag Projektleiter, Anwendervertreter, Projektunterstüt-
erarbeiten zung
Änderungen managen Änderungsantrag Projektleiter, Anwendervertreter, Business Analyst,
Projektunterstützung
Änderungsstatusliste Projektleiter, Anwendervertreter, Projektunterstüt-
zung
Projektmanagementplan Projektleiter
Lösungsanforderungen Projektleiter, Anwendervertreter
Leistungen vereinbaren Offertanfrage Projektleiter, Projektunterstützung
und steuern
Angebot Projektleiter, Projektunterstützung
Evaluationsbericht Projektleiter, Anwendervertreter, Projektunterstüt-
zung
Vereinbarung Projektleiter, Auftraggeber, Projektunterstützung
Probleme behandeln und Projekterfahrungen Projektleiter, Auftraggeber, Anwendervertreter
Erfahrungen nutzen
ROLLEN
Qualitätssicherung füh- Projektmanagementplan Projektleiter

ren
Prüfprotokoll Projektleiter, Anwendervertreter, Projektunterstüt-
zung
Risiken managen Projektmanagementplan Projektleiter
153 / 200
Ergebniserstellung
Phasenfreigabe vorberei- Phasenbericht Projektleiter, Anwendervertreter, Projektunterstüt-
ten zung
Releaseabschluss vorbe- Releasebericht Projektleiter, Anwendervertreter, Projektunterstüt-
reiten zung
Projektabschluss vorbe- Projekterfahrungen Projektleiter, Auftraggeber, Anwendervertreter
reiten
Projektschlussbeurtei- Projektleiter, Projektunterstützung
lung
Projektgrundla- Rechtsgrundlagenanalyse Rechtsgrundlagenanalyse Projektleiter, Projektunterstützung
gen erarbeiten
Studie erarbeiten Studie Projektleiter, Anwendervertreter, Business Analyst,
IT-Architekt, Projektunterstützung
Stakeholderliste Projektleiter, Auftraggeber, Anwendervertreter, Bu-
siness Analyst, Projektunterstützung
Entscheid Weiteres Vor- Checkliste Weiteres Vor- Projektleiter, Anwendervertreter, Qualitäts- und Ri-
gehen treffen gehen sikomanager, Projektunterstützung
Studie Projektleiter, Anwendervertreter, Projektunterstüt-
zung
Meilenstein Weiteres Projektleiter, Anwendervertreter
Vorgehen
Liste Projektentscheide Projektleiter, Anwendervertreter, Projektunterstüt-
Führung zung
Produkt Entscheid Produktkon- Checkliste Produktkon- Projektleiter, Qualitäts- und Risikomanager, Pro-
zept treffen zept jektunterstützung
Meilenstein Produktkon- Projektleiter, Anwendervertreter
zept
Liste Projektentscheide Projektleiter, Projektunterstützung
Führung
IT-System Entscheid Lösungsarchi- Checkliste Lösungsarchi- Projektleiter, Qualitäts- und Risikomanager, Pro-
tektur treffen tektur jektunterstützung
Meilenstein Lösungsar- Projektleiter, Anwendervertreter
chitektur
Führung
Beschaffung Ausschreibung durchfüh- Angebot Projektleiter, Anwendervertreter, Betriebsverant-
ren wortlicher, Entwickler
Ausschreibungsunterla- Projektleiter, Anwendervertreter, Projektunterstüt-
gen zung
Vereinbarung erarbeiten Vereinbarung Projektleiter, Auftraggeber, Anwendervertreter
Einführungsorga- Entscheid Vorabnahme Checkliste Vorabnahme Projektleiter, Qualitäts- und Risikomanager, Pro-
nisation treffen jektunterstützung
Abnahmeprotokoll Projektleiter, Anwendervertreter, Betriebsverant-
wortlicher, Entwickler, Qualitäts- und Risikomana-
ROLLEN
ger, Projektunterstützung
Meilenstein Vorabnahme Projektleiter, Anwendervertreter
Führung zung
154 / 200
Ergebniserstellung
Entscheid Abnahme tref- Checkliste Abnahme Projektleiter, Qualitäts- und Risikomanager, Pro-
fen jektunterstützung
Meilenstein Abnahme Projektleiter, Anwendervertreter
Führung zung
IT-Migration Entscheid Abnahme Mig- Checkliste Abnahme Projektleiter, Qualitäts- und Risikomanager, Pro-
ration treffen Migration jektunterstützung
Meilenstein Abnahme Projektleiter, Anwendervertreter
Migration
Führung zung
ISDS Entscheid ISDS-Konzept Checkliste ISDS-Konzept Projektleiter, Qualitäts- und Risikomanager, Pro-
treffen jektunterstützung
Meilenstein ISDS-Kon- Projektleiter, Anwendervertreter
zept
Führung
Tabelle 21: Aufgaben, die der Projektleiter verantwortet und weitere an der Ergebniserstellung beteiligte Rollen
6.4.2.3 Projektunterstützung
Beschreibung
Die Projektunterstützung hilft dem Projektleiter in organisatorischen und administrativen Be-
langen. Die Rolle wird auch als Project Office (PO) bezeichnet.
Verantwortung
 Verantwortung der an die Rolle delegierten Aktivitäten
Kompetenzen
 Kann im Rahmen der an die Rolle delegierten Aktivitäten:
o Informationen einfordern, erteilen, aufbereiten und bereitstellen
o Anordnungen treffen
Fähigkeiten
 Vertiefte Kenntnisse in Projektmanagement
 Kenntnisse der in seinen Aufgaben anzuwendenden Methoden und Praktiken
 Betriebswirtschaftliche Kenntnisse
ROLLEN

 Gute schriftliche Ausdrucksfähigkeit und Fähigkeit zur Erstellung von Dokumentationen
6.4.2.4 Teilprojektleiter
Beschreibung
Der Teilprojektleiter trägt die Verantwortung für das Teilprojekt im Auftrag des Projektleiters.
Er verfügt dabei über alle Kompetenzen, um die vom Projektleiter delegierten Tätigkeiten
wahrzunehmen.
Verantwortung
 Führung des Teilprojekts zur Erreichung der mit dem Projektleiter vereinbarten Ziele (Zeit,
Kosten, Qualität)
 Einhaltung der mit dem Projektleiter vereinbarten Richtlinien im eigenen Teilprojekt
155 / 200
 Wirtschaftlicher und nachhaltiger Einsatz der Ressourcen im eigenen Bereich
 Führung des Berichtswesens im eigenen Teilprojekt und umfassende, regelmässige und
situative Information des Projektleiters, damit dieser seinen Führungs- und Kommunikati-
onsaufgaben nachkommen kann
 Umsetzen der Entscheide Steuerung und Führung
Kompetenzen
 Kann auf alle Informationen seines Teilprojekts zugreifen
 Kompetenz bezüglich des Einsatzes der für das Teilprojekt freigegebenen Ressourcen
 Alleinige Führungsverantwortung und Anordnungskompetenz im Teilprojekt, ohne wäh-
rend der agilen Vorgehensweise in die Selbstorganisation des Entwicklungsteams (im Teil-
projekt) einzugreifen
 Entscheidungskompetenz im mit dem Projektleiter definierten Umfang (im Rahmen der
Kompetenzen des Projektleiters)
Fähigkeiten
Anwendung oder an die Anwendung des Produkts
 Vertiefte Kenntnisse im Projektmanagement
 Kenntnisse der im Projekt angewendeten Methoden und Praktiken
 Kenntnisse von Methoden und Techniken für die Beurteilung von Varianten und der Wirt-
schaftlichkeit
 Führungskompetenz
 Kommunikationsfähigkeit
 Angemessene schriftliche Ausdrucksfähigkeit
6.4.3 Ausführungsrollen
6.4.3.1 Anwendervertreter
Beschreibung
Der Anwendervertreter vertritt im Projekt die Anwender und deren Interessen. Er verwaltet die
mit den Fachbereichen abgestimmten und eindeutigen fachlichen Lösungsanforderungen als
stabile Basis für die Realisierung und ist für den fachlichen Erfolg der Entwicklung verantwort-
lich. Er ist sowohl für die Entwickler als auch für die Stakeholder der Ansprechpartner und
bildet damit in der Projektorganisation einen verbindlichen Kommunikationskanal. Er wird
vom Auftraggeber ernannt, vom Projektleiter geführt, ist jedoch während der Lösungsentste-
hung in fach- und lösungsspezifischen Fragen und Entscheidungen im Rahmen des Budgets
eigenständig.
ROLLEN
Bei agiler Vorgehensweise fungiert er als Schnittstelle zum Entwicklungsteam. Der Rollenin-
haber nimmt in diesem Fall durch zusätzliche Übernahme der aus dem im agilen Umfeld be-
kannten Rolle "Product Owner" im Entwicklungsteam seine fachliche Verantwortung wahr. Alle
Detailaufgaben und Verantwortlichkeiten im agilen Entwicklungsteam sind durch die zur An-
wendung kommende agile Methode definiert.
Verantwortung
 Verantwortung für die Lösung
 Erhebung aller lösungsspezifischen Anforderungen
 Verantwortung für die Lösungsanforderungen
 Transparenzhaltung und Verfügbarmachung der Lösungsanforderungen für alle am Pro-
jekt Beteiligten
156 / 200
 Einbringen der vollständigen, mit den Fachbereichen und Kunden abgestimmten fachli-
chen Anforderungen und Funktionalität, Vertretung der Stakeholderinteressen
 Maximierung der Wertschöpfung der Entwicklungsarbeit (Wertmaximierung der Lösung)
 Sicherstellung des Leistungsumfangs und des fachlichen Erfolgs der Lösung
 Einbindung der Stakeholder gemäss Stakeholderliste in die Lösungsentstehung
 Einhaltung der Anforderungen an ISDS
 Verantwortung für die Kommunikation mit dem Entwicklungsteam (Schnittstelle, agil)
Kompetenzen
 Entscheid über die Eigenschaften der Lösung inklusive der Qualitätsanforderungen
 Definition der Akzeptanzkriterien
 Zusammenarbeit mit Stakeholdern und Entwicklungsteam
 Mitsprache bei der Festlegung von Anforderungen an und beim Abschluss der SLAs
Fähigkeiten
 Vertiefte Kenntnisse im Fachbereich
 Kenntnisse im Projektmanagement und von HERMES
 Vertiefte Kenntnisse im klassischen und agilen Entwicklungsmanagement
 Kenntnisse der Methoden und Praktiken für Entwicklungsmanagement, Design, Spezifika-
tion
 Betriebswirtschaftliche Grundkenntnisse
 Kenntnisse der Vorgaben der Stammorganisation an den Betrieb der Anwendung (z. B. für
Beschaffungen, Finanzierung, Controlling, Sicherheit) oder an die Anwendung des Pro-
dukts
 Fähigkeit zur Erhebung, Formulierung, Bewertung und Priorisierung von Anforderungen
und Erstellung von Änderungsanträgen
 Gute schriftliche Ausdrucksfähigkeit
 Fähigkeit, zu abstrahieren und zu vereinfachen
 Visionäres Denken
 Durchsetzungsvermögen
 Natürliche Autorität
Beziehungen
Ergebniserstellung
Projektgrundla- Beschaffungsanalyse er- Beschaffungsanalyse Anwendervertreter, Projektleiter
gen arbeiten
Beschaffung Ausschreibung erarbei- Ausschreibungsunterla- Anwendervertreter, Projektleiter
ten gen
ROLLEN
Angebote bewerten Evaluationsbericht Anwendervertreter, Projektleiter

Angebotsprotokoll Anwendervertreter, Projektleiter
Organisation Stakeholderinteressen Stakeholderinteressen Anwendervertreter
vertreten
Produkt Lösungsanforderungen Situationsanalyse Anwendervertreter, Business Analyst
erarbeiten
Lösungsanforderungen Anwendervertreter, Business Analyst
Stakeholderinteressen Stakeholderinteressen Anwendervertreter
vertreten
Produktkonzept erarbei- Produktkonzept Anwendervertreter, Business Analyst
ten
157 / 200
Ergebniserstellung
IT-System Lösungsanforderungen Situationsanalyse Anwendervertreter, IT-Architekt, Business Analyst
erarbeiten
Lösungsanforderungen Anwendervertreter, IT-Architekt, Business Analyst
Stakeholderinteressen Stakeholderinteressen Anwendervertreter
vertreten
Einführungsorga- Einführungskonzept erar- Einführungskonzept Anwendervertreter, Projektleiter, Business Analyst
nisation beiten
Projektmanagementplan Anwendervertreter, Projektleiter
Einführungsmassnahmen Einführungsmassnahmen Anwendervertreter, Projektleiter, Business Analyst
realisieren realisiert
Einführungsmassnahmen Einführungsmassnahmen Anwendervertreter, Projektleiter, Business Analyst
durchführen durchgeführt
ISDS ISDS-Konzept realisieren ISDS-Konzept Anwendervertreter, Projektleiter, Betriebsverant-
wortlicher, ISDS-Verantwortlicher, Entwickler
ISDS-Massnahmen reali- Anwendervertreter, Projektleiter, Betriebsverant-
siert wortlicher, ISDS-Verantwortlicher, IT-Architekt
Tabelle 22: Aufgaben, die der Anwendervertreter verantwortet und weitere an der Ergebniserstellung beteiligte
Rollen
6.4.3.2 Betriebsverantwortlicher
Beschreibung
Der Betriebsverantwortliche vertritt im Projekt die Partnergruppe Betreiber und ist für den
Aufbau des Betriebs mit den Betriebsplattformen und der Betriebsorganisation zuständig. Er
stellt die technische und organisatorische Integration und den Betrieb des Systems auf den
verschiedenen Systemplattformen während der Projektphasen und des Betriebs sicher.
Verantwortung
 Erbringen der mit dem Betreiber vereinbarten Leistungen unter Einhaltung der gesetzten
Termine und Kosten
 Einbringen der Anforderungen des Betreibers
 Einhaltung der Anforderungen an ISDS des Betreibers
Kompetenzen
 Anordnungskompetenzen für die eigenen Spezialbereiche beim Betreiber
Fähigkeiten
 Vertiefte Kenntnisse des Betriebs
Anwendung (z. B. technische und organisatorische Vorgaben)
 Fähigkeit zur Erarbeitung von Anforderungen, Spezifikationen, Konzepten und Betriebs-
dokumentationen
ROLLEN
 Betriebswirtschaftliche Kenntnisse zur Beurteilung von Varianten und Wirtschaftlichkeit

 Gute schriftliche Ausdrucksfähigkeit, um z. B. Betriebsdokumentationen zu erstellen
 Führung von Fachspezialisten im eigenen Verantwortungsbereich
158 / 200
Beziehungen
Ergebniserstellung
Tests Testinfrastruktur realisie- Testinfrastruktur reali- Betriebsverantwortlicher, Anwendervertreter, Busi-
ren siert ness Analyst, Testverantwortlicher
IT-Betrieb Betriebskonzept erarbei- Betriebskonzept Betriebsverantwortlicher, IT-Architekt
ten
Service Level Agreement Betriebsverantwortlicher, Auftraggeber, Projektlei-
ter, Anwendervertreter
Betrieb realisieren Betriebshandbuch Betriebsverantwortlicher
Betriebsinfrastruktur rea- Betriebsverantwortlicher
lisiert
Betriebsorganisation rea- Betriebsverantwortlicher
lisiert
System in Betrieb integ- Betriebshandbuch Betriebsverantwortlicher
rieren
System integriert Betriebsverantwortlicher, Entwickler
Betrieb aktivieren Betriebshandbuch Betriebsverantwortlicher
Betrieb aktiviert Betriebsverantwortlicher, Entwickler
Tabelle 23: Aufgaben, die der Betriebsverantwortliche verantwortet und weitere an der Ergebniserstellung betei-
ligte Rollen
6.4.3.3 Business Analyst

Beschreibung
Der Business Analyst, oft auch Betriebsorganisator genannt, bildet die Schnittstelle zwischen
den Partnergruppen Anwender und Ersteller/Betreiber. Er erhebt, hinterfragt, analysiert und
priorisiert die Bedürfnisse und Anforderungen der Anwender auf der Basis der Geschäftsab-
läufe und -strukturen und transformiert sie in Organisationsanforderungen. Diese dienen Er-
steller und Betreiber als Grundlage für die Konzipierung und für den Betrieb des Produkts
oder des Systems. Umgekehrt berücksichtigt er lösungsspezifische Aspekte in der Konzipie-
rung der angestrebten Organisation.
Verantwortung
 Erhebung aller organisatorischen Anforderungen
 Verantwortung für die Organisationsanforderungen
 Definition der Geschäftsprozesse und der Aufbauorganisation
 Sicherstellung des Einbezugs von diversen Spezialisten
Kompetenzen
 Zusammenarbeit mit allen Partnergruppen
 Konzipierung, Umsetzung und Aktivierung der Organisation
Fähigkeiten
ROLLEN
 Vertiefte Kenntnisse im Fachbereich

 Kenntnisse der Vorgaben der Stammorganisation an das Projekt, an den Betrieb der An-
wendung (z. B. für Beschaffungen, Finanzierung, Controlling, Sicherheit) oder an die An-
wendung des Produkts
 Vertiefte Kenntnisse in Business-Analyse sowie den einschlägigen Methoden und Techni-
ken
 Betriebswirtschaftliche Kenntnisse in Organisationslehre und zur Bewertung von Varianten
und Wirtschaftlichkeit
 Fähigkeit zur Erhebung, Formulierung, Bewertung und Priorisierung von Anforderungen
 Kenntnisse im Projektmanagement
 Gute schriftliche Ausdrucksfähigkeit
 Führung von Spezialisten im eigenen Verantwortungsbereich
159 / 200
Beziehungen
Ergebniserstellung
Organisation Organisationsanforde- Situationsanalyse Business Analyst, Anwendervertreter
rungen erarbeiten
Organisationsanforde- Business Analyst, Anwendervertreter
rungen
Organisationskonzept er- Organisationskonzept Business Analyst, Anwendervertreter
arbeiten
Geschäftsmodellbe- Business Analyst, Anwendervertreter
schreibung
Prozessbeschreibung Business Analyst, Anwendervertreter
Organisationsbeschrei- Business Analyst, Anwendervertreter
bung
Organisation umsetzen Prozessbeschreibung Business Analyst, Anwendervertreter
Organisationsbeschrei- Business Analyst, Anwendervertreter
bung
Organisation umgesetzt Business Analyst
Organisation aktivieren Organisation aktiviert Business Analyst, Anwendervertreter
Tabelle 24: Aufgaben, die der Business Analyst verantwortet und weitere an der Ergebniserstellung beteiligte Rol-
len
6.4.3.4 Entwickler
Beschreibung
Die Rolle Entwickler ist umfassend und bezeichnet den Produktentwickler und den IT-Entwickler
in einem. Der Entwickler realisiert das Produkt bzw. das System gemäss den Lösungsanforde-
rungen und den vorangehenden Konzepten. Er aktiviert das Produkt bzw. das System.
Verantwortung
 Verantwortung für die Realisierung des Produkts oder des Systems
Kompetenzen
Fähigkeiten
 Vertiefte Kenntnisse im Spezialgebiet Produkt- oder Softwareentwicklung
 Vertiefte Kenntnisse der Methoden und Praktiken für Design, Spezifikation, Entwicklung,
Test und Integration
 Kenntnisse von HERMES
Beziehungen
Ergebniserstellung
ROLLEN
Projektgrundla- Prototyping durchführen Prototyp realisiert Entwickler, Anwendervertreter, IT-Architekt

gen
Prototypdokumentation Entwickler, IT-Architekt
Produkt Prototyping durchführen Prototyp realisiert Entwickler, Anwendervertreter
Prototypdokumentation Entwickler
Produkt realisieren Detailspezifikation Entwickler, Anwendervertreter, Business Analyst
Produktdokumentation Entwickler
Anwendungshandbuch Entwickler, Anwendervertreter
Produkt entwickelt Entwickler, Anwendervertreter, Business Analyst
oder angepasst
Produkt aktivieren Produkt aktiviert Entwickler, Anwendervertreter, Business Analyst
160 / 200
Ergebniserstellung
IT-System Prototyping durchführen Prototyp realisiert Entwickler, Anwendervertreter, IT-Architekt
Prototypdokumentation Entwickler
System realisieren Detailspezifikation Entwickler, Anwendervertreter, Business Analyst,
IT-Architekt
Systemkonzept Entwickler, Betriebsverantwortlicher, IT-Architekt,
Anwendervertreter
Lösungsarchitektur Entwickler, Betriebsverantwortlicher, IT-Architekt
Anwendungshandbuch Entwickler, Anwendervertreter
System entwickelt oder Entwickler, Anwendervertreter, Business Analyst,
parametrisiert IT-Architekt
Systemintegration vorbe- Schnittstellen realisiert Entwickler, Betriebsverantwortlicher
reiten
Lösungsarchitektur Entwickler, Betriebsverantwortlicher, IT-Architekt
Integrations- und Instal- Entwickler, Betriebsverantwortlicher
lationsanleitung
Detailspezifikation Entwickler, Business Analyst, IT-Architekt
System aktivieren System aktiviert Entwickler, Betriebsverantwortlicher, Anwenderver-
treter, Business Analyst
IT-Migration Migrationsverfahren rea- Detailspezifikation Entwickler, Business Analyst, IT-Architekt
lisieren
Migrationsverfahren rea- Entwickler, Betriebsverantwortlicher
lisiert
Migration durchführen Migration durchgeführt Entwickler, Betriebsverantwortlicher, Business Ana-
lyst
Tabelle 25: Aufgaben, die der Entwickler verantwortet und weitere an der Ergebniserstellung beteiligte Rollen
6.4.3.5 Entwicklungsteam
Beschreibung
Das Entwicklungsteam ist eine interdisziplinäre Rollengruppe, die ausschliesslich während der
agilen Vorgehensweise in der Phase Umsetzung zum Tragen kommt. Die Zusammensetzung
der Rollengruppe richtet sich nach der Art des Vorhabens und der zu erarbeitenden Ergeb-
nisse sowie nach der zur Anwendung kommenden agilen Entwicklungsmethode. Im Entwick-
lungsteam können je nach Vorhaben alle Ausführungsrollen zum Einsatz kommen. Bei der
Etablierung der agilen Projektorganisation ist der fachlichen Verantwortung des Anwender-
vertreters durch Wahrnehmung einer entsprechenden Rolle im Entwicklungsteam Rechnung
zu tragen.
Die Projektführungsverantwortung liegt beim Projektleiter, er darf dennoch nicht in die Selbst-
organisation des Entwicklungsteams eingreifen. Das Entwicklungsteam organisiert sich selbst.
Für das Entwicklungsteam werden keine Verantwortung, Kompetenzen, Fähigkeiten oder Be-
ziehungen definiert:
 Das Entwicklungsteam wirkt innerhalb des eingekapselten Entwicklungsvorgehens.
 Das Entwicklungsteam setzt sich aus allen, für die Erarbeitung der Ergebnisse und die Er-
ROLLEN
reichung der Meilensteine notwendigen Ausführungsrollen zusammen.

 Im Prinzip können im Entwicklungsteam je nach Vorhaben alle Ausführungsrollen vorkom-
men.
Verantwortung
 Gemäss den Beschreibungen der im Entwicklungsteam mitwirkenden Rollen
Kompetenzen
Fähigkeiten
161 / 200
6.4.3.6 ISDS-Verantwortlicher
Beschreibung
Der ISDS-Verantwortliche nimmt die Aspekte der Informationssicherheit und des Datenschut-
zes im Projekt wahr.
Verantwortung
 Sicherstellung der Berücksichtigung und Umsetzung von Informationssicherheitsvorgaben
und von Datenschutzmassnahmen im Projekt
 Förderung des ISDS-Verständnisses/-Bewusstseins im Projekt
Kompetenzen
 Kann auf alle benötigten Informationen des Projektes zugreifen
 Erlassen von sicherheitsrelevanten Vorgaben zum Umgang mit Daten und Informationen
während der Projektabwicklung
Fähigkeiten
 Vertiefte Kenntnisse im Spezialgebiet ISDS
 Kenntnisse der gesetzlichen Grundlagen und der Vorgaben der Stammorganisation
 Kenntnisse der Standards, Architekturen, Methoden und Praktiken der Informatik
 Vertiefte Kenntnisse der im eigenen Aufgabenkreis anzuwendenden Methoden und Prak-
tiken
 Betriebswirtschaftliche Kenntnisse zur Bewertung von Varianten und Wirtschaftlichkeit
 Kenntnisse im Prozessmanagement
 Kenntnisse von HERMES, vorzugsweise nachgewiesen durch ein Zertifikat
 Gute schriftliche Ausdrucksfähigkeit, um z. B. Berichte zu erstellen
Beziehungen
Ergebniserstellung
Projektgrundla- Schutzbedarfsanalyse er- Schutzbedarfsanalyse ISDS-Verantwortlicher, Projektleiter
gen arbeiten
ISDS ISDS-Konzept erarbeiten ISDS-Konzept ISDS-Verantwortlicher, Betriebsverantwortlicher,
IT-Architekt
ISDS-Konzept überführen ISDS-Konzept überführt ISDS-Verantwortlicher, Projektleiter, Anwenderver-
treter, Betriebsverantwortlicher
ISDS-Konzept ISDS-Verantwortlicher, Auftraggeber, Projektleiter,
Anwendervertreter, Betriebsverantwortlicher, IT-
Architekt
Tabelle 26: Aufgaben, die der ISDS-Verantwortliche verantwortet und weitere an der Ergebniserstellung beteiligte
Rollen
6.4.3.7 IT-Architekt
ROLLEN
Beschreibung
Der IT-Architekt entwirft die Lösungsarchitektur des zu erstellenden Systems. Er definiert die
Lösungskomponenten des Systems und ihre Schnittstellen mit den Umsystemen.
Verantwortung
 Gesamtverantwortung für die technischen Aspekte des entstehenden Systems
 Sicherstellung der Konformität mit den vorhandenen Standards und Architekturvorgaben
und Durchführen von Prüfungen
Kompetenzen
 Anordnungskompetenz
 Entscheidungskompetenz bezüglich der Lösungsarchitektur
162 / 200
Fähigkeiten
 Vertiefte Kenntnisse im Spezialgebiet IT-Architekturen
 Vertiefte Kenntnisse der Standards, Architekturen, Methoden und Praktiken der Informatik
 Betriebswirtschaftliche Kenntnisse zur Bewertung von Varianten und Wirtschaftlichkeit
 Kenntnisse von HERMES
 Sehr gute schriftliche Ausdrucksfähigkeit, um z. B. Lösungsarchitekturdokumentationen zu
erstellen
Beziehungen
Ergebniserstellung
IT-System Lösungsarchitektur erar- Systemkonzept IT-Architekt, Business Analyst, Anwendervertreter,
beiten Entwickler
Lösungsarchitektur IT-Architekt, Betriebsverantwortlicher, Entwickler
Integrationskonzept Integrationskonzept IT-Architekt, Betriebsverantwortlicher, Business
erarbeiten Analyst, Entwickler
IT-Migration Migrationskonzept erar- Migrationskonzept IT-Architekt, Business Analyst, Entwickler
beiten
Altsystem ausser Betrieb Altsystem entfernt IT-Architekt, Projektleiter, Betriebsverantwortlicher,
setzen Business Analyst
Tabelle 27: Aufgaben, die der IT-Architekt verantwortet und weitere an der Ergebniserstellung beteiligte
Rollen
6.4.3.8 Tester
Beschreibung
Der Tester arbeitet bei der Erstellung der Testfallbeschreibungen mit, führt Tests durch und
beurteilt und protokolliert die Ergebnisse.
Verantwortung
 Unterstützung des Testverantwortlichen bei der Erstellung der Testfallbeschreibungen
 Durchführung der Tests eines oder mehrerer Testobjekte
 Beurteilung der Testergebnisse und Festhalten der Ergebnisse in Form von Testprotokol-
len
Kompetenzen
 Entscheidungskompetenz zur Einstufung der Testergebnisse gemäss den im Testplan fest-
gelegten Mängelklassen
Fähigkeiten
ROLLEN
 Vertiefte Kenntnisse im Fachbereich (fachliche Prozesse, Organisationsanforderungen, Lö-

sungsanforderungen usw. im eigenen Testbereich)
 Kenntnisse im Testen und in der Testmethode
 Rasche Auffassungsgabe und gründliche Arbeitsweise
 Durchsetzungsvermögen
6.4.3.9 Testverantwortlicher
Beschreibung
Der Testverantwortliche konzipiert, plant und koordiniert das Testen. Er stellt sicher, dass die
Testgrundlagen in Form des Testkonzepts erarbeitet werden, und überführt das Testen in den
anschliessenden Betrieb.
163 / 200
Verantwortung
 Sicherstellung der Erfüllung der verschiedenen Anforderungen wie z. B. Organisationsan-
forderungen und Lösungsanforderungen in Bezug auf die Qualität des Systems
Kompetenzen
 Legt Testmethoden und Testorganisation fest
 Legt Mitarbeitereinsatz und Systemeinsatz für das Testen fest und ordnet Tests an
Fähigkeiten
 Vertiefte Kenntnisse der Testobjekte (fachliche Prozesse, Technik usw.)
 Vertiefte Kenntnisse im Spezialgebiet Qualitätssicherung und Testen mit den entsprechen-
den Methoden und Praktiken
 Kenntnisse in Design und Umsetzung von Informatiklösungen
 Vertiefte Kenntnisse im Änderungsmanagement
 Gute schriftliche Ausdrucksfähigkeit, um z. B. Testkonzepte und Testberichte zu erstellen
Beziehungen
Ergebniserstellung
Tests Testkonzept erarbeiten Testkonzept Testverantwortlicher, Tester, Anwendervertreter,
Betriebsverantwortlicher, Business Analyst, Ent-
wickler
Test durchführen Testprotokoll Testverantwortlicher, Tester
Testkonzept Testverantwortlicher, Tester, Anwendervertreter,
Betriebsverantwortlicher, Business Analyst, Ent-
wickler
Testinfrastruktur über- Testkonzept Testverantwortlicher, Projektleiter
führen
Testinfrastruktur über- Testverantwortlicher, Projektleiter
führt
Protokoll Testverantwortlicher, Projektleiter
Tabelle 28: Aufgaben, die der Testverantwortliche verantwortet und weitere an der Ergebniserstellung beteiligte
Rollen
ROLLEN
164 / 200
7 Hinweise zur Anwendung
7.1 Einleitung
Dieses Kapitel hilft HERMES-Projektmanagement richtig anzuwenden. Um die Anwender zu
unterstützen, wurden in diesem Kapitel Hinweise zusammengestellt, die z. B. ein vertieftes
Verständnis für HERMES ermöglichen, Anwendungsfälle erläutern oder fallspezifisch auch eine
Art Leitfaden liefern.
7.2 Übersicht der Hinweise

Die Hinweise zur Anwendung von HERMES werden in zwei Kategorien zusammengefasst:
a) Erläuterungen
Die Erläuterungen betreffend HERMES zeigen auf, wie spezifische Themen in HERMES in-
tegriert sind. Sie vermitteln Zusammenhänge und ermöglichen ein vertieftes Methoden-
verständnis.
b) Anwendungsfälle
Die Hinweise zu Anwendungsfällen zeigen auf, wie HERMES in spezifischen Situationen
umgesetzt werden soll. Sie schaffen Sicherheit in der Anwendung und helfen, den Inter-
pretationsspielraum zu reduzieren.
Die Tabelle zeigt die Hinweise pro Kategorie.
Kategorie Hinweis
Erläuterungen Governance
Nachhaltigkeit
Projektmanagement und Entwicklungsmanagement
Finanzielle Steuerung und Führung
Anwendungsfälle Planung
Realisierungseinheiten bei klassischer Vorgehensweise
Anwendung mit anderen Methoden und Praktiken
Integration von HERMES in die Stammorganisation
Tabelle 29: Hinweise zur Anwendung pro Kategorie
7.3 Erläuterung der Hinweise-Beschreibung

Die Beschreibung der Hinweise folgt keiner festen oder einheitlichen Struktur. Jeder Hinweis
ist bedarfsgerecht gegliedert und bildet für sich eine unabhängige Themeneinheit.
7.4 Beschreibung der Hinweise

7.4.1 Governance
7.4.1.1 Projekt-Governance
Unter Governance wird allgemein die «verantwortungsvolle Unternehmungsführung und -
kontrolle» verstanden. Sie muss insbesondere durch das Management der Stammorganisa-
tion umgesetzt werden.
Die Projekt-Governance ist ein Teil der Unternehmens-Governance. Die folgenden Kennzei-
HINWEISE ZUR
ANWENDUNG
chen guter Projekt-Governance stellen Anforderungen an die Projektsteuerung und Projekt-

führung dar:
 Effektive und funktionsfähige Projektplanung, -steuerung und -führung
 Konstruktive Zusammenarbeit von Projektorganisation und Stammorganisation
 Berücksichtigung der Stakeholderinteressen
 Abstimmung der gesetzten Ziele mit Vorgaben der Stammorganisation
 Solide Basis für richtige, effiziente und transparente Entscheidungen
165 / 200
 Institutionalisierter und zeitgerechter Informationsfluss, Transparenz in der Projektkom-
munikation
 Nachvollziehbarkeit der Projektdurchführung und etwaiger Zieländerungen
 Angemessener Umgang mit Risiken
 Funktionale und adäquate Projektorganisation und Projektinfrastruktur
 Effizienter und nachhaltiger Ressourceneinsatz
HERMES-Projektmanagement ist darauf ausgerichtet, eine gute Projekt-Governance zu ge-
währleisten.
7.4.1.2 Umsetzung von bedeutenden Veränderungen

Erstellung der Lösung
Bei der durch HERMES-Projektmanagement unterstützten Umsetzung der Unternehmenspla-
nung werden mittels Projekten bedeutende Veränderungen realisiert.
Während der Phase Initialisierung werden die Skizzen der Unternehmensplanung vertieft. Am
Ende der Phase wird ein Durchführungsauftrag erarbeitet, damit der Auftraggeber in Abstim-
mung mit der Stammorganisation entscheiden kann, ob die Projektfortsetzung freigegeben
und wie die Lösungsentstehung angegangen wird.
Die Stammorganisation ernennt und besetzt die entscheidenden Rollen des Projekts aus ihren
eigenen Reihen bzw., aus der Partnergruppe Anwender. Zuerst den Auftraggeber und durch
den Auftraggeber den Projektleiter und den Anwendervertreter. Die Leitung sowie die Con-
trolling- und Vorgabestellen werden über Entscheidungsaufgaben und das Reporting in das
Projekt eingebunden. Der Auftraggeber sorgt für die ständige Kommunikation zwischen
Stamm- und Projektorganisation, der Projektleiter für die Identifizierung und u.U. für die Ge-
winnung der Stakeholder für das Projekt und deren Information und der Anwendervertreter
für deren Einbindung in die Projektdurchführung. Im Rahmen des Projekts ist der Auftragge-
ber die oberste Entscheidungsinstanz.
Nutzung der Lösung
Die Nutzung
 des erstellten Produkts oder der Dienstleistung beginnt mit der Aktivierung des Produkts
und der Organisation,
 des erstellten Systems mit der Aktivierung des Betriebs und
 der erstellten Organisation mit der Aktivierung der Organisation.
Die Voraussetzungen für die nachhaltige Nutzung werden im Projekt geschaffen. Das Projekt
wird abgeschlossen, wenn der Betrieb stabil erfolgt, die Lösung abgenommen und alle not-
wendigen Schlussaufgaben erledigt sind. Beim Übergang von der Projekt- zur Anwendungs-
organisation wird sichergestellt, dass die für die Nutzung benötigten Rollen besetzt sind. Dazu
gehören oft die Rollen des Anwendervertreters und des Betriebsverantwortlichen. Das Projekt
wandelt sich zur Anwendung. Führt die Stammorganisation sowohl für Projekte als auch für
Anwendungen das gleiche Portfolio, wie es auch im HERMES-Portfoliomanagement vorgese-
hen ist, ändert lediglich der Status von Projekt zu Anwendung. Es ist allerings zu berücksich-
tigen, dass sich das Projekt und die Anwendung im Portfolio überlappen. Dies kommt insbe-
sondere bei der agilen Lösungsentstehung zum Tragen. Die Leitung des Anwenders und die
des Erstellers bzw. Betreibers bleiben auch während der Periode der Nutzung in Verbindung.
Die Erfolgskontrolle, ob die ursprünglich gesetzten Ziele letztlich erreicht wurden, geschieht
während der Nutzung.
7.4.1.3 Nachvollziehbarkeit der gewählten Vorgehensweise

HINWEISE ZUR
ANWENDUNG
Zur verantwortungsvollen Projektdurchführung gehört auch die Wahl der geeigneten Vorge-
hensweise. Die Entscheidung, ob Projekte klassisch oder agil angegangen werden, muss auf
Projektebene erfolgen, da jedes Vorhaben individuelle Charakteristiken aufweist. Dies gilt
auch für Projekte in einem Programm. Auch mehrere IT-Projekte, die parallel abgewickelt wer-
den, können durchaus unterschiedliche Rahmenbedingungen haben, die unterschiedliche
Vorgehensweisen erfordern.
166 / 200
Für die Wahl der Vorgehensweise können verschiedene Methoden und Techniken verwendet
werden. Die Anforderungen von Controlling- und Vorgabestellen müssen erfüllt werden. Die
Wahl der Vorgehensweise muss nachvollziehbar sein.
7.4.1.4 Selbstbestimmung der Anwender über das Projekt

Manchenorts hat es sich eingebürgert, dass die Dienstleistungserbringer bzw. die Partner-
gruppen Ersteller oder Betreiber das Projektgeschehen massgeblich beeinflussen, teilweise
nahezu dominieren. Dies widerspricht einerseits dem Rollen- und Partnerverständnis von
HERMES. Anderseits können so die Anwender ihre Verantwortung im Projekt nicht vollum-
fänglich wahrnehmen und somit auch ihre Interessen nicht wahren.
Die Stammorganisation bzw. die Partnergruppe Anwender stellt als Inhaberin des Projekts
und als Nutzerin der Lösung die finanziellen Ressourcen für das Projekt zur Verfügung. Dies
gibt ihr das Recht, frei und ohne Einschränkung anderer Partnergruppen über die Projekt-
struktur, die angewandte Managementmethode und die Vorgehensweise zu entscheidenund
auch die minimal zu besetzenden Rollen zwingend mit eigenen oder von ihr engagierten Per-
sonen zu besetzen. Allerdings muss sie von ihrem Recht auch Gebrauch machen und dies/sich
konsequent durchsetzen. Dies wiederum gehört zu ihrer Pflicht.
In Bezug auf die Selbstbestimmung der Anwender über das Projekt sind die folgenden Pro-
jektrollen besonders relevant:
 Auftraggeber
o Legt den Rahmen für die Projektinitialisierung und für die Lösungsentstehung fest.
o Bestimmt die Rollenbesetzung, insbesondere der Partnergruppe Anwender.
o Entscheidet über die Art des Entwicklungsvorgehens.
o Setzt die Interessen seiner Stammorganisation durch.
 Projektleiter
o Bereitet die Entscheide der Steuerung vor.
o Wahrt die Interessen der Stammorganisation.
o Führt die Rollen aller Partnergruppen.
o Setzt das gewählte Vorgehen durch.
o Sichert das Reporting.
 Anwendervertreter
o Bereitet die Entscheide der Steuerung und der Führung vor.
o Bewertet Varianten im Interesse der Stammorganisation.
o Unterstützt den Projektleiter bei der Wahrung der Interessen der Stammorganisation
und beim Reporting.
In der Stammorganisation sind im Speziellen die folgenden Rollengruppen mit der Selbstbe-
stimmung konfrontiert:
o Beurteilen die Einhaltung der Vorgaben in Bezug auf die Vorgehensweise im Durch-
führungsauftrag.
 Leitung
o Prüft, ob die Vorgaben und Ziele der Stammorganisation in Bezug auf das Projekt
erfüllt sind.
7.4.1.5 Integration in das Portfolio

Die Abbildung 30 stellt eine mögliche Unterstellung des Portfolios in der Stammorganisation
dar. Es ist oft
a) im Kompetenzzentrum Projektmanagement oder
HINWEISE ZUR
ANWENDUNG
b) bei den Controlling- und Vorgabestellen

angesiedelt. Die Verantwortung obliegt in der Regel jedoch der Leitung.
167 / 200
Die Governance-Anforderung eines effizienten und nachhaltigen Ressourceneinsatzes be-
dingt, dass beurteilt wird, ob ein Projekt gestartet und seine Durchführung später freigegeben
werden soll. Eine Aufgabe der Stammorganisation ist es, die Gesamtheit der Projekte der Or-
ganisation übergeordnet zu steuern und zu kontrollieren. Dies erfolgt mit dem Projektportfo-
liomanagement. Es umfasst die übergeordnete Priorisierung und Koordination der Projekte,
die Ressourcenzuweisung zu Projekten und die Entscheide darüber, welche Projekte initiali-
siert, umgesetzt, angehalten und beendet werden. Aus Unternehmenssicht werden mit Vorteil
Projektportfolio und Anwendungsportfolio in einem übergeordneten Produktportfolio zu-
sammengeführt.
Stammorganisation
Kompetenzzentrum Controlling- und
Leitung Projektmanagement Vorgabestellen
a) oder b)
Portfolio
Portfolio
Abbildung 30: Zwei übliche Möglichkeiten der organisatorischen Zuordnung des Portfolios
HERMES unterstützt die Integration der Projekte – sowie der Anwendungen – in das Portfoli-
omanagement unter anderem mit dem Phasenmodell (übereinstimmende Projektstruktur),
mit den Phasen und den Releases sowie mit Meilensteinen und mit Reporting.
7.4.1.6 Reporting
Die Forderung der Projekt-Governance nach einer transparenten Kommunikation bedingt ein
Reporting. Das Reporting unterstützt ebenfalls die Anforderung der Projekt-Governance an
die Nachvollziehbarkeit des Projektverlaufs. Das Reporting erfolgt periodisch entlang den
Phasen gemäss den Vorgaben der Stammorganisation.
Mit dem Reporting wird der Informationsfluss in der Projektorganisation und gegenüber der
Stammorganisation formell geregelt. Das zeitnahe Reporting ist eine Voraussetzung dafür,
dass die verantwortlichen Stellen in der Projekt- und der Stammorganisation ihre Aufgaben
verantwortungsvoll ausführen können.
Die mit dem Reporting erzielte Transparenz ist nicht nur für die Stammorganisation und den
Auftraggeber, sondern auch für den Projektleiter von Nutzen, da es die Qualität der Projekt-
durchführung dokumentiert. Die folgenden Ergebnisse fallen beim Reporting an:
HINWEISE ZUR
ANWENDUNG
Projektstatusberichte werden periodisch ab Projektbeginn bis Projektabschluss erstellt. In
von der Stammorganisation definierten Zeitperioden informiert die Projektleitung mit dem
Projektstatusbericht den Auftraggeber und die Stammorganisation über den Projektstand
(Vergleich Plan/Ist) und den voraussichtlichen weiteren Verlauf (Prognose).
168 / 200
 Phasenbericht
Am Ende der Phasen Konzept, Realisierung, Einführung und Umsetzung werden die Er-
gebnisse der Phase und die Planung des weiteren Projektverlaufs für den Auftraggeber so
aufbereitet, dass er den Entscheid zum weiteren Projektvorgehen (in der Regel zur Pha-
senfreigabe) treffen kann.
 Releasebericht (agil)
Während der Phase Umsetzung werden am Ende jedes Release die Ergebnisse des Release
für den Auftraggeber so aufbereitet, dass er über den Releaseerfolg sowie den Fortschritt
und die gesamte Entwicklung informiert ist. Wurde in der Initialisierungsphase festgelegt,
dass der Entscheid Releasefreigabe jeweils getroffen werden muss, dient der Releasebe-
richt der Entscheidungsfindung.
Am Ende der Phase Abschluss wird die Projektschlussbeurteilung erarbeitet. Sie dient der
kontinuierlichen Verbesserung in der Stammorganisation aufgrund der gemachten Erfah-
rungen.
Wie die Abbildung 31 zeigt, bleibt das Reporting innerhalb der Projektorganisation und ge-
genüber der Stammorganisation einheitlich, gleichgültig, welches Entwicklungsvorgehen ge-
wählt wird. Dadurch bleibt im Reportingbereich die Governance sowohl beim klassischen als
auch beim agilen Entwicklungsvorgehen gewahrt.
klassisch Initialisierung Konzept Realisierung Einführung Abschluss
Ausführung Lösungs- klassisch

architektur
Führung
Durchfüh- Phasen- Phasen- Phasen- Projektschluss-
rungsauftrag bericht bericht bericht beurteilung
Steuerung
Stamm- Projektstatus- Projektstatus- Projektstatus-

organisation bericht bericht bericht
Steuerung
Durchfüh- Release Release Phasen- Projektschluss-

rungsauftrag -bericht -bericht bericht beurteilung
Führung
Lösungsarchitektur
Ausführung agil
hybrid Initialisierung Release 1 Release 2 Umsetzung Release n Abschluss
Abbildung 31: Gekapselte, gegenüber der Stammorganisation einheitliche Reporting Struktur
Ergänzend zum Reporting werden definierte fachliche Ergebnisse den Controlling- und Vor-
gabestellen zur Prüfung zugestellt (Beispiel: Lösungsarchitektur).
7.4.1.7 Erfüllung der Anforderungen der Projekt-Governance

Prüfungsgegenstand
Bei der Beurteilung eines Projekts wird unter anderem geprüft, ob es die Anforderungen an
HINWEISE ZUR
ANWENDUNG
die gute Projekt-Governance erfüllt.

Nachfolgend ist für jede Anforderung beschrieben, wie die einzelnen HERMES-Methodenele-
mente deren Erfüllung unterstützen.
169 / 200
Funktionsfähige Projektsteuerung und -führung
 Rollen
Die Rollen sind ein zentrales Methodenelement, um die Anforderung an die funktionsfä-
hige Projektsteuerung und Führung erfüllen zu können:
o Die Verantwortung für Aufgaben und Ergebnisse ist den definierten Rollen im Projekt
zugewiesen.
o Die Rollen sind den Hierarchieebenen Steuerung, Führung und Ausführung zugeord-
net. Damit wird die Verantwortlichkeit der Rollen zusätzlich sichtbar gemacht.
o Die Rollen sind mit Rollenbeschreibungen konkretisiert. Dabei sind die Aufgaben,
Kompetenzen und die Verantwortung sowie die benötigten Fähigkeiten zur Ausübung
der Rolle beschrieben.
o Zur Unterstützung der Rolle des Auftraggebers ist eine Rolle Qualitäts- und Risikoma-
nager definiert. Dieser nimmt unabhängige Beurteilungen der Projektdurchführung
vor und gibt Empfehlungen ab.
o Zur Unterstützung der Rolle des Auftraggebers ist eine Rollegruppe Projektausschuss
definiert. Sie ermöglicht die Integration der Stakeholder in die Projektorganisation, auf
der Hierarchieebene Steuerung.
o Zur Unterstützung der Rolle des Projektleiters ist beim klassischen Vorgehen eine Rol-
legruppe Fachausschuss definiert. Dadurch können die Stakeholder sowohl im Füh-
rungsbereich als auch auf der fachlichen Ebene in die Projektorganisation eingebun-
den werden.
o Im Kapitel Projektorganisation ist beschrieben, welche Aspekte bei der Rollenbeset-
zung berücksichtigt werden sollen, damit eine funktionsfähige Projektsteuerung und -
führung sichergestellt ist.
 Module und Aufgaben
Die Aufgaben der Steuerung und der Führung sind umfassend beschrieben. Sie sind in
den Modulen Projektsteuerung und Projektführung gruppiert und damit für Auftraggeber,
Projektleiter und weitere Projektbeteiligte klar ersichtlich.
Dadurch besteht eine hohe Transparenz bezüglich der Aufgaben und Ergebnisse, die in
die Verantwortung von Auftraggeber und Projektleiter fallen.
 Ergebnisse
In jedem Projekt müssen bestimmte Ergebnisse, die minimal geforderten Dokumente, er-
arbeitet werden, damit ein Projekt gesteuert und geführt werden kann. Dazu gehören bei-
spielsweise der Durchführungsauftrag oder der Projektmanagementplan. Sie sind aus
Sicht der Governance im Kapitel Ergebnisse definiert.
 Reporting
Die Projektsteuerung erfordert verlässliche Informationen über Planung, Projektstand und
Prognosen. Diese werden über das Reporting bereitgestellt.
Berücksichtigung der Stakeholderinteressen
 Rollen
Die Rollen der Projektsteuerung (Auftraggeber), der Projektführung (Projektleiter) und der
fachlichen Produktentwicklung (Anwendervertreter) sind verantwortlich für die entspre-
chenden Aufgaben.
 Aufgaben
o Mit der Aufgabe Stakeholder managen und informieren wird sichergestellt, dass die
Stakeholder identifiziert und ihre Interessen analysiert werden.
o Mit der Aufgabe Stakeholderinteressen vertreten wird sichergestellt, dass die Stake-
holder ihre Ideen und Forderungen in das Projekt einbringen können und bei Bedarf
in das Entwicklungsgeschehen eingebunden werden.
HINWEISE ZUR
ANWENDUNG
 Ergebnisse
Die Stakeholderliste und die Stakeholderinteressen werden erstmals in der Phase Initiali-
sierung erstellt und im Projektablauf kontinuierlich weitergeführt.
Zusammenarbeit von Projektorganisation und Stammorganisation
 HERMES und Portfoliomanagement
HERMES unterstützt die Integration der Projekte in das Portfoliomanagement.
170 / 200
 Phasen und Meilensteine
Die Phasen und Meilensteine (mit Quality Gates) unterstützen die Zusammenarbeit (z. B.
hinsichtlich klarer Schnittstellen).
 Rollen
Das Rollenmodell schafft eine klare Beziehung zwischen der Projektorganisation und der
Stammorganisation mit ihren Controlling- und Vorgabestellen.
 Aufgaben
Mehrere Aufgaben unterstützen die Zusammenarbeit von Projektorganisation und Stam-
morganisation. Beispielsweise:
o die Entscheidungsaufgaben zu Projektinitialisierungsfreigabe, Durchführungsfreigabe,
Phasenfreigabe, Releasefreigabe und Projektabschluss;
o die Aufgabe Leistungen vereinbaren und steuern;
o die Aufgabe Entscheid Lösungsarchitektur treffen;
o die Aufgabe Entscheid ISDS-Konzept treffen.
Abstimmung der gesetzten Ziele mit Vorgaben der Stammorganisation
 Phasen bzw. Releases
Vor der Durchführungsfreigabe am Ende der Phase Initialisierung und der jeweiligen Pha-
senfreigabe bzw. der Releasefreigabe werden die Ziele im Rahmen der jeweiligen Ent-
scheidungsaufgaben mit der Strategie und den Zielen der Stammorganisation abge-
stimmt.
Transparenz in der Projektkommunikation
 Aufgaben
Mit der Aufgabe Stakeholder managen und informieren wird die Kommunikationsplanung
erarbeitet. Die Kommunikation wird zielgruppenorientiert geführt.
 Reporting
Das Reporting stellt die projektinterne Kommunikation zwischen Projektleitung und Auf-
traggeber sowie eine realistische und zeitnahe Gesamtbetrachtung und -bewertung ge-
genüber der Stammorganisation sicher.
Nachvollziehbarkeit des Projektverlaufs
 Ergebnisse
Die im Projektverlauf anfallenden Ergebnisse dokumentieren den Projektverlauf.
o Mit dem periodischen Reporting, das den Projektstatusbericht und den Phasenbericht
umfasst, wird der Projektablauf dokumentiert.
o Projektentscheide werden festgehalten und Sitzungen protokolliert.
o Projekterfahrungen werden laufend festgehalten.
o In der Projektschlussbeurteilung werden die Plan- und Ist-Werte verglichen (Soll-Ist-
Vergleich) und wesentliche Erkenntnisse festgehalten.
o Der Projektmanagementplan wird laufend nachgeführt und dokumentiert den jeweili-
gen Planungsstand.
o Beschaffungen werden mit einem Evaluationsbericht dokumentiert.
o Änderungen werden in der Änderungsstatusliste geführt und festgehalten.
Angemessener Umgang mit Risiken
 Ergebnisse
Der Projektstatusbericht enthält die aktuelle Risikobeurteilung und informiert die Empfän-
ger über die Beurteilung des Projektleiters.
 Aufgaben
Mit der Aufgabe Risiken managen wird das Risikomanagement kontinuierlich geführt.
HINWEISE ZUR
ANWENDUNG
 Rollen
Auf Hierarchieebene Projektsteuerung unterstützt die Rolle des Qualitäts- und Risikoma-
nagers den Auftraggeber mit einer unabhängigen Beurteilung des Projekts.
 Phasen bzw. Releases
Werden am Ende einer Phase oder eines Release die Risiken als nicht tragbar beurteilt,
muss über das weitere Vorgehen befunden und das Projekt eventuell abgebrochen wer-
den.
171 / 200
 Module und Szenarien
Module und Szenarien unterstützen alle Projektbeteiligten und die Stammorganisation im
gemeinsamen Verständnis, wie ein Projekt einer spezifischen Charakteristik abgewickelt
wird. Dadurch können Missverständnisse vermieden und die Projektrisiken insgesamt ge-
senkt werden.
Effizienter und nachhaltiger Ressourceneinsatz
 Module und Szenarien
Module und Szenarien ermöglichen die effiziente Planung.
 Phase Initialisierung
Am Ende der Phase Initialisierung wird geprüft, ob es sinnvoll ist, mittels eines Durchfüh-
rungsauftrags das Projekt fortzusetzen. Mögliche Gründe, dies nicht zu tun, sind fehlende
Wirtschaftlichkeit, zu hohe Risiken, fehlende Realisierbarkeit, fehlende Übereinstimmung
mit den Zielen und Strategien der Organisation.
 Phasen, Releases und Meilensteine
Am Ende der Phasen oder am Ende der Release wird im Rahmen der Lösungsentstehung
geprüft, ob es sinnvoll ist, das Projekt weiterzuführen. Die möglichen Gründe für einen
Abbruch sind z. B. zu hohe Risiken, ausbleibender Nutzen, ausufernde Kosten, usw.
 Hinweise zur Anwendung
Das Kapitel Nachhaltigkeit beschreibt, wie Projekte nachhaltig durchgeführt bzw. wie
nachhaltige Ergebnisse erzielt und welche Kriterien zur Beurteilung der Nachhaltigkeit her-
angezogen werden.
7.4.2 Nachhaltigkeit
7.4.2.1 Nachhaltigkeitsverständnis
Das Fundament der Nachhaltigkeit bildet das Nachhaltigkeitsverständnis der Weltkommission
für Umwelt und Entwicklung («Brundtland-Kommission»). Diese definiert, dass die nachhaltige
Entwicklung zwar die Bedürfnisse der Gegenwart befriedigen soll, jedoch die Bedürfnisse der
künftigen Generationen nicht gefährden darf. Dabei sollen die wirtschaftlichen, gesellschaftli-
chen und ökologischen Vorgänge miteinander in Einklang gebracht werden. Eine nachhaltige
Entwicklung strebt ein auf Dauer ausgewogenes Verhältnis zwischen der Natur und ihrer Er-
neuerungsfähigkeit und ihrer Beanspruchung durch den Menschen an.
Die Auswirkungen des heutigen Handelns auf die Zukunft müssen folglich einberechnet wer-
den. So soll z. B. auch der Umwelt- und Ressourcenverbrauch unter Wahrung der wirtschaft-
lichen Leistungsfähigkeit und des sozialen Zusammenhalts auf ein dauerhaft tragbares Niveau
gesenkt werden. Alle diese Nachhaltigkeitsforderungen betreffen auch die Projekte. Diese
dürfen sich bei der Definition der zu erreichenden Ziele nicht lediglich auf die Wirtschaftlich-
keit beschränken, sondern müssen auch die Gesellschaft und die Umwelt einbeziehen. Inso-
fern hat ein erfolgreiches Projektmanagement auch positive Auswirkungen im Bereich der
nachhaltigen Entwicklung.
Im Bereich der Informations- und Kommunikationstechnologien stehen aus Nachhaltigkeits-
sicht in einer Lebenszyklusbetrachtung vor allem die Energie- und Ressourceneffizienz sowie
die Arbeitsbedingungen in den Produktionsländern im Vordergrund. Ein besonderes Augen-
merk gilt dabei dem Beschaffungswesen durch das Definieren von ökologischen und sozialen
Zuschlagskriterien. Für Informationstechnologien spielen zusätzlich die langfristige Sicherung
der Daten, der Datenschutz und die Datenintegrität sowie der Zugang zu Wissen eine wichtige
Rolle.
7.4.2.2 Nachhaltigkeit mit HERMES

HINWEISE ZUR
ANWENDUNG
HERMES als Gesamtprodukt

HERMES unterstützt die Nachhaltigkeit der Lösung. Nachfolgend sind die Methodenelemente
im Hinblick auf Nachhaltigkeitsaspekte beschrieben.
Phasen
Wichtig ist die Verankerung von Nachhaltigkeitszielen bei der Definition der strategischen
Ziele. Diese fliessen in der Phase Initialisierung als Vorgabe in das Projekt ein.
172 / 200
 Für den Auftraggeber ist eines der Entscheidungskriterien bei der Durchführungsfreigabe,
ob und wie die Vorgaben und Ziele zur Nachhaltigkeit durch das Projekt erfüllt werden.
Nicht nachhaltige Projekte werden dadurch gar nicht erst zur Fortsetzung freigegeben.
 Bei jedem Entscheid zur Phasen- bzw. Releasefreigabe wird nebst der Einhaltung der Vor-
gaben sowie der Übereinstimmung mit den strategischen Zielen auch die Erreichung der
Nachhaltigkeitsziele als Bewertungskriterium mitberücksichtigt.
Ergebnisse
Im Projekt werden alle Ergebnisse erarbeitet, die für einen nachhaltigen Betrieb benötigt wer-
den. Dazu gehören die Organisation mit den Prozessen sowie die Ergebnisse für Wartung und
Weiterentwicklung mit Anwendungshandbuch, Betriebshandbuch, Produktkonzept, Lösungs-
architektur und Detailspezifikation. Für die Weiterentwicklung nach Projektabschluss werden
Testinfrastruktur und Testhilfsmittel vom Projekt an die Stammorganisation übergeben.
Die folgenden Ergebnisse unterstützen die Nachhaltigkeit von Entscheiden:
 Studie
Bewertungskriterien für den Entscheid Weiteres Vorgehen (Wahl der Lösungsvariante)
 Ausschreibungsunterlagen (Lastenheft)
Kriterienkatalog für Bewertung der Lösung und Bewertung der Anbieter
 Checklisten
Prüfpunkte und Kriterien im Entscheidungsprozess
Aufgaben
Mehrere Aufgaben unterstützen die Nachhaltigkeit im Projekt konkret, beispielsweise:
 die Entscheidungsaufgaben wie:
o Entscheide Durchführungsfreigabe, Phasenfreigabe, Releasefreigabe und Projektab-
schluss;
o Entscheid Weiteres Vorgehen;
o Entscheid Lösungsarchitektur;
 die Aufgabe Leistungen vereinbaren und steuern;
 die Aufgabe Stakeholder managen und informieren;
 die Aufgabe Beschaffungsanalyse erarbeiten;
 die Aufgaben des Modules Beschaffung.
Module
Im Modul Beschaffung werden die Ziele und Anforderungen der Nachhaltigkeit in den Krite-
rienkatalog für die Beschaffung von Dienstleistungen und Produkten aufgenommen und flies-
sen in die Bewertung ein.
Rollen
Die Rollen können mit ihren Kompetenzen und ihrer Verantwortung einen bewussten Um-
gang mit den Ressourcen fördern. Das dazu nötige Verständnis wird bei den Beteiligten be-
reits anlässlich der Zieldefinition geschaffen. Entsprechend sind für die Nachhaltigkeit des Pro-
jekts alle Rollen mit ihren Aufgaben massgebend.
In Bezug auf Nachhaltigkeitsziele sind die folgenden drei Rollen besonders relevant:
 Auftraggeber
o Legt die Ziele in Übereinstimmung mit der Strategie und den Vorgaben zur Nachhal-
tigkeit fest.
o Priorisiert die Lösungsziele, bereinigt Zielkonflikte und lässt diese in die Lösungsanfor-
HINWEISE ZUR
ANWENDUNG
derungen und Organisationsanforderungen einfliessen.

o Überprüft die Umsetzung der Vorgaben und die Zielerreichung regelmässig.
o Stellt den Einbezug der Stakeholder mit ihren Ansprüchen sicher.
o Stellt die langfristig benötigten Ressourcen für den Betrieb sicher.
 Projektleiter
o Verankert das Bewusstsein zur Nachhaltigkeit im Projekt.
o Berücksichtigt bei Entscheiden die Nachhaltigkeitskriterien.
173 / 200
o Stellt den schonenden Umgang mit Ressourcen sicher.
o Stellt bei der Rollenbesetzung sicher, dass die Fachspezialisten über die notwendigen
Fähigkeiten verfügen, und sorgt für die Schliessung vorhandener Fähigkeitslücken
(bei agiler Vorgehensweise erfolgt dies in eigener Kompetenz des Entwicklungsteams).
 Anwendervertreter
o Integriert die Nachhaltigkeitsziele in den Lösungsanforderungen und priorisiert sie.
o Verankert das Bewusstsein zur Nachhaltigkeit bei der Lösungsentstehung.
o Versteht unter der Wertschöpfung der Entwicklungsarbeit auch die Nachhaltigkeit.
o Berücksichtigt die Interessen der Stakeholder.
o Unterstützt den Auftraggeber bei der Definition der Nachhaltigkeitsziele.
o Bringt die Nachhaltigkeit in den Beschaffungsprozess ein.
o Stellt sicher, dass bei der Anforderungsdefinition die Anforderungen auch aus Sicht
der Nachhaltigkeit erhoben werden.
o Nimmt eine werteorientierte Priorisierung der Anforderungen vor.
 In die Bewertung der Anforderungen fliessen die Nachhaltigkeitsziele ein.
o Bewertet Varianten auch unter dem Gesichtspunkt der Nachhaltigkeit.
In der Projektorganisation befassen sich speziell folgende Ausführungsrollen mit der Nach-
haltigkeit:
 Business Analyst
o Ermittelt die Vorgaben der Stammorganisation bezüglich der Nachhaltigkeit.
o Integriert die Nachhaltigkeitsziele in die Organisationsanforderungen.
o Berücksichtigt die Aspekte der Nachhaltigkeit bei der Erarbeitung des Organisations-
konzepts.
o Begleitet den Anwendervertreter bei der Formulierung der Nachhaltigkeitsziele.
 Betriebsverantwortlicher
o Berücksichtigt die Aspekte der Nachhaltigkeit bei der Anforderungsdefinition aus Sicht
des Betriebs.
o Berücksichtigt die Aspekte der Nachhaltigkeit bei der Erarbeitung des Betriebskon-
zepts.
o Stellt einen nachhaltigen Betrieb sicher.
In der Stammorganisation sind im Speziellen die folgenden Rollengruppen mit der Nachhal-
tigkeit konfrontiert:
o Beurteilen die Einhaltung der Vorgaben und die Erreichung der Nachhaltigkeitsziele.
o Prüfen das Produktkonzept.
o Prüfen die Lösungsarchitektur.
 Homogene Architekturen sollen ermöglichen, den Betrieb und die Weiterentwick-
lung von Systemen langfristig zu sichern.
 Leitung
o Priorisiert die Projekte im Portfolio auch mittels Kriterien, die die Nachhaltigkeit be-
rücksichtigen.
o Prüft, ob die Vorgaben und Ziele der Nachhaltigkeit mit dem Projekt realistisch erreicht
werden können.
7.4.3 Projektmanagement und Entwicklungsmanagement

7.4.3.1 Projektmanagement
Wie die Abbildung 32 zeigt, unterscheidet HERMES zwischen einem klassischen und hybriden
Projektmanagement.
HINWEISE ZUR
ANWENDUNG
Klassisches Projektmanagement

Umsetzung
Hybrides Projektmanagement
Abbildung 32: HERMES bietet klassisches und hybrides Projektmanagement an
174 / 200
Dadurch kann die Lösungsentstehung klassisch, agil und (für Spezialfälle) auch hybrid ange-
gangen werden:
 Das klassische Projektmanagement unterstützt das klassische Entwicklungsmanagement;
 Das hybride Projektmanagement unterstützt das agile und hybride Entwicklungsmanage-
ment. Es ist eine Kombination von klassischem Projektmanagement und agilem Entwick-
lungsvorgehen.
7.4.3.2 Entwicklungsmanagement agil

Agile Entwicklungsmethoden gehören nicht zu den Projektmanagementmethoden, sondern
zu Entwicklungsmanagementmethoden. Weil Projekte unter HERMES von Anfang an gewisse
Rahmenbedingungen erfüllen müssen, wie z. B. die Einhaltung der Governance, die reibungs-
lose Einbettung des Vorhabens in die bestehenden Planungs- und Controlling Prozesse der
Stammorganisation (Grundmission von HERMES) oder die gemeinsame Sprache bzw. einheit-
liche Terminologie, erfüllt eine blosse agile Entwicklung diese an HERMES gestellten Anforde-
rungen nicht. Deshalb wird die agile Methode in ein dafür geeignetes hybrides Projektma-
nagement eingebettet.
Die Abbildung 33 zeigt den hybriden Teil des HERMES-Phasenmodells mit agilem Entwick-
lungsmanagement.
Hybrides Projektmanagement
Initialisierung Umsetzung Abschluss
Agiles Entwicklungsmanagement
Abbildung 33: Phasenmodell mit agiler Entwicklung
Das Rollenverständnis im hybriden Projektmanagement lehnt sich sowohl an das klassische

Projektmanagement als auch an die agilen Entwicklungsmethoden an. Der Auftraggeber samt
Projektausschuss und Qualitäts- und Risikomanager auf der Hierarchieebene Steuerung und
der Projektleiter samt Fachausschuss und Projektunterstützung auf der Hierarchieebene Füh-
rung arbeiten entsprechend dem klassischen Projektmanagement; das Entwicklungsteam auf
der Hierarchieebene Ausführung mit den agilen Techniken. Der Anwendervertreter nimmt
eine zusätzliche Schnittstellenfunktion ein.
7.4.3.3 Entwicklungsmanagement hybrid

Die Entwicklung im Projekt, also die Lösungsentstehung, kann entweder mit der klassischen
oder mit der agilen Vorgehensweise abgewickelt werden. Dennoch gibt es in der Praxis Fälle,
in denen ein Projekt mit einer Kombination aus beiden Vorgehensweisen abgewickelt wird.
Da alle Methodenelemente aufeinander abgestimmt sind, unterstützt HERMES-Projektma-
nagement auch diese "hybride" Vorgehensweise. Allerdings setzt dies ein entsprechendes Tai-
loring am Ende der Initialisierungsphase voraus, denn das Hybride muss den jeweiligen Be-
dürfnissen angepasst werden. Abbildung 34 zeigt zwei denkbare Varianten eines hybriden
Entwicklungsvorgehens.
Hybride Variante 1 Konzept Realisierung Einführung
Hybride Variante 2 Umsetzung
Abbildung 34: Hybrides Entwicklungsvorgehen - Beispielvarianten
7.4.4 Finanzielle Steuerung und Führung

HINWEISE ZUR
7.4.4.1 Allgemeines
ANWENDUNG
Die finanzielle Steuerung und Führung des Projekts beginnt mit dem Entscheid Projektinitia-
lisierungsfreigabe und endet mit dem Entscheid Projektabschluss, allenfalls mit dem Entscheid
Projektabbruch.
175 / 200
7.4.4.2 Finanzierung
Die Stammorganisation stellt als Inhaberin des Projekts die finanziellen Ressourcen für das
Projekt zur Verfügung. Die Phase Initialisierung stellt eine Vorleistung für das gesamte Vorha-
ben dar und wird durch das Projekt- oder über das Linienbudget finanziert. In die Wirtschaft-
lichkeitsbetrachtung des Projekts fliessen die Aufwände der Phase Initialisierung als Vorleis-
tung ein.
Die Planung des Ressourcenbedarfs und der Finanzierung erfolgt für das Gesamtprojekt. In
der Phase Initialisierung wird eine Gesamtplanung erstellt, die laufend überprüft und ange-
passt wird. Bei klassischer Vorgehensweise sollen am Ende der Konzeptphase die Investitions-
und Betriebskosten verbindlich bekannt sein. Dabei werden auch die Kosten für die Deckung
von Projektrisiken berücksichtigt.
Bei agiler Vorgehensweise hingegen werden Kennzahlen zu den Betriebskosten von Release
zu Release sukzessive konkretisiert und releaseweise rapportiert. Die zu erwartenden Investi-
tionskosten bzw. das gesamte Budget für die Lösungsentstehung zuzüglich jenes für die Ab-
schlussphase sind im Durchführungsauftrag grundsätzlich fix definiert.
Die Betriebskosten werden während der Projektabwicklung über das Projektbudget finanziert,
anschliessend über das Linienbudget.
7.4.4.3 Steuerung
Mit dem Entscheid Durchführungsfreigabe wird das für die Durchführung benötigte Investiti-
onsbudget durch die Stammorganisation bewilligt. Der Auftraggeber übernimmt hierfür die
Verantwortung und gibt bei der klassischen Vorgehensweise die finanziellen Ressourcen pha-
senweise frei. Diese Freigabe wird über die Entscheidungsaufgaben zur Phasenfreigabe ge-
steuert.
Bei der agilen Vorgehensweise erübrigt sich eine stufenweise Freigabe von Finanzen. Diese
sind für die Lösungsentstehung fix oder als Kostendach definiert und werden einmalig mit
dem Durchführungsauftrag freigegeben. Im Rahmen der agilen Entwicklung wird mittels
Burn-Down-Diagramm der geschätzte restliche Aufwand dem tatsächlich verbleibenden Auf-
wand gegenübergestellt und mittels Releasebericht kommuniziert.
Der Auftraggeber ist für die finanzielle Steuerung verantwortlich und stellt die Wirtschaftlich-
keit des Projekts sicher. Entsprechend steuert er die Projektkosten und die zukünftigen Be-
triebskosten. Er erhält über das Reporting alle notwendigen Informationen, um den Projekt-
stand und die Kostenentwicklung beurteilen zu können. Da im agilen Umfeld das Budget fix
definiert ist, wird die finanzielle Kontrolle und Projekterfolg durch andere Instrumente gemes-
sen und gesichert.
Zur Unterstützung der Steuerung beauftragt der Auftraggeber bei Bedarf einen unabhängi-
gen Qualitäts- und Risikomanager.
Die finanzielle Führung des Projekts obliegt dem Projektleiter. Er führt eine Projektbuchhal-
tung und liefert Informationen an die Steuerung.
Mit der Aufgabe Änderungen managen stellt der Projektleiter sicher, dass Änderungen von
Anforderungen und des Umfangs sowie ihre Auswirkungen auf Kosten, Personalbedarf und
Termine rechtzeitig identifiziert, analysiert, beantragt und entschieden werden. Die Planung
wird entsprechend angepasst.
7.4.5 Planung
7.4.5.1 Planungsbasis und das Vorgehen
HINWEISE ZUR
ANWENDUNG
Die Planung bildet die Grundlage für den effektiven und effizienten Einsatz der im Projekt
benötigten Ressourcen. Sie ist die Voraussetzung für die Führung und Steuerung des Projekts.
Sie unterstützt die Kommunikation und die Abstimmung der Aktivitäten unter den Projektbe-
teiligten.
176 / 200
Nach der Erarbeitung der Studie mit den Zielen und dem Entscheid Weiteres Vorgehen in der
Phase Initialisierung ist der erste Schritt in der Durchführungsplanung die Durchführungs-
strukturierung. Der Projektleiter wählt dazu das passende Szenario gemäss Entscheid Weiteres
Vorgehen in HERMES-Online aus. Das Szenario mit seinen Methodenelementen gibt eine
grundlegende Struktur vor, die für die Lösungsentstehung übernommen und an die projekt-
spezifische Realität angepasst wird.
Die Ergebnisse der Planung werden im Projektmanagementplan festgehalten. Er ist das zent-
rale Instrument für die Führung des Projekts und umfasst alle Pläne, die im Projekt anfallen.
Er wird in der Phase Initialisierung erstellt und in nachfolgenden Phasen laufend nachgeführt.
Nach dem Entscheid Durchführungsfreigabe trennen sich die Wege, in dem die Planung klas-
sisch bzw. agil angegangen wird. In der klassischen Lösungsentstehung wird durch den Pro-
jektleiter nach dem Prinzip der rollenden Planung geplant, in der agilen Lösungsentstehung
erfolgt die weitere Planung autonom durch das Entwicklungsteam.
7.4.5.2 Initiale Planung der Lösungsentstehung

In der Phase Initialisierung wird die Fortsetzung des Projekts geplant. Die Durchführungsstruk-
turierung wird erstellt und die Ergebnisse des weiteren Projektverlaufs werden auf der Grund-
lage der Studie definiert. Die personellen und finanziellen Ressourcen werden nur so detailliert
geplant, dass die Verfügbarkeit für das gesamte Projekt sichergestellt werden kann.
Zuerst wird nach dem folgenden Vorgehen der Durchführungsstrukturplan erarbeitet:
1. Studie erarbeiten, für die Lösungsentstehung den Umfang und die Abgrenzung festhalten.
2. In HERMES-Online:
a. Szenario wählen und bei Bedarf anpassen (im Rahmen der Studie).
b. Durchführungsstrukturplan erstellen und exportieren.
c. Durchführungsstrukturplan in den Projektmanagementplan integrieren.
3. Lösungsspezifische Ergebnisse und Aufgaben ergänzen.
4. Rollen im Projektmanagementplan an das Szenario anpassen.
Anschliessend wird der Projektmanagementplan mit den folgend aufgeführten Schritten er-
arbeitet – sie müssen nicht zwingend in dieser Reihenfolge unternommen und können mehr-
mals durchlaufen werden:
 Risikomanagement festlegen;
 QS-Plan und Prüfplan erarbeiten;
 Aufwandschätzungen für Ergebnisse vornehmen;
 Abhängigkeiten ermitteln;
 Terminplan erarbeiten (ggf. auch Releaseplan vorsehen (agil));
o Ressourcen mit der Aufgabe Leistungen vereinbaren und steuern für die Dauer des
gesamten Projekts sicherstellen;
o Qualifikation und Verfügbarkeit der Ressourcen bei Schätzungen von Aufwand und
Dauer berücksichtigen;
o Dauer der Aufgaben schätzen;
 Einsatz von Ressourcen planen;
 Kommunikationsplan erarbeiten;
 Kostenplan erarbeiten;
 Projektmanagementplan mit QS-Massnahme prüfen;
 Projektmanagementplan mit Stakeholdern abstimmen und als Grundlage für Durchfüh-
rungsauftrag verifizieren.
HINWEISE ZUR
ANWENDUNG
177 / 200
7.4.5.3 Planung der klassischen Lösungsentstehung
Vom Groben zum Detail
Die Unterscheidung nach Phasen und die Konkretisierung und Erweiterung der Vorgehens-
komponente "vom Groben zum Detail" kommt aus dem Systems Engineering10 und ist eine
der Grundlagen der klassischen phasenweisen Vorgehensweise von HERMES. In der
klassischen Lösungsentstehung wird nach dem Prinzip der rollenden Planung geplant, ge-
steuert und geführt. Gegen Ende der Phasen Konzept und Realisierung wird jeweils die
nächste Phase vor dem Entscheid zur Phasenfreigabe detailliert geplant, und die grobe Pla-
nung wird überprüft.
Detailplanung der nächsten Phase
Die folgenden Aktivitäten werden ausgeführt:
 Durchführungsstrukturplan überprüfen und Aufgaben und Ergebnisse vervollständigen;
 Aufgaben und Ergebnisse konkretisieren;
 Arbeitspakete der nächsten Phase definieren und Verantwortliche pro Arbeitspaket fest-
legen;
 Aktivitäten und Ergebnisse der Arbeitspakete konkretisieren;
 Aufwandschätzungen auf der Grundlage der Arbeitspakete verifizieren;
 Ressourcenplanung konkretisieren;
 Terminplan der Phase konkretisieren;
 Entscheidungsplan erarbeiten;
 Prüfplan konkretisieren;
 Kommunikationsplan konkretisieren;
 Risikoliste und Massnahmen nachführen;
 Gesamtplan verifizieren;
 Projektmanagementplan mit QS-Massnahme prüfen;
 Projektmanagementplan mit Stakeholdern abstimmen.
Planung und Steuerung mit Arbeitspaketen
Die Detailplanung einer klassischen Phase erfolgt auf der Grundlage von Arbeitspaketen. Sie
sind eine Voraussetzung für die Kontrolle und Steuerung des Projekts. Für Arbeitspakete gel-
ten die folgenden Hinweise:
 Aus einer Aufgabe können mehrere Arbeitspakete gebildet werden.
 Aus einem Arbeitspaket resultieren ein oder mehrere Ergebnisse. Sie werden in Aktivitäten
erarbeitet. Bei der Erstellung eines Arbeitspaketauftrags werden die beschriebenen Akti-
vitäten weiter verfeinert.
 Die Ergebnisse sind bei Abschluss des Arbeitspakets den im Prüfplan oder im Testkonzept
definierten QS-Massnahmen unterzogen worden und sind abgenommen.
 Ein Verantwortlicher wird mit einem Arbeitspaket beauftragt. In einem Arbeitspaket kön-
nen mehrere Personen mitarbeiten.
 Typischerweise dauert ein Arbeitspaket zwischen zwei und sechs Wochen.
Planungsgenauigkeit im Projektablauf
Am Anfang des Projekts sind die Kenntnisse einer potenziellen Lösung keinesfalls gleich Null.
Bereits zu Anfang der Initialisierungsphase ist eine Planung mit nur geringer Genauigkeit
möglich. Mit dem phasenweisen Vorgehen bzw. dem Vorgehen vom Groben zum Detail wer-
den die Ergebnisse laufend konkretisiert. Entsprechend steigen die Kenntnisse, die Unsicher-
heit im weiteren Projektverlauf sinkt und die Planungsgenauigkeit steigt. Die steigenden
HINWEISE ZUR
ANWENDUNG
Kenntnisse (mit der Detaillierung der Ergebnisse) und die Planungsgenauigkeit stehen in ei-
nem direkten Zusammenhang. Die zu einem bestimmten Zeitpunkt zu erreichende Planungs-
genauigkeit gibt vor, wie detailliert die Ergebnisse erarbeitet werden sollen.
Die Abbildung 35 zeigt die mit dem Projektverlauf steigenden Kenntnisse über die Lösung
sowie die abnehmende Ungenauigkeit der Planung.
10 Vgl. Fussnote 2, S. 9
178 / 200
hoch
gering
Zeit
Abbildung 35: Steigende Kenntnisse / abnehmende Planungsungenauigkeit
HERMES kann nicht vorgeben, wie detailliert die Planung zu einem bestimmten Zeitpunkt im
Projektverlauf sein soll, weil dies stark von der jeweiligen Situation, der Charakteristik des Pro-
jekts und seiner Komplexität abhängt. Diese Vorgabe soll durch den Auftraggeber und die
Controlling- und Vorgabestellen der Stammorganisation geleistet werden.
Grundsätzlich sollen Schätzungen mit Angabe der Planungsgenauigkeit und darauf basierend
mit Reserven im Durchführungsauftrag sowie im Projektmanagementplan ausgewiesen wer-
den. Dazu müssen die Annahmen zu den Schätzungen dokumentiert sein, um die Anforde-
rung der Governance an die transparente Kommunikation zu erfüllen.
7.4.5.4 Planung der agilen Lösungsentstehung

In der agilen Lösungsentstehung kommen andere Mechanismen zum Tragen, der Aspekt vom
Groben zum Detail spielt sich im Rahmen der iterativen Abwicklung ab und erfolgt auf der
Hierarchieebene Ausführung autonom durch das Entwicklungsteam. Die agile Releaseplanung
ist mit dem Terminplan im Projektmanagementplan verknüpft. Projektseitig beschränkt sich
die Planung auf der Führungsebene auf koordinierende Aspekte und wird erst wieder in der
Phase Abschluss aktiviert.
7.4.6 Realisierungseinheiten bei klassischer Vorgehensweise

Wenn die klassisch abgewickelte Lösungsentstehung eines IT-Vorhabens so komplex wird,
dass die Realisierung des ganzen Umfangs fraglich erscheint, oder wenn möglichst schnell
erste Ergebnisse für die Nutzung geliefert werden sollen, können die Phasen Realisierung und
Einführung in mehreren Realisierungseinheiten abgewickelt werden.
Die klassische Vorgehensweise von HERMES-Projektmanagement ermöglicht sowohl die se-
quenzielle wie auch die zeitlich überlappte oder parallele Entwicklung in Realisierungseinhei-
ten. Die Freigabe der ersten Realisierungseinheit ist die Phasenfreigabe Realisierung, die den
regulären Abschluss der Phase Konzept voraussetzt. Jede Realisierungseinheit erstreckt sich
über die beiden Phasen Realisierung und Einführung.
HINWEISE ZUR
Eine Realisierungseinheit umfasst alle technischen und organisatorischen Ergebnisse des Pro-
ANWENDUNG
jekts, die für die Einführung des Systems oder eines Teils davon benötigt werden. Am Ende
einer Realisierungseinheit wird das Produkt bzw. das System produktiv genutzt.
179 / 200
Die Abbildung 36 zeigt schematisch zeitlich verschobene Realisierungseinheiten als eigen-
ständige Kontrolleinheiten mit jeweils der Phase Realisierung und Einführung.
Phasenfreigabe
Realisierungseinheit 1 Abschluss
Initialisierung Konzept Realisierung Einführung
Realisierungseinheit 2
Realisierung Einführung
Realisierungseinheit 3
Realisierung Einführung
Realisierungseinheit n
Realisierung Einführung Abschluss
Realisierungseinheiten
Projektdauer
Abbildung 36: Zeitlich verschobene Realisierungseinheiten bei klassischer Vorgehensweise
Bei Realisierungseinheiten müssen die folgenden Punkte beachtet werden:

 Die Phasen Initialisierung und Konzept werden vollständig durchlaufen. Nach der Phase
Konzept können Realisierungseinheiten gestartet werden. Ab diesem Zeitpunkt spielt sich
das Projekt in den Phasen und Meilensteinen der jeweiligen Realisierungseinheit ab. Es
gibt kein übergeordnetes Phasenmodell.
 Die Anzahl der Realisierungseinheiten ist durch HERMES nicht begrenzt, aber die Dauer
des Projekts soll nicht unbegrenzt sein. Deshalb werden die Realisierungseinheiten in der
Phase Konzept gesamthaft geplant.
 Jede Realisierungseinheit umfasst die Phasen Realisierung und Einführung. Jede Realisie-
rungseinheit durchläuft die Entscheidungsaufgaben der Steuerung und Führung.
 Der Start einer Realisierungseinheit muss durch die Projektsteuerung freigegeben werden.
Dazu muss ein aktualisierter Projektmanagementplan vorliegen.
 Realisierungseinheiten werden aus Sicht des Controllings bezüglich Kosten, Terminen und
Ergebnissen separat geplant und kontrolliert. Sie bilden eigenständige Kontrolleinheiten.
Entsprechend soll das Reporting auf die Realisierungseinheiten ausgerichtet sein.
 Sinnvollerweise können am Ende jeder Realisierungseinheit eine Schlussbeurteilung der
Realisierungseinheit erstellt und die Erfahrungen dokumentiert und genutzt werden.
Vorausgesetzt, dass jede Realisierungseinheit mit einer formellen Phasenfreigabe beendet
werden konnte, wird am Ende der letzten Realisierungseinheit über die effektive Freigabe der
nächsten Phase Abschluss entschieden. In der Phase Abschluss werden entsprechende Auf-
gaben und Ergebnissen durchgeführt. Dies umfasst auch die Projektschlussbeurteilung sämt-
licher Realisierungseinheiten.
7.4.7 Anwendung mit anderen Methoden und Praktiken

HERMES definiert die Ergebnisse und den generellen Ablauf des Projektes. Es gibt nicht vor,
welche Methoden und Praktiken für die Erarbeitung der Ergebnisse eingesetzt werden sollen.
Im Projektverlauf kommen somit ergänzend zu HERMES fachspezifische Methoden und Prak-
tiken zum Einsatz (vgl. Abbildung 37). Anwender, Ersteller und Betreiber legen diese fest und
stimmen sie mit den Aufgaben, Ergebnissen und Rollen gemäss HERMES ab.
HINWEISE ZUR
ANWENDUNG
180 / 200
Umsetzung
Methoden/Praktiken des Anwenders (z.B. BPMN oder INTERLIS)
Methoden/Praktiken des Erstellers (z.B. SCRUM)
Methoden/Praktiken des Betreibers (z.B. ITIL)
Abbildung 37: Einsatz von ergänzenden Methoden und Praktiken
Insofern ergeben sich für die Akteure, insbesondere im Rahmen der Lösungsentstehung, neue
Dimensionen, die die An- und Verwendbarkeit von HERMES universalisieren und dennoch den
einzelnen Methodenprotagonisten voll entgegenkommen. So kann z. B. der Anwender spezi-
fizieren, dass er für die konzeptionelle Datenmodellierung ein Opensourcetool nutzt, oder der
Entwickler für den Entwicklungsprozess die in seiner Stammorganisation favorisierte agile Ent-
wicklungsmethode zum Einsatz bringt.
Beim Einsatz von ergänzenden Methoden und Praktiken müssen die folgenden Punkte be-
achtet werden:
 Die Aufgaben, Ergebnisse und Rollen der Projektsteuerung und Projektführung basieren
immer auf HERMES und können nicht durch andere Methoden ersetzt werden.
 Das HERMES-Phasenmodell bleibt bestehen.
 Die Meilensteine sind gesetzt und können nicht verändert werden.
 Festlegungen zum Einsatz von Methoden und Praktiken werden im Projektmanagement-
plan festgehalten.
7.4.8 Integration von HERMES in die Stammorganisation

7.4.8.1 Allgemeines
Da jede Stammorganisation ihre spezifischen Eigenheiten hat, ist die Anpassung der Methode
an ihre Bedürfnisse oft unerlässlich und vorteilhaft für eine effiziente Projektabwicklung.
Mit der Integration von HERMES in die Stammorganisation werden folgende Ziele verfolgt:
 Spezifische Prozesse und Vorgaben der Stammorganisation, die HERMES nicht kennt, sind
berücksichtigt.
 Projektleiter, Anwendervertreter und weitere Projektbeteiligte werden noch besser unter-
stützt. Sie verfügen über einen organisationsspezifisch definierten Rahmen.
 Die Effizienz in der Projektabwicklung ist erhöht, da Prozesse und Vorgaben nicht mit je-
dem Projekt neu erfunden werden müssen.
 Mit der weitergehenden Integration von Praktiken in die Methode, von anderen Methoden
sowie von Hilfsmitteln wird die Qualität erhöht. Insbesondere die breit eigesetzten agilen
Entwicklungsmethoden werden ihrer Projektmanagementdefizite beraubt. Sie passen sich
dank HERMES voll der Organisation an.
 Die Schulung von HERMES kann mit den organisationsspezifischen Anpassungen erfolgen
und ist entsprechend wirksamer. In Bezug auf die Zertifizierung empfiehlt es sich, insbe-
sondere die Terminologie von HERMES nicht übermässig zu verändern.
7.4.8.2 Vorgehen
Die Integration von HERMES in die Stammorganisation erfolgt am besten über ein Projekt.
HINWEISE ZUR
ANWENDUNG
Das Projekt kann auf der Grundlage des Szenarios Dienstleistung/Produkt Adaption durchge-
führt werden. Dabei werden auch die Aspekte der Einführungsorganisation mit der Ausbil-
dung beachtet sowie die Organisation mit den Prozessen für Betrieb und Weiterentwicklung
des Projektmanagements erstellt und aktiviert.
Die Anpassung erfolgt durch das Kompetenzzentrum Projektmanagement.
181 / 200
7.4.8.3 Anpassung der Methode
Integration wichtiger Elemente in die Methode
Die Vorgaben der Stammorganisation werden in die Methode integriert, z. B.
 Vorgaben aus organisationsspezifischen Prozessen
 Entscheidungsprozess klassisch/agil, notwendige Entscheidungsgrundlagen
 Vorgaben sonstiger Entscheidungsprozesse
 Vorgaben des Reportings (Projektstatusbericht, Phasenbericht, Releasebericht)
 Vorgaben zu SLAs, Verträgen und Vereinbarungen
 Aspekte der Sicherheit und des Datenschutzes
 Aspekte der Lösungsarchitektur
Die spezifischen Methoden und Praktiken zur Ergebniserarbeitung werden in die Methode
integriert, z. B.
 Ergebnisdarstellungen des Requirement Engineerings
 Ergebnisdarstellungen der Datenmodellierung (z. B. mit INTERLIS, UML11)
 Ergebnisdarstellungen der Geschäftsprozessmodellierung (z. B. mit BPMN12)
 Einbettung der agilen Entwicklungsmethode (z. B. mit SCRUM)
 Praktiken zur Integration in den Betrieb (z. B. mit Hilfe von ITIL13)
Die Methodenelemente werden bei Bedarf angepasst. Dabei sollen die folgenden Punkte be-
achtet werden:
Phasen und Meilensteine
 Die definierten Phasen dürfen nicht entfallen, sie können aber unterteilt werden.
 Die Meilensteine dürfen nicht entfallen, richten sich aber nach der Vorgehensweise und
nach einer allfälligen Unterteilung der Phasen.
 Die Bezeichnungen der Methodenelemente sollen nicht geändert werden.
Ergebnisse mit Dokumentvorlagen und Aufgaben
 Minimal geforderte Dokumente (Ergebnisse) dürfen nicht entfallen.
 Mehrere Einzelergebnisse können zusammen in ein gemeinsames Dokument integriert
werden.
 Ergebnisse können aufgeteilt werden.
 Zusätzliche Ergebnisse können definiert werden.
 HERMES-Dokumentvorlagen können durch organisationsspezifische Dokumentvorlagen,
durch Dokumentvorlagen aus GEVER-Systemen14 oder durch andere Lösungen ersetzt
werden.
 Ergebnisse können in der Dokumentvorlage differenzierter beschrieben werden.
 Für ein Ergebnis können mehrere Dokumentvorlagen erstellt werden.
 Dokumentvorlagen sollen den in der Ergebnisbeschreibung der Methode definierten In-
halt umfassen, können aber erweitert und konkretisiert werden.
 Die zur Erarbeitung der Ergebnisse notwendigen neuen Aufgaben müssen beschrieben
werden.
HINWEISE ZUR
ANWENDUNG
11 Unified Modeling Language (UML), entworfen von der Object Management Group für die objektorientierte
Modellierung, ist eine grafische Beschreibungssprache zur Darstellung von Softwaresystemen wie Datenbank-
anwendungen, Echtzeitsystemen oder Workflowanwendungen.
12 Business Process Model and Notation (BPMN), entworfen von der Object Management Group, ist eine grafi-
sche Beschreibungssprache zur Erstellung von Geschäftsprozessmodellen, Flussdiagrammen und Workflows.
13 Information Technology Infrastructure Library (ITIL) ist ein IT-Service Management Framework bestehend aus
Best Practice-Prozessen zur Bereitstellung von IT-Services.
14 Abkürzung für "Geschäftsverwaltung“, wird im Verwaltungswesen für Workflow-Systeme mit elektronischer
Geschäfts- oder Aktenführung verwendet.
182 / 200
Module, Szenarien
 Es können neue Module und Szenarien erstellt werden.
 Die definierten HERMES-Szenarien und -Module können mit Ergebnissen und den dazu-
gehörigen Aufgaben erweitert, aber nicht reduziert werden. Wenn Ergebnisse oder Auf-
gaben aus einem Szenario oder Modul entfernt werden, ergibt sich daraus ein individuel-
les Szenario.
Rollen
 Rollen können differenzierter beschrieben werden, solange der wesentliche Aufgabenbe-
reich identisch ist.
 Weitere Rollen können definiert werden. Für jede neue Rolle ist eine Rollenbeschreibung
zwingend.
 Neue Rollen müssen einer der Hierarchieebenen und einer Partnergruppe zugeordnet
werden.
 Minimal zu besetzende Rollen sowie deren Zugehörigkeit zur Partnergruppe Anwender
dürfen nicht verändert werden.
Checklisten
 Der Inhalt aller Checklisten kann beliebig angepasst und erweitert werden.
 Checklisten, die in Entscheidungsaufgaben beschrieben sind, können nicht entfallen.
 Es können zusätzlich auch separate individuelle Checklisten definiert werden.
Nachdem organisationsspezifische Anpassungen durchgeführt wurden, werden Szenarien für
Projekte mit gleicher Charakteristik erstellt.
HINWEISE ZUR
ANWENDUNG
183 / 200
Anhang A – Inhaltsverzeichnis
Vorwort ........................................................................................................................................................................ 1
HERMES-Evolution .................................................................................................................................................................... 1
Impressum .................................................................................................................................................................. 2
Prolog........................................................................................................................................................................... 3
«Kleine Taten, die man ausführt, sind besser als grosse, die man plant.» ..........................................................................3
HERMES im neuen Kleid ........................................................................................................................................... 5
A Methodenüberblick .................................................................................................. 6
A.1 HERMES-Projektmanagement – Big Picture ..................................................................... 6
A.2 Was ist HERMES-Projektmanagement?.............................................................................. 8
A.3 Durch HERMES unterstützte Projektgrössen..................................................................... 8
A.4 Nutzung des HERMES-Projektmanagements in der Praxis ........................................... 9
A.5 Die Schnittstellen des HERMES-Projektmanagements .................................................. 10
A.6 Agiles Entwicklungsmanagement mit HERMES ............................................................... 10
A.7 Positionierung Programmmanagement ............................................................................ 11
A.8 Hinweise zur Anwendung ..................................................................................................... 11
B HERMES-Projektmanagement-Methodenelemente .......................................12
B.1 Phasen ........................................................................................................................................ 12
B.2 Szenarien ................................................................................................................................... 12
B.3 Module ....................................................................................................................................... 13
B.4 Ergebnisse ................................................................................................................................. 13
B.5 Aufgaben ................................................................................................................................... 14
B.6 Rollen .......................................................................................................................................... 14
B.7 Projektmanagement ............................................................................................................... 15
C Datenmodell HERMES ............................................................................................16
1 Phasen ........................................................................................................................17
1.1 Einleitung ................................................................................................................................... 17
1.1.1 Projektlebenszyklus ................................................................................................................... 17
1.1.2 Projektbeginn............................................................................................................................. 17
1.1.3 Lösungsentstehung................................................................................................................... 18
1.1.4 Projektende ................................................................................................................................ 18
1.2 Übersicht der Phasen ............................................................................................................. 19
1.2.1 HERMES-Phasenmodell ........................................................................................................... 19
1.2.2 Einheitliche Projektstruktur ...................................................................................................... 19
1.2.3 Phasenverlauf ............................................................................................................................ 20
1.3 Erläuterung der Phasenbeschreibung ................................................................................ 21
1.4 Beschreibung der Phasen...................................................................................................... 21
1.4.1 Projektbeginn............................................................................................................................. 21
1.4.1.1 Initialisierung ......................................................................................................................... 21
1.4.2 Lösungsentstehung klassisch ................................................................................................. 22
1.4.2.1 Konzept.................................................................................................................................. 22
1.4.2.2 Realisierung .......................................................................................................................... 22
1.4.2.3 Einführung............................................................................................................................. 23
1.4.3 Lösungsentstehung agil .......................................................................................................... 23
1.4.3.1 Umsetzung............................................................................................................................ 23
1.4.4 Projektende ............................................................................................................................... 24
1.4.4.1 Abschluss............................................................................................................................... 24
2 Szenarien .................................................................................................................. 25
2.1 Einleitung .................................................................................................................................. 25
2.2 Übersicht der Szenarien........................................................................................................ 25
2.2.1 Aufbau der Szenarien .............................................................................................................. 25
2.2.2 Standardszenarien ................................................................................................................... 26
2.2.3 Individuelle Szenarien.............................................................................................................. 26
2.2.3.1 Anpassung der Szenarien ................................................................................................. 26
185 / 200
2.2.3.2 Sizing ...................................................................................................................................... 27
2.2.3.3 Tailoring ................................................................................................................................. 27
2.3 Erläuterung der Szenario-Beschreibung .......................................................................... 28
2.4 Szenarien-Verzeichnis ........................................................................................................... 28
2.4.1 Dienstleistung/Produkt-Szenarien ......................................................................................... 28
2.4.1.1 Dienstleistung/Produkt Entwicklung .............................................................................. 28
2.4.1.2 Dienstleistung/Produkt Adaption ................................................................................... 29
2.4.2 Informatik-Szenarien ................................................................................................................ 30
2.4.2.1 IT-Entwicklung...................................................................................................................... 30
2.4.2.2 IT-Adaption ........................................................................................................................... 30
2.4.3 Organisation-Szenarien ........................................................................................................... 31
2.4.3.1 Organisationsanpassung.................................................................................................... 31
3 Module...................................................................................................................... 32
3.1 Einleitung.................................................................................................................................. 32
3.2 Übersicht der Module ........................................................................................................... 32
3.2.1 Standardmodule ....................................................................................................................... 32
3.2.2 Individuelle Module .................................................................................................................. 33
3.3 Erläuterung der Modulbeschreibung ................................................................................ 33
3.4 Beschreibung der Module ................................................................................................... 33
3.4.1 Module zur Steuerung und Führung ..................................................................................... 33
3.4.1.1 Projektsteuerung ................................................................................................................. 33
3.4.1.2 Projektführung ..................................................................................................................... 34
3.4.2 Module zur Ausführung ........................................................................................................... 35
3.4.2.1 Projektgrundlagen .............................................................................................................. 35
3.4.2.2 Beschaffung .......................................................................................................................... 36
3.4.2.3 Organisation ......................................................................................................................... 36
3.4.2.4 Produkt .................................................................................................................................. 37
3.4.2.5 IT-System............................................................................................................................... 38
3.4.2.6 Tests ........................................................................................................................................ 38
3.4.2.7 Einführungsorganisation ................................................................................................... 39
3.4.2.8 IT-Migration .......................................................................................................................... 39
3.4.2.9 IT-Betrieb ............................................................................................................................... 40
3.4.2.10 ISDS ......................................................................................................................................... 40
4 Ergebnisse ................................................................................................................ 42
4.1 Einleitung.................................................................................................................................. 42
4.2 Übersicht der Ergebnisse ..................................................................................................... 42
4.2.1 Standardergebnisse .................................................................................................................. 42
4.2.1.1 Standarddokumente .......................................................................................................... 42
4.2.1.2 Standardzustände ............................................................................................................... 43
4.2.2 Individuelle Ergebnisse............................................................................................................. 43
4.3 Erläuterung der Ergebnisbeschreibung ............................................................................ 43
4.4 Beschreibung der Ergebnisse .............................................................................................. 44
4.4.1 Dokumente ................................................................................................................................ 44
4.4.1.1 Abnahmeprotokoll .............................................................................................................. 44
4.4.1.2 Änderungsantrag ................................................................................................................ 44
4.4.1.3 Änderungsstatusliste .......................................................................................................... 45
4.4.1.4 Angebot ................................................................................................................................. 45
4.4.1.5 Angebotsprotokoll .............................................................................................................. 45
4.4.1.6 Anwendungshandbuch ..................................................................................................... 45
4.4.1.7 Arbeitsauftrag ...................................................................................................................... 46
4.4.1.8 Ausschreibungsunterlagen ............................................................................................... 46
4.4.1.9 Beschaffungsanalyse .......................................................................................................... 47
4.4.1.10 Betriebshandbuch ............................................................................................................... 48
4.4.1.11 Betriebskonzept ................................................................................................................... 48
4.4.1.12 Checklisten ............................................................................................................................ 49
 Checkliste Abnahme........................................................................................................... 49
 Checkliste Abnahme Migration ....................................................................................... 49
 Checkliste Ausschreibung ................................................................................................. 49
 Checkliste Betriebsaufnahme ........................................................................................... 49
 Checkliste Durchführungsfreigabe ................................................................................. 49
 Checkliste ISDS-Konzept ................................................................................................... 49
 Checkliste Lösungsarchitektur ......................................................................................... 49
 Checkliste Phasenfreigabe ................................................................................................ 49
186 / 200
 Checkliste Phasenfreigabe Abschluss ............................................................................ 49
 Checkliste Produktkonzept............................................................................................... 49
 Checkliste Projektabbruch ................................................................................................ 49
 Checkliste Projektabschluss.............................................................................................. 50
 Checkliste Projektinitialisierungsfreigabe ..................................................................... 50
 Checkliste Releasefreigabe ............................................................................................... 50
 Checkliste Vorabnahme .................................................................................................... 50
 Checkliste Weiteres Vorgehen ........................................................................................ 50
 Checkliste Zuschlag ............................................................................................................ 50
4.4.1.13 Detailspezifikation............................................................................................................... 50
4.4.1.14 Durchführungsauftrag ........................................................................................................ 51
4.4.1.15 Einführungskonzept ............................................................................................................ 51
4.4.1.16 Evaluationsbericht ............................................................................................................... 52
4.4.1.17 Geschäftsmodellbeschreibung ........................................................................................ 52
4.4.1.18 Integrations- und Installationsanleitung ....................................................................... 53
4.4.1.19 Integrationskonzept ........................................................................................................... 53
4.4.1.20 ISDS-Konzept ....................................................................................................................... 53
4.4.1.21 Liste Projektentscheide Führung..................................................................................... 54
4.4.1.22 Liste Projektentscheide Steuerung ................................................................................. 54
4.4.1.23 Lösungsanforderungen ..................................................................................................... 54
4.4.1.24 Lösungsarchitektur ............................................................................................................. 55
4.4.1.25 Migrationskonzept.............................................................................................................. 56
4.4.1.26 Offertanfrage........................................................................................................................ 56
4.4.1.27 Organisationsanforderungen .......................................................................................... 56
4.4.1.28 Organisationsbeschreibung ............................................................................................. 57
4.4.1.29 Organisationskonzept........................................................................................................ 57
4.4.1.30 Phasenbericht ...................................................................................................................... 58
4.4.1.31 Produktdokumentation ..................................................................................................... 58
4.4.1.32 Produktkonzept ................................................................................................................... 58
4.4.1.33 Projekterfahrungen............................................................................................................. 59
4.4.1.34 Projektinitialisierungsauftrag ........................................................................................... 59
4.4.1.35 Projektmanagementplan .................................................................................................. 59
4.4.1.36 Projektschlussbeurteilung ................................................................................................. 60
4.4.1.37 Projektstatusbericht ............................................................................................................. 61
4.4.1.38 Protokoll ................................................................................................................................. 61
4.4.1.39 Prototypdokumentation .................................................................................................... 62
4.4.1.40 Prozessbeschreibung ......................................................................................................... 62
4.4.1.41 Prüfprotokoll ........................................................................................................................ 62
4.4.1.42 Publikation ............................................................................................................................ 63
4.4.1.43 QS- und Risikobericht ........................................................................................................ 63
4.4.1.44 Rechtsgrundlagenanalyse ................................................................................................. 63
4.4.1.45 Releasebericht ...................................................................................................................... 63
4.4.1.46 Schutzbedarfsanalyse ........................................................................................................ 64
4.4.1.47 Service Level Agreement .................................................................................................. 64
4.4.1.48 Situationsanalyse................................................................................................................. 65
4.4.1.49 Stakeholderinteressen ....................................................................................................... 65
4.4.1.50 Stakeholderliste ................................................................................................................... 66
4.4.1.51 Studie ..................................................................................................................................... 66
4.4.1.52 Systemkonzept .................................................................................................................... 67
4.4.1.53 Testkonzept .......................................................................................................................... 67
4.4.1.54 Testprotokoll ........................................................................................................................ 68
4.4.1.55 Vereinbarung ....................................................................................................................... 68
4.4.2 Zustände .................................................................................................................................... 68
4.4.2.1 Altsystem entfernt............................................................................................................... 68
4.4.2.2 Betrieb aktiviert.................................................................................................................... 69
4.4.2.3 Betriebsinfrastruktur realisiert.......................................................................................... 69
4.4.2.4 Betriebsorganisation realisiert ......................................................................................... 69
4.4.2.5 Einführungsmassnahmen durchgeführt ....................................................................... 69
4.4.2.6 Einführungsmassnahmen realisiert ................................................................................ 69
4.4.2.7 ISDS-Konzept überführt .................................................................................................... 69
4.4.2.8 ISDS-Massnahmen realisiert ............................................................................................ 69
4.4.2.9 Meilensteine ......................................................................................................................... 69
 Meilenstein Abnahme ........................................................................................................ 70
 Meilenstein Abnahme Migration .................................................................................... 70
 Meilenstein Ausschreibung .............................................................................................. 70
 Meilenstein Betriebsaufnahme ........................................................................................ 70
 Meilenstein Durchführungsfreigabe .............................................................................. 70
 Meilenstein ISDS-Konzept ................................................................................................ 70
 Meilenstein Lösungsarchitektur ...................................................................................... 70
 Meilenstein Phasenfreigabe ............................................................................................. 70
187 / 200
 Meilenstein Phasenfreigabe Abschluss ......................................................................... 70
 Meilenstein Produktkonzept ............................................................................................ 70
 Meilenstein Projektabschluss ........................................................................................... 70
 Meilenstein Projektinitialisierungsfreigabe................................................................... 70
 Meilenstein Releasefreigabe ............................................................................................ 70
 Meilenstein Vorabnahme .................................................................................................. 70
 Meilenstein Weiteres Vorgehen ....................................................................................... 71
 Meilenstein Zuschlag .......................................................................................................... 71
4.4.2.10 Migration durchgeführt ...................................................................................................... 71
4.4.2.11 Migrationsverfahren realisiert ........................................................................................... 71
4.4.2.12 Organisation aktiviert .......................................................................................................... 71
4.4.2.13 Organisation umgesetzt ..................................................................................................... 71
4.4.2.14 Produkt aktiviert ................................................................................................................... 71
4.4.2.15 Produkt entwickelt oder angepasst................................................................................. 71
4.4.2.16 Prototyp realisiert ................................................................................................................. 71
4.4.2.17 Schnittstellen realisiert ....................................................................................................... 72
4.4.2.18 System aktiviert.................................................................................................................... 72
4.4.2.19 System entwickelt oder parametrisiert .......................................................................... 72
4.4.2.20 System integriert ................................................................................................................. 72
4.4.2.21 Testinfrastruktur realisiert ................................................................................................. 72
4.4.2.22 Testinfrastruktur überführt ............................................................................................... 72
5 Aufgaben.................................................................................................................. 73
5.1 Einleitung.................................................................................................................................. 73
5.1.1 Aufgabenpositionierung .......................................................................................................... 73
5.1.2 Entscheidungsaufgaben........................................................................................................... 73
5.1.2.1 Generell .................................................................................................................................. 73
5.1.2.2 Entscheide der Steuerung................................................................................................. 73
5.1.2.3 Entscheide der Führung .................................................................................................... 73
5.2 Übersicht der Aufgaben ....................................................................................................... 74
5.2.1 Standardaufgaben .................................................................................................................... 74
5.2.2 Individuelle Aufgaben .............................................................................................................. 77
5.3 Erläuterung der Aufgabenbeschreibung ......................................................................... 77
5.4 Beschreibung der Aufgaben ............................................................................................... 78
5.4.1 Entscheidungsaufgaben der Steuerung ................................................................................ 78
5.4.1.1 Entscheid Ausschreibung treffen .................................................................................... 78
5.4.1.2 Entscheid Betriebsaufnahme treffen .............................................................................. 78
5.4.1.3 Entscheid Durchführungsfreigabe treffen .................................................................... 79
5.4.1.4 Entscheid Phasenfreigabe Abschluss treffen ............................................................... 80
5.4.1.5 Entscheid Phasenfreigabe treffen .................................................................................... 81
5.4.1.6 Entscheid Projektabbruch treffen ................................................................................... 82
5.4.1.7 Entscheid Projektabschluss treffen ................................................................................. 84
5.4.1.8 Entscheid Projektinitialisierungsfreigabe treffen ........................................................ 85
5.4.1.9 Entscheid Releasefreigabe treffen .................................................................................. 86
5.4.1.10 Entscheid Zuschlag treffen ............................................................................................... 87
5.4.2 Entscheidungsaufgaben der Führung ................................................................................... 88
5.4.2.1 Entscheid Abnahme Migration treffen .......................................................................... 88
5.4.2.2 Entscheid Abnahme treffen .............................................................................................. 88
5.4.2.3 Entscheid ISDS-Konzept treffen ...................................................................................... 89
5.4.2.4 Entscheid Lösungsarchitektur treffen ............................................................................ 90
5.4.2.5 Entscheid Produktkonzept treffen .................................................................................. 90
5.4.2.6 Entscheid Vorabnahme treffen......................................................................................... 91
5.4.2.7 Entscheid Weiteres Vorgehen treffen ............................................................................ 92
5.4.3 Sonstige Aufgaben ................................................................................................................... 93
5.4.3.1 Altsystem ausser Betrieb setzen...................................................................................... 93
5.4.3.2 Änderungen managen....................................................................................................... 94
5.4.3.3 Angebote bewerten ........................................................................................................... 95
5.4.3.4 Ausschreibung durchführen ............................................................................................. 95
5.4.3.5 Ausschreibung erarbeiten................................................................................................. 96
5.4.3.6 Beschaffungsanalyse erarbeiten...................................................................................... 97
5.4.3.7 Betrieb aktivieren ................................................................................................................ 98
5.4.3.8 Betrieb realisieren ............................................................................................................... 99
5.4.3.9 Betriebskonzept erarbeiten ............................................................................................ 100
5.4.3.10 Durchführungsauftrag erarbeiten .................................................................................. 101
5.4.3.11 Einführungskonzept erarbeiten ...................................................................................... 101
5.4.3.12 Einführungsmassnahmen durchführen ....................................................................... 103
5.4.3.13 Einführungsmassnahmen realisieren ........................................................................... 103
188 / 200
5.4.3.14 Integrationskonzept erarbeiten......................................................................................104
5.4.3.15 ISDS-Konzept erarbeiten .................................................................................................104
5.4.3.16 ISDS-Konzept realisieren..................................................................................................105
5.4.3.17 ISDS-Konzept überführen................................................................................................106
5.4.3.18 Leistungen vereinbaren und steuern ............................................................................106
5.4.3.19 Lösungsanforderungen erarbeiten ...............................................................................108
5.4.3.20 Lösungsarchitektur erarbeiten........................................................................................109
5.4.3.21 Migration durchführen ..................................................................................................... 110
5.4.3.22 Migrationskonzept erarbeiten ......................................................................................... 111
5.4.3.23 Migrationsverfahren realisieren ..................................................................................... 112
5.4.3.24 Organisation aktivieren .................................................................................................... 112
5.4.3.25 Organisation umsetzen .................................................................................................... 113
5.4.3.26 Organisationsanforderungen erarbeiten ..................................................................... 114
5.4.3.27 Organisationskonzept erarbeiten .................................................................................. 115
5.4.3.28 Phasenfreigabe vorbereiten ............................................................................................ 116
5.4.3.29 Probleme behandeln und Erfahrungen nutzen ......................................................... 117
5.4.3.30 Produkt aktivieren .............................................................................................................. 117
5.4.3.31 Produkt realisieren ............................................................................................................. 118
5.4.3.32 Produktkonzept erarbeiten ............................................................................................. 119
5.4.3.33 Projekt führen und kontrollieren ...................................................................................120
5.4.3.34 Projekt steuern.................................................................................................................... 121
5.4.3.35 Projektabschluss vorbereiten ..........................................................................................122
5.4.3.36 Projektmanagementplan erarbeiten .............................................................................123
5.4.3.37 Prototyping durchführen .................................................................................................125
5.4.3.38 Qualitätssicherung führen ...............................................................................................125
5.4.3.39 Rechtsgrundlagenanalyse erarbeiten ...........................................................................126
5.4.3.40 Releaseabschluss vorbereiten .........................................................................................127
5.4.3.41 Risiken managen ................................................................................................................128
5.4.3.42 Schutzbedarfsanalyse erarbeiten ...................................................................................129
5.4.3.43 Stakeholder managen und informieren.......................................................................129
5.4.3.44 Stakeholderinteressen vertreten ....................................................................................130
5.4.3.45 Studie erarbeiten ................................................................................................................ 131
5.4.3.46 System aktivieren ...............................................................................................................133
5.4.3.47 System in Betrieb integrieren .........................................................................................133
5.4.3.48 System realisieren ..............................................................................................................134
5.4.3.49 Systemintegration vorbereiten .......................................................................................135
5.4.3.50 Test durchführen ................................................................................................................135
5.4.3.51 Testinfrastruktur realisieren .............................................................................................136
5.4.3.52 Testinfrastruktur überführen ...........................................................................................137
5.4.3.53 Testkonzept erarbeiten ....................................................................................................137
5.4.3.54 Vereinbarung erarbeiten ..................................................................................................138
6 Rollen ....................................................................................................................... 140
6.1 Einleitung ................................................................................................................................ 140
6.1.1 Rollenmodell ............................................................................................................................ 140
6.1.2 Stammorganisation ................................................................................................................. 140
6.1.3 Projektorganisation ................................................................................................................. 141
6.1.3.1 Übersicht .............................................................................................................................. 141
6.1.3.2 Partnergruppen .................................................................................................................. 141
6.1.3.3 Hierarchieebenen ...............................................................................................................142
6.1.3.4 Projektrollen in Programmen .........................................................................................142
6.2 Übersicht der Rollen ............................................................................................................ 144
6.2.1 Standardrollen ......................................................................................................................... 144
6.2.2 Individuelle Rollen ................................................................................................................... 145
6.2.3 Rollenbesetzung ...................................................................................................................... 145
6.2.3.1 Allgemeine Erläuterungen ...............................................................................................145
6.2.3.2 Steuerung.............................................................................................................................146
6.2.3.3 Führung ................................................................................................................................146
6.2.3.4 Ausführung ..........................................................................................................................147
6.3 Erläuterung der Rollenbeschreibung .............................................................................. 147
6.4 Beschreibung der Rollen .................................................................................................... 148
6.4.1 Steuerungsrollen ..................................................................................................................... 148
6.4.1.1 Auftraggeber .......................................................................................................................148
6.4.1.2 Projektausschuss ................................................................................................................150
6.4.1.3 Qualitäts- und Risikomanager ........................................................................................ 151
6.4.2 Führungsrollen ......................................................................................................................... 151
6.4.2.1 Fachausschuss ..................................................................................................................... 151
189 / 200
6.4.2.2 Projektleiter ......................................................................................................................... 152
6.4.2.3 Projektunterstützung........................................................................................................ 155
6.4.2.4 Teilprojektleiter .................................................................................................................. 155
6.4.3 Ausführungsrollen................................................................................................................... 156
6.4.3.1 Anwendervertreter ............................................................................................................ 156
6.4.3.2 Betriebsverantwortlicher ................................................................................................. 158
6.4.3.3 Business Analyst ................................................................................................................ 159
6.4.3.4 Entwickler ............................................................................................................................ 160
6.4.3.5 Entwicklungsteam .............................................................................................................. 161
6.4.3.6 ISDS-Verantwortlicher...................................................................................................... 162
6.4.3.7 IT-Architekt ......................................................................................................................... 162
6.4.3.8 Tester .................................................................................................................................... 163
6.4.3.9 Testverantwortlicher ......................................................................................................... 163
7 Hinweise zur Anwendung ................................................................................... 165
7.1 Einleitung................................................................................................................................. 165
7.2 Übersicht der Hinweise ........................................................................................................ 165
7.3 Erläuterung der Hinweise-Beschreibung ........................................................................ 165
7.4 Beschreibung der Hinweise ................................................................................................ 165
7.4.1 Governance .............................................................................................................................. 165
7.4.1.1 Projekt-Governance.......................................................................................................... 165
7.4.1.2 Umsetzung von bedeutenden Veränderungen ........................................................ 166
7.4.1.3 Nachvollziehbarkeit der gewählten Vorgehensweise ............................................. 166
7.4.1.4 Selbstbestimmung der Anwender über das Projekt................................................ 167
7.4.1.5 Integration in das Portfolio............................................................................................. 167
7.4.1.6 Reporting............................................................................................................................. 168
7.4.1.7 Erfüllung der Anforderungen der Projekt-Governance .......................................... 169
7.4.2 Nachhaltigkeit .......................................................................................................................... 172
7.4.2.1 Nachhaltigkeitsverständnis ............................................................................................. 172
7.4.2.2 Nachhaltigkeit mit HERMES ........................................................................................... 172
7.4.3 Projektmanagement und Entwicklungsmanagement ....................................................... 174
7.4.3.1 Projektmanagement ......................................................................................................... 174
7.4.3.2 Entwicklungsmanagement agil...................................................................................... 175
7.4.3.3 Entwicklungsmanagement hybrid ................................................................................ 175
7.4.4 Finanzielle Steuerung und Führung ..................................................................................... 175
7.4.4.1 Allgemeines ........................................................................................................................ 175
7.4.4.2 Finanzierung ....................................................................................................................... 176
7.4.4.3 Steuerung ............................................................................................................................ 176
7.4.5 Planung ..................................................................................................................................... 176
7.4.5.1 Planungsbasis und das Vorgehen ................................................................................ 176
7.4.5.2 Initiale Planung der Lösungsentstehung .................................................................... 177
7.4.5.3 Planung der klassischen Lösungsentstehung ............................................................ 178
7.4.5.4 Planung der agilen Lösungsentstehung ..................................................................... 179
7.4.6 Realisierungseinheiten bei klassischer Vorgehensweise................................................... 179
7.4.7 Anwendung mit anderen Methoden und Praktiken ......................................................... 180
7.4.8 Integration von HERMES in die Stammorganisation.......................................................... 181
7.4.8.1 Allgemeines ......................................................................................................................... 181
7.4.8.2 Vorgehen .............................................................................................................................. 181
7.4.8.3 Anpassung der Methode ................................................................................................ 182
Anhang A – Inhaltsverzeichnis ............................................................................................. 185
Anhang B – Abbildungsverzeichnis..................................................................................... 191
Anhang C – Tabellenverzeichnis .......................................................................................... 192
Anhang D – Vokabular ........................................................................................................... 193
Phasen – Phases – Fasi – Phases .......................................................................................................... 193
Szenarien – Scénarios – Scenari – Scenarios..................................................................................... 193
Module – Modules – Moduli – Modules ............................................................................................ 193
Ergebnisse – Résultats – Risultati – Outcomes ................................................................................. 194
Aufgaben – Tâches – Compiti – Tasks ................................................................................................ 197
Rollen – Rôles – Ruoli – Roles ............................................................................................................... 199
Index der HERMES-Projektmanagementmethodenelemente .................................................................. 201
190 / 200
Anhang B – Abbildungsverzeichnis
Abbildung 1: Gesamtbild der HERMES-Module und der wesentlichen Ergebnisse entlang
der Phasen................................................................................................................................... 6
Abbildung 2: Die drei obersten Methodenelemente der HERMES-Methode .................................... 8
Abbildung 3: Die Funktionalität von HERMES-Projektmanagement in der Praxis ............................ 9
Abbildung 4: Gleichzeitiges Führen von Projekten und Programmen in einer
Stammorganisation .................................................................................................................. 11
Abbildung 5: HERMES-Projektlebenszyklus mit Phasenmodell für klassische und agile
Vorgehensweise ....................................................................................................................... 12
Abbildung 6: Projekte einer Stammorganisation mit Szenarien .......................................................... 13
Abbildung 7: Modul setzt sich aus Ergebnissen und Aufgaben zusammen ..................................... 13
Abbildung 8: Ergebnisse stehen im Zentrum von HERMES .................................................................. 14
Abbildung 9: Phasen und Releases mit Meilensteinen als Quality Gates .......................................... 14
Abbildung 10: Minimal zu besetzenden Rollen Auftraggeber, Projektleiter und
Anwendervertreter .................................................................................................................. 15
Abbildung 11: Diagramm des Datenmodells HERMES ............................................................................. 16
Abbildung 12: HERMES-Projektlebenszyklus ............................................................................................... 17
Abbildung 13: Ergebnisdiagramm der Phase Initialisierung .................................................................... 17
Abbildung 14: HERMES-Phasenmodell für klassische und agile Vorgehensweise ............................ 19
Abbildung 15: Meilensteine am Beginn und am Ende jeder Phase und bei der
Releasefreigabe........................................................................................................................ 19
Abbildung 16: Meilensteine für klassische und agile IT-Entwicklungsprojekte .................................. 20
Abbildung 17: Wahl und Anwendung des für das Projekt geeigneten Szenarios ............................. 25
Abbildung 18: Mehrere Module mit Aufgaben und Ergebnissen als Basis für ein Szenario .......... 25
Abbildung 19: Anwendung von Standard- und benutzerdefinierten Szenarien ............................... 28
Abbildung 20: Module im Kontext des Szenarios Dienstleistung/Produkt Entwicklung .................. 29
Abbildung 21: Module im Kontext des Szenarios Dienstleistung/Produkt Adaption ....................... 29
Abbildung 22: Module im Kontext des Szenarios IT-Entwicklung ......................................................... 30
Abbildung 23: Module im Kontext des Szenarios IT-Adaption .............................................................. 31
Abbildung 24: Module im Kontext des Szenarios Organisationsanpassung ...................................... 31
Abbildung 25: Standardmässig verfügbare HERMES-Module im Gesamtkontext ............................ 32
Abbildung 26: Stammorganisation sowie Projektorganisation mit minimal erforderlichen
Rollen (grau) ........................................................................................................................... 140
Abbildung 27: Rollenzuordnung zu Hierarchieebenen einer klassischen oder agilen
Projektorganisation ............................................................................................................... 142
Abbildung 28: Projekte zu Programmen zusammengefasst ................................................................. 143
Abbildung 29: Drei mögliche Grundvarianten der Projektorganisation ............................................. 143
Abbildung 30: Zwei übliche Möglichkeiten der organisatorischen Zuordnung des Portfolios .... 168
Abbildung 31: Gekapselte, gegenüber der Stammorganisation einheitliche Reporting
Struktur..................................................................................................................................... 169
Abbildung 32: HERMES bietet klassisches und hybrides Projektmanagement an .......................... 174
Abbildung 33: Phasenmodell mit agiler Entwicklung .............................................................................. 175
Abbildung 34: Hybrides Entwicklungsvorgehen - Beispielvarianten ................................................... 175
Abbildung 35: Steigende Kenntnisse / abnehmende Planungsungenauigkeit ................................ 179
Abbildung 36: Zeitlich verschobene Realisierungseinheiten bei klassischer Vorgehensweise ..... 180
Abbildung 37: Einsatz von ergänzenden Methoden und Praktiken ..................................................... 181
191 / 200
Anhang C – Tabellenverzeichnis
Tabelle 1: HERMES-Phasen für Projekte mit klassischer und agiler Lösungsentstehung ................19
Tabelle 2: Standardszenarien für Projekte verschiedener Charakteristiken samt Modulen ........... 26
Tabelle 3: Standardmodule den Projektphasen zugeordnet ................................................................. 32
Tabelle 4: Aufgaben und Ergebnisse Modul Projektsteuerung ............................................................. 34
Tabelle 5: Aufgaben und Ergebnisse Modul Projektführung ................................................................. 35
Tabelle 6: Aufgaben und Ergebnisse Modul Projektgrundlagen .......................................................... 36
Tabelle 7: Aufgaben und Ergebnisse Modul Beschaffung ...................................................................... 36
Tabelle 8: Aufgaben und Ergebnisse Modul Organisation ..................................................................... 37
Tabelle 9: Aufgaben und Ergebnisse Modul Produkt .............................................................................. 37
Tabelle 10: Aufgaben und Ergebnisse Modul IT-System........................................................................... 38
Tabelle 11: Aufgaben und Ergebnisse Modul Tests .................................................................................... 39
Tabelle 12: Aufgaben und Ergebnisse Modul Einführungsorganisation ............................................... 39
Tabelle 13: Aufgaben und Ergebnisse Modul IT-Migration ...................................................................... 40
Tabelle 14: Aufgaben und Ergebnisse Modul IT-Betrieb ........................................................................... 40
Tabelle 15: Aufgaben und Ergebnisse Modul ISDS ......................................................................................41
Tabelle 16: Ergebnisübersicht – Dokumente ................................................................................................ 43
Tabelle 17: Ergebnisübersicht – Zustände ..................................................................................................... 43
Tabelle 18: Zuordnung aller Aufgaben samt entsprechender Ergebnisse zu Projektphasen .......... 77
Tabelle 19: Rollen und deren Zuordnung zur Hierarchieebene und zur Partnergruppe................ 145
Tabelle 20: Aufgaben, die der Auftraggeber verantwortet und weitere an der
Ergebniserstellung beteiligte Rollen ........................................................................................ 150
Tabelle 21: Aufgaben, die der Projektleiter verantwortet und weitere an der
Tabelle 22: Aufgaben, die der Anwendervertreter verantwortet und weitere an der
Tabelle 23: Aufgaben, die der Betriebsverantwortliche verantwortet und weitere an der
Tabelle 24: Aufgaben, die der Business Analyst verantwortet und weitere an der
Tabelle 25: Aufgaben, die der Entwickler verantwortet und weitere an der Ergebniserstellung
beteiligte Rollen ............................................................................................................................. 161
Tabelle 26: Aufgaben, die der ISDS-Verantwortliche verantwortet und weitere an der
Tabelle 27: Aufgaben, die der IT-Architekt verantwortet und weitere an der
Tabelle 28: Aufgaben, die der Testverantwortliche verantwortet und weitere an der
Tabelle 29: Hinweise zur Anwendung pro Kategorie ............................................................................... 165
Tabelle 30: Vokabular HERMES-Phasen 4-sprachig.................................................................................. 193
Tabelle 31: Vokabular HERMES-Szenarien 4-sprachig ............................................................................. 193
Tabelle 32: Vokabular HERMES-Module 4-sprachig................................................................................. 193
Tabelle 33: Vokabular HERMES-Ergebnisse 4-sprachig ........................................................................... 196
Tabelle 34: Vokabular HERMES-Aufgaben 4-sprachig............................................................................. 198
Tabelle 35: Vokabular HERMES-Rollen 4-sprachig ................................................................................... 199
192 / 200
Anhang D – Vokabular
Phasen – Phases – Fasi – Phases
Deutsch Française Italiano English
Phasen Phases Fasi Phases
1.4.4.1 Abschluss Clôture Conclusione Closure 24
1.4.2.3 Einführung Déploiement Introduzione Deployment 23
1.4.1.1 Initialisierung Initialisation Avvio Initiation 21
1.4.2.1 Konzept Conception Progettazione Concept 22
1.4.2.2 Realisierung Réalisation Realizzazione Implementation 22
1.4.3.1 Umsetzung Mise en œuvre Attuazione Execution 23
Tabelle 30: Vokabular HERMES-Phasen 4-sprachig
Szenarien – Scénarios – Scenari – Scenarios

Szenarien Scénarios Scenari Scenarios
2.4.1.2 Dienstleistung/Pro- Adaptation de la presta- Adeguamento del servi- Service/product adapta- 29
dukt Adaption tion/du produit zio / prodotto tion
2.4.1.1 Dienstleistung/Pro- Développement de la Sviluppo del servizio / Service/product develop- 28
dukt Entwicklung prestation/du produit prodotto ment
2.4.2.2 IT-Adaption Adaptation IT Adeguamento IT IT adaptation 30
2.4.2.1 IT-Entwicklung Développement IT Sviluppo IT IT development 30
2.4.3.1 Organisationsanpassung Adaptation de l’organisa- Adeguamento dell’orga- Organizational adjust- 31
tion nizzazione ment
Tabelle 31: Vokabular HERMES-Szenarien 4-sprachig
Module – Modules – Moduli – Modules

Module Modules Moduli Modules
3.4.2.2 Beschaffung Achat Acquisto Procurement 36
3.4.2.7 Einführungsorganisation Organisation du déploie- Organizzazione dell’int- Deployment organization 39
ment roduzione
3.4.2.10 ISDS SIPD SIPD ISDP 40
3.4.2.9 IT-Betrieb Exploitation informatique Esercizio IT IT operation 40
3.4.2.8 IT-Migration Migration informatique Migrazione IT IT migration 39
3.4.2.5 IT-System Système informatique Sistema IT IT system 38
3.4.2.3 Organisation Organisation Organizzazione Organization 36
3.4.2.4 Produkt Produit Prodotto Product 37
3.4.1.2 Projektführung Conduite du projet Gestione del progetto Project management 34
3.4.2.1 Projektgrundlagen Bases du projet Basi del progetto Project foundations 35
3.4.1.1 Projektsteuerung Pilotage du projet Conduzione del progetto Project steering 33
3.4.2.6 Tests Tests Test Tests 38
Tabelle 32: Vokabular HERMES-Module 4-sprachig
193 / 200
Ergebnisse – Résultats – Risultati – Outcomes
Ergebnisse Résultats Risultati Outcomes
4.4.1.1 Abnahmeprotokoll Procès-verbal de récep- Verbale di accettazione Acceptance report 44
tion
4.4.2.1 Altsystem entfernt Ancien système mis hors Vecchio sistema disin- Legacy system removed 68
service stallato
4.4.1.2 Änderungsantrag Demande de modifica- Domanda di modifica Change request 44
tion
4.4.1.3 Änderungsstatusliste Liste de l’état des modifi- Lista Stato delle modifi- Change status list 45
cations che
4.4.1.4 Angebot Offre Offerta Offer 45
4.4.1.5 Angebotsprotokoll Procès-verbal des offres Verbale dell’offerta Tender report 45
4.4.1.6 Anwendungshandbuch Manuel d’utilisation Manuale d’uso User manual 45
4.4.1.7 Arbeitsauftrag Mandat de travail Mandato di lavoro Work order 46
4.4.1.8 Ausschreibungsunterla- Dossier d’appel d’offres Documentazione del Tender documentation 46
gen bando di concorso
4.4.1.9 Beschaffungsanalyse Analyse de l’appel d’off- Analisi dell’acquisto Procurement analysis 47
res
4.4.2.2 Betrieb aktiviert Exploitation activée Esercizio attivato Operation activated 69
4.4.1.10 Betriebshandbuch Manuel d’exploitation Manuale di esercizio Operating manual 48
4.4.2.3 Betriebsinfrastruktur rea- Infrastructure d’exploita- Infrastruttura di esercizio Operating infrastructure 69
lisiert tion réalisée realizzata realized
4.4.1.11 Betriebskonzept Concept d’exploitation Piano di esercizio Operating concept 48
4.4.2.4 Betriebsorganisation rea- Organisation de l’exploi- Organizzazione di eser- Operating organization 69
lisiert tation réalisée cizio realizzata realized
4.4.1.12 Checkliste Abnahme Liste de contrôle Récep- Lista di controllo Ac- Acceptance checklist 49
tion cettazione
4.4.1.12 Checkliste Abnahme Liste de contrôle Récep- Lista di controllo Accetta- Migration acceptance 49
Migration tion de la migration zione della migrazione checklist
4.4.1.12 Checkliste Ausschreibung Liste de contrôle Appel Lista di controllo Bando Tender checklist 49
d’offres di concorso
4.4.1.12 Checkliste Betriebsauf- Liste de contrôle Mise en Lista di controllo Messa Launch of operation 49
nahme service in esercizio checklist
4.4.1.12 Checkliste Durchfüh- Liste de contrôle Libéra- Lista di controllo Via li- Execution release check- 49
rungsfreigabe tion de l’exécution bera all'esecuzione list
4.4.1.12 Checkliste ISDS-Konzept Liste de contrôle Concept Lista di controllo Piano ISDP concept checklist 49
SIPD SIPD
4.4.1.12 Checkliste Lösungsarchi- Liste de contrôle Archi- Lista di controllo Archi- Solution architecture 49
tektur tecture de la solution tettura della soluzione checklist
4.4.1.12 Checkliste Phasenfrei- Liste de contrôle Libéra- Lista di controllo Via li- Phase release checklist 49
gabe tion de la phase bera alla fase
4.4.1.12 Checkliste Phasenfrei- Liste de contrôle Libéra- Lista di controllo Via li- Closure phase release 49
gabe Abschluss tion de la phase de clô- bera alla fase Conclu- checklist
ture sione
4.4.1.12 Checkliste Produktkon- Liste de contrôle Concept Lista di controllo Proget- Product concept checklist 49
zept du produit tazione del prodotto
4.4.1.12 Checkliste Projektab- Liste de contrôle Inter- Lista di controllo Interru- Project discontinuation 49
bruch ruption du projet zione del progetto checklist
4.4.1.12 Checkliste Projektab- Liste de contrôle Clôture Lista di controllo Conclu- Project closure checklist 50
schluss du projet sione del progetto
4.4.1.12 Checkliste Projektinitiali- Liste de contrôle Libéra- Lista di controllo Via li- Project initiation release 50
sierungsfreigabe tion de l’initialisation du bera all'avvio del pro- checklist
projet getto
4.4.1.12 Checkliste Releasefrei- Liste de contrôle Libéra- Lista di controllo Via li- Release checklist 50
gabe tion du release bera al rilascio
4.4.1.12 Checkliste Vorabnahme Liste de contrôle Lista di controllo Accetta- Preliminary acceptance 50
Préréception zione preliminare checklist
4.4.1.12 Checkliste Weiteres Vor- Liste de contrôle Suite du Lista di controllo Conti- Next steps checklist 50
gehen projet nuazione
4.4.1.12 Checkliste Zuschlag Liste de contrôle Adjudi- Lista di controllo Aggiu- Contract award checklist 50
cation dicazione
4.4.1.12 Checklisten Listes de contrôle Liste di controllo Checklists 49
4.4.1.13 Detailspezifikation Spécification détaillée Specifica dettagliata Detailed specifications 50
4.4.1.14 Durchführungsauftrag Mandat d’exécution Mandato di esecuzione Execution order 51
4.4.1.15 Einführungskonzept Concept de déploiement Progettazione dell’intro- Deployment concept 51
duzione
194 / 200
4.4.2.5 Einführungsmassnahmen Mesures de déploiement Misure d’introduzione Deployment measures 69
durchgeführt effectuées attuate carried out
4.4.2.6 Einführungsmassnahmen Mesures de déploiement Misure d’introduzione Deployment measures 69
realisiert réalisées realizzate realized
4.4.1.16 Evaluationsbericht Rapport d’évaluation Rapporto di valutazione Evaluation report 52
4.4.1.17 Geschäftsmodellbe- Description du modèle Descrizione del modello Business model descrip- 52
schreibung d’affaires operativo tion
4.4.1.18 Integrations- und Instal- Guide d’intégration et Guida per l’integrazione Integration and installa- 53
lationsanleitung d’installation e l’installazione tion instructions
4.4.1.19 Integrationskonzept Concept d’intégration Progettazione dell’in- Integration concept 53
tegrazione
4.4.1.20 ISDS-Konzept Concept SIPD Piano SIPD ISDP concept 53
4.4.2.7 ISDS-Konzept überführt Concept SIPD transféré Piano SIPD trasferito ISDP concept transferred 69
4.4.2.8 ISDS-Massnahmen reali- Mesures SIPD réalisées Misure SIPD realizzate ISDP measures realized 69
siert
4.4.1.21 Liste Projektentscheide Liste Décisions de Lista Decisioni di ge- List of management pro- 54
Führung conduite stione del progetto ject decisions
4.4.1.22 Liste Projektentscheide Liste Décisions de pilo- Lista Decisioni di condu- List of steering project 54
Steuerung tage zione del progetto decisions
4.4.1.23 Lösungsanforderungen Exigences envers la solu- Requisiti della soluzione Solution requirements 54
tion
4.4.1.24 Lösungsarchitektur Architecture de la solu- Architettura della soluzi- Solution architecture 55
tion one
4.4.2.9 Meilenstein Abnahme Jalon Réception Pietra miliare Accettazi- Acceptance milestone 70
one
4.4.2.9 Meilenstein Abnahme Jalon Réception de la mi- Pietra miliare Accetta- Migration acceptance 70
Migration gration zione della migrazione milestone
4.4.2.9 Meilenstein Ausschrei- Jalon Appel d’offres Pietra miliare Gara d’ap- Tender milestone 70
bung palto
4.4.2.9 Meilenstein Betriebsauf- Jalon Mise en service Pietra miliare Messa in Launch of operation mi- 70
nahme esercizio lestone
4.4.2.9 Meilenstein Durchfüh- Jalon Libération de Pietra miliare Via libera Execution release miles- 70
rungsfreigabe l’exécution all'esecuzione tone
4.4.2.9 Meilenstein ISDS-Kon- Jalon Concept SIPD Pietra miliare Piano SIPD ISDP concept milestone 70
zept
4.4.2.9 Meilenstein Lösungsar- Jalon Architecture de la Pietra miliare Architet- Solution architecture mi- 70
chitektur solution tura della soluzione lestone
4.4.2.9 Meilenstein Phasenfrei- Jalon Libération de la Pietra miliare Via libera Phase release milestone 70
gabe phase alla fase
4.4.2.9 Meilenstein Phasenfrei- Jalon Libération de la Pietra miliare Via libera Closure phase release 70
gabe Abschluss phase de clôture alla fase Conclusione milestone
4.4.2.9 Meilenstein Produktkon- Jalon Concept du produit Pietra miliare Progetta- Product concept miles- 70
zept zione del prodotto tone
4.4.2.9 Meilenstein Projektab- Jalon Clôture du projet Pietra miliare Conclu- Project closure milestone 70
schluss sione del progetto
4.4.2.9 Meilenstein Projektinitia- Jalon Libération de l’ini- Pietra miliare Via libera Project initiation release 70
lisierungsfreigabe tialisation du projet all'avvio del progetto milestone
4.4.2.9 Meilenstein Releasefrei- Jalon Libération du re- Pietra miliare Via libera Release milestone 70
gabe lease al rilascio
4.4.2.9 Meilenstein Vorabnahme Jalon Préréception Pietra miliare Accettazi- Preliminary acceptance 70
one preliminare milestone
4.4.2.9 Meilenstein Weiteres Jalon Suite du projet Pietra miliare Conti- Next steps milestone 71
Vorgehen nuazione
4.4.2.9 Meilenstein Zuschlag Jalon Adjudication Pietra miliare Aggiudi- Contract award miles- 71
cazione tone
4.4.2.9 Meilensteine Jalons Pietra miliare Milestones 69
4.4.2.10 Migration durchgeführt Migration effectuée Migrazione effettuata Migration carried out 71
4.4.1.25 Migrationskonzept Concept de migration Progettazione della mig- Migration concept 56
razione
4.4.2.11 Migrationsverfahren rea- Procédure de migration Procedura di migrazione Migration procedure rea- 71
lisiert réalisée realizzata lized
4.4.1.26 Offertanfrage Demande d’offres Domanda di offerta Quote request 56
4.4.2.12 Organisation aktiviert Organisation activée Organizzazione attivata Organization activated 71
4.4.2.13 Organisation umgesetzt Organisation mise en Organizzazione attuata Organization implemen- 71
œuvre ted
4.4.1.27 Organisationsanforde- Exigences organisati- Requisiti dell’organiz- Organizational require- 56
rungen onnelles zazione ments
195 / 200
4.4.1.28 Organisationsbeschrei- Description de l’organi- Descrizione dell’organiz- Organization description 57
bung sation zazione
4.4.1.29 Organisationskonzept Concept d’organisation Progettazione dell’orga- Organization concept 57
nizzazione
4.4.1.30 Phasenbericht Rapport de phase Rapporto di fase Phase report 58
4.4.2.14 Produkt aktiviert Produit activé Prodotto attivato Product activated 71
4.4.2.15 Produkt entwickelt oder Produit développé ou Prodotto sviluppato o a- Product developed or 71
angepasst adapté deguato adapted
4.4.1.31 Produktdokumentation Documentation du pro- Documentazione del Product documentation 58
duit prodotto
4.4.1.32 Produktkonzept Concept du produit Progettazione del pro- Product concept 58
dotto
4.4.1.33 Projekterfahrungen Expériences acquises Esperienze acquisite Lessons learned 59
4.4.1.34 Projektinitialisierungs- Mandat d’initialisation Mandato di avvio del Project initiation order 59
auftrag du projet progetto
4.4.1.35 Projektmanagementplan Plan de gestion du projet Piano di gestione pro- Project management 59
gettuale plan
4.4.1.36 Projektschlussbeurtei- Evaluation finale du pro- Valutazione finale del Final project evaluation 60
lung jet progetto
4.4.1.37 Projektstatusbericht Rapport sur l’état du Rapporto sullo stato del Project status report 61
projet progetto
4.4.1.38 Protokoll Procès-verbal Verbale Minutes 61
4.4.2.16 Prototyp realisiert Prototype réalisé Prototipo realizzato Prototype realized 71
4.4.1.39 Prototypdokumentation Documentation du pro- Documentazione del Prototype documenta- 62
totype prototipo tion
4.4.1.40 Prozessbeschreibung Description de processus Descrizione del processo Process description 62
4.4.1.41 Prüfprotokoll Procès-verbal de vérifica- Rapporto di verifica Review report 62
tion
4.4.1.42 Publikation Publication Pubblicazione Publication 63
4.4.1.43 QS- und Risikobericht Rapport sur la qualité et Rapporto Controllo qua- QA and risk report 63
les risques lità e rischi
4.4.1.44 Rechtsgrundlagenana- Analyse des bases léga- Analisi delle basi legali Legal basis analysis 63
lyse les
4.4.1.45 Releasebericht Rapport de release Rapporto di rilascio Release report 63
4.4.2.17 Schnittstellen realisiert Interfaces réalisées Interfacce realizzate Interfaces realized 72
4.4.1.46 Schutzbedarfsanalyse Analyse des besoins de Analisi delle esigenze di Protection needs analysis 64
protection protezione
4.4.1.47 Service Level Agreement Accord sur le niveau de Accordo sui livelli di ser- Service level agreement 64
service vizio
4.4.1.48 Situationsanalyse Analyse de la situation Analisi della situazione Situation analysis 65
4.4.1.49 Stakeholderinteressen Intérêts des parties pren- Interessi degli stakehol- Stakeholder interests 65
antes der
4.4.1.50 Stakeholderliste Liste des parties prenan- Lista Stakeholder (porta- Stakeholder list 66
tes tori di interessi)
4.4.1.51 Studie Étude Studio Study 66
4.4.2.18 System aktiviert Système activé Sistema attivato System activated 72
4.4.2.19 System entwickelt oder Système développé ou Sistema sviluppato o pa- System developed or pa- 72
parametrisiert paramétré rametrizzato rameterized
4.4.2.20 System integriert Système intégré Sistema integrato System integrated 72
4.4.1.52 Systemkonzept Concept du système Piano del sistema System concept 67
4.4.2.21 Testinfrastruktur reali- Infrastructure de test Infrastruttura di test rea- Test infrastructure reali- 72
siert réalisée lizzata zed
4.4.2.22 Testinfrastruktur über- Infrastructure de test Infrastruttura di test tras- Test infrastructure trans- 72
führt transférée ferita ferred
4.4.1.53 Testkonzept Concept de test Progettazione dei test Test concept 67
4.4.1.54 Testprotokoll Procès-verbal de test Verbale dei test Test report 68
4.4.1.55 Vereinbarung Accord Accordo Agreement 68
Tabelle 33: Vokabular HERMES-Ergebnisse 4-sprachig
196 / 200
Aufgaben – Tâches – Compiti – Tasks
Aufgaben Tâches Compiti Tasks
5.4.3.1 Altsystem ausser Betrieb Mettre l’ancien système Disattivare il vecchio sis- Decommission the le- 93
setzen hors service tema gacy system
5.4.3.2 Änderungen managen Gérer les modifications Gestire le modifiche Manage changes 94
5.4.3.3 Angebote bewerten Évaluer les offres Valutare le offerte Evaluate tenders 95
5.4.3.4 Ausschreibung durchfüh- Effectuer l’appel d’offres Pubblicare il bando di Issue call for tenders 95
ren concorso
5.4.3.5 Ausschreibung erarbei- Élaborer l’appel d’offres Elaborare il bando di Prepare call for tenders 96
ten concorso
5.4.3.6 Beschaffungsanalyse er- Élaborer l’analyse de Elaborare l’analisi Prepare procurement 97
arbeiten l’appel d’offres dell’acquisto analysis
5.4.3.7 Betrieb aktivieren Activer l’exploitation Attivare l’esercizio Activate operation 98
5.4.3.8 Betrieb realisieren Réaliser l’environnement Realizzare l’esercizio Realize operation 99
d’exploitation
5.4.3.9 Betriebskonzept erarbei- Élaborer le concept d’ex- Elaborare il piano di Design operating con- 100
ten ploitation esercizio cept
5.4.3.10 Durchführungsauftrag Élaborer le mandat Elaborare il mandato di Draw up project execu- 101
erarbeiten d’exécution esecuzione del progetto tion order
5.4.3.11 Einführungskonzept er- Élaborer le concept de Elaborare la progettazi- Design deployment con- 101
arbeiten déploiement one dell’introduzione cept
5.4.3.12 Einführungsmassnahmen Effectuer les mesures de Eseguire le misure d’int- Execute deployment 103
durchführen déploiement roduzione measures
5.4.3.13 Einführungsmassnahmen Réaliser les mesures de Realizzare le misure Realize deployment 103
realisieren déploiement d’introduzione measures
5.4.2.1 Entscheid Abnahme Mig- Décider de la réception Decisione Accettazione Decide on acceptance of 88
ration treffen de la migration della migrazione migration
5.4.2.2 Entscheid Abnahme tref- Décider de la réception Decisione Accettazione Decide on acceptance 88
fen
5.4.1.1 Entscheid Ausschreibung Décider de l’appel d’off- Decisione Bando di con- Decide on call for ten- 78
treffen res corso ders
5.4.1.2 Entscheid Betriebsauf- Décider de la mise en Decisione Messa in eser- Decide on launch of op- 78
nahme treffen service cizio eration
5.4.1.3 Entscheid Durchfüh- Décider de la libération Decisione Via Libera Decide on execution re- 79
rungsfreigabe treffen de l’exécution alll’esecuzione lease
5.4.2.3 Entscheid ISDS-Konzept Décider du concept SIPD Decisione Piano SIPD Decide on ISDP concept 89
treffen
5.4.2.4 Entscheid Lösungsarchi- Décider de l’architecture Decisione Architettura Decide on solution archi- 90
tektur treffen de la solution della soluzione tecture
5.4.1.4 Entscheid Phasenfrei- Décider de la libération Decisione Via libera alla Decide on closure phase 80
gabe Abschluss treffen de la phase de clôture fase Conclusione release
5.4.1.5 Entscheid Phasenfrei- Décider de la libération Decisione Via libera alla Decide on phase release 81
gabe treffen de la phase fase
5.4.2.5 Entscheid Produktkon- Décider du concept du Decisione Progettazione Decide on product con- 90
zept treffen produit del prodotto cept
5.4.1.6 Entscheid Projektab- Décider l’interruption du Decisione Interruzione Decide on project dis- 82
bruch treffen projet del progetto continuation
5.4.1.7 Entscheid Projektab- Décider de la clôture du Decisione Conclusione Decide on project closure 84
schluss treffen projet del progetto
5.4.1.8 Entscheid Projektinitiali- Décider de la libération Decisione Via libera Decide on project initia- 85
sierungsfreigabe treffen de l’initialisation du pro- all'avvio del progetto tion release
jet
5.4.1.9 Entscheid Releasefrei- Décider de la libération Decisione Via libera Decide on release 86
gabe treffen du release all'avvio del rilascio
5.4.2.6 Entscheid Vorabnahme Décider de la prérécep- Decisione Accettazione Decide on preliminary 91
treffen tion preliminare acceptance
5.4.2.7 Entscheid Weiteres Vor- Décider de la suite du Decisione Continuazione Decide on next steps 92
gehen treffen projet
5.4.1.10 Entscheid Zuschlag tref- Décider de l’adjudication Decisione Aggiudicazi- Decide on contract a- 87
fen one ward
5.4.3.14 Integrationskonzept er- Élaborer le concept Elaborare la progettazi- Design integration con- 104
arbeiten d’intégration one dell’integrazione cept
5.4.3.15 ISDS-Konzept erarbeiten Élaborer le concept SIPD Elaborare il piano SIPD Design ISDP concept 104
5.4.3.16 ISDS-Konzept realisieren Réaliser le concept SIPD Realizzare il piano SIPD Implement ISDP concept 105
5.4.3.17 ISDS-Konzept überfüh- Transférer le concept Trasferire il piano SIPD Transfer ISDP concept 106
ren SIPD
5.4.3.18 Leistungen vereinbaren Définir et piloter les Concordare e gestire le Agree on and steer 106
und steuern prestations prestazioni goods/services
197 / 200
Aufgaben Tâches Compiti Tasks
5.4.3.19 Lösungsanforderungen Élaborer les exigences Elaborare i requisiti della Prepare solution require- 108
erarbeiten envers la solution soluzione ments
5.4.3.20 Lösungsarchitektur erar- Élaborer l’architecture de Elaborare l’architettura Prepare solution archi- 109
beiten la solution della soluzione tecture
5.4.3.21 Migration durchführen Effectuer la migration Eseguire la migrazione Conduct migration 110
5.4.3.22 Migrationskonzept erar- Élaborer le concept de Elaborare la progetta- Design migration con- 111
beiten migration zione della migrazione cept
5.4.3.23 Migrationsverfahren rea- Réaliser la procédure de Realizzare la procedura Realize migration proce- 112
lisieren migration di migrazione dure
5.4.3.24 Organisation aktivieren Activer l’organisation Attivare l’organizzazione Activate organization 112
5.4.3.25 Organisation umsetzen Réaliser l’organisation Attuare l’organizzazione Implement organization 113
5.4.3.26 Organisationsanforde- Élaborer les exigences Elaborare i requisiti Establish organizational 114
rungen erarbeiten organisationnelles dell’organizzazione requirements
5.4.3.27 Organisationskonzept er- Élaborer le concept d’or- Elaborare la progettazi- Draw up organization 115
arbeiten ganisation one dell’organizzazione concept
5.4.3.28 Phasenfreigabe vorberei- Préparer la libération de Preparare il vial libera Prepare phase release 116
ten la phase alla fase
5.4.3.29 Probleme behandeln und Traiter les problèmes et Trattare i problemi e va- Deal with problems and 117
Erfahrungen nutzen mettre à profit les expé- lorizzare le esperienze benefit from lessons
riences learned
5.4.3.30 Produkt aktivieren Activer le produit Attivare il prodotto Activate product 117
5.4.3.31 Produkt realisieren Réaliser le produit Realizzare il prodotto Realize product 118
5.4.3.32 Produktkonzept erarbei- Élaborer le concept du Elaborare la progetta- Design product concept 119
ten produit zione del prodotto
5.4.3.33 Projekt führen und kon- Conduire et contrôler le Gestire e controllare il Manage and control pro- 120
trollieren projet progetto ject
5.4.3.34 Projekt steuern Piloter le projet Condurre il progetto Steer project 121
5.4.3.35 Projektabschluss vorbe- Préparer la clôture du Preparare la conclusione Prepare project closure 122
reiten projet del progetto
5.4.3.36 Projektmanagementplan Élaborer le plan de ges- Elaborare il piano di ge- Draw up project man- 123
erarbeiten tion du projet stione progettuale agement plan
5.4.3.37 Prototyping durchführen Effectuer le prototypage Eseguire la prototipazi- Carry out prototyping 125
one
5.4.3.38 Qualitätssicherung füh- Conduire l’assurance de Gestire la garanzia della Perform quality as- 125
ren la qualité qualità surance
5.4.3.39 Rechtsgrundlagenana- Élaborer l’analyse des Elaborare l’analisi delle Analyze legal basis 126
lyse erarbeiten bases légales basi legali
5.4.3.40 Releaseabschluss vorbe- Préparer la clôture du re- Preparare la conclusione Prepare release closure 127
reiten lease del rilascio
5.4.3.41 Risiken managen Gérer les risques Gestire i rischi Manage risks 128
5.4.3.42 Schutzbedarfsanalyse er- Élaborer l’analyse des Elaborare l’analisi delle Analyze protection needs 129
arbeiten besoins de protection esigenze di protezione
5.4.3.43 Stakeholder managen Gérer et informer les Gestire e informare gli Manage and inform sta- 129
und informieren parties prenantes stakeholder keholders
5.4.3.44 Stakeholderinteressen Représenter les intérêts Rappresentare gli inte- Advocate stakeholder in- 130
vertreten des parties prenantes ressi degli stakeholder terests
5.4.3.45 Studie erarbeiten Élaborer l’étude Elaborare lo studio Prepare study 131
5.4.3.46 System aktivieren Activer le système Attivare il sistema Activate system 133
5.4.3.47 System in Betrieb integ- Intégrer le système en Integrare il sistema Integrate the system into 133
rieren fonctionnement nell’esercizio operation
5.4.3.48 System realisieren Réaliser le système Realizzare il sistema Realize system 134
5.4.3.49 Systemintegration vorbe- Préparer l’intégration du Preparare l’integrazione Prepare system integra- 135
reiten système del sistema tion
5.4.3.50 Test durchführen Effectuer les tests Eseguire i test Conduct test 135
5.4.3.51 Testinfrastruktur realisie- Réaliser l’infrastructure Realizzare l’infrastruttura Realize test infrastruc- 136
ren de test per i test ture
5.4.3.52 Testinfrastruktur über- Transférer l’infrastructure Trasferire l’infrastruttura Transfer test infrastruc- 137
führen de test per i test ture
5.4.3.53 Testkonzept erarbeiten Élaborer le concept de Elaborare la progetta- Design test concept 137
test zione dei test
5.4.3.54 Vereinbarung erarbeiten Élaborer l’accord Elaborare l’accordo Draw up agreement 138
Tabelle 34: Vokabular HERMES-Aufgaben 4-sprachig
198 / 200
Rollen – Rôles – Ruoli – Roles
Rollen Rôles Ruoli Roles
6.4.3.1 Anwendervertreter Représentant des utilisa- Rappresentante degli User representative 156
teurs utenti
6.4.1.1 Auftraggeber Mandant Committente Project sponsor 148
6.4.3.2 Betriebsverantwortlicher Responsable de l’exploi- Responsabile dell’eser- Operations manager 158
tation cizio
6.4.3.3 Business Analyst Business analyst Business analyst Business analyst 159
6.4.3.4 Entwickler Développeur Sviluppatore Developer 160
6.4.3.5 Entwicklungsteam Équipe de développe- Team di sviluppo Development team 161
ment
6.4.2.1 Fachausschuss Comité spécialisé Comitato esperti Technical committee 151
6.4.3.6 ISDS-Verantwortlicher Responsable SIPD Responsabile SIPD ISDP manager 162
6.4.3.7 IT-Architekt Architecte informatique Architetto IT IT architect 162
6.4.1.2 Projektausschuss Comité de pilotage Comitato di progetto Project committee 150
6.4.2.2 Projektleiter Chef de projet Capoprogetto Project management 152
6.4.2.3 Projektunterstützung Assistance de projet Supporto di progetto Project support 155
6.4.1.3 Qualitäts- und Risikoma- Gestionnaire de la qua- Gestore della qualità e Quality and risk manager 151
nager lité et des risques dei rischi
6.4.2.4 Teilprojektleiter Chef de sous-projet Responsabile di sot- Sub-project manager 155
toprogetto
6.4.3.8 Tester Testeur Collaudatore Tester 163
6.4.3.9 Testverantwortlicher Responsable des tests Responsabile dei test Test manager 163
Tabelle 35: Vokabular HERMES-Rollen 4-sprachig
199 / 200
Index der HERMES-Projektmanagementmethodenelemente
Phasen Meilenstein Abnahme
Meilenstein Abnahme Migration
70
70
Entscheid Ausschreibung treffen
Entscheid Betriebsaufnahme treffen
78
78
Abschluss 24
Einführung 23 Meilenstein Ausschreibung 70 Entscheid Durchführungsfreigabe
Initialisierung 21 Meilenstein Betriebsaufnahme 70 treffen 79
Konzept 22 Meilenstein Durchführungsfreigabe 70 Entscheid ISDS-Konzept treffen 89
Realisierung 22 Meilenstein ISDS-Konzept 70 Entscheid Lösungsarchitektur treffen 90
Umsetzung 23 Meilenstein Lösungsarchitektur 70 Entscheid Phasenfreigabe Abschluss
Meilenstein Phasenfreigabe 70 treffen 80
Szenarien Meilenstein Phasenfreigabe Abschluss
Meilenstein Produktkonzept
70
70
Entscheid Phasenfreigabe treffen
Entscheid Produktkonzept treffen
81
90
Dienstleistung/Produkt Adaption 29
Dienstleistung/Produkt Entwicklung 28 Meilenstein Projektabschluss 70 Entscheid Projektabbruch treffen 82
IT-Adaption 30 Meilenstein Entscheid Projektabschluss treffen 84
IT-Entwicklung 30 Projektinitialisierungsfreigabe 70 Entscheid Projektinitialisierungsfreigabe
Organisationsanpassung 31 Meilenstein Releasefreigabe 70 treffen 85
Meilenstein Vorabnahme 70 Entscheid Releasefreigabe treffen 86
Module Meilenstein Weiteres Vorgehen
Meilenstein Zuschlag
71
71
Entscheid Vorabnahme treffen
Entscheid Weiteres Vorgehen treffen
91
92
Beschaffung 36
Einführungsorganisation 39 Migration durchgeführt 71 Entscheid Zuschlag treffen 87
ISDS 40 Migrationskonzept 56 Integrationskonzept erarbeiten 104
IT-Betrieb 40 Migrationsverfahren realisiert 71 ISDS-Konzept erarbeiten 104
IT-Migration 39 Offertanfrage 56 ISDS-Konzept realisieren 105
IT-System 38 Organisation aktiviert 71 ISDS-Konzept überführen 106
Organisation 36 Organisation umgesetzt 71 Leistungen vereinbaren und steuern 106
Produkt 37 Organisationsanforderungen 56 Lösungsanforderungen erarbeiten 108
Projektführung 34 Organisationsbeschreibung 57 Lösungsarchitektur erarbeiten 109
Projektgrundlagen 35 Organisationskonzept 57 Migration durchführen 110
Projektsteuerung 33 Phasenbericht 58 Migrationskonzept erarbeiten 111
Tests 38 Produkt aktiviert 71 Migrationsverfahren realisieren 112
Produkt entwickelt oder angepasst 71 Organisation aktivieren 112
Ergebnisse Produktdokumentation
Produktkonzept
58
58
Organisation umsetzen
Organisationsanforderungen erarbeiten
113
114
Abnahmeprotokoll 44
Altsystem entfernt 68 Projekterfahrungen 59 Organisationskonzept erarbeiten 115
Änderungsantrag 44 Projektinitialisierungs-auftrag 59 Phasenfreigabe vorbereiten 116
Änderungsstatusliste 45 Projektmanagementplan 59 Probleme behandeln und Erfahrungen
Angebot 45 Projektschlussbeurteilung 60 nutzen 117
Angebotsprotokoll 45 Projektstatusbericht 61 Produkt aktivieren 117
Anwendungshandbuch 45 Protokoll 61 Produkt realisieren 118
Arbeitsauftrag 46 Prototyp realisiert 71 Produktkonzept erarbeiten 119
Ausschreibungsunterlagen 46 Prototypdokumentation 62 Projekt führen und kontrollieren 120
Beschaffungsanalyse 47 Prozessbeschreibung 62 Projekt steuern 121
Betrieb aktiviert 69 Prüfprotokoll 62 Projektabschluss vorbereiten 122
Betriebshandbuch 48 Publikation 63 Projektmanagementplan erarbeiten 123
Betriebsinfrastruktur realisiert 69 QS- und Risikobericht 63 Prototyping durchführen 125
Betriebskonzept 48 Rechtsgrundlagenanalyse 63 Qualitätssicherung führen 125
Betriebsorganisation realisiert 69 Releasebericht 63 Rechtsgrundlagenanalyse erarbeiten 126
Checkliste Abnahme 49 Schnittstellen realisiert 72 Releaseabschluss vorbereiten 127
Checkliste Abnahme Migration 49 Schutzbedarfsanalyse 64 Risiken managen 128
Checkliste Ausschreibung 49 Service Level Agreement 64 Schutzbedarfsanalyse erarbeiten 129
Checkliste Betriebsaufnahme 49 Situationsanalyse 65 Stakeholder managen und informieren 129
Checkliste Durchführungsfreigabe 49 Stakeholderinteressen 65 Stakeholderinteressen vertreten 130
Checkliste ISDS-Konzept 49 Stakeholderliste 66 Studie erarbeiten 131
Checkliste Lösungsarchitektur 49 Studie 66 System aktivieren 133
Checkliste Phasenfreigabe 49 System aktiviert 72 System in Betrieb integrieren 133
Checkliste Phasenfreigabe Abschluss 49 System entwickelt oder parametrisiert 72 System realisieren 134
Checkliste Produktkonzept 49 System integriert 72 Systemintegration vorbereiten 135
Checkliste Projektabbruch 49 Systemkonzept 67 Test durchführen 135
Checkliste Projektabschluss 50 Testinfrastruktur realisiert 72 Testinfrastruktur realisieren 136
Checkliste Projektinitialisierungsfreigabe 50 Testinfrastruktur überführt 72 Testinfrastruktur überführen 137
Checkliste Releasefreigabe 50 Testkonzept 67 Testkonzept erarbeiten 137
Checkliste Vorabnahme 50 Testprotokoll 68 Vereinbarung erarbeiten 138
Checkliste Weiteres Vorgehen 50 Vereinbarung 68
Checkliste Zuschlag 50 Rollen
Detailspezifikation 50 Aufgaben Anwendervertreter 156
Durchführungsauftrag 51 Altsystem ausser Betrieb setzen 93 Auftraggeber 148
Einführungskonzept 51 Änderungen managen 94 Betriebsverantwortlicher 158
Einführungsmassnahmen durchgeführt 69 Angebote bewerten 95 Business Analyst 159
Einführungsmassnahmen realisiert 69 Ausschreibung durchführen 95 Entwickler 160
Evaluationsbericht 52 Ausschreibung erarbeiten 96 Entwicklungsteam 161
Geschäftsmodellbeschreibung 52 Beschaffungsanalyse erarbeiten 97 Fachausschuss 151
Integrations- und Installations-anleitung 53 Betrieb aktivieren 98 ISDS-Verantwortlicher 162
Integrationskonzept 53 Betrieb realisieren 99 IT-Architekt 162
ISDS-Konzept 53 Betriebskonzept erarbeiten 100 Projektausschuss 150
ISDS-Konzept überführt 69 Durchführungsauftrag erarbeiten 101 Projektleiter 152
ISDS-Massnahmen realisiert 69 Einführung durchführen 103 Projektunterstützung 155
Liste Projektentscheid Steuerung 54 Einführung realisieren 103 Qualitäts- und Risikomanager 151
Liste Projektentscheide Führung 54 Einführungskonzept erarbeiten 101 Teilprojektleiter 155
Lösungsanforderungen 54 Entscheid Abnahme Migration treffen 88 Tester 163
Lösungsarchitektur 55 Entscheid Abnahme treffen 88 Testverantwortlicher 163
Die Projektmanagementmethode für Produkte, Dienst-
leistungen, Informatik und Organisation.
HERMES ist sofort anwendbar und bietet:

 Modularen Aufbau für konkrete Projektabläufe;
 Onlinetool zur Methodenunterstützung;
 Dokumentvorlagen inklusive Checklisten für die effiziente Projektabwicklung;
 Szenarien für einfachere Umsetzungsplanung.
HERMES ist einfach und verständlich und liefert:

 Klare Aufgabenbeschreibungen mit Aktivitäten;
 Konkrete Rollenbeschreibungen für die organisationsübergreifende Zusam-
menarbeit;
 Dokumentvorlagen für schnelle und klar dargestellte Ergebnisse.
HERMES als Führungswerkzeug unterstützt:

 Den Auftraggeber hinsichtlich Governance und Nachhaltigkeit;
 Die Projekt- und Programmleiter bei Planung, Kontrolle und Führung;
 Den Anwendervertreter und Fachspezialisten bei der Projektausführung;
 Das Management bei der übergeordneten strategischen Steuerung der Pro-
jekte und Programme.
Dieses Referenzhandbuch ist der Standard für Projekte der Schweizer Bundesverwaltung und vieler
Kantone, Gemeinden und Firmen. HERMES ist ebenfalls der eCH-Standard für
E-Government-Projekte und -Programme.
Das Programmmanagement als Teil des Projektmanagements wird in einem separaten Anhang be-
handelt.
HERMES wird für alle Arten von Programmen und Projekten empfohlen.
HERMES deckt alle Dimensionen des zeitgemässen Programm- und Projektmanagements ab, wie Be-
schaffungsmanagement, Stakeholdermanagement, Kommunikation und Reporting, Risiko- und Quali-
tätsmanagement, klassische, agile und hybride Entwicklung, Governance und Nachhaltigkeit. Zudem
sind die programm-/projektspezifischen Vorgehensweisen beschrieben.
HERMES online: www.hermes.admin.ch

Referenzhandbuch HERMES-Projektmanagement 2022 de

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Referenzhandbuch HERMES-Projektmanagement 2022 de

Hochgeladen von

Copyright:

Verfügbare Formate

HERMES

Ausbildung und Zertifizierung

Patrik Riesen, Programmleiter SUPERB

Urheberrechte und Vorbehalt

Hinweis zur sprachlichen Gleichbehandlung

Typografische Gestaltung, Grafiken und Druckvorstufe

Support und Unterstützung

Eidgenössische Finanzkontrolle EFK

HERMES ist ein Erfolgsprodukt und so soll es auch in Zukunft bleiben.

Phasenunabhängig Situations- Situations- Situations-

Projekt- Organisations- Lösungs- Lösungs-

Detail- Detail- Detail-

QS- und Produkt System Schnittstellen

Organisation Produkt System

aktiviert aktiviert aktiviert

HERMES-Phasenmodell für klassische und agile Projekte

Beschaffung Tests Einführungs- IT-Migration IT-Betrieb ISDS

Test- Einführungs- Detail- Betriebs- Betriebs- ISDS-

Migrations- System Betriebs-

Einführungs- Migration Betrieb ISDS-Konzept

HERMES- HERMES- HERMES-

Abbildung 2: Die drei obersten Methodenelemente der HERMES-Methode

HERMES-Projektmanagement unterstützt die Steuerung, Führung und Ausführung von Vor-

A.3 Durch HERMES unterstützte Projektgrössen

HERMES Projektmanagement im Einsatz

Abbildung 3: Die Funktionalität von HERMES-Projektmanagement in der Praxis

HERMES-Kurse und Zertifizierungen festigen die geforderte Kompetenz und Know-how.

2 Das klassische Vorgehensmodell des "Systems Engineerings", ETHZ, Walter F. Daenzer

A.5 Die Schnittstellen des HERMES-Projektmanagements

A.6 Agiles Entwicklungsmanagement mit HERMES

Initialisierung Konzept Realisierung Einführung Abschluss

Projekt 1 Initialisierung Konzept Realisierung Einführung Abschluss

Projekt 2 Initialisierung Umsetzung Abschluss

Projekt 3 Initialisierung Umsetzung Abschluss

Projekt 4 Initialisierung Konzept Realisierung Einführung Abschluss

Projekt 5 Initialisierung Umsetzung Abschluss

Projekt n Initialisierung Konzept Realisierung Einführung Abschluss

Initialisierung Umsetzung Abschluss

Initialisierung Konzept Realisierung Einführung Abschluss

Programm Projekte mögliches Portfolio

HERMES-Projektmanagement schafft ein gemeinsames Verständnis zum Projekt- und Pro-

A.8 Hinweise zur Anwendung

Projektbeginn Lösungsentstehung Projektende

Beschaffung Projekt 1 Initialisierung IT-Adaption Abschluss

Projekt 2 Initialisierung Dienstleistung/Produkt Entwicklung Abschluss

Rechtsetzung Projekt n Initialisierung Individuelles Szenario "abc" Abschluss

Abbildung 6: Projekte einer Stammorganisation mit Szenarien

Konzept Realisierung Einführung

Konzept Realisierung Einführung

Studie Lösungsanforderungen Organisation

Konzept Realisierung Einführung

Abbildung 9: Phasen und Releases mit Meilensteinen als Quality Gates

Alle Meilensteine sind Ergebnisse, die im Projektverlauf die Entscheidungspunkte markieren.

Abbildung 10: Minimal zu besetzenden Rollen Auftraggeber, Projektleiter und Anwendervertreter

The HERMES data model

Das Datenmodell wurde mittels INTERLIS7, einer bundeseigenen konzeptionellen Datenbe-

Konzept Realisierung Einführung

Projektbeginn Lösungsentstehung Projektende

Der HERMES-Projektlebenszyklus wird unterteilt in Projektbeginn, Lösungsentstehung und

8 Hybride Vorgehensweise wird als Spezialfall im Kapitel 7 thematisiert.

Abbildung 14: HERMES-Phasenmodell für klassische und agile Vorgehensweise

1.2.2 Einheitliche Projektstruktur

Konzept Realisierung Einführung