IT-Projektmanagement: Was wirklich funktioniert – und was ... · 59 3 Kapitel 3 Wie am Schnürchen wieProjekte ablaufen (sollen) Viele Steine, müde Beine, Aussicht keine, Heinrich

LeseprobeEntwicklungsleiter Matthias Geirhos zeigt Ihnen, wie Sie Ihre Projekte auf Kurs bringen. In dieser Leseprobe erhalten Sie jede Menge Tipps, wie Sie Ihr IT-Projekt von A bis Z planen und strukturieren sollten. Zudem bietet Ihnen diese Lesepro-be das komplette Inhaltsverzeichnis und den Stichwort-Index.

Matthias Geirhos

IT-Projektmanagement: Was wirklich funktioniert – und was nicht235 Seiten, broschiert, 2. Auflage 2016

12,90 Euro, ISBN 978-3-8362-4098-7

www.rheinwerk-verlag.de/4097

»Wie Projekte ablaufen (sollen)«

Inhaltsverzeichnis

Index

Der Autor

Leseprobe weiterempfehlen

Wissen, wie’s geht.

https://www.rheinwerk-verlag.de/it-projektmanagement_4097/?GPP=lpn

mailto:?body=Leseproben-Empfehlung:%20%C2%BBIT-Projektmanagement:%20Was%20wirklich%20funktioniert%20%E2%80%93%20und%20was%20nicht%C2%AB%20von%20Rheinwerk,%20http://gxmedia.galileo-press.de/leseproben/4097/leseprobe_rheinwerk_it-projektmanagement.pdf&subject=Leseprobe:%20%C2%BBIT-Projektmanagement:%20Was%20wirklich%20funktioniert%20%E2%80%93%20und%20was%20nicht%C2%AB

59

3

Kapitel 3

Wie am Schnürchen –

wie Projekte ablaufen (sollen)

Viele Steine,

müde Beine,

Aussicht keine,

Heinrich Heine.

»So ein Unsinn! Wozu soll ich etwas planen, wenn mich das Leben morgen

schon wieder überholen wird?« Aussagen wie diese hört man häufiger. Da

hat man mit viel Mühe einen Plan gezimmert, nur um zu sehen, wie er

langsam dahinbröselt oder gar in lautem Getöse zerbirst.

Und IT-Projekte, gehen die nicht sowieso immer schief? Gibt es überhaupt

ein IT-Projekt, das jemals im Plan war? Oder, wie mir einmal offenbart

wurde: »Ohne IT-Projektmanagement scheitern viele IT-Projekte, mit al-

lerdings auch.« Bevor dieses Buch als Unterleger für wackelige Tischbeine

endet (das würde mich arg treffen), lesen Sie bitte weiter.

Zunächst aber der gesamte Zyklus eines Projektes im Überblick:

Abbildung 3.1 Der Kreislauf von Projekten

Durch-führung

Kontrolle

Anpassung

Projekt-abschluss

Nach-betrachtung

Folge-projekt

Projekt-idee

Projekt-antrag

Projekt-auftrag

KickoffProjekt-planung

4098.book Seite 59 Dienstag, 8. November 2016 10:02 10

60

3 Wie am Schnürchen – wie Projekte ablaufen (sollen)

Von den ersten Phasen war schon die Rede, hier geht es nun um Planung,

Kontrolle, Anpassung und den Projektabschluss; zuerst im Überblick, De-

tails finden Sie jeweils in eigenen Kapitel weiter hinten in diesem Buch.

3.1 Der Sinn von Projektplanung – wie vorhersagbar sind Projekte?

Es ist schon wahr. In der Wirtschaft grassiert immer noch die schlechte

Angewohnheit der Planungsgläubigkeit. Der Glaube, man könne ein Pro-

jekt bis zum Ende gedanklich vorwegnehmen ist aber ebenso falsch wie

der Glaube, ohne Projektplanung ginge es ebenso gut. Wofür sind Projekt-

planung und Projektmanagement also eigentlich gut?

Die Top-7-Gründe für Projektmanagement

1. Ohne scheitern weit mehr Projekte als mit (wirklich!).

2. Projektmanagement macht Komplexität beherrschbar, durch das

Herunterbrechen komplexer Vorgänge und durch die Transparenz,

die ein Projektplan mit sich bringt.

3. Ein Projektplan ist ein Führungsinstrument, Projektmanagement

ist gelebte Führung. Ohne Projektmanagement ist eine längerfris-

tige, koordinierte und zielgerichtete Zusammenarbeit kaum denk-

bar.

4. Ohne Projektmanagement und ohne Projektplanung wird es kaum

jemanden geben, der Zeit und Geld in eine Sache investiert.

5. Ohne Projektplanung wissen Sie nicht, ob Sie auf Kurs sind oder

jemals waren.

6. Gutes Projektmanagement besteht aus Best Practices, also aus dem

Erfahrungswissen unzähliger Projektleiter vor Ihnen.

7. Wenn verschiedenste Fach- und Führungskräfte interdisziplinär an

einer Sache arbeiten sollen, dann werden Spielregeln benötigt, die

das Projektmanagement festlegt.


61

3.1 Der Sinn von Projektplanung – wie vorhersagbar sind Projekte?

3

Ich könnte noch mehr nennen, der Seitenzahl des Buches wegen hoffe ich

aber, dass diese Liste genügt.

Die negative Einstellung vieler Menschen gegenüber dem Projektmanage-

ment hat ihre Ursache oft in einem völlig falschen Verständnis darüber –

und einigen prominenten Projektdisastern, die in den Medien weidlich

zelebriert wurden. Sie glauben an das alte Wasserfallmodell, wie in der fol-

genden Abbildung dargestellt.

Abbildung 3.2 Wasserfallmodell

Dieses Modell ist nicht totzukriegen, auch 60 Jahre nach dessen Ein-

führung nicht. Dabei haben doch schon die Erfinder vor dem Einsatz ge-

warnt und es als fehlerträchtig und risikobehaftet beschrieben.

Der Reiz liegt in den Phasen, die klar voneinander getrennt sind. Geplant

ist geplant, und später könne man sich für alle Zeit auf die Planung verlas-

sen. Dabei wissen wir doch alle, dass wir häufig nicht einmal den Familien-

ausflug für nächsten Samstag verlässlich planen können. Wie soll dann

eine Planung über Monate oder gar Jahre möglich sein? Aber gilt nicht

auch: Wie wahrscheinlich ist ein größerer Familienausflug, wenn Sie ihn

nicht rechtzeitig planen?

Vorbereitung

Analyse

Planung

Realisierung

Einführung

Wartung


62


Dann gibt es natürlich noch die andere Fraktion, die »Agilen«. Auch hier

sind viele Missverständnisse am Werk. Und so hört man schon einmal:

»Mit agilen Methoden müssen wir uns nicht mehr festlegen, sondern sind

zu jeder Zeit flexibel. Die Planung entsteht gewissermaßen beim Gehen.«

Agilität bedeutet nicht das Fehlen jeder Planung, sondern akzeptiert, dass

nicht der gesamte Weg im Voraus bekannt ist und dass im Laufe des Pro-

jektes Wissen und Planungssicherheit zunehmen. Und zudem, dass die

Wünsche und Bedürfnisse sich während des Projektes ändern können

(und vermutlich werden). Agilität braucht einen Rahmen, innerhalb des-

sen sie einen Sinn ergibt. Denn jede Planung hat zwei Komponenten:

� Den Planungshorizont, also bis in welche Zukunft geplant wird.

� Die Planungstiefe, also wie detailliert die Planung ist.

Ein Projekt kann durchaus bis zum Ende durchgeplant werden; Je weiter

wir dabei in die Zukunft gelangen, desto gröber muss die Planung aber

zwangsläufig sein. Planung ist also ein fortlaufender Prozess – sie wird ste-

tig verfeinert, den neuen Gegebenheiten angepasst und so mit der Zeit

immer besser. Am besten ist sie freilich, wenn das Projekt vorüber ist, aber

diese Qualität ist gar nicht notwendig, um von Nutzen zu sein. Manchmal

erweist sich der eingeschlagene Weg als falsch – dann ändern wir ihn. Die

meiste Zeit über wird die Planung aber von hohem praktischen Nutzen

