Projektmanagement für Ingenieure || Projektorganisation

4 Projektorganisation

„Organisation besteht darin, weder den Dingen ihren Lauf noch den Menschen ihren Willen zu lassen.“ (Helmar Nahr) Dieses Kapitel zeigt Ihnen, wie der Aufbau und der Ablauf von Projekten mit Hilfe von einigen Grundregeln organisiert werden kann. Zunächst werden die verschiedenen Aufbauorganisati-onsformen vorgestellt, sie lernen deren Vor- und Nachteile kennen und sie können so anhand weniger Kriterien beurteilen, welche Form in einem konkreten Projekt am besten geeignet ist. Der zeitliche Ablauf von Projekten kann durch Teilprojekte, Arbeitspakete, Projektphasen und Meilensteine gegliedert werden. Sie lernen den sequentiellen Ablauf mit strikter Phasenab-grenzung als Standard-Ablaufmodell und das Wasserfallmodell als seine bekannteste Realisie-rungsform kennen. Sie werden sehen, wie ein Ablauf mit Hilfe des Spiralmodells iterativ orga-nisiert werden kann und wie sich die Projektlaufzeit durch Parallelisierung, z. B. in Form des Simultaneous Engineering verkürzen lässt. Zur Regelung der Informationsflüsse in einem Projekt werden zunächst die Zusammenhänge zwischen Information, Kommunikation und Dokumentation aufgefrischt. Dabei sollen Sie die Bedeutung unterschiedlicher Informations-, Kommunikations- und Dokumentenarten kennen lernen. Danach soll die Aufgabe eines allgemeinen Informationsmanagements in Unternehmen bewusst gemacht werden, um darauf aufbauend auf die Besonderheiten der Informationshand-habung in Projekten einzugehen. Abschließend werden die verschiedenen Dokumentenarten vorgestellt, die im Projekt vor-kommen und die Aufgabe eines Projektmanagement-Handbuchs wird erläutert.

Nach der Bearbeitung des Kapitels sind Sie in der Lage, die verschiedenen Aufbauorganisationsformen von Projekten innerhalb eines Unter-

nehmens zu beschreiben und im konkreten Fall, die passende Aufbauorganisation fest-zulegen,

die verschiedenen Rollen zu benennen, die in Projekten von Personen zu übernehmen sind,

den Ablauf eines Projekts mit Hilfe von Arbeitspaketen, Teilprojekten, Projektphasen und Meilensteinen zu untergliedern,

die wesentlichen Merkmale des Wasserfallmodells, des Spiralmodells und des Simul-taneous Engineerings sowie deren Vor- und Nachteile zu erläutern,

zu erklären, wie der Informations- und Kommunikationsfluss in Projekten organisiert werden kann,

die wichtigsten Dokumentenarten in Projekten zu benennen und die Regeln zu deren formaler Gestaltung festzulegen,

die Bedeutung und den Inhalt eines Projektmanagement-Handbuchs zu erläutern.

W. Jakoby, Projektmanagement für Ingenieure, DOI 10.1007/978-3-8348-2274-1_4, © Springer Fachmedien Wiesbaden 2013

4.1 Aufbauorganisation 93

4.1 Aufbauorganisation „Wer glaubt, dass Projektleiter Projekte leiten, glaubt auch, dass Zitronenfalter Zitronen fal-ten.“ (Unbekannter praxiserprobter Projektbeteiligter) Als Organ bezeichnet man einen Teil eines Körpers, der eine bestimmte Aufgabe übernimmt und im Zusammenwirken mit anderen Organen die Funktionsweise des Körpers sicherstellt. Es kann sich dabei um verschiedenartige Körper handeln, wie z. B. um biologische, soziologische oder juristische Körper. In der Technik spricht man hier eher von einem System, das aus ver-schiedenen Komponenten besteht. Für den Begriff der Organisation gibt es zwei unterschiedliche Bedeutungen. Zum einen meint man damit ein Gebilde, das aus mehreren zusammenwirkenden Organen besteht. In dieser Bedeutung ist eine Organisation ein Körper oder ein System. Zum anderen ist Organisation ein Vorgang, bei dem Regeln für das Zusammenwirken von Organen erstellt werden. In der Be-triebswirtschaftslehre beispielsweise versteht man unter Unternehmensorganisation die Schaf-fung eines Systems von Regelungen, durch das die Arbeitsleistung der Mitarbeiter auf die Unternehmensziele ausgerichtet wird. Überträgt man diese Beschreibung auf die Organisation von Projekten, so kommt man zu folgender Definition:

Projektorganisation ist die Schaffung von Regeln, durch die die Arbeit der Projektbe-teiligten auf die Projektziele ausgerichtet wird.

Wie bereits gesehen, kann man ein Projekt als System betrachten. Es besitzt eine statische Struktur und ein dynamisches Verhalten. Beide Aspekte müssen organisiert werden, so dass sowohl die statische Aufbauorganisation als auch die dynamische Ablauforganisation betrach-tet werden muss.

4.1.1 Linienorganisation von Unternehmen Bei weitem nicht alle Arbeiten in einem Unternehmen besitzen Projektcharakter. Viele Arbei-ten finden regelmäßig und in gleicher Weise wiederkehrend statt. Eine effiziente Produktion verlangt sogar, die Arbeitsabläufe so weit zu standardisieren, dass sie in immer gleicher Weise ablaufen und immer Produkte gleichbleibender Qualität liefern. Ausnahmen und einmalige Probleme sind so weit wie möglich zu vermeiden. Da somit gleichartig wiederholte Arbeiten und Routine in vielen Unternehmen überwiegen, ist die Unternehmensorganisation auch für diese Art von Arbeit optimiert.

......

......

U: Unternehmensleitung

V: VertriebE: EntwicklungF: FertigungK: Kaufmännischer Bereich

U

V E F K

Bild 4-1 Organigramm eines Unternehmens

94 4 Projektorganisation

Sehr typisch ist eine baumartig aufgebaute Unternehmensstruktur. Es gibt mehrere Hierarchie-ebenen und jeder Mitarbeiter hat einen einzigen unmittelbaren Vorgesetzten. Sachbearbeiter sind in Gruppen organisiert; mehrere Gruppen bilden eine Abteilung, mehrere Abteilungen einen Bereich und mehrere Bereiche zusammen genommen bilden ein Unternehmen. Da von jedem Mitarbeiter über die Hierarchie-Ebenen eine direkte Linie bis zur Unternehmensleitung führt, wird zwar meist von einer Linienstruktur gesprochen, obwohl es sich im Sinne der Graphentheorie eigentlich um eine Baumstruktur handelt. In graphischer Form wird die Orga-nisationsstruktur eines Unternehmens als Organigramm dargestellt. Die Zahl der Hierarchieebenen hängt natürlich von der Unternehmensgröße ab. Geht man da-von aus, dass im Durchschnitt etwa 3 bis 20 Mitarbeiter einen Leiter brauchen und wählt einen Wert von 7 Mitarbeitern pro Leiter als Faustregel, kommt man auf folgende Werte:

Tabelle 4.1 Zusammenhang zwischen der Zahl der Hierarchieebenen und der Mitarbeiter

Ebenen 1 2 3 4 5 6 7

Mitarbeiter 1 7 50 350 2.000 15.000 100.000 Der entscheidende Vorteil, der zur großen Verbreitung der Linienorganisation geführt hat, ist deren Klarheit. Jegliche Weisungsbefugnis, sowohl die fachliche als auch die disziplinarische, liegt in den Händen einer Person. Missverständnisse oder Weisungskonflikte sollten daher aus-geschlossen sein.

4.1.2 Formen der Aufbauorganisation Von den üblichen Arbeiten in einem Unternehmen unterscheiden sich Projekte vor allem durch ihre Einmaligkeit, die zeitliche Begrenzung, die Komplexität, insbesondere der Beteiligung mehreren Personen, Bereiche und Abteilungen. Ein Projekt stellt an die Organisation, vor al-lem hinsichtlich der fachlichen und disziplinarischen Weisungen eigene Anforderungen, die zum Teil zu den festen Unternehmensstrukturen im Widerspruch stehen. Damit diese Diskre-panz nicht während des Projekts zu Kollisionen führen, ist es notwendig, Unternehmensanfor-derungen und Projektanforderungen zu Projektbeginn festzulegen. Für jedes Projekt muss entschieden werden, wie die für das Projekt erforderliche Struktur mit der bestehenden Unter-nehmensstruktur in Übereinklang gebracht werden kann. Soll die Projektarbeit in der gleichen Organisation, wie die Routinearbeit stattfinden, so muss ein Kompromiss zwischen beiden Anforderungen gefunden werden. Zunächst ist zu klären, wer das Projekt leiten soll und wer im Projekt mitarbeiten wird. Hierbei ist auch festzulegen, welche Weisungsbefugnisse ein Projektleiter gegenüber den einzelnen Projektmitarbeitern besitzen soll. Die Bandbreite der Befugnisse reicht von vollständiger Wei-sungsbefugnis, über eingeschränkte, z. B. rein fachliche Befugnisse bis hin zur Einfluss-Befug-nis, die manchmal auch zu einem „guten Zureden“ mutiert. Die Befugnisse des Projektleiters gegenüber den Projektmitarbeitern können individuell sehr unterschiedlich sein, so dass jedes Projekt eine andere Aufbauorganisation besitzt. Es gibt aber einige bewährte Grundstrukturen, die in unterschiedlichen Variationen immer wieder anzutreffen sind. In der Regel werden Projektleiter und Projektmitarbeiter aus dem Unternehmen kommen. Da sie aber mit ihren „normalen“ Aufgaben im Rahmen der Linienorganisation ausgelastet sind, müssen sie ganz oder teilweise hiervon freigestellt werden. Bei einer teilweisen Freistellung haben sie vorübergehend zwei Vorgesetzte: den Projektleiter und den Abteilungsleiter. Hierbei


ergeben sich vielfältige praktische Fragen: Wer legt die Prioritäten fest? Wer trifft die fachli-chen Entscheidungen? Wer genehmigt den Urlaub? Wer beurteilt die Leistung für die Gehalts-verhandlungen? Einfacher ist es sicherlich, die benötigten Mitarbeiter vollständig aus der Linienstruktur heraus zu nehmen und von ihren normalen Aufgaben zu entbinden. Man erhält dadurch eine reine Projektorganisation.

......

......

U

V E F K

...

P

Bild 4-2 Reine Projektorganisation

Die Projektmitarbeiter werden für die Projektdauer von den anderen Abteilungen abgeordnet und dem Projektleiter unterstellt. Er besitzt ihnen gegenüber vollständige Weisungsbefugnis. Dadurch ergeben sich keine personellen Konflikte mit anderen Bereichen. Das Projektteam agiert wie eine eigenständige Abteilung. Personelle Probleme, die dadurch entstehen, dass ein Mitarbeiter seinem Linienvorgesetzten und dem Projektleiter unterstellt ist, gibt es bei der reinen Projektorganisation nicht. Trotzdem können auch in dieser Organisationsform Probleme auftreten. Zum einen werden nicht alle Mitarbeiter für die gesamte Projektlaufzeit tatsächlich im Projekt benötigt. Kann der Bedarf auf einen zusammenhängenden Zeitraum konzentriert werden, ist es möglich, den Mitarbeiter auch nur für einzelne Projektphasen ins Projekt zu nehmen. Schwie-riger ist es, wenn Mitarbeiter nur zu einem bestimmten Teil, z. B. zu 50 % ihrer Arbeitszeit im Projekt benötigt werden. Hier wird die reine Projektorganisation fragwürdig. Andere personelle Probleme können sich bei der Integration der Mitarbeiter ins Projekt durch die Unterstellung unter der Projektleiter als „Chef auf Zeit“ und bei der Reintegration in die ursprüngliche Abteilung ergeben. Akzeptiert z. B. der Linienvorgesetzte die Leistungsbeurtei-lung, die der Projektleiter vorgenommen hat bei der Gehaltsverhandlung? Wie ist das Verhält-nis zu den Kollegen, die die Aufgabe, des vorübergehend im Projekt Tätigen übernommen und sich damit vielleicht profiliert haben? Aufgrund der beschriebenen Probleme und des größeren Aufwands zur Bildung einer reinen Projektorganisation ist diese nur bei länger laufenden und großen Projekten empfehlenswert.

Beispiel 4-1 Neue Produktionslinie für einen Pizza-Hersteller Ein Lebensmittelhersteller, auf dessen zwei Produktionslinien ausschließlich Tiefkühl-Pizzen hergestellt werden, möchte eine neue, dritte Produktionslinie zur Herstellung von Nudelgerichten aufbauen. Planung, Errichtung und Inbetriebnahme soll im Rahmen eines Projekts erfolgen.


Zum Projekt gehören eine Vielzahl von Arbeiten: Festlegung der zu produzierenden Ge-richte, Entwurf des zugehörigen automatisierten Produktionsverfahrens, Konstruktion der benötigten Maschinen, Ermittlung des Platzbedarfs und eines geeigneten Standorts für die Produktionslinie sowie deren Aufbau und Inbetriebnahme. Der zu erwartende Umfang des Projekts, die Zahl der beteiligten Personen im Unterneh-men und auch außerhalb des Unternehmens sowie das mit der Erweiterung verbundene Ri-siko machen es ratsam ein eigenständiges Projektteam, mit eigenem Projektleiter und fest zugeordneten Mitarbeitern zu bilden.

