Agile Softwareentwicklung „tickt“ anders als gewohnt: Statt brav sequentiell im Wasserfallmodell Anforderungsanalyse, Konzeption, Umsetzung, Test und Produktivsetzung abzuarbeiten, wird mit vielen kleinen iterativen Zyklen gearbeitet.
Aber mal ehrlich: das Wasserfallmodell haben wir doch schon lange nicht mehr so genau genommen. Die Überlappung von Phasen, mitunter auch ein zyklisches Springen zwischen den Phasen gehören längst dem Projektalltag an.
Insofern ist es nur konsequent dieser Realität auch methodisch gerecht zu werden, z.B. mit SCRUM, einem Methodenset der agilen Softwareentwicklung, bzw. einem Projektmanagementframework für agile Projekte.
Diese Darstellung agiler Softwareentwicklung ist zugegebenermaßen reichlich verkürzt. Um der Sache halbwegs gerecht zu werden hier wenigstens noch der Link zur zugrundeliegenden Philosophie: dem Manifesto for Agile Software Development.

„Als Rettungsversuch für ein in Not geratenes Projekt sollten Sie keinesfalls skalieren oder verteilen. Ist der Fertistellungstermin der Software unrealistisch, sind die Anforderungen nicht verstanden oder Architektur. und Technologieauswahl nicht tragfähig, so verschlimmert das Hinzufügen von neuen Mitarbeitern oder von weiteren Standorten die Situtation. Dies besag Brooks Law: ‚Adding manpower to a late software project makes it later'(…). Bedenken Sie: Neue Mitarbeiter können erst nach einer Einarbeitungsphase produktiv mitarbeiten. Ist ein Projekt in Schwierigkeiten geraten, so sollten Sie eine Ursachenforschung betreiben und dann die richtigen Maßnahmen ergreifen.“

aus Roman Pichler, Scrum – Agiles Projektmanagement erfolgreich einsetzen. Heidelberg 2008, S. 128 (Amazon Affiliate Link)

Ein weiser Ratschlag von Roman Pichler, der nicht nur für agiles Projektmanagement, sondern grundsätzlich gilt:

„Bevor Sie mächtige Software zum Planen und Verfolgen Ihres (…)-Projekts einsetzen, empfehle ich Ihnen, zunächst mit einfachen Hilfsmitteln und händisch die Pläne und Berichte zu erstellen. So stellen Sie sicher, dass Sie das Planen und Verfolgen beherrschen, bevor Sie sich von softwarebasierten Werkzeugen abhängig machen.“

aus Roman Pichler, Scrum – Agiles Projektmanagement erfolgreich einsetzen. Heidelberg 2008, S. 79 (Amazon Affiliate Link)

Mindjet, der Hersteller der Mind Map-Software Mindmanager bietet kostenlos eine Sammlung von englischsprachigen Mindmaps zu vielen Themen, u.a. Beispiele für die Projektplanung und Risikoassessment, zum Download an.
Ebenfalls kostenlos erhältlich ist ein Viewer, so dass auch nicht Mindmanager-Besitzer diese Mind Maps nutzen können. Mit dem Viewer ist es allerdings nicht möglich die Mind Maps zu verändern und weiterzuentwickeln.

Im vorangegangenen Beitrag schwingt latent eine Frage mit:

Wann ist ein Projekt erfolgreich?

Zunächst hört sich diese Frage trivial an. Ein Projekt ist erfolgreich, wenn der Projektauftrag zeit-, termin- und kostengerecht umgesetzt ist.

Ist dem wirklich so?

Diese Liste hat keinen Anspruch auf Vollständigkeit. Es finden sich sicher noch weitere „Erfolgs-Fälle“.

In der aktuellen Ausgabe des Projektmagazins findet sich ein Praxisbeitrag (nur für Abonnenenten, ansonsten kostenpflichtig) des Internet-Providers 1&1 mit einer provozierenden These: Projekte, die auf allzuviel PM-Methodik verzichten, sind tendenziell erfolgreicher als Projekte mit ausgeprägter PM-Methodik, wenn die Schlüsselfaktoren Mitarbeiterverhalten und Vertrauen gegeben sind.