sein; als Führungsinstrument für Sie, als Handlungsrahmen für Ihr Pro-

jektteam, als Diskussionsgrundlage mit dem Auftraggeber, als Gedan-

kenstütze für alle und, besonders zum Ende hin, auch als Dokumentation.

Das leistet die Planung, und dort liegen auch ihre Grenzen. Ein Plan ist ein

Werkzeug, nichts weiter. Und Projektmanagement die Kunst, mit diesem

Werkzeug (und vielen anderen Werkzeugen) etwas zu schaffen – im Team

und unter Einhaltung (relativ) starrer Rahmenbedingungen. Und das,

während sich die Welt während des Projektes beständig weiterdreht.

3.2 Auf Los geht’s los

Vielleicht erinnern Sie sich noch an die gleichnamige Fernsehshow in den

70er und 80er Jahren. Niemand wäre dort auf die Idee gekommen, den Zu-

schauer über den Startzeitpunkt eines Spiels im Unklaren zu lassen. Er-


63


3

staunlicherweise geschieht das bei Projekten recht häufig, so dass viele

Projekte loslegen, ohne dies zu wissen und daher auch ohne vom Fleck zu

kommen.

Auf die Frage: »Hat das Projekt schon begonnen?« ist die einzig mögliche

Antwort: »Ja, der Startzeitpunkt war das Kick-off-Meeting am letzten Mitt-

woch. Dort wurde der Projektauftrag besprochen. Das haben wir dort doch

entschieden!« (natürlich, Donnerstag ist auch möglich).

Die Literatur kennt verschiedene solcher Anfangszenarien. Ich bin da

recht pragmatisch und definiere den Projektstart wie folgt:

»Ein Projekt beginnt, wenn der Auftraggeber einen Projektauftrag

erteilt und der Projektmanager ihn akzeptiert (also unterschrieben)

hat.«

Ein solcher Projektauftrag muss schriftlich erfolgen. Wie ein Projekt dort-

hin gelangt, ist unwesentlich. Größere Unternehmen praktizieren häufig

einen eigenen Prozess, der mit dem Projektantrag beginnt, mit der Pro-

jektgenehmigung fortfährt und mit dem Projektauftrag endet. Genauso

wahrscheinlich ist es aber, dass Projekte spontan gestartet werden, zum

Beispiel im Rahmen einer Geschäftsführungssitzung.

Der Start ist auch eine wunderbare Gelegenheit mit dem »Alles-ist-ein-

Projekt-Mythos« aufzuräumen und die Projekteigenschaft abzuklären.

Auch wenn der Mythos schön klingt: In Kapitel 1 habe ich die Kriterien für

ein Projekt beschrieben. Und wenn Ihr Vorhaben diese Kriterien nicht er-

füllt, dann brauchen Sie auch keine Projektorganisation dafür aufzusetzen

und sollten dies auch nicht tun.

3.2.1 Der Projektauftrag

Wie auch immer ein Projektauftrag zu Stande kommt – die folgenden An-

gaben sind wirklich notwendig. Es gibt in der Praxis Fälle, in denen der

Projektauftrag nicht in der nötigen Qualität gefordert werden kann – dann

sollten Sie selbst einen solchen erstellen und vom Entscheider, dem Auf-

traggeber, unterzeichnen lassen. Besser ein guter Projektauftrag von Ih-

nen als ein schlechter vom Auftraggeber – oder gar keiner. Auch für den

Projektauftrag finden Sie auf www.rheinwerk-verlag.de/4097 eine Vorlage.


64


Inhalte eines Projektauftrags

� Projektbezeichnung: Eine griffige Bezeichnung für das Projekt, z. B.

»Ablösung des bestehenden Vertriebsinformationssystems Apollo«.

� Auftraggeber: Name desjenigen, der für das Projekt verantwortlich

zeichnet.

� Datum: Das Startdatum (s. o.)

� Ziele: Was sind die Ziele des Projektes? Diese Angabe ist besonders

wichtig, denn die gesamte Projektplanung ist darauf auszurichten.

Beispiel: »Steigerung der Effizienz im Vertrieb durch Einführung

eines neuen Vertriebsinformationssystems (VIS), das Schnittstellen

zu unserem ERP- und CRM-System aufweist. Die Vertriebsmitarbei-

ter sollen wenigstens 20 % mehr Besuchstermine vereinbaren und

neue Erlöspotenziale erschließen.« Bei größeren Projekten können

auch Teilziele formuliert werden, z. B. die Erstellung eines Pflichten-

heftes.

� Nicht-Ziele: Diese Angabe erscheint zunächst einmal unnötig. Ist

denn nicht alles, was nicht als Ziel formuliert wurde, automatisch

ein »Nicht-Ziel«? Ja, so sollte es sein. Aber häufig gibt es Bereiche,

die man explizit ausnehmen möchte. Beispiel: Das Vertriebs-Data-

Warehouse soll unverändert beibehalten werden. Das explizit zu

erwähnen, bringt Klarheit und setzt Grenzen.

� Begründung: Warum ist das Projekt notwendig? Hier sollten Hinter-

grundinformationen stehen. In unserem Beispiel könnten das die

Schwachstellen der bestehenden Anwendung sein. Die Begrün-

dung zeigt Ihnen die Denkweise des Auftraggebers.

� Gewünschtes Projektende: Ein festes Datum, zu dem der Auftragge-

ber sich das Ende des Projektes wünscht. Das ist keine verbindliche

Planung, sondern eben ein Wunschtermin. Es ist immer gut, wenn

Erwartungen möglichst spezifisch formuliert werden. Nur so kön-

nen Sie als Projektleiter darauf reagieren, zum Beispiel durch eine

dementsprechende Planung oder, auch das kommt häufiger vor,

indem Sie die Erwartungen noch einmal verhandeln.


65


3

� Budget bzw. Kostenschätzung: Nicht immer werden Sie zum jetzi-

gen Zeitpunkt schon ein Budget erhalten. Die meisten Auftragge-

ber legen sich nicht so früh fest. Sie wollen erst einmal etwas

sehen, bevor sie eine Entscheidung darüber treffen. Dann akzeptie-

ren Sie bitte auch eine grobe Schätzung der Kosten. Es geht hier

darum, ob die Vorstellungen von Ihnen und Ihrem Auftraggeber

überhaupt kompatibel sind.

� Projektleiter: Der Name des Projektleiters, also Ihr Name.

� Kontrollinstanz: Wer wird das Projekt kontrollieren, an wen berich-

ten Sie? Das kann der Auftraggeber sein, eine von ihm ernannte

Person oder ein Lenkungsausschuss.

� Kriterien für das Projektende: Ist das Projekt denn nicht zu Ende,

wenn die Projektziele erreicht sind? Doch, aber die Ziele sind dafür

meist nicht konkret genug. Näheres lesen Sie bitte unter Abschnitt

3.3. Beispiel: Das Ziel ist erreicht, wenn alle Vertriebsmitarbeiter

mit dem neuen System produktiv arbeiten und das alte System

»Apollo« nur noch für den Lesebetrieb zur Verfügung steht.

Projektaufträge sind nicht selten eine ungeliebte Angelegenheit. Aber

warum? Sie zwingen einen zur Klarheit und zur Festlegung. Sich nicht

festzulegen, vor allem in Hinsicht auf das Budget, kann erst einmal für alle

Seiten bequem sein. Dabei schiebt man wichtige Diskussionen aber nur

hinaus. Während ein Projektantrag entbehrlich sein kann, ist dies ein Pro-

jektauftrag niemals.

Aus der Praxis

Vor einem Jahr habe ich ein Projekt begonnen, das intern den Arbeits-

titel »Unicorn« trägt. Es besteht aus mehreren Teilprojekten, für die es

jeweils eigene Projektaufträge gibt. Und, wie so häufig, fing die Diskus-

sion mit dem Projektauftrag erst so richtig an: »Was, so teuer wird das?

Lassen sich die Meilensteine nicht nach vorne ziehen?« Oder auch: »Ich

dachte, das wäre schon in diesem Teilprojekt enthalten?«

Am Ende brauchte es drei Projektaufträge, bis Projektleiter und Auf-

traggeber unter dem Projekt dasselbe verstanden.


