Project Health Check

Project Health Check Report

Kolumbus

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 Author:Ralf Eisend

VERTRAULICH

Printed on: 11/13/2008 Page 1 of 21

Kolumbus

Filename: 10157247.xls/Project Health Check Report Author:Ralf Eisend

Project Health Check Report

VERTRAULICH

RO+e

Printed on: 11/13/2008 Page 2 of 21

Kolumbus

Filename: 10157247.xls/Project Health Check Report Author:Ralf Eisend

Project Health Check Report

VERTRAULICH

RO+e

Printed on: 11/13/2008 Page 3 of 21

Kolumbus

Project Health Check Report

RO

Teil 1: Lieferungen pro Phase / Team

Filename: 10157247.xls/Teil 1 Author:Ralf Eisend

VERTRAULICH

Printed on: 11/13/2008 Page 4 of 21

Project Health Check Report

Kolumbus Bewertung: 1 = OK 2 = Optimierungspotenzial 3 = Handlungsbedarf

Priorität: 3 = muss 2 = soll 1 = kann

Bewertung: 123

Projekt Vorbereitungs Phase Programm Management Projekt Auftrag Vision Stakeholder Analyse Projekt Organisation

3 3 2 3

1 1 2 3

Projekt Telefonverzeichnis

2

3

Meeting Structure and Schedule

3

3

Kommunikation, Reporting (Schedule, Templates, …)

3

3

Ressourcen bewilligt Urlaubspläne / Anwesenheitspläne

3 3

3

High Level Risiko Identifikation Risk & Issue Management

3 3

1 3

Projekt Directory/ Lotus Notes Database Business Case Budget Process Änderungsmanagement

3 2 3 2

1 1 1 3

Deliverables Definition & Tracking

3

3

Document Review Process

2

3

Gültigkeit: (reviewd & signed off)

Aktualität:

Verfügbarkeit:

Empfohlene Maßnahme

RO Vereinbarte Maßnahme

3 3 4 Projektstrukturplan mit vollständiger hierarchischer Anordnung erstellen. Telefonliste mit Handynummern der Key Player. Meeting hierarchisch strukturieren. Ziele der Meetings beschreiben. Teilnehmer der wichtigen Meetings beschränken.

9 6

9

Einführung von strukturiertem, hierarchischem Team- und Projektreporting. Nutzung von einheitlichen Templates für Reporting. 9 0 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. Einführung eines strukturierten RisikoManagements.

Kommunikation der Änderungen. Anpassen der betroffenen Dokumentationen. Detailierte Lieferlisten (wer muß bis wann was liefern) müssen erstellt erden. Review der Dokumente ist vorzugeben.

9 3 9 3 2 3 6 9 6

Filename: 10157247.xls/Teil 1 Author:Ralf Eisend

VERTRAULICH

Printed on: 11/13/2008 Page 5 of 21

Project Health Check Report

Kolumbus Key Performance Indikatoren für Programm / Projekt

2

2

Projekt Controlling Projekt Marketing Projekt Planung

3 2 3

1 2 3

Projekt Scope/ Scope Statement Quality Management

3 3

1 3

Resource Management Projekt Kick-Off

3 2

1 1

3

2

HL Plan muß auch elektronisch zur Verfügung stehen und etwas detailierter strukturiert sein. Inhalt der Phasen sollte klar beschrieben werden.

Low Level Pläne

3

3

Detailiertere Planung auf Arbeitspaketebene und konsilidierung der Detailpläne.

Genehmigtes Budget Bewilligte Ressourcen Lieferdaten für Dokumente & Erwartung an Dokumente Budget Tracking ist aufgesetzt Risiko Management Plan Abhängigkeiten zwischen den Projekten

3 3 3

Planungs Phase Programm Management High Level Milestone Plan (Gantt-Chart)

RO

Kriterien definierten nach denen das Programm und die Projekte als "erfolgreich" eingestuft werden können. 4 3 4 Detailiertere Planung auf Arbeitspaketebene und konsilidierung der Detailpläne.

9 3

Verantwortlicher für Qualitätsmaßnahmen sollte benannt werden. Umsetzung von Qualitätsmaßnahmen während der Entwicklung. 9 3 2 0 0 0

6 9 0 0 0 0 0 0 0

3 3 3

Anforderungsmanagement /Design & Architektur Funktionale Anforderungen an das System Architekturübersicht & Schnittstellenübersicht Betriebliche Anforderungen an das System Vorgehensmodell / Plan zum Anforderungsmanagment Entwicklung High Level Design (Grobkonzept)

Filename: 10157247.xls/Teil 1 Author:Ralf Eisend

0 0 0 0

3 3 3 3

0 0 0

3

VERTRAULICH

