IT-Spezifikation: Weniger schreiben, mehr kommunizieren

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. Hier einige Tipps, die Ihnen beim Realisieren eines solchen Ansatzes beim Spezifizieren geplanter IT-Systeme helfen.

Schaffen Sie eine Vertrauensbasis

• 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.

Sponsored Post

Unterschätzte Risiken

Beliebte Gewerbeversicherungen

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 beiden Seiten lernen die Bedürfnisse und Denkweise der jeweils anderen kennen. Das ist eine Grundvoraussetzung für Vertrauen.

Planen Sie deshalb nicht zu groß. Fangen Sie mit einer relativ kleinen Funktionalität an. 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. Versuchen Sie den Funktionsumfang so klein zu halten, dass zwischen dem Beginn der Spezifikation und der fertigen Implementierung maximal vier bis acht Wochen vergehen.

Gewinnen Sie den Überblick – gemeinsam

„It’s all about Scope.” 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. Oder weil dem Anwender erst im Verlauf des Entwicklungsprozesses (oder bei den Funktionalitätstests) klar wird, was zum Beispiel aufgrund der Arbeitsprozesse wirklich wichtig ist. 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.

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 (zum Beispiel Excel-Sheets)? 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 sollte 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“

Weniger ist oft mehr

„Spezifizieren Sie so wenig wie möglich“ – 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, um sich abzusichern und sicherzugehen, dass ja nichts vergessen wird. 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 Sie 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:

• 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 (wie zum Beispiel die Wertebereiche und die Abnahmekriterien) in Testfällen festgeschrieben.

So erhalten Sie eine übersichtliche Spezifikation mit einer Reihe zusätzlicher Arbeitsergebnisse. Warum sich also die Arbeit doppelt machen?

Lassen Sie neue Erkenntnisse einfließen

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. Streben Sie zudem eine kontinuierliche Integration der entwickelten Komponenten an, damit Sie regelmäßig testen können. Denn diese Tests liefern wichtige Erkenntnisse, die wiederum in die Spezifikation einfließen können. Und noch ein Hinweis: Deckeln Sie die Budgets. 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 bei ein übergeordneter Entscheider sagt „Jetzt reichts“ und das Projekt stoppt.

Jedes Projekt hat eine Lernkurve. Diese sollten Sie bewusst durchlaufen. Das heißt: Fangen Sie mit funktionalen Einheiten an, die eine möglichst ähnliche Größe haben. Mit den ersten Ergebnissen erhalten Sie tatsächliche Aufwandszahlen. Mit diesen können Sie das Backlog, also den Bestand der noch ausstehenden funktionalen Einheiten, abzuschätzen – und somit zu einer realistischen (Budget-)Planung gelangen.

Wenn Sie einen Änderungsbedarf erkennen, fügen Sie die Änderung in das Backlog ein und bewerten Sie 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. Und Sie zeigen, dass Sie bereit sind, auf Unwesentliches zu verzichten, wenn die wichtigen Funktionalitäten zeitnah umgesetzt werden.

Fazit

Ein gemeinsames Vorgehen von (firmeninternen) Kunden beziehungsweise Anwendern sowie Lieferanten bei der IT-Spezifikation schafft 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 Sie beim Spezifieren statt auf ein detailliertes Ausarbeiten im Vorfeld auf eine intensive Kommunikation im Verlauf des Prozesses setzen. Durch regelmäßige Tests erhalten Sie ein frühzeitiges Feedback zu Ihrer Spezifikation. Und mit einer gemeinsamen Priorisierung der funktionalen Einheiten sowie der erforderlichen Änderungen schaffen Sie mit der Zeit ein gemeinsames Verständnis dafür, was wirklich wichtig ist.