Überwachung und Steuerung – ein weiterer Stolperstein fürs Management

Prolog

Als Manager oder Berater hat man gelernt in Prozessen zu denken. Da ist es nicht verwunderlich, dass auch das Managen von IT-Projekten als ein Prozess gesehen wird. Nach allgemeinem Verständnis umfasst dieser (grob vereinfacht) folgende Teilprozesse:

• Initiierung
• Planung
• Ausführung
• Überwachung und Steuerung
• Abschluss

Bei den Phasen Initiierung und Abschluss herrscht wenig Uneinigkeit. Anders sieht es da bei den übrigen drei Punkten aus.

In meinem letzten Artikel habe ich mich bereits kurz den Themen Planung und Ausfühung gewidmet. In diesem Beitrag möchte ich die Überwachung und Steuerung etwas unter die Lupe nehmen.

Überwachung und Steuerung

Jede Unternehmung kann sich im Laufe ihrer Fortführung ändern. Dies ist zwar kein Grund die Planung ausfallen zu lassen und sich einer falsch verstandenen „Agilität“ hinzugeben. Aber auch eine vernünftige Planung muss von Zeit zu Zeit überprüft werden, da sich die Anforderungen geändert haben und eine Korrektur im „Kurs“ zu vollziehen ist.

Genau so denken die meisten Projektleiter.

Der Projektleiter ist der Kapitän

Viele Projektleiter sehen in der Aufgabe der Steuerung und Kontrolle sich selbst als Kapitän eines gut funktionierenden Schiffs. Das Schiff hat ein klares Ziel, eine funktionierende Mannschaft und nimmt anfangs kräftig Fahrt auf. Kommt das Schiff vom Kurs ab oder wird das Ziel (durch den Kunden) geändert, greift der Kapitän ins Steuer und korrigiert sachte den Kurs, so dass keiner seiner Leute von Board fällt.

Diese Analogie hinkt an allen Stellen!

Das fängt schon damit an, dass ein Schiff auf hoher See nahezu Luftlinie zum Ziel fahren kann. Außerdem sind wir es heutzutage gewohnt, dass ein Gebiet bis zum Ziel bereits gut kartographiert ist. Uns ist bereits im Vorfeld klar, um welche Kontinente und Inseln wir fahren müssen, um schnellstmöglich anzukommen. Vor allem aber gibt es eine berechenbare Strecke und eine nahezu konstante Geschwindigkeit, so dass man ganz genau feststellen kann, wie gut man in der Zeit liegt. Die Maßnahmen bei einem Schiff sind ebenfalls klar: schneller fahren.

Ein Softwareprojekt ist anders

Das Ziel sollte zwar in der Regel klar sein, aber der Weg dahin ist meist nur sehr grob bekannt. Mögliche Hindernisse, die es zu umschiffen gilt, tauchen erst spät auf und bringen nicht selten einen empfindlichen Zeitverlust mit sich. Anfangs geht alles noch leicht und schnell. Die Anzahl der Abhängigkeiten und Kommunikationswege ist überschaubar und kann ohne viel Administrativen Overhead erfolgen. Mit einem wachsenden Projekt werden diese jedoch dichter und undurchdringlicher. Die Entwicklung verliert an Fahrt, die anfangs optimistischen Aussichten weichen realistischen Einsichten bis zu einem Punkt an dem das Projekt hinter den Plan gerät.

In Verzug geraten

Nahezu jedes zweite IT-Projekt wird nicht Termingerecht fertig. (Solche, die Termingerecht fertig werden, haben dafür nicht selten personelle und finanzielle Notgroschen einlösen müssen.) Entweder muss man davon ausgehen, dass Projektleiter es in 30 Jahren nicht gelernt haben realistisch Schätzen zu lernen oder man muss sich eingestehen, dass Softwareentwicklung oft nicht so leicht planbar ist, wie eine Reise mit einem Schiff.

