Prioritäten von Entwicklungsprojekten

Hallo,

wir sind gerade dabei ein Projektblatt zum Start von Entwicklungsprojekten zu entwerfen.
Nun sind wir auf das Thema Priorität gekommen.

Kann man überhaupt von vornherein festlegen welche Priorität ein Projekt hat?

Ich denke dass dies eher ein dynamischer Prozess ist. Das heißt, je näher der Endtermin rückt, desto höher ist die Priorität dieses Projekts.

Meinungen/Wissen hierzu?

Hallo,

Kann man überhaupt von vornherein festlegen welche Priorität ein Projekt hat?

Was versteht Euer Unternehmen unter dem Begriff „business case“?

Sicher müssen business cases ab und zu der Realität angepasst werden - wenn sie jedoch im Prinzip bei jedem Review neu gewürfelt werden, dann läuft irgend was Anderes im Unternehmen aus dem Ruder.

Ja, man kann Prioritäten festlegen.
Verschiedene Kriterien (längst nicht vollständig):

  • Wichtigkeit für (Strategien)
  • Einfluss auf (Metriken)
  • Relevanz für (Ziele)
  • Nutzen für (Zielgruppe)

Ich denke dass dies eher ein dynamischer Prozess ist. Das heißt, je näher der Endtermin rückt, desto höher ist die Priorität dieses Projekts.

Da könnte ich jetzt sicher eine Menge Geld als Berater bei Euch machen :smiley: (Das war jetzt mit Absicht provokativ)
Prozesse wie zB. DfSS, QFD, Hoshin und Kanban dienen dazu, Entwicklungs-Projekte genau so zu steuern, dass ihre Fertigstellung mit den Unternehmenszielen einhergeht.
Entsprechend ist auch schon vor Beginn der Umsetzung einer Entwicklung anhand von Planzahlen klar, was bis wann von wem wozu entwickelt wird - entsprechend ergibt sich die Priorität.

Wer Projekte realisiert, deren Priorität erst im Lauf der Umsetzung klar wird, hat schwere strategische Probleme.

Gruss,
Michael

Hallo,

Bis jetzt läuft es so:

Irgendwer kommt und vermeldet „die Konkurenz hat…“, oder „der Kunde will…“

Und die Entwicklung legt los. Darüber welchen Aufwand man in das Projekt steckt und welchen Umsatz dies generrieren kann, macht man sich erst so nach und nach Gedanken.

Das wollen wir abstellen.

Haben deswegen ein Projektblatt entwickelt. Wenn dies nicht vollständig ausgefüllt ist (Umlauf verschiedene Abteilungen), legen wir gar nicht los.
Darin sind auch Termine ein Thema. „Wuschtermin des Vertriebs“, „Zeitlicher Aufwand“, „Zeitliche Einordnung“.

Auch gehören vorgeplante Reviews in dieses Projektblatt. Ebenso ist die Priorität mit drin, die von der technischen Leitung festgelegt wird.

Nur stelle ich mir die Frage:

  • Ein Endtermin und eine zeitliche Einordnung ist vorhanden

Wozu benötige ich da noch Prioritäten? Was bringt es mir wenn ich eine 1,2 oder 3 hinter die Projektnummer lege. Im Endeffekt hat der Leiter der Entwicklung schon einen Überblich was seine 4 Mann da treiben.

Nur stelle ich mir die Frage:

  • Ein Endtermin und eine zeitliche Einordnung ist vorhanden

Wozu benötige ich da noch Prioritäten? Was bringt es mir wenn
ich eine 1,2 oder 3 hinter die Projektnummer lege. Im
Endeffekt hat der Leiter der Entwicklung schon einen Überblich
was seine 4 Mann da treiben.

In meinem Umfeld (SAP-Projekte bzw. kundeninterne Mini-Org.- oder Entwicklungsprojekte im Rahmen einer ERP-Einführung) dient die Priorität einfach als übergeordnetes Entscheidungskriterium, in welcher Reihenfolge die leistenden Kapazitäten arbeiten sollen, wenn der Endtermin als Auswahl-Kriterium nicht mehr reicht.
Wenn Du selbst die Prio festlegen kannst, setze diejenigen Projekte auf hoch, die Deinen bzw. den Abteilungszielen am ehesten entsprechen (Bevor einer aufheult: Natürlich ist das ein Suboptimum! Natürlich sollte bei unternehmenswichtigen Projekten derartiges nicht (nur) von der Entwicklung festgelegt werden!)

Also: bei Schönwetter arbeiten alle die nächstliegenden (Endtermin) Projekte ab. Ist man damit fertig, kommt das Projekt mit dem nächsten Endtermin, etc.
Kommt man nun in Bedrängnis (Wg. Krankheit, Verzug, Schätzfehler, etc.) und muß sich entscheiden, welches von 2 konkurrierenden Projekten bearbeitet wird, hilft die Priorität dies zu entscheiden - theoretisch.
In der Praxis wird die oft vor Wochen/Monaten festgelegte Prio aber oft von irgendeiner Führungskraft nach aktuellen Belangen zurechtgerückt.

