Wir nehmen sie ernster, als Ihnen lieb ist.


07.11.2019, Lesezeit: ~3min

Eine der Ironien, die einem im Alltag des Projektmanagements ständig begegnet, ist die Tatsache, dass erst im Laufe eines Projektes klar wird, was das Projekt genau erreichen soll. Es ist, als würde man eine Wanderung beginnen, das Ziel ist aber erst 1 Kilometer vor Ende auszumachen.

Noch verzwickter wird es, wenn man weiß, dass die beteiligten Parteien, meist vom Gegenteil überzeugt sind und entrüstet protestieren würden, behaupte man, sie wüssten nicht genau, was sie denn wollten.

Für diese Standardmisere des Projektmanagements haben sich im Laufe der Zeit verschiedene Strategien herausentwickelt.

Das Wasserfallmodell ignoriert diesen Umstand und tut so, als wäre die Zielvorstellung klar und geht ganz strikt nach den Schritten Plan – Entwicklung – Einsatz vor. Was dann rauskommt, ist oft nicht das, was der Kunde wollte.

Das Modell ist flexibel wie ein Öltanker mit angehängtem Eisberg. Es produziert eine Menge Bürokratie (und ist daher sehr beliebt in IT-Töchtern großer Konzerne, die um Auslastung ihrer Planstellen bemüht sind) und über die Kosten wollen wir schweigen. Vorteil, ist dass alles sehr definiert abläuft.

Ziemlich am anderen Ende des Spektrums befinden sich agile Modelle. Hier wird akzeptiert, dass es nur eine ungefähre Vorstellung gibt, wohin es gehen soll. In kleinen fassbaren Zyklen nähert man sich dem Ziel und definiert gleichzeitig das große Werk, unter intensiver Mitarbeit des Kunden. Anhänger dieses Zugangs, sogenannte agile Evangelisten, werden nicht müde, die Vorteile anzupreisen. Bürokratie wird durch die direkte Kommunikation ersetzt, das Modell kann sehr flexibel auf Änderungen reagieren. Die Sicherheit und Planbarkeit des Wasserfallmodells wird dabei durch Prozesshaftigkeit ersetzt; Auftraggeber und Team sitzen in vielen Meetings zusammen und gestalten den Ablauf.

Diese Vorteile sind auch Nachteile: Das Modell erfordert intensivere Zusammenarbeit, Preis (zumeist wählt man einen Moneybox-Ansatz) und Scope (Umfang des Projektes) sind nicht festgezurrt, Auftraggeber und Team müssen den Ansatz aktiv leben und ein gemeinsames Grundverständnis haben.

Unserer Erfahrung nach wird kein Modell der Wirklichkeit und ihren Anforderungen gerecht.

Zumeist kommen Kunden zu uns mit sehr vagen Vorstellungen. Diese Vorstellungen sind nur oberflächlich im Unternehmen des Kunden abgestimmt. Dennoch, einen Preis will man wissen.

Wir sind in einer Expertenrolle: Der Kunde erwartet sich zu Recht, dass wir seinen Wünschen und Vorstellungen ein Gesicht geben, dass wir sagen, was geht und was sinnvoll ist, wie das Projekt ein voller Erfolg wird - und was es kostet.

Wir bieten daher seit Kurzem einen dritten Weg an und wenden uns damit direkt dem Dilemma zu: Unser PM-Team und Teile unserer Entwicklung haben sich in einem intensiven Kurs als Requirements Engineer nach IREB zertifizieren lassen.

Die Philosophie dahinter ist, die Anforderungen als einen kontinuierlichen Prozess zu verstehen. Zu jeder Phase in der Detailgenauigkeit wie sie möglich und notwendig ist.

Keine Angst: Wir schlagen keine Studie vor, keine überbordende und kostenintensive Analyse und Planungsphase. Aber wir wollen sie ernst nehmen und verstehen.

Requirements Engineering versteht sich als die Kunst, Anforderungen zu erheben, sie abzustimmen, zu dokumentieren und diese im Laufe des Projektes (egal mit welcher Entwicklungsmethodik) flexibel anzupassen.

Es ist eine völlig neue Rolle, die sich in jede PM-Methodik einpassen lässt und den Kunden begleitet und unterstützt. Ob der Requirements Engineer in einem agilen Umfeld als Product Owner stellvertretend tätig wird, oder ein Konzept für eine wasserfall-artige Umsetzung verfertigt, ist anpassbar. Requirement Engineering, so wie wir es verstehen, versteht die Anforderung als ein sich wandelndes Kontinuum und setzt so nicht erst bei der Umsetzung an. Dieser Ansatz alleine ist unglaublich wertvoll, weil er beim ursprünglichen Dilemma ansetzt.

Damit ist es uns möglich - noch präziser als bisher - das anfangs geschilderte Delta aus Wissen und Nichtwissen zu verringern, noch besser zu analysieren, was gefordert ist und gleichzeitig flexibel genug zu sein, um auf dieser Basis mit unseren Kunden die ideale Lösung zu finden.

Mag. Stefan Oswald

Head of Software - Development & Project Management

  • Teilen:
  • Ihr Ansprechpartner:
  • Stefan Oswald
  • Tätigkeit
  • Head of Software - Development & Project Management - Process Design
  • E-Mail:
  • stefan.oswald@cardsys.at
  • Telefon:
  • +43 1 790 33-157

we keep you informed

Mit unserem Blog-Newsletter informieren wir Sie regelmäßig über Spannendes, Ungewöhnliches, Neues & Kommendes aus der IT-Welt.

We keep you informed

Mit unserem Blog-Newsletter informieren wir Sie regelmäßig über Spannendes, Ungewöhnliches, Neues & Kommendes aus der IT-Welt.

Kontakt