Eine zweite Form der Organisation findet man, wenn die fachliche und die disziplinarische Weisungsbefugnisse voneinander getrennt werden. Die im Projekt tätigen Mitarbeiter bleiben disziplinarisch in ihren jeweiligen Bereichen, werden aber der fachlichen Weisung des Projekt-leiters unterstellt. Stellt man die disziplinarische Weisung senkrecht und die fachliche waage-recht dar, erhält man eine matrixförmiges Organigramm, weshalb man auch von einer Matrix-Projektorganisation spricht.

......

......

U

V E F K P

Bild 4-3 Matrix-Projektorganisation

Vorteilhaft macht sich hier die weitgehende Beibehaltung bestehender personeller Strukturen bemerkbar, und es wird trotzdem ein funktionierendes Projektteam geschaffen. Auch die Auf-nahme neuer Projektmitarbeiter, die vorübergehende Mitarbeit im Projekt oder die Rück-integration in die Linienarbeit ist relativ einfach möglich. Leider kann es bei zwei Vorgesetzten immer zu Spannungen und Weisungskonflikten kommen. Für deren Lösung bedarf es entweder des guten Willens der Beteiligten oder einer übergeordneten Entscheidungsinstanz.

......

......

U

V E F K P

Bild 4-4 Auftrags-Projektorganisation


Die Auftrags-Projektorganisation stellt eine Mischform der beiden ersten Varianten dar (Bild 4-4). Der Projektleiter hat in seinem Team sowohl feste Mitarbeiter, gegenüber denen er voll-ständig weisungsbefugt ist, als auch Mitarbeiter anderer Bereiche, denen er nur fachliche Wei-sungen erteilen darf. Diese Organisationsform lässt sich vor allem dann sinnvoll einsetzen, wenn das Projekt einige Mitarbeiter erfordert, die dauerhaft im Projekt arbeiten und andere, die nur temporär benötigt werden. Eine weitere Abschwächung der Befugnisse des Projektleiters führt zur Einfluss-Projekt-organisation. Der Projektleiter besitzt hierbei keine formalen Weisungsbefugnisse, sondern kann die Mitarbeiter nur durch seine eigene oder von der Unternehmensleitung verliehene Autorität führen. Er kann also nur im Dialog mit den Linienleitern das Projekt führen.

......

......

U

V E F K

P

Bild 4-5 Einfluss-Projektorganisation

Die Funktionsfähigkeit dieser Organisationsform ist sehr stark von der Person des Projektkoor-dinators abhängig, von dessen Autorisierung durch die Geschäftsleitung und der Akzeptanz durch die Linienleiter. Die Einfluss-Projektorganisation lässt sich vor allem bei kleineren Pro-jekten anwenden und bei Projekten, bei denen die Aufgabentrennung zwischen den Bereichen unstrittig ist. Um der Funktion des Projektleiters genügend Gewicht zu verleihen, wird die Position im Organigramm als Stabsstelle eingebaut, die direkt der Unternehmensleitung unter-stellt ist. Daher wird oft auch von einer Stabs-Projektorganisation gesprochen.

Beispiel 4-2 Fallbeispiel „Solaranlage“: Aufbauorganisation Das Ingenieurbüro Sunnyboy, das seit mehreren Jahren solarthermische Anlagen für priva-te Wohnhäuser plant und mit Hilfe von Subunternehmen errichtet, erhält eine Anfrage der Steinbachwerke zur Erweiterung der Heizung des Bürogebäudes durch eine Anlage zur so-larthermischen Energiegewinnung. Die Kubatur und der Wärmebedarf des Bürogebäudes liegen beide um einen Faktor 4 über dem normaler Wohnhäuser. Die an das Bürogebäude angrenzende Maschinenhalle besitzt eine ausreichend großes Dach zur Anbringung der So-larkollektoren. Welche Organisationsform sollte bei Sunnyboy für das Projekt gewählt werden? Bei dem Ingenieurbüro ist eigentlich jeder Auftrag ein Projekt. Es sollte daher eine eigene Projektierungsabteilung besitzen, die alle Anfragen bearbeitet. Auch wenn sonst nur Wohnhäuser ausgestattet werden, ist die Anbringung einer Solaranlage auf einer Maschi-nenhalle hinsichtlich der Anlagen- und Projektkomplexität nicht so unterschiedlich. Die Anfrage sollte daher als „normales“ Projekt in der Projektierungsabteilung durchgeführt werden.


Das Ingenieurbüro erhält nun die Anfrage eines Lebensmitteldiscounters zur Ausstattung aller 40 Filialen mit Solaranlagen. Verglichen mit den übrigen „normalen“ Projekten ist diese Anfrage deutlich umfangrei-cher. Das Risiko ist ebenfalls deutlich größer und könnte die Substanz des Ingenieurbüros gefährden. Aus diesem Grund sollte sich die Bedeutung des Projekts auch in der passen-den Organisationsform widerspiegeln. Hier erscheint eine Matrix-Projektorganisation sinnvoll zu sein. Eine Person wird als ei-genständiger Projektleiter eingesetzt, der auf Mitarbeiter anderer Abteilungen fachlich zu-rückgreifen kann. Diese bleiben aber in ihren angestammten Abteilungen, um die dort lau-fenden Arbeiten nicht komplett lahm zu legen. Außerdem werden sie im Discounter-Projekt wohl nicht permanent benötigt, da der größere Teil der Projektarbeit, nämlich die Anlagenerrichtung, von externen Unternehmen ausgeführt wird.

Es ist auch denkbar, die Vorteile der Linienorganisation und der reinen Projektorganisation zu kombinieren, indem man einen Bereichsleiter gleichzeitig zum Projektleiter macht. In diesem Fall sind alle Entscheidungen, die für ein Projekt benötigt werden, an einer Stelle gebündelt, und es kann keine Weisungskonflikte geben. Man spricht von einer Projektleitung in der Linie.

......

......

U

V F KE

Bild 4-6 Projektleitung in der Linie

Allerdings ist eine Linien-Projektleitung nur bei kleinen Projekten anwendbar. Außerdem soll-te der Personalbedarf zu einem großen Teil aus einer einzigen Abteilung gedeckt werden. Die Weisungen innerhalb der eigenen Abteilung sind für den Projektleiter, der ja sowieso schon Linienleiter ist, unproblematisch. Seine Weisungsbefugnisse gegenüber den Projektmitarbei-tern aus anderen Abteilungen müssen aber gesondert definiert werden.

Beispiel 4-3 Fallbeispiel „DMS“: Aufbauorganisation Für das geplante Projekt zur Auswahl, Anschaffung und Einführung eines Dokumenten-Managementsystems bei den Steinbachwerken, soll eine geeignete Aufbauorganisation festgelegt werden. Mit dem DMS sollen die Abteilungen Einkauf, Produktion, Montage, Entwicklung und Service arbeiten. An der Spezifikation der Anforderungen und auch an der Systemeinführung müssen alle diese Abteilungen beteiligt werden. Ein DMS ist ein rechnergestütztes Werkzeug, also ein IT-Produkt, so dass Fachkenntnisse in diesem Be-reich im Projekt benötigt werden.


Die Idee, einen externen Spezialisten als Projektleiter einzusetzen und eine Einfluss-Pro-jektorganisation aufzubauen, wird von den Beteiligten verworfen, da zu viele Informatio-nen über interne Abläufe im Projekt zu berücksichtigen sind. Da die Steinbachwerke in der Person des IT-Spezialisten, Herrn Wulff über ausreichendes IT-Know-how verfügen, wird er zum Projektleiter ernannt. Der Aufwand und die Bedeu-tung des Projekts werden nicht so hoch eingestuft, so dass die Organisationsform „Projekt-leitung in der Linie“ gewählt wird. Herr Wulff übernimmt also die Aufgabe der Projektlei-tung zusätzlich zu seinen normalen Aufgaben, erhält aber für Routineaufgaben, wie Instal-lation neuer Software und Administrierung neuer Rechner im Firmennetzwerk, Unterstüt-zung von einem externen IT-Büro. Aus jeder betroffenen Abteilung wird ein Mitarbeiter in Teilzeitform im Umfang von einem Arbeitstag pro Woche in das Projektteam entsandt.

4.1.3 Auswahlkriterien für die Organisationsform Die Frage der Projektorganisation läuft im Kern darauf hinaus, festzulegen von wem die Pro-jektmitarbeiter ihre Weisungen erhalten. Das Bündel an Weisungsbefugnissen kann unter-schiedlich aufgeteilt werden. In den beiden Extremfällen erhält ein Mitarbeiter seine Weisun-gen vollständig von einer Person, entweder dem Linienleiter (reine Linienstruktur) oder dem Projektleiter (reine Projektstruktur). Zwischen diesen beiden Extremfällen existieren Mischlö-sungen, bei denen zwischen disziplinarischen und fachlichen Weisungen unterschieden wird (Matrix-Projektorganisationen), oder bei denen an die Stelle von Weisungsbefugnissen Koor-dinationsbefugnisse treten (Einfluss-Projektorganisation). Die beiden wichtigsten Parameter zur Auswahl der richtigen Organisationsform sind die Pro-jektgröße (im Wesentlichen der Personalaufwand) und die Schnittstellenzahl, d. h. das Aus-maß, in dem unterschiedliche Abteilungen an einem Projekt beteiligt sind. Je größer die Pro-jekte sind und je vielfältiger die Schnittstellen, desto größer sollte der Umfang der Weisungs-befugnisse des Projektleiters (in Relation zu den Linienleitern) sein. Eine qualitative Einord-nung zeigt das Diagramm in Bild 4-7.

Schnittstellenanzahlund -bedeutung

Projektgrößeund -bedeutung

Matrix-PO

Einfluss-POLinie-PO

Reine PO

Auftrags-PO

V+E E

V

FV+F

klein

groß

niedrig hoch

V: vollständigWeisungsbefugnisse:

E: EinflussF: fachlich

Bild 4-7 Abhängigkeit der Organisationsform von Projektgröße und Schnittstellenzahl


Bei kleinen Projekten mit wenig bereichsübergreifenden Schnittstellen wird der Leiter des Bereichs, aus dem die meisten Projektmitarbeiter kommen, zum Projektleiter ernannt. Er erhält auf die Mitarbeiter anderer Bereiche lediglich Einflussbefugnis. Der Projektleiter übt seine Aufgabe neben seiner hauptamtlichen Bereichsleitungsaufgabe aus. Bei kleinen Projekten mit vielen bereichsübergreifenden Schnittstellen wird ein hauptamtlicher Projektleiter bestellt, der aber nur Einflussbefugnisse erhält. Der Projektleiter kann sich voll-ständig auf die Projektaufgabe konzentrieren. Da er nur vorübergehend auf der gleichen Ebene tätig ist wie die Bereichsleiter in Linienfunktion, wird er von diesen nicht so stark als Konkur-rent gesehen und eher unterstützt. Bei mittleren Projekten mit wenig bereichsübergreifenden Schnittstellen gibt es einen haupt-amtlichen Projektleiter mit festen Mitarbeitern, auf die er vollständige Weisungsbefugnis er-hält, sowie einer fachlichen Weisungsbefugnis auf Projektbeteiligte aus anderen Bereichen. Bei mittleren Projekten mit vielen bereichsübergreifenden Schnittstellen gibt es einen haupt-amtlichen Projektleiter der ausschließlich auf Projektbeteiligte aus anderen Bereichen zugrei-fen kann und für diese nur fachliche Weisungsbefugnisse hat. Für große Projekte schließlich wird ein eigener Projektbereich gebildet. Alle Projektbeteiligte sind dem Projektleiter für die Dauer des Projekts vollständig unterstellt.

Beispiel 4-4 Brandmeldezentrale Bei einem mittelständischen Hersteller von Systemen für die Gebäudeautomatisierung soll eine neue Brandmeldezentrale entwickelt werden. Der Aufwand hierfür wird mit ca. 5 Per-sonenjahren und einer Laufzeit von 2 Jahren veranschlagt. Die Entwicklungsabteilung besteht aus 20 Mitarbeitern, von denen ein Hardware-Entwickler und ein Software-Entwickler dauerhaft im Projekt arbeiten sollen. Aus den Ab-teilungen Vertrieb, Produktion und mechanische Konstruktion wird je 1 Mitarbeiter zeit-weise im Projekt benötigt. Welche Aufbauorganisation soll für das Projekt gewählt wer-den? Aufgrund der Laufzeit und des Umfangs kann das Projekt in Relation zur Unternehmens-größe als Projekt mittlerer Größe eingestuft werden. Die Zahl der Schnittstellen bzw. der Projektbeteiligten ist überschaubar, so dass eine Auftrags-Projektorganisation geeignet er-scheint. Die beiden Entwickler werden für die gesamte Projektlaufzeit aus ihrer Abteilung freige-stellt, die Mitarbeiter aus den anderen Abteilungen stehen bei Bedarf zur Verfügung. Als Projektleiter könnte einer der beiden Entwickler eingesetzt werden. Eventuell käme auch eine Linien-Projektorganisation in Frage, bei der der Entwicklungs-leiter die Rolle des Projektleiters übernimmt.

