Allgemein

Führungskräfte sind Vorbilder

Veröffentlicht am

Ich weiß, es ist schon ziemlich abgedroschen…

  • Leading by example
  • Taten zählen mehr als Worte
  • Wasser predigen, Wein trinken
  • Der Fisch stinkt vom Kopf

All diese Sprichworte sagen im Wesentlichen aus, dass sich Mitarbeiter an den Handlungen von Führungskräften orientieren. Eine Führungskraft muss daher ein feines Gespür dafür entwickeln, welche Konsequenzen die eigenen Handlungen auf den inneren Kompass der Mitarbeiter hat. (mehr …)

Allgemein

Überlasse niemandem die Deutungshoheit über Daten

Veröffentlicht am

Kennen Sie das? Zwei Personen diskutieren über das gleiche Chart – die Prognose des weiteren Arbeitsfortschritts. Person A sagt „ist doch alles prima, wir werden voraussichtlich etwas vor dem geplanten Fertigstellungstermin fertig“. Person B sagt „das sieht fürchterlich aus, ich bin mir nicht sicher, ob wir es schaffen, es könnte ja noch x,y,z passieren“. (mehr …)

Allgemein

Welche Differenzierungsmerkmale sind heute und morgen relevant?

Veröffentlicht am

In der Vergangenheit (und auch heute noch) werden Produkte häufig in den Dimensionen Produkteigenschaft, Preis und Marke differenziert:

  • Produkteigenschaft: z.B. Spaltmaße bei einem Auto, Auflösung bei Digitalkameras etc.
  • Preis: z.B. niedrigster Preis in einer Produktkategorie
  • Marke: z.B. „das Beste oder nichts“, „Zeit für Gefühle“

Aus meiner Sicht werden diese Differenzierungsmerkmale zu Gunsten von zwei neuen Merkmalen in den Hintergrund treten:

  • Customer knowledge: das Wissen über den Kunden, seine Bedürfnisse und seinen Kontext
  • Customer experience: die Einfachheit und Bequemlichkeit der Interaktion.

Markant formuliert: Customer Experience is the next Competitive Battleground.

Diese Hypothese mache ich an einer Reihe von Beispielen fest:

  • Musik & Filme: Der Erfolg von Streamingdiensten (z.B. Spotify, Netflix, Amazon Prime) basiert nicht nur auf einem geänderten Geschäftsmodell, sondern insbesondere auf den o.g. Differenzierungsmerkmalen:
    • Customer Knowledge: der Kunde bekommt relevante Empfehlungen basierend auf seinen Vorlieben und seiner Historie
    • Customer Experience: die Interaktion ist extrem einfach, sowohl in der Bedienung (siehe insbesondere Netflix) als auch in der Bezahlung (Abo-Modell, Flatrate)
  • Mobilität: Das Wachstum von Anbietern für Carsharing / integrierter Mobilität (z.B. Car2Go, Qixxit, Moovel) fußt ebenfalls auf diesen Differenzierungsmerkmalen:
    • Customer Knowledge: wann will mein Kunde von Ort A nach Ort B
    • Customer Experience: der Kunde zahlt nur für die tatsächliche Nutzung bzw. er erhält einen Vergleich aller Reisemöglichkeiten
  • Handel: Amazon ist nicht notwendigerweise der günstigste Anbieter, aber auch hier:
    • Customer Knowledge: Amazon kennt seine Kunden und kann relevante Vorschläge unterbreiten
    • Customer Experience: Einfacher Check-out-Prozess (one-click), einfache Retouren, einfacher Ersatz von defekten Produkten – all dies mit dem Ziel, die Interaktion für den Kunden so einfach und bequem zu gestalten

Was heißt dies jeweils für die Produzenten? Sie werden in den Hintergrund gedrängt. Netflix entscheidet, welcher Film dem Kunden vorgeschlagen wird – nicht das Studio. Qixxit entscheidet, ob ein Kunde besser das Auto oder das Flugzeug nehmen sollte – nicht die Airline. Amazon entscheidet, welches Buch dem Kunden vorgeschlagen wird – nicht der Verlag. Die Produzenten werden sowohl aus Sicht des Kunden als auch der Anbieter austauschbar.