Steuerung statt Kontrolle

Für den Kapitän schein jetzt die Zeit gekommen zu sein von der Überwachung zur Steuerung überzugehen. Er stellt eine Liste der möglichen Handlungsalternativen auf und stellt fest, dass sich der Termin nur einhalten lässt, wenn der Kunde die Anforderungen reduziert oder das Team schneller vorwärts kommt. Da der Kunde meist aus Kostengründen ohnehin dem Team entgegengekommen ist, so wie ein Hafen so nah an der See liegt wie möglich, so unmöglich wird es ihm sein, weiter entgegenzukommen ohne das die ganze Sache in Wasser fällt.

Es bleibt dem Projektleiter nun nichts weiter übrig, als das Schiff auf maximale Fahrt zu bringen. Die Mannschaft wird zusammen gerufen, die Situation wird erläutert und alle werden angehalten nun so viel zu schaffen wie es nur geht.

Es wird im Team Druck aufgebaut, so wie in einem Kessel Druck aufgebaut wird um die Schaufelräder des Schiffes schneller drehen zu lassen. Dem Kapitän ist klar, dass es Grenzen gibt und er den Kessel nicht überstrapazieren darf. Aber solange der Kessel hält, kann man den Druck aufrecht behalten.

Wirkung auf das Team

Dass das Entwicklerteam nicht begeistert sein wird, ist sicherlich klar. Was aber manchen Projektleitern nicht klar wird, ist die Nachricht, die sie mit solch einer Handlung geben.

Mit der Annahme, man könne noch schneller und noch härter arbeiten, wird implizit ausgedrückt, man sei der Meinung, bisher hätte das Team gefaulenzt und nicht sein bestes gegeben. Die bisherige Leistung wird als „nicht ausreichend“ eingestuft. Natürlich hat man das so nicht gemeint. Aber das ist das, was das Team verstehen wird.

Die Moral im in der Gruppe wird sinken und alle so gut gemeinten Teambildenden Maßnahmen sind dahin. Die Vorwürfe werden zunehmen und Aufgaben werden zunehmend hin und her geschoben um irgendwie zumindest die eigenen Aufgaben schaffen zu können.

Das Team zerfällt in einer empfindlichen Phase, in der einzelne Teile, die bisher separat entwickelt wurden miteinander verbunden und verheiratet werden sollen. Gerade am Anfang und am Ende eines Projektes ist eine reibungslose Kommunikation im unter den Beteiligten sehr wichtig.

Die nett gemeinte Variante

Dass Druck auf „Kopfarbeiter“ wenig beschleunigend wirkt, haben zum Glück mittlerweile einige Projektleiter begriffen und versuchen anders an das Problem heranzugehen.

Statt Druck aufzubauen Versuchen die Ablenkungen und Störungen vom Team abzuschirmen. Auch hier könnte der Eindruck beim Team entstehen, man sei abgelenkt gewesen. Aber das Frust- und Stresspotential ist hier wesentlich geringer.

Leider schießen manche Projektleiter hier etwas über das Ziel hinaus. So ist das isolieren von Einzelpersonen vom Team oder des Teams vom restlichen Unternehmen keine gute Idee. Soziale Interaktion ist wichtig. Wenn Entwickler Ruhe brauchen, sollten sie in die Lage versetzt werden auch ungestört zu bleiben. Hängen sie jedoch an einer Stelle fest, kann eine kurze Ablenkung mit Kollegen aus der Nachbarabteilung den Kopf wieder lösen. – Das nachdenkliche Trinken eines Kaffes in der Cafeteria muss nicht zwangsläufig bedeuten, dass der betreffende nicht über die Aufgabe nachdenkt, die es zu lösen gibt.

Ebenso dienen Pausen der Abwechslung und Sozialisation. Es ist eine Unart mancher Projektleiter (und überengagierter Mitglieder des Teams) die Kaffepause zu nutzen um Aufgaben für den Vormittag durchzugehen.

