Projektarbeit in allen Facetten

Schlagwort: Definitionen

Prozess, Projekt, komplex und die Kunst …

Prozess, Projekt, komplex und die Kunst …

Posted on by Dr. Eberhard Huber
An mehreren Stellen wird zurzeit über obige Begriffe diskutiert. Auf openPM steht die Abgrenzung zwischen Prozess und Projekt im Fokus, bei Stefan Hagen geht es um große, komplexe Vorhaben, die jenseits eines Projekthorizontes liegen. Pauschalisierungen wie »Alles ist ein Projekt«, »Es gibt keine Projekte«, »Alles ist ein Prozess« helfen nicht weiter. Ein kritischer Blick auf das zu bewältigende Vorhaben und eine ordentliche Verwendung von Begriffen ermöglichen hingegen einen sinnvollen Einsatz von Methoden. Ein triviales Beispiel: Wenn ich zwei Holzstücke verbinden will, hängt die Wahl des Werkzeugs von der Art der Verbindungselemente ab. Werden die Bretter vernagelt, verschraubt oder verleimt? Je nach dem wäre ein Hammer, ein Schraubendreher bzw. ein Pinsel nebst Klemme erste Wahl. Sicher – ein Nagel kann auch mit dem Griff des Schraubendrehers eingeschlagen werden – optimal ist das aber nicht. Ein etwas besseres Beispiel aus der Welt der Automobil-Produktion: Wenn ich ein Mittelklasse-Fahrzeug kaufen möchte, kann ich einen Katalog, eine Ausstattungsliste und eine Preisliste einsehen und mein neues Auto konfigurieren und bestellen. Der Preis ist festgelegt, der Liefertermin ist bekannt und wird in der Regel eingehalten. Das ist möglich, weil Produktion und Lieferung eine Kette von wohldefinierten Prozessen sind, die in sehr ähnlicher Weise vielfach und reproduzierbar ablaufen. In der automobilen Luxusklasse wird das schwieriger. Wenn sich die Extrawünsche auf eine ausgewählte Maserung des Holzes am Armaturenbrett, eine bestimmte Narbung des Sitzleders, anatomische Anpassung des Sitzes und vieles mehr erstrecken, bekommt der Prozess allmählich Projektcharakter. Es ist z.B. zu Beginn unklar, ob das speziell genarbte Lederstück in ausreichender Größe für den noch nicht vermessenen Sitz vorhanden ist. Es wird geplant, geschätzt und gehofft, dass der anvisierte Liefertermin (Plan) eingehalten wird. Komplex und noch schlechter planbar wird es, wenn der Kunde den Hersteller wählt, aber eine Individualfertigung eines Einzelstückes verlangt, das noch nicht einmal in Konzeptform existiert. Es soll ein »Mercedes SLR« mit Elektroantrieb werden, der ähnliche Fahrleistungen wie sein 600 PS starkes Vorbild mit Verbrennungsmotor hat. Das ist kein fiktives Beispiel. Dieser Elektro-SLR wird inzwischen gebaut. Er besitzt für jedes Rad einen eigenen Motor, eine gänzlich neue Fahrwerksteuerung und Bremsanlage und vieles mehr, was es zuvor noch nie gab. Die Sinnhaftigkeit solcher Elektrofahrzeuge möchte ich an dieser Stelle nicht diskutieren. Es geht mir darum, dass der Weg von der Idee bis zur ersten Fahrt lang, einmalig, komplex und nahezu unplanbar war. Auf diesem Weg mag es kurze Prozesselemente und Teilprojekte gegeben haben. Gesamt betrachtet ist es aber unsinnig von einem Prozess oder EINEM Projekt zu sprechen. Merke! Selbst im produzierenden Gewerbe ist nicht alles Prozess und »Nicht alles was neu ist lässt sich angemessen als Projekt betrachten«. Damit schließt sich der Kreis zur Ãœberschrift: »Prozess, Projekt, komplex …«. Die Ergänzung lautet »… und die Kunst der Unterscheidung«. Hierzu habe ich meine schon früher beschriebenen Projekt-Kriterien ergänzt. Bei der Anwendung der Kriterien setze ich voraus, dass es Rollen wie Auftraggeber und Lieferant und eine nennenswerte Anzahl von Beteiligten gibt. Für Ein-Personen-Aufträge lohnt sich m.E. die Diskussion nicht. Prozess
  • Die Arbeitsabläufe sind schon vor Beginn dokumentiert.
  • Vorgang wird regelmäßig mit identischen Arbeitsschritten wiederholt.
  • Das Arbeitsergebnis ist reproduzierbar.
  • Die Definition von Kennzahlen ist möglich.
Projekt
  • Das Vorhaben wurde in dieser Form noch nicht durchgeführt.
  • Es existiert ein in Worten beschreibbares Ziel bzw. Arbeitsergebnis.
  • Es existiert ein Zeithorizont zur Erstellung des Arbeitsergebnisses.
Mehr und komplexer als Projekt
  • Ziel und Arbeitsergebnis sind nur grob beschreibbar.
  • Zeithorizont ist unabsehbar.
Fortsetzung des Automobil-Beispiels: Der Bau des Elektro-Super-Sportwagens könnte noch als Serie von Entwicklungsprojekten betrachtet werden. Das Ende der Projektbegriffs ist aber spätestens dann erreicht, wenn angesichts der abnehmenden Öl-Fördermengen das gesamte Unternehmen auf regenerative Antriebskonzepte umgestellt werden soll. Derartig tief greifende Veränderungen stehen in den nächsten Jahren nicht nur in der Automobilbranche an. Fortsetzung folgt.  

Projekt oder Gedanken über ein unpassendes Etikett

Posted on by Dr. Eberhard Huber
Ãœber Etikettenschwindeleien im Projektgeschäft hatte ich schon letzte Woche geschrieben, sie sind auch Thema des heutigen Cartoons. Darüber hinaus möchte ich den Gedanken von Jens Hofmann aufgreifen, der die Fragestellung ob der Projektbegriff in einer agilen Welt überhaupt sinnvoll ist diskutiert hat. Ich stimme ihm zu, dass sich der Projektbegriff nicht überholt hat, ich kann aber auch die radikale Gegenposition, dass der Projektbegriff überflüssig sei ein Stück weit nachempfinden. Warum? Der Projektbegriff wird m.E. bis zur Schmerzgrenze und darüber hinaus überstrapaziert. Projekte wohin man schaut, Projektleiter, Teilprojektleiter, Projektmanager, Projektmanagement-Büros, PM-Systeme und vieles mehr geistern durch die Organisationen und Firmen und versuchen Probleme zu lösen, die es ohne die Pseudoprojekte nicht gäbe. Ist das übertrieben? Ich möchte das Problem gewissermaßen aus der Froschperspektive der ursprünglichen Definition eines Projektes angehen und stelle die Frage: “Was ist ein Projekt?” Ein Projekt hat folgende Merkmale:
  1. ein in Worten beschreibbares Ziel oder Arbeitsergebnis,
    das in dieser Form noch nicht existiert,
  2. einen Termin an dem mit den Arbeiten begonnen wird,
  3. einen Termin an dem das Arbeitsergebnis vorliegen soll,
  4. mindestens zwei Personen, die zum Arbeitsergebnis beitragen,
  5. sowie mindestens eine weitere Person,
    an die das Arbeitsergebnis geliefert wird.
