Konfliktpotenzial gibt es in Projekten genug, etwa wenn der Anwendungsentwickler nicht einsehen will, warum er eine kleine Softwareänderung nicht ohne Test einspielen kann. Autorin Sabine Niodusch skizziert einen fiktiven Dialog zwischen Programmierer und Projektleiterin, wie er sich in vielen Unternehmen zutragen könnte.
Der neue Entwickler der fiktiven Humor AG hat eine andere Arbeitsauffassung als seine Projektleiterin. Foto: Ljupco Smokovski/Fotolia.com
"Ich spiele die Änderungen eben mal ein“, sagte Simon Hechler, Anwendungsentwickler in der fiktiven Humor AG, und seit vier Wochen im Unternehmen. Das machst du nicht!“, warnte ihn Julia Matthies, eine sehr erfahrene Projektleiterin und seit Jahren im Unternehmen. Sie hatte ihm zum Üben die Verantwortung für eine kleine Softwareänderung innerhalb ihres Projektes übertragen.
"Und wieso nicht? Die Software ist fertig und sie ist getestet." Hechler wurde ungeduldig. Projektleiterin Matthies klärte ihn auf: „Bei uns laufen die Änderungen an der Software nach einem festen Schema ab: Im Projektantrag werden neben Zielen und fachlichen Anforderungen auch Risiken, Vorgehensweise, Betroffene und Beteiligte,Kosten, Abnahmekriterien und Termine schriftlich festgelegt. Jeder Projektantrag wird von Auftraggeber und -nehmer unterschrieben. Nach der Änderung werden diese von der IT getestet. War die Fachabteilung der Auftraggeber, testet sie die Software. Den finalen Integrationstest macht ein Integrations-Test-Team. Nur eine erfolgreich getestete Software wird zur Installation freigegeben. Die Installation der Änderungen erfolgt ausschließlich über den Tisch des Koordinators für die Softwareentwicklung.“
„Auch bei diesem kleinen Projektchen?“, fragte Hechler irritiert.
„Auch bei diesem kleinen Projektchen, wie du es so schön nennst“, bestätigte Matthies. „Wenn du das Gesamtsystem nicht kennst, kannst du meist allein nicht abschätzen, was eine kleine Änderung für Auswirkungen am Gesamtsystem hat.“
„Aber das kann doch keiner“, widersprach Hechler, „dafür ist das Unternehmen doch viel zu groß.“
„Ja und nein“, sagte Matthies, „Thomas Kowalsky koordiniert die Softwareentwicklung. Alle Projektanträge laufen über seinen Schreibtisch, er koordiniert Termine und die späteren Softwareinstallationen.“ Entwickler Hechler schüttelte den Kopf. „So viel Aufwand für so einen Kleinkram. Diese Miniänderung ist doch schnell eingespielt…“
„… und kann dich Kopf und Kragen kosten, wenn es anderer Stelle knallt“, unterbrach ihn Projektleiterin Matthies. »Es wäre nicht das erste Mal, dass so eine Miniänderung dazu geführt hat, dass gar nichts mehr geht, und dann hast du alle Anwender gegen dich, und hier laufen die Telefone heiß. Oder es knallt im Verborgenen, und ein Anwender fragt dich ganz unschuldig, wie diese Daten zustande kommen sind, er hätte sie doch gar nicht so eingegeben.“
„Das behaupten die Anwender immer“, schmunzelte Hechler. „Unterschätze die Anwender nicht, die sind nicht nur doof. Wir haben hier schon nächtelang Fehler gesucht, weil eine Miniänderung einen solchen Datenschrott produziert hat, dass nichts mehr ging. Und das ist super-aufwändig. Dann müssen die ganzen Änderungen Stück für Stück rückwärts nachvollzogen und manchmal sogar zurückgesetzt werden. Wenn du Tim Lenze, unseren CIO, wirklich einmal in Rage erleben willst… Es ist deine Entscheidung.“
„Das würde ich riskieren!“, konterte Hechler frech. „Vorher musst du aber an Kowalsky vorbei,“ entgegnete Matthies. „Den schaff ich. Das ist doch der alte Typ mit den weißen Haaren“, meinte Hechler. „Auch wenn er schon in den Sechzigern ist und weiße Haare hat, ohne ihn läuft hier gar nichts. Er hat den absoluten Überblick und ein geniales Detailwissen“, wies ihn die Projektleiterin zurecht. „Ich versuche es trotzdem“, beharrte der junge Entwickler. Julia Matthies holte tief Luft: „Ich warne dich, er hat einen schwarzen Gürtel im Judo.“
Sabine Niodusch ist selbst Projektleiterin und hat ihre Erfahrungen in fiktiven Projektgeschichten zusammengefasst. Foto: Niodusch Consulting
Zwei Tage später rief Softwarekoordinator Kowalsky Projektleiterin Matthies an: „Hat dem Neuen noch niemand erklärt, dass Software bei uns nicht mal eben eingeführt wird?“. „Ich hab es probiert“, entgegnete Matthies geduldig. "Es hat offensichtlich noch nichts genützt. Wie hat er es geschafft, dich zu umgehen?“ Kowalsky lächelte großzügig: "Zum Einspielen der Software braucht er ja Berechtigungen. Er hat versucht, eine Zugriffsberechtigung zu bekommen und wurde sofort abgewiesen. Alle, die ihn abgewiesen haben, waren so clever, mich zu informieren. Als das Bürschchen dann bei mir im Büro stand, habe ich ihn mir vorgenommen: Erst einen auf väterlich machen und dann die große Keule des Hüters der Software der H.umor AG herausholen und eine Predigt über die Konsequenzen des unbedachten Einspielens von Software und die damit einhergehenden Verantwortlichkeiten halten. Dann verließ er ziemlich geknickt mein Büro.“ Schweigen. „Ist er bei dir schon wieder aufgetaucht?“
„Bis jetzt noch nicht“, sagte Projektleiterin Matthies. „Klingt aber ganz so, als müsste ich jetzt wieder Aufbauarbeit leisten.“Darauf Kowalsky: „Julia, ich weiß, dass du das kannst. Du hast schon ganz andere Probleme gemeistert.“
Die 14 Fehler beim Projekt-Management Sie tun es immer wieder: IT-Abteilungen begehen regelmäßig dieselben Fehler beim Projekt-Management. Risiken werden nicht analysiert oder nicht das richtige Personal eingesetzt. Kein Wunder, dass nur ein Drittel aller Vorhaben erfolgreich ist.
Falsches Personal Der Fehler: Nicht die richtigen Leute für ein Projekt zu haben, kann das ganze Vorhaben sterben lassen. Alle Planungen sind nichts wert, wenn die notwendigen Talente fehlen.<br><br> Die Lösung: IT und Projekt Management müssen einen kompletten Überblick über die Fähigkeiten und Belastungsgrenzen des Personals haben. Das bezieht sich auch auf Berater, Anbieter und Outsourcing-Partner. Entscheidend ist, die Ressourcen bei den unzähligen Projekten und der täglichen Arbeit richtig einzusetzen.
Keine erfahrenen Projekt-Manager Der Fehler: Projekte können schnell außer Kontrolle geraten, wenn ein erfahrener Projekt-Manager am Steuer fehlt.<br><br> Die Lösung: Es muss ein Projekt-Manager her, der über die richtigen Zertifizierungen und die Finesse verfügt, die einzelnen Akteure zu steuern. Gute Projekt-Manager verstehen es, Meetings in die gewünschte Richtung zu lenken, Risiken zu managen und mit einer Vielzahl von unterschiedlichsten Mitarbeitern umzugehen.
Keine Methode Der Fehler: Keine Methode mit Standards zu haben erhöht das Risiko, dass das Projekt durch das Raster fällt. Es kann vorkommen, dass es dann komplett überarbeitet werden muss. Im schlimmsten Fall wird es nicht rechtzeitig fertig oder sprengt das Budget.<br><br> Die Lösung: Eine Methodik hilft, Projekte effizienter zu gestalten und informiert über alle Aktivitäten, die bei der Ausführung dazu gehören.
Zu viele Prozesse Der Fehler: Zu viele Prozesse auf einmal macht das Projekt-Team unflexibel. Was dabei herauskommt ist Frust bei den Beteiligten. <br><br>Die Lösung: Flexibel sein und mit Auftraggebern und Projektbeteiligten kommunizieren.
Änderungen beim Projektumfang werden nicht berücksichtigt Die Folge: Das Budget für das Projekt explodiert. Zeitpläne sind nur Makulatur. <br><br> Die Lösung: Strazza von CA empfiehlt einen Änderungsantrag ganz formal anzugehen. Ein Dokument sollte die spezifischen Änderungen auflisten. Der Projektleiter muss dann ermitteln, wie sie sich auf das Budget und den Zeitplan auswirken.
Keine Ahnung über den Status quo Der Fehler: Bei vielen IT-Projekten fehlen aktuelle Daten über den momentanen Status. Aber wie soll man etwas managen, wenn man es nicht messen kann? Vor allem ist es schier unmöglich, Ressourcen zu koordinieren oder auf Veränderungen zu reagieren.<br><br>Die Lösung: Software einsetzen und sich stets über den aktuellen Stand der Dinge informieren.
Probleme ignorieren Der Fehler: Probleme lösen sich leider nicht von selbst. Sie nehmen immer mehr zu, je länger man wartet. Die Folge sind steigende Kosten. <br><br> Die Lösung: Wenn mal etwas schief läuft, kommt es anschließend darauf an, wie schnell man es wieder in Ordnung bringt.
Umfang nicht klar definieren Der Fehler: Wenn der Umfang eines Projekts nicht klar umrissen ist, kann es so aufgeblasen enden wie Elvis in seinen letzten Jahren. Irgendwann verliert die IT die Richtung, um das Vorhaben im Rahmen des Zeitplans und des Budgets so über die Bühne zu bekommen, wie sich das Business das vorstellt. <br><br> Die Lösung: IT und Business sollten sich zunächst einmal Zeit nehmen und die Grenzen des Projekt strikt feststecken.
Zusammenhänge zwischen Projekt nicht sehen Der Fehler: Projekte laufen niemals isoliert für sich allein. Sie hängen oft mit anderen zusammen. Projektleiter vergessen schon mal, das zu berücksichtigen. Die Folge ist, dass nicht nur das einzelne Projekt den Bach runtergeht, sondern auch noch weitere mit nach unten zieht. <br><br> Die Lösung: Zusammenhänge zwischen einzelnen Projekten sollten schon bei der Planung berücksichtigt werden. Dabei hilft es, sich mit den Beteiligten zu besprechen und Projekte als Diagramme darzustellen, um zu erkennen, wie sie sich gegenseitig beeinflussen.
Murphy´s Law vergessen Der Fehler: Probleme kann es immer geben - und meistens folgt eins dem anderen. Das Schlimme ist nur, wenn die IT davon auf dem falschen Fuß erwischt wird. Das Projekt hat dann erst mal Zwangspause, während die IT versucht, den Laden wieder auf Vordermann zu bringen. <br><br> Die Lösung: Zu einer guten Projektplanung gehört ein Risiko-Assessment. Dafür muss das ganze Team überlegen, was passieren könnte. Danach geht es darum, diese Szenarien zu verhindern.
Kein Change Management Der Fehler: All die Zeit, Geld und harte Arbeit, die man in neue Technologien steckt, bringen nichts, wenn die Anwender diese nicht annehmen. <br><br> Die Lösung: Bevor zum Beispiel neue Applikationen implementiert werden, sollte geschaut werden, wo es im Unternehmen Widerstand gibt, um die entsprechenden Leute ansprechen zu können. Aufklärungsarbeit ist gefragt.
Unvollständige Ablaufpläne Der Fehler: Die Beteiligten wissen oft nicht, was wann zu erledigen ist. <br><br> Die Lösung: Zunächst sollten alle Schritte festgelegt werden, die für das Projekt notwendig sind. Als zweiter Schritt muss jedem Punkt eine Deadline gesetzt werden. Hilfreich dabei ist eine entsprechende Software.
Unrealistische Deadlines Der Fehler: Die IT weist zu selten nicht einhaltbare Deadlines zurück, die vom CEO vorgegeben werden. Dass das Projekt dann nicht just in time läuft, ist kein Wunder. <br><br> Die Lösung: Die IT muss dem CEO erklären, was es kostet, bestimmte Termine einzuhalten. Der hat dann die Wahl zwischen mehr Kosten oder mehr Zeit, die er dem Projekt zur Verfügung stellt.
Fachchinesisch Der Fehler: Die IT kommuniziert oft mit den Auftraggebern und anderen Beteiligten in einer Weise, die keiner außer ihr selbst versteht. <br><br> Die Lösung: Von Vorteil ist es, wenn man sich bei der Kommunikation auf die Gegenseite einstellt. Das gilt vor allem für die IT. Das Business hat keine Lust, seitenweise Technikbegriffe lesen zu müssen, die ein paar Funktionalitäten erklären sollen.