In der aktuellen Serie stelle ich eine integrierte Methode vor, wie Sie den Aufwand bei Software-Entwicklungsprojekten plausibel und zuverlässig vorhersagen. Selbst wenn Sie als Auftraggeber ein Projekt mit einem Festpreis beauftragen, sind Sie gut beraten, die Plausibilität der Schätzung abzuklopfen. Denn wenn der Dienstleister die beauftragte Leistung nicht im Zeit- und Kostenrahmen liefern kann, haben Sie den Ärger – da hilft kein noch so „wasserdichter“ Vertrag. Darüber habe ich in Teil 1 dieser Serie geschrieben.
Das Risiko vor Projektstart
Dieser zweite Artikel dreht sich um die organisatorische Seite des Projektes. Hier sprechen wir nicht über Code-Zeilen oder Objektklassen, sondern über die Veränderung der Organisation. Und gerade weil in diesem Schritt kein IT-Vokabular zum Einsatz kommt, wird er von den IT-Architekten gerne vergessen. Und das hat fatale Folgen.
Gute Kommunikation hilft Risiken zu minimieren
Das größte Risiko in IT-Projekten liegt nämlich nicht in der technischen Realisierung sondern in der unklaren organisatorischen Erwartung. Jede Änderung der Spezifikation während der laufenden Entwicklung bringt die Kalkulation aus dem Gleichgewicht. Und ein guter Teil aller Änderungen ist darauf zurückzuführen, dass die Beteiligten vorher aneinander vorbei gesprochen haben. So banal es auch klingt: Gute Kommunikation vor dem Projekt hilft Kosten zu sparen.
IT-Fachleute sprechen gern über die Funktionalität von Applikationen – also darüber, was die Lösung tun soll. Unter dem Strich interessiert aber nur, was die Lösung in der Organisation bewirkt. Wenn die Lösung fertig ist, soll die Arbeit im Unternehmen anders sein als vorher (sonst könnte man sich das Ganze gleich sparen). Aber ist dieses anders auch besser? Bietet der Prozess „nachher“ wirklich eine Kostensenkung, eine Beschleunigung oder eine Qualitätsverbesserung gegenüber „vorher“?
„Bloß keinen Widerstand provozieren!“
Eine verbreitete Unsitte in frühen Projektphasen ist es, die geplante Lösung wachsweich zu formulieren. Wenn es darum geht, im Unternehmen Allianzen für ein Budget zu mobilisieren, stört allzu intensive Diskussion um das Ziel. „Jetzt bloß keinen Widerstand provozieren.“ Lieber kreative Interpretationsspielräume lassen. Vielen Menschen fällt es schwer, sich ihre zukünftige Arbeit vorzustellen, wenn die gewohnten Abläufe und Zuständigkeiten nicht mehr gelten sollten. Soll ein Projekt wegen ein paar skeptischen Bewahrern auf der Strecke bleiben? Die notwendige Diskussion in dieser Phase wird gerne umgangen. „Wenn wir erst einmal fertig sind, werden auch die Skeptiker überzeugt sein.“
„Das haben wir doch schon alles ausdisktuiert!“
Aber die nicht ausgefochtenen Kämpfe holen das Projekt ein. Was anfangs wie irrationaler Widerstand gegen Veränderung aussah, entpuppt sich oft als Hinweis auf ernstzunehmende Hindernisse. Am Ende kann die Lösung nicht wie geplant umgesetzt werden, es werden nachträglich umständliche Kompromisslösungen notwendig.
Es ist gefährlich, sich die Zustimmung in frühen Projektphasen durch weiche Formulierungen zu erkaufen. Wenn Skeptikern die Argumente für ihren Widerstand ausgehen, sind sie noch lange nicht im Boot. Der Wind ändert sich, und plötzlich zählen wieder Bedenken, die man glaubt, schon lange „ausdiskutiert“ zu haben.
Ich erinnere mich an eine Softwareeinführung, wo Filialleiter eines Dienstleistungsunternehmens ihre Kundenverträge direkt vor Ort im System erstellen und freigeben sollten. Bis dato haben sie „Anmeldungen“ auf Papier geschrieben, die in der Zentrale ins System erfasst wurden. Angesichts dieser Verlagerung wuchs die Angst, in den Filialen könnten „falsche“ Konditionen ungehindert erfasst werden und sich im Unternehmen eine Rabattmentalität breit machen.
Zunächst war geplant, den Gebietsleitern Kennzahlen an die Hand zu geben, mit denen sie die Filialleiter im Gespräch zu sinnvoller Nutzung ihrer Freiheit führen könnten. Später setzte sich die Skepsis durch und es kam der Ruf nach enger Führung durch das System. So musste nachträglich ein komplexes Tarifwerk im Vertragssystem abgebildet werden, damit je nach Kunde, Filiale und Leistung genau ein „richtiger“ Preis vom System vorgegeben wurde.
Sie können sich leicht ausmalen, wie hier ein Lösungskonzept auf den Kopf gestellt werden musste. Wie viel einfacher wäre es gewesen, die am Ende gewünschte Lösung gleich zu realisieren.
Widerstand provozieren, nicht vermeiden
Die Herausforderung in der Projektphase vor dem Anbieterangebot ist es, sich für eine organisatorische Lösung zu entscheiden. Klären Sie zunächst, ob die gewünschte Lösung im Prozess wirklich zu einer Verbesserung führt. Stellen Sie sicher, dass alle beteiligten Verantwortlichen diese angepeilte Veränderung verstanden haben und die Verbesserung sehen. Überprüfen Sie, ob die Prozessveränderung in der Organisation auch umgesetzt werden kann. Und nehmen Sie die Entwickler in der Diskussion immer mit – bevor Sie sich auf der „Fachseite“ in Lösungen verrennen, die später technisch teuer werden.
Für diesen Prozess ist es nötig, dass alle Beteiligten einen zukünftigen Prozess verstehen, die Änderungen erkennen und die Möglichkeit zum Widerspruch haben, wenn sich Skepsis meldet. Veränderung ist immer mit Widerstand verbunden. Wo sich kein Widerstand regt, gibt es wahrscheinlich auch keine Veränderung. Widerstand in Veränderungsprojekten ist also kein schlechtes Zeichen – im Gegenteil: trügerische Ruhe in der Organisation muss einen Projektleiter aufs höchste alarmieren.
Wer spätere Ehrenrunden im Projekt vermeiden will, tut gut daran, Widerstand in der Organisation früh zu provozieren. Machen Sie die Veränderungen für jeden Beteiligten klar und deutlich erkennbar. Spitzen Sie die Aussagen zu – fordern Sie die Menschen heraus, ihre Skepsis und ihren Unwillen zu formulieren. Jede Diskussionsrunde, die Sie jetzt drehen, spart Ihnen teure Schleifen im späteren Projekt.
BPMN-Modell als Klärungsinstrument
Als Instrument für diese Klärung hat sich das Prozessmodell nach dem BPMN-Standard bewährt. Der ISO-Standard für die Beschreibung von Geschäftsprozessen zeigt die Abläufe als Kollaboration zwischen den beteiligten Organisationen und den Applikationen. Gerade die Übergaben zwischen den Prozessen werden herausgearbeitet. Ein gutes BPMN-Kollaborationsdiagramm schafft Klarheit in der Organisation. Damit diskutieren alle Beteiligten auf einer konkreten Basis. In meinem Blog-Beitrag „BPMN 2.0 verstehen“ habe ich den Standard erläutert.
Im nächsten Beitrag geht es darum, wie man nach der organisatorischen Klärung aus dem BPMN-Modell den Projekt-Umfang ableitet.
