Wie viele der Anforderungen sind zu Beginn eines Projektes bekannt?

Diese Frage ist Teil der gerade laufenden Untersuchung. Inzwischen sind Daten von 80 Projekten zusammen gekommen. Damit ist ein erster vorsichtiger Blick auf die Daten möglich. Die oben genannte Frage haben wir neu aufgenommen da bei den Auswertungen der älteren Daten insbesondere im Zusammenhang mit dem Umsetzungserfolg die Differenzierung zwischen im Projekt neu hinzugekommenen und bereits zu Beginn des Projektes bekannten Anforderungen nicht möglich war.

Grafik: Anforderungen zu Beginn des ProjektesDie gefühlte Antwort auf die obige Frage lautet: “Ein großer Teil der Anforderungen ist zu Beginn des Projekts noch nicht bekannt”. Der erste Blick auf die Daten scheint dies zu bestätigen. Nur bei 10% der Projekte sind alle Anforderungen zu Beginn des Projektes bekannt. Bei 26% sind es immer noch ca. 80%. Bei 29% zwischen 50 und 80% der Anforderungen. Bei einem immer noch nennenswerten Teil von 25 % ist weniger als die Hälfte der Anforderungen zu Beginn bekannt. Diese Prozentzahlen scheinen zudem relativ unabhängig von der Art des Projektes zu sein – zumindest die IT-Projekte und die nicht-IT-Projekte zeigen die gleichen Werte. Eine genauere Differenzierung wird allerdings erst bei einer größeren Zahlenbasis möglich sein.

Diese Zahlen zeigen auf wie notwendig ein funktionierendes Anforderungs- und Changemanagement oder eine agile Vorgehensweise ist. Eine Schlussfolgerung lässt sich schon jetzt ziehen. Die einmalige Erstellung eines endgültigen Planes, der nicht mehr geändert werden muss, ist eine Illusion.

  • Share/Bookmark
Posted in Forschung | Tagged , , , | 3 Comments

Rückmeldungen zur Umfrage

Die Umfrage Erfolgfaktoren in Projekten läuft nun schon einige Wochen. Die ersten 80 Fragebögen sind vollständig ausgefüllt. Auch an dieser Stelle noch ein Dankeschön an alle, die sich bisher die Zeit genommen haben. Am Ende des Fragebogens gibt es auch die Möglichkeit uns eine kurze Rückmeldung zukommen zu lassen. Einige der Rückmeldungen, die von allgemeinem Interesse sind möchte ich hier anonym und auszugsweise vorstellen und beantworten:

Bei Frage 31 sollten Sie vielleicht spezifizieren, um welche Art von Interview es sich handelt: Soll es veröffentlich werden oder dient es der weiteren Datenerhebung und bleibt anonym? Wo und wie soll es ggf. geführt werden und mit wem?

Danke für den Hinweis, ich werde da noch eine Notiz anfügen. Wir (nebenstehende Autoren) würden uns nach den ersten Auswertungen bei den jeweiligen Personen per Mail melden um Details zu vereinbaren. Die Themen Kommunikation und Projektkultur sind derzeit Favoriten für die Interviews. Der Wunsch nach Anonymität wird selbstverständlich vollständig respektiert. Die Verwendung von Äußerungen aus den Interviews in etwaigen Publikationen erfolgt ebenfalls nur mit ausdrücklicher Genehmigung der Interviewpartner.

Ich könnte mir vorstellen dass IT-Projekte andere tiefergehende Fragen benötigen als z.B. Entwicklungsprojekte in der Forschung. Ist aber vielleicht auch nicht notwendig für eine globale Aussage.

Es ist eine echte Zwickmühle die Balance zwischen globalen und speziellen Aussagen zu halten. Jeder Fragebogen ist ein Kompromiss zwischen Detailgenauigkeit und Ausfüllzeit. Um diverse Zusammenhänge aufzuspüren benötigen wir vor allem eine große Datenbasis, diese ist leider nur mit einem Fragebogen zu erreichen, der in akzeptabler Zeit auszufüllen ist. 10 min markieren hier so etwas wie eine kritische Grenze.

