Revision history for Meilenstein


Revision [16826]

Last edited on 2013-07-29 13:04:41 by ToBo
Additions:
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.
~-**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!
~-**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?
||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.|| ||
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,
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.
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.
Deletions:
Meilensteine sind mächtige Steuerwekzeuge 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 Steuerinstrumen! Sie bsagen auch, was passiert, wenn mal etwa nicht zeitig erreicht. Und das gibt es wie das Amen in der Kirche.
~-**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 AP x und AP 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 sit 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öglcihst realistisch. Achtung: Das Projekt verlängert sich durch Iterationen! Wie viele Iterationen wollen sie sich hier erlauben? Eine, zwei oder mehr? Planen sie gliech 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 Meilensteis streichen. Es ist jedoch besser auf unwichtige Funktionen zu verzichten, als später auf wichtige verzichten zu müssen. Ein ordetlich 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 Hofnung, das sie das noch schaffen, aber wenigstens ist das Produkt zeitig und zu einem vernünftigen Preis auf dem Markt!
~-**Komponenten kaufen:** Sie bekommen Komponente X doch nicht auf die Reihe? Was nun? Projektabbruch? :) Oder ist ihr Plan die Entwickler stärker zu tretten? Wow, leider gibt es das wirklich. Projektleiter sind Menschen und diese tut schrekliche Dinge, wenn Sie gerade selbstverschuldet in Panik geraten! Oder haben sie einen Alternativplan? Kaufen Sie eine Komponente hinzu von der Fa. 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?
||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 widerholt. 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 erolgreich. ||Eigenentwicklung "Steuereinheit 212" durch ein zugekauftes Systems des Herstellers XY ersetzen und damit weitermachen.|| ||
Das kommt darauf an. Ja, ich habe solche Antworten auch gern. Auf was ganu kommt es also an? Das kommt im Grunde darauf an wie viel sie Planen wollen/können und mit wem Sie letzendlich zusammenarbeiten. Letztendlich gibt es in den Meisten Projekten ein Paar entscheidende Punkte. Diese sind dort,
meistens wird schon am Anfang des Projektes geschludert. Legen sie auf jeden Fall ein Paar Meilensteine am Anfang. Damit die Arbeit zeitig Begint. Klar, die Anforderungen werden ermittelt und die Spezifikation wird erstellt. Warum dauern diese Arbeitspakete dann immer länger als geplant? Weil niemend rechtszeitig prüft, ob sich die Mühlen schon in Bewegung gesetzt haben.
Ein Projektleiter trägt die Verantwortung für viel Geld, die geleistete Arbeit der Kollegen und den Projekterfolg. Es ist ein Naturgesetzt, 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 Konsquenzen 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.


Revision [15554]

Edited on 2013-03-07 20:48:07 by ToBo
Additions:
~-**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.
====Beispiele====
====Wie viele Meilensteine braucht ein Projekt?====
Das kommt darauf an. Ja, ich habe solche Antworten auch gern. Auf was ganu kommt es also an? Das kommt im Grunde darauf an wie viel sie Planen wollen/können und mit wem Sie letzendlich 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 Begint. Klar, die Anforderungen werden ermittelt und die Spezifikation wird erstellt. Warum dauern diese Arbeitspakete dann immer länger als geplant? Weil niemend rechtszeitig 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.
Deletions:
~-**Personal aufstocken/Auslagern:** Sie könne eine Firma als Unterauftrag beauftragen, sie können einen MA aus Abteilung X reinholen. Aber das sollten sie vorher für den Fall der Fälle in der Hand haben. Klar, das kostet mehr Geld. Das Projekt wird teurer. 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.
====Beispiel====


Revision [15553]

Edited on 2013-03-07 20:32:44 by ToBo
Additions:
~-**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.
Deletions:
~-**Projektabbruch:** Auch das sollten sie vorsehen; klingt hart, könnte aber ganz motivierend für alle am Projekt beteiligten Verantwortlichen sein, diesen Meilenstein zu 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 kenne, empfehle ich Ihnen google Sie es.


Revision [15552]

Edited on 2013-03-07 20:30:59 by ToBo
Additions:
~-**Funktionsumfang reduzieren:** Auf einen Teil der Funktionalität verzichten/gezielt niedrig priorisierte Anforderungen bei nicht zeitiger Erreichung eines Meilensteis streichen. Es ist jedoch besser auf unwichtige Funktionen zu verzichten, als später auf wichtige verzichten zu müssen. Ein ordetlich 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 Hofnung, das sie das noch schaffen, aber wenigstens ist das Produkt zeitig und zu einem vernünftigen Preis auf dem Markt!
Deletions:
~-**Funktionsumfang reduzieren:** Auf einen Teil der Funktionalität verzichten/gezielt niedrig priorisierte Anforderungen bei nicht zeitiger Erreichung eines Meilensteis streichen. Es ist jedoch besser auf unwichtige Funktionen zu verzichten, als später auf wichtige verzichten zu müssen. Ein ordetlich priorisierten [[AnforderungsSpezifikitation 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 Hofnung, das sie das noch schaffen, aber wenigstens ist das Produkt zeitig und zu einem vernünftigen Preis auf dem Markt!


Revision [15551]

Edited on 2013-03-07 20:29:48 by ToBo
Additions:
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!====
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.
====Meilensteine sind aber auch Entscheidungspunkte====
Meilensteine sind mächtige Steuerwekzeuge 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 Steuerinstrumen! Sie bsagen 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.
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.
~-**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 AP x und AP 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 sit 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öglcihst realistisch. Achtung: Das Projekt verlängert sich durch Iterationen! Wie viele Iterationen wollen sie sich hier erlauben? Eine, zwei oder mehr? Planen sie gliech 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 Meilensteis streichen. Es ist jedoch besser auf unwichtige Funktionen zu verzichten, als später auf wichtige verzichten zu müssen. Ein ordetlich priorisierten [[AnforderungsSpezifikitation 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 Hofnung, 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 zu 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 kenne, empfehle ich Ihnen google Sie es.
~-**Personal aufstocken/Auslagern:** Sie könne eine Firma als Unterauftrag beauftragen, sie können einen MA aus Abteilung X reinholen. Aber das sollten sie vorher für den Fall der Fälle in der Hand haben. Klar, das kostet mehr Geld. Das Projekt wird teurer. 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.
~-**Komponenten kaufen:** Sie bekommen Komponente X doch nicht auf die Reihe? Was nun? Projektabbruch? :) Oder ist ihr Plan die Entwickler stärker zu tretten? Wow, leider gibt es das wirklich. Projektleiter sind Menschen und diese tut schrekliche Dinge, wenn Sie gerade selbstverschuldet in Panik geraten! Oder haben sie einen Alternativplan? Kaufen Sie eine Komponente hinzu von der Fa. 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?
====Schlusswort====
Ein Projektleiter trägt die Verantwortung für viel Geld, die geleistete Arbeit der Kollegen und den Projekterfolg. Es ist ein Naturgesetzt, 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 Konsquenzen 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====
Deletions:
Im Rahmen des [[ProjektManagement Projektmanagements ]] sind Meilensteine ein sehr 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 sind Meilensteine terminierte Kontrollpunkte zur Messung des Projektfortschritts.
Allerdings setzt dieses einfache Werkzeug einige Randbedingungen voraus, die selbst in guter Fachliteratur unter den Tisch gekehrt werden.
====It's binary!====
====Formulierung von Meilensteinen====
Meilensteine sind als Zwischenziele zu verstehen. Ziele sollte generell anhand der [[http://de.wikipedia.org/wiki/SMART_%28Projektmanagement%29 SMART-Kriterien]] formuliert werden.
====Entscheidungspunkt====
Meilensteine sind mächtige Steuerwekzeuge im Projekt und ein Orientierungspunkt für alle beteiligten Projektpartner. Gute Prüfkriterien sind die halbe Miete. Es geht noch einen wichtigen Schritt weiter.
In der Fachliteratur wird oft ein wichtiger Aspekt der Meilensteine unterschlagen.
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, was passieren wird, wenn der Projektleiter als Verantwortlicher einen beliebigen Meilenstein nicht erreichen wird. Der Plan B! Oder besser gesagt zumindest einen Plan B sollten sie haben. Kurz am Rande: Ein sehr guter Projektleiter wird sich überlegen, was er tun wird, wenn Plan B aus unerwarteten gründen zum beliebigen Meilenstein nicht anwendbar ist. Aber das nur am Rande - kommen wir zum Plan B zurück.
~-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 AP x und AP 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 sit 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öglcihst realistisch. Achtung: Das Projekt verlängert sich durch Iterationen! Wie viele Iterationen wollen sie sich hier erlauben? Eine, zwei oder mehr? Planen sie gliech Puffer im Projekt ein. Time to market beachten?!
~-Auf einen Teil der Funktionalität verzichten/gezielt niedrig priorisierte Anforderungen bei nicht zeitiger Erreichung eines Meilensteis streichen. Es ist jedoch besser auf unwichtige Funktionen zu verzichten, als später auf wichtige verzichten zu müssen. Ein ordetlich priorisierten [[AnforderungsSpezifikitation 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 Hofnung, 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 zu 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 kenne, empfehle ich Ihnen google Sie es.
====Links====


Revision [15550]

Edited on 2013-03-07 20:02:39 by ToBo
Additions:
||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 widerholt. 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 erolgreich. ||Eigenentwicklung "Steuereinheit 212" durch ein zugekauftes Systems des Herstellers XY ersetzen und damit weitermachen.|| ||
||3||... || || || ||
Deletions:
||1||12.12.2012||Gehäuseentwurf fertiggestellt||Konstruktionspläne für das Gehäuse liegen vor und sind von .. freigegeben worden. || Arbeitspaket 3.4 wird widerholt. Projektlaufzeit verlängert sich um X Wochen.||
||2||||||||||


Revision [15549]

Edited on 2013-03-07 19:59:51 by ToBo
Additions:
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.
Meilensteine sind mächtige Steuerwekzeuge im Projekt und ein Orientierungspunkt für alle beteiligten Projektpartner. Gute Prüfkriterien sind die halbe Miete. Es geht noch einen wichtigen Schritt weiter.
In der Fachliteratur wird oft ein 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, was passieren wird, wenn der Projektleiter als Verantwortlicher einen beliebigen Meilenstein nicht erreichen wird. Der Plan B! Oder besser gesagt zumindest einen Plan B sollten sie haben. Kurz am Rande: Ein sehr guter Projektleiter wird sich überlegen, was er tun wird, wenn Plan B aus unerwarteten gründen zum beliebigen Meilenstein nicht anwendbar ist. Aber das nur am Rande - kommen wir zum Plan B zurück.
Beispiele für Maßnahmen bei nicht fristgerechter Erreichung von Meilensteinen:
~-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 AP x und AP 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 sit 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öglcihst realistisch. Achtung: Das Projekt verlängert sich durch Iterationen! Wie viele Iterationen wollen sie sich hier erlauben? Eine, zwei oder mehr? Planen sie gliech Puffer im Projekt ein. Time to market beachten?!
~-Auf einen Teil der Funktionalität verzichten/gezielt niedrig priorisierte Anforderungen bei nicht zeitiger Erreichung eines Meilensteis streichen. Es ist jedoch besser auf unwichtige Funktionen zu verzichten, als später auf wichtige verzichten zu müssen. Ein ordetlich priorisierten [[AnforderungsSpezifikitation 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 Hofnung, 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 zu 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 kenne, empfehle ich Ihnen google Sie es.
||1||12.12.2012||Gehäuseentwurf fertiggestellt||Konstruktionspläne für das Gehäuse liegen vor und sind von .. freigegeben worden. || Arbeitspaket 3.4 wird widerholt. Projektlaufzeit verlängert sich um X Wochen.||
Deletions:
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.
Es geht noch einen wichtigen Schritt weiter...
In der Fachliteratur wird oft ein 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, was passieren wird, wenn er als Verantwortlicher einen beliebigen 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 beliebigen Meilenstein nicht anwendbar ist. Aber das nur am Rande - kommen wir zum Plan B zurück.
Beispiele:
~-Eine Projektabschnitt vor dem Meilenstein wiederholen (Projekt verlängert sich! Time to market?!)
~-Auf einen Teil der Funktionalität verzichten (wird kaum jemand akzeptieren, es ist jedoch besser auf unwichtige Funktionen zu verzichten, als später auf wichtige)
~-usw. die Freiheitsgrade sind hier gigantisch
||1||12.12.2012||Gehäuseentwurf fertiggestellt||Konstruktionspläne für das Gehäuse liegen vor und sind von .. freigegeben worden.||Projektabschnitt von ... bis .. verlängern. Eine Iteration einfügen. Projektlaufzeit verlängert sich um .. Wochen.||


Revision [11238]

Edited on 2010-10-27 13:17:46 by ToBo
Additions:
~-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?
~-Ist klar was zu tun ist, wenn der Meilenstein nicht erreicht wird?
||1||12.12.2012||Gehäuseentwurf fertiggestellt||Konstruktionspläne für das Gehäuse liegen vor und sind von .. freigegeben worden.||Projektabschnitt von ... bis .. verlängern. Eine Iteration einfügen. Projektlaufzeit verlängert sich um .. Wochen.||
Deletions:
~-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üfkrierüums als erreicht oder nicht erreicht deklarieren?
~-Ist klar was zu tun ist, wenn der Meilenstein nciht erreicht wird?
||1||12.12.2012||Gehäuseentwurf fertiggestellt||Kostruktionspläne für das Gehäuse liegen vor und sind von .. freigegeben worden.||Projektabschnitt von ... bis .. verlängern. Eine Itteration einfügen. Projektlaufzeit verlängert sich um .. Wochen.||


Revision [11237]

Edited on 2010-10-27 13:16:28 by ToBo
Additions:
|=|Nr|=|Datum|=|Meilensteintitel|=|Prüfkriterium|=|Entscheidung bei Nichterfüllung||
||1||12.12.2012||Gehäuseentwurf fertiggestellt||Kostruktionspläne für das Gehäuse liegen vor und sind von .. freigegeben worden.||Projektabschnitt von ... bis .. verlängern. Eine Itteration einfügen. Projektlaufzeit verlängert sich um .. Wochen.||
||2||||||||||
Deletions:
|=|Nr|=|Meilensteintitel|=|Prüfkriterium|=|Entscheidung bei Nichterfüllung||
||1||Gehäuseentwurf fertiggestellt||Kostruktionspläne für das Gehäuse liegen vor und sind von .. freigegeben worden.||Projektabschnitt von ... bis .. verlängern. Eine Itteration einfügen. Projektlaufzeit verlängert sich um .. Wochen.||
||2||||||||


Revision [11236]

Edited on 2010-10-27 12:08:13 by ToBo
Additions:
Im Rahmen des [[ProjektManagement Projektmanagements ]] sind Meilensteine ein sehr 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 sind Meilensteine terminierte Kontrollpunkte zur Messung des Projektfortschritts.
Meilensteine sind als Zwischenziele zu verstehen. Ziele sollte generell anhand der [[http://de.wikipedia.org/wiki/SMART_%28Projektmanagement%29 SMART-Kriterien]] formuliert werden.
Deletions:
Im Rahmen des [[Projektmanagements ProjektManagement]] sind Meilensteine ein sehr 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 sind Meilensteine terminierte Kontrollpunkte zur Messung des Projektfortschritts.
Meilensteine sind als Zwischenziele zu verstehen. Ziele sollte generell anhand der [[SMART-Kriterien http://de.wikipedia.org/wiki/SMART_%28Projektmanagement%29]] formuliert werden.


Revision [11235]

Edited on 2010-10-27 12:07:47 by ToBo
Additions:
=====Meilenstein=====
Im Rahmen des [[Projektmanagements ProjektManagement]] sind Meilensteine ein sehr 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 sind Meilensteine terminierte Kontrollpunkte zur Messung des Projektfortschritts.
Allerdings setzt dieses einfache Werkzeug einige Randbedingungen voraus, die selbst in guter Fachliteratur unter den Tisch gekehrt werden.
====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.
"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...
====Formulierung von Meilensteinen====
Meilensteine sind als Zwischenziele zu verstehen. Ziele sollte generell anhand der [[SMART-Kriterien http://de.wikipedia.org/wiki/SMART_%28Projektmanagement%29]] formuliert werden.
~-**S**pezifisch
~-**M**essbar
~-**A**kzeptiert
~-**R**ealisierbar
~-**T**erminierbar
====Entscheidungspunkt====
Es geht noch einen wichtigen Schritt weiter...
In der Fachliteratur wird oft ein 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, was passieren wird, wenn er als Verantwortlicher einen beliebigen 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 beliebigen 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:
~-Eine Projektabschnitt vor dem Meilenstein wiederholen (Projekt verlängert sich! Time to market?!)
~-Auf einen Teil der Funktionalität verzichten (wird kaum jemand akzeptieren, es ist jedoch besser auf unwichtige Funktionen zu verzichten, als später auf wichtige)
~-usw. die Freiheitsgrade sind hier gigantisch
====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üfkrierüums 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 nciht erreicht wird?
====Beispiel====
|=|Nr|=|Meilensteintitel|=|Prüfkriterium|=|Entscheidung bei Nichterfüllung||
||1||Gehäuseentwurf fertiggestellt||Kostruktionspläne für das Gehäuse liegen vor und sind von .. freigegeben worden.||Projektabschnitt von ... bis .. verlängern. Eine Itteration einfügen. Projektlaufzeit verlängert sich um .. Wochen.||
||2||||||||
====Links====
~-http://pm-blog.com/2007/05/14/meilensteine-unverzichtbare-orientierungspunkte-im-projekt/
~-http://de.wikipedia.org/wiki/Meilensteinplan
Deletions:
=====Titel=====


Revision [11234]

The oldest known version of this page was created on 2010-10-27 10:59:38 by ToBo
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki