Geschrieben am

Von selbst passiert nichts – oder: wie bekomme ich als Anforderungsautor Antworten?

frage-und-antwort

Wie bekommt man als Spezifikateur Input?

In Requirements Management Trainings bekomme ich regelmäßig die Frage:

„Ich habe einige wichtige Stakeholder um ihren Input gebeten — aber die rühren sich einfach nicht! Wie kriege ich die dazu, mir endlich ihren Input zu geben?“

So einfach das Thema klingt, so leichtfertig sollte es nicht genommen werden.

Wenn Spezifikationsautoren ihren Input nicht bekommen, weil sie nicht wissen, wie sie ihn aus den nicht antwortenden Stakeholdern „herausbekommen“, dann ist das nicht auf die leichte Schulter zu nehmen. Fehlender Input bedeutet fehlende Anforderungen – und Anforderungen, die man nicht kennt, kann man nicht erfüllen.

Hin und wieder gibt es Ansätze wie etwa die folgenden:

„Es müsste da eine firmeninterne Anweisung geben, dass jeder auf Fragen eines Spezifikateurs antworten muss!“

Oder auch

„Wenn ich keinen Input bekomme, dann denke ich mir selbst was aus, was zum befragten Stakeholder eigentlich passen müsste — und hoffe, dass es stimmt. Ich versuche, das dann aber vor dem nicht antwortenden Stakeholder zu verbergen, nachher merkt der das und dann dauert es noch länger!“

Und dieses Statement habe ich auch bereits mehr als einmal gehört:

„Der Stakeholder, der mir nicht antwortet, ist mein Chef. Den kann ich ja schon prinzipiell nicht unter Druck setzen und zwingen zu reagieren!“

Es gibt jedoch eine Reihe von sehr freundlichen Maßnahmen, die es ermöglichen, als Spezfikateur in solchen Situationen durchaus guten und zeitnahen Input zu bekommen — oder die Information, dass es von Stakeholderseite nichts Nenneswertes einzubringen gibt. Was ja auch ein akzeptabler Input ist.

Der Kerngedanke aller folgenden Überlegungen ist der folgende:

Druck oder „Dienstanweisungen“ funktionieren nicht — Das Skizzieren von Konsequenzen aber durchaus

Wir kennen das alle: Druck oder direkte Anweisungen empfinden wir als impertinent, unhöflich und übergriffig. Niemand möchte gerne durch Zwang oder „offizielle Dienstanweisung“ zu Arbeitsergebnissen genötigt werden. Kaum erwähnenswert, dass Arbeitsergebnisse unter solchen Umständen auch nicht besser werden.

Was jedoch funktioniert, ist das Interesse eines Stakeholders, überhaupt Stakeholder zu sein. Jeder Stakeholder hat ein Interesse, Einfluss auf eine Spezifikation auszuüben — sonst wäre er kein Stakeholder.

Zudem ist es auch selten so, dass aus reiner Bosheit keine Antwort kommt — Stakeholder haben halt auch andere, manchmal dringendere Dinge zu tun.

Möchte man also erreichen, dass Stakeholder reagieren, so kann das über die folgenden Hebel geschehen:

  1. Die direkte Bezugnahme auf das Interesse, das ein Stakeholder eigentlich haben sollte.
  2. Die Möglichkeit für den Stakeholder, die Arbeit des Input-Generierens innerhalb seiner Aufgabenliste zu priorisieren.

Ich habe mit dem S.I.T.K.A.-Vorgehen sehr gute Erfahrungen gemacht:

  1. Ich erbitte Input und Review-Kommentare für Spezifikationen grundsätzlich schriftlich (S) (per Email). Das hat den Vorteil, dass ich jederzeit den Stand der Dinge nachlesen kann. Erinnerungen, wann man wen um was gefragt hat, sind gerne trügerisch — und die andere Seite kann sich ganz anders daran erinnern.
  2. Ich versuche (sofern das nicht vorab schon klar ist), das Interesse (I)  aufzugreifen, das ein Stakeholder am eigenen Input hat.
  3. Ich empfehle, jede Bitte um Input für eine Spezifikation mit einem Termin (T) zu versehen, bis zu dem sie bitte zu erfolgen hat. Der Termin sollte auf Nachfrage erklärbar sein, sich aus dem Projektplan ergeben und nicht willkürlich sein. Auch dies hilft, eine Frist nicht als Gängelung oder persönlichen Affront aufzufassen.
  4. Ich stelle freundlich die Konsequenz (K) dar, die es hat, wenn Input nicht oder verspätet kommt. Wichtig: Das Wort „Konsequenz“ kann hier schnell als „Sanktion“ missverstanden werden. Das ist nicht gemeint. „Konsequenz“ ist hier nicht zu verstehen als „Wenn Sie nicht antworten, rufe ich Ihren Chef an“, sondern als „Wenn Sie kein Input für mich haben, müssen wir ohne weitermachen“ oder „Nach dem TT.MM.JJJJ kann ich Ihre Antwort leider nicht mehr berücksichtigen aus diesen oder jenen Gründen.“ Das ist eine ganz neutrale Konsequenz, die keinen Geruch des persönlichen Angriffs hat. Dass nicht gegebener Input zu fehlenden Anforderungen und eine Verlängerung einer Frist zu Projektverzug führen kann, kann im Projektplan einfach nachgeschaut werden.
  5. Ich füge eine Annahme (A) hinzu, die dazu führt, dass ich weiterarbeiten kann, wenn kein Input kommt und dann nicht auch noch hinterhertelefonieren muss.

