Wiki source for Meilenstein


Show raw source

=====Meilenstein=====

Im Rahmen des [[ProjektManagement Projektmanagements]] sind Meilensteine ein alt-bewährtes, effizientes und unverzichtbares Werkzeug für die Projektplanung und Projektdurchführung. Im Sinne einer Meilensteinplanung nach DIN 69 900 ist ein Meilenstein ein "Ereignis besonderer Bedeutung" im Verlauf eines Projekts. Für den Projektleiter und alle Beteiligten sind Meilensteine terminierte Kontrollpunkte zur Messung des Projektfortschritts.

Allerdings setzt dieses einfache Werkzeug einige Randbedingungen voraus, die selbst in allgemein akzeptierter Fachliteratur unter den Tisch gekehrt werden.

Meilensteine haben Prüfkriterien und Konsequenzen. Darauf gehe ich in diesem kurzen Atikel genauer ein.


====Prüfkriterien - it's binary!====

Ein Meilenstein gilt entweder als erfüllt oder nicht erfüllt. Diskussionen um Grauzonen sind Ablenkungsmanöver von der tatsächlichen Situation. Ggf. wurden die Meilensteine zu unpräzise (schwammig) formuliert. Die Diskussion um erfüllt, nicht erfüllt oder teilweise erfüllt ist ein Anzeichen für unpräzise Formulierung von Meilenstein-Kriterien. Ein Meilenstein braucht ein Prüfkriterium anhand dessen die Erfüllung (ja/nein) geprüft werden kann. Holen sie das nach, lieber zu spät als nie. Formulieren sie Kriterien, die eine Antwort wie ja oder nein zulassen. Können alle Fragen mit einem JA beantwortet werden, dann ist ein Meilenstein erfüllt.

"ist das Modul XY implementiert, vollständig getestet und freigegeben? Die Dokumente A, B, C... mit Unterschriften der Verantwortlichen liegen vor."

Dieses Kriterium lässt sich mit Ja oder Nein beantworten...


