Risikomanagement - Projektrisiken der Anforderungsanalyse

Zusammenfassung
Allgemeines
Risiken der Anforderungsanalyse im Verantwortungsbereich des Analytikers
Risiken der Anforderungsanalyse im Verantwortungsbereich des Managements
Risiken der Anforderungsanalyse im Verantwortungsbereich des Auftraggebers
Risiken der Anforderungsanalyse im Verantwortungsbereich von Zulieferern

Zusammenfassung

Auf dieser Seite werden die wesentlichen Risiken dargestellt, die innerhalb eines IT-Projekts im Umfeld der Anforderungsanalyse auftreten können. Dabei wird nicht nur auf die unmittelbar vom Business Analysten zu verantwortenden Risiken eingegangen, sondern auch auf Risiken im weiteren Projektumfeld, auf die der Analytiker möglicherweise keinen Einfluss hat. Die Menge potentieller Risiken führte zu einer lediglich Checklisten-artigen Auflistung. Allerdings sind die einzelnen Punkte fast immer selbsterklärend und in der Praxis reicht es im Rahmen der üblichen project survival tests aus, die Checklisten durchzuarbeiten. Bitte fragen Sie im Einzelfall nach, wenn etwas nicht ganz klar ist (Kontakt).

Allgemeines

Projektrisiken lauern an allen Ecken und Enden eines IT-Projekts. Folgende Klassifizierung lässt sich ungefähr vornehmen:

Anforderungsanalyse
Erstplanung (erste Version eines Plans für ein neues Projekt)
Organisation und Management
Entwicklungsumgebung (räumlich, technisch)
Design und Implementierung
Auftraggeber und Fachanwender
Zulieferer und externe Unternehmen
Produkt
äußere Umstände (sich ändernde Standards, Regelungen)
Personal
Formalien und Bürokratie

[Fowler2] unterscheidet etwas pragmatischer und weniger differenzierter in

Anforderungsrisiken
technologische Risiken
Risiken bei den Fähigkeiten
politsche Risiken

Innerhalb eines IT-Projekts sind Fehler in der Projektplanung, vor allem eine unzureichende Erstplanung, die teuersten Risiken. An zweiter Stelle folgen Risiken der Anforderungsanalyse. Außerhalb des eigentlichen IT-Projekts kommen jedoch Risiken durch Organisation und Management sowie Auftraggeber und Fachanwender noch vor den Projektplanungsrisiken. Mangelhafte Unterstützung des Projekts, Desinteresse, Entscheidungslosigkeit und Einmischungen in die technischen Entwicklungsphasen sind zusammen mit politischen Entscheidungen, die häufig durch ebenso teure wie rhetorisch talentierte Berater beeinflusst werden, Risiken, auf die das Entwicklerteam keinen Einfluss nehmen kann. Ist gar der Analytiker oder Projektmanager inkompetent, so ist ein Projekt-Misserfolg so gut wie sicher.

Hier werden nur die Risiken dargestellt, die im näheren und ferneren Umfeld der Anforderungsanalyse entstehen können.

Risiken der Anforderungsanalyse im Verantwortungsbereich des Analytikers

Der Business Analyst führt die Anforderungsanalyse durch und schreibt das Anforderungsdokument. Er ist die erste Schlüsselfigur auf dem Weg von der Produktidee zum abgenommenen fertigen Produkt. Ein Analytiker kann folgende Fehler machen, bzw. von der Person des Analytikers gehen folgende Risiken aus:

Der Endanwender wird nicht befragt.
Der Analytiker akzeptiert ein Verbot, mit dem Kunden nicht frei zu kommunizieren.
Die Anforderungen werden nur unzureichend spezifiziert und bleiben bis in die Entwicklungsphase hinein interpretierbar.
Die Anforderungen sind nicht so formuliert, dass sie testbar sind.
Der Analytiker nimmt nach Ende der Spezifikationsphases weitere Informationen in das Anforderungsdokument auf, ohne das Change Request-Verfahren zu beachten.
Der Analytiker animiert den Auftraggeber zu nicht notwendiger Funktionalität.
Der Analytiker befasst sich nicht ausreichend mit Interfaces zu Fremdsystemen.
Es bestehen Abhängigkeiten von einer Technologie oder einem Produkt, das selbst noch in Entwicklung ist, und der Analytiker beachtet die Produktentwicklung nicht.
Der Analytiker greift dem technischen Design vor.
Der Analytiker berücksichtigt nicht die Bedürfnisse des IT-Teams bzw. die Notwendingkeiten eines Software-Entwicklungs-Prozesses
Der Analytiker berichtet nicht ausreichend über die Entwicklung der Anforderungsanalyse.
Der Analytiker ist überlastet, ein normaler Arbeitstag reicht für das Projekt nicht aus.
Der Analytiker hat noch andere Aufgaben und steht nicht ausreichend dem Projekt zur Verfügung.
Der Analytiker ist desinteressiert.
Der Analytiker sabotiert das Projekt.