S.I.T.K.A. — Keine Antwort ist auch eine Antwort

Wenn ich in einer Bitte um Input die fünf Tipps von oben einbaue, werde ich in jedem Fall am Ende der Frist einen Stand haben, auf dem ich weiter arbeiten kann. Hier mal ein Beispiel für eine Bitte um Input in S.I.T.K.A.-Form:

„Lieber Herr/Frau X,

wie schon angekündigt habe ich die Dinge mal in ein Konzept verarbeitet (siehe Anhang). Ich denke, der erreichte Stand ist für Sie interessant zum Review, da Sie ja aus Grund Y Interesse an einer guten Spezifikation haben.

Könnten Sie mir Ihre Anmerkungen dazu (z.B. weitere Inhalte, zu änderende Dinge, etc.) bis zum TT.MM.JJJJ zukommen lassen? Dann könnte ich sie noch berücksichtigen, ohne dass sich was im Projektplan verzögert.

Ich denke im Moment, das passt alles, wie ich es aufgeschrieben habe. Insofern würde ich davon ausgehen, dass das so für Sie OK ist, wenn Sie mir keine Anmerkungen schicken.

Vielen Dank im Voraus!
Paul“

Egal, ob Paul eine Antwort erhält oder nicht: Zum Zeitpunkt der gesetzten Frist kann er mit gutem Gewissen weiterarbeiten. Der Stakeholder X war einbezogen. Er hatte auch eine Zeitspanne genannt bekommen. Ihm war nochmal deutlich gemacht worden, was auf dem Spiel steht und auch, was passiert, wenn er nicht antwortet.

Alles völlig fair gelaufen. Niemand kann sagen, er wäre hintergangen worden.

Einige zusätzliche Hinweise

Dieses Vorgehen als solches ist nicht ungewöhnlich und auch nicht neu. Es ist unter Kaufleuten gängig und wird dort als sog. Kaufmännisches Bestätigungsschreiben bezeichnet.

  • Es kann helfen, dieses Vorgehen einmal zu Anfang darzustellen (im Spezifikations-Kickoff z.B.) und zu sagen, dass man es praktizieren wird.
  • Es gibt eine leicht abgewandelte Form, die noch ein wenig freundlicher ist, jedoch auch mehr Arbeit macht. Wenn man möchte, kann man noch folgenden Satz hinzufügen:

„[…] Wenn Sie bis zum genannten Termin keine Zeit haben, sich mit dem Thema zu beschäftigen, nennen Sie mir gerne einen anderen, späteren Termin, sofern dieser den Projektplan nicht verzögert. […]

  • Die Sache mit dem Chef: Dieses Verfahren ist meines Erachtens absolut „chef-kompatibel“. Ist der Vorgesetzte auch gleichzeitig Input-Geber einer Spezifikation, so begegnet man ihm ja in dieser Hinsicht nicht in der Rollenpaarung „Chef-Untergebener“, sondern „Stakeholder-Spezifikateur“. Es soll Chefs geben, die dennoch nicht damit klar kommen, dass Sie von Untergebenen irgendwelche Wünsche um Mitarbeit bekommen, die man entfernt als „Arbeitsanweisungen“ verstehen könnte. Auch dann nicht, wenn diese fachlich völlig legitim sind und sich aus der Rollenverteilung klar ergeben. Das ist dann allerdings ein Problem, das sich auf einer anderen Ebene abspielt. Falls der Spezifikateur nicht gleichzeitig auch Projektleiter ist, kann er den Projektleiter bitten, hier zu vermitteln. Generell gilt jedoch, dass in diesem Fall die konstruktive Zusammenarbeit im Projekt gefährdet ist. Grund ist dann die Weigerung des Chefs, bestimmte Rollen zu akzeptieren.
Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.