66


Und dennoch: Hüten Sie sich davor, es mit Details im Projektauftrag zu

übertreiben. Was habe ich nicht schon alles darin gelesen: Projektrisiken,

Ressourcenaufteilung, bewilligte Personalkosten, Projektphasen, Wirt-

schaftlichkeitsberechnungen usw. Wenn das alles schon vorher bekannt

ist: prima! Aber lassen wir die Kirche im Dorf. Der Projektauftrag steht am

Anfang. Wer noch vor der Projektplanung die Projektphasen benennen

kann, der ist entweder ein Genie, ein Prophet oder ein Scharlatan. Es ist

nicht das Ziel des Projektauftrags, die Planung vorwegzunehmen, sondern

die Planung darauf zu begründen.

Manchmal gibt es noch einige Formalien, die sich von Unternehmen zu

Unternehmen unterscheiden – zum Beispiel Projektnummern, die dann

als Kostenstellen eingerichtet werden oder die Zuordnung zu einem stra-

tegischen Unternehmensziel. Diese sollten Sie natürlich berücksichtigen.

Ein Muster für einen Projektauftrag finden Sie übrigens unter www.rhein-

werk-verlag.de/4097 bei den »Materialien zum Buch«, neben einigen wei-

teren Formblättern.

3.2.2 Die Entscheidung

Der Auftraggeber hat also ein Projekt vor. Damit ist es aber noch nicht ge-

nehmigt. Vielleicht benötigt er zuvor die Zustimmung der Geschäfts-

führung. In jedem Fall aber benötigt er Ihre Zustimmung, bevor er Sie als

Projektleiter festsetzen kann.

Viele, wirklich sehr viele, Projekte scheitern deshalb, weil sich Projektleiter

auf Projekte einlassen, die sie nicht überblicken können; oft deshalb, weil

sie sich nicht die nötige Zeit nehmen, den Projektauftrag zu verstehen

und zu durchdenken. Oder sie lassen sich zu einem Projekt drängen, das

im besten Fall als Himmelfahrtskommando bezeichnet werden kann.

Es ist ganz natürlich, dass ein Auftraggeber sportliche Ziele festlegt. Auch

solche Ziele, die unrealistisch sind. Woher soll er denn auch wissen, was

»realistisch« ist? Dazu benötigt er Sie! Seine Erwartungen sind jedenfalls

nicht in Stein gemeißelt, sondern sie sind seine Verhandlungsposition.

Was aber können Sie tun?


67


3

Tipps zur Verhandlung mit Ihrem Auftraggeber

� Sagen Sie niemals einfach »Das geht nicht!«. Bieten Sie eine Lösung

an, oder, wenn Sie noch keine haben, einen Vorschlag, wie Sie dort-

hin kommen können. Beispiel: »Unsere Erfahrungen aus dem letz-

ten CRM-Projekt haben gezeigt, dass wir mit so wenig Geld und Zeit

nicht auskommen werden. Ich schlage vor, dass wir gemeinsam mit

dem Projektleiter des CRM-Projektes sprechen. Er kann uns helfen,

zu einer Lösung zu kommen, die sportlich und realistisch ist.«

� Bereiten Sie sich unbedingt gründlich vor. Überlegen Sie schon ein-

mal, aus welchen groben Phasen das Projekt bestehen könnte. Las-

sen Sie den Auftraggeber erkennen, was er selbst alles übersehen

hat, ohne ihn mit der Nase darauf zu stoßen.

� Wenn möglich: Sprechen Sie mit anderen Projektleitern, die viel-

leicht schon über Erfahrungen in ähnlichen Projekten verfügen.

� Manchmal ist es einfach nicht möglich, ein Projekt sinnvoll abzu-

schätzen, einfach, weil es zu neuartig und/oder zu komplex ist. Das

ist Teil der Projektrealität und damit völlig in Ordnung! Vereinbaren

Sie dann eine Voruntersuchung oder stellen Sie die Erstellung des

Lastenheftes der Umsetzung voran. Machen Sie klar, dass dies

ohnehin notwendig ist und dass Sie sich erst dann festlegen kön-

nen, wenn Sie mehr Informationen haben.

Im Grunde genommen sind die Würfel damit gefallen, der unterzeichnete

Projektauftrag ist der offizielle Beginn des Projektes. Ab jetzt läuft die Zeit

und ab jetzt haben Sie Handlungsfreiheit, soweit es der Projektauftrag und

Ihre Stellung als Projektleiter zulassen. Der nächste Schritt ist damit aber

nicht weniger wichtig.

3.2.3 Die Kick-off-Veranstaltung

Ein häufiges Bild in Unternehmen: Das Projektteam wird vor vollendete

Tatsachen gestellt, ohne dass man ihm Gelegenheit gegeben hätte, Stel-

lung zu beziehen. Das ist eine Situation, die eine Abwehrhaltung geradezu

herausfordert. Und eine solche destruktive Einstellung können wir in Pro-

jekten am wenigsten gebrauchen!


68


Die Ziele des Kick-off-Meetings sind:

� Das Team soll verstehen, worum es bei dem Projekt geht, warum es

notwendig ist und was auf das Team zukommt. Das ist das Informati-

onsziel.

� Im Kick-off-Meeting wird das Projekt für die Mitarbeiter formal gestar-

tet, unter Beteiligung des Projektteams. Das ist das formale Ziel.

� Die Teammitglieder lernen sich untereinander kennen, gerade in

größeren Unternehmen ist das besonders wichtig. Das ist das soziale

Ziel.

� Die Teammitglieder sollen auf das Projekt eingestimmt werden, es mit-

tragen oder, im Minimum, keine Ablehnung dagegen entwickeln. Das

ist das wichtigste (Motivations-)Ziel.

Und so geht’s:

Steckbrief Kick-off-Meeting

Wer nimmt teil?

� Der Projektleiter

� Das Projektteam. In größeren Projekten muss das Kick-off-Meeting

vielleicht geteilt werden. In jedem Fall aber sollten alle Teammit-

glieder ins Boot geholt werden, es sei denn ihre Rolle beginnt erst

sehr viel später im Projekt oder ihre Rolle ist wirklich, wirklich klein.

� Der Auftraggeber, sofern Sie das für sinnvoll erachten. Der Vorteil:

Die Veranstaltung erhält eine verbindliche Note. Er signalisiert

seine volle Unterstützung und die wichtige Bedeutung des Projek-

tes. Der Nachteil: Die Diskussionen bleiben vielleicht aus und der

Auftraggeber übernimmt eventuell schnell informell die Führung

der Veranstaltung.

Wie wird die Besprechung vorbereitet?

� Sie laden rechtzeitig ein. Denken Sie bitte daran, dass die Bespre-

chung umso früher anberaumt werden muss, je mehr Teilnehmer

nötig sind – schon allein, um einen freien Termin zu finden.


69


3

� Setzen Sie die Besprechung auf eine Länge zwischen ein und zwei

Stunden an, je nach Teilnehmerzahl und je nachdem, wie kontro-

vers Sie die Diskussionen erwarten.

� Verteilen Sie vorab schon einmal die Agenda und eine grobe Pro-

jektübersicht. Aber erwarten Sie nicht, dass diese Informationen

von allen Teammitgliedern gelesen werden.

Wie sieht die Agenda aus?

� Sie wissen inzwischen, dass ich für eine Agenda aber meist gegen

feste Zeiten darin bin, den Start und das Ende der Veranstaltung

natürlich ausgenommen.

� Stellen Sie das Projekt kurz vor: Seine Entstehungsgeschichte, sei-

nen Umfang, warum es notwendig ist und was alle davon haben,

wenn es erfolgreich abgeschlossen wird.

� Wenn sich die Teilnehmer noch nicht kennen: Schieben Sie eine

kurze Vorstellungsrunde ein.

� Erläutern Sie wichtige Rahmenbedingungen: Wie lange dauert das

Projekt? Was wird es kosten? Und: Was gehört alles dazu?

� Klären Sie die Rollen der wichtigsten Beteiligten, also z. B.: Wer

gehört dem Lenkungsausschuss an, wer übernimmt etwaige Teil-

projektleitungen etc.

