Business Value und MUDA?

DSVGO konform! Falls es gefällt, belohne den Autor! Teile diesen Beitrag!

Business Value und MUDA? Gibt es da Zusammenhänge? MUDA reimt sich auf Buddha und löst automatisch die Assoziation zu Jürgen Klinsmann aus. Klinsmann dementierte aber, je etwas mit den Buddha Figuren in Bayern zu tun gehabt zu haben. Und MUDA soll auch nichts Metaphysisches involvieren. 

Japanisch „Muda“ bedeutet auf Englisch „Waste“, also Müll. „Wasted time“, Zeit die nichts brachte! Im Kontext des Business Value übersetzt man den Begriff als Verschwendung. Sieben MUDA Weisheiten sollen helfen, Verschwendung, und damit eine Reduktion des Business Values, zu vermeiden.

Der Business Value (BV) existiert dagegen auf Unternehmensebene und wird in allen Bereichen des Unternehmens beeinflusst, auch auf Projektebene. Für jedes Projekt gilt es den BV des Unternehmens zu bedienen. Gem. PmBok 6 Seite 8, werden manche Projekte ausschließlich zu dem Zweck initiiert, den BV des Unternehmens zu bedienen. Die meisten Projekte erzeugen aber einen BV, der dem Kunden dienen soll. Trotzdem entstehen in diesen Projekten Kuppeleffekte, die dem BV des ausführenden Unternehmens bereichern. Reputation, öffentliches Interesse und Branding sind nur einige Punkte, die der Guide auf Seite 7 nennt.

Die neue Examination Content Outline (ECO) des PMI® für die PMP Prüfung zur PMP Zertifizierung, hier gilt der Business Value als wichtiger Indikator und Treiber des eigenen Erfolgs und der Kundenzufriedenheit. Allerdings ist der BV auch schon seit Jahren im PmBok Guide vertreten. Und Unternehmen, die Earned Value Management betrieben haben,  hatten auch immer auch den „Wert“ des Liefergegenstands und nicht nur die funktionalen und nicht funktionalen Anforderungen des Liefergegenstands im Fokus. Auch die Anforderungs-Nachverfolgungs-Matrix (PmBok 6, S.149) wurde bezogen auf die einzelnen Anforderungen, im Kontext des Konfigurationsmanagements, mit dem Business Value verknüpft.

Prozesse: Domäne 2 Aufgabe 1 der PMP® Prüfung (ECO®)*

Das Projekt mit der notwendigen Dringlichkeit durchführen, um geschäftlichen Wert liefern zu können

  • Chancen bewerten, um wachsenden Mehrwert zu generieren.

  • Den geschäftlichen Wert während des gesamten Projekts prüfen.

  • Das Team bei der bedarfsgerechten Unterteilung von Projektaufgaben unterstützen, um das  Minimum Viable Product* ((MVP) minimal brauchbares oder existenzfähiges Produkt oder die erste präsentierbare Iteration eines Produkts) zu finden.

 
*PMIstandards+ Nur für PMI Mitglieder im Zugriff
*Die ECO ist die neu Prüfungsordnung für die PMP Prüfung
Werbung für Seminare
PMP Trainer seit PmBok Guide 3th. MS Project Trainer seit Version 4.0.

MUDA und Chancenbewertung?

TRANSPORT“ ist eine der sieben Verschwendungsarten MUDA´s. Sie sollten wissen, dass man zwischen wertschöpfenden, nicht wertschöpfenden und Wert reduzierenden Treibern in Prozessen – die sollte es eigentlich gar nicht geben – unterscheidet. Leertransporte bspw. sind Wert reduzierende Vorgänge in Prozessen, die es zu eliminieren gilt. Meistens werden in der Bewertung auch nur die eigenen Kosten kalkuliert. Nachhaltigkeit bezüglich der Kosten des CO2 Ausstoßes, werden nicht mit einbezogen.

Auch im privaten Bereich, bspw. bei den Arbeitnehmern kann MUDA eingesetzt werden. Jeder kommt im eigenen Auto zur Arbeit, obwohl man mit geringfügigen Umwegen, den Weg zur Arbeit mit einigen Kollegen teilen könnte.

