Ãœber die manchmal wundersame Vermehrung von Projektzielen oder Anforderungen habe ich hier schon geschrieben. Angesichts der Wichtigkeit des Themas habe ich ein weiteres Kärtchen mit Merksätzen. Diese Sätze sind zwar auf dem Hintergrund von IT-Projekten entstanden, die Mechanismen, die dahinter stecken, sind aber in allen Formen von Projekten zu finden. Wie kommt man also den Anforderungen wirklich auf die Spur?
– Auf ungefragt geäußerte Information achten!
– Auf persönliche Steckenpferde achten!
– Gibt es mehrere Anforderer?
– Gibt es widersprüchliche Anforderungen?
– Das „Was“ und das „Wie“ nicht vermischen?
– Was braucht der Kunde wirklich?
Der Prozess genaue und klare Anforderungen zu ermitteln ist lange und mühselig. Manchmal ist es wie das Fischen in einer trüben Suppe. Manches ist schwierig zu erwischne, ss gibt aber auch „Brocken in der Suppe“, die immer wieder von alleine auftauchen. Anforderungen, die freiwillig und ohne Nachfragen genannt werden. Das erleichtert im ersten Moment die Arbeit, dennoch sollten solche Anforderungen besonders genau unter die Lupe genommen werden. Hinter diesen Anforderungen stecken meist starke Interessen des jeweiligen Anforderers. Diese Interessen müssen nicht zwingend im Sinne des Projektes sein. Deshalb gilt es diese Anforderungen kritisch zu prüfen. Im Sinne dieser Prüfung sollte man sich auch fragen ob sich dahinter eventuell persönliche Steckenpferde verstecken. Ich möchte „persönliche Steckenpferde“ nicht schlecht machen, oft ist es eine große Hilfe für die Anforderungsdefinition wenn Spezialwissen gepaart mit Begeisterung für ein Thema zusammen kommen. Die Aufnahme aller persönlichen Steckenpferde kann die Anforderungsliste aber auch überfrachten – womit wir wieder bei der Zielvermehrung angekommen wären. Bei der Bewertung der Anforderungen lohnt sich immer auch ein Blick darauf ob es eine einzelne Person oder mehrere Personen sind, die hinter einer formulierten Anforderung stehen. Nicht immer zählt die Masse aber es hilft bei der Steckenpferdanalyse.
Jetzt wird es spannend. Sehr gut beschriebene Anforderungen können wertlos werden, wenn sie nicht genau auf Widersprüche geprüft worden sind. Wenn Zeit und Budget im Ãœbermaß vorhanden sind, lassen sich manche Widersprüche durch ein salomonisches „sowohl als auch“ lösen. In realen Projekten sind Zeit und Geld aber knapp. Entscheidungen, welche der widersprüchlichen Anforderungen umgesetzt wird, müssen so früh wie möglich gefällt werden um den Anforderer zum Ende des Projektes hin nicht unnötig zu verärgern. Fällt der Widerspruch erst am Ende auf, wenn eine der Anforderungen schon umgesetzt wurde und dann doch die Entscheidung für die andere fällt wurde für den Papierkorb gearbeitet. Das ist dann der „worst case“ im Projektgeschäft.
Die nächste Frage erscheint trivial und ist dennoch von großer Bedeutung. An einem Beispiel wird es deutlich. Die Anforderung lautet: „6 Personen aus Stuttgart müssen morgen um 10:00 Uhr in Mannheim pünktlich zu einem Termin erscheinen“. Das ist das „Was“ – eine Formulierung der Anforderung. Das „Wie“ ist die Frage nach dem Transportmittel, als da wären: Auto, ICE, Flugzeug. Eine vermischte Formulierung wäre „6 Personen müssen mit dem Zug nach Mannheim fahren und pünktlich zu einem Termin erscheinen“. Selbst wenn die Lösung der Anforderung wirklich die Zugfahrt ist, muss die Anforderung selbst lösungswegneutral formuliert werden. Wird dieser Grundsatz vernachlässigt werden manche Entscheidungen vorweggenommen bzw. Entscheidungsspielraum im Projekt eingeschränkt. Dieser Effekt tritt oft in IT-Projekten auf, wenn Anforderungen mit Implementierungshalbwissen vermischt werden. Wer kennt nicht den Satz „Wir brauchen eine Datenbank?“ … die Frage „Was soll die Datenbank tun?“ bleibt oft lange unbeantwortet.
Die letzte Frage schließt den Kreis zur ersten Frage auf dem vorherigen Kärtchen, diese lautete „Wer ist der Auftraggeber“. Egal ob man diesen Auftraggeber, Stakeholder oder Kunde nennt. Man sollte immer versuchen sich in den Kunden hinein zu versetzen und versuchen zu verstehen was er wirklich braucht. Nicht immer ist das was formuliert wird auch wirklich das was benötigt wird. Echte Zufriedenheit beim Kunden/Auftraggeber wird sich nur einstellen, wenn er wirklich das bekommt was er braucht.
Pingback: Zusammenfassung Projektmanagement - Checklisten » Von Dr. Eberhard Huber » Agile Projekte IT-Projekte Agiles Projektmanagement Agil Teamentwicklung Risikomanagement Teamuhrwerk PMRT Projektkultur Faktor Mensch Weiterbildung Seminare Coaching Scrum Tuckm
Pingback: Die wundersame Vermehrung von Projektzielen / Projektmanagement-Checklisten: Die Vierte » Von Dr. Eberhard Huber » Agile Projekte IT-Projekte Agiles Projektmanagement Agil Teamentwicklung Risikomanagement Teamuhrwerk PMRT Projektkultur Faktor Mensch Wei