� Vereinbaren Sie wichtige Spielregeln und formulieren Sie auch Ihre

eigenen Erwartungen. Beispiele: Wie stellen Sie sich die Kommuni-

kation im Team vor? Oder: Wie stellen Sie das Projekt nach außen

hin dar?

� Lassen Sie nun Raum für Diskussionen und Rückmeldungen der

Teammitglieder.

� Geben Sie den offiziellen Startschuss für das Projekt und bedanken

Sie sich bei Ihrem Team für die Bereitschaft, Sie (und damit Ihr Pro-

jekt) zu unterstützen.


70


Was ist sonst noch wichtig?

� Behalten Sie die Zeit im Auge.

� Geben Sie eine Antwort auf die Frage: Warum können Sie das,

warum werden Sie das Projekt zum Erfolg führen?

� Kehren Sie die Risiken nicht unter den Teppich, überhöhen Sie diese

aber auch nicht.

� Geben Sie ruhig zu, wenn Sie etwas noch nicht wissen. Das ist

menschlich – jeder wird das verstehen.

� Gibt es bereits eine unheilvolle Projektvergangenheit? Dann den-

ken Sie darüber nach, ob Sie nicht einen externen Moderator um

die Moderation bitten.

� Achten Sie auf einen positiven Abschluss der Veranstaltung.

Und danach?

Danach beginnt das Projekt auch für Ihre Projektmitarbeiter. Aber vorher

sollten Sie noch ein kurzes Protokoll verfassen und an die Teilnehmer

schicken. In den meisten Projekten wird jetzt mit der Projektplanung be-

gonnen. Es gibt aber auch Fälle, in denen der Plan schon feststeht, bevor

das Kick-off-Meeting beginnt, dann können Sie ihn natürlich schon vorab

verteilen und (bitte nur kurz) vorstellen. Wichtig ist aber, dass zwischen

der Besprechung und dem für die Projektteilnehmer fühlbaren Projekt-

start nicht zu viel Zeit verstreicht – nutzen Sie den Schwung aus dem Kick-

off-Meeting.

Aus der Praxis

Ob Sie den Auftraggeber hinzu bitten oder nicht, dazu gibt es keine

feste Regel. Ich persönlich tue das meistens nicht. Es gibt meist auch

außerhalb des Kick-offs genügend Gelegenheit, dass der Auftraggeber

Sie und das Projekt vorstellt und seine Unterstützung signalisiert. Beim

Kick-off behalte ich gerne die volle Kontrolle. Für Sie als Projektleiter ist

es wichtig, als »Chef« des Projektes wahrgenommen zu werden.


71

3.3 Der Nebelkerzenradierer – die Projektplanung

3


Der Projektplanung ist ein ganzes Kapitel gewidmet, Kapitel 6. Daher kann

ich mich hier ein wenig kürzer fassen. In Abschnitt 3.1 habe ich zudem

schon ein wenig über die Rolle und die Grenzen der Projektplanung

erzählt.

Albert Einstein wird das Zitat zugeschrieben: Planung ersetzt den Zufall

durch den Irrtum. Witzig, aber unnötig pessimistisch. Ich würde sagen,

dass Projektplanung den Zufall durch die Möglichkeit der Standortbestim-

mung ersetzt, und das ist wiederum Voraussetzung dafür, eine Kurskor-

rektur einzuleiten.

Die Projektplanung kann schon vor dem Projektauftrag erfolgen, meist

ist sie aber der erste Schritt im neuen Projekt, häufig nach dem Kick-off-

Termin.

Grundsätze der Projektplanung

Ein Projektplan ist kein Selbstzweck. Er hat die Aufgabe, Unsicherheit

zu beseitigen, den Weg zum Ziel in machbare Einheiten zu unterteilen

und Verbindlichkeit in Form von Terminen zu schaffen. Er ist die Grund-

lage für die Zusammenarbeit zwischen Auftraggeber, Projektleiter und

Projektmitarbeitern.

Der Projektplan wird ausschließlich vom Projektleiter erstellt und ge-

pflegt, auch wenn er dafür natürlich die Hilfe anderer benötigt.

Ein Projektplan lebt und wird ständig den Gegebenheiten angepasst.

Er ist so konkret, wie es die Kenntnis des Lösungsweges zulässt, aber

nie konkreter, als es für die Sache notwendig ist. Nach hinten hin wird

er für gewöhnlich gröber, auf Sicht hingegen sind die Details umfas-

sender.

Ein Projekt wird also nur insoweit geplant, als sich daraus die nächsten

Schritte in die Wege leiten und auch kontrollieren lassen.

Die Projektplanung hat die Aufgabe, ein relativ komplexes Problem in

Teilschritte zu zerlegen, deren Abhängigkeiten und zeitliche Dimen-

sionen abzuschätzen und das schriftlich darzulegen. Außerdem sind


72


Ressourcen und Kosten ein zentrales Thema darin, weil sie für die Projekt-

steuerung einfach wichtig sind.

Mehr noch, ein Projektplan zwingt einen dazu, das Projekt erst einmal sys-

tematisch zu durchdenken und seine Gedanken zu ordnen, was eine gan-

ze Reihe an Fragestellungen aufwirft. Nicht alle lassen sich gleich zu Be-

ginn klären, manche begleiten einen das ganze Projektleben hindurch.

Wie schon gesagt, ist der Projektplan ein Werkzeug; eines, das ständig ver-

feinert und angepasst werden muss – wenn er gelebt werden und nicht in

den Akten ein Schattendasein fristen soll.

Der Projektplan ist außerdem auch eine wichtige vertragliche Grundlage,

auf deren Basis Projektleiter, Auftraggeber und Projektteam zusammenar-

beiten. Die dort enthaltenen Termine sind verbindlich, die dort verzeich-

neten Vorgänge spiegeln die Vorgehensweise wider. Die hinterlegten Kos-

ten dürfen nicht überschritten werden und die zugeordneten Ressourcen

müssen rechtzeitig zur Verfügung stehen. Nur so lässt sich ein Projekt

wirklich leiten. Wer bei jedem Vorgang neu verhandeln muss, der lähmt

sich und das ganze Projekt. Was geplant ist, kann zwar noch verändert

werden, ist aber zunächst einmal gesetzt.

Zu guter Letzt ist ein Projektplan eine Entscheidungshilfe. Vor allem,

wenn er in Bits und Bytes vorliegt, sagt er Ihnen, welche Auswirkungen die

Verzögerung einzelner Vorgänge auf das gesamte Projekt hat oder wie

sich Vorgänge besser neu anordnen lassen.

Wichtig: Ein Projektplan soll immer so detailliert sein, dass er seine Aufga-

ben erfüllen kann, aber nicht detaillierter.

Merkmale eines guten Projektplans

� Ein guter Projektplan ist immer aktuell.

� Er lebt.

� Er wird häufig in den Details, seltener in seinen groben Strukturen

geändert.

� Er ist so detailliert, dass er unmittelbar für das Controlling verwen-

det werden kann.


73


3

� Er ist aber nicht so detailliert, dass das Projektteam bei der Umset-

zung daraus keinen Vorteil mehr ziehen kann, weil das Team die

Details der Umsetzung selbst festlegt und ohnedies nicht alle

Details im Voraus bekannt sind.

� Er kann, ja, sollte Meilensteine enthalten, also mit Terminen verse-

hene, wichtige Teilziele des Projektes.

� Er spiegelt die Erfahrungen wider, die sich im Projektverlauf ange-

sammelt haben.

� Er ist wohl dokumentiert und so verständlich, dass Dritte damit

zurechtkommen, ein wenig geistigen Einsatz vorausgesetzt.

� Er gibt den Rahmen vor, lässt aber im Detail die Spielräume, die das

Projektteam braucht. Er bringt Planungssicherheit und Agilität

zusammen.

� Er enthält Vorgänge, Termine, Kosten, Ressourcen und Abhängig-

keiten. Die Kosten können aber auch außerhalb geplant werden.

� Er eignet sich vorzüglich für Berichte, gerade mit Softwarewerkzeu-

gen lassen sich eine ganze Reihe von nützlichen Standardberichten

direkt daraus generieren.

Die meisten Projektpläne sind phasenorientiert aufgebaut. Da gibt es eine