Beispiel 4-5 Qualitäts-Managementsystem (QMS) Im gleichen Unternehmen soll nun ein Qualitäts-Managementsystem eingeführt werden, das von allen Abteilungen durchgängig zu nutzen ist. Die Festlegung der Anforderungen, die Auswahl eines geeigneten Systems und dessen Einführung im Unternehmen soll als Projekt durchgeführt werden. Welche Aufbauorganisationsform ist hier geeignet? An dem Projekt sind mehrere Abteilungen des Unternehmens beteiligt. In jeder Abteilung gibt es mehrere Mitarbeiter, die Erfahrungen mit den Arbeitsprozessen und der Anwen-dung von Verfahren zur Sicherung der Qualität der Arbeitsergebnisse gemacht haben. Die-se Erfahrungen sollen in die Auswahl eines QMS eingebracht werden. Der individuelle


Aufwand für das Projekt ist wohl eher niedrig anzusetzen, aber aufgrund der Vielzahl der Beteiligten ist mit einer vergleichsweise langen Laufzeit zu rechnen. Es bietet sich eine Einfluss-Projektorganisation an. Die benötigten Mitarbeiter werden nur einen geringen Teil (5–10 %) ihrer Arbeitszeit für das Projekt aufwenden, so dass eine Matrix-PO wenig Sinn macht. Gegen eine Linien-PO spricht die Tatsache, dass alle betei-ligten Abteilungen gleiches Gewicht im Projekt besitzen. Als Projektleiter wird eine externe Person, die bereits Erfahrungen mit QMS besitzt, auf eine zeitlich befristete Stabsstelle berufen.

4.1.4 Projektbeteiligte Jede im Projekt beteiligte Person übernimmt eine bestimmte Rolle. Derartige Rollen können z. B. Projektleitung, Projektmitarbeit, Auftraggeber, Auftragnehmer oder Beobachter sein. Be-trachtet man die im Projekt zu erledigenden Aufgaben, kann man drei grundlegenden Rollen der Beteiligten unterscheiden. Für jede Aufgabe muss es genau eine verantwortliche Person (V) geben. Aufgaben ohne ver-antwortliche Person werden selten bedarfsgerecht erledigt. Bei mehreren Verantwortlichen sind Konflikte vorprogrammiert. Des Weiteren gibt es bei jeder Aufgabe mitarbeitende Personen (M), die die Aufgabe durchführen. Zu dieser Personengruppe können eine oder mehrere Perso-nen gehören. Schließlich gibt es für jede Aufgabe auch zu informierende Personen (I), die im besten Falle bei der erfolgreichen Erledigung oder in anderen Fällen bei auftretenden Proble-men unterrichtet werden müssen. Ordnet man alle Arbeiten zeilenförmig und alle Beteiligten spaltenförmig an, so entsteht eine Matrix, die so genannte IMV-Matrix, in der jedem Beteiligten seine entsprechende Rolle bei den Arbeiten zugewiesen wird [Kraus 2004]. Die IMV-Matrix schafft Übersicht über die Rol-len aller Beteiligten. Ihr Aussehen ermöglicht es auch einige Schlussfolgerungen zu ziehen, ohne dass alle Details der Aufgabenzuordnung bekannt sind.

Beispiel 4-6 IMV-Matrix In der dargestellten IMV-Matrix gibt es 6 Beteiligte (A – F) und 4 Arbeiten (a – d).

Tabelle 4.2 Beispiel einer IMV-Matrix

Beteiligte A B C D E F Arbeit a V M M M M I

Arbeit b I V I I

Arbeit c I I V M I

Arbeit d I V M I Welche Aussagen können über die Rollen der einzelnen Beteiligten gemacht werden? Bei welcher Arbeit handelt es sich um das Gesamtprojekt? Wer ist Projektleiter, wer Auftraggeber und wer Mitarbeiter im Projekt? Welche Vermutung über die Reihenfolge der Arbeiten lässt sich anstellen? Da bei Arbeit a alle Personen beteiligt sind, könnte es sich hier um das Gesamtprojekt handeln. A wäre dann der Projektleiter, B, C, D und E bilden das Projektteam, da sie an den übrigen Arbeiten mitwirken und F ist wahrscheinlich Auftraggeber.


Bei den Arbeiten b, c, und d werden Projektleiter und Auftraggeber informiert. Im Team gibt es eine verantwortliche und eine zu informierende Person. Vermutlich laufen die Ar-beiten in der Reihenfolge b, c, d ab.

Ein ähnliches Hilfsmittel ist die RACI-Matrix. Sie verwendet 4 Rollen der Projektbeteiligten. Für jede Arbeit muss eine Person verantwortlich sein (R: responsible). Es gibt eine Auftrag gebende Person (A: accountable), die auch das Ergebnis abnimmt und die Kosten trägt. Darü-ber hinaus gibt es Personen, die beratend hinzu gezogen werden und auch an den Entscheidun-gen mitwirken (C: consulted), sowie Personen, die den Fortgang über Entscheidungen und Ergebnisse zu informieren sind (I: informed). Darüber hinaus gibt es Vorschläge für weitere Rollen, wie z. B. unterstützende Personen (S: supportive) oder Personen, die die Ergebnisse der Arbeiten verifizieren (V: verifying). Egal ob nun die IMV-Matrix, die RACI-Matrix oder ein selbst definiertes Repertoire von Rol-len verwendet wird – entscheidend ist, dass die wichtigen Rollen der beteiligten und benötigten Personen für das Projekt, für die Teilprojekte und die Arbeitspakete festgelegt und dokumen-tiert werden.

4.2 Ablauforganisation „Ordnung ist das Durcheinander, an das man sich gewöhnt hat.“(Robert Lembke)

4.2.1 Teilprozesse eines Projekts In einem Projekt gibt es im Allgemeinen mehrere Beteiligte, die viele Arbeiten zu verrichten haben. Der Prozesscharakter von Projekten, d. h. die logischen und zeitlichen Abhängigkeiten zwischen den verschiedenen Arbeiten, stellen eine beträchtliche planerische und steuernde Herausforderung dar. Um diese zu bewältigen, ist es notwendig, neben den Fragen der Wei-sungsbefugnisse auch die Abläufe zu organisieren. Die Ablauforganisation eines Projektes, legt allgemeingültige Regeln fest, nach denen alle Aktivitäten mit ihren gegenseitigen Abhängigkeiten in einen geordneten Ablauf zu bringen sind. Hierzu ist es notwendig, ein Projekt als Ganzes so weit in einzelne Teile zu zerlegen, bis man bei überschaubaren und gut planbaren Arbeitseinheiten angelangt. Die kleinste derartige Einheit wird als Arbeitspaket bezeichnet. Ein Arbeitspaket fasst Arbeiten zusammen, die einen engen funktionellen und zeitlichen Zusammenhang bilden.

Beispiel 4-7 Arbeitspakete bei der Entwicklung eines elektrischen Geräts Die Anfertigung einer Gehäuseskizze. Das Erstellen des Layouts einer Platine anhand des Schaltplans. Das Programmieren einer datenverarbeitenden Funktion. Die Erstellung eines Benutzerhandbuchs. Das Erstellen des Layouts einer Platine zur Ankopplung von analogen Spannungseingän-gen an eine CPU. Der Test einer Funktion zur Berechnung des Sicherungs-Bytes für ein Datentelegramm. Die Verdrahtung eines Schaltschranks. Die Analyse eines Lastenhefts auf technische Machbarkeit.

4.2 Ablauforganisation 103

Ein Arbeitspaket wird immer einer verantwortlichen Person zugeordnet, es besitzt einen klaren Start- und Endtermin und es liefert zum Endtermin ein messbares bzw. feststellbares Ergebnis. Aus Sicht des Projektmanagements muss ein Arbeitspaket nicht weiter unterteilt werden, son-dern es bildet eine zusammenhängende Einheit, die von der Projektleitung gestartet, nach Fer-tigstellung von der verantwortlichen Person zurückgemeldet wird und zwischendurch im Nor-malfall keine Management-Aktivität erfordert.

Ein Arbeitspaket besteht aus Arbeiten, die funktionell und zeitlich sehr eng zusam-mengehören und von einer Person ausgeführt werden. Es stellt aus Sicht des Projekt-managements die kleinste betrachtete Aktivitätseinheit dar.

Der typische Umfang eines Arbeitspakets liegt zwischen 1 und 10 Personentagen (PT). Auch wenn es im Einzelfall einmal noch kleinere oder größere Arbeitspakete geben kann, ist es sinn-voll sich in der genannten Bandbreite zu bewegen. Sehr kleine Arbeitspakete (< 1 PT) sollten zusammengefasst werden, um den Planungs- und Verwaltungsaufwand nicht unnötig in die Höhe zu treiben. Größere Pakete (> 10 PT) sollten aufgeteilt werden, damit eine regelmäßige Rückkopplung von der Ausführungsebene in die Projektmanagementebene sichergestellt ist. Jedes Projekt besteht aus einer Vielzahl von Arbeitspaketen. Viele können beliebig nacheinan-der oder nebeneinander ausgeführt werden. Andere müssen aufgrund von wechselseitigen Abhängigkeiten in einer bestimmten Reihenfolge abgearbeitet werden. Um die Komplexität eines Projekts mit seinen vielen Arbeitspaketen im Ablauf beherrschen zu können, ist es not-wendig, die Arbeitspakete zu gruppieren. Mehrere Arbeitspakete, die funktionell oder zeitlich eng miteinander gekoppelt sind, werden deshalb auf der nächst höheren Gliederungsebene zu einer Einheit zusammengefasst. Für derar-tige Einheiten sind unterschiedliche Bezeichnungen im Gebrauch. In diesem Buch werden zusammengefasste Einheiten als Teilprojekt bezeichnet. Ein Teilprojekt besteht also aus meh-reren Arbeitspaketen, die funktionell zusammengehören und meist auch zusammenhängend in einem bestimmten Zeitrahmen ausgeführt werden.

Beispiel 4-8 Fallbeispiel „Maschinenterminal“: Typische Teilprojekte Im Projekt zur Entwicklung des Maschinenterminals, das aus einem Gehäuse, mehreren elektrischen Baugruppen und einem Programm besteht, können verschiedene Teilprojekte gebildet werden. Aus produktorientierter Sicht kann man Arbeitspakete, die zu einem bestimmten Produkt-teil gehören, zu einem Teilprojekt zusammenfassen. Das Teilprojekt „Gehäuse“ könnte dann aus den Arbeitspaketen Grobentwurf, Detailkonstruktion, Musteraufbau, Redesign und Nullserienherstellung bestehen. Das Teilprojekt „CPU-Platine“ würde aus den Ar-beitspaketen Schaltplanerstellung, Probeaufbau, Test, Erstellung eines PCB-Layouts, Fer-tigung der Platinen, Bestückung, Test der Baugruppe und Dokumentation bestehen. Genau so gut könnte man die Bildung von Teilprojekten auch ablauforientiert vornehmen. Hier würde z. B. aus allen Entwurfsarbeiten, wie Gehäuseentwurf, Schaltungsentwurf und Programmentwurf das Teilprojekt „Entwurf“ gebildet. Alle Testarbeiten, wie z. B. Muster-aufbau des Gehäuses, Test der CPU-Platine, Test der IO-Platine, Funktionstest der Soft-ware-Module, Integrationstest und Systemtest könnten zum Teilprojekt „Test“ zusammen-gefasst werden.

Auch ein Teilprojekt muss einen klaren Start- und Endtermin besitzen und es muss ein nach-prüfbares Ergebnis liefern. Im Gegensatz zu einem Arbeitspaket erfordert ein Teilprojekt nicht


nur beim Start und am Ende, sondern auch während seiner Durchführung Projektmanagement-Aktivitäten. Da in der Regel mehrere Personen beteiligt sind, muss das Teilprojekt vorher ge-plant, während der Durchführung überwacht und bei Planabweichungen gesteuert werden. Ein Teilprojekt, das aus einzelnen Arbeitspaketen zusammengesetzt ist, besitzt in der Regel einen Arbeitsumfang von etwa 0,5 bis 5 Personenmonaten (PM). Es enthält also durchschnitt-lich etwa 10 Arbeitspakete. Je nach Projektgröße können die aus Arbeitspaketen gebildeten Teilprojekte auf der nächsten Gliederungsebene zu einem größeren Teilprojekt zusammenge-fasst werden. Bei noch größeren Projekten können auch diese wiederum zusammengefasst werden, bevor man auf der Ebene eines (Gesamt-)Projekts landet.

Tabelle 4.3 Gliederung von Projekten unterschiedlicher Größe auf mehreren Ebenen

Projektgröße Untergliederung 50 ... 500 PJ Groß-Projekt

5 ... 50 PJ Teilprojekte Mittleres Projekt

0,5 ... 5 PJ Teilprojekte Teilprojekte Kleines Projekt

0,5 ... 5 PM Teilprojekte Teilprojekte Teilprojekte

1 ... 10 PT Arbeitspakete Arbeitspakete Arbeitspakete Neben der statischen Strukturierung eines Projekts in Teilprojekte und Arbeitspakete ist auch der Ablauf in Form von Prozessen von großem Interesse. Verschiedene Teilprojekte oder Ar-beitspakete müssen nicht immer getrennt und nacheinander ausgeführt werden. Zur Verkür-zung der Durchlaufzeit ist es oft sinnvoll, Arbeitspakete oder Teilprojekte auch parallel zu bearbeiten. Ein typischer Projektablauf besteht daher sowohl aus sequentiell gekoppelten als auch aus parallelen Prozessen. Jeder Prozess besitzt im Plan mindestens einen Start- und einen Endtermin, oft auch noch Zwi-schentermine, die bei der Projektsteuerung überwacht werden können. Trotzdem ist es notwen-dig, im Projekt übergeordnete Termine zu definieren, an denen wichtige Projektphasen abge-schlossen werden. Derartige Termine werden allgemein als Meilensteine bezeichnet. Sie gren-zen einzelne Phasen eines Projekts voneinander ab. Zwischen zwei Meilensteinen liegt also jeweils eine Projektphase. Projektphasen können mit Teilprojekten identisch sein. In diesem Fall laufen die Teilprojekte ebenfalls sequentiell ab. Um die Laufzeit eines Projekts möglichst kurz zu halten, ist es aber oft sinnvoll, Teilprojekte auch parallel ablaufen zu lassen. In diesem Fall bilden mehrere nachei-nander oder nebeneinander ablaufende Teilprojekte eine Projektphase. Durch die Kombination rein sequentieller Projektphasen und paralleler oder sequentieller Teilprojekte werden die bei-den Ziele der klaren Projektorganisation mit den praktischen Zielen kurzer Projektlaufzeiten miteinander in Einklang gebracht.