Diese Minimaldefinition ist gewissermaßen eine Konkretisierung der in der EN ISO 9000:2005 enthaltenen Definition:
Ein Projekt ist ein einmaliger Prozess, der aus einem Satz von abgestimmten und gelenkten Tätigkeiten mit Anfangs- und Endtermin besteht und durchgeführt wird, um unter Berücksichtigung von Zwängen bezüglich Zeit, Kosten und Ressourcen ein Ziel zu erreichen, das spezifische Anforderungen erfüllt.
Die nebenstehende Mindmap fasst die Merkmale zusammen und bezieht den Aspekt der temporären Organisation mit ein. Mit dieser Definition wird deutlich, dass der Begriff weiterhin sinnvoll ist. In einer Diskussion auf g+ wurde kürzlich ein eindrückliches Beispiel genannt. Eine Stadt hat Jubiläum, an einem Termin X soll ein Fest mit verschiedenen Veranstaltungen im Stadtgebiet verteilt stattfinden. In der Vorbereitung sind Vertreter der Stadt, von Vereinen, und Bürger beteiligt. Die Aufgabenpalette reicht von der Beschaffung von mobilen Toiletten, über Vertragsgestaltung mit Künstlern, Absperrung von Parkplätzen, Ticketverkauf bis hin zur Anlieferung von Strohballen für ein historisches Bogenturnier. Es werden Landwirte, Juristen, Kaufleute in der Vorbereitung benötigt … und zu guter Letzt begrenzt der Gemeinderat das Budget. Für dieses Vorhaben fällt mir kein besserer Begriff als “Projekt” ein. Zudem liegt auf der Hand, dass eine temporäre Organisation benötigt wird, die neben der normalen Organisation einer Stadtverwaltung arbeitet. Das normale Arbeitsaufkommen einer Stadtverwaltung ist im Jubiläumsjahr schließlich genauso hoch wie in allen anderen Jahren. Wenn alle “Projekte” diesen Kriterien genügen würde wäre die Welt übersichtlicher. Ich erlebe es allerdings immer wieder, dass alles was irgendwie nach Veränderung und Neuerung riecht reflexartig als Projekt bezeichnet wird. Die Wartung einer bestehenden Software, die regelmäßig weiter entwickelt wird ist kein Projekt auch wenn ein ganzes Team an der Software entwickelt. Vielleicht genügt ein großer Release-Sprung den Anforderungen eines Projektes. Der Wechsel von 5.1.7 auf 5.1.8 ist aber kein Projekt. Die Beschaffung von Umzugskartons und Büromöbeln ist kein Projekt – vor allem nicht in einer Organisation in der Umziehen zum Tagesgeschäft gehört. Eine umfangreiche Aufgabe, die sich mittels vieler gleichartiger Arbeitsschritte vollständig parallelisieren lässt ist kein Projekt. Eine Aufgabe, die kein Ende kennt ist ebenfalls kein Projekt. Auf dem Hintergrund kann ich agil arbeitende Teams gut verstehen wenn sie sich gegen den Projektbegriff wehren, vor allem wenn sie verpflichtet werden klassische PM Aufgaben als Pflichtübung mitzuerfüllen. Ich habe mehr als ein Dauer-Entwicklungsteam kennen gelernt, das regelmäßige Berichte mit unsinnigen Gantt-Diagrammen und Ampeln abliefern musste. Die Frage, die sich mir stellt, ist: “Warum wird dieser notorische Etikettenschwindel betrieben?”. Hierzu fallen mir eine ganze Reihe von Verdachtsmomenten ein:
  • Mitarbeiter werden mit Pseudo-Titeln angefüttert um mehr Aufgaben zu erledigen. Es werden Aufgaben bei einem Mitarbeiter konzentriert, das Etikett Projekt wird aufgeklebt und der Mitarbeiter zum Projektleiter ernannt.
  • Organisatorische Änderungen werden aus unterschiedlichen Gründen verschleppt und nicht umgesetzt. Nicht zugeordnete Mitarbeiter werden in “Projekten” geparkt. Am Ende wird dies zum Prinzip erhoben und eine Projektorganisation definiert.
  • Verschleierung von Verantwortungen: Statt Entscheidungen zu treffen werden strategische Projekte aufgesetzt, die gewissermaßen Entscheidungsvarianten ausprobieren. Erweisen sich alle Ideen als schlecht hat man in Gestalt des Projektleiters ggf. einen Schuldigen zur Hand.
  • Umwidmen von Tagesgeschäft in Projekte um Defizite in Prozessen und Organisation zu kaschieren.
Den letzten Punkt möchte ich provokativ ergänzen und erläutern. Im IT-Bereich wird sehr häufig von Projekten gesprochen obwohl eigentlich in vielen Fällen ein fundamentales Interesse bestehen müsste keine Projekte sondern Standard-Installationen mit so wenig wie möglich Anpassungen durchzuführen. Echte Individualentwicklungen, die am ehesten die Merkmale eines Projektes erfüllen, sind auf jeden Fall weniger häufig als es die Unmengen von Pseudoprojekten vermuten lassen. Es kommt sogar vor, dass Projekte durchgeführt werden weil die bereits vorhandene Lösung nicht mehr gefunden wird  1. Dass nicht jede Organisation perfekt funktioniert liegt auf der Hand. Dass Umwege gesucht werden um die Aufgaben zu lösen und die Umwege als Projekte bezeichnet werden, könnte man auch entspannt als “gesunden Pragmatismus” bezeichnen. Wenn man die Umwege pragmatisch beschreiten dürfte wäre dagegen wenig einzuwenden. De Realität sieht jedoch anders aus. Es wird versucht den vielen Pseudo-Projekten mit den ungeeigneten Methoden zu Leibe zu rücken. Viele gute Ansätze werden abgenutzt wenn nicht gar vergeudet um Probleme zu lösen, die es nicht gäbe wenn der Etikettenschwindel aufhören würde. Multiprojektmanagement, mehrdimensionale Resourcenplanung, Aufteilung von Arbeitszeiten einzelner Mitarbeiter über mehrere Projekte hinweg und vieles mehr wäre unnötig wenn man sich an die zwei folgenden Grundsätze halten würde:
  • nur echte Projekte machen
  • jede( r ) nur ein Projekt
Zu 100% werden sich diese Grundsätze nie einhalten lassen aber es lohnt sich den Weg zu beschreiten. Wenn ein Handwerker einen Nagel mit dem Griff eines Schraubendrehers einklopft liegt die Unsinnigkeit auf der Hand. Defiziten in der Organisation mit Verbesserung von Projektmanagement-Methoden entgegenzutreten ist in meinen Augen ähnlich unsinnig  2. Wenn ich die bisher geäußerten Gedanken in eine Grafik fassen wollte sehe ich drei Ecken: Projekte, Stabile Organisationen und Organisationen im Wandel. Dass von stabilen Organisationen Projekte gestartet werden können ist trivial. Spannend ist der Bereich zwischen sich im Wandel befindlichen Organisationen und Projekten. Wie schon geschrieben ein simples Ausdehnen von Projekt-Werkzeugen und Methoden auf die Organisation halte ich nicht für geeignet. Was sich hinter dem Fragezeichen verbergen könnte ist noch nicht zu Ende formuliert wird aber im Laufe der Woche folgen.
  1. Das mit der unauffindbaren Lösung ist leider kein Witz sondern eine konkrete Erfahrung. Im fraglichen Fall wurde ein Teilprojekt für Datenbeschaffung und Datenerfassung aufgesetzt. Es handelte sich hierbei um Daten, die bereits erfasst wurden, die Organisation aber nicht mehr in der Lage war zu ermitteln wo die Daten gespeichert wurden. Ein Teil der Daten wurde dann von noch vorhandenen ausgedruckten Dokumenten abgetippt. [↩]
  2. Ergänzung zu Anspruch und Wirklichkeit. Ich selbst habe auch schon Nägel mit dem Griff eines Messers eingeklopft. Das ging irgendwie und ist im Einzelfall vielleicht sogar schneller als das Herbeiholen eines Hammers. Als grundsätzliches Arbeitsprinzip für das Einschlagen von Nägeln taugt das aber nicht. Dann ist es besser dafür zu sorgen, dass ein Hammer in der Nähe ist. [↩]
Manager, Unternehmer und Projektleiter

Manager, Unternehmer und Projektleiter

Posted on by Dr. Eberhard Huber
Ein Stück weit beziehe ich mich auf die Beiträge von Stefan Hagen im Projektmanagement-Blog (Beitrag 1, Beitrag 2). Ausgangspunkt der dortigen Diskussionen war die provokante und verkürzte These dass, Projektmanagement = Management wäre. Dementsprechend ausführlich und auch widersprüchlich war dann die Diskussion. Im Nachgang hat mich die Frage beschäftigt wie es zu der durchaus vorhandenen Begriffsverwirrung kommt. Ich sehe dies inzwischen als Resultat einer Ãœberhöhung des Manager-Begriffs. Der Manager ist überspitzt formuliert der Leitungsträger und Heilsbringer der Leistungsgesellschaft. Projekte werden heute nicht mehr geleitet sondern gemanaged, also brauchen wir Projektmanager, die genauso wichtig sind wie richtige Manager. Unternehmerisch denken müssen beiden, also wird der Unternehmer auch noch in den Topf geworfen. Genug der Ironie – die drei wesentlichen Akteure sind jetzt benannt:
  • Unternehmer
  • Manager
  • Projektleiter
Dass es Ähnlichkeiten der Tätigkeiten und Anforderungen an diese Akteure gibt ist klar. Ich möchte aber bewusst eine Abgrenzung der Begriffe versuchen. Für die Abgrenzung verwende ich unter anderem folgende Aspekte:
  • Der Unternehmer trägt Gesamt-Risiko und wirtschaftliche Verantwortung.
  • Unternehmer beschäftigen Manager.
  • Ein bestehendes Geschäft muss gesteuert und optimiert werden und sollte so lange es der Markt erlaubt profitabel sein.
  • Projekte sind in größere Kontexte eingebettet.
  • Projekte haben eine begrenzte Laufzeit.
  • Ein Projekt liefert ein Ergebnis an den Auftraggeber.
  • Ein Projekt ist nicht profitabel, lediglich aus dem Ergebnis des Projektes lässt sich (manchmal) ein profitables Geschäft machen.
Risiko und wirtschaftliche Verantwortung sind für mich der wesentliche Unterschied (und das größte Missverständnis) zwischen einem Unternehmer und einem Manager. Die mächtigsten Manager, die Milliarden Umsätze verantworten selbst Millionen-Gehälter beziehen tragen keine persönliche wirtschaftliche Verantwortung. Ein guter Manager hat in seinem Vertrag eine Klausel stehen, dass der Arbeitgeber eine Versicherung1 abschließt, die für die wirtschaftlichen Schäden, die er eventuell anrichtet aufkommt. Der klassische Unternehmer steht jedoch auch mit seinem Privatvermögen in der Verantwortung. Der Manager optimiert im Auftrag des Unternehmers ein bestehendes Geschäft. Der Unternehmer hat das Geschäft aufgebaut und baut ggf. weitere Geschäfte auf. Der Unternehmer arbeitet kreativer, der Manager steuernd und kontrollierend. Controlling ist der Partner des Managers nicht des Unternehmers. Aus Controlling Sicht wären viele Unternehmen gar nicht erst entstanden. Und wo verstecken sich das Projekt und der Projektleiter? Die kleinen Mosaiksteinchen werden leicht übersehen. Der Projektleiter ist immer (!) in einen größeren Kontext eingebettet. Er erhält einen Auftrag vom Unternehmer oder Manager. Auch wenn Projekte häufiger, größer und wichtiger werden bleiben Sie doch immer Teil eines größeren Ganzen. Der Projektleiter liefert ein Ergebnis, danach wird das Projekt beendet. Das Projekt kann in gewisser Weise die Früchte seiner Arbeit nicht ernten. Projekte können zwar Bausteine für den Aufbau eines neuen Geschäftes sein sind aber nicht das neue Geschäft selbst. Dieses Kleinreden von Projekten aus dem Munde eines Projektleiters mag sich seltsam anhören. Ich bin jedoch der festen Ãœberzeugung, dass ein “größer reden” der Projekt-Disziplin nicht weiter hilft. Dass sich die drei Aspekte (Unternehmen, Management, Projekte) überlappen und Gemeinsamkeiten haben liegt auf der Hand, man sollte aber gelegentlich den Blick schärfen und auf die Ecken des Diagramms schauen und nicht in der Mitte einen Einheitsbrei anrühren.
  1. http://www.finanzberatung-versicherungsvergleiche.de/vergleich_sachversicherungen/managerhaftpflicht_D&O_haftpflicht_versicherung.htm [↩]
