Strategie für Veränderungen

Rationale Strategie: Sie setzt auf Denken, sachliche Argumente, Logik. Zentral ist der Experte. Er analysiert das Pro­blem, erarbeitet Lösungsvorschläge und geht davon aus, dass andere ebenso sachbezogen und logisch denken wie er. Der Auftraggeber unterstellt dem Experten einen Wissensvorsprung und erwartet von ihm eine Lösung. Rationale Strategien liefern oft schlüssige Konzepte, doch ist es für Betroffene oft schwer, die vom Experten erarbeiteten Lösungen nachzuvollziehen. Sie werden als fremd empfunden und nicht akzeptiert. Auch wird kein eigenes Know-how erarbeitet. Experten können zu 100 Prozent richtigliegen und trotzdem kann das Projekt im Misserfolg enden. Der Skeptiker Michael Shermer hat dazu einmal gesagt: Je schlauer du bist, desto besser bist du im Rationalisieren einer schlechten Idee.

Entwicklungsstrategie: Hier bleibt die Verantwortung für die Veränderung bei der Organisation. Der beratende Experte liefert keine fertigen Lösungen, sondern gestaltet den Veränderungsprozess zum Wohl der beteiligten Organisationen. Der Ansatz geht davon aus, dass die Lösungsfähigkeit in der Organisation bereits vorhanden ist oder entwickelt werden kann. Die alten Lieferanten sind die neuen Partner.

Technische Expertise wird durch Methoden der Facili­tation integriert. Ein psychologisch sicherer Raum wird geöffnet, der Höchstleistung zulässt. Die Entwicklungsstrategie stärkt die Innovationsfähigkeit der Organisation, die Mitglieder erlernen Methoden sowie Strategien auch für künftige Entwicklungsprozesse. Das setzt einen hohen Zeitaufwand voraus. Sind Mitglieder der Organisation selber nicht bereit, Verantwortung zu übernehmen, kann keine Wirkung erzielt werden.

Für klassische Software-Projekte gibt es ein erprobtes vertragliches Instrumentarium. Früh werden Berater mit einer Bestandsaufnahme und mit der Erarbeitung eines Lastenhefts beauftragt. Dafür werden Verträge auf der Basis des Auftragsrechts ab­geschlossen. Geschuldet ist eine sorgfältige Beratung, aber kein Resultat, doch Pauschalpreise können vereinbart werden. Anschließend sucht eine Ausschreibung einen Anbieter, der bereit ist, das Projekt gemäß des Lastenhefts zu realisieren. Ein Werkvertrag fixiert Leistungsgegenstand, Termine und Kosten. Kommt es zu Änderungen des Leistungsgegenstands im Projektverlauf (was bei Software immer der Fall ist), müssen diese in Vertragsnachträgen (Change Requests) abgebildet werden. Für die Betriebsphase werden separate Wartungsverträge abgeschlossen.

Für Applikationsprojekte ist dieses vertragliche Instrumentarium jedoch nur beschränkt brauchbar. Denn das Werkvertragsrecht mit seiner auf messbare Ergebnisse ausgerichteten Resultatverantwortung polarisiert die Interessen. Es versteht Kundinnen und Kunden als bloße Leistungsempfänger statt als wesent­liche Faktoren für den Erfolg. Zudem bekommt der Kunde die falsche Sicherheit, man könne Projekterfolg einkaufen. Das Auftragsrecht bietet daher eine geeignete Grundlage, um Dienstleister mit Steuerungs- oder Moderationsaufgaben in Entwicklungsprojekten zu beauftragen, auch mit Pauschalpreisen für Leistungspakete. Doch kennt das Auftragsrecht keine Gewährleistung und deshalb auch keine Verpflichtung, für Mängel einzustehen.