Definition Projekt in Abgrenzung zur Produktion

Definition Projekt in Abgrenzung zur Produktion

Ein Projekt ist ein zeitlich befristetes Vorhaben um ein vereinbartes Ergebnis mit gegebenen Mitteln zu erreichen (s. auch weitere Projektdefinitionen).

Ein Projekt grenzt sich darüber hinaus von der Produktion darin ab, dass die Bearbeitungszeit im Verhältnis der Durchlaufzeit relativ groß ist.

Bei Anteilen von <10% spricht man von Produktion - bei Anteilen >20% sicher von Projekt.

Was heißt Projekt im Kontext von Projekten?

Diese Abgrenzung hat weitreichende Auswirkung für das Projektmanagement und hilft vor allem die Unterschiede zwischen den agilen und den klassischen Ansätzen zu verstehen.

Produktion

Von Produktion spricht man bei einem Anteil der Bearbeitungszeit zur Durchlaufzeit kleiner 10%. Wenn man sich z.B. die Produktion von einer Schraube, einem Auto oder einem elektronischen Gerät betrachtet sieht das immer wie folgt aus: Das Produkt wird in vielen kleinen Teilen produziert. Viele dieser kleinen Teile bilden zusammen ein Produktionslos (Batch). Aus Sicht des einzelnen Teils besteht der größte Teil der Durchlaufzeit aus "warten". Warten in einer Palette, dann transportierten, herausholen, kurz bearbeiten, wieder in eine Palette, transportieren u.s.w. - zwischen den einzelnen Bearbeitungsschritten entstehen relativ lange Wartezeiten.

Das was sich jetzt vielleicht negativ anhört hat aber große Vorteile. Durch die verhältnismäßig kurzen Bearbeitungszeiten kann man die einzelnen Zeiten recht genau schätzen. Wenn eine Zeit einmal überschritten wird kann sie sich mit der Unterschreitung des nächsten ausgleichen und fällt nicht ins Gewicht. Wenn mehrere Teile parallel zu bearbeiten sind erhält man durch die langen Wartezeiten die Möglichkeit die Reihenfolge der Teile vor jedem Arbeitsschritt zu vertauschen und kann so jeden beliebigen Termin einhalten. Der Work-In-Progress lässt sich leicht Begrenzen, da er sehr überschaubar ist.Produktionsteuerungen sind extrem einfach (s. Henry-Ford, Scrum, Kanban, Drum-Buffer-Rope oder Simplified-Drum-Buffer-Rope).

Hierfür muss man aber einen Preis bezahlen: man muss alle Vorhaben in kleinste und unabhängige Teilaufgaben zerlegen und man braucht irgendwo Warteschlangen (Puffer oder Backlogs) die die mittlere Durchlaufzeit erhöhen.

Wenn man sich nun die agilen "Projektmanagement"-Methoden betrachtet wird man feststellen, dass diese im Kern Produktionssteuerungen sind - kleine Teilaufgaben, unabhängige Teilaufgaben, Puffer in Kanban, Backlog in Kanban und Scrum. Auf der Speed4Projects findet sich eine Gegenüberstellung der Steuerungen in Form einer Simulation - dies ist gleichzeitig auch eine Beschreibung von Drum-Buffer-Rope.

Projekt(ion) oder Projektmanagement

Von Projekten oder Projektmanagement spricht man wenn der Anteil der Bearbeitungszeit zur Durchlaufzeit größer als 20% beträgt. Hierbei wird vor allem der kritische Pfad oder, wenn man die Ressourcenverfügbarkeit mit betrachtet, die kritische Kette (Critical Chain) betrachtet. Das Ziel im Projektmanagement ist typischerweise das vereinbarte Ergebnis in der kürzest möglichen Zeit zu erbringen. Hierzu sind die echten Abhängigkeiten zwischen den Arbeitspaketen zu betrachten. Die Arbeitspakete sind hierbei optimal mit Ressourcen zu versorgen, so dass die Projektlaufzeit minimal wird.

