In diesem 3. (und auch letzten) Teil des Blogeintrags sind die weiteren Kernaussagen des Buchs von Tom DeMarco: "Der Termin. Ein Roman über Projektmanagement" zusammengetragen.

Konflikte: (S.195)

• Wenn an einer Entwicklungsanstrengung mehrere Parteien beteiligt sind, sind Interessenskonflikte unvermeidlich.Der Bereich der Systementwicklung und -installation ist für Konflikte besonders anfällig.
• Die meisten Systementwicklungsorganisationen verfügen über schlechte Konfliktlösungsfähigkeiten.
• Konflikte verdienen Respekt. Konflikte sind kein Zeichen für unprofessionelles Verhalten.
• Legen Sie von vornherein klar fest, daß die Gewinnbedingungen aller Beteiligten respektiert werden. Stellen Sie sicher, daß alle Gewinnbedingungen, die kleinen ebenso wie die großen, auf den Tisch gelegt werden.
• Verhandlungen sind schwierig; Mediation ist einfach.
• Machen sie von Anfang an deutlich: Wenn Gewinnbedingungen einander ganz oder teilweise ausschließen, wird von den Parteien erwartet, daß sie sich in Mediation begeben, um den Konflikt zu lösen.
• Ganz wichtig: Wir stehen beide auf der gleichen Seite; es ist das Problem, das auf der anderen Seite steht.

Rolle das Katalysators: (S. 205)

• Es gibt so etwas wie eine katalytische Persönlichkeit. Solche Menschen leisten einen Projektbeitrag, indem sie dem Team helfen, zusammenzuwachsen und gesund und produktiv zu bleiben. Selbst wenn eine Katalysator-Persönlichkeit nichts sonst leisten würde (meistens leistet sie sehr viel mehr), ist sie allein aufgrund ihrer Katalysator-Rolle wichtig und wertvoll.
• Mediation ist ein Spezialfall der Katalysator-Rolle. Mediation läßt sich mit geringem Aufwand erlernen.
• Das kleine Ritual, das mit dem Satz beginnt "Kann ich Ihnen helfen, indem ich versuche, als Mediator für Sie zu vermitteln?" , kann ein wichtiger erster Schritt der Konfliktlösung sein.

Menschliches Irren: (S. 212)

• Nicht das, was wir NICHT wissen, bringt uns zu Fall . . . sondern das, was wir fälschlicherweise zu wissen glauben.

Mitarbeiterzahl: (S. 223)

• Ist ein Projekt in der Anfangsphase personell aufgebläht, besteht die Gefahr, daß die Entwurfsaktivitäten abgekürzt werden (um all die Leute zu beschäftigen).
• Wenn die Arbeit vor Fertigstellung des Entwurfs auf ein großes Team verteilt wird, wird darauf verzichtet, die Schnittstellen zwischen Mitarbeitern und Arbeitsgruppen zu minimieren.
• Die Folgen sind: größere wechselseitige Abhängigkeit, mehr Besprechungen, Redundanz und Frustrationen.
• Die ideale Personalbesetzung erfordert über weite Strecken hinweg ein kleines Kernteam, das gegen Ende des Projekts (erst im letzten Sechstel der veranschlagten Zeit) um eine beträchtliche Zahl von Mitarbeitern ergänzt wird.
• Ein schrecklicher Verdacht: Projekte mit einem aggressiven Terminplan werden später abgeschlossen, als das mit einem vernünftigen Terminplan der Fall gewesen wäre.

Projektsoziologie: (S. 236)

• Halten Sie Besprechungen klein, indem Sie nicht benötigten Leuten die Sicherheit vermitteln, nichts zu versäumen. Eine schriftlich vorliegende Tagesordnung, die streng eingehalten wird, ist die einfachste Möglichkeit, ihnen diese Gewißheit zu geben.
• Projekte brauchen Rituale.
• Rituale helfen, die Aufmerksamkeit auf Projektziele und -ideale zu konzentrieren: kleine Besprechungen, fehlerlose Arbeit usw.
• Unternehmen sie Schritte, Mitarbeiter vor zerstörerischem Zorn zu bewahren.
• Denken Sie daran: Zorn = Angst. Manager, die in zerstörerischer Wut ihre Mitarbeiter quälen, tun das fast immer, weil sie Angst haben.
• Beobachtung: Wenn jeder die Gleichung Zorn = Angst versteht, wird Wut zu einem leicht erkennbaren Signal: Wer zornig ist, hat Angst. Weil die meisten Menschen dazu neigen, Angst nicht zu zeigen, können sie ihrer Wut nicht mehr Luft machen. (Das löst nicht das Problem des zornigen Mitarbeiters, macht aber allen anderen das Leben leichter).

Pathologische Politik (einweiteres Mal): (S. 247)