Ebenso wenig hilfreich sind „Workshops“, welche die Kommunikation in der Endphase beschleunigen sollen, wenn eigentlich jeder weiß, was zu tun ist und eher Ruhe braucht.

Was tun?

Zunächst einmal sollte man als Projektleiter versuchen aus vergangenen Projekten zu lernen. Fragen sie sich, was hiervon bei ihnen bereits so vorgekommen ist. Wenn mehr als Ihnen lieb ist, dann ändern sie einen Teil ihrer Maßnahmen. Hier möchte ich einige aufzählen. Es ist aber bei allen darauf zu achten wann sie sinnvoll sind und wann nicht. Eine gute Maßnahme zur falschen Zeit ist wie eine falsche Maßnahme zur richtigen Zeit.

Planen sie realistisch

Seien sie sich bewusst, dass das Projekt anfangs schneller und später langsamer voran kommt. Gehen sie nicht von einem linearen Verlauf aus. Schaffen sie keine unrealistische Erwartungshaltung, die das Team anschließend nicht einhalten können wird. Mit einer realistischen Planung sind die meisten Probleme bereits im Vorfeld beseitigt.

Temin verschieben

Einen Termin zu verschieben oder das Budget aufstocken ist eine sehr unangenehme Aufgabe. Es wirft viele Fragen auf, die man als Projektleiter ungerne beantworten möchte; vor allem dann, wenn das Projekt in Verzug geraten ist. Man sollte sich jedoch nicht verleiten lassen, dies auf dem Rücken der eigenen Administratoren, Entwicklern und Testern austragen, in dem sie antreibt. Sonst verliert man den Rückhalt und die Unterstützung im eigenen Team, was die ganze Sache nicht besser macht. Außerdem wird ein Termin selten auf die Art eingehalten. Das Problem wird also nur vertagt. – Verschafft man dem Team hingegen Zeit, gewinnt man die Achtung des Teams.

Raum geben

Entwickler brauchen Räume. Einen Raum um Ruhe zu haben und mindestens einen, wo man sich treffen kann und kurzfristig Dinge besprechen kann ohne die anderen zu stören. Dies ist ein Luxus, den sich die meisten Unternehmen nicht dauerhaft für jedes Team leisten können. Jedoch gibt es oft Räume, die man sich mit anderen teilen muss. Vor allem am Anfang und gegen Ende eines Projektes ist es daher wichtig ihrem Team möglichst oft einen Raum verfügbar zu machen. Freuen sie sich, wenn er nicht gebraucht wird und machen sie Kollegen glücklich. Zeigen sie ihrem Team, welchen Beitrag sie leisten.

Probleme abholen

Ihr Team ist eine Gruppe von Problemlösern. Sie sind gewohnt Probleme zu erkennen und eigenständig zu lösen. Dies ist gut, wenn es um das Produkt geht; aber es ist schlecht, wenn es darum geht Probleme zu melden. Die meisten werden dazu tendieren Wege zu suchen ihre Probleme auf eigene Faust zu lösen. Manches geht nicht ohne den Segen von „oben“. Hier können eventuell sie helfen oder vermitteln. Sie haben einen ganz anderen Blickwinkel auf die Situation und ganz andere Möglichkeiten. Gehen sie also auf ihre Entwickler zu und fragen sie nach bestehenden Problemen. Aber Vorsicht: Es sollte darum gehen, wie sie helfen können eine gute Arbeitsumgebung zu schaffen – nicht um inhaltliche technische Fragen, welche die aktuelle Aufgabe des Entwicklers betreffen.

Diese Liste ließe sich bestimmt um noch einige Punkte erweitern. Ich habe mich hier auf jene Beschränkt, die m.E. gerade in der stressreichen Endphase eine Projektes helfen sollten den Druck vom Team fernzuhalten.