Es wurde bereits xig Artikel, Bücher und Publikationen dazu veröffentlicht. Warum jetzt dieser Blog zu diesem Thema?

Meine zentrale Frage: Was ist der Unterschied zwischen einem erfolgreichen Projekt und einem missglückten Projekt? Hierzu möchte ich meine Erfahrungen aus vielen Jahren Projektmanagement weitergeben. Wer weiss, vielleicht findet der eine oder andere einen Hinweis oder Anregung darin – und nicht zuletzt kann ja auch nachgefragt werden.

Projektstart, Projekt Initiation und Voranalyse

Wie wir alle wissen sind es die bekannten Kriterien wie u.a. klare, messbare Ziele, Einbezug der Projekt Stakeholder – und diese in die Verantwortung nehmen. Die Projektorganisation ist in diesem Beispiel schlank gehalten, d.h. meine Frau, meine Kinder und ich selbst. Auch müssen die Anforderungen klar und messbar sein, so z. B. anhand meines Beispiels „Auto Evaluation“: Während ich mir Gedanken zu den technischen Daten (Diesel / Benziner oder gar Hybrid, PS, Navi und tiefe Betriebskosten) mache, sind für meine Frau ganz andere Dinge wichtig. So etwa der „Rund-um-Blick“ vom Fahrersitz aus oder genug Stauraum für Gepäck, nicht zuletzt das Aussehen des Autos und dessen Farbe. Ebenso bei den Kindern – je nach Alter – sind bereits vorhandene USB–Anschlüsse zwingende Voraussetzung oder sogar ein Bildschirm auf der Rückseite der vorderen Sitze ist für strapazierte Nerven teilweise Gold wert (Video schauen). Übersetzt heisst das, die unterschiedlichen Anforderungsgruppen zu definieren und zu kennen. Alle reden auch von Systemgrenzen, also was gehört in ein Projekt rein, was nicht. Nun, glücklicherweise habe ich die Garagenmasse mitgenommen, so konnten allzu „hohe“ und „breite“ Vehikel bereits von Anfang an ausgeschlossen werden.

Zugegeben, einen unterschriebenen Projektantrag mit definierten Zielen hatten wir nicht für so ein Kleinprojekt, jedoch ist für mich zwingende Voraussetzung im „daily business“. Wir hatten uns ca. 3 Monate Durchlaufzeit vorgenommen für den Autowechsel, d.h. die Projektzeitdauer.

Konzept, Proof of Concept

Von Beginn an war für uns klar, dass wir keinen Neuwagen wollten, ebenso hatten wir uns eine klare Budget-Obergrenze gesetzt – Projekt-Scoping war angesagt. Mit diesen messbaren Vorgaben und Zielen ging es nun auf die Suche auf dem Markt. Glücklicherweise gibt es heute Suchmaschinen, welche einem die Arbeit erleichtern. In einem realen IT Projekt hisse dies: Lieferantenauswahl – basierend auf einem vorgängig abgegebenen Pflichtenheft. RFI und RFQ sind die Stichworte ebenso wie Lieferanten – „Long List“ – „Short List“. Zurück zu unserer Autoauswahl folgt nun ein spannender Teil des Projektes. Verschiedene Produktvarianten gibt es zu untersuchen: Bei einem IT Projekt gilt es nun mit allen Projektvertretern die Produktehersteller und ihre Lösungen zu präsentieren, sei es der Aufbau, Integration in die IT oder Betrieb selbst.

Proof of Concept: Nun, zurück bei meiner Autoevaluation war es mir wichtig, dass meine Frau mit dabei war und die verschiedenen Fahrzeuge nicht nur äusserlich begutachtete, sondern auch selbst ein paar Kilometer fuhr. Zugegeben, was der Seite gefiel, fiel bei mir technisch durch. Oft macht es Sinn, während des Projekts ein Proof of Concept einzubauen. Ich kann diese risikomindernden Massnahmen nur wärmstens empfehlen. Dadurch stellt der Lieferant oder das Projektteam einerseits seine Fähigkeiten unter Beweis, anderseits können Projektanforderungen oder ein bestimmtes Lösungsdesign in einer frühen Phase validiert werden.