Printed on: 11/13/2008 Page 6 of 21

Project Health Check Report

Kolumbus Aufwände geschätzt RIA / (+/- 25 %) Software Entwicklungs Plan Quality Assurance QA-Strategie / Konzept Master Testplan Rollout & Abnahme Rollout & Schulungsplan Produkt Akzeptanz Plan / Abnahme Konzept Betrieb Auswirkungen HW / SW Auswirkungen Betrieb Betriebliche Anforderungen

0 0 0 0 0 0 0 0 0 0 0

3 2 3 3 3 3 3 3 3

3

3

3

3

3

Vertreter des Betriebs sollte in Projekt vertreten sein und die betrieblichen Anforderungen aufstellen.

Umsetzungs Phase Programm Mangement

Anforderungsmanagement Fachkonzepte GUI Designs completed Entwicklung DV-Konzepte E2E-design walkthrough Component Test Plan Component Test Completion Report Administrator Handbuch Einsatzinfo Installationshandbuch Deinstallationsbeschreibung Release Notes Fall Back Plan

3

Komponenten Test Pläne sollten erstellt werden. QA muß wissen was bereits getestet wurde. Komponenten Test Pläne sollten erstellt werden. QA muß wissen was bereits getestet wurde.

3

Fall Back Plan sollte existieren, damit das Bestandsgeschäft bei einem Scheitern der Implementierung nicht gefährdet wird.

Quality Assurance

Filename: 10157247.xls/Teil 1 Author:Ralf Eisend

RO

VERTRAULICH

9 0 0 0 0 0 0 0 0 0 0 0 0 0 9 9 0 0 0 0 0

9 0 0

Printed on: 11/13/2008 Page 7 of 21

Project Health Check Report

Kolumbus Test Master Plan (QA)

3

3

System Integration Test Plan Gesamt Integrations Test Plan Test Completion Report

3 3 3

2 2 2

Rollout & Abnahme Schulungspläne Rollout Pläne Benutzerhandbücher Einsatzkonzept User Acceptance Test Plan Abnahme Test Plan

3 3 3 3 3 3

1 2

Betrieb Infrastruktur Planung Verifikationsplan

3 3

1 3

After Launch Phase Programm Management Post Implementation Review Problem Management Eskalation Management

Betrieb Reporting after Launch

Filename: 10157247.xls/Teil 1 Author:Ralf Eisend

Strukturierte Gesamtübersicht über die Tests sollte aufgestellt werden.

1 1 1

3 3

3

3

3

Für die Verifikation muß pro RZ ein Verantwortlicher benannt werden.

Problem Management im After Launch muß geplant und organisert werden. Eskalations Management im After Launch muß geplant und organisert werden.

3

VERTRAULICH

RO

9 6 6 6 0 0 3 6 0 3 3 3 0 0 3 9 0 0 0 0 0 9 9 0 0 0 0

Printed on: 11/13/2008 Page 8 of 21

Kolumbus

Project Health Check Report

RO

Teil 2: Projekterfolgsfaktoren

Filename: 10157247.xls/Teil 2 Author:Ralf Eisend

VERTRAULICH

Printed on: 11/13/2008 Page 9 of 21

Project Health Check Report

Kolumbus Bewertung: 1 = OK 2 = Optimierungspotenzial 3 = Handlungsbedarf Allgemeine Projekt-Erfolgsfaktoren Zielkonformität Strategiekonformität Stabiler Scope (keine wechselnden Ziele, moving target) Einbindung der Kunden Konsistente Planung und Kommunikation Projektkommunikation Meetingstruktur

Priorität: Bewert3 = muss ung: 2 = soll 123 1 = kann

3 3

1 1

3

1

3 3

1 3

Meetingkultur

3

Gesamtsicht Architektur / Design Klarheit über Big-Picture - Programm Vorgaben Projektplanung

Wahrnehmung

Empfohlene Maßnahme

Meeting hierarchisch strukturieren. Ziele der Meetings beschreiben. Teilnehmer der wichtigen Meetings beschränken.

3

Häufig keine Agenda, häufig ist den Teilnehmern Ihre Rolle nicht klar. Es werden kaum Aufgaben verteilt. Es wird nur informiert. Es wird nur selten ein Protokoll geschrieben. Die Teilnehmer arbeiten während der Sitzungen am Laptop und zeigen Desinteresse.

Den Projektmitarbeitern müssen die Grundregeln von Arbeitssitzungen vorgelebt werden. Protokolle schreiben. Meetings nur mit Agenda. Keine Laptops oder Handys in Sitzungen.

3

3

Arbeitsergebnisse von Design und Ziele des Arbeitspakets Design und Architektur sind nicht erkennbar Architektur beschreiben und Ergebnisse und unverständlich. einfordern.