Vorbereitungsphase, eine Spezifikationsphase, eine Entwicklungsphase

usw. In der Praxis trifft man häufig auf agilere Modelle, wie besprochen,

bzw. auf eine mehr iterative Vorgehensweise. Wie man diese beiden Wel-

ten zusammenbringt, erfahren Sie in Kapitel 6. Dort erhalten Sie auch

viele weitere Informationen zur Planung.

Aus der Praxis

Dass ein Plan notwendig ist, dafür braucht es in der Praxis wenig Über-

zeugungsarbeit, das sehen die meisten Leute ein.

Schwieriger ist da schon die Einsicht, dass es einen Prozess zur Anpas-

sung des Plans braucht. Ich erlebe auch häufig, dass der Plan zwar

erstellt, aber nicht bekannt ist, nicht einmal dem Projektleiter selbst.


74


Gerade erst habe ich einem Mitarbeiter farbige Magnetstreifen

gekauft, so dass dieser seinen Plan am Whiteboard erstellen kann, wo

er ihn jeden Tag sieht. Besser ein gröberer, manuell geführter Plan, der

lebt und den man stets vor Augen hat, als ein Plan, der zwar mit elabo-

rierter Software erstellt, aber dann in irgendeinem Dateiverzeichnis

vergessen wird.

Planung hat viel mit Sichtbarkeit zu tun. Wer die Planung nicht pflegt,

hat ein Werkzeug erstellt, mit dem er nichts anfangen kann. Schade um

die schöne Zeit dafür.

3.4 Malochen mit Grips – Projektdurchführung und Projektcontrolling

Eines gleich vorweg: Der cocktailschlürfende Projektleiter im Liegestuhl

ist ein Mythos. Andererseits: Es soll schon vorgekommen sein.

Die Projektdurchführung verlangt vom Projektleiter ständige Präsenz, ein

wachsames Auge, kommunikative Fähigkeiten, ein wenig Marketinggetö-

se sowie Geduld und Ausdauer.

Grob gesagt ist die Projektdurchführung der immerwährende Dreiklang

zwischen

� dem Arbeiten an den Vorgängen,

� deren Kontrolle und

� der Anpassung des Plans aufgrund neuer Erkenntnisse,

so wie es Abbildung 3.1 zeigt.

Der Projektdurchführung und dem Projektcontrolling ist das gesamte Ka-

pitel 7 gewidmet. Dort finden Sie auch Tipps, wenn es im Projekt mal

klemmen sollte.

Hier beschränke ich mich daher auf die wichtigsten Grundlagen.


75

3.5 Geschafft! Der Projektabschluss

3

Zunächst: Was muss alles kontrolliert werden?

� Das Einhalten der vereinbarten Termine

� Die geforderte Qualität

� Der Umfang der geleisteten Arbeit

� Die laufenden und noch anfallenden Kosten

Die Kontrolle ist die bei weitem wichtigste Aufgabe des Projektleiters,

noch wichtiger als die Planung selbst – die ohnehin zu Lasten der Kontrol-

le häufig überschätzt wird.

Das soll nun aber nicht heißen, es gäbe keine weiteren Aufgaben mehr für

den Projektleiter. Die wichtigsten sind:

� Er muss Konflikte lösen, unterschiedliche Interessen ausgleichen und

sein Projektteam motivieren. Das sind seine bedeutendsten Führungs-

aufgaben.

� Er muss die Planung den sich verändernden Gegebenheiten anpassen.

� Die Auftraggeber und andere Führungskräfte wollen regelmäßig und

umfassend informiert werden.

� Das Projekt muss immer wieder angeschoben werden, wozu auch Pro-

jektmarketing gehört.

� Die Dokumentation ist mal mehr, mal weniger ausgeprägt – je nach

Unternehmen und Art des Projektes.

Näheres zum Projektleiter und den anderen Projektbeteiligten finden Sie

in Kapitel 5.


Mit dem Projektabschluss tun sich viele Auftraggeber sehr schwer. Das

liegt meist daran, dass es immer noch Arbeit gibt, die in ihren Augen zu

erledigen ist. Sie wollen den Projektleiter daher vorher nicht aus seiner

Verantwortung entlassen. In der Praxis führt das dann zu der äußerst frus-

trierenden Erfahrung, dass dem Projektleiter der Erfolg für seine Arbeit

verwehrt bleibt und das Projekt irgendwann einmal versandet, ohne je-

mals für beendet erklärt worden zu sein.


76


Das beruht aber auf dem Irrglauben, nach einem Projekt gäbe es nichts

mehr zu tun. Nichts aber könnte weiter von der Wahrheit entfernt sein!

Das Ende eines Projektes markiert nicht das Ende jeder Arbeit, sondern

das Ende derjenigen Phase, die eine Projektorganisation notwendig macht

und gleichzeitig den Beginn der nächsten Phase, meist die der Wartung,

manchmal auch einfach eine Phase der Nacharbeit.

Nehmen wir einmal unser obiges Beispiel, die Einführung eines neuen

Vertriebsinformationssystems. Was wären mögliche Kriterien für einen

Projektabschluss?

� Die neue Software wurde installiert, die Anwender können damit ar-

beiten.

� Die neue Software wurde installiert und die alte Software für die Einga-

be deaktiviert, es muss also die neue Software produktiv verwendet

werden.

� Die neue Software wurde installiert, die Anwender arbeiteten eine Wei-

le damit, die Kinderkrankheiten wurden also beseitigt und die alte Soft-

ware wurde deinstalliert.

Wurde nichts vereinbart, wird der Auftraggeber eher der dritten Definiti-

on zustimmen, während der Projektleiter die Aufgabe mit der ersten Defi-

nition als abgeschlossen ansieht.

In Abschnitt 3.2.1 habe ich empfohlen, die Kriterien für den Projektab-

schluss bereits im Projektauftrag festzuschreiben, Sie wissen nun warum.

Aber auch wenn das versäumt wurde, sollten Sie das Gespräch suchen und

die Kriterien für den Projektabschluss noch festlegen. Das geht meist viel

leichter, wenn die nächsten Schritte – dann außerhalb des Projektes – be-

reits benannt werden.

Aus der Praxis

Wenn wir neue Software einführen, dann oft in mehreren Ländern. Da

bleibt wenig Raum für Projekte, die ewig laufen. Im Gegenteil: Jedes

überzogene Projekt hat Auswirkungen auf die anderen Länder – und

auf weitere Projekte, die parallel laufen.


77


3

Dennoch sind auch immer (ich meine wirklich immer) noch Punkte

offen, nachdem die Software eingeführt wurde. Wir erfassen diese

Punkte in einer sogenannten Known-Issues-Liste und legen exakt fest,

welche davon noch im Rahmen des Projektes erledigt werden und wel-

che später, im Rahmen der regulären Softwarewartung.

Nicht immer verläuft diese Einschätzung völlig konfliktfrei, wie Sie sich

denken können. Aber immer entsteht am Ende eine Lösung, die es uns

erlaubt, mit den Projekten fortzufahren, die Anwender aber auch nicht

im Regen stehen lässt. Ein Projekt endet damit mit der, wie wir es nen-

nen, »Begleiteten Einführung«, in der wir diejenigen Punkte noch erle-

digen, die zum Projekt gehören und Kapazität für Fragen und

erweiterte Hilfestellungen vorhalten.

So viel zur Bedeutung des Projektabschlusses im Projektmanagement.

Der Vollständigkeit halber sei erwähnt, dass ein Projekt natürlich auch

durch Abbruch enden kann. In beiden Fällen ist aber essenziell, dass dem

Projektabschluss eine Entscheidung vorausgeht, die vom Auftraggeber

und Projektleiter gemeinsam zu treffen ist.

In der Praxis hilft es meist wenig, wenn als Projektabschluss der Abnah-

metermin festgelegt wird, jedenfalls solange die Abnahmekriterien dann

nicht genauso sorgfältig definiert wurden.

Wie auch immer: Auch für das Projektende gibt es einige Dinge, die be-

rücksichtigt werden sollten.

Take-away

� Wenn für das Projektende die Abnahme vereinbart wurde, dann

benötigen Sie nun den unterzeichneten Abnahmebericht.