Eine Projektphase ist ein zeitlich abgegrenzter Teil eines Projekts. Sie kann ein oder mehrere Teilprojekte umfassen. Anfangs- und Endzeitpunkt einer Projektphase stellen Meilensteine dar.

Jede Projektphase muss abgeschlossen sein, bevor die nächste beginnen kann. Durch diese saubere Schnittstelle zwischen zwei Projektphasen gewinnt man Ordnung und Planungssicher-heit. Das Ergebnis eines Projekts kann dadurch nicht erst am Ende – positiv oder negativ –


festgestellt werden, sondern bereits in frühen Phasen sind Zwischenergebnisse überprüfbar. Das Erreichen eines Meilensteins erlaubt einen Vergleich der bis dahin geleisteten Arbeit mit dem Plan. Auf eventuell aufgetretene Abweichungen zwischen Plan und Realität kann und muss hier mit grundlegenden Entscheidungen reagiert werden.

I II IVIIIProjektphasen

Teilprojekte

Meilensteine

Arbeitspakete(im Teilprojekt)

Bild 4-8 Arbeitspakete, Teilprojekte und Projektphasen

Kann eine Projektphase nicht wie geplant abgeschlossen werden, macht es keinen Sinn, mit der nächsten Projektphase zu beginnen. Eine mögliche Reaktion ist z. B. die Verlängerung der Projektphase mit einem neuen Zieltermin. Dadurch verschieben sich nachfolgende Phasen und, falls die verlorene Zeit nicht wieder hereingeholt werden kann, auch der Endtermin des Pro-jekts. Bei noch gravierenderen Problemen könnte auch das Abbrechen des Projekts eine not-wendige Reaktion auf das Überschreiten eines Meilensteins sein. So unangenehm derartige Entscheidungen auch sind, je länger sie aufgeschoben werden, desto unangenehmer werden die Konsequenzen. Ohne die Trennung der Projektphasen durch Meilensteine werden notwendige Überprüfungen und Entscheidungen oft immer wieder aufgeschoben. Typische Auswirkungen sind das lautlose Versickern, das ewige Dahinplätschern oder das ergebnislose Beenden von Arbeitspaketen und Teilprojekten. Ein solches Verhalten im Projekt führt zumindest zu drastischen Terminüber-schreitungen, viel zu oft aber auch zu gescheiterten Projekten.

Beispiel 4-9 Leistungsphasen nach HOAI Die Baubranche besitzt umfangreiche und lange zurück reichende Erfahrungen mit der Strukturierung und Planung von Projekten, so dass es hier seit langem eine Standard-Ablaufstruktur gibt. Sie wird durch die Honorarordnung für Architekten und Ingenieure (HOAI) in 9 aufeinander folgende Leistungsphasen unterteilt [Schneider 2008]. In der Grundlagenermittlung werden die Vorstellungen der Bauherren und der Ist-Zustand erfasst. Daran schließen sich drei Entwurfsphasen an. In der Vorplanung erfolgen die Analyse der Aufgabe, die Erarbeitung eines Konzepts und eine Kostenschätzung. Die Entwurfsplanung umfasst eine detaillierte Planung des Projektgegenstands und eine darauf basierende Kostenrechnung. In der Genehmigungsplanung werden alle Fragen, die für den Bauantrag relevant sind, ge-klärt und die entsprechenden Unterlagen erstellt. In den beiden nächsten Leistungsphasen geht es um die Vergabe des Auftrags. Zunächst bereiten Architekten oder Ingenieure die


Vergabe vor und wirken in der nächsten Phase an der Vergabe und der Erstellung eines Kostenvoranschlags mit.

Tabelle 4.4 Leistungsphasen nach HOAI

Nr. Phase Aufwand 1 Grundlagenermittlung 3 %

2 Vorplanung 7 %

3 Entwurfsplanung 11 %

4 Genehmigungsplanung 6 %

5 Ausführungsplanung 25 %

6 Vorbereitung der Vergabe 10 %

7 Mitwirkung bei der Vergabe 4 %

8 Objektüberwachung 31 %

9 Dokumentation 3 % Die eigentliche Bauausführung beginnt in Phase 8. Hier übernehmen Architekten oder In-genieure die Bauleitung. Der Gesamtablauf wird durch die Dokumentationsphase abge-schlossen. Zusätzlich zur Phaseneinteilung macht die HOAI auch Aussagen über den Anteil des Ar-beitsaufwands, der in den 9 Leistungsphasen erfahrungsgemäß anfällt.

4.2.2 Standard-Ablaufstrukturen Die vielen Arbeitspakete eines Projektes können zum Teil beliebig nebeneinander oder nachei-nander ausgeführt werden. Zwischen manchen Arbeiten bestehen aber Abhängigkeiten, so dass sie parallel bzw. sequentiell ausgeführt werden müssen. Ob eine Arbeit so früh wie nötig, so spät wie möglich oder mit einem zeitlichen Puffer eingeplant wird, hängt teilweise von den Projektzielen ab. Daher könnte man erwarten, dass jedes Projekt eine individuelle, einzigartige Ablaufstruktur aufweist. Bei sehr detaillierter Betrachtung ist dies auch der Fall. Andererseits findet man in Projekten oft gleichartige Arbeitspakete, Teilprojekte und Projekt-phasen. Es ist daher sinnvoll, Ablaufstrukturen, die sich in vielen Projekten bewährt haben, als Standard zu definieren. Ausgangspunkt hierfür ist die Betrachtung eines Projekts als ein Prob-lemlösungsprozess. Die systematische Lösung von Problemen, auch wenn diese sehr unter-schiedlich sein können, erfolgt in abstrahierter Sicht immer wieder in mehreren Prozessen, die in gleicher Weise aufeinander folgen. Sowohl in der Theorie als auch in der praktischen An-wendung gibt es mehrere Modelle, die sich in der Anzahl und in der Bezeichnung der Prozesse unterscheiden. Hier wird ein Modell mit den vier aufeinander folgenden Prozessen Problem-analyse – Lösungsentwurf – Realisierung – Validierung verwendet. Die Problemlösung beginnt mit einer Problemanalyse. Deren Input bildet die Problembeschrei-bung. In der Analyse wird das Problem detailliert untersucht, die Problemdimensionen werden ermittelt, Ist-Zustand und Ziel-Zustand werden bestimmt sowie die Randbedingungen und zu optimierenden Kriterien formuliert. Während die von außen kommende Problembeschreibung teilweise unspezifisch, lückenhaft oder in sich widersprüchlich sein kann, sollte die aus der


Analyse herauskommende Aufgabenbeschreibung möglichst konkret, vollständig und wider-spruchsfrei sein. Die Aufgabenbeschreibung wird dann im nächsten Schritt, dem Entwurf, verwendet. Sinnvoll ist es hier, sich nicht von vorneherein auf eine einzige Lösung zu konzentrieren, sondern meh-rere mögliche Lösungen zu suchen, diese bis zu einem gewissen Grad auszuarbeiten, Vor- und Nachteile gegenüber zu stellen und sich dann für eine Lösung zu entscheiden. Die ausgewählte, den meisten Erfolg versprechende Lösung wird dann detailliert als Plan ausgearbeitet. Die Lösungspläne bilden die Grundlage für die nun folgende Realisierungsphase. Hier wird der Plan in eine reale Lösung umgesetzt. Im letzten Schritt, der Validierung, wird die Qualität der Lösung überprüft. Hier wird untersucht, ob die erreichte Realisierung tatsächlich eine Lösung des Problems darstellt, ob die vorgegebenen Randbedingungen eingehalten und das Gütekrite-rium tatsächlich optimiert wurde. Jeder der vier Lösungsschritte stellt ein eigenes Teilprojekt dar. Im Idealfall muss jedes Teil-projekt abgeschlossen sein, bevor das nächste beginnen kann. Somit bildet jedes Teilprojekt eine eigene Projektphase. Der Output des einen Teilprojekts bildet den Input für das nächste. Stellt man die Teilprojekte sowie deren Input und Output kaskadenförmig, nacheinander dar, so erinnert dies an einen Wasserfall. Daher hat sich für diese Art des Ablaufs die Bezeichnung „Wasserfallmodell“ etabliert, wobei in der Literatur mit einer unterschiedlichen Zahl von Teil-projekten und Projektphasen gearbeitet wird.

Problem Analyse

Aufgabe

Entwurf

Realisierung

Lösung

Plan

Validierung val. Lösung

I II III IV Zeit Bild 4-9 In Phasen gegliederte Standard-Ablaufstruktur („Wasserfallmodell“)

Durch die saubere Trennung der einzelnen Teile und Phasen eines Projekts besitzt das Wasser-fallmodell einen sehr einfachen und klaren Aufbau, der sich daher auch gut für die Projektkon-trolle eignet. Allerdings kann das Modell in der Realität nur selten in Reinform umgesetzt werden. Die Analyse eines Problems kann z. B. nicht immer vollständig abgeschlossen werden, bevor mit dem Lösungsentwurf begonnen wird. Oft treten beim Versuch, eine Lösung zu erar-beiten neue, bisher unberücksichtigte Probleme auf, so dass eine erneute Analyse notwendig wird. Auch ein Lösungsentwurf kann meistens nicht vollständig „trocken, auf Papier“ erfolgen, sondern Realisierungsmöglichkeiten müssen oft ausprobiert werden, um eine größere Sicher-heit für die Realisierbarkeit zu erlangen. Aus diesen Gründen gibt es in der Praxis viele Ab-wandlungen der rein sequentiellen Ablaufstruktur des Wasserfallmodells.


Der Preis für die Einfachheit und Klarheit des Wasserfallmodells ist die hohe Durchlaufzeit. Ein neues Teilprojekt und damit auch eine neue Projektphase wird erst begonnen, wenn die vorangehende beendet ist. Die Reduzierung der Durchlaufzeit kann erreicht werden, wenn die Prozesse nicht nacheinander sondern gleichzeitig, nebeneinander laufen. Dies ist der Kernge-danke des so genannten Simultaneous Engineering [Ribbens 2000], [Dixius 1999], das oft auch als Concurrent Engineering [Bullinger 1995] oder als Integrierte Produktentwicklung [Ehren-spiel 2006] bezeichnet wird. In der Herleitung dieses Modells wird die sequentielle Arbeits-weise des Wasserfallmodells, bei dem die Ergebnisse einer Projektphase ohne Rückkopplung an die nächste fließen („over the wall“-Engineering) als Ursache vieler Probleme im Projekt erkannt. Beim simultanen Vorgehen werden die Arbeiten so weit wie möglich parallelisiert. Eine vollständige Parallelisierung ist kaum möglich, daher gibt es einen gewissen zeitlichen Versatz, der allerdings möglichst klein gehalten werden soll. Liegen die ersten Ergebnisse aus der Analyse vor, wird bereits mit dem Entwurf begonnen. Genau so beginnen Realisierung und Validierung schon, sobald erste greifbare Resultate der davor liegenden Prozesse verfügbar sind. Diese Vorgehensweise erfordert natürlich eine ganz andere Denkweise, weshalb die Ein-führung einer simultanen Arbeitsweise auch gravierende organisatorische Änderungen voraus-setzt. Da es keine abgrenzbaren Projektphasen mehr gibt, ist ein deutlicher höherer Informati-onsaustausch zwischen den einzelnen Arbeitspaketen erforderlich.

Problem Analyse

Aufgabe

Entwurf

Realisierung

Lösung

Plan

Validierung val. Lösung

Zeit Bild 4-10 Ablauf mit Simultaneous Engineering

Ein simultanes Ausführen der Arbeiten erhöht natürlich das Risiko. Frühe Fehler, die nicht sofort bemerkt werden, sind schon in viele Arbeiten eingeflossen. Im schlimmsten Fall sind diese Arbeiten vergebens. Im weniger schlimmen Fall erfordert die Beseitigung der Fehler einen zusätzlichen Aufwand. Der Lohn für das erhöhte Risiko ist aber eine Reduzierung der Durchlaufzeit.

Beispiel 4-10 Projektplan mit sequentieller und paralleler Bearbeitung Gegeben sei ein kleines Projekt mit den Phasen Analyse, Entwurf, Realisierung und Vali-dierung. Jede dieser 4 Phasen wird noch einmal in Grob- und Fein-Phase unterteilt. In den Grob-Phasen (GA, GE, GR, GV) werden die für den Projekterfolg kritischen Fragen be-handelt. Die fein-Phasen (FA, FE, FR, FV) haben die unkritischen Fleiß-Arbeiten zum


