Weniger schreiben, mehr kommunizieren

Von: Jürgen Rohr, PM-Berater, Wiesbaden

Was muss das neue System können? Das fragen sich Unternehmen

zurecht, bevor sie mit dem Entwickeln neuer IT-Systeme beginnen. Doch wie detailliert sollte die IT-Spezifikation sein, und wie sollte man bei ihr vorgehen? Diesbezüglich besteht oft Unsicherheit.

In vielen Unternehmen wird die IT-Spezifikation als mühsame Pflicht gesehen. Denn gerade die „alten Projekthasen“ wissen: Wenn wir erst einmal ans Entwickeln des neuen Systems gehen, kommt ohnehin vieles anders als geplant. Entsprechend mechanisch und bürokratisch wird diese Aufgabe oft erledigt. Viel sinnvoller wäre es, sie als dynamischen sowie interaktiven Prozess zu verstehen, an dessen Ende das von allen Beteiligten gewünschte oder benötigte IT-System entsteht.

IT-Spezifikation hat etwas mit Vertrauen zu tun – und zwar mit Vertrauen in die Lieferanten, dass diese verstehen, was die Fachabteilung wirklich braucht, und in die Fachabteilung, dass sie nicht mehr fordert, als sie bereit ist zu investieren. Fehlt dieses Vertrauen, tendieren die Beteiligten zum Sich-Absichern. Dies manifestiert sich in Lastenheften mit Tausenden von Anforderungen, deren Nutzen höchst fraglich ist.

Vertrauen schaffen

Oft kennen sich zu Beginn des Spezifizierungsprozesses die Fachleute und die IT-ler noch nicht. Sie müssen sich erst finden und eine gemeinsame Sprache entwickeln, um Missverständnisse zu vermeiden. Das Grundprinzip, um Vertrauen zu schaffen, lautet: Klein anfangen und rasche Erfolge erzielen. Der Vorteil eines „langsamen“ Starts ist: Die Arbeitsprozesse zwischen Fachabteilung und IT-Lieferant können sich einspielen. Und beide Seiten lernen die Bedürfnisse und Denkweise der jeweils anderen kennen. Das ist eine Grundvoraussetzung für Vertrauen.

Deshalb sollte man nicht zu groß planen, sondern mit einer relativ kleinen Funktionalität anfangen. Diese sollte jedoch keine Spielwiese sein, sondern eine Funktionalität, die bereits erkennbar zu einer Verbesserung der Arbeitsprozesse beiträgt. Das kann so etwas wie die automatische Datenübernahme zwischen zwei Systemen sein, sodass niemand mehr die Daten manuell eingeben muss. Der Funktionsumfang sollte so klein gehalten werden, dass zwischen dem Beginn der Spezifikation und der fertigen Implementierung maximal vier bis acht Wochen vergehen.

Überblick gewinnen

In IT-Projekten dreht sich fast alles um die Frage: Was sollte das System können und was nicht? Denn was nützt den Beteiligten das modernste IT-System, wenn darin wichtige Funktionen fehlen? Doch welches sind die wichtigen Funktionalitäten? Und welche blähen das System unnötig auf? Und welches sind Nice-to-have-Funktionen, auf die man eventuell verzichten kann?

Sich hierüber (vorläufig) zu verständigen, fällt oft leichter, wenn man bedenkt: Der Scope, also der Inhalt und Umfang von komplexen IT-Projekten, verändert sich in deren Verlauf stets – zum Beispiel weil sich Rahmenbedingungen wandeln. Deshalb macht es wenig Sinn, vorab 100-seitige Spezifikationsdokumente zu schreiben, die sich in allen Details verlieren. Sinnvoller ist es, das Dokument im Verlauf des Projekts immer weiter zu konkretisieren und dieses fortlaufend zu aktualisieren.

Fragen klären

Für eine initiale Scope-Beschreibung reicht in der Regel ein Workshop von zwei Tagen. Dort sollten folgende Fragen geklärt werden:

• Wer sind die relevanten Mitspieler?
• Wer erwartet sich einen Nutzen von dem IT-System?
• Wer wird es bedienen?
• Was sind die Ziele dieser Mitspieler?
• Welchen Nutzen erwarten die verschiedenen Mitspieler von dem System?
• Welche Erwartungen und Bedürfnisse haben sie?
• In welchen Bereichen soll das IT-System Arbeit erleichtern?
• Welche Arbeitsprozesse sind betroffen?
• Welche Aufgaben haben die Mitspieler?
• Welche Teile der Wertschöpfungskette sind betroffen?
• Wo gibt es eine Interaktion zwischen unterschiedlichen Abteilungen?
• Welche Prozessvarianten gibt es/sind möglich?
• Welche IT-Systeme gibt es schon heute?
• Welche IT-Systeme sollen das neue System ablösen?
• Welche „Unter-Tisch-Software“ wird aktuell eingesetzt?
• Welche Systeme sollten angebunden werden?
• Welche technologischen Vorgaben sind einzuhalten?
• Welche unternehmensweiten Standards müssen beachtet werden?
• Welche Guidelines existieren?
• Welche Software-Schnittstellen sind zu beachten?
• Welche Zielarchitektur wird angestrebt?
• Welche Projekte laufen derzeit noch?
• Wo gibt es möglicherweise Überschneidungen zu anderen Projekten?
• Wie lassen sich die Projekte abgrenzen?
• Welche Zulieferungen sind notwendig?
• Welche Projekte könnten die Arbeitsprozesse oder Ziele verändern?
• Wer sind die relevanten Entscheider?
• Wer bezahlt das IT-Projekt?
• Wer muss im Lenkungskreis vertreten sein?
• Wer sollte über das Projekt und seine Zwischenergebnisse informiert sein?
• Welche Personen sind Multiplikatoren?
• Wer entscheidet am Ende über Erfolg oder Nicht-Erfolg?
• Was sind die Rahmenbedingungen?
• Wie viel Zeit haben wir?
• Welches Budget steht zur Verfügung?
• Wie wird das Budget akquiriert?
• Was ist der Business-Case?
• Wie und wann rechnet sich das Projekt?
• Wo sind Einsparungen zu erwarten?
• Wie lassen sich die Kosten rechtfertigen?

In einem Scope-Workshop sollten möglichst alle relevanten Interessen- und Funktionsgruppen vertreten sein, damit eine tragfähige Basis für das Projekt entsteht. Anwesend sollten unter anderem sein: Vertreter der betroffenen Fachabteilungen, (IT-)Techniker und IT-Administratoren, Support-Mitarbeiter und Entscheider, Fürsprecher und Gegner, „alte Hasen“ und „junge Hunde“.

Spezifikation anpassen

„So wenig wie möglich spezifizieren“ – das mag provokant klingen, ist aber eine wichtige Projekterfahrung. Gerade bei strategisch bedeutsamen Projekten ist die Versuchung oft groß, alles bis ins letzte Detail zu beschreiben. Dabei ist vor Beginn großer (IT-)Projekte in der Organisation meist niemand in der Lage, die Komplexität eines geplanten IT-Systems in seiner ganzen Tiefe gedanklich zu erfassen. Also kommt es zwangsläufig zu Änderungen – und damit meist zu Zeitdruck. Je höher dieser ist, um so eher wird „vergessen“, die Spezifikation der aktuellen Entwicklung anzupassen. Eine häufige Folge: Am Ende des Projekts hat das Unternehmen zwar eine sehr detaillierte Spezifikation, das entwickelte IT-System ist aber ein ganz anderes als das spezifizierte.

Wann immer möglich, sollten die Spezifikation auf die Anwendung des IT-Systems beschränkt werden. Wie soll ein Anwender (oder ein externes System) mit dem neuen IT-System interagieren? Welche Schritte werden durch den Anwender durchgeführt, welche durch das IT-System? Der Rest ist Kommunikation: In der Interaktion mit den User-Interface-Designern werden die passenden Bildschirmdialoge und Druckausgaben entworfen, in der Interaktion mit den Datenbank-Entwicklern werden die Geschäftsobjekte modelliert, in der Interaktion mit den Architekturverantwortlichen werden die fachlich relevanten IT-Schnittstellen definiert und in der Interaktion mit den Systemtestern werden die fachlichen Details in Testfällen festgeschrieben. So erhält man eine übersichtliche Spezifikation mit einer Reihe zusätzlicher Arbeitsergebnisse.

Lernkurve durchlaufen

Der Systemtest ist keine alleinige Aufgabe des IT-Lieferanten. Die Fachexperten wissen am Besten, worauf beim Testen besonders geachtet werden muss. Deshalb sollten sie sich an der Ausarbeitung der System-Testfälle beteiligen. Zudem wäre es von Vorteil, eine kontinuierliche Integration der entwickelten Komponenten anzustreben, damit regelmäßig getestet werden kann. Denn diese Tests liefern wichtige Erkenntnisse, die wiederum in die Spezifikation einfließen können. Außerdem geben gedeckelte Budgets Investitionssicherheit und setzen Projekten wichtige Limits. Ohne feststehende Budgets wird schnell mehr und mehr investiert, ohne dass ein wirklicher Mehrwert entsteht.

Jedes Projekt hat eine Lernkurve, die bewusst durchlaufen werden sollte. Das heißt, mit funktionalen Einheiten anzufangen, die eine möglichst ähnliche Größe haben. Mit den ersten Ergebnissen erhält man dann tatsächliche Aufwandszahlen. Mit diesen kann das Backlog, also der Bestand der noch ausstehenden funktionalen Einheiten, abgeschätzt werden – um somit zu einer realistischen (Budget-)Planung zu gelangen.

Kommunikation intensivieren

Wenn ein Änderungsbedarf erkannt wird, fügt man die Änderung in das Backlog ein und bewertet diese gemeinsam. Die wichtigsten funktionalen Einheiten werden vorgezogen; alles, was eher „nice to have“ ist, nach hinten geschoben. So entwickelt sich allmählich ein gemeinsames Verständnis zwischen Fachleuten und „IT-lern“, worauf es wirklich ankommt.

Zusammengefasst schafft ein gemeinsames Vorgehen von (firmeninternen) Kunden beziehungsweise Anwendern sowie Lieferanten bei der IT-Spezifikation wechselseitiges Vertrauen. Es legt auch die Grundlage dafür, dass das System wirklich den Bedürfnissen der Organisation entspricht. Es erspart zudem viel Zeit und Arbeit, wenn beim Spezifieren statt auf ein detailliertes Ausarbeiten im Vorfeld auf eine intensive Kommunikation im Verlauf des Prozesses gesetzt wird. Durch regelmäßige Tests erhält man ein frühzeitiges Feedback zu eigenen Spezifikation. Und mit einer gemeinsamen Priorisierung der funktionalen Einheiten sowie der erforderlichen Änderungen wird mit der Zeit ein gemeinsames Verständnis dafür geschaffen, was wirklich wichtig ist.