Im Gegensatz zur Produktion strebt man nun aber einen Anteil der Bearbeitungszeit an der Durchlaufzeit von 100% an (wird selten wirklich erreicht - typisch sind effektiv 50-80%). Hieraus ergibt sich, dass man folgende Eigenschaften von Projekten explizit managen muss: die Abhängigkeiten, die Streuungen in den Schätzungen und die operative Ressourcenzuordnung im Multiprojektmanagement. Projektmanagement ist etwas aufwändiger (s. Critical Chain Projektmanagement).

Bei Projekten muss man daher: ausreichend konzeptionieren und planen, so dass die Arbeitspakete und ihre Abhängigkeiten klar werden, muss die Aufwände schätzen um die Ressourcenzuordnung sicher zu stellen und die Streuungen in den Arbeitspaketen abpuffern am Projektende oder im Projektportfolio.

Der Lohn hierfür ist die optimal kurze Durchlaufzeit.

Multiprojektmanagement

Im Multiprojektmanagement kommt es zu einer Kombination aus beiden Welten. Die strategische Planung der Projekte - Terminierung richtet sich nach der Ressourcenverfügbarkeit einer Engpassressource. Diese wird typischerweise wie die Engpassressource in einer Produktion gesteuert - also mit Drum-Buffer-Rope.

Das Einzelprojekt wird dann wiederum über die Zeiten und Abhängigkeiten der Arbeitspakete gesteuert - also mit Hilfe Critical Chain Projektmanagement.

Großprojekte

In Großprojekten kommt es wiederum zu einer neuen Situation. Innerhalb eines Großprojektes gibt es unterschiedliche Phasen und unterschiedliche Teilprojekte. Je nach Phase und Teilprojekt kann es sein, dass entweder eine Produktionssituation oder eine Projektsituation vorliegt. Großprojekte weisen hierbei folgenden generischen Projektaufbau auf:

  • Auftragsklärung, Konzeption und Planung - typisches Projektgeschäft - ideale Steuerung Critical Chain
  • Umsetzung in Form von Teilprojekten - hier kann alles auftreten - je nach Situation Scrum, Kanban, Critical Chain
  • Integration der Teilprojekte, Test und Stabilisierung - typische Produktion (viele kleine unabhängige Probleme) - ideale Steuerung Kanban oder Drum-Buffer-Rope/Simplified-Drum-Buffer-Rope
  • Roll-Out - typisch Produktion - Ticketsysteme - in dem Fall verschmilzt Kanban und Drum-Buffer-Rope

Um die Produktionssteuerungen in der Umsetzung sinnvoll nutzen zu können müssen diese aber noch an die Projektwelt angepasst werden - ein Beispiel hierfür ist Reliable Scurm, das Scrum um eine korrekte Terminfindung und Projektpuffer ergänzt.

Unternehmen, die in Zukunft das Optimum an Durchsatz erreichen wollen müssen daher sowohl Produktions- als auch Projektsteuerungen aus den FF beherrschen und situationsbezogen korrekt anwenden können. Da alle drei bekannten Steuerungen hier vereint sind bietet sich der Begriff Projektmanagement 3.0 an.

Hintergrund zu Abgrenzung von Projekt zu Produktion

Die Produktionssteuerungen wurden in folgenden Generationen entwickelt:

Jahr und Urheberein Eindruckschematische Darstellung
1913 Henry Ford

Begrenzung des WIP über die Fläche vor jeder Arbeitsstation

Eigenschaften:

+ ultimativer Durchsatz

-  keine Flexibilität (nur ein Modell und das auch noch schwarz!)

1953 Taiichi Ohno (Kanban)

Begrenzung des WIP durch den Bestand (Paletten) vor jeder Arbeitsstation

Eigenschaften:

+ flexible Modellvarianten möglich

+ einfache Steuerung über Kanban-Karten

-  hoher Bestand (Puffer vor jeder Arbeitsstation)

-  träge, sehr empfindlich auf Änderungen des Bedarfs und Aufgaben

2005 Eliyahu Goldratt (Drum-Buffer-Rope)

Begrenzung des WIP an der Engpassstation. Nur noch ein Puffer vor dem Engpass. Dieser steuert den Start von neuen Aufträgen und terminiert das Auftragsende.

Eigenschaften:

+ volle Flexibilität

+ einfache Steuerung über den Füllstand des Puffers vor dem Engpass

+ minimaler Bestand (nur ein Puffer)

+ kompatibel zu Projektsteuerungen wie Critical Chain

-  aufwändiger als Kanban in der Vermittlung und Anwendung

Beiträge auf openPM zu Projekt

Twittern

10 Comments

  1. Interessante Überlegungen. Ich würde neben Produktion auch noch den Prozess-Gedanken mitbetrachten. In "modernen" Produktionssystemen, die auf dem Toyota Production System (TPS) basieren (vgl. Lean Management), wird danach gestrebt, die Durchlaufzeit der Bearbeitungszeit anzugleichen. Vereinfachend ausgedrückt, wird dies erreicht bzw. angestrebt, indem die Losgröße im Idealfall 1 beträgt und Zwischenpuffer dadurch weitgehend vermieden werden können. Stichworte sind dazu das Flussprinzip, verbunden mit dem Pullprinzip (Steuerung durch den Kunden bzw. den nachfolgenden Prozessschritt). Vermideden bzw. reduziert werden dadurch die Verschwendungen Lagerhaltung, ggf. Überproduktion, Wartezeiten, häufig auch Transport.

    Nach 1953 fehlt die Weiterentwicklung eben durch Taiichi Ohno zum o.g. TPS mit den tw. genannten Prinzipien unter Vermeidung von Verschwendungen. Dort entfallen dann die genannten Nachteile (Bestände und Trägeheit). Das TPS strebt danach den Engpass, der bei Goldratt als Steuerungselement eingesetzt, völlig zu vermeiden. Erreicht wird dies paradoxerweise dadurch, dass sein Auftreten offensichtlich gemacht wird und dann die Optimierungsbestrebungen darin beruhen, ihn abzuschaffen.

    Der Bezug Prozess zum Projektmanagement entsteht durch den Projektmanagement-Prozess. Inhaltlich ist jedes Projekt einmalig, trotzdem genügt die Abfolge der Aktivitäten einer Regelmäßigkeit, also dem Prozess-Gedanken. Auf höchster Ebene erkennbar durch die Projektphasen (nach IPMA/GPM) Initiierung-Definition-Planung-Umsetzung-Abschluss.

    1. Danke für die Ergänzungen - aus Produktions und Prozesssicht absolut erwähnenswert

      Die Idee mit der Losgröße 1 wird IMHO in Scrum und Kanban Projektsteuerungen aufgegriffen. Haben allerdings in der Projektwelt Grenzen und Nachteile. Wenn man Losgröße 1 in die Projektwelt übertragen will muss man letzt endlich das große Projekte in eine vielzahl extrem kleiner Teile zerlegen, die ähnlich groß sind und voneinander unabhängig. Wenn man das schafft erhält man die von ihnen genannten Vorteile. Grenzen hierbei sind eben die Unabhängigkeit und die Möglichkeit die Teile klein zu hacken - in der IT ist das gerade am Anfang oft möglich - in Großprojekten tendenziell nicht. Projekte weisen ja per se auch immer neue Herausforderungen auf und grenzen sich dadurch auch von den Prozessen ab - daher ist nach einer gewissen Zeit zu beobachten, dass Projektorganisationen die zu stark in Prozessen denken die Organisation und auch die Systeme für jedes neue größere Projekte umgebaut werden muss so dass der Prozess wieder passt.

      Auch Goldratt hat sich weiter entwickelt (smile) In der urspünglichen Produktionssteuerung (Drum-Buffer-Rope) wird tatsächlich ein Engpass als Steuerelement genutzt. Mittlerweile ist man auch hier soweit, dass man davon ausgeht, dass der Engpass nicht im eigenen Unternehmen sein sollte sondern im Markt (Vertrieb). Wenn das der Fall ist kann die Steuerung nochmals vereinfacht werden und wird dann zu einer Simplified-Drum-Buffer-Rope. Hier wird zwar noch von einer "near constraint resource" als Fast-Engpass gesprochen - mit Hilfe diesen werden aber nur noch die Lieferzeitpunkte terminiert und dann über Zeitverbrauch gesteuert. Auch hier erfolgt die Optimierung wie im TPS über Reduktion des Bestandes und Offenlegung der Engpässe. TPS nähert sich aktuell stark an Goldratt an. Goldratt macht aber kein Hehl daraus, dass er auf die Leistungen von Ohno aufbaut http://www.goldrattschools.org/pdf/shoulders_of_giants-eli_goldratt.pdf

      Am Schluss unterscheiden sich Projekte dann doch von der Produktion. Die strategische Priorisierung und Einlastung ist dabei identisch zur Produktion und ähnelt einer Drum-Buffer-Rope. Auf Arbeitspaketebene ist es aber komplexer, da die Abhängigkeiten und Unsicherheiten stark zum Tragen kommen - hier ist die Ressourcenzuordnung nach Critical Chain das Mittel der Wahl

  2. Arrgh, irgendwas ist jetzt schiefgelaufen, mein ganzer schöner Kommentar ist weg (sad) %$&§@ Vorschau-Funktion.

    Also noch ein Anlauf. Mal seh'n, ob ich noch alles zusammenkriege ...

    Geendet hat es mit folgendem Video, das ein Großprojekt mit ganz starker Prozessorientierung und minimaler Losgröße zeigt:

    Speziell in SW-Projekten in bestimmten Bereichen ist man schon ganz gut in Richtung Losgröße 1 unterwegs. Das sind m.E. vorallem solche Applikationen, bei denen der Endanwender nichts installiert, also z.B.

    • SaaS (Software as a Service)
    • Telekommunikationsdienste
    • Cloud-basierte Anwendungen mit Webfrontend
    • Social Media (Facebook, XING und Co.) also bekannte Sonderfälle

    Gerade habe ich auch ein Buch (Lean Startup von Eric Ries) zuendegehört, indem Lean-Prinzipien auf die Gründung von Unternehmen oder eben die Entwicklung neuer Produkte übertragen wird. Seine Grundaussage ist, dass viel zu oft der Hauptfokus auf die Entwicklung neuer Leistungsmerkmale gelegt wird, nur um dann später zu erkennen, dass die Nutzer das gar nicht wollten. Er appelliert hier ganz stark dafür die Losgröße 1 auch auf diese Bereiche zu übertragen und vergleicht die Widerstände mit denen, die auch in der Produktion gegen die Losgröße 1 bestanden und in vielen Bereichen immer noch bestehen. Letztlich beruhte ja die ganze industrielle Revolution auf der Einführung der Massenproduktion. Und jetzt soll alles falsch sein. Vermutlich würden wir immer noch Autos immer noch wie Ford bauen, hätte Toyota nicht bewiesen, dass es auch anders geht.

    Als ich das erste Mal von Scrum und agiler SW-Entwicklung gehört habe, dachte ich, dass hier ein paar Geeks (war selber mal einer (wink) den aktuellen Zustand zur Methode erklärt haben. Mittlerweile sehe ich das etwas differenzierter. Wie in vielen anderen Fällen ist es die große Herausforderung, die Spreu (den Hype) vom Weizen zu treffen. Wenn es etwas nicht funktioniert, dann war abwarten die richtige Strategie. Aber wehe, wenn nicht (Ford --> GM --> Toyota / iTunes / ...) Auf jeden Fall ist es einige Überlegungen wert, wie die beiden vermeintlich disjunkten Welten miteinander kombiniert werden und voneinander lernen können.

    1. Ja - ich bin fest überzeugt, dass die in Zukunft wirklich erfolgreichen Unternehmen - die Fähigkeit haben die Welten zu kombinieren.

      Vielleicht noch ein anderer Aspekt, der von vielen in der Hype gar noch nicht wargenommen wird. Ich bin in Kontakt mit sehr bekannten IT-Unternehmen, die schon seit Jahren (min 3 Jahre) auf Scrum und Kanban setzen. Es ist interessant zu sehen, mit welchen Problemen diese "kämpfen". In der Anfangsphase war alles Fried-Freude-Eierkuchen. Sie hatten alle einen Berg an kleinen Verbesserungen, die zum Kunde raus mussten. Das ist eine ideale Losgröße 1 Welt - daher super Erfolge.

      Das was am Anfang aber super ist kann sich später umkehren (nicht komplett aber doch störend).

      Die Kunden haben ja dann ein schönes Produkt und bekommen laufen immer wieder kleine Verbesserungen. Das verrückte ist, das ist dann "gewohnt" damit kann man niemand auf dauer neues Geld aus der Tasche ziehen. Also was kommt es muss etwas neues Großes her - etwas, das wieder wahrgenommen werden kann! Aber das Neue hat einen Nachteil - es passt nicht in die eingeschliffenen Prozesse und Systeme. Selbst die Organisation passt nicht mehr. Und weil es Groß ist hat es viele Schnittstellen - denn der Kunde will heute ja, dass die Komplexität vor ihm versteckt wird (iPhone/Tunes/Pad-Welt). Wenn man dann nur Scrum/Kanban/Prozesse als Werkzeug kennt - musst man die ganze Organisation inkl. Systeme umbauen oder verliert sich in den ganzen Abhängigkeiten zwischen den Scrum-Teams.

      Auch hier gehe ich davon aus, dass weder das eine (produktion/prozesse) noch das andere (projekt) allein die Lösung sind - sondern erst wenn man beides wirklich beherrscht man je nach situation umschalten kann.

      mfg Wolfram Müller

      p.s.: auf jeden Fall zu empfehlen ist auch das Buch "Inventors Dilemma" - das beschreibt die theoretischen Grundlagen für diesen Umkehreffekt

  3. Hier ein Link zu Heise Developer, wo - aus Sicht der IT - die derzeit fast überall beobachtbaren Probleme mit der typischen organisatorischen Umsetzung des Allheilmittels "Agil" kurz angerissen werden. Ob man Argumentationsreihe des Artikels folgen möchte, sei aber jedem selbst überlassen...

    http://www.heise.de/developer/artikel/Agile-Software-Entwicklung-braucht-auch-ein-agiles-Projektmanagement-1598135.html

  4. Interessanter Artikel. Ein Vorteil von agiler SW-Entwicklung ebenso wie agilem Projektmanagement ist der Fokus auf den Nutzungserfolg. Sklavisches Festhalten am ursprünglichen Plan bringt natürlich nichts, wenn hinterher niemand mehr das Projektergebnis in der geplanten Form benötigt. Sicher überzeichnet der Artikel dabei etwas, tendenziell passiert das leider aber viel zu oft. Etwas etwas irreführend finde ich die Darstellung des magischen Dreiecks als Zeit-Kosten-Inhalt. Ich verwende hier lieber "Leistung" statt "Inhalt". Damit kommt auch wieder der Nutzungserfolg ins Boot, während "Inhalt" eine Abgrenzung nach außen impliziert. Eher skeptisch bin ich auch, wie Änderungen von innen initiiert werden (sollen). Hier fehlt mir auch der Bezug zur Außenwelt, d.h. zum Kunden. Bei den Vorgehensmodellen klafft für mich eine Lücke durch die fehlende Nennung des V-Modells. Abschließend fehlt mir noch die Nennung der notwendigen Reife (bzgl. Zusammenarbeit, Kommunikation usw.) des Projektteams bei agilen Methoden. Hier sind mir im Reallife doch immer wieder Defizite aufgefallen.

    Der Grundthese des Artikels, dass agile Entwicklung(s-prozesse) auch agiles Projektmanagement benötigen stimme ich völlig zu. Alles andere ist unsinnig und ist m.E. von vorne herein zum Scheitern verurteilt. Letztlich inkarniert ein spezifisches Projekt mit seinem Management immer aus dem zugrundeliegenden Prozess. Mit Prozessen ist es m.E. wie mit Kommunikation und Verhalten: Man kann es nicht nicht tun oder nicht keines haben. Trotz People over Process ist das bei agilen Ausprägungen genauso. Aber das ist auch kein Widerspruch. Letztlich steht auch bei einem ultimativ prozessorientieren Modell wie dem Toyota Production System der Mensch als bestimmende Größe im Vordergrund.

  5. Mein Hauptbedenken, wenn mal wieder irgendwo die Idee auftaucht, mit agiler Entwicklung wird alles viel besser, drücke ich mit einem Zitat aus (Quelle unbekannt): "Wenn man einen Sumpf trockenlegen möchte, darf man nicht die Frösche beauftragen."

    Wenn ich das Glück habe, ein Team aus lösungsorientierten und sehr gut selbstorganisierten Leuten zur Verfügung zu haben, ist es klar, dass mit agilen Methoden exzellente Erfolge zu erzielen sind. Aber mit einem solchen Team wird auch nie der Ruf nach einem Paradigmenwechsel laut werden, denn dieses Team wird auch mit traditionellen Methoden sehr erfolgreich sein. Oft sogar ohne explizites Projektmanagement, da meist eh jeder weiß, was wann zu tun ist.

    Versteht mich nicht falsch, ich bin sehr wohl von den Vorzügen agiler Entwicklung/agiles PM überzeugt. Nur scheitert es eben meistens schon an der Grundeinstellung der beteiligten Menschen. Viele im Projektteam wollen gar keine Verantwortung übernehmen, oder inhaltlich mitwirken. Viele Auftraggeber wollen gar nicht ihr spontanen Machtdemonstrationen aufgeben, und viele Kunden wollen gar nicht zugeben, dass im Verlauf des Projekts im umsetzenden Team Experten heranreifen, die im Wissen den eigenen Inhouse-Experten überlegen sind.

    Aus diesen Gründen habe ich bisher meist die Versuche a la "jetzt sind wir agil, alles wird besser" scheitern sehen. Weil keiner die Mühen investieren will, zu verstehen, welches Werkzeug man damit in die Hände bekommt.

    --

    Um auf den ursprünglichen Artikel noch mal zurückzukommen: Ich habe sehr wohl die Erfahrung gemacht, dass traditionelles PM mit agilem Vorgehen funktionieren. Wir haben damals Scrum als Entwicklungsmethode eingesetzt, aber nach den PMI-Richtlinien gemanagt. Der aktuelle Sprint (6 Wochen-Zyklus) war voll als eigenes Kleinprojekt recht gut ausgeplant, der nächste Sprint zu 95% fertig geplant. Und die folgenden Sprints immer besser je näher sie waren. Und natürlich war für das ganze Projekt auch ein High-Level-Managament verfügbar, das sich häufig geändert hat, was aber der Teilprojekte wegen gut akzeptiert war.

    So konnten die Kunden ihre wichtigen Milestones in den jeweiligen Sprints schon sehen, unser  interner Auftraggeber/CEO hat seine gewohnten Charts und Berichte erhalten (die er zwar nicht verstanden hat, aber wegen gewohnten Aussehens akzeptiert hat), und wir als Team haben uns damit auch recht gut gefühlt, weil auch die einzelnen Personen die längerfristigen Perspektiven und Ziele nicht verloren haben (was bei purem Scrum ja durchaus vorkommt: Teile des Teams verlieren den Blick auf das Ganze). Und mich hat es beruhigt, weil ich meine PMP-Zertifizierung nicht umsonst gemacht habe...

  6. zum Thema agil und classisch zusammen gibt es wieder neues:

    a) Vortrag auf der InterPM 2012 in Glashütten - hier wird auch gezeigt, wie man die Steuerungen vereinheitlicht ... so dass interessanterweise auch das Thema Motivation in Gang kommt ... Vortrag kann man hier downloaden den Rohentwurf des Tagesbandes kann man bei mir anfordern

    b) auf der Website www.reliable-scrum.info wird gezeigt wie man scrum mit CCPM verheiraten kann und so noch mehr rausholt ... auch hier sobald man die Steuerung verändert kann man sogar aus Scrum nochmal ganz schön was rausholen

    c) aus der Zeit vor "agil" gibt es schon zwei Artikel die beschreiben, wie wir bei der 1&1 High Speed Projekt gemanged haben ... http://www.speed4projects.net/downloads/projektmagazin/ die Artikel kann man aber auch bei mir bekommen - einfach kurz melden mail@speed4projects.net

  7. Um ehrlich zu sein, ich finde die meisten hier vorgenommen Definitionen ziemlich absurd

    Beispiel: Definition Produktion:

    > Ein Projekt grenzt sich darüber hinaus von der Produktion External Link darin ab, dass die Bearbeitungszeit External Link im Verhältnis der Durchlaufzeit External Link relativ groß ist.
    > Bei Anteilen von <10% spricht man von Produktion - bei Anteilen >20% sicher von Projekt.

    Diese Definition scheint mir völlig willkürlich, keinesfalls zwingend und nennt in keiner Weise das Wesen von Projekt und Produktion

    Beispiel: Definition Projekt:

    > ..die ein einzelner Mitarbeiter allein bearbeiten bzw. ausführen kann, sind - in der Regel - keine Projekte

    Auch hier wird nicht auf das Wesen von Projekten eingegangen. Absurd ist der Fakt, dass die Leistungsfähigkeit des betrauten Mitarbeiters darüber entscheiden soll, ob etwas Projekt ist oder eben nicht. Da scheint mir auch der unzulässige Gedanke mitzuschwingen, dass nur Projekt sein darf, was einen dedizierten Projektleiter braucht,

    Und da die Frage sicher kommen wird, wie ich die Begriffe definiere:

    Projekt:

    Das Wesen eines Projektes ist etwa neues zu schaffen. Es wird ein Weg oder Plan gesucht wie etwas gemacht werden kann. Das Ergebnis kann ein Prototyp sein. Die Erstmaligkeit wird nur relativ zu den Beteiligten gefordert. So verliert ein Vorgang nicht seinen Projektstatus nur weil jemand anderst auf der Welt das Gleiche macht, wohl aber dann wenn die Ergebnisse des Anderen übernommen werden.

    Damit impliziert ein Projekt zwingend hohe Risiken. Und keineswegs kann ein Projekt vollständig definierte Ergebnisvorstellung garantieren (Das wird vielen sauer aufstossen). Wohl aber kann versucht werden die Schwerpunkte anhand von Prioritäten zu steuern. Und böse ausgedrückt, hinterher wird so nachdefiniert dass das Projekt als Erfolg erscheint.

    Bei Projekten geht es primär um Effektivität.

    Produktion:

    Das Wesen der Produktion ist die Ausführung eines Planes um ein Produkt zu erstellen. Der Weg/Plan ist schon da und muß nun möglichst fehlerfrei und effizient umgesetzt werden. Eine Produktion kann vollständig definierte Ergebnisvorstellungen wirklich auch garantieren (stabile Prozesse vorausgesetzt) . Die verschiedenen Produktionsmethode wollen die Effizienz erhöhen.

    Prozess:

    Ist ein wiederholter Vorgang der immer wieder das gleiche konkrete Ergebnis erzeugt. Kennzahlen sind sehr präzisse ermittelbar (Kosten, Zeiten, Aufwand...). Prozesse sollen effizient sein.

    Methode/Systematik

    Ist ein Vorgang, der ähnlich strukturiert in verschiedenen Situation angewendet wird. Kennzahlen sind nicht präzisse ermittelbar, wohl aber Stärken und Schwächen. Methoden sollen effektiv sein.

    Beispiel:

    Eine Softwareentwicklung erstellt eine neue Anwendung. Teile der Vorgänge sind bekannt, also Prozesse. Andere Teile sind neu. Da muss erst ein Weg/Plan gefunden werden. Das entspricht dem Projektanteil.

    Das Verhältnis der genannten Teile bestimmt wieviel Risiko in dem Vorhaben liegt. Ist es hoch, werden Aussagen über Zeit, Aufwand immer unsicherer.

    Das Vorgehen, sei es Wasserfall oder Scrum ist eine Methode/Systematik. Es hängt stark vom Thema ab, welche Methode effektiver und effizienter ist.

    Die Produktion ist das Kopieren eines Installationpaketes für die Anwendung. Produktion ist in der Softwareentwicklung ein so kleiner Aufwand, dass er konzeptionell übersehen wird. Bei Hardware und Massenprodukten ist die Produktion in der Regel der grössere Anteil an den Kosten. (Ich habe auch noch nie von Produktionsingenieuren in der Softwareentwicklung gehört)

    Gemäß obiger Definition ist "Projektmanager"/"Projektleiter" ein falscher Begriff, da selten reine Projekte anzutreffen sind oder der Projektanteil durch eine eigene Person betreut wird. Ein "Projektmanager"/"Projektleiter" wird sich für den Erfolg des gesamten Vorhabens einsetzen.

    (Sicher kann man die Definition noch anreichern, aber die Mail ist eh schon lang gewordern)

  8. Hallo,

    nur weil etwas willkürlich erscheint muss es nicht willkürlich sein. Diese ergänzende Definition/Abgrenzung zwischen Projekt und Produktion bezieht sich hauptsächlich auf die Steuerungsaspekte im Multiprojektmanagement (wichtig - hier konkurrieren viele Projekte um die gleichen Ressourcen). Die Thematischen und allgemein anerkannte Definition wird hier ergänzt und erweitert.

    Aber warum ist das Verhältnis von Touch-Time zu Lead-Time so relevant für die Steuerung. Wenn die Touch-Time < 10% wird kann man im Multiprojektmanagement einfach durch Vertauschung der Arbeitspakete der Projekte fast jeden zugesagten Termin einhalten.Vorraussetzung nebenbei ist natürlich auch dass man vertauschen kann und wenig Abhängigkeiten bestehen.

    Wenn die Touch-Time klein ist können Produktionssteuerungen wie z.B. Kanban, Scrum, Drum-Buffer-Rope oder Simplified-Drum-Buffer-Rope zum Einsatz kommen.

    Wenn nicht dann muss man die volle Komplexität berücksichtigen und ist in der Multiprojekt und Critical Chain Projektsteuerungswelt

    Die Betrachtung des Verhältnis zwischen Touch-Time und Lead-Time ist wichtig um die Frage von Ihnen zu beantworten "Es hängt stark vom Thema ab, welche Methode effektiver und effizienter ist"

    Die agilen Methoden sind dadurch gekennzeichnet, dass sie das Problem (Projekt) in viele kleine unabhängige Teile zergliedern (Stories) so dass eine Produktionsumgebung entsteht die einfach zu steuern ist. Das macht an vielen Stellen Sinn - man muss nur wissen wo und das man das macht. Wenn man versucht alles so zu managen verliert man an Effektivität und Effizienz (wink) Die Definition hier kann helfen zu unterscheiden wann was sinnvoll ist

    mfg Wolfram Müller

    p.s.: Effektivität und Effizienz ist leider keine Unterscheidung - es geht immer um Effizienz. Effektivität ist per def. die Ergebnisqualität (Output) und nur die Voraussetzung. Es geht immer darum den größt möglichen Output bei kleinst möglichem Resourceneinsatz zu erreichen = Effizienz.

    p.s.: Produktion ist nicht unbedingt ein Prozess der nur immer das gleiche Ergebnis produziert. In der Automobilindustrie dauert es oft Monate bis wieder mal ein gleiches Auto vom Band läuft ...

    p.s.: ihr Zitat "die ein einzelner Mitarbeiter allein bearbeiten bzw. ausführen kann, sind - in der Regel - keine Projekte" finde ich in diesem Thread nicht - das erschwert die Beurteilung der Qualität ihres Beitrags erheblich. Ich wäre auch zurückhaltender mit wertenden Adjektiven

     

Dieser Inhalt von openPM steht unter einer Creative Commons Lizenz (CC BY 3.0) und kann frei verwendet werden unter Namensnennung durch Link auf http://openpm.info. Unpassende Inhalte, insbesondere Verstöße gegen Urheberrechte, bitte via info@openpm.info melden. Weitere Informationen unter Nutzungsbedingungen