Das Vorgehen entscheidet.

Vorgehensmodell_Pionier

WFM-Projekte sind nach wie vor Projekte mit Pioniercharakter. Als Kunde eines Systemlieferanten werden Sie relativ schnell die Erfahrung machen, dass Sie für manche Funktionen der einzige Anwender sind, der diese Funktionen benutzt oder fordert. Die Systeme sind weit davon entfernt, mit einem Knopf installiert zu werden. Projektlaufzeiten von vielen Wochen und Monaten, sogar Jahren, sind keine Seltenheit. Die Softwarequalität der Hersteller lässt oft zu wünschen übrig. Man fühlt sich als Kunde von WFM-Systemen häufig alleingelassen, obwohl sich die Hersteller allergrößte Mühe geben, um den Anforderungen gerecht zu werden. Die Produktpräsentationen der Software versprechen viel – die Realität sieht leider oft anders aus.

Wie kann man trotzdem erfolgreiche WFM-Projekte durchführen? Wie kann man als Projektleiter einer solchen Situation begegnen?

Es gilt mal wieder der Spruch des berühmten Wissenschaftlers Darwin: „Nichts in der Geschichte des Lebens ist beständiger als der Wandel.“ – oder ganz nach dem griechischen Philosophen Heraklit: „Panta Rhei! –  Alles fließt!“ Das Projektmanagement und das Projektvorgehensmodell muss so gestaltet sein, dass man die Schwierigkeiten und die Änderungen im Projekt von Anfang an mit in das Projekt einplant. Ein Vorgehensmodell, das von einer stabilen Planung von Anfang bis zum Ende ausgeht, ist für WFM-Projekte nicht geeignet. Dazu sind diese Projekt doch zu sehr von Innovationen und Pioniercharakter geprägt.

Veränderung einplanen!

Leben Sie in den Projekten die Veränderung! Die gute Vorbereitung muss den Faktor Veränderung als Leitmotiv beinhalten. Wahrheiten von heute sind die Geschichte von Morgen. Das ist die Realität und muss von Projektleitern in WFM-Projekten berücksichtigt werden. Daher ist ein Vorgehensmodell zu empfehlen, das die Vorteile eines konservativen „Wasserfallmodells“ mit den Vorteilen einer agilen Vorgehensweise kombiniert. Eine Spezifikation sollte so schlank wie möglich aber auch nicht schlanker gehalten werden. Die Anforderungen sollten so einfach wie möglich aber auch nicht einfacher spezifiziert sein. Die Stabilität im Projekt sollte so stabil und stetig wie möglich, aber auch nicht stabiler sein.

Ich empfehle einen Mix aus klassischer und agiler Vorgehensweise in bestimmten Phasen:

1. Projektinitierung

Klassische Vorgehensweise: Gute Definition der Projektziele (Balanced Scorecard: Finanzziele, Qualitätsziele, Prozessziele…) mit Messkriterien, Formulierung der Kernanforderungen, Definition der Verantwortlichkeiten, Zusammensetzung eines Lenkungsausschusses

2. Grobplanung

Klassische Vorgehensweise: Bildung des Kernteams, Erstellen eines groben Lastenhefts, Prozessanalyse- und Dokumentation, Priorisierung der Anforderungen, Grobkonzeption und IT-Integrationskonzept, Einbindung aller Abteilungen inkl. Betriebsrat in das Vorhaben.

3. Lieferantenauswahl/Ausschreibung

Klassische Vorgehensweise: Bewertung der Hersteller anhand Matrix/Abdeckung, Bewertung der Hersteller bezüglich der Prozesskompatibilität und Qualitätsmanagement.

4. Feinplanung

Agile Vorgehensweise: Definition der Einführungsstufe 1..N, Erstellung von schlanken Stufenkonzepten zusammen mit dem Hersteller, Definition der Qualitätskriterien, Aufstellen eines Testplans und des Testteams, Definition der Schulungsmaßnahmen.

5. Umsetzung/Rollout Stufe 1..N

Agile Vorgehensweise: Einführung von Stufe N anhand Einführungplan, Korrektur von Problemen in vorhergehenden Stufen, Einbezug der Mitarbeiter

6. Qualitätssicherung Stufe 1..N

Agile Vorgehensweise: Qualitätssicherung anhand Testplan, Schulung der Mitarbeiter

7. Rollout Stufe 1..N

Agile Vorgehensweise: Bereitstellung IT-Systeme, Vorbereitung zur Umstellung der Prozesse, Bereitstellung der Stammdaten

8 .Review Agile Stufe 1..N

Agile Vorgehensweise: Definition von Verbesserungspotentialen, Korrektur der vorherigen Stufen

9. Nächste Iteration -weiter mit 4.

Kommentare sind geschlossen.