Als Projektleiter ist Micha für die Ergebnisse und Ziele seines Projekts verantwortlich. In acht Monaten soll er ein neues Workflow-Tool in seiner Organisation einführen. Dazu gehören Aufgaben wie: Anforderungen erheben, Tools evaluieren und auswählen, das Tool implementieren sowie die Anwender schulen. All das gehört zu seinem Projektumfang. Sozusagen ein "klassisches IT-Projekt". Standard.

Auch die Anforderungen für die Tool-Anbieter gehören für diese zum Tagesgeschäft. Micha glaubt, es ist ein Projekt ohne Potential für "Herzinfarkt-Puls-Frequenz", denn er sieht keine unkontrollierbare Risiken, keine "technische Herausforderungen" oder bahnbrechenden Innovationen. Ein ganz normales, unaufgeregtes Projekt also.

Der Projektanlass: Die bisherige Unterstützung von Workflows ist nicht durchgängig, Aufträge dauern zu lange, Eskalationen und Beschwerden treten viel zu häufig auf. Es gibt viele Tools – oft individuelle Excel-Checklisten – die als Provisorium begonnen haben und nie ersetzt wurden. Michas Auftraggeber möchte weniger Beschwerden und Rückfragen. Er wünscht sich einen "reibungslosen Standard", mit dem Aufträge schneller und besser bearbeitet werden.

Projektauftrag & Statusbericht

Micha hat sich an die Arbeit gemacht und den Projektauftrag mit seinem Auftraggeber beschrieben. Er hat einen ersten Meilensteinplan erstellt und alle zu liefernden Ergebnisse seines Projekts beschrieben. Micha weiß aus seinen letzten Projekten, wie wichtig es ist, seine Stakeholder zu kennen und regelmäßigen Kontakt zu halten. Auch darum kümmert er sich.

Den ersten Statusbericht erstellt er routiniert, aber dennoch mit Sorgfalt. Alles auf grün und solange er noch in der Konzept- und Planungsphase ist, ist das auch nicht weiter aufregend. Nach ungefähr zwei Monaten Projektlaufzeit beschleicht ihn ein merkwürdiges Gefühl.

Alles läuft planmäßig, trotzdem ist es "irgendwie zäh". Selbstverständlich führt kein Projektleiter sein Projekt nach Gefühl (!), aber jeder sollte auf sein Bauchgefühl hören. Also beginnt Micha zu analysieren "was da los ist".

Wie am Schnürchen

Die Stakeholder und die zukünftigen Nutzer unterstützen sein Projekt. Soweit so gut. Es gibt unterschiedliche Meinungen und Aspekte zum Thema "Workflow", aber das ist nach Michas Ansicht in Ordnung, schließlich sieht jeder zuerst seinen Arbeitsbereich. Einige sehen das Projekt kritisch, aber es gibt keine echten Gegner.

Auch sein Projektteam ist bei der Sache. Es gibt zwar manchmal Engpässe, weil alle im Team noch Linienaufgaben wahrnehmen, aber das kennt Micha aus anderen Projekten.

Alles kein Hexenwerk, findet Micha. Auf dem Papier sieht also alles ok aus: Zeitplan realistisch, Ressourcen kritisch, aber machbar (ganz normal also), Risiken bekannt und überschaubar. Alle Projektfakten scheinen zu stimmen.

Aber: Wird das Tool nach der Einführung (also nach dem Ende von Michas Projekt) auch genutzt werden? Ja klar, dafür macht Micha ja das Projekt, oder? Schließlich bietet das Unternehmen auch Schulungen für die Nutzer an.

Mehr als eine Tool-Einführung

Und als Micha bei diesem Gedanken anlangt, ist er am Kern seines Zweifels: Was sein Auftraggeber von ihm verlangt, ist ja auch eine Verhaltensänderung aller Kollegen. Was? Es geht doch bloß um ein Tool.

Im letzten Gespräch mit dem Projektauftraggeber haben die beiden über dessen Erwartungen diskutiert: Alle sollen sich an die Regeln halten, keine Ausnahme ohne klare Begründung, Dokumentation aller "Ausnahmen" und Sonderfälle, keine Eskalation ohne Lösungsvorschlag, und so weiter…. Das ist die Veränderung und letzten Endes der Impact (also Einfluss), den der Auftraggeber von Michas Projekt erwartet.

Was hat das mit der Implementierung von Workflows in einem wie auch immer gearteten Tool zu tun, fragt sich Micha. Er hat doch keinen Einfluss darauf, wann die Mitarbeiter zum Chef laufen, statt sich selbst um eine Lösung zu bemühen. Aber genau dies wird den Unterschied machen. Was soll Micha tun? Projektauftrag buchstabengetreu umsetzen oder am Impact des Projekts arbeiten?

Welcher Weg ist der richtige?

Es gibt Michas, die halten sich an den Projektauftrag. Das ist sicherer. Aufgrund der Erfahrungen, die sie mit ihrer Organisation gemacht haben, ist das für sie der einzige Weg, um das Projekt erfolgreich umzusetzen.

Und es gibt Michas, die halten sich an den Projektauftrag und möchten den Impact nicht vernachlässigen. Die sind unter Umständen für den Auftraggeber sehr unbequem, denn sie schneiden Aspekte an, die mit dem eigentlichen Projekt nichts zu tun haben, sondern mit Verhalten und Arbeitsweisen von Mitarbeitern und Führungskräften.

Lieber Projektauftraggeber, welcher Projektleiter passt besser in Ihre Organisation? Welchen Projektleiter Typ wünschen Sie sich für Ihre Organisation? Welcher Projektleiter-Typ hat in Ihrer Organisation eine Chance auf ein erfolgreiches Projekt in Ihrem Sinne?

Jede Projektmedaille hat wie immer drei Seiten: die des Auftraggebers, Michas, und die, die beide Seiten (noch) nicht kennen.