reading

Die Texte und Illustrationen sind urheberrechtlich geschützt. Eine Vervielfältigung, Verbreitung oder Übertragung darf auch auszugsweise ohne Einwilligung der Autoren nicht vorgenommen werden.

Danke!

Es gehört für uns zu den schönsten Dingen im Leben, die Zeit mit etwas zu verbringen, woran wir glauben, was uns begeistert und worauf wir stolz sind.

Dazu gehört die Arbeit an diesem Buch. Auf diesem Weg wurden wir unterstützt von Michel Vergères, der mit seinen klaren Analysen und Rückmeldungen in spannenden Diskussionen wesentlich zu dessen Qualität beigetragen hat. Genauso viel Qualität hat das Buch sprachlich gewonnen durch unseren Lektor von Books on Demand.

Nicht zuletzt ein großer Dank unseren Familien, die uns den notwendigen Freiraum zugestanden haben.

INHALT

Warum dieses Buch?

Gemäß der CHAOS-Studie der Standish Group liegen die Chancen, ein IT-Projekt erfolgreich abzuwickeln, bei niedrigen 30%. Daran hat sich in den letzten 20 Jahren leider nicht viel geändert, obschon man seit Jahrzenten vergeblich versucht, die erfolgreichen Fertigungsprozesse aus der Industrie in die Welt der Software-Erstellung zu transferieren. Software ist einmalig und lässt sich nicht maschinell erstellen, vielmehr ist sie zu einem wesentlichen Teil Peopleware. Der Mensch macht den Unterschied, nicht der Prozess. Dieser ist zwar ebenfalls zwingend notwendig, jedoch nicht ausreichend. Es genügt also nicht, eine etablierte Projektmanagementmethode zu kopieren, ohne die Essenz des eigenen Softwareprojektes verstanden zu haben. Deshalb gilt stets das Motto: Kapieren statt Kopieren.

Daher geht es uns in diesem Buch nicht darum, eine weitere Projektmanagementmethode zu beschreiben. Von diesen gibt es unzählige. Die meisten sind sinnvoll und unter bestimmten Voraussetzungen erfolgreich. Unser Anliegen ist es, dich bei der für dein Projekt richtigen Wahl des Prozesses und der Methoden zu unterstützen.

Leider stützt man sich viel zu oft auf eine Projektmanagementmethode, die gerade angesagt ist und die man unbedingt anwenden muss, um mitreden zu können. Dies führt zu der absurden Situation, dass man, ohne die genauen Hintergründe zu kennen, deren Methoden und Checklisten anwendet.

Was ist so schlecht an Checklisten, dass man sie verbannen muss? Sie sind Sammlungen von wichtigen oder sogar essenziellen Aspekten, zusammengetragen von intelligenten und fachkundigen Personen. Sie stellen sicher, dass Erfahrungen aus der Vergangenheit einfließen und nichts vergessen wird. Was also soll daran so falsch sein? Nichts, außer man wendet sie unreflektiert an. Bequem, wie wir alle sind, besteht nämlich die Gefahr, dass das Verstehen und Denken ausgeschaltet wird und nur noch das sture Abarbeiten der vielen Punkte auf der Checkliste im Vordergrund steht.

Jeder Checklistenpunkt macht in einem gewissen Maße Sinn. Arbeiten wir diese der Reihe nach ab, setzen wir wahrscheinlich mehr um, als notwendig wäre. Doch ohne zuerst die Bedürfnisse des eigenen Projekts erkannt zu haben, kann nicht beurteilt werden, welche der Punkte auf einer Checkliste relevant sind und welche nicht. Eventuell fehlen sogar wesentliche Aspekte, die nur auf dein Projekt zutreffen.

Genauso verhält es sich im Projektmanagement. Wenn man die Essenz im Projektmanagement verstanden hat, lässt sich leichter beurteilen, was im konkreten Projekt hilfreich sein wird. Bevor also irgendein Prozess oder eine Methode kopiert wird, sollte man verstehen, um was es im eigenen Projekt wirklich geht. So hat man bessere Chancen, mit minimalen Mitteln die expliziten Anforderungen und impliziten Erwartungen der Stakeholder zu erfüllen.

Da jedes Projekt von Natur aus einem individuellen Charakter aufweist, gibt es folglich nicht die eine Projektmanagementmethode, die genau auf dein Projekt passt und alle deine Probleme lösen würde. Daher ist es umso wichtiger, die angewendeten Methoden zu verstehen. Beispielsweise spielt es keine große Rolle, in welchem Dokumentenmanagementtool man seine Dokumente verwaltet. Es spielt aber eine Rolle, ob man sie versioniert verwaltet oder einfach nur lokal herumliegen hat. In diesem Sinne wollen wir hier nicht Werkzeuge empfehlen oder gar vergleichen, sondern auf wesentliche Tugenden hinweisen, die für den Projekterfolg wichtig sind.

Mit diesem Buch wollen wir die Essenz im Projektmanagement hervorheben, nämlich die Elemente, die man nicht weglassen sollte. Es geht also um die Erkenntnis, warum etwas gemacht werden soll, oder anders formuliert, es geht um kapieren statt kopieren.

Das Buch ist bewusst kompakt gehalten und soll Tipps zu den wesentlichen Projektmanagementbereichen geben, die, zweckmäßig angewendet, den Projekterfolg positiv beeinflussen werden. Es richtet sich eher an Leserinnen und Leser, die bereits etwas Erfahrung im Projektmanagementumfeld gesammelt haben, um so das Ganze besser verstehen und einordnen zu können. Zudem haben wir dieses Buch bewusst in der Du-Form geschrieben, weil es dich hoffentlich so direkter anspricht und motiviert, das eine oder andere hier Gesagte und Empfohlene im eigenen Projekt anzuwenden – darauf kommt es schlussendlich an.