3

1

3

3

Projekt ist nur high level geplant

Detailierte Planung aller Projekte und Subprojekte erstellen und konsolidieren.

3

3

Auswahl Tools für QA und ggfl. für Anforderungsmanagement.

Entscheidungsfähigkeit /-schnelligkeit

3

2

Alle wissen immer in welche Richtung zu ziehen ist. Es gibt kein Herumirren.

3

3

keine adäquate Toolunterstützung bei QA und für Anforderungsmanagement. In heissen Phasen sind tägliche Früh- und Abend-termine nicht institutionalisiert. Enges Management der Ressourcen und Aufgaben wird nicht wahrgenommen

Filename: 10157247.xls/Teil 2 Author:Ralf Eisend

Vereinbarte Maßnahme

3.00 3.00 3.00

Meetings haben immer zu viele Teilnehmer. Ziele der Meetings sind unklar beschrieben. Meetings sind nicht hierarchisch und haben keinen inneren Zusammenhalt.

Steuerung Einsatz von State of the Art tools

RO

3.00 7.00 3.00 9.00

9.00

9.00 3.00

In heissen Phasen müssen tägliche Morgenstund' Sitzungen eingeführt werden. Engere Aufgabensteuerung einführen

VERTRAULICH

9.00 8.00 9.00 6.00 9.00

Printed on: 11/13/2008 Page 10 of 21

Project Health Check Report

Kolumbus Klarheit über Verantwortlichkeiten

3

3

Priorisierung

3

2

Management Unterstützung

3

3

Kontrolle Abhängigkeiten werden erkannt

3

Verantwortliche sind benannt, was diese liefern müssen wird nicht genau beschrieben. Verantwortlichkeiten werden von den MA teilweise nicht wahrgenommen Priorosierungslücke bei QA. 2 mtl. Steering Boards sind zu wenig. Die High Prio Themen sind nicht auf dem Management Radar.

RO

Verantwortlichkeiten müssen anhand der erwarteten Ergebnisse geplant werden und sich im Reporting (Team / Projekt / Programm Reporting) Niederschlag finden.

9.00

Priorisierung von Testcases durchführen. 4 Wöchentliches Steering Board, wöchentliches Programm Reporting ans Steering Board.

6.00 9.00

0.00 6.75 9.00

3 Technische Abhängigkeiten sind nicht dargestellt und werden kaum berücksichtigt. Reporting nach Zeitlichem Fortschritt, Budget, verfügbaren Ressourcen, Risiken und Problemen, Zielerreichung und nächste Schritte wird nicht strukturiert durchgeführt.

Konsistentes Reporting - Fortschritt und Status

3

3

Klarheit der Entscheidungsfindung Transparentes Budget (IST-SOLL) Organisation & Effizienz Passt die Projekt- und Programmstruktur

3 3

1 2

3

2

Dokumentenvorlagen

2

2

Einige der verwendeten Dokumente sind zu lange / umfangreich: Bsp Einsatzinfo

Zusammenarbeit (Interfaces) sind genau definiert

3

3

Phasenübergänge sind nicht geplant. Eingangskriterien und Ausgangskriterien sind nicht definiert.

Verbindlichkeit von Aussagen (Verantwortung - Kompetenz)

3

2

Vereinbarungen und Entscheidungen werden nicht immer dokumentiert und kommuniziert.

Technische Abhängigkeiten müssen dargestellt und kommuniziert werden. Einführung von strukturiertem, hierarchischem Team- und Projektreporting.

Ein übergeordneter Projektleiter und Phasenverantwortliche sollen benannt werden. Bei der Ergebnisplanung pro Arbeitspaket / Phase sollten die Dokumentenvorlagen kritisch untersucht werden auf "fit for purpose". Zu lange Dokumente lassen sich nicht reviewen. Detailiertere Planung der Phasen mit definierten Verantwortlichen pro Phase sind notwendig. In Protokollen müssen Entscheidungen und offene Aktionen deutlich gekennzeichnet werden.

9.00

3.00 6.00 6.25 6.00 4.00

9.00

6.00

0.00 0.00 0.00 Filename: 10157247.xls/Teil 2 Author:Ralf Eisend

VERTRAULICH

Printed on: 11/13/2008 Page 11 of 21

Project Health Check Report

Kolumbus Projekt-Erfolgsfaktoren-Offshoring: Organisatorische Schnittstellen managen Aufgaben, Übergabepunkte und Schnittstellen sind klar kommuniziert und jedem bekannt.

SW-Lieferungen sicherstellen Definierte Eingangs- und Ausgangskriterien für jede Phase / Aufgabe Projektweite Standards und Richtlinien Etablierte Qualitätskontrollen