Und in der Touristik? Sind Reiseveranstalter immun gegen diese Entwicklung? Wahrscheinlich nicht. Das Beispiel booking.com zeigt aus meiner Sicht eindrucksvoll, welchen massiven Effekt eine großartige Customer Experience schon heute haben kann. Zukünftig erwarte ich aber die größte Veränderung von Google: Google kennt auf Grund der Suchen und ggf. über die Nutzung von Android den Kontext des Kunden perfekt. Wohin möchte er reisen, wann möchte er reisen, Haushaltseinkommen, Interessen… für Google ist dies ermittelbar. Jetzt müssen Sie dem Nutzer nur noch die passenden Reisebausteine vorschlagen – schon sind alle Anbieter von touristischen Leistungen in den Hintergrund gedrängt und austauschbar.

Ist das ein bedrohliches Szenario? Absolut. Ist das ein realistisches Szenario? Absolut. Müssen Reiseveranstalter den Kopf in den Sand stecken? Nein – sie müssen allerdings sehr wohl überlegen, wie sie die Differenzierungsmerkmale Customer Knowledge und Customer Experience umsetzen wollen.

Allgemein

So vermeiden Sie Micromanagement in Projekten

Veröffentlicht am
Kennen Sie diese Situation? Sie wollen kein Micromanagement betreiben. Sie nehmen sich fest vor, Arbeiten zu delegieren. Sie vertrauen Ihren Teilprojektleitern. Und trotzdem finden Sie sich nach einigen Monaten in einer Situation wieder, die ein Außenstehender als Micromanagement bezeichnen würde. Wie konnte es soweit kommen?
Ich beobachte derartige Situationen bei Unternehmen, die selten große und komplexe Projekte durchführen, d.h. mit mehr als 100 Mitarbeitern und mehr als 10 Teilprojekten. Diesen Unternehmen ist die Einzigartigkeit des Projektes bewusst und sie suchen üblicherweise nach einem erfahrenen Projektleiter, der es führt. Diese Sorgfalt wird auf der Ebene der Teilprojektleiter oft nicht mehr angewendet. Die Zeit drängt und es werden Personen als Teilprojektleiter eingesetzt, die gerade verfügbar sind und/oder in die Aufgabe hineinwachsen können.
Im Laufe des Projektes treten dann die Probleme auf, die unerfahrene Projektleiter haben:
  • Die Aufgaben werden nicht klar im Team verteilt
  • Die Mitarbeiter arbeiten nicht ausschließlich an den geplanten Projektaufgaben
  • Probleme werden nicht rechtzeitig erkannt und/oder eskaliert
  • Der Fortschritt ist nicht transparent und/oder wird nicht transparent kommuniziert
Allerdings nicht vereinzelt, sondern in allen Teilprojekten. Dies bringt den Projektleiter in eine Zwickmühle. Probleme in einem einzelnen Team könnte er tolerieren und den Teilprojektleiter die Erfahrung sammeln lassen. Sind alle Teams betroffen, riskiert er mit diesem Ansatz den Erfolg des Projektes. Häufig sehen Projektleiter keine andere Möglichkeit, als explizit vorzugeben, wie der Mitarbeitereinsatz zu erfolgen hat, wie kommuniziert wird, wie der Fortschritt zu berichten ist etc. Micromanagement!
Lassen Sie das Kind gar nicht erst in den Brunnen fallen. Achten Sie darauf, dass bei kritischen Projekten der Großteil Ihrer Teilprojektleiter über die notwendige Qualifikation und Erfahrung verfügt. Wenn dies nicht möglich ist, suchen Sie für die Anfangsphase des Projektes nach einem Coach für die Teilprojektleiter, damit sie schneller „up to speed“ kommen. Und auch wenn Sie schon in der Situation sind, dass es im Projekt lichterloh brennt – vermeiden Sie Micromanagement und suchen Sie Coaches, damit die Aufgaben der Teilprojektleiter dort bleiben, wo sie hingehören. Und ordentlich erledigt werden.
Allgemein

Broken-Windows-Theorie & Softwareentwicklung

Veröffentlicht am

Ich habe mich kürzlich an die Broken-Windows-Theorie erinnert und überlegt, ob sie auch auf die Softwareentwicklung „passt“:

  • Bei 300 Fehlern ist der 301. Fehler „nicht mehr schlimm“
  • Bei 1000 undokumentierten Klassen ist die 1001. fehlende Dokumentation „nicht mehr schlimm“
  • Bei 50 nicht eingehaltenen Terminaussagen ist der 51. gerissene Termin „nicht mehr schlimm“
  • Bei 100 ergebnislosen Meetings ist das 101. ergebnislose Meeting „nicht mehr schlimm“
  • Bei 20 ignorierten Eskalationen ist die 21. Eskalation „nicht mehr schlimm“

