Meine Projektmanagement Methodik

"... über 50 % der IT-Projekte scheitern ..." stellt die Computerwoche fest.

Ein Projekt ist z.B. auch dann gescheitert wenn das doppelte des ursprünglich geplante Budget verbraucht wurde. Schließlich hätte man das Projekt dann zweimal machen können.

=> Das muss nicht sein, wie meine Projekte beweisen!

Mein Erfolg als Projekt-Manager beruht auf folgenden Elementen:

• solide handwerkliche Basis und jahrelange Erfahrung

• gemeinsame Festlegung der Ziele (Leistungen, Termine, Kosten)

• Alle westlichen Beteiligten (Meinungsführer, Manager, gut vernetzte Mitarbeiter, etc.) müssen den user stories (Detaillierte Ziele aus der Sicht des Mitarbeiters) zustimmen bzw. diese bei Fehlern korrigieren.

• gewissenhafte Risiko-Analyse, ergänzt durch Proof of Concepts (=Praktische Machbarkeitsstudien)

• saubere Planung der Aufgaben und Ressourcen

• permanente Überwachung des laufenden Projekts

• rechtzeitige Gegensteuerung des Projekts bei Abweichungen von der Planung

​

Wichtige Bestandteile meiner Projekte:

 

​Methodik

Ich nutze sowohl Elemente aus dem klassischen Projektmanagement mit einem Ablaufplan als auch Elemente aus Scrum. Vom klassischen Projektmanagement nehme ich die Projektplanung mit festen messbaren Meilensteinen. Von Scrum nehme ich die Art wie die Requirements aufgenommen und final abgenommen werden als auch die Idee sich dem Ziel mit neuen vorzeigbaren Prototypen nach jedem Entwicklungssprint zu nähern.

 

​Festlegen der Vision

Zu Beginn eines Projekts wird mit dem Auftraggeber die Vision des Projekts festgelegt. Die Vision auch eine user story und in der Regel nicht mehr als eine Satz. z. B. könnte eine Vision lauten:

"Als Bereichsleiter möchte ich das ein Configuration Management nach ITIL eingeführt wird um zukünftig die Abhängigkeiten eines IT-Service schnell identifizieren zu können."

 

​Organisation

Definieren von Organisationskreisen wie