Wir sind überzeugt, dass dieses Buch hilfreiche, kompakte und kurzweilige Tipps mit einigen Aha-Effekten rund ums Projektmanagement bietet.

Projektmanagement auf einen Blick

Gibt es das überhaupt? Der Definition nach ist ein Projekt endlich und einzigartig. Basierend auf dieser Einzigartigkeit, kann folglich kein vorgefertigtes Vorgehensmodell deinem Projekt umfassend gerecht werden. Trotzdem sind in den letzten Jahrzehnten viele Vorgehensmodelle entstanden, die genau das von sich behaupten. Diese erstrecken sich von einfachen agilen Managementmethoden (z. B. Scrum) bis zu umfassenden Prozessmodellen, welche durch behördliche und normative Vorgaben geprägt sind (z. B. PRINCE2). Es ist also nicht unsere Absicht, hier einen weiteren heilsbringenden Prozess vorzustellen. Vielmehr haben wir uns Gedanken darüber gemacht, was allen Softwareprojekten gemeinsam ist. Was ist das absolute Minimum, die Essenz, die allen Softwareprojekten gerecht wird?

Es ist in keiner Weise unsere Absicht, die etablierten Vorgehensmodelle zu kritisieren oder kleinzureden. Alle haben ihre Daseinsberechtigung, sofern man sie richtig einsetzt. Doch unsere Erfahrungen haben gezeigt, dass ein blind übernommenes Vorgehensmodell selten eine echte Unterstützung bietet. Auch noch so viele Vorgaben, Templates, Quality-Gates oder Checklisten garantieren keinen Projekterfolg. Häufig lenken diese lediglich von der eigentlichen Problemstellung ab. Man kümmert sich zu sehr um Prozessthemen, welche unter Umständen viel Zeit in Anspruch nehmen, während die Lösung der eigentlichen Problemstellung keinen Schritt vorankommt.

Mit anderen Worten: Wer blind und unreflektiert ein bestehendes Vorgehensmodell übernimmt, ohne daran die für sein eigenes Projekt notwendigen Anpassungen vorzunehmen, hat das Projektmanagement nicht vollumfänglich verstanden. Doch welche Anpassungen braucht nun das Vorgehensmodell für mein Projekt? Um diese Frage beantworten zu können, muss man zuerst sein Projekt in all seiner Komplexität erfassen. Dies nimmt dir kein Vorgehensmodell ab. Man kommt somit am Denken nicht vorbei!

Unser Ansatz beruht auf der Überzeugung, dass alle Softwareprojekte eine gemeinsame Basis haben. Dies bedeutet, dass es eine Anzahl von Gemeinsamkeiten gibt, die in allen Projekten vorkommt. Die alleinige Erfüllung dieser minimalen Gemeinsamkeit garantiert zwar längst nicht den Projekterfolg, ist aber eine zwingende Notwendigkeit und kann folglich nicht vernachlässigt werden. Aus unserer Sicht haben alle Softwareprojekte mindestens Folgendes gemeinsam:

Wie kommt man nun am besten zum Vorgehensmodell für das eigene Projekt? Man könnte hingehen und ein etabliertes Vorgehensmodell so zurechtschneidern (Top-down-Ansatz), bis es für das eigene Projekt passt. Ja, das ist möglich, birgt aber die Gefahr, dass man zu viel mitnimmt, weil man unsicher ist, ob man es evtl. doch noch brauchen könnte. Dies ist genau dann der Fall, wenn man sich zuvor nicht die Zeit genommen hat, das eigene Projekt umfassend zu verstehen. Zudem lässt sich aus den etablierten Vorgehensmodellen die eigentliche Essenz des Projektmanagements nicht so einfach erkennen, da häufig die jeweiligen Besonderheiten des Vorgehensmodell in den Vordergrund gerückt werden.

Eine andere Möglichkeit wäre der Bottom-up-Ansatz. Geht man davon aus, das allen Softwareprojekten, wie oben beschrieben, eine minimale Anzahl von Gemeinsamkeiten aufweisen (Phasen, Rollen, Artefakte), wird die Essenz des eigenen Projekts deutlich erkennbar. In der nachfolgenden Abbildung 1 haben wir versucht, das darzustellen. Die projektspezifischen Eigenheiten können respektive müssen noch ergänzt werden. Ja, dies erfordert etwas Erfahrung und mag im ersten Moment abschrecken, doch der Top-down-Ansatz erfordert mindestens so viel Erfahrung und Arbeit – glaube uns.

Abbildung 1: Projektmanagement auf einen Blick

Projekte erfolgreich ins Ziel führen

Als Projektleiter kannst du dich also an diesem minimalen Vorgehensmodell orientieren und es um deine Projektspezifika erweitern. Das Vorgehensmodell gibt dir dabei eine Leitlinie für die Umsetzung deines Projektes. Um als Projektleiter aber erfolgreich zu sein, genügt das noch nicht ganz, denn genauso wichtig wie der methodische Teil sind die zwischenmenschlichen Aufgaben im Zusammenhang mit dem Team, den Stakeholdern, der Qualitätskultur oder dem Projektmarketing. Auch diese Themen tragen zum Projekterfolg wesentlich bei und beinhalten Essenzen.

Hast du die aus dem Grundvorgehensmodell und den zwischenmenschlichen Aufgaben hervorgehenden notwendigen Essenzen verstanden, bist du für deine kommenden Projekte sehr gut gerüstet. Trotzdem bleibt noch eine letzte Essenz, die du aber selbst mitbringen musst: Aktiv sein!