Unter der Hypothese, dass Sie unter den Folgen der „zerbrochenen Scheiben“ leiden, welche Maßnahmen könnten Sie ergreifen?

  • Eindeutige Definition des „erwünschten Verhaltens“ und ggf. auch Priorisierung von Rahmenbedingungen (z.B. fehlerfreie Softwarekomponente ist wichtiger als mehr Funktionalität; vollständiger Abschluss von Tests ist wichtiger als Termineinhaltung; …)
  • Sofortige & konsequente Sanktionierung des unerwünschten Verhaltens ohne Ausnahmen (d.h. gerade kein „im Prinzip ist das richtig, aber jetzt gerade müssen wir eine Ausnahme machen…“)
  • Schrittweise Beseitigung der bereits existierenden „zerbrochenen Scheiben“

Die Umsetzung derartiger Maßnahmen wird schmerzhaft… Sie müssen Ihr liebgewonnenes Verhalten verändern und Ihre Komfortzone verlassen, denn ein „weiter-so“ ist aus meiner Sicht keine Alternative.

Test

Brauchen Sie einen vollständigen Überblick über den Testumfang ?

Veröffentlicht am

Eine der ersten Tätigkeiten eines Testleiters ist aus meiner Sicht, sich einen möglichst vollständigen Überblick über den Testumfang zu verschaffen. Damit meine ich einerseits die Funktionalitäten / Bereiche, die getestet werden müssen. Andererseits auch die ungefähre Anzahl der durchzuführenden Testfälle.

Mit diesem Ansinnen stoße ich regelmäßig auf Verwunderung und Unverständnis. Woher soll ich jetzt schon wissen, was ich testen will? Das kann ich doch erst sagen, wenn ich die Testvorbereitung abgeschlossen habe. Wie kann ich denn die Anzahl der Testfälle abschätzen? Das kann ich erst sagen, wenn ich sie erstellt habe. Und überhaupt, das ist ja alles völlig ungenau…

Warum sollte man sich also die Arbeit machen? Ein Beispiel aus einem laufenden Projekt. Das Projektteam berichtete seit mehreren Sprints, dass alle Tests vorbereitet und erfolgreich durchgeführt waren. Als Außenstehender musste man den Eindruck bekommen, dass die Software zu jedem Zeitpunkt eingeführt werden konnte. Auf meine explizite Nachfrage erfuhr ich, dass im aktuellen Testsystem nur eine stark begrenzte Anbieter- und Produktvielfalt nutzbar sei. Ein Test mit weiteren Anbieter- und Produktvarianten sei selbstverständlich vor einem Go-Live notwendig. Die Frage, ob dieser Test zeitlich in die geplante Lücke zwischen Fertigstellung der Software und Go-Live passe, konnte nicht beantwortet werden.

Wozu wird also der Überblick über den Testumfang benötigt?

  • Er sorgt für die notwendige Transparenz – wie viel Arbeit liegt noch vor mir
  • Er ermöglicht eine verlässlichere Planung und ein besseres Erwartungsmanagement – die notwendigen Tätigkeiten werden nicht in „Salamitaktik“ kommuniziert

Mein Plädoyer an jeden Testleiter: Verschaffen Sie sich initial einen vollständigen Überblick über den Testumfang! Mut zur Lücke – es kommt nicht auf exakte Informationen an, sondern auf das „große Ganze“! Verfeinern Sie den Überblick kontinuierlich, wenn Sie neue Erkenntnisse haben!


Wenn Sie mehr über das Thema Test wissen wollen, schauen Sie sich doch meinen Onlinekurs zum Thema „Testreporting“ an!

Projektmanagement

Wenn der Projektfortschritt hinter Plan ist…

Veröffentlicht am

Lassen Sie uns mit einem kleinen Quiz starten: Was machen Sie, wenn Sie eine derartige Grafik sehen:

  • Sie verschieben den Endtermin nach hinten
  • Sie reduzieren das Ziel (die Anzahl)
  • Sie ergreifen Maßnahmen, um die Produktivität zu steigern
  • Sie machen nichts – ab der nächsten Woche wird die Produktivität ganz sicher steigen