• Man kann nicht erwarten, ein pathologisches Verhalten von unten her zu heilen.
• Verschwenden Sie nicht Ihre Zeit und gefährden Sie nicht Ihre Position in dem Versuch, es doch zu versuchen.
• Manchmal besteht die einzige Möglichkeit darin, der Sache zu trotzen und darauf zu warten, daß das Problem sich von selbst erledigt oder daß sich eine gute Gelegenheit für einen Wechsel ergibt.
• Wunder sind möglich (aber rechnen Sie nicht damit).

Straff und Taff: (S. 257)

• Straff und taff ist eine Formel, zu der in gescheiterten Unternehmen die Leute greifen, die für das Scheitern verantwortlich sind.
• Sie ist das Gegenstück des natürlichen Ziels jeder Organisation: Produktivität und Partnerschaft.
• Wann immer Sie die Phrase "straff und taff" hören, ersetzen Sie sie mit dem, was sie wirklich bedeutet: eingeschüchtert und gescheitert.

Gesunder Menschenverstand: (S. 261)

• Ein Projekt braucht sowohl Ziele als auch Termine.
• Sie sollten sich voneinander unterscheiden.

Fazit:

Dieses Buch ist ein absolutes Muss für jeden Projektmanager aber auch für die Mitglieder in Projektlenkungsausschüssen und natürlich die Projektmitarbeiter. Ich habe dieses Buch mindestens schon 10 Mal gelesen bzw. gehört, denn neben der Buchausgabe gibt es eine sehr gut gemachte Hörbuchversion. Die Hörbuchversion eignet sich sehr gut auf längeren Autobahn- oder auch Zugfahrten um sein eigenes Projekt von einem anderen Standpunkt aus zu beleuchten und sich immer wieder neu zu orientieren, ob man das eigentliche Ziel des Projekts noch verfolgt oder schon auf einem "Nebenkriegsschauplatz" seine Energie vergeudet.

In diesem 2. Teil des Blogeintrags sind die weiteren Kernaussagen des Buchs von Tom DeMarco: "Der Termin. Ein Roman über Projektmanagement" zusammengetragen.

Modellierung und Simulation des Entwicklungsprozesses: (S. 99)

• Modellieren Sie Ihre Instinkte über die Arbeitsprozesse.
• Entwickeln Sie die Modelle gemeinsam mit Kollegen, um Ihre Vermutungen über den Ablauf von Arbeitsprozessen auszutauschen und aufeinander abzustimmen.
• Nutzen Sie die Modelle als Basis für Simulationen zur Abschätzung von Ergebnissen.
• Nutzen Sie die tatsächlichen Ergebnisse zur Verfeinerung der Modelle.

Pathologische Politik: (S. 114)

• Man muß bereit sein, seinen Job jeden Tag aufs Spiel zu setzen . . .aber das garantiert nicht, daß einem pathologische Politik nichts anhaben kann.
• Pathologische Politik gedeiht überall, auch in der gesündesten Organisation.
• Die herausragendste Eigenschaft pathologischer Politik ist, daß das Streben einzelner nach Macht und Einfluß die natürlichen Ziele einer Organisation überlagert.
• Das kann selbst dann passieren, wenn das pathologische Ziel dem Ziel der Organisation diametral entgegengesetzt ist.
• Eine der schlimmsten Nebenwirkungen pathologischer Politik: Sie hat es besonders auf schlank besetzte Projekte abgesehen.

Metriken: (S. 130)

• Die Größe jedes einzelnen Produkts muß gemessen werden..
• Es ist nicht notwendig, sich den Kopf über Meßeinheiten zu zerbrechen - so lange Sie keine objektiven Maße haben, wählen Sie subjektive Meßeinheiten.
• Bilden Sie synthetische Maße aus allen verfügbaren Primitiven (abzählbaren Software-Eigenschaften).
• Sammeln Sie archäologische Daten, um Produktivitätstrends aus mittlerweile abgeschlossenen Projekten abzuleiten.
• Experimentieren Sie solange mit der Formulierung der synthetischen Metrik, bis ihre Werte optimal mit dem Entwicklungsaufwand für die untersuchten Projekte in Ihrer archäologischen Datenbank korrelieren.
• Legen Sie eine Trendlinie durch Ihre Datenbank, die den erwarteten Entwicklungsaufwand als Funktion von Werten der synthetischen Metrik zeigt.
• Berechnen Sie nun zur Aufwandabschätzung jedes neuen Projekts den Wert der synthetischen Metrik und lesen Sie mit seiner Hilfe den erwarteten Entwicklungsaufwand von der Trendlinie ab.
• Nehmen Sie die Schwankungsbreite um den Produktivitätstrend herum als Hinweis darauf, mit welchen Toleranzen Sie bei Ihren Hochrechungen rechnen müssen.

Prozeß und Prozeßverbesserung: (S. 141)

