Die Umbauarbeiten im Blog neigen sich dem Ende zu. Da sich über manchen Sachverhalt leichter reden als schreiben lässt, wird es in Kürze hier auch das eine oder andere Video zu sehen geben. Das youtube Icon ist immerhin schon vorhanden. Bis das erste eigene Video fertig gestellt ist möchte ich noch auf einige Videos aus meiner Favoritenliste hinweisen. In einem davon wird eine fiktive Geschichte erzählt. Nehmen wir an es gäbe auf den Straßen noch keine Stopp-Schilder. Eine große Firma beauftragt eine Agentur ein Stoppschild zu entwerfen. Irgendwelche Ähnlichkeiten zu Diskussionen bzgl. Projektanforderungen sind hierbei rein zufälliger Natur

Ähnliche Beiträge:

1. Die Hartnäckigkeit der Spezifikation Manche technische Spezifikation vererbt sich selbstständig von Projekt zu Projekt. Die Übernahme bewährter Lösungen spart beim ersten Mal sicher...
2. Projekte gegen die Krise Der Grundgedanke des vorangegangenen Beitrags Projektmanagement in der Krise war es die Projektziele noch schärfer zu fassen als man...
3. Politik, Teamgeist und Projektarbeit Politiker fordert mehr Teamgeist in der Regierung. Dieser Satz ist einer Schlagzeile meiner Tageszeitung entnommen. Eine Regierung, die gemeinsam...

Politiker fordert mehr Teamgeist in der Regierung.

Dieser Satz ist einer Schlagzeile meiner Tageszeitung entnommen. Eine Regierung, die gemeinsam voller Teamgeist arbeitet – das ist eine schöne Vorstellung. Die aktuellen Berliner Regierungsgeschäfte scheinen davon jedoch weit entfernt zu sein. Teamgeist lässt sich aber nicht einfordern. Teamgeist muss wachsen. Der Samen für den Teamgeist ist eine gemeinsame Vision. Möglicherweise fehlt es genau daran. Ich sehe mich, wenn ich mich in die Lage der Regierung versetze, nicht in der Lage eine kurz formulierte Vision für die Regierungsarbeit der nächsten Jahre zu formulieren. Ich befürchte manchem Regierungsangehörigen geht es ähnlich.

Keine Teamarbeit ohne Vision! Und was hat das mit Projekten zu tun?

Dass unklare Ziele einen gewichtigen Misserfolgsfaktor darstellen, ist unbestritten. Über den konkreten Zielen oder Anforderungen steht aber noch die Vision. Auch Projekte brauchen Visionen. Eine kurze Kontrollfrage lautet: “Warum machen wir das Projekt?” Die Antwort auf diese Frage sollte von allen Mitarbeitern ohne zu zögern kurz und prägnant beantwortet werden können. Es bleibt noch anzumerken, dass sich die Antworten ähneln sollten. Wenn bei der Frage nach dem “Warum” schon Differenzen bestehen, werden sich bei der Ermittlung der konkreten Anforderungen zwingend Widersprüche ergeben. Damit schließt sich der Kreis zur Politik Widersprüchliche Maßnahmen haben derzeit Hochkonjunktur.

Ein Tipp zum Schluss: Es lohnt sich die Frage nach dem “Warum” explizit zu stellen und ggf. einen Konsens herzustellen. Damit lassen sich viele Missverständnisse vermeiden.

Ähnliche Beiträge:

1. Die wundersame Vermehrung von Projektzielen / Projektmanagement-Checklisten: Die Vierte Die nächsten zwei Beiträge bzw. Kärtchen widmen sich den Zielen eines Projektes. Ziele eines Projektes – ein leidiges Thema,...
2. Und immer noch mehr Anforderungen / Projektmanagement-Checklisten: die Fünfte Über die manchmal wundersame Vermehrung von Projektzielen oder Anforderungen habe ich hier schon geschrieben. Angesichts der Wichtigkeit des Themas...
3. Die Legende von Web 2.0 Werkzeugen Collaboration und Wissensmanagement sind mit modernen Web 2.0 Werkzeugen kein Problem mehr. Es ist nur ein elegantes Tool auszuwählen...

Im voran gegangenen Beitrag hatte ich diese Aussage schon getroffen. Nachdem einige Nachfragen eingetroffen sind, möchte ich die Aussage etwas weiter ausführen. Nebenstehend ist ein typisches Wasserfall-Diagramm zu sehen. Die konkrete Benennung der Phasen kann variieren – entscheidend ist der Grundgedanke, dass eine Phase abgeschlossen wird und ihre Ergebnisse quasi in die nächste Phase ergießt. Die Ähnlichkeit zu Gantt Diagrammen und klassischen Projektplänen ist keineswegs zufällig. Diese Darstellung geht auf eine Veröffentlichung von Winston Royce aus dem Jahr 1970 zurück. Der Titel lautet MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS. Diese Darstellung des Wasserfalls hat sich in das Bewusstsein der Softwarebranche und des Projektmanagements eingebrannt. Bei aller Kritik am Wasserfallmodell blieb der Eindruck hängen, dass es bei hinreichender Sorgfalt der Anforderungserhebung, funktionieren würde.

Anforderungs-, Change- und Scopemanagement sind genau genommen Versuche das Wasserfallmodell zu verbessern. Im Laufe der Zeit verbreiteten sich iterative Ansätze und mündeten in den 90er Jahren des letzten Jahrhunderts in agile Vorgehensweise. Das tragische Element an dieser Geschichte ist, dass die Grundaussage der Veröffentlichung eine andere ist als jene die in das Bewusstsein der Branche drang.

Winston Royce schreibt in der Zusammenfassung:

In my experience, however the simpler method has never worked on large software development efforts and the costs to recover far exceeded those required to finance the five-step process listed.

Die erwähnte “simpler method” ist der klassische oben skizzierte Wasserfall. Die Mehrkosten durch den aufwändigeren Prozess (Iterationen) sind geringer als jene, die durch Nachbesserungen (Terminüberschreitungen) am einfachen Modell entstehen. Er schreibt also sinngemäß: “Das hat noch nie funktioniert“. Dementsprechend sind in der Veröffentlichung einige andere Grafiken enthalten, mit denen er bereits 1970 eine iterative Vorgehensweise bis hin zu wiederholtem Coding vorschlägt – das würde man heute Refactoring nennen.

Ein wenig erinnert mich das an die Legende vom Eisengehalt des Spinats

… den bis heute noch gelegentlich behaupteten, außergewöhnlich hohen Eisenanteil besitzt Spinat jedoch nicht – der Schweizer Physiologe Gustav von Bunge hatte 1890 den Wert zwar richtig berechnet, doch bezogen sich seine Angaben auf getrockneten Spinat, wurden aber später irrtümlich frischem Spinat zugeschrieben, der zu ca. 90 % aus Wasser besteht. (Wikipedia)

Ähnliche Beiträge:

1. Über die gelegentliche (Un)Sinnigkeit von Planungen Keine Sorge – ich will das Erstellen von Projektplänen nicht grundsätzlich in Frage stellen. Ich möchte lediglich – dieses...

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.

Die 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.

Ähnliche Beiträge:

1. es gibt etwas zu gewinnen und zwar zweierlei: Zum ersten Erkenntnis. Zum Zweiten amazon-Einkaufsgutscheine und andere Preise. Unter den Teilnehmern der diesjährigen Umfrage werden...
2. 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...
3. Die wundersame Vermehrung von Projektzielen / Projektmanagement-Checklisten: Die Vierte Die nächsten zwei Beiträge bzw. Kärtchen widmen sich den Zielen eines Projektes. Ziele eines Projektes – ein leidiges Thema,...

Keine Sorge – ich will das Erstellen von Projektplänen nicht grundsätzlich in Frage stellen. Ich möchte lediglich – dieses Mal ganz im originären Sinne eines Blogs als Tagebuch – von einem aktuell laufenden Projekt berichten. Es handelt sich um ein Organisationsentwicklungsprojekt mit leichten IT-Anteilen. Vor wenigen Wochen saß ich mit den Stakeholdern zusammen um die Kernfragen aus denen sich die Arbeitspakete definieren lassen zu identifizieren. In der gemeinsamen sehr konstruktiven Besprechung wurden 6 Fragen und daraus abzuleitende Aufgabenpakete gefunden. Auf Basis dieser 6 Fragen wurde ein erster Projektplan erstellt.

Wenige Wochen später sollten diese Fragen nochmals geprüft und ggf. durch weitere ergänzt werden. Dieser Termin hat inzwischen stattgefunden. Von den ursprünglichen Fragen sind nur noch zwei relevant. Die anderen haben sich durch Ergebnisse aus anderen Projekten und veränderte Rahmenbedingungen praktisch erledigt bzw. ihre Priorität hat sich erheblich verändert. Auch der Projektplan wird sich dadurch erheblich verändern. Mit anderen Worten: Die erste Version des Planes ist für die Tonne.

Der erste Reflex die veränderten Fragestellungen im alten und modifizierten Plan abzubilden ging zum Glück schnell vorüber. Ich erinnere mich aber durchaus an Projekte in denen dieser erste Impuls in die Tat umgesetzt wurde. Das hilft aber niemandem weiter. Wenn sich die Bedingungen für den Plan grundlegend geändert haben, muss sich das auch im Plan wiederfinden. In meinem konkreten Fall setze ich einen neuen Plan auf. Mit drastischen Worten zusammengefasst:

Wenn schon für die Tonne gearbeitet wurde, dann aber richtig.

oder

Sackgassen müssen als Sackgassen akzeptiert werden.

Ein solcher Einstieg in ein Projekt ist ein deutlicher Hinweis, dass hier eine agile Vorgehensweise keine schlechte Lösung wäre

Ähnliche Beiträge:

1. Projektmanagement-Checklisten: Die Erste Stefan Hagen hat heute in seinem Blog einen Beitrag geschrieben, der (Projekt)management sehr klar auf den Punkt bringt. Die...
2. Die wundersame Vermehrung von Projektzielen / Projektmanagement-Checklisten: Die Vierte Die nächsten zwei Beiträge bzw. Kärtchen widmen sich den Zielen eines Projektes. Ziele eines Projektes – ein leidiges Thema,...

Was ist das Hey Joe Prinzip? In der Wikipedia findet sich eine knappe und treffende Definition:

Das Hey-Joe-Prinzip beschreibt die Auswirkungen der im IT-Support problematischen “Nachbarschaftshilfe” (Peer Support), die dabei den vorgesehenen Arbeitsprozess (Workflow) umgeht. Das geschieht, indem der Anwender die Hilfe für eine Problemlösung über eine inoffizielle Anfrage in seinem firmeninternen Bekanntenkreis erfragt, anstelle den eigentlich dafür vorgesehenen Service Desk zu kontaktieren, was plakativ mit „Hey Joe…“ beschrieben wird.

Das Hey Joe-Prinzip spielt in Softwareentwicklungs- und auch in anderen Projekten oft eine gewichtige Rolle. Was dahinter steckt habe ich heute in einem anderen Blog geschrieben. Deshalb verweise ich einfach auf den Artikel auf PHPhatesme:

PHPhates.me: Das HeyJoe Prinzip

Keine ähnlichen Beiträge.