Interessanterweise erlebe ich es immer wieder (und erschreckend oft), dass die Option 4 verfolgt wird. Dabei ist es unerheblich, ob es sich um den Projektfortschritt, Testfortschritt oder Produktionsfortschritt handelt. Die Menschen, die derartige Entscheidungen treffen, sind in der Regel intelligent, gut ausgebildet und mit reichlich Berufserfahrung ausgestattet.

Wieso laufen diese Menschen sehenden Auges ins Verderben? Wieso wählen sie einen objektiv unmöglichen Weg? Diese Frage beschäftigt mich seit vielen Jahren.

Ich habe hierzu die folgende Hypothese entwickelt:

  • Das Projekt / der Test / die Produktion existiert nicht allein, sondern ist in ein Umfeld eingebettet
  • Das Umfeld ist üblicherweise ständigen Veränderungen unterworfen
  • Früher oder später kann eine dieser externen Veränderungen als Erklärung dienen, warum der eigene Plan nicht erreicht werden kann

Ich höre beispielsweise Erklärungen wie…

  • „Projekt X ist in Verzug und benötigt zusätzliche Ressourcen. Selbstverständlich helfen wir, das hat aber leider Auswirkungen auf unseren eigenen Projektplan…“
  •  „Das Testsystem unseres Partners Y steht diese Woche nicht zur Verfügung. Ausgerechnet jetzt hatten wir unseren Spezialisten für die Tests eingeplant, es ist völlig offen, wann er wieder zur Verfügung steht…“
  • „Wir hatten mit Unterstützung aus Abteilung Z geplant. Die Kollegen wurden überraschend für ein anderes Thema abgezogen, jetzt können wir unseren Plan nicht erreichen…“

Die Gründe für die Planabweichung liegen außerhalb des eigenen Einflussbereichs, daher konnte man selber auch nichts dagegen tun.

Jetzt könnte man sagen „Ist doch egal, aus welchem Anlass der Plan aktualisiert wird und Maßnahmen ergriffen werden. Wichtig ist, dass etwas passiert“. Dieser Aussage stimme ich nicht zu. Ja, die Kosten auf Grund einer längeren Projektlaufzeit fallen eh an. Ja, die Kosten für zusätzliche Tester fallen eh an. Der größte Schaden entsteht allerdings üblicherweise nicht durch erhöhte Projektkosten, sondern durch entgangene Chancen wegen einer späteren produktiven Nutzung.

  • Das neue Cabrio steht nicht im Frühling bei den Händlern? Dann kaufen die Kunden ein anderes…
  • Die neue Spielekonsole ist nicht für das Weihnachtsgeschäft verfügbar? Dann kaufen die Kunden bei der Konkurrenz…
  • Die Flugzeuge sind noch nicht mit den neuen Business Class Sitzen ausgestattet? Dann fliegen die Kunden mit der Konkurrenz…

Neben dem direkten Schaden durch entgangene Chancen entsteht ggf. auch ein indirekter Schaden – die Kunden bleiben bei der Konkurrenz. Projektleiter, die auf erkannte Probleme nicht unverzüglichen reagieren, schaden einem Unternehmen mehr, als es auf den Blick scheint. Daher ist das Aussitzen von Problemen bis „5 vor 12“ in meinen Augen die schlechteste Option.

Allgemein

Anwendertest und Scrum – wie passt das zusammen?

Veröffentlicht am

Ich saß vor einigen Tagen mit Kollegen zum Thema „Test“ zusammen, insbesondere aus einer Anwender- / Nutzerperspektive. In klassischen Projektvorgehensweisen wie beispielsweise V-Modell ist diesem Test üblicherweise eine eigene Projektphase „Abnahmetest“ oder auch „User Acceptance Test“ gewidmet. Insofern stellt sich weniger die Frage, ob ein Anwendertest durchgeführt wird, sondern wie gut und wie ausführlich.

Und in Scrum? Die Definition of Done wird gemeinsam entwickelt, das Entwicklungsteam ist für die Qualität der Software verantwortlich, der Product Owner definiert Akzeptanzkriterien in den User Stories. Ergo gibt es keine Notwendigkeit für Anwendertest?!

Falsch – und gleichzeitig richtig. Ein Ziel von Scrum ist das kontinuierliche und frühzeitige Feedback von Nutzern (test and adapt). Insofern bietet Scrum eine großartige Chance, durch Anwendertests die Software kontinuierlich besser zu machen. Es benötigt nicht mehr einer langen Testphase an deren Ende nur das Schlimmste verhindert werden kann, sondern die Anwender können kontinuierlich testen und ihr Feedback äußern.