Risiken der Anforderungsanalyse im Verantwortungsbereich des Managements

Personal - Auswahl des Business Analysten

Die Kompetenzen des ausgewählten Analytikers passen nicht zur Domäne (domain, Problembereich). Abhängig von der betrieblichen Situation bestehen folgende Kompetenzrisiken:

der Analytiker bringt für die Domäne nicht genügend Sachkompetenz mit: der Analyseprozess zieht sich in die Länge, der Analytiker erkennt triviale Probleme nicht
der Analytiker bringt für die Domäne zu viel Sachkompetenz mit, insbesondere unternehmensspezifisches Wissen: der Analytiker ist wie die befragten Fachanwender betriebsblind, neue Ideen und Wege werden nicht erschlossen, Optimierungen finden nicht statt, die Analyse ist nur unvollständig, der Analytiker entscheidet eigenmächtig ohne ausreichende Interaktion mit den Fachanwendern

Das Management bzw. die Personen, die den Business Analysten auswählen, haben nicht die Kompetenz zu einer sinnvollen Personalauswahl, sie können die Fähigkeiten des Analytikers nicht beurteilen.

Beispiele aus der Praxis

Ein Personalvermittler lehnte die Weiterleitung des Lebenslaufs eines Bewerbers an den Auftraggeber mit der Begründung ab, dass man einen Business Analysten für ein CRM-System (customer relationship management) suchen würde. Der Bewerber hatte im Lebenslauf die Begriffe "CRM consultant" und "solutions analyst" benutzt. Aus dem Lebenslauf war sehr klar erkennbar, dass er zu den besten CRM-Spezialisten Großbritanniens gehörte.

Eine Stellenbeschreibung enthielt die Forderung, dass der Kandidat für einen BA-Vertrag für eine Bank sich im Bereich Options und Futures gut auskennen muss, Detailwissen über Derivate aber nicht unbedingt notwendig wäre. (Falls Sie sich mit Wertpapieren nicht auskennen: Optionen und Futures sind Derivate)

In einer Stellenausschreibung waren für einen Business Analysten Kenntnisse in Oracle, MS SQL-Server und relationale Datenbanksysteme gefordert. Ein Bewerber stellte fest, dass sein Interviewpartner, der über seine Einstellung entscheiden sollte, nicht wusste, dass Oracle und MS SQL-Server relationale Datenbanksysteme waren.

Projektplanung

Projektplanungsfehler liegen ausschließlich in der Verantwortung des Projektmanagements. Die häufigsten Fehler bzw. Risiken im Umfeld der Anforderungsanalyse sind:

Für die Spezifikationsphase wird nicht genügend Zeit vorgesehen.
Wenn vorab Budget und Liefertermin feststeht, wird keine verbindliche Vereinbarung mit dem Kunden getroffen, dass Zeit- und Budgetpläne überarbeitet werden müssen, wenn die Spezifikationsphase länger als ca. ein Drittel der Gesamtprojektdauer dauert.
Wenn vorab Budget und Liefertermin feststeht, wird keine verbindliche Vereinbarung mit dem Kunden getroffen, dass nach einem Fünftel der Zeit die Spezifikationsphase unterbrochen wird und die vorhandene Spezifikation lediglich soweit vervollständigt wird, dass ein Produkt geschrieben werden kann, das (gerade noch) gut genug ist, um die Anforderungen des Kunden zu erfüllen. (Vgl. hierzu die Hinweise zu Projekt-Modellen in der Praxis im Kapitel über Kosten und Aufwände)
Dem Kunden wird nicht deutlich kommuniziert, dass erst nach Ende der Spezifikationsphase ein verbindlicher Kostenvoranschlag für die Entwicklung möglich ist.
Das Projektmanagement erlaubt dem Auftraggeber, nach Beginn der Entwicklungsphase weitere Anforderungen ohne ordentliches Change Request-Verfahren einzubringen.
Zeit, Budget, Ressourcen und Anforderungen werden vom Kunden oder vom gehobenen Management diktatorisch vorgegeben und stehen nicht in angemessenem Verhältnis zueinander, und der Projektmanager akzeptiert dies ohne Widerspruch.
Das Projektmanagement sieht nicht genügend Zeit und Ressourcen für den geforderten Leistungsumfang vor.
Vom Projektmanager wird nicht berücksichtigt, dass der Analytiker nicht im geplanten Umfang verfügbar ist.
Budget oder Ressourcen werden gekürzt oder das Lieferdatum wird vorverlegt, ohne dass das Projektmanagement dafür sorgt, dass die Anforderungen reduziert werden.