� Der Auftraggeber sollte den Abschluss formell und öffentlich ver-

künden. Es wäre zudem schön, wenn er einige feierliche und löbli-

che Worte dafür finden würde.

� In größeren Projekten ist es üblich, dass man sich trifft – das

kann auch außerhalb der Arbeitszeit sein und hat oft Incentive-

Charakter.


78


� Sie sollten sich ebenfalls bei Ihrem Projektteam bedanken und

deren Leistung entsprechend würdigen.

� Vielleicht gibt es noch organisatorische Arbeiten zu erledigen, im

Rahmen der so genannten Projektauflösung. Das kann zum Beispiel

das Schließen der Projektkostenstelle sein.

� Wie schon einmal erwähnt, sollten Sie auf das Abhalten einer

»Manöverkritik« verzichten. Wenn etwas nicht rund lief, dann wis-

sen das inzwischen alle Beteiligten recht genau.

� Manche Unternehmen erstellen eine Projektabschlussanalyse, in

der die Projektziele mit den Ergebnissen verglichen, die Wirtschaft-

lichkeit untersucht und eine Nachkalkulation erstellt werden.

� Häufiger ist der so genannte Projektabschlussbericht anzutreffen,

eine formelle Dokumentation des Projektabschlusses. Dieses Doku-

ment wird dann zu den Akten gelegt, zusammen mit den anderen

Projektdokumenten, und kann für spätere Fragen oder ähnliche

Projekte herangezogen werden.

Anstelle einer Manöverkritik kann es aber schon einmal hilfreich sein,

sich am Ende des Projektes für eine Rückbetrachtung zu treffen – und sei

es nur, um das zu würdigen, was geleistet wurde.

Wenn Sie so etwas vorhaben, dann empfehle ich Ihnen dafür diese Agenda:

Agenda Rückbetrachtung

� Verkündigung des formellen Projektendes

� Vorstellen dessen, was erreicht wurde (also z. B. eine Präsentation

des Vertriebsinformationssystems). Idealerweise übernehmen das

diejenigen, für die das Projektergebnis bestimmt war

� Würdigung der Leistung Ihrer Projektmitarbeiter

� Dank an die Stakeholder, allen voran den Auftraggeber

� Abstimmung darüber, welche Punkte noch offen sind und wie da-

mit verfahren werden soll

� Vorstellung der nächsten Schritte nach dem Projektende

� Eventuell kurze Vorstellung eines möglichen Folgeprojektes


79

3.6 Wirklich? Noch nicht ganz! Vom Projektende als Startschuss

3

Die Formalien sind eine Sache, da wird genauso oft übertrieben, wie sorg-

los gehandelt. Genauso wichtig, wenn nicht wichtiger, ist es, dass Sie nun

selbst mit dem Projekt abschließen. Lehnen Sie sich also zurück und

lassen Sie die letzten Wochen, Monate oder Jahre Revue passieren. Was

würden Sie heute anders machen? Welche Ihrer Ideen haben sich gut be-

währt? Was haben Sie gelernt? Hat es Spaß gemacht und wo stehen Sie

heute in Ihrem Unternehmen im Vergleich zu früher? Hat Sie das Projekt

persönlich und beruflich weitergebracht?

3.6 Wirklich? Noch nicht ganz! Vom Projektende als Startschuss

Häufig wird die Zeit nach einem Projekt wenig beachtet. Eine Software,

einmal eingeführt, möchte umsorgt und gepflegt werden. Der Bau eines

Gebäudes zieht den Umzug dorthin nach sich. Es gibt eigentlich immer

eine Fortführung eines Projektes. Wichtig ist daher, das Projekt gegenüber

der folgenden Phase abzugrenzen – auch dafür ist der Projektabschluss

zuständig.

Solche Phasen nach einem Projekt können selbst wiederum eigene Projek-

te sein, wenn sie nach einer Projektorganisation verlangen. Oder es ist

Bestandteil des Alltagsgeschäftes, wie zum Beispiel die fortwährende Soft-

warepflege, wie im obigen Beispiel.

In den meisten Fällen ändert sich nach dem Projekt auch die Zuständig-

keit, der Projektleiter gibt den Staffelstab an seinen Nachfolger ab. Das

liegt eigentlich außerhalb des Fokus dieses Buches, aber einige Empfeh-

lungen möchte ich schon gerne beisteuern.

Empfehlungen für die Staffelstab-Übergabe

� Ein Projekt ist nicht plötzlich zu Ende. Sprechen Sie rechtzeitig vor

dessen Ende mit demjenigen, der Ihnen nachfolgt.

� Häufig wird dieser eine Dokumentation von Ihnen benötigen.

Klären Sie vorher ab, wie umfangreich diese sein soll und was sie

enthalten soll.


80


� Nach dem formalen Projektende – dem Projektabschluss – sollte

ebenfalls die nächste Phase formal eingeleitet werden. Warum

nicht zusammen?

� Neben der Dokumentation hilft Ihrem Nachfolger sicherlich auch,

wenn Sie einige informelle Dinge weitergeben. Andauernde

Schwierigkeiten zum Beispiel oder andere Einschätzungen. Sie sind

schließlich der Profi und verfügen über einen großen Informations-

vorsprung.

� Begleiten Sie Ihren Nachfolger noch eine Weile, seien Sie also noch

über das Projektende hinaus für ihn ansprechbar.

Damit ist die Projektarbeit grob umrissen. Das nächste Kapitel bereitet Sie

für alle weiteren Kapitel vor, in dem es Ihnen, ganz praktisch, gute Ge-

wohnheiten nahebringt, ohne die Projekte nur halb so erfolgreich sind.


Auf einen Blick

3

Auf einen Blick

1 Einführung ............................................................................................. 13

2 Im Nebel nach Turkmenistan –

warum Projekte scheitern (können) .............................................. 29

3 Wie am Schnürchen – wie Projekte ablaufen (sollen) ............ 59

4 Gute Gewohnheiten – was Projekte erfolgreich macht ......... 81

5 Ein ungleicher Haufen – das Projektteam ................................... 101

6 Der Nebel lichtet sich – die Projektplanung ............................... 125

7 Flaute oder raue See? Projektdurchführung und

Projektcontrolling ................................................................................ 169

8 Agile Methoden im Projektmanagement .................................... 203

9 Das Märchen vom Projektmanagement ...................................... 225


5

Inhalt

Inhalt

1 Einführung 13

1.1 Wie ich mir Sie vorstelle .................................................................... 14

1.2 Das Projekt auf dem Präsentierteller ........................................... 15

1.2.1 Was ist eigentlich ein Projekt? ....................................... 15

1.2.2 Was ist eigentlich Projektmanagement? ................... 16

1.2.3 Projekt annehmen oder lieber vorbeigehen? ............ 20

1.2.4 Projekt übernehmen, ohne sich zu übernehmen .... 21

1.3 Wegweiser für eilige Leser ............................................................... 21

1.4 Die Projekt-Checkliste ........................................................................ 22

1.4.1 Projektbeteiligte .................................................................. 23

1.4.2 Projektdefinition ................................................................. 24

1.4.3 Projektumfang ..................................................................... 25

1.4.4 Das Unternehmen und sein Projektleiter .................. 26

1.4.5 Stand des Projektes ............................................................ 27

1.4.6 Projektkommunikation .................................................... 27

1.4.7 Projektrisiken ....................................................................... 28

2 Im Nebel nach Turkmenistan – warum Projekte scheitern (können) 29

2.1 Die Kommunikation eines alten Ehepaars ................................. 30

2.1.1 Die E-Mail-Seuche .............................................................. 30

2.1.2 Irrglaube Nr. 1: Geschrieben ist schon getan ............ 32

2.1.3 Irrglaube Nr. 2: Ist doch sonnenklar, oder? ................ 33

2.1.4 Irrglaube Nr. 3: Toll, ein Job! ........................................... 34

2.2 2 + 2 = 5 – die Regeln der Komplexität ........................................ 35

2.3 Zero Trouble Forecast ........................................................................ 39


6

Inhalt

2.4 Tontaubenprojekte – von der Kunst, bewegliche Ziele

zu treffen ............................................................................................... 41

2.5 Virtuelles Kaffeekränzchen – von der Kunst, überhaupt

