Zusammenfassung: Der Blogbeitrag bietet eine prägnante Zusammenfassung der wichtigsten Projektmanagement-Prozesse für Scope-, Problem-/Risiko- und Decision-Management in SAP-Projekten und gibt hilfreiche Tipps, wie man das Entscheidungsmanagement pragmatisch umsetzen kann.
Scope-Change-Management / Decision Making Process
Zunächst eine begriffliche Klärung: Unter Change-Management werden häufig zwei unterschiedliche Sachen verstanden. Zum einen das Change-Management, um Änderungen in die Organisation zu bringen. Diese bezeichne ich als OCM (Organizational Change Management. Worum es dabei geht, kann der entsprechenden Beschreibung im BLOG Beitrag 12 entnommen werden). Zum anderen geht es das Scope-Change-Management, bei dem es um das Management der Anpassungen des definierten Projekt-Scope geht. Ich spreche hier von letzterem und würde dies noch erweitern um das Management der Anpassungen im ausgelieferten S/4HANA System, also namentlich den WRICEF und den von den vereinbarten Projektvorgaben abweichenden Konfigurationen. Wenn es z.B. nicht erlaubt ist, eine neue Materialart einzurichten, muss eine entsprechende Anforderung diesen Prozess durchlaufen.
Zielsetzung dieses Prozesses ist es, Entscheidungen bewusst und vor dem Hintergrund der Evaluation aller möglichen Alternativen und insbesondere auch der Wirtschaftlichkeit zu treffen.
Wie ist ein Change Request definiert?
In der Regel wird jeder beantragte Change in einem eigenen Change Request (CR) behandelt. In diesem sollten folgende Dinge klar definiert sein:
- Wer ist Eigentümer des CR und wer sind die Stakeholder?
- Weshalb ist der CR notwendig (mögliche Kategorien wären: Legale Anforderung, Konzernanforderung, Wirtschaftlichkeit oder Komfort)? Dabei sind legale oder Konzernanforderungen i.d.R. umzusetzen und bedürfen keiner weiteren Diskussion.
- Was sind die Alternativen (z.B. organisatorisch oder Nutzung eines anderen SAP Prozesses im Standard)? Diese und die CR Anforderung sollten jeweils im Rahmen einer SWOT Analyse gegenübergestellt werden. Auch sollten Kosten und Nutzen der einzelnen Alternativen QUANTIFIZIERT (das geht immer!) zur Verfügung stehen.
Ein solcher CR sollte einen definierten und dokumentierten Evaluations- und Freigabeprozess durchlaufen, der in der Regel zur finalen Entscheidung im Lenkungsausschuss endet. Dies kann z.B. im Solution-Manager der SAP passieren oder auch einfach in einer Excel-Tabelle vom PMO verwaltet werden. Darüber hinaus sollte dieser Prozess weitgehend analog auch zur dokumentierten Entscheidungsfindung in wichtigen Fragen im Projekt angewendet werden. Hier sollte er um die dokumentierte Aufnahme der Anforderungen aller Beteiligter erweitert werden (siehe beispielhafte Entscheidungspapiervorlage Decision_Paper DE.PDF). Unsere MS Word-Vorlage des „Decision Paper“ für die dokumentierte Aufnahme aller Anforderungen im Entscheidungsprozess können Sie über diesen Link im Digistore24 erwerben und herunterladen.
Risikomanagement
Definition und Abgrenzung: Ein Problem oder Issue ist ein Umstand, der aktuell das Team oder Teile des Teams davon abhält, wie geplant zu arbeiten. Ein Risiko ist ein Umstand der dazu führen kann, in der Zukunft ein Problem oder Issue zu haben. Dies gilt es abzuwenden. Während für Probleme (oder Issues) Aktionen defininert werden müssen, um diese schnellstmöglich zu beseitigen, damit wieder wie geplant gearbeitet werden kann, geht es bei Risiken darum, Maßnahmen zu ergreifen, um das künftige Problem (oder die Issue) abzuwenden oder dessen Eintrittswahrscheinlichkeit zu reduzieren, sogenannte Mitigation Actions.
Sehen Sie unseren Erklärfilm zum Thema „Risk Management“ hier auf YouTube!
Gehen Sie offensiv mit dem Risikomanagement um, machen Sie eine initiale Risikoanalyse (s. Vorlage Risk_Analysis_DE.PDF). Lassen Sie sich die erkennbaren Risiken von den Teams regelmässig im Rahmen des Status reporten und loggen und bewerten Sie diese in einem Risiko-Log (s. beispielhafte Risk_Log_Sample.pdf) und definieren und monitoren Sie die Mitigation Actions. Machen Sie das Reporting der wichtigsten Projektrisiken auch zu einem festen Bestandteil des Berichts an den Lenkungsausschuss. Die 16-seitige Risikoanalyse können Sie über diesen Link als Word-Vorlage im Digistore24 erwerben und herunterladen, Risk Log zum Reporting von Risiken in MS Excel finden Sie hier.
oder schematisch dargestellt:
Risiken können vielerlei Ursachen haben, der grösste Fehler wäre, die Augen davor zu verschliessen:
Issue- und Decision-Management
Problem- oder Issue-Management zu betreiben, ist meiner Erfahrung nach Zeitverschwendung. Probleme müssen gelöst werden, und dafür müssen Aktionen definiert und deren Erledigung nachgehalten werden. Zum Decision Making Prozess habe ich mich weiter oben schon geäußert. Hier soll es darum gehen, Entscheidungen, die im Projekt getroffen wurden, an alle Stakeholder des Projektes zu kommunizieren und diese dann zu schließen, damit sie in der Zukunft nicht wieder aufgemacht werden.
Folgende Komponenten & Verfahren setze ich dazu schon seit vielen Jahren erfolgreich in Projekten ein:
- Es wird EIN zentrales Meetingprotokoll für alle im Rahmen des Projektes stattfindenen Meetings geführt
- In dem Meetingprotokoll gibt es folgende Kategorien für Einträge
– P: Teilnehmer (hier werden alle Teilnehmer des Meetings eingetragen)
– A: Agenda (hier wird die Meeting Agenda festgehalten)
– D: für Entscheidungen (hier werden alle getroffenen Entscheidungen festgehalten)
– T: Task: hier werden alle vereinbarten Aufgaben mit Angabe GENAU EINES Verantwortlichen, dem Zieldatum und dem Status (open, wip, closed) festgehalten
– I: für wichtige Informationen, die geteilt werden und dokumentiert sein sollten - Für die gleichen Meetings wird immer derselbe Meetingname verwendet
Eine beispielhafte Vorgabe findet sich hier (Meeting_Minutes.PDF). Die Meeting Minutes – das zentrale Meetingprotokoll in MS Excel – können Sie über diesen Link im Digistore24 erwerben und herunterladen.
Dieses Vorgehen ermöglicht:
- Dass in einem Folgemeeting sehr einfach die offenen Tasks und Entscheidungen der vorherigen Meetings gefiltert werden können, anstatt wie sonst in diversen Word Protokollen zu suchen.
- Es dem PMO, offene und überfällige Tasks regelmäßig nachzuhalten.
- Dass jeder im Team seine Tasks einfach finden und regelmässig abarbeiten kann.
- Und nicht zuletzt, dass die Entscheidungen periodisch in ein Decision Log übernommen werden, an alle Stakeholder des Projektes unter Nennung einer Einspruchsfrist zur Kenntnisnahme und dem Stellen möglicher Rückfragen zur Klärung verteilt und nach Ablauf dieser Frist im Decision Log gelockt (geschlossen) werden können. Ein Beispiel für ein Decision Log findet sich hier als PDF. Das Decision Log können Sie über diesen Link als MS Excel-Vorlage im Digistore24 erwerben und herunterladen.
Hier beispielhaft die Regelungen zum vierten Aspekt:
- Entscheidungen aus Team-Meetings, SteCo, Manager Board oder Projektmanagement werden in einer zentralen Datei gesammelt (Decision Log).
- Die Entscheidungen werden ins Englische und Deutsche übersetzt.
- Die Projektleitung prüft die Entscheidungen auf Plausibilität.
- Einmal im Monat werden die neuen Entscheidungen an alle Beteiligten verteilt.
- Die Beteiligten haben ein Überprüfungsfenster von vier Wochen, um Feedback zu den Entscheidungen zu geben.
- Nach den vier Wochen werden die Entscheidungen gesperrt und veröffentlicht.
Dieser vierte Aspekt ist meiner Ansicht nach besonders wichtig, da dieses Vorgehen zum einen dem Vorwurf vorbeugen kann, dass Entscheidungen im „stillen Kämmerchen“ gefällt werden. Und zum anderen, damit meiner Erfahrung nach effektiv dem „Wiederaufmachen“ bereits entschiedener Punkte vorgebeugt werden kann. Letzteres ist ja in vielen Unternehmen eines der größten Probleme.
Unser Erklärvideo zu Meeting Minutes und Decision Log finden Sie hier auf Youtube.
Und hier finden Sie eine Übersicht unserer Tools, die Sie im Digistore24 erwerben, herunterladen und für Ihr Projekt nutzen können.