This post originated from an RSS feed registered with .NET Buzz
by -.
Original Post: Den Projekt-Sumpf hinter sich lassen. Jetzt!
Feed Title: Norbert Eder - Living .NET
Feed URL: http://feeds.feedburner.com/NorbertEder-Livingnet
Feed Description: Copyright (c)2005, 2006 by Norbert Eder
Unterschiedlichste Studien (beispielsweise von der Standish Group [1]) zeigen auf, dass nur ein Bruchteil s��mtlicher IT-Projekte auch tats��chlich fertiggestellt werden. Populieren wir diese Studien zus��tzlich mit Zufriedenheitsdaten, dann sieht die Statistik noch weit schlechter aus.
Woran diese scheitern m��chte ich nun anhand meiner ganz pers��nlichen Erfahrung beschreiben.
Wie schon in der Post Warum "Mein Chef will .."-Projekte meist in die Hose gehen (und in der darauffolgenden Diskussion, siehe Kommentare) beschrieben, sind oft ungenaue Spezifikationen und/oder Beteiligte mit fehlender Kompetenz, Faktoren f��r das Scheitern von Projekten. Dem kann im Grunde recht einfach entgegengewirkt werden, allerdings entsteht hierf��r anfangs ein erh��hter Aufwand, als auch m��glicherweise (sogar eher wahrscheinlich) zus��tzliche Kosten.
1) Fehlende interne Kompetenz durch externe Berater kompensieren. So kann vermieden werden, dass in den wichtigen Anfangsschritten grundlegende Fehler gemacht werden. Dies gilt sowohl f��r die gemeinsame Spezifikation mit dem Kunden, als auch der Entscheidung bez��glich zu verwendender Technologien, Entwurf der Architektur und verwandten Themen.
2) Kommen aufgrund der Unternehmensgr����e Business Consultants zum Einsatz empfiehlt es sich auf technisch versierte Personen zu setzen. Hier denke ich unter anderem an Spezifikationen die so technisch nicht umsetzbar sind oder den Aufwand ins quasi Unermessliche treiben. Auch Techniker k��nnen den Umgang mit dem Kunden lernen und wirtschaftliche Zusammenh��nge begreifen. Aus meiner Erfahrung erzielen Business Consultants die gr����ten Erfolge, die in "ihrem Leben davor" die Rolle des Umsetzenden inne hatten.
3) Technische Entscheidungen, L��sungswege etc. sollten auf jedem Fall mit der Entwicklungsabteilung (den zust��ndigen Personen) abgestimmt werden. Der Kunde versteht im allgemeinen dass bestimmte Punkte nicht sofort fixiert werden k��nnen, da notwendige Zusagen der Umsetzenden fehlen. Dadurch erh��ht sich f��r ihn die Chance das zu bekommen was er auch tats��chlich m��chte.
Eine zus��tzliche Problematik ergibt sich bei der Kommunikation. Oftmals werden bereits vorhandene Kan��le nicht benutzt oder es existiert eine Scheu vor neuen M��glichkeiten. Ablagesysteme f��r Dokumente aller Art fehlen oft (nun, wer findet ein bestimmtes Dokument als erstes?). Zust��ndigkeiten, Tasklisten werden oft nicht kommuniziert. Missverst��ndnisse stehen also an der Tagesordnung. Vielfach kommt zus��tzlich folgendes Verhalten zu Tage: Ein Thema wird lieber ��ber mehrere Tage hinweg via Email diskutiert, anstatt f��r 10 Minuten zum H��hrer zu greifen, das Thema zu besprechen, danach kurz in einem Protokoll zusammen zu fassen um es dann endlich erledigen zu k��nnen.
Das Thema der Kommunikation ist jedoch nicht nur auf interne Prozesse beschr��nkt. Ebenfalls wird oftmals die Kommunikation zum Kunden vernachl��ssigt. So ist ein Projekt spezifiziert, das Projekt begonnen, aber eine laufende Absprache und Kontrolle mit dem Kunden fehlt vollkommen. Der Kunde m��chte ��ber den Fortschritt bescheid wissen, kommt im Zuge diverser Demonstrationen auf Ver��nderungsw��nsche usw.
Fehlende Kontrolle. Wir bereits angesprochen: In vielen F��llen fehlen Kontrollmechanismen. Nein hier soll nicht der Mitarbeiter ��berwacht werden, sondern vielmehr der Fortschritt des gesamten Projektes. Denn nur dadurch kann festgestellt werden ob der Fertigstellungstermin zu halten ist. Nur dadurch kann dem Kunden st��ndig Feedback ��ber den aktuellen Implementierungsstand geliefert werden. Fakt ist: man wei�� wo man steht.
Dokumentation. Nein, nicht nur die Software sollte dokumentiert werden. Besprechungen, Telefonate, eben s��mtliche Entscheidungen. Dadurch kann festgestellt werden, wann etwas definiert wurde, wer anwesend war und dadurch kann vermieden werden, dass immer wieder ��ber bereits beschlossene Tasks diskutiert wird (sogenannte Endlos-Tasks die wie ein Damokles-Schwert ��ber alle Beteiligten h��ngen). Zus��tzlich zur daraus resultierenden Historie k��nnen Entscheidungswege nachvollzogen werden, k��nnen beispielsweise auch neue Mitarbeiter einfacher ins Boot geholt werden.
Lange Rede kurzer Sinn:
Ein Projekt erfolgreich abzuschlie��en ist im Grunde nicht schwer. Es erforderd Konsequenz von allen Beteiligten und eine realistische Planung. Ein Kunde ist bereit einen Monat l��nger auf die Software zu warten, wenn es zu Beginn so definiert wurde. Aber dann muss sie ausgerollt werden. Er soll ja als Kunde erhalten bleiben ...
Nat��rlich habe ich jetzt viele Punkte nicht beachtet, aber ich denke, dass ich viele wichtige Punkte erfasst habe. Leider steht jedem Projektmanagement Aufwand und Kosten gegen��ber, aber durch eine effiziente und genaue Planung k��nnen Kosten, Aufwand, Ungem��tlichkeiten, Streit etc. eingespart werden.
Previous Topic