In meiner persönlichen Interpretation deckt sich dies mit meinem Plädoyer für Selbstorganisation in Projekten. PM-Methodik ist natürlich sinnvoll, wer es aber schafft, den gesunden Menschenverstand der Beteiligten und ihre soziale Kompetenz zu nutzen, ist noch erfolgreicher. Der Artikel verdammt auch keine PM-Methodik, sondern weist auf die zentrale Bedeutung der Schlüsselfaktoren also von Soft-Skills im Projektmanagement hin.

Im Artikel wird aber noch auf einen zweiten Aspekt verwiesen:
PM-Methodik fokussiert sehr stark auf den Zielvereinbarungsprozess zwischen Auftraggeber und Auftragnehmer. Dabei werden zahlreiche Kompromisse geschlossen. Gemäß PM-Methodik ist ein Projekt erfolgreich, wenn diese Ziele erreicht werden. Die Ziele decken sich aber nicht mehr mit den ursprünglichen Erwartungen der Beteiligten. PM-Methodik verleitet dazu, dass man sich mit den Kompromissen zufrieden zeigt und die maximale Abdeckung der eigentlichen Erwartungen vernachlässigt, selbst wenn mehr erreichbar gewesen wäre. Stellt dies die Zielarbeit und Scopedefiniton in Frage? Nein, nicht wirklich, vielmehr wird die Bedeutung der „richtigen“ Ziele betont.

Ein wesentlicher Punkt wird im Beitrag gar nicht erwähnt:
Das Unternehmen besitzt bereits eine ausgeprägte Projektkultur! Die Mitarbeiter kennen Projektarbeit und sind es gewohnt eigenverantwortlich in Projekten zu arbeiten. Nur weil Projektarbeit im Unternehmen bereits etabliert ist, war die Untersuchung von zahlreichen Projekten, die dem Beitrag zugrunde liegt, erst möglich.

Christian Henner-Fehr macht in seinem Blog Das Kulturmanagement auf einen Beitrag von Thomas Albrecht aufmerksam, der u.a. zeigt wie die Frage „Wozu?“ als Leitfrage bei der Projektplanung dienen kann. In der Praxis wird das „Wozu?“ häufig durch ein „Warum?“ verdrängt. Bei der Planung geht es aber nicht nur um den Aufbau von reinen Kausalketten, sondern auch um die Frage nach dem Sinn und Zweck – nämlich dem Projektauftrag.

Abseits der bekannten Definitionen von Projekten (siehe auch Wikipedia), lassen sich Projekte auch als soziale Systeme interpretieren. Projekte können als ein Organisationsform sozialer Systeme für komplexe Aufgabenstellungen verstanden werden.

Einige vorangegangene Beiträge auf schlossbBlog haben sich bereits mit dem Thema Projektplanung und insbesondere den Grenzen der Planung beschäftigt.

Hier wird die Interpretation von Projekten als sozialen Systemen wieder interessant:

In der Theorie sozialer Systeme gibt es das Konzept der Autopoiesis. Autopoiesis (Begriffserklärung in Wikipedia) beschreibt die Selbstorganisation sozialer Systeme. In der täglichen Projektarbeit stellt sich die Frage, wie sich solche Selbstorganisationsmechanismen gezielt nutzen lassen. Die Antwort liegt auf der Hand: in der Schaffung einer entsprechenden Projektkultur, die die erforderlichen Freiräume zur Selbstorganisation sicherstellt. Das heißt z.B. für die Planung eines komplexen Projekts, dass diese nicht auf den Level von mehreren Tausend Tasks oder mehr heruntergebrochen werden muss, sofern die Selbstorganisation auf diesen Ebenen gewährleistet ist. Ein Planungsmonster von tausenden Zeilen ist nicht mehr aktuell pflegbar und ein solches Projekt wahrscheinlich mehr tot als lebendig.

Die Forderung: „Selbstorganisation statt Planung“ ist zugegebenermaßen ketzerisch und so nicht haltbar. Auch kleinere Teileinheiten können und müssen ihre Tasks sehr wohl planen. Dies muss aber nicht unbedingt in einer zentralen Gesamtplanung geschehen. Eine solche Planung muss nicht unbedingt deren formalen Anforderungen genügen, kann mitunter auch kurzfristig erfolgen und ist weitaus flexibler.

