Sie sind auf Seite 1von 21

Kolumbus Project Health Check Report RO+e

Allgemeine Informationen
Programm Name:
Programm Manager:
Projekt Manager:
Funktionsverantwortliche:
Health Check Durchführung:
Datum des Health Check:
Projekt Type:
Projekt Lieferdatum:
Programm Budget:
Derzeitige Projekt Phase:
Art und Ziele des Health Check
Art:
Ziel:
Vorgehensweise:
Interviews: Datum Ziel (Referenz zu "Inhalt / Dimensionen") Status
Name, Vorname
Name, Vorname

Inhalt / Dimensionen des Health Checks


Teil 1: Lieferungen / Templates
Teil 2: Projekterfolgsfaktoren
Teil 3: Zeitplan, Aufwand & Kosten
Teil 4: Projektrisiken
Teil 5: Team Struktur
Teil 6: Lessons Learnt

Filename: 10157247.xls/Project Health Check Report Printed on: 11/13/2008


Author:Ralf Eisend VERTRAULICH Page 1 of 21
Kolumbus Project Health Check Report RO+e

Filename: 10157247.xls/Project Health Check Report Printed on: 11/13/2008


Author:Ralf Eisend VERTRAULICH Page 2 of 21
Kolumbus Project Health Check Report RO+e

Filename: 10157247.xls/Project Health Check Report Printed on: 11/13/2008


Author:Ralf Eisend VERTRAULICH Page 3 of 21
Kolumbus Project Health Check Report RO

Teil 1: Lieferungen pro Phase / Team

Filename: 10157247.xls/Teil 1 Printed on: 11/13/2008


Author:Ralf Eisend
VERTRAULICH Page 4 of 21
Kolumbus Project Health Check Report RO

Bewertung: Priorität: Bewert- Gültigkeit: Aktualität: Verfüg- Empfohlene Maßnahme Vereinbarte Maßnahme
1 = OK 3 = muss ung: (reviewd & barkeit:
2 = Optimierungspotenzial 2 = soll 123 signed off)
3 = Handlungsbedarf 1 = kann
Projekt Vorbereitungs Phase
Programm Management
Projekt Auftrag 3 1 3
Vision 3 1 3
Stakeholder Analyse 2 2 4
Projekt Organisation 3 3 Projektstrukturplan mit vollständiger
hierarchischer Anordnung erstellen. 9
Projekt Telefonverzeichnis 2 3 Telefonliste mit Handynummern der
Key Player. 6
Meeting Structure and Schedule 3 3 Meeting hierarchisch strukturieren.
Ziele der Meetings beschreiben.
Teilnehmer der wichtigen Meetings
beschränken.
9
Kommunikation, Reporting (Schedule, 3 3 Einführung von strukturiertem,
Templates, …) hierarchischem Team- und
Projektreporting. Nutzung von
einheitlichen Templates für Reporting.

9
Ressourcen bewilligt 3 0
Urlaubspläne / Anwesenheitspläne 3 3 Urlaubspläne müssen aktualisiert
werden. Urlaub und Schulungen erst
genehmigen nach Rücksprache mit PL.
Dies ist vor allem für das November
Release relevant, da die Urlaubssaison
in diese Zeit fällt. 9
High Level Risiko Identifikation 3 1 3
Risk & Issue Management 3 3 Einführung eines strukturierten Risiko-
Managements. 9
Projekt Directory/ Lotus Notes Database 3 1 3
Business Case 2 1 2
Budget Process 3 1 3
Änderungsmanagement 2 3 Kommunikation der Änderungen.
Anpassen der betroffenen
Dokumentationen. 6
Deliverables Definition & Tracking 3 3 Detailierte Lieferlisten (wer muß bis
wann was liefern) müssen erstellt
erden. 9
Document Review Process 2 3 Review der Dokumente ist vorzugeben.
6

Filename: 10157247.xls/Teil 1 Printed on: 11/13/2008


Author:Ralf Eisend
VERTRAULICH Page 5 of 21
Kolumbus Project Health Check Report RO

