Sonntag, 4. Juli 2010

EVM World 2010 - Präsentationsfolien verfügbar

Vom 2.-4. Juni hat die EVM World 2010 in Naples, Florida stattgefunden. Die Präsentationsfolien aller Beiträge sind seit kurzem Online beim PMI College of Perfomance Management abrufbar. Auch ohne bei dieser wichtigen Konferenz dabei zu sein ist es doch interessant zu entdecken was die EVM Welt bewegt. Um die Folien herunterzuladen gehen Sie an folgende Adresse:
http://www.pmi-cpm.org/pages/library/4.00.library.html
Dort klicken Sie auf "I Agree" und markieren auf der folgenden Seite rechts das Keyword "EVM World 2010" und klicken dann auf "Search". Ich hoffe Sie können von der gebotenen Themenvielfalt profitieren

Dienstag, 4. Mai 2010

Past performance is not necessarily indicative of future results

Diese „Warnung“ kennen Sie vielleicht bei Banken wenn es um Anlageprodukte geht. Vergangene gute Renditen können nicht unbedingt in die Zukunft fortgeschrieben werden. Kann man die Finanzmärkte mit Projekten vergleichen? Nein, das kann man nicht. Darum gilt für Projekte die Aussage im Titel nicht. Bei Projekten müsste es heissen:

Past performance is indicative of future results!

Es gibt viele Gründe, weshalb immer mehr Unternehmen mit Earned Value Management Ihre Projekte führen. Einer der wichtigsten Gründe ist die Fähigkeit der „statistischen“ Vorhersage der wahrscheinlichen Projekt-Endkosten und des Projekt-Endtermins zu einem sehr frühen Zeitpunkt. Schon nach 15% Projektfortschritt können erste Prognosen gemacht werden. Mit Earned Value Management muss man nicht warten bis 80% des Budgets ausgegeben sind, um zu wissen, dass man auf ein Problem zusteuert.

"Prognosen sind schwierig, besonders wenn sie die Zukunft betreffen." Mark Twain hat mit seiner Aussage schon recht. Aber mit Earned Value Management erhält das Management ein Instrument, das Frühwarnsignale liefert und es ihm somit erlaubt rechtzeitig korrigierende Massnahmen einzuleiten. Das heisst aber nicht, dass man sich blind auf den CPI, EAC etc. verlassen soll und die gerechneten Werte als alleinige Wahrheit betrachten soll. Als Projektleiter wird man den berechneten EAC immer mit seiner eigenen, besten Schätzung vergleichen. Wenn die eigene Schätzung besser ist als der statistisch berechnete EAC, dann sollte man für das Management eine gute Erklärung bereit halten, wie man seine Schätzung erreichen will.

Montag, 5. April 2010

Der PLAN-/SOLL-IST-Vergleich

Sie haben sicher auch schon vom SOLL-IST-Vergleich gehört? Im Projektumfeld reden viele Personen vom SOLL-IST Vergleich und meinen damit vermutlich den PLAN-IST-Vergleich. Ist denn SOLL gleichbedeutend wie PLAN? Im kaufmännischen Sinne spricht man von den SOLL-Kosten, wenn es um die Kosten geht, die beim erreichten Leistungsniveau laut Planung anfallen sollten. In der Technik ist der SOLL-Wert eine vorgegebene Grösse, die von einer dynamischen Grösse, dem IST-Wert, erreicht werden sollte. Was genau bedeuten nun die SOLL-Werte in der Projektwelt?
Beim Projektcontrolling versucht man mit dem PLAN-/SOLL-IST-Vergleich einen Schritt weiter zu gehen als beim üblichen PLAN-/IST-Vergleich. Dabei wird der Projektfortschritt nicht nur qualitativ, sondern auch quantitativ erfasst und analysiert. Die Analyse der Abweichungen und die Berechnung der REST-Werte liefert dann die Grundlage für die Vorhersage der Projektendkosten.
Die folgende Abbildung zeigt, was mit dem PLAN-/SOLL-IST-Vergleich genau gemeint ist. Dabei haben die PLAN-/SOLL-IST-Werte folgende Bedeutung:

Die PLAN-Werte entsprechen den Werten der eingefrorenen Basispla-nung. Sie gelten für die gesamte Projektdauer, das heisst links und rechts vom Stichtag. Die PLAN-Werte werden nur im „Notfall“ geändert, z.B. wenn sich der Projektumfang ändert.

Die IST-Werte entsprechen den aktuellen Kosten, die im Buchhaltungs-system verrechnet wurden. Die IST-Werte können nur für die Vergangenheit beschafft werden. Sie liegen deshalb links vom Stichtag.

Die REST-Werte sehen Sie in Abbildung 6 nicht. Sie entsprechen den verbleibenden Kosten für die noch unerledigte Arbeit, bis das Arbeitspaket oder das Projekt beendet ist. Die Restkosten werden vom Projektleiter oder vom Arbeitspaketverantwortlichen gemäss der noch verbleibenden Arbeit geschätzt.

Die SOLL-Werte entsprechen der Summe der aktuellen IST-Kosten und der REST-Werte. Bei den SOLL-Werten handelt es sich um Prognosen. Sie liegen deshalb rechts vom Stichtag, also in der Zukunft. Sie definieren die “aktuelle Planung“.