In der klassischen Projektplanung werden die Beziehungen zwischen einzelnen Tasks in Form von Abhängigkeiten abgebildet. Für den Projekterfolg entscheidend ist aber weniger deren formale Abbildung als das entsprechende Bewußtsein der Beteiligten und die Berücksichtigung im Handeln. Anderenfalls erklären Abhängigkeiten nur die Gründe für das Scheitern. Ein solches Bewußtsein, das Ansprechen und Aufgreifen der „richtigen Themen“ ist der Schlüssel zum Projekterfolg und führt uns wieder zurück zur Theorie sozialer System, insbesondere zu den Arbeiten von Niklas Luhmann (Wikipedia), der soziale Systeme über die Kommunikation definiert. In diesem Sinne liegt in der Kommunikation der Schlüssel zum Projekterfolg (aber auch der Schlüssel für eine erfolgreiche Planung 🙂 ).

Als Schlusspunkt dieser Reihe mit Beiträgen zur Planung noch ein Thesenkatalog über die Grenzen der Planung:

Die Abbildung von Abhängigkeiten in der Projektplanung ist ein zweiseitiges Schwert. Einerseits ist die Kenntnis von Abhängigkeiten erforderlich, um Auswirkungen des Verlaufs von Arbeitspaketen aufeinander abschätzen, sowie Termine und Kosten automatisch bei Planänderungen aktualisieren zu können, auf der anderen Seite sprengt die damit verbundene Komplexität regelmäßig die Projektplanung.
Die Abbildung von generischen Abhängigkeiten – meist auf einem sehr hohen Level – ist zwar noch einfach, ihre Aussagekraft hingegen tendiert gegen Null und grenzt an Trivialität, ja, sie ist mitunter sogar falsch. Einerseits erscheint es logisch, dass die Konzeption abgeschlossen sein muss, bevor eine Realisierung beginnen kann, diese muss wiederum abgeschlossen sein, bevor ein Test erfolgen kann, etc., aber die Wahrheit sieht anders aus, zumindest in einer schnelllebigen Zeit wie der unseren, in der viele Aktivitäten parallelisiert werden. Natürlich muss die Konzeption nicht vollständig abgeschlossen sein, bevor ene Realisierung beginnenen kann. Zunächst sind nur gewisse Eckpunkte erforderlich, die parallel zur Realisierung noch um die fehlenden Details zu ergänzen sind, usw., d.h. aber auch dass eine Pflege von Abhängigkeiten in einer Planung nur dann sinnvoll möglich ist, wenn man die Planung bis auf die kleinste erforderliche Planungeinheit herunterbricht. Dies kann mitunter eine Planung unbeherrschbar machen. Die Planungstiefe und die Detaillierung wird schnell zum Problem.
Für komplexe Planung gab mir einst ein auf MS Project spezialisiertes deutsches Systemhaus mit auf den Weg, dass sie ihren Kunden in komplexen Problemen von der Pflege von Vorgänger-/Nachfolgerbeziehungen (und in solchen werden Abhängigkeiten abgebildet) in den dafür vorgesehenen Feldern abraten würden. Wenn sie diese Beziehungen abbilden, dann würden sie Textfelder hierfür missbrauchen, damit die Plandatei noch pflegbar bleibt.
Natürlich ist es trotzdem sinnvoll, ja auch erforderlich sich mit Abhängigkeiten auseinanderzusetzen. Entscheidend ist, dass in einem Projekt alle voneinander abhängigen Parteien miteinander reden und sich ihrer Abhängigkeiten bewußt sind. Die Abbildung in der Planung ist hingegen eher ein Formalie und darf nur soweit gehen, dass sie den Rahmen der Planung nicht sprengt. Hierfür gibt es aber auch alternative Konzepte, wie z.B. eine DEBI-Matrix, in der je Arbeitspaket definiert wird welche Partei für die Durchführung zuständig ist, wer ein Paket zu verantwortden und darüber zu Entscheiden hat, wer lediglich Beratend mitwirkt und wer Informiert werden sollte.