Projektkommunikation
Im Projekt ist Reden Gold
Die Unternehmensleitung und die Fachbereiche, die Anwender und die Mitarbeiter sowie die Kunden und die Partner - sie alle können von IT-Projekten betroffen sein. Folglich sollten sie auch in die Projektkommunikation einbezogen werden. Das ist den meisten Führungskräften in der IT auch klar. Aber die wenigsten von ihnen handeln entsprechend. Als Gründe nennen sie vor allem fehlende Zeit und Ressourcen.
Zu diesem Ergebnis kommt eine "Snapshot"-Studie der Münchner Agentur Progress 5 Brand & Business Development, für die sie im März und April dieses Jahres 21 IT-Führungskräfte aus deutschen Unternehmen befragte. Von diesen äußerten etwa drei Viertel die Ansicht, dass eine systematische und rollenbasierende Kommunikation in Projekten notwendig sei und wirtschaftliche Vorteile bringe. Das helfe, notwendige Anpassungen im Projekt frühzeitig und strukturiert umzusetzen. Zudem würden so die viel beschworene "Management Attention", die Akzeptanz der Anwender und die abteilungsübergreifende Zusammenarbeit gefördert.
- Probleme frühzeitig wahrnehmen
Damit man ein Projekt gar nicht erst in die "Notaufnahme für Projekte" schicken muss, hat Projektberaterin Andrea Ramscheidt ein paar Tipps zusammengestellt. Je früher sich ein Entscheider dazu Gedanken macht, desto besser. - Viel Zeit am Anfang
Welche Ziele ein Projekt erreichen soll, dafür sollte man sich gerade am Anfang viel Zeit nehmen. Menschen neigen dazu, schnell etwas zu beginnen. Dass man am Ziel vorbeischießt, merkt man erst nach einer Weile. Da kann es schon zu spät sein. Am Beginn eines Projekts sollte daher eine Stakeholder-Analyse stehen, mit Inhalts- und Ablaufplanung. - Nicht unter Druck setzen lassen
"Sagen Sie nicht Termin, Budget und Teilziele zu, bevor Sie einen ganz genauen Überblick haben“, rät Ramscheidt. Eine valide Prüfung braucht Zeit, schließlich muss alles genau berechnet werden. Die Zeit muss man sich als Projektleiter nehmen. Hat man alles genau geprüft und hält Zeitplan und Budget für enigermaßen realistisch, kann man loslegen. So muss man später nicht „nein“ sagen. - An einen Kollegen wenden
Bewährt habe sich, so Ramscheidt, sich früh an einen Externen zu wenden oder – noch besser – an einen Kollegen, der die Firma kennt, aber nicht im Projekt mitarbeitet. „Das gibt eine zusätzliche Sichtweise und ist für jedes Projekt wertvoll.“ Eventuelle Probleme können besprochen werden, bevor sie akut werden. - Offene Kommunikation etablieren
Ein Projektleiter sollte darauf achten, wie die Kommunikation im Team funktioniert. „Tauschen sich die Beteiligten nur während der Meetings aus oder reden sie auch mal beim Mittagessen über mögliche Probleme?“, sagt Ramscheidt. Es sei Aufgabe des Projektleiters, eine offene Kommunikation zu etablieren. - Besser als nichts
„Ein Projektleiter muss sich die Frage stellen, ob das Vorhaben noch Sinn macht oder ob es man es aufgeben sollte“, sagt Ramscheidt. „Er sollte aber auf jeden Fall Ruhe bewahren.“ Hat sich der Projektleiter eingestanden, dass das Projekt im Argen ist, muss er sich vor Augen führen: „Wie ist die Situation jetzt und welche Handlungsalternativen habe ich? Kann ich vielleicht noch Teilziele erreichen oder etwa eine Software nur mit Teilfunktionen live gehen lassen“, sagt Ramscheidt. Das ist immerhin noch besser, als das Projekt ganz abzuschreiben. - Schuldzuweisungen bringen nichts
Eines muss klar sein: Schuldzuweisungen bringen keine Lösungen. Vielmehr sollte sich der Projektleiter darauf konzentrieren, welcher Mitarbeiter im Team welche Ressourcen braucht, um seinen Teil noch zu schaffen. Wenn es nicht zu retten ist, sagt Ramscheidt: „Den Mut aufzubringen, zuzugeben, dass es gescheitert ist: Das ist eine der Aufgaben des Projektleiters.“
Belastung fürs IT-Budget
Zwei Drittel der Befragten würden sich also eine gruppenspezifisch abgestimmte Kommunikation mit allen Stakeholdern wünschen. Dennoch hapert es an der Umsetzung. Laut Progress 5 liegt das zunächst an einem Kostenstellungsproblem: Obwohl eine solche Kommunikation vielen Unternehmensbereichen zugutekäme, gehe der Aufwand dafür einseitig zu Lasten der IT-Budgets.
"Die IT-Projektteams haben dafür weder Zeit noch Ressourcen." So lautet der von den Umfrageteilnehmern am häufigsten genannte Grund für die mangelhafte Projektkommunikation. Häufig heißt es auch: "Der Nutzen ist unklar, der Return on Investment nicht quantifizierbar." Oder: "Im Unternehmen gibt es dafür keine Kompetenz." Wie ein Drittel der IT-Verantwortlichen einräumte, wird das Thema vielerorts "nicht als sonderlich wichtig" und als "unnötige Belastung des IT-Projektteams" betrachtet.
- Wann läuft ein Projekt schief
Die Reißleine ziehen - wann und woran lässt sich erkennen, dass ein Projekt aus dem Ruder läuft? - Ist für das Projekt eine Zeitdauer von mehr als eineinhalb Jahren vorgesehen?
Dann ist es besser, das Projekt in kleinere Teilschritte zu gliedern und Geschäftsprozesse nacheinander umsetzen. Der Grund: Ein Unternehmen entwickelt sich in zwei Jahren weiter, Geschäftsprozesse verändern sich und die ursprünglich geplanten Projektumfänge sind nicht mehr dieselben. Selbst ein sauber aufgesetztes Change-Management greift immer in die laufende und noch nicht vollständige Implementierung ein. - Werden Meilensteintermine überschritten?
Spätestens wenn der erste Termin überschritten wird, muss die Projektleitung dem sofort Rechnung tragen und gemeinsam mit dem Lenkungsausschuss die geplanten Maßnahmen kritisch prüfen. - Gibt es viele Änderungen während des Projektes?
Tauchen während der Projektlaufzeit permanent Änderungen auf, war die Planung schlecht oder die Realität überholt die Einführung. In diesen Fällen sollten alle Beteiligten offen über die absehbaren Risiken sprechen und realistische Gegenmaßnahmen entwickeln, die den Projekterfolg sicherstellen. Oder gemeinsam entscheiden, Termin- und Budgetanpassungen vorzunehmen. - Stimmen die zwischenmenschlichen Beziehungen noch?
Kommt es zwischen Beratern, Projektleitung und Key Usern vermehrt zu Spannungen, funktioniert die Kommunikation nicht (mehr) richtig. Motivationsprobleme treten auf und es werden oft Schuldige gesucht statt Lösungen. In solchen Fällen sollte umgehend gehandelt werden - dies ist eine der Hauptursachen für scheiternde Projekte! - Ist die vereinbarte Dokumentation ...
... im Projekt aktuell und sind Änderungen sauber dokumentiert? Wenn nicht, ist dies ein sicherer Indikator dafür, dass das Projekt aus dem Ruder zu laufen droht. - Stimmt die Qualität ...
... der Implementierungspartner und wie lässt sich mangelndes Wissen der Consultants erkennen? Implementierungsziele, die gerissen werden und Teilschritte, die qualitativ nicht der Planung entsprechen, sind eindeutige Anzeichen der Schwäche. Prüft man Teilschritte in regelmäßigen Abnahmen per Testkatalog, sind Abweichungen leicht festzustellen. - Ein Implementierungspartner ...
... und Verantwortlicher ist immer einfacher zu steuern als mehrere. Vor allem dann, wenn diese in einer Wettbewerbssituation zueinander stehen.