“Wichtig waren vor allem drei Punkte im Projekt:
a) 100% Rückendeckung vom Sponsor
b) die “Richtigen” Teammitglieder, sowohl intern als auch extern
c) Alles 1. Immer 2. Offen 3. Transparent kommunizieren – wirklich alles.”

Das sind auch meiner Ansicht sehr wichtige Faktoren, ich bin gespannt ob sich das in den Daten widerspiegeln wird.

allerdings ist mir die Umfrage etwas zu Software-Entwicklungsprojektlastig

Das ist nicht ganz von der Hand zu weisen. Das hat zwei Ursachen, zum Einen müssen wir manche Fragen aus früheren Umfragen, die explizit auf SW-Projekte zielten, beibehalten um eine gewisse Vergleichbarkeit der Daten zu ermöglichen. Andererseits ist die Vielfalt der Methoden im Bereich SW-Entwicklung größer als in anderen Gebieten, dementsprechend häufiger tauchen in den Auswahlfragen SW-Entwicklungsmethoden auf.

Soweit für heute – ein erstes Zwischenergebnis finden Sie hier.

  • Share/Bookmark
Posted in Forschung | Tagged | Leave a comment

über PM Werkzeuge – Teil I

“A fool with a tool is still a fool”. So lautet ein häufig zitierter Spruch. Er wird in vielen Bereichen und natürlich auch im Projektmanagement verwendet. Manchmal wird er als polemisches Argument gegen jeglichen Tooleinsatz vorgebracht. Die Erkenntnis, dass sich jeder Einsatz eines Werkzeugs durch ungeschickten Gebrauch ad absurdum führen lässt ist trivial. Wenn jemand versucht einen Nagel mit dem Griff eines Hammers einzuschlagen macht das natürlich keinen Sinn – es ist aber kein Argument den Hammer zur Seite zu legen. Die Notwendigkeit von Schulungen d.h. den Hammer richtig zu halten ist heute jedoch nicht mein primäres Anliegen.

Mir fällt beim Einsatz von Projektmanagement-Werkzeugen gelegentlich etwas Anderes auf. Es wird nicht mit dem Hammerstiel auf die Nägel geklopft, sondern mit dem Griff eines Schraubendrehers, der nächste klopft die Schraube mit dem Schraubenschlüssel in die Wand, im schlimmsten Fall werden Nägel an die Wand geklebt und im Gegenzug die Tapete mit Nägeln befestigt. Das klingt provozierend, entspricht aber manchmal leider der Realität. Kein Projekt gleicht dem anderen, jedes Projekt benötigt andere Werkzeuge. Ein Systemhaus ist für wechselnde Kundenprojekte (z.B. Software-Einführungs-Projekte) mit einem Werkzeug, das standardisierte, ggf. wiederkehrende Aufgaben und Abläufe unterstützt gut bedient. Ein internes Produkt-Entwicklungsprojekt mit dem Ziel das Produktspektrum des Systemhauses zu erweitern stellt hingegen ganz andere Anforderungen an das Werkzeug. Im ersten Fall wäre ein klassisches Planungs- im anderen ein “agileres” Werkzeug angesagt. Nägel und Schrauben lassen sich leicht unterscheiden, das genannte Beispiel ist ebenfalls nachvollziehbar. Schwieriger wird es mit einer generellen Klassifizierung von Projekten und dazu passender Werkzeugwahl. Die folgenden Fragen liefern zumindest erste Ansätze:

  • Wie viele der konkreten Anforderungen sind zu Projektbeginn schon klar? Dass ein übergeordnetes Ziel bzw. eine Vision vorhanden ist, setze ich heute voraus.
  • Aus wie viel Quellen werden Anforderungen erhoben?
  • Wurde ein ähnliches Projekt (Beteiligte und Inhalte) schon einmal durchgeführt?
  • Arbeiten die Mitarbeiter in einen oder in mehreren Projekten?
  • Wie groß und wie verteilt ist das Team?

