Projektmanagement- und Dokumentationskonzept

Diese Zusammenfassung beschreibt ein Projektmanagement- und Dokumentationskonzept der mdw, das den Prozess von der initialen Kundenanfrage bis zum laufenden Betrieb strukturiert. Es gliedert sich in drei Hauptphasen: Ticketsystem, Umsetzung (unterteilt in Requirement Engineering, Solution Engineering und die Projektphase selbst) und laufender Betrieb. Der Fokus liegt auf einer detaillierten Anforderungserhebung, der gemeinsamen Lösungsfindung mit dem Kunden und der klaren Definition von Rollen und Verantwortlichkeiten. Der Einsatz von Tools wie Zammad, OpenProject und GitLab unterstützt die effiziente Abwicklung und Dokumentation der Projekte. Das Ziel ist eine strukturierte und erfolgreiche Projektabwicklung mit kontinuierlicher Verbesserung.
 

Ablauf

 

1. Ticketsystem

Jedes Projekt beginnt mit der Erfassung eines Kundenwunsches oder Problems im Ticketsystem. Der Helpdesk ist dafür zuständig, die Tickets zu prüfen und den zuständigen Mitarbeitern zuzuweisen. Abhängig vom Inhalt wird eine Priorisierung vorgenommen und abhängig von der Art des Tickets – Supportfall, Serviceanfrage oder neue Anforderung (etwa in Form einer Idee oder eines Wunsches) – wird der weitere Prozessablauf festgelegt.

Abgrenzung

Supportfälle betreffen die Behebung von Fehlern und Störungen, während Serviceanfragen die Bereitstellung von Dienstleistungen umfassen, die keine neuen Anforderungen darstellen (z.B. die Zurverfügungstellung virtueller Infrastruktur). Handelt es sich um eine neue Anforderung, beginnt der Prozess des Requirements Engeineering.

Das Ticketsystem wird in dem neuen Prozess das bisherige Tool Anforderungsmanagement ersetzen.
 

2. Umsetzung

2.1. Requirements Engineering (RE)

Ziel des RE ist es, die Bedürfnisse und Wünsche der Kunden so präzise wie möglich zu verstehen, um eine solide Grundlage für die Entwicklung einer Lösung zu schaffen Die zentrale Frage des RE lautet: WAS wird WARUM benötigt? (Ziel). Im Fokus steht die detaillierte Erhebung des Kundenwunsches, die Erhebungsphase beschäftigt sich mit den W-Fragen: Wer, Was, Warum, Wozu und Wann.

• Wer stellt die Anforderung? Nur so kann sichergestellt werden, dass zu jeder Zeit eine konkrete Ansprechperson auf Kundenseite vorhanden ist.
• Was ist der Grund/Auslöser der Anforderung? Daraus ergibt sich eine möglichst detaillierte Beschreibung der Ausgangssituation und der Ursache des Problems.
• Was ist das Ziel/Welches konkrete Problem soll gelöst werden?
• Warum wird die Anforderung benötigt?
• Gibt es eine gesetzliche Grundlage für die Anforderung?
• Entspricht die Anforderung gesetzlichen Grundlagen?
• Welcher zeitliche Rahmen wird erwartet (Fertigstellung, Inbetriebnahme), wann soll die Anforderung umgesetzt werden?

Es ist wichtig, dass die Anforderung möglichst detailliert und vollständig erfasst wird, um eine schnelle und fundierte Entscheidungsfindung in den folgenden Prozessschritten zu ermöglichen. Die Beschreibung der Anforderung darf jedoch keine konkrete Lösung enthalten.

Bei Bedarf wird ein Requirements Engineer hinzugezogen. Dieser kann den Anforderungserheber bei der Präzisierung und Ausarbeitung der Anforderung unterstützen, indem er gezielte Rückfragen stellt und Feedback gibt.

Die erhobenen Anforderungen werden anschließend vom Requirements Controller geprüft. Dieser stellt sicher, dass die Anforderungen die formalen Kriterien erfüllen und inhaltlich kohärent und verständlich formuliert sind.

Die Entscheidung über die Verfügbarkeit eines Requirements Engineers trifft der IT-Abteilungsleiter.
Stehen keine Ressourcen für das Requirements Engineering zur Verfügung, wird der Kundenwunsch in einer Evidenzliste dokumentiert und der Kunde darüber informiert. Der Kunde ist in diesem Fall dafür verantwortlich, die IT zu informieren, falls das Thema nicht mehr relevant ist.
 

2.2. Solution Engineering (SE)

Im SE wird die Frage beantwortet: WIE sieht die Lösung aus? (Weg). Ausgehend von der im RE erarbeiteten Anforderung werden konkrete Lösungsansätze entwickelt und bewertet.

Der Solution Engineer analysiert in einer Schnellschätzung verschiedene Lösungswege und bewertet diese anhand folgender Kriterien:

• Benötigte Infrastruktur
• Entwicklungsaufwand
• Impact auf Enduser
• Impact auf Services, Abläufe und Prozesse
• Aufwand auf Seiten der Kunden
• Einbindung Externer (Drittanbieter, externes Projektmanagement)
• Verfügbarkeit von Ressourcen in der IT
• Kosten-Nutzen-Verhältnis

