Das magische Dreieck im ProjektmanagementAnforderungsanalyse im Projektmanagement

Ob Projekte “laufen wie geschmiert” oder sich “ziehen wie Kaugummi”, ist davon abhängig, wie genau die Kundenanforderungen erhoben und umgesetzt werden. In diesem Artikel wollen wir unsere Erfahrungen aus der Praxis teilen und aufzeigen, wo die Herausforderungen bei der Aufnahme der Kundenanforderungen liegen und wie dieser Prozess in den Projektablauf integriert werden kann.

Die Aufnahme der Kundenwünsche, die Anforderungsanalyse und -erhebung, wird im Arbeitsalltag oft stiefmütterlich behandelt. Denn das alles kostet bereits vor der Auftragserteilung meist Zeit – und Zeit ist Geld. Das rächt sich dann aber meist in der Umsetzungsphase und auch vermeintlich „leichte” Projekte können ungeahnte Ausmaße annehmen. In diesem Artikel wollen wir deshalb einen genaueren Blick auf diesen Aspekt der Projektimplementierung werfen.

DAS „MAGISCHE DREIECK”

Das magische Dreieck ist im theoretischen Projektmanagement weit verbreitet. Nur, wenn die Aspekte „Kosten”, „Zeit” und „Qualität” ein gleichseitiges Dreieck bilden, ist die Projektumsetzung ausgewogen. Wir plädieren dafür, den Begriff der Qualität durch den Begriff des „Scopes”, also des Umfangs, zu ersetzen. Denn der Umfang der Leistungserbringung ist viel klarer definierbar als die Qualität der Leistungserbringung. Damit kann der Scope auch viel effektiver an die Aspekte der Kosten und der Zeit gekoppelt werden, wobei die Qualität dann einen Aspekt des Scopes darstellt.

DEN KUNDENWÜNSCHEN AUF DER SPUR

Die daraus resultierende Frage ist: Wie kann der Scope am genauesten erhoben werden? Dabei fällt meist der Begriff der Anforderungsanalyse. Also zu analysieren, was der Kunde möchte und welche der Kundenwünsche im konkreten Auftrag umgesetzt werden sollen. Dieser Prozess, der oft als „Anforderungsanalyse” bezeichnet wird, besteht allerdings aus zwei separaten Schritten: Zuerst kommt die Anforderungserhebung und erst im zweiten Schritt folgt die eigentliche Analyse.

DIE ANFORDERUNGSERHEBUNG

Bei der Anforderungserhebung geht es darum, herauszufinden was der Kunde „wirklich will”. Die Anforderungen, die der Kunde an sein künftiges Produkt hat, sind in der Regel in der Sprache und mit dem Vokabular des Kunden formuliert. Es lohnt sich hier eine extra Abstimmungsschleife zu drehen, um sicherzustellen, dass Kunde und Auftragnehmer eine möglichst deckungsgleiche Vorstellung des späteren Produktes haben.

FUNKTIONALE UND NICHT-FUNKTIONALE ANFORDERUNGEN

Funktionale Anforderungen beschreiben dabei, WAS ein System leisten soll. Nicht-funktionale Anforderungen beschreiben, WIE ein System funktionieren soll.

Beide Aspekte sind im Kundengespräch dabei nicht immer klar voneinander zu trennen. Die Herausforderung für den Auftragnehmer ist es, diese Aspekte zu trennen – gegebenenfalls auch erst nach dem Gespräch mit dem Kunden. Denn für den Kunden sind beide Aspekte oft „ein und dasselbe”. Für die Definition des Scopes ist die Trennung aber immens wichtig: Die funktionalen Anforderungen, also das WAS, müssen den Kern der Anforderungserhebung bilden. Herrscht darüber zwischen Kunde und Auftragnehmer keine Einigkeit, kann das Projekt nicht erfolgreich umgesetzt werden.

PRAXISBEISPIELE