Aus dieser Beschreibung sehen Sie, dass links vom Stichtag immer nur der Vergleich von PLAN- und IST-Werten möglich ist. In der Zukunft, das heisst rechts vom Stichtag, können nur PLAN- und SOLL-Werte miteinander verglichen werden. Nur am Stichtag selbst können PLAN-, IST- und SOLL-Werte gegenübergestellt werden. Dies entspricht dann dem „echten“ SOLL-IST-Vergleich im kaufmännischen Sinne.

Entdecken Sie mehr Details über die PLAN-/SOLL-IST-Berechnung und wie Earned Value Management als weiterer Schritt noch mehr Transparenz und Sicherheit bietet im umfassenden Buch von Roland Wanner:  Projektcontrolling – Projekteerfolgreich planen, überwachen und steuern.

Erhalte mein kostenloses eBook: Projektplanung

Montag, 29. März 2010

Earned Value Management in der Cloud

Apptis und Deltek liefern als Partner die erste "Cloud-Based Enterprise Project Management Solution" für Regierungs-Behörden in den USA. Die beiden Unternehmen liefern Delteks komplette Earned Value Management Lösung COBRA und wInsight auf einer Cloud Computing Platform. Apptis wird dabei Datensicherheit und Infrastrukur managen. Durch die Cloud-Lösung soll eine substantiel kosteneffizientere Technologieinfrastruktur zu Anwendung kommen meldete das Amerikanische "Office of Management and Budget" (OMB). Mehr Informationen finden Sie hier ...

Mittwoch, 17. Februar 2010

Das Verhalten von SV, CV, SPI und CPI

Wenn Sie EVM anwenden sollten Sie auch wissen wie sich SV, CV, SPI und CPI während der Projektabwicklung normalerweise verhalten, sonst erleben unter Umständen einmal eine böse Überraschung.
In der folgenden Abbildung sehen Sie, dass die SV gegen das effektive Projektende immer kleiner wird und dann gegen „0“ konvergiert. Dies, weil der EV und der PV am Projektende immer den gleichen Wert annehmen. Aus diesem Grund ist der Wert der SV, zirka ab dem letzten Viertel der Projektdauer nicht mehr brauchbar. Die CV hingegen zeigt jederzeit, bis zum effektiven Projektende, die korrekte Kostenabweichung an. Die CV ist am Projektende nur in einem Fall „0“. Nämlich, wenn das Projekt zu den geplanten Kosten fertig gestellt wird – dies ist jedoch eher selten der Fall.Nun schauen wir das Verhalten von SPI und CPI genauer an. In der folgenden Abbildung erkennen Sie, dass der SPI bei Projektende gegen „1.0“ konvergiert, obwohl das Projekt die Kosten erheblich überschritten hat. Auch in diesem Fall nimmt der EV und der PV am Projektende den gleichen Wert an und deshalb ist der Quotient von EV und PV „1“. Der CPI wird bei Projektende selten „1.0“ sein. Nur dann, wenn das Projekt zu den geplanten Kosten fertig gestellt wird.
Die Probleme mit der ungenügenden Zuverlässigkeit der SV und des SPI waren schon längere Zeit bekannt, wurden aber nie richtig angepackt. Erst mit dem „Earned Schedule“ Konzept, das im Sommer 2002 von Walter Lipke erarbeitet und zum ersten Mal im März 2003 publiziert wurde ist ein hoffnungsvoller, rechnerischer Lösungsansatz für die zeitbezogenen EVM-Kennzahlen gefunden worden.

Dienstag, 5. Januar 2010

EVM und agile Softwareentwicklung?

Über das Thema EVM bei der agilen Softwareentwicklung wurde in Fachzeitschriften schon einiges geschrieben. Wenn man die Berichte so verfolgt, dann könnte man meinen: Die, die schon immer nicht viel von EVM gehalten haben schliessen so etwas vollständig aus; die EVM Befürworter zeigen sich hingegen optimistisch EVM auch bei agilen Projekten gewinnbringend einzusetzen. Ein weiterer Artikel aus dem "The Measurable News Issue 4/2009" ab Seite 24 zeigt gut verständlich die Argumente der Befürworter. Ich versuche ein paar Punkte daraus zusammenzufassen.

Es gibt ja nicht nur "eine Art" von agiler Softwareentwicklung. Methoden wie Extreme Programming, Scrum, Dynamic System Development und einige andere wurden in den letzten 20 Jahren entwickelt. Sie haben zwar ähnliche Grundwerte, die im "Agilen Manifest" 2001 definiert wurden, sind sind jedoch doch in ihrerer Vorgehensweise recht verschieden.
Die Gegner von EVM bei agilen Projekten sagen: Agile Projekte können den Scope nicht im voraus definieren. Dies ist ja ein zentraler Punkt beim EVM. Gemäss dem Autor des oben genannten Artikels stimmt dies jedoch nur bedingt, denn bei den meisten agilen Methoden kann ein grosser Teil des Scopes schon zum voraus grob definiert werden, z.B. in der "Product Backlog" bei Scrum. Wenn man EVM anwenden will, muss man sich einzig hier ein wenig mehr Mühe geben. Mehr will ich über den interessanten Artikel nicht mehr verraten, lesen Sie Ihn selber und machen Sie sich Ihre Meinung. Für agile Softwareprojekte, welche die EVM Norm ANSI/EIA-748 einhalten müssen ist dieser Artikel definitiv sehr lesenswert.