Inhalt : Definition Projekt in Abgrenzung zur Produktion

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.

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 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

Arrgh, irgendwas ist jetzt schiefgelaufen, mein ganzer schöner Kommentar ist weg  %$&§@ 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  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.

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

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

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.

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...

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

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 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.

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)

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 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