Nehmen wir als Beispiel einen Gastronomen, der ein Reservierungssystem benötigt. Dieser beschreibt die funktionale Anforderung als: “Das System soll anzeigen, wie viele freie Plätze im Restaurant noch verfügbar sind”. Diese Formulierung birgt ein hohes Risiko für Missverständnisse: Bezieht sich die Anforderung rein auf freie Plätze, also wie viele potentielle Gäste das Restaurant aufnehmen kann? Oder muss die Verteilung der Plätze auf die Tische mitberücksichtigt werden?

Ein anderes Beispiel: Für einen Kunden soll eine Suchabfrage aus einer Datenbank realisiert werden. Die funktionale Anforderung ist erfasst und so geklärt, dass Kunde und Auftragnehmer ein gemeinsames Verständnis teilen. Eine nicht-funktionale Anforderung ist die spätere Darstellung der Suchergebnisse. Zum Beispiel, ob die Suchergebnisse paginiert oder nicht-paginiert dargestellt werden sollen, oder wie viele Suchergebnisse überhaupt angezeigt werden sollen. Aber auch, auf welche Zielgruppe der Suchdienst abzielt und in welcher Form die Suchergebnisse dargestellt werden sollen (sollen z. B. nur der Titel oder auch weitere Details angezeigt werden?).

Die beiden Beispiele zeigen, dass die funktionalen Anforderungen zwar den Kern des Scopes bilden, aber die nicht-funktionalen Aspekte trotzdem nicht vernachlässigt werden dürfen und ebenso gewissenhaft erhoben werden müssen. Denn, auch wenn in einem Projekt alle funktionalen Anforderungen abgebildet werden, ist es möglich, dass das Ergebnis trotzdem nicht dem entspricht, was der Kunde sich vorstellt, da die nicht-funktionalen Anforderungen nicht ausreichend abgeklärt wurden.

ANFORDERUNGSERHEBUNG = DER DIENSTLEISTER ALS DETEKTIV

Der Fokus der Anforderungserhebung sollte darauf liegen, alle möglichen Eventualitäten in den Kundenanforderungen aufzudecken. Dabei kann der Softwaredienstleister sich als Detektiv verstehen, um den Fokus nicht aus den Augen zu verlieren und sich folgende zwei Fragen stellen:

Um im Bild eines ermittelnden Kommissars zu bleiben, dient die Anforderungserhebung also dazu, die „wahren Motive” des Kunden zu erkennen.

ANFORDERUNGSANALYSE ALS ZWEITER SCHRITT

Die eigentliche Analyse der Anforderungen erfolgt erst nach der Anforderungserhebung. Nachdem die Kundenanforderungen aufgenommen wurden, muss – im besten Falle gemeinsam mit dem Kunden – geprüft werden, ob diese überhaupt umsetzbar sind.

Hier gilt es zu klären, ob die notwendigen technischen Voraussetzungen gegeben sind, um die Anforderungen umzusetzen. Außerdem muss geklärt werden, ob Anforderungen im vorgegebenen Zeit- und Kostenrahmen realisierbar sind.

Ist das nicht der Fall, muss geprüft werden, ob es sinnvoll ist, in einer ersten Umsetzungsphase nur einen Teil der Anforderungen umzusetzen. Ist das möglich, ist sowohl aus Kunden- als auch aus Auftragnehmersicht eine Anforderungspriorisierung hilfreich: Es gilt zu klären, welche Elemente für den Kunden am wichtigsten sind, und ob diese auch realisierbar sind.

ABGLEICH MIT DER REALITÄT

Was in Büchern zum erfolgreichen Projektmanagement oft fehlt, ist ein Abgleich mit der Realität. In einer idealtypischen Welt haben sowohl Kunde als auch Auftragnehmer genügend Zeit und Muße, die Anforderungen zu erheben und die Anforderungen gemeinsam zu analysieren und zu priorisieren, damit der Auftragnehmer im Anschluss daran ein gut kalkuliertes Angebot erstellen kann.