Minimaldefinition eines Projektes

Minimaldefinition eines Projektes

Posted on by Dr. Eberhard Huber
Mit der Frage Wann ist ein Projekt (k)ein Projekt? hatte ich mich vor einiger Zeit schon ausführlicher befasst. Bei der Vorbereitung einer Untersuchung bin ich erneut auf diese Frage gestoßen. Die damals erstellte Mindmap fasst zwar wesentliche Merkmale eines Projektes zusammen liefert aber keine Kriterien, die eine Abgrenzung zu “projektartigen Vorhaben” ermöglichen würde. Ãœber Begriffe lässt sich zwar trefflich streiten und manchem mag dies als Erbsenzählerei erscheinen – für eine wissenschaftliche Auseinandersetzung mit dem Themen “Projekte / Projektleitung / Projektmanagement” ist eine saubere Abgrenzung der Begriffe jedoch notwendig. In diesem Sinne möchte ich eine Reihe von minimalen Merkmalen nennen, die vorhanden sein sollen um von einem Projekt sprechen zu können. Ein Vorhaben nennen wir dann ein Projekt, wenn es folgende Merkmale aufweist:
  1. ein in Worten beschreibbares Ziel oder Arbeitsergebnis, das in dieser Form noch nicht existiert,
  2. einen Termin an dem mit den Arbeiten begonnen wird,
  3. einen Termin an dem das Arbeitsergebnis vorliegen soll,
  4. mindestens zwei Personen, die zum Arbeitsergebnis beitragen,
  5. sowie mindestens eine weitere Person, an die das Arbeitsergebnis geliefert wird.
Wenn ich beispielsweise für mich selbst etwas programmiere – so schwierig das Problem auch sein mag – ist es kein Projekt, da ich Auftraggeber und Projektmitarbeiter in einer Person wäre. In der IT Branche gibt es gelegentlich Aufträge, die vollständig von einer Person abgearbeitet werden. Solche Aufträge weisen bis auf die Personenzahl (Punkt 4) alle Merkmale eines Projektes auf und erfordern ein straffes Management. Hier handelt es sich aber eher um Selbst-Management als um Projektmanagement, das immer auch einen Aspekt der Koordination verschiedener Mitarbeiter enthält. Auch die W-Fragen des Projektmanagements ergeben erst dann einen Sinn, wenn ein Vorhaben oder Auftrag diese Merkmale aufweist. Dieser Text ist unter Creative Commons BY NC ND (Namensnennung – Nicht Kommerziell – Keine Bearbeitung) lizenziert. Er ist Teil des Buchprojekts “Menschen im Projekt”. Er gehört zum Abschnitt 3A, siehe Mindmap zu Inhalt und Struktur.
© pentaeder 2019 / 2020