3

3

Die kritischen Übergabepunkte Ein- Ausgangskriterien pro Phase sind nicht klar defininert. Ein- und definieren. Ausgangskriterien fehlen pro Phase. Dokumente werden nicht sauber reviewt und abgezeichnet.

RO 0.00 9.00 9.00

0.00 6.57 9.00

3

3

3 3

1 3

Regelmäßige Reporting- und Feedbackschleifen

3

3

Qualitätsstandard (DIN ISO 9xxx) Sprachbarrienen werden überwunden Kulturelle Barrieren werden überwunden

1 3 2

1 3 3

Integration des externen Entwicklungsteams Rotation der MA onsite und offsite

2

3

3 2

1 2

3.00 4.00

2 2 2

1 2 3

2.00 4.00 6.00

Adäquate Dokumentation Offsite Unterstützungsteam für Qualität, Management, Produktivität und Ausbildung. Regelmäßige gegenseitige Besuche Transparenz in den Abläufen Regelmäßige Steering Komitee Meetings

Daten-Sicherheit Unauthorisierten Zugriff auf Systeme vermeiden

Filename: 10157247.xls/Teil 2 Author:Ralf Eisend

3

Ein- und Ausgangskriterien fehlen Ein- Ausgangskriterien pro Phase pro Phase. definieren. Qualitätmanagementmaßnahmen werden während des Entwicklungszeitraums nur wenige durchgeführt.

Code reviews müssen früher durchgeführt werden. Schnittstellenbeschreibungen müssen geliefert werden. Syntax und Semantikarbeitssitzugnen müssen gehalten werden. Design Walkthroughs müssen durchgeführt werden. Komponenten Tests müssen geplant und dokumentiert werden.

Reporting ist detailiert und bietet keine Übersicht über die wichtigsten Themen.

Konsistentes, regelmäßiges Reporting aufbauen.

Rotation einführen. Review Runden in Wien.

2 mtl. Steering Boards sind zu wenig. Die High Prio Themen sind nicht auf dem Management Radar.

4 Wöchentliches Steering Board, wöchentliches Programm Reporting ans Steering Board.

3.00 9.00

9.00 1.00 9.00 6.00 0.00 4.17 6.00

0.00 3.00 3.00

1

VERTRAULICH

Printed on: 11/13/2008 Page 12 of 21

Project Health Check Report

Kolumbus Gut beschriebene Back-up Vorgaben Sicherung von Intellektuellem Eigentum

Filename: 10157247.xls/Teil 2 Author:Ralf Eisend

3 3

1 1

RO 3.00 3.00 0.00

VERTRAULICH

Printed on: 11/13/2008 Page 13 of 21

Project Health Check Report

Kolumbus

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 Author:Ralf Eisend

VERTRAULICH

Printed on: 11/13/2008 Page 14 of 21

Kolumbus

Project Health Check Report

RO

Teil 4: Projektrisiken (top 10) Risiko

Es gibt kein gesichertes Q-Environement.

Filename: 10157247.xls/Teil 4 Author:Ralf Eisend

Maßnahme

Eintritts- AusGewichtung wahrschei wirkung (1- (ExA) nlich-keit 5) (1-5)

Verantwortlicher (natürliche Person)

0 0 0 0 0 0 0 0 0 0

VERTRAULICH

Printed on: 11/13/2008 Page 15 of 21

Project Health Check Report

Kolumbus

RO

Teil 5: Team Struktur Bewertung: 1 = OK 2 = Optimierungspotenzial 3 = Handlungsbedarf Erfahrung Tools & Techniken Prozesse & Standards Produkt (Software) Banken know how Software Entwicklungszyklus Teamwork Motivation Teamspirit / Teamzusammenhalt Management Unterstützung Kunde mit einbezogen Team Fluktuation bis 5 % bis 10 % über 10 % Operational Support (Betrieb der Umgebungen) Zufriedenheit

Priorität: 3 = muss 2 = soll 1 = kann

Bewert-ung: Kommentar 123

3 2 3 2 2 3 2 3 3

Vertreter sind nicht benannt.

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

Filename: 10157247.xls/Teil 5 Author:Ralf Eisend

VERTRAULICH

Printed on: 11/13/2008 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 Author:Ralf Eisend

VERTRAULICH

Printed on: 11/13/2008 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 Konsistente Planung und Kommunikation Steuerung Kontrolle Organisation & Effizienz Organisatorische Schnittstellen managen SW-Lieferungen sicherstellen Integration des externen Entwicklungsteams Daten-Sicherheit

3.00 7.00 8.00 6.75 6.25 9.00 6.57 4.17 3.00

11.00 8.00 7.00 8.25 8.75 6.00 8.43 10.83 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