• Stakeholder (Jemand der an dem Projekt irgendwie interessiert ist aber keine wesentliche Rolle spielt

• Projektmanager

• Teilprojektmanager

• Prozess Owner (Jemand der für einen Prozess und dessen Gestaltung Verantwortlich ist)

• ext Zulieferer

• Auftraggeber

​​

​Workshop mit Projektbeteiligten

Nachdem die Vision festgelegt wurde. Werden mit den beteiligten Stakeholdern (Interessensgruppen) Workshops abgehalten. Nach jedem Workshop wird ein Protokoll erstellt in dem Termin, Beteiligte, Feststellungen, Definitionen, Schnittstellen und offene Fragen festgehalten und an die Beteiligten versendet wird.

​

Requirements engineering mit user stories nach Scrum

Aus den Protokollen der Workshops mit den Stakeholdern werden einzelne user stories erstellt. Größerere Themenblöcke werden in mehrere user stories die voneinander abhängen geschrieben.  In den user stories wird die fachliche Anforderung schriftlich erfasst. Die user stories haben folgendes Schema:

• user story - Wer? Willwas? Warum?

• IST-Zustand - Wie wird aktuell mit dem Thema umgegangen.

• SOLL-Zustand - Was soll zukünftig möglich sein.

• Akzeptanzkriterien - Welche Funktionen sollen zukünftig möglich sein. Die einzelnen Funktionen sollten so weit wie Möglich der S.M.A.R.T. Methodik folgen.

 

Ablageort für user stories definieren

Die user stories sollte man nach Möglichkeit in einem für die Scrum Methodik geeignetes Tool erfassen. Typische Tools sind Jira von Atlassian oder Gemini von Countersoft. Die Tools bieten gegenüber einer Erfassung in einem Dokument folgende Vorteile:

• Die Stakeholder (Interessensgruppen) bekommen Zugriff auf die user stories um diese im Anschluss kommentieren bzw. abnehmen (genehmigen) zu können.

• Alle Änderungen werden automatisch mit Datum, Änderung und Bearbeiter gespeichert um Änderungen im Nachhinein nachvollziehen zu können.

• Die user stories werden an einem für interne wie externe Stakeholder zugänglichen Ort gespeichert. Dadurch ist sichergestellt das jeder den aktuellsten Stand prüfen kann.

• Jeder Stakeholder bekommt automatisch eine Nachricht mit der Änderung sobald sich etwas an einer user story ändert.

• Kommentare zu den user stories können beim Schreiben nur für bestimmte Personengruppen sichtbar gemacht werden um interne von externen Kommentaren zu trennen.

• user stories können bei Bedarf während der Bearbeitung gesperrt werden um keine Wiedersprüche bei verschiedenen user stories Bearbeitungsstände entstehen zu lassen.

 

Die user stories für ein Projekt werden in einem Projekt zusammengefasst. User stories können hierarchisch oder partiell gegliedert werden. Falls eine hierarchische Gliederung gewünscht ist sollte man keinesfalls mehr als zwei Ebenen verwenden da sonst die Übersicht kaum noch möglich ist. Besser ist die Themenblöcke partiell zu gliedern.

Beispiel einer partiellen Gliederung:

• IncidentMgmt - Emailimport

• IncidentMgmt - Emailversand

• IncidentMgmt - Pools

• IncidentMgmt - Userverwaltung

• ProblemMgmt - Verknüpfungen mit Incidents

• ProblemMgmt - Verknüpfungen mit Known Errors

​

user story

Beispiel: "Als Leiter der Marketingabteilung ("Peter Rocket") möchte ich das ein Kundenumsatz-Reporting auf Monatsbasis per Webinterface abrufbar sein soll um jederzeit einen Überblick über den Verlauf des Kundenumsatzes abrufen zu können."

Erklärung: Hier wird aus der Person die den Wunsch hat geschrieben was benötigt wird und warum.

​

IST-Zustand

Beispiel: "Aktuell gib es einen Report für die Kudenumsatzzahlen der in einer Software erstellt wird die nicht mehr weiterentwickelt wird."

Erklärung: Hier wird der aktuelle Zustand in einem Satz zusammengefasst. Wenn nötig können hier auch bis zu drei Sätze stehen.

z.B. "Aktuell wird das Incident Management mit Emails durchgeführt."

 

SOLL-Zustand

Beispiel: "Zukünftig soll das Incident Management mit einem ITIL-konformen Standardtool durchgeführt werden."

Erklärung: Hier wird der zukünftige Zustand in einem Satz zusammengefasst. Wenn nötig können hier auch bis zu drei Sätze stehen.

​

Akzeptanzkriterien

Beispiel: "Die Emails aus dem Emaileingangspostfach des Incident Managements soll alle 2 Minuten in das ITSM-Tool importiert und bei vorhandener TicketID automatisch zugeordnet werden."

Erklärung: Bei den Akzeptanzkriterien werden die einzelnen Funktionen aufgelistet die nach der Umsetzung der user story funktionieren sollen. Hier hilft die S.M.A.R.T.-Methodik.

​

Abgrenzung

Beispiel: "Spammails im Emaileingangspostfach des Incident Managements werden nicht automatisch aussortiert."

Erklärung: Bei der Abgrenzung werden die einzelnen Funktionen aufgelistet die nach der Umsetzung NICHT funktionieren werden. Die Abgrenzung ist unbedingt nötig da es häufig zu Missverständnissen kommt was die Mächtigkeit / Funktionsumfang von user stories betrifft.

 

Offene Fragen

Beispiel: "Welche Personen soll Zugriff auf die User Rechte Pflege für das Incident-Management erhalten? (Steering-Committee)"

Erklärung: Beim schreiben der user stories fallen typischerweise offene Fragen an die man im Workshop nicht angesprochen hat oder die dort nicht beantwortet werden konnten. Damit diese offenen Fragen zu einer user story nicht in Vergessenheit geraten schreibt man die offenen Fragen an das Ende einer user story gefolgt von einer Person bzw Gruppe die vermutlich eine Antwort geben kann.

 

Einteilung in Phasen

Nachdem oder während die user stories erfasst sind werden die user stories in Phasen eingeteilt. Typischerweise werden beim Requirements-Engeneering (Erfassung der Anforderungen der Stakeholder) viele Funktionen gewünscht die im ersten Schritt nicht unbedingt erforderlich sind. Diese nennt man Umgangssprachlich auch gerne "Nice to Haves". Bzw. es werden Funktionen gewünscht die im ersten Schritt mit dem Budget / Resourcen, Skope und der Zeit nicht umsetzbar sind. Diese user stories werden mit "Phase2" im Titel markiert. Alle user stories die im aktuellen Projekt mit dem aktuellen Budget / Ressourcen, Scope und Zeit umgesetzt werden sollen bekommen im Titel der user story die Erweiterung "Phase1".

 

Projektplan

Der Projektplan erfolgt nach einigen Versuchen mit verschiedenen Versuchen mit Projektmanagement-Standardsoftware inzwischen ausschließlich mit Excel-Dokumenten die in der Cloud (z.B. Firmenfileshare oder Microsoft-OneDrive) verfügbar gemacht werden. Falls das gewünscht ist wird eine Firmeninterne Projektmanagement Software in regelmäßigen Zyklen an das Excel-Dokument angeglichen.

​

Regelmäßige Meetings

Kommunikation ist alles - wer diesen Satz schon einmal in einer Softskill Schulung zu hören bekommen hat wird nach spätestens dem ersten Projekt dem zustimmen. Wichtig ist das man sich immer und immer wieder zusammensetzt um sich gegenseitig Abzustimmen. Dabei ist es extrem wichtig das die Beteiligten vom Management die klare Anweisung bekommen Ihr Tagesgeschäft hinter die Abstimmung zu stellen.

​

Umsetzung nach Scrum

Für die Umsetzung nach Scrum in sogenannte Sprints muss es ein festes Entwicklerteam geben. Andernfalls kann man zwar das Requirements Engineering nach Scrum machen aber die Entwicklung nach dem klassischen V-Modell, Wasserfall-Modell oder Iterativen-Modell.

​

Lessons Learned

Nach dem Abschluss des Projekts kommt eine Retrospektive. Das alle Projektbeteiligten zeichnen einen Chart auf wie Sie die Qualität des Projekts im Zeitlichen Verlauf (X-Achse ist Zeit, Y-Achse ist Qualität) wahrgenommen haben, sowie einige positive und negative Stichpunkte für das Projekt. Es kann Sinn machen hierfür das Unternehmensmanagement aktiv auszuschließen um eine offenere und ehrlichere Diskussion zu ermöglichen.​