Auch haben wir uns die Testberichte namhafter Autozeitschriften angeguckt. Was heisst dies wiederum in einem Projekt? Viele Projekte / Ausschreibungen verlangen seitens Lieferanten Referenzen. Dies geht so weit, dass ausgesuchte Projekt Mitglieder Referenzkunden besuchen und vor Ort sich dieses Produkt zeigen lassen in der Produktion. Fragen zum Produkt-Einsatz, Zufriedenheit und Betrieb sowie zum Lieferanten werden erfragt.

Ebenso Projekt-intern müssen die Voraussetzungen geschaffen werden, d.h. die dem Projekt zur Verfügung gestellten Personen müssen klare Aufträge, abgeleitet aus den Zielen, erhalten. Diese Aufträge müssen jedoch überwacht und ggf. bei Termin- oder Qualitätsverzug umgehend korrigiert werden. Klingt eigentlich alles logisch – nicht „rocket Science“. Aber gerade diese Steuerungsaufgaben werden oft vernachlässigt, das Projekt läuft dadurch in die falsche Richtung, was dann oft erst spät erkannt wird und aufwändig zu korrigieren ist. Was ist mit dem „Xunder Menschenverstand“ (XMV) Prinzip? Auch dieses hilft hier in vielen Fällen weiter, den „gesunder Menschenverstand“ leben wir – sei es im privaten Bereich oder im Geschäft. Eine gewisse Methodik (Hermes lässt grüssen) hat mir meistens geholfen eine kritische Startphase zu meistern. Sei es bei der „Auto Evaluation“ oder bei einem (für meine Verhältnisse) grossen Projekt „Hausbau“.

Realisierung

Heutzutage wird ein grosses Augenmerk auf die Agilität in einem Projekt gelegt. Dies durch den Umstand, dass ein Projekt nicht von Anfang an zu 100% planbar ist und Entwicklungsprozesse oft nur schwer vorhersehbar sind. Im Beispiel der Autoevaluation kann dies bedeuten, dass während der Autoevaluation erkennen, dass wir eigentlich etwas ganz anderes wollen. Kann der gewünscht Service nicht auch via ÖV erbracht werden? Oder soll ich mir meine 3 Favoriten jeweils während 2 Wochen mieten? Dies darf nicht ignoriert werden, sonst ist am Schluss des Projekts der Mehrwert nicht gegeben. Der wahre Challenge bei agilen Projekten ist, dass das agile Vorgehen oft nicht zur aktuellen Unternehmenskultur passt. Hier müssen erst die notwendigen Voraussetzungen geschaffen werden. Während in der Informatik dieser Teil einer Phase jeweils länger dauert, ist es bei der Autoevaluation recht einfach. Unser Modellauto ist nun definiert und es gilt den Markt für Vorführwagen und Occasionen zu testen und schlussendlich auszuwählen.

Einführung

Die letzten Vertragsverhandlungen stehen mit der Garage noch an, Zahlungsmodalitäten und die Fragen nach dem noch notwendigen Zubehör. Der Übergabetag wird festegelegt sowie die Bezahlung und dann warten wir auf diesen Tag. In der Informatik bedeutetet diese Phase sehr viel Aufwand, muss doch alles getestet und in Ordnung gebracht werden. Nicht zuletzt das beliebte Thema „Dokumentation“ sollte ebenfalls auf Vordermann gebracht werden. Mit dem Produktivtermin werden auf die Benutzervertreter geschult und auf das neuen System eingefuchst – mit dem „teach the teacher“ Prinzip habe ich sehr gute Erfahrungen gemacht.

Erfolgsfaktoren

Hier einige weitere Erfolgsfaktoren, welche aus meiner Erfahrung wichtig sind:

• Risk tracken und stetig managen, Massnahmen auf die Wirkungen überprüfen.
• Leadership wahrnehmen, Kommunikation „Betroffene beteiligen“, frühzeitiger Einbezug von Anwendervertretern
• Projekt-Staffing – die richtigen Leute in den richtigen Projektrollen
• Scoping, Scoping, Scoping sowie Priorisierung der Anforderungen. Die führt unweigerlich zu Terminverzug, Kostenüberschreitungen
• Die Projekt Stakeholder beraten, d.h. Varianten und Alternativen aufzeigen, nicht zuletzt auch die Kosten aufzeigen

Und wie steht es mit meiner Auto Evaluation? Ganz einfach, seit gut 14 Jahren habe ich dasselbe Auto und bin sehr damit zufrieden.

Dasselbe gilt für mich im Beruf – seit Jahren praktiziere ich das Projektmanagement und blicke auf viele erfolgreiche Projekte zurück.