Gegenstand. Man erhält somit 8 (kleine) Phasen. Die Durchlaufzeit beträgt hier 63 Ar-beitstage.

Bild 4-11 Screenshot eines Projektplans mit sequentieller und parallelisierter Ausführung

Der laufzeitverkürzende Effekt von simultanem Engineering wird durch zwei Maßnahmen erreicht. Erstens werden die kritischen Arbeiten jeder Phase zuerst ausgeführt und danach die weniger kritischen. Außerdem wird mit den weniger kritischen Arbeiten bereits begon-nen, bevor die kritischen Arbeiten der Folgephasen abgeschlossen sind. Die Durchlaufzeit kann dadurch auf 44 Tage reduziert werden.

Beispiel 4-11 Fallbeispiel „Maschinenterminal“: Simultaneous Engineering Die Entwicklung des neuen Maschinenterminals sollte aufgrund auslaufender Verträge mit den bisherigen Zulieferern bis zur Serienreife in maximal 8 Monaten entwickelt werden. Es war klar, dass dies nur durch massive Parallelisierung der Arbeiten zu erreichen war. Um eine weit gehende Parallelisierung der Arbeiten zu erreichen, wurden zunächst eine Grob-Analyse der Anforderungen und ein Grob-Entwurf des Terminals durchgeführt. Hierbei wurden die wichtigsten Entwurfsentscheidungen, so getroffen, dass sie einerseits möglichst konkrete Vorgaben für die nachfolgenden Arbeiten ermöglichen, andererseits aber gewisse Spielräume für die noch nicht berücksichtigte Detail-Anforderungen lassen. Als Hardwarebasis wurde die x86-Prozessorreihe mit einem freien DOS-Betriebssystem gewählt, da dieses für alle benötigten Schnittstellen entsprechende Treiber zur Verfügung stellt. Ein Multitasking- oder Echtzeit-Betriebssystem war wegen der nicht benötigten Gra-fik-Schnittstelle und der nicht benötigten Echtzeitanforderungen nicht erforderlich. Zur Verkürzung der Entwicklungszeit sollten am Markt verfügbare eingebettete Single-Board CPU-Module im PC/104-Format verwendet werden. Alle anwendungsspezifischen Teile (Anschlüsse für Lesegeräte, Relaisausgänge, Anschluss für Tastatur und Display) sollten auf einem zu entwickelnden Basis-Board realisiert werden. Als Gehäuse sollte ein am Markt verfügbares Kunststoffgehäuse verwendet werden. In diesem sollte neben der Elektronik die zu entwerfende Folientastatur, das Display, ein


Durchzugleser und die externen Steckanschlüsse untergebracht werden. Der benötigte Platz für die Elektronik wurde mit 18·25·5 cm³ (L·B·H) abgeschätzt. Die Stromversor-gung sollte mit einem externen Steckernetzteil erfolgen. Wegen der Verwendung einer standardisierter Hardware- und Betriebssystem-Plattform konnte die Software-Entwick-lung sofort beginnen und auf einem Standard-PC durchgeführt und getestet werden.

Bild 4-12 Projektplan Maschinenterminal M4

Durch die Festlegung der wesentlichen Entwurfsentscheidungen während des Grob-Entwurfs konnte anschließend parallel mit den mechanischen Arbeiten (Gehäuse, Einbau-geräte, Tastatur, Stecker, Auswahl von Zubehör wie Magnetkarten-Durchzugleser, Bar-code-Durchzugleser, Barcode-Lesestift) mit den elektrischen Arbeiten (Schaltungsentwurf, Layout, Test) und den Software-Arbeiten (Festlegung der Protokolle, Festlegung der Da-tensicherung, Benutzerdialog, Programmierung, Test) begonnen werden.

4.2.3 Varianten von Ablaufstrukturen Der rein sequentielle Projektablauf, wie er im Wasserfallmodell verwirklicht ist und der extrem parallele Ablauf des Simultaneous Engineering stellen die beiden Grundformen für die Ablauf-organisation dar. Die parallele Vorgehensweise führt zu einer minimalen Projektlaufzeit, aller-


dings auf Kosten höheren Aufwands. Die sequentielle Arbeitsweise ist einfacher anzuwenden, hat aber längere Laufzeiten zur Folge. In der Praxis existieren zahlreiche weitere Ablaufmodelle. Die beiden Grundmodelle gehen davon aus, dass jeder der Prozesse Analyse, Entwurf, Realisierung und Validierung vollständig abgearbeitet sein muss, bevor der nächste beginnen kann. Dieser Ansatz basiert auf dem Ge-danken, dass das Projektergebnis eine untrennbare Einheit darstellt, die erst am Ende des ge-samten Projekts zum ersten Mal funktioniert. Dies muss aber nicht immer so sein. Viele Pro-dukte und Dienstleistungen, die in einem Projekt realisiert werden, lassen sich unterteilen. Typische Muster für derartige Unterteilungen sind das Komponentenmodell, das Schichtenmo-dell und das Prototypenmodell. Beim Komponentenmodell wird das Projektergebnis – das Produkt – in mehrere gleichwertige Module zerlegt. Diese können unabhängig voneinander realisiert und am Ende zum Gesamt-ergebnis zusammengesetzt werden. Das Komponentenmodell findet man heute in sehr vielen bereichen, wie z. B. bei der Herstellung von Autos, bei denen viele Fahrzeuge aus einem Mo-dulbaukasten aufgebaut werden. Beim Schichtenmodell besteht das Projektergebnis aus mehreren, aufeinander aufbauenden Schichten. Jede Schicht greift auf Funktionen der darunter liegenden Schicht zurück und stellt selbst Funktionen für die darüber liegende Schicht zurück. Diese Art der Produktstrukturierung wird z. B. bei der Softwareerstellung, beim Aufbau von Kommunikationssystemen und bei Rechnersystemen vielfach angewendet. Unter einem Prototyp versteht man eine einfache Objekt-Realisierung, die nur einen bestimm-ten, in der Regel besonders wichtigen Aspekt eines Objekts realisiert und viele andere Details weglässt. Das Prototypenmodell unterteilt das Projektergebnis daher in mehrere Konkretisie-rungsstufen, die bei einem groben, abstrakten Prototyp beginnen und diesen schrittweise ver-feinern und konkretisieren. Die Gliederung des Projektergebnisses in mehrere Teile, eröffnet die Möglichkeit, das Projekt iterativ zu durchlaufen und in jeder Iteration ein Teilergebnis zu realisieren. Jedes Produktmo-dell eignet sich für iterative Projektdurchläufe. Eine Iteration erzeugt dann entsprechend eine Komponente, eine Schicht oder einen Prototyp. Je nach Abhängigkeit der Einzelergebnisse sind mehr oder weniger starke Überlappungen der einzelnen Iterationen möglich. Durch die Aufteilung der 4 Prozesse ergeben sich zusätzliche Freiheitsgrade bei der Organisa-tion des Projektablaufs in iterativer Form (Bild 4-13). Im einfachsten Fall laufen sowohl die Iterationen als auch die Teilprozesse rein sequentiell ab (iss). Die Projektdurchlaufzeit wird zwar dadurch nicht verringert, aber es liegen viel früher bereits überprüfbare Teilergebnisse vor. Der Projektfortschritt ist dadurch besser zu kontrollieren. Außerdem werden Fehler früher festgestellt und verursachen dadurch geringere Kosten. Ein typisches Beispiel für diese Ab-laufform ist das so genannte Spiralmodell, das später ausführlich behandelt wird. Wenn innerhalb einer Iteration die Teilprozesse parallelisiert werden, die Iterationen aber wei-terhin sequentiell ablaufen, erhält man eine Ablaufstruktur wie sie z. B. beim agilen Projekt-management der Scrum-Methodik verwendet wird (ips). Man erreicht eine deutliche Verkür-zung der Laufzeit und kann die Komplexität trotzdem überschaubar halten, da es weiterhin abgegrenzte Projektphasen gibt. Dies ist bei der nächsten Struktur nicht mehr der Fall. Hier wird zwar innerhalb jeder Iteration sequentiell gearbeitet, aber die Iterationen überlappen sich (isp). Die kürzeste Durchlaufzeit wird bei doppelter Parallelisierung erreicht: sowohl die Teil-prozesse innerhalb einer Iteration, als auch die Iterationen selbst laufen überlappend ab (ipp).


sequentiell

parallel

Einheit PrototypenSchichtenKomponenten

iterative Durchläufeeinmaliger Durchlaufz.B. Wasserfallmodell

z.B. SimultaneousEngineering

z.B. Scrum

z.B. Spiralmodell

Projekt-ergebnis

Projekt-ablauf

AnEn

ReVa iss

ips

isp

ipp

AnEn

ReVa

Bild 4-13 Modelle für Projekt-Ablaufstrukturen

Das Prototypenmodell erfordert in der Regel eine sequentielle Abarbeitung der Iterationen. In den einzelnen Iterationen entstehen Projektergebnisse mit zunehmendem Konkretisierungs-grad. In der ersten Iteration werden die Prozesse Analyse, Entwurf, Realisierung und Validie-rung relativ schnell und grob durchlaufen. Das Ergebnis ist ein Prototyp, der nur die wichtigs-ten Merkmale des angestrebten Ergebnisses zeigt. Beispiele hierfür findet man in allen Berei-chen: als einfache, verkleinerte Modelle („Holzmodelle“) in der Architektur oder im Maschi-nebau, als Platinen mit „fliegender Verdrahtung“ in der Elektronik oder als Software, die nur die Benutzerinteraktion ohne weitergehende Verarbeitungsfunktionen realisiert. In darauf fol-genden Iterationen können weitere, konkretere Prototypen aufgebaut werden, bis man schließ-lich im letzten Schritt beim vollständigen Projektergebnis angelangt. Die Zahl der Iterationen kann dabei je nach Projekt variieren. In der Regel werden 2 oder 3 Iterationen genügen.

Beispiel 4-12 DeLorean DMC-12 Anfang der 70er Jahre hatte John DeLorean die Idee, ein Fahrzeug zu entwickeln, das den höchsten zu dieser Zeit bekannten Sicherheitsstandards genügen und dabei aber ein sport-liches Aussehen haben sollte. Trotz vieler Probleme konnte das Auto als Ergebnis eines fast 7 Jahre dauernden Entwicklungsprojekts in Serie produziert werden. Das Projekt wur-de in mehreren Iterationen entwickelt (Bild 4-14). In einem ersten Durchlauf wurden die Ideen gesammelt und ein Grundkonzept entworfen. Wichtige Fragen zum Antriebskonzept wurden anhand des „Red Rocket“ genannten Ver-suchsfahrzeugs geklärt, das aus verfügbarer Teilen aufgebaut wurde (u. a. ein Fiat X1/9, ein Motor von Ford und ein Getriebe von Borg Warner). Parallel dazu wurde ein Holzmo-dell im Maßstab 1:1 als Design-Studie hergestellt.


Konzept Red Rocket 1. DMC-Prot. Serienprod.

Holzmodell

2. DMC-Prot. Lotus-Prot. Pre-Prod.-Car

1/74 1/75 10/75 12/77 7/78 12/79 10/80

1. Iteration 6. Iteration2. Iteration 3. Iteration 4. Iteration 5. Iteration

Bild 4-14 Projektplan DeLorean DMC12

In der nächsten Projektiteration entstand ein erster DMC-12-Prototyp mit einem Motor von Citroen, der sich aber als zu schwach heraus stellte. Im zweiten Prototyp wurde das Konzept des Mittelmotors zugunsten eines Heckantriebs aufgegeben. Für die Weiterent-wicklung zur Serienreife wurde eine Verbindung mit Lotus eingegangen. Dabei wurden viele der ursprünglichen Ideen über Bord geworfen und auch der Chefentwickler von DeLorean warf wegen gravierender Dissonanzen mit Lotus das Handtuch. In der letzten Iteration wurde schließlich ein Pre-Production-Car entwickelt, womit das Projekt nach 6 Iterationen erfolgreich abgeschlossen wurde. Anzumerken bleibt noch, dass insgesamt 8583 Fahrzeuge in Serie hergestellt wurden. Aufgrund von Qualitätsmängeln in der Serienproduktion und daraus resultierender finan-zieller Probleme musste die Firmen nach nur 2 Jahren ihre Geschäftstätigkeit beenden. (Eine interessante, detaillierte Beschreibung mit Photos ist zu finden auf [DeLorean.de]).

Der Vorteil des Prototypenmodells besteht darin, dass die kritischen Fragen bezüglich des Projektgegenstands als erstes überprüft werden, bevor Aufwand in die Detailarbeit gesteckt wird. Sind in der Aufgabenstellung oder im gewählten groben Lösungsgedanken grundlegende Fehler enthalten, so fallen diese schon sehr früh auf. Die Fehler können dann mit überschauba-rem Aufwand behoben werden. Falls erforderlich kann das Projekt auch in einer frühen Phase abgebrochen werden, wodurch der Schaden immerhin begrenzt bleibt.

Problem A0

E0

R0

V0 val. Lösung

Zeit

A1

E1

R1

V1

Prototyp

Bild 4-15 Iterativer Ablauf mit einem Prototyp als Zwischenergebnis


In der Literatur ist diese Form der Ablauforganisation auch als Spiralmodell bekannt [Boehm 1988]. Der Ursprung dieses Namens wird anschaulich klar, wenn man den Ablauf nicht linear über einer Zeitachse aufträgt, sondern in einem Ursprung beginnend spiralförmig nach außen. Dabei stellt jede Umdrehung einen vollständigen Teilablauf dar.