• Ein guter Prozeß und kontinuierliche Prozeßverbesserungen sind ein anerkennenswertes Ziel.
• Sie sind gleichzeitig ein sehr natürliches Ziel: Gute technische Mitarbeiter bemühen sich darum, ganz gleich, ob man sie dazu anhält oder nicht.
• Formale Prozeßverbesserungsprogramme kosten Zeit und Geld; ein angeordnetes Programm zur Prozeßverbesserung kann sogar zu Rückschlägen in der Projektarbeit führen. Selbst wenn langfristig Produktivitätsgewinne erzielt werden, kosten QS-Programme den Projekten, in die sie eingebettet waren, meistens mehr als sie nützen.
• Ein Projekt kann allenfalls hoffen, von einer gutgewählten Methodenverbesserung so viel zu profitieren, daß sich der in die Veränderung gesteckte Zeit- und Geldaufwand auszahlt.
• Die Hoffnung, ein Projekt könnte in seiner Laufzeit mehr als eine Methodenverbesserung verkraften, ist unrealistisch. Bei Programmen, die auf die Verbesserung mehrerer Fähigkeiten abzielen (zum Beispiel Anhebung um eine ganze (CMM-Stufe), ist die Wahrscheinlichkeit besonders groß, daß Projekte später abgeschlossen werden, als das ohne das Verbesserungsprogramm der Fall gewesen wäre.
• Die Gefahr standardisierter Prozesse liegt darin, daß die Mitarbeiter wichtige Abkürzungsmöglichkeiten ungenutzt lassen.
• Bei überbesetzten Projekten ist die Gefahr besonders groß, daß der Standardprozeß stur eingehalten wird, wenn er nur genügend Arbeit (sinnvolle oder sinnlose) generiert, um alle Mitarbeiter zu beschäftigen.

Die Herangehensweise verändern: (S.156)

• Die einzige Möglichkeit, die Leistung innerhalb eines Projekts substantiell zu verbessern, besteht darin, die Zeit für die Fehlersuche stark zu reduzieren.
• Hochproduktive Projekte wenden anteilsmäßig sehr viel weniger Zeit für das Debuggen auf.
• Hochproduktive Projekte wenden anteilsmäßig sehr viel mehr Zeit für den Entwurf auf.
• Man kann Menschen ohne Fürsorge und Zuneigung nicht dazu bringen, anders als bisher zu handeln. Um sie zu einer Verhaltensänderung zu bewegen, muß man verstehen, woher sie kommen und warum sie sind, wie sie sind.

Die Auswirkungen von Druck: (S.174)

• Menschen unter Druck denken nicht schneller.
• Mehrarbeit über einen längeren Zeitraum hinweg ist eine Methode zur Produktivitätssenkung
• Kurze Perioden der Anspannung und sogar der Mehrarbeit können eine sinnvolle Taktik sein, weil sie die Konzentration der Mitarbeiter bündeln und das Gefühl für die Wichtigkeit der Arbeit erhöhen. Mehrarbeit über einen längeren Zeitraum hinweg aber ist immer ein Fehler.
• Vielleicht setzen Manager Druck deshalb so oft ein, weil sie nicht wissen, was sie sonst tun sollen, oder die schwierigeren Alternativen scheuen.
• Ein schrecklicher Verdacht: Möglicherweise steckt hinter Druck und Mehrarbeit der Grund, daß im Falle eines Scheiterns niemandem ein Vorwurf gemacht werden kann.

Zornige Manager: (S. 182)

• Zorn und Verachtung im Management sind ansteckend. Wenn das höhere Management seine Macht mißbraucht, ahmt das mittlere Management dieses Verhalten nach (so wie aus mißhandelten Kindern oft mißhandelnde Eltern werden).
• Das Management glaubt, Geringschätzung würde die Mitarbeiter zu größeren Anstrengungen anspornen. Geringschätzung ist die Peitsche, die ein Zuckerbrotund-Peitsche-Management am häufigsten einsetzt. Dabei gibt es keinen Beweis dafür, daß Geringschätzung Menschen jemals zu größeren Leistungen angespornt hätte.
• Wenn ein Manager seine Mitarbeiter geringschätzig behandelt, um sie zu größeren Leistungen anzuspornen, so ist das eher ein Zeichen für die Unzulänglichkeit des Managers als für die der Mitarbeiter.

Mehrdeutige Spezifikationen: (S. 188)

• Mehrdeutigkeit in Spezifikationen deutet auf einen Konflikt zwischen den verschiedenen Interessengruppen an einem System hin.
• . Eine Spezifikation, die keine vollständige Aufzählung der Ein- und Ausgaben enthält, ist ein Flop; sie erfüllt die Anforderungen an eine Spezifikation nicht einmal ansatzweise.
  . Niemand sagt einem, daß eine Spezifikation lausig ist. Die Menschen neigen dazu, die Schuld bei sich selbst zu suchen, nicht bei der Spezifikation.

Die meisten Bücher zum Thema Projektmanagement sind sehr sachlich geschrieben und sind voll gepackt mit Hilfsmitteln und guten Ratschlägen.

Leider lesen die meisten Käufer solcher Bücher nur sehr gezielt einzelne Aspekte nach und eher selten das ganze Buch, denn die Sachlichkeit wirkt oft wenig motivierend auf den Leser.

DeMarco geht einen anderen Weg. Er lehnt sich an ein didaktisches Konzept des Physikers George Gamov an, der in den dreißiger Jahren des letzten Jahrhunderts Kurzgeschichten zu physikalischen Themen schrieb, um diese Themen der breiten Öffentlichkeit leichter zugänglich zu machen.

Gamov entführte seinen Helden Mr. Tompkins in irreale Welten, in denen jeweils einzelne Gesetze der Physik so verändert wurden, dass man diese populärwissenschaftlich gut erklären konnte. Z.B. reiste Mr. Tompkins in eine (Traum)welt, in der der Wert der Lichtgeschwindigkeit c nur 30 Meilen pro Stunde beträgt. An einem Radfahrer beschreibt er die Auswirkungen der Längenkontraktion und weitere relativistische Effekte.

Einen ähnlich genialen Schachzug überlegte sich DeMarco für seine Thesen zum Thema Projektmanagement.

Auf Amazon.de kann man dazu folgendes lesen:
"Man nehme Mr. Tompkins, einen soeben freigesetzten Telekommunikations-Manager, kidnappt ihn durch eine geheimnisvolle Schönheit und beauftragt den Entführten anschließend, im kommunistischen Phantasieland Morovien eine konkurrenzfähige Softwareindustrie hochzuziehen.

Aus diesen Zutaten entsteht ein spritziger Cocktail voller Überraschungen.

Anfangs werden viele noch Mr. Tompkins um die paradiesischen Arbeitsbedingungen beneiden. Aus einer überdimensionierten Entwicklungsmannschaft bildet er 18 Teams, die sechs verschiedene Softwareprodukte entwickeln sollen und miteinander im Wettbewerb stehen. Die Besonderheit dabei: Die Teams sind unterschiedlich groß und setzen zur Zielerfüllung jeweils andere Methoden ein. Plötzlich auftretende bürokratische Hemmnisse und immer utopischere Terminvorgaben verleihen dem gesamten ehrgeizigen Entwicklungsprojekt einen atemberaubenden Bezug zur Realität."
(Quelle: Amazon.de)

Die Kernaussagen des Buchs sind nachfolgend zusammengestellt und basieren auf der Buchausgabe:

Vier Grundsätze guten Managements: (S. 23)

• Wählen Sie die richtigen Leute aus.
• Betrauen Sie die richtigen Mitarbeiter mit den richtigen Aufgaben.
• Motivieren Sie die Mitarbeiter.
• Helfen Sie den Teams, durchzustarten und abzuheben.
• (Alles andere sind Administrivialitäten.)

Sicherheit und Veränderung: (S. 29)

• Menschen können Veränderungen nur in Angriff nehmen, wenn sie sich sicher fühlen.
• Veränderung ist eine entscheidende Voraussetzung für den Erfolg jeder Projektarbeit (und wahrscheinlich auch der meisten anderen lohnenden Unternehmungen).
• Fehlende Sicherheit bewirkt fehlende Risikobereitschaft.
• Risikovermeidung ist fatal: Sie führt dazu, daß die mit einem Risiko verbundenen Chancen ungenutzt bleiben.
• Unsicherheit entsteht, wenn Menschen sich direkt bedroht fühlen oder Angst vor Machtmißbrauch haben.

Negative Verstärkung: (S. 39)

• Drohungen motivieren nur bedingt zu höheren Leistungen.
• Eine Drohung kann so ernst sein wie sie will: Eine Aufgabe wird nicht termingerecht erledigt werden, wenn die veranschlagte Zeit zu knapp bemessen ist.
• Schlimmer noch: Wenn das Ziel nicht erreicht wird, muß man seine Drohung womöglich wahr machen.

Die wichtigsten Körperteile eines Managers sind Herz, Bauch, Seele und Nase. Sie
braucht er um: (S. 51)

• mit dem Herzen zu führen,
• dem Gefühl im Bauch zu vertrauen (auf die innere Stimme zu hören),
• die Organisation zu beseelen,
• zu riechen, daß etwas stinkt.

Vorstellungsgespräch und Personalbeschaffung: (S. 60)

• Wer Personal einstellt, braucht dafür alle für das Management relevanten Körperteile: Herz, Seele, Nase und Bauch (vor allem das Gefühl aus dem Bauch heraus).
• Versuchen Sie nicht, es alleine zu tun - zwei Bäuche sind besser als einer.
• Bitten Sie neu eingestellte Mitarbeiter, ein Projekt zu leiten, dessen Anforderungen exakt denen entsprechen, denen sie bereits früher gerecht wurden, und herausforderndere Ziele dieses eine Mal zurückzustellen.
• Fragen Sie nach Empfehlungen: Vielleicht kann Ihnen die Person, die Ihnen am meisten zusagt, andere gute Kandidaten nennen.
• Reden ist Silber, Zuhören ist Gold.
• Alles funktioniert besser, wenn die Karten richtig gemischt sind.

Produktivitätsverbesserungen: (S. 72)

• Es gibt keine Schnellschüsse zur Verbesserung der Produktivität.
• Produktivitätsverbesserungen erfordern langfristige Investitionen.
• Alles, was kurzfristige Ergebnisse verspricht, ist vermutlich Scharlatanerie.

Risikomanagement: (S. 72)

• Managen Sie Projekte, indem Sie ihre Risiken managen.
• Führen Sie akribisch Buch über die Risiken jedes Projekts.
• Setzen Sie sich mit den ursächlichen Risiken auseinander, statt nur die unerwünschten Folgen am Ende zu sehen.
• Schätzen Sie für jedes Risiko die Wahrscheinlichkeit seines Auftretens und die mutmaßlichen Kosten ab.
• Antizipieren Sie für jedes Risiko das allererste Symptom, mit dem es sich vermutlich ankündigen wird.
• Ernennen Sie einen Risikobeauftragten, einen Mitarbeiter, den Sie von der Das-Schaffen-wir-Haltung entbinden.
• Richten Sie zwanglose (vielleicht sogar anonyme) Kanäle ein, über die schlechte Nachrichten bis in die höchsten Hierarchie-Ebenen hinauf kommuniziert werden können.

Defensives Management: (S. 82)

• Begrenzen Sie die Verluste.
• Sie können Ihre Gesamtleistung stärker durch Eindämmen der Mißerfolge als durch Optimieren der Erfolge verbessern.
• Blasen Sie scheiternde Anstrengungen frühzeitig ab - ohne Wenn und Aber.
• Überlassen Sie es nicht dem Zufall, ob ein Team zusammenwächst oder nicht: Setzen Sie, wenn irgend möglich, ein vorgeformtes Team ein.
• Trennen sie nie ein funktionierende Team (wenn die Teammitglieder damit einverstanden sind). So ersparen Sie Ihren Nachfolgern die Schwierigkeit, sich mit Teams herumschlagen zu müssen, die nur langsam oder überhaupt nicht zusammenwachsen.
• Betrachten Sie ein eingeschworenes Team, das bereit und willens ist, ein neues Projekt in Angriff zu nehmen, als eines der Projektergebnisse.
• Ein Tag, der am Anfang eines Projekts verloren geht, tut genauso weh wie ein Tag, der am Ende verloren geht.
• Es gibt unendlich viele Möglichkeiten, einen Tag zu vertun, . . . aber keine einzige, ihn zurückzubekommen.

  Hier geht es zum 2. Teil des Blogs.

Haben Sie jemals schon an einem Softwareprojekt mitgewirkt? Wenn Ja, dann könnte Ihnen die folgende Geschichte bekannt vorkommen...

Das Projekt ist der Bau eines Einfamilienhauses mit zwei Stockwerken und Keller mit einer Grundfläche von 100 Quadratmetern. Als Baumaterial werden Ziegelsteine verwendet. Der Architekt kalkuliert wie folgt: Das letzte Bauvorhaben (eine Doppelgarage) hatte eine Grundfläche von 25 Quadratmetern. Verbraucht wurden 1000 Ziegel. Die Baukosten betrugen 10.000 Euro, was einen Preis von zehn Euro pro Ziegel bedeutet. Das neue Haus hat die vierfache Grundfläche und die doppelte Höhe - dies bedeutet 8.000 Ziegel oder 80.000 Euro Baukosten.

Das Angebot von 80.000 Euro erhält den Zuschlag, und der Bau beginnt. Da die Maurerkolonne ausgelastet sein will, wird beschlossen, immer nur ein Zimmer zu konstruieren und gleich anschließend zu bauen. Das hat den Vorteil, dass die Planungs- und die Ausführungsgruppe immer ausgelastet sind. Weiter wird beschlossen, mit den einfachsten Sachen anzufangen, um möglichst schnell in die Bauphase einsteigen zu können. Das Schlafzimmer scheint dafür am besten geeignet zu sein.

Das Schlafzimmer wird zu schnell fertig und die Planungen für die Küche müssen unterbrochen werden. Da im Zusammenhang mit der Küche bereits am Esszimmer geplant wurde (Durchreiche zur Küche), wird dieses, um die Bauarbeiten fortführen zu können, als nächstes in Angriff genommen. Schritt drei in der Fertigstellung ist das Wohnzimmer. Als auch dieses fertig ist, stellt sich heraus, dass die Planungen für Küche und Bäder doch mehr Zeit in Anspruch nehmen, als geschätzt. Da der Bauherr auch "endlich" mal was Konkretes sehen will, wird eine Seite der Fassade komplett hochgezogen, um den Eindruck des fertigen Hauses zu vermitteln. Um das Dach montieren zu können, wird die andere Seite der Fassade ebenfalls hochgemauert. Da hier noch keine Planung vorliegt, können leider keine Fenster- und Türöffnungen berücksichtigt werden. Man ist aber überzeugt davon, diese ohne größere Probleme später herausbrechen zu können.

Leider ist damit auch die Grundfläche des Hauses festgelegt. Damit ergibt sich der Zwang, die Küche in den ersten Stock verlegen zu müssen. Statt der geplanten Durchreiche wird nun ein Speiseaufzug eingebaut, was das Projekt erheblich verteuert. Dadurch haben sich trotz beständigen Arbeitens unter Hochdruck die Bauarbeiten verzögert, so dass der Hausherr (der seine alte Wohnung gekündigt hatte) gezwungen ist, in das erst halbfertige Haus einzuziehen. Als besonders nachteilig erweist sich das Fehlen von Elektro- und Sanitäranschlüssen. Letzteres Problem wird durch Anmieten eines Toilettenwagens (Kosten 170 Euro pro Tag) vorläufig endgültig überbrückt.

Alle anderen Arbeiten werden gestoppt, um vorrangig die Elektroinstallation vorzunehmen, schon allein wegen der fehlenden Fenster. Mit Hilfe externer Kräfte (1500 Euro pro Tag) wird die Elektronik in kürzester Zeit verlegt, allerdings auf Putz, um "saubere Schnittstellen" für die noch nicht geplanten Hausteile zu schaffen. Im Alltagsbereich stellt sich als nachteilig heraus, dass das Wohnzimmer als zuerst gebauter Hausteil als einziges Zimmer zur Straße hin liegt. Damals war dies die einfachste Lösung (kurzer Transportweg der Ziegelsteine), die Haustür hierhin zu legen, so dass das Haus vom Wohnzimmer her betreten werden muss.

Dies erscheint dem Hausherrn ganz und gar unerträglich; als Lösung wird ein Teilabriss erwogen. Dagegen spricht, dass bereits 250.000 Euro verbaut sind und dass der Bauherr samt Familie übergangsweise in ein Hotel ziehen müsste. Die Tür nach hinten zu versetzen, erforderte ein Loch in die Fassade zu brechen. Im Hinblick auf die unsichere Statik wird davon Abstand genommen. So wird das Haus bis zum ersten Stock von außen mit Erde aufgeschüttet. Das ursprünglich geplante Badezimmer wird zum Flur umfunktioniert - die Toilettenwagen-Lösung hat sich inzwischen etabliert. Weiterer Vorteil: auf den Fensterdurchbruch im ehemaligen Erdgeschoss kann verzichtet werden.

Das Erdgeschoss wird zum Keller, der Dachgarten als Wohnzimmer umgebaut und aus Kostengründen (und um eine endgültige Lösung nicht von vornherein zu verbauen) mit Planen abgedeckt. Kostengründe sind es auch, die das Projekt an dieser Stelle beenden. Alles weitere wird auf eine spätere Realisierungsphase verschoben.

Fazit: Der Bauherr hat zwar etwas ganz anderes bekommen, als er eigentlich wollte - aber immerhin hat er überhaupt etwas bekommen, auch wenn er statt der geplanten 80.000 Euro nun immerhin ganze 440.000 Euro hingelegt hat. Der Architekt hat seine Truppe ständig ausgelastet und mit Hochdruck und Überstunden gearbeitet. Wie vorgesehen, wurden 8000 Ziegelsteine verbraucht, was beweist, dass seine Schätzung im Prinzip richtig war. Seine aktualisierte "Cost-Database" weist nun einen Preis von 55 Euro pro Ziegel aus, was bei der nächsten Garage einen Angebotspreis von 55.000 Euro ergibt.

Wenn du entdeckst, dass du ein totes Pferd reitest, steig ab.

Doch Projektmanager versuchen oft andere Strategien: Täuschen, Verschleiern, Abmildern...

1. Wir besorgen eine stärkere Peitsche.
2. Wir wechseln die Reiter.
3. Wir sagen: „So haben wir das Pferd doch immer geritten.“
4. Wir gründen einen Arbeitskreis, um das Pferd zu analysieren.
5. Wir besuchen andere Orte, um zu sehen, wie man dort tote Pferde reitet.
6. Wir erhöhen die Qualitätsstandards für den Beritt toter Pferde.
7. Wir bilden eine Task Force, um das tote Pferd wieder zu beleben.
8. Wir schieben eine Trainingseinheit ein, um besser reiten zu lernen.
9. Wir stellen Vergleiche unterschiedlich toter Pferde an.
10. Wir ändern die Kriterien, die besagen, ob ein Pferd tot ist.
11. Wir kaufen Leute von außerhalb ein, um das tote Pferd zu reiten.
12. Wir schirren mehrere tote Pferde zusammen an, damit sie schneller werden.
13. Es wird versucht, Leistungsanreize für das tote Pferd einzuführen.
14. Wir machen zusätzliche Mittel locker, um die Leistung des Pferdes zu erhöhen.
15. Wir machen eine Studie, ob es billigere Berater gibt.
16. Wir kaufen etwas zu, das tote Pferde schneller laufen lässt.
17. Wir erklären, daß unser Pferd „besser, schneller und billiger“ - tot ist.
18. Wir bilden einen Qualitätszirkel, um eine Verwendung für tote Pferde zu finden.
19. Wir überarbeiten die Leistungsbedingungen für tote Pferde.
20. Wir richten eine unabhängige Kostenstelle für tote Pferde ein.
21. Es wird versucht, die Kommunikation zwischen Reiter und totem Pferd zu optimieren.
22. Es werden Berater engagiert um das Reiten toter Pferde zu optimieren.
23. Es werden Mittel eingekauft, die tote Pferde schneller laufen lassen.
24. Die Qualitätsstandards für den Beritt toter Pferde werden erhöht.
25. Es wird Restrukturiert, damit das tote Pferd in einem anderen Bereich tätig ist.
26. Das Pensions Eintrittsalter für tote Pferde wird drastisch verringert.
27. Wir erklären: 'Kein Pferd kann so tot sein, dass man es nicht noch schlagen könnte'.
28. Wir melden das Pferd bei einem Weiterbildungskursus zur Selbstmotivation an.
29. Wir bezahlen eine Tierarzt, der das Innere des Pferdes umorganisiert.
30. Wir malen PowerPointFolien, die präsentieren, was das Pferd könnte, wenn es denn leben würde.
31. Wir bilden eine neue Abteilung, integrieren dort alle toten Pferde, um Synergien zu nutzen.
32. Wir wechseln den Pferdelieferanten.
33. Der Futterlieferant wird gewechselt.
34. Das tote Pferd wird „reengineert“.
35. Wir suchen einen finanzstarken Partner und gründen zusammen mit dessen toten Pferden ein Joint Venture.
36. Wir bringen die toten Pferde unter einem phantasievollen Namen an die Börse.
37. Wir tauschen das tote Pferd gegen ein anderes totes Pferd aus, dass laut Prognose schneller läuft.
38. Wir nennen das tote Pferd „Dead Horse Power“ und bieten es als neuestes Produkt auf dem afrikanischen Markt an.
39. Wir lassen das tote Pferd 48 Stunden ausruhen und probieren aus, ob es danach wieder läuft.
40. Es wird angeordnet, daß Pferde nicht mehr mitten im Fluß gewechselt werden dürfen, weil dies die Ursache des Todes gewesen sein könnte.

Nachfolgend finden Sie eine Linksammlung zum Thema Projektmanagement:

Organisationen

• Project Management Institute (PMI)
• International Project Management Association (IPMA)
• PRINCE2 (PRINCE2)
• Scrum.org

Magazine

• Projektmagazin.de Projektmagazin (teilweise kostenpflichtig)
• Projektmanagement aktuell GPM-Mitgliedermagazin (teilweise kostenpflichtig)

Blogs

• PM-Blog.com Projektmanagement Blog mit pragmatischen Anregungen, Tipps und Erfahrungsberichten (von den Machern von PM-Handbuch.com)
• Projekt Management Beratung News und Wissen zum Projektmanagement von Standardisierung bis Anwendung

andere Quellen

• XING allgemeine Netzwerkplattform mit PM-Forum

Was ist Scrum?

Scrum ist ein Vorgehensmodell aus dem Bereich der agilen Softwareentwicklung, dass aus der Produktentwicklung heraus entstanden ist und maßgeblich von Jeff Sutherland und Ken Schwaber ausgebaut wurden ist.
Das Modell Scrum definiert im wesentlichen Rollen und Hilfsmittel um die Entwicklung eines (Software-) Produkts erfolgreich durchzuführen. Eine Grundannahme ist dabei, dass die komplexen Prozesse weder in grob abgeschlossene Phasen zerlegt noch als fein granulare Aufgaben in Stunden abgeschätzt werden können.

Begrifflichkeiten und Prinzipien:

Product Owner

Gruppe oder Person die den Kunden repräsentiert. Als Kunde definiert und priorisiert die Funktionen und legt die Abgabezeitpunkte der einzelnen Releases fest. Ebenso ist er dafür verantwortlich Ergebnisse abzunehmen oder abzulehnen.

Scrum Master

Person die das Team führt und Störungen von außen während der Sprint-Phasen (dazu später) blockt und weitere Aufgaben des Managements übernimmt.

Team

Das Team setzt die erarbeiteten Aufgaben (Stories aus dem Sprint-Backlog) um, stellt Ergebnisse vor und trägt maßgeblich dazu bei den Prozess zu verbessern (Retrospective).

Product-Backlog

Beinhaltet alle priorisierten Anforderungen die der Kunde an das Produkt hat.

Sprint-Backlog

Teilmenge an Anforderungen/Funktionen aus dem Product-Backlog die in einem Sprint umgesetzt werden.

Sprint

Als Sprint bezeichnet man die Phase (ca. 30 Tage) im Projekt in der die Stories aus dem Sprint-Backlog umgesetzt werden und (das ist entscheidend) keine Einflussnahme von außen mehr erfolgt. Die typischen Änderungen in letzter Minute bleiben hier aus. Anpassungen können aber nachträglich in das Product-Backlog aufgenommen, priorisiert und einen nächsten Sprint mit eingesteuert werden.

Story

Eine Story ist ein Eintrag aus dem Sprint-Backlog. Im Allgemeinen werden diese Stories auf Papier ausgedruckt und an ein Whiteboard geheftet. Start- und Restaufwand sowie zu erledigende Aufgaben die zum Abschluss dieser Aufgabe gehören werden (neben der Beschreibung) darauf vermerkt. Erst wenn diese Aufgaben der Story (z.B. Technische Doku, Test) erledigt sind ist die Story wirklich abgeschlossen. Um dieses Prinzip von einer final beendeten Aufgabe noch mehr in den Vordergrund zu rücken spricht man von "Done Done". Dies soll dem 90%-Syndrom entgegenwirken.

Sprint-Planning

Vor jeder Sprint-Phase müssen die nächsten Stories aus dem Product-Backlog ausgewählt werden. Das hängt von den Prioritäten im Product-Backlog ab aber auch von Rahmenbedingungen wie: Verfügbarkeit von Mitarbeitern und aktueller Produktzustand. Wichtig ist hierbei die Anforderungen des Product-Owner in zuzuordnende Aufgaben zu teilen. Aus der Praxis heraus kann ich sagen, dass diese Aufteilung nicht zwingend erforderlich ist. Wer über ein Team mit umfassendem Know-How hat muss die Aufteilung von UI, Business-Logic, etc. nicht unbedingt in unterschiedliche Hände legen.
In einem (meist zweiten) Sprint-Planning wird das Team dazu beitragen, die vereinbarten Stories für diesen Sprint zu bewerten.

Daily-Scrum

In einem täglichen, kurzen (15min) Meeting zwischen Scrum-Master und Team erläutert jeder was er seit dem letzten Meeting getan hat und bis zum nächsten geplant hat. Er berichtet auch wenn abhängige Aufgaben oder äußere Bedingungen sie oder ihn abhalten eine Aufgabe zu erledigen.

Sprint Review

Im Review werden die Ergebnisse des Teams dem Product-Owner vorgestellt. Dabei geht es nicht darum die schönsten Präsentationen zu zeigen, sondern vielmehr die umgesetzte Funktionalität vorzuführen. Die Resultate können genehmigt oder auch abgelehnt werden.

Retrospective

Das Reprospective-Meeting dient der kontinuierlichen Verbesserung des eigenen Scrum-Prozesses. Das Team stellt fest was gut oder nicht so gut gelaufen ist und versucht diese während des nächsten Sprints zu berücksichtigen (abhängig von Rahmenparametern).

Mehr dazu kann man in der Präsentation "zen of Scrum" von Jurgen Appelo lesen (s. letzten Blog-Eintrag)

Die Frage "Woran scheitern Projekte?" oder "Was muss man tun, damit ein Projekt erfolgreich wird?" sind die häufigsten Fragen im Bereich Projektmanagement, denn kein Projektleiter will, dass gerade sein Projekt "an die Wand fährt". Mit den Antworten auf diese Fragen erhofft man sich häufig den "Stein der Weisen" im Projektmanagement. Es geht darum, dass man altbekannte Fehler vermeidet und erfolgreiche Vorgehensmodelle kopieren bzw. nachahmen kann.

Auf einen wichtigen Fakt möchte ich vorab aber noch hinweisen:

"Alles ist relativ." oder etwas anders formuliert: "Es kommt auf den Kontext an...". Was soll dass nun wieder??? In wenigen Worten ausgedrückt und stark vereinfacht, bedeutet es, dass die hier aufgeführten Fehler und ggf. Problemlösungen je nach Kontext des Projekts unterschiedlich stark ausgeprägt sein können und evtl. in Ihrem speziellen Fall nur wenige Punkte zum Tragen kommen.

Der Kontext des Projekts ist geprägt durch:

• die Größe des Vorhabens (der geschätzte Aufwand bzw. das Budget)
• die Anzahl der Beteiligten am Projekt (Einzelperson, kleines Team, größeres Team, sehr großes Team)
• die Organisationsform des Unternehmens (kleine Firma mit wenigen Hierarchien vs. sehr große Konzern-Organisation mit vielen Hierarchie- und Berichtsebenen)
• die "Projekterfahrenheit" der Beteiligten über die Ebenen der Organisation hinweg (Projektteam, Projektowner)
• die Ziele des Projekts (hier sei insbesondere auf das z.T. sehr komplexe Zielgeflecht gerade in großen Organisationen hiengewiesen)
• die persönlichen Ziele der einzelnen Projektbeteiligten
• und und und...

"Sag mir, wie ein Projekt beginnt und ich sage Dir, wie es endet."