Als Auftragnehmer haben wir aber die Erfahrung gemacht, dass dies in der Realität so oft nicht abzubilden ist. In anderen Worten: Zeit ist Geld und Geld muss zuerst einmal verdient werden. Der Kunde ist darauf angewiesen, so schnell wie möglich ein Angebot zu erhalten, das er beauftragen kann, damit das gewünschte Produkt so schnell wie möglich umgesetzt wird. Der Auftragnehmer ist ebenfalls an einer schnellen Auftragserteilung interessiert, um Planungssicherheit zu haben. Eine umfassende Anforderungserhebung und -analyse findet manchmal sogar erst nach der Beauftragung statt.

VIER ERKENNTNISSE FÜR EINE ERFOLGREICHE ANFORDERUNGSPHASE

Im Folgenden stellen wir vier Erkenntnisse aus unserer Erfahrung dar, die zeigen, wie man die Anforderungserhebung und -analyse in Auftragskalkulationen abbilden und die Risiken für Kunde und Auftragnehmer verringern kann.

ZEITTRACKING SCHON VOR PROJEKTBEGINN

Als Auftragnehmer sollte man kontinuierlich monitoren, wie viel Zeit für die Auftragsklärung benötigt wird. Nur dann kann man Erfahrungswerte sammeln, und weiß später, wie aufwändig sich der Prozess gestaltet, und kann die Kosten besser einpreisen.

KONZEPTIONSPHASEN EINPLANEN

Im Angebot sollte eine zusätzliche Konzeptionsphase dargestellt werden – je nach Umfang von einigen Stunden bis hin zu ganzen Tagen. Darin sollte dann nicht nur die notwendige Zeit für die Softwarearchitektur, sondern auch Zeit für grundsätzliche Absprachen mit dem Kunden berücksichtigt werden. Vor allem, wenn eine Ausschreibung nicht klar formuliert ist, sollte diese Angebotsposition besonders berücksichtigt werden.

GRENZEN DEFINIEREN

Das Angebot sollte klare Grenzen definieren. Vor allem für Kunden ist oft nicht ganz eindeutig, was sich hinter einzelnen Angebotspunkten versteckt. Ggf. ist es sinnvoll, das eigentliche Angebot um ein Dokument zu ergänzen, das die einzelnen Punkte genauer erläutert.

PROJEKTMANAGEMENTKOSTEN BESSER AUFTEILEN

Projektmanagement wird oft als “unproduktiver” Overhead gesehen. Je höher die Projektmanagementkosten, desto schwieriger wird es, die Notwendigkeit dieser Position dem Kunden gegenüber zu erläutern.

Wir schlagen deshalb vor, in der Kalkulation die einzelnen technischen Angebotspositionen um einen gewissen Anteil an PM-Zeit zu erhöhen. Das Angebot an den Kunden enthält dann trotzdem den finalen Zeit- und Kostenaufwand. Damit wird der extra ausgewiesene PM-Anteil im Angebot nicht zu hoch. Der zusätzliche PM-Anteil kann für Absprachen mit dem Kunden genutzt werden und sollte im Projektcontrolling auch immer getrennt von der technischen Umsetzung gemonitort werden.

Eine fünfte Erkenntnis für die erfolgreiche Umsetzung von Projekten ist auch die Definition von Abnahmekriterien.

FAZIT: DER ANFORDERUNGSPROZESS BEI BLUESHOE

Zu Beginn unserer Unternehmensgeschichte haben sich die Entwickler noch stark in den Anforderungsprozess eingebracht und sehr viel persönlich mit den Kunden kommuniziert. Manchmal wurde Anforderungen sogar „on the fly” erhoben und gleichzeitig umgesetzt. Aufgrund der steigenden Anzahl an Kunden und Projekt haben wir erkannt, dass dieses Vorgehen ab einer gewissen Größe nicht mehr möglich ist. Seither nimmt der Anforderungsprozess in unserem Projektmanagement eine zentrale Stelle ein und wird von unseren Projektmanagern durchgeführt.

Uns ist es dabei besonders wichtig, dass wir immer flexibel auf Änderungen in den Anforderungen reagieren können, die sich während der Projektimplementierung ergeben. Die konsequente Anforderungserhebung gibt aber nicht nur uns, sondern vor allem auch unseren Kunden eine wesentlich höhere Planungssicherheit hinsichtlich des Umsetzungszeitraums eines Projektes.