In vielen Unternehmen wird die IT-Spezifikation als mühsame Pflicht betrachtet. Denn die alten Projekthasen wissen: Wenn man erst einmal mit dem Entwickeln des neuen Systems beginnt, kommt ohnehin vieles anders als geplant. Entsprechend bürokratisch wird diese Aufgabe oft erledigt, statt sie als dynamischen sowie interaktiven Prozess zu verstehen, an dessen Ende das von allen Beteiligten gewünschte oder benötigte IT-System entsteht.
Vertrauen aufbauen
IT-Spezifikation hat etwas mit Vertrauen zu tun – und zwar mit Vertrauen in die Lieferanten und dass diese verstehen, was die Fachabteilung wirklich braucht, sowie in die Fachabteilung und dass sie nicht mehr fordert, als sie bereit ist, zu investieren. Fehlt dieses Vertrauen, tendieren alle Beteiligten zum Sich-Absichern. Das manifestiert sich in Lastenheften mit Tausenden von Anforderungen, deren Nutzen fraglich ist.
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 spielen sich ein. Und beide Seiten lernen die Bedürfnisse und Denkweise der jeweils anderen kennen. Das ist eine Voraussetzung für Vertrauen.
Man sollte also nicht zu gross planen und mit einer relativ kleinen Funktionalität beginnen. Diese sollte jedoch keine Spielwiese sein, sondern eine Funktionalität, die bereits erkennbar zu einer Verbesserung der Arbeitsprozesse beiträgt. Dabei gilt es, den Funktionsumfang möglichst so klein zu halten, dass zwischen dem Beginn der Spezifikation und der fertigen Implementierung maximal ein bis zwei Monate vergehen.
Wichtigste Funktionalitäten bestimmen
In IT-Projekten dreht sich fast alles um die Frage: Was sollte das System können oder eben nicht? Denn was nützt den Anwendern 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 was 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 dabei bedenkt: Der Scope, also Inhalt und Umfang von komplexen IT-Projekten, verändert sich in deren Verlauf stets – zum Beispiel weil sich Rahmenbedingungen wandeln. Oder weil dem Anwender erst im Verlauf des Entwicklungsprozesses oder bei den Funktionalitätstests klar wird, was aufgrund der Arbeitsprozesse wirklich wichtig ist. Deshalb macht es wenig Sinn, vorab voluminöse Spezifikationsdokumente zu schreiben, die sich in allen Details verlieren. Zielführender ist es, das Dokument im Verlauf des Projekts immer weiter zu konkretisieren und fortlaufend zu aktualisieren.
Gemeinsamen Überblick verschaffen
Für eine initiale Scope-Beschreibung reicht in der Regel ein Workshop von zwei Tagen. In ihm sollten folgende Fragen geklärt werden:
- Wer sind die Stakeholder? Wer erwartet sich einen Nutzen von dem IT-System? Wer wird es bedienen?
- Was sind die Ziele dieser Stakeholder? Welchen Nutzen erwarten sie von dem System? Welche Erwartungen und Bedürfnisse haben sie?
- Welche Arbeitsprozesse sind betroffen? Welche Teile der Wertschöpfungskette sind tangiert? 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 Systeme sollten angebunden werden?
- Welche technologischen Vorgaben sind einzuhalten? Welche unternehmensweiten Standards müssen beachtet werden? Welche Guidelines existieren? Welche Softwareschnittstellen 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 hat man? 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. So sollten unter anderem Vertreter der betroffenen Fachabteilungen, (IT-)Techniker und IT-Administratoren, Support-Mitarbeiter und Entscheider, Fürsprecher und Gegner sowie alte Hasen und junge Hunde anwesend sein.
Im Gespräch bleiben
Eine wichtige Projekterfahrung ist, so wenig wie möglich zu spezifizieren. Gerade bei strategisch wichtigen Projekten ist die Versuchung oft gross, alles bis ins letzte Detail zu beschreiben, um sich abzusichern und sicherzugehen, dass nichts vergessen wird. Dabei kann vor Beginn grosser IT-Projekte in der Organisation meist niemand die Komplexität eines geplanten IT-Systems in seiner ganzen Tiefe gedanklich erfassen. Also kommt es zwangsläufig zu Änderungen. Und damit meist zu Zeitdruck. Je höher er ist, umso 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, sollte man die Spezifikation auf die Anwendung des IT-Systems beschränken. 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: So werden in der Interaktion mit den User-Interface-Designern die passenden Bildschirmdialoge und Druckausgaben entworfen, zusammen mit den Datenbank-Entwicklern werden die Geschäftsobjekte modelliert und in der Interaktion mit den Architekturverantwortlichen werden die fachlich relevanten IT-Schnittstellen definiert. Und schliesslich werden zusammen mit den Systemtestern die fachlichen Details – wie zum Beispiel die Wertebereiche und die Abnahmekriterien – in Testfällen festgeschrieben. So erhält man eine übersichtliche Spezifikation mit einer Reihe zusätzlicher Arbeitsergebnisse. Warum sich also die doppelte Arbeit machen?
Gemeinsam im Projekt lernen
Der Systemtest ist keine alleinige Aufgabe des IT-Lieferanten. Die Fachexperten wissen am Besten, worauf beim Testen besonders geachtet werden sollte. Deshalb sollten sie sich an der Ausarbeitung der System-Testfälle beteiligen. Zudem sollte eine kontinuierliche Inte- gration der entwickelten Komponenten angestrebt werden, damit man regelmässig testen kann. Denn diese Tests liefern wichtige Erkenntnisse, die wiederum in die Spezifikation einfliessen können. Und noch ein Hinweis: Man muss das Budget deckeln. Gedeckelte Budgets geben Investitionssicherheit und setzen Projekten wichtige Limits. Ohne feststehende Budgets wird schnell mehr und mehr investiert, ohne dass ein wirklicher Mehrwert entsteht. Und zwar oft so lange, bis ein übergeordneter Entscheider sagt «Jetzt reicht’s» und das Projekt stoppt.
Jedes Projekt hat eine Lernkurve. Diese sollte man bewusst durchlaufen. Das heisst: Man beginnt mit funktionalen Einheiten, die eine ähnliche Grösse haben. Mit den ersten Ergebnissen erhält man tatsächliche Aufwandszahlen. Mit diesen kann man das Backlog, also den Bestand der noch ausstehenden funktionalen Einheiten, abschätzen – und so zu einer realistischen (Budget-)Planung gelangen.
Wenn man einen Änderungsbedarf erkennt, dann 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.
Der Autor
Dr. Georg Kraus ist geschäftsführender Gesellschafter der Unternehmensberatung Dr. Kraus & Partner, Bruchsal, für die über 100 Berater, Trainer und Projektmanager arbeiten. Der diplomierte Wirtschaftsingenieur promovierte an der TH Karlsruhe zum Thema Projektmanagement. Er ist unter anderem Autor des «Change Management Handbuch» und zahlreicher Projektmanagement-Bücher. Seit 1994 ist er Lehrbeauftragter an der Universität Karlsruhe, der IAE in Aix-en-Provence und der technischen Universität Clausthal.
www.kraus-und-partner.de
Dr. Georg Kraus (Quelle: kraus und partner)