Je nachdem wie die Antworten der obigen Fragen ausfallen werden Werkzeuge mit unterschiedlichen funktionalen Schwerpunkten benötigt:

  • Aufgaben- und Ressourcen Planung
  • Aufgabenverfolgung
  • Anforderungsmanagement
  • Erfassung und Überwachung von Zeitaufwänden
  • Kommunikation und Kooperation

Grafik: Welches Tool für welche ProjektartWenn die Fragen teilweise als Koordinatenachsen aufgefasst werden, ergibt sich eine erste grafische Darstellung. Je häufiger das Projekt in ähnlicher Weise wiederholt wird, desto eher ist ein echtes Planungswerkzeug sinnvoll. Ist das Projekt einzigartig und sind die Anforderungen zu Beginn nicht klar, werden eher Anforderungsmanagement und mit wachsender Teamgröße und Verteilung Kommunikation und Kooperation wichtig. Vor der Wahl eines Werkzeugs ist es unabdingbar sich den Charakter des Projektes bewusst zu machen. Allzu schnell kommt man sonst in die Lage mit dem Schraubendreher zu hämmern.

Eine versteckte Botschaft des bisher Geschriebenen lautet, dass es das “beste” Werkzeug nicht gibt. Als Projektleiter sollte mann/frau eine Vielzahl von Werkzeugen kennen und soweit möglich in jedem Projekt neu und bewusst wählen.

Derzeit haben wir in unterschiedlichen Projekten verschiedene Werkzeuge mit Schwerpunkten in den jeweiligen Bereichen im Praxistest. Unter anderem arbeiten wir derzeit mit A-Plan, MS-Project, Zcope, FogBugz, Mindmanager und auch Office. In den nächsten Tagen wird es hierzu mehrere Erfahrungsberichte geben.

  • Share/Bookmark
Posted in Projektmanagement RT | Tagged | 7 Comments

von verstopften Rohren, Engpässen und höheren Gewalten

Vielleicht sollte ich die Worte der Überschrift etwas erläutern. Das verstopfte Rohr ist ein aktuelles und reales Problem im Hause. Nichts was sich nicht durch etwas Arbeit und die Hilfe eines Rohrreinigungs-Service wieder lösen ließe, aber es kostet unvorhergesehen Zeit, Nerven und Geld. Anstatt wichtige Dinge zu erledigen, stehe ich in Gummistiefeln auf dem Hof und versuche den Engpass im Abflussrohr zu beseitigen.

Mit der Projektleiterbrille sehe ich das Ganze als eine unvorhergesehene Störung, einen plötzlich auftretenden Zeitengpass, die zu einer Planabweichung des eigentlichen Projektes führen wird. Ein Stück weit ist das verstopfte Rohr höhere Gewalt. Auch die Wolke aus Vulkanasche, die heute über Deutschland hinweg zieht und Flughäfen lahm legt, ist höhere Gewalt. Weder das verstopfte Rohr noch der Vulkanausbruch sind in einem Projektplan als mögliches Zeitverlust-Risiko enthalten. Ich stelle mir gerade vor in einem Projektantrag würde stehen “Puffer, für unvorhergesehene Ereignisse wie “verstopfte Rohre” oder “Vulkanausbrüche”. Eine solche Formulierung würde im günstigsten Fall für Heiterkeit sorgen.

Vorhersehen und präventiv einplanen lassen sich solche Ereignisse also nicht. Das ändert aber nichts daran, dass sie eintreten. Letztendlich lässt sich dieses Problem auch nicht lösen. Es geht mehr darum eine innere Einstellung zu finden um stressreduziert mit solchen Störungen umzugehen. Ich habe mir dazu drei Dinge hinter die Ohren geschrieben:

  • Akzeptiere, dass es Störungen gibt, und freue Dich über jeden Tag, der ohne Störung verläuft.
  • Eine Störung ist nur eine kurzzeitige Verschiebung der Prioritäten.
  • Eine gründlich beseitigte Störung kommt nicht so schnell wieder, und schafft neuen Freiraum.

und jetzt ziehe ich meine Gummistiefel an ;-)

  • Share/Bookmark
Posted in Projektmanagement RT | Tagged , | 1 Comment