Zum Inhalt springen

Das Eiserne Dreieck: Ignorieren auf eigene Gefahr

Korrigierte Projektplanung: Das Qualitätsziel wird reduziert.

In einem kurzen Video spricht Philippe Back über die drei Aspekte im Projektgeschäft. Das Video ist in Englisch. Ich möchte den Beitrag allen Projektmanagern wärmstens empfehlen. Wenn es im Projekt schief geht, ist das Eiserne Dreieck vermutlich missachtet worden. Ich möchte Philippes Vortrag kurz zusammenfassen.

Die drei Ecken (Aspekte) sind:

  • Scope (also das, was vom Projekt geleistet werden soll)
  • Qualität
  • Zeit

Diese drei Aspekte bilden die drei Achsen des Koordinatensystems. Zu Projektbeginn definiert man das Ziel auf der jeweiligen Achse. Man setzt also für jeden Aspekt einen Punkt.

Das kann dann so aussehen:

Die ursprüngliche Projektplanung

Die ursprüngliche Projektplanung mit ihren drei Zielen

In diesem Beispiel hat man sich entschlossen, 30 der zuvor analysierten 35 Use Cases umzusetzen. Man möchte mit dem Produkt in das Weihnachtsgeschäft 2011 und möchte eine Fehlerquote < 3% erreichen. Das sind möglicherweise sehr sportliche Ziele.

Das Projekt geht voran – nur leider nicht wie erhofft. Es treffen sich also nun die Projektverantwortlichen zur Krisensitzung und überlegen was zu tun ist. Sie haben jetzt verschiedene Möglichkeiten. Philippe Back empfiehlt, zuerst eine klare Perspektive auf das Projekt einzunehmen. Um zu verstehen, was damit gemeint ist, betrachten wir die Seiten des Dreiecks. Jede Dreieckseite stellt eine Perspektive dar:

  • Scope <-> Qualität
  • Qualität <-> Zeit
  • Scope <-> Zeit

Alle weiteren Überlegungen unserer fiktiven Krisensitzung hängen von der gewählten Perspektive ab. Dahinter steckt die Erkenntnis, dass man nur ein Ziel reduzieren darf, da das Projekt sonst jegliche Orientierung verliert. Weiter im Beispiel: Unsere Projektmanager wollen Ihr Produkt unbedingt im Weihnachtsgeschäft platzieren. Und da die Konkurrenz nicht schläft, müssen die geplanten Use Cases angeboten werden. Es bleibt also nur übrig, den Qualitätsanspruch zu reduzieren. “Ist ja nicht so schlimm. Da reichen wir ein paar Bugfixes nach…” Sie kennen das? Ich hatte schon Software in den Händen, bei der muss das so gelaufen sein.

Um das Projekt zu retten, reduzieren die Projektmanager das Qualitätsziel also auf eine Fehlerquote < 15 % statt zuvor < 3%. Das verschafft Luft!

Korrigierte Projektplanung: Das Qualitätsziel wird reduziert.

Korrigierte Projektplanung: Das Qualitätsziel wird reduziert.

In anderen Projekten wird man sich eventuell anders entscheiden müssen. Stellen Sie sich ein Verkehrsleitsystem vor. Da wird man am Qualitätsziel bestimmt nichts ändern dürfen. Je nach der gewählten Perspektive wird man aber wohl schon den Auslieferungszeitpunkt oder den Funktionsumfang reduzieren können. Aber immer nur ein Ziel ändern!

Ich persönlich interpretiere Philippe Backs Beitrag aber schon dahingehend, dass man in zukünftigen Steuerungsmaßnahmen schon die Perspektive wechseln kann. Aber das erfordert, dass man den Erfolg / Misserfolg aktuell laufender Maßnahmen genau beziffern kann. Ein sprunghaftes Wechseln zwischen den Perspektiven, verhindert die Messbarkeit und verunsichert jedes Projektteam.

Was halten Sie von Philippes Gedanken?

Anmerkung: Ich habe Philippe Back als Projektmanagement Guru persönlich kennen und schätzen gelernt. Besonders interessant finde ich, was Philippe über Projektmanagement und Prozesse schreibt und spricht.

 

Ähnliche Artikel:

  1. Philippe Back spricht mit Bernd Lohmeyer: Nutzen zentrierter Beratungsansatz und Usability Interview über Nutzerzentrierten Beratungsansatz. Philippe Back interviewt Bernd Lohmeyer. Erst wenn man die Geschäftsanforderungen genau kennt, kann man eine Lösung...
  1. avatar

    Bernd,

    Great graphics and write up. It is indeed a shame that a lot of project managers do not have the cojones to keep their line when it comes to selecting an edge and staying there.

    This has to do with self esteem in my view. These so-called PMs are easily swayed out of their way because they trust others more than they trust their own gut or think they will gain something out of being “yes-men.” Beware of the latter, they usually jump ship before the ship will get into the iceberg. They can then look at the wreckage in a safeboat from a distance.

    It takes courage to be a great project manager. When I am in that role, I’ll never be the “yes-man.” What matters is getting the product out with the agreed upon characteristics. But this means that I have to be very selective on what projects and environments I will accept to work in/with. No every organization deserves great PMs. Organizations that deal with their people as they were “cogs in the machine” deserve to go down in flames, especially when competition intensifies. In the knowledge worker era, we need to be good at what we do, but it is our duty to help only those who deserve it. Darwin was right.

    März 26, 2011
  2. avatar
    Bernd Lohmeyer #

    Hi Philippe,

    I think when a project comes into troubled waters the pressure to succeed leads project managers to react head over heels. The higher the pressure is the more screws they try to drive at once. As a result they switch perspectives permanently and doing so they lose any ability to measure success of activities. Without knowing they switch from being a driver (what they are supposed to be) to being managed by chaotic circumstances. You stated that very clearly.

    Whether a project deserves a good PM or not is another issue. To my mind more relevant is that many projects / companies (the ones with the “cogs in the machine”) prevent brilliant PMs to act as such. This is pretty sad. But how to find out before you sign a contract? I’m afraid that all persons in charge will pretend the willingness to adopt your PM-baselines. Don’t they? Are there any signals which you can interprete as a warning?

    Thanks and bye,

    Bernd

    März 28, 2011

Antworten

Sie können einfaches HTML in Ihren Kommentaren verwenden. Ihre E-Mail-Adresse wird nicht veröffentlicht.

Abonnieren Sie Kommentare via RSS