Sicher gehört Mut dazu, ein Projekt nicht anzunehmen bzw. seinen Abbruch zu empfehlen, wenn man selbst der Projektmanager ist. Dies ist aber für das Unternehmen auf jeden Fall der bessere Weg, als Geld in einem Projekt unverantwortlich zu versenken. Der Projektmanager muss dazu das mittlere und höhere Management offen und vollständig über den Sachverhalt informieren und auch willens sein, schlechte Nachrichten zu überbringen.

Beispiele aus der Praxis

In einem Projektmanagerkurs (nicht nur IT!) wurden von den zwölf Teilnehmern verschiedene Szenarien vorgestellt und diskutiert. Zwar war man sich bei bestimmten Szenarien immer wieder einig, dass es nicht zu einem erfolgreichen Projektende führen konnte, jedoch konnte sich bis auf einen Teilnehmer niemand dafür entscheiden, das Projekt abzubrechen oder abzulehnen. Dieser einzige Teilnehmer, der auch der einzige Freiberufler im Kurs war, begründete seine Haltung damit, dass er sich selbst recht rasch aus dem Geschäft katapultieren würde, wenn er Lieferzusagen geben würde, die er nicht einhalten könne. Er insistierte darauf, dass das mittlere und gehobene Management bzw. sein Auftraggeber objektiv über den gegebenen Sachverhalt zu informieren sei und dass dazu auch gehört, schlechte Nachrichten zu überbringen.

Im selben Kurs erklärte ein Dozent, dass er den Abbruch von Projekten empfohlen hatte, in die bereits zweistellige Millionensummen investiert worden waren. Bei den Projekten war abzusehen, dass das gelieferte Produkt nicht mehr die Marktbedürfnisse befriedigen würde. Dem federführenden Unternehmen wurde dadurch der zusätzliche Verlust eines größeren zweistelligen Millionenbetrags erspart.

Einflussnahme auf die Analysephase

Mit einem Business Analysten ist es wie mit einem Lotsen: So, wie ein Lotse ein Schiff in ihm bekannten gefährlichen Gewässern steuert, übernimmt der Business Analyst die Anforderungsanalyse und die Führung des Kunden zum Anforderungsdokument. Entreisst der Kapitän dem Lotsen das Steuer, so ist es ein Glücksspiel, ob er durch die gefährlichen Gewässer findet. Der Analytiker orientiert sich an den vor Projektbeginn vereinbarten Richtlinien, die i.d.R. durch Unternehmenskultur und Qualitätsmanager vorgegeben werden. Risiken für eine erfolgreiche Anforderungsanalyse entstehen in folgenden Fällen:

Das Projektmanagement ändert die Ansprüche an eine Anforderungsanalyse während der Analysephase.
Das Projektmanagement versucht ohne Rücksprache mit dem Kunden, Anforderungen zu ändern oder zu streichen oder zusätzliche Anforderungen aufzunehmen.
Das Projektmanagement verbietet dem Analytiker die freie Interaktion mit dem Kunden.

Unterstützung

Mangelhafte Unterstützung eines Projekts, sei es nun durch den eigenen Projektmanager, den Auftraggeber oder das obere Management, führt zu der absurden Situation, dass die ausführende Ebene ohne oder gar gegen die Führungsetage im Sinne des Unternehmens handeln soll. Projektrisiken für die Analysephase sind:

