IT-Projekte im Mittelstand

Für heute nachmittag ist bei meinem Mittelständler der Akzeptanztest für ein neues Modul der hiesigen ERP-Software (Individualentwicklung) angesetzt. Das neue Modul beinhaltet die elektronische Signatur und das ist relativ tricky, weil dieses Unternehmen mit dieser Technologie in vorherigen Projekten noch nie in Berührung gekommen ist. Außerdem ranken sich um das neue Softwaremodul verschiedene betriebliche Prozesse in verschiedenen Prozessvariationen. Ob eben diese von dem neuen Modul abgedeckt werden, das soll der Test heute rausfinden. Am Test sollen nebst mir und einer Kollegin aus dem Rechenzentrum zwei Mitarbeiter aus zwei unterschiedlichen Fachabteilungen, die das Moduls später hauptsächlich nutzen werden, teilnehmen.

Zwei Stunden vor Testbeginn ruft mich der Kollege aus der Fachabteilung A an. Er wolle nur mal eben Bescheid sagen, dass krankheitsbedingt ein Kollege ausgefallen ist und er diesen Kollegen nun vertreten soll. Von seinem Chef hätte er ordentlich Druck gekriegt und könne darum nicht ganz bis zum Ende mittesten. Das wäre aber ja nicht so schlimm, denn sein Kollege (der, wie schon erwähnt, aus einem ganz anderen Fachbereich kommt) wäre ja noch da.

Für mich ist diese Situation typisch für den Umgang mit Akzeptanztests in vielen Unternehmen. Diese Tests werden leider häufig von den Fachabteilung nicht sonderlich ernst genommen. Unser Test zum Beispiel wurde seit einer Woche geplant und damals war die Situation bezüglich Krankheitsvertretung schon bekannt. Der Projektleiter hat jedoch in der Projektrunde zugesagt, dass für den Kollegen aus Fachbereich A eine Vertretung gefunden werden würde. So richtig geklappt hat das aber offensichtlich nicht. Ich habe meinem Kollegen angeboten, zur Klärung der Vertretung noch einmal mit dem Projektleiter zu sprechen. Aus Angst vor Ärger mit seinem Chef war das aber das Letzte, was mein Kollege wollte.

Wir werden jetzt einen zweiten Termin ansetzen, falls der Test heute nicht beendet werden kann. Das ist zwar ärgerlich, weil es alle Beteiligte wieder Zeit kostet, aber meiner Meinung nach immer noch besser, als den Akzeptanztest nur unvollständig durchzuführen. Denn wer kann besser beurteilen als ein kompetener Enduser aus der jeweiligen Fachabteilung, ob das neue Modul alle Prozesse seiner Abteilung abdeckt? Das weiß der Kollege aus der Nachbarabteilung nicht und der IT’ler noch weniger. Auf der Notwendigkeit von Tests herumzureiten, bringt einem zwar keine zusätzlichen Beliebtheitspunkte bei den Kollegen - aber das tut ein Modul, in dem die Halfte der betrieblichen notwendigen Features fehlt, erst recht nicht.

Über den genauen Anteil gescheiterter IT-Projekte in mittelständischen deutschen Unternehmen sind sich die Experten uneinig. Bei silicon.de ist zu lesen, dass 68 % aller IT-Projekte insgesamt als gescheitert betrachtet werden müssen. Das deckt sich in etwa mit dem Ergebnis der Standish Group, die ermittelt hat, dass 2004 weltweit lediglich 29% aller IT-Projekte erfolgreich abgeschlossen wurden. Die Success-Studie, die 2006 vom Oldenburger Offis-Institut durchgeführt wurde, identifiziert dagegen in Deutschland nur ca. 20% der IT-Projekte in den befragten Unternehmen, welche nur mit einem ausreichenden oder schlechteren Ergebnis beendet wurden.