Transporte die aber eher kostenintensiv ohne Rücksicht auf MUDA aufgewertet werden sollten, sind Tiertransporte!

Weitere TRANSPORT Verschwendungsarten!

Treiber in Prozessen, die Verluste oder Gewinne forcieren können.
Prozessanalyse: PmBok Guide 6th, Seite 292

Hört sich nicht gut an, aber ist Tatsache: 

Projektmanager, SCRUM Master und Product Owner sind Blindleister!

Trotzdem machen diese Rollen sehr viel Sinn!

Ein SCRUM Master und ein Projektmanager, in Unwissenheit, aus Prozesssicht Blindleister zu sein.
Zwei Blindleister treffen sich!

„WARTEN“ ist eine weitere Verschwendungsart der MUDA Philosophie. Da fällt mir immer die Zeit bei der Bundeswehr ein. Da gab es den Spruch, „Die meiste Zeit des Lebens, wartet der Soldat vergebens“. 

Wartezeiten in Projekten oder in der Produktion kosten Geld. Auch Puffer kosten Geld. Mieten, Lizenzen, Versicherungen, leer laufende Aufwände von Mitarbeitern, alles kostet Geld und mindert den Business Value. 

Gerade vor dem Hintergrund der Theorie of Constraints könnte man meinen, jede Ressource müsste voll ausgelastet sein. Aber nein, agile als auch prognostizierende Projekte sollten immer mit Unterlast ein Projekte durchlaufen. „Unterlast“ bedeutet nicht, dass Ressourcen öfter mal nichts zu tun haben. „Unterlast“ ist quasi eine Philosophie, die durch die Theorie of Constraints impliziert wird. Hier geht es um Engpässe, die gemeistert werden müssen, um Pönalen oder Terminverzögerungen zu vermeiden.

Unterlast ein Treiber für Wartezeiten?

Ganz im Gegenteil! Unterlast bedeutet auch, Verantwortung und intrinsische Motivation der Mitarbeiter zu erzeugen. Bei Unterlast kommt es immer zu Phasen, in der die ein oder andere Ressource „nichts zu tun hat“. Das heißt aber nicht, dass es keine Arbeit gibt. Eine intrinsisch motivierte Ressource im „Unterlast – Projekt“, wird sich Arbeit suchen. Man spricht dann von einem natürlichen „Flow“. Leider gibt es doch immer wieder Mitarbeiter, die nicht auf die Suche gehen. Da sind die agilen Evangelikalen etwas blauäugig. Man tut so, als ob es im agilen Umfeld nicht zu Demotivationen kommen kann. Wenn alles richtig gemacht wird, das gilt dann aber für das prognostizierende als auch agile PM, dann kann man Frustrationspotenziale weitgehend ausschließen.

Fehlende Motivation ist ein grundsätzliches Problem in prognostizierenden und in agilen Projekten. In prognostizierenden Projekten werden nicht benötigte Puffer nicht zurück gegeben, in agilen Projekten werden mehr Storypoints als nötig geschätzt. Zu diesen Effekten kommt es in der Regel erst, wenn Ressourcen schlechte Erfahrungen gemacht haben. Also wenn eine Schätzung an Storypoints nicht eingehalten wurde oder Aufwandschätzungen überschritten wurden. In beiden Fällen ist immer die Reaktion der Projektmanager, Product Owner, der SCRUM Master oder Strukturen des Upper Managements ausschlaggebend. Man sollte nicht meinen, prognostizierendes und agiles PM wären da sehr unterschiedlich. Ein Mindset kann man nicht befehlen. Entscheidend ist immer das Führungsverhalten.

Wer oben die Aufgabe 1 in der Domäne 2 aufmerksam durchgelesen hat, hat wohl festgestellt, dass diese „Unterlast-Philosophie“ durch den dritten Punkt gestützt wird. „Das Team bei der bedarfsgerechten Unterteilung von Projektaufgaben unterstützen…“, gehört in das Mindset aller Beteiligten.

Lesen Sie in der Fortsetzung weitere „Weisheiten“ der MUDA Philosophie. 

DSVGO konform! Falls es gefällt, belohne den Autor! Teile diesen Beitrag!

Schreibe einen Kommentar