2021...Das HERMES Handbuch 2021 ist ein Spiegel unserer schnelllebigen Epoche, auch wenn wir manchmal – unliebsam gebremst werden. Der grösste Teil der Anpassungen betrifft die

Umsetzung

EinführungRealisierungKonzept

AbschlussInitialisierung

Projektmanagement

HERMES 2021

HERMES 2021 REFERENZHANDBUCH – Projektmanagement

Ergebnisorientierte Projektmanagementmethode für verschiedene Arten von Projekten

HERMES AUF EINEN BLICK:

Methode

Dieses Referenzhandbuch dokumentiert die Methode und ist ge-

druckt sowie online verfügbar.

Es bildet die Referenzgrundlage für die Zertifizierung.

Es wird in der Ausbildung eingesetzt und eignet sich auch für das

Selbststudium.

HERMES online

Szenarien sind die Grundlage für die Projektplanung.

Dokumentvorlagen und Checklisten ermöglichen eine rasche An-

wendung.

Individuelle Szenarien decken die Besonderheiten der Organisation

ab.

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 eGovernment.

Die Anwender sind in der HERMES-Fachgruppe vertreten.

1 / 202

Vorwort – Verantwortlicher HERMES-Methode

HERMES Revolution

Das HERMES Handbuch 2021 ist ein Spiegel unserer schnelllebigen Epoche, auch wenn wir manchmal – unliebsam gebremst werden.

Der grösste Teil der Anpassungen betrifft die überarbeitete Agilität. Dennoch können Projekte auch weiterhin nach dem klassischen Phasenmodell abgewickelt werden, wie aus HERMES 5

bekannt ist; es gilt also den bisherigen Erfolg von HERMES zu sichern und zugleich Neues einfliessen zu lassen.

Die gesamtheitliche Überarbeitung der Methode hat uns zu neuen Erkenntnissen verholfen. Da waren nicht nur die längst überfälligen Anforderungen unserer Anwender, wie zum Beispiel der Ruf nach einer prominenteren Platzierung des Beschaffungsprozesses, sondern auch die

Frage, wann beginnt eigentlich ein Projekt und wer soll welche Rolle wann besetzen?

Um die IT-Lastigkeit zu reduzieren und betriebswirtschaftliche Aspekte mehr in den Vorder-grund zu rücken, haben wir einige Rollen angepasst und nicht zuletzt die Wichtigkeit der Sta-

keholder 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 2021 den Fachbereichen helfen, selber zu bestimmen, wie das eigene Projekt abzu-wickeln ist, statt sich dem Druck allfälliger Dienstleistungserbringer zu beugen.

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 Umsetzung ausgewählt und in ein- und derselben Organisation problem-

los nebeneinander abgewickelt werden kann.

Wir sind also bestrebt, die Projektmanagement-Methode fortlaufend an die aktuellen Bedürf-nisse anzupassen und nehmen die Anliegen unserer Anwender sehr ernst.

Über das HERMES Referenzhandbuch hinaus unterstützen wir Sie gerne zu Fragen über den Aufbau der Projektorganisation und der Zusammenarbeit mit allen Stakeholdern. Sie können

uns gerne via E-Mail oder telefonisch kontaktieren.

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 HERMES 2021 konnten die Erfahrungen aus der Abwicklung von

agilen Vorhaben übernommen werden. Dies ermöglicht die optimale Steuerung und Führung von komplexen agilen Vorhaben wie SUPERB».

Patrik Riesen, Programmleiter SUPERB

http://www.isb.admin.ch/

2 / 202

Impressum

Herausgeber

Bundeskanzlei BK, Digitale Transformation und IKT Leitung DTI

Gesamtverantwortung

André Bürki, Verantwortlicher HERMES-Methode, Digitale Transformation und IKT Leitung 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 baut auf HERMES 5.1 auf. Sie 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 anderslautender zwingender gesetzlicher Bestimmungen des anwendbaren Rechts aus-

geschlossen. Irrtümer, Probleme oder Änderungsvorschläge können dem Herausgeber über HERMES on-

line www.hermes.admin.ch mitgeteilt werden.

HERMES 2021 / Referenzhandbuch / Dokumentvorlagen / Checklisten

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;

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 Frauen in ihrer jeweiligen Funktion explizit mit ein.

Typografische Gestaltung, Grafiken und Druckvorstufe

Stoupa & Partners AG, Münsingen

Online-Tool

ICTpark AG, Allenwinden

E-Government Standards

eCH Standard 0054

Bezugsquelle

Vertrieb: BBL, Verkauf Bundespublikationen, CH-3003 Bern

Deutsch www.bundespublikationen.admin.ch

Französisch www.publicationsfederales.admin.ch

Art.-Nr. 999.999.D

ISBN 978-3-906211-62-6

Ausgabe / Auflage

HERMES 2021 / PDF Draft-Version 7. Auflage, 26/03/2021

https://www.admin.ch/opc/de/classified-compilation/19920251/index.html

https://www.admin.ch/opc/de/classified-compilation/19920251/index.html

http://www.stoupa.swiss/



http://www.bundespublikationen.admin.ch/

http://www.publicationsfederales.admin.ch/

3 / 202

Prolog

«Kleine Taten, die man ausführt, sind besser als grosse, die man plant.» (George C. 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 EFK zeigen allerdings, dass die konsequente Anwendung einer Methode leider kein Garant für eine er-

folgreiche Projektumsetzung ist. Wichtig sind auch weitere 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.

Steuern Sie als Auftraggeber das Vorhaben, indem sie den erwarteten Geschäftsnutzen ins Zentrum stellen und die Berichterstattung konsequent danach ausrichten. Definieren Sie zum

Beispiel über Meilensteine, wann Sie welchen Nutzen realisiert haben wollen und überlassen Sie die Umsetzung der Inhalte 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, 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- 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 Kontrollen und Sicherheitselemente vorliegen und diese möglichst automatisiert durchgeführt

werden.

Statten Sie Ihre Organisation mit Kompetenzen aus.

Legen Sie die Verantwortlichkeiten unmissverständlich fest und sichern Sie sich die Schlüssel-

ressourcen rechtzeitig und nachhaltig. Achten Sie darauf, dass der Anwendervertreter (Pro-duct Owner) sowohl über das Fachwissen wie auch die nötigen Entscheidungsbefugnisse ver-

fügt und starten Sie nie ohne ein ausgereiftes Qualitäts- und Risikomanagement. 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

mailto:[email protected]

http://www.efk.admin.ch/

4 / 202

In eigener Sache

«Was ändert in HERMES 2021? (Libor F. Stoupa, Autor HERMES 2021)

Was führte zur neuen Version des HERMES 2021 Projektmanagements, was wurde geändert und warum...?

Die Anforderung war, das agile HERMES Vorgehen soweit anzupassen, dass es den neuesten Anforderungen gerecht wird. Hierbei sollte die bereits im HERMES 5.1 vorhandene agile Vor-gehensweise anhand der neuesten Erkenntnisse aus erfolgreichen agilen Projekten optimiert

werden. Und dies nach wie vor unter Berücksichtigung der Governance, eines einheitlichen Vorgehens in den Projekten und einheitlichen Schnittstellen zu der nicht agilen Projektumge-

bung. Darüber hinaus sollten Aspekte wie Organisation und Geschäftsorientierung stärker ins Gewicht fallen und die IT-Lastigkeit weiter verringert werden.

Das aktualisierte Projektmanagement HERMES ist weder agil, noch klassisch, sondern es er-laubt im Rahmen eines einheitlichen Vorgehens die Einbindung möglichst vieler klassischer und agiler Entwicklungsmethoden. Hierfür nutzt HERMES entweder das klassische oder das

hybride Projektmanagement. Ansonsten bietet HERMES die gleiche Struktursystematik und die gleichen Methodenelemente wie bis anhin. Auch das Buch blieb gleich strukturiert, nur die

Reihenfolge der Kapitel wurde noch besser an das HERMES angepasst. Jeder, der die vorhe-rige HERMES Version kennt, versteht und beherrscht mühelos auch die neue.

Die eigenständige HERMES Terminologie wurde mit kleinen Anpassungen beibehalten. Auf-gaben, Rollen und Ergebnisse sollen sich unabhängig vom Entwicklungsvorgehen möglichst

nicht voneinander unterscheiden. Das klassische Entwicklungsvorgehen wurde der heutigen Realität angepasst. Die klassischen Phasen samt Meilensteinen blieben das, was sie sein sollen

– nämlich die Steuerungsmechanik des phasenweisen Vorgehens. Bei der agilen Vorgehens-weise wurde Governance halber eine Releasefreigabe vorgesehen, die einerseits dem Auf-

traggeber oder dem Programmleiter die Möglichkeit gibt, nebst dem Studium des Projektsta-tus bei Bedarf auch direkt in das Projektgeschehen einzugreifen und anderseits hilft, die

Governance zu sichern.

Weitere wichtige Verbesserungen:

HERMES Projektmanagement richtet sich weiterhin nach dem Projektlebenszyklus.

Aufgrund der Erkenntnisse aus agilen Projekten mussten die Phasen angepasst werden.

Das Projekt beginnt bereits mit einer gewollt schlanken Phase Initialisierung, die Szenarien starten und enden mit der Umsetzung.

Minimal zu besetzende Rollen sind Auftraggeber, Projektleiter und Anwendervertreter

(Product Owner), die zwingend durch den Anwender zu besetzen sind.

Die Rolle des Anwendervertreters hat an Bedeutung gewonnen; sie besitzt die fachliche

Produktverantwortung (klassisch und agil). Dementsprechend steigen auch die Anforde-

rungen an den Rolleninhaber.

Die Methodenelemente Meilensteine sind Zustände und werden neu namentlich aufge-

zählt und in der Methode aktiv genutzt.

Der Beschaffungsprozess wird bereits in der Initialisierung geplant und vorbereitet, so er-

möglicht er die Szenarien mit Adaption.

Die Einbettung der Projekte in die Programme erfolgt auf integrierte Weise.

Gerne möchten darauf hinweisen, dass das vorliegende Handbuch analog HERMES 5.1 eine «Maximalvariante» für die wirklich grossen und wichtigen Projekte darstellt. Allerdings wird eine vorhabenbezogene Anwendung der Methode gewünscht (Tailoring). In diese Richtung

zielt auch das bei den Szenarien beschriebene Sizing. Ziel sollte es sein, den administrativen Aufwand zu senken und die Komplexität des Vorhabens so tief wie möglich zu halten.

Wir freuen uns auf viele Feedbacks. HERMES ist ein Erfolgsprodukt und so soll es auch in Zukunft bleiben.

5 / 202

SZ

EN

AR

IEN

PH

ASEN

RO

LLEN

MO

DU

LE

ER

GEBN

ISSE

AN

WEN

DU

NG

HIN

WEIS

E Z

UR

AU

FG

AB

EN

6 / 202

A Methodenüberblick

A.1 HERMES Projektmanagement – Big Picture

Das Ergebnisdiagramm (Abbildung 1) zeigt die komplexen Gesamtzusammenhänge des HERMES Projektmanagements.

Anwendungs-handbuch

Lösungs-architektur

System-konzept

Integrations-konzept

Detail-spezifikation

Organisation IT-System


Produkt

Produkt-konzept

Organisations-anforderungen

Situations-analyse

Lösungs-anforderungen

Situations-analyse

Lösungs-anforderungen

Situations-analyse

Phasenunabhängig

ProjektsteuerungProjektführung

Integrations-und

Installations-anleitung


Projektgrundlagen

Projektmana-gementplan

Stakeholder-liste

Umsetzungs-auftrag

Schutzbedarfs-analyse

StudieRechts-

grundlagen-analyse

Anwendungs-handbuch

Projekt-entscheid

Projektschluss-beurteilung

Änderungs-statusliste

Änderungs-antrag

Phasenbericht

Projektstatus-bericht

Stakeholder-liste

Projekt-management-

plan

Iteration

Beschaffungs-analyse

Projekt-initialisierungs-

auftrag


Iteration

Organisations-konzept

Organisationaktiviert

Produktaktiviert

Systemaktiviert

Organisationumgesetzt

Schnittstellenrealisiert

Produktentwickelt/angepasst

Systementwickelt/

parametrisiert

Organisations-beschreibung

Prozess-beschreibung

Prozess-beschreibung

Organisations-beschreibung

Geschäftsmod.-beschreibung

Geschäftsmod.-beschreibung

Ab

schlu

ssIn

itia

lisie

rung

Um

setz

un

g

Ein

führu

ng

Realis

ieru

ng

Ko

nze

pt

HERMES Phasenmodell für klassische und agile Projekte

Releasebericht

QS- und Risikobericht

Abbildung 1: Gesamtbild der HERMES Module samt wichtigsten Ergebnissen entlang der Phasen

7 / 202

HERMES ist eine ergebnisorientierte Vorgehensmethode; die Ergebnisse stehen bei HERMES im Zentrum. Das Gesamtbild zeigt die wichtigsten Ergebnisse der HERMES Module entlang

der Phasen sowie die groben logischen Abhängigkeiten und Zusammenhänge.

ISDS-Konzept

Testkonzept

Testkonzept


ISDS-Konzept

IT-BetriebIT-MigrationTesten ISDS

Migrations-konzept

Betriebs-handbuch

Service Level Agreement

Betriebs-konzept

Beschaffung

Betriebs-infrastruktur

realisiert

Evaluations-bericht

Ausschrei-bungs-

unterlagen

Vereinbarung

Testkonzept

ISDS-Konzept

TestprotokollBetriebs-

organisationrealisiert

Migrations-verfahrenrealisiert

Systemintegriert

Betriebaktiviert

Migration durchgeführt

ISDS-Konzept überführt

Altsystem entfernt

Testinfrastruk-tur überführt

Test-infrastruktur

realisiert

ISDS-Massnahmen

realisiert

Abnahme-protokoll

Abnahme-protokoll

Einführungs-konzept

Einführungs-organisation

Einführungs-massnahmendurchgeführt

Einführungs-massnahmen

realisiert

8 / 202

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 Einsatzgebieten, wie zum

Beispiel in der Anpassung der Geschäftsorganisation, in der Informatik, oder in der Entwick-lung von Dienstleistungen und Produkten.

HERMES Projektmanagement unterstützt somit die Steuerung, Führung und Ausführung von Vorhaben aller Art und begleitet die Weiterentwicklung von organisatorischen Strukturen, Produkten und, Dienstleistungen, IT- und Logistiksystemen, Infrastrukturen u. ä. unterschied-

licher Charakteristiken und Komplexitäten.

HERMES Projektmanagement hat eine klare, einfach verständliche Methodenstruktur, ist mo-

dular aufgebaut und erweiterbar. Es wird laufend aktualisiert und weiterentwickelt.

A.3 Durch HERMES unterstützte Projektgrössen

Wie schon bei der vorherigen HERMES Projektmanagement Version 5.1, fokussiert auch das vorliegenden HERMES 2021 Projektmanagement eine «Maximalvariante» der wirklich grossen und wichtigen Projekte, um die Vollständigkeit der Information zu gewährleisten. Allerdings

sollte schon immer eine vorhabenbezogene Anwendung der Methode angewendet werden, da viele Stammorganisation in ihrem Portefeuille nur mittlere und kleine Projekte haben. Da

Tailoring in der Vergangenheit nicht immer zum gewünschten Ergebnis führte, führt HERMES 2021 Projektmanagement eine neue Funktionalität ein, nämlich das Sizing. Der Einsatz von

Sizing soll die Komplexität des Vorhabens so tief wie möglich halten und die Dokumentati-onsaufwendungen auf das absolute Muss zu reduzieren..

Sizing richtet sich nach der "Grösse" des anzugehenden Vorhabens oder dessen Wertigkeit. Die Grösse oder Wertigkeit werden aus einer Kombination von Durchlaufzeit, Aufwand oder Kosten, Grösse des Projektteams, Stakeholder-Struktur, politischer Auswirkung, Vertraulich-

keitsstufe, rechtlicher Relevanz usw. ermittelt. Sie zeigt die Relevanz des Vorhabens oder nur eines Teils des Vorhabens gegenüber anderen projektierten Vorhaben und den daraus resul-

tierenden Anspruch an den Detaillierungsgrad der Dokumentation.

Diese neue Dimension passt den administrativen Aufwand und den Umfang der Dokumenta-

tion diesem Kriterium entsprechend an. Es werden alle möglichen Grössen eines Projekts un-terstützt:

a) Megaprojekte XL (ohne/mit Teilprojekten)

b) Grossprojekte L (ohne/mit Teilprojekten

c) Mittlere Projekte M

d) Kleinprojekte S

Dies unabhängig davon, ob diese Projekte zum Beispiel in einem Programm zusammenge-fasst oder Teil eines Portfolios sind.

Aufgrund der in der Initialisierungsphase ermittelten Grösse werden entsprechende Varianten von Szenarien sowie die dazugehörige Dokumentation generiert. Diese online-tool-gestützte Anpassung garantiert die Methoden-Kontinuität und -Kohärenz und erlaubt auch kleine Vor-

haben entsprechend schlank abzuwickeln.

Eine anschliessende manuelle Anpassung ist natürlich immer noch möglich.

A.4 HERMES Vorgehensmodell und Vorgehens-Layer

HERMES unterstützt insbesondere bei Entwicklungsprojekten grundsätzlich zwei Vorgehens-arten: Das traditionelle klassische SE-Vorgehen1, nachfolgend "klassisch" genannt, und das iterative Vorgehen2, nachfolgend "agil" genannt.

1 Das klassische Vorgehensmodell des "Systems Engineerings", ETHZ, Walter F. Daenzer 2 In Anlehnung an SCRUM, SAFe, usw.

9 / 202

HERMES nimmt nicht in Anspruch die Vorgehensmethode erfunden zu haben, sondern liefert lediglich ein Framework an Funktionalitäten, das es erlaubt, unterschiedliche Vorgehenswei-

sen und folglich auch die jeweils projektspezifisch eingesetzten Methoden wie zum Beispiel SCRUM3 einheitlich einzubetten. Die Abbildung 2 veranschaulicht, wie die Anwendung von

HERMES eine entsprechende, anderweitige methodische Ausbildung oder zumindest fun-dierte Projektpraxis voraussetzt und – entsprechend erweitert – für den einheitlichen Einsatz

bereitstellt.

HERMES kanalisiert das verschieden Orts erworbene Wissen, erweitert dieses durch HERMES spezifische Elemente und Terminologie und bietet allen Vorhaben einen homogenen Rah-

men. Entsprechende HERMES Kurse und Zertifizierungen festigen die geforderte Kompetenz. Dadurch wird in den Projekten nach innen wie nach aussen gleichartig rapportiert und kom-

muniziert und zeitgleich werden die flankierenden Rahmenanforderungen des HERMES er-füllt. Somit können Projekte aller Art, in der Stammorganisation einheitlich verankert werden

und sie liefern unabhängig der gewählten Vorgehensart annährend identische Informationen.

Klassisches Projektmanagement

------Ausbildung

(SE, IPMA, PMI etc.)

Agile Projektentwicklung

-----Ausbildung

(z.B. SCRUM)

HERMES Projektmanagement im Einsatz

HERMES

Handbücher / Online

Dokumentvolagen

Ausbildung / Zertifizierung

PM

Kn

ow

ho

w

Ag

il K

no

wh

ow

HERMES Methode

Verwaltungsalltag

Projekte

Erfahrung & Praxis

Verwaltung

Abbildung 2: Die Funktionalität von HERMES in der Praxis

Die Projektteams werden darin unterstützt, die für das Vorhaben gewählte Vorgehensme-thode anzuwenden und dennoch, ohne grossen Mehraufwand, die von HERMES verlangten

flankierenden Massnahmen zu erfüllen. Insofern werden die klassischen und agilen Methoden nicht beschnitten, es werden aber hinsichtlich der Rollen, der Aufgaben oder der Ergebnisse

zusätzliche Methodenelemente definiert, die als verbindlichen Anforderungen notwendig sind.

HERMES legt über die gewählte Methode einen 'transparenten' Layer, der nach Aussen ein einheitliches Bild aller Projekte vermittelt und allen Projektbeteiligten immer und stets die gleiche Sprache vermittelt. Dadurch wird das gewählte Projektvorgehen in sich völlig autonom

und kann in jede Verwaltungsumgebung integriert werden. Sowohl die Planung, als auch das Controlling erfolgen weitgehend im gewohnten Rahmen. Dies gilt auch für Methoden wie

SAFe4, oder den prozessualen Optimierungsansatz DevOps5, die ebenfalls durch HERMES Me-thode entsprechend unterstützt werden.

3 SCRUM ist eine agile Entwicklungsmethode zur agilen Softwareentwicklung. Der Entwicklungsprozess steht im

Mittelpunkt, spezifische ganzheitliche Projektmanagement Aspekte sind nicht vorgesehen. 4 SAFe ermöglicht die Anwendung von skalierter Agilität im breiten Unternehmensumfeld und im grossen Mas-

sstab. 5 Bei DevOps (Development/Operations) steht der ganzheitliche LifeCycle eines Produkts, oder eines Systems,

im Vordergrund

10 / 202

A.5 Agiles Entwicklungsmanagement mit HERMES

HERMES Projektmanagement garantiert die Kompatibilität der bisherigen Schnittstellen nach aussen, wie z.B. Reporting, unabhängig davon, ob die Entwicklung zum Beispiel agil nach

SCRUM durchgeführt oder klassisch d. h. phasenorientiert, angegangen wird. Es deckt den gesamten Projektlebenszyklus (Project LifeCycle) ab. Es ist ergebnisorientiert, Prozesse werden

nicht vorgeschrieben. HERMES ist eine Projektvorgehenshülle, in die zum Beispiel eine spezi-fische agile Entwicklungsmethode eingefügt wird.

Das Wording innerhalb der Entwicklung ist nicht vorgeschrieben, es richtet sich nach der Ent-wicklungsmethode. Festgelegt sind hingegen die Ergebnis-Schnittstellen und Begrifflichkeiten nach aussen. Die HERMES Terminologie garantiert die gemeinsame Sprache und ein gemein-

sames Verständnis zwischen der Stamm- und Projektorganisation, zwischen dem Projekt und dem Programm, zwischen der agilen und der klassischen Entwicklungswelt. HERMES garan-

tiert seine standardisierten Schnittstellen.

Innerhalb der Projektorganisation sind der Auftraggeber und der Projektleiter jene Rollen, die

das Projekt managen. Der Anwendervertreter hingegen verantwortet die fachliche Lösungs-entwicklung. Alle drei Rollen sind für das Projekt unentbehrlich. Das Entwicklungsteam ist nur

bedingt in die Steuerung des Projekts involviert, da seine Steuerung über die zum Einsatz kommende Methode mittels Lösungsanforderungen (Product Backlog) und Detailspezifika-

tion (Sprint Backlog) erfolgt.

Je nach Projekt werden alle HERMES Module benötigt, da agiles Entwicklungsmanagement keine Angaben zu den konkreten Aufgaben und Ergebnissen zur Beschaffung, zur Entwick-

lung einer Lösung, zum Testen, zur Migration etc. macht, sondern lediglich auf die agile Steu-erung der Entwicklung fokussiert.

Im HERMES 2021 Projektmanagement steht der Projektlebenszyklus im Vordergrund, das je-weilige Entwicklungsmanagement ist eingekapselt. Das Projektmanagement gibt dem Vorha-ben seine einheitliche Struktur und ebensolchen Rahmen, das eingebettete Entwicklungsma-

nagement regelt die Organisation und die Steuerung des Entwicklungs-Teams, es steuert au-tonom das Entwicklungsvorgehen. Somit kann das im HERMES Projektmanagement einge-

kapselte agile Entwicklungsmanagement sowohl seine Rollenmodelle, Prozesse und Rituale als auch die vier Leitsätze des Agilen Manifests weitgehend leben:

1. Individuen und Interaktionen vor Prozessen und Werkzeugen

2. Funktionierende Software vor einer umfassenden Dokumentation

3. Zusammenarbeit mit dem Kunden vor Vertragsverhandlungen

4. Reagieren auf Veränderung vor dem Befolgen eines Plans

Inwieweit diese Leitsätze voll zum Tragen kommen, wird einerseits durch die Bestimmungen und Vorgaben der Stammorganisation beeinflusst, anderseits im Rahmen der Initialisierungs-

phase projektindividuell definiert. Da die Leitsätze lediglich priorisieren, können sie aus me-thodischer Sicht prinzipiell für alle agil geführten Projekte gemäss HERMES angewendet wer-

den.

HERMES betrachtet das ganze Entwicklungsvorgehen nur grob und aus grösserer Flughöhe

als es die jeweiligen Entwicklungsmethoden tun und so bleibt es jedem Entwicklungsteam überlassen, die benötigten Prozesse und Rituale entsprechend zu pflegen – Konsens innerhalb

der Stamm- und Projektorganisation vorausgesetzt.

A.6 Positionierung Programmmanagement

In Organisationen mit vielen bedeutenden Veränderungen benötigt man ein gesamtheitliches Projektmanagementsystem, um die Veränderungen mittels Projekten planen und steuern zu können. Programmmanagement ist ein Bestandteil des Projektmanagements.

Die Abbildung 3 zeigt ein mögliches Portfolio mit klassischen und agilen Projekten und einem Programm, das ebenfalls Projekte beinhaltet.

11 / 202

Die Darstellung zeigt, dass ein Projekt eigenständig oder Teil eines Programms sein kann. Ein Programm enthält immer mehrere Projekte. Projekte und Programme sind Teil eines Portfo-

lios. In der Praxis spricht man häufig von einem Projektportfolio, auch wenn dieses neben den Projekten eines oder mehrere Programme enthält.

Wenn eine Organisation mehrere Portfolios führt, kann ein Projekt oder Programm in mehre-ren Portfolios enthalten sein.

Projekt 1

Projekt 2

Projekt 3

Projekt 4

Projekt 5

Projekt n

Programminitialisierung Programmdurchführung Programmabschluss

AbschlussEinführungRealisierungKonzeptInitialisierung



Initialisierung Umsetzung Abschluss






Portfolio Programm Projekte

Abbildung 3: Positionierung Programmmanagement

A.7 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 agilen Entwicklung oder der Anwendung von HERMES in Programmen.

B HERMES Projektmanagement – Methodenelemente

B.1 Phasen

Das HERMES Phasenmodell bildet das Rückgrat jedes Projekts. Es schafft die Voraussetzung für das gemeinsame Verständnis der Projektbeteiligten vom Projektablauf. Dies ist eine wich-

tige Voraussetzung für die erfolgreiche organisationsübergreifende Abwicklung der Projekte.

Das einheitliche Phasenmodell baut auf dem Lebenszyklus eines Projekts auf. Die Abbildung 4 zeigt das HERMES Phasenmodell für die klassische und agile Vorgehensweise; die Phase Ini-

tialisierung am Anfang und die Phase Abschluss am Ende des Projekts sind beiden Vorge-hensweisen gemeinsam, sie Kapseln das Entwicklungsvorgehen im HERMES ein.


Umsetzung


agil

klassisch

Abbildung 4: Abwicklung der klassischen und agilen Projekte in Phasen

12 / 202

Die Projekte werden somit entweder in fünf oder in drei Phasen abgewickelt. Das Projekt beginnt stets mit der Phase Initialisierung und endet am Schluss der Phase Abschluss. Die Phase Initiali-

sierung entspricht einer strukturierten Orientierung, bei der es um ein fokussiertes Vorhaben geht: Welche sind die möglichen Lösungen und welcher Weg führt ungefähr dorthin? Die Phase

Abschluss beendet das Vorhaben endgültig und regelt organisatorisch und administrativ den Übergang von der Projekt- zur Anwendungsorganisation.

Das zwischen der Initialisierung und Abschluss eingekapselte Entwicklungsvorgehen wird in der klassischen Vorgehensweise mit den Phasen Konzept, Realisierung und Einführung abgewickelt, in der agilen Vorgehensweise hingegen mit der Phase Umsetzung.

Wird durch die Stammorganisation eine mögliche Projektdurchführung geprüft, startet das Vorhaben mit der Phase Initialisierung, deren Ergebnisse letztlich auch darüber entscheiden sollen, ob das Entwicklungsvorgehen im Projekt klassisch oder agil angegangen wird. Diese

Antwort muss fachlich und vorgehenstechnisch begründet sein. Es ist durchaus möglich, dass im Rahmen eines Programmes einige Projekte klassisch, andere wiederum agil abgewickelt

werden.

B.2 Ergebnisse

Wie die Abbildung 5 zeigt, stehen die Ergebnisse im Zentrum von HERMES.

Für jedes Ergebnis gibt es eine Ergebnisbeschreibung. Für viele Ergebnisse 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 auf die Betei-ligung bei der Ergebniserstellung. HERMES definiert minimal geforderte Dokumente (Ergeb-

nisse), um die Anforderungen an die Projekt-Governance zu erfüllen.

Projekt

Erg

eb

nis

se Studie

Projekt-

managementplan

Umsetzungsauftrag

Lösungsanforderungen

Organisationskonzept

Systemkonzept

Lösungsarchitektur

System

entwickelt/parametrisiert

Organisation

umgesetzt

Anwendungshandbuch

Organisation

aktiviert

System aktiviert

Abnahmeprotokoll

Altsystem

entfernt


Umsetzung


Nutzung

Abbildung 5: Ergebnisse stehen im Zentrum von HERMES

Als spezielle Ergebnisse gelten die Meilensteine. Sie markieren in der Projektdurchführung die

Entscheidungspunkte.

Die Abbildung 6 zeigt, dass zu Beginn und am Ende der Phasen Meilensteine stehen. Analog zu Phasen, kann beim agilen Vorgehen optional eine Releasefreigabe verlangt werden, was

zu weiteren Meilensteinen führt. Aufgaben, die zu einem Entscheid führen, enden auch mit einem Meilenstein. Je nach Szenario gibt es verschiedene Meilensteine. Sie entsprechen Qua-

lity Gates, an denen über Ergebnisse und das Vorgehen entschieden wird. Dabei erfolgt auch die Abstimmung mit den strategischen Zielen und Vorgaben der Stammorganisation.

Umsetzung

Releasefreigabe(optional)


Projekt-

abschluss

Projekt-

initialisierungs-

freigabe

Release 2Release 1 Release n



Umsetzungs-

freigabe

Phasen-

freigabe

Phasen-

freigabe

Phasenfreigabe

Abschluss

Abbildung 6: HERMES Phasen und Releases mit Meilensteinen als Quality Gates

13 / 202

B.3 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. Jeder Auf-gabe ist eine verantwortliche Rolle zugeordnet.

B.4 Rollen

HERMES Projektmanagement unterscheidet zwischen eigenständigen Projekten (stand-alone projects) und Projekten, die in einem Programm eingebettet sind.

HERMES unterscheidet zwischen den Rollen der Stammorganisation und Rollen der Projekt-organisation und definiert ihre Beziehungen. Für jede Rolle der Projektorganisation gibt es

eine Rollenbeschreibung. Sie definiert die Verantwortung, die Kompetenzen und die benötig-ten Fähigkeiten der Rolle. Jede Rolle in der Projektorganisation ist einer der Hierarchieebenen

Steuerung, Führung oder Ausführung zugeordnet (vgl. Abbildung 7).

In der Projektorganisation sind die Partnergruppen Anwender, Ersteller und Betreiber ver-treten. Jede Rolle ist einer oder mehreren Partnergruppen zugeordnet. Die Abbildung 7 zeigt

eine minimale Projektorganisation mit den Rollen Auftraggeber, Projektleiter und Anwender-vertreter als Vertreter des Entwicklungsteams und ihre Beziehung zur Stammorganisation. In

HERMES sind zahlreiche weitere Rollen definiert, die nach Bedarf verwendet werden.

Stammorganisation

Projektorganisation klassisch

Steuerung

Führung

Ausführung

Projektorganisation agil

Steuerung

Führung

AusführungAnwender-vertreter

Projektleiter

Auftraggeber

Projektleiter

Auftraggeber

EntwicklungsteamAnwender-

vertreter

Abbildung 7: Beziehung zwischen der Stamm- und einer minimalen Projektorganisation

B.5 Module

Module sind wiederverwendbare Bausteine zur Erstellung von Szenarien. Thematisch zusam-mengehörende Ergebnisse bilden samt Aufgaben ein Modul (s. Abbildung 8). Sie sind den Pha-sen zugeordnet.

Szenario

Modul A

Modul B

Modul N

Ergebnisse samt Aufgaben

AbschlussInitialisierungUmsetzung


Abbildung 8: Modul setzt sich aus Ergebnisse und Aufgaben zusammen

14 / 202

HERMES gruppiert beispielsweise die Aufgaben und Ergebnisse der Projektsteuerung im Mo-dul Projektsteuerung. Damit ist für den Auftraggeber gut ersichtlich, für welche Aufgaben und

Ergebnisse er verantwortlich ist.

Die Anwender von HERMES können zusätzliche Module erstellen, die sie in ihre individuellen Szenarien integrieren.

B.6 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 eingekapselte Entwicklungs-

vorgehen bestimmt, also bei der klassischen Vorgehensweise für die Phasen Konzept, Reali-sierung 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 genau 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 9 zeigt beispielhaft mehrere Vorhaben einer

Stammorganisation mit den dazu passenden Projekten samt Szenarien.

Vorhaben Projekte einer Stammorganisation mit Szenarien

Service public"Guichet Virtuel"

Projekt 3 Initialisierung AbschlussIT-Anwendung Entwicklung

Beschaffung GEVER-System

Fusion der Bereiche A & B

InfrastrukturHosting Services

Rechtsetzung Projekt n AbschlussInitialisierung Individuelles Szenario "abc"

Projekt 5 Initialisierung AbschlussOrganisationsanpassung

Projekt 2 AbschlussInitialisierung Dienstleistung/Produkt Entwicklung

Projekt 4 Initialisierung AbschlusslT-Infrastruktur

Projekt 1 AbschlussInitialisierung IT-Anwendung Adaption

Abbildung 9: 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, für den

Aufbau von IT-Infrastruktur 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.

C Datenmodell HERMES

Das HERMES-Datenmodell ist ein konzeptionelles Datenmodell, das die Daten und Informa-tionen aus methodischer Sicht beschreibt und deren Struktur formuliert. Die Abbildung 10

zeigt das UML Diagramm6des Datenmodells HERMES 2021.

Das Datenmodell HERMES wurde mittels INTERLIS7, einer bundeseigenen konzeptionellen Da-tenbeschreibungssprache erarbeitet. Mit diesem Datenmodell wird die HERMES-Kohärenz,

d. h. die einheitliche Struktur der Daten in einem Methodenelement festgelegt (z. B., dass jede

6 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. 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.

15 / 202

Aufgabe einem Modul zugeordnet gehört). Das HERMES-Datenmodell zu implementieren bedeutet, die Daten im entsprechenden Detailierungsgrad speichern, anzeigen und auch ge-

nerieren zu können.

basiertAuf

Das HERMES 2021 Datenmodell

existiert nur einsprachig.

Ergebnis

Name[1]

istMinimal[0..1]

Beschreibung[1]

Inhalt[0..1]

Unterkapitel[0..1]

Rolle

Name[1]

Beschreibung[1]

Verantwortung[1]

Kompetenzen[1]

Faehigkeiten[1]

Hinweise[0..1]

Beziehungen[0..1]

istMinimal[1]

Unterkapitel[0..1]Partner

Name[1]

Beschreibung[1]

Phase

Name[1]

Schwerpunkt[1]

Beschreibung[1]

Unterkapitel[0..1]

Methode

Name[1]

Beschreibung[1]

Vorlage

Dateiname[0..1]

Dateiinhalt[0..1]

Modul

Name[1]

WasIstZuTun[1]

Aufgaben[0..1]

Unterkapitel[0..1]

Szenario

Name[1]

Anwendbarkeit[1]

PhasenUndMeilensteine[0..1]

Module[0..1]

Aufgaben[0..1]

Ergebnisse[0..1]

Unterkapitel[0..1]

+

0..*0..*

1..*1..*

0..*

fuehrtZu+

1..*

1..*

1..*

0..*

Mitarbeiter+

0..*

0..*

Verantwortlicher+

1

0..*

1..*

0..*1..*

1..*

1..*

Hierarchieebene

Name[1]0..1

Name[1]

Zweck[1]

Grundidee[0..1]

HERMES_Spezifisch[0..1]

Grundlagen[0..1]

Aktivitaeten[1]

Ergebnisse[0..1]

istEntscheid[0..1]

Unterkapitel[0..1]

Aufgabe

Abbildung 10: UML Diagramm des HERMES 2021 Datenmodells

Mit Hilfe des HERMES-Datenmodell und der Beschreibungssprache INTERLIS sollen die ange-strebte Weiterentwicklung von neuen Methodenelementen, aber auch der Ausbau bestehen-

der Methodenelemente wie zum Beispiel des vorliegenden Projektmanagements vorangetrie-ben werden.

D Sichten auf das Projekt

D.1 Übersicht über die Sichten

Aufgrund der klaren Struktur von HERMES Projektmanagement mit den Rollen, Aufgaben und Ergebnissen können verschiedene Sichten auf das Projekt eingenommen werden (s. Abbil-

dung 11).

Sicht des zeitlichen Ablaufs

Sicht der Partner

Sicht der Hierarchieebenen

16 / 202

Zeitlicher Ablauf

Partner

Szenarien

Szenarien

Module

Module

Ergebnisse

Aufgaben Rollen

Hierarchie

Steuerung

Führung

Ausführung

Agil

Klassisch

Umsetzung

EinführungRealisierungKonzeptAbschlussInitialisierung

Anwender

BetreiberErsteller Abbildung 11: Sichten auf Projekt

17 / 202

D.2 Sicht des zeitlichen Ablaufs

Das Phasenmodell gliedert den Lebenszyklus des Projekts und schafft die Voraussetzung für das gemeinsame Verständnis der Projektbeteiligten betreffend den Projektablauf.

Die Sicht des zeitlichen Ablaufs zeigt,

welche Aufgaben und Ergebnisse in welcher Phase bearbeitet werden,

welche Meilensteine in welcher Phase liegen und welche Entscheide dabei getroffen wer-

den.

D.3 Sicht der Partner

Eine Rolle ist einem oder mehreren Projektpartnern (Anwender, Ersteller oder Betreiber) zu-geordnet. Der Rolleninhaber vertritt die Sicht seiner Organisation im Projekt.

Aufgrund der Zuordnung der Rollen zu einem Partner sieht jeder Partner,

welche Rollen er typischerweise im Projekt besetzen muss,

für welche Aufgaben er verantwortlich ist,

für welche Ergebnisse er mitarbeitend wirkt.

D.4 Sicht der Hierarchieebenen

Die Hierarchieebenen regeln die Verantwortung in einem Projekt. Sie unterstützen die Einhal-tung der Governance.

Die Sicht der Hierarchieebenen zeigt,

welche Entscheidungsaufgaben auf welcher Hierarchieebene angesiedelt sind,

welche Ergebnisse auf welcher Hierarchieebene anfallen,

welcher Hierarchieebene die Rollen zugeordnet sind.

19 / 202

PH

ASEN 1 Phasen

1.1 Einleitung

1.1.1 Projektlebenszyklus

Die HERMES Projektmanagementmethode unterstützt mit ihrem HERMES-Phasenmodell so-

wohl klassisches als auch agiles Entwicklungsvorgehen. Das Phasenmodell selbst beruht auf dem Lebenszyklus des Projekts und schafft somit die Voraussetzung für das gemeinsame Ver-

ständnis aller Projektbeteiligten vom Projektablauf. Egal, ob das Entwicklungsvorgehen auf die klassische oder auf die agile Art abgewickelt wird, die Phasen bestimmen die Projektstruktur.

Die Abbildung 12 zeigt den HERMES Projektlebenszyklus (Project LifeCycle).

Projekt

Umsetzung



Projektbeginn ProjektendeLösungsentstehung

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 auch der mögliche Handlungsbedarf o-der der Einfluss externer oder übergeordneter Instanzen im Fokus.

Die Lösungsentstehung nach klassischer oder agiler Vorgehensweise erfolgt anlässlich der Umsetzungsfreigabe.

Das Projektende schliesst das laufende Projekt organisatorisch und formell ab und bereitet

den Wechsel zur nachfolgenden Anwendungsorganisation vor.

1.1.2 Projektbeginn

Umsetzung


Im Projektbeginn, dem ersten Zyklus des Projekts, ist stets die Phase Initialisierung angesiedelt. Die Abbildung 13 zeigt das Ablaufschema der Initialisierung.


Umsetzungs-auftrag

Projektgrundlagen

Projektinitialisie-rungsauftrag

Stakeholderliste

Rechts-grundlagen-

analyse

Projekt-managementplan

StudieBeschaffungs-

analyseSchutzbedarfs-

analyse

Ori

entieru

ng

Abbildung 13: Ablaufschema der Initialisierung samt Ergebnissen

20 / 202

PH

ASEN

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-

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 bzw. des Entwicklungsvorgehens. Die Mehrzahl der Methodenelemente bleibt in bei-

den Vorgehensarten dennoch annährend identisch; unterschiedlich sind die Organisation und die Struktur des Projekts, folglich auch das Entwicklungsvorgehen und letztlich teilweise auch

der technische und formelle Inhalt der erarbeiteten Ergebnisse.

Im agilen Entwicklungsmanagement sind Änderungen essenziell. Das Entwicklungsteam folgt

der vorgegebenen und gewünschten Wirkung und reagiert proaktiv auf die sich ändernde Anforderungen anstatt einen fixen Plan zu verfolgen. Die Entwicklung und die Einführung er-

folgen iterativ-inkrementell. Eine Phasenstruktur macht in diesen Prozessen keinen Sinn. Des-halb ist im agilen Teil des HERMES Phasenmodells nur die Phase Umsetzung wirklich agil und

kann nicht weiter unterteilt werden. Dennoch verbleiben einige Aktivitäten, die im normalen Iterationsvorgehen keinen Platz haben und klassisch abgewickelt werden müssen.

Je nachdem, welches Entwicklungsvorgehen gewählt wird, wird nach einer Umsetzungsfrei-gabe die Lösungsentstehung des Projektes entweder

klassisch

mit den Phasen Konzept, Realisierung und Einführung, oder

agil mit der Phasen Umsetzung fortgesetzt

und wieder gemeinsam 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


Die letzte Phase jedes Projekts ist stets die Phase Abschluss, in der das Projekt endgültig be-endet wird. Das wichtigste Augenmerk gilt der Projektdokumentation, die entsprechend ge-prüft und insbesondere aus formeller Sicht, sofern angebracht, 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 deakti-

viert oder entfernt, etwaige Projektdaten gemäss Bestimmungen der Stammorganisation der Archivierung zugeführt und die Verantwortung für die Lösung weitergegeben.

Die Phase Abschluss verfolgt u. a. den Zweck sicherzustellen, dass die organisatorische und administrative Schnittstellen des Projekts (gegenüber der Stammorganisation, dem Pro-gramm, dem Portfolio, der Anwenderorganisation, allenfalls der Betriebsorganisation usw.)

unabhängig vom gewählten Projektvorgehen stets die gleichen bleiben.

1.2 Phasenübersicht

Da die Projekte in unterschiedlichen Organisationen zum Einsatz kommen, kann nicht erwartet

werden, dass die Entscheidungsträger der Stammorganisation je nach Vorgehen umdenken und sich der jeweiligen Projektvorgehensweise anpassen. Deshalb sind die Anforderungen an

das HERMES-Phasenmodell entsprechend hoch.

21 / 202

PH

ASEN

Das Phasenmodell soll:

fugenlos in die Projektmanagement Methode HERMES passen und nach aussen hin, ins-

besondere gegenüber der Stammorganisation, gleichwertig interagieren;

sich vollständig in eine die klassische Vorgehensweise favorisierende Stammorganisation

einfügen und dennoch sowohl das klassische, als auch das agile Vorgehen unterstützen;

die bestehenden HERMES Methodenelemente verwenden, Synergien nutzen und jegliche

Redundanzen vermeiden;

den üblichen Controlling- und Reporting Anforderungen des Managements der Stam-

morganisation genügen; und

verständlich bleiben sowie einfach anwendbar sein.

Die Tabelle zeigt das HERMES-Phasenmodell für klassisches und agiles Projektvorgehen – das klassische Vorgehen mit fünf, und das agile Vorgehen mit drei Phasen:

HERMES Phasen klassisches Vorgehen

Projektlebenszyklus HERMES Phasen agiles Vorgehen

Initialisierung Projektbeginn Initialisierung

Konzept

Lösungsentstehung Umsetzung Realisierung

Einführung

Abschluss Projektende Abschluss

Tabelle 1: HERMES-Phasen für klassisches und agiles Projektvorgehen

Ein Vorhaben beginnt stets mit der Phase Initialisierung und endet mit der Phase Abschluss. Im Anschluss an die Phase Initialisierung startet die Lösungsentstehung entweder mit den klassischen Phasen Konzept, Realisierung und Einführung oder mit der agilen Phase Umset-

zung. Die Abbildung 14 stellt das HERMES-Phasenmodell für klassisches und agiles Projekt-vorgehen grafisch dar.


Umsetzung


agil

klassisch

Abbildung 14: HERMES Phasenmodell für klassische und agile Projekte

Entlang den Phasen erfolgt das Reporting im Einklang mit den Vorgaben der Stammorgani-sation bezüglich des Inhalts und je nach Machbarkeit auch der Frequenz.

Das klassische Projektvorgehen bildet eine Grundlage für die finanzielle Steuerung des Pro-jekts. Bei Phasenfreigabe werden die Ressourcen (finanziell, personell, Infrastruktur) für die nächste Phase durch den Auftraggeber freigegeben. Das agile Projektvorgehen dient insbe-

sondere der Einbettung der agilen Entwicklung in das HERMES Framework, gleichgültig wel-cher agilen Methode.

Das nachfolgende Kapitel beschreibt die Phasen mit ihrem jeweiligen Schwerpunkt.

1.3 Erläuterung der Phasenbeschreibung

Für jede Phase gibt es eine Phasenbeschreibung, die stets gleich aufgebaut ist:

Erster Abschnitt

Umschreibung der Phase, hervorgehobene Schrift

Mittlerer Bereich mit Aufzählungspunkten

Aufzählung und Beschreibung der Aktivitäten im Verlauf der Phase

Letzter Abschnitt Abschlussaktivitäten der Phase, hervorgehobene Schrift

22 / 202

PH

ASEN 1.4 Phasenverzeichnis

1.4.1 Projektbeginn

1.4.1.1 Initialisierung

LösungsentstehungOrientierung Übergang






Die Phase Initialisierung wird unabhängig von der späteren Vorgehensweise bei jedem

Projekt durchgeführt. Sie schafft eine definierte Ausgangslage für das Projekt und stellt

sicher, dass die Projektziele mit den Zielen und Strategien der Organisation abgestimmt sind. Die Projektgrundlagen und der Umsetzungsauftrag werden erarbeitet und der Ent-

scheid Umsetzungsfreigabe wird getroffen.

Auf der Grundlage des Projektinitialisierungsauftrags gibt der Auftraggeber die Ressour-

cen für die Phase Initialisierung frei. Er beauftragt einen Projektleiter mit der Durchführung der Phase Initialisierung.

Die Phase Initialisierung wird aus Projektmanagementsicht klassisch abgewickelt. Da aber

HERMES methodenneutral ist, können durchaus auch agilen Methoden zum Einsatz kom-men, wie bspw. 'Agiles Requirements Engineering'.

Die Studie mit grober Standortbestimmung, Zielen und groben Anforderungen sowie die Varianten werden erarbeitet. Die Beschreibung der Varianten erfolgt so detailliert, dass sie

nachvollziehbar und transparent bewertet werden können. Unter anderem werden die Projekt- und Betriebsrisiken ermittelt, die Rechtsgrundlagenanalyse und die Schutzbe-

darfsanalyse erarbeitet und in die Entscheidung einbezogen. Zusätzlich wird festgelegt und nachvollziehbar dokumentiert, wie im Rahmen jeder Variante weiter vorgegangen

wird: entweder klassisch oder agil. Der Entscheid weiteres Vorgehen wird getroffen.

Das für das Entwicklungsvorgehen passende Szenario auswählen, eventuelle individuali-

sieren.

Für die allfällige Beschaffung eines Produkts bzw. eines Systems wird eine Beschaffungs-

analyse durchgeführt.

Auf der Basis der gewählten Variante und des Vorgehens werden Projektmanagementplan

und Umsetzungsauftrag erarbeitet und mit den Strategien, Vorgaben und übergeordne-ten Zielen der Stammorganisation abgeglichen. Die Stakeholderinteressen werden analy-

siert und Zielkonflikte bereinigt.

Der Entscheid Umsetzungsfreigabe wird getroffen und der Umsetzungsauftrag unter-

zeichnet. Die Freigabe erfolgt durch die Stammorganisation und den Auftraggeber.

Am Ende der Phase Initialisierung wird geprüft, ob es sinnvoll ist, die Umsetzung des

Projekts freizugeben. Mögliche Gründe für eine Beendigung sind fehlende Wirtschaft-lichkeit, zu hohe Risiken, keine Realisierbarkeit, rechtliche oder politische Bedenken, feh-

lende Übereinstimmung mit den Zielen, Strategien und Prioritäten der Organisation.

1.4.2 Lösungsentstehung klassisch

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 Organisation, das Produkt oder das System auf einer verlässlichen Grundlage planen, offerieren und realisieren

können.

Basierend auf der gewählten Variante sowie der Standortbestimmung aus der Studie wer-

den 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

23 / 202

PH

ASEN

-strukturen tangiert werden, sind zwingend die Organisationsanforderungen und an-schliessend das Organisationskonzept zu erarbeiten.

Die Lösung wird konzeptionell erarbeitet. Die Machbarkeit wird zum Beispiel mit Prototy-pen ü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). Die Ressourcen für die nächste Phase werden aufgrund des konkretisierten Pro-jektmanagementplans und der vorliegenden Angebote freigegeben. Die Projekt- und Be-

triebsrisiken müssen identifiziert, analysiert und bewertet sein. Die Machbarkeit muss nachgewiesen sein.

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 werden realisiert und getestet. Die nötigen Vorarbeiten

werden geleistet, um die Einführungsrisiken zu minimieren.

Das Produkt bzw. das System werden entwickelt oder, sofern sie beschafft wurden, para-metrisiert bzw. angepasst.

Die Organisation sowie die Betriebsorganisation werden realisiert und die Dokumentatio-nen erarbeitet.

In IT-Projekten wird das System in die Betriebsinfrastruktur integriert und die Vorabnahme

durchgeführt.

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.

1.4.2.3 Einführung

Umsetzung





In der Phase Einführung wird der sichere Übergang vom alten zum neuen Zustand ge-

währleistet. Der Betrieb wird aufgenommen.

Die Einführungsmassnahmen wie Anwenderschulung usw. werden durchgeführt.

Der Betrieb wird vorbereitet und das Produkt bzw. das System sowie Geschäftsorganisa-

tion und Betriebsorganisation werden aktiviert.

Je nach Szenario wird eine Migration durchgeführt.

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.

24 / 202

PH

ASEN

1.4.3 Lösungsentstehung agil

1.4.3.1 Umsetzung

Umsetzung





Die in der Phase Initialisierung gewählte Variante wird sukzessive iterativ-inkrementell

umgesetzt. Das Entwicklungsteam wird formell in der Projektorganisation etabliert, die

Projektorganisation als Ganzes wird gegenüber Stammorganisation und Stakeholdern kommuniziert. Die Lösungsanforderungen werden weiter aufgeteilt, verfeinert und kon-

kretisiert. Die geschätzten und priorisierten Aufträge werden nach absteigender Priorität abgearbeitet (entwickelt, realisiert, eingeführt und in Betrieb genommen), wobei die Pri-

oritäten kontinuierlich aktualisiert und den Projekterkenntnissen entsprechend ange-passt 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: o Die Lösungsanforderungen werden laufend konkretisiert, verfeinert, vervollständigt

und soweit aufgeteilt, dass sie in einem Iterationszyklus abgearbeitet werden können. Die einzelnen Aufträge werden priorisiert.

o Führend wird das Organisationskonzept erarbeitet und die sukzessive entstehende Or-ganisation realisiert und dokumentiert.

o Die Projekt-, Betriebs- und Einführungsrisiken werden identifiziert, analysiert, bewertet und vertretbar beurteilt. Die Gewissheit über die Machbarkeit wird stets gewahrt.

o Die Lösungsanforderungen werden in absteigender Priorität abgearbeitet und das Produkt entwickelt oder angepasst bzw. das System entwickelt oder parametrisiert.

o Begleitend wird die Betriebsorganisation konzeptuell erarbeitet, realisiert und doku-mentiert.

o Bei Systemen wird das Integrationskonzept erarbeitet und (pro Iteration oder Release) der Entscheid Lösungsarchitektur getroffen.

o Bei Systemen werden (pro Iteration oder Release) Tests konzipiert und durchgeführt, die Migration vorbereitet und durchgeführt und das System in die Betriebsinfrastruktur

integriert. o Die Vorabnahme wird durchgeführt.

Gemäss Releaseplan werden pro Inkrement die Einführung konzeptuell erarbeitet, die Ein-führungsmassnahmen wie Anwenderschulung usw. durchgeführt, der Betrieb vorbereitet

und das Produkt bzw. das System sowie die Geschäfts- und die Betriebsorganisation akti-viert.

Entsprechend den Bestimmungen des Projektmanagementplans wird der Entscheid über

die Freigabe des nächsten Releases 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 vollendeter Betriebsaufnahme inklusive der Abnahme des letzten Releases werden der agile Teil des Projekts und somit die Phase Umsetzung abgeschlos-

sen und das Entwicklungsteam formell in der Projektorganisation aufgelöst.

25 / 202

PH

ASEN

1.4.4 Projektende

1.4.4.1 Abschluss







In der Phase Abschluss wird der Betrieb so lange durch das Projekt unterstützt, bis er

stabil ist. Die neue Phase bietet eine Struktur für das systematische Herunterfahren eines

Projektes, insbesondere im Verwaltungsumfeld. Die Projektdokumentation wird geprüft und je nach Bedarf ergänzt. Der Projektabschluss wird vorbereitet.

Während der ersten Betriebszeit des vollständigen Systems oder Produkts unterstützt das Projekt die Problemanalyse und Problembehebung.

Das Altsystem wird vollständig ausser Betrieb gesetzt.

Die Ergebnisse werden geprüft und insbesondere aus formeller Sicht ergänzt.

Es wird geprüft und entschieden, ob die Projektorganisation aufgelöst bzw. teilweise oder

vollständig in die Anwendungsorganisation übergeht.

In IT-Projekten werden die Projektergebnisse, Testinfrastruktur samt Testkonzept und

Hilfsmittel an die Stammorganisation z.H. der Anwendungs-, Betriebs- und Wartungsor-ganisation übergeben.

Die Dokumentation der Projektabwicklung inklusive der Vorgehensergebnisse usw. wer-den gemäss den Ablagevorschriften der Stammorganisation archiviert.

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 wird je nach Bestimmungen der Stammorganisation entweder auf-gelöst oder sie geht (evtl. nur teilweise) in eine mögliche Anwendungsorganisation über.

26 / 202

ER

GEBN

ISSE

2 Ergebnisse

2.1 Einleitung

2.1.1 Ergebnispositionierung

Ergebnis als HERMES Methodenelement

HERMES ist eine ergebnisorientierte Methode, die Ergebnisse sind die wichtigsten Methoden-elemente im HERMES, sie stehen im Zentrum.

HERMES Projektmanagement unterscheidet zwischen zwei Arten von Ergebnissen. Ein Ergeb-nis kann

1. ein Dokument sein, das auf der Basis einer möglichst vorhandenen Dokumentvorlage er-arbeitet wird, wie beispielsweise ein Umsetzungsauftrag, eine Studie, eine Checkliste oder

eine Prozessbeschreibung;

2. ein Zustand sein, der neu erreicht wird, wie beispielsweise 'Betriebsinfrastruktur realisiert',

der 'System aktiviert' oder auch ein Meilenstein, der die direkte Folge eines Entscheids ist;.

Hermes definiert ferner spezielle Ergebnisse, denen besondere Aufmerksamkeit gebührt.

Abgrenzung

Das Ergebnis eines ganzen Projekts, die eigentliche Lösung, ist hingegen kein HERMES-Me-thodenelement. Dies können ein Produkt, Dienstleistungen, IT-Anwendungen, Infrastrukturen, geänderte, neue betriebliche Organisationen, neue oder fusionierte Stammorganisationen o-

der einzelne Organisationseinheiten usw. sein. Das Projektergebnis besteht oft auch aus aus-gebildeten Anwendern und der aktivierten Organisation mit ihren Prozessen. Am Ende eines

erfolgreichen Projekts resultiert also als Ergebnis eine Lösung, ein Gesamtsystem, bestehend aus einem oder mehreren aktivierten Elementen.

2.1.2 Spezielle Ergebnisse

2.1.2.1 Checklisten

Checklisten gehören zu den Dokumenten. Sie stellen Kataloge von Kontroll- und Prüfungs-schritten dar, die im Rahmen einer Entscheidungsvorbereitung systematisch und vollständig

durchgeführt werden sollen. Dies verringert die Wahrscheinlichkeit von Fehlentscheiden, weil der eine oder andere Aspekt nicht berücksichtigt wurde.

Jede Checkliste ist auf einen konkreten Entscheid abgestimmt und nennt die notwendigen Prüfpunkte mit Ergebnis, Abnahmekriterien, Bewertung, Verantwortlichen und Prüfungsda-tum. Die von HERMES bereitgestellten Dokumentvorlagen der Checklisten sollen im Rahmen

der Entscheidungsvorbereitung mit weiteren Projekt- und Lösungsspezifischen Kriterien er-gänzt werden.

2.1.2.2 Minimal geforderte Dokumente

In HERMES Projektmanagement sind minimal geforderte Dokumente definiert, die benötigt werden, um die Anforderungen der Governance zu erfüllen. Dazu gehören u. a. nicht nur die-

jenigen 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 (vgl. Tabelle 2) sind die Leitplanken für die Sicherstellung des Projekterfolges und widerspiegeln eine allgemeine Projektsituation ohne auf die Beson-derheiten der einzelnen Projekte einzugehen. Die Erarbeitung der minimal geforderten Do-

kumente ist obligatorisch. Ist ein Modul nicht relevant für das Projekt, entfallen auch die darin definierten minimal geforderte Dokumente. Sie entfallen ebenso, wenn unter gewissen Um-

ständen ihre Verwendung im Modul nicht vorgesehen ist (z.B. im Fall klassisch/agil).

2.1.2.3 Meilensteine

Meilensteine gehören zu den Zuständen. Sie sind spezielle Ergebnisse, die immer die Folge

27 / 202

ER

GEBN

ISSE

eines Entscheides sind und einen erreichten konkreten Zeitpunkt im Projektverlauf kennzeich-nen bzw. definieren. Sie dienen als anvisierte und erreichte Entscheidungsergebnisse der Pro-

jektsteuerung und -führung, verleihen dem Projekt eine Struktur und markieren in der Pro-jektdurchführung wichtige Punkte, an denen über das weitere Vorgehen entschieden wird

oder etwas gestartet oder abgeschlossen werden kann. Eine Entscheidung endet mit einem Entscheidungsergebnis Meilenstein.

Gemäss Abbildung 15 stehen am Anfang und am Ende der Phasen Meilensteine. Optional können für die agile Phase Umsetzung weitere Meilensteine für die Releasefreigabe festgelegt werden.

Umsetzung



Projekt-

abschluss

Projekt-

initialisierungs-

freigabe

Release 2Release 1 Release n



Umsetzungs-

freigabe

Phasen-

freigabe

Phasen-

freigabe

Phasenfreigabe

Abschluss

Abbildung 15: HERMES Meilensteine am Beginn und am Ende jeder Phase und bei Releasefreigabe

Diese Meilensteine entsprechen Quality Gates, an denen über Ergebnisse und das Vorgehen entschieden wird. Bei jedem Meilenstein werden die Einhaltung der Vorgaben und die Über-einstimmung des Projekts mit den strategischen Zielen der Stammorganisation sowie mit den

Nachhaltigkeitszielen überprüft.

Je nach Szenario gibt es weitere spezifische Meilensteine. Die Abbildung 16 zeigt als Beispiel

die Entscheidungsergebnisse bzw. Meilensteine der Steuerung sowie der Führung und Aus-führung für klassische und agile IT-Entwicklungsprojekte.

Führung und Ausführung

Release n

Führung und Ausführung

Steuerung

klassisch

Steuerung

agil

Umsetzungs-

freigabe


Phasen-

freigabe

Phasen-

freigabe

Betriebs-

aufnahme

Phasenfreigabe

Abschluss

Abschluss

Projekt-

abschluss

AbnahmeVorab-

nahme

Projekt-

initialisierungs-

freigabe

Initialisierung

ISDS-

Konzept

Lösungs-

architektur

Weiteres

Vorgehen

Abnahme

Migration

Projekt-

initialisierungs-

freigabe

Initialisierung Abschluss

Projekt-

abschluss

Weiteres

Vorgehen

Phasenfreigabe

AbschlussUmsetzungs-

freigabe

UmsetzungRelease 2Release 1 Release z


Vorab-

nahme

Betriebs-

aufnahmeAbnahme

Lösungs-

architektur

ISDS-

Konzept

Abnahme

Migration

pro Release


Abbildung 16: Meilensteine für klassische und agile IT-Entwicklungsprojekte

Beim Meilenstein weiteres Vorgehen und bei weiteren Meilensteinen – wie beispielsweise dem Meilenstein Lösungsarchitektur – wird die Erreichung der Nachhaltigkeitsziele als Bewertungs-

kriterium mitberücksichtigt.

28 / 202

ER

GEBN

ISSE

2.2 Ergebnisse-Übersicht

Die folgende Tabelle listet alle im HERMES standardmässig vorgesehenen Dokumente auf. Die "minimal geforderten Dokumente" sind mit einem X markiert. Die Minimalliste widerspie-gelt eine allgemeine Projektsituation ohne auf Spezialitäten der einzelnen Projekte einzuge-

hen. Dokumente

minimal geforderte Dokumente = X minimal geforderte Dokumente = X

Abnahmeprotokoll X Produktdokumentation X

Änderungsantrag X Produktkonzept X

Änderungsstatusliste X Projekterfahrungen

Angebot X Phasenbericht X

Angebotsprotokoll Projektinitialisierungsauftrag X

Anwendungshandbuch Projektmanagementplan X

Arbeitsauftrag Projektschlussbeurteilung X

Ausschreibungsunterlagen X Projektstatusbericht X

Beschaffungsanalyse Protokoll

Betriebshandbuch X Prototyp

Betriebskonzept X Prototypdokumentation

Checklisten Prozessbeschreibung X

Detailspezifikation X Prüfprotokoll

Einführungskonzept X Publikation X

Evaluationsbericht X QS- und Risikobericht X

Geschäftsmodellbeschreibung X Rechtsgrundlagenanalyse X

Inkrement Releasebericht

Integrations- und Installationsanleitung Releaseplan

Integrationskonzept X Schutzbedarfsanalyse X

ISDS-Konzept X Service Level Agreement

Liste Projektentscheide Führung X Situationsanalyse X

Liste Projektentscheide Steuerung X Stakeholderinteressen

Lösungsanforderungen X Stakeholderliste X

Lösungsarchitektur X Studie X

Migrationskonzept Systemkonzept

Offertanfrage X Testkonzept X

Organisationsanforderungen X Testprotokoll X

Organisationsbeschreibung X Umsetzungsauftrag X

Organisationskonzept Vereinbarung

Tabelle 2: Liste der HERMES Dokumente – die minimal geforderten sind mit einem X markiert

Die folgende Tabelle listet alle Zustände auf. Zustände

Altsystem entfernt Migrationsverfahren realisiert

Betrieb aktiviert Organisation umgesetzt

Betriebsinfrastruktur realisiert Produkt aktiviert

Betriebsorganisation realisiert Produkt entwickelt oder angepasst

Einführungsmassnahmen durchgeführt Schnittstellen realisiert

Einführungsmassnahmen realisiert System aktiviert

Organisation aktiviert System entwickelt oder parametrisiert

ISDS-Konzept überführt System integriert

ISDS-Massnahmen realisiert Testinfrastruktur realisiert

Meilensteine Testinfrastruktur überführt


Tabelle 3: HERMES Liste der HERMES Zustände

2.3 Erläuterung der Ergebnisbeschreibung

Für jedes Ergebnis gibt es eine Ergebnisbeschreibung, die immer gleich strukturiert ist:

Beschreibung Schafft das grundlegende Verständnis des Ergebnisses.

29 / 202

ER

GEBN

ISSE

Inhalt (nur bei Dokumenten)

Beschreibt den Inhalt eines Dokuments.

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.

Für viele Dokumente steht eine Dokumentvorlage zur Verfügung. Sie verfeinert die Ergebnis-beschreibung und ist ein konkretes Hilfsmittel für die Anwendung von HERMES. Die Doku-

mentvorlagen können an die Bedürfnisse der Organisation angepasst werden.

HERMES stellt keine keine Dokumentvorlagen bereit, wenn die Dokumentvorlage projektspe-zifisch oder durch die Stammorganisation vorgegeben sind wie beispielsweise

Anwendungshandbuch oder

Vereinbarungen.

2.4 Ergebnisse-Verzeichnis

2.4.1 Dokumente

2.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.

o Massnahmen

o Verantwortlichkeiten und o Terminen

Abnahmeergebnis

Unterschrift

2.4.1.2 Änderungsantrag

Beschreibung

Der Änderungsantrag kommt ausschliesslich bei klassisch geführten Projekten zum Tragen

und bildet die Grundlagen für eine Änderung. Er umfasst die Änderungsbeschreibung mit dem eigentlichen Antrag, das Vorgehen, um die Änderung durchzuführen, und den Lösungs-

vorschlag, um die Änderung umzusetzen. Der Änderungsantrag hat Anforderungscharakter und spezifiziert die durchzuführende Änderung im Detail.

Inhalt

Identifikation Änderungsantrag

Antragsteller

Änderungsbeschreibung

Angaben zur Ausführung

Lösungsvorschlag

Beurteilung der Auswirkungen

o Aufwand

30 / 202

ER

GEBN

ISSE

o Kosten o Termin

o Risiken

2.4.1.3 Änderungsstatusliste

Beschreibung

Die Änderungsstatusliste dient zur Überwachung der Änderungsanträge sowie der Dokumen-tation aller hinzugefügten, gelöschten oder geänderten Funktionen oder sonstiger durchge-

führter Änderungen (Changes Report). Sie unterstützt die Nachvollziehbarkeit der Projekt-durchführung (Governance) und gibt einen Überblick über deren Bearbeitungsstatus und

– falls die Änderungen erfolgen – den Status der Änderungen.

Inhalt

Je Änderung: (A=agil, K=klassisch)

Verantwortlich A K

Eingangsdatum A K

Identifikation Änderungsantrag K

Änderung / Kurzbeschreibung A

Entscheidungsverantwortlicher K

Status A K

Änderungsdatum A K

Änderungsverantwortlicher K

Aufwand K

Kosten K

Zudem:

Total Aufwand und Kosten aller bewilligter Änderungsanträge K

2.4.1.4 Angebot

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 des Beschaffers.

2.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

Protokollpositionen

Pendenzenliste (Anhang)

31 / 202

ER

GEBN

ISSE

2.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.

Inhalt

Übersicht

Funktionen

Detailbeschreibungen zur Anwendung

Mängelbehandlung

2.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

o Terminen o Status

Ressourcenbedarf

Ergebnisdarstellung

Qualitätssicherung

2.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.

Ohne ein Lastenheft ist es praktisch unmöglich die eingegangenen Angebote miteinander zu vergleichen. Das von der ausschreibenden Stelle erstellte Lastenheft der zu erbringenden Leis-

tung dient sowohl ihr wie dem potentiellen Anbieter. Die ausschreibende Stelle wird sich bei der Erstellung bewusst, was sie wirklich benötigt, der Anbieter wiederum erkennt, was der

Kunde will. Es zwingt ihn aber auch, zu Fragen Stellung zu nehmen, denen er vielleicht lieber ausweichen möchte, ferner, das Angebot in geforderter Struktur abzugeben. So erhält die

auszuschreibende Stelle eine klare Bezugsbasis und sie kann die Angebote untereinander ver-gleichen.

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

32 / 202

ER

GEBN

ISSE

Anbietern zugestellt werden.

Inhalt

Lastenheft mit o Ausgangslage mit

Einleitung, Zweck des Dokuments o Grund für die Ausschreibung, Handlungsbedarf

Beschaffungsgegenstand o Beschreibung der Situation mit

Geschäftsorganisation Stärken und Schwächen

Mengen und Häufigkeiten Umfang und Preis

o Soll-Zustand mit Zielen und Anforderungen

Muss- und Kann-Kriterien 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

2.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 andere Rahmenbedingun-

gen zu beachten sind und welches Beschaffungsverfahren zum Tragen kommt. Die Analyse 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 Umsetzung freigegeben wird oder nicht. Ebenso ist sie die Voraussetzung für die Erar-beitung des Projektmanagementplans und des Umsetzungsauftrags.

Inhalt

Grund für die Ausschreibung, 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 potentieller 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

33 / 202

ER

GEBN

ISSE

Terminliche Aspekte (Grundlage für Beschaffungsplan)

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?

Ausschreibungsverfahren

Vorgehen bei Fragen zur Ausschreibung, zu den Unterlagen

2.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.

In agilen Projekten wird das Betriebshandbuch mehrmals, pro Iteration/Release, entsprechend der Aktivierung eines vollständigen Teils der Lösung aktualisiert, vervollständig und erweitert.

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

Changemanagement mit o Changemanagement-Prozess

o Changemanagement-Organisation mit Rollen

Kontaktinformationen

Sicherheitsbestimmungen

Anhänge

o Betriebskonzept

o Integrationskonzept

2.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

34 / 202

ER

GEBN

ISSE

o Netze o Datensicherung

o Archivierung

Organisation

o Aufbauorganisation o Betriebsprozesse

Systembetrieb mit

o Normalbetrieb o Systemüberwachung

o Arbeitsvorbereitung

Behandlung von Störungen

Beschreibung der Sicherheitsaspekte

Anforderungsabdeckung

2.4.1.12 Checklisten

Beschreibung

Checkliste Abnahme

Die Checkliste Abnahme beschreibt alle generellen und projektspezifischen Prüfpunkte und Kri-

terien, die für den Entscheid Abnahme notwendig sind.

Checkliste Abnahme Migration

Die Checkliste Abnahme Migration beschreibt alle generellen und projektspezifischen Prüf-

punkte und Kriterien, die für den Entscheid Abnahme Migration notwendig sind.

Checkliste Ausschreibung

Die Checkliste Ausschreibung beschreibt alle generellen und projektspezifischen Prüfpunkte

und Kriterien, die für den Entscheid Ausschreibung notwendig sind.

Checkliste Betriebsaufnahme

Die Checkliste Betriebsaufnahme beschreibt alle generellen und projektspezifischen Prüfpunkte

und Kriterien, die für den Entscheid Betriebsaufnahme notwendig sind.

Checkliste ISDS-Konzept

Die Checkliste ISDS-Konzept beschreibt alle generellen und projektspezifischen Prüfpunkte und

Kriterien, die für den Entscheid ISDS-Konzept notwendig sind.

Checkliste Lösungsarchitektur

Die Checkliste Lösungsarchitektur beschreibt alle generellen und projektspezifischen Prüf-

punkte und Kriterien, die für den Entscheid Lösungsarchitektur notwendig sind.

Checkliste Phasenfreigabe

Die Checkliste Phasenfreigabe beschreibt alle generellen und projektspezifischen Prüfpunkte

und Kriterien, die für den Entscheid Phasenfreigabe notwendig sind.

Checkliste Phasenfreigabe Abschluss

Die Checkliste Phasenfreigabe Abschluss beschreibt alle generellen und projektspezifischen

Prüfpunkte und Kriterien, die für den Entscheid Phasenfreigabe Abschluss notwendig sind.

Checkliste Produktkonzept

Die Checkliste Produktkonzept beschreibt alle generellen und projektspezifischen Prüfpunkte

und Kriterien, die für den Entscheid Produktkonzept notwendig sind.

Checkliste Projektabbruch

Die Checkliste Projektabbruch beschreibt alle generellen und projektspezifischen Prüfpunkte

und Kriterien, die für den Entscheid Projektabbruch notwendig sind.

Checkliste Projektabschluss

Die Checkliste Projektabschluss beschreibt alle generellen und projektspezifischen Prüfpunkte

und Kriterien, die für den Entscheid Projektabschluss notwendig sind.

Checkliste Projektinitialisierungsfreigabe

Die Checkliste Projektinitialisierungsfreigabe beschreibt alle generellen und projektspezifischen

Prüfpunkte und Kriterien, die für den Entscheid Projektinitialisierungsfreigabe notwendig sind.

Checkliste Releasefreigabe

Die Checkliste Releasefreigabe beschreibt alle generellen und projektspezifischen Prüfpunkte

35 / 202

ER

GEBN

ISSE

und Kriterien, die für den Entscheid Releasefreigabe notwendig sind.

Checkliste Umsetzungsfreigabe

Die Checkliste Umsetzungsfreigabe beschreibt alle generellen und projektspezifischen Prüf-

punkte und Kriterien, die für den Entscheid Umsetzungsfreigabe notwendig sind.

Checkliste Vorabnahme

Die Checkliste Vorabnahme beschreibt alle generellen und projektspezifischen Prüfpunkte und

Kriterien, die für den Entscheid Vorabnahme notwendig sind.

Checkliste Weiteres Vorgehen

Die Checkliste Weiteres Vorgehen beschreibt alle generellen und projektspezifischen Prüf-

punkte und Kriterien, die für den Entscheid Weiteres Vorgehen notwendig sind.

Checkliste Zuschlag

Die Checkliste Zuschlag beschreibt alle generellen und projektspezifischen Prüfpunkte und Kri-

terien, die für den Entscheid Zuschlag notwendig sind.

2.4.1.13 Detailspezifikation

Beschreibung

Die Detailspezifikation konkretisiert die funktionalen und qualitativen Anforderungen und be-schreibt die detaillierten Lösungseigenschaften. Sie basiert auf den Lösungsanforderungen

und auf dem Produktkonzept bzw. bei IT-Projekten auf dem Systemkonzept und der Lösungs-architektur. Sie wird inhaltlich und planerisch so detailliert erstellt, dass sie eine verlässliche

Grundlage für die Realisierung (Entwicklung und Anpassung bzw. Entwicklung und Paramet-risierung) der Lösung bildet. Die Detailspezifikation bildet im weiteren Projektverlauf die

Grundlage für die Erstellung von detaillierten Testfallbeschreibungen und für die die Abnahme der Lösung.

Im agil geführten Projekt dient die Detailspezifikation der agilen Steuerung der Entwicklung und enthält alle Aufträge, die innerhalb einer Iteration umgesetzt werden sollen. Die Summe der Aufträge muss innerhalb einer Iteration durchführbar sein. Die Detailspezifikation ent-

spricht einem "Sprint Backlog", mit dem Unterschied, dass sie pro Iteration im Gesamtkontext der Umsetzung fortwährend aktualisiert wird und dass die bereits erledigten Aufträge der

vorangehenden Iterationen als nachfolgende Kapitel bestehen bleiben.

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 Geschäftsorganisation o Funktionalen Anforderungen

o Qualitätsanforderung, Rahmenbedingung

In agil geführten Lösungsentstehung hingegen ist der Inhalt klar spezifiziert:

Übersicht über den Gesamtkontext

Aktuelle und nachfolgend allfällige vorangehende Iterationen mit

o Übersicht aller Aufträge pro Iteration o Einzelne Aufträge

Auftragsnummer und Bezeichnung Detailanforderungen gemäss Inhalt in Lösungsanforderungen

Planung der Iterationen

o Lösungsbeschreibung o Ziel der Iteration

2.4.1.14 Einführungskonzept

Beschreibung

Das Einführungskonzept beschreibt die Massnahmen und Organisation für die Einführung. Dazu gehören auch die Analyse und Planung der Massnahmen des Organisations-Change-

36 / 202

ER

GEBN

ISSE

Managements zur Unterstützung des Übergangs vom alten zum neuen Zustand. Im Einfüh-rungskonzept werden ebenfalls das Vorgehen für die Abnahme geregelt sowie die Abnahme-

kriterien festgelegt.

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

2.4.1.15 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 dem geeignetsten Angebot (Leistungswert) o das wirtschaftlichste Angebot (Kosten/Nutzen)

o das beste Angebot (Leistungswert/Wirtschaftlichkeit)

Anträge

Anhänge mit

o ausgefülltem Kriterienkatalog o Bewertung

o weiteren Beilagen

2.4.1.16 Geschäftsmodellbeschreibung

Beschreibung

Die Geschäftsmodellbeschreibung beinhaltet alle organisatorischen Aspekte, die für die Lö-sung relevant sind bzw. die durch die Lösung beeinflusst werden und gibt den Rahmen für die Ablauf- und Aufbauorganisation vor. Sie orientiert sich an den Elementen des Geschäfts-

modells einer Organisation, verstärkt die ganzheitliche Sichtweise auf die Organisation und

37 / 202

ER

GEBN

ISSE

umfasst in der Regel eine Auswahl von Komponenten wie zum Beispiel die Kundensegmen-tierung oder die Kundenbeziehungen.

Inhalt

Der Inhalt ist stark durch das Projekt und die Vorgehensart sowie durch die Stammorganisa-

tion selbst 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 Finanziell o Intellektuell

o Menschlich

Schlüsselpartnerschaften

Einnahmequellen

Kostenstruktur

o Kostenorientiertes Geschäftsmodell o Wertorientiertes Geschäftsmodell

2.4.1.17 Inkrement

Beschreibung

Das Inkrement (Product Increment) ist ein lauffähiges, durch den Anwender testbares, nach einer Iteration vorliegendes Ergebnis der Entwicklung. Es entsteht aus einer Iteration des Ent-wicklungsteams und ist gemäss den Abnahmekriterien (Definition of Done) im Projektma-

nagementplan überprüft und freigegeben.

Inhalt

Der Inhalt eines Inkrements wird im Sprint Backlog festgelegt.

2.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

38 / 202

ER

GEBN

ISSE

2.4.1.19 Integrationskonzept

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.

Ist eine schrittweise Realisierung und Einführung oder gar die ganze Umsetzung mit Realisie-rungsabschnitten vorgesehen, ist die Planung der Realisierungsabschnitte 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

Qualitätssicherung.

2.4.1.20 ISDS-Konzept

Beschreibung

Das ISDS-Konzept bildet die Grundlage für die Festlegung der Massnahmen für die Informa-tionssicherheit und den Datenschutz. Es zeigt die Restrisiken auf, die mit dem Betrieb des

Systems und der Organisation verbunden sind. Es beschreibt das Notfallkonzept.

Inhalt

Verzeichnis der sicherheitsrelevanten Dokumente

Einstufung aufgrund der Schutzbedarfsanalyse

Sicherheitsrelevante Systembeschreibung

Risikoanalyse mit Restrisiken

Notfallkonzept

Bearbeitungsreglement

Einhaltung / Überprüfung der Schutzmassnahmen

Test / Abnahme der Informationssicherheitsfunktionen

Liquidation

2.4.1.21 Liste Projektentscheide Führung

Beschreibung

Die Liste Projektentscheide Führung dokumentiert die Ergebnisse der Entscheidungsaufgaben der Projektführung. Die Liste wird während der ganzen Dauer eines Projekts verwendet.

Inhalt

Entscheid

Meilenstein erreicht ja/nein

zugrundeliegende Dokumente

Entscheidungsträger der Hierarchieebene Führung und/oder Ausführung

Datum

2.4.1.22 Liste Projektentscheide Steuerung

Beschreibung

Die Liste Projektentscheide Steuerung dokumentiert die Ergebnisse der Entscheidungsaufga-ben der Projektsteuerung. Die Liste wird während der ganzen Dauer eines Projekts verwendet.

39 / 202

ER

GEBN

ISSE

Inhalt

Entscheid

Meilenstein erreicht ja/nein

zugrundeliegende Dokumente

Entscheidungsträger der Hierarchieebene Steuerung

Datum

2.4.1.23 Lösungsanforderungen

Beschreibung

Die Lösungsanforderungen beinhalten die fachlichen und technischen Anforderungen, aber auch weitere Elemente wie Eigenschaften, Funktionen, Optimierungen und Mängelkorrektu-

ren, 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 einflies-

senden Geschäftsanforderungen, Betriebsanforderungen, Supportanforderungen oder Si-cherheitsanforderungen. Es ist eine Liste eindeutig priorisierter Aufträge bzw. Anforderungen,

bei Bedarf unterteilt in Releases, die nach geschäftsspezifischen oder anderen für das Vorha-ben wichtigen Aspekten und logischen Abhängigkeiten geordnet ist und abgearbeitet bzw.

realisiert werden soll.

Die Anforderungserhebung der Lösung kann mit Standardnotationen der gewählten Requi-rement Engineering Methode erfolgen.

Im klassisch geführten Projekt werden die Lösungsanforderungen in der Phase Konzept im endgültigen Detaillierungsgrad erarbeitet und bei Bedarf über das Änderungsmanagement

sukzessive nachgeführt.

Im agil geführten Projekt entsprechen die Lösungsanforderungen einem "Product Backlog" in SCRUM. Sie werden erstmalig in der Phase Initialisierung auf der Basis der Studie und der

Situationsanalyse erarbeitet und dann in der Phase Umsetzung kontinuierlich detailliert und ergänzt. In der Regel werden sie pro Iteration nach absteigender Priorität abgearbeitet.

Inhalt

Der Inhalt ist stark durch das Projekt und die Vorgehensart geprägt.

Übersicht aller Aufträge (evtl. unterteilt nach Releases)

Releases

Allgemeine Beschreibung

o Wirkung / Nutzen o Business Use Case

Epics/Features o System Use Case

Stories

Auftrag / 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 (User Story)

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 o Nutzen/Mehrwert

o Geschäftsrelevanz o Akzeptanzkriterien

40 / 202

ER

GEBN

ISSE

o Product Compliance o Realisierungstermin

o geschätzter Aufwand o Testkriterien

o weitere Aspekte und Kriterien

2.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 Datenar-chitektur/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 zusammengefasst.

Die Lösungsarchitektur berücksichtigt die Vorgaben der Controlling- und Vorgabestellen.

Inhalt

Systemstruktur o Übersicht über das System

o Subsysteme und Komponenten o Architekturen / Modelle

Schnittstellen und Abgrenzung

o Schnittstellen zu Umsystemen o Hinweis auf Integrationskonzept

o Abgrenzung

Machbarkeitsbeurteilung

Konformität mit Vorgaben

Anforderungszuordnung und –Abdeckung

Ergebnisse des Systemkonzepts

2.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 der Informati-onssicherheit und des Datenschutzes berücksichtigt.

Inhalt

Ziele der Migration

Anforderungen an die Migration

Migrationsobjekte

Datenanalyse

Migrationsverfahren

Migrationsplan

Machbarkeit

Archivierung und Ausserbetriebssetzung Altsystem


2.4.1.26 Offertanfrage

Beschreibung

Mit der Offertanfrage werden Angebote für nicht umfassende Beschaffungen eingeholt. Die Angebote bilden die Grundlage für die Leistungsvereinbarung, wie in der Aufgabe Leistungen

41 / 202

ER

GEBN

ISSE

vereinbaren und steuern beschrieben ist. Die Vorgaben an die Offerte erlauben es, die Ange-bote zu vergleichen und zu bewerten.

Inhalt

Auftraggeber

Ausgangslage

Auftragsgegenstand

Termine

Bedingungen

Vorgaben an die Offerte

administrativer Ablauf der Beschaffung

2.4.1.27 Organisationsanforderungen

Beschreibung

Die Organisationsanforderungen beinhalten jene kontextbezogenen, betriebswirtschaftlichen und organisatorischen Anforderungen, die die interne Organisation im Rahmen der künftigen

Lösung stärken und der Lösung selbst einen höheren Wirkungsgrad ermöglichen.

Sie umfassen die klassischen aufbau- und ablauforganisationsspezifischen Aspekte sowie die Anforderungen an die Wirtschaftlichkeit, Effektivität und Effizienz, die Ziele der Organisation

und die aus den Zielen abgeleitete Organisationsstrategie. Die Ziele und Strategie einer Or-ganisation geben den Rahmen vor, in den die neue Geschäftsorganisation eingepasst werden

muss.

Inhalt

Der Inhalt ist stark durch das Projekt und die Vorgehensart geprägt.

Ausgangslage

Beschreibung des geplanten/geänderten Geschäftsmodells

Beschreibung der geplanten/geänderten Aufbauorganisation

Beschreibung der geplanten/geänderten Ablauforganisation

Anforderungskatalog

2.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

2.4.1.29 Organisationskonzept

Beschreibung

Das Organisationskonzept beschreibt die relevanten Geschäftsmodellaspekte sowie die dar-aus resultierende Aufbau- und Ablauforganisation (Geschäftsprozesse) für die Geschäftsab-wicklung und den Support. Im Organisationskonzept wird aufgezeigt, welche neue Organisa-

tion erstellt wird und welche Änderungen an Bestehendem vorgenommen werden.

Inhalt

Ausgangslage

Geschäftsmodell mit o Kundensegmentierung und Werteangebote

42 / 202

ER

GEBN

ISSE

o Kundenberührungspunkte und Kundenbeziehungen o Schlüsselaktivitäten und Schlüsselressourcen

o allfällige Schlüsselpartner o Einnahmequellen und Kostenstruktur

Aufbauorganisation mit o Organisationsprinzipien und –varianten

o Organisationsbeschreibung o Organigramm

Ablauforganisation mit

o Gesamtübersicht mit Prozesslandkarte

Ist-/ Soll-Beschreibung Zu unterstützende Prozesse

o Prozessbeschreibung Kernprozesse

Führungsprozesse Supportprozesse

Übersicht der Veränderungen


2.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

2.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

Der Inhalt der Produktdokumentation ist abhängig von den im Entwicklungsprozess definier-ten Ergebnissen.

2.4.1.32 Produktkonzept

Beschreibung

Das Produktkonzept vertieft die in der Studie beschriebene und gewählte Variante. Es basiert auf den Lösungsanforderungen, ggfs. ergänzt durch die Erkenntnisse aus den Organisations-anforderungen und beschreibt das zu erstellende Produkt. Je nach Produkt und Komplexität

der Lösungsanforderungen variieren die Struktur und der Detaillierungsgrad. Im Produktkon-zept können verschiedene Produktvarianten beschrieben und beurteilt werden.

43 / 202

ER

GEBN

ISSE

Inhalt

Ausganslage

Anforderungen

Abgrenzung

Produktbeschreibung mit

o Verwendungszweck

o Produktklassifizierungen o Varianten

Beschreibung Anforderungsabdeckung

Konformität mit Vorgaben Machbarkeitsbeurteilung

o Variantenwahl

Gewählte Variante

2.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

2.4.1.34 Projektinitialisierungsauftrag

Beschreibung

Der Projektinitialisierungsauftrag bildet die verbindliche Grundlage für die Freigabe der Phase Initialisierung. Er ist die Vereinbarung zwischen Auftraggeber und Projektleiter für die Phase Initialisierung.

Inhalt

Ausgangslage

Ziele

o Ziele der Phase Initialisierung

o Rahmenbedingungen

Ressourcenbedarf

Termine

Organisation und Ressourcen

Kommunikation

Risiken

2.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.

44 / 202

ER

GEBN

ISSE

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 gegebenenfalls externen Lieferanten ausreichend klar geregelt und dokumen-

tiert sind. Er wird im Projektverlauf nach dem Prinzip der rollenden Planung und Steuerung kontinuierlich konkretisiert und nachgeführt.

Bei agilen Projekten kann für die Phase Umsetzung der Terminplan mit einem umfassenden Releaseplan kombiniert werden. Dann wird eine Übersicht darüber benötigt, welche Iteratio-nen zu einem Release zusammengefasst werden können und wann der Betrieb pro Release

aktiviert wird. Der eigentliche Inhalt der einzelnen Releases wird im Rahmen der Lösungsan-forderungen in der Phase Umsetzung definiert.

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

Szenario mit

o Phasen und Meilensteinen oder o Releases / Freigabe J/N

Szenario mit Projektstrukturplan

Organisation mit

o Projektorganigramm

o Rollen in der Stamm- und Projektorganisation o Besetzung der Rollen (z. B. des Entwicklungsteams)

Projektergebnisstruktur

Lösungsanforderungsmanagements mit o Struktur der Lösungsanforderungen und der Aufträge

o Priorisierungsvorgaben o Änderungs- und Verwaltungsmanagements

Beschreibung Iteration (nur agil) mit

o Iterationsplanung o Iterationsdauer

o Abnahmekriterien (Definition of Done) o Vorgaben zu Iterationsreview

Prüfplan (QS)

Termine mit o Terminplan

o evtl. Releaseplan (agil)

Scope

Kostenplan / genehmigtes Budget

Ressourcenplan

Beschaffungsplan

Kommunikationsplan

Reporting

Vorgaben, Methoden, Arbeitsinstrumente und Werkzeuge

Qualitätssicherung

Risikomanagement

Eskalationsvorgehen

Projektabbruchkriterien

Dokumentenmanagement

45 / 202

ER

GEBN

ISSE

2.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 Projekterfahrungen sind zusammen-

fassend dokumentiert. Inhalt und Termine der Projekterfolgskontrolle sind bestimmt.

Inhalt

Ausgangslage

Beurteilung der Zielerreichung

Wirtschaftlichkeit

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

2.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 durch das Projekt berücksichtigt.

Inhalt

Übersicht Projektstand

Prognose der Zielerreichung / Burn-Down-Diagramm

Soll/Ist-Vergleich und Prognosen mit

o Kosten/Nutzen

o Aufwand o Termine

o Ergebnisse

Probleme und Massnahmen

Risiken

Ausblick

2.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 einmal bei Bedarf nachvollzogen werden müssen. Wichtige Diskussions- und Hand-

lungspunkte werden festgehalten. Im Protokoll festgehaltene Aufträge werden in einer Pen-denzenliste verwaltet.

46 / 202

ER

GEBN

ISSE

Generell: Die Sammlung aller Protokolle dient der Nachvollziehbarkeit von Entscheiden und Abläufen

bzw. Prozessen.

Inhalt

Sitzungsart / Thema

Datum

Teilnehmer

Traktanden

Protokollpositionen

Pendenzenliste (Anhang)

2.4.1.39 Prototyp

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. Im Projektverlauf können mehrere, verschiedene Prototypen realisiert werden. Sie werden für

den ‹Proof-of-Concept› (POC) realisiert. Es kann zwischen Wegwerfprototypen und wieder-verwendbare Prototypen unterschieden werden.

2.4.1.40 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

2.4.1.41 Prozessbeschreibung

Beschreibung

Die Prozessbeschreibung beschreibt die Prozesse mit den eingesetzten Hilfsmitteln.

Inhalt

Prozessbezeichnung

Prozessverantwortlicher

Prozessbeteiligte

Prozessziele

Prozesskennzahlen/Messgrössen

Kritische Erfolgsfaktoren

Prozessbewertung

Prozessdiagramm mit

o Input o Output

47 / 202

ER

GEBN

ISSE

o Aktivitäten o Hilfsmitteln

2.4.1.42 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

Entscheid zum Ergebnis

Entscheid zum Befund

2.4.1.43 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

2.4.1.44 QS- und Risikobericht

Beschreibung

Der QS- und Risikobericht informiert aus unabhängiger Sicht über die Qualität und die Risi-kosituation des Projekts. Der Inhalt des QS- und Risikoberichts ist abhängig von Auftrag und

Abgrenzung sowie von den eingesetzten Methoden.

Inhalt

Auftrag und Abgrenzung

Vorgehensweise

Gesamtbeurteilung mit Projektstatus

Qualitätsbeurteilung

Risikobeurteilung

Empfehlungen

2.4.1.45 Rechtsgrundlagenanalyse

Beschreibung

Die Rechtsgrundlagenanalyse beschreibt die für das Projektergebnis vorgesehenen Rechts-grundlagen und den allfälligen Bedarf für deren Änderung. Ein besonderes Augenmerk gilt

den kommunalen, kantonalen, nationalen und allenfalls auch den internationalen rechtlichen sowie produktrelevanten und regulatorischen Vorgaben für die anvisierte Lösung (Product

Compliance).

Inhalt

bestehende Rechtsgrundlagen

bevorstehende Änderungen

identifizierte Lücken

48 / 202

ER

GEBN

ISSE

Vorschläge zur Deckung von Lücken

Hinweise betreffend Product Compliance

Beurteilung der Konsequenzen

Empfehlungen

2.4.1.46 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.

Inhalt

Ausgangslage

Strategiebezug und Erfolge

Nutzen und Wirtschaftlichkeit

Inhalt des Release

Bekannte Fehler

Burn-Down-Diagramm

Risiken

Fazit

2.4.1.47 Releaseplan

Beschreibung

Der Releaseplan bildet bei der agilen Entwicklung die Grundlage für die Durchführung der Iterationen, die Planung der Auslieferung eines Releases an die Anwender und die Koordina-

tion der Aktivitäten mit den betroffenen Stellen.

Der Releaseplan umfasst mehrere Iterationen und definiert, wann Integrationen erfolgen und

wann die Auslieferung an den Anwender erfolgt. Er kann auch bei Bedarf während der Um-setzung mit dem Terminplan im Projektmanagementplan kombiniert werden.

Inhalt

Releases

Abhängigkeiten und Voraussetzungen

Organisation

Termine

2.4.1.48 Schutzbedarfsanalyse

Beschreibung

Die Schutzbedarfsanalyse, auch ISDS-Analyse genannt, dokumentiert die Anforderungen an die Informationssicherheit und den Datenschutz.

Inhalt

Anforderungskategorie

Anforderungsbeschreibung

Anforderungszuordnung

2.4.1.49 Service Level Agreement

Beschreibung

Ein Service Level Agreement (SLA) ist eine spezielle Art von Vereinbarung zwischen dem Be-

treiber und 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

49 / 202

ER

GEBN

ISSE

Nichteinhaltung. Die vereinbarten Dienstleistungen und deren Service Level sind in der Regel kostenpflichtig.

Wird der Betrieb outgesourcet, können die SLAs ein wichtiger Faktor bei der Evaluation des möglichen Betreibers sein.

Inhalt

Der Inhalt einer SLA wird in der Regel durch die Stammorganisation vorgegeben. Bei einem externen Provider kann bereits ein vorgefertigtes SLA vorliegen. Das SLA kann unter anderem

die folgenden Punkte beinhalten:

Einführung

Gegenstand, Beschreibung der Anwendung

(des Systems im Betrieb bzw. während der Nutzungsphase)

Geltungsbereich

Anforderungen

Leistungsumfang

o Leistungen (Services) o Laufzeiten (Zeit von-bis, Stunden, Tage, Feiertage usw.)

o Auslastung (Anzahl Anwender gleichzeitig, absolut, usw.) o Verfügbarkeit in %

o Servicezeiten (Kalendertage, Zeit von-bis) o Reaktionszeiten (in Minuten, klassifiziert)

o Konsequenzen bei Abweichungen, Sanktionen, Pönale

Messmethoden

Personen im Einsatz

Mitwirkungspflichten und Verantwortlichkeiten

Haftung, Schadenersatz

Datenschutz und Datensicherheit

Backup und Archivierung

Kosten (Preismodell)

Gewährleistung

Laufzeit des SLA

Sonstiges

Unterschriften

Beilagen usw.

2.4.1.50 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. Die Situa-tionsanalyse bildet die fachliche Basis für die Definition der vom Projektergebnis zu erfüllen-

den Lösungs- und Organisationsanforderungen. Sie ist ziel- und lösungsneutral und umfasst alle für die Lösung relevanten Aspekte.

Inhalt

Einleitung

Organisation mit

o Geschäftsmodell / geschäftliche Sichtweise

o Aufbauorganisation / Strukturen o Ablauforganisation / Prozesse

Beschreibung, sofern vorhanden, der bestehenden Lösung (Ist-System / Ist-Produkt) o Ziel und Anwendungszweck, Funktion

50 / 202

ER

GEBN

ISSE

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

2.4.1.51 Stakeholderinteressen

Beschreibung

Die Stakeholderinteressen werden erstmals in der Phase Initialisierung erstellt und im Projekt-ablauf seitens Projektleiter und Anwendervertreter kontinuierlich weitergeführt. Sie 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. Sie ist

eine subjektive, projektinterne Einschätzung der beiden Rollenträger und kein öffentliches Er-gebnis, dennoch werden die Stakeholderinteressen für die Kommunikation benötigt.

Inhalt

Stakeholder-Positionierung

Stakeholder-Beschreibung

Erkannte Interessen- und Zielkonflikte

2.4.1.52 Stakeholderliste

Beschreibung

Die Stakeholderliste wird erstmals in der Phase Initialisierung erstellt und bildet die Grundlage für das Managen der Stakeholder, für die direkte Zusammenarbeit mit ihnen und für die Kom-

munikationsplanung. Sie wird erstmals in der Phase Initialisierung erstellt und im Projektablauf kontinuierlich weitergeführt.

Inhalt

Stakeholder

2.4.1.53 Studie

Beschreibung

Die Studie beschreibt die angestrebte Lösung, indem sie die groben Ziele definiert, mögliche Lösungsvarianten und das vorgeschlagene Vorgehen aufführt und diese anschliessend be-

wertet. Alle Aspekte, die einen Einfluss auf die geplante Lösung haben oder die von der Lö-sung beeinflusst werden können, werden in der Studie erwähnt. Darüber hinaus wird das pas-

sende Szenario (vgl. Kapitel 6 Szenarien) ausgewählt, allenfalls ein individuelles Szenario er-stellt und es wird geschätzt, welche ungefähre Wertigkeit das fokussierte Projekt haben wird

(Size).

Die Studie bildet die Grundlage für die Entscheidung, ob ein Projekt umgesetzt wird oder nicht. Sie ist die Voraussetzung für die Erarbeitung des Projektmanagementplans und des

Umsetzungsauftrags.

Die Studie wird nur so weit ausdetailliert, dass die Stossrichtung des anvisierten Projekts klar

ersichtlich ist und der Entscheid weiteres Vorgehen getroffen werden kann. Die straffe Vorge-hensweise trifft insbesondere auf die Standortbestimmung zu, um die Durchführung der Ini-

tialisierungsphase nicht unnötig zu verlängern.

51 / 202

ER

GEBN

ISSE

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 Vorgehensart o Analyse und Bewertung mit

Zielerreichungsgrad Anforderungsabdeckung

weitere Kriterien wie Kosten/Nutzen/Wirtschaftlichkeits-Betrachtungen, Risikobe-urteilung usw.

Vorschlag zum weiteren Vorgehen inklusive Begründung mit

o Variante o Vorgehensart

o Projekt Size

Entscheid weiteres Vorgehen

Planung und Termine

o Szenario und Module o Projekttermine, Meilensteine

o geplanter Nutzungszeitraum

2.4.1.54 Systemkonzept

Beschreibung

Das Systemkonzept vertieft die in der Studie beschriebene und gewählte Variante. Sie basiert

auf den Lösungsanforderungen und zeigt auf, wie die Anforderungen mit der Lösung erfüllt werden. Es können Systemkonzepte zu mehreren Themenbereichen erarbeitet werden. Im

Systemkonzept können Systemvarianten beschrieben und beurteilt werden.

Inhalt

Ausgangslage

Anforderungen

Lösungskonzept mit

o Varianten

Beschreibung Anforderungsabdeckung

Machbarkeitsbeurteilung

Variantenvergleich

Empfehlung

2.4.1.55 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.

52 / 202

ER

GEBN

ISSE

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

Testfallbeschreibungen

Testplan

Testorganisation und Zuständigkeiten

Testinfrastruktur mit o Testsystem

o Testdaten o Testhilfsmittel

2.4.1.56 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

2.4.1.57 Umsetzungsauftrag

Beschreibung

Der Umsetzungsauftrag bildet die verbindliche Grundlage für die Umsetzungsfreigabe. Es handelt sich um eine Vereinbarung zwischen Auftraggeber und Projektleiter.

Inhalt

Ausgangslage und Handlungsbedarf

Ziele

o Lösungsziele o Vorgehensziele mit

klassisch / agil Szenario

weitere o Rahmenbedingungen & Abgrenzung

Lösungsbeschreibung

Strategiebezug und Umsetzung von Vorgaben

Rechtliche Grundlagen

Investitionsbedarf

Ressourcen- und Hilfsmittelbedarf

Kosten / Nutzen / Wirtschaftlichkeit (Vorschau)

Planung und Organisation

53 / 202

ER

GEBN

ISSE

Vorgehensart (Entwicklungsmanagement)

Risiken

Konsequenzen

Verbindlichkeiten

2.4.1.58 Vereinbarung

Beschreibung

Die Vereinbarung regelt die Zusammenarbeit zwischen den verschiedenen Projektbeteiligten, 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

usw.

2.4.2 Zustände

2.4.2.1 Altsystem entfernt

Beschreibung

Die alte Systemversion (SW) sowie das Altsystem (HW) sind unter Berücksichtigung der Vor-gaben abgebaut bzw. entfernt. Die Ausserbetriebssetzung umfasst ebenfalls die Vernichtung oder Archivierung von Daten.

2.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.

2.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

54 / 202

ER

GEBN

ISSE

Betriebsüberwachung nötigen Komponenten wie Monitoring und Alarmierung, Statistikwerk-zeuge usw.

2.4.2.4 Betriebsorganisation realisiert

Beschreibung

Die im Betriebskonzept definierte Betriebsorganisation mit der Aufbauorganisation und den Betriebsprozessen des Betreibers sind realisiert. Das Betriebspersonal ist ausgebildet und kann die Betriebsaufgaben wahrnehmen.

2.4.2.5 Einführungsmassnahmen durchgeführt

Beschreibung

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.

2.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.

2.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.

2.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.

2.4.2.9 Meilensteine

Beschreibung

Meilenstein Abnahme

Der Meilenstein wird erreicht, wenn der Entscheid Abnahme getroffen wird. Die Lösung

wird definitiv in die Betriebs- oder Anwenderorganisation überführt.

Meilenstein Abnahme Migration

Der Meilenstein wird erreicht, wenn der Entscheid Abnahme Migration getroffen wird. Danach

kann die Nutzung des neuen Systems für die Anwender freigegeben werden (Entscheid Be-

triebsaufnahme).

Meilenstein Ausschreibung

Der Meilenstein wird erreicht, wenn der Entscheid Ausschreibung getroffen wird. Nach dem

Entscheid kann die Ausschreibung publiziert werden.

Meilenstein Betriebsaufnahme

Der Meilenstein wird erreicht, wenn der Entscheid Betriebsaufnahme getroffen wird. Die Lö-

sung kann in Betrieb genommen werden.

Meilenstein ISDS-Konzept

Der Meilenstein wird erreicht, wenn der Entscheid ISDS-Konzept getroffen wird. Nach dem Ent-

scheid kann die Realisierung der ISDS-Massnahmen an die Hand genommen werden. Der

55 / 202

ER

GEBN

ISSE

Entscheid ist die Voraussetzung für die Realisierung des ganzen Systems (klassisch) bzw. ei-

nes Teils davon (Inkrement, agil).

Meilenstein Lösungsarchitektur

Der Meilenstein wird erreicht, wenn der Entscheid Lösungsarchitektur getroffen wird. Der Ent-

scheid bildet die Voraussetzung für die Entwicklung oder Adaption von Systemen.

Meilenstein Phasenfreigabe

Der Meilenstein wird erreicht, wenn der Entscheid Phasenfreigabe getroffen wird. Der Entscheid

Phasenfreigabe schafft im Rahmen der klassischen Vorgehensweise die Voraussetzung für

die Arbeiten in der nächsten Phase.

Meilenstein Phasenfreigabe Abschluss

Der Meilenstein wird erreicht, wenn der Entscheid Phasenfreigabe Abschluss getroffen wird. Der

Entscheid beendet die Leistungserbringung im Rahmen des Projekts und schafft die Vorausset-

zung für die abschliessenden Projektarbeiten in der Phase Abschluss. Nach dem Entscheid wird

das agile Entwicklungsteam in der Projektorganisation formell aufgelöst und der Projektleiter

übernimmt wieder die alleinige Führungsverantwortung.

Meilenstein Produktkonzept

Der Meilenstein wird erreicht, wenn der Entscheid Produktkonzept getroffen wird. Der Entscheid

bildet die Voraussetzung für die Entwicklung oder Adaption von Produkten oder Dienstleistun-

gen.

Meilenstein Projektabschluss

Der Meilenstein wird erreicht, wenn der Entscheid Projektabschluss getroffen wird. Der Ent-

scheid ist der letzte ordentliche und formelle Entscheid im Projekt. Nach dem Entscheid wird

die Projektorganisation aufgelöst und das Projekt beendet.

Meilenstein Projektinitialisierungsfreigabe

Der Meilenstein wird erreicht, wenn der Entscheid Projektinitialisierungsfreigabe getroffen wird.

Mit dem Entscheid wird das Projekt formell ins Leben gerufen.

Meilenstein Releasefreigabe

Der Meilenstein wird erreicht, wenn der Entscheid Releasefreigabe getroffen wird. Der Entscheid

Releasefreigabe schafft im Rahmen der agilen Vorgehensweise die Voraussetzung für die Arbeiten am nächsten Release.

Meilenstein Umsetzungsfreigabe

Der Meilenstein wird erreicht, wenn der Entscheid Umsetzungsfreigabe getroffen wird. Nach

dem Entscheid werden die Arbeiten gemäss dem Umsetzungsauftrag gestartet. Bei agiler Vor-

gehensart wird das Entwicklungsteam in der Projektorganisation formell etabliert und die Pro-

jektorganisation wird als Ganzes gegenüber Stammorganisation und Stakeholdern kommuni-

ziert.

Meilenstein Vorabnahme

Der Meilenstein wird erreicht, wenn der Entscheid Vorabnahme getroffen wird. Die Vorab-

nahme schafft die Grundlage für die Betriebsaufnahme und die Inbetriebsetzung der Lösung

mit vertretbaren Risiken

Meilenstein Weiteres Vorgehen

Der Meilenstein wird erreicht, wenn der Entscheid Weiteres Vorgehen getroffen wird. Der Ent-

scheid bildet die Grundlage für die Erarbeitung des Projektmanagementplans sowie des Um-

setzungsauftrags.

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.

2.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.

56 / 202

ER

GEBN

ISSE

2.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.

2.4.2.12 Organisation aktiviert

Beschreibung

Die neue Organisation ist aktiviert. Sie führt ihre Prozesse gemäss den Prozessbeschreibungen durch.

Wird die neue Organisation im Rahmen einer Lösungsentwicklung aktiviert, ist sie ist die Vo-raussetzung für die Aktivierung des Produkts oder des Systems. Bei agiler Lösungsentwicklung wird nur der entsprechende Teil der Organisation aktiviert.

2.4.2.13 Organisation umgesetzt

Beschreibung

Die im Organisationskonzept definierte Geschäftsorganisation ist umgesetzt.

Auf der Grundlage der Prozessbeschreibung und der Organisationsbeschreibung wurden die Massnahmen realisiert, um die Organisation ins Leben zu rufen (Stellenbesetzungen, Perso-

nalanstellungen usw.).

2.4.2.14 Produkt aktiviert

Beschreibung

Das ganze aktivierte Produkt (klassisch) bzw. der aktivierte vollständige Teil des Produkts (In-krement, agil) wird den Anwendern für die Nutzung zur Verfügung gestellt. Nach der Vorab-nahme und der Freigabe der Einführung wird das Produkt aktiviert. Es umfasst alle Kompo-

nenten, die für den Betrieb notwendig sind.

2.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.

2.4.2.16 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.

2.4.2.17 System aktiviert

Beschreibung

Das aktivierte System (klassisch) bzw. das aktivierte Inkrement (agil) wird den Anwendern für die Nutzung zur Verfügung gestellt.

2.4.2.18 System entwickelt oder parametrisiert

Beschreibung

Das entwickelte und/oder parametrisierte System (klassisch) bzw. das entwickelte und/oder

57 / 202

ER

GEBN

ISSE

parametrisierte Inkrement (vollständiger Teil des Systems, agil) 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ön-nen in mehreren Schritten bzw. Releases erfolgen.

2.4.2.19 System integriert

Beschreibung

Das ganze integrierte System (klassisch) bzw. der integrierte vollständige Teil des Systems (Inkrement, agil) 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.

2.4.2.20 Testinfrastruktur realisiert

Beschreibung

Für die Durchführung der Tests wird eine Testinfrastruktur bestehend aus Testsystem, Testda-ten und Testhilfsmitteln verwendet. Sie wird gemäss Testkonzept bereitgestellt. Je nach Test-

methode werden unterschiedliche Anforderungen an die Testinfrastruktur gestellt. Folgend können auch unterschiedliche Testsysteme benötigt werden.

Die Infrastruktur des Testsystems richtet sich nach der Infrastruktur des Produktionssystems, also nach der realisierten Betriebsinfrastruktur. Das Testsystem muss soweit dem Produktions-

system entsprechen, dass die Testfallbeschreibungen unter realistischen Bedingungen durch-geführt werden können.

Werden für die Tests als Testdaten nicht anonymisierte Kopien von produktiven Daten ver-wendet, müssen die Anforderungen der Informationssicherheit und des Datenschutzes erfüllt sein.

2.4.2.21 Testinfrastruktur überführt

Beschreibung

Die gesamte Testinfrastruktur inklusive des Testkonzepts wurde in die Stammorganisation überführt.

58 / 202

AU

FG

AB

EN

3 Aufgaben

3.1 Einleitung

3.1.1 Aufgabenpositionierung

In HERMES stehen die Ergebnisse im Mittelpunkt. Sie werden mit den Aufgaben erarbeitet.

Die Aufgabe besteht aus mehreren Aktivitäten für die Erarbeitung der Ergebnisse sowie die Sicherstellung der Qualitätsanforderungen.

HERMES unterscheidet zwischen zwei Arten von Aufgaben:

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/erhöhen.

Aufgabenbeschreibungen ersetzen nicht die Kenntnisse der anzuwendenden Methoden und Praktiken oder eine entsprechende Ausbildung.

3.1.2 Entscheidungsaufgaben

3.1.2.1 Entscheidungsaufgaben generell

In der Projektdurchführung müssen Entscheide getroffen werden. Aufgaben, die zu einem

Entscheid führen, sind im HERMES als Entscheidungsaufgaben definiert. Sie enden mit dem Ergebnis Meilenstein.

HERMES unterscheidet zwischen Entscheiden, die durch die Steuerung, sowie Entscheiden, die durch die Projektführung getroffen werden. So erfolgt beispielsweise der Entscheid Be-triebsaufnahme durch den Auftraggeber (Steuerung), während der Entscheid Lösungsarchi-

tektur durch den Projektleiter erfolgt.

Die Steuerung prüft am Ende einer Phase, ob die benötigten Fachentscheide vorliegen. Fehlen diese, wird die nächste Phase nicht freigegeben. Die Steuerung kann damit Entscheidungen

treffen, ohne selbst über die notwendige Fachkompetenz zu verfügen.

Die Entscheidungsaufgaben in HERMES werden mit der Checkliste unterstützt.

3.1.2.2 Entscheide der Steuerung

Auf der Hierarchieebene Steuerung entscheidet der Auftraggeber. Er entscheidet über die Projektinitialisierungsfreigabe, Umsetzungsfreigabe, Phasenfreigaben, Releasefreigabe und

den Projektabschluss, allenfalls Projektabbruch sowie über wichtige Weichenstellungen wie eine Ausschreibung auslösen, einen Zuschlag entscheiden oder eine Betriebsaufnahme bewil-

ligen. Bei Bedarf wird er durch weitere Rollen, wie z. B. den Projektausschuss, den Projektleiter oder den Anwendervertreter beraten und unterstützt.

3.1.2.3 Entscheide der Führung

Entscheide der Führung und Ausführung sind Entscheide zu Projektergebnissen.

Prüfung und Abnahme von technischen Ergebnissen erfolgen durch die Führung und Ausfüh-rung, d. h. durch die jeweiligen Spezialisten für das entsprechende Thema.

Je nach Vorgehensmodell planen der Projektleiter oder Anwendervertreter die Entschei-dungsaufgaben. Sie berücksichtigen die Vorgaben der Controlling- und Vorgabestellen der Stammorganisation.

59 / 202

AU

FG

AB

EN

3.2 Aufgabenübersicht

Die Tabelle zeigt die Zuordnung aller Aufgaben samt entsprechender Ergebnisse zu Pro-jektphasen, wobei die Entscheidungsaufgaben farblich (pink) hervorgehoben sind.

Aufgabe Ergebnis

Phasen

I K R E U A

Altsystem ausser Betrieb setzen Altsystem entfernt X

Änderungen managen Änderungsantrag X X X

Änderungsstatusliste X X X X

Projektmanagementplan 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

Einführung durchführen Einführungsmassnahmen durchgeführt X X

Einführung realisieren Einführungsmassnahmen realisiert X X

Einführungskonzept erarbeiten Einführungskonzept X X

Entscheid Abnahme Migration treffen Checkliste Abnahme Migration X X

Abnahmeprotokoll X X

Meilenstein Abnahme Migration X X

Liste Projektentscheide Führung X X

Entscheid Abnahme treffen Checkliste Abnahme X X


Meilenstein Abnahme X X


Entscheid Ausschreibung treffen Checkliste Ausschreibung X X

Meilenstein Ausschreibung X X

Liste Projektentscheide Steuerung 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

QS- und Risikobericht X X

Meilenstein Phasenfreigabe Abschluss X X


Entscheid Phasenfreigabe treffen Checkliste Phasenfreigabe X X


Meilenstein Phasenfreigabe X X


Entscheid Produktkonzept treffen Checkliste Produktkonzept X X

Meilenstein Produktkonzept X X


Entscheid Projektabbruch treffen Checkliste Projektabbruch X X X X

60 / 202

AU

FG

AB

EN

Aufgabe Ergebnis

Phasen

I K R E U A

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

QS- und Risikobericht X

Meilenstein Projektabschluss X

Liste Projektentscheide Steuerung X

Entscheid Projektinitialisierungsfreigabe treffen Checkliste Projektinitialisierungsfreigabe X

Projektinitialisierungsauftrag X

Meilenstein Projektinitialisierungsfreigabe X


Entscheid Releasefreigabe treffen Checkliste Releasefreigabe X


Meilenstein Releasefreigabe X


Entscheid Umsetzungsfreigabe treffen Checkliste Umsetzungsfreigabe X

Umsetzungsauftrag X

Meilenstein Umsetzungsfreigabe 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

Publikation X X

Meilenstein Zuschlag X X


Integrationskonzept erarbeiten Integrationskonzept X X

Iterationen durchführen Inkrement X

Protokoll X

Iterationen planen Detailspezifikation 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ösungsanforderungen erarbeiten Situationsanalyse X X

Lösungsanforderungen X X

Lösungsanforderungen führen Lösungsanforderungen X

Lösungsarchitektur erarbeiten Systemkonzept X X

Lösungsarchitektur X X

Migration durchführen Migration durchgeführt X X

Migrationskonzept erarbeiten Migrationskonzept X X

Migrationsverfahren realisieren Detailspezifikation X X

Migrationsverfahren realisiert X X

Organisation aktivieren Organisation aktiviert X X

Organisation umsetzen Geschäftsmodellbeschreibung X X

Prozessbeschreibung X X

61 / 202

AU

FG

AB

EN

Aufgabe Ergebnis

Phasen

I K R E U A

Organisationsbeschreibung X X

Organisation umgesetzt X X

Organisationsanforderungen erarbeiten Situationsanalyse X X

Organisationsanforderungen X X

Organisationskonzept erarbeiten Organisationskonzept X X

Geschäftsmodellbeschreibung X X



Phasenfreigabe vorbereiten Phasenbericht X X X X


Projektstatusbericht 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

Anwendungshandbuch 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

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 X X X X

Prototypdokumentation X X X X

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

Releaseplan erarbeiten Releaseplan 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

Stakeholderinteressen vertreten Stakeholderinteressen 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



System entwickelt oder parametrisiert X X

Systemintegration vorbereiten Schnittstellen realisiert X X


Integrations- und Installationsanleitung X X

Detailspezifikation X X

62 / 202

AU

FG

AB

EN

Aufgabe Ergebnis

Phasen

I K R E U A

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

Umsetzungsauftrag erarbeiten Umsetzungsauftrag X

Vereinbarung erarbeiten Vereinbarung X X

Tabelle 4: Zuordnung aller Aufgaben samt entsprechender Ergebnisse zu Projektphasen

3.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.

Grundlagen/Voraussetzungen

Legt die Ergebnisse fest, die für die Ausführung der Aufgabe notwendig sind.

Aktivitäten

Beschreiben, wie die Aufgabe ausgeführt wird. Nach Möglichkeit sind die Aktivitäten chro-nologisch aufgeführt. Bei Bedarf wird jede Aktivität 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 wird jedes Ergebnis

mit "A" für agil bzw. mit "K" für klassisch gekennzeichnet.

3.4 Aufgabenverzeichnis

3.4.1 Entscheidungsaufgaben der Steuerung

3.4.1.1 Entscheid Ausschreibung treffen



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, (falls vorhanden) unter Mitwir-kung der Ausschreibungsstelle der Stammorganisation. Der Auftraggeber stellt die Abstim-

mung mit der Stammorganisation sicher.


Ausschreibungsunterlagen

Projektmanagementplan

63 / 202

AU

FG

AB

EN

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

Checkliste Ausschreibung


Liste Projektentscheide Steuerung

3.4.1.2 Entscheid Betriebsaufnahme treffen



Zweck

Der Entscheid Betriebsaufnahme bildet die Voraussetzung für die Inbetriebsetzung und pro-duktive Nutzung der ganzen Lösung (klassisch) bzw. des vollständigen Teils der Lösung (In-

krement, agil).

Grundidee

Der Auftraggeber entscheidet auf Antrag des Projektleiters oder des Anwendervertreters über die Betriebsaufnahme.

HERMES-spezifisch

Der Entscheid Betriebsaufnahme basiert auf den Entscheiden Vorabnahme und Abnahme Migration, auf der Durchführung der Einführungsmassnahmen und auf weiteren, z. T. projekt-spezifischen Freigabekriterien.




Einführungsmassnahmen durchgeführt


Aktivitäten

Checkliste Betriebsaufnahme mit weiteren Kriterien ergänzen.

Freigabekriterien beurteilen und Einführungsrisiken einschätzen.

Entscheidungsgrundlagen den Entscheidungsträgern zustellen.

Beurteilung der Freigabekriterien und Risiken präsentieren.

Formellen Entscheid Betriebsaufnahme treffen.

Nutzung für die Anwender nach erfolgreicher Betriebsaufnahme freigeben.

Ergebnisse

Checkliste Betriebsaufnahme



64 / 202

AU

FG

AB

EN

3.4.1.3 Entscheid Phasenfreigabe Abschluss treffen



Zweck

Der Entscheid Phasenfreigabe Abschluss beendet die Leistungserbringung im Rahmen des Projekts und schafft die Voraussetzung für die Arbeiten in der Phase Abschluss.

Grundidee

Die Ergebnisse der der gesamten Lösungsentstehung werden geprüft sowie abgenommen oder zurückgewiesen. Die Phase wird abgeschlossen und die Phase Abschluss sowie die dazu

benötigten Ressourcen werden freigegeben.

HERMES-spezifisch

Am Ende der Phase Einführung bzw. am Ende der Phase Umsetzung wird der Phasenbericht bzw. der letzte Releasebericht abgenommen und über den Abschluss der Phase und somit

auch über das Ende der Lösungsentstehung entschieden. Anschliessend wird über die Frei-gabe der nächsten Phase Abschluss entschieden.

Mit dem Entscheid Phasenfreigabe Abschluss wird die Entwicklung/Parametrisierung des Sys-tems oder die Entwicklung/Anpassung des Produkts definitiv abgeschlossen und die Leis-tungserbringung im Rahmen des Projekts beendet.

Wurde die Lösungsentstehung agil angegangen, wird das Entwicklungsteam in der Projektor-ganisation formell aufgelöst.

Vor der Phasenfreigabe vergleicht der Auftraggeber die ursprünglichen Ziele und die des Pro-jekts mit den tatsächlich erreichten Ergebnissen und prüft den Erfolg des Projekts sowie seine Wirtschaftlichkeit. Er prüft weiter, ob die notwendigen Abnahmen der Ergebnisse sowie der

Gesamtlösung durch die Controlling- und Vorgabestellen sowie die Fachspezialisten erfolgt sind und ob die Ergebnisse des gesamten Projekts seinen Erwartungen entsprechen. Weiter

werden der Phasenbericht und der Projektmanagementplan mit den übergeordneten Strate-gien und Zielen der Stammorganisation abgeglichen, der Projektmanagementplan wird zu-

sätzlich entsprechend vorbereitet und angepasst.

Es wird entschieden,

ob die Phase abgeschlossen wird oder ob vor dem Phasenabschluss weitere Ergebnisse

zu erarbeiten sind oder

ob die nächste Phase Abschluss freigegeben wird.

Vor der Phasenfreigabe werden der Phasenbericht und der Projektmanagementplan mit den übergeordneten Strategien und Zielen der Stammorganisation abgeglichen, der Projektma-

nagementplan wird zusätzlich entsprechend vorbereitet und angepasst.


Meilenstein Abnahme


Projektstatusbericht K A

Phasenbericht K

Releasebericht A

Aktivitäten

Checkliste Phasenfreigabe Abschluss mit weiteren Freigabekriterien ergänzen.

Entscheidung in der Stammorganisation abstimmen.

Formellen Entscheid Phasenfreigabe Abschluss treffen oder Ergebnisse zurückweisen.

Bei positivem Entscheid: o Ressourcen für nächste Projektphase freigeben. o Betroffene über Entscheid informieren.

65 / 202

AU

FG

AB

EN

Ergebnisse



Meilenstein Phasenfreigabe Abschluss


3.4.1.4 Entscheid Phasenfreigabe treffen



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 Ziele des Projekts nicht erreicht werden, wird

das Projekt beendet.

HERMES-spezifisch

Am Ende der laufenden Projektphase wird der Phasenbericht abgenommen und über den Abschluss der Phase entschieden. Anschliessend wird über die Freigabe der nächsten Phase

entschieden.

Vor der Phasenfreigabe werden der Phasenbericht und der Projektmanagementplan mit den übergeordneten Strategien und Zielen der Stammorganisation abgeglichen. Dabei werden

neue Erkenntnisse berücksichtigt.

Anpassungen des Projektmanagementplans und der Projektorganisation werden entschie-

den.

Wenn im Projekt spezifische Stellen für Controlling und QS/Risikomanagement beauftragt wurden, erstellen sie einen Bericht zuhanden des Auftraggebers.


Projektmanagementplan K

Projektstatusbericht K

Phasenbericht K

Aktivitäten

Checkliste zur Phasenfreigabe mit weiteren Freigabekriterien ergänzen. K

Projektziele, Machbarkeit und Nutzen des Projekts aufgrund neuer Erkenntnisse

kritisch überprüfen und mit den Zielen der Stammorganisation abstimmen.

K

Überprüfen, ob übergeordnete Strategien, Standards und Vorgaben eingehalten

sind und Bestätigungen der zuständigen Stellen vorliegen.

K

Phasenbericht, Projektmanagementplan und weitere Entscheidungsunterlagen

den Entscheidungsträgern zustellen.

K

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.

K

Entscheidung in der Stammorganisation abstimmen. K

Phasenbericht, Projektmanagementplan und phasenspezifischen Ergebnisse prü-

fen und genehmigen oder zurückweisen.

K

Formellen Entscheid Phasenfreigabe treffen oder Ergebnisse zurückweisen. K

Bei positivem Entscheid:

o Ressourcen für nächste Projektphase frei geben. K

o Betroffene über Entscheid informieren. K

66 / 202

AU

FG

AB

EN

Können die Projektziele nicht erreicht werden: o entweder Korrekturmassnahmen festlegen. K

o oder Entscheid Projektabschluss oder Projektabbruch treffen und Beendigung

des Projekts beantragen. K

Ergebnisse

Checkliste Phasenfreigabe K

QS- und Risikobericht K

Meilenstein Phasenfreigabe K

Liste Projektentscheide Steuerung K

3.4.1.5 Entscheid Projektabbruch treffen



Zweck

Mit dem Entscheid Projektabbruch wird die vorzeitige Beendigung eines Projektes beschlos-sen, noch bevor die Projektziele erreicht worden sind. Sofern der Projektabbruch nicht aus-

serhalb jeglicher methodischer Pfade erfolgt, wird die Projektorganisation regulär aufgelöst und das Projekt geordnet beendet.

Grundidee

Ein Projektabbruch ist ein nicht geplanter Schritt, der höchstens als mögliches Handlungssze-nario vorgesehen werden kann für den Fall, dass 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 formelle Auflösung der Projektorganisation wird analog ei-

nem Projektabschluss durchgeführt. Die Projektbeteiligten werden offiziell aus den Projekt-verantwortlichkeiten 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, wenn überhaupt, nur im Rahmen der Lösungsentstehung möglich, also

nach dem Entscheid Umsetzungsfreigabe und vor dem Entscheid Phasenfreigabe Abschluss. Er stellt einen vorzeitigen, nicht geplanten, in der Regel abrupten Projektabschluss mit einem

entsprechendem Projektabschluss Meilenstein dar. Er ist keinesfalls mit einer ausbleibenden Phasenfreigabe mit anschliessender Projektbeendigung gleichzusetzen.

Der Projektabbruch sollte, sofern dies die Umstände erlauben, organisiert, methodisch korrekt und möglichst ohne Kollateralschäden vonstattengehen. Es ist insbesondere bei agilen Pro-jekten darauf zu achten, dass die allenfalls bereits erbrachte Wertschöpfung erhalten werden

kann und folglich 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-

jektabschlussbeurteilung 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.

67 / 202

AU

FG

AB

EN


dass das Projekt abgebrochen wird.

Wenn im Projekt spezifische Stellen für Controlling und QS/Risikomanagement beauftragt wurden, erstellen sie einen 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-

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 kommunizieren.

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.

Ergebnisse

Checkliste Projektabbruch

Projekterfahrungen

Projektschlussbeurteilung



3.4.1.6 Entscheid Projektabschluss treffen



Zweck

Mit dem Entscheid Projektabschluss wird die Projektorganisation aufgelöst und das Projekt beendet.

Grundidee

Der letzte Schritt des Projektabschlusses ist die formelle Auflösung der Projektorganisation. Sie liegt in Kompetenz und Verantwortung des Auftraggebers. Die Projektbeteiligten werden offiziell aus den Projektverantwortlichkeiten entlassen.

68 / 202

AU

FG

AB

EN

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 bestehende Projektorganisation während der Nutzungsdauer des Lösungssystems Verwendung finden könnte und wenn ja, ob dies im Rahmen der Stam-

morganisation möglich bzw. machbar sei.


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 anderer Bezeichnung teilweise oder vollstän-

dig an die Nachfolgeorganisation übergeht oder nicht.

Wenn im Projekt spezifische Stellen für Controlling und QS/Risikomanagement beauftragt wurden, erstellen sie einen Schlussbericht.



Testinfrastruktur überführt

Altsystem entfernt

Projekterfahrungen


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.

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




3.4.1.7 Entscheid Projektinitialisierungsfreigabe treffen



Zweck

Der Entscheid Projektinitialisierungsfreigabe startet das Projekt. Der Entscheid ist die Voraus-

setzung für die Arbeiten in der Phase Initialisierung, in der die Projektidee geprüft sowie die

69 / 202

AU

FG

AB

EN

Grundlagen zum geplanten Vorhaben erarbeitet werden und letztlich über die Umsetzung der fokussierten Lösung entschieden wird.

Grundidee

Mit der Projektinitialisierungsfreigabe beginnt formell das Projekt, das mit der initialen Abklä-

rung der allfälligen späteren Umsetzung des Vorhabens startet.

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 alleine durch den Auf-traggeber im Namen der Stammorganisation, evtl. im Rahmen eines bestehenden Projekt-

portfolios getroffen. Es wird entschieden, dass das anvisierte Vorhaben mit der Phase Initiali-sierung auf Projekttauglichkeit und -würdigkeit geprüft werden soll.

Die Erarbeitung des Projektinitialisierungsauftrags erfolgt noch ausserhalb der möglichen künftigen Projektstruktur. Solange der Entscheid Projektinitialisierungsfreigabe nicht getroffen ist, ist das Projekt noch inexistent.

Zur Erarbeitung des Projektinitialisierungsauftrags beauftragt der Auftraggeber einen Projekt-leiter. Dieser muss nicht zwingend die Projektleitung für die folgenden Phasen übernehmen.

Der Entscheid Projektinitialisierungsfreigabe erfolgt ausschliesslich durch den Auftraggeber.

Die Organisation der Phase Initialisierung, oft nur aus dem Auftraggeber und dem Projektlei-ter bestehend und von der späteren Projektorganisation noch losgelöst, wird in Kraft gesetzt.

Die für die Initialisierung benötigten Ressourcen werden freigegeben.



Aktivitäten

Checkliste Projektinitialisierungsfreigabe mit weiteren Kriterien ergänzen.

Überprüfung des Projektinitialisierungsauftrags durch den Auftraggeber anhand der

Checkliste für Projektinitialisierungsfreigabe.

Ressourcen für die Phase Initialisierung sicherstellen.

Formellen Entscheid Projektinitialisierungsfreigabe treffen.

Projektinitialisierungsauftrag unterschreiben, Ressourcen für die Phase Initialisierung frei-

geben, Stammorganisation orientieren.

Ergebnisse


Projektinitialisierungsauftrag



3.4.1.8 Entscheid Releasefreigabe treffen



Zweck

Der Entscheid Releasefreigabe schafft im Rahmen der agilen Vorgehensweise die Vorausset-zung für die Arbeiten am 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 Ziele des Pro-jekts nicht erreicht werden, wird das Projekt beendet.

70 / 202

AU

FG

AB

EN

HERMES-spezifisch

Bei der Erarbeitung des Projektmanagementplans in der Phase Initialisierung wird festgelegt, ob der fakultative Entscheid Releasefreigabe treffen im Projekt zwingend vorgeschrieben ist

oder nicht.

Am Ende des aktuellen Release wird der Releasebericht abgenommen und über den Ab-schluss des Release entschieden. Anschliessend wird über die Freigabe des nächsten Release

entschieden.

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.

Wenn spezifische Stellen für Controlling und QS/Risikomanagement beauftragt wurden, er-stellen sie einen Bericht zuhanden des Auftraggebers.


Projektmanagementplan A

Projektstatusbericht A

Releasebericht A

Aktivitäten

Checkliste zur Releasefreigabe mit weiteren Freigabekriterien ergänzen. A

Projektziele, Machbarkeit und Nutzen des Projekts aufgrund neuer Erkenntnisse kritisch überprüfen und mit den Zielen der Stammorganisation abstimmen.

A

Überprüfen, ob übergeordnete Strategien, Standards und Vorgaben eingehalten

werden und Bestätigungen der zuständigen Stellen vorliegen.

A

Releasebericht, Projektmanagementplan und weitere Entscheidungsunterlagen

den Entscheidungsträgern zustellen.

A

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.

A

Entscheidung in der Stammorganisation abstimmen. A

Releasebericht, Projektmanagementplan und Release spezifischen Ergebnisse

prüfen und genehmigen oder zurückweisen.

A

Formellen Entscheid Releasefreigabe treffen oder Ergebnisse zurückweisen. A


o Betroffene über Entscheid informieren. A

Können die Projektziele nicht erreicht werden:

o entweder Korrekturmassnahmen festlegen; oder A

o Entscheid Projektabbruch treffen und Beendigung des Projekts beantragen. A

Ergebnisse

Checkliste Releasefreigabe A

QS- und Risikobericht A

Meilenstein Releasefreigabe A

Liste Projektentscheide Steuerung A

3.4.1.9 Entscheid Umsetzungsfreigabe treffen



Zweck

Der Entscheid Umsetzungsfreigabe schafft die Voraussetzung für die Arbeiten in der Phase

Konzept bei klassischer Vorgehensweise und in der Phase Umsetzung bei agiler Vorgehens-weise.

71 / 202

AU

FG

AB

EN

Grundidee

Mit der Umsetzungsfreigabe beginnt das eigentliche Projekt und die Projektorganisation wird in Kraft gesetzt. Die für die Phase benötigten Ressourcen werden freigegeben.

HERMES-spezifisch

Die Umsetzungsfreigabe erfolgt am Ende der Phase Initialisierung. Der Entscheid wird ge-meinsam durch den Auftraggeber und die Stammorganisation getroffen, evtl. im Rahmen ei-nes bestehenden Projektportfolios. Vor der Umsetzungsfreigabe werden der Umsetzungsauf-

trag und der Projektmanagementplan mit den übergeordneten Strategien und Zielen der Stammorganisation abgeglichen.

Mit der Umsetzungsfreigabe wird die eigentliche Lösungsentstehung eingeläutet, die beim klassischen Vorgehen mit der Phase Konzept, beim agilen Vorgehen mit der Phase Umsetzung startet.

Es wird einerseits entschieden, ob:

die Phase Initialisierung abgeschlossen wird oder ob weitere Ergebnisse zu erarbeiten sind;

und

anderseits, sofern die Phase Initialisierung abgeschlossen werden kann, ob die Umsetzung

(mit der Phase Konzept für klassisch bzw. Phase Umsetzung für agil):

freigegeben wird;

zurzeit nicht freigegeben wird und es später nochmals beantragt werden soll; oder

nicht freigegeben und das Vorhaben beendet wird.

Bei reinen Beschaffungsprojekten umfasst Umsetzungsauftrag lediglich die Beschaffungsfrei-gabe. Die Beschaffung ist dann ein normaler Einkaufsprozess, der losgelöst vom HERMES ab-

gewickelt werden kann. Mit dem Umsetzungsauftrag endet das Projekt.



Umsetzungsauftrag

Aktivitäten

Checkliste zur Umsetzungsfreigabe mit weiteren Kriterien ergänzen.

Überprüfung des Umsetzungsauftrags mit der Checkliste für Umsetzungsfreigabe durch

den Auftraggeber.

Ressourcen (personell, finanziell, Infrastruktur) für die gesamte Projektdauer sicherstellen.

Umsetzungsauftrag den Entscheidungsträgern zustellen.

Entscheidung in der Stammorganisation abstimmen.

Formellen Entscheid Umsetzungsfreigabe treffen.

Bei positivem Entscheid: o Umsetzungsauftrag unterzeichnen;

o Ressourcen für Lösungsentstehung (Phase Konzept bzw. Umsetzung) freigeben; o Betroffene und Stakeholder über Entscheid informieren.

Ergebnisse

Checkliste Umsetzungsfreigabe

Umsetzungsauftrag

Meilenstein Umsetzungsfreigabe


3.4.1.10 Entscheid Zuschlag treffen



Zweck

Der Entscheid Zuschlag ist die Voraussetzung für die Publikation des Zuschlags und die Erar-beitung des Vertrags mit dem Zuschlagsempfänger.

72 / 202

AU

FG

AB

EN

Grundidee

Nach dem Entscheid Zuschlag werden die Anbieter über das Ergebnis der Bewertung infor-miert. Der Zuschlag wird publiziert.

HERMES-spezifisch

Die Aktivitäten richten sich nach dem Kapitel Beschaffungsplan im Projektmanagementplan.


Evaluationsbericht


Aktivitäten

Checkliste Zuschlag ergänzen.

Projektziele, Machbarkeit und Nutzen des Projekts aufgrund neuer Erkenntnisse kritisch

überprüfen und mit den Zielen der Stammorganisation abstimmen.

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 (Debriefings).

Ergebnisse

Checkliste Zuschlag

Publikation



3.4.2 Entscheidungsaufgaben der Führung

3.4.2.1 Entscheid Abnahme Migration treffen



Zweck

Der Entscheid Abnahme Migration 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.




Aktivitäten

Checkliste Abnahme Migration mit weiteren Kriterien ergänzen.

Erreichung der Qualitätskriterien überprüfen.

Migration abnehmen, oder zurückweisen.

73 / 202

AU

FG

AB

EN


o formellen Entscheid Abnahme Migration treffen; o Migration formal abschliessen und nachvollziehbar protokollieren; o System freigeben.

Ergebnisse


Abnahmeprotokoll


Liste Projektentscheide Führung

3.4.2.2 Entscheid Abnahme treffen



Zweck

Die vollständige Lösung (klassisch) oder ein vollständiger Teil der Lösung (Inkrement, agil) werden inklusive der erforderlichen Dokumentation definitiv in die Betriebs- oder Anwender-

organisation überführt. Die Abnahme der ganzen Lösung bzw. des letzten Teils einer Lösung schafft die Grundlage für den Entscheid Projektabschluss.

Grundidee

Die Abnahme erfolgt zwischen Auftraggeber, 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.

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 – zum Beispiel gemäss Produktkonzept –

erfolgen kann und etwaige Mängel identifiziert werden.

Die Abnahme wird durch alle Beteiligten zeitgerecht geplant.

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

Abnahmeprotokoll

Meilenstein Abnahme


74 / 202

AU

FG

AB

EN

3.4.2.3 Entscheid ISDS-Konzept treffen



Zweck

Der Entscheid zum gesamten ISDS-Konzept (klassisch) oder zu einem in sich abgeschlossenen Teil des ISDS-Konzepts passend zur Realisierung eines Teils der Lösung (Inkrement, agil), ist die Voraussetzung für die Realisierung der ISDS-Massnahmen und zur Realisierung des Sys-

tems bzw. eines Teils davon.

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


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



3.4.2.4 Entscheid Lösungsarchitektur treffen



Zweck

Der Entscheid zur gesamten Lösungsarchitektur (klassisch) oder zu einem in sich abgeschlos-senen Teil der Lösungsarchitektur passend zur Realisierung eines Teils der Lösung (Inkrement,

agil) bildet die Voraussetzung für die Entwicklung oder Adaption 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.

75 / 202

AU

FG

AB

EN


Lösungsarchitektur

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



3.4.2.5 Entscheid Produktkonzept treffen



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.

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



3.4.2.6 Entscheid Vorabnahme treffen



Zweck

Die Vorabnahme schafft die Grundlage für die spätere Betriebsaufnahme sowie die Inbetrieb-setzung der ganzen Lösung (klassisch) bzw. eines vollständigen Teils der Lösung (Inkrement, agil) mit vertretbaren Risiken.

76 / 202

AU

FG

AB

EN

Grundidee

Die Vorabnahme erfolgt vor der Einführung und der Inbetriebsetzung der Lösung. Vorgängig werden qualitätssichernde Massnahmen wie Tests und Inspektionen durchgeführt. Die Vor-

abnahme gibt Anwendern, Entwicklern und Betreibern die Sicherheit, dass die Überführung der Lösung in den neuen Zustand mit hoher Wahrscheinlichkeit erfolgreich verlaufen wird.

HERMES-spezifisch

Die Vorabnahme erfolgt vor der Betriebsaufnahme der Lösung bzw. eines Teils der Lösung. Sie wird durch alle Beteiligten frühzeitig geplant. Dabei werden die Abnahmekriterien gemein-sam vereinbart. Bei der Entwicklung einer neuen Lösung werden sie mit der Abnahme der

Lösungsanforderungen und der Lösungsarchitektur festgelegt. Bei der Beschaffung einer Lö-sung erfolgt die Festlegung der Abnahmekriterien zum Zeitpunkt des Vertragsabschlusses

zwischen den projektbeteiligten Organisationen.


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.

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

Abnahmeprotokoll



3.4.2.7 Entscheid weiteres Vorgehen treffen



Zweck

Der Entscheid über das weitere Vorgehen bildet die Grundlage für die Erarbeitung des Pro-

jektmanagementplans. Gestützt auf den Entscheid wird der Umsetzungsauftrag erstellt.

Grundidee

Der Entscheid weiteres Vorgehen ist richtungsweisend für die Durchführungsart der Lösungs-entstehung, 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

77 / 202

AU

FG

AB

EN

Bei der Vorgehenswahl wird erstens sichergestellt, dass eine nachhaltige Variante gewählt wird. Entsprechend wird die vorgeschlagene Variante nochmals aus diesem Blickwinkel über-

prüft. Dazu werden die verschiedenen Stakeholder in den Entscheidungsprozess einbezogen. Der Projektleiter entscheidet sich nach Konsultation des Auftraggebers und weiterer Stake-

holder für eine Variante. Die Entscheidung basiert auf den in der Studie erarbeiteten Varian-tenbeschreibungen und -bewertungen sowie den Empfehlungen 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.

Die Studie wird gemäss den getroffenen Entscheiden ergänzt.


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.

Auf der Grundlage der Variantenbeschreibung und -bewertung in der Studie Empfehlun-

gen einholen.

Die geeignete Vorgehensart für die bevorzugte Variante prüfen.

Entscheid mit Auftraggebern und Stakeholdern abstimmen.

Formellen Entscheid zum weiteren Vorgehen treffen.

Ergebnisse

Checkliste weiteres Vorgehen

Studie

Meilenstein weiteres Vorgehen


3.4.3 Sonstige Aufgaben

3.4.3.1 Altsystem ausser Betrieb setzen



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)

78 / 202

AU

FG

AB

EN

werden umgesetzt.


Migrationskonzept


Meilenstein Abnahme

Aktivitäten

Altsystem oder alte Systemversion ausser Betrieb setzen.

Altdaten gemäss Migrationskonzept behandeln.

Altsystem abbauen und entsorgen oder die alte Systemversion (SW) entfernen.

Ergebnisse

Altsystem entfernt

3.4.3.2 Änderungen managen



Zweck

Das Änderungsmanagement stellt mit einem definierten Prozess sicher, dass Änderungen

klassisch geführter Projekte identifiziert, beurteilt und entschieden werden. Und es stellt weiter sicher, dass Änderungen aller klassischen und agilen Projekte dokumentiert werden.

Grundidee

Das Änderungsmanagement ermöglicht es, bei Änderungen von Zielen, Umfang, Anforde-

rungen, Rahmenbedingungen usw. die Kontrolle über die Entwicklung des klassisch geführten Projektes zu behalten und Auswirkungen auf den Betrieb zu erkennen. Die Projektplanung

und die Ergebnisse werden aufgrund der genehmigten Änderungen angepasst. Im klassisch geführten Projekt stellt der Projektleiter sicher, dass der Änderungsprozess konsequent ein-

gehalten, und bei sämtlichen Projekten, dass er konsequent dokumentiert wird.

HERMES-spezifisch

Die Änderungen werden im Rahmen der Lösungsentstehung gemäss Projektmanagement-plan gemanagt.

Beim klassischen Vorgehen werden bewilligte Änderungen in den Lösungsanforderungen nachgeführt.

Beim agilen Vorgehen wird nur die Dokumentation nur der wesentlichsten Änderungen er-stellt, die Änderungen selbst werden in der Aufgabe Lösungsanforderungen führen gehand-

habt und dokumentiert.

Die Änderungsstatusliste führt über alle behandelten Änderungen Buch und liefert eine Über-

sicht über deren Status.


Änderungsantrag K

Lösungsanforderungen A

Aktivitäten

Änderungsanträge der klassischen und die wesentlich Änderungen der agilen

Projekte in der Änderungsstatusliste erfassen und nachführen.

K A

Änderungsanträge analysieren und bewilligen/ablehnen. K

Bewilligte Änderungen planen, umsetzen und überprüfen. K

Projektmanagementplan aufgrund der Entscheide zu Änderungsanträgen an-

passen.

K

Projektmanagementplan aufgrund der Änderungen anpassen. A

79 / 202

AU

FG

AB

EN

Ergebnisse

Änderungsantrag K

Änderungsstatusliste K A

Projektmanagementplan K A

Lösungsanforderungen K

3.4.3.3 Angebote bewerten



Zweck

Die vorliegenden Angebote werden protokolliert und gemäss den Bewertungskriterien be-wertet. Die konkretisierten Aktivitäten der Beschaffungsanalyse werden durchgeführt.

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



Beschaffungsanalyse

Aktivitäten

Angebote öffnen, formal prüfen (rechtzeitig, vollständig) und Protokoll erstellen.

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

Evaluationsbericht

Angebotsprotokoll

3.4.3.4 Ausschreibung durchführen



Zweck

Die Ausschreibung wird nach einem bestimmten, transparenten Ablauf durchgeführt.

80 / 202

AU

FG

AB

EN

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


3.4.3.5 Ausschreibung erarbeiten



Zweck

Die Ausschreibung bildet die Voraussetzung für die Schaffung eines Wettbewerbs unter den Anbietern, für vergleichbare Angebote und für eine nachvollziehbare Bewertung.

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.

Das Lastenheft (auch Pflichtenheft genannt) beschreibt die Anforderungen an die zu beschaf-

fenden Leistungen (Güter, Dienstleistungen usw.) und das Vorgehen für die Beschaffungs-durchführung.

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.

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 zutreffend und vorhanden, ein integrierter Teil des Lasten-

hefts.

81 / 202

AU

FG

AB

EN


Beschaffungsanalyse


Schutzbedarfsanalyse

Studie

Organisationsanforderungen


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


3.4.3.6 Beschaffungsanalyse erarbeiten



Zweck

Mit der Erarbeitung der Beschaffungsanalyse werden alle beschaffungsrelevante Informatio-nen und Vorgaben zusammengetragen, der Ausschreibungsprozess vorbereitet und die

Grundlage für die Wahl der Verfahrensart erstellt. Es wird sichergestellt, dass die Beschaffung mit der Projektplanung abgestimmt ist

Grundidee

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 andere Rahmenbedingungen zu beachten sind, ob eventuell beschaffungsrechtlichen Anforderungen

zu erfüllen sind und welches Beschaffungsverfahren zum Tragen kommt. Die Beschaffungs-analyse wird mit den Controlling- und Vorgabestellen für das Beschaffungswesen abgestimmt.

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?

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?

82 / 202

AU

FG

AB

EN

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 vorgehen?

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 eigentliche 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.

Die Ausschreibung selbst findet erst nach der Umsetzungsfreigabe statt.

Der ermittelte und mit der Studie abgestimmte Beschaffungsplan wird im Projektmanage-mentplan (bei der Erarbeitung des Projektmanagementplans) festgehalten, falls die Ausschrei-

bungsstelle der Stammorganisation keinen Beschaffungsplan vorsieht.

Bei reinen Beschaffungsprojekten werden die Studie und die Beschaffungsanalyse zusammen-

gelegt. Der Umsetzungsauftrag umfasst in diesem Fall lediglich die Beschaffungsfreigabe.



Studie

Aktivitäten

Bedarfsanalyse und Marktanalyse durchführen und Informationen zu möglichen Lösungen

(Produkte, Services usw.) beschaffen.

Kickoff-Meeting in Wege leiten.

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

Beschaffungsanalyse

3.4.3.7 Betrieb aktivieren



Zweck

Die neue Betriebsorganisation des Betreibers wird aktiviert. Sie nimmt mit dem Betrieb des aktivierten Systems ihre Funktion auf.

Der Anwender nutzt das System.

83 / 202

AU

FG

AB

EN

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 kann einmalig er-folgen; im Rahmen der agilen Projekte kann sie aber auch mehrmals, pro Iteration/Release,

angegangen werden. Hierbei kommen immer weitere Teile der Lösung zum Tragen, die auf-einander aufbauen. Der Betreiber stellt den Betrieb gemäss SLA sicher.

Anwender und Betreiber werden durch den Ersteller in der ersten Zeit der Nutzung aktiv un-terstü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

Betriebshandbuch

Betrieb aktiviert

3.4.3.8 Betrieb realisieren



Zweck

Die Betriebsinfrastruktur und -organisation werden so weit realisiert, 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


Aktivitäten

Betriebsinfrastruktur realisieren und Tests durch den Betreiber durchführen.

Betriebshandbuch erstellen.

84 / 202

AU

FG

AB

EN

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

Betriebshandbuch

Betriebsorganisation realisiert

3.4.3.9 Betriebskonzept erarbeiten



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.





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.

Entwurf der SLA erarbeiten.

SLA mit den Controlling- und Vorgabestellen abstimmen bzw. durch diese prüfen lassen und danach abschliessen.

Betriebskonzept mit den Stakeholdern abstimmen.

Ergebnisse

Betriebskonzept


85 / 202

AU

FG

AB

EN

3.4.3.10 Einführung durchführen



Zweck

Die Durchführung der Einführungsmassnahmen schafft eine der Grundlagen für die Betriebs-aufnahme und die 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 ganze Dauer der Einführung bis zum Entscheid Betriebsaufnahme erstre-cken.

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.

Die Inbetriebsetzung des Systems erfolgt über entsprechende Aufgaben in den jeweiligen Modulen. Diese enthalten weitere Aktivitäten, die im Zusammenhang mit der Inbetriebset-zung und der Einführung stehen.



Einführungskonzept


Aktivitäten

Durchführen der realisierten Einführungsmassnahmen.

Wirksamkeit der Einführungsmassnahmen überprüfen.

Ergebnisse


3.4.3.11 Einführung realisieren



Zweck

Das Einführungskonzept ist soweit erarbeitet, dass die Einführung vorbereitet und somit rea-

lisiert werden kann.

Grundidee

Auf der Basis des Einführungskonzepts werden die Einführungsmassnahmen und die Einfüh-rungsorganisation vorbereitet. Ein Beispiel für die Vorbereitung:

einer Einführungsmassnahme ist die Entwicklung einer Ausbildung; die eigentliche Durch-führung der Ausbildung erfolgt dann erst im Zuge der Einführung;

der Einführungsorganisation ist die Ausbildung von Superusern, die die Einführung unter-stützen; sie werden jedoch erst während der Einführung aktiv.

HERMES-spezifisch

Die im Einführungskonzept festgelegten Notfallmassnahmen und die Notfallorganisation wer-den vorbereitet.

Die realisierten Einführungsmassnahmen und Notfallorganisation werden in der Aufgabe Ent-

scheid Vorabnahme treffen geprüft.

86 / 202

AU

FG

AB

EN


Einführungskonzept

Aktivitäten

Einführungsmassnahmen und -organisation realisieren (inkl. Notfallmassnahmen und -or-

ganisation).

Ergebnisse


3.4.3.12 Einführungskonzept erarbeiten



Zweck

Das Einführungskonzept wird soweit erarbeitet, dass in der Phase Realisierung die Einführung vorbereitet werden kann.

Grundidee

Das Einführungskonzept legt fest, wie die Einführung gestaltet wird:

Einführungsvorgehen: Eine stichtagartige oder stufenweise Einführung wählen und Pla-

nung festlegen;

Einführungsorganisation: Rollen der Einführungsunterstützung definieren;

Einführungsmassnahmen: Ausbildung entwickeln, Unterlagen vorbereiten.

HERMES-spezifisch

Auf Basis der Konzepte der verschiedenen Module wird das Einführungskonzept erarbeitet.

Die im Einführungskonzept definierten Einführungsmassnahmen werden anschliessend reali-siert und durchgeführt.

Ausgehend vom Einführungskonzept werden die Freigabekriterien für den Entscheid Betriebs-aufnahme festgelegt.

Wird ein Produkt oder ein System 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.

Bei der Ablösung eines bestehenden Systems steht das Einführungskonzept inhaltlich in Be-zug zum Migrationskonzept. Sie können sich gegenseitig beeinflussen.




Systemkonzept

Produktkonzept

Betriebskonzept

Migrationskonzept

ISDS-Konzept

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.

Ergebnisse

Einführungskonzept

87 / 202

AU

FG

AB

EN

3.4.3.13 Integrationskonzept erarbeiten



Zweck

Die Erarbeitung des Integrationskonzepts schafft die Grundlage für die Integration des Sys-tems in die Betriebsinfrastruktur, in den IT-Umsystemen und in den verschiedenen Betriebs-plattformen.

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.



Lösungsarchitektur

Aktivitäten

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

3.4.3.14 Iterationen durchführen



Zweck

Die Durchführung von Iterationen erlaubt in einem agil geführten Projekt die im HERMES festgelegte Entwicklung inkrementell voranzutreiben, Feedback von den Stakeholdern einzu-fordern und auf Änderungen oder Probleme zeitnah zu reagieren.

Grundidee

Bei agilen Projekten erfolgt die Entwicklung iterativ in Feedback-Schleifen, die jeweils in einem lauffähigen, überprüften und freigegebenen Ergebnis münden. Deshalb ist die Steuerung der Ergebniserarbeitung nach HERMES agil abzuwickeln.

HERMES-spezifisch

Die Durchführung der Iterationen richtet sich im Wesentlichen nach der verwendeten agilen Entwicklungsmethode. Die Aufgabe Iterationen durchführen steuert nur die Durchführung der einzelnen modulspezifischen HERMES Aufgaben und die sukzessive iterative Erarbeitung der

88 / 202

AU

FG

AB

EN

entsprechenden Ergebnisse. Die Ergebnisse wie Konzepte usw. entstehen hierbei inkrementell. Erst bei der letzten Iteration ist das Ergebnis vollständig.

Das Entwicklungsteam arbeitet selbstorganisierend und trägt die Verantwortung für die Durchführung der geplanten Iteration und insbesondere für die Erarbeitung der im Modul vorgesehen Ergebnisse gemäss den entsprechenden Aufgaben.

Das Entwicklungsteam hält sich an die definierten Vereinbarungen der agilen Arbeitsweise, die im Projektmanagementplan dokumentiert wurde. Bei vielen nicht unmittelbar entwick-lungsspezifischen Aufgaben wird das Entwicklungsteam durch den Projektleiter entlastet.



Releaseplan

Detailspezifikation

Aktivitäten

Tagespensum ausführen.

Lösung entwickeln.

Iterationsreview durchführen:

Präsentation der Lösung vorbereiten und durchführen und gemäss Testkonzept testen.

Iterationsrückblick durchführen und Erfahrungen im Protokoll festhalten.

Ergebnisse

Inkrement

Protokoll

3.4.3.15 Iterationen planen



Zweck

In einem agil geführten Projekt müssen die iterativ-inkrementelle Entwicklungsschleifen, die Iterationen, geplant und definiert sowie in der Detailspezifikation festgehalten werden.

Grundidee

Der Iterationsleiter moderiert die Planungssitzung, an der das ganze Entwicklungsteam betei-ligt ist. Das Entwicklungsteam schätzt pro Auftrag die Aufwände und entscheidet autonom,

wie viele der am höchsten priorisierten Aufträge der Lösungsanforderungen es in der geplan-ten Iteration abarbeiten kann. Es übernimmt die priorisierten Aufträge streng nach absteigen-

der Priorität in die Detailspezifikation, deren Eigentümer es ist. Es werden genauso viele Auf-träge übernommen, wie maximal in der geplanten Iteration umgesetzt werden können. Das

Ziel der Iteration sowie die Lösung werden festgelegt.

HERMES-spezifisch

Die agile Steuerung der Entwicklung pro Iteration erfolgt in der Aufgabe Iteration durchführen mittels Detailspezifikation. Die Iteration muss daher gemäss Vorgaben im Projektmanage-

mentplan definiert, geplant und in der Detailspezifikation festgehalten werden. Die Iterations-planung basiert auf dem Releaseplan, der in einzelne Iterationen heruntergebrochen wird. Die

Aufträge werden aus den stets aktualisierten Lösungsanforderungen gemäss den gesetzten Prioritäten und dem Releaseplan übernommen. In der Detailspezifikation steht, was in der

Iteration erreicht werden soll.

Obwohl das Entwicklungsteam der Eigentümer der Detailspezifikation ist, ist die Aufgabe

selbst dem Iterationsleiter zugeordnet. Er ist derjenige, der letztlich den ganzen Iterationspro-zess sichert und verantwortet.

Die in der klassischen Vorgehensweise für die Detailspezifikation vorausgesetzten Ergebnisse wie Konzepte oder Architekturen werden beim agilen Vorgehen erst im Rahmen der Iterati-onsdurchführung mittels entsprechenden Aufgaben nachgeführt.

89 / 202

AU

FG

AB

EN




Releaseplan

Aktivitäten

Planungssitzung einberufen und durchführen.

Aufträge aus der Lösungsanforderungen auswählen und in die Detailspezifikation über-nehmen.

Detailspezifikation erarbeiten.

An Projektsitzungen berichten, Fortschrittskontrolle unterstützen, Plan- und Istwerte lie-

fern.

Ergebnisse

Detailspezifikation

3.4.3.16 ISDS-Konzept erarbeiten



Zweck

Das ISDS-Konzept (Informationssicherheits- und Datenschutzkonzept) schafft die Vorausset-

zungen dafür, dass die Informationssicherheit und der Datenschutz sichergestellt werden kön-nen.

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 Schutzbedarfanalyse, 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

90 / 202

AU

FG

AB

EN

3.4.3.17 ISDS-Konzept realisieren



Zweck

Die im ISDS-Konzept definierten Schutzmassnahmen werden realisiert. Die Realisierung ist Voraussetzung für die Systemtests.

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 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.

Beurteilung der Restrisiken im ISDS-Konzept nachführen.

ISDS-Konzept mit den Restrisiken durch den Auftraggeber genehmigen.

Ergebnisse


ISDS-Konzept

3.4.3.18 ISDS-Konzept überführen



Zweck

Das ISDS Konzept wird aktualisiert und durch die Controlling- und Vorgabestelle geprüft. Dies ist eine der Voraussetzungen für den Entscheid Betriebsaufnahme. Das ISDS-Konzept wird

von der Projektorganisation in die Stammorganisation überführt.

Grundidee

Der Auftraggeber muss sich mit dem aktualisierten und geprüften ISDS-Konzept identifizieren, dieses gutheissen und nach aussen hin vertreten sowie die Restrisiken akzeptieren können.

HERMES-spezifisch

Durch die Genehmigung und Überführung des ISDS-Konzepts akzeptieren der Auftraggeber sowie die Leitung der Stammorganisation die ISDS-Restrisiken. Mit dem nachfolgenden Ent-scheid Betriebsaufnahme übernimmt somit der Auftraggeber die Verantwortung für die Risi-

ken des Betriebs.



ISDS-Konzept

91 / 202

AU

FG

AB

EN

Aktivitäten

Stand der Realisierung im ISDS-Konzept nachführen.

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

3.4.3.19 Leistungen vereinbaren und steuern



Zweck

Mit der Leistungsvereinbarung entsteht eine klar geregelte Beziehung zwischen den Projekt-partnern sowie zwischen der Projekt- und der Stammorganisation. Abweichungen während

der Leistungserbringung werden identifiziert und behandelt.

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 reine Beschaffung.

Umfassende Beschaffung mittels offenem oder selektivem Verfahren und öffentlicher Pub-likation (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 betreffend den Bezug von betriebs- und wartungsspezifischen Dienst-

leistungen während der Nutzungsphase des Systems zwischen dem Anwender und dem künftigen 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.

Im Rahmen einer Analyse wird der Bedarf an Leistungen identifiziert und analysiert und eine Marktuntersuchung durchgeführt. Hierbei werden folgende Fragen geklärt wie:

Rechtfertigt sich eine Ausschreibung, wie ist der konkrete Handlungsbedarf?

Welche Ressourcen sollen genau beschafft werden, in welcher Anzahl und bei Personal-

ressourcen z. B. mit welcher fachlicher 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?

Darauf basierend werden Angebote eingeholt und Vereinbarungen abgeschlossen.

Wird allerdings im Rahmen der Bedarfs- und Marktanalyse festgestellt, dass eine umfassende Beschaffung mittels offenem oder selektivem Verfahren und öffentlicher Publikation notwen-

dig ist, wird die Ressourcenbeschaffung mit dem Modul Beschaffung durchgeführt.

92 / 202

AU

FG

AB

EN

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.

Fall 3 Bezug von externen Leistungen im freihändigen Verfahren wird über Offertanfragen und

Verträge sowie Leistungserbringer spezifischen SLAs geregelt.

Fall 4

Bezug von externen Leistungen im Einladungsverfahren wird über Offertanfragen und

Verträge sowie Leistungserbringer bezogene SLAs geregelt. Für die Bewertung der Offer-ten wird beim Einladungsverfahren ein Evaluationsbericht erstellt.

Projektvereinbarungen, Projekt-SLAs, Leistungserbringer bezogene SLAs und Verträge wer-den nach den Vorgaben der Stammorganisation erarbeitet. HERMES bezeichnet diese Ergeb-nisse generell als Vereinbarung.

Während der Leistungserbringung und bei Abschluss derselben wird eine Leistungsbeurtei-lung durchgeführt und mit den Projektpartnern besprochen. Sie bildet die Grundlage für all-

fä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.




Umsetzungsauftrag

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.

Leistungen während der Leistungserbringung und bei deren Abschluss beurteilen.

93 / 202

AU

FG

AB

EN

Ergebnisse

Offertanfrage

Angebot

Evaluationsbericht

Vereinbarung

3.4.3.20 Lösungsanforderungen erarbeiten



Zweck

Mit den Lösungsanforderungen werden alle erkannten und genannten relevanten Anforde-rungen an das System oder an das Produkt erarbeitet.

Im klassisch geführten Projekt bilden sie die Grundlage für die Erarbeitung der Lösungsarchi-tektur bzw. das Produktkonzept.

Im agil geführten Projekt sind sie der Grundstein für deren Führung im Sinne eines "Product Backlogs".

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 Umset-

zungsauftrag 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 Beschaffung oder Realisierung des Systems

bilden. Im Falle einer Beschaffung fliessen sie in das Lastenheft ein und sind die Grundlage für den Entscheid Abnahme.

Bei klassischen Projekten werden bei Bedarf die abgenommenen Lösungsanforderungen nur noch mittels Änderungsmanagement nachgeführt.

Bei agilen Projekten werden sie im Rahmen der Aufgabe "Lösungsanforderungen führen" dy-namisch weitergepflegt und bilden die Grundlage für die Planung der Iterationen.

Je nach Kritikalität eines Systemelements variiert die Detaillierungstiefe.

Die Lösungsanforderungen werden im Zuge der Lösungsentstehung weiter konkretisiert und in der Detailspezifikation dokumentiert.


Studie

Rechtsgrundlagenanalyse

Beschaffungsanalyse

Umsetzungsauftrag

Stakeholderliste

Aktivitäten

Rahmenbedingungen aus dem Umsetzungsauftrag kritisch hinterfragen und Einflüsse auf

den Projekterfolg analysieren.

Die Standortbestimmung aus der Studie umfassend ergänzen und vertiefen.

Anforderungen konkretisieren, als Lösungsanforderungen dokumentieren und eindeutig

priorisieren.

94 / 202

AU

FG

AB

EN

Lösungsanforderungen mit den Stakeholdern abstimmen.

Ergebnisse

Situationsanalyse


3.4.3.21 Lösungsanforderungen führen



Zweck

Die Lösungsanforderungen, die in einem agil geführten Projekt im Sinne eines "Product Back-logs" alle noch ausstehenden Aufträge des Entwicklungsteams beinhalten, müssen verwaltet

und aktualisiert, pro Iteration neu bewertet und priorisiert werden.

Grundidee

In den sukzessiv weitergeführten Lösungsanforderungen wird ein stets aktualisierter Bestand an unerledigten, projektspezifischen und priorisierten Aufträgen verwaltet, die aufgrund von

Anforderungen spezifiziert wurden und auf ihre Abarbeitung warten.

HERMES-spezifisch

Die Lösungsanforderungen werden in der Phase Umsetzung sukzessive weitergeführt und aktualisiert. Die bestehenden Aufträge werden laufend konkretisiert und verfeinert, es kom-

men neue hinzu und andere werden gelöscht. Dieses interne, systemische und agile Ände-rungsmanagement beinhaltet den reaktiven, proaktiven und retrospektiven Umgang sowohl

mit Änderungen der Lösungsanforderungen in der Entwicklung als auch mit den daraus re-sultierenden Änderungen und Konsequenzen für die spätere Betriebs- und Anwendungsor-

ganisation.

Die priorisierten Aufträge werden so gehandhabt, dass die Priorität jedes einzelnen Auftrags

stets eineindeutig bleibt und somit eine eindeutige, unmissverständliche und stets aktuelle Reihenfolge der Aufträge besteht.

Die nachgeführten Lösungsanforderungen sind die Basis für die Planung und die Durchfüh-rung der Iterationen. Die sukzessive Abarbeitung der Lösungsanforderungen erfolgt mit der Aufgabe Iterationen planen nach absteigender Priorität, wobei die wichtigsten Anliegen als

Erste in Angriff genommen werden. Hierbei werden die Aufträge, die in einer kommenden Iteration erledigt werden sollen, im Rahmen der Iterationsplanung in die Detailspezifikation

übertragen. Die Wichtigkeit und somit die Priorität der verbliebenen Aufträge kann jederzeit ändern.

Bei kleineren Entwicklungsvorhaben kann das Weiterführen der Lösungsanforderungen mit der Aufgabe Iterationen planen abgewickelt werden.



Releaseplan

Aktivitäten

Neue Lösungsanforderungen erarbeiten.

Aufträge verwalten und priorisieren.

Lösungsanforderungen abarbeiten.

Auswirkungen der Priorisierung auf die Zielerreichung des Projekts analysieren.

Neue und wegfallende Anforderungen dem Änderungsmanagement zuführen.

Projektumfang und Inhalt überwachen.

Ergebnisse


95 / 202

AU

FG

AB

EN

3.4.3.22 Lösungsarchitektur erarbeiten



Zweck

Mit der Lösungsarchitektur wird die Grundlage für die Realisierung des Systems geschaffen.

Grundidee


Systemkonzepte schaffen Grundlagen für die Lösungsarchitektur und ergänzen diese. Sie

beschreiben Lösungskonzepte für spezifische Themen (z. B. Benutzerverwaltung und Zu-griffsrechte, Archivierung).

Die Lösungsarchitektur beschreibt das System mit seinen Komponenten und seinem Auf-bau (Architektur) sowie den Schnittstellen zu den Umsystemen. Die Lösungsarchitektur

beschreibt auch den Bezug der IT-Architektur zu den Geschäftsprozessen.

Im Systemkonzept werden Lösungsvarianten erarbeitet und bewertet. Die ausgewählten Va-

rianten werden in der Lösungsarchitektur zu einer gesamthaften Lösung zusammengeführt.

HERMES-spezifisch

Das Systemkonzept vertieft die in der Studie beschriebene und gewählte Variante. Es können mehrere themenspezifische Systemkonzepte mit jeweils verschiedenen Lösungsvarianten er-

arbeitet 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

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

Lösungsarchitektur

3.4.3.23 Migration durchführen



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.

96 / 202

AU

FG

AB

EN

HERMES-spezifisch

Eine erfolgreiche Migration ist die Voraussetzung für die Abnahme der Migration.


Detailspezifikation

Migrationsverfahren realisiert

Aktivitäten

Migration mit den Migrationsverfahren gemäss Migrationskonzept durchführen.

Qualitätssichernde Massnahmen durchführen.

Notwendige Bereinigungen durchführen.

Ergebnisse


3.4.3.24 Migrationskonzept erarbeiten

Zweck

Das Migrationskonzept schafft die Grundlage für die Überführung des alten in das neue Sys-tem sowie für die Ausserbetriebnahme des Altsystems.

Grundidee

Der Schwerpunkt der Systemmigrationen ist die Datenmigration. Migrationen können tech-nisch (maschinell) oder organisatorisch (manuell) erfolgen.

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).



Einführungskonzept

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

Migrationskonzept



97 / 202

AU

FG

AB

EN

3.4.3.25 Migrationsverfahren realisieren



Zweck

Die Migrationsverfahren werden so weit 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.


Migrationskonzept

Aktivitäten

Detailspezifikation für Migration und Abbau des Altsystems erstellen.

Testinfrastruktur realisiert.

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

Detailspezifikation

Migrationsverfahren realisiert

3.4.3.26 Organisation aktivieren

Zweck

Die neue Geschäftsorganisation wird aktiviert. 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 Geschäftsorganisation, damit die Mitarbeitenden in ihren neuen Rollen 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 und anschliessend wird in Übereinstimmung mit der neuen Geschäfts-

organisation gearbeitet.

Die Projektorganisation begleitet und unterstützt die Geschäftsorganisation in der ersten Zeit

der Nutzung.

Sobald die Nutzung gemäss neuem Geschäftsmodell, neuer Prozessbeschreibung und neuer Organisationsbeschreibung problemlos erfolgen kann, wird der Entscheid Abnahme getrof-

fen.



98 / 202

AU

FG

AB

EN



Aktivitäten

Stakeholder frühzeitig informieren.

Organisation aktivieren.




Ergebnisse

Organisation aktiviert

3.4.3.27 Organisation umsetzen



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 so weit re-alisiert, dass die neue Organisation operationell aktiviert werden kann.

HERMES-spezifisch

Basierend auf dem Organisationskonzept werden die Geschäftsmodell-, die Prozess- und die Organisationsbeschreibung realisiert sowie die entsprechenden Massnahmen umgesetzt.

Die Geschäftsmodellbeschreibung umfasst die geschäftliche Sichtweise und legt den Rahmen für die Prozess- und Organisationsbeschreibung fest. Die Prozessbeschreibung beschreibt die

Prozesse mit den eingesetzten Hilfsmitteln. Die Organisationsbeschreibung beschreibt die Aufbauorganisation mit dem detaillierten Organigramm, den Funktionsbeschreibungen und

Personalanforderungen. Aufgrund der Geschäftsmodell-, Prozess- und Organisationsbe-schreibung werden die Massnahmen realisiert, um die Organisation ins Leben zu rufen (Kom-

munikationskanäle, Distributionskanäle, Rollenbesetzungen, Personalanstellungen usw.).

Im Modul Einführungsorganisation werden die Ergebnisse der realisierten Geschäftsorganisa-

tion vor der Vorabnahme mit der Aufgabe Entscheid Vorabnahme treffen geprüft.




Prozessbeschreibung


Aktivitäten

Geschäftsmodellbeschreibung realisieren/fertigstellen.

Prozessbeschreibung realisieren/fertigstellen.

Organisationsbeschreibung realisieren/fertigstellen.

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.

99 / 202

AU

FG

AB

EN

Ergebnisse


Prozessbeschreibung


Organisation umgesetzt

3.4.3.28 Organisationsanforderungen erarbeiten



Zweck

Mit den Organisationsanforderungen werden alle erkannten relevanten Anforderungen an die Geschäftsorganisation erarbeitet.

Grundidee


Die Situationsanalyse vertieft die Standortbestimmung aus der Studie und zeigt den Hand-lungsbedarf auf.

Die Organisationsanforderungen konkretisieren die groben Anforderungen aus der Studie

aus organisatorischer und geschäftlicher Sicht und erweitern sie aufgrund des in der Situ-ationsanalyse 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 Beschaffung oder Realisierung der Lö-sung (Produkt, System) bilden. Im Falle einer Beschaffung fliessen sie in das Lastenheft ein

und bilden die Grundlage für den Entscheid Abnahme.

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.


Studie



Stakeholderliste

Beschaffungsanalyse

Aktivitäten

Rahmenbedingungen aus dem Umsetzungsauftrag 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


100 / 202

AU

FG

AB

EN

3.4.3.29 Organisationskonzept erarbeiten



Zweck

Im Organisationskonzept wird die neue Geschäftsorganisation beschrieben und das Vorgehen für ihre Realisierung festgelegt.

Grundidee

Im Organisationskonzept wird das Geschäftsmodell sowie die daraus resultierende Aufbau- und Ablauforganisation (Prozesse) für die Geschäftsabwicklung beschrieben. Es wird aufge-

zeigt, wie die neue Organisation gestaltet wird und welche Änderungen an Bestehendem vor-genommen werden. Die Prozessbeschreibung umfasst die Kernprozesse, die Führungspro-

zesse und die Supportprozesse.

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 in der Geschäftsmodellbetrachtung, in der Aufbau- und in der Ablauforganisation konzeptuell

entwickelt. Die Geschäftsmodellbeschreibung legt hierbei den Rahmen für die Aufbau- und Ablauforganisation fest. Die Aufbauorganisation gibt Auskunft über die neuen oder ange-

passten Strukturen in der Stammorganisation, in der Ablauforganisation werden das Prozess-modell erstellt und die entsprechenden Prozesse identifiziert und dokumentiert.

Basierend auf dem Organisationskonzept können bereits je nach Projektart und Möglichkeit, insbesondere in Verbindung mit allfälligen parallelen Aktivitäten der Module Produkt und IT-System, die Geschäftsmodell-, die Prozess- und die Organisationsbeschreibung in Angriff ge-

nommen werden.


Studie



Aktivitäten

Organisationskonzept erarbeiten

Auswirkungen auf die Organisation analysieren und auf Machbarkeit prüfen

Organisationskonzept mit den Stakeholdern abstimmen

Ergebnisse



Prozessbeschreibung


3.4.3.30 Phasenfreigabe vorbereiten



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 für die Entscheidungsträger aufbereitet.

101 / 202

AU

FG

AB

EN

HERMES-spezifisch

Die Gesamtplanung des Projekts wird überprüft, und die Detailplanung für die nächste Phase wird 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

Änderungsstatusliste

Projekterfahrungen

Aktivitäten

Nächste Phase detailliert planen.

Gesamtplan verifizieren.

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).

Ergebnisse des Projektablaufs, inklusive von Änderungen, im Phasenbericht zusammen-fassen.

Anträge zur Abnahme von Ergebnissen, zum weiteren Vorgehen, zu den freizugebenden

Ressourcen usw. stellen.

Entscheide bei der Projektsteuerung initiieren.

Ergebnisse

Phasenbericht



3.4.3.31 Probleme behandeln und Erfahrungen nutzen



Zweck

Die stufengerechte Bearbeitung von Problemen hilft, die Ziele zu erreichen. Mit der Nutzung der Erfahrungen wird die kontinuierliche Verbesserung im Projekt und in der Stammorgani-

sation unterstützt.

Grundidee

Das frühzeitige Erkennen und Lösen von Problemen ist eine wichtige Voraussetzung für das Erreichen der Meilensteine und Projektziele. Ist die Problemlösung durch den Bearbeitenden

nicht oder nicht rechtzeitig möglich, wird das Problem umgehend innerhalb der Projektorga-nisation 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

102 / 202

AU

FG

AB

EN

ist eine Teamaufgabe.

Die Erfahrungen bzw. identifizierten Massnahmen zu Problemlösungen fliessen in die Aufga-ben Projekt führen und kontrollieren, Phasenfreigabe vorbereiten und Releaseabschluss vor-

bereiten ein.



Aktivitäten

Probleme identifizieren und bewerten.

Massnahmen definieren und Umsetzung ü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 die Stam-

morganisation weitergeben.

Ergebnisse

Projekterfahrungen

3.4.3.32 Produkt aktivieren

Zweck

Das Produkt wird aktiviert. Der Anwender nutzt das Produkt.

Grundidee

Der Ersteller aktiviert das Produkt, damit es der Anwender produktiv nutzen kann.

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 (Betreiber) wird durch den Ersteller in der ersten Zeit der Nutzung aktiv unterstützt.



Produkt entwickelt oder angepasst

Aktivitäten

Stakeholder frühzeitig informieren.

Produkt aktivieren.




Ergebnisse

Produkt aktiviert



103 / 202

AU

FG

AB

EN

3.4.3.33 Produkt realisieren



Zweck

Das Produkt wird so weit realisiert, dass es die definierten Qualitätsmerkmale erfüllt und ein-geführt werden kann.

Grundidee

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 eigentliche Produkt realisiert wird. Das hängt stark vom Produkt ab.

Für die Durchführung der qualitätssichernden Massnahmen kann die Aufgabe Qualitätssiche-rung führen im Modul Projektführung und/oder direkt das Modul Tests genutzt werden.

Im Modul Einführungsorganisation wird das Produkt vor der Vorabnahme mit der Aufgabe Entscheid Vorabnahme treffen geprüft.



Produktkonzept


Aktivitäten


Produkt entwickeln oder anpassen.

Produktdokumentation erarbeiten.

Anwendungshandbuch erarbeiten.

Qualitätssichernde Massnahmen vorbereiten und durchführen.

Ergebnisse

Detailspezifikation

Produktdokumentation

Anwendungshandbuch


3.4.3.34 Produktkonzept erarbeiten



Zweck

Mit dem Produktkonzept wird die Grundlage für die Beschaffung oder Realisierung des Pro-dukts geschaffen.

Grundidee


Das Produktkonzept beschreibt das Produkt mit seinen Komponenten und seiner Struktur,

104 / 202

AU

FG

AB

EN

evtl. auch den Bezug des Produkts zu den Geschäftsprozessen.

Im Produktkonzept können bei Bedarf Lösungsvarianten erarbeitet und bewertet werden.

Anschliessend werden die gewählten Varianten ausdetailliert.

HERMES-spezifisch

Im Produktkonzept werden die Anforderungen und die Beschreibung der gewählten Variante 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 Beschaffung) des Produkts bildet.

Das Produktkonzept bildet im weiteren Projektverlauf die Grundlage für die Abnahme des Produkts.


Studie



Prototyp

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

3.4.3.35 Projekt führen und kontrollieren



Zweck

Während der gesamten Projektdauer werden die Projektbeteiligten beauftragt und geführt, damit die Aufgaben erfüllt werden. Der Projektfortschritt wird über die ganze Projektdauer laufend überprüft und die Planung aktualisiert.

Grundidee

Die Führung und die Kontrolle des Projekts basieren auf der Projektplanung. Die Planung beschreibt, wie die Ziele erreicht werden (Soll) und zeigt den aktuellen Projektstand (Ist) sowie die zukünftige Entwicklung (Prognose) auf.

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 stimmt er beim klassischen Vorgehen im

Voraus mit den Anwendervertreter ab, beim agilen Vorgehen fallen diese weg. Er 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. Die Istwerte der aktuellen Projektsituation werden erhoben

und mit der Planung verglichen. Die Aufwände, Kosten und Termine für den weiteren Projekt-verlauf werden geschätzt und als Prognose in der Planung abgebildet. Bei aufgetretenen oder

prognostizierten Abweichungen von der Planung leitet der Projektleiter, unterstützt vom An-wendervertreter, Massnahmen ein, damit die 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 geliefert. Das

Reporting stellt die formal standardisierte Information zwischen Projektführung, Projektsteu-erung und weiteren Stellen sicher.

105 / 202

AU

FG

AB

EN

HERMES-spezifisch

In der Phase Initialisierung bildet der Projektinitialisierungsauftrag die Grundlage für die Füh-rung und Kontrolle des Projekts. In den nachfolgenden Phasen werden die Informationen zur

Projektführung und -kontrolle sowie zur Regelung des Reportings im Projektmanagement-plan festgehalten. Das Reporting besteht aus dem Berichtswesen und Projektsitzungen. Zum

Berichtswesen gehören der Projektstatusbericht und der Phasenbericht. 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.

Sind massgebende Projektänderungen erforderlich, werden sie über die Aufgabe Änderungen

managen behandelt. In der Phase Initialisierung gibt es allerdings noch kein formales Ände-rungsmanagement, da die Organisations- und Lösungsanforderungen sowie die Projektziele

noch nicht definiert sind. Gibt es Änderungen gegenüber dem Projektinitialisierungsauftrag, die Ergebnis, Aufwand oder Termin betreffen, entscheidet der Auftraggeber darüber.




Umsetzungsauftrag

Projekterfahrungen

Aktivitäten

Kick-off-Sitzung mit Beteiligten durchführen und Projektkultur gestalten.

Infrastruktur bereitstellen.

Aufgaben, Ergebnisse und Ressourcen der Initialisierung planen, beauftragen und Fort-schritt kontrollieren (inklusive QS-Massnahmen und Risiken).

Rahmenbedingungen und Vorgaben für das Reporting ermitteln.

Reporting mit Berichtswesen und Projektsitzungen im Projektmanagementplan festlegen

und mit Auftraggeber vereinbaren.

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 und die Zielorientierung sicherstellen.

Arbeitsaufträge erstellen und wenn notwendig mit dem Anwendervertreter abstimmen.

Gemeinsames Verständnis in Bezug auf Vorgehen und Ergebnisse sicherstellen.

Abhängigkeiten zwischen Aufträgen koordinieren.

Fortschrittskontrolle durchführen, dazu Istwerte mit Planwerten vergleichen und Progno-sen erstellen.

Abweichungen von der Planung analysieren und Massnahmen einleiten.

Während der Phase Initialisierung ermittelte Änderungen gegenüber dem Projektinitiali-

sierungsauftrag durch den Auftraggeber genehmigen lassen.

Nach Umsetzungsfreigabe Projektmanagementplan laufend nachführen.

Ergebnisse


Arbeitsauftrag


Protokoll

3.4.3.36 Projekt steuern

Zweck

Die Steuerung des Projekts sowie das Treffen von Entscheidungen bilden eine Voraussetzung für den Projekterfolg.



106 / 202

AU

FG

AB

EN

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 Abweichungen im Projektablauf frühzeitig erkannt und der Projekterfolg sichergestellt werden kann, führen die für die Steuerung zuständigen Personen regelmässig Fortschritts-kontrollen durch.

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.

Damit die Projektdurchführung effizient erfolgt, stellt der Auftraggeber rasche Entscheidun-gen sicher. Er plant und steuert die Entscheidungsprozesse in Zusammenarbeit mit dem Pro-

jektleiter und bei Bedarf mit weiteren Stellen. Er integriert die Entscheidungsträger in das Pro-jekt.

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.




Umsetzungsauftrag


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- und Risikomanagement und/oder Projektreviews und -audits beauftragen.

Entscheidungen o Entscheidungsprozesse planen und steuern.

o Liste Projektentscheide fällen, kommunizieren und durchsetzen. o Stakeholder einbinden.

o Entscheide zu Änderungsanträgen fällen. o Eskalationen behandeln.

Ergebnisse



107 / 202

AU

FG

AB

EN

3.4.3.37 Projektabschluss vorbereiten



Zweck

Mit der Vorbereitung des Projektabschlusses wird die Voraussetzung zur Auflösung der Pro-jektorganisation und Beendigung des Projekts geschaffen.

Grundidee

Die Dokumentenablage wird bereinigt, und die Projektdokumentation wird an die Stammor-ganisation übergeben.

Die Projektabwicklung und die Ergebnisse werden beurteilt.

Zur Projekterfolgskontrolle muss einige Zeit nach dem Projektabschluss überprüft werden, ob die erwartete Wirkung aus Sicht des Auftraggebers eingetreten ist. Dazu gehören zum Beispiel

die vertiefte Überprüfung der Zielerreichung oder eine Nachkalkulation.

Alle offenen Pendenzen aus dem Projekt werden an die zuständigen Personen in der Stam-morganisation übergeben.

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.

Projekterfahrungen abschliessen und an die Stammorganisation übergeben.

Festlegen, was im Rahmen der Projekterfolgskontrolle untersucht werden soll, welche

Massnahmen dazu vorzusehen sind und wer diese ausführen wird.

Als Pendenz an die Stammorganisation übergeben.

Offene Pendenzen aus dem Projekt an verantwortliche Personen in der Stammorganisa-

tion übergeben.

Ergebnisse

Projekterfahrungen


108 / 202

AU

FG

AB

EN

3.4.3.38 Projektmanagementplan erarbeiten



Zweck

Mit der Erarbeitung des Projektmanagementplans werden die Gesamtplanung des Projekts und die wesentlichen Bestimmungen und Regelungen festgelegt sowie die Voraussetzungen dafür geschaffen, den Umsetzungsauftrag zu erarbeiten.

Grundidee

Mit der Erarbeitung des Projektmanagementplans werden noch vor der Freigabe der Umset-zung die erstmalige Gesamtplanung des vollständigen Umsetzungsprozesses sowie die we-sentlichen Regelungen 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, je nach Situation die Beschaffungsanalyse und die Studie mit dem Ent-scheid weiteres Vorgehen bilden die Grundlage, um den Projektmanagementplan zu erarbei-

ten. Der Projektmanagementplan ist die Voraussetzung für die Steuerung und Kontrolle des Projekts durch den Auftraggeber und für die Abstimmung des Projekts mit den Strategien

und Zielen der Stammorganisation.

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 o-

der die Qualitätssicherung der Ergebnisse und Prozesse/Aufgaben sichergestellt werden.

Der Entscheid Releasefreigabe ist beim agilen Vorgehen fakultativ. Im Projektmanagement-plan wird jedoch festgelegt, ob der Entscheid Releasefreigabe treffen im Projekt zwingend

vorgeschrieben ist oder nicht. Diese Entscheidung obliegt dem Auftraggeber. Vor der Frei-gabe der Umsetzung wird nach dem Prinzip der rollenden Planung ein Gesamtplan erstellt,

und die nachfolgende Phase, Konzept oder Umsetzung, detailliert geplant. Jeweils am Ende einer Phase bzw. eines Releases wird die nächste Phase/das nächste Release detailliert geplant

und der Gesamtplan überprüft. Dies erfolgt mit der Aufgabe Phasenfreigabe vorbereiten bzw. Releaseabschluss vorbereiten.

Derogatorische Kraft eines allfälligen Programmmanagementplans: 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 der klassischen oder agilen Vorgehensweise eines Projekts. Diese muss

zwingend für jedes einzelne Projekt individuell geprüft werden.


Stakeholderliste

Studie

Beschaffungsanalyse

Meilenstein weiteres Vorgehen

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 Prüfmethoden der Qualitätssicherung festlegen;

o Prüfverfahren für die Ergebnisse und Prozesse/Aufgaben festlegen und im Kapitel Prüfplan festhalten;

o Qualitätsziele für das Gesamtprojekt festlegen;

109 / 202

AU

FG

AB

EN

o beim agilen Vorgehen explizit festhalten, ob der Entscheid Releasefreigabe treffen zwingend vorgeschrieben ist.

Ergebnisse


3.4.3.39 Prototyping durchführen



Zweck

Mit einem Prototyp wird ein vereinfachtes, jedoch weitestgehend funktionsfähiges Testmodell eines Systems, eines Produkts oder eines Teils davon erstellt. So können die Machbarkeit

(Proof of Concept) oder Brauchbarkeit der fokussierten Lösung, allenfalls auch deren Nütz-lichkeit und Akzeptanz, geprüft werden. Nebst den technischen und funktionalen Kriterien

können insbesondere beim Produkt auch das Aussehen oder die Masse und die Proportionen, bei Dienstleistungen die visualisierte Idee begutachtet 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 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.


Studie


Aktivitäten

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

Prototyp

Prototypdokumentation

3.4.3.40 Qualitätssicherung führen



Zweck

Mit der Qualitätssicherung wird sichergestellt, dass die Ergebnisse im Projektablauf die gefor-derte Qualität aufweisen.

110 / 202

AU

FG

AB

EN

Grundidee

Grundsätzlich wird bei der Qualitätssicherung zwischen ‹Prüfen› und ‹Testen› unterschieden:

Prüfen umfasst die inhaltliche und formale Überprüfung von Ergebnissen (Dokumente)

und die Einhaltung vereinbarter Prozesse/Aufgaben;

Testen umfasst die Überprüfung der Erfüllung der Systemanforderungen 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 über das Modul Projektsteuerung mit der Aufgabe Projekt steuern.



Arbeitsauftrag

Aktivitäten

Qualitätsziele für die Projektphase bzw. das Release – abgeleitet von den Projektzielen – im Projektmanagementplan festlegen.

Prüfverfahren und Abläufe gemäss Projektmanagementplan im Arbeitsauftrag festhalten 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

3.4.3.41 Rechtsgrundlagenanalyse erarbeiten



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.

111 / 202

AU

FG

AB

EN

Grundidee

Die rechtlichen Grundlagen müssen in jedem Projekt eingehalten werden. Sie bilden eine un-verrückbare Restriktion für ein Projekt.

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.

Die Erkenntnisse aus der Rechtsgrundlagenanalyse fliessen in die Studie ein.




Stakeholderliste

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


3.4.3.42 Releaseabschluss vorbereiten



Zweck

Für den Abschluss eines Releases werden im Rahmen der agilen Vorgehensweise die Ergeb-nisse zusammengefasst und für das Reporting bereitgestellt.

Grundidee

Am Ende eines Release werden Informationen zum Projektstand und zur Prognose über das Reporting an die Projektsteuerung geliefert. Muss gemäss Projektmanagementplan Entscheid Releasefreigabe getroffen werden, werden die Informationen von den Entscheidungsträ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.



Releaseplan

112 / 202

AU

FG

AB

EN


Änderungsstatusliste

Projekterfahrungen

Aktivitäten

Nächstes Release gemäss Releaseplan identifizieren.

Gesamtplan verifizieren.

Projektmanagementplan nachführen und mit allen Beteiligten sowie den Controlling- und


Projektstatusbericht als Beilage zu Releasebericht aktualisieren.

Ergebnisse des Releases, inklusive von Änderungen, im Releasebericht zusammenfassen.

Entscheide bei der Projektsteuerung initiieren.

Ergebnisse

Releasebericht



3.4.3.43 Releaseplan erarbeiten



Zweck

In einem agil geführten Projekt schafft der an sich optionale Releaseplan die Voraussetzungen dafür, die Entwicklung in in sich abgeschlossene vollständige Lösungsteile zu gliedern und die Aktivitäten im Zusammenhang mit Releases mit den betroffenen Stellen zu koordinieren.

Grundidee

Wenn es nicht möglich ist, in einer Iteration einen vollständigen Lösungsteil zu erstellen, wird das Entwicklungsvorgehen in Releases benötigt. Ein Releaseplan umfasst mehrere Iterationen und definiert, zu welchem Zeitpunkt die Auslieferung an den Anwender erfolgt.

HERMES-spezifisch

Der Releaseplan wird auf der Basis der Lösungsanforderungen erarbeitet. Er ist eng mit dem Projektmanagementplan abgestimmt. Während der späteren sukzessiven Planung der Itera-tionen wird der Releaseplan in einzelne Iterationen heruntergebrochen.




Aktivitäten

Releaseplan erarbeiten.

Releaseplan mit Stakeholdern abstimmen.

Ergebnisse

Releaseplan


3.4.3.44 Risiken managen



Zweck

Mit dem Risikomanagement werden Risiken frühzeitig identifiziert und Massnahmen festge-

legt, um den Erfolg sicherzustellen.

113 / 202

AU

FG

AB

EN

Grundidee

Risiken sind zukünftige Ereignisse, die bei Eintreten ein Problem darstellen. Projektrisiken be-treffen den Projektablauf. Betriebsrisiken betreffen die Nutzung der Projektergebnisse.

Risiken werden identifiziert und analysiert. Abhängig von der Bedeutung eines Risikos werden die Strategie 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 Releases findet eine vertiefte Risikoüberprüfung statt, damit die Entscheidung zur

Freigabe der nächsten Phase bzw. des nächsten Releases getroffen werden kann. Die effekti-ven Risiken werden je nach Projektlauf im Phasen- bzw. Releasebericht und im Projektstatus-

bericht 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 mit dem Projektstatusbericht periodisch an die relevanten

Stellen und Personen kommunizieren.

Ergebnisse



3.4.3.45 Schutzbedarfsanalyse erarbeiten



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 Informatiksicherheit von Anfang an berücksichtigt wird.

HERMES-spezifisch

Zeigt die Schutzbedarfsanalyse, dass ein erhöhter Schutz nötig ist, muss bei der späteren Um-setzung eine vertiefte Risikoanalyse durchgeführt und ein ISDS-Konzept verfasst werden.

Die Erkenntnisse aus der Schutzbedarfsanalyse fliessen in die Studie ein.

114 / 202

AU

FG

AB

EN




Stakeholderliste

Aktivitäten

Schutzbedarfsanalyse durchführen.

Anforderungen bezüglich Informationssicherheit und Datenschutz analysieren und Aus-wirkungen auf die Studie und die Projektabwicklung beurteilen.

Schutzbedarfsanalyse mit den Controlling- und Vorgabestellen abstimmen.

Ergebnisse


3.4.3.46 Stakeholder managen und informieren



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. Dazu gehört auch das Projektmarketing.

Grundidee

Projektleiter und Auftraggeber identifizieren und analysieren die Stakeholder.

Die Interessen, Erwartungen und Ziele der betroffenen Stakeholder werden zusammengetra-gen, analysiert und auf mögliche Diskrepanzen und Konflikte untersucht. Um die Erfolgschan-cen zu erhöhen, müssen erkannte Diskrepanzen oder Konflikte bereinigt werden. Bei Bedarf

werden Entscheidungsprozesse geplant und Entscheide vorbereitet.

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.

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. Die Analyse der Stakeholderinteressen ist eine projektinterne Einschätzung und wird für die Zusammenarbeit mit den Stakeholdern benötigt.

Der institutionalisierte Informationsfluss wird im Kommunikationsplan als Teil des Projektma-nagementplans festgelegt.



Stakeholderliste

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 potentielle Projektausschussmitglieder identifizieren und dem

115 / 202

AU

FG

AB

EN

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-

onsplanung integrieren.

Ergebnisse

Stakeholderliste



3.4.3.47 Stakeholderinteressen vertreten



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 ermöglicht und sichert den Projekterfolg.

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 durch teilweise oder

fortwährende direkte Mitwirkung am Projekt als Fachspezialisten erzielt werden.

HERMES-spezifisch

Die Aufgabe obliegt grundsätzlich dem Anwendervertreter.

Die Impulse und Funktionsanforderungen der Stakeholder fliessen bei klassischen Vorgehens-weise via Änderungsmanagement ein, bei agilen Projekten über die Führung der Lösungsan-

forderungen.

Die erstmals in der Phase Initialisierung erstellten Stakeholderinteressen werden im Projekt-ablauf kontinuierlich weitergeführt und analysiert.


Stakeholderliste


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


116 / 202

AU

FG

AB

EN

3.4.3.48 Studie erarbeiten



Zweck

Mit der Studie werden Ziele, grobe Anforderungen und Varianten erarbeitet. Die Studie bildet die Grundlage für den Entscheid weiteres Vorgehen.

Grundidee

Ein Projekt muss mit der Strategie und den Zielen der Organisation übereinstimmen. Es muss die Rahmenbedingungen berücksichtigen und seine Wirtschaftlichkeit muss gewährleistet

sein.

Die Studie wird so weit konkretisiert, dass eine dem Projekt angemessene Planungsgenauig-keit für Termine, Kosten und Aufwand erreicht wird. Die Risiken und die Wirtschaftlichkeit

müssen umfassend beurteilt werden können.

HERMES-spezifisch

Die Studie wird erarbeitet, um den Umsetzungsauftrag erarbeiten zu können.

Die Ziele und Anforderungen bilden die Grundlage für die Erarbeitung von Varianten. Die

Ziele werden abschliessend festgelegt. Die Anforderungen werden so beschrieben, dass der Projektinhalt und der Projektumfang klar sind und die Beurteilungskriterien festgelegt 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 mögliche Beschaffung vorsehen, werden allfällige Erkenntnisse (z. B. aus dem Marktumfeld) aus der parallel zur Studie zwingend erstellten 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 Vorgehensart 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 6 Szenarien) ausgewählt und bei Bedarf angepasst.

Die Studie entspricht dem ‹Business-Case› und zeigt den Geschäftsnutzen sowie den Bezug zur Strategie und den Zielen der Stammorganisation.




Stakeholderliste



Beschaffungsanalyse

Aktivitäten

Standortbestimmung erarbeiten und in der Studie festhalten.

Ziele und Anforderungen erarbeiten, mit Stakeholdern abstimmen, Stakeholderliste an-

passen und in der Studie festhalten.

Zielkonflikte erkennen und mit dem Auftraggeber bereinigen.

Marktabklärungen und Informationen aus der Beschaffungsanalyse in die Studie integrie-

ren.

117 / 202

AU

FG

AB

EN

Erkenntnisse aus der Rechtsgrundlagenanalyse und der Schutzbedarfsanalyse in die Stu-

die integrieren.

Varianten einzeln beschreiben.

Beurteilungskriterien und ihre Gewichtung festlegen.

Varianten aufgrund der Beurteilungskriterien bewerten.

Auswirkung der Variantenwahl auf das Projekt beurteilen.

Passendes Szenario auswählen, allenfalls individuell weiter anpassen.

Projekt und Termine grob planen, grobe Eckpfeile (Meilensteine) definieren

Studie fertigstellen.

Studie mit Auftraggeber und Stakeholdern inklusive der Controlling- und Vorgabestellen

abstimmen.

Ergebnisse

Studie

Stakeholderliste

3.4.3.49 System aktivieren



Zweck

Das integrierte System wird aktiviert. Der Betrieb kann aktiviert werden.

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

3.4.3.50 System in Betrieb integrieren



Zweck

Die Integration des Systems in die Betriebsinfrastruktur schafft die Voraussetzungen für die Durchführung der Tests und für die Vorabnahme.

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

118 / 202

AU

FG

AB

EN

integriert. Das Testen erfolgt im Modul Tests Die Anbindungen zu Umsystemen werden akti-viert.

Es werden mehrere Integrationsschritte durchgeführt. Sie sind im Integrationsplan im Ergebnis Integrations- und Installationsanleitung festgelegt.



Testinfrastruktur realisiert

Betriebshandbuch

Betriebskonzept

Integrationskonzept

Integrations- und Installationsanleitung

System entwickelt oder parametrisiert

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 in Betriebshandbuch

hinzufügen.

Ergebnisse

Betriebshandbuch

System integriert

3.4.3.51 System realisieren



Zweck

Das System wird so weit realisiert, dass es die Lösungsanforderungen erfüllt und für die In-tegration 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 Ersteller testet das System während der Realisierung, bevor die erste Auslieferung an den Anwender und Betreiber erfolgt.

Die Tests nach der ersten Auslieferung werden mit dem Modul Tests unterstützt. Die bisher erarbeitete Dokumentation wie Lösungsarchitektur, Systemkonzept usw. wird nachgeführt

und das Anwendungshandbuch erarbeitet.



Systemkonzept

Lösungsarchitektur


119 / 202

AU

FG

AB

EN


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

Detailspezifikation

Lösungsarchitektur

Anwendungshandbuch


3.4.3.52 Systemintegration vorbereiten



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.


Integrationskonzept

Lösungsarchitektur

Betriebskonzept

Aktivitäten


Schnittstellen entwickeln.

Anpassungen an den Umsystemen koordinieren.

Integration in den Betrieb vorbereiten.

Integrations- und Installationsanleitung erstellen.

Lösungsarchitektur aktualisieren.

Ergebnisse

Schnittstellen realisiert

Lösungsarchitektur

Integrations- und Installationsanleitung

Detailspezifikation

120 / 202

AU

FG

AB

EN

3.4.3.53 Test durchführen



Zweck

Mit Tests wird die Erfüllung der an das System (beim agilen Vorgehen auch an die Inkremente) gestellten Anforderungen überprüft. Die Tests werden durchgeführt, die Testergebnisse wer-den 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.

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.

Gegebenenfalls Mängel beheben und Tests wiederholen.

Vorgehen zu offenen Punkten vereinbaren.

Ergebnisse

Testprotokoll

Testkonzept

3.4.3.54 Testinfrastruktur realisieren



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.

121 / 202

AU

FG

AB

EN

Grundidee

Die Testinfrastruktur umfasst das Testsystem, Testhilfsmittel (z. B. Testverwaltungssystem zur Sammlung und Bewertung der Ergebnisse) und die Testdaten.

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


Aktivitäten

Testinfrastruktur gemäss Testkonzept bereitstellen.

Qualität der Testinfrastruktur sicherstellen.

Testinfrastruktur für die Tests freigeben.

Ergebnisse


3.4.3.55 Testinfrastruktur überführen



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.


Meilenstein Abnahme

Testkonzept

Aktivitäten

Testkonzept mit Testfallbeschreibungen sowie Testdaten bereinigen bzw. mit Erkenntnis-

sen aus den Tests aktualisieren.

Zuständige informieren und ausbilden.

Übergabe formal vornehmen.

Übergabe protokollieren.

Ergebnisse

Testkonzept

Testinfrastruktur überführt

Protokoll

122 / 202

AU

FG

AB

EN

3.4.3.56 Testkonzept erarbeiten



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.

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 Test Konzept 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

Migrationskonzept

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

3.4.3.57 Umsetzungsauftrag erarbeiten



Zweck

Mit der Erarbeitung des Umsetzungsauftrags werden die Voraussetzungen dafür geschaffen, den Entscheid Umsetzungsfreigabe zu fällen.

Grundidee

Der Umsetzungsauftrag ist die verbindliche Vereinbarung zwischen Auftraggeber und Pro-jektleiter für die gesamte restliche Projektdauer bis zum Projektabschluss. Er basiert auf einer

nachvollziehbaren Projektplanung. Auf der Grundlage des erarbeiteten Umsetzungsauftrages überprüft der Auftraggeber, ob das Projekt den Zielen der Organisation dient und ob die

nötigen Ressourcen freigegeben werden können.

123 / 202

AU

FG

AB

EN

HERMES-spezifisch

Der Projektmanagementplan oder je nach Situation die Beschaffungsanalyse und die Studie bilden die Grundlage, um den Umsetzungsauftrag zu erarbeiten. Umsetzungsauftrag und Pro-

jektmanagementplan sind Voraussetzung für die Steuerung und Kontrolle des Projekts durch den Auftraggeber und die Abstimmung des Projekts mit den Strategien und Zielen der Stam-

morganisation.


Studie


Beschaffungsanalyse

Aktivitäten

Relevante Ergebnisse aus der Studie, der Beschaffungsanalyse und dem Projektmanage-

mentplan in den Umsetzungsauftrag übernehmen.

Umsetzungsauftrag mit Auftraggeber und Stakeholdern inklusive der Projektpartner und

der Controlling- und Vorgabestellen verifizieren.

Ergebnisse

Umsetzungsauftrag

3.4.3.58 Vereinbarung erarbeiten



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) regeln die Zu-sammenarbeit zwischen den verschiedenen Projektbeteiligten wie Anwender (Auftraggeber), Ersteller und Betreiber und/oder zwischen unterschiedlichen Projektphasen.

HERMES-spezifisch

Diese Aufgabe steht in Beziehung zur Aufgabe Leistungen vereinbaren und steuern. Mit ihr wird der Vertrag abgeschlossen und die Leistung gesteuert.

Für den Vertragsvollzug kann die Vereinbarung in einem informatikbasierten Vertragsma-nagementtool erfasst werden. In diesem Tool können allfällige weitere Informationen (bspw.

involvierte Personen, Termine, usw.) zum Vertrag hinterlegt werden. Nach Abschluss der Ver-einbarung werden die Leistungen periodisch auf Übereinstimmung mit der Planung und den

Vereinbarungen hin überprüft. In HERMES wird dies in der Aufgabe Leistungen vereinbaren und steuern abgewickelt.




Angebot


Aktivitäten

Vereinbarung erarbeiten.

Vereinbarung durch die Stammorganisation bzw. Controlling- und Vorgabestellen prüfen

lassen.

Vertragsvollzug sicherstellen.

124 / 202

AU

FG

AB

EN

Ergebnisse

Vereinbarung

125 / 202

MO

DU

LE

4 Module

4.1 Einleitung

Die HERMES Projektmanagement Module enthalten thematisch zusammengehörende Aufga-ben und Ergebnisse. Sie sind wiederverwendbare Bauklötze zur Erstellung von ganzen Pro-jekten.

Die Abbildung 17 zeigt im Gesamtkontext alle HERMES Module, die für die Erstellung der Pro-jekte verwendet werden können und teils sogar verwendet werden müssen. Ergänzend kön-

nen die Anwender fach-, organisations- oder vorhabenspezifische Module erstellen.

Beschaffung

Steuerung Projektsteuerung

Projektführung

Ausführung

Führung

Tests


IT-Migration

IT-Betrieb

ISDS

agil

klassisch

Umsetzung



Organisation

Projektgrundlagen

IT-System

Produkt

Abbildung 17: Standardmässig verfügbare HERMES Module im Gesamtkontext

4.2 Module-Übersicht

4.2.1 Standardmodule

Die folgenden Module sind in HERMES 2021 Projektmanagement standardmässig verfügbar. Die Tabelle führt alle Module kontextgerecht auf und zeigt, in welchen Projektphasen sie vor-

kommen können.

Projektphase

Modul

klassisch agil

Init

ialisi

e-

run

g

Ko

nze

pt

Realisi

e-

run

g

Ein

füh

run

g

Um

setz

un

g

Ab

sch

luss

Projektsteuerung X X X X X X

Projektführung X X X X X X

Projektgrundlagen X

Beschaffung X X X X

Organisation X X X X

Produkt X X X X

IT-System X X X X

Tests X X X X X

126 / 202

MO

DU

LE

Projektphase

Modul

klassisch agil

Init

ialisi

e-

run

g

Ko

nze

pt

Realisi

e-

run

g

Ein

füh

run

g

Um

setz

un

g

Ab

sch

luss

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 5: Standardmässig mit HERMES verfügbare Module

Einige Module müssen in HERMES zwingend in jedem Projekt vorkommen, damit die Gover-nance eingehalten werden kann. Es sind dies die Module:

Projektsteuerung;

Projektführung;

Projektgrundlagen.

4.2.2 Individuelle Module

Ergänzend zu den standardmässig verfügbaren Modulen besteht die Möglichkeit, eigene fachspezifische Module zu entwickeln und diese in eigene Projekte zu integrieren. Dies wird durch HERMES online unterstützt. Beispiele von fachspezifischen individuellen Modulen, die

selbst entwickelt werden können:

Marketing

Kommunikation

Personalentwicklung

Rechtsetzung

Ausbildung

Strategieentwicklung

Einführung Geschäftsverwaltung

4.3 Erläuterung der Modulbeschreibung

Für jedes Modul gibt es eine Modulbeschreibung, die stets gleich strukturiert ist:

Was ist zu tun

Umschreibung der Modulaufgaben im Gesamtkontext des Moduls.

Aufgaben und Ergebnisse

Tabellarische Auflistung o der Modulaufgaben im Gesamtkontext, wobei die Entscheidungsaufgaben farblich

(pink) hervorgehoben sind; o der aus den Aufgaben abgeleiteten oder durch die Aufgaben angepassten, den ent-

sprechenden Projektphasen zugeordneten Ergebnisse.

4.4 Modul-Verzeichnis

4.4.1 Management Module

4.4.1.1 Projektsteuerung

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.

Das Projekt abschliessen, eventuell vorzeitig abbrechen.

127 / 202

MO

DU

LE

Aufgaben und Ergebnisse Aufgabe

Ergebnis

Phasen

I K R E U A

Entscheid Projektinitialisierungsfreigabe treffen Checkliste Projektinitialisierungsfreigabe X

Projektinitialisierungsauftrag X

Meilenstein Projektinitialisierungsfreigabe X


Entscheid Umsetzungsfreigabe treffen Checkliste Umsetzungsfreigabe X

Umsetzungsauftrag X

Meilenstein Umsetzungsfreigabe 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


Meilenstein Phasenfreigabe X X


Entscheid Releasefreigabe treffen Checkliste Releasefreigabe 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 6: Aufgaben und Ergebnisse Modul Projektsteuerung

4.4.1.2 Projektführung

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, die Kommunikation führen.

Entscheide sicherstellen.

Risiken managen, Probleme bewältigen und Erfahrungen berücksichtigen.

Leistungen vereinbaren und steuern, das Änderungsmanagement und die Qualitätssiche-

rung führen.


Ergebnis

Phasen

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

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

128 / 202

MO

DU

LE

Aufgabe

Ergebnis

Phasen

I K R E U A

Umsetzungsauftrag erarbeiten Umsetzungsauftrag X

Änderungen managen Änderungsantrag X X X

Änderungsstatusliste X X X X


Lösungsanforderungen X 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

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


Phasenfreigabe vorbereiten Phasenbericht X X X X



Releaseabschluss vorbereiten Releasebericht X


Projektstatusbericht X

Projektabschluss vorbereiten Projekterfahrungen X

Projektschlussbeurteilung X

Tabelle 7: Aufgaben und Ergebnisse Modul Projektführung

4.4.2 Fachmodule

4.4.2.1 Projektgrundlagen

Was ist zu tun

Die Studie erarbeiten, damit der Entscheid weiteres Vorgehen gefällt werden kann.

Die Rechtsgrundlagen klären und den Schutzbedarf analysieren.

Ist eine Beschaffung mit anschliessender Adaption geplant, wird eine Beschaffungsanalyse

durchgeführt.

Die Voraussetzungen schaffen, um den Projektmanagementplan und den Umsetzungs-auftrag zu erarbeiten.


Ergebnis Phasen

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 X

Prototypdokumentation X

Entscheid weiteres Vorgehen treffen Checkliste weiteres Vorgehen X

Studie X

Meilenstein weiteres Vorgehen X

Liste Projektentscheide Führung X

Tabelle 8: Aufgaben und Ergebnisse Modul Projektgrundlagen

129 / 202

MO

DU

LE

4.4.2.2 Beschaffung

Was ist zu tun

Beschaffung mit offenem oder selektivem Verfahren und öffentlicher Publikation, alle an-

deren Fälle von Beschaffungen werden über das Modul Projektführung abgewickelt.

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 in der Phase Ini-

tialisierung statt.

Die eigentliche Beschaffung findet je nach Bedarf wenn möglich während der Lösungs-

entstehung statt.

Die Beschaffung endet spätestens vor der Freigabe der Phase Abschluss.

Bei einer Produkt- oder Systemadaption ist zu berücksichtigen, dass alle Anpassungen

und Parametrisierungen ruhen, bis die Beschaffung abgeschlossen ist.

Bei reinen Beschaffungsprojekten endet das Projekt im Prinzip bereits mit dem Umset-zungsauftrag. Dennoch kann für die eigentliche Beschaffung zwecks methodischer Unter-

stützung das Modul Beschaffung genutzt werden.


Ergebnis

Phasen

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 9: Aufgaben und Ergebnisse Modul IT- Beschaffung

4.4.2.3 Organisation

Was ist zu tun

Geschäftsorganisation mit Geschäftsmodellaspekten, Aufbau- und Ablauforganisation neu konzipieren oder verändern, realisieren und einführen.

In einem eigenständigen Organisationsprojekt wird das Modul in der Regel klassisch ab-gewickelt. Wird das Modul jedoch begleitend zu einer agilen Lösungsentstehung benötigt,

richten sich Aufgabendurchführung und die Erarbeitung der Ergebnisse nach dem suk-zessiven agilen Ablauf.

Die Interessen der Stakeholder kennen und sie an der Lösungsentstehung mitwirken las-

sen.

Aufgaben und Ergebnisse Aufgabe Ergebnis Phasen

I K R E U A

Organisationsanforderungen erarbeiten Situationsanalyse X X

Organisationsanforderungen X X


Organisationskonzept erarbeiten Organisationskonzept X X

Geschäftsmodellbeschreibung X X



Organisation umsetzen Geschäftsmodellbeschreibung X X

130 / 202

MO

DU

LE

Aufgabe Ergebnis Phasen

I K R E U A



Organisation umgesetzt X X

Organisation aktivieren Organisation aktiviert X X

Tabelle 10: Aufgaben und Ergebnisse Modul Organisation

4.4.2.4 Produkt

Was ist zu tun

Das Produktkonzept erarbeiten und das Produkt erstellen oder beschaffen.


sen.


I K R E U A







Protokoll X


Produktkonzept erarbeiten Produktkonzept X X

Prototyping durchführen Prototyp X X X

Prototypdokumentation X X X

Entscheid Produktkonzept treffen Checkliste Produktkonzept X X

Meilenstein Produktkonzept X X


Produkt realisieren Detailspezifikation X X

Produktdokumentation X X


Produkt entwickelt oder angepasst X X

Produkt aktivieren Produkt aktiviert X X


Tabelle 11: Aufgaben und Ergebnisse Modul Produkt

4.4.2.5 IT-System

Was ist zu tun

Das System realisieren bzw. integrieren und dokumentieren.

Die Lösungsanforderungen verfeinern, die Lösungsarchitektur erarbeiten und die Mach-

barkeit überprüfen (Proof of Concept, allenfalls mit Prototypen).

Die Detailspezifikation erarbeiten und das System und die Integration realisieren.


sen.


I K R E U A







131 / 202

MO

DU

LE


I K R E U A


Protokoll X


Lösungsarchitektur erarbeiten Systemkonzept X X


Prototyping durchführen Prototyp 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



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 12: Aufgaben und Ergebnisse Modul IT-System

4.4.2.6 Tests

Was ist zu tun

Das Testen konzipieren, vorbereiten, durchführen und dokumentieren.


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 13: Aufgaben und Ergebnisse Modul Tests

4.4.2.7 Einführungsorganisation

Was ist zu tun

Organisatorische Aufgaben und Massnahmen durchführen, um den Übergang vom alten zum neuen Zustand zu unterstützen.

Vorabnahme und Abnahme durchführen.

Organisations-Change-Management durchführen.


I K R E U A

Einführungskonzept erarbeiten Einführungskonzept X X

Einführung realisieren Einführungsmassnahmen realisiert X X

Entscheid Vorabnahme treffen Checkliste Vorabnahme X X


Meilenstein Vorabnahme X X


Einführung durchführen Einführungsmassnahmen durchgeführt X X

132 / 202

MO

DU

LE


I K R E U A

Entscheid Betriebsaufnahme treffen Checkliste Betriebsaufnahme X X

Meilenstein Betriebsaufnahme X X


Entscheid Abnahme treffen Checkliste Abnahme X X


Meilenstein Abnahme X X


Tabelle 14: Aufgaben und Ergebnisse Modul Einführungsorganisation

4.4.2.8 IT-Migration

Was ist zu tun

Ein System ablösen.

Die IT-Migration konzipieren, planen, vorbereiten und durchführen.

Das Altsystem ausser Betrieb setzen.


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 15: Aufgaben und Ergebnisse Modul IT-Migration

4.4.2.9 IT-Betrieb

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 16: Aufgaben und Ergebnisse Modul IT-Betrieb

133 / 202

MO

DU

LE

4.4.2.10 ISDS

Was ist zu tun

Anforderungen der Sicherheit und des Datenschutzes ermitteln, Risiken bewerten und Massnahmen zur Erfüllung der Anforderungen konzipieren und umsetzen.

Das ISDS-Konzept erarbeiten und die Ergebnisse laufend dokumentieren.


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 17: Aufgaben und Ergebnisse Modul ISDS

134 / 202

RO

LLEN

5 Rollen

5.1 Einleitung

5.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 (stand-alone projects) und Projekten, die in einem Programm einge-

bettet sind.

Das Rollenmodell unterscheidet zwischen den Rollen der Stammorganisation und den Rollen der Projektorganisation. Die Abbildung 18 zeigt eine minimale Projektorganisation der klas-

sisch und agil geführten Projekte mit den Rollen Auftraggeber, Projektleiter und Anwender-vertreter bzw. Auftraggeber, Projektleiter und der Gruppenrolle Entwicklungsteam, bestehend

aus den Rollen Anwendervertreter, Iterationsleiter und Entwickler, vertreten durch den An-wendervertreter. Nach Bedarf werden weitere Rollen verwendet.

Stammorganisation

LeitungKompetenzzentrumProjektmanagement

Controlling- und Vorgabestellen


Auftraggeber

Projektleiter

Anwender-vertreter

Steuerung

Führung

Ausführung


Auftraggeber

Projektleiter

Steuerung

Führung

AusführungEntwicklungsteam

Anwender-vertreter

Iterations-leiter Entwickler

Abbildung 18: Klassisches und agiles Beispiel einer minimalen Projektorganisation

5.1.2 Stammorganisation

Die Stammorganisation ist die Organisation des Auftraggebers und des Anwenders, in der

das Projekt angesiedelt ist. Sie ist eine rechtliche Einheit, die Strategien und Vorgaben für Projekte bestimmt. Die Stammorganisation stellt die benötigten Ressourcen wie z. B. Infra-

struktur, Finanzen und Personal für das Projekt zur Verfügung. Beispiele von Stammorganisa-tionen sind die Bundesverwaltung, eine Kantonsverwaltung, eine Stadtverwaltung, ein Verein,

eine Unternehmung.

Wie die Abbildung 18 zeigt, sind für alle Projekte in der Stammorganisation drei permanente Rollengruppen relevant:

Leitung Projektportfolio aus strategischer Sicht steuern, Projekte priorisieren und Infrastruktur so-

wie personelle und finanzielle Ressourcen dem konkreten Projekt zuweisen.

Kompetenzzentrum Projektmanagement

Methoden, Hilfsmittel, Coaching und weitere Leistungen für das Projekt- und Programm-

management bereitstellen. Diese Funktion wird auch als Project Management Office (PMO) bezeichnet.

135 / 202

RO

LLEN


Vorgaben definieren und die Einhaltung aus Sicht der gesamten Organisation prüfen. Sol-

che Stellen sind beispielsweise die Finanzkontrolle, die Revisionsstelle, das IT-Controlling, die Architektur und die Stellen für Informationssicherheit und Datenschutz.

Je nach Stammorganisation sind die Rollen der aufgeführten Rollengruppen unterschiedlich ausgeprägt. In HERMES sind sie daher nicht weiter beschrieben.

5.1.3 Projektorganisation

5.1.3.1 Übersicht

Die Projektorganisation ist eine temporäre Organisation, die in enger Beziehung zur Stam-morganisation steht. Sie wird mit dem Projektinitialisierungsauftrag in Kraft gesetzt, mit dem

Umsetzungsauftrag den Projektanforderungen angepasst und mit dem Entscheid Projektab-schluss aufgelöst.

Im Verlauf der Projektabwicklung wird die Projektorganisation kontinuierlich an die Bedürf-nisse des Projekts angepasst. Je nach Projektablauf stossen weitere Partner dazu. Beispiels-

weise steht ein externer Anbieter eines Produkts erst nach der Beschaffung fest und wird dann Teil der Projektorganisation. Die agile Projektorganisation hat wiederum ihre Gültigkeit aus-

schliesslich während der Phase Umsetzung. In den Phasen Initialisierung und Abschluss bleibt die Projektorganisation klassisch, was jedoch das Projektteam nicht daran hindert, für geeig-

nete Aufgaben agile Methoden einzusetzen (vgl. Kapitel 1.4.1.1. Initialisierung).

Die Projektorganisation besteht aus verschiedenen Rollen. Sie regeln Aufgaben, Kompetenzen und Verantwortung der Projektbeteiligten. Jede Rolle ist mit einer Rollenbeschreibung spezi-

fiziert.

5.1.3.2 Hierarchieebenen

Jede Rolle ist einer der Hierarchieebenen Steuerung, Führung oder Ausführung zugeordnet:

Steuerungsrollen Projekt gesamthaft, organisationsübergreifend steuern und sicherstellen, dass die Projekt-

ziele erreicht werden.

Führungsrollen

Projektgrundlagen erarbeiten, Projekt und Mitarbeitende führen, Projekt abschliessen.

Ausführungsrollen Projektergebnisse erarbeiten und qualitätssichernde Massnahmen durchführen.

Die Abbildung 19 zeigt die Zuordnung der Rollen zu den gelb dargestellten Hierarchieebenen in einer typischen klassischen und agilen Projektorganisation.


Projektausschuss

Qualitäts- undRisikomanager

Auftraggeber

Entwicklungsteam

Fachspezialist

IterationsleiterAnwender-vertreter

ProjektleiterFührung

Steuerung

Ausführung


Projektausschuss

Qualitäts- undRisikomanager

Auftraggeber

Projekt-unterstützung

Fachausschuss

Entwickler

Projekt-unterstützung

Fachspezialist

Anwender-vertreter

Projektleiter

Entwickler

Abbildung 19: Rollenzuordnung zu Hierarchieebenen einer klassischen oder agilen Projektorganisation

136 / 202

RO

LLEN

5.1.3.3 Partnergruppen

Jede Rolle ist einer oder mehreren Partnergruppen zugeordnet. In der HERMES Projektorga-nisation sind die Partner Anwender, Ersteller und Betreiber vertreten:

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/das System bzw. die Lösung ab.

Ersteller Der Ersteller als Dienstleistungserbringer entwickelt oder liefert und integriert die Lösung.

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 Abbildung 20 zeigt schematisch, dass jeder Rolleninhaber die Sicht seiner Partnergruppe im Projekt zu vertreten hat.

Anwender

BetreiberErsteller

Abbildung 20: Die Sicht der Rolleninhaber im Projekt

Die am Projekt beteiligten Partner werden in der Praxis oft durch Lieferanten oder externe Dienstleister unterstützt. Insbesondere die Rollen der Partnergruppe Ersteller werden oft di-

rekt durch externe Dienstleister besetzt und sind dann im Projekt den internen Erstellern gleichgestellt. Werden diverse Dienstleistungen der Stammorganisation outgesourcet, kön-

nen zum Beispiel auch die Betreiber, in seltenen Ausnahmefällen sogar die Anwender, externe Dienstleister sein. Dessen ungeachtet haben die Rolleninhaber stets und ausschliesslich die

Rollensicht ihrer Partnergruppe zu vertreten, um jegliche Interessenkonflikte auszuschliessen. Dies ist insbesondere dann von Bedeutung, wenn bspw. mangels Anwenderkompetenz oder

ungenügenden Projektressourcen bestimmende Rollen des Projekts durch interne IT-Fach-leute anderer Partnergruppen wahrgenommen werden.

Die Beschaffung der Leistungen und die Integration ins Projekt erfolgen in der Verantwortung der jeweiligen Partnergruppe der Anwender, Ersteller oder Betreiber.

5.1.3.4 Projekterollen in Programmen

Programme

Programme umfassen mehrere Projekte (s. Abbildung 21), die ein gemeinsames Ziel verfolgen und zeitlich überlappt durchgeführt werden. Das Programm sichert die projektübergreifende Steuerung und Führung der Projekte. Das HERMES Phasenmodell erleichtert die Koordination

und Steuerung der Projekte in einem Programm.

137 / 202

RO

LLEN

Programminitialisierung Programmdurchführung Programmabschluss

Projekt 2

Projekt 3

Projekt 4

Projekt 1 AbschlussEinführungRealisierungKonzeptInitialisierung


Projekt n



Projekt 5 AbschlussEinführungRealisierungKonzeptInitialisierung


Abbildung 21: Projekte können zu Programmen zusammengefasst werden

Der Programmauftraggeber steuert das Programm. Der Programmleiter führt das Programm und koordiniert die projektübergreifenden Aspekte und die Abhängigkeiten zwischen den Projekten. Der Projektleiter führt sein Projekt. Der Anwendervertreter definiert das Produkt

bzw. 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.

Beim Abschluss des Programms wird ein vorheriger Abschluss jedes einzelnen Projekts samt

Auflösung der jeweiligen Projektorganisation vorausgesetzt.

Organisationsformen

Wird ein Projekt Teil eines Programms, muss die Projektorganisation in die Programmorgani-sation integriert werden. Dazu sind einige Anpassungen der Projektorganisation bzw. ihrer

Rollen notwendig. Sie betreffen vorwiegend die Rollen des Auftraggebers und des Projektlei-ters, die angepasst oder ersetzt werden. Aus Projektsicht ändert sich dennoch wenig, die Aus-

wirkungen spielen sich vorwiegend im Steuerungs-, Führungs- und Kontrollbereich ab.

Die Darstellung in der Abbildung 22 zeigt schematisch drei denkbare Organisationsformen, eine als eigenständiges Projekt und zwei als Teile eines Programms. Minimal zu besetzende

Rollen im Projekt sind grau dargestellt. Programmspezifische Rollen sind blau umrandet und werden hier nicht weiter erläutert.

Projekt

Programm-auftraggeber

Programm-koordinator

Auftraggeber

Projektleiter

Anwendervertreter

Programmorganisation 1 Programmorganisation 2

Programm-auftraggeber

Programmleiter

Projekt

Projektleiter

Anwendervertreter

Steuerung

Führung

AusführungAusführung

Projektorganisation

Führung

SteuerungAuftraggeber

Projektleiter

Anwendervertreter

Stammorganisation

Projekt

Abbildung 22: Drei mögliche Grundvarianten der Projektorganisation

Die nachfolgende Beschreibung der drei in der Abbildung 22 dargestellten Organisationsfor-men zeigt das Ganze aus Sicht der Projekte, sie ist rudimentär und dient lediglich dem Allge-meinverständnis.

138 / 202

RO

LLEN

Projektorganisation

Eine Organisationseinheit oder eine Stammorganisation ist verantwortlich für 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 Organisationseinheiten oder Stammorganisationen sind verantwortlich für den Er-folg der ihnen zugeordneten Projekte:

der Auftraggeber ist verantwortlich für den Erfolg des Projekts und steuert das Projekt im

Auftrag des Programmauftraggebers;

der Projektleiter führt das Projekt im Auftrag des Auftraggebers;


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 Einsatz des Projektleiters wird durch den Programmkoordinator

bestimmt.

Programmorganisation 2

Eine Stammorganisation ist verantwortlich für den Erfolg des Programms und aller daran be-teiligten Projekte:

der Programmleiter führt quasi als Auftraggeber (Rollenbeschreibung Auftraggeber) die Projektleiter und agiert in den Projekten, die Verantwortung für den Projekterfolg obliegt

hingegen dem Programmauftraggeber;

der Projektleiter führt das Projekt im Auftrag des Programmleiters;


Diese Art der Programmorganisation verzichtet auf den Auftraggeber und ersetzt ihn durch den Programmleiter. Er übernimmt wie der Auftraggeber alle Aufgaben und Pflichten inner-

halb eines Projekts. Der Projektleiter ist somit einem Programmleiter unterstellt, der in der Projektorganisation der Hierarchieebene Steuerung, in der Programorganisation der Ebene

Führung zugeordnet ist.

5.2 Rollenübersicht

5.2.1 Standardrollen

Die Tabelle gibt eine Übersicht der Rollen, die HERMES standardmässig zur Verfügung stellt. Sie zeigt zudem die Zuordnung jeder Rolle zur Hierarchieebene und zur Partnergruppe und enthält die in einer Projektorganisation minimal zu besetzende Rollen Auftraggeber, Projekt-

leiter und Anwendervertreter. Diese sind zwingend durch die Partnergruppe Anwender zu besetzen. Hierarchieebene Rolle Anwender Ersteller Betreiber

* = minimal zu besetzende Rollen

Steuerung Steuerungsrollen X X X

Auftraggeber* X

Projektausschussmitglied X X X

Qualitäts- und Risikomanager X

Führung Führungsrollen X X X

Projektleiter* X

Teilprojektleiter X X X

Projektunterstützung X X

Fachausschussmitglied X X X

139 / 202

RO

LLEN

Hierarchieebene Rolle Anwender Ersteller Betreiber

* = minimal zu besetzende Rollen

Ausführung Ausführungsrollen X X X

Anwendervertreter* X

Anwendungsverantwortlicher X

Betriebsverantwortlicher X

Business Analyst X X

Entwickler X

Entwicklungsteam X X X

Geschäftsprozessverantwortlicher X

ISDS-Verantwortlicher X

Iterationsleiter X

IT-Architekt X X X

Tester X X X

Testverantwortlicher X X X

Tabelle 18: Übersicht der Rollen und deren Zuordnung zur Hierarchieebene und zum Partner

Die Ausführungsrollen, in Organigrammen summarisch auch als Fachspezialisten genannt, sind zahlreich und im HERMES nicht abschliessend aufgeführt. Je nach Stammorganisation,

oder der Art eines Vorhabens können weitere individuelle Ausführungsrollen dazukommen.

Bei agiler Vorgehensweise werden während der Umsetzungsphase die Ausführungsrollen, so-

fern sie intensiv an der Lösung beteiligt sind, im Entwicklungsteam zusammengefasst. Sie kön-nen aber bei Bedarf das Entwicklungsteam auch als eigenständige beratende Rolle begleiten,

zum Beispiel als Geschäftsprozessverantwortliche. Die Rolle Entwicklungsteam ist eine Grup-penrolle, die zum Beispiel in Tabelle 18 de facto zu Doppelnennungen führt: einmal als kon-

krete Ausführungsrolle und einmal als Mitglied des Entwicklungsteams.

5.2.2 Erläuterungen zur Rollenbesetzung

Für jede im Projekt benötigte Rolle wird die Rollenbesetzung festgelegt.

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 Governance eingehalten werden kann:

Die Rollen Auftraggeber, Projektleiter und Anwendervertreter müssen in jedem Projekt

besetzt sein (vgl. Tabelle 18). Weitere Rollen werden abhängig von den Projekt-Anforde-

rungen zugewiesen.

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 für einige Rollen aufgeführt.

5.2.3 Hinweise zur Rollenbesetzung

5.2.3.1 Steuerung

Auftraggeber

Der Auftraggeber muss beim Anwender angesiedelt 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.

140 / 202

RO

LLEN

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 Projektausschussmitglieder 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.

5.2.3.2 Führung

Projektleiter

Der Auftraggeber bestimmt den Projektleiter.

Der Projektleiter muss beim Anwender angesiedelt sein.

Der Projektleiter führt das Projekt und verantwortet den reibungslosen Projektablauf.

Übernimmt der Projektleiter zusätzlich eine Ausführungsrolle, muss durch den Auftragge-

ber sichergestellt werden, dass dennoch genügend Kapazität für die Projektleitung zur Verfügung steht.

Teilprojektleiter

Jeder Partner (Anwender, Ersteller, Betreiber) stellt einen Verantwortlichen, der die Arbei-ten in seinem Bereich plant und führt. Dieser kann die Rolle des Teilprojektleiters wahr-

nehmen.

Der Teilprojektleiter des Anwenders kann zugleich Projektleiter sein.

5.2.3.3 Ausführung

Anwendervertreter

Der Auftraggeber bestimmt den Anwendervertreter.

Der Anwendervertreter muss beim Anwender angesiedelt sein.

Der Anwendervertreter verantwortet die fachliche Ausgestaltung der Lösung.

Übernimmt der Anwendervertreter zusätzlich eine Ausführungsrolle, muss durch den Auf-

traggeber sichergestellt werden, dass dennoch genügend Kapazität für die Anwenderver-

tretung zur Verfügung steht.

Business Analyst

Der Business Analyst kann in kleineren Projekten zusätzlich die Rolle des Projektleiters

oder des anwenderseitigen Teilprojektleiters übernehmen, sofern er das Anforderungs-profil erfüllt und über die benötigte Arbeitskapazität verfügt.

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

Jeder Partner (Anwender, Ersteller, Betreiber) testet in seinem Verantwortungsbereich.

Testverantwortlicher

Jeder Partner (Anwender, Ersteller, Betreiber) kann in seinem Verantwortungsbereich ei-nen Testverantwortlichen einsetzen.

Der Anwender kann das Testmanagement an einen der Projektpartner delegieren. Die Gesamtverantwortung für das Projektergebnis bleibt jedoch bei ihm.

141 / 202

RO

LLEN

5.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 die Verantwortung der Rolle.

Kompetenzen

Beschreiben die Befugnisse der Rolle.

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

Zeigen pro Modul, sofern zutreffend, für welche konkreten Aufgaben die Rolle verant-

wortlich ist und welche weiteren Rollen an der Ergebniserstellung beteiligt sind. o Die für die Aufgabe verantwortliche Rolle trägt auch die Verantwortung für die Erar-

beitung 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.

5.4 Rollenverzeichnis

5.4.1 Steuerungsrollen

5.4.1.1 Auftraggeber

Beschreibung

Der Auftraggeber ist verantwortlich für die Entstehung der Lösung, für die Ergebnisse des Projekts und die Erreichung der Ziele innerhalb der gesetzten klassischen oder agilen Rah-

menbedingungen. Der Auftraggeber ist immer eine einzelne natürliche Person aus der Stam-morganisation. Bei agiler Durchführung ist er einem Business Owner gleichzusetzen, seine

Aufgaben und Kompetenzen gehen aus Projektmanagement Sicht jedoch weiter als die eines Business Owners.

Verantwortung

Initiieren und Steuern des Vorhabens

Gesamtverantwortung für das Vorhaben und das Erreichen der Ziele

Abstimmung der Projektziele 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 und Führen des Projektausschusses

Bestimmen und Steuern des Projektleiters

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

142 / 202

RO

LLEN

Fähigkeiten

Geschäftsverständnis und Kenntnisse im Fachbereich

Kenntnisse der Vorgaben der Stammorganisation an das Projekt und des Betriebs (z. B. für Beschaffungen, Finanzierung, Controlling, Sicherheit)

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

Beziehungen Modul Aufgabe Ergebnis Beteiligt an der

Ergebniserstellung

Projektsteuerung Entscheid Projektinitiali-sierungsfreigabe treffen

Checkliste Projektinitiali-sierungsfreigabe

Auftraggeber, Projektleiter

Projektinitialisierungsauf-trag


Meilenstein Projektinitia-lisierungsfreigabe




Entscheid Umsetzungs-freigabe treffen

Checkliste Umsetzungs-freigabe


Umsetzungsauftrag Auftraggeber, Projektleiter, Anwendervertreter, Ge-schäftsprozessverantwortlicher

Meilenstein Umsetzungs-freigabe

Auftraggeber, Projektleiter, Projektausschussmit-glied, Qualitäts- und Risikomanager



Projekt steuern QS- und Risikobericht

Auftraggeber, Qualitäts- und Risikomanager



Entscheid Phasenfrei-gabe treffen

Checkliste Phasenfrei-gabe


QS- und Risikobericht Auftraggeber, Qualitäts- und Risikomanager

Meilenstein Phasenfrei-gabe

Auftraggeber, Projektleiter, Projektausschussmit-glied, Anwendervertreter, Qualitäts- und Risikoma-nager



Entscheid Releasefrei-gabe treffen

Checkliste Releasefrei-gabe

Auftraggeber, Projektleiter, Anwendervertreter


Meilenstein Releasefrei-gabe




Entscheid Projektabbruch treffen

Checkliste Projektab-bruch

Auftraggeber, Projektleiter, Anwendervertreter

Projekterfahrungen Auftraggeber, Projektleiter, Anwendervertreter

Projektschlussbeurtei-lung


Meilenstein Projektab-schluss

Auftraggeber, Projektleiter, Anwendervertreter, Projektausschussmitglied, Qualitäts- und Risikoma-nager



Entscheid Phasenfrei-gabe Abschluss treffen

Checkliste Phasenfrei-gabe Abschluss



143 / 202

RO

LLEN

Modul Aufgabe Ergebnis Beteiligt an der Ergebniserstellung

Meilenstein Phasenfrei-gabe Abschluss




Entscheid Projektab-schluss treffen

Checkliste Projektab-schluss







Beschaffung Entscheid Ausschreibung treffen

Checkliste Ausschreibung Auftraggeber, Projektleiter, Anwendervertreter

Meilenstein Ausschrei-bung




Entscheid Zuschlag treffen

Checkliste Zuschlag Auftraggeber, Projektleiter, Anwendervertreter

Publikation Auftraggeber, Projektleiter

Meilenstein Zuschlag Auftraggeber, Projektleiter, Projektausschussmit-glied, Anwendervertreter, Qualitäts- und Risikoma-nager



Einführungsorga-nisation

Entscheid Betriebsauf-nahme treffen

Checkliste Betriebsauf-nahme


Meilenstein Betriebsauf-nahme




Tabelle 19: Aufgaben, die der Auftraggeber verantwortet, und andere an der Aufgabe beteiligte Rollen

5.4.1.2 Projektausschussmitglied

Beschreibung

Der Projektausschuss unterstützt den Auftraggeber in seinen Aufgaben. Die Mitglieder des Projektausschusses bringen die Anliegen der Organisation ein, die sie vertreten. Der Auftrag-

geber 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

Fähigkeiten

Kenntnisse im Fachbereich

Vertiefte Kenntnisse im Spezialgebiet, das vertreten wird

144 / 202

RO

LLEN

Betriebswirtschaftliche Kenntnisse zur Sicherstellung des effizienten und effektiven Einsat-

zes der finanziellen und personellen Ressourcen

Vertiefte Kenntnisse in der Projektsteuerung

Kenntnisse von HERMES, nachgewiesen durch einen Kursbesuch

Team-, Kommunikations- und Konfliktlösungsfähigkeit

5.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 Projektziele

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 Projektpartnern

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 Projekt-

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 direktem 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

5.4.2 Führungsrollen

5.4.2.1 Fachausschussmitglied

Beschreibung

Beim klassischen Vorgehen unterstützt der Fachausschuss den Projektleiter durch die Beurtei-lung von Ergebnissen.

Die Mitglieder des Fachausschusses bringen die Anliegen der Organisationseinheit ein, die sie vertreten. Der Projektleiter organisiert und leitet die Sitzungen des Fachausschusses.

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

145 / 202

RO

LLEN

Kompetenzen

Gibt Empfehlungen zu Ergebnissen zuhanden des Projektleiters ab.

Gibt Empfehlungen zu qualitätssichernden Massnahmen zuhanden des Projektleiters ab.

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 und der Wirtschaftlichkeit


5.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. Beim agilen Vorgehen delegiert er die fach- und lösungsspezifischen As-pekte an der Anwendervertreter. Er wird vom Auftraggeber ernannt und gesteuert.

Verantwortung

Führen des Projekts zur Erreichung der Projektergebnisse und der Vorgehensziele (Zeit,

Kosten, Qualität) des Projekts

Wirtschaftlicher und nachhaltiger Einsatz der Ressourcen

Führen des Berichtswesens und umfassende, regelmässige und situative Information der

Projektsteuerung, damit sie ihre Steuerungs- und Entscheidungsaufgaben wahrnehmen

kann.

Führen des Stakeholdermanagements und Sicherstellen des Einbezugs der berechtigten

Anspruchsgruppen

Führen des Qualitäts- und Risikomanagements

Rechtzeitiger Einbezug der zuständigen Controlling- und Vorgabestellen, damit ihre be-

rechtigten Anforderungen erfüllt werden.

Regelung der im Projekt ergänzend zu HERMES einzusetzenden Methoden, Praktiken und Werkzeuge und Sicherstellung ihrer Anwendung

Durchführen von Beschaffungen unter Einhaltung der Vorgaben

Ausführen der Entscheidungsaufgaben

Überprüfung der Einhaltung des SLA (Service Level Agreements, Dienstleistungsniveau Vereinbarung) durch die Vertragspartner im Projekt

Kompetenzen

Kann auf alle Projektinformationen zugreifen

Kompetenz bezüglich des Einsatzes der freigegebenen Ressourcen

Entscheidungskompetenz im mit dem Auftraggeber definierten Rahmen

Anordnungskompetenz

In Absprache mit dem Auftraggeber das Projekt in Teilprojekte aufteilen, Teilprojektleiter

bestimmen und 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)


Grobe Kenntnisse der im Projekt angewendeten Methoden und Praktiken

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.

146 / 202

RO

LLEN


Führungsfähigkeit


keholder zu managen und Konflikte zu lösen.

Gute schriftliche Ausdrucksfähigkeit, um z. B. Projektberichte zu erstellen.


Ergebniserstellung

Projektführung Projekt führen und kon-trollieren

Projektmanagementplan Projektleiter

Arbeitsauftrag Projektleiter, Anwendervertreter

Projektstatusbericht Projektleiter

Protokoll Projektleiter, Anwendervertreter, Iterationsleiter

Stakeholder managen und informieren

Stakeholderliste Projektleiter, Auftraggeber, Business Analyst, Ge-schäftsprozessverantwortlicher

Stakeholderinteressen Projektleiter, Anwendervertreter


Projektmanagementplan erarbeiten

Projektmanagementplan Projektleiter, Auftraggeber

Umsetzungsauftrag erar-beiten

Umsetzungsauftrag Projektleiter, Anwendervertreter, Geschäftsprozessverantwortlicher

Änderungen managen Änderungsantrag Projektleiter, Anwendervertreter, Business Analyst

Änderungsstatusliste Projektleiter, Anwendervertreter


Leistungen vereinbaren und steuern

Offertanfrage Projektleiter

Angebot Projektleiter

Evaluationsbericht Projektleiter, Anwendervertreter

Vereinbarung Projektleiter, Auftraggeber

Probleme behandeln und Erfahrungen nutzen

Projekterfahrungen Projektleiter, Auftraggeber, Anwendervertreter, Ite-rationsleiter

Qualitätssicherung füh-ren


Prüfprotokoll Projektleiter, Anwendervertreter

Risiken managen Projektmanagementplan Projektleiter


Phasenfreigabe vorberei-ten

Phasenbericht Projektleiter, Anwendervertreter, Iterationsleiter



Releaseabschluss vorbe-reiten

Releasebericht Projektleiter, Anwendervertreter, Iterationsleiter



Projektabschluss vorbe-reiten

Projekterfahrungen Projektleiter, Auftraggeber, Anwendervertreter

Projektschlussbeurtei-lung

Projektleiter

Projektgrundla-gen

Rechtsgrundlagenanalyse erarbeiten

Rechtsgrundlagenanalyse Projektleiter, Geschäftsprozessverantwortlicher

Studie erarbeiten Studie Projektleiter, Anwendervertreter, Business Analyst, Geschäftsprozessverantwortlicher, IT-Architekt

Stakeholderliste Projektleiter, Auftraggeber, Anwendervertreter, Bu-siness Analyst, Geschäftsprozessverantwortlicher

Entscheid weiteres Vor-gehen treffen

Checkliste weiteres Vor-gehen

Projektleiter, Anwendervertreter

Studie Projektleiter, Anwendervertreter

Meilenstein weiteres Vor-gehen

Projektleiter, Anwendervertreter, Qualitäts- und Ri-sikomanager



147 / 202

RO

LLEN


Produkt Entscheid Produktkon-zept treffen

Checkliste Produktkon-zept

Projektleiter

Meilenstein Produktkon-zept

Projektleiter, Qualitäts- und Risikomanager, An-wendervertreter


Projektleiter, Qualitäts- und Risikomanager

IT-System Entscheid Lösungsarchi-tektur treffen

Checkliste Lösungsarchi-tektur

Projektleiter

Meilenstein Lösungsar-chitektur

Projektleiter, Qualitäts- und Risikomanager, An-wendervertreter


Projektleiter, Qualitäts- und Risikomanager

Beschaffung Ausschreibung durchfüh-ren

Angebot Projektleiter, Anwendervertreter, Betriebsverant-wortlicher, Entwickler

Ausschreibungsunterla-gen


Vereinbarung erarbeiten Vereinbarung Projektleiter, Auftraggeber, Anwendervertreter


Entscheid Vorabnahme treffen

Checkliste Vorabnahme Projektleiter

Abnahmeprotokoll Projektleiter, Anwendervertreter, Betriebsverant-wortlicher, Entwickler, Qualitäts- und Risikomana-ger

Meilenstein Vorabnahme Projektleiter, Anwendervertreter, Qualitäts- und Ri-sikomanager



Entscheid Abnahme tref-fen

Checkliste Abnahme Projektleiter


Meilenstein Abnahme Projektleiter, Anwendervertreter, Qualitäts- und Ri-sikomanager



IT-Migration Entscheid Abnahme Mig-ration treffen


Projektleiter






ISDS Entscheid ISDS-Konzept treffen

Checkliste ISDS-Konzept Projektleiter

Meilenstein ISDS-Kon-zept



Projektleiter

Tabelle 20: Aufgaben, die der Projektleiter verantwortet, und andere an der Aufgabe beteiligte Rollen

5.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

Verantwortet die an ihn delegierten Projektmanagementaktivitäten.

Kompetenzen

Kann im Rahmen der an ihn delegierten Aufgaben: o Informationen einfordern und erteilen;

148 / 202

RO

LLEN

o Anordnungen treffen.

Fähigkeiten


Vertiefte Kenntnisse in Projektmanagement

Kenntnisse der in seinen Aufgaben anzuwendenden Methoden und Praktiken




Gute schriftliche Ausdrucksfähigkeit und Fähigkeit zur Erstellung von Dokumentationen

5.4.2.4 Teilprojektleiter

Beschreibung

Der Teilprojektleiter trägt die Verantwortung für die Erbringung der mit dem Projektleiter ver-einbarten Leistungen. Er verfügt dabei über alle Kompetenzen, um die vom Projektleiter de-legierten Tätigkeiten wahrzunehmen.

Verantwortung

Qualität der erarbeiteten Ergebnisse sowie Einhaltung der Richtlinien im eigenen Teilpro-jekt

Einhaltung der vereinbarten Kosten und Termine im eigenen Bereich

Führung der Fachspezialisten im eigenen Bereich

Berichtswesen im eigenen Teilprojekt

Sicherstellung der benötigten Ressourcen mit den geforderten Qualifikationen im eigenen

Bereich

Kompetenzen

Analog Projektleiter, gültig für den Bereich des eigenen Teilprojektes

Fähigkeiten




Anwendung (z. B. für Beschaffungen, Finanzierung, Controlling, Sicherheit)

Vertiefte Kenntnisse im Projektmanagement

Kenntnisse der im Projekt angewendeten Methoden und Praktiken

Betriebswirtschaftliche Kenntnisse für die Beurteilung von Varianten und der Wirtschaft-

lichkeit sowie für die Sicherstellung des effizienten und effektiven Einsatzes der finanziellen und personellen Ressourcen



Führungskompetenz


keholder zu managen und Konflikte zu lösen

Gute schriftliche Ausdrucksfähigkeit, um z. B. Projektberichte zu erstellen

5.4.3 Ausführungsrollen

5.4.3.1 Anwendervertreter

Beschreibung

Der Anwendervertreter vertritt die Interessen seiner Nutzergruppe bzw. der Anwender im Pro-jekt. Bei agiler Durchführung ist er Teil des Entwicklungsteams und ist in dieser Funktion einem

Product Owner gleichzusetzen, seine Aufgaben und Kompetenzen gehen aus Projektmanage-ment Sicht jedoch weiter als die eines Product Owners. Diese sind bei klassischer und agiler

149 / 202

RO

LLEN

Durchführung weitgehend identisch, etwaige Unterschiede ergeben sich aus dem gewählten Entwicklungsvorgehen.

Der Anwendervertreter verwaltet die mit den Fachbereichen abgestimmten und eindeutigen fachlichen Lösungsanforderungen als stabile Basis für die Realisierung und ist für den Erfolg der Entwicklung verantwortlich. Er ist sowohl für die Entwickler, als auch für die Stakeholder

der Ansprechpartner und bildet damit einen verbindlichen Kommunikationskanal. Er wird vom Auftraggeber ernannt, vom Projektleiter geführt, ist jedoch während der ganzen Lösungsent-

stehung in fach- und lösungsspezifischen Fragen und Entscheidungen eigenständig.

Im Rahmen des agilen Entwicklungsvorgehens bestimmt der Anwendervertreter darüber hin-aus die Reihenfolge der in den Lösungsanforderungen gelisteten Aufträge und priorisiert

diese. Er verantwortet die Releases (in Lösungsanforderungen) und Releasepläne (im Projekt-managementplan) und nimmt die abgearbeiteten Aufträge vom Entwickler ab. Weiterge-

hende konkrete Detailaufgaben und Verantwortlichkeiten im agilen Entwicklungsteam sind durch die zur Anwendung kommende agile Methode definiert und nicht HERMES relevant.

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

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 Liefertermins, des Leistungsumfangs und des wirtschaftlichen Erfolgs

der Lösung

Direkter Draht zu Stakeholdern

Einhaltung der Anforderungen an die Informatiksicherheit und an den Datenschutz

Im Rahmen des agilen Vorgehens:

o Bestimmung der Umsetzungsreihenfolge der Lösungsmerkmale bzw. der Priorität der Aufträge

o Überprüfung der Lösungslieferungen (Inkrement)

Kompetenzen

Kann auf alle benötigten Informationen zugreifen

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 und Abschluss der SLA

Im Rahmen des agilen Vorgehens:

o Entscheid über die Releaseplanung (Gliederung der Lösungsanforderungen nach Re-leases)

o Definition der Aufträge in den Lösungsanforderungen o Abnahme der realisierten Aufträge und der Lösungen

Fähigkeiten

Vertiefte Kenntnisse im Fachbereich

Kenntnisse im Projektmanagement

Betriebswirtschaftliche Grundkenntnisse

Kenntnisse der Methoden und Praktiken für Entwicklungsmanagement, Design, Spezifika-tion


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

Formulieren von Anforderungen und Änderungsanträgen

Kenntnisse von HERMES

150 / 202

RO

LLEN

Gute schriftliche Ausdrucksfähigkeit

Fähigkeit, zu abstrahieren und zu vereinfachen


Visionäres Denken

Durchsetzungsvermögen

Natürliche Autorität


Ergebniserstellung

Projektgrundla-gen

Beschaffungsanalyse er-arbeiten

Beschaffungsanalyse Anwendervertreter, Projektleiter

Beschaffung Ausschreibung erarbei-ten

Ausschreibungsunterla-gen

Anwendervertreter, Projektleiter

Angebote bewerten Evaluationsbericht Anwendervertreter, Projektleiter

Angebotsprotokoll Anwendervertreter, Projektleiter

Organisation Stakeholderinteressen vertreten

Stakeholderinteressen Anwendervertreter

Produkt Lösungsanforderungen erarbeiten

Situationsanalyse Anwendervertreter, Business Analyst, Geschäfts-prozessverantwortlicher

Lösungsanforderungen Anwendervertreter, Business Analyst, Geschäfts-prozessverantwortlicher

Releaseplan erarbeiten Releaseplan Anwendervertreter, Betriebsverantwortlicher, Busi-ness Analyst, Projektleiter

Projektmanagementplan Anwendervertreter, Projektleiter

Lösungsanforderungen führen

Lösungsanforderungen Anwendervertreter

Stakeholderinteressen vertreten


Produktkonzept erarbei-ten

Produktkonzept Anwendervertreter, Business Analyst

IT-System Lösungsanforderungen erarbeiten

Situationsanalyse Anwendervertreter, IT-Architekt, Business Analyst, Geschäftsprozessverantwortlicher

Lösungsanforderungen Anwendervertreter, IT-Architekt, Business Analyst, Geschäftsprozessverantwortlicher

Releaseplan erarbeiten Releaseplan Anwendervertreter, Betriebsverantwortlicher, Busi-ness Analyst, Projektleiter

Projektmanagementplan Anwendervertreter, Projektleiter

Lösungsanforderungen führen

Lösungsanforderungen Anwendervertreter

Stakeholderinteressen vertreten



Einführungskonzept erar-beiten

Einführungskonzept Anwendervertreter, Projektleiter, Business Analyst, Geschäftsprozessverantwortlicher

Einführung realisieren Einführungsmassnahmen realisiert

Anwendervertreter, Projektleiter, Business Analyst, Geschäftsprozessverantwortlicher

Einführung durchführen Einführungsmassnahmen durchgeführt

Anwendervertreter, Projektleiter, Business Analyst, Geschäftsprozessverantwortlicher

ISDS ISDS-Konzept realisieren ISDS-Massnahmen reali-siert

Anwendervertreter, Projektleiter, Betriebsverant-wortlicher, ISDS-Verantwortlicher, Entwickler

ISDS-Konzept Anwendervertreter, Projektleiter, Betriebsverant-wortlicher, ISDS-Verantwortlicher, IT-Architekt

Tabelle 21: Aufgaben, die der Anwendervertreter verantwortet, und andere an der Aufgabe beteiligte Rollen

5.4.3.2 Anwendungsverantwortlicher

Beschreibung

Der Anwendungsverantwortliche stellt den Unterhalt und die Weiterentwicklung sowie den

sicheren und wirtschaftlichen Betrieb der fertigen der IT-Anwendung während seiner Nut-zungsdauer sicher. Im Projekt begleitet er als Gesandte der Nachfolgeorganisation den Wech-

sel der IT-Anwendung in die Nutzungsphase und bereitet diese (ausserhalb der Projektorga-nisation) vor.

https://www.hermes.admin.ch/de/projektmanagement/verstehen/rollen/betriebsverantwortlicher.html

https://www.hermes.admin.ch/de/projektmanagement/verstehen/rollen/business-analyst.html


https://www.hermes.admin.ch/de/projektmanagement/verstehen/rollen/betriebsverantwortlicher.html



151 / 202

RO

LLEN

5.4.3.3 Betriebsverantwortlicher

Beschreibung

Der Betriebsverantwortliche vertritt im Projekt den Betreiber (Service-Provider) 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 die Informatiksicherheit und an den Datenschutz beim

Betreiber

Kompetenzen


Anordnungskompetenzen gegenüber den eigenen Spezialbereichen 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

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


Ergebniserstellung

Tests Testinfrastruktur realisie-ren

Testinfrastruktur reali-siert

Betriebsverantwortlicher, Business Analyst, Test-verantwortlicher

IT-Betrieb Betriebskonzept erarbei-ten

Betriebskonzept Betriebsverantwortlicher, IT-Architekt

Betrieb realisieren Betriebshandbuch Betriebsverantwortlicher

Betriebsinfrastruktur rea-lisiert

Betriebsverantwortlicher

Betriebsorganisation rea-lisiert


System in Betrieb integ-rieren

Betriebshandbuch Betriebsverantwortlicher

System integriert Betriebsverantwortlicher, Entwickler

Betrieb aktivieren Betriebshandbuch Betriebsverantwortlicher

Betrieb aktiviert Betriebsverantwortlicher, Entwickler

Service Level Agreement Betriebsverantwortlicher, Auftraggeber, Projektlei-ter, Anwendervertreter

Tabelle 22: Aufgaben, die der Betriebsverantwortliche verantwortet, und andere an der Aufgabe beteiligte Rollen

5.4.3.4 Business Analyst

Beschreibung

Der Business Analyst bildet die Schnittstelle zwischen Anwender und Ersteller/Betreiber. Er erhebt und priorisiert die Anforderungen der Anwender auf der Basis der Geschäftsprozesse

und transformiert sie in Systemanforderungen. Diese dienen Ersteller und Betreiber als Grund-lage für die Konzipierung und für den Betrieb des Produkts, der Dienstleistung oder des IT-

Systems.

152 / 202

RO

LLEN

Verantwortung

Definition der Geschäftsprozesse, Erhebung der vollständigen Anforderungen und Sicher-

stellen des Einbezugs von Spezialisten, Anwendervertretern und Geschäftsprozessverant-wortlichen

Systematische Dokumentation der Ergebnisse mit geeigneten Methoden

Übergabe der Anforderungen an die weiterbearbeitenden Stellen

Kompetenzen


Fähigkeiten

Vertiefte Kenntnisse im Fachbereich


Anwendung (z. B. für Beschaffungen, Finanzierung, Controlling, Sicherheit)

Vertiefte Kenntnisse in Business-Analyse sowie den einschlägigen Methoden und Techni-

ken

Betriebswirtschaftliche Kenntnisse zur Bewertung von Varianten und Wirtschaftlichkeit

Fähigkeit zur Erhebung, Bewertung und Priorisierung der Anforderungen




Gute schriftliche Ausdrucksfähigkeit, um z. B. Anforderungen zu dokumentieren

Führung von Fachspezialisten im eigenen Verantwortungsbereich


Ergebniserstellung

Organisation Organisationsanforde-rungen erarbeiten

Situationsanalyse Business Analyst, Anwendervertreter, Geschäfts-prozessverantwortlicher

Organisationsanforde-rungen

Business Analyst, Anwendervertreter, Geschäfts-prozessverantwortlicher

Organisationskonzept er-arbeiten

Organisationskonzept Business Analyst, Anwendervertreter, Geschäfts-prozessverantwortlicher

Geschäftsmodellbe-schreibung


Prozessbeschreibung Business Analyst, Anwendervertreter, Geschäfts-prozessverantwortlicher

Organisationsbeschrei-bung


Organisation umsetzen Geschäftsmodellbe-schreibung


Prozessbeschreibung Business Analyst, Anwendervertreter, Geschäfts-prozessverantwortlicher

Organisationsbeschrei-bung


Organisation umgesetzt Business Analyst, Geschäftsprozessverantwortlicher

Organisation aktivieren Organisation aktiviert Business Analyst, Anwendervertreter, Geschäfts-prozessverantwortlicher

Tabelle 23: Aufgaben, die der Business Analyst verantwortet, und andere an der Aufgabe beteiligte Rollen

5.4.3.5 Entwickler

Beschreibung

Die Rolle Entwickler ist umfassend und bezeichnet den Produktentwickler und den IT-Entwickler. Der Entwickler entwirft, gestaltet und erstellt das Produkt bzw. das IT-System gemäss den Lö-sungsanforderungen und unter der Führung des Projektleiters bei klassischer oder im Rahmen

des Entwicklungsteams bei agiler Vorgehensweise. Er integriert das Produkt bzw. das IT-System in die Umgebung des Betreibers.

Verantwortung

Verantwortet die Erarbeitung der Entwicklungsergebnisse unter Einhaltung der gesetzten

153 / 202

RO

LLEN

Termine und Kosten

Kompetenzen


Fähigkeiten

Vertiefte Kenntnisse im Spezialgebiet Produkt- oder Softwareentwicklung

Vertiefte Kenntnisse der Methoden und Praktiken für Design, Spezifikation, Entwicklung,

Test und Integration




Ergebniserstellung

Projektgrundla-gen

Prototyping durchführen Prototyp Entwickler, IT-Architekt

Prototypdokumentation Entwickler, IT-Architekt

Produkt Prototyping durchführen Prototyp Entwickler, IT-Architekt


Produkt realisieren Detailspezifikation Entwickler, Business Analyst

Produktdokumentation Entwickler

Anwendungshandbuch Entwickler, Anwendervertreter


Entwickler, Anwendervertreter

Produkt aktivieren Produkt aktiviert Entwickler, Betriebsverantwortlicher

IT-System Prototyping durchführen Prototyp Entwickler, IT-Architekt


System realisieren Detailspezifikation Entwickler, Business Analyst, IT-Architekt

Lösungsarchitektur Entwickler, Betriebsverantwortlicher, IT-Architekt

Anwendungshandbuch Entwickler, Anwendervertreter, Entwickler


Entwickler

Systemintegration vorbe-reiten

Schnittstellen realisiert Entwickler

Lösungsarchitektur Entwickler, Betriebsverantwortlicher, IT-Architekt

Integrations- und Instal-lationsanleitung

Entwickler, Betriebsverantwortlicher

Detailspezifikation Entwickler, Business Analyst, IT-Architekt

System aktivieren System aktiviert Entwickler, Betriebsverantwortlicher, Business Ana-lyst

IT-Migration Migrationsverfahren rea-lisieren

Detailspezifikation Entwickler, Business Analyst, IT-Architekt

Migrationsverfahren rea-lisiert

Entwickler, Betriebsverantwortlicher

Migration durchführen Migration durchgeführt Entwickler, Betriebsverantwortlicher, Business Ana-lyst

Tabelle 24: Aufgaben, die der Entwickler verantwortet, und andere an der Aufgabe beteiligte Rollen

5.4.3.6 Entwicklungsteam

Beschreibung

Das Entwicklungsteam ist eine ausschliesslich agile Rolle in der Phase Umsetzung. Die Rolle ist eine interdisziplinäre Gruppenrolle und somit eine Sonderrolle. In ihr sind die Rollen An-wendervertreter, Iterationsleiter, alle Entwickler sowie verschiedene Fachspezialisten, wie z. B.

der Business Analyst oder bei IT-Vorhaben auch der IT-Architekt oder der ISDS-Verantwortli-che zusammengefasst. Als Eigentümerin ist sie (als Team) für die Gestaltung der Detailspezi-

fikation zuständig. Sie kann selber entscheiden, ob sie die einzelnen Aufträge herunterbrechen will. Die Details in Aktivitäten und Prozessen des Entwicklungsmanagements sind durch die

zur Anwendung kommende agile Methode definiert und nicht HERMES relevant.

154 / 202

RO

LLEN

Verantwortung

Verantwortet die Abarbeitung der Detailspezifikation

Verantwortet Erarbeitung der Lösung

Verantwortet den Gesamtablauf und Abschluss der Iteration

Verpflichtet sich gegenüber den gesetzten Iterationszielen (Commitment).

Sichert die Qualitätsanforderungen

Kompetenzen


Entscheidet funktionsübergreifend

Organisiert sich selbst

Aus Projektsicht liegt die alleinige Führungsverantwortung beim Projektleiter, er darf

lediglich nicht in die Selbstorganisation des agilen Teams eingreifen.

Fähigkeiten

Vertiefte Kenntnisse in den entsprechenden Fachgebieten; ist als Gruppenrolle funktionsübergreifend kompetent, verfügt über alle Fähigkeiten zum

Erarbeiten einer Lösung

Vertiefte Kenntnisse der Methoden und Praktiken für agile Entwicklung



5.4.3.7 Geschäftsprozessverantwortlicher

Beschreibung

Der Geschäftsprozessverantwortliche bearbeitet die prozessrelevanten Aspekte innerhalb des Projekts.

Verantwortung

Fachspezifische Prozessleistung

Sicherstellen der wesentlichen Informationen bezüglich der Informatikbedürfnisse des ei-

genen Prozesses, damit Entscheidungen durch die Projektleitung getroffen werden kön-nen.

Planung und Umsetzung der Prozessoptimierungsaktivitäten

Kompetenzen

Anordnungskompetenz

Entscheidungskompetenz bezüglich Prozessanpassungen

Fähigkeiten

Vertiefte Kenntnisse der Prozesse und der Organisation des Fachbereichs


Vertiefte Kenntnisse im Spezialgebiet Prozessmanagement




Gute schriftliche Ausdrucksfähigkeit, um z. B. Prozessdokumentationen zu erstellen

5.4.3.8 ISDS-Verantwortlicher

Beschreibung

Der ISDS-Verantwortliche nimmt die Aspekte der Informationssicherheit und des Datenschut-zes im Projekt wahr.

Verantwortung

Sicherstellen, dass die Informationssicherheitsvorgaben und die Schutzmassnahmen im Projekt berücksichtigt und umgesetzt werden.

155 / 202

RO

LLEN

Fördern des Informationssicherheits- und Datenschutzbewusstseins 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 Informatiksicherheit und Datenschutz

Kenntnisse der gesetzlichen Grundlagen

Kenntnisse der Standards, Architekturen, Methoden und Praktiken der Informatik

Vertiefte Kenntnisse der im eigenen Aufgabenkreis anzuwendenden Methoden und Prak-

tiken


Kenntnisse im Prozessmanagement

Vertiefte Kenntnisse von HERMES, vorzugsweise nachgewiesen durch ein Zertifikat


Gute schriftliche Ausdrucksfähigkeit, um z. B. Berichte zu erstellen


Ergebniserstellung

Projektgrundla-gen

Schutzbedarfsanalyse er-arbeiten

Schutzbedarfsanalyse ISDS-Verantwortlicher, Projektleiter, Geschäftspro-zessverantwortlicher

Informationssi-cherheit und Da-tenschutz

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 25: Aufgaben, die der ISDS-Verantwortliche verantwortet, und andere an der Aufgabe beteiligte Rollen

5.4.3.9 Iterationsleiter

Beschreibung

Der Iterationsleiter ist eine ausschliesslich agile Rolle.

Er ist Teil des Entwicklungsteams und ist in dieser Funktion einem Scrum Master gleichzuset-zen. So steuert er die Prozesse des Entwicklungsteams und sorgt dafür, dass sie nicht abbre-chen. Er ist der Vermittler zwischen den verschiedenen Rollen und hat die Aufgabe, das Ent-

wicklungsteams zu moderieren, es vor äusseren Störungen zu schützen, Hindernisse aus dem Weg zu räumen und auf die Einhaltung des agilen Vorgehens zu achten. Er hat weder diszip-

linarische noch fachliche Autorität. Weitergehende konkrete Detailaufgaben und Verantwort-lichkeiten im Entwicklungsteam sind durch die zur Anwendung kommende agile Methode

definiert und nicht HERMES relevant.

Aus Projektmanagementsicht interagiert er zusätzlich mit der Projektführung sowie dem An-wendervertreter und wirkt im Berichtswesen des Projekts mit.

Verantwortung

Ist verantwortlich für die Planung und Durchführung der Iterationen.

Ist verantwortlich für die Einhaltung der Iterations-Praktiken und der Iterations-Regeln.

Ist verantwortlich für die korrekten Zahlen der Entwicklung im Berichtswesen.

Kompetenzen

Entscheidet über die prozessuale und methodische Abwicklung der Iteration.

Plant die Iterationen.

Er unterstützt als Prozesswächter die Iterationen, steuert die damit verknüpften Prozesse

156 / 202

RO

LLEN

des Entwicklungsteams und beseitigt Unklarheiten und Hindernisse (Enabler), die den Ar-beitsfortschritt behindern.

Fähigkeiten

Fundiertes Wissen und grosse Erfahrung betreffend agiles Entwicklungsvorgehen (agile

Methoden und Prozesse)

Kommunikation mit Entwicklungsteam und mit Projektleiter

Teamfähigkeit

Erfahrung in dienender Führung (Servant Leadership)

Erfahrung als Coach, Trainer, Moderator, Mediator und Assistent


Ergebniserstellung

Produkt Iterationen planen Detailspezifikation Iterationsleiter, Anwendervertreter, Entwicklungs-team, Business Analyst

Iterationen durchführen Inkrement Iterationsleiter, Entwicklungsteam

Protokoll Iterationsleiter

IT-System Iterationen planen Detailspezifikation Iterationsleiter, Anwendervertreter, Entwicklungs-team, Business Analyst

Iterationen durchführen Inkrement Iterationsleiter, Entwicklungsteam

Protokoll Iterationsleiter

Tabelle 26: Aufgaben, die der Iterationsleiter verantwortet, und andere an der Aufgabe beteiligte Rollen

5.4.3.10 IT-Architekt

Beschreibung

Der IT-Architekt entwirft die Architektur des zu erstellenden Systems. Er definiert die System-komponenten und ihre Schnittstellen mit den Umsystemen.

Verantwortung

Technische Gesamtverantwortung für das entstehende IT-System

Sicherstellen der Konformität mit den vorhandenen Standards und Architekturvorgaben

und Durchführen von Prüfungen

Kompetenzen

Anordnungskompetenz

Entscheidungskompetenz bezüglich der Systemarchitektur

Fähigkeiten


Vertiefte Kenntnisse im Spezialgebiet IT-Architektur

Vertiefte Kenntnisse der Standards, Architekturen, Methoden und Praktiken der Informatik





Sehr gute schriftliche Ausdrucksfähigkeit, um z. B. Architekturdokumentationen zu erstel-

len


Ergebniserstellung

IT-System Lösungsarchitektur erar-beiten

Systemkonzept IT-Architekt, Business Analyst, Anwendervertreter, Entwickler

Lösungsarchitektur IT-Architekt, Betriebsverantwortlicher, Entwickler

Integrationskonzept erarbeiten

Integrationskonzept IT-Architekt, Betriebsverantwortlicher, Business Analyst, Entwickler

157 / 202

RO

LLEN


IT-Migration Migrationskonzept erar-beiten

Migrationskonzept IT-Architekt, Business Analyst, Entwickler

Altsystem ausser Betrieb setzen

Altsystem entfernt IT-Architekt, Betriebsverantwortlicher, Business Analyst

Tabelle 27: Aufgaben, die der IT-Architekt verantwortet, und andere an der Aufgabe beteiligte Rollen

5.4.3.11 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

Vertiefte Kenntnisse im Fachbereich (fachliche Prozesse, Systemanforderungen usw. im eigenen Testbereich)

Kenntnisse im Testen und in der Testmethode

Rasche Auffassungsgabe und gründliche Arbeitsweise

Durchsetzungsvermögen


5.4.3.12 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.

Verantwortung

Sicherstellen, dass die verschiedenen Anforderungen wie z. B. Geschäftsanforderungen

und Systemanforderungen in Bezug auf die Qualität des IT-Systems erfüllt werden.

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



158 / 202

RO

LLEN


Gute schriftliche Ausdrucksfähigkeit, um z. B. Testkonzepte und Testberichte zu erstellen


Ergebniserstellung

Tests Testkonzept erarbeiten Testkonzept Testverantwortlicher, Tester, Betriebsverantwortli-cher, Business Analyst, Entwickler

Test durchführen Testprotokoll Testverantwortlicher, Tester

Testkonzept Testverantwortlicher, Tester, Betriebsverantwortli-cher, Business Analyst, Entwickler

Testinfrastruktur über-führen

Testkonzept Testverantwortlicher, Projektleiter

Testinfrastruktur über-führt

Testverantwortlicher, Projektleiter

Protokoll Testverantwortlicher, Projektleiter

Tabelle 28: Aufgaben, die der Testverantwortliche verantwortet, und andere an der Aufgabe beteiligte Rollen

159 / 202

SZ

EN

AR

IEN

6 Szenarien

6.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 ausgerichtet, beispielsweise für eine Organisationsanpassung, für den Aufbau von IT-Infra-

strukturen oder für die Entwicklung einer Dienstleistung bzw. eines Produkts.

Das Szenario bildet die komplette Lösungsentstehung eines Projekts ab und unterstützt den Projektleiter bei der Projektplanung. Es beinhaltet standardmässig diejenigen Methodenele-

mente von HERMES, die üblicherweise für Projekte der jeweiligen Charakteristik von Bedeu-tung sind. Dadurch ist HERMES rasch und einfach anwendbar. Die meisten Szenarien können

sowohl für das klassische, als auch das agile Entwicklungsvorgehen gewählt werden (vgl. Ab-bildung 23. Den Ausschlag dafür, welches Szenario für die Lösungsentstehung passend ist,

geben die Erkenntnisse der Studie in der Initialisierungsphase.

Szenario 1

Szenario 2

Szenario 5


Entwicklungsvorgehen / Lösungsentstehung

? Szenario 2

Szenario x

oder

oder

oder

oder

Abbildung 23: Wahl und Anwendung des für das Projekt geeigneten Szenarios

Die Auswahl des geeigneten Standardszenarios erfolgt nach dem Entscheid weiteres Vorge-hen in der Studie in der Phase Initialisierung. Die Anwender von HERMES können Stan-

dardszenarien an die Bedürfnisse ihrer Stammorganisation sowie des konkret vorliegenden Projektes anpassen und weitere, individuelle Szenarien selber erstellen.

6.2 Szenarien-Übersicht

6.2.1 Aufbau der Szenarien

Szenarien basieren auf Modulen, die thematisch zusammengehörende Aufgaben und Ergeb-nisse gruppieren. Die Abbildung 24 zeigt in einem Beispiel, wie die Module A, B und N zu-

sammen ein fiktives Szenario bilden.

Szenario

Modul A

Modul B

Modul N

Ergebnisse

Aufgaben

Modul A



Abbildung 24: Mehrere Module, bestehend aus Ergebnisse und Aufgaben, bilden ein Szenario

160 / 202

SZ

EN

AR

IEN

Die Szenarien sind auf die Durchführung von Projekten mit einer spezifischen Charakteristik ausgerichtet und beinhalten daher genau diejenigen Module, die für die Umsetzung des Pro-

jekts geeignet sind. Dabei kann ein Modul in mehreren Szenarien verwendet werden. Und da sich die Module wiederum aus den entsprechenden Aufgaben und Ergebnissen zusammen-

setzen, erhält der Anwender am Schluss eine perfekt abgestimmte Umsetzungsvorlage inklu-sive der notwendigen Dokumentvorlagen.

Ein Szenario beschreibt immer nur die Lösungsentstehung; die Phasen Initialisierung und Ab-schluss befinden sich ausserhalb des Szenarios.

6.2.2 Standardszenarien

HERMES bietet sechs Standardszenarien für Projekte mit verschiedenen Charakteristiken an:

Dienstleistung/Produkt Entwicklung

Dienstleistung/Produkt Adaption

IT-Anwendung Entwicklung

IT-Anwendung Adaption

IT-Infrastruktur

Organisationsanpassung

Die Tabelle zeigt pro Szenario die verwendeten Module kontextgerecht auf.

Module

Szenario P

roje

kts

teu

e-

run

g

Pro

jektf

üh

run

g

Pro

jektg

run

dla

-g

en

Besc

haff

un

g

Org

an

isati

on

Pro

du

kt

IT-S

yst

em

Test

s

Ein

füh

run

gso

r-g

an

isati

on

IT-M

igra

tio

n

IT-B

etr

ieb

ISD

S

Dienstleistung/Produkt Entwicklung X X X X X

Dienstleistung/Produkt Adaption X X X X X X X

IT-Anwendung Entwicklung X X X X X X X X X

IT-Anwendung Adaption X X X X X X X X X X

IT-Infrastruktur X X X X X X

Organisationsanpassung X X X X

Tabelle 29: Standardszenarien für Projekte verschiedener Charakteristiken samt Modulen

Das Angebot der Standardszenarien ist nicht abschliessend. Die Nachfrage bezüglich neuen Szenarien wird periodisch überprüft und bei Bedarf werden weitere Standardszenarien bereit-

gestellt.

6.2.3 Individuelle Szenarien

6.2.3.1 Anpassung der Szenarien

Es besteht die Möglichkeit, ein bestehendes Szenario anzupassen oder sein eigenes, individu-

elles Szenario zu erstellen. HERMES bieten dazu zwei Möglichkeiten, die in folgender Reihen-folge kombiniert angewendet werden können:

Sizing

Tailoring

6.2.3.2 Sizing

Mit der in HERMES Online bereitgestellten Sizing-Funktion werden die Standardszenarien ge-mäss der ermittelten Projektwertigkeit angepasst. Die Wertigkeit beruht auf einer Anzahl von

Kriterien wie beispielsweise Projektbudget, Durchlaufzeit, Grösse des Projektteams, Stakehol-der-Struktur oder politische Brisanz, die sich auf die Komplexität der zugrundeliegenden Lö-

sungsvariante gemäss Studie in der Phase Initialisierung bezieht. Aufgrund der Wertigkeit er-mittelt das Sizing die "Grösse" des anvisierten Projekts und stellt dem Anwender gemäss Sze-

nariowahl das entsprechend angepasste Szenario samt angepassten Dokumentvorlagen be-reit.

Es werden verschiedene Projektgrössen/-wertigkeiten unterstützt:

a) Megaprojekte XL (ohne/mit Teilprojekten)

161 / 202

SZ

EN

AR

IEN

b) Grossprojekte L (ohne/mit Teilprojekten

c) Mittlere Projekte M

d) Kleinprojekte S

Die im HERMES Online eingestellten Projektgrössen/-wertigkeiten sind als generelle Stan-dardannahmen (Default) zu verstehen. Sie können durch die Projektleitung oder Stammorga-nisation ihren eigenen Bedürfnissen angepasst werden.

Die Ergebnisbeschreibung im vorliegenden HERMES-Referenzhandbuch entspricht in etwa der obigen Maximalvariante a), also derjenigen für Megaprojekte XL. In der Praxis entspricht

die Mehrheit der Projekte jedoch eher den Grössen L oder M. Es ist deshalb sinnvoll, die in HERMES Online bereitgestellte Sizing-Funktion zu nutzen.

6.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.

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 Aufgaben und Ergebnissen – erstellt und in das Szenario integriert. Beispiele von fachspezifischen individuellen Modu-

len, die selbst entwickelt werden können, sind beispielsweise: o Marketing

o Immobilien o Kommunikation

o Personalentwicklung o Rechtssetzung

o Ausbildung o Strategieentwicklung

o Einführung Geschäftsverwaltung o Service Public

4. Aufgaben und Ergebnisse hinzufügen:

Der Inhalt eines Moduls kann erweitert werden. Neue Aufgaben und Ergebnisse können erstellt werden.

Mit diesen Möglichkeiten lassen sich weitere individuelle, projekt- oder organisationsspezifi-sche Szenarien einfach abbilden. Abbildung 25 zeigt, wie mehrere Projekte einer Stammor-ganisation mit unterschiedlichen Szenarien gleichzeitig nebeneinander abgewickelt werden

können.

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.

162 / 202

SZ

EN

AR

IEN

Vorhaben Projekte einer Stammorganisation mit Szenarien

Service public"Guichet Virtuel"

Projekt 3 Initialisierung AbschlussIT-Anwendung Entwicklung

Beschaffung GEVER-System

Fusion der Bereiche A & B

InfrastrukturHosting Services

Rechtsetzung Projekt n AbschlussInitialisierung Individuelles Szenario "abc"

Projekt 5 Initialisierung AbschlussOrganisationsanpassung

Projekt 2 AbschlussInitialisierung Dienstleistung/Produkt Entwicklung

Projekt 4 Initialisierung AbschlusslT-Infrastruktur

Projekt 1 AbschlussInitialisierung IT-Anwendung Adaption

Abbildung 25: Anwendung von Standard- und benutzerdefinierten Szenarien

6.3 Szenarien-Beschreibungen

6.3.1 Erläuterung der Szenario-Beschreibung

Sowohl in diesem Referenzhandbuch, als auch in HERMES Online gibt es für jedes Szenario eine rudimentäre Beschreibung der Dienlichkeit des jeweiligen Szenarios:

Anwendbarkeit

Beschreibung von konkreten Projektenkriterien, für die das Szenario sich eignet.

Module

Aufzählung und graphische Zusammenstellung aller Module entlang der Lösungsentste-

hung – das Modul Grundlagen wird zwar vollständigkeitshalber graphisch angezeigt, ist jedoch in keinem Szenario enthalten.

Aufgaben (nur online verfügbar) Tabellarische Darstellung der Aufgaben nach Projektphasen, wobei die Entscheidungsauf-

gaben farblich (pink) hervorgehoben sind.

Ergebnisse (nur online verfügbar)

Ablaufdiagramm des Projekts nach Projektphasen mit Ergebnissen.

6.4 Szenarien-Verzeichnis

6.4.1 Dienstleistung/Produkt Szenarien

6.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 für die spezifischen Bedürfnisse eines oder mehrerer Fachbereiche (Anwenderbedürfnisse) entwickelt und bereitgestellt wird.

Beispiele:

Vorbereiten und Durchführen eines grossen Anlasses

Entwickeln einer Methode, eines Standards

Beschaffung und Einführung einer SaaS-Lösung (Software as a Service/Cloud-Lösung),

ohne technische Integration

Module

Das Szenario Dienstleistung/Produkt Entwicklung besteht aus folgenden, in der Abbildung 26

aufgeführten Modulen:

Projektsteuerung

Projektführung

Organisation

163 / 202

SZ

EN

AR

IEN

Produkt


Das Szenario kann weiter an das konkrete Projekt angepasst werden.


Projektführung

Ausführung

Führung


agil

klassisch

Umsetzung


Organisation

Produkt

Projektgrundlagen

Projektsteuerung

Projektführung


Abbildung 26: Module im Kontext des Szenarios Dienstleistung/Produkt Entwicklung

6.4.1.2 Dienstleistung/Produkt Adaption

Anwendbarkeit

Das Szenario Standard Dienstleistung/Produkt Adaption unterstützt die Durchführung jener Projekte, in denen ein im Markt verfügbares Produkt oder eine Dienstleistung beschafft und

in der Organisation integriert wird.

Module

Das Szenario Dienstleistung/Produkt Adaption besteht aus folgenden, in der Abbildung 27 aufgeführten Modulen:

Projektsteuerung

Projektführung

Beschaffung

Organisation

Produkt



Beschaffung


Projektführung

Ausführung

Führung


agil

klassisch

Umsetzung


Organisation

Produkt

Projektgrundlagen

Projektsteuerung

Projektführung


Abbildung 27: Module im Kontext des Szenarios Dienstleistung/Produkt Adaption

164 / 202

SZ

EN

AR

IEN

6.4.2 Informatik Szenarien

6.4.2.1 IT-Anwendung Entwicklung

Anwendbarkeit

Das Szenario IT-Anwendung Entwicklung unterstützt die Durchführung jener Projekte, in de-

nen eine neue IT-Anwendung für die spezifischen Bedürfnisse eines oder mehrerer Fachbe-reiche (Anwenderbedürfnisse) entwickelt oder eine bestehende IT-Anwendung weiterentwi-

ckelt und sowohl technisch als auch organisatorisch integriert wird.

Module

Das Szenario IT-Anwendung Entwicklung besteht aus folgenden, in der Abbildung 28 aufge-führten Modulen:

Projektsteuerung

Projektführung

Organisation

IT-System

Tests


IT-Migration

IT-Betrieb

ISDS

Das Szenario kann weiter an das konkrete Projekt angepasst werden. Ist beispielsweise keine Ablösung eines Altsystems notwendig oder ändert im Rahmen einer Weiterentwicklung keine Datenstruktur, kann das Modul IT-Migration einfach weggelassen werden.


Projektführung

Ausführung

Führung

Tests


IT-Migration

IT-Betrieb

ISDS

agil

klassisch

Organisation

IT-System

Projektgrundlagen

Umsetzung


Projektsteuerung

Projektführung


Abbildung 28: Module im Kontext des Szenarios IT-Anwendung Entwicklung

6.4.2.2 IT-Anwendung Adaption

Anwendbarkeit

Das Szenario IT-Anwendung Adaption unterstützt die Durchführung jener Projekte, in denen

eine im Markt verfügbare IT-Anwendung beschafft und sowohl technisch als auch organisa-torisch integriert wird.

Module

Das Szenario IT-Anwendung Adaption besteht aus folgenden, in der Abbildung 29 aufgeführ-

ten Modulen:

165 / 202

SZ

EN

AR

IEN

Projektsteuerung

Projektführung

Beschaffung

Organisation

IT-System

Tests


IT-Migration

IT-Betrieb

ISDS

Das Szenario kann weiter an das konkrete Projekt angepasst werden. Ist beispielsweise keine Ablösung eines Altsystems notwendig, kann das Modul IT-Migration einfach weggelassen werden.

Beschaffung


Projektführung

Ausführung

Führung

Tests


IT-Migration

IT-Betrieb

ISDS

agil

klassisch

Umsetzung


Organisation

IT-System

Projektgrundlagen

Projektsteuerung

Projektführung


Abbildung 29: Module im Kontext des Szenarios IT-Anwendung Adaption

6.4.2.3 IT-Infrastruktur

Anwendbarkeit

Das Szenario IT-Infrastruktur unterstützt die Durchführung jener Projekte, in denen eine be-stehende IT-Infrastruktur ohne Anpassung der Geschäfts- und Supportprozesse erweitert wird.

Beispiele:

Ausbau einer Serverfarm

Ausbau eines IT-Netzwerks

Module

Das Szenario IT-Infrastruktur besteht aus folgenden, in der Abbildung 30 aufgeführten Mo-dulen:

Projektsteuerung

Projektführung

Tests


IT-Migration

IT-Betrieb

166 / 202

SZ

EN

AR

IEN

Das Szenario kann weiter an das konkrete Projekt angepasst werden. Ändert bei der Anpas-sung der bestehenden Infrastruktur keine Datenstruktur, kann das Modul IT-Migration einfach

weggelassen werden.


Projektführung

Ausführung

Führung

IT-Migration

IT-Betrieb

agil

klassisch

Umsetzung


Tests


Projektgrundlagen

Projektsteuerung

Projektführung


Abbildung 30: Module im Kontext des Szenarios IT-Infrastruktur

6.4.3 Organisation/Betriebswirtschaft Szenarien

6.4.3.1 Organisationsanpassung

Anwendbarkeit

Das Szenario Organisationsanpassung unterstützt die Durchführung jener Projekte, in denen die Aufbau- und Ablauforganisation einer Organisationseinheit angepasst wird.

Beispiele:

Umzug, Anpassung oder Schaffung einer Organisation

Fusion von Organisationen

Outsourcing von Dienstleistungen in ein Service-Center

Module

Das Szenario Organisationsanpassung besteht aus folgenden, in der Abbildung 31 aufgeführ-ten Modulen:

Projektsteuerung

Projektführung

Organisation




Projektführung

Ausführung

Führung

agil

klassisch

Umsetzung


Organisation


Projektgrundlagen

Projektsteuerung

Projektführung


Abbildung 31: Module im Kontext des Szenarios Organisationsanpassung

167 / 202

AN

WEN

DU

NG

HIN

WEIS

E Z

UR

7 Hinweise zur Anwendung

7.1 Einleitung

In HERMES stehen die Ergebnisse im Zentrum. Sie werden mit anderen Methodenelementen wie Aufgaben oder Rollen in Beziehung gesetzt und manche Ergebnisse werden bei der An-wendung durch Dokumentvorlagen ergänzt. Eine eigentliche Visualisierung der Projektpro-

zesse steht nicht im Vordergrund.

Dieses Kapitel hilft, HERMES in seiner neuen Form richtig anzuwenden. Um die Anwender bei

der Nutzung von HERMES zu unterstützen, wurden in diesem Kapitel Hinweise zusammenge-stellt, die zum Beispiel ein vertieftes Verständnis für HERMES ermöglichen, Anwendungsfälle

erläutern oder fallspezifisch auch eine Art Leitfaden liefern.

7.2 Hinweise-Übersicht

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

HERMES klassisch, agil oder hybrid?

Selbstbestimmung der Anwender über das Projekt

Finanzielle Steuerung und Führung

Anwendungsfälle Planung

Realisierungseinheiten

Anforderungen an die Lösung

Anwendung mit anderen Methoden und Praktiken

Einführung von HERMES in die Organisation

Tabelle 30: Hinweise zur Anwendung pro Kategorie

7.3 Hinweise-Beschreibungen

7.3.1 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 Hinweise-Verzeichnis

7.4.1 Governance

7.4.1.1 Allgemeines

Unter Governance wird allgemein die «verantwortungsvolle Unternehmungsführung und -kontrolle» verstanden. Sie muss insbesondere durch das Management der Stammorganisa-tion umgesetzt werden.

168 / 202

AN

WEN

DU

NG

HIN

WEIS

E Z

UR

Die Projekt-Governance ist ein Teil der Unternehmens-Governance. Die folgenden Kennzei-chen guter Projekt-Governance stellen Anforderungen an die Projektsteuerung und Projekt-

durchführung dar:

effektive und funktionsfähige Projektplanung, -steuerung und -führung

konstruktive Zusammenarbeit von Projektorganisation und Stammorganisation

Berücksichtigung der Stakeholderinteressen

Abstimmung der Projektziele mit Strategien und Zielen der Stammorganisation

solide Basis für richtige, effiziente und transparente Entscheidungen

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 Projektinfrastruktur

effizienter und nachhaltiger Ressourceneinsatz

HERMES Projektmanagement ist darauf ausgerichtet, eine gute Projekt-Governance zu ge-währleisten.

7.4.1.2 Unternehmensprozesse und HERMES

Unternehmen betreiben einerseits ihr operatives Geschäft und verändern sich andererseits kontinuierlich, um aktuellen und zukünftigen Herausforderungen gewachsen zu sein. Wie die Abbildung 32 zeigt, verfügt eine Unternehmung über Prozesse und Methoden, die

die Erstellung der Unternehmensplanung unterstützen;

die Umsetzung der Unternehmensplanung begleiten; und

die Nutzung der Ergebnisse sicherstellen.

Anw

end

er

Ers

telle

r/B

etr

eib

er

Leitung

Controlling & Vorgabestellen

Geschäftsprozess-verantwortlicher

Anwendungs-verantwortlicher

Betriebs-verantwortlicher

Unternehmens-planung

Account Manager

Umsetzung der Unternehmensplanung

Projektleiter

Auftraggeber

Anwendervertreter

Teilprojektleiter

Anwendervertreter

Nutzung derErgebnisse

Umsetzung


Abbildung 32: Unternehmensprozesse im Lichte von HERMES

7.4.1.3 Erstellung der Unternehmensplanung

Grundzüge der Unternehmensplanung

Mit der Erstellung der Unternehmensplanung werden die Vorhaben priorisiert und die nötigen Ressourcen für die Umsetzung geplant, damit sie ausreichend zur Verfügung stehen.

Die Unternehmensplanung basiert auf einer Skizzierung der Bedürfnisse aus einem Geschäfts-prozess, aus Ideen für zukünftige Lösungen oder strategischen Vorhaben. Diese groben Skiz-

zen werden häufig als ‹Studie› bezeichnet und verursachen im Normalfall keine externen Kos-ten.

Gehören die Partner derselben Organisation an (z. B. einer öffentlichen Verwaltung), stehen sie bereits während der Unternehmensplanung miteinander in Kontakt. Zwischen dem Ac-count-Manager des Erstellers bzw. Betreibers und der Leitung des Anwenders werden je nach

169 / 202

AN

WEN

DU

NG

HIN

WEIS

E Z

UR

Art der Geschäftsbeziehungen frühzeitig Informationen ausgetauscht, damit die notwendigen Ressourcen bei allen betroffenen Partnern ausreichend verfügbar sind. Dabei werden die or-

ganisationsspezifischen Vorgaben berücksichtigt. Auf der Grundlage der Unternehmenspla-nung entscheidet die Stammorganisation, welche Projekte initialisiert werden. Ab dem Ent-

scheid Projektinitialisierungsfreigabe wird das Projekt nach HERMES abgewickelt und in das Projektportfolio der Stammorganisation aufgenommen.

Umsetzung der Unternehmensplanung

Bei der Umsetzung der Unternehmensplanung werden mittels Projekten bedeutende Verän-

derungen realisiert. Wenig bedeutende, nicht risikobehaftete Vorhaben von geringer Kom-plexität werden oft mit Aufträgen umgesetzt. Die Definition, was ein Projekt ist, hängt stark

von der jeweiligen Unternehmung ab und muss durch diese verbindlich geregelt werden. HERMES Projektmanagement unterstützt die Umsetzung der Unternehmensplanung mittels

Projekten.

HERMES regelt die Zusammenarbeit der Partner im Projekt und unterstützt sie bei Initialisie-rung, Konzeption, Realisierung und Einführung des Ergebnisses und bei der Bereitstellung der

nötigen Betriebsorganisation. HERMES beschreibt die Rollen, Ergebnisse und Aufgaben der Partner Anwender, Ersteller und Betreiber und sorgt für die nötige Klarheit in der Zusammen-

arbeit. Während der Phase Initialisierung werden die Skizzen oder Studien der Unternehmens-planung vertieft. Dabei werden Varianten erarbeitet und bewertet. Für die gewählte Variante

wird ein Umsetzungsauftrag erarbeitet, damit die Stammorganisation am Ende der Phase Ini-tialisierung entscheiden kann, wie das Projekt angegangen und ob es überhaupt für die Um-

setzung freigegeben wird.

Das Projekt steht mit der Stammorganisation des Anwenders in enger Beziehung. Die Stam-morganisation ernennt und besetzt die entscheidenden Rollen des Projekts, den Auftragge-

ber, den Projektleiter und den Anwendervertreter aus ihren eigenen Reihen. Die Leitung sowie die Controlling- 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 Rekrutierung der Stakeholder und

deren Information und der Anwendervertreter für deren Einbindung in das Projekt und für ihre Mitwirkung.

Nutzung der Ergebnisse

Die Nutzung des Ergebnisses aus einem Projekt beginnt mit der Betriebsaufnahme. Die Vo-raussetzungen für die nachhaltige Nutzung werden im Projekt geschaffen. Das Projekt wird abgeschlossen, wenn der Betrieb stabil erfolgt und die Ergebnisse abgenommen sind. Die

Partner stellen beim Wechsel zur Anwendungsorganisation sicher, dass die für die Nutzung benötigten Rollen besetzt sind. Dazu gehören oft die Rollen des Anwendervertreters, des Ge-

schäftsprozessverantwortlichen, des Anwendungsverantwortlichen und des Betriebsverant-wortlichen. Das Projekt wandelt sich zur Anwendung und wechselt vom Projekt- ins Anwen-

dungsportfolio. Führt die Stammorganisation sowohl für Projekte als auch für Anwendungen das gleiche Portfolio, ändert lediglich der Status von Projekt zu Anwendung. Die Leitung des

Anwenders und der Account-Manager des Erstellers bzw. Betreibers bleiben auch während der Periode der Nutzung in Verbindung. Die Erfolgskontrolle, ob die Projektziele letztlich er-

reicht wurden, geschieht während der Nutzung.

7.4.1.4 Nachvollziehbarkeit der gewählten Vorgehensweise

Zur verantwortungsvollen Projektdurchführung gehört auch die Wahl der gewählten Vorge-hensweise. Die Entscheidung, ob Projekte klassisch oder agil angegangen werden, muss auf der Projektebene erfolgen, da jedes Vorhaben individuelle Charakteristiken aufweist. Auch

mehrere IT-Projekte nebeneinander können durchaus unterschiedliche Rahmenbedingungen haben, die zu unterschiedlichen Prämissen bei der Suche der geeigneten Vorgehensweise

führen.

Für die Wahl der Vorgehensweise können verschiedene Methoden und Techniken verwendet

werden. Allerdings müssen die Vorgaben von Controlling- und Vorgabestellen eingehalten werden. Die Wahl der Vorgehensweise muss nachvollziehbar sein.

170 / 202

AN

WEN

DU

NG

HIN

WEIS

E Z

UR

7.4.1.5 Integration in das Projektportfolio

Wie die Abbildung 33 zeigt, ist das Projektportfolio in der Stammorganisation oft

a) im Kompetenzzentrum Projektmanagement oder

b) bei den Controlling- und Vorgabestellen

angesiedelt.

Stammorganisation

Leitung Kompetenzzentrum

Projektmanagement

Controlling- und

Vorgabestellen

a) oder b)

Projektportfolio

Projektportfolio

Projekt 1

Projekt 2

Projekt 3

Projekt 4

Projekt 5

Projekt n







Abbildung 33: Zwei übliche Unterstellungsvarianten des Portfolios

Die Governance-Anforderung eines effizienten und nachhaltigen Ressourceneinsatzes be-dingt, dass beurteilt wird, ob ein Projekt gestartet und seine Umsetzung 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 bzw. gestartet werden, ob die Projekte umgesetzt, angehalten und beendet werden.

HERMES unterstützt die Integration der Projekte sowie der Anwendungen in das Portfolioma-

nagement unter anderem mit den Phasen und Releases sowie mit Meilensteinen. Diese un-terstützen eine transparente Steuerung der Projekte. An den Meilensteinen sind Quality Gates

definiert, wo die notwendigen Prüfungen mit der Checkliste unterstützt und nachweisbar do-kumentiert werden.

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.

171 / 202

AN

WEN

DU

NG

HIN

WEIS

E Z

UR

Wie die Abbildung 34 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.

Steuerung

Ausführung

Führung

Steuerung

Ausführung

Führung

Stamm-organisation





klassisch

hybrid

Phasen-bericht

Phasen-bericht


Lösungsarchitektur

Umsetzungs-auftrag


Release-bericht

Lösungsarchitektur


Initialisierung Abschluss

Release-bericht

Umsetzungs-auftrag

UmsetzungRelease 2Release 1 Release n

klassisch

agil

Abbildung 34: Gekapselte, gegenüber der Stammorganisation einheitliche Reporting Struktur

Die folgenden Ergebnisse fallen beim Reporting an:

Projektstatusbericht 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).

Phasenbericht (klassisch)

Am Ende der Phasen Konzept und Realisierung werden die Ergebnisse der Phase und die

Planung des weiteren Projektverlaufs für den Auftraggeber so aufbereitet, dass er den Entscheid zum weiteren Vorgehen (in der Regel zur Phasenfreigabe) fällen kann.

Releasebericht (agil) Während der Phase Umsetzung werden am Ende jedes Releases die Ergebnisse des Re-

leases für den Auftraggeber so aufbereitet, dass er über den Fortschritt sowie den Erfolg des Releases sowie der gesamten Entwicklung informiert ist. Wurde in der Initialisierungs-

phase festgelegt, dass der Entscheid Releasefreigabe jeweils getroffen werden muss, dient der Releasebericht der Entscheidungsfindung.


Am Ende der Phase Abschluss wird die Projektschlussbeurteilung erarbeitet. Sie dient der kontinuierlichen Verbesserung in der Stammorganisation aufgrund der gemachten Erfah-

rungen.

Fachliche Ergebnisse der Projektausführung

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 die gute Projekt-Governance erfüllt.

172 / 202

AN

WEN

DU

NG

HIN

WEIS

E Z

UR

Nachfolgend ist für jede Anforderung beschrieben, wie die einzelnen HERMES-Methodenele-mente deren Erfüllung unterstützen.

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 definierten Rollen und den Part-nern 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 Rolle Projektausschuss defi-niert. Sie ermöglicht die Integration der Stakeholder in die Projektorganisation, auf der

Hierarchieebene Steuerung. o Zur Unterstützung der Rolle des Projektleiters ist eine Rolle Fachausschuss definiert.

Dadurch können die Stakeholder sowohl im Führungsbereich, als auch auf der fachli-chen Ebene in die Projektorganisation eingebunden 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 Umsetzungsauftrag 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. Das Reporting ist weiter unten

beschrieben.

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.

Ergebnisse

Die Stakeholderliste und die Stakeholderinteressen werden erstmals in der Phase Initiali-

sierung erstellt und im Projektablauf kontinuierlich weitergeführt.

173 / 202

AN

WEN

DU

NG

HIN

WEIS

E Z

UR

Zusammenarbeit von Projektorganisation und Stammorganisation

HERMES und Portfoliomanagement

HERMES unterstützt die Integration der Projekte in das Portfoliomanagement. Siehe dazu die nachstehenden Erläuterungen.

Meilensteine Die Meilensteine (mit Quality Gates) unterstützen die Zusammenarbeit.

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, Umsetzungsfreigabe, 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 Projektziele mit Strategie und Zielen der Stammorganisation

Phasen bzw. Releases Vor der Umsetzungsfreigabe am Ende der Phase Initialisierung und der jeweiligen Pha-

senfreigabe bzw. der Releasefreigabe werden die Projektziele im Rahmen der jeweiligen Entscheidungsaufgaben 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 der Projektdurchführung

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-Vergleiche durchgeführt 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.

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 Releases die Risiken als nicht tragbar beurteilt,

174 / 202

AN

WEN

DU

NG

HIN

WEIS

E Z

UR

muss über das weitere Vorgehen befunden und das Projekt eventuell abgebrochen wer-den.

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 Projektplanung.

Phase Initialisierung

Am Ende der Phase Initialisierung wird geprüft, ob es sinnvoll ist, die Umsetzung zu star-

ten. 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 und Meilensteine

Am Ende der Phasen oder am Ende der Releases wird im Rahmen der Umsetzung geprüft, ob es sinnvoll ist, das Projekt weiterzuführen. Auch hier sind mögliche Gründe für einen

Abbruch die zu hohen 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 Allgemeines

Nachhaltigkeitsverständnis

Die Schweiz stützt sich auf das Nachhaltigkeitsverständnis der Weltkommission für Umwelt und Entwicklung («Brundtland-Kommission»). Diese definiert, dass die nachhaltige Entwick-lung zwar die Bedürfnisse der Gegenwart befriedigen soll, jedoch die Bedürfnisse der künfti-

gen Generationen nicht gefährden darf. Dabei sollen die wirtschaftlichen, gesellschaftlichen und ökologischen Vorgänge miteinander in Einklang gebracht werden.

Insofern ist nachhaltige Entwicklung in der Schweiz, zumindest auf der Verwaltungsebene, keine freiwillige Aufgabe. Die Bundesverfassung erklärt zum Beispiel die nachhaltige Entwick-lung zu einem Staatsziel und fordert «ein auf Dauer ausgewogenes Verhältnis zwischen der

Natur und ihrer Erneuerungsfähigkeit einerseits und ihrer Beanspruchung durch den Men-schen anderseits» anzustreben.

Die Auswirkungen des heutigen Handelns auf die Zukunft müssen folglich einberechnet wer-den (Generationen von heute und morgen). So soll zum Beispiel auch der Umwelt- und Res-

sourcenverbrauch unter Wahrung der wirtschaftlichen Leistungsfähigkeit und des sozialen Zu-sammenhalts auf ein dauerhaft tragbares Niveau gesenkt werden. Alle diese Nachhaltigkeits-

forderungen betreffen auch die Projekte. Diese dürfen sich bei der Definition der Projektziele nicht lediglich auf die Wirtschaftlichkeit beschränken, sondern müssen auch die Gesellschaft

und die Umwelt einbeziehen. Insofern hat ein erfolgreiches Projektmanagement auch positive Auswirkungen im Bereich der nachhaltigen Entwicklung.

Spezifisch im Bereich der Informations- und Kommunikationstechnologien stehen aus Nach-haltigkeitssicht in einer Lebenszyklusbetrachtung vor allem die Energie- und Ressourceneffi-zienz sowie die Arbeitsbedingungen in den Produktionsländern im Vordergrund. Ein beson-

deres Augenmerk gilt dabei dem Beschaffungswesen durch das Definieren von ökologischen und sozialen Zuschlagskriterien. Für Informationstechnologien spielen zusätzlich die langfris-

tige Sicherung der Daten, der Datenschutz und die Datenintegrität sowie der Zugang zu Wis-sen eine wichtige Rolle.

175 / 202

AN

WEN

DU

NG

HIN

WEIS

E Z

UR

7.4.2.2 Nachhaltigkeit mit HERMES

HERMES als Gesamtprodukt

HERMES unterstützt die Nachhaltigkeit der Lösung. Nachfolgend sind die HERMES Metho-denelemente im Hinblick auf Nachhaltigkeitsaspekte beschrieben.

Phasen

Wichtig ist die Verankerung von Nachhaltigkeitszielen bei der Definition der strategischen Projektziele. Diese fliessen in der Phase Initialisierung als Vorgabe in das Projekt ein.

Am Ende der Phase Initialisierung wird der Entscheid Umsetzungsfreigabe getroffen. Für die Stammorganisation und den Auftraggeber ist eines der Entscheidungskriterien, ob und

wie die Vorgaben und Ziele zur Nachhaltigkeit durch das Projekt erfüllt werden. Nicht nachhaltige Projekte werden dadurch gar nicht erst zur Umsetzung 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 (Variantenwahl)

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 Umsetzungsfreigabe, 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.

176 / 202

AN

WEN

DU

NG

HIN

WEIS

E Z

UR

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 Ziele und bereinigt Zielkonflikte. 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. 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 schliesst vorhandene Fähigkeitslücken.

Anwendervertreter

o Integriert die Nachhaltigkeit in den Lösungsanforderungen und priorisiert sie. o Verankert das Bewusstsein zur Nachhaltigkeit bei der Lösungsentwicklung.

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 Bring die Nachhaltigkeit in den Beschaffungsprozess ein.

o Stellt sicher, dass bei der Anforderungsdefinition die Anforderungen 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 Nachhaltigkeit 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.


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:

Controlling- und Vorgabestellen o Beurteilen die Einhaltung der Vorgaben und die Erreichung der Nachhaltigkeitsziele.

o Prüfen das Produktkonzept. o Prüfen die Lösungsarchitekturarchitektur.

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.

177 / 202

AN

WEN

DU

NG

HIN

WEIS

E Z

UR

7.4.3 Projekt– und Entwicklungsmanagement

7.4.3.1 HERMES klassisch, agil oder hybrid?

HERMES 2021 Projektmanagement bietet für die Lösungsentstehung das klassische, das agile und für Spezialfälle auch das hybride Entwicklungsmanagement an. Das klassische Entwick-lungsmanagement wird durch das klassische Projektmanagement unterstützt, das agile und

hybride hingegen durch das hybride Projektmanagement. Die Abbildung 35 zeigt die von HERMES bereitgestellte klassische und hybride Projektmanagementvariante.


Realisierung EinführungKonzept

Umsetzung

Hybrides Projektmanagement


Abbildung 35: HERMES bietet klassisches und hybrides Projektmanagement an

7.4.3.2 HERMES Projektmanagement klassisch

Bei klassischer Vorgehensweise wird in HERMES 2021 Projektmanagement voll auf das tradi-tionelle, jahrzehntelang bewährte phasenweise Projektmanagement gesetzt. Der einzige we-

sentliche Unterschied bildet die zusätzlichen Phase Abschluss, um die Einheitlichkeit der Pro-jekte nach aussen zu gewährleisten und die Schnittstellen für das Controlling und innerhalb

von Programmen und Portfolios gleich zu gestallten. Darüber hinaus soll der Übergang zur Anwendungs- und Betriebsorganisation unabhängig vom Vorgehen gleich gestaltet bleiben.

Allerdings gibt es Organisationseinheiten, die (noch) keine agile Entwicklung durchführen und deshalb für sie die Phase Abschluss nicht immer viel Sinn macht. Die Abbildung 36 zeigt ei-nerseits den klassischen Teil des HERMES 2021 Phasenmodells, andererseits eine abgekürzte

Modellvariante, bei der die Phasenfreigabe Abschluss umgangen werden kann. Allerdings ist diese Phasenmodellvariante nur in rein klassischer Umgebung zulässig.


Initialisierung Einführung & AbschlussRealisierungKonzept

AbschlussInitialisierungInitialisierung AbschlussRealisierung EinführungKonzept

Einführung & AbschlussInitialisierung RealisierungKonzept

Abbildung 36: HERMES 2021 Phasenmodell in rein klassischer Entwicklungsumgebung

7.4.3.3 HERMES Projektmanagement hybrid

Beim agilen Vorgehen kommt hybrides Projektmanagement zum Tragen. HERMES Projekt-management unterscheidet nicht zwischen einem klassischen und agilen Projektmanagement,

sondern zwischen einem klassischen und hybriden. Das hybride HERMES Projektmanagement ist eine Kombination von klassischem Projektmanagement und agilen Techniken.

Agile Methoden, wie z.B. SCRUM, gehören nicht zu Projektmanagementmethoden, sondern zu Entwicklungsmanagementmethoden. Weil Projekte unter HERMES von Anfang an gewisse Rahmenbedingungen erfüllen müssen, wie zum Beispiel die Einhaltung der Governance, die

reibungslose Einbettung des Vorhabens in die bestehende Planungs- und Controlling Pro-zesse der Stammorganisation (Grundmission von HERMES) oder die gemeinsame Sprache

bzw. einheitliche Terminologie, erfüllt ein reines agile Vorgehen diese an HERMES gestellten Anforderungen nicht. Deshalb wird die Agile Methode in ein dafür geeignetes hybrides Pro-

jektmanagement eingebettet. Die Abbildung 37 zeigt den hybriden Teil des HERMES 2021 Phasenmodells mit agiler Entwicklung.


Hybrides Projektmanagement

Agiles Entwicklungsmanagement

Umsetzung

Abbildung 37: HERMES 2021 Phasenmodell mit agiler Entwicklung

178 / 202

AN

WEN

DU

NG

HIN

WEIS

E Z

UR

Das Rollenverständnis im hybriden Projektmanagement lehnt sich sowohl an das klassische Projektmanagement, als auch an die agilen Techniken an. So können alle Rollen vertreten sein:

aus dem klassischen Projektmanagement: o Auftraggeber

o Projektleiter o Fachspezialisten

aus den agilen Techniken: o Anwendervertreter (Product Owner) o Iterationsleiter (Scrum Master) o Fachspezialisten

Der Auftraggeber samt Projektausschuss und Qualitäts- und Risikomanager auf der Hierar-chieebene Steuerung und der Projektleiter samt Fachausschuss und Projektunterstützung auf der Hierarchieebene Führung arbeiten nach dem klassischen Projektmanagement, das Ent-

wicklungsteam auf der Hierarchieebene Ausführung nach den agilen Techniken.

7.4.3.4 HERMES Entwicklungsmanagement hybrid

Die Entwicklung im Projekt, also die Lösungsentstehung, wird entweder mit dem klassischen oder mit dem agilen Vorgehen abgewickelt. Hermes unterscheidet daher zwischen dem klas-sischen und dem agilen Entwicklungsmanagement. Dennoch gibt es in der Praxis Fälle, in

denen ein Projekt mit einer Kombination aus beiden Vorgehensarten abgewickelt werden soll. Die Gründe sind mannigfaltig. Es gibt Organisationen, die zuerst ein Konzept erstellen und es

dann agil realisieren und einführen. Und wiederum andere, die die gesamte Entwicklung agil angehen, aber dann klassisch auf einmal einführen. Ob ein solches Vorgehen Sinn macht oder

nicht, ist situativ zu beurteilen.

Die Frage stellt sich daher eher, ob HERMES auch dieses "hybride" Vorgehen unterstützen kann. Die Antwort lautet ja, denn alle Methodenelemente sind in HERMES aufeinander abge-

stimmt. Allerdings setzt dies ein entsprechendes Tailoring am Ende der Initialisierungsphase voraus, denn das Hybride muss den jeweilige Bedürfnissen angepasst werden. Die Abbil-

dung 38 zeigt zwei denkbare Varianten eines hybriden Entwicklungsvorgehens.


RealisierungKonzept

Umsetzung

Hybride Variante 1

Hybride Variante 2

Einführung

Abbildung 38: Hybrides Vorgehen - Beispielvarianten

7.4.4 Selbstbestimmung der Anwender über das Projekt

Die Stammorganisation stellt als Inhaberin des Projekts die finanziellen Ressourcen für das Projekt zur Verfügung. Dies gibt ihr und ihrer Partnerrolle Anwender auch das Recht, frei und

ohne Einmischung anderer Partnergruppen über die Projektstruktur, die angewandte Ma-nagementmethoden und über den Projektverlauf zu entscheiden.

In Bezug auf die Selbstbestimmung über das Projekt sind die folgenden Projektrollen beson-ders relevant:

Auftraggeber

o Legt den Rahmen für die Projektinitialisierung und für die Umsetzung fest. o Bestimmt die Rollenbesetzung, insbesondere der Partnergruppe Anwender.

o Entscheidet über die Art der 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 Lichte der Stammorganisation.

179 / 202

AN

WEN

DU

NG

HIN

WEIS

E Z

UR

o Unterstützt den Projektleiter bei der Wahrung der Interessen der Stammorganisation und beim Reporting.

In der Stammorganisation selbst sind im Speziellen die folgenden Rollengruppen mit der Selbstbestimmung konfrontiert:


o Beurteilen die Einhaltung der Vorgaben betreffend das Projektvorgehen im Umset-zungsauftrag.

Leitung o Prüft, ob die Vorgaben und Ziele der Stammorganisation in Bezug auf das Projektvor-

gehen erfüllt sind.

7.4.5 Finanzielle Steuerung und Führung

7.4.5.1 Allgemeines

Die finanzielle Steuerung und Führung des Projekts beginnt mit dem Entscheid Projektinitia-lisierungsfreigabe und endet mit dem Entscheid Projektabschluss, im Notfall mit dem Ent-

scheid Projektabbruch.

7.4.5.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 Unter-fangen dar und wird durch das Projekt- oder über das Linienbudget finanziert. In die Wirt-

schaftlichkeitsbetrachtung des Projekts fliessen die Aufwände der Phase Initialisierung als Vor-leistung ein.

Die Planung des Ressourcenbedarfs und der Finanzierung erfolgt für das Gesamtprojekt. Ende Phase Initialisierung wird eine Gesamtplanung erstellt, die laufend überprüft und angepasst

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. Beim agilen Vorgehen hingegen werden Zahlen zu den Betriebs-kosten von Release zu Release sukzessive konkretisiert und releaseweise rapportiert. Die In-

vestitionskosten bzw. das gesamte Umsetzungsbudget sind im Umsetzungsauftrag fix defi-niert und werden nicht mehr geändert.

Die Betriebskosten werden während der Projektabwicklung über das Projektbudget finanziert, anschliessend über das Linienbudget.

7.4.5.3 Steuerung

Mit dem Entscheid Umsetzungsfreigabe wird das benötigte Investitionsbudget durch die Stammorganisation bewilligt. Der Auftraggeber übernimmt die Verantwortung dafür und gibt bei der klassischen Vorgehensweise die finanziellen Ressourcen phasenweise frei. Diese Frei-

gabe wird über die Entscheidungsaufgaben zur Phasenfreigabe gesteuert. Bei der agilen Vor-gehensweise erübrigt sich eine stufenweise Freigabe, die Finanzen sind für die ganze Umset-

zung fix definiert und werden einmalig mit dem Umsetzungsauftrag freigegeben.

Der Auftraggeber ist für die finanzielle Steuerung verantwortlich. Er erhält über das Reporting alle notwendigen Informationen, um den Projektstand und die Kostenentwicklung beurteilen

zu können. Im agilen Umfeld macht eine finanzielle Steuerung weniger Sinn, der Projekterfolg wird durch andere Instrumente gesichert.

Der Auftraggeber stellt die Wirtschaftlichkeit des Projekts sicher. Entsprechend steuert er die Projektkosten und die zukünftigen Betriebskosten.

Zur Unterstützung der Steuerung beauftragt er bei Bedarf einen unabhängigen Qualitäts- und Risikomanager.

7.4.5.4 Führung

Der Projektleiter ist verantwortlich für die finanzielle Führung des Projekts. Er führt die Pro-jektbuchhaltung und erarbeitet die Informationen für die Steuerung.

180 / 202

AN

WEN

DU

NG

HIN

WEIS

E Z

UR

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.6 Planung

7.4.6.1 Planungsbasis und das Vorgehen

Die Planung bildet die Grundlage für den effektiven und effizienten Einsatz der Ressourcen bei der Umsetzung. 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 Projektbetei-

ligten.

Nach der Erarbeitung der Studie mit den Zielen und dem Entscheid weiteres Vorgehen in der Phase Initialisierung ist der erste Schritt in der Umsetzungsplanung die Projektstrukturierung.

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

Projektstruktur vor, die für die Umsetzung übernommen und an die reale Umsetzungssitua-tion 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 im Prinzip alle Pläne, die im Projekt

anfallen. Er wird in der Phase Initialisierung erstellt und in nachfolgenden Phasen laufend nachgeführt.

Nach dem Entscheid Umsetzungsfreigabe trennen sich die Wege, wie die Planung klassisch und agil angegangen wird. In der klassischen Umsetzung wird durch den Projektleiter nach dem Prinzip der rollenden Planung geplant, in der agilen Umsetzung erfolgt die Planung au-

tonom durch das Entwicklungsteam.

7.4.6.2 Initiale Planung des Gesamtprojekts

In der Phase Initialisierung wird das Projekt gesamthaft geplant. Die Projektstrukturierung wird durchgeführt und die Ergebnisse des gesamten Projekts werden auf der Grundlage 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 Projektstrukturplan erarbeitet:

1. Studie mit Varianten erarbeiten. Für die gewählte Variante den Umfang und die Abgren-

zung festhalten

2. In HERMES online auf der Grundlage des Projektergebnisses:

a. Szenario wählen und bei Bedarf anpassen (im Rahmen der Studie).

b. Projektstrukturplan erstellen und exportieren.

c. Projektstrukturplan in den Projektmanagementplan integrieren.

3. Projektspezifische Ergebnisse und Aufgaben ergänzen

4. Rollen im Projektmanagementplan an das Projekt anpassen

Anschliessend wird der Projektmanagementplan mit den folgend aufgeführten Schritten er-arbeitet – sie müssen nicht zwingend in dieser Reihenfolge unternommen, sondern können mehrmals durchlaufen werden:

Risiken ermitteln und Massnahmen festlegen;

QS-Plan und Prüfplan erarbeiten;

Aufwandschätzungen für Ergebnisse vornehmen;

Abhängigkeiten ermitteln;

Terminplan erarbeiten (vgl. auch Releaseplan);

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;

181 / 202

AN

WEN

DU

NG

HIN

WEIS

E Z

UR

Einsatz von Ressourcen planen;

Kommunikationsplan erarbeiten;

Kostenplan erarbeiten;

Projektmanagementplan mit QS-Massnahme prüfen;

Projektmanagementplan mit Stakeholdern abstimmen und als Grundlage für Umset-zungsauftrag verifizieren.

7.4.6.3 Umsetzungsplanung klassisch

Vom Groben zu Detail

Die Unterscheidung nach Phasen und die Konkretisierung und Erweiterung der Vorgehens-komponente "vom Groben zu Detail" kommt aus dem Systems Engineering8 und ist eine der

Grundlagen der klassischen phasenweisen Vorgehensweise von HERMES. In der klassischen Umsetzung wird nach dem Prinzip der rollenden Planung geplant, gesteuert und geführt. Ge-

gen Ende der Phasen Konzept und Realisierung wird jeweils die nächste Phase vor dem Ent-scheid zur Phasenfreigabe detailliert geplant, und die grobe Planung wird überprüft.

Detailplanung der nächsten Phase

Die folgenden Aktivitäten werden ausgeführt:

Projektstrukturplan ü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 HERMES-Aufgabe können mehrere Arbeitspakete gebildet werden.

Aus einem Arbeitspaket resultieren eines oder mehrere Ergebnisse. Sie werden in Aktivi-

täten erarbeitet. Bei der Erstellung eines Arbeitspaketauftrags werden die in HERMES be-schriebenen Aktivitä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 keinesfalls gleich Null, diesbezüglich ist bereits zu Anfang der Initialisierungsphase eine, allerdings sehr grobe, Schätzung möglich. Mit dem

phasenweisen Vorgehen bzw. dem Vorgehen vom Groben zum Detail werden die Ergebnisse

8 Vgl. Fussnote 1, S. 9

182 / 202

AN

WEN

DU

NG

HIN

WEIS

E Z

UR

laufend konkretisiert. Entsprechend steigen die Kenntnisse, die Unsicherheit im Umsetzungs-verlauf sinkt und die Planungsgenauigkeit steigt. Die steigenden Kenntnisse (mit der Detail-

lierung der Ergebnisse) und die Planungsgenauigkeit stehen in einem direkten Zusammen-hang. Die zu einem bestimmten Zeitpunkt zu erreichende Planungsgenauigkeit gibt vor, wie

detailliert die Ergebnisse erarbeitet werden sollen.

Die Abbildung 39 zeigt die mit dem Projektverlauf steigenden Kenntnisse über die Lösung sowie die abnehmende Ungenauigkeit der Planung.

HERMES kann nicht vorgeben, wie genau 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ängig ist. Diese Vorgabe soll jedoch durch den Auftraggeber

und die Controlling- und Vorgabestellen der Stammorganisation gemacht werden.

Grundsätzlich sollen Schätzungen mit Angabe der Planungsgenauigkeit und darauf basierend

mit Reserven im Umsetzungsauftrag sowie im Projektmanagementplan ausgewiesen werden. Dazu müssen die Annahmen zu den Schätzungen dokumentiert sein, um die Anforderung der

Governance an die transparente Kommunikation zu erfüllen.

AbschlussInitialisierung Einführung RealisierungKonzept

Zeit

gering

hoch

Abbildung 39: Steigende Kenntnisse / abnehmende Planungsungenauigkeit

7.4.6.4 Umsetzungsplanung agil

In der agilen Umsetzung kommen andere Mechanismen zum Tragen, der Aspekt vom Groben zum Detail spielt sich in der sukzessiven Abarbeitung der Lösungsanforderungen bzw. im

Rahmen der Release- und Iterations-Abwicklung ab und erfolgt während der agilen Entwick-lung auf der Hierarchieebene Ausführung autonom durch das Entwicklungsteam. Die agile

Umsetzung richtet sich nach dem Releaseplan und den Lösungsanforderungen. Der Release-plan ist bei Bedarf mit dem Terminplan im Projektmanagementplan verknüpft. Eine über die

agile Releaseplanung weitergehende Planung erübrigt sich. Projektseitig beschränkt sich die Planung auf der Führungseben auf koordinierende Aspekte und wird erst wieder in der Phase

Abschluss aktiviert.

7.4.7 Realisierungseinheiten bei klassischer Vorgehensweise

Wenn die klassisch abgewickelte Lösungsentstehung eines IT-Vorhabens so komplex wird, dass die Realisierung des ganzen Umfangs auf einmal fraglich erscheint, oder wenn möglichst schnell erste Ergebnisse für die Nutzung geliefert werden sollen, können die Phasen Realisie-

rung und Einführung in mehreren Realisierungseinheiten abgewickelt werden.

Die klassische Vorgehensweise von HERMES 2021 Projektmanagement ermöglicht sowohl die

sequenzielle wie auch die zeitlich überlappte oder parallele Entwicklung in Realisierungsein-

183 / 202

AN

WEN

DU

NG

HIN

WEIS

E Z

UR

heiten. Die Freigabe der ersten Realisierungseinheit ist die eigentliche Phasenfreigabe Reali-sierung, die den regulären Abschluss der Phase Konzept voraussetzt. Jede Realisierungsein-

heit erstreckt sich über die beiden Phasen Realisierung und Einführung.

Eine Realisierungseinheit umfasst alle technischen und organisatorischen Ergebnisse des Pro-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.

Die Abbildung 40 zeigt schematisch zeitlich verschobene Realisierungseinheiten als eigen-ständige Kontrolleinheiten mit jeweils der Phase Realisierung und Einführung.

Projektdauer

Projektbeginn ProjektendeLösungsentstehung

Abschluss

Initialisierung Konzept

Realisierungseinheit 1

EinführungRealisierung





Realisierungseinheit n


Phasenfreigabe

Abschluss

Realisierungseinheiten

Abbildung 40: 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, Führung und Ausfüh-rung.

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.

Am Ende der letzten Realisierungseinheit wird über die Freigabe der nächsten Phase Ab-schluss entschieden. In der Phase Abschluss werden entsprechenden Aufgaben und Ergeb-

nissen durchgeführt. Dies umfasst auch die Projektschlussbeurteilung sämtlicher Realisie-rungseinheiten.

7.4.8 Anforderungen an die Lösung

Die Anforderungsdefinition und die Lösungsentstehung erfolgen entlang den Phasen. Die An-

forderungen werden nach dem Prinzip ‹vom Groben zum Detail› im Projektverlauf konkreti-siert.

In der Phase Initialisierung werden in der Studie die Ziele festgelegt und die ersten Groban-forderungen soweit erarbeitet, dass Lösungsvarianten gebildet, bewertet und evaluiert wer-den können. Auf der Grundlage der Variantenwahl wird letztlich der Umsetzungsauftrag er-

stellt.

184 / 202

AN

WEN

DU

NG

HIN

WEIS

E Z

UR

Die Grundlage für die Erarbeitung der Lösungsanforderungen bilden einerseits die Studie samt den Grobanforderungen und anderseits eine zu erarbeitende umfassende Situations-

analyse, die den konkreten und nachgewiesenen Handlungsbedarf aufzeigt. Die Erarbeitung der Situationsanalyse sowie der Lösungsanforderungen an ein Produkt oder ein System findet

erst nach der Umsetzungsfreigabe in der Lösungsentstehung statt und ist zwingend. Aufgrund der Erkenntnisse aus der Situationsanalyse werden die Anforderungen erhärtet und weiter

verfeinert und ergänzt, zum Schluss werden sie priorisiert.

Wird die Lösungsentstehung agil angegangen, werden die Lösungsanforderungen laufend an die Hand genommen. In einem ersten Schritt findet nach der Erarbeitung der Situationsana-

lyse die Formulierung der ersten initialen und priorisierten Lösungsanforderungen statt. An-schliessend erfolgt die Verwaltung der Lösungsanforderungen dynamisch und aufgrund von

Iterationen: Die fachlichen und technischen Anforderungen, aber auch die weiteren Elemente wie Eigenschaften, Funktionen, Optimierungen und Mängelkorrekturen werden weiter ausde-

finiert und sukzessive der Situation sowie den Erkenntnissen aus den vorangehenden Iterati-onen angepasst. Mit jeder Iteration werden die Lösungsarchitektur und die Detailspezifikation

weiter konkretisiert und das darauf basierende Lösungssystem oder Produkt sukzessive ent-wickelt.

Wird die Lösungsentstehung hingegen klassisch abgewickelt, ist die Erarbeitung der Lösungs-anforderungen abschliessend. Eine mögliche Anpassung oder Erweiterung der Lösungsanfor-derungen ist entlang des weiteren Projektverlaufs dennoch möglich. Sie erfolgt über das Än-

derungsmanagement.

7.4.9 Anwendung mit anderen Methoden und Praktiken

HERMES definiert die Ergebnisse und den generellen Ablauf des Projektes. HERMES gibt aber nicht vor, welche Methoden und Praktiken für die Erarbeitung der Ergebnisse eingesetzt wer-

den sollen.

Im Projektverlauf kommen somit ergänzend zu HERMES fachspezifische Methoden und Prak-tiken zum Einsatz (vgl. Abbildung 41). Anwender, Ersteller und Betreiber legen diese fest und

stimmen sie mit den Aufgaben, Ergebnissen und Rollen gemäss HERMES ab.


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 41: 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 zum Beispiel der Anwen-der spezifizieren, dass er für die Datenmodellierung das unentgeltliche und frei verfügbare

INTERLIS nutzt, oder der Entwickler für den Entwicklungsprozess die Methode SCRUM zum Einsatz bringt. Das setzt natürlich voraus, dass im Rahmen der Initialisierungsphase die agile

Vorgehensweise gewählt wurde.

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.

185 / 202

AN

WEN

DU

NG

HIN

WEIS

E Z

UR

7.4.10 Integration von HERMES in die Organisation

7.4.10.1 Allgemeines

Da jede Organisation 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 Organisation 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 wieder 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 das aktuell favorisierte SCRUM wird seiner Projektmanagementdefizite beraubt, da es kein Projekt-, sondern le-

diglich ein Entwicklungsmanagement ist. SCRUM passt sich dank HERMES voll der Orga-nisation 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.10.2 Vorgehen

Die Integration von HERMES in die Organisation erfolgt am besten über ein Projekt.

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 Geschäftsorganisation mit den Prozessen für Betrieb und Weiterent-wicklung des Projektmanagements erstellt und aktiviert.

Die Anpassung erfolgt durch das Kompetenzzentrum Projektmanagement.

7.4.10.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. mir INTERLIS)

Ergebnisdarstellungen der Geschäftsprozessmodellierung (z. B. mir BPMN)

Einbettung der agilen Entwicklungsmethode (z. B. mit SCRUM)

Praktiken zur Integration in den Betrieb (z. B. mit Hilfe von ITIL)

Die Methodenelemente werden bei Bedarf angepasst. Dabei sollen die folgenden Punkte be-

achtet werden:

Phasen und Meilensteine

Die definierten Phasen klassisch oder agil können nicht entfallen, sie können aber unter-teilt werden.

Die Meilensteine können nicht entfallen, richten sich aber nach der Vorgehensart und nach

186 / 202

AN

WEN

DU

NG

HIN

WEIS

E Z

UR

einer allfälligen Unterteilung der Phasen.

Die Bezeichnungen der Methodenelemente sollen nicht geändert werden.

Ergebnisse mit Dokumentvorlagen und Aufgaben

Minimal geforderten Dokumente (Ergebnisse) können nicht entfallen.

Mehrere Einzelergebnisse können zusammen in ein gemeinsames Dokument integriert

werden.

Ergebnisse können aufgeteilt werden. Für ein Ergebnis können mehrere Dokumentvorla-gen erstellt werden.

Zusätzliche Ergebnisse können definiert werden.

Ergebnisse können in der Dokumentvorlage differenzierter beschrieben werden.

HERMES-Dokumentvorlagen können durch organisationsspezifische Dokumentvorlagen, durch GEVER-Systeme und andere Lösungen ersetzt 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.

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 einem Partner 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.

187 / 202

Anhang A – Inhaltsverzeichnis Vorwort – Verantwortlicher HERMES-Methode ............................................................................................... 1

HERMES Revolution .................................................................................................................................................................. 1 Impressum .................................................................................................................................................................. 2 Prolog........................................................................................................................................................................... 3

«Kleine Taten, die man ausführt, sind besser als grosse, die man plant.» ......................................................................... 3 In eigener Sache ........................................................................................................................................................ 4

«Was ändert in HERMES 2021? ............................................................................................................................................. 4

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 HERMES Vorgehensmodell und Vorgehens-Layer .......................................................... 8 A.5 Agiles Entwicklungsmanagement mit HERMES .............................................................. 10 A.6 Positionierung Programmmanagement ........................................................................... 10 A.7 Hinweise zur Anwendung ...................................................................................................... 11

B HERMES Projektmanagement – Methodenelemente ..................................... 11 B.1 Phasen ......................................................................................................................................... 11 B.2 Ergebnisse ................................................................................................................................. 12 B.3 Aufgaben ................................................................................................................................... 13 B.4 Rollen.......................................................................................................................................... 13 B.5 Module ....................................................................................................................................... 13 B.6 Szenarien ................................................................................................................................... 14

C Datenmodell HERMES............................................................................................ 14

D Sichten auf das Projekt .......................................................................................... 15 D.1 Übersicht über die Sichten ................................................................................................... 15 D.2 Sicht des zeitlichen Ablaufs .................................................................................................. 17 D.3 Sicht der Partner ...................................................................................................................... 17 D.4 Sicht der Hierarchieebenen .................................................................................................. 17

1 Phasen........................................................................................................................ 19 1.1 Einleitung ................................................................................................................................... 19 1.1.1 Projektlebenszyklus .................................................................................................................. 19 1.1.2 Projektbeginn ............................................................................................................................ 19 1.1.3 Lösungsentstehung .................................................................................................................. 20 1.1.4 Projektende ................................................................................................................................ 20 1.2 Phasenübersicht ..................................................................................................................... 20 1.3 Erläuterung der Phasenbeschreibung ............................................................................... 21 1.4 Phasenverzeichnis .................................................................................................................. 22 1.4.1 Projektbeginn ............................................................................................................................ 22

1.4.1.1 Initialisierung ........................................................................................................................ 22 1.4.2 Lösungsentstehung klassisch .................................................................................................. 22

1.4.2.1 Konzept .................................................................................................................................. 22 1.4.2.2 Realisierung .......................................................................................................................... 23 1.4.2.3 Einführung ............................................................................................................................. 23

1.4.3 Lösungsentstehung agil ........................................................................................................... 24 1.4.3.1 Umsetzung ............................................................................................................................ 24

1.4.4 Projektende ................................................................................................................................ 25 1.4.4.1 Abschluss ............................................................................................................................... 25

2 Ergebnisse ................................................................................................................ 26 2.1 Einleitung .................................................................................................................................. 26 2.1.1 Ergebnispositionierung ............................................................................................................ 26 2.1.2 Spezielle Ergebnisse ................................................................................................................. 26

2.1.2.1 Checklisten ............................................................................................................................ 26

188 / 202

2.1.2.2 Minimal geforderte Dokumente ..................................................................................... 26 2.1.2.3 Meilensteine ......................................................................................................................... 26

2.2 Ergebnisse-Übersicht ............................................................................................................ 28 2.3 Erläuterung der Ergebnisbeschreibung ............................................................................ 28 2.4 Ergebnisse-Verzeichnis ......................................................................................................... 29 2.4.1 Dokumente ................................................................................................................................ 29

2.4.1.1 Abnahmeprotokoll .............................................................................................................. 29 2.4.1.2 Änderungsantrag ................................................................................................................ 29 2.4.1.3 Änderungsstatusliste .......................................................................................................... 30 2.4.1.4 Angebot ................................................................................................................................. 30 2.4.1.5 Angebotsprotokoll .............................................................................................................. 30 2.4.1.6 Anwendungshandbuch ...................................................................................................... 31 2.4.1.7 Arbeitsauftrag ....................................................................................................................... 31 2.4.1.8 Ausschreibungsunterlagen ................................................................................................ 31 2.4.1.9 Beschaffungsanalyse .......................................................................................................... 32 2.4.1.10 Betriebshandbuch ............................................................................................................... 33 2.4.1.11 Betriebskonzept ................................................................................................................... 33 2.4.1.12 Checklisten ............................................................................................................................ 34 2.4.1.13 Detailspezifikation ............................................................................................................... 35 2.4.1.14 Einführungskonzept ........................................................................................................... 35 2.4.1.15 Evaluationsbericht ............................................................................................................... 36 2.4.1.16 Geschäftsmodellbeschreibung ........................................................................................ 36 2.4.1.17 Inkrement .............................................................................................................................. 37 2.4.1.18 Integrations- und Installationsanleitung ....................................................................... 37 2.4.1.19 Integrationskonzept ........................................................................................................... 38 2.4.1.20 ISDS-Konzept ....................................................................................................................... 38 2.4.1.21 Liste Projektentscheide Führung ..................................................................................... 38 2.4.1.22 Liste Projektentscheide Steuerung ................................................................................. 38 2.4.1.23 Lösungsanforderungen ..................................................................................................... 39 2.4.1.24 Lösungsarchitektur ............................................................................................................. 40 2.4.1.25 Migrationskonzept .............................................................................................................. 40 2.4.1.26 Offertanfrage ........................................................................................................................ 40 2.4.1.27 Organisationsanforderungen ............................................................................................ 41 2.4.1.28 Organisationsbeschreibung .............................................................................................. 41 2.4.1.29 Organisationskonzept ......................................................................................................... 41 2.4.1.30 Phasenbericht ....................................................................................................................... 42 2.4.1.31 Produktdokumentation ..................................................................................................... 42 2.4.1.32 Produktkonzept ................................................................................................................... 42 2.4.1.33 Projekterfahrungen ............................................................................................................. 43 2.4.1.34 Projektinitialisierungsauftrag ............................................................................................ 43 2.4.1.35 Projektmanagementplan ................................................................................................... 43 2.4.1.36 Projektschlussbeurteilung ................................................................................................. 45 2.4.1.37 Projektstatusbericht ............................................................................................................ 45 2.4.1.38 Protokoll ................................................................................................................................ 45 2.4.1.39 Prototyp ................................................................................................................................. 46 2.4.1.40 Prototypdokumentation .................................................................................................... 46 2.4.1.41 Prozessbeschreibung ......................................................................................................... 46 2.4.1.42 Prüfprotokoll......................................................................................................................... 47 2.4.1.43 Publikation ............................................................................................................................ 47 2.4.1.44 QS- und Risikobericht ........................................................................................................ 47 2.4.1.45 Rechtsgrundlagenanalyse ................................................................................................. 47 2.4.1.46 Releasebericht ...................................................................................................................... 48 2.4.1.47 Releaseplan ........................................................................................................................... 48 2.4.1.48 Schutzbedarfsanalyse......................................................................................................... 48 2.4.1.49 Service Level Agreement ................................................................................................... 48 2.4.1.50 Situationsanalyse ................................................................................................................. 49 2.4.1.51 Stakeholderinteressen ........................................................................................................ 50 2.4.1.52 Stakeholderliste ................................................................................................................... 50 2.4.1.53 Studie ..................................................................................................................................... 50 2.4.1.54 Systemkonzept ..................................................................................................................... 51 2.4.1.55 Testkonzept ........................................................................................................................... 51 2.4.1.56 Testprotokoll ........................................................................................................................ 52 2.4.1.57 Umsetzungsauftrag ............................................................................................................ 52 2.4.1.58 Vereinbarung........................................................................................................................ 53

2.4.2 Zustände ..................................................................................................................................... 53 2.4.2.1 Altsystem entfernt ............................................................................................................... 53 2.4.2.2 Betrieb aktiviert .................................................................................................................... 53 2.4.2.3 Betriebsinfrastruktur realisiert .......................................................................................... 53

189 / 202

2.4.2.4 Betriebsorganisation realisiert ......................................................................................... 54 2.4.2.5 Einführungsmassnahmen durchgeführt........................................................................ 54 2.4.2.6 Einführungsmassnahmen realisiert ................................................................................ 54 2.4.2.7 ISDS-Konzept überführt .................................................................................................... 54 2.4.2.8 ISDS-Massnahmen realisiert ............................................................................................ 54 2.4.2.9 Meilensteine ......................................................................................................................... 54 2.4.2.10 Migration durchgeführt ..................................................................................................... 55 2.4.2.11 Migrationsverfahren realisiert .......................................................................................... 56 2.4.2.12 Organisation aktiviert ......................................................................................................... 56 2.4.2.13 Organisation umgesetzt .................................................................................................... 56 2.4.2.14 Produkt aktiviert .................................................................................................................. 56 2.4.2.15 Produkt entwickelt oder angepasst ................................................................................ 56 2.4.2.16 Schnittstellen realisiert ....................................................................................................... 56 2.4.2.17 System aktiviert .................................................................................................................... 56 2.4.2.18 System entwickelt oder parametrisiert .......................................................................... 56 2.4.2.19 System integriert ................................................................................................................. 57 2.4.2.20 Testinfrastruktur realisiert ................................................................................................. 57 2.4.2.21 Testinfrastruktur überführt ............................................................................................... 57

3 Aufgaben .................................................................................................................. 58 3.1 Einleitung .................................................................................................................................. 58 3.1.1 Aufgabenpositionierung .......................................................................................................... 58 3.1.2 Entscheidungsaufgaben ........................................................................................................... 58

3.1.2.1 Entscheidungsaufgaben generell ................................................................................... 58 3.1.2.2 Entscheide der Steuerung................................................................................................. 58 3.1.2.3 Entscheide der Führung .................................................................................................... 58

3.2 Aufgabenübersicht ................................................................................................................ 59 3.3 Erläuterung der Aufgabenbeschreibung ......................................................................... 62 3.4 Aufgabenverzeichnis ............................................................................................................. 62 3.4.1 Entscheidungsaufgaben der Steuerung ................................................................................ 62

3.4.1.1 Entscheid Ausschreibung treffen .................................................................................... 62 3.4.1.2 Entscheid Betriebsaufnahme treffen .............................................................................. 63 3.4.1.3 Entscheid Phasenfreigabe Abschluss treffen ............................................................... 64 3.4.1.4 Entscheid Phasenfreigabe treffen ................................................................................... 65 3.4.1.5 Entscheid Projektabbruch treffen ................................................................................... 66 3.4.1.6 Entscheid Projektabschluss treffen ................................................................................. 67 3.4.1.7 Entscheid Projektinitialisierungsfreigabe treffen ........................................................ 68 3.4.1.8 Entscheid Releasefreigabe treffen .................................................................................. 69 3.4.1.9 Entscheid Umsetzungsfreigabe treffen ......................................................................... 70 3.4.1.10 Entscheid Zuschlag treffen ................................................................................................ 71

3.4.2 Entscheidungsaufgaben der Führung ................................................................................... 72 3.4.2.1 Entscheid Abnahme Migration treffen .......................................................................... 72 3.4.2.2 Entscheid Abnahme treffen .............................................................................................. 73 3.4.2.3 Entscheid ISDS-Konzept treffen ...................................................................................... 74 3.4.2.4 Entscheid Lösungsarchitektur treffen ............................................................................ 74 3.4.2.5 Entscheid Produktkonzept treffen .................................................................................. 75 3.4.2.6 Entscheid Vorabnahme treffen ........................................................................................ 75 3.4.2.7 Entscheid weiteres Vorgehen treffen ............................................................................. 76

3.4.3 Sonstige Aufgaben ................................................................................................................... 77 3.4.3.1 Altsystem ausser Betrieb setzen ...................................................................................... 77 3.4.3.2 Änderungen managen....................................................................................................... 78 3.4.3.3 Angebote bewerten ........................................................................................................... 79 3.4.3.4 Ausschreibung durchführen ............................................................................................. 79 3.4.3.5 Ausschreibung erarbeiten ................................................................................................. 80 3.4.3.6 Beschaffungsanalyse erarbeiten ....................................................................................... 81 3.4.3.7 Betrieb aktivieren ................................................................................................................ 82 3.4.3.8 Betrieb realisieren ............................................................................................................... 83 3.4.3.9 Betriebskonzept erarbeiten .............................................................................................. 84 3.4.3.10 Einführung durchführen .................................................................................................... 85 3.4.3.11 Einführung realisieren ........................................................................................................ 85 3.4.3.12 Einführungskonzept erarbeiten ....................................................................................... 86 3.4.3.13 Integrationskonzept erarbeiten ....................................................................................... 87 3.4.3.14 Iterationen durchführen .................................................................................................... 87 3.4.3.15 Iterationen planen ............................................................................................................... 88 3.4.3.16 ISDS-Konzept erarbeiten................................................................................................... 89 3.4.3.17 ISDS-Konzept realisieren ................................................................................................... 90 3.4.3.18 ISDS-Konzept überführen ................................................................................................. 90 3.4.3.19 Leistungen vereinbaren und steuern .............................................................................. 91

190 / 202

3.4.3.20 Lösungsanforderungen erarbeiten................................................................................. 93 3.4.3.21 Lösungsanforderungen führen ........................................................................................ 94 3.4.3.22 Lösungsarchitektur erarbeiten ......................................................................................... 95 3.4.3.23 Migration durchführen ...................................................................................................... 95 3.4.3.24 Migrationskonzept erarbeiten ......................................................................................... 96 3.4.3.25 Migrationsverfahren realisieren....................................................................................... 97 3.4.3.26 Organisation aktivieren ..................................................................................................... 97 3.4.3.27 Organisation umsetzen ..................................................................................................... 98 3.4.3.28 Organisationsanforderungen erarbeiten ...................................................................... 99 3.4.3.29 Organisationskonzept erarbeiten ................................................................................. 100 3.4.3.30 Phasenfreigabe vorbereiten ........................................................................................... 100 3.4.3.31 Probleme behandeln und Erfahrungen nutzen ......................................................... 101 3.4.3.32 Produkt aktivieren ............................................................................................................. 102 3.4.3.33 Produkt realisieren ............................................................................................................ 103 3.4.3.34 Produktkonzept erarbeiten ............................................................................................ 103 3.4.3.35 Projekt führen und kontrollieren ................................................................................... 104 3.4.3.36 Projekt steuern ................................................................................................................... 105 3.4.3.37 Projektabschluss vorbereiten ......................................................................................... 107 3.4.3.38 Projektmanagementplan erarbeiten ............................................................................ 108 3.4.3.39 Prototyping durchführen ................................................................................................ 109 3.4.3.40 Qualitätssicherung führen .............................................................................................. 109 3.4.3.41 Rechtsgrundlagenanalyse erarbeiten ........................................................................... 110 3.4.3.42 Releaseabschluss vorbereiten .......................................................................................... 111 3.4.3.43 Releaseplan erarbeiten ..................................................................................................... 112 3.4.3.44 Risiken managen ................................................................................................................ 112 3.4.3.45 Schutzbedarfsanalyse erarbeiten ................................................................................... 113 3.4.3.46 Stakeholder managen und informieren ....................................................................... 114 3.4.3.47 Stakeholderinteressen vertreten .................................................................................... 115 3.4.3.48 Studie erarbeiten ................................................................................................................ 116 3.4.3.49 System aktivieren ............................................................................................................... 117 3.4.3.50 System in Betrieb integrieren.......................................................................................... 117 3.4.3.51 System realisieren .............................................................................................................. 118 3.4.3.52 Systemintegration vorbereiten ....................................................................................... 119 3.4.3.53 Test durchführen ............................................................................................................... 120 3.4.3.54 Testinfrastruktur realisieren ............................................................................................ 120 3.4.3.55 Testinfrastruktur überführen ........................................................................................... 121 3.4.3.56 Testkonzept erarbeiten .................................................................................................... 122 3.4.3.57 Umsetzungsauftrag erarbeiten ...................................................................................... 122 3.4.3.58 Vereinbarung erarbeiten ................................................................................................. 123

4 Module..................................................................................................................... 125 4.1 Einleitung ................................................................................................................................. 125 4.2 Module-Übersicht ................................................................................................................. 125 4.2.1 Standardmodule ..................................................................................................................... 125 4.2.2 Individuelle Module ................................................................................................................ 126 4.3 Erläuterung der Modulbeschreibung ............................................................................... 126 4.4 Modul-Verzeichnis ................................................................................................................ 126 4.4.1 Management Module ............................................................................................................ 126

4.4.1.1 Projektsteuerung ............................................................................................................... 126 4.4.1.2 Projektführung ................................................................................................................... 127

4.4.2 Fachmodule ............................................................................................................................. 128 4.4.2.1 Projektgrundlagen ............................................................................................................ 128 4.4.2.2 Beschaffung ........................................................................................................................ 129 4.4.2.3 Organisation ....................................................................................................................... 129 4.4.2.4 Produkt ................................................................................................................................ 130 4.4.2.5 IT-System ............................................................................................................................. 130 4.4.2.6 Tests ....................................................................................................................................... 131 4.4.2.7 Einführungsorganisation .................................................................................................. 131 4.4.2.8 IT-Migration ........................................................................................................................ 132 4.4.2.9 IT-Betrieb ............................................................................................................................. 132 4.4.2.10 ISDS ....................................................................................................................................... 133

5 Rollen ....................................................................................................................... 134 5.1 Einleitung ................................................................................................................................. 134 5.1.1 Rollenmodell ............................................................................................................................ 134 5.1.2 Stammorganisation ................................................................................................................ 134 5.1.3 Projektorganisation ................................................................................................................. 135

191 / 202

5.1.3.1 Übersicht ............................................................................................................................. 135 5.1.3.2 Hierarchieebenen .............................................................................................................. 135 5.1.3.3 Partnergruppen ................................................................................................................. 136 5.1.3.4 Projekterollen in Programmen ...................................................................................... 136

5.2 Rollenübersicht ...................................................................................................................... 138 5.2.1 Standardrollen ......................................................................................................................... 138 5.2.2 Erläuterungen zur Rollenbesetzung..................................................................................... 139 5.2.3 Hinweise zur Rollenbesetzung .............................................................................................. 139

5.2.3.1 Steuerung ............................................................................................................................ 139 5.2.3.2 Führung................................................................................................................................ 140 5.2.3.3 Ausführung ......................................................................................................................... 140

5.3 Erläuterung der Rollenbeschreibung ............................................................................... 141 5.4 Rollenverzeichnis ................................................................................................................... 141 5.4.1 Steuerungsrollen ...................................................................................................................... 141

5.4.1.1 Auftraggeber ....................................................................................................................... 141 5.4.1.2 Projektausschussmitglied ................................................................................................ 143 5.4.1.3 Qualitäts- und Risikomanager ....................................................................................... 144

5.4.2 Führungsrollen......................................................................................................................... 144 5.4.2.1 Fachausschussmitglied .................................................................................................... 144 5.4.2.2 Projektleiter ......................................................................................................................... 145 5.4.2.3 Projektunterstützung........................................................................................................ 147 5.4.2.4 Teilprojektleiter .................................................................................................................. 148

5.4.3 Ausführungsrollen ................................................................................................................... 148 5.4.3.1 Anwendervertreter ............................................................................................................ 148 5.4.3.2 Anwendungsverantwortlicher ........................................................................................ 150 5.4.3.3 Betriebsverantwortlicher .................................................................................................. 151 5.4.3.4 Business Analyst ................................................................................................................. 151 5.4.3.5 Entwickler ............................................................................................................................ 152 5.4.3.6 Entwicklungsteam ............................................................................................................. 153 5.4.3.7 Geschäftsprozessverantwortlicher ................................................................................ 154 5.4.3.8 ISDS-Verantwortlicher...................................................................................................... 154 5.4.3.9 Iterationsleiter .................................................................................................................... 155 5.4.3.10 IT-Architekt ......................................................................................................................... 156 5.4.3.11 Tester .................................................................................................................................... 157 5.4.3.12 Testverantwortlicher ......................................................................................................... 157

6 Szenarien ................................................................................................................. 159 6.1 Einleitung ................................................................................................................................. 159 6.2 Szenarien-Übersicht ............................................................................................................. 159 6.2.1 Aufbau der Szenarien ............................................................................................................. 159 6.2.2 Standardszenarien .................................................................................................................. 160 6.2.3 Individuelle Szenarien ............................................................................................................ 160

6.2.3.1 Anpassung der Szenarien ............................................................................................... 160 6.2.3.2 Sizing .................................................................................................................................... 160 6.2.3.3 Tailoring ................................................................................................................................ 161

6.3 Szenarien-Beschreibungen ................................................................................................. 162 6.3.1 Erläuterung der Szenario-Beschreibung ............................................................................. 162 6.4 Szenarien-Verzeichnis .......................................................................................................... 162 6.4.1 Dienstleistung/Produkt Szenarien ........................................................................................ 162

6.4.1.1 Dienstleistung/Produkt Entwicklung ............................................................................ 162 6.4.1.2 Dienstleistung/Produkt Adaption ................................................................................. 163

6.4.2 Informatik Szenarien ............................................................................................................... 164 6.4.2.1 IT-Anwendung Entwicklung ........................................................................................... 164 6.4.2.2 IT-Anwendung Adaption ................................................................................................ 164 6.4.2.3 IT-Infrastruktur ................................................................................................................... 165

6.4.3 Organisation/Betriebswirtschaft Szenarien ......................................................................... 166 6.4.3.1 Organisationsanpassung ................................................................................................. 166

7 Hinweise zur Anwendung ................................................................................... 167 7.1 Einleitung ................................................................................................................................. 167 7.2 Hinweise-Übersicht ............................................................................................................... 167 7.3 Hinweise-Beschreibungen .................................................................................................. 167 7.3.1 Erläuterung der Hinweise-Beschreibung............................................................................. 167 7.4 Hinweise-Verzeichnis ........................................................................................................... 167

192 / 202

7.4.1 Governance .............................................................................................................................. 167 7.4.1.1 Allgemeines ........................................................................................................................ 167 7.4.1.2 Unternehmensprozesse und HERMES ........................................................................ 168 7.4.1.3 Erstellung der Unternehmensplanung ........................................................................ 168 7.4.1.4 Nachvollziehbarkeit der gewählten Vorgehensweise ............................................. 169 7.4.1.5 Integration in das Projektportfolio ............................................................................... 170 7.4.1.6 Reporting ............................................................................................................................. 170 7.4.1.7 Erfüllung der Anforderungen der Projekt-Governance ........................................... 171

7.4.2 Nachhaltigkeit .......................................................................................................................... 174 7.4.2.1 Allgemeines ........................................................................................................................ 174 7.4.2.2 Nachhaltigkeit mit HERMES ........................................................................................... 175

7.4.3 Projekt– und Entwicklungsmanagement ............................................................................. 177 7.4.3.1 HERMES klassisch, agil oder hybrid? ........................................................................... 177 7.4.3.2 HERMES Projektmanagement klassisch ...................................................................... 177 7.4.3.3 HERMES Projektmanagement hybrid .......................................................................... 177 7.4.3.4 HERMES Entwicklungsmanagement hybrid ............................................................... 178

7.4.4 Selbstbestimmung der Anwender über das Projekt ......................................................... 178 7.4.5 Finanzielle Steuerung und Führung ..................................................................................... 179

7.4.5.1 Allgemeines ........................................................................................................................ 179 7.4.5.2 Finanzierung ....................................................................................................................... 179 7.4.5.3 Steuerung ............................................................................................................................ 179 7.4.5.4 Führung................................................................................................................................ 179

7.4.6 Planung ..................................................................................................................................... 180 7.4.6.1 Planungsbasis und das Vorgehen ................................................................................ 180 7.4.6.2 Initiale Planung des Gesamtprojekts ........................................................................... 180 7.4.6.3 Umsetzungsplanung klassisch ........................................................................................ 181 7.4.6.4 Umsetzungsplanung agil ................................................................................................ 182

7.4.7 Realisierungseinheiten bei klassischer Vorgehensweise ................................................... 182 7.4.8 Anforderungen an die Lösung .............................................................................................. 183 7.4.9 Anwendung mit anderen Methoden und Praktiken ......................................................... 184 7.4.10 Integration von HERMES in die Organisation .................................................................... 185

7.4.10.1 Allgemeines ........................................................................................................................ 185 7.4.10.2 Vorgehen ............................................................................................................................. 185 7.4.10.3 Anpassung der Methode ................................................................................................ 185

Anhang A – Inhaltsverzeichnis ............................................................................................. 187

Anhang B – Abbildungsverzeichnis ..................................................................................... 193

Anhang C – Tabellenverzeichnis .......................................................................................... 194

Anhang D – Vokabular ........................................................................................................... 195 Phasen – Phases – Fasi – Phases .......................................................................................................... 195 Ergebnisse – Résultats – Risultati – Outcomes ................................................................................. 195 Aufgaben – Tâches – Compiti – Tasks ................................................................................................ 198 Module – Modules – Moduli – Modules ............................................................................................ 200 Rollen – Rôles – Ruoli – Roles ............................................................................................................... 200 Szenarien – Scénarios – Scenari – Scenarios ..................................................................................... 201

Index der HERMES Projektmanagement Methodenelemente................................................................. 203

193 / 202

Anhang B – Abbildungsverzeichnis Abbildung 1: Gesamtbild der HERMES Module samt wichtigsten Ergebnissen entlang der

Phasen .......................................................................................................................................... 6 Abbildung 2: Die Funktionalität von HERMES in der Praxis .................................................................... 9 Abbildung 3: Positionierung Programmmanagement ............................................................................. 11 Abbildung 4: Abwicklung der klassischen und agilen Projekte in Phasen .......................................... 11 Abbildung 5: Ergebnisse stehen im Zentrum von HERMES ...................................................................12 Abbildung 6: HERMES Phasen und Releases mit Meilensteinen als Quality Gates ..........................12 Abbildung 7: Beziehung zwischen der Stamm- und einer minimalen Projektorganisation ..........13 Abbildung 8: Modul setzt sich aus Ergebnisse und Aufgaben zusammen ........................................13 Abbildung 9: Projekte einer Stammorganisation mit Szenarien ...........................................................14 Abbildung 10: UML Diagramm des HERMES 2021 Datenmodells ..........................................................15 Abbildung 11: Sichten auf Projekt ...................................................................................................................16 Abbildung 12: HERMES Projektlebenszyklus ................................................................................................19 Abbildung 13: Ablaufschema der Initialisierung samt Ergebnissen ........................................................19 Abbildung 14: HERMES Phasenmodell für klassische und agile Projekte .............................................21 Abbildung 15: HERMES Meilensteine am Beginn und am Ende jeder Phase und bei

Releasefreigabe ........................................................................................................................ 27 Abbildung 16: Meilensteine für klassische und agile IT-Entwicklungsprojekte .................................. 27 Abbildung 17: Standardmässig verfügbare HERMES Module im Gesamtkontext ........................... 125 Abbildung 18: Klassisches und agiles Beispiel einer minimalen Projektorganisation ..................... 134 Abbildung 19: Rollenzuordnung zu Hierarchieebenen einer klassischen oder agilen

Projektorganisation ............................................................................................................... 135 Abbildung 20: Die Sicht der Rolleninhaber im Projekt ............................................................................ 136 Abbildung 21: Projekte können zu Programmen zusammengefasst werden .................................. 137 Abbildung 22: Drei mögliche Grundvarianten der Projektorganisation ............................................. 137 Abbildung 23: Wahl und Anwendung des für das Projekt geeigneten Szenarios ........................... 159 Abbildung 24: Mehrere Module, bestehend aus Ergebnisse und Aufgaben, bilden ein

Szenario ................................................................................................................................... 159 Abbildung 25: Anwendung von Standard- und benutzerdefinierten Szenarien ............................. 162 Abbildung 26: Module im Kontext des Szenarios Dienstleistung/Produkt Entwicklung ................ 163 Abbildung 27: Module im Kontext des Szenarios Dienstleistung/Produkt Adaption ..................... 163 Abbildung 28: Module im Kontext des Szenarios IT-Anwendung Entwicklung ............................... 164 Abbildung 29: Module im Kontext des Szenarios IT-Anwendung Adaption .................................... 165 Abbildung 30: Module im Kontext des Szenarios IT-Infrastruktur ....................................................... 166 Abbildung 31: Module im Kontext des Szenarios Organisationsanpassung .................................... 166 Abbildung 32: Unternehmensprozesse im Lichte von HERMES ........................................................... 168 Abbildung 33: Zwei übliche Unterstellungsvarianten des Portfolios ................................................... 170 Abbildung 34: Gekapselte, gegenüber der Stammorganisation einheitliche Reporting

Struktur...................................................................................................................................... 171 Abbildung 35: HERMES bietet klassisches und hybrides Projektmanagement an .......................... 177 Abbildung 36: HERMES 2021 Phasenmodell in rein klassischer Entwicklungsumgebung ............. 177 Abbildung 37: HERMES 2021 Phasenmodell mit agiler Entwicklung ................................................... 177 Abbildung 38: Hybrides Vorgehen - Beispielvarianten ........................................................................... 178 Abbildung 39: Steigende Kenntnisse / abnehmende Planungsungenauigkeit ................................ 182 Abbildung 40: Zeitlich verschobene Realisierungseinheiten bei klassischer Vorgehensweise ..... 183 Abbildung 41: Einsatz von ergänzenden Methoden und Praktiken .................................................... 184

194 / 202

Anhang C – Tabellenverzeichnis Tabelle 1: HERMES-Phasen für klassisches und agiles Projektvorgehen .............................................21 Tabelle 2: Liste der HERMES Dokumente – die minimal geforderten sind mit einem X

markiert ............................................................................................................................................. 28 Tabelle 3: HERMES Liste der HERMES Zustände ....................................................................................... 28 Tabelle 4: Zuordnung aller Aufgaben samt entsprechender Ergebnisse zu Projektphasen .......... 62 Tabelle 5: Standardmässig mit HERMES verfügbare Module .............................................................. 126 Tabelle 6: Aufgaben und Ergebnisse Modul Projektsteuerung ........................................................... 127 Tabelle 7: Aufgaben und Ergebnisse Modul Projektführung ............................................................... 128 Tabelle 8: Aufgaben und Ergebnisse Modul Projektgrundlagen ........................................................ 128 Tabelle 9: Aufgaben und Ergebnisse Modul IT- Beschaffung .............................................................. 129 Tabelle 10: Aufgaben und Ergebnisse Modul Organisation ................................................................... 130 Tabelle 11: Aufgaben und Ergebnisse Modul Produkt ............................................................................ 130 Tabelle 12: Aufgaben und Ergebnisse Modul IT-System .......................................................................... 131 Tabelle 13: Aufgaben und Ergebnisse Modul Tests ................................................................................... 131 Tabelle 14: Aufgaben und Ergebnisse Modul Einführungsorganisation ............................................. 132 Tabelle 15: Aufgaben und Ergebnisse Modul IT-Migration .................................................................... 132 Tabelle 16: Aufgaben und Ergebnisse Modul IT-Betrieb ......................................................................... 132 Tabelle 17: Aufgaben und Ergebnisse Modul ISDS ................................................................................... 133 Tabelle 18: Übersicht der Rollen und deren Zuordnung zur Hierarchieebene und zum Partner 139 Tabelle 19: Aufgaben, die der Auftraggeber verantwortet, und andere an der Aufgabe

beteiligte Rollen ............................................................................................................................ 143 Tabelle 20: Aufgaben, die der Projektleiter verantwortet, und andere an der Aufgabe

beteiligte Rollen ............................................................................................................................ 147 Tabelle 21: Aufgaben, die der Anwendervertreter verantwortet, und andere an der Aufgabe

beteiligte Rollen ............................................................................................................................ 150 Tabelle 22: Aufgaben, die der Betriebsverantwortliche verantwortet, und andere an der Aufgabe

beteiligte Rollen .............................................................................................................................. 151 Tabelle 23: Aufgaben, die der Business Analyst verantwortet, und andere an der Aufgabe

beteiligte Rollen ............................................................................................................................ 152 Tabelle 24: Aufgaben, die der Entwickler verantwortet, und andere an der Aufgabe beteiligte

Rollen ............................................................................................................................................... 153 Tabelle 25: Aufgaben, die der ISDS-Verantwortliche verantwortet, und andere an der Aufgabe

beteiligte Rollen ............................................................................................................................ 155 Tabelle 26: Aufgaben, die der Iterationsleiter verantwortet, und andere an der Aufgabe

beteiligte Rollen ............................................................................................................................ 156 Tabelle 27: Aufgaben, die der IT-Architekt verantwortet, und andere an der Aufgabe

beteiligte Rollen ............................................................................................................................ 157 Tabelle 28: Aufgaben, die der Testverantwortliche verantwortet, und andere an der Aufgabe

beteiligte Rollen ............................................................................................................................ 158 Tabelle 29: Standardszenarien für Projekte verschiedener Charakteristiken samt Modulen ......... 160 Tabelle 30: Hinweise zur Anwendung pro Kategorie ............................................................................... 167 Tabelle 31: Vokabular HERMES-Phasen 4-sprachig .................................................................................. 195 Tabelle 32: Vokabular HERMES-Ergebnisse 4-sprachig ........................................................................... 198 Tabelle 33: Vokabular HERMES-Aufgaben 4-sprachig .............................................................................200 Tabelle 34: Vokabular HERMES-Module 4-sprachig.................................................................................200 Tabelle 35: Vokabular HERMES-Rollen 4-sprachig ................................................................................... 201 Tabelle 36: Vokabular HERMES-Szenarien 4-sprachig ............................................................................. 201

195 / 202

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

1.4.2.3 Einführung Déploiement Introduzione Deployment

1.4.1.1 Initialisierung Initialisation Avvio Initiation

1.4.2.1 Konzept Conception Concetto Concept

1.4.2.2 Realisierung Réalisation Realizzazione Implementation

1.4.3.1 Umsetzung Mise en œuvre Attuazione Execution

1.4.4.1 Abschluss Clôture Conclusione Closure

Tabelle 31: Vokabular HERMES-Phasen 4-sprachig

Ergebnisse – Résultats – Risultati – Outcomes

Deutsch Française Italiano English Ergebnisse Résultats Risultati Outcomes

Abnahmeprotokoll Procès-verbal de réception Protocollo di accettazione Acceptance report

Altsystem entfernt Ancien système hors ser-vice

Vecchio sistema disinstal-lato

Legacy system removed

Änderungsantrag Demande de modification Domanda di modifica Change request

Änderungsstatusliste Liste de l’état des modifi-cations

Elenco dello stato delle modifiche

Change status list

Angebot Offre Offerta Offer

Angebotsprotokoll Procès-verbal des offres Protocollo delle offerte Tender report

Anwendungshandbuch Manuel d’utilisation Manuale d'uso User manual

Arbeitsauftrag Mandat de travail Mandato di lavoro Work order

Ausschreibungsunterlagen Dossier d’appel d’offres Documentazione del bando di concorso

Tender documentation

Beschaffungsanalyse Analyse de l'appel d'offres Analisi dell'acquisto Procurement analysis

Betrieb aktiviert Exploitation activée Esercizio attivato Operation activated

Betriebshandbuch Manuel d’exploitation Manuale d'esercizio Operating manual

Betriebsinfrastruktur reali-siert

Infrastructure d’exploita-tion réalisée

Infrastruttura d'esercizio realizzata

Operating infrastructure realized

Betriebskonzept Concept d’exploitation Concetto d'esercizio Operating concept

Betriebsorganisation reali-siert

Organisation d’exploitation réalisée

Organizzazione d'esercizio realizzata

Operating organization re-alized

Checkliste Abnahme Liste de contrôle Réception Lista di controllo accetta-zione

Acceptance checklist

Checkliste Abnahme Mig-ration

Liste de contrôle Réception de la migration

Lista di controllo accetta-zione della migrazione

Migration acceptance checklist

Checkliste Ausschreibung Liste de contrôle Appel d'offres

Lista di controllo bando di concorso

Tender checklist

Checkliste Betriebsauf-nahme

Liste de contrôle Mise en service

Lista di controllo messa in esercizio

Launch of operation check-list

Checkliste ISDS-Konzept Liste de contrôle Concept SIPD

Lista di controllo piano SIPD

ISDP concept checklist

Checkliste Lösungsarchi-tektur

Liste de contrôle Architec-ture de la solution

Lista di controllo architet-tura di sistema

Solution architecture checklist

Checkliste Phasenfreigabe Liste de contrôle Libération de la phase

Lista di controllo avvio della fase

Phase release checklist


Liste de contrôle Libération de la phase de clôture

Lista di controllo avvio della fase di chiusura

Closure phase release checklist

Checkliste Produktkonzept Liste de contrôle Concept du produit

Lista di controllo concetto del prodotto

Product concept checklist

Checkliste Projektabbruch Liste de contrôle Interrup-tion du projet

Lista di controllo interru-zione del progetto

Project discontinuation checklist

196 / 202


Checkliste Projektabschluss Liste de contrôle Clôture du projet

Lista di controllo chiusura del progetto

Project closure checklist

Checkliste Projektinitialisie-rungsfreigabe

Liste de contrôle Libération de l'initialisation du projet

Lista di controllo avvio dell'inizializzazione del progetto

Project initiation release checklist

Checkliste Releasefreigabe Liste de contrôle Libération du release

Lista di controllo dell'avvio del rilascio

Release checklist

Checkliste Umsetzungsfrei-gabe

Liste de contrôle Libération de la mise en œuvre

Lista di controllo avvio dell'attuazione

Execution release checklist

Checkliste Vorabnahme Liste de contrôle Prérécep-tion

Lista di controllo accetta-zione preliminare

Preliminary acceptance checklist

Checkliste weiteres Vorge-hen

Liste de contrôle Suite des opérations

Lista di controllo continua-zione

Next steps checklist

Checkliste Zuschlag Liste de contrôle Adjudica-tion

Lista di controllo aggiudi-cazione

Contract award checklist

Detailspezifikation Spécification détaillée Specifica dettagliata Detailed specifications

Einführungskonzept Concept de déploiement Concetto di introduzione Deployment concept


Mesures de déploiement effectuées

Misure d’introduzione at-tuate

Deployment measures car-ried out


Mesures de déploiement réalisées

Misure d’introduzione rea-lizzate

Deployment measures re-alized

Evaluationsbericht Rapport d’évaluation Rapporto di valutazione Evaluation report

Geschäftsmodellbeschrei-bung

Description du modèle d'affaires

Descrizione del modello operativo

Business model description

Inkrement Incrément Incremento Increment

Integrations- und Installa-tionsanleitung

Guide d’intégration et d’installation

Guida all’integrazione e all’installazione

Integration and installation instructions

Integrationskonzept Concept d’intégration Concetto d’integrazione Integration concept

ISDS-Konzept Concept SIPD Piano SIPD ISDP concept

ISDS-Konzept überführt Concept SIPD transféré Piano SIPD trasferito ISDP concept transferred

ISDS-Massnahmen reali-siert

Mesures SIPD réalisées Misure SIPD realizzate ISDP measures realized

Liste Projektentscheid Steuerung

Liste Décisions de pilotage Lista decisioni relative alla guida del progetto

List of steering project de-cisions


Liste Décisions de conduite Lista decisioni relative alla gestione del progetto

List of management pro-ject decisions

Lösungsanforderungen Exigences envers la solu-tion

Requisiti relativi alla solu-zione

Solution requirements

Lösungsarchitektur Architecture de la solution Architettura di sistemi Solution architecture

Meilenstein Abnahme Jalon Réception Milestone accettazione Acceptance milestone

Meilenstein Abnahme Mig-ration

Jalon Réception de la mi-gration

Milestone accettazione della migrazione

Migration acceptance mile-stone

Meilenstein Ausschreibung Jalon Appel d'offres Milestone bando di con-corso

Tender milestone

Meilenstein Betriebsauf-nahme

Jalon Mise en service Milestone messa in eserci-zio

Launch of operation mile-stone

Meilenstein ISDS-Konzept Jalon Concept SIPD Milestone piano SIPD ISDP concept milestone

Meilenstein Lösungsarchi-tektur

Jalon Architecture de la so-lution

Milestone architettura di sistemi

Solution architecture mile-stone

Meilenstein Phasenfrei-gabe

Jalon Libération de la phase

Milestone avvio della fase Phase release milestone

Meilenstein Phasenfrei-gabe Abschluss

Jalon Clôture de la libéra-tion de la phase

Milestone chiusura dell'av-vio della fase

Closure phase release milestone

Meilenstein Produktkon-zept

Jalon Concept du produit Milestone concetto del prodotto

Product concept milestone


Jalon Clôture du projet Milestone chiusura del progetto

Project closure milestone

Meilenstein Projektinitiali-sierungsfreigabe

Jalon Libération de l'initia-lisation du projet

Milestone avvio dell'inizia-lizzazione del progetto

Project initiation release milestone

Meilenstein Releasefrei-gabe

Jalon Libération du release Milestone avvio del rilascio Release milestone

197 / 202


Meilenstein Umsetzungs-freigabe

Jalon Libération de la mise en œuvre

Milestone avvio dell'attua-zione

Execution release mile-stone

Meilenstein Vorabnahme Jalon Préréception Milestone accettazione preliminare

Preliminary acceptance milestone

Meilenstein weiteres Vor-gehen

Jalon Suite des opérations Milestone continuazione Next steps milestone

Meilenstein Zuschlag Jalon Adjudication Milestone aggiudicazione Contract award milestone

Migration durchgeführt Migration effectuée Migrazione effettuata Migration carried out

Migrationskonzept Concept de migration Concetto di migrazione Migration concept

Migrationsverfahren reali-siert

Procédure de migration ré-alisée

Procedura di migrazione realizzata

Migration procedure real-ized

Offertanfrage Demande d’offres Domanda di offerta Quote request

Organisation aktiviert Organisation activée Organizzazione attivata Organization activated

Organisation umgesetzt Organisation mise en œuvre

Organizzazione attuata Organization implemented

Organisationsanforderun-gen

Exigences organisation-nelles

Requisiti organizzativi Organizational require-ments

Organisationsbeschreibung Description de l’organisa-tion

Descrizione dell’organizza-zione

Organization description

Organisationskonzept Concept d’organisation Piano di organizzazione Organization concept

Phasenbericht Rapport de phase Rapporto di fase Phase report

Produkt aktiviert Produit activé Prodotto attivato Product activated


Produit développé ou adapté

Prodotto sviluppato o ade-guato

Product developed or adapted

Produktdokumentation Documentation du produit Documentazione del pro-dotto

Product documentation

Produktkonzept Concept du produit Concetto del prodotto Product concept

Projekterfahrungen Expériences acquises Esperienze del progetto Lessons learned

Projektinitialisierungsauf-trag

Mandat d’initialisation du projet

Mandato per l’avvio del progetto

Project initiation order

Projektmanagementplan Plan de gestion du projet Piano di gestione del pro-getto

Project management plan

Projektschlussbeurteilung Appréciation finale du pro-jet

Valutazione finale del pro-getto

Final project evaluation

Projektstatusbericht Rapport sur l’état du projet Rapporto sullo stato del progetto

Project status report

Protokoll Procès-verbal Verbale Minutes

Prototyp Prototype Prototipo Prototype

Prototypdokumentation Documentation du proto-type

Documentazione del pro-totipo

Prototype documentation

Prozessbeschreibung Description de processus Descrizione del processo Process description

Prüfprotokoll Procès-verbal de vérifica-tion

Rapporto di verifica Review report

Publikation Publication Pubblicazione Publication

QS- und Risikobericht Rapport sur la qualité et les risques

Rapporto controllo qualità e rischi

QA and risk report

Rechtsgrundlagenanalyse Analyse des bases légales Analisi delle basi legali Legal basis analysis

Releasebericht Rapport de release Rapporto di release Release report

Releaseplan Plan de release Piano di release Release plan

Schnittstellen realisiert Interfaces réalisées Interfacce realizzate Interfaces realized

Schutzbedarfsanalyse Analyse des besoins de protection

Analisi delle esigenze di protezione

Protection needs analysis

Service Level Agreement Accord sur le niveau de service

Service level agreement Service level agreement

Situationsanalyse Analyse de la situation Analisi della situazione Situation analysis

Stakeholderinteressen Intérêts des parties pre-nantes

Interessi degli stakeholder Stakeholder interests

Stakeholderliste Liste des parties prenantes Elenco degli stakeholder Stakeholder list

Studie Étude Studio Study

System aktiviert Système activé Sistema attivato System activated

198 / 202


System entwickelt oder pa-rametrisiert

Système développé ou pa-ramétré

Sistema sviluppato o para-metrizzato

System developed or pa-rameterized

System integriert Système intégré Sistema integrato System integrated

Systemkonzept Concept du système Concetto del sistema System concept

Testinfrastruktur realisiert Infrastructure de test réali-sée

Infrastruttura per i test realizzata

Test infrastructure realized

Testinfrastruktur überführt Infrastructure de test transférée

Infrastruttura per i test tra-sferita

Test infrastructure trans-ferred

Testkonzept Concept de test Concetto dei test Test concept

Testprotokoll Procès-verbal de test Protocollo del test Test report

Umsetzungsauftrag Mandat de mise en œuvre Mandato di attuazione Execution order

Vereinbarung Accord Accordo Agreement

Tabelle 32: Vokabular HERMES-Ergebnisse 4-sprachig

Aufgaben – Tâches – Compiti – Tasks

Deutsch Française Italiano English Aufgaben Tâches Compiti Tasks

3.4.3.1 Altsystem ausser Betrieb setzen

Mettre l’ancien système hors service

Disattivare il vecchio si-stema

Decommission the legacy system

3.4.3.2 Änderungen managen Gérer les modifications Gestire le modifiche Manage changes

3.4.3.3 Angebote bewerten Évaluer les offres Valutare le offerte Evaluate tenders

3.4.3.4 Ausschreibung durchfüh-ren

Effectuer l'appel d'offres Pubblicare il bando di con-corso

Issue call for tenders

3.4.3.5 Ausschreibung erarbeiten Élaborer l’appel d’offres Elaborare il bando di con-corso

Prepare call for tenders

3.4.3.6 Beschaffungsanalyse erar-beiten

Élaborer l'analyse de l'ap-pel d'offres

Elaborare l'analisi dell'ac-quisto

Prepare procurement anal-ysis

3.4.3.7 Betrieb aktivieren Activer l'exploitation Attivare l’esercizio Activate operation

3.4.3.8 Betrieb realisieren Réaliser l'environnement d'exploitation

Realizzare l’esercizio Realize operation

3.4.3.9 Betriebskonzept erarbeiten Élaborer le concept d’ex-ploitation

Elaborare il concetto di esercizio

Design operating concept

3.4.3.10 Einführung durchführen Effectuer le déploiement Eseguire l’introduzione Execute deployment

3.4.3.11 Einführung vorbereiten Préparer le déploiement Preparare l’introduzione Prepare deployment

3.4.3.12 Einführungskonzept erar-beiten

Élaborer le concept de dé-ploiement

Elaborare il concetto d’in-troduzione

Design deployment con-cept

3.4.2.1 Entscheid Abnahme Migra-tion treffen

Décider de la réception de la migration

Decidere l'accettazione della migrazione

Decide on acceptance of migration

3.4.2.2 Entscheid Abnahme treffen Décider de la migration Decidere l'accettazione Decide on acceptance

3.4.1.1 Entscheid Ausschreibung treffen

Décider de l'appel d'offres Decidere di indire un bando di concorso

Decide on call for tenders

3.4.1.2 Entscheid Betriebsauf-nahme treffen

Décider de la mise en ser-vice

Decidere la messa in eser-cizio

Decide on launch of opera-tion

3.4.2.3 Entscheid ISDS-Konzept treffen

Décider du concept SIPD Decidere in relazione al piano SIPD

Decide on ISDP concept

3.4.2.4 Entscheid Lösungsarchitek-tur treffen

Décider de l'architecture Decidere l'architettura di sistema

Decide on solution archi-tecture

3.4.1.3 Entscheid Phasenfreigabe Abschluss treffen

Décider de la libération de la phase clôture

Decidere l'avvio della della fase di chiusura

Decide on closure phase release

3.4.1.4 Entscheid Phasenfreigabe treffen

Décider de la libération de la phase

Decidere l'avvio della fase Decide on phase release

3.4.2.5 Entscheid Produktkonzept treffen

Décider du concept du produit

Decidere il concetto del prodotto

Decide on product concept

3.4.1.5 Entscheid Projektabbruch treffen

Décider l'interruption du projet

Decidere l'interruzione del progetto

Decide on project discon-tinuation

3.4.1.6 Entscheid Projektabschluss treffen

Décider de la clôture du projet

Decidere la chiusura del progetto

Decide on project closure

3.4.1.7 Entscheid Projektinitialisie-rungsfreigabe treffen

Décider de la libération de l'initialisation du projet

Decidere l'avvio dell'inizia-lizzazione del progetto

Decide on project initiation release

199 / 202


3.4.1.8 Entscheid Releasefreigabe treffen

Décider de la libération du release

Decidere l'avvio del rilascio Decide on release

3.4.1.9 Entscheid Umsetzungsfrei-gabe treffen

Décider de la libération de la mise en œuvre

Decidere l'avvio dell'attua-zione

Decide on execution re-lease

3.4.2.6 Entscheid Vorabnahme treffen

Décider de la préréception Decidere l'accettazione preliminare

Decide on preliminary ac-ceptance

3.4.2.7 Entscheid weiteres Vorge-hen treffen

Décider de la suite des opérations

Decidere la continuazione Decide on next steps

3.4.1.10 Entscheid Zuschlag treffen Décider de l'adjudication Decidere l'aggiudicazione Decide on contract award

3.4.3.13 Integrationskonzept erar-beiten

Élaborer le concept d’inté-gration

Elaborare il concetto d’in-tegrazione

Design integration concept

3.4.3.16 ISDS-Konzept erarbeiten Élaborer le concept SIPD Elaborare il piano SIPD Design ISDP concept

3.4.3.17 ISDS-Konzept realisieren Réaliser le concept SIPD Realizzare il piano SIPD Implement ISDP concept

3.4.3.18 ISDS-Konzept überführen Transférer le concept SIPD Trasferire il piano SIPD Transfer ISDP concept

3.4.3.14 Iterationen durchführen Effectuer les itérations Effettuare le iterazioni Perform iterations

3.4.3.15 Iterationen planen Planifier les itérations Pianificare le iterazioni Plan iterations

3.4.3.19 Leistungen vereinbaren und steuern

Définir et piloter les pres-tations

Concordare e gestire le prestazioni

Agree on and steer goods/services

3.4.3.20 Lösungsanforderungen er-arbeiten

Élaborer les exigences en-vers la solution

Elaborare i requisiti relativi alla soluzione

Prepare solution require-ments

3.4.3.21 Lösungsanforderungen führen

Gérer les exigences envers la solution

Gestire i requisiti relativi alla soluzione

Manage solution require-ments

3.4.3.22 Lösungsarchitektur erar-beiten

Élaborer l'architecture de la solution

Elaborare l'architettura di sistemi

Prepare solution architec-ture

3.4.3.23 Migration durchführen Effectuer la migration Eseguire la migrazione Conduct migration

3.4.3.24 Migrationskonzept erarbei-ten

Élaborer le concept de mi-gration

Elaborare il concetto di mi-grazione

Design migration concept

3.4.3.25 Migrationsverfahren reali-sieren

Réaliser la procédure de migration

Realizzare la procedura di migrazione

Realize migration proce-dure

3.4.3.26 Organisation aktivieren Activer l'organisation Attivare l'organizzazione Activate organization

3.4.3.27 Organisation umsetzen Réaliser l’organisation Attuare l'organizzazione Implement organization

3.4.3.28 Organisationsanforderun-gen erarbeiten

Élaborer les exigences or-ganisationnelles

Elaborare i requisiti orga-nizzativi

Establish organizational re-quirements

3.4.3.29 Organisationskonzept erar-beiten

Élaborer le concept de l’or-ganisation

Elaborare il piano d'orga-nizzazione

Draw up organization con-cept

3.4.3.30 Phasenfreigabe vorberei-ten

Préparer la libération de la phase

Preparare l’avvio della fase Prepare phase release

3.4.3.31 Probleme behandeln und Erfahrungen nutzen

Traiter les problèmes et mettre à profit les expé-riences

Gestire i problemi e sfrut-tare le esperienze

Deal with problems and benefit from lessons learned

3.4.3.32 Produkt aktivieren Activer le produit Attivare il prodotto Activate product

3.4.3.33 Produkt realisieren Réaliser le produit Realizzare il prodotto Realize product

3.4.3.34 Produktkonzept erarbeiten Élaborer le concept du produit

Elaborare il concetto di prodotto

Design product concept

3.4.3.35 Projekt führen und kon-trollieren

Conduire et contrôler le projet

Gestire e controllare il pro-getto

Manage and control pro-ject

3.4.3.36 Projekt steuern Piloter le projet Guidare il progetto Steer project

3.4.3.37 Projektabschluss vorberei-ten

Préparer la clôture du pro-jet

Preparare la chiusura del progetto

Prepare project closure

3.4.3.38 Projektmanagementplan erarbeiten

Élaborer le plan de gestion du projet

Elaborare il piano di ge-stione progettuale

Draw up project manage-ment plan

3.4.3.39 Prototyping durchführen Effectuer le prototypage Eseguire la prototipazione Carry out prototyping

3.4.3.40 Qualitätssicherung führen Conduire l’assurance de la qualité

Gestire la garanzia della qualità

Perform quality assurance

3.4.3.41 Rechtsgrundlagenanalyse erarbeiten

Élaborer l’analyse des bases légales

Elaborare l’analisi delle basi legali

Analyse legal basis

3.4.3.42 Releaseabschluss vorberei-ten

Préparer la clôture du re-lease

Preparare la chiusura del rilascio

Prepare release closure

3.4.3.43 Releaseplan erarbeiten Élaborer le plan de release Elaborare il piano di rila-scio

Design release plan

3.4.3.44 Risiken managen Gérer les risques Gestire i rischi Manage risks

200 / 202


3.4.3.45 Schutzbedarfsanalyse erar-beiten

Élaborer l’analyse des be-soins de protection

Elaborare l’analisi delle esi-genze di protezione

Analyse protection needs

3.4.3.46 Stakeholder managen und informieren

Gérer et informer les par-ties prenantes

Gestire e informare gli sta-keholder

Manage and inform stake-holders

3.4.3.47 Stakeholderinteressen ver-treten

Représenter les intérêts des parties prenantes

Rappresentare gli interessi degli stakeholder

Advocate stakeholder in-terests

3.4.3.48 Studie erarbeiten Élaborer l’étude Elaborare lo studio Prepare study

3.4.3.49 System aktivieren Activer le système Attivare il sistema Activate system

3.4.3.50 System in Betrieb integrie-ren

Intégrer le système Integrare il sistema Integrate system

3.4.3.51 System realisieren Réaliser le système Realizzare il sistema Realize system

3.4.3.52 Systemintegration vorbe-reiten

Préparer l’intégration du système

Preparare l’integrazione del sistema

Prepare system integration

3.4.3.53 Test durchführen Effectuer les tests Eseguire i test Conduct test

3.4.3.54 Testinfrastruktur realisie-ren

Réaliser l'infrastructure de test

Realizzare l’infrastruttura per i test

Realize test infrastructure

3.4.3.55 Testkinfrastruktur überfüh-ren

Transférer l'infrastructure de test

Trasferire l'infrastuttura per i test

Transfer test infrastructure

3.4.3.56 Testkonzept erarbeiten Élaborer le concept de test Elaborare il concetto dei test

Design test concept

3.4.3.57 Umsetzungsauftrag Élaborer le mandat de mise en œuvre

Mandato di attuazione Execution order

3.4.3.58 Vereinbarung erarbeiten Élaborer l’accord Elaborare l’accordo Draw up agreement

Tabelle 33: Vokabular HERMES-Aufgaben 4-sprachig

Module – Modules – Moduli – Modules

Deutsch Française Italiano English Module Modules Moduli Modules

4.4.2.2 Beschaffung Achat Acquisto Procurement

4.4.2.7 Einführungsorganisation Organisation du déploie-ment

Organizzazione dell’intro-duzione

Deployment organization

4.4.2.10 ISDS SIPD SIPD ISDP

4.4.2.9 IT-Betrieb Exploitation informatique Esercizio IT IT operation

4.4.2.8 IT-Migration Migration informatique Migrazione IT IT migration

4.4.2.5 IT-System Système informatique Sistema IT IT system

4.4.2.3 Organisation Structures organisation-nelles

Organizzazione Organization

4.4.2.4 Produkt Produit Prodotto Product

4.4.1.2 Projektführung Conduite du projet Gestione del progetto Project management

4.4.2.1 Projektgrundlagen Bases du projet Basi del progetto Project foundations

4.4.1.1 Projektsteuerung Pilotage du projet Guida del progetto Project steering

4.4.2.6 Tests Tests Test Tests

Tabelle 34: Vokabular HERMES-Module 4-sprachig

Rollen – Rôles – Ruoli – Roles

Deutsch Française Italiano English Rollen Rôles Ruoli Roles

5.4.3.1 Anwendervertreter Représentant des utilisa-teurs

Rappresentante degli utenti

User representative

5.4.3.2 Anwendungsverantwortli-cher

Responsable d’application Responsabile dell’applica-zione

Application owner

5.4.1.1 Auftraggeber Mandant Committente Project sponsor

5.4.3.3 Betriebsverantwortlicher Responsable de l’exploita-tion

Responsabile dell’esercizio Operations manager

5.4.3.4 Business Analyst Business analyst Business analyst Business analyst

5.4.3.5 Entwickler Développeur Sviluppatore Developer

5.4.3.6 Entwicklungsteam Équipe de développement Team di sviluppo Development team

201 / 202

Deutsch Française Italiano English Rollen Rôles Ruoli Roles

5.4.2.1 Fachausschussmitglied Membre du comité spécia-lisé

Membro del comitato di esperti

Technical committee mem-ber

5.4.3.7 Geschäftsprozessverant-wortlicher

Responsable de processus métier

Responsabile dei processi operativi

Business process owner

5.4.3.8 ISDS-Verantwortlicher Responsable SIPD Responsabile SIPD ISDP manager

5.4.3.10 IT-Architekt Architecte informatique Architetto IT IT architect

5.4.3.9 Iterationsleiter Responsable des itérations Responsabile dell'itera-zione

Iteration manager

5.4.1.2 Projektausschussmitglied Membre du comité de pi-lotage

Membro del comitato di progetto

Project committee member

5.4.2.2 Projektleiter Chef de projet Project manager Project management

5.4.2.3 Projektunterstützung Assistance de projet Supporto di progetto Project support

5.4.1.3 Qualitäts- und Risikomana-ger

Gestionnaire de la qualité et des risques

Gestore della qualità e dei rischi

Quality and risk manager

5.4.2.4 Teilprojektleiter Chef de sous-projet Responsabile di sotto pro-getto

Sub-project manager

5.4.3.11 Tester Testeur Tester Tester

5.4.3.12 Testverantwortlicher Responsable des tests Responsabile dei test Test manager

Tabelle 35: Vokabular HERMES-Rollen 4-sprachig

Szenarien – Scénarios – Scenari – Scenarios

Deutsch Française Italiano English Szenarien Scénarios Scenari Scenarios


Adaptation de la prestation / du produit

Servizio/adeguamento del prodotto

Service/product adaptation

6.4.1.1 Dienstleistung/Produkt Entwicklung

Développement de la pres-tation / du produit

Servizio/sviluppo del pro-dotto

Service/product develop-ment

6.4.2.2 IT-Anwendung Adaption Adaptation de l'infrastruc-ture informatique

Adeguamento dell'applica-zione IT

IT application adaptation

6.4.2.1 IT-Anwendung Entwick-lung

Développement de l'infras-tructure informatique

Sviluppo dell'applicazione IT

IT application development

6.4.2.3 IT-Infrastruktur Infrastructure informatique Infrastruttura IT IT infrastructure

6.4.3.1 Organisationsanpassung Adaptation de l'organisa-tion

Adeguamento dell'organiz-zazione

Organizational adjustment


Adaptation de la prestation / du produit

Servizio/adeguamento del prodotto

Service/product adaptation

Tabelle 36: Vokabular HERMES-Szenarien 4-sprachig

Index der HERMES Projektmanagement Methodenelemente

Phasen Abschluss 25 Einführung 23 Initialisierung 22 Konzept 22 Realisierung 23 Umsetzung 24 Ergebnisse Abnahmeprotokoll 29 Altsystem entfernt 53 Änderungsantrag 29 Änderungsstatusliste 30 Angebot 30 Angebotsprotokoll 30 Anwendungshandbuch 31 Arbeitsauftrag 31 Ausschreibungsunterlagen 31 Beschaffungsanalyse 32 Betrieb aktiviert 53 Betriebshandbuch 33 Betriebsinfrastruktur realisiert 53 Betriebskonzept 33 Betriebsorganisation realisiert 54 Checkliste Abnahme 34 Checkliste Abnahme Migration 34 Checkliste Ausschreibung 34 Checkliste Betriebsaufnahme 34 Checkliste ISDS-Konzept 34 Checkliste Lösungsarchitektur 34 Checkliste Phasenfreigabe 34 Checkliste Phasenfreigabe Abschluss 34 Checkliste Produktkonzept 34 Checkliste Projektabbruch 34 Checkliste Projektabschluss 34 Checkliste Projektinitialisierungsfreigabe 34 Checkliste Releasefreigabe 34 Checkliste Umsetzungsfreigabe 35 Checkliste Vorabnahme 35 Checkliste weiteres Vorgehen 35 Checkliste Zuschlag 35 Detailspezifikation 35 Einführungskonzept 35 Einführungsmassnahmen durchgeführt 54 Einführungsmassnahmen realisiert 54 Evaluationsbericht 36 Geschäftsmodellbeschreibung 36 Inkrement 37 Integrations- und Installations-anleitung 37 Integrationskonzept 38 ISDS-Konzept 38 ISDS-Konzept überführt 54 ISDS-Massnahmen realisiert 54 Liste Projektentscheid Steuerung 38 Liste Projektentscheide Führung 38 Lösungsanforderungen 39 Lösungsarchitektur 40 Meilenstein Abnahme 54 Meilenstein Abnahme Migration 54 Meilenstein Ausschreibung 54 Meilenstein Betriebsaufnahme 54 Meilenstein ISDS-Konzept 54 Meilenstein Lösungsarchitektur 55 Meilenstein Phasenfreigabe 55 Meilenstein Phasenfreigabe Abschluss 55 Meilenstein Produktkonzept 55 Meilenstein Projektabschluss 55 Meilenstein

Projektinitialisierungsfreigabe 55 Meilenstein Releasefreigabe 55 Meilenstein Umsetzungsfreigabe 55 Meilenstein Vorabnahme 55 Meilenstein weiteres Vorgehen 55 Meilenstein Zuschlag 55 Migration durchgeführt 55 Migrationskonzept 40 Migrationsverfahren realisiert 56 Offertanfrage 40 Organisation aktiviert 56 Organisation umgesetzt 56 Organisationsanforderungen 41 Organisationsbeschreibung 41 Organisationskonzept 41

Phasenbericht 42 Produkt aktiviert 56 Produkt entwickelt oder angepasst 56 Produktdokumentation 42 Produktkonzept 42 Projekterfahrungen 43 Projektinitialisierungs-auftrag 43 Projektmanagementplan 43 Projektschluss-beurteilung 45 Projektstatusbericht 45 Protokoll 45 Prototyp 46 Prototypdokumentation 46 Prozessbeschreibung 46 Prüfprotokoll 47 Publikation 47 QS- und Risikobericht 47 Rechtsgrundlagenanalyse 47 Releaseplan 48 Schnittstellen realisiert 56 Schutzbedarfsanalyse 48 Service Level Agreement 48 Situationsanalyse 49 Stakeholderinteressen 50 Stakeholderliste 50 Studie 50 System aktiviert 56 System entwickelt oder parametrisiert 56 System integriert 57 Systemkonzept 51 Testinfrastruktur realisiert 57 Testinfrastruktur überführt 57 Testkonzept 51 Testprotokoll 52 Umsetzungsauftrag 52 Vereinbarung 53 Aufgaben Altsystem ausser Betrieb setzen 77 Änderungen managen 78 Angebote bewerten 79 Ausschreibung durchführen 79 Ausschreibung erarbeiten 80 Beschaffungsanalyse erarbeiten 81 Betrieb aktivieren 82 Betrieb realisieren 83 Betriebskonzept erarbeiten 84 Einführung durchführen 85 Einführung realisieren 85 Einführungskonzept erarbeiten 86 Entscheid Abnahme Migration treffen 72 Entscheid Abnahme treffen 73 Entscheid Ausschreibung treffen 62 Entscheid Betriebsaufnahme treffen 63 Entscheid ISDS-Konzept treffen 74 Entscheid Lösungsarchitektur treffen 74 Entscheid Phasenfreigabe Abschluss

treffen 64 Entscheid Phasenfreigabe treffen 65 Entscheid Produktkonzept treffen 75 Entscheid Projektabbruch treffen 66 Entscheid Projektabschluss treffen 67 Entscheid Projektinitialisierungsfreigabe

treffen 68 Entscheid Releasefreigabe treffen 69 Entscheid Umsetzungsfreigabe treffen 70 Entscheid Vorabnahme treffen 75 Entscheid weiteres Vorgehen treffen 76 Entscheid Zuschlag treffen 71 Integrationskonzept erarbeiten 87 ISDS-Konzept erarbeiten 89 ISDS-Konzept realisieren 90 ISDS-Konzept überführen 90 Iterationen durchführen 87 Iterationen planen 88 Leistungen vereinbaren und steuern 91 Lösungsanforderungen erarbeiten 93 Lösungsanforderungen führen 94 Lösungsarchitektur erarbeiten 95 Migration durchführen 95 Migrationskonzept erarbeiten 96 Migrationsverfahren realisieren 97 Organisation aktivieren 97

Organisation umsetzen 98 Organisationsanforderungen erarbeiten 99 Organisationskonzept erarbeiten 100 Phasenfreigabe vorbereiten 100 Probleme behandeln und Erfahrungen

nutzen 101 Produkt aktivieren 102 Produkt realisieren 103 Produktkonzept erarbeiten 103 Projekt führen und kontrollieren 104 Projekt steuern 105 Projektabschluss vorbereiten 107 Projektmanagementplan erarbeiten 108 Prototyping durchführen 109 Qualitätssicherung führen 109 Rechtsgrundlagenanalyse erarbeiten 110 Releaseabschluss vorbereiten 111 Releaseplan erarbeiten 112 Risiken managen 112 Schutzbedarfsanalyse erarbeiten 113 Stakeholder managen und informieren 114 Stakeholderinteressen vertreten 115 Studie erarbeiten 116 System aktivieren 117 System in Betrieb integrieren 117 System realisieren 118 Systemintegration vorbereiten 119 Test durchführen 120 Testinfrastruktur realisieren 120 Testinfrastruktur überführen 121 Testkonzept erarbeiten 122 Umsetzungsauftrag erarbeiten 122 Vereinbarung erarbeiten 123 Module Beschaffung 129 Einführungsorganisation 131 ISDS 133 IT-Betrieb 132 IT-Migration 132 IT-System 130 Organisation 129 Produkt 130 Projektführung 127 Projektgrundlagen 128 Projektsteuerung 126 Tests 131 Rollen Anwendervertreter 148 Anwendungsverantwortlicher 150 Auftraggeber 141 Betriebsverantwortlicher 151 Business Analyst 151 Entwickler 152 Entwicklungsteam 153 Fachausschussmitglied 144 Geschäftsprozess-verantwortlicher 154 ISDS-Verantwortlicher 154 IT-Architekt 156 Iterationsleiter 155 Projektausschussmitglied 143 Projektleiter 145 Projektunterstützung 147 Qualitäts- und Risikomanager 144 Teilprojektleiter 148 Tester 157 Testverantwortlicher 157 Szenarien Dienstleistung/Produkt Adaption 163 Dienstleistung/Produkt Entwicklung 162 IT-Anwendung Adaption 164 IT-Anwendung Entwicklung 164 IT-Infrastruktur 165 Organisationsanpassung 166

HERMES online: www.hermes.admin.ch

Die Projektmanagementmethode für Produkte, Dienst-

leistungen, Informatik und Geschäftsorganisation.

HERMES ist sofort anwendbar und bietet:

Szenarien für konkrete Projektabläufe;

Webtool zur Methodenunterstützung;

Dokumentvorlagen inklusive Checklisten für die effiziente Projektabwicklung.

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 Ergebnisse.

HERMES unterstützt:

den Auftraggeber hinsichtlich Governance und Nachhaltigkeit;

die Projekt- und Programmleiter bei Planung, Kontrolle und Führung;

den Anwendervertreter und weitere Fachspezialisten bei der Projektausfüh-

rung;

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-schaffungs- und Lieferantenmanagement, Stakeholder managen sowie Kommunikation, Risiko- und Qualitätsmanagement, Change Management, klassische und agile Entwicklung, Governance und Nachhaltigkeit. Zudem sind die programm-/projektspezifischen Vorgehensweisen beschrieben.

http://www.hermes.admin.ch/

Documents

2021...Das HERMES Handbuch 2021 ist ein Spiegel unserer schnelllebigen Epoche, auch wenn wir manchmal – unliebsam gebremst werden. Der grösste Teil der Anpassungen betrifft die