Dem Projekt fehlt generell die aktive Unterstützung durch das höhere Management.
Das höhere Management hat dem Fachbereich nicht klar genug kommuniziert, dass die Anforderungsanalyse aktiv unterstützt werden muss.
Ressourcen werden entzogen, Budget gekürzt oder Liefertermine vorverlegt, ohne den geforderten Leistungsumfang zu reduzieren.
Reviews, Abnahme oder Entscheidungen zu Anforderungen werden zu langsam gefällt.
Das Projektmanagement oder andere Mitarbeiter des Managements sabotieren das Projekt.
Das Projektmanagement informiert den Analytiker nicht über aktuelle Entwicklungen im Projektumfeld.
Das Projektmanagement hält sich nicht über die Entwicklung der Analyse auf dem laufenden, insbesondere beachtet es nicht die Berichte des Analytikers.
Das Projektmanagement arbeitet nur halbherzig mit dem Analytiker zusammen, oder aber es blockiert die Analysephase durch Bürokratie.
Das Qualitätsmanagement arbeitet nur halbherzig mit dem Analytiker zusammen, oder aber es blockiert die Analysephase durch Bürokratie.
Das Risikomanagement arbeitet nur halbherzig mit dem Analytiker zusammen, oder aber es blockiert die Analysephase durch Bürokratie.

Organisation

Die Anforderungsanalyse ist noch nicht fertig, aber das Entwicklerteam steht schon bereit.
Dem Analytiker wird ungestörtes Arbeiten nicht ermöglicht, z.B. durch Lärm am Arbeitsplatz.
Arbeitsmittel stehen nicht rechtzeitig bereit, z.B. Telefon, PC, Freischaltung von Benutzerkonten.

Risiken der Anforderungsanalyse im Verantwortungsbereich des Auftraggebers

Endanwender

Der Endanwender muss mit dem fertigen Produkt arbeiten.

Der Endanwender unterstützt die Anforderungsanalyse nicht aktiv.
Der Endanwender hält Informationen zurück bzw. artikuliert nicht seine Bedürfnisse.
Der Endanwender befasst sich nicht mit einem Prototypen.

Entscheider

Sehr häufig ist sich ein Auftraggeber über Mitverantwortung und Mitwirkungspflicht am Gelingen eines Projekts nicht im Klaren. Insbesondere in stark politisierten Arbeitsumgebungen versuchen Auftraggeber die Verantwortung für den Projekterfolg vollständig an den Auftragnehmer zu delegieren. I.d.R. hat ein Analytiker mit diesen Auseinandersetzungen nicht viel zu tun, jedoch kann es vorkommen, dass sein eigener Projektleiter (eher, wenn er auf Seiten des Auftragnehmers arbeitet) nicht seiner Pflicht nachkommt, seinem Team und somit auch dem Analytiker die Arbeit zu ermöglichen.

Der Auftraggeber schließt den Endanwender von der Anforderungsanalyse aus.
Die Anforderungen ändern sich laufend ("moving target"), sodass es nicht zu einer Abnahme kommt.
Nach Abnahme der Anforderungsanalyse und Entwicklungsbeginn besteht der Kunde auf weiteren Anforderungen, ohne sich an ein Change Request-Verfahren zu halten.
Entscheidungen über Anforderungen dauern lange.
Der Auftraggeber nimmt an Reviews der Anforderungsanalyse oder eines Prototypen nicht teil.
Der Auftraggeber verweigert die Abnahme des Anforderungsdokuments ohne konkrete Reklamationen.
Der Auftraggeber verweigert oder verzögert die Abnahme des Anforderungsdokuments, verlangt jedoch dennoch den Beginn der Produktentwicklung.

Risiken der Anforderungsanalyse im Verantwortungsbereich von Zulieferern

Zwar liegt die Verantwortung über den Umgang mit Zulieferern in den Händen der Projektleitung, aber es gibt einige Berührpunkte mit dem verantwortlichen Analytiker. Entweder muss der Analytiker sein fachliches Urteil über gelieferte Komponenten abgeben, oder er spezifiziert Komponenten, die von Zulieferern, häufig ohne weitere Kontrolle, implementiert werden sollen.

Gelieferte Dokumentationen und Schnittstellenbeschreibungen sind nicht korrekt.
Dokumentationen und Schnittstellenbeschreibungen werden nicht rechtzeitig geliefert.
Beauftragte Komponenten werden nicht rechtzeitig wie spezifiziert geliefert.
Der Zulieferer interpretiert die Anforderungsanalyse ohne mit dem Analytiker Rücksprache zu nehmen.
Der Zulieferer zieht den Analytiker nicht zum Review von Architektur und Design hinzu.