ein Ziel zu haben ................................................................................. 45

2.6 Zu viel Tücke in zu wenig Detail .................................................... 46

2.7 Mit dem Autopiloten nach Turkmenistan? ................................ 50

2.8 Von der wundersamen Ressourcenvermehrung und

anderen Wundern ............................................................................... 52

2.9 Karma oder freier Wille .................................................................... 55

3 Wie am Schnürchen – wie Projekte ablaufen (sollen) 59

3.1 Der Sinn von Projektplanung –

wie vorhersagbar sind Projekte? ................................................... 60

3.2 Auf Los geht’s los ................................................................................ 62

3.2.1 Der Projektauftrag .............................................................. 63

3.2.2 Die Entscheidung ................................................................ 66

3.2.3 Die Kick-off-Veranstaltung .............................................. 67

3.3 Der Nebelkerzenradierer – die Projektplanung ........................ 71

3.4 Malochen mit Grips –

Projektdurchführung und Projektcontrolling ........................... 74

3.5 Geschafft! Der Projektabschluss .................................................... 75

3.6 Wirklich? Noch nicht ganz!

Vom Projektende als Startschuss .................................................. 79


7

Inhalt

4 Gute Gewohnheiten – was Projekte erfolgreich macht 81

4.1 In den Kerker mit Murphy – warum Optimismus wichtig ist 82

4.2 Hüten Sie sich vor Akronymen ........................................................ 84

4.3 Was Sie von Ihrem Gartenthermometer lernen können ....... 85

4.4 Klappern gehört zum Handwerk .................................................... 88

4.5 Was Sie von Ihrer Taschenlampe lernen können ..................... 92

4.6 Das Lustprinzip – warum Motivation der Treibstoff ist ......... 96

5 Ein ungleicher Haufen – das Projektteam 101

5.1 Erwartungen allenthalben – die Player im Überblick ............. 102

5.1.1 Der Auftraggeber ................................................................ 102

5.1.2 Der Kunde als Auftraggeber ........................................... 105

5.1.3 Der Projektleiter .................................................................. 107

5.1.4 Der Teilprojektleiter ........................................................... 109

5.1.5 Fach-Mitarbeiter ................................................................. 110

5.1.6 Die Kontrolleure .................................................................. 112

5.2 Der Projektleiter als Zeitdieb, oder:

so werben Sie um Ihr Projektteam ................................................ 114

5.2.1 Phase 1: Kennenlernen ..................................................... 115

5.2.2 Phase 2: Mittendrin ........................................................... 117

5.2.3 Phase 3: Am Ende ............................................................... 118

5.3 Der Erste-Hilfe-Kasten für notleidende Teams ......................... 119

5.3.1 Phase 1: Das Problem und die Beteiligten

verstehen ............................................................................... 119

5.3.2 Phase 2: Das Gespräch ...................................................... 120

5.3.3 Phase 3: Projekt-Reset ....................................................... 122

5.3.4 Phase 4: Nachsorge ............................................................ 122


8

Inhalt

6 Der Nebel lichtet sich – die Projektplanung 125

6.1 Lieber schätzen als verzocken ........................................................ 125

6.1.1 Über den Sinn einer Schätzung ...................................... 126

6.1.2 Anforderungen .................................................................... 127

6.1.3 Methoden der Aufwandschätzung ............................... 130

6.2 Gefangen im Bermudadreieck –

von Qualität, Zeit und Kosten ........................................................ 133

6.3 Das Phasenmodell der Projektplanung ....................................... 134

6.4 Phase 1: Teile und herrsche, aber teile nicht den Herrscher 135

6.4.1 Schritt 1: Themensammlung .......................................... 135

6.4.2 Schritt 2: Teilen, also feiner planen .............................. 136

6.4.3 Schritt 3: Ordnen ................................................................. 137

6.5 Phase 2: Abhängigkeiten bestimmen und planen .................. 138

6.6 Phase 3: Aufwand bestimmen ....................................................... 141

6.6.1 Aufwand/Dauer ergänzen ............................................... 141

6.6.2 Puffer ....................................................................................... 145

6.6.3 Meilensteine ......................................................................... 148

6.7 Phase 4: Ressourcen planen ............................................................ 149

6.8 Phase 5: Kosten planen ..................................................................... 150

6.8.1 Schritt 1: Welche Kosten fallen überhaupt an

und welche davon sind relevant? .................................. 151

6.8.2 Schritt 2: Wie hoch sind die Kosten? ............................ 152

6.8.3 Schritt 3: Kosten planen ................................................... 153

6.8.4 Kostenplan genehmigen .................................................. 154

6.9 Phase 6: Risiken erkennen und bewerten .................................. 155

6.10 Projektphasen ...................................................................................... 157

6.11 Zu guter Letzt ....................................................................................... 166


9

Inhalt

7 Flaute oder raue See? Projektdurchführung und Projektcontrolling 169

7.1 Der »Aller-Anfang-ist-leicht-Effekt« ............................................. 170

7.2 Projektcontrolling ohne Paranoia .................................................. 171

7.2.1 Worum es genau geht ...................................................... 172

7.2.2 Erfolgsfaktoren .................................................................... 175

7.2.3 Der Controllingfahrplan ................................................... 176

7.2.4 Terminkontrolle .................................................................. 178

7.2.5 Kostenkontrolle ................................................................... 184

7.2.6 Projektmanagementsoftware ........................................ 186

7.3 Der Wind macht die Welle – wie man Probleme rechtzeitig

erkennt und löst .................................................................................. 187

7.3.1 Probleme im Team erkennen ......................................... 188

7.3.2 Typische Problemindikatoren ........................................ 189

7.3.3 Probleme rechtzeitig lösen .............................................. 191

7.4 Der Projekt-Reset ................................................................................. 192

7.4.1 Phase 1: Entscheidung und Vorbereitung ................. 193

7.4.2 Phase 2: Überblick gewinnen ......................................... 193

7.4.3 Phase 3: Diskussion mit dem Auftraggeber und

persönliche Entscheidung ............................................... 194

7.4.4 Phase 4: Das Projekt neu planen ................................... 196

7.4.5 Phase 5: Kommunizieren und loslegen ...................... 198

7.5 Sitzungs-Knigge für Projektleiter .................................................. 198

8 Agile Methoden im Projektmanagement 203

8.1 Das Agile Manifest und worum es eigentlich geht .................. 203

8.1.1 Menschen und Interaktionen vor Prozessen

und Werkzeugen ................................................................. 204


10

Inhalt

8.1.2 Funktionierende Software vor umfassender

Dokumentation ................................................................... 205

8.1.3 Zusammenarbeit mit dem Kunden vor

Vertragsverhandlungen .................................................... 205

8.1.4 Reagieren auf Veränderungen vor dem Befolgen

eines Plans ............................................................................. 206

8.1.5 Zusammenfassung ............................................................. 207

8.2 Eine Einführung in Scrum ................................................................. 208

8.2.1 Die Scrum-Methode ........................................................... 209

8.2.2 Die Scrum-Rollen ................................................................. 211

8.2.3 Empfehlungen für Scrum ................................................. 213

8.3 DevOps – Entwickler und Admin finden zusammen .............. 215

8.3.1 Was DevOps ist, und was nicht ...................................... 215

8.3.2 Der DevOps-Prozess ........................................................... 218

8.3.3 Phase 1: Grundvoraussetzungen schaffen ................ 220

8.3.4 Phase 2: Den Prozess festlegen ...................................... 220

8.3.5 Phase 3: Die Toolkette aufbauen ................................... 221

8.3.6 Phase 4: Umsetzung .......................................................... 222

8.3.7 Weitere Tipps ....................................................................... 223

9 Das Märchen vom Projektmanagement 225

Index ................................................................................................................... 231


231

Index

Index

A

Agile Methoden 203

Agiles Manifest 203

Agilität 41, 61

Fallen 42

Aller Anfang ist leicht 51

Anfang-Anfang-Beziehung 140

Anforderung 127

Inhalte 128

Merkmale einer guten 128

Qualität 46

Anforderungsanalyse 160

Anforderungs-Management 44

Arbeitspaket 136

Architekturfindung 162

Aufschiebe-Effekt 170

Auftraggeber 102

