Aus aktuellem Anlass, habe ich mir wieder einmal Gedanken zum Thema “Warum SharePoint Projekte scheitern” gemacht.
Es gibt offensichtlich mehrere Gründe warum SharePoint-Projekte scheitern. Gelegentlich finden sich die Gründe außerhalb der Reichweite der beteiligten Parteien und sind nicht wirklich die Schuld von einer bestimmten Person, die an dem Projekt beteiligt ist. Meiner Erfahrung nach ist dies jedoch fast nie der Fall. Der Fehler ist in der Regel ein Fehler von einem oder mehreren Mitgliedern des Teams.
Der Grund liegt (meine Erfahrung) vielfach beim Management des Projektes. Der Projektmanager hat keine leichte Aufgabe. Er muss eine Balance finden zwischen über- und unter Koordinieren, Leiten und Managen. Je nach Symptomen die gerade während der Projektlaufzeit auftauchen. Diese Symptome sind auf den zweiten Blick nicht nur auf SharePoint Projekte anwendbar, sondern vermutlich auf die meisten IT-Projekte (die scheitern) anwendbar. Aber was sind diese Symptome?
1. Business-Ziele nicht genau definiert oder der vom Auftraggeber akzeptierte Vorschlag steht im Wiederspruch mit der tatsächlichen strategischen oder operativen Anforderungen. Dieser Punkt wird vielfach erst während dem Projekt realisiert. Wenn der Projektmanager dann probiert, einfach seine Linie weiter zu gehen, (Weg des geringsten Wiederstandes) sieht es logischerweise nicht gut für das Projekt und/oder den Erfolg der Realisierung aus.
2. Die Anforderungen wurden vom Kunden oder dem Lieferanten oder beiden nicht vollständig verstanden. Auch dieser Punkt bemerkt man oft, wenn das Projekt im Gange ist. Wenn man sich hier scheut offen und ehrlich noch einmal einen Schritt zurück zu gehen, wird das Projekt wohl kaum vom Erfolg gekrönt werden.
3. Der Kunde probiert mit dem Produkt Office SharePoint Server 2007 ein Web 2.0 Buzzword mit auf seine Intra/Extranet Seite, oder sogar auf das Internet zu bringen. Er ist sich aber über die Konsequenzen die sich dadurch in seiner eigenen Organisation ergeben nicht bewusst.
4. Die Erwartungshaltung in Bezug auf Lieferobjekte werden nicht geklärt. Dieser Punkt ist vermutlich der Wichtigste. Unterschiedliche Erwartungshaltung lösen während dem Projekt immer wieder Meinungsverschiedenheiten aus. Wird die gegenseitige Erwartungshaltung zu lange nicht geklärt, merkt eine Partei plötzlich (meist vor einem Meilenstein), dass aus ihrer Sicht ja alles völlig im argen liegt. Aussagen wie: “… dann hätte ich es ja gleich tun können”, oder “..ich dachte ihr seit Profis genug” werden dann über den Tisch hin uns her geschoben.
5. Falsche Schätzungen bei Kosten, Zeit, Ressourcen, Infrastruktur – Hardware-und Software-, Kapazitäts-Management usw.).
6. Umfangreiche Änderungen und/oder strategische Neupositionierung im laufenden Projekt. Wird von allen geliebt, insbesondere während der Endphase des Projekts.
7. Projekt-Prozesse wurden nicht definiert oder sie sind definiert, werden aber nicht konsequent eingehalten. Wir alle haben es während der Ausbildung gelernt: An einem Kickoff sollte man erläutern wie man gedenkt zu Dokumentieren, welche Kommunikations-Kanäle benutzt werden sollen (insbesondere wenn mit dezentralen Teams gearbeitet wird), wo man die Risiken heute schon sieht, welche Masstäbe man an die Qualität setzt und so weiter. Man hat uns das beigebracht, damit wir aus vergangen Fehlern lernen.
8. Fehlende Kommunikation und fehlende Aufrechterhaltung der Beziehungen mit allen Beteiligten (Kunde, Berater-, Infrastruktur-Anbieter, Geschäftspartner und alle anderen Beteiligten in dem Projekt). Ich glaube, das ist bei grossen und komplexen Projekten eines der Hauptprobleme. Vor allem externe und dezentrale Projektmitarbeiter tendieren bei fehlender Kommunikation dazu die “Begeisterung” für das Projekt zu zügeln.
Wie sieht es bei Euch aus? Habt Ihr Kommentare oder weiter wichtige Punkt hinzuzufügen?