AA

EE

RR

R

VV

V

A0

E0

0

0

1

11

1 2

22

2

Bild 4-16 Spiralförmiger Ablauf mit mehreren iterativen Durchläufen

Das Spiralmodell nutzt eine auf dem Pareto-Prinzip basierende Erkenntnis aus vielen prakti-schen Projekten: In jedem Teilprojekt und jeder Projektphase gibt es wichtige Arbeiten mit weit reichenden Konsequenzen und weniger kritische Fleiß-Arbeiten. Die Entwurfsentschei-dungen in den frühen Projektphasen führen zu einer weitgehenden Festlegung des Aufwands für die folgenden Arbeiten. Außerdem haben Fehler, die in solchen Arbeiten gemacht und erst in späten Projektphasen bemerkt werden, viele verlorene Arbeiten und somit erhöhten Auf-wand zur Folge. Führt man einen vollständigen Zyklus zuerst für die kritischen Arbeiten durch und erst anschließend die Fleiß-Arbeiten, kann man das Fehlerrisiko reduzieren. Da beim Spi-ralmodell nur die Reihenfolge der Arbeiten geändert wird, diese aber nach wie vor sequentiell ausgeführt werden, ändert sich die Projektlaufzeit nicht. Tabelle 4.5 fasst die wesentlichen Merkmale der bekanntesten Ablaufmodelle zusammen.

Tabelle 4.5 Vergleich der Grundmodelle der Ablauforganisation

Kriterium Wasserfallmodell Spiralmodell Scrum Simultaneous Engineering

Ablauf sequentiell iterativ iterativ parallel

Phasentrennung ausgeprägt schwächer schwächer fehlt

Durchlaufzeit lang lang kürzer kurz

Feststellung von Fehlern Spät früher Früher Spät

Aufwand für Planung … … und Kommunikation

gering mittel niedrig hoch

hoch

Die beschriebenen Modelle des Projektablaufs stellen Grundformen dar, die nicht immer in Reinform auftreten. Je nach Anforderungen können die verschiedenen Strukturmerkmale mit-einander kombiniert werden. So ist es z. B. möglich, die Analyse eines Problems und die Suche

4.3 Organisation der Informationsflüsse 115

nach möglichen Lösungen sequentiell auszuführen, danach zwei oder drei mögliche Lösungen parallel durch konkurrierende Arbeitsgruppen ausarbeiten zu lassen und dann die ausgewählte Lösung so weit wie möglich parallel zu realisieren.

4.3 Organisation der Informationsflüsse Information verhält sich zum Wissen wie eine handvoll Sand zu den Pyramiden von Gizeh. Im Laufe eines Projekts fallen sehr viele Informationen an, die von ganz unterschiedlicher Bedeutung sein können.

Beispiel 4-13 Projektinformationen „Wir haben den Auftrag für das Projekt erhalten.“ „Die Software ist so gut wie fertig.“ „Das Arbeitspaket muss bis zum 30.9. abgeschlossen werden.“ „Der Test des Prototyps ist erfolgreich abgeschlossen worden.“ „Wiesemann hat am Samstag ein Tor geschossen.“ „Die Projektbesprechung ist auf 9:30 Uhr vorverlegt worden.“ „Die Lieferung der CPU-Baugruppe wird sich um 4 Wochen verzögern.“ „Theisen hat sich beim Fußballspielen einen Kreuzbandriss zugezogen.“ „Wenn beim Test alles glatt geht, können wir den Terminplan noch einhalten.“

Bei weitem nicht immer ist die Wichtigkeit oder Unwichtigkeit einer Information so offen-sichtlich wie in diesen einfachen Beispielen. Für ein Gelingen des Projekts ist es eine wichtige Voraussetzung, alle relevanten Informationen zu erfassen, zu speichern und den Projektbetei-ligten zugänglich zu machen. Dies ist die Aufgabe des Informationsmanagements. Damit beim Entstehen von Information nicht immer individuell entschieden werden muss, was mit dieser Information gemacht wird, sollten die Regeln der Erfassung, Kommunikation und Speicherung von Informationen vor Projektbeginn festgelegt werden.

4.3.1 Information, Kommunikation, Dokumentation Von einer Information bzw. einem Informationsgewinn spricht man, wenn jemand Kenntnisse über den Wert eines Sachverhalts erlangt. Der Informationsgewinn ist umso größer, je seltener und unwahrscheinlicher ein Sachverhalt ist. Informationen können in sehr unterschiedlicher Form dargestellt und als Daten gespeichert werden. Dieser theoretische Informationsbegriff verwendet nur den Kenntnisstand des Informations-empfängers. Die Relevanz einer Information wird nicht berücksichtigt. Daher hat die Informa-tion „unsere Fußballmannschaft hat gewonnen“ und die Information „wir haben den Projekt-auftrag bekommen“ den gleichen Informationsgehalt, nämlich genau 1 Bit. Grundsätzlich könnte man natürlich argumentieren, dass in einem Projekt jede Information relevant sein kann und deshalb erfasst, kommuniziert und gespeichert werden muss. Die in den letzten Jahrzehnten rasant gestiegenen Möglichkeiten der Informationserfassung, der Kommu-nikation und der Datenspeicherung scheinen dies auch technisch möglich zu machen. Dass es aber auch beim Umgang mit Informationen notwendig geworden ist, auf Effizienz zu achten, wird jeder bestätigen, der täglich in einer Flut von Anrufen, SMS-Nachrichten, E-Mails, Besprechungsnotizen, Berichten, Zeitungs- und Zeitschriftenartikeln zu ertrinken droht.


Aus praktischer Sicht muss jede Information neben ihrem Gehalt auch auf ihre Relevanz über-prüft werden. Als nächstes stellt sich die Frage, wie mit einer relevanten Information im Rahmen eines Pro-jektes umzugehen ist. Neu entstehende Informationen, wie z. B. die Stornierung einer Liefe-rung per E-Mail, die telefonische Krankmeldung eines Mitarbeiters oder einer Entscheidung im Rahmen einer Projektbesprechung müssen an die richtigen Adressaten kommuniziert und eventuell gespeichert werden. Da der Umgang mit Informationen in einem Projekt einerseits nicht für jede Information ein-zeln festgelegt werden kann, andererseits auch nicht jedem Beteiligten frei gestellt werden kann, müssen im Rahmen der Projektorganisation Informationskategorien gebildet und allge-meingültige Regeln für jede Kategorie festgelegt werden. Informationsgewinn findet nur statt, wenn jemand von der Information Kenntnis erlangt. Daher bildet die Weitergabe der Informationen an die richtigen Empfänger – die Kommunikation – einen bedeutenden Bestandteil des Informationsmanagements. Die technischen Kommunikati-onsmöglichkeiten sind heute vielfältig, angefangen von Besprechungen, über Telefonate, Vi-deokonferenzen, E-Mails, bis hin zu internetbasierten Diensten und Datenbanken. Wichtiger als die Frage des Kommunikationskanals ist der Ablauf für den Umgang mit Informationen. Bei einer eher unwichtigen Information kann es ausreichen, die Information selbst oder einen Hinweis auf ihre Ablage in einer Datenbank zu versenden, ohne weitere Aktivitäten zu veran-lassen. Bei wichtigen Informationen genügt dies nicht. Hier sollte der Empfang durch eine Rückmeldung quittiert werden, um erstens sicher zu sein, dass die Information angekommen ist und um zweitens die Weitergabe dokumentiert zu haben. Neben derartigen Basisregeln, kön-nen die Kommunikationsabläufe im Rahmen der Projektorganisation noch viel detaillierter geregelt werden. Hierzu gehören z. B. Festlegung der zu informierenden Personen, Festlegun-gen über einzuhaltende Zeitfenster bei der Kommunikation.

Beispiel 4-14 Informationskategorien Die folgende Einteilung bildet 5 Informationskategorien, die sich nach ihrer Wichtigkeit bzw. Auswirkung auf das Projekt unterscheiden.

Tabelle 4.6 Bildung von Informationskategorien

Kat. Art der Information Zu informieren: Reaktion I1 Informationen, die den Erfolg des

gesamten Projekts gefährden können Auftraggeber + Projektleiter

Krisensitzung mit Auf-traggeber

I2 Informationen, die eine Verzögerung oder Mehraufwand nach sich ziehen

Auftraggeber + Projektleiter

Projektinterne Krisen-sitzung

I3 Informationen, die das gesamte Pro-jektteam betreffen

Projektleiter + gesamtes Team

Auf regelmäßiger Projekt-sitzung behandeln

I4 Informationen, die mehrer Projektbe-teiligten betreffen

Projektleiter + alle Betroffenen

Besprechung der Betrof-fenen

I5 Informationen, die nur einen Projekt-beteiligte betreffen

Betroffener Bearbeitung durch Betrof-fenen

Für jede Kategorie muss festgelegt werden, wer zu informieren ist, wenn ein solches In-formationsereignis eintritt und was zu tun ist. Mögliche Reaktionen reichen vom Weiter-


leiten der Information an die Betroffenen, über die Einberufung einer Projektsitzung bis zu einem Krisengespräch mit dem Auftraggeber. Denkbar ist auch, in der IMV-Matrix bei der Informationspflicht die Kategorie der Infor-mation (I1-I5) zu berücksichtigen.

Der dritte grundlegende Baustein des Informationsmanagements ist die Dokumentation, d. h. die dauerhafte Ablage der Informationen für einen späteren Zugriff. Ein Dokument ist eine formale und dauerhafte Zusammenfassung von Informationen. Dokumente können in Papier-form (p-Dokument) oder in elektronischer Form (e-Dokument) vorgelegt werden. Inhaltlich können Texte, Grafiken, Listen und Tabellen unterschieden werden. Wird ein Dokument frei-gegeben bzw. veröffentlicht, darf es danach nicht mehr geändert werden. Damit notwendige Änderungen nachvollziehbar bleiben, müssen sie entweder über eine Versionierung oder über Änderungsmitteilungen gehandhabt werden. Bei der Versionierung erhält jedes geänderte Dokument eine neue Versionsnummer. In einer neuen Version des Dokuments können Infor-mationsbausteine beibehalten, entfernt oder hinzugefügt werden. Versionsnummer können hierarchisch gegliedert werden (Beispiel: Lastenheft Version 1.3). Änderungsmitteilungen sind nur bei kleinen und wenigen Änderungen zu empfehlen, da sonst zu viele einzelne Ände-rungsmitteilungen anfallen und die Übersicht verloren geht. Größere und viele Änderungen sind übersichtlicher in Form versionierter Dokumente zu hand-haben. Die neueste Dokumentenversion zeigt den aktuellen Stand im Zusammenhang, zurück-liegende Versionen werden nur bei Betrachtung der Entstehungsgeschichte gebraucht.

4.3.2 Informationsmanagement Das Informationsmanagement hat sich in den letzten Jahrzehnten durch die Einführung der elektronischen Datenverarbeitung rasant gewandelt. Dieser Wandel ist bei weitem noch nicht abgeschlossen, sondern befindet sich möglicherweise noch in einer frühen Phase. Während vieler Jahrzehnte wurden Informationen ausschließlich in Papierform dokumentiert. Die Ablage erfolgt in Mappen, Ordnern, Regalen, Schränken etc. Die Suche nach Informatio-nen war ein aufwändiges und nicht selten vergebliches Unterfangen. Durch die Einführung von Rechnern konnten Informationen auch in elektronischer Form er-stellt, verteilt und gespeichert werden. Dadurch nahm der Informationsfluss sowohl in der Menge als auch in der Fließgeschwindigkeit deutlich zu, weshalb oft der Eindruck einer Infor-mationsflut entsteht. Die systematische Ablage und das zielgerichtete Wiederfinden der Informationen konnten mit der Verbreitungsgeschwindigkeit nicht mithalten. Die Ablage der Daten erfolgte zunächst als elektronische Dokumente auf verschiedenen, persönlichen Rechnern. Das Wiederfinden der Dokumente hing sehr stark vom Einzelnen ab. Einen ersten Fortschritt brachte die Verbindung von Rechnern in Netzen. Die Ablage der Dokumente auf zentralen Netz-Laufwerken, ermög-lichte jedem berechtigten Beteiligten Zugang zu den Dokumenten und sorgte für eine (oft be-scheidene) Vereinheitlichung der Ablagesystematik. Die Zugriffsproblematik wurde durch Einführung von zentralen Dokumenten-Servern verbessert. Nicht nur in einem Projekt, sondern auch bei den vielen Routineaufgaben, die ohne Projekte in Unternehmen ausgeführt werden, fallen vielfältige Dokumente an. Aus diesem Grund hat sich das Dokumentenmanagement als eigenständige Aufgabe etabliert. Besitzt ein Unternehmen ein Dokumentenmanagementsystem (DMS), so können die im Projekt anfallenden Dokumente in diesem System gehandhabt werden.


Dabei sind unter anderem folgende Fragen zu beantworten: Wie und wo erfolgt die Ablage der Dokumente? Wer darf auf welche abgelegten Dokumente (lesend) zugreifen? Wie wird der Zugriff geschützt? Wie wird die Suche (nach abgelegten Dokumenten) unterstützt? Wie erfolgt die Sicherung (abgelegter Dokumente)?