Noch ein kleines Add-On: Meilensteine sind als Zwischenziele zu verstehen. Wenn man möchte, kann man auch diese Ziele anhand der [[http://de.wikipedia.org/wiki/SMART_%28Projektmanagement%29 SMART-Kriterien]] formulieren.

~-**S**pezifisch
~-**M**essbar
~-**A**kzeptiert
~-**R**ealisierbar
~-**T**erminierbar


====Meilensteine sind aber auch Entscheidungspunkte====

Meilensteine sind mächtige Steuerwerkzeuge im Projekt und ein Orientierungspunkt für alle beteiligten Projektpartner. Gute Prüfkriterien sind die halbe Miete. Es geht noch einen wichtigen Schritt weiter. Meilensteine sind ein Steuerinstrument! Sie besagen auch, was passiert, wenn mal etwa nicht zeitig erreicht. Und das gibt es wie das Amen in der Kirche.

In der Fachliteratur wird oft dieser wichtiger Aspekt der Meilensteine unterschlagen.

**Was tun, wenn ein Meilenstein nicht erfüllt wird?**

Egal wie viele Jahre ein Projekt dauert und wie schwierig ein Projekt ist, ein guter Projektleiter wird sich zu jedem Meilenstein einen Plan zurechtlegen und diesen auch kommunizieren. Er wir definieren was passieren wird, wenn einen Meilenstein nicht erreichen wird. Der Plan B! Kurz am Rande: Ein sehr guter Projektleiter wird sich überlegen, was er tun wird, wenn Plan B aus unerwarteten gründen zum Meilenstein nicht anwendbar ist. Aber das nur am Rande - kommen wir zum Plan B zurück.

Was tun, wenn wenn der Meilenstein nicht erreicht wird?

Die Maßnahmen müssen klar zu jedem Meilenstein formuliert werden und sind Teil der Projektplanung!

Beispiele für Maßnahmen bei nicht fristgerechter Erreichung von Meilensteinen:
~-**Iteration:** Ein Projektabschnitt/Arbeitspaket wird wiederholt. Bei iterativen Prozessen ohnehin vorgegeben. Aber liest man die Iterationen auch aus ihren Projektplan? Bauen sie Iterationen ein! Maßnahme: Meilenstein A nicht erreicht, dann Arbeitspaket x und Arbeitspaket y noch einmal durchführen. Immerhin kalkuliert man nach ihren Projektplan die Zeit. Oft sehe ich Projektpläne die zwar nach iterativen Prozessen abgewickelt werden, aber die Projektpläne sehen nach Wasserfall-Modellen aus, die in der Praxis bei weitem nicht durchführbar sind. Das ist so als ob ein Programmierer ein Programm schreiben würde, welches ein Computer nie so ausführen würde. So wird ihr Projekt nie ablaufen. Planen sie möglichst realistisch. Achtung: Das Projekt verlängert sich durch Iterationen! Wie viele Iterationen wollen sie sich hier erlauben? Eine, zwei oder mehr? Planen sie gleich Puffer im Projekt ein. Time to market beachten?!
~-**Funktionsumfang reduzieren:** Auf einen Teil der Funktionalität verzichten/gezielt niedrig priorisierte Anforderungen bei nicht zeitiger Erreichung eines Meilensteins streichen. Es ist jedoch besser auf unwichtige Funktionen zu verzichten, als später auf wichtige verzichten zu müssen. Ein ordentlich priorisierten [[AnforderungsSpezifikation Anforderungskatalog]] könnte hier natürlich eine große Hilfe sein. Meilenstein B nicht erreicht, dann wird Funktion F120, F34 und F133 nicht implementiert. Klar, dem Auftraggeber müssen sie das jetzt erklären, denn immerhin hatte er die Hoffnung, das sie das noch schaffen, aber wenigstens ist das Produkt zeitig und zu einem vernünftigen Preis auf dem Markt!
~-**Projektabbruch:** Auch das sollten sie vorsehen; klingt hart, könnte aber ganz motivierend für alle am Projekt beteiligten Verantwortlichen sein, diesen Meilenstein erreichen zu wollen. Manchmal macht es aber auch Sinn ein Projekt abzubrechen, wenn sich schon am Anfang zeigt, dass die grundlegenden Ziele nicht erreicht werden können. Das ist die Geschichte mit dem Reiten toter Pferde: "Wenn du entdeckst, dass du ein totes Pferd reitest, steig ab." Wenn Sie das nicht kennen, empfehle ich Ihnen, google Sie es.
~-**Personal aufstocken/Auslagern:** Sie könne eine Firma mit einem Unterauftrag beauftragen. Sie können einen Mitarbeiter aus der Nachbarabteilung X reinholen. Aber das sollten sie vorher für den Fall der Fälle in der Hand und geklärt haben. Klar, das kostet mehr Geld. Das Projekt wird dadurch teurer. Und irgendjemand wird das bezahlen müssen. Aber das entscheiden Sie schon vorher. Oft ist es dem Industriekunden lieber mehr Geld auszugeben, als eine verspätete Produkteinführung hinnehmen zu müssen, für die parallel nach Plan teure Marketing-Programme zur Ankündigung und Markteinführung laufen. Eine zu späte Markteinführung kann den Todesstoß für ein Projekt bedeuten. Steuern sie entgegen. Planen sie das schon für den Fall im Voraus.
~-**Komponenten kaufen:** Sie bekommen Komponente X doch nicht auf die Reihe? Was nun? Projektabbruch? :) Oder ist ihr Plan die Entwickler stärker zu treten? Wow, leider gibt es das wirklich. Projektleiter sind Menschen und diese tut schreckliche Dinge, wenn Sie gerade selbst verschuldet in Panik geraten! Oder haben sie einen Alternativplan? Kaufen Sie eine Komponente hinzu von der Firma XY? Das Produkt wird vielleicht teurer und die Funktionalität nicht 1A, aber sie haben ein Produkt, welches die hoch priorisierten Anforderungen erfüllt. Wäre das nicht ein guter Alternativplan?


====Checkliste====

~-Sind die Prüfkriterien präzise (spezifisch) formuliert und lassen sie damit eine Messung des Projektfortschritts zu? Mit anderen Worten: Ist ganz genau beschrieben, was erfüllt sein muss? Oder: Kann ich als Projektleiter am Tag X den Meilenstein anhand dieses Prüfkriteriums als erreicht oder nicht erreicht deklarieren?
~-Gibt es einen Termin (Datum) für den Meilenstein?
~-Ist der Meilenstein aus heutiger Sicht realistisch bis zu dem Zeitpunkt erreichbar?
~-Ist klar was zu tun ist, wenn der Meilenstein nicht erreicht wird?


====Beispiele====

|=|Nr|=|Datum|=|Meilensteintitel|=|Prüfkriterium|=|Entscheidung bei Nichterfüllung||
||1||11.11.2011||Gehäuseentwurf fertiggestellt||Konstruktionspläne für das Gehäuse liegen vor und sind von .. freigegeben worden. || Arbeitspaket 3.4 wird wiederholt. Projektlaufzeit verlängert sich um X Wochen.||
||2||12.12.2012 ||Der Test der Steuereinheit 212 entsprechend der Testspezifikation T34 wurde durchgeführt. Testbericht liegt vor. Test war erfolgreich. ||Eigenentwicklung "Steuereinheit 212" durch ein zugekauftes Systems des Herstellers XY ersetzen und damit weitermachen.|| ||
||3||... || || || ||



====Wie viele Meilensteine braucht ein Projekt?====

Das kommt darauf an. Ja, ich habe solche Antworten auch gern. Auf was genau kommt es also an? Das kommt im Grunde darauf an wie viel sie Planen wollen/können und mit wem Sie letztendlich zusammenarbeiten. Letztendlich gibt es in den Meisten Projekten ein Paar entscheidende Punkte. Diese sind dort,
~- wo es auf die Zuarbeit von Partnern oder externer Firmen ankommt,
~- wo Ergebnisse vorliegen müssen, die eine für die Projektfortführung unabdingbar sind.
~- wo Ergebnisse weitergegeben werden.

meistens wird schon am Anfang des Projektes geschludert. Legen sie auf jeden Fall ein Paar Meilensteine am Anfang. Damit die Arbeit zeitig Beginnt. Klar, die Anforderungen werden ermittelt und die Spezifikation wird erstellt. Warum dauern diese Arbeitspakete dann immer länger als geplant? Weil niemand rechtzeitig prüft, ob sich die Mühlen schon in Bewegung gesetzt haben.

Fazit: Viele Meilensteine müssen es nicht sein. Aber wenn ein Projekt nur einen Meilenstein pro Jahr hat, dann ist das schon sehr wenig. Auf der anderen Seite ist es auch seltsam, wenn drei Meilensteine zeitlich übereinander liegen.


====Schlusswort====

Ein Projektleiter trägt die Verantwortung für viel Geld, die geleistete Arbeit der Kollegen und den Projekterfolg. Es ist ein Naturgesetz, dass ein Plan A nicht funktioniert. Ein PL muss dafür Sorge tragen, dass Alternativpläne existieren, wenn etwas schief geht. Wenn ihre Meilensteine unklare Prüfkriterien haben oder wenn es keine Konsequenzen bei nicht Erreichung von Meilensteinen gibt, dann nutzen sie dieses einfache und effektive Werkzeug der Projektsteuerung schlichtweg nicht und ihr Projekt taumelt wie ein Schiff ohne Steuermann. Sie haben keine Alternativpläne sondern hoffen, dass alles gute geht? Ich hoffe, Sie hoffen das nicht. Legen Sie sich einen Meilensteinplan zu.


====Links zum Weiterlesen====

~-http://pm-blog.com/2007/05/14/meilensteine-unverzichtbare-orientierungspunkte-im-projekt/
~-http://de.wikipedia.org/wiki/Meilensteinplan



----
Siehe auch {{backlinks}}
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki