Anforderungsmanagement - Best Practise

Anforderungen an ihr Projekt müssen zentral an einer gesammelt werden. Denn nur so erkennt sie sich gegenseitig widersprechende Anforderungen. Und die kommen oft genug vor.

Eigentlich ist aus der agilen Sicht allein schon das Wort "Anforderung" ein Anti-Pattern. Viel besser ist es ein Ziel und einen Mehrwert zu formulieren. Was möchten sie mit dieser Anforderung erreichen?  Nicht: "Ich will Nutzer in einer Datenbank speichern können." Sondern "Als Benutzer möchte ich einmal eingegebene Nutzerdaten wieder abrufen können, so dass ich sie nicht jedes Mal wieder neu eingeben muss." Das klingt bei so einem einfachen Beispiel banal, diese Formulierung "Als Nutzer möchte ich ... damit ... "  hilft aber sehr um sich auf ein Ziel zu konzentrieren und festzulegen.

Anforderungen müssen natürlich die S.M.A.R.T Kriterien erfüllen - mindestens meß- und testbar sein.

Meeeting Kultur

Es bedarf einer neuen Meeting Kultur. Alte Gewohnheiten müssen über Bord geworfen werden und gesellschaftliche Ängste durch Effektivität ersetzt werden.



Zu Beginn eines jeden Meetings

• Kein Meeting ohne Agenda
• Als allererster Punkt 0 eines jeden Meetings wird die Agenda kurz durchgesprochen: "Fehlt noch etwas?"
• Als nächster Puntk werden die Anwesende kontrolliert. Wer ist hier fehl am Platz? Es muss für jeden Anwesenden jetzt völlig ok sein an dieser Stelle aufzustehen und zu gehen.
• Ein/e Protokollant/in wird bestimmt. (Tip: Protokoll direkt am Beamer tippen, wer flink genug tippt.)

Während des Meetings

• Das Meeting in der Reihenfolge der Agenda durchgehen. Möglichst nicht springen. 
• Auf die Zeit achten
• Diskussionen moderieren
• Nur einer redet. (Notfalls einen Hut rumgeben und aufsetzten.)

Am Ende des Meetings

•  ActionItems sammeln und festhalten: Wer macht was bis wann?

Nach dem Meeting

• Protokoll und alle gezeigten Präsentationen/Dokumente an alle Teilnehmer verschicken

Dauer und Aufwand

Ein einfaches, aber doch oft nicht verstandenes Prinzipt: Der Unterschied zwischen Brutto-Dauer und Netto-Aufwand.

Wie lange denken sie Arbeitet ein Mitarbeiter für ihr Projekt? Wahrscheinlich würden sie im ernsten Moment sagen: Ja natürlich 40 h pro Woche. So stehts im Vertrag. Aber arbeitet denn die Resource nur für ihr Projekt? Selbst wenn dem so ist, sind 100% noch lang keine 40 Stunden. Ein Mitarbeiter hat Urlaub, Pausen, Ablenkungen und viele viele administrativen Tätigkeiten. Die Erfahrung lehrt, dass man mit einem Faktor von 0,7 gut beraten ist. Selbst eine exklusive Resource arbeitet also nur zu ca. 70% ihrer Zeit an ihrem Projekt.

Wie lange braucht jemand also für 1BT (einen Bearbeitertag) Aufwand?  "Na da ist er ja morgen fertig!"  - wohl kaum. Wenn man die Reibungsverluste für das Kontextswitching abzieht, sind das mindestesn 2 Tage in brutto real Zeitdauer.

Überlasten sie ihre Resourcen nie mehr als 70%, denn darunter leidet die Qualität. Das müssen sie später im Bugfixing nur doppelte und dreifach wieder nachholen.

MS Projekt Einstellungen

Das berühmte MS Projekt. Jeder kennt es. Jeder hasst es. Und keiner kann damit richtig umgehen. Dabei ist dieses Monster-Tool gar nicht mal so schlecht, wenn man ein paar Tricks bei der Verwendeung beachtet.   Im Vergleich zu anderen Projektmanagement Tools hat MS Projekt die Eigenschaft 'immer alles selber machen zu wollen'. Aber mit den richtigen Einstellungen kann man ihm das abgewöhnen:

MS Office -> Menü -> Extras -> Optionen
-> Reiter: "Berechnen" -> Berechnungsmodus > Manuell     und
-> Reiter: "Terminplan" -> Standardvorgangsart -> Feste Arbeit


Wenn man nun Tasks und Abhängigkeiten einfügt ist nicht gleich immer alles 'zerschossen'. "Feste Arbeit" bedeutet: Wenn sie eine Resource zu einem Task hinzufügen, wird die Dauer kürzer und umgekehrt. Wenn sie "mit gewalt", die Dauer verkürzen, wird die Auslastung der Resource(n) höher. MS Projekt nennt das "Einheiten". Der geschätze Arbeitsaufwand für einen Task bleibt jedoch immer gleich.

Auf dem Reiter "Terminplan" gibt es noch eine Checkbox: "Angefangene Vorgänge automatisch unterbrechen". Standardmäßig ist dies aktiviert. Wenn sie einen halbfertigen Vorgang in die Zukunft verschieben, so wird der Taskbalken geteilt und nur der hintere (noch nicht erledigte Teil) verschoben. Das kann man so machen. Da ja der vordere Teil bereits in der Vergangenheit erledigt wurde.

Möchte man größere Umbauten am Projektplan in einer frühen Phase des Projekts machen, dann macht man diese Einstellung lieber aus.

Noch ein weiterer Tip: Sparsam sein mit Abhängigkeiten. Am besten Tasks gruppieren und dann ausschließlich nur Abhängigkeiten auf den obersten Ebenen vergeben, also z.B. Task-Gruppe B kann erst beginnen wenn die komplette Gruppe A fertig ist (Ende-Anfang-Beziehung)

Dann bleibt das Projekt einigermaßen handhabbar.