Ein erster, einfacher Ansatz zur Beantwortung der Fragen könnte sein, alle Informationen als wichtig einzustufen, sie an alle Beteiligten zu kommunizieren und auch zu dokumentieren. Zwar würde man dadurch sicherstellen, dass keine Information verloren geht, aber zum einen wäre, aufgrund der Vielzahl anfallender Informationen der Aufwand enorm. Außerdem tritt bei den Beteiligten eine solche Informationsüberflutung ein, dass „vor lauter Bäumen der Wald nicht mehr gesehen wird“ oder einfacher gesagt, dass bei der Flut von Informationen die wich-tigen übersehen werden. Man kommt also nicht umhin, zunächst die Wichtigkeit einer Information zu bewerten, dann die Projektbeteiligten zu identifizieren, die diese Information benötigen und schließlich, Art der Dokumentation und Ort der Dokumentenablage zu bestimmen.

4.3.3 Informationsmanagement im Projekt Jede Aktivität in einem Projekt besitzt Input und Output. Neben materiellem Input und Output sind Dokumente die wichtigsten Ein- und Ausgänge einer Aktivität. Daher muss für jede Pro-jektaktivität festgelegt sein, welche Informationen und Dokumente als Eingang und als Aus-gang zu einer Aktivität gehören. Entsprechend der zeitlichen Abfolge eines Projekts kann man folgende Dokumentenarten un-terscheiden: Auftragsdokumente Organisationsdokumente Planungsdokumente Steuerungsdokumente Abschlussdokumente

Die Auflistung erhebt keinen Anspruch auf Vollständigkeit. Bei der Vielfalt der Projekte und Dokumente ist dies gar nicht möglich. Vielmehr soll die Auflistung als ein Grundvorrat benö-tigter Dokumente angesehen werden, dereine Überprüfung im konkreten Projekt ermöglicht und zur Erzeugung weiterer, benötigter Dokumente anregen soll. Daneben gibt es in jedem Projekt eine mehr oder weniger geordnete Sammlung von Daten, die während des Projekts anfallen. Hierzu zählen z. B. Notizen, E-Mails, Memoranden etc. Diese Daten können wichtige Informationen tragen, ohne dass sie adäquat dokumentiert sind. In Anlehnung an die dunkle Materie im Weltall, könnte man hier von dunkler Information spre-chen: sie ist nicht sichtbar aber aufgrund ihrer Schwerkraft immer wirksam. Alle Dokumente, die in einem Unternehmen und damit auch in einem Projekt erstellt werden, sollten gewisse Mindestanforderungen an einen einheitlichen formalen Aufbau und an den Inhalt erfüllen. Außerdem sollte jede Seite eines Dokuments in der Kopf- oder Fußzeile ein-heitliche Rahmendaten enthalten, wie Seitennummer, Dokumententitel und Datum. Folgende Informationen sollten zu den Dokumentenstammdaten gehören:


Titel/Thema des Dokuments Anlass/Zweck/Art des Dokuments Angaben zum Verfasser Verteiler (Lese-Verpflichtete, Lese-Berechtigte) Erstellungs-/Freigabe-Datum Stichworte, die für das Suchen, Filtern und Sortieren verwendet werden können Gliederungsmerkmale, die zur hierarchischen Einordnung des Dokuments dienen

Bild 4-17 Dokumentenarten in einem Projekt (F: Formular im Anhang)

Alle Projektdokumente sollten darüber hinaus auch eine kurze Angabe der wichtigsten Projekt-stammdaten enthalten. Hierzu gehören: Projektbezeichnung Projektidentifikation (Kürzel, Nummer) Projektleiter

Auf alle weiter gehenden Informationen zum Projekt kann dann über die Projektidentifikation zugegriffen werden. Zur Unterstützung eines einheitlichen Aufbaus und eines vollständigen Umfangs der Dokumente, sollte es eine entsprechende Vorlage geben. Außerdem sollte für jede spezielle Dokumentenart ein eigenes Formular erstellt und zum Bestandteil des Projekt-handbuchs gemacht werden. Verschiedene Muster-Formulare sowie Hinweise zum Ausfüllen derartiger Formulare sind im Anhang zu finden.

AuftragsdokumenteAnfrage

OrganisationsdokumenteOrganigramm

Planungsdokumente Steuerungsdokumente

Abschlussdokum.AbschlussberichtAnalyse

Entwurf+

Realisierung

Validierung+

allgemeine Projektdokumente

LastenheftPflichtenhaftAngebotProjektauftragProjektantragProjektdefinition (F)Kalkulationsunterlagen

Liste der ProjektbeteiligtenBesprechungsberichte (F)Statusberichte (F)To-Do-Listen (F)

PM-Handbuch

Arbeitspaket-

ProduktstrukturplanProjektstrukturplanTerminplan

Risikoregister

KapazitätsplanPersonaleinsatzplan

Ressourcenregister

ÜbergabeprotokollNachkalkulation

Projekt-Daten-Sammlung"dunkle Information"

Beschreibungen

Meilensteinliste

ÄnderungsanträgeLeistungsmessungFortschrittsberichte

Lessons Learned

ChecklistenQM-Handbuch

Anforderungs-Doku.

div. Management-Pläne,z.B. Proj.-MP, Term.-MP, Qual.-MP

Komm.-MP, Besch.-MP


Im Rahmen eines Projekts fallen nicht nur eine ganze Menge von Informationen an, sondern auch sehr vielfältige Dokumententypen. Ohne Anspruch auf Vollständigkeit sollen hier exemp-larisch einige wichtige Dokumententypen skizziert werden. Ein Logbuch stellt die einfachste Form der Dokumentation von stetig anfallenden Informatio-nen dar. Ein Logbuch wird von einer Person geführt, die darin alle Gedanken, Ideen, Gesprä-che und auch deren Ausarbeitung enthält. Die Informationen werden in der zeitlichen Reihen-folge ihres Auftretens in ein gebundenes, fortlaufend nummeriertes Buch eingetragen. Wegen fehlender formaler Anforderungen sind Logbücher sehr einfach zu führen. Dies hat aber auch Nachteile. Hierzu zählen die fehlende Gliederung und eine aufwändige Suche nach bestimmten Stichworten. Trotz dieser Nachteile sind Logbücher aber immerhin besser als gar keine Doku-mentation. Die Informationen sind festgehalten, nachträgliche Eintragungen sind nicht mehr möglich bzw. zumindest nicht erlaubt und Informationen können nicht entfernt werden (Sei-tenzahlen!). Sie eignen sich daher vorwiegend als individuelle Informationssammlungen der einzelnen Projektbeteiligten. Für die Projektdurchführung ist die To-Do-Liste eine sehr wichtige Dokumentenart. In ihr werden für eine Person, für eine Gruppe von Personen oder für alle Projektbeteiligten die aus-zuführenden Aufgaben in Form einer Liste oder Tabelle zusammengefasst. Jeder Eintrag ent-hält eine auszuführende Aufgabe, eine verantwortliche Person und einen Zieltermin. Weitere Angaben können den Erledigungsstatus (z. B. offen, in Arbeit, erledigt), den geplanten Beginn, den Aufwand oder die Priorität beschreiben. Eine vergleichbare Aufgabe und einen ähnlichen Aufbau hat eine „Liste offener Punkte“ (LOP). In ihr werden verschiedene kleinere Aufgaben gesammelt, die nicht als Arbeitspakete im Projektplan auftauchen. Auch hier gehören zu jeder Aufgabe eine verantwortliche Person, ein Termin und ein Status. Eine Notiz wird verfasst, wenn ein informationell relevantes Ereignis auftritt und die entstan-denen Informationen nachvollziehbar weiter gegeben und dauerhaft gespeichert werden sollen. Hierbei kann es sich z. B. um eine Telefonnotiz, eine Aktennotiz oder eine Gesprächsnotiz handeln. Ein Bericht wird aus unterschiedlichen Anlässen verfasst. Ein Bericht wird immer anlässlich eines bestimmten Ereignisses verfasst. Er sollte nach der Erstellung bzw. Freigabe später nicht geändert werden können. Von einer Notiz unterscheidet sich ein Bericht nicht nur im Umfang, sondern es werden vor allem höhere formale Anforderungen gestellt. Jede Besprechung sollte z. B. in Form eines Berichts dokumentiert werden. Statusberichte werden zu festgelegten Ter-minen verfasst, z. B. als Meilensteinreport nach Abschluss einer bestimmten Projektphase. Von besonderer Bedeutung ist natürlich der Projektabschlussbericht. Ein Besprechungsbericht sollte die wichtigen Inhalte einer Besprechung dokumentieren. Dies kann entweder als kurzes Ergebnisprotokoll oder ausführlicher als Wiedergabe der Diskussion und unterschiedlicher Standpunkte erfolgen. Typische Informationsarten sind Aufträge (wer, was, bis wann), Beschlüsse und Informationen. In einem Projekt sollte es keine Besprechung ohne einen Bericht geben. Statusberichte werden zu festgelegten Zeitpunkten (z. B. periodisch oder an Meilensteinen) verfasst. Sie fassen die Aktivitäten und Ergebnisse des abgelaufenen Zeitraums zusammen und machen Aussagen über den Projektstatus hinsichtlich Produkt, Auf-wand, Kosten und Terminen.


Beispiel 4-15 Fallbeispiel „CAD-Software“, Besprechungsbericht Der Screenshot in Bild 4-18 zeigt einen Besprechungsbericht, der mit Hilfe des Formulars aus dem Anhang erstellt wurde.

Bild 4-18 Screenshot eines Besprechungsberichts

Neben den grundlegenden Angaben, die in jedem Projektdokument enthalten sein sollten, sind im Bericht die wichtigen Ergebnisse der Besprechung festgehalten. Bei jedem Ergeb-nis wird kenntlich gemacht, ob es sich um eine Information, einen Beschluss oder einen Auftrag handelt. Bei allen Aufträgen muss die verantwortliche Person und ein Erledi-gungstermin angegeben werden.

Checklisten sind standardisierte Listen für bestimmte Aktivitäten. Die Aktivitäten, die für eine bestimmte Aufgabe normalerweise benötigt werden, sind in der Checkliste gesammelt. Wird eine entsprechende Aufgabe bearbeitet, werden die einzelnen Punkte der Checkliste abgehakt. Checklisten stellen sicher, dass nichts vergessen wird. Die Standardisierung erleichtert die Übersicht bei verschiedenen Projekten und Beteiligten. Ein Nachteil entsteht, wenn eine Checkliste zu allgemeingültig angelegt wird. Sie wird dadurch umfangreich und enthält viele Punkte, die im Einzelfall nicht nötig sind.


Eine Ressourcentabelle enthält alle für das Projekt benötigten und zur Verfügung stehenden Ressourcen mit ihren Ausstattungs- und Verfügbarkeitsmerkmalen. In einer Personaltabelle werden alle Personen aufgelistet, die am Projekt beteiligt sind (alle Stakeholder). Für die Per-sonen kann es viele Attribute geben. Personaltabellen enthalten nur Informationen über einzel-ne Personen; Beziehungen zwischen verschiedenen Personen werden hier nicht beschrieben. Das Ergebnis der Analyse- und Entwurfsphase eines Projekts sind vielfältige Planungsdoku-mente. Hierzu gehören der Produktstrukturplan, der Projektstrukturplan, Testpläne, Ressour-ceneinsatzpläne, Personaleinsatzpläne, Kostenpläne. Die Pläne können in der Form von Tabel-len bzw. Listen verfasst sein. Übersichtlicher sind graphische Darstellungen in Form von Netz-plänen und Ablaufplänen.

4.4 Das Projektmanagement-Handbuch „Ein Buch ist wie ein Spiegel: Wenn ein Affe hinein schaut, kann kein Apostel herausblicken.“ (G.C. Lichtenberg) Gemäß der Definition zu Beginn des Kapitels versteht man unter Projektorganisation die Schaffung von Regeln, durch die die Arbeit der Beteiligten auf die Projektziele ausgerichtet wird. Im Wesentlichen gehören hierzu die Regeln für die personellen Weisungsbefugnisse, die Regeln für den Ablauf der Arbeitsprozesse und die Regeln für die Informationsflüsse. Zur Vermeidung unnötiger Reibungsverluste während der Durchführung eines Projekts ist es wichtig, diese Regeln zu Projektbeginn zu definieren und dauerhaft einzuhalten. Projekte, bei denen es diese Regeln nicht gibt, führen früher oder später zu Problemen. Diese können sich sehr vielfältig äußern, wie z. B. in personellem Weisungswirrwarr zwischen Projekt- und Li-nien-Vorgesetzten, im Festfahren des Projekts in permanent sich wiederholenden Schleifen von Fehlern, Notlösungen und neuen Fehlern oder im vergeblichen Suchen nach nicht auffindbaren Dokumenten. Trotz sehr unterschiedlicher Erscheinungsformen, haben derartige Probleme fast immer eine systematische Ursache: mangelnde Projektorganisation. Immer wieder werden bestimmte Erklärungen für fehlende oder lückenhafte organisatorische Festlegungen in Projekten herangezogen, wie z. B. „Zeitdruck“, „zu viel Aufwand“ oder „un-nötiger Formalismus“. Angesichts der vielen Nachteile sind diese Ausreden aber nicht akzep-tabel. Außerdem lassen sich die Erklärungen mit Hilfe eines Projekthandbuchs entkräften. Werden in einem Unternehmen, das in einer bestimmten Branche und in einem bestimmten Marktsegment tätig ist, öfter Projekte durchgeführt, so ist es wahrscheinlich, dass die Projekte, auch wenn sie sich fachlich voneinander unterscheiden können, viele organisatorische Gemein-samkeiten aufweisen. Es ist daher sinnvoll, die Regeln der Projektorganisation für eine ganze Reihe von Projekten, eventuell sogar für alle Projekte des Unternehmens einheitlich festzule-gen. Sie können dann in Form eines Handbuchs dokumentiert werden. Laut DIN 69905 ist das Projektmanagement-Handbuch (PM-Handbuch) eine "Zusammen-stellung von Regelungen, die innerhalb einer Organisation generell für die Planung und Durch-führung von Projekten gelten." Diese allgemeingültigen organisatorischen Regeln werden nicht nur für ein einziges Projekt aufgestellt, sondern gelten für alle Projekte in einem Unternehmen. Außerdem enthält das PM-Handbuch vereinheitlichte Vorlagen für zu verwendende Dokumen-te. Ein umfangreiches Beispiel findet man in [Hilpert 2001, S. 181]. Der Aufwand für die Erstellung eines PM-Handbuchs wird durch die erreichbaren Vorteile mehr als wettgemacht. Ist das Handbuch erst einmal erstellt, kann bei jedem Projekt darauf