Also - keep cool.
Thomas

Irgendwer kommt und vermeldet „die Konkurenz hat…“, oder „der Kunde will…“

Oki, also fahrt Ihr schonmal reaktiv. Kann man machen.
Muss sich dann jedoch nicht wundern, wenn man niemals die Rolle der zweiten Geige verläßt.

Und die Entwicklung legt los. Darüber welchen Aufwand man in das Projekt steckt und welchen Umsatz dies generrieren kann, macht man sich erst so nach und nach Gedanken.

Süß. Wie sagte Deming vor knapp 100 Jahren schon: „Failing to plan is planning to fail“

Haben deswegen ein Projektblatt entwickelt. Wenn dies nicht vollständig ausgefüllt ist (Umlauf verschiedene Abteilungen), legen wir gar nicht los.

Nur Abteilungen - wie sieht Euer Laden aus? Habt Ihr Bereiche und Fachgruppen? Wenn ja: wie sind die involviert? Wissen die überhaupt, was Ihr so treibt? :wink:

Darin sind auch Termine ein Thema. „Wuschtermin des Vertriebs“, „Zeitlicher Aufwand“, „Zeitliche Einordnung“.

Ich will jetzt nicht Eure Unternehmensstruktur in einem Forum blanklegen lassen, aber der Aufbau wäre schon interessant, da kann man mit Sicherheit noch einiges verbessern :wink:

Ebenso ist die Priorität mit drin, die von der technischen Leitung festgelegt wird.

Und wie machen die das? Sechserwürfel rausnehmen, Ergebnis durch 2 teilen und aufrunden?

Nur stelle ich mir die Frage:

  • Ein Endtermin und eine zeitliche Einordnung ist vorhanden

Wozu benötige ich da noch Prioritäten? Was bringt es mir wenn ich eine 1,2 oder 3 hinter die Projektnummer lege. Im Endeffekt hat der Leiter der Entwicklung schon einen Überblich was seine 4 Mann da treiben.

Wie viele Projekte bearbeitet Ihr zeitgleich?
Gibt es im Unternehmen nur 1 Projekt?

In effizienteren Unternehmen ist es oft so, dass Entwickler an 2-3 Projekten gleichzeitig sitzen, da ist es schon interessant zu wissen, welches davon wichtiger ist.

Hat ein Entwickler nur 1 Projekt, ist ihm die Priorität herzlich egal.
Hat ein Executive 116 Projekte zu koordinieren und sieht er, dass 17 davon auf Status „Rot“ sind, könnte er von den Prio3 Projekten Ressourcen wegziehen und sie auf die kritischen Prio1 Projekte pflanzen.
Wenn er sagt „Was nutzen Prios“, und er ballert Ressourcen von einem Prio1 Projekt auf ein anderes Prio1, dann blinkt in der Folgewoche gleich wieder was. Da wäre es schon gut, wenn er irgend eine Entscheidungshilfe hat.

Typische Fauxpas beim Einführen eines Prioritäten-Systems:
Ein Manager erzählte mir einmal ganz stolz, dass in seiner ganzen Abteilung nur an Prio1 Themen gearbeitet wird. Fand ich sehr lustig, ihn zu fragen, wie er Ressourcen umverteilt wenn’s brennt :smiley:

Moin,
ergänzt die anderen Kommentare.

Kann man überhaupt von vornherein festlegen welche Priorität
ein Projekt hat?

Ist nicht verboten.

Ich denke dass dies eher ein dynamischer Prozess ist.

Dann macht die Festlegung keinen Sinn. Wenn ich eine Priorität festlege (egal wobei), dann bleibt sie so bestehen - es sein denn, es ändern sich die Rahmenbedingungen überraschend(!).
Grottenschlechte Planung/Projektverfolgung zähle ich nicht dazu - das wäre fahrlässig und nicht überraschend.

Das heißt, je näher der Endtermin rückt, desto höher ist die
Priorität dieses Projekts.

Das ist dann sinnlos. Die Priorisierung ist dann eine rein akademische Übung.

Was man machen kann: man ordnet Projekten/ Anforderungen/ Funktionalitäten jeweils Prioritäten zu und entscheidet VORHER, was man in den nächsten Monaten davon aktiv machen will (also 0% oder 100%). Der sinnvolle Zeitraum für so etwas hängt von eurem Business etc. ab.
Das wäre dann ein aktives Programm-/Scopemanagement.

Es wirkt, als ob ihr grundsätzlich ad hoc vorgeht.
Wie schon von anderen hier angedeutet, birgt das erhebliche Risiken.
So etwas kann gut gehen - es sind aber nicht wenige Firmen durch so etwas übel in Schräglage geraten, weil die Kosten aus dem Ruder laufen können und/oder die Wettberwerbsfähigkeit massiv leidet.
Wenn ihr nicht Monopolist seit, dann spielt ihr russisches Roulette.

Grüße
Michael