Key Performance Indikatoren für Programm / 2 2 Kriterien definierten nach denen das
Projekt Programm und die Projekte als
"erfolgreich" eingestuft werden können.
4
Projekt Controlling 3 1 3
Projekt Marketing 2 2 4
Projekt Planung 3 3 Detailiertere Planung auf
Arbeitspaketebene und konsilidierung
der Detailpläne. 9
Projekt Scope/ Scope Statement 3 1 3
Quality Management 3 3 Verantwortlicher für
Qualitätsmaßnahmen sollte benannt
werden. Umsetzung von
Qualitätsmaßnahmen während der
Entwicklung.
9
Resource Management 3 1 3
Projekt Kick-Off 2 1 2
0
Planungs Phase 0
Programm Management 0
High Level Milestone Plan (Gantt-Chart) 3 2 HL Plan muß auch elektronisch zur
Verfügung stehen und etwas detailierter
strukturiert sein. Inhalt der Phasen
sollte klar beschrieben werden.
6
Low Level Pläne 3 3 Detailiertere Planung auf
Arbeitspaketebene und konsilidierung
der Detailpläne. 9
Genehmigtes Budget 3 0
Bewilligte Ressourcen 3 0
Lieferdaten für Dokumente & Erwartung an 3
Dokumente 0
Budget Tracking ist aufgesetzt 3 0
Risiko Management Plan 3 0
Abhängigkeiten zwischen den Projekten 3 0
0
Anforderungsmanagement /Design & Architektur
0
Funktionale Anforderungen an das System 3 0
Architekturübersicht & Schnittstellenübersicht 3 0
Betriebliche Anforderungen an das System 3 0
Vorgehensmodell / Plan zum 3
Anforderungsmanagment 0
Entwicklung 0
High Level Design (Grobkonzept) 3 0

Filename: 10157247.xls/Teil 1 Printed on: 11/13/2008


Author:Ralf Eisend
VERTRAULICH Page 6 of 21
Kolumbus Project Health Check Report RO

Aufwände geschätzt RIA / (+/- 25 %) 3 0


Software Entwicklungs Plan 2 0
Quality Assurance 0
QA-Strategie / Konzept 3 0
Master Testplan 3 0
Rollout & Abnahme 0
Rollout & Schulungsplan 3 0
Produkt Akzeptanz Plan / Abnahme Konzept 3 0
Betrieb 0
Auswirkungen HW / SW 3 0
Auswirkungen Betrieb 3 0
Betriebliche Anforderungen Vertreter des Betriebs sollte in Projekt
vertreten sein und die betrieblichen
3 3 Anforderungen aufstellen. 9
0
0
Umsetzungs Phase 0
Programm Mangement 0
0
0
Anforderungsmanagement 0
Fachkonzepte 0
GUI Designs completed 0
0
Entwicklung 0
DV-Konzepte 0
E2E-design walkthrough 0
Component Test Plan 3 3 Komponenten Test Pläne sollten erstellt
werden. QA muß wissen was bereits
getestet wurde. 9
Component Test Completion Report 3 3 Komponenten Test Pläne sollten erstellt
werden. QA muß wissen was bereits
getestet wurde. 9
Administrator Handbuch 0
Einsatzinfo 0
Installationshandbuch 0
Deinstallationsbeschreibung 0
Release Notes 0
Fall Back Plan 3 3 Fall Back Plan sollte existieren, damit
das Bestandsgeschäft bei einem
Scheitern der Implementierung nicht
gefährdet wird. 9
0
Quality Assurance 0

Filename: 10157247.xls/Teil 1 Printed on: 11/13/2008


Author:Ralf Eisend
VERTRAULICH Page 7 of 21
Kolumbus Project Health Check Report RO

Test Master Plan (QA) 3 3 Strukturierte Gesamtübersicht über die


Tests sollte aufgestellt werden. 9
System Integration Test Plan 3 2 6
Gesamt Integrations Test Plan 3 2 6
Test Completion Report 3 2 6
0
Rollout & Abnahme 0
Schulungspläne 3 1 3
Rollout Pläne 3 2 6
Benutzerhandbücher 3 0
Einsatzkonzept 3 1 3
User Acceptance Test Plan 3 1 3
Abnahme Test Plan 3 1 3
0
Betrieb 0
Infrastruktur Planung 3 1 3
Verifikationsplan 3 3 Für die Verifikation muß pro RZ ein
Verantwortlicher benannt werden. 9
0
0
After Launch Phase 0
Programm Management 0
Post Implementation Review 3 0
Problem Management 3 3 Problem Management im After Launch
muß geplant und organisert werden. 9
Eskalation Management 3 3 Eskalations Management im After
Launch muß geplant und organisert
werden. 9
0
Betrieb 0
Reporting after Launch 3 0
0

Filename: 10157247.xls/Teil 1 Printed on: 11/13/2008


Author:Ralf Eisend
VERTRAULICH Page 8 of 21
Kolumbus Project Health Check Report RO

Teil 2: Projekterfolgsfaktoren

Filename: 10157247.xls/Teil 2 Printed on: 11/13/2008


Author:Ralf Eisend
VERTRAULICH Page 9 of 21
Kolumbus Project Health Check Report RO

Bewertung: Priorität: Bewert- Wahrnehmung Empfohlene Maßnahme Vereinbarte Maßnahme


1 = OK 3 = muss ung:
2 = Optimierungspotenzial 2 = soll 123
3 = Handlungsbedarf 1 = kann
Allgemeine Projekt-Erfolgsfaktoren
Zielkonformität 3.00
Strategiekonformität 3 1 3.00
Stabiler Scope (keine wechselnden Ziele, 3 1 3.00
moving target)
Einbindung der Kunden 3 1 3.00
Konsistente Planung und Kommunikation 7.00
Projektkommunikation 3 1 3.00
Meetingstruktur 3 3 Meetings haben immer zu viele Meeting hierarchisch strukturieren. 9.00
Teilnehmer. Ziele der Meetings Ziele der Meetings beschreiben.
sind unklar beschrieben. Meetings Teilnehmer der wichtigen Meetings
sind nicht hierarchisch und haben beschränken.
keinen inneren Zusammenhalt.

Meetingkultur 3 3 Häufig keine Agenda, häufig ist Den Projektmitarbeitern müssen die 9.00
den Teilnehmern Ihre Rolle nicht Grundregeln von Arbeitssitzungen
klar. Es werden kaum Aufgaben vorgelebt werden.
verteilt. Es wird nur informiert. Es Protokolle schreiben.
wird nur selten ein Protokoll Meetings nur mit Agenda.
geschrieben. Die Teilnehmer Keine Laptops oder Handys in
arbeiten während der Sitzungen Sitzungen.
am Laptop und zeigen
Desinteresse.

Gesamtsicht Architektur / Design 3 3 Arbeitsergebnisse von Design und Ziele des Arbeitspakets Design und 9.00
Architektur sind nicht erkennbar Architektur beschreiben und Ergebnisse
und unverständlich. einfordern.
Klarheit über Big-Picture - Programm 3 1 3.00
Vorgaben
Projektplanung 3 3 Projekt ist nur high level geplant Detailierte Planung aller Projekte und 9.00
Subprojekte erstellen und
konsolidieren.
Steuerung 8.00
Einsatz von State of the Art tools 3 3 keine adäquate Toolunterstützung Auswahl Tools für QA und ggfl. für 9.00
bei QA und für Anforderungsmanagement.
Anforderungsmanagement.
Entscheidungsfähigkeit /-schnelligkeit 3 2 In heissen Phasen sind tägliche In heissen Phasen müssen tägliche 6.00
Früh- und Abend-termine nicht Morgenstund' Sitzungen eingeführt
institutionalisiert. werden.
Alle wissen immer in welche Richtung zu 3 3 Enges Management der Engere Aufgabensteuerung einführen 9.00
ziehen ist. Es gibt kein Herumirren. Ressourcen und Aufgaben wird
nicht wahrgenommen

Filename: 10157247.xls/Teil 2 Printed on: 11/13/2008


Author:Ralf Eisend
VERTRAULICH Page 10 of 21
Kolumbus Project Health Check Report RO

Klarheit über Verantwortlichkeiten 3 3 Verantwortliche sind benannt, was Verantwortlichkeiten müssen anhand 9.00
diese liefern müssen wird nicht der erwarteten Ergebnisse geplant
genau beschrieben. werden und sich im Reporting (Team /
Verantwortlichkeiten werden von Projekt / Programm Reporting)
den MA teilweise nicht Niederschlag finden.
wahrgenommen
Priorisierung 3 2 Priorosierungslücke bei QA. Priorisierung von Testcases 6.00
durchführen.
Management Unterstützung 3 3 2 mtl. Steering Boards sind zu 4 Wöchentliches Steering Board, 9.00
wenig. wöchentliches Programm Reporting ans
Die High Prio Themen sind nicht Steering Board.
auf dem Management Radar.
0.00
Kontrolle 6.75
Abhängigkeiten werden erkannt 3 3 9.00
Technische Abhängigkeiten sind Technische Abhängigkeiten müssen
nicht dargestellt und werden kaum dargestellt und kommuniziert werden.
berücksichtigt.
Konsistentes Reporting - Fortschritt und 3 3 Reporting nach Zeitlichem Einführung von strukturiertem, 9.00
Status Fortschritt, Budget, verfügbaren hierarchischem Team- und
Ressourcen, Risiken und Projektreporting.
Problemen, Zielerreichung und
nächste Schritte wird nicht
strukturiert durchgeführt.
Klarheit der Entscheidungsfindung 3 1 3.00
Transparentes Budget (IST-SOLL) 3 2 6.00
Organisation & Effizienz 6.25
Passt die Projekt- und Programmstruktur 3 2 Ein übergeordneter Projektleiter und 6.00
Phasenverantwortliche sollen benannt
werden.
Dokumentenvorlagen 2 2 Einige der verwendeten Bei der Ergebnisplanung pro 4.00
Dokumente sind zu lange / Arbeitspaket / Phase sollten die
umfangreich: Bsp Einsatzinfo Dokumentenvorlagen kritisch
untersucht werden auf "fit for purpose".
Zu lange Dokumente lassen sich nicht
reviewen.
Zusammenarbeit (Interfaces) sind genau 3 3 Phasenübergänge sind nicht Detailiertere Planung der Phasen mit 9.00
definiert geplant. Eingangskriterien und definierten Verantwortlichen pro Phase
Ausgangskriterien sind nicht sind notwendig.
definiert.

Verbindlichkeit von Aussagen (Verantwortung 3 2 Vereinbarungen und In Protokollen müssen Entscheidungen 6.00
- Kompetenz) Entscheidungen werden nicht und offene Aktionen deutlich
immer dokumentiert und gekennzeichnet werden.
kommuniziert.
0.00
0.00
0.00

Filename: 10157247.xls/Teil 2 Printed on: 11/13/2008


Author:Ralf Eisend
VERTRAULICH Page 11 of 21
Kolumbus Project Health Check Report RO

Projekt-Erfolgsfaktoren-Offshoring: 0.00
Organisatorische Schnittstellen managen 9.00
Aufgaben, Übergabepunkte und Schnittstellen 3 3 Die kritischen Übergabepunkte Ein- Ausgangskriterien pro Phase 9.00
sind klar kommuniziert und jedem bekannt. sind nicht klar defininert. Ein- und definieren.
Ausgangskriterien fehlen pro
Phase.
Dokumente werden nicht sauber
reviewt und abgezeichnet.
0.00
SW-Lieferungen sicherstellen 6.57
Definierte Eingangs- und Ausgangskriterien 3 3 Ein- und Ausgangskriterien fehlen Ein- Ausgangskriterien pro Phase 9.00
für jede Phase / Aufgabe pro Phase. definieren.
Projektweite Standards und Richtlinien 3 1 3.00
Etablierte Qualitätskontrollen 3 3 Qualitätmanagementmaßnahmen Code reviews müssen früher 9.00
werden während des durchgeführt werden.
Entwicklungszeitraums nur wenige Schnittstellenbeschreibungen müssen
durchgeführt. geliefert werden. Syntax und
Semantikarbeitssitzugnen müssen
gehalten werden. Design Walkthroughs
müssen durchgeführt werden.
Komponenten Tests müssen geplant
und dokumentiert werden.

Regelmäßige Reporting- und 3 3 Reporting ist detailiert und bietet Konsistentes, regelmäßiges Reporting 9.00
Feedbackschleifen keine Übersicht über die aufbauen.
wichtigsten Themen.
Qualitätsstandard (DIN ISO 9xxx) 1 1 1.00
Sprachbarrienen werden überwunden 3 3 9.00
Kulturelle Barrieren werden überwunden 2 3 6.00
0.00
Integration des externen Entwicklungsteams 4.17
Rotation der MA onsite und offsite 2 3 Rotation einführen. 6.00
Review Runden in Wien.
Adäquate Dokumentation 3 1 3.00
Offsite Unterstützungsteam für Qualität, 2 2 4.00
Management, Produktivität und Ausbildung.
Regelmäßige gegenseitige Besuche 2 1 2.00
Transparenz in den Abläufen 2 2 4.00
Regelmäßige Steering Komitee Meetings 2 3 2 mtl. Steering Boards sind zu 4 Wöchentliches Steering Board, 6.00
wenig. wöchentliches Programm Reporting ans
Die High Prio Themen sind nicht Steering Board.
auf dem Management Radar.
0.00
Daten-Sicherheit 3.00
Unauthorisierten Zugriff auf Systeme 3 1 3.00
vermeiden

Filename: 10157247.xls/Teil 2 Printed on: 11/13/2008


Author:Ralf Eisend
VERTRAULICH Page 12 of 21
Kolumbus Project Health Check Report RO

Gut beschriebene Back-up Vorgaben 3 1 3.00


Sicherung von Intellektuellem Eigentum 3 1 3.00
0.00

Filename: 10157247.xls/Teil 2 Printed on: 11/13/2008


Author:Ralf Eisend
VERTRAULICH Page 13 of 21
Kolumbus Project Health Check Report RO

Teil 3: Zeitplan, Aufwand und Kosten


Plan Ist Abweichung Kommentar
Projekt Start
Projekt Ende
Aufwand in MT
Kosten
Hardware
Software
interne MA
externe MA

Empfohlene Maßnahme:
Vereinbarte Maßnahme:

Filename: 10157247.xls/Teil 3 Printed on: 11/13/2008


Author:Ralf Eisend
VERTRAULICH Page 14 of 21
Kolumbus Project Health Check Report RO

Teil 4: Projektrisiken (top 10)


Risiko Eintritts- Aus- Gewichtung Maßnahme Verantwortlicher
wahrschei wirkung (1- (ExA) (natürliche Person)
nlich-keit 5)
(1-5)

Es gibt kein gesichertes Q-Environement. 0


0
0
0
0
0
0
0
0
0

Filename: 10157247.xls/Teil 4 Printed on: 11/13/2008


Author:Ralf Eisend
VERTRAULICH Page 15 of 21
Kolumbus Project Health Check Report RO

Teil 5: Team Struktur


Bewertung: Priorität: Bewert-ung: Kommentar
1 = OK 3 = muss 123
2 = Optimierungspotenzial 2 = soll
3 = Handlungsbedarf 1 = kann

Erfahrung
Tools & Techniken 3
Prozesse & Standards 2
Produkt (Software) 3
Banken know how 2
Software Entwicklungszyklus 2
Teamwork
Motivation 3
Teamspirit / Teamzusammenhalt 2 Vertreter sind nicht benannt.
Management Unterstützung 3
Kunde mit einbezogen 3
Team Fluktuation
bis 5 %
bis 10 %
über 10 %
Operational Support (Betrieb der Umgebungen)
Zufriedenheit 3

Empfohlene Maßnahme: Vertreterregelungen sollen für key player (Schlüsselfunktionen) getroffen werden.
Vereinbarte Maßnahme:

Filename: 10157247.xls/Teil 5 Printed on: 11/13/2008


Author:Ralf Eisend
VERTRAULICH Page 16 of 21
Kolumbus Project Health Check Report RO

Teil 6: Lessons Learnt


Verbesserungspotenzial

postitive Einflüsse im Projekt

negative Einflüsse im Projekt

Verbesserungspotenzial

Filename: 10157247.xls/Teil 6 Printed on: 11/13/2008


Author:Ralf Eisend
VERTRAULICH Page 17 of 21
Artefakt
Software Entwicklungs Plan

Qualitäts Sicherungs Plan

Risiko Management Plan

Produkt Akzeptanz Plan


Beschreibung
The purpose of the Software Development Plan is to gather all of the information necessary to control the
project. It describes the approach to the development of the software, and is the top-level plan generated
and used by the managers to direct the development effort.
The purpose of the Quality Assurance Plan is to provide a single point of reference on the topic of quality for
the project. It is a process-oriented artifact and highlights those elements that are the contributors to
achievement of quality objectives. The Quality Assurance Plan will not contain details of the techniques,
criteria, metrics, and so on, of the peer reviews and evaluations whose focus is product.
The purpose of the Risk Management Plan is to ensure that project risks are properly identified, analyzed,
documented, mitigated, monitored, and controlled. It describes the approach that will be used to identify,
analyze, prioritize, monitor, and mitigate risks.

The Risk Management Plan should be updated when risks or mitigation strategies change.
The purpose of the Product Acceptance Plan is to ensure that an objective and clearly-defined procedure,
and a set of criteria will be used to determine whether the artifacts to be delivered to the customer are
acceptable.
Zielkonformität 3.00 11.00
Konsistente Planung und Kommunikation 7.00 8.00
Steuerung 8.00 7.00
Kontrolle 6.75 8.25
Organisation & Effizienz 6.25 8.75
Organisatorische Schnittstellen managen 9.00 6.00
SW-Lieferungen sicherstellen 6.57 8.43
Integration des externen Entwicklungsteams 4.17 10.83
Daten-Sicherheit 3.00 12.00

Zielkonformität

20.00
Konsistente Planung und Kommunikation

Daten-Sicherheit

10.00

Steuerung Integration des


0.00

Kontrolle SW-Lieferungen s

Organisation
Organisatorische
& Effizienz Schnittstellen managen
Daten-Sicherheit

Integration des externen Entwicklungsteams

SW-Lieferungen sicherstellen

en managen