4.4 Das Projektmanagement-Handbuch 123

zurückgegriffen werden. Die Organisation für ein neues Projekt reduziert sich dadurch auf einige wenige Entscheidungen, wie z. B. die Auswahl der passenden Aufbau- und Ablauforga-nisation aus den im Handbuch aufgelisteten Standard-Organisationsformen. Die Verwendung eines PM-Handbuchs verringert auch die Gefahr, dass Projekte ohne entsprechende organisato-rische Regelungen begonnen werden.

AblauforganisationPM-Handbuch

Informationsorganisation

Aufbauorganisation

Projekt-organisation

Bild 4-19 PM-Handbuch als Output der Projektorganisation

Beispiel 4-16 Zusammensetzung eines PM-Handbuchs Die folgende Auflistung stellt den Aufbau und die Gliederung eines exemplarischen Pro-jektmanagement-Handbuchs dar. Das Handbuch wurde bei den Steinbachwerken im Laufe zahlreicher Projekte erstellt und wird stetig weiter gepflegt. Es ist ein Bestandteil des Qua-litätsmanagements. Seine Anwendung wird bei den regelmäßig stattfindenden Audits zur Bestätigung der Zertifizierung nach ISO 9000 überprüft.

1. Einleitung 1.1 Aufgaben und Anwendungsbereich des Handbuchs 1.2 Begriffsklärungen 1.3 Versionen des PM-Handbuchs

2. Projektgründung 2.1 Anforderungen an das Lastenheft 2.2 Aufgaben und Aufbau des Pflichtenhefts 2.3 Grundlagen für die Projektkalkulation

3. Aufbauorganisation 3.1 Aufgaben, Verantwortungen und Befugnisse der Projektbeteiligten und Gremien 3.2 Vorgesehene Formen der Aufbauorganisation 3.3 Festlegungen für die Teamarbeit 3.4 Regeln für die Kommunikation im Projekt 3.5 Regeln für die Dokumentierung und Dokumentenablage

4. Projektplanung 4.1 Anforderungen an den Produktstrukturplan 4.2 Anforderungen an den Projektstrukturplan 4.3 Muster eines Standard-Projektstrukturplans 4.4 Anleitung und Regeln für die Aufwandsschätzung 4.5 Festlegung der Methoden für die Ablauf- und Terminpläne 4.6 Vorgehensweise für die Risikoanalyse

5. Projektsteuerung 5.1 Aufgabe der Projektkontrolle 5.2 Einzusetzende Methoden der Fortschrittsanalyse 5.3 Korrekturmaßnahmen


6. Projektabschluss 6.1 Arbeitsschritte des Projektabschlusses 6.2 Festlegung der Projektauswertung

Anhang: Checklisten, Formulare

Die Einleitung legt die grundlegenden Randbedingungen für die Anwendung des Hand-buchs fest. Danach werden die notwendigen Arbeiten und die Anforderungen an die Do-kumente beschrieben, die zu Beginn eines Projekts benötigt werden. Da das Handbuch für alle Arten von Projekten im Unternehmen gültig ist, werden die möglichen Formen der Aufbauorganisation beschrieben, aus der im konkreten Projekt eine Organisationsform ausgewählt wird. Das nächste Kapitel legt die Anforderungen an die Pläne, sowie die Re-geln für die Arbeitsschritte der Planerstellung fest. Danach werden der Aufgabenbereich und die Methodik für die Überwachung und Steuerung des Projektablaufs festgelegt. Das letzte Kapitel behandelt die Regeln für den Projektabschluss. Der Anhang des PM-Hand-buchs enthält alle Checklisten und einheitliche Vorlagen für alle Projektdokumente.

4.5 Repetitorium

4.5.1 Zusammenfassung Als Projektorganisation bezeichnet man ein System von Regeln, durch die die Arbeit der Betei-ligten auf die Ziele des Projektes ausgerichtet wird. Die Aufbauorganisation beschreibt, wie sich ein Projektteam in einer bestehenden Unterneh-mensorganisation einfügt. Insbesondere regelt sie die Befugnisse der Projektleitung und grenzt sie gegenüber den Befugnissen der Linienmanager ab. Die fünf Grundmuster der Aufbauorga-nisation (Linien-, Einfluss-, Auftrags-, Matrix- und reine PO) unterscheiden sich durch die Positionierung der Projektleiter in der Unternehmenshierarchie und durch die Stärke ihrer Be-fugnisse gegenüber den Projektmitarbeitern. Die geeignete Organisationsform hängt im We-sentlichen von der Größe bzw. Bedeutung des Projekts für das Unternehmen und von der An-zahl der beteiligten Abteilungen ab. Im Rahmen der Ablauforganisation wird festgelegt, nach welchen Grundregeln die Teilprojek-te und Arbeitspakete eines Projekts aufeinander folgen sollen. Es werden Projektphasen festge-legt, in denen zusammengehörende Arbeiten zu erledigen sind. Am Ende jeder Projektphase liegt ein Meilenstein, an dem die erfolgreiche Abarbeitung überprüft und der Projektfortschritt erfasst wird. Bei einem Standard-Ablauf, wie dem Wasserfallmodell folgen mehrere Projektphasen mit jeweils einem Teilprojekt rein sequentiell aufeinander. Aufgrund ihrer einfachen und klaren Grundstruktur ist diese Ablaufart in der Planung und Projektsteuerung am einfachsten zu hand-haben. Bei einem iterativen Ablauf wie dem Spiralmodell wird das Projekt in mehreren Zyklen mit zunehmendem Detaillierungsgrad durchlaufen. Fehler die z. B. in der Aufgabendefinition oder der Planung gemacht wurden, können dadurch früher erkannt und mit geringerem Auf-wand behoben werden. Eine deutliche Reduzierung der Projektlaufzeit lässt sich durch eine weitgehende Parallelisierung der Arbeitspakete erreichen, wie dies z. B. beim Simultaneous Engineering der Fall ist. Allerdings geht hier die Trennung in einzelne Projektphasen vollstän-dig verloren. Dieses Ablaufmodell stellt daher besonders hohe Anforderungen an Planung und Steuerung eines Projekts.

4.5 Repetitorium 125

In einem Projekt fallen zahlreiche und vielfältige Informationen an. Um wichtige Informatio-nen zu erkennen und entsprechend ihrer Wichtigkeit angemessen zu handhaben, ist es hilfreich, Informationskategorien zu bilden und für jede Kategorie die Regeln der Handhabung festzule-gen. Zum Informationsmanagement gehören vor allem Regeln für die Weitergabe der Informa-tionen – die Kommunikation – und für deren dauerhafte Speicherung – die Dokumentation. Zur Festlegung des Umgangs mit Dokumenten in einem Projekt gehört auch die Beschreibung der verwendeten Dokumentenarten. Alle organisatorischen Festlegungen, die den Aufbau, den Ablauf und die Informationshandha-bung von Projekten innerhalb eines Unternehmens regeln, sollten in einem Projektmanage-ment-Handbuch festgehalten werden.

4.5.2 Checklisten

Checkliste 4.1 Projektorganisation

1. Welche Aufbauorganisation hat das Projekt?

Wie hoch ist die Schnittstellenkomplexität des Projekts?

Wie umfangreich ist das Projekt?

2. Gibt es eine Liste der Projektbeteiligten?

3. Sind die Rollen (Aufgabe, Verantwortung) der Beteiligten festgelegt?

4. Welche Ablauforganisation hat das Projekt?

Stehen Aufwand, Kosten, Qualität im Vordergrund (Sequentialisierung)?

Oder ist das Projekt sehr zeitkritisch (Parallelisierung)?

5. Gibt es ein PM-Handbuch?

Checkliste 4.2 Informations-, Kommunikations- und Dokumentenmanagement

1. Information

Welche Information ist relevant?

Für wen ist die Information relevant?

Was ist als Reaktion auf die Information zu tun?

2. Kommunikation

Wie erreicht die Information den Empfänger?

Ist eine Rückmeldung erforderlich?

Wie erfolgt die Rückmeldung?

3. Dokumentation

In welcher Form werden Informationen dokumentiert?

Gibt es Vorlagen für die Projektdokumente?

Wo und wie erfolgt die Ablage?

Wie erfolgt der Zugriff und wer besetzt welche Zugriffsrechte?


4.5.3 Verständnisfragen 1. Welche Formen der Aufbauorganisation gibt es für Projekte? Beschreiben Sie deren

wichtigste Merkmale! Worin unterscheiden sie sich? 2. Stellen Sie die verschiedenen Projektorganisationsformen in Abhängigkeit der Schnitt-

stellenanzahl und Projektgröße in einem Diagramm dar! 3. Was versteht man unter einem Arbeitspaket, einem Teilprojekt, einem Meilenstein und

einer Projektphase? 4. Was ist eine IMV-Matrix? 5. Welche Ablaufmodelle gibt es? 6. Was beschreibt das „Wasserfallmodell“ und das „Spiralmodell“? 7. Was versteht man unter Simultaneous Engineering? 8. Erstellen Sie eine Vorlage für einen Projekt-Besprechungsbericht! 9. Welche Informationen sollten in jedem Projektdokument enthalten sein? 10. Was ist ein Dokument und welche Arten von Dokumenten entstehen in den verschie-

denen Projektphasen? 11. Worin unterscheiden sich Bericht, To-Do-Liste und Logbuch? 12. Was ist ein Projektmanagement-Handbuch?

4.5.4 Übungsaufgaben

Aufgabe 4-1 Gliederung eines Projekts Der Ablauf für ein Projekt mit einem Arbeitsumfang von 20 Personenjahren soll entworfen werden. Wie würden Sie es hierarchisch gliedern?

Aufgabe 4-2 IMV-Matrix Die folgende Tabelle zeigt eine IMV-Matrix mit 6 Projektbeteiligten und 5 Arbeiten.

Beteiligte Arbeit A B C D E F

a I V

b I I I V

c M I M V M M

d V I I I M

e I V I M Welche Aussagen können über die Rollen der einzelnen Beteiligten gemacht werden? Bei welcher Arbeit handelt es sich um das Gesamtprojekt? Wer ist Projektleiter, wer Auftraggeber und wer Mitarbeiter im Projekt? Welche Vermutung über die Reihenfolge der Arbeiten lässt sich anstellen?

4.5 Repetitorium 127

Aufgabe 4-3 IMV-Matrix In einem Projekt soll ein Programm für die Firma Fabag entwickelt werden. Dazu sind ver-schiedene Arbeiten zu erledigen. Zunächst muss Anne das Pflichtenheft erstellen. Die Benut-zerschnittstelle wird von Bernie programmiert und getestet. Chris erstellt das Hauptprogramm. Wenn diese beiden fertig sind, führt Doris den Gesamttest durch. Alle erstellen die Dokumen-tation. Projektleiter ist Ernie. Legen Sie für die beschriebenen Arbeiten und die Beteiligten (A bis F) die IMV-Matrix an. Denken Sie auch daran, das Gesamtprojekt als Arbeit mit aufzu-nehmen. Erläutern Sie Ihre Festlegungen.

Aufgabe 4-4 Aufbauorganisation

Das dargestellte Organigramm zeigt die Aufbauorganisation eines Unter-nehmens. Stellen Sie eine Matrix-Projektorga-nisation graphisch dar!

......

......

U

V E F K

Aufgabe 4-5 Aufbauorganisation

Um welche Aufbauorganisationsform eines Projekts handelt es sich bei dem dargestellten Diagramm? Für welche Fälle ist diese Organisati-onsform vorteilhaft?

......

......

U

V E F K P

Aufgabe 4-6 Organisation des Entwicklungsprojekts für ein Navigationsgerät Der Hersteller von Fahrradzubehör hat die Vorstudie für das Entwicklungsprojekt des neuen Navigationsgeräts für Fahrräder abgeschlossen. Der Aufwand wird mit ca. 3 Personenjahren bei einer Laufzeit von 12 Monaten veranschlagt. Aus der Entwicklungsabteilung sollen ein Hardware-Entwickler und ein Software-Entwickler dauerhaft im Projekt arbeiten. Aus den Abteilungen Vertrieb, Produktion und mechanische Konstruktion wird je 1 Mitarbeiter zeitwei-se im Projekt benötigt. Welche Aufbauorganisation soll für das Projekt gewählt werden? In wie viele Ebenen sollte das Projekt gegliedert werden?

Documents

Projektmanagement für Ingenieure || Projektorganisation