Damit die Anwendertests nicht in Freestyle-Tests ausarten ist auch hier ein wenig Struktur hilfreich, die sich an den Zielen der Anwendertests orientieren kann:

  • Verbesserung der Software:
    • Aus meiner Sicht bieten sich hier Tests entlang der Geschäftsprozesse an. Auf diese Weise kann leicht festgestellt werden, wie gut (schnell, qualitativ hochwertig, …) die Software die Prozesse unterstützt. Außerdem lassen sich Lücken identifizieren, z.B. welche Sonderfälle nicht unterstützt werden.
    • Sofern eine Prozessdokumentation vorliegt, ist dies eine wunderbare Ausgangsbasis für diese Art von Tests.
    • Verbesserungsvorschläge können als neue Anforderungen an den Product Owner gehen, der sie regulär bewertet, priorisiert und ggf. umsetzt
  • Identifikation von Fehlern:
    • Es muss der Anspruch des agilen Entwicklungsteams sein, funktionierende Software auszuliefern. Aus Anwendersicht sollte es daher nicht notwendig sein, explizit nach Fehlern zu suchen.
    • Sofern Fehler dennoch gefunden werden, sollten sie sofort vom Entwicklungsteam behoben werden (Null-Toleranz-Strategie)
  • Formale Abnahme:
    • Eine formale Abnahme wird vom Product Owner durchgeführt. Basis hierfür ist die gemeinsam verabschiedete Definition of Done sowie die Akzeptanzkriterien in den User Stories.
    • Vor diesem Hintergrund kann es aus Anwendersicht sinnvoll sein, gemeinsam mit dem Product Owner die User Stories zu erstellen. So werden unnötige Diskussionen nach Abnahme vermieden.

Aus meiner Sicht wird hieraus deutlich, dass der Anwendertest im agilen Umfeld nicht überflüssig wird, er sich allerdings verändert. Weg von „das Schlimmste verhindern“ hin zu wertstiftenden Verbesserungen der Software und zu glücklichen Anwendern!

Allgemein

Ein Projektplan, an den nicht einmal der Ersteller glaubt

Veröffentlicht am

Das Leben ist voller Überraschungen. Ein Kollege stellte mir neulich den Plan für sein Projekt vor. Ich schaute etwas irritiert, da der Plan aus meiner Sicht nicht realistisch war. Der Kollege nickte nur und sagte: „Stimmt. Die Annahmen zu den Aufgaben, zusätzlichen Mitarbeitern und der Produktivität sind so vage, da kann ich eigentlich gar nicht planen.“ Ich war sprachlos. In diesem Fall war der Endtermin nämlich unverrückbar…

Nehmen wir als Analogie den Weihnachtsmann. Santa Claus möchte am 24.12. die Geschenke für 100.000 Kinder verteilen. Jedoch…

  • …weiß er nicht, ob alle Geschenke im September angeliefert werden oder auch noch später
  • …weiß er nicht, ob ihn mehr Wichtel als vorheriges Jahr beim Einpacken unterstützen
  • …weiß er nicht, ob die Wichtel signifikant schneller packen als vorheriges Jahr

Die Planung geht jedoch von genau diesen Punkten aus.

Schlimm? Das kommt drauf an, wie man die möglichen Konsequenzen einschätzt.

  • Möglicherweise bekommen nur (zufällig ausgewählte) 80.000 Kinder ihre Geschenke. Aus Sicht von Santa Claus ist das wahrscheinlich nicht akzeptabel.
  • Möglicherweise bekommen die Kinder ihre Geschenke erst am 17. Januar. Aus Sicht von Santa Claus ist das wahrscheinlich nicht akzeptabel.
  • Möglicherweise werden die Wichtel wegen einer Überlastung krank. Aus Sicht von Santa Claus ist das wahrscheinlich nicht akzeptabel.

Was sollte der Weihnachtsmann tun? In Abhängigkeit von den Auswirkungen eines Scheiterns sollte der Projektleiter einen pessimistischen, realistischen oder optimistischen Plan entwerfen. Wenn ein Scheitern nicht akzeptabel ist, dann sollte der Projektleiter bei der Durchführung immer „auf der sicheren Seite“ sein. Dies kann beispielsweise bedeuten

  • Dass er bewusst weniger Kinder beschenkt als ursprünglich geplant (z.B. nur Kinder ab 4 Jahren)
  • Dass er die Schleife des Geschenks weglässt
  • Dass er Unterstützung vom Nikolaus und den heiligen drei Königen anfordert