Der Solution Controller evaluiert die vom Solution Engineer ausgearbeiteten Lösungsansätze und steht ihm beratend zur Seite. Der Solution Controller ist in der Regel der Fachvorgesetzte des Solution Engineers.

Die möglichen Lösungsansätze werden mit dem Kunden besprochen, um gemeinsam den vielversprechendsten Ansatz auszuwählen. Der Kunde entscheidet auf Basis der vorgestellten Lösungsansätze, welcher Ansatz für ihn am besten geeignet ist.

Der Kunde erteilt der IT eine explizite Beauftragung zur Umsetzung des gewählten Lösungsansatzes. Bei großen und sehr großen Projekten kann die Entscheidung über die Beauftragung an ein Gremium delegiert werden, das auch für die Priorisierung verantwortlich ist.
 

2.3. Projektphase

Die Projektphase ist die letzte Phase im Projektmanagementprozess der mdw und beginnt nach der Beauftragung durch den Kunden im Solution Engineering. In dieser Phase wird eine detaillierte Spezifikation der zuvor definierten Lösung ausgearbeitet, konkret umgesetzt und in den laufenden Betrieb überführt. Die zentrale Frage in der Projektphase lautet: "WAS ist von WEM notwendig, um dem Weg zum Ziel folgen zu können?

Zunächst prüfen die IT-Abteilungsleiter, ob ausreichend Ressourcen zur Verfügung stehen. Sind die Ressourcen vorhanden, startet das Projekt und die Projektrollen werden definiert.

Sobald die Ressourcen freigegeben wurden, wird das Projekt offiziell gestartet. Der Projektleiter wird benannt und übernimmt die Verantwortung für die Planung, Steuerung und Überwachung des Projekts.

Der Projektleiter ist dafür verantwortlich, dass eine detaillierte Spezifikation gemeinsam mit der IT und dem Kunden (und falls notwendig auch Mitgliedern des Projektteams) erstellt wird.

Weiters ist er für die Planung des Projekts zuständig und behält den Überblick über die laufende Umsetzung. Er ist verantwortlich für die Erreichung der Projektziele. Dementsprechend hat er Verzögerungen oder Probleme rechtzeitig dem Kunden zu kommunizieren bzw. bei der Planung der Meilensteine Offene Fragen mit dem Kunden zu klären.

Die Organisation von (laufenden) Projektmeetings obliegt ebenfalls dem Projektleiter.

Der Projektleiter hat keinen direkten Zugriff auf die Ressourcen der IT-Abteilung. Werden über die geplanten Aufwände (pro Meilenstein/Task) hinaus Ressourcen benötigt, ist dies mit den IT-Abteilungsleitern zu besprechen, die die Ressourcen freigeben können.

Projektleiter ist für die Protokollierung von getroffenen Enscheidungen im Rahmen von Meetings oder dirkten Absprachen mit dem Kunden verantwortlich. Letztere sind dem Projektteam zu kommunizieren.

Zu Beginn des Projekts werden grob die Phasen und Meilensteine definiert.
Die Abwicklung selbst erfolgt iterativ, wobei jede Iteration die folgenden Schritte beinhaltet:

• Definition von Tasks: Zu Beginn jeder Iteration werden die Aufgaben (Tasks) definiert, die zur Erreichung des nächsten Meilensteins notwendig sind.
• Umsetzung der Tasks: Die Teammitglieder bearbeiten die definierten Tasks und dokumentieren ihren Fortschritt.
• Abnahme der Tasks: Am Ende jeder Iteration werden die erledigten Tasks abgenommen und auf ihre Konformität mit den Anforderungen geprüft.

Bereits während der Implementierungsphase wird an der Dokumentation gearbeitet. Am Ende des Projekts muss sichergestellt sein, dass zumindest eine IT-Dokumentation existiert.

Nach Abschluss aller Iterationen und der finalen Abnahme des Projekts erfolgt die Inbetriebnahme der Lösung. Die Projektphase endet mit einer Feedback-Rückschau, in der alle Projektbeteiligten ihre Erfahrungen und Erkenntnisse teilen. Die Ergebnisse der Feedback-Rückschau dienen der kontinuierlichen Verbesserung des Projektmanagementprozesses.

Eine detaillierte Spezifikation des Betriebs im Hinblick auf den Lebenszyklus von Software ist noch zu erarbeiten.
 

Toolunterstützung

• Zammad: Dient als Ticketsystem zur Erfassung, Priorisierung und Zuweisung von Kundenwünschen und Problemen.

• OpenProject: OpenProject wird nach der positiven Ressourcenprüfung zur detaillierten Planung, Organisation und Dokumentation des Projekts verwendet. Das Tool unterstützt die Definition von Aufgaben, Meilensteinen, Abhängigkeiten und Ressourcen in der Umsetzung.

• GitLab wird primär in Softwareentwicklungsprojekten zur Versionierung des Codes und zur Erfassung und Verfolgung von Fehlern und Änderungswünschen (Issues) eingesetzt. In GitLab wird auch die IT-Dokumentation abgelegt.

Das vorgestellte Konzept zielt darauf ab, Kundenwünsche strukturiert und effizient zu bearbeiten. Durch die klare Definition von Phasen, Rollen und Verantwortlichkeiten sowie den Einsatz von geeigneten Tools soll sichergestellt werden, dass Projekte erfolgreich geplant, umgesetzt und dokumentiert werden und in einen geregelten laufenden Betrieb übergehen.