Die IT-Spezifikation: Eine mühsame Pflicht, die man möglichst schnell hinter sich bringen will oder ein Prozess, an dessen Ende ein IT-System steht, dass allen Beteiligten wirklich nützt? Je nach Betrachtungsweise ist die IT-Spezifikation nur ein lebloses Stück Papier, um das man sich trefflich streiten kann oder eine dynamische, lebhafte Interaktion zwischen den unterschiedlichsten Beteiligten, bei der alle das Ziel verfolgen, etwas Gemeinsames reifen zu lassen. In etwa so wie einen guten Wein. Sie können sich sicher denken, dass ich für die zweite Sichtweise plädiere. Dazu habe ich Ihnen einige Tipps zusammengestellt, die mir bei der Spezifikation stets gute Dienste erwiesen haben.
Schaffen Sie eine Vertrauensbasis
IT-Spezifikation hat etwas mit Vertrauen zu tun. Vertrauen in die Lieferanten, dass sie verstehen, was die Fachabteilung wirklich braucht und Vertrauen in die Fachabteilung, dass sie nicht mehr fordert, als sie bereit ist, zu investieren. Wenn dieses Vertrauen nicht da ist, manifestiert sich das regelmäßig in detailliertesten Lastenheften mit tausenden von Anforderungen, deren Nutzen höchst fraglich ist. Oft kennen am Anfang die Fachleute die “IT-ler” nicht und umgekehrt. Man muss sich erst gegenseitig finden und eine gemeinsame Sprache entwickeln, um Missverständnisse zu vermeiden.
Mein Grundprinzip, um Vertrauen zu schaffen: Klein anfangen und rasche Erfolge erzielen. Planen Sie nicht zu groß. Fangen Sie mit einer relativ kleinen Funktionalität an. Das sollte jedoch keine Spielwiese sein, sondern eine Funktionalität, die bereits zu einer Verbesserung der Arbeitsprozesse beiträgt. Beispiele: Automatische Datenübernahme zwischen zwei Systemen oder die Möglichkeit für Kunden, Daten direkt in Ihre Systeme einzugeben oder abzufragen. Versuchen Sie, den Funktionumfang so klein zu halten, dass zwischen dem Beginn der Spezifikation und der fertigen Implementierung ein Zeitraum von maximal 4-8 Wochen liegt.
Den Vorteil in einem solchen “langsamen” Start sehe ich darin, dass sich die Arbeitsprozesse zwischen Fachabteilung und IT-Lieferant einspielen können. Beide Seiten lernen die Bedürfnisse und die Denkweise der jeweils anderen Seite kennen. Sie erhalten erste Anhaltspunkte für die Abschätzung.
Gewinnen Sie den Überblick. Gemeinsam
“It’s all about Scope”. In IT-Projekten dreht sich alles darum, was drin sein soll, und – viel wichtiger noch – was nicht. Was nützt es den Beteiligten, wenn sie ein sensationell modernes IT-System erhalten, wenn darin wichtige Funktionalität nicht enthalten ist. Auch hier gilt die Regel: Keep it simple! Der Scope eines IT-Projekts wird sich im Laufe der Zeit verändern. Mit sehr hoher Wahrscheinlichkeit werden Arbeitsprozesse am Ende des Projekts anders aussehen, als zu Beginn des Projekts. Ebenso werden sich die Bedürfnisse der betroffenen Anwender verändern. Es macht also keinen Sinn, ein hundertseitiges Scope-Dokument zu schreiben, das keiner mehr aktualisieren will.
Aus meiner Warte reicht für eine initiale Scope-Beschreibung ein Workshop von 2 Tagen. Darin sollten die folgenden Fragen geklärt werden:
- Wer sind die relevanten Mitspieler? Wer erwartet sich einen Nutzen aus dem IT-System? Wer wird es bedienen?
- Was sind die Ziele dieser Mitspieler? Welchen Nutzen erwarten sich die Mitspieler aus dem IT-System? Welche Erwartungen und Bedürfnisse haben sie jeweils? In welchen Bereichen soll das IT-System Arbeit erleichtern? Welchen geschäftlichen Nutzen erwarten sich die Beteiligten?
- Welche Arbeitsprozesse sind betroffen? Mit welchen Aufgaben beschäftigen sich die Mitspieler? Welche Teile der Wertschöpfungskette sind betroffen? Wo gibt es eine Interaktion zwischen unterschiedlichen Abteilungen? Welche Prozessvarianten gibt es?
- Welche IT-Systeme gibt es schon heute? Welche IT-Systeme sollen durch das neue System abgelöst werden? Welche “unter-Tisch-Software” wird eingesetzt? (Excel-Sheets!) Welche Systeme sollten angebunden werden?
- Welche technologischen Vorgaben sind einzuhalten? Welche unternehmensweiten Standards sind einzuhalten? Welche Guidelines? Welche Middleware? 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 (siehe oben) verändern?
- Wer sind die relevanten Entscheider? Wer bezahlt für das IT-Projekt? Wer muss im Lenkungskreis vertreten sein? Wer sollte über das Projekt und seine Zwischenergebnisse informiert sein? Wer sind die Multiplikatoren? Wer entscheidet am Ende über Erfolg oder Nicht-Erfolg?
- Was sind die Rahmenbedingungen? Wie lange ist Zeit? Wieviel Budget steht zur Verfügung? Wie wird das Budget akquiriert?
- Was ist der Business-Case? Wie rechnet sich das Projekt? Wo sind Einsparungen zu erwarten? Wie lassen sich die Kosten rechtfertigen?
Ein solcher Projekt-Scope Workshop sollte möglichst vielfältig besetzt sein:
- Vertreter aus den betroffenen Fachabteilungen
- (IT-)Techniker
- IT-Administratoren, Support-Mitarbeiter
- Entscheider
- Fürsprecher und Gegner
- Alte Hasen und junge Hunde
Spezifizieren Sie so wenig wie möglich
Das mag provokativ klingen, ist jedoch eine der wichtigsten Erfahrungen, die ich in den vergangenen Jahren gemacht habe. Ein natürlicher Vorgang ist, alles bis ins letzte Detail zu beschreiben, um sicherzugehen, dass man auch ja nichts vergessen hat. Dabei wird allerdings außer Acht gelassen, dass kaum jemand in der Lage ist, die Komplexität eines IT-Systems in dieser Tiefe gedanklich zu verarbeiten. Es kommt zwangsläufig zu Änderungen. Je höher der Zeitdruck, desto eher wird “vergessen”, die Spezifikation an die aktuelle Entwicklung anzupassen. Mit dem Ergebnis, dass man am Ende des Projekts eine detaillierte Spezifikation hat und ein IT-System, dass sich oft ganz anders verhält, als spezifiziert.
Wenn immer es möglich ist, sollte sich die Spezifikation auf die Anwendung des IT-Systems beschränken: Wie soll ein Anwender (oder ein extenes 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 GUI-Designern werden passende Bildschirmdialoge und Druckausgaben entworfen;
- In der Interaktion mit Datenmodellieren werden die Geschäftsobjekte modelliert;
- In der Interaktion mit den Schnittstellenverantwortlichen werden fachlich relevante IT-Schnittstellen definiert;
- In der Interaktion mit den Systemtestern werden die fachlichen Details (wie z.B. Wertebereiche) in Testfällen festgeschrieben.
Sie erhalten also eine übersichtliche Spezifikation und eine Reihe zusätzlicher Arbeitsergebnisse, die die Spezifikation um Details anreichern. Warum sich diese Arbeit doppelt machen?
Beteiligen Sie sich am Test
Der Systemtest ist keine alleinige Aufgabe des IT-Lieferanten. Fachexperte wissen am Besten, worauf der Schwerpunkt beim Systemtest gelegt werden sollte. Deshalb sollten sie sich an der Ausarbeitung der System-Testfälle beteiligen. Sie sollten zudem eine kontinuierliche Integration der entwickelten Komponenten anstreben, damit Sie regelmäßig testen können. Diese Tests liefern wesentliche Erkenntnisse, die Sie wiederum in die Spezifikation einfließen lassen können.
Ändern Sie und priorisieren Sie gemeinsam
Ich bin ein Freund von gedeckelten Budgets. Sie geben Investitionssicherheit und setzen Projekten wichtige Limits. Ohne feststehende Budgets kann es passieren, dass mehr und mehr investiert wird, ohne dass ein wirklicher Mehrwert herauskommt. Oft genug laufen Projekte finanziell aus dem Ruder und werden dann irgendwann durch einen Unbeteiligten gestoppt.
Jedes Projekt hat eine Lernkurve. Diese sollten Sie bewusst durchlaufen. Das heißt: Sie fangen mit funktionalen Einheiten an, die eine möglichst ähnliche Größe haben. Mit den ersten Ergebnissen erhalten Sie tatsächliche Aufwandszahlen. Diese können Sie verwenden, um den Bestand (das Backlog) der noch ausstehenden funktionalen Einheiten abzuschätzen.
Sehen Sie Änderungsbedarf, fügen Sie die Änderung in das Backlog ein und bewerten Sie sie gemeinsam. Die wichtigsten funktionalen Einheiten werden vorgezogen. Alles was eher “nice to have” ist, wird nach hinten geschoben. Damit entwickeln Sie ein gemeinsames Verständnis zwischen Fachleuten und “IT-lern”, worauf es wirklich ankommt. Und Sie zeigen, dass Sie bereit sind, auf unwesentliches zu verzichten, wenn Sie dafür eine wichtigere Funktionalität zeitnah umgesetzt bekommen.
Fazit
Mit einer gemeinschaftlichen Vorgehensweise bei der IT-Spezifikation können Sie gegenseitiges Vertrauen aufbauen. Damit schaffen Sie die Grundlage, dass Sie ein System erhalten, das Ihre Bedürfnisse wirklich erfüllt. Sie ersparen sich Arbeit durch vermeidbare Spezifikationstiefe, wenn Sie statt auf detaillierte Dokumente auf Kommunikation setzen. Wenn Sie einen regelmäßigen Test anstreben, erhalten Sie frühzeitiges Feedback zu Ihrer Spezifikation. Mit einer gemeinsamen Priorisierung von funktionalen Einheiten und Änderungen schaffen Sie nach und nach ein gemeinsames Verständnis, was wirklich für Sie wichtig ist.
Ich wünsche viel Erfolg und freue mich auf Ihr Feedback!
Dein Kommentar