Tipps zum Umgang 103

Verhandlungstipps 67

Aufwand 181

Aufwandschätzung 125

Gründe dafür 126

Methoden 130

B

Basisplan 180

Begleitete Einführung 165

Beherrschbarkeit 35

Besprechungen planen 198

Beta-Versionen 162

Black Box 207

Budget 54, 184

Bullshit-Bingo 198

C

Change Request 41

Commitment 126

Controllingfahrplan 176

D

Daily Scrum 210

Datenmigration 163

Dauer 181

Delegieren 18

Designentscheidungen 162

DevOps 215

Divide et impera 135

E

Earned Value Analysis 180

EAV 180

Einzelschätzung 131

Ende-Anfang-Beziehung 139

Ende-Ende-Beziehung 140

Endfolge 140

Entwicklung 162

Ergiebigkeitsprinzip 154

Erste-Hilfe-Kasten 119

Erwartungen 38, 102

F

Fachliche Risiken 156

Fach-Mitarbeiter 110

Freie Puffer 148

Frühestmöglicher Beginn 146

Frühestmögliches Ende 146

Function Points 133


232

Index

G

Gesamter Puffer 148

Granularität 137

Granularität des Projekt-

controllings 177

Gruppenschätzung 132

I

Impediment Backlog 210

Inbetriebnahme 164

Iterative Projektplanung 139

K

Kapazitäten 54

Kick-off-Meeting 63, 67, 115

Kommunikation 17, 30

Missverständnisse 32

Phasen 32

Kommunikationsphasen 32

Komplexität 15

reduzieren 18

Regeln 35

Konflikte im Team 188

Konkurrenzkampf 96

Kontrolleure 112

Kontrollgremium


Kosten für extern erbrachte

Dienstleistungen 151

Kostenarten 151

Kostenkontrolle 184

Kostenplan 153

Kostenplanung 153

Kostenrechnung 151

Kostenrisiken 155

Kostenschätzung 152

Kostenüberschreitung 185

Kritischer Pfad 141, 146

L

Lastenheft 160

Leistungswert 180

Leistungswertanalyse 180

Lenkungsausschuss 112

M

Magisches Dreieck im

Projektmanagement 133

Märchen 225

Maximumprinzip 154

Meilensteine 148

Microsoft Project 138

Migration 163

Minimumprinzip 154

Motivation 19, 96

Anreize 99

Information 97

Persönliches 98

Moving Targets 41

Murphy 82

O

Optimismus 82

Optimumprinzip 154

P

Personalkosten 151

Personalressourcen 142

Personelle Risiken 155

Pflichtenheft 161

Phasenmodell 157

Phasenmodell der

Softwareentwicklung 160


233

Index

Phasenorientierte Projektpläne 73

Planungshorizont 62, 92

Planungstiefe 62

PMBOK 84

PRINCE2 84

Problemanalyse 160

Probleme erkennen 187

Problemindikatoren 189

Product Backlog 209

Product Owner 210, 211

Produktinkrement 210

Produktionsfreigabe 164

ProjectLibre 138

Projekt

Ablauf 59

Abschluss 75

Beginn 62

Controlling 19

Definition 15

Kontrollinstanzen 112

Marketing 88

Phasenübergang 79

Reset 122

Tipps für erfolgreiche 81

Unsicherheiten 49

Voraussetzungen 20

Ziele 45

Projektabschluss 75

Projektabschlussanalyse 78

Projektabschlussbericht 78

Projektauflösung 78

Projektauftrag 63

Inhalte 64

Projektcontrolling 19, 74, 169

Erfolgsfaktoren 175

Inhalte 75

Problemerkennung 187

Terminkontrolle 178

Worum es geht 172

Projektdurchführung 74, 169

Projektende 79

Projektleiter 107

Projektleitung

Eigentliche 56

Uneigentliche 56

Projektmanagement 60

Definition 16

Gründe und Aufgaben 60

Kostenplanung 150

Modelle 84

Projektmanagementsoftware 186

Projektmarketing 88

Adressaten 90

Goldene Regeln 91

Gründe und Aufgaben 88

Medien 90

Projektphasen 157

Gründe für 158

Phasenmodell der


Projektphasen 157

Projektplan

Merkmale eines guten 72

Projektplanung 60, 71, 125

Abhängigkeiten 138

Aufwandbestimmung 141

für Eilige 166

Genauigkeit 85

Granularität 137

Ressourcenplanung 149

Risikomanagement 155

Sinn und Grenzen 60

Projekt-Reset 122, 192

Projektteam 101, 114

Erste-Hilfe-Kasten 119

Notleidende 119

Phasen der Kommunikation 115


Proof of Concept 49

Prototyp 161


234

Index

Puffer 140, 145

Puffermanagement 146

Q

Qualifikation der Projekt-

mitglieder 150

Qualitätscontrolling 177

R

Rahmenbedingungen 56

Regelkreis des Projekt-

controllings 173

Release-Candidate 162

Requirement Engineering 41

Ressourcen 52

Retrospektive 210

Risikomanagement 155

RTM 162

Rückwärtsrechnung 145

S

Sachmittelkosten 151

Sachmittelressourcen 142

Schulung 164

Scrum 208

Einführen 214

Empfehlungen 213

Prozess 209

Rollen 211

Scrum Master 212

Scrum-Team 212

Selected Backlog 210

Sitzungs-Knigge für Projekt-

leiter 198


Softwaretest 163

Softwarewartung 165

Sparsamkeitsprinzip 154

Spätestmöglicher Beginn 146

Spätestmögliches Ende 146

Spezifikation 161

Sprint 208, 209

Sprint Backlog 209

Sprint-Review 210

Stakeholder 90

T

Technologische Risiken 156

Teile und herrsche 135

Teilprojektleiter 109

Terminkontrolle 178

Terminliche Risiken 156

Testprotokoll 163

Timekeeper 200

Tontaubenprojekte 41

Trade-off 44, 134

U

Uneigentliche Projektleitung 108

Use-Case-Punkte 133

V

Virtuelle Genauigkeit

in Projekten 85

Vorhersagbarkeit von Projekten 60

Vorwärtsrechnung 145

W

Wartung 165

Wasserfallmodell 61

WBS 136

Wegweiser 21

Work Breakdown Structure 136


235

Index

Z

Zeitpuffer 145

Zeitschätzung 127

Zero Trouble Forecast 39

Ziele 45

ZTF 39


Matthias Geirhos

IT-Projektmanagement: Was wirklich funktioniert – und was nicht235 Seiten, broschiert, 2. Auflage 2016

12,90 Euro, ISBN 978-3-8362-4098-7

www.rheinwerk-verlag.de/4097

Wir hoffen sehr, dass Ihnen diese Leseprobe gefallen hat. Sie dür-fen sie gerne empfehlen und weitergeben, allerdings nur vollstän-dig mit allen Seiten. Bitte beachten Sie, dass der Funktionsumfang dieser Leseprobe sowie ihre Darstellung von der E-Book-Fassung des vorgestellten Buches abweichen können. Diese Leseprobe ist in all ihren Teilen urheberrechtlich geschützt. Alle Nutzungs- und Verwertungsrechte liegen beim Autor und beim Verlag.

Teilen Sie Ihre Leseerfahrung mit uns!

Matthias Geirhos ist C#- und .NET-Spezialist und arbeitet seit mehr als zehn Jahren als Ent-wicklungsleiter. Dabei war er für große und kleine IT-Projekte verantwortlich. Er ist bestens mit den Methoden und Fallstricken des IT-Projektmanage-ments vertraut und wird gerne als Referent und Fachautor gebucht, da er auch komplexe Sach- verhalte verständlich und unterhaltsam auf den Punkt bringt.

Wissen, wie’s geht.

https://www.rheinwerk-verlag.de/it-projektmanagement_4097/?GPP=lpn

https://www.facebook.com/rheinwerkverlag

https://plus.google.com/118435207805510651040

http://twitter.com/rheinwerkverlag

Documents

IT-Projektmanagement: Was wirklich funktioniert – und was ... · 59 3 Kapitel 3 Wie am Schnürchen wieProjekte ablaufen (sollen) Viele Steine, müde Beine, Aussicht keine, Heinrich