Derartige Maßnahmen sollte der Projektleiter sofort ergreifen. Es besteht keine Notwendigkeit, bis zum 23. Dezember zu warten, um festzustellen, dass der Plan nicht funktioniert hat…

Allgemein

Lügen haben kurze Beine

Veröffentlicht am

Ich habe neulich meiner sechsjährigen Tochter erklärt, dass sich Lügen und Schwindeleien nicht lohnen. Früher oder später kommt die Wahrheit heraus. Bei Kindern sind es eher Kleinigkeiten wie „hast du dir die Hände gewaschen“, die in der Regel keine ernsthaften Konsequenzen haben. Hier geht es in erster Linie um das Prinzip und die Einstellung.

Im Projektgeschäft sind Lügen, Unwahrheiten und Halbwahrheiten leider weit verbreitet, in der Regel in Verbindung mit Projektstatus, Fertigstellungstermin, Budgeteinhaltung oder sogar mit dem initialen Plan. Beispiele gefällig?

  • Der berühmte Melonenstatus (außen grün, innen rot): Die Projektmitarbeiter erklären, dass sie ein ernsthaften Problem haben bzw. nicht rechtzeitig fertig werden (rot). Der Teilprojektleiter signalisiert ein Risiko (gelb). Der Projektleiter erklärt dem Lenkungsausschuss, alles liefe nach Plan (grün).
  • An einem Fertigstellungstermin wird bis zur letzten Sekunde festgehalten. „Plötzlich“ wird festgestellt, dass man nicht rechtzeitig fertig wird.
  • Ein Projektplan wird vorgestellt und verabschiedet, der objektiv unmöglich umzusetzen ist (Geplanter Aufwand, geplante Ressourcen und geplante Zeit passen nicht zusammen).

Schlimm? Ja. Mit derartigen Unwahrheiten und Halbwahrheiten beschneidet man seine Handlungsmöglichkeiten als Projektleiter:

  • Ein korrekter Status ermöglicht es dem Projektleiter, ein angemessenes Erwartungsmanagement des Lenkungsausschusses und des Auftraggebers durchzuführen. Überraschungen werden vermieden.
  • Ein korrekter Status ermöglicht es dem Projektleiter, ggf. Unterstützung von außerhalb des Projektes zu erhalten bzw. die Prioritäten innerhalb des Projektes
  • Ein korrekter Status ermöglicht es, rechtzeitig Gegenmaßnahmen zu ergreifen, um einen Termin noch zu ermöglichen (und nicht erst in einen Panikmodus zu verfallen, wenn das Kind bereits in den Brunnen gefallen ist)
  • Als Projektleiter begibt man sich in einen Teufelskreislauf, in dem auf eine Lüge eine weitere folgt, und noch eine weitere, … da man nicht sein Gesicht verlieren möchte.

Lügen haben kurze Beine. Es ist nicht die Frage, ob eine Unwahrheit entdeckt wird, sondern wann.

Warum existiert das Phänomen der Unwahrheiten so häufig im Projektmanagement? Aus meiner Sicht gibt es hierfür zwei zentrale Erklärungen:

  • Unkenntnis. Häufig werden in der Projektdurchführung keine quantitativen Fortschrittsmessungen genutzt. Damit kommt es zum „Fast-Fertig-Syndrom“ und man folgt der trügerischen Hoffnung, dass das Problem in der nächsten Berichtsperiode von alleine verschwindet. Dies passiert in der Regel nicht…
  • Ego. Als Projektleiter bin ich Macher, Leiter, Manager und habe meinen Laden im Griff. Jede Abweichung vom Plan werte ich als persönliches Versagen und lasse sie nicht zu. Bis es zu spät ist…

Es ist Zeit, sich den unbequemen Wahrheiten des Projektgeschäfts zustellen. Ich kann an dieser Stelle nur für totale Transparenz und den Einsatz quantitativer Projektmanagementmethoden plädieren. Aus meiner Sicht ist dies ein entscheidender Vorteil agiler Vorgehensweisen wie z.B. Scrum: schnelles Feedback, Transparenz und quantitative Methoden gibt es fast automatisch.