Unser Sprachgebrauch ist häufig "unsauber". Es gibt nicht nur unterschiedliche Definitionen des Projektbegriffs, der Projektbegriff wird auch noch inflationär gebraucht. Eine "Projekttitis" findet sich allerorten. jedes Vorhaben wird zum Projekt, jeder Auftrag, jede Aufgabe. Vor diesem Hintergrund macht es sicherlich Sinn den Projektbegriff (mit hoffentlich reger Beteiligung) weiter zu diskutieren und ihn von anderen Begriffen stärker abzugrenzen. Diese Seite ist der Versuch mit einigen Thesen hierzu die Diskussion in Gang zu bringen indem zentral die Unterscheidung von Projekt und Prozess n
Vorneweg: Diese Diskussion sollte wertfrei sein - Ein Projekt ist nicht besser oder schlechter als eine Aufgabe oder ein Prozess. Sie ist lediglich anders. Wenn wir über Werkzeuge und Methoden diskutieren können Projektmethoden natürlich auch anderenorts eingesetzt werden und umgekehrt. Sie sind dann im Einzelfall äußerst wertvoll, taugen aber nicht unbedingt zur Verallgemeinerung oder als generelle Handlungsempfehlung, auch wenn sie situationsspezifisch der Schlüssel zum Erfolg sein mögen.
Einzigartigkeit
Ein wesentliches Element für den Projektbegriff ist die Einzigartigkeit eines Vorhaben. Dies trennt ihn vom Prozessbegriff, der geprägt ist von der Wiederholung der Vorgänge. Wir befinden uns aber auf einem schmalen Grad, den selbstverständlich ist beispielsweise jedes Bauunternehmen routiniert in der Abwicklung von Bauvorhaben und doch ist jedes für sich schon wieder einzigartig. Ein Fertighaus vielleicht wieder weniger, aber ein komplexes Bauvorhaben, wie ein Flughafen oder ein Krankenhaus hingegen schon. Und auch wenn wir zwischen Projektarbeit und einer prozessorientierten Arbeit unterscheiden, gibt es auf einer Metaebene natürlich auch Projektmanagementprozesse.
Mit der Einzigartigkeit einher geht ein zweiter wesentlicher Aspekt der Projektarbeit (zumindest wenn man einen engen Projektbegriff heranzieht): Die Problemlösungsorientierung.
Fokus auf die Problemlösung
Einzigartigkeit und Problemlösungsorientierung grenzen Projekte ab von einer Optimierungsorientierung in Prozessen. Auch auf openPM sind Ansätze wie High Speed Projektmanagement schon kritisch diskutiert worden. Möglicherweise liegt die Kontroverse darin begründet, dass hier ein Optimierungsgedanke á la Critical Chain betont wird. Das mag im Einzelfall zielführend sein, setzt aber voraus, dass der Lösungsweg bereits weitgehend bekannt ist.
An dieser Stelle liegt möglicherweise auch ein grundlegendes Missverständnis zwischen agilen und klassischen Projektmanagementansätzen (von der Wertediskussion einmal völlig abgesehen): In einem Backlog findet sich bereits ein Pool vergleichbarer Aufgabenstellungen, die im Team bearbeitet werden. Für Vertreter eines klassischen Projektmanagement ist dieser Schritt aber nicht selbstverständlich. Zwischen den einzelnen Aufgaben kann ein großes Ungleichgewicht, eine Unvergleichbarkeit herrschen, und die Abhängigkeiten zwischen den Aufgaben können ein sequentielles Vorgehen erzwingen, dass keine Iterationen/Sprints zulässt. Dies ist keine Fundamentalkritik an agilen Vorgehensweisen, sondern lediglich eine Relativierung. Die große Stärke agiler Ansätze liegt in der Etablierung von Projektmangagementprozessen (Metaebene) unter Einbeziehung aller Beteiligter, einer Betonung des Teams und vor allem der Kommunikation im Team.
Formale oder inhaltliche Definition
Nicht alles was in Unternehmen als Projekt bezeichnet wird, erfüllt die Kriterien, wird aber formal durch Projektmanagementprozesse getragen. Umgekehrt gibt es häufig "echte" Projekte, die unter anderem Titel (als "U-Boot") umgesetzt werden, um formalen Anforderungen aus dem Weg zu gehen, Politik zu betreiben oder aus anderen Gründen. Viele solcher Pseudo-Projekte führen Projektmanagement und Projektmanagementmethoden ad absurdum. Umgekehrt könnte Projektdenken viele dieser Vorhaben bereichern.
Bitte helft diesen Artikel und die Diskussion weiter zu entwickeln. Neue Thesen bitte gerne in den Artikel integrieren und nutzt die Kommentare zur Diskussion.
Comments:
|
Hallo Bernhard, ich war gerade online und das Thema taucht in meiner Arbeit in Unternehmen immer und immer wieder auf ... ... ich möchte nicht verwegen sein - aber es gibt eine einfach Lösung für die Definition und Unterscheidung zwischen Projekt und "Auftrag". Denn hier liegt schon der erste Hase im Pfeffer. Das Begriffspaar passt nicht zusammen. Hier mal ein Versuch passende Begriffe zusammen zu bringen: Prozess ist eine effiziente strukturierte Abarbeitung von Aufträgen. Prozesse haben den Charakter von Produktion. Produktion dient der Herstellung von Produkten. Projektmanagement ist eine flexible Abarbeitung von Projekten. Projektmanagement hat eingen ganz eigenen Charakter und dient der Erstellung von Projekten (gerne wie sie in der DIN definiert wurde - neu, risikoreich, zeitlich terminiert, wirtschaftlich sinnvoll und spannend (o.ä.). kurz Prozesse sind in der Domain der Produktion - Projekte in der Domain des Projektmanagements bleibt die Frage, wie sich diese unterscheiden? 1. Produktion (Prozesse) - viele relativ ähnliche Aufträge (in Bezug auf Aufwand und Dauer) wobei die Aufträge relativ unabhängig von einander sind. Das Kernmerkmal ist hier - die Touch-Time (Bearbeitungszeit) ist viel viel kleiner als die Lead-Time (Durchlaufzeit). Typischerweise ist die Touch-Time < 10% der Lead-Time. Warum ist das so wichtig - Prozesssteuerung basieren auf der Tatsache, dass man (wenn das System nicht überladen ist) - jeden Termin einhalten kann in dem man die Reihenfolge der Aufträge vertauschen kann. Die meisten kennen ja agile Methoden - das sind interessanterweise alles Produktionssteuerung (+ etwas Gruppendynamik). Die Lead-Time beginnt in dem Moment in dem eine Story bestellt wird. Dann liegt sie lange im Backlog und wird kurz in einem Sprint bearbeitet. Sehr oft ist hier die Touch-Time < 10% der Lead-Time. Ähnliches gilt für Kanban - hier kann man auch schön die Reihenfolgenvertauschungen sehen. Achtung: Produktion heist nicht stupide unkreative Tätigkeiten - Produktion kann auch sehr sehr kreativ sein. Ich möchte auch nicht gegen agile Methoden wettern - sie sollten überall eingesetzt werden wo es nur möglich ist - denn es gibt keine einfacheren und leichtgewichtigerer Steuerungen. Aber man muss halt die 10% im Auge behalten! 2. Projektmanagement (Projekte) - hier steht ein einzelnes Vorhaben im Vordergrund. Es besteht aus Arbeitspaketen, die dummerweise hart über Abhängigkeiten gekoppelt sind (ich kann halt eine Wand erst bauen, wenn das Fundament trocken ist). Des weiteren weiß man bei den einzelnen Arbeitspaketen wirklich nicht wie lange es geht (ehrlich) und wenn man genau hinschaut sind sie sich auch nicht ähnlich und vor allem unterschiedlich groß. So ein Ärger aber auch - in solch einem Fall versagen Produktionssteuerungen kläglich. Man muss die Abhängigkeiten und Streuungen managen. Was aber auch interessant ist - die Touch-Time (auf der kritischen Kette) sollte möglichst Nahe and der Lead-Time sein. Kein Auftraggeber würde 90% pausen akzeptieren und das macht das ganze interessant. Eine gute Methode ist hier z.B. Critical Chain, die explizit die Abhängigkeiten in den Vordergrund rückt und die Streuungen über explizites Buffermanagement handelt. Ab einer Touch-Time von größer 20% der Lead-Time rutsch man in die Projektwelt. Achtung: im Bereich 10-20% kann man beides einsetzen - Projekte will man eigentlich näher bei 80-90% haben. Ab 20% ist man aber sehr sicher in der Projektwelt.
Auf OpenPM gibt es schon ein ähnlicher Artikel der ein bisschen mehr Hintergründe gibt über die Abgrenzung von Projektmanagement zur Produktion ... Jetzt sollte man eigentlich deine Fragen beantworten können:
Das alte klassiche Wasserfall-Projektmanagement war geeignet für sehr gut bekannt Lösungen für eigentlich bekannte Probleme - sobald es etwas problematischer (komplexer) wurde ging es in die Knie. Wesentlich besser als das klassiche Projektmanagement kann Critical Chain mit Risiken und Ungewisheiten umgehen - dafür hat es die Puffer und das Puffermanagement. Aber auch das hat seine Grenze. Critical Chain bringt zusätzlich noch eine einfach Art des Portfoliomanagements mit, das sicher stellt, dass der Engpass nciht überlastet ist.
Wenn es noch risikobehafteter wird dann wird es auch für Critical Chain eng. Hier können agile Methoden manchmal noch ein bisschen mehr rausholen. Wobei ich ja vertreter der 3. Generation Agile bin - also sprintloses Scrum oder one Stage-Kanban. Denn mit diesen 3. Generation Agile-Methoden kann man noch schneller Itterieren. Wenn es dann ich dich hochinnovativen Prozesse geht - dann ist man bei IDEO, TRIZ oder Design-Thinking.
Also ich wollte hier nur das Verhältnis von Touch-Time zu Lead-Time ins Spiel bringen. Das Produkton (Prozesse) von Projekten unterscheidet. Damit kann man super viel erklären. z.B.:
Und das ist mein letzter Beitrag für heute ... wenn man genau hinschaut sieht man in Produktentwicklungsbereichen drei Sytemebenene - mit unterschiedlichem Charakter: L1 - Portfolio - viele relative ähnliche Projekte die in der Reihenfolge vertauschbar sind = Produktion L2 - Projekt - hier hat man es mit dem Gelumpe der Abhängigkeiten und Streuungen zu tun = Projektmanagement L3 - Task - hier können sich die agilen Methode austoben - viele kleine Stories = Produktion damit kann man auch ein Framework beschreiben, das beides kann - Projekte und Produktion und das ohne sich zu behindern und das Beste aus beiden Welten zu nutzen: http://speed4projects.net/know-how/forschung/project-agile-framework/ oder der Vortrag auf der TOCICO Weltkonferenz ...
Ich würde mich wie Bernhard über eine rege Diskussion freuen 
Posted by wmueller at 01. Feb 2014 21:46
|
|
Zum klassischen IT-Betrieb (Produktion) gehört auch ein Problem Prozess. Während der normale Betrieb sicher nichts mit Projekten zu tun hat, glaube ich , dass es genau in diesem Prozess zu einem fließenden Übergang vom Prozess zum Projekt kommt. Das Problem ist auch einzigartig, da man andererseits schon eine Lösung parat hätte. Zusätzlich wird ein „Lösungstreiber oder Tickettreiber“ gesucht welcher für zusätzliche Ressourcen, Teambildung, Kundenkommunikation und Management Einbindung sorgt um möglichst bald eine Lösung zu finden. Fühlt sich an wie Projekt, wird aber nach meinen Erfahrungen in der Regel nicht so behandelt. Kommt es jetzt noch durch eine soziale Rückkopplung zum direkten Einfluss auf ein gerade laufendes Vertriebs oder Rollout Projekt (Kunde droht mit Auftragsverzögerung) ist das Problem eigentlich Teil eines Projektes. Was natürlich als störender Faktor eher bekämpft als integriert wird weil es als Thema des Betriebs gesehen wird. Im Betrieb ist es ähnlich unbeliebt weil die hohe Touch-Time die KPIs negativ beeinflusst.. Eine feine Unterscheidung zwischen den beiden Systemzuständen ist tatsächlich wünschenswert und kann auch sicher für eine harmonischere Zusammenarbeit zwischen Betrieb und Projekt sorgen.
Posted by pmad at 02. Feb 2014 14:39
|
|
Super Beispiel - IT-Betrieb ist typischerweise eher "Produktion" - im Falle eines Incidents wechselt der Charakter aber schlagartig hin zu Projekt. In großen ITIL-Organisation gibt es in so einem Fall dann einen andere Organisation die übernimmt. Es kommt ein Incident-Manager ins Spiel, der dann eher in "Projektform" die Analyse und Aktivitäten koordiniert. Das gleiche wenn der Inicdent gelöst ist (und ein Workaround) etabliert ist geht der Sachverhalt in ein Problemlösemodus (heist dann auch Problem) - das sollte dann wie ein Projekt gemanaged werden und ist auch nicht mehr zwingen in der Betriebsorganisation. cu Wolfram p.s.: solche schlagartigen Übergänge gibt es interessanterweise auch innerhalb eines Projektes. Vielen Projektmanager ist es gar nicht bewusst, dass die Integrationsphase (also die End-2-End-Tests) gar keinen projektcharakter haben - sondern reinrassige Produktion sind. In der Integrationsphase weiß man ja nicht was passiert - es wird getestet, dann funktioniert was nicht. Dann weiß man nicht welchen Experten man braucht - aber es ist gewiss, dass man jemand braucht mit viel systemischem Wissen. Wenn der Verfügbar wir dann schaut er sich das kurz (hoffentlich) an - dann weiß man wo das Problem ist und wartet auf den Entwickler der es fixed. Danach geht es in den Retest und wartet erst mal. Also kurze Touch-Time, leichte Vertauschung der Bugs - volle Produktion. In Multiprojektumgebungen wird daher diese Intergraionsphase zum "virtuellen Engpass" - gute Firmen staffeln Ihre Projekte genau so, dass nie mehr wie eine definiert Zahl von Projekten in dieser Phase gleichzeitig ist. Einfach weil die Experten begrenzt sind.
Posted by wmueller at 03. Feb 2014 12:03
|
|
Hm. Tw. hatten wir diese Diskussion bei der Abgrenzung Projekt zu Prozess schon. M.E. ist es nicht richtig, nur bzw. anhand des Verhältnisses Bearbeitungszeit zu Durchlaufzeit die Abgrenzung vorzunehmen. Im Prozessmanagement ist es immer das Bestrebung dieses Verhältnis in Richtung 1 zu bewegen, d.h. die Bearbeitungszeit nähert sich der Durchlaufzeit. Beim idealen Pull- und Flow-Prinzip (1-Piece-Flow) gelingt das auch. Allein aufgrund dieser Tatsache ist mMn das o.g. Verhältnis ein ungeeignetes Kriterium. Das klassische Kriterium der Einmaligkeit bei Projekten ist da ein sehr deutlich schärferes Kriterium. Auch bei der Unabhängigkeit der Teilaufgaben/Aufträge als Unterscheidungsmerkmal bin ich mich nicht sicher. Die Teilprozesse einer Autoproduktion sind sehr stark gekoppelt, zumindest in den Teilergebnissen, eben um das o.g. Verhältnis positiv zu beeinflussen. Natürlich kann eine Bremse unabhängig vom Motor oder Navigationssystem produziert werden. Das Bestreben geht auch hier ganz klar zu Just-in-Time bzw. sogar zu Just-in-Sequence. Schließlich gehört die Überproduktion und Lagerhaltung (mit allen Sekundärfolgen) ganz klar zu den Verschwendungsarten. Auch die Kopplung der Durchläufe (also Bremse A zu Bremse B) ist bei der Serienproduktion ist hoch, weil die knappen Ressourcen auch hier die Menschen und Maschinen sind und durch Rüstvorgänge ganz automatisch eine Kopplung entsteht (aber natürlich nicht innerhalb der Produktion eines einzelnen Autos). Obwohl Projekte und Prozesse in der Detailarbeit etwas Selbst wenn die Einmaligkeit des Projektbegriffs in Form der Innovation auf die Spitze getrieben wird, ist man trotzdem in der Lage und tut auch gut daran, einen Innovationsprozess darunter zu legen. Die entstehende Routine schafft m.E. auch Freiräume für die notwendige Kreativität. Wenn man sich hoch innovative Unternehmen wie Apple ansieht, wird dieser Innovationsprozess im Ergebnis sehr deutlich. Ich wage hier sogar die Aussage, dass dieser Erfolg ohne einen Prozess gar nicht möglich ist. Das Vorhandensein eines Prozesses ist gleichzeitig nicht notwendigerweise damit verkoppelt, dass dieser Prozess nach allen Regeln der Kunst dokumentiert ist. Hier möchte ich bspw. auf die Toyota Kata verweisen. Das ist ein Begriff der innerhalb Toyotas so gar nicht existiert, sondern nur durch die externe Modellierung dessen entstanden ist, was innerhalb von Toyota unbewusster Bestandteil der Kultur ist. Auch hier handelt es sich um inhaltlich einmalige Vorgänge, die trotzdem einen prozessualen Charakter auf der Meta-Ebene haben.
Posted by goetzmueller at 06. Feb 2014 18:10
|
|
Hallo Herr Müller, ist ja nur ein Angebot - das Kriterium Touch-Time zu Lead-Time ist ein systemisches Charakteristikum und sicher nicht das einzige ... ... ich hab einfach noch ein paar ergänzende Anmerkungen: a) Prozessmangement versucht in Richtung 1 zu kommen - sprich Touch-Time = Lead-Time ... im Ideal/Theorie ist das vielleicht auch zu erreichen - aber weder Projekte noch Prozesse schaffen dies. Es gibt zwar die Idee einer "fully balanced line" (entspricht dem idealen 1 Piece Flow) - das ist aber sehr instabil und letzt endlich führen die unvermeidlichen Störungen zu einem schlechteren Durchsatz. Es würde auch nur für eine ideal Produktionslinien gelten und für First-In-First-Out. Alles Ideale die in der Realität nicht auftreten. Wir befassen uns viel mit solchen Themen, da wir nicht nur Projekt- sondern auch Produktionsfirmen beraten - wir sind hier sehr tief drin (z.B. http://speed4projects.net/know-how/forschung/dbr-produktions-simulator/) damit können sie sogar Störungen in einer idealen Produktion simulieren und sehen, wie Störungen durch die Linie propagieren. b) Des weiteren reden wir hier eben nicht über eine Produktionslinie sondern über eine Multi-Auftrag-Produktion. Sprich viele unterschiedliche Aufträge müssen durch ene beliebig komplexe Landschaft von Arbeitsstationen. In solch einer Umgebung haben sie es nicht nur mit Störungen zu tun, sondern die Bearbeitungszeiten auf einer Station sind durch die unterschielichen Aufträge schon unterschiedlich. Sie brauchen daher eine Steuerung, die die Aufträge durch die Produktion leitet. Die genannten Produktionssteuerungen sind einfach, wenn die Touch-Time viel kleiner ist als die Lead-Time, dann kann man Aufträge vertauschen (daher auch die Voraussetzung mit der Vertauschbarkeit) - wenn nicht muss man mit Projektsteuerungen arbeiten und die sind kompliziertert. c) JIT und JIS sind ja auch große Fortschritte gewesen ... wenn man sich die realen touch-time/leat-time Verhältnisse anschaut ist man aber immer noch weit weit unter 10%. Auch in JIT brauchen sie Puffer und selbst bei VMI (Vender Managed Inventory) müssen sie diese Managen um Störungen in der Lieferkette auszugleichen. d) Natürlich kann man von einem Projektmanagementprozess reden. Typischerweise ist zum Glück das Projektmanagement nicht auf der kritischen Kette sondern eine Unterstützungsfunktion. Daher fällt es nicht auf, dass die Bearbeitungszeit/Durchlaufzeit von Artefakten in diesen Prozessen eben auch <10% ist. Schauen sie sich einfach nur die Initialisierung von Projekten an. Netto könnte sowas in wenigen Stunden/Tagen erledigt sein. In der Realität von Unternehmen dauert es min. Wochen wenn nicht Monate - sprich viel kleiner 10%. ... um was es mir geht ist einfach folgendes: Je nach Situation kann man in einem Umfeld sein in dem das Verhältnis von Touch-Time zu Lead-Time <10% ist und die Vertauschbarkeit weitgehend geben ist. Dann kan man die Produktionssteuerungen super einsetzen. Sehr sehr sehr oft ist das bei Prozessen der Fall. Wenn nicht dann sollte man bei den Projektsteuerungen schauen. Je nachdem welche Steuerung man wählt erhält man aber auch die Systemeigenschaften. Produktionssteuerungen führen zu langen Durchlaufzeiten. Wenn man das alles weiß sieht man ggf. auch, dass Teile eines Projektes (z.B. die End-2-End-Testphase) gar keinen Projektcharakter hat sondern wieder wie ein Prozess modelliert werden kann. In diesem Fall können sehr einfache Steuerungen wie eine Drum-Buffer-Rope zum Einsatz kommen - perfekt weil billiger. Wenn man die Kriterien und Steuerungen nicht kennt kann es passieren, dass man hier Chancen vergiebt. cu Wolfram p.s.: es sind vor allem die alten Projektmanagementschulen, die die Prozesse und Phase kennen ... die werden interessanterweise gerade von den neuen agilen einfach überholt - zoooooom zoooooom
Posted by wmueller at 06. Feb 2014 22:14
|
|
Im Kern bin mit den Aussagen durchaus einverstanden. Bis auf die Ursache-Wirkungskette, dass Produktionssteuerungen zu langen Durchlaufzeiten führen (jede Produktionssteuerung hat immer auch das Bestreben die Durchlaufzeit zu optimieren=reduzieren) und den Schwellwert von 10 %, an dem Produktion beginnen soll. Das erscheint mir als willkürlich gesetzte Schwelle für eine ziemlich digitale Entscheidung. Zumal eben auch Produktionen das Bestreben haben, die Durchlaufzeit zu reduzieren. Damit schließt sich in meinen Augen ein Schwelle der Durchlaufzeit als Entscheidungskriterium ganz automatisch aus. Eine Systemgröße als Entscheidungskriterium für die Einordnung des Systems in Kategorien zu wählen, wenn beide Systemkategorien nach der Optimierung der Größe streben, ist systemtheoretisch nicht möglich. Das wäre genau so, wie wenn ich sage, ein Fortbewegungsmittel wird mittels der Geschwindigkeit in die Kategorien Fahrzeug oder Flugzeug eingeordnet, wenn die Geschwindigkeit gleichzeitig ein (zu optimierendes) Leistungsmerkmal des Fortbewegungsmittels ist.
Posted by goetzmueller at 08. Feb 2014 08:56
|
|
ok - klar - natürlich ... ... die 10% sind voll künstlich - es ist mehr so zu verstehen, wenn man unter 10% ist ist man sicher bei den Produktionssteuerungen bei >20% sollte man über Projektsteuerungen nachdenken. ... und ich bin auch voll bei Ihnen, dass die Prouduktionssteuerungen versuchen in Richtung höhere Werte zu kommen. Wir fangen oft mit Produktionen an, die z.T. unter 1% liegen - am Schluß kommen wir oft auf 20% - dann wird es aber eben eng mit den Puffern und der Vertauschbarkeit der Aufträge (nicht der Arbeitsschritte in den Aufträgen). Was die Produktionssteuerungen machen um schneller zu werden ist of mit "protective capacity" zu arbeiten z.B. Rapid-Response lanes o.ä. damit kann man nochmal einen drauf legen. Im mittel wird es aber ab ca. 20% einfach eng - dann machen sich die Abhängigkeiten und die Streuungen bemerkbar und die muss man dann halt managen. Wolfram p.s.:
Posted by wmueller at 08. Feb 2014 09:56
|
|
Hallo zusammen, das Thema begegnet mir seit Jahren immer wieder aufs Neue. Ich bin mir nicht sicher ob all die Abgrenzungen "Projekt vs X" hilfreich sind. Ich persönlich habe für mich eine Liste von Kriterien aufgestellt. Wenn ein "Vorhaben" diese Kriterien vollständig erfüllt, bezeichne ich es als Projekt. Ich verzichte in der Formulierung der Kriterien ganz bewusst auf die üblichen Termini.
Das ist sicher keine umfassende Projektdefinition, allerdings fallen - wenn man die Kriterien ernstnimmt - gefühlte 90% der so genannten Projekte schon durchs Raster.
Posted by ehuber at 11. Feb 2014 08:17
|
|
Hallo zusammen, mir kommt nochmal ein Gedanke. Vielleicht ist es hilfreich eine ähnlich naive Liste von Kriterien für Prozesse aufuschreiben. Ein Prozess ist durch folgendes gekenzeichnet:
LG Eberhard
Posted by ehuber at 15. Feb 2014 07:43
|
|
Warum darf eigentlich eine Projekt kein Prozess sein? Kann es nicht so sein, dass lediglich die Begrifflichkeiten und deren historische Ordnung immer öfter nicht mehr zur angetroffenen Umgebung passen? Mein Eindruck ist, dass der Begriff „Projekt“ immer dann auftaucht, wenn die vorhande, Lösungsorganisation nicht zum Problem passt. „Projekt“, ist am Anfang doch oft nur der Versuch es einfach anders zu machen. Unter diesem Gesichtspunkt passt es dann meistens nicht zu den klassischen Kriterien welche ein „echtes“ Projekt auszeichnen. Wenn jetzt nach bestimmten Regeln versucht wird zwischen Projekt und nicht „Projekt“ zu trennen, ist zwar die ursprüngliche Ordnung wieder hergestellt, aber ob es auch der Problemlösung dient ist zumindest fraglich. Ich denke auch, dass es ein sehr guter Ansatz ist, zuerst das Problem in den Mittelpunkt zu stellen. Die zugehörige Frage ist dann meines Erachtens aber noch nicht Projekt ja oder nein. Sondern: Geht es um ein Problem oder eine Störung? Um die Frage auch beantworten zu können hat sich eine Definition in ITIL ganz gut bewährt. Ein Problem ist etwas für das Lösung und Ursache noch unbekannt sind. Eine Störung ist etwas mit bekannter Ursache und bekanntem Lösungsweg. Mit diesen Kriterien sollte es klappen, dass ein Problem mit guter Wahrscheinlichkeit teil eines komplexen Systems ist. Eine Störung Teil eines einfachen bis komplizierten Systems ist Die Lösungsorganisation oder der Lösungsprozess sollte dann dem System gerecht werden. Wenn Projektmethoden passen, gut. Wenn Produktionsmethoden passen auch gut. Bei größeren Aufgaben (ob nun Projekt oder Produktion) sind sicher abwechselnd Probleme und Störungen zu bearbeiten. Bzw. abwechseln komplexe oder komplizierte Themen. Wird diesen Systemübergängen zu wenig Beachtung zuteil wird es am Ende nicht wirklich klappen. Ich denke, worauf es ankommt, ist zu erkennen welche Systemübergänge gerade vorliegt um die passenden Handlungsmuster anwenden zu können. Es kann dann so Etwas wie ein dynamisches Gleichgewicht entstehen. Etwa wie ein Schifahrer im Tiefschnee, der sich den wechselnden Schnee und Geländebedingungen dynamisch anpasst. Wenn er / sie es gut kann gibt es eine saubere und gleichmäßige Spur.
Posted by pmad at 15. Feb 2014 08:46
|
|
Bei dieser spezifischen Betrachtung bin ich ganz bei dir, aber wenn wir PM-Methoden und Werkzeuge beurteilen wollen, brauchen wir eine spezifische Betrachtung und genau darum geht es mir mit dieser begrifflichen Spitzfindigkeit. Bei Prozessen stehen eher Optimierung und Fehlerbehebung im Vordergrund, bei Projekten (in einem engeren Sinn) hingegen kreative Problemlösung. Selbstverständlich brauchen wir beides und eines ist nicht wichtiger oder besser als das andere, aber wir sollten vielleicht doch mehr schauen, welchen Charakter unsere Problemstellung hat und danach das richtige Werkzeug auswählen. Wenn wir anfangen alles als Projekt zu bezeichnen und dann auch allem mit Projektmethodiken begegnen, dann treiben wir nicht nur Unsinniges, sondern das geht auch auf Kosten der Akzeptanz dort, wo die Methodiken sinnvoll eingesetzt wären. Mein Eindruck in der Praxis ist durchaus der, dass mit dem inflationären Gebrauch des Projektbegriffs genau das passiert.
Posted by bschloss at 15. Feb 2014 13:12
|
|
Noch eine Ergänzung der einfachen Kriterien: "In einem Prozess können Kennzahlen definiert werden."
Posted by ehuber at 18. Feb 2014 14:26
|
|
Und Eberhard Huber hat unsere Diskussion auch in seinem Blog aufgegriffen: Prozess, Projekt, komplex und die Kunst …
Posted by bschloss at 18. Feb 2014 18:30
|
|
Kennzahlen kann (muss) ich auch in einem Projekt festlegen (Sonst hätte Tom De Marco unrecht: you can't control what you can't measure) Eines (wenn nicht das) wesentliche Merkmal nach meiner Meinung ist die Einmaligkeit des Vorhabens (Produktionstechnisch: Losgröße 1),
Posted by dieter.stadelmaier at 18. Feb 2014 22:51
|
|
Einverstanden bzgl. Kennzahlen und Einmaligkeit. Losgröße 1 alleine ist aber kein Projektmerkmal. Nach Losgröße 1 strebt auch (fast) jeder Produktionsprozess. Nur wenn Losgröße und Losanzahl gleich 1 ist, könnte man von einem Projekt sprechen.
Posted by goetzmueller at 18. Feb 2014 23:17
|
|
d'accord
Posted by dieter.stadelmaier at 18. Feb 2014 23:36
|
|
Hallo Herr Müller, hallo Dieter dem kann ich auch zustimmen LG Eberhard
Posted by ehuber at 19. Feb 2014 07:02
|
|
Hallo, bzgl. der "Einmaligkeit" von Projekten ... das ist auch kein Alleinstellungsmerkmal mehr! Wenn man sich in den Bereich der Innovationstechniken begibt (TRIZ, IDEO, Design-Thinking) - sind das allesamt Prozesse! Es fällt oft der Begriff Innovationsprozess. Sprich auch Prozesse können einmaliges produzieren - nämlich viel viele kleine Ideen - von denen dann eine eine Innovation wird. und auch beides der Prozess und das Projekt sind mit Kennzahlen verbunden - weil eben beides "geregelte Systeme" sind ... die Kennzahlen für ein Projekt sind hinreichend bekannt - sehr gut ist z.B. Fortschritt auf der kritischen Kette zu Pufferverbrauch und jedes Projekt kann als Losgröße 1 betrachtet werden. Wenn man dann nur ein Projekt hat dass unabhängig ist von allem anderen (sehr selten) dann hat man Loszahl 1 und Einzelprojektmanagement (Projektcharakter) und wenn es mehr werden die um die gleichen Ressourcen kämpfen dann hat man Multiprojektmanagement (Prozesscharakter) also alles keine wirklich guten Kriterien um die beiden klassen von Systemen zu unterscheiden - und nur Begriffe die helfen zu unterscheiden sind für die Definition und Beschreibung des Einsatzgebietes wirklich nützlich. Ich kann nur nochmal das Verhältnis von Bearbeitungszeit zu Durchlaufzeit anbieten. Am Montag hab ich hierzu einen Vortrag auf dem 9. BPM-Club-Treffen in Dresden gehalten ... die Präsentation dazu gibt es hier ... die Präsentation und Diskussion kam extrem gut an. Mit reinrassigen Prozessmanagern über Projekte zu diskutieren war ein wirkliches echtes Vergnügen. Die Prozessmanager haben den Prozessleuten einfach ein paar Erkenntnisse voraus - z.B. "Laste den Engpass nie über 80% hinaus aus - sonste bekommst du Probleme" und das gilt für Multiprojektmanagement 1:1 cu Wolfram p.s.: ich halte es für eine Legene, dass man überhaupt etwas (einigermaßen interessantes) steuern kann - eigentlich sprechen wir von "etwas regeln" - also tatsächlich etwas messen, wenn es nicht zu dem passt was wir wollen dann nachjustieren u.s.w. bis es passt. "Steuern" heißt ich weiß genau wie das system reagiert und verändere die Eingangsparameter so dass das richtige rauskommt. Ich bin aber auch mehr für "führen" - sprich in unterschiedliche "leads" gehen (Faszination, Entscheidung, Prozess) und es den umliegenen zu überlassen hier zu "folgen" (freiwillig) - da musst man dann nicht mehr messen ... dazu muss man aber auch etwas haben, dass fasziniert und man mus entscheidungen treffen und auch innovative Prozesse designen (und da schließt sich der Kreis wieder
Posted by wmueller at 19. Feb 2014 07:24
|
|
Hallo Wolfram, wenn du Innovationsprozesse ansprichst, würde ich die wieder auf einer Metabene sehen. Das sind idealtypische Prozesse, die ein Projekt durchläuft, aber dennoch käme niemand auf die Idee diese für ein einzelnes Projekt beliebig zu optimieren, während das was du z.B. mit dem Critical Chain Ansatz treibst schon sehr spezifische Prozessoptimierung darstellt. Gruß Bernhard
Posted by bschloss at 19. Feb 2014 07:35
|
) - ja ich denke der Aspekt ist wichtig! Ich würde aber hier von Innovationsgrad sprechen