Die Zahlen zu gescheiterten IT-Projekten sprechen also keine deutliche Sprache. Ich frage mich jedoch bei alledem, wann ein IT-Projekt letztendlich als gescheitert einzustufen ist. Sind Projekte erst gescheitert, wenn sie abgebrochen werden? Oder ist auch ein Projekt gescheitert, das zwar beendet wurde, jedoch in einer Software resultierte, die die Anforderungen der Anwender nicht oder nur ungenügend erfüllt und damit den Betrieb mehr aufhält als dass sie hilft? Oder - mindestens genauso schlimm - in einer Software, die aus diesen Gründen niemand benutzt? Und was ist mit Budget- und Terminüberschreitungen, wie spielen die in diese Bewertung herein? Kann ein Projekt bespielsweise als erfolgreich bezeichnet werden, wenn es den Terminplan um 200% und das Budget um 100% überschritten hat?

Meine Erfahrung der letzten Jahre hat gezeigt, dass es gerade im Mittelstand viele IT-Projekte gibt, die zwar mit Biegen und Brechen durchgeboxt oder künstlich am Leben gehalten werden. Ich würde diese Projekte jedoch nicht unbedingt als erfolgreich bezeichnen würde - aus den eben genannten Gründen. Gleichzeitig werden bei neuen Projekten dieselben Fehler immer wieder gemacht: die Anwender werden nicht ausreichen einbezogen, gewünschte Features werden nicht schriftlich spezifiziert sondern zwischen Tür und Angel gesprochen, man möchte alles auf einmal umsetzen anstatt Features oder sogar ganze Projekte sinnvoll zu priorisieren, für die Tests und das Bugfixing wird nicht genug Zeit eingeplant und so weiter… Bis dann im monatlichen Gschäftsführerbericht, zwar ganz wenige Projekte auf rot stehen, die Zahl der problemlosen Projekte aber auch verschwindend gering sind.

Das sind alles Dinge, zu denen die jeder, der einige Zeit in der IT-Abteilung eines Mittelständlers oder bei dem Dienstleister eines Mittelständlers verbracht hat, wieder und wieder mit dem Kopf nicken kann. Im Prinzip weiß jeder, warum es nicht so erfolgreich läuft wie es am Anfang gedacht war - an der betrieblichen Praxis ändert das freilich nichts. So manchmal fühlt man sich da schon in den Film “Und täglich grüßt das Murmeltier” mit Bill Murray versetzt…

In diesem Blog möchte ich meine Erfahrungen mit IT-Projekten festhalten und so versuchen, einen Bogen zu spannen zwischen der theoretischen Best-Practise zur Umsetzung von IT-Projekten und der betrieblichen Realität bei einem Mittelständler. Diese Erfahrungen müssen nicht immer zwangsläufig meine eigenen sein - da ein großer Teil meines Bekanntenkreises in der IT-Branche tätig ist, werden ganz sicher auch mal Geschichten aus dieser Quelle dabei sein. Um Arbeitgeber oder Kunden damit nicht zu verägern, gilt hier natürlich weitestgehend “Ich nennen keine Namen”. Das ist aus meiner Sicht auch gar nicht wichtig, denn die Erfahrung zeigt, dass die Probleme der Unternehmen bei der Umsetzung von IT-Projekten sehr ähnlich sind - egal um welches Unternehmen in welcher Branche es sich handelt.

Es geht hierbei gar nicht darum, den “einen richtigen Weg” zur erfolgreichen Umsetzung von IT-Projekten im Mittelstand zu finden. Ich bin jetzt schon davon überzeugt, dass es den wahrscheinlich sowieso nicht gibt. Es geht hier erst einmal vor allem darum, Erfahrungen zusammen zu tragen und Dinge, die man beim nächsten Projekt besser machen könnte, festzuhalten. Mein fachlicher Schwerpunkt liegt bei dem was ich schreibe im Bereich Dokumentenmanagementsysteme, aber es wird sich auch um Beispiele aus anderen Bereichen drehen.

Zum Schluss bleibt dann nur noch viel Spaß beim Lesen zu wünschen sowie der Hinweis, dass ich mich über Kommentare und angeregte Diskussionen in diesem Blog sehr freuen würde!

Quellen:
http://www.silicon.de/cio/strategie/0,39038989,39200412,00/68+prozent+aller+it_projekte+scheitern.htm
http://www.offis.de/umfragesuccess