Grundlagen der Projektplanung

"Ein Plan ist nichts, Planung ist alles" (Dwight D. Eisenhower) - diese Worte gelten auch im Rahmen des Projektmanagements. Dabei geht es im vorliegenden Beitrag vor allem um die Darstellung der projektgerechten Planung anhand einer allen Projekten gemeinsamen Methode. Planung umfasst dabei die Beantwortung der Frage: Wie packe ich das Projekt richtig an?

Grundlagen der Projektplanung

Stellenwert und Prinzipien

Die Begriffe Planung und Projekt gehörten schon immer eng zusammen. So bedeutet "Pro " nach vorne und "jekt" werfen, also den Blick nach vorne werfen. Dies entspricht der wohlbekannten Definition von Planung:

Planung ist das gedankliche Vorwegnehmen zukünftigen, zielgerichteten Handelns.

Durch Planung erstellt der Projektleiter ein mentales Modell dessen, was vor ihm liegt, einen Plan. Dieser ist wie eine Straßenkarte, die zur Orientierung benutzt wird. Danach kann der Projektleiter navigieren und den Fortschritt messen. Damit ist der Plan auch ein Element der Führung, um Aufgaben koordinieren und delegieren zu können. Er gibt den Projektmitarbeitern Anknüpfungspunkte und Sicherheit. Deshalb sollte der Projektleiter jede Gelegenheit nutzen, das Team im Detail mit dem Plan vertraut zu machen oder noch besser an der Planung zu beteiligen.

Die Aufgabe zu planen, begleitet den Projektleiter das gesamte Projekt. Die Planung beansprucht vor allem zu Beginn des Projektes viel Zeit. Sie soll die Frage beantworten: Wie packe ich das Projekt richtig an?

  • Was wollen wir erreichen?
  • Mit welcher Lösung wollen wir das oder die Ziele erreichen?
  • Welche Aufgaben fallen im Projekt an?
  • Wann, in welcher Reihenfolge werden die Aufgaben erledigt?
  • Wer übernimmt die Aufgaben?
  • Wieviel Aufwand verursacht es, die Aufgaben zu erledigen?
  • Wieviel kostet es, die Aufgaben im Projekt abzuwickeln?
  • Welche Einsatzmittel werden für die Aufgabenerledigung benötigt?

Der Projektleiter sollte sich trotz innerer Widerstände hierfür ausreichend Zeit nehmen

denn die Planung kann

  • die Effizienz des Handelns erhöhen
  • die Komplexität reduzieren
  • Transparenz schaffen
  • Risiken / Chancen aufzeigen
  • den Zeitdruck bei Entscheidungen reduzieren
  • eine Vernetzung ermöglichen und
  • Abweichungen erst erkennbar machen.

Der Zeiteinsatz lohnt, obwohl sie

  • vom Handeln abhält
  • Zeit kostet
  • die Flexibilität einschränkt
  • weniger Kreativität zulässt
  • gegebenenfalls zu umfangreich wird.

<media 700>Wirkung eines Planungsaufwands</media>

Nach einer ersten Planung wird der Plan auf Papier oder mit Projektmanagement-Software festgehalten und vielleicht als Tapete (Format DIN A0) im Zimmer des Projektleiters aufgehängt. Damit scheint er oft seinen Zweck erfüllt zu haben, denn er wird kaum mehr wahrgenommen, nicht mehr aktualisiert und verliert seinen Wert. Der Projektleiter sollte arbeiten und ihn lebendig halten, nach dem Motto: "Ein Plan ist nichts, Planung ist alles." (Dwight D. Eisenhower)

Merksätze zur Planung

Planung ersetzt den Zufall durch den Irrtum. Ohne Planung erscheinen die Geschehnisse im Projekt zufällig. Es werden keine Abweichungen erkannt und es gibt auch keinen Handlungsdruck, sich auf Veränderungen einzustellen.

Plane und du wirst Irren. Trotz aller Planung lässt sich die Zukunft nicht vorhersagen. Es wird immer wieder Überraschungen geben, die nicht planbar sind. Irrtümer sind in Projekten völlig normal. Es sollte allerdings geplant sein, wie damit umgegangen werden soll.

Je genauer der Plan, desto härter trifft der Zufall. Meist werden sehr detaillierte Pläne von Projektleitern im "stillen Kämmerlein" erstellt. Es trifft ihn dann sehr hart, wenn ein Teammitglied sagt: "An diesen Punkt haben Sie nicht gedacht !" oder plötzlich unerwartete Ziele auftauchen. Lassen Sie Ihr Team mitdenken.

Je weniger geplant wird, um so leichter hat es der Zufall. Wenn in komplexen Projekten mit vielen Beteiligten die Planung vernachlässigt wird, geht der Projektleiter große Risiken ein. Der Zufall hat eine große "Angriffsfläche", wenn keine Vorkehrungen für die wichtigsten Bedrohungen getroffen sind.

Adventure is the result of a poor planing. Nicht alle Teammitglieder machen gerne abenteuerliche Projekte. So benötigen viele Mitarbeiter aus der Linie klare Ansatzpunkte und Grenzen für ihre Projektaufgaben, um sie leichter innerhalb der Tagesarbeit unterbringen zu können.

Je mehr der Zufall trifft, desto nötiger ist der Plan. Wird mit einem Projekt "Neuland" betreten, beschäftigt es sich mit einem schwierigen, dynamischen Umfeld und haben die Projektbeteiligten wenig Erfahrung, so gibt ein detaillierter Plan vor allem für die ersten Schritte ausreichend Sicherheit.

Plane nicht und du wirst auch nicht wissen, ob du geirrt hast. Ohne Planung werden viele Lernchancen vergeben. Irrtümer sind gute Gelegenheiten, um zu lernen. Ohne Planung fehlen Vergleichsmöglichkeiten und konkrete Ansatzpunkte für Verbesserungen.

Plane nur soviel wie Du kontrollieren wirst (kannst und willst) - keine Diagnose und Steuerung ohne Planung - keine Planung ohne Diagnose und Steuerung Die Planung formuliert den Qualitätsanspruch an die Ergebnisse. Die Qualität wird sinken, wenn diese Qualitätsanforderungen nicht überprüft werden. Umfang und Form der Planvorgaben bestimmen den Führungsstil im Projekt. Vertrauen Sie als Projektleiter Ihrem Team und planen Sie ziel- und ergebnisorientiert, sonst steigt der Kontrollaufwand.

Planungstiefe

Der geeignete Detaillierungsgrad für die Planung wird vor allem durch die Komplexität, den Umfang und den Zeitrahmen des Projektes bestimmt. Hier gilt: Soviel wie nötig, nicht soviel wie möglich. Das Ziel muss sein, eine praktikable, übersichtliche und wirtschaftliche Projektabwicklung zu gewährleisten.

Eine zu grobe Planung birgt die Gefahr, dass Einzelheiten des Projektes nicht mehr festgelegt werden. Bei der Projektdurchführung können dann beträchtliche Koordinations-, Abstimmungs- und Kontrollprobleme auftreten.

Es ist unmöglich und unsinnig, beim Projektbeginn die Planung bis zum Abschluss des Vorhabens im Detail zu planen. Zum einen nimmt die für Projekte charakteristische Unsicherheit überproportional zu, je mehr der Realisierungszeitpunkt vom Planungszeitpunkt entfernt ist; zum anderen schränkt eine zu detaillierte Planung die gerade mit der Projektform beabsichtigte flexible und ganzheitliche Arbeitsweise ein.

Aus diesem Grund hat sich in der Praxis die rollierende Korridorplanung bewährt:

  • Für das Gesamtprojekt wird ein grober Plankorridor festgelegt
  • die anstehende Phase wird detailliert geplant
  • Erkenntnisse aus der Realisierung einer Phase fließen in die Detailplanung der nächsten Phase und in die grobe Planung des restlichen Projektverlaufes ein.

Rollierende Planung mit Plankorridoren

Mit der rollierenden Korridorplanung wird erreicht, dass

  • das Projekt nicht grundsätzlich die falsche Richtung einschlägt
  • situationsbezogene Arbeitsweisen für den Projektmitarbeiter ad-hoc möglich sind
  • der Planungsaufwand vertretbar und realistisch bleibt
  • ein Projektabbruch in einem frühen Stadium des Projektes ohne "Gesichtsverlust" möglich ist.

Planungsprozess

Ziel des Planungsprozesses ist, aus den im Projektauftrag geforderten Ergebnissen (deliverables) konkrete delegierbare Arbeitspakete zu machen, die ohne den Zusammenhang zu verlieren, rationell, zielgerichtet, möglichst parallel, mit klaren Abhängigkeiten, einzeln oder im Team erledigt und überwacht werden können. Dies ist eine anspruchsvolle Aufgabe.

Ausgangspunkt ist eine allen Projekten gemeinsame Methode , in die Erfahrungen aus vielen Projekten eingeflossen sind und die zielorientierte und planmäßige Abwicklung von Projekten unterstützt. Kommen in Unternehmen bestimmte Projektarten häufig vor, so können hierfür eigenständige Methoden sinnvoll sein.

In der Methode wird ein standardisiertes Vorgehen beschrieben - wie gehe ich allgemein in Projekten vor? -, über ein System verständnis der Projektgegenstand allgemein zugänglich gemacht - worum geht es, woraus besteht es? - und über Ziele der Anspruch an die Lösungen formuliert - wie gut soll es sein?

Aus der Anwendung der Methode auf das konkrete Projekt werden Teilprojekte, Teilaufgaben, Arbeitspakete und Aufgaben abgeleitet und in Form eines Strukturplan es hierarchisch gegliedert, um die große Projektaufgabe zu zerlegen.

Für jede Aufgabe aus dem Strukturplan wird abgeleitet, welche Einsatzmittel (Personal, Sachmittel) mit welcher Leistungsfähigkeit in welchem Umfang benötigt werden und woher mit welchen Kosten sie beschafft werden können.

Anschließend wird ermittelt, in welcher Reihenfolge und zu welchen Terminen von wem in welcher Rolle mit welchen Kompetenzen und Verantwortlichkeiten die Aufgaben erledigt werden sollen.

Nach der ersten Zuordnung werden die Konsequenzen deutlich, denn die Planungsinhalte sind stark voneinander abhängig. Deshalb schließt sich immer ein Abstimmprozess an, um den Plan plausibel zu machen und Ungereimtheiten zu beseitigen.

Ziele und Einordnung der Methode

Die Methode unterstützt eine planmässige und zielorientierte Abwicklung von Projekten und fasst die Erfahrungen vieler gleichartiger Projekte zusammen. Sie legt Standards auf grober Ebene fest und ist damit quasi der "größte gemeinsame Nenner" für die Planung aller Projekte. Sie liefert naturgemäß keine Aussagen, welche Lösung für ein Fachproblem zu wählen ist, sondern sie unterstützt den Projektleiter auf seinem Lösungsweg und bietet ihm Hilfsmittel an, einen Projektplan für sein Projekt abzuleiten.

Zur Methode gehören im Einzelnen

  • ein standardisiertes Vorgehen , das für jedes Vorhaben eine grobe Reihenfolge von Phasen und Teilschritten regelt
  • ein System verständnis, das den Projektgegenstand systematisch in Gestaltungsinhalte zerlegt und seine Beziehungen nach innen und außen aufdeckt
  • Ziele , mit denen sich die gewünschten Wirkungen des Projektes beschreiben lassen.

Methode

Grundsätzlich dient eine Methode dazu, ein möglichst gutes Verhältnis von Ergebnisqualität und Projektaufwand zu gewährleisten. Im Einzelnen werden die folgenden Ziele angestrebt:

  1. Zielorientiertes Vorgehen: Es soll sichergestellt werden, dass die Ziele der Entscheider erkannt und verfolgt werden. Erst wenn die Ziele bekannt sind, sollen geeignete Lösungen gesucht werden.
  2. Das "richtige" Problem anfassen: Es soll Einigkeit darüber bestehen, was als Problem anzusehen ist. Es sollen nur für solche Bereiche Vorschläge erarbeitet werden, die verändert werden dürfen. Den Handlungsspielraum einengende Vorschriften – Randbedingungen, zwingende Vorgaben - sollen so früh wie möglich bekannt sein.
  3. Standardisiertes Vorgehen: Die Projektarbeit soll sich an einem Vorgehensmodell orientieren, das die Koordination aller Beteiligten erleichtert und die Grundstruktur eines Projektes nicht jedes Mal neu geplant werden muss.
  4. Projektbegleitende Steuerung sicherstellen: Der oder die Entscheider sollen kontinuierlich den Projektfortschritt steuern, damit kostspielige Fehlentwicklungen frühzeitig erkannt werden und ihre Entscheidungsfähigkeit und -bereitschaft gefördert wird.
  5. Beherrschen komplexer Probleme: Es soll gewährleistet werden, dass - die gedankliche Auseinandersetzung mit einem Problem geordnet und vereinfacht wird - bei der Arbeit im Detail der Überblick erhalten bleibt - Einzellösungen miteinander verträglich sind - Insellösungen vermeiden.
  6. Rationalisierungspotenziale nutzen: Mehrfach benötigte Faktoren sollen möglichst nur einmal entwickelt oder bereitgestellt werden.

Vorgehensmodelle

Prinzipien und Überblick

In der Praxis gibt es eine Reihe von Vorgehensmodellen, die sich aus den Besonderheiten bestimmter Projektarten herausgebildet haben. Auch wenn die Bezeichnungen der Phasen und Teilschritte oft sehr unterschiedlich sind, so verfolgen alle Modelle gleiche Prinzipien.

Folgende Prinzipien tauchen in jedem phasenorientierten Vorgehensmodell auf:

  • Vor der Lösung die Ziele
  • von der Breite in die Tiefe
  • vom Groben zum Detail
  • vor dem Detail die verbindliche Entscheidung
  • zur Entscheidung "echte" Varianten anbieten
  • Abweichungen vom Standard nur in begründeten Ausnahmefällen.

Phasenorientierte Vorgehensmodelle haben folgende Merkmale:

  • Angestrebte zeitliche Begrenzung
  • definierte Teilziele
  • beschriebene Leistungsbilder
  • Prüfung des Phasenergebnisses am Ende
  • Entscheidung über nächste Phase(n), Wiederholung oder Abbruch.

Die Phasen können einander anstoßen oder überlappend ausgerichtet sein.

<media 97>Anstoßplanung - sequentieller Projektverlauf</media>

<media 749>überlappende Phasen - revolvierender Projektverlauf</media>

Je nach Projekttyp ergeben sich in den Vorgehensmodellen andere Phaseneinteilungen und Verläufe sowie unterschiedliche Lieferobjekte am Ende der Phase, die Grundlage für das weitere Vorgehen in der anschließenden Phase sind.

<media 684>Vorgehensmodell nach Projektarten</media>

Für die folgenden Ausführungen wird ein allgemeines Vorgehensmodell nach Götz Schmidt verwendet, das für Organisationsprojekte typisch ist. Es lässt sich leicht auf andere Projekttypen übertragen und ist deshalb universell verwendbar. Es wird hier im Überblick vorgestellt. (Siehe dazu: Schmidt, Götz: Methode und Techniken der Organisation. Schriftenreihe "Organisation" Band 1. 12. Auflage. Gießen 2000.)

Allgemeines Vorgehensmodell

Das Vorgehensmodell nach Götz Schmidt folgt dem Lebenszykluskonzept von Systemen. Es grenzt die Initiative (oder Anstoß) zu Beginn und die nach Projektende beginnende Erhaltung von den eigentlichen Projektphasen ab. Es folgt dem Grundmuster Planen - Machen - Übergeben. Innerhalb der Planungsphasen (Vorstudie, Hauptstudie, Teilstudien) wiederholen sich systematisch oder auch für Einzelfragen sehr schnell immer wieder - wie in einem Zyklus - die gleichen Schritte. Diese Detailschritte pro Planungsphase bilden den Planungszyklus. Darin werden folgende vier Fragen zu jedem Systembestandteil beantwortet:

  • Wohin sollen wir?
  • Wo stehen wir?
  • Welche Wege gibt es?
  • Welcher ist der beste Weg?

Der Planungszyklus in den Planungsphasen

Projektphasen

Zur Abgrenzung der Phasen werden konkrete Ergebnisse und Ziele formuliert, die am Ende einer jeden Phase vorliegen sollen. An jedem Phasenende liegen Entscheidungspunkte, an denen die künftige Richtung des Projektes festgelegt wird und (theoretisch) ein Abbruch des Projektes möglich ist. Dies garantiert eine Einbindung von Lenkungsausschuss und Auftraggeber und verhindert ein "Abdriften" des Projektteams in eine ungewollte Richtung.

Initiative / Anstoß

Ziel Die richtigen Vorgaben des Auftraggebers ermitteln und die Voraussetzungen für das Projekt prüfen und schaffen.

Ergebnis Abgestimmter Projektauftrag

Projektbeginn Vorstudie

Ziel Feststellen, ob es machbare Lösungsrichtungen bzw. Lösungsvarianten gibt, die besser sind, als die bestehende Ausgangslage.

Ergebnis Ein bewerteter Vorschlag für die Lösungsrichtung bzw. Lösungsvariante zur Weiterverfolgung in der Hauptstudie (auch die "Null-Variante" als Lösungsvariante betrachten, es sei denn eine gesetzliche Vorgabe schließt dies aus).

Hauptstudie

Ziel Konkretisierung der Lösung in Form von Grobkonzepten für abgegrenzte Teilprojekte.

Ergebnis Bewertete Teillösungsvorschläge zur Weiterverfolgung in den Teilstudien. Der Umfang ist geklärt und die Auswirkungen auf Kosten und Zeit sind bekannt. Varianten zum Standardablauf sind entschieden.

Teilstudien

Ziel Freigabe der Realisierung.

Ergebnis Abgeschlossene Planung bis hin zu ausführungsreifen Detailplänen.

Systembau

Ziel Umsetzen der Planung in eine arbeitsfähige Lösung.

Ergebnis Fertiggestelltes, betriebsbereites System.

Einführung

Ziel Ein formell vom Lenkungsausschuss abgenommenes, voll funktionsfähiges System. Akzeptanz der Lösung.

Ergebnis Nutzungsfreigabe.

Projektende

Erhaltung

Ziel Aufrechterhaltung der technischen und funktionalen Betriebsbereitschaft.

Ergebnis Ein angepasstes, funktionsfähiges, genutztes System.

Aus den folgenden Inhalten der Phasen können konkrete Aufgaben für ein Projekt abgeleitet werden.

Vorstudie

  • Erheben und analysieren von Informationen (grob)
  • modellieren der Situation
  • abgrenzen des Projektes
  • interne Wirkzusammenhänge
  • externe Beziehungen und Einflüsse
  • ermitteln der wichtigsten Funktionen der Lösung (was muss / soll sie leisten / können)
  • erarbeiten grober Lösungsvarianten bzw. prinzipieller Lösungsrichtungen
  • erarbeiten einer Empfehlung
  • Realisierbarkeit prüfen u.a. nach den Kriterien
  • machbar (technisch / personell / juristisch)
  • durchsetzbar
  • sozial verträglich
  • wirtschaftlich sinnvoll (Vergleich mit Null-Variante)
  • Verfeinerung der Ziele auf der Basis von Stärken / Schwächen, Chancen / Risiken
  • Bewertung
  • Kosten (einmalig und laufend)
  • Nutzen.

Hauptstudie

  • Verfeinerung der modellierten Situation
  • Zerlegung des Projektes in abgrenzbare Teilprojekte
  • weitergehende Erhebung und Analyse zu den abgegrenzten Teilprojekten und zu der Projektumwelt
  • Ermittlung der Schnittstellen zwischen abgegrenzten Teilprojekten sowie den Teilprojekten und der Projektumwelt
  • Ermittlung der fachlichen Benutzeranforderungen in dem größtmöglichen Detaillierungsgrad
  • Ermittlung von Prioritäten für Teilprojekte.
  • Erarbeitung globaler Lösungsvarianten für die abgegrenzten Teilprojekte
  • Verfeinerung der Ziele für die Teilprojekte aus der weitergeführten Würdigung
  • Bewertung der Lösungsvarianten (Kosten / Nutzen)
  • Prüfung der Verträglichkeit von Teillösungen
  • Qualitätssicherung durchführen
  • Erarbeitung von Empfehlungen für die Teilprojekte
  • Ermittlung weiterer Qualitätsanforderungen (z.B. Ausfallsicherheit).

Beispiele für Besonderheiten bei EDV-Projekten (abhängig vom gewählten Verfahren der Systementwicklung)

  • Technische Realisierbarkeit prüfen (globale Anforderungen an Hardware und Systemsoftware)
  • Erarbeitung eines funktionalen Modells (Input und Output festlegen)
  • Mengengerüst ermitteln
  • Darstellung des logischen Datenmodells
  • Weitgehend eindeutige Darstellung der Benutzerschnittstelle z.B. durch Prototypen / Listen / Masken
  • Konvertierung bestehender Daten planen
  • Ausfallverfahren / Backup-Konzept planen
  • Sicherheitskonzept planen.

Teilstudien

  • Bedarfsabhängig weitere Erhebung und Analyse von Informationen
  • komplettieren der funktionalen Anforderungen und der Ziele
  • Ermittlung des quantitativen und qualitativen Bedarfs an – Personal – Raum / Gebäuden – sonstigen Sachmitteln.
  • Erarbeiten ausführungsreifer Pläne
  • aufstellen von Pflichtenheften / Anforderungskatalogen
  • erstellen von Ausschreibungsunterlagen
  • einholen von Angeboten und Bewertung der Angebote
  • Planung der Einführung
  • erarbeiten entscheidungsreifer Vorlagen für die Realisierung.

Beispiele für Besonderheiten bei EDV-Projekten

  • Datenfluss beschreiben
  • Schnittstellenbeschreibung zwischen Systemkomponenten
  • Beschreibung von Elementarfunktionen
  • Entwurf der physischen Datenbankstruktur
  • Entwurf und Spezifikation von Tests
  • detaillierte Anforderungen an Hard- und Systemsoftware festlegen.

Systembau

  • Umsetzen der Pläne in arbeitsfähige Lösungen
  • Vergabe und Überwachung von Fremdaufträgen
  • Durchführung baulicher Maßnahmen
  • Installation notwendiger Sachmittel
  • Abschluss der Projektdokumentation
  • Benutzerdokumentation fertigstellen
  • Einführungsvorbereitung abschließen
  • Qualitätssicherung durchführen.

Beispiele für Besonderheiten bei EDV-Projekten

  • Vollständige Beschreibung der Struktur und des Ablaufes jeden Programmes
  • Programm erstellen
  • Hard- und Software installieren
  • bereitstellen von Testdaten.
  • Programme testen
  • Integration von Programmen
  • Test der Integration
  • (Erst-) Erfassung von Daten.

Einführung

  • Information der indirekt Betroffenen
  • Schulung der direkt Betroffenen
  • Unterstützung der Anwender in der Anfangsphase.
  • Sicherstellen eines störungsfreien Funktionierens (Stabilisierung einer Lösung)
  • Vorbereitung der Entscheidung für die Nutzungsfreigabe.

Erhaltung

  • Sammeln von Betriebs- und Nutzungsinformationen
  • Störungsdiagnose und Behebung von Störungen
  • Überprüfen, in welchem Ausmaß die Regelungen eingehalten bzw. die Lösung genutzt werden.
  • Überprüfen auf sachgerechte Ergebnisse
  • Soll / Ist-Vergleich: Sind die Ziele - in welchem Ausmaß - erreicht?
  • ermitteln von Anpassungs- / Änderungsbedarf (ggf. Anstoß für ein neues Projekt).

Planungszyklus

Die Planungsphasen des Vorgehensmodells werden nach dem gleichen Grundmuster abgewickelt. Sie umfassen jeweils einen oder mehrere Planungszyklen. Innerhalb eines Zyklus sind auch Rücksprünge (Schleifen) möglich.

Bestandteile eines Planungszyklus

Auftrag Ziele, Restriktionen, Projektorganisation, Termine, Kosten (Budget) für diese Phase. Damit muss am Ende der Phase eine neue Entscheidung eingeholt / gefällt werden. Da Aufträge oft unvollständig (zu vage) oder zu sehr lösungsorientiert formuliert werden, ist ein vollständig formulierter Auftrag als Holschuld des Projektleiters anzusehen.

Erhebung Sammeln von relevanten Informationen. Wesentliche Techniken sind Interviews, Fragebogen, Dokumentenstudium, Beobachtungen, Selbstaufschreibungen etc.

Analyse Ordnen des erhobenen Materials. Modellierung der Problemstellung (welche Faktoren gehören zum untersuchten Bereich, wie hängen diese Faktoren zusammen, welche Faktoren wirken von aussen auf das Problem?). Zur Modellierung kann das Systemdenken herangezogen werden.

Würdigung Ermittlung von Stärken und Schwächen, Chancen und Risiken sowie Ursachen des Ist-Zustandes, um bei der Erarbeitung von Lösungsvarianten Stärken zu erhalten / auszubauen bzw. Schwächen zu beseitigen. Dieser Schritt führt zu einer Konkretisierung des Zielkataloges und gegebenenfalls zu einer Zielerweiterung oder -korrektur.

Lösungsentwurf Sammlung möglicher Lösungen. In einer Vorstudie sollte der Ist-Zustand ("Nullvariante") grundsätzlich auch eine mögliche Lösung sein, es sei denn, eine Restriktion verhindert dies.

Bewertung Die Wirkungen möglicher Lösungen werden untersucht. Den betrachteten Varianten werden die Ziele gegenübergestellt, um den Zielerreichungsgrad der Varianten zu ermitteln. Der Bewertungsvorschlag durch die Entscheidungsvorbereiter wird durch die Entscheidungsberechtigten überprüft.

Auswahl Die Auswahl schließt sich an die Bewertung an. Es wird festgelegt, ob und gegebenenfalls wie weiter vorzugehen ist. Es wird ein Auftrag für die nächste Phase erteilt.

Aus dem Planungszyklus lassen sich sehr leicht Teilaufgaben innerhalb von Arbeits-paketen ableiten.

Varianten zum Standardvorgehen

Die Vielfalt der Projekte ist so groß, dass nur selten ein standardisiertes Vorgehensmodell eins zu eins befolgt werden kann. Manche Projekte sind zu klein, um alle Phasen gleichermaßen zu durchlaufen, im anderen Fall ist die Ungewissheit über die künftige Lösung sehr groß, dass sehr schnell greifbare Ergebnisse vorliegen müssen oder aufgrund gesetzlicher Vorgaben es kaum Handlungsalternativen gibt. Oft ist eine Variante zum Standardvorgehen bereits im Projektauftrag als Projektstrategie formuliert oder stellt sich im Rahmen der Vorstudie als eine grundsätzliche Lösungsalternative heraus. Spätestens nach Abschluss der Hauptstudie sollte über die Vorgehensvariante bezogen auf das Gesamtprojekt oder in Teilbereichen entschieden sein. Die Varianten werden hier nur im Überblick erläutert.

Empirisches versus konzeptionelles Vorgehen

Die Entscheidung für empirisches oder konzeptionelles Vorgehen bedeutet nicht notwendigerweise eine Abkehr vom Standard. Hierbei werden unterschiedliche Schwerpunkte gesetzt. So werden beim empirischen Vorgehen umfangreiche Erhebungs- und Analyse- und Würdigungsschritte nötig, um im Detail Verbesserungspotenziale zu erkennen, die dann schrittweise umgesetzt werden. Beim konzeptionellen Vorgehen wird ein grundlegend neuer Ansatz verfolgt. Deshalb werden nur grobe Erhebungen und Analysen durchgeführt und der Schwerpunkt auf das Entwickeln und Bewerten neuer Lösungen gelegt.

Für die Projektplanung ergeben sich daraus unterschiedliche Aufwände für die jeweiligen Projektschritte.

<media 247>Empirisches und konzeptionelles Vorgehen1</media>

<media 248>Empirisches und konzeptionelles Vorgehen2</media>

Wegfall / Komprimierung von Projektphasen

Es kann auf eine Vorstudie verzichtet werden, wenn

  • die Lösung bereits feststeht, d.h. der Lenkungsausschuss ein bestimmtes Ergebnis haben will
  • ein fertiges System nur noch eingeführt werden soll
  • aufgrund der politischen und rechtlichen Situation keine echten Varianten vorhanden sind.

Hauptstudie und Teilstudien können zusammengelegt werden, wenn

  • sie innerhalb von weniger als 3 Monaten abzuwickeln sind
  • keine eigenständigen Teilprojekte sinnvoll sind
  • eine erneute Wirtschaftlichkeitsbetrachtung nicht verlangt wird.

Prototyping

Damit Produkte und Systeme nicht an den Wünschen der Kunden und Anwender vorbei entwickelt werden, empfiehlt sich das Konzept des Prototypings. Der Prototyp enthält entweder wesentliche Funktionen des zu entwickelnden Systems (funktionaler Prototyp) oder die wesentlichen Eigenschaften der Benutzeroberfläche (Prototyp der Benutzerschnittstelle). Der Prototyp wird schon in der Hauptstudie entwickelt, so dass schon sehr früh zu erkennen ist, wie später mit dem System gearbeitet wird. Änderungswünsche der Anwender können sehr früh eingebracht werden. Dadurch wird gewährleistet, dass das zu entwickelnde System in Einklang mit den Anforderungen der Anwender steht. In der Regel ist das Prototyping jedoch nur für einzelne Teilprojekte anwendbar, nicht für das Gesamtprojekt.

Haubentaucher

Voraussetzung für die Anwendung des Haubentaucher-Modells ist, dass als Ergebnis der Vorstudie ein Rahmenkonzept vorliegt, das dann in der Hauptstudie in Teilprojekte zerlegt wird. Entweder von hier aus oder von der Plattform der Teilstudien aus werden die Teilprojekte gemäss Prioritätenrangfolge nacheinander ausführungsreif geplant, realisiert und eingeführt. Das Haubentaucher-Konzept ähnelt damit einem Puzzlespiel, bei dem die Randstücke zuerst gelegt wurden. Es wird zwar letztlich eine komplette Lösung angestrebt, aber sie wird Teilprojekt für Teilprojekt, Puzzleteil für Puzzleteil, vervollständigt.

Versionenkonzept

Soll bewusst nur eine Annäherung an eine fiktive Ideallösung entwickelt werden, die später vervollständigt und verbessert wird, so wird das Versionenkonzept angewendet. Dabei laufen Planungs- und Realisierungsphasen sequenziell, zunächst aber nur für einen eingeschränkten Lösungsumfang des Gesamtsystems ab, später für weiter zu entwickelnde Teilbereiche. Dieses Vorgehen wird empfohlen, wenn

  • dringend und kurzfristig eine Problemlösung gesucht wird
  • die Rahmenbedingungen des Projektes stark schwanken
  • die Gesamtlösung mehrere Jahre dauern würde
  • schnell Erfahrungen der Anwender in weitere Versionen einfließen sollen.

System planen

Mit der Systemplanung wird in methodischen Schritten ein Bild der angefertigten und die Lösung beeinflussenden Faktoren bestimmt. Dabei wird der Projektgegenstand systematisch in Gestaltungsinhalte zerlegt und seine Beziehungen nach innen und außen aufgedeckt, um sagen zu können, was gehört dazu und was nicht und welche Komponenten sollen geändert werden und welche können beibehalten werden.

Hierzu wird der Projektgegenstand als System begriffen, um komplexe und vielschichtige Probleme leichter zu bearbeiten und möglichst redundanzfreie Ergebnisse zu erhalten. Das Systemdenken basiert auf dem Systems Engineering (der ingenieurmäßigen Gestaltung von Systemen).Was im konkreten Projekt sinnvoll als Elemente und Beziehungen anzusehen ist, ist sehr stark vom Fachgebiet, der Projektart und dem Detaillierungsgrad abhängig.

Ein System ist gegenüber seiner Umwelt abgegrenzt, besteht aus Teilen ( Elemente ), die bestimmte Merkmale ( Dimensionen ) aufweisen, die Elemente werden miteinander verknüpft ( Beziehungen ) und wirken aufeinander ein.<media 246>Elemente und Beziehungen nach Projektart</media>

Insgesamt hilft das Systemdenken den Fachexperten für die gemeinsame Modellbildung des Projektgegenstandes, damit sie sich orientieren können: Wo befinden wir uns gerade, welche Komponente ist wovon abhängig, welche Änderung bewirkt was. Hierzu haben sich je Fachgebiet eigenständige Verfahren und Darstellungsformen herausgebildet, dessen gemeinsames Gedankengut das Systemdenken ist.

Grundbegriffe des Systemdenkens

<media 601>System, Umsystem und Elemente</media>

<media 156>Beziehungen, Untersystem und Teilsystem</media>

Schritte des Systemdenkens

Systemgrenzen bestimmen Abgrenzen des Systems nach außen: Wie soll das zu untersuchende System von der Systemumwelt abgegrenzt werden? Welche Sachverhalte sollen / dürfen organisatorisch verändert werden, welche nicht? Damit wird der Gestaltungsbereich festgelegt.

Einflussgrößen ermitteln Einflussgrößen sind - aus der Sicht des Projektes - nicht lenkbare Faktoren. Es werden unterschieden

  • Restriktionen, die durch Entscheider im Projekt als Vorgaben gesetzt sind oder extern erzwungen werden (Gesetze, Verträge etc.)
  • Rahmenbedingungen (haben Einfluss auf die Problemsituation, können im Rahmen des Projektes nicht verändert werden = Schlüsselgrößen, z.B. Verfügbarkeit von geeigneten Mitarbeitern, technisches Angebot im Markt etc.).

Untersysteme / Teilsysteme abgrenzen Abgrenzung von Systemen nach innen: Welche kleineren Einheiten können abgegrenzt werden, um sie isoliert zu bearbeiten? Was gehört im Innern zum Projekt? Konzentration auf Unter- und Teilsysteme, die nacheinander geplant werden. Vorgehen:

  • Vom Groben ins Detail - stufenweise Bildung
  • Minimierung der Schnittstellen bei der Abgrenzung

Schnittstellen ermitteln Welche Schnittstellen sind zwischen den Unter- bzw. Teilsystemen und zu den relevanten Umsystemen zu beachten?

  • Integration der Untersysteme von außen nach innen (Schnittstellenmatrix)
  • Zur Integration von Teilsystemen: schichtenweise - iterative - Planung, keine Realisation vor Abschluss der Planung (ohne Kenntnis wichtiger Zusammenhänge von Teil- bzw. Untersystemen).

Analysieren Ermittlung und Ordnung der Elemente, Beziehungen und Dimensionen in den Unter- und Teilsystemen.

Gemeinsamkeiten ermitteln Ermittlung gemeinsamer Elemente und Beziehungen in den abgegrenzten Unter- und Teilsystemen.

Anwenden des Systemdenkens auf Projekte

Systemgrenze bestimmen

Bei einem Organisationsprojekt werden zunächst die relevanten Organisationseinheiten, aber auch Interessengruppen (Stakeholder) als Komponenten oder Bestandteile des Systems ermittelt.

Kernfrage: Wer ist vom Projekt betroffen, daran beteiligt, hat Interessen?

Bei dem Projekt "Call-Center für den Kundenservice" könnten das sein:

betroffene.jpg

Danach werden als übergreifende Themen die heutigen und künftigen Beziehungen gesammelt. Damit nichts Wichtiges vergessen wird, sollten Fachexperten herangezogen werden oder Checklisten benutzt werden.

Kernfrage: Um welche Themen müssen wir uns kümmern?

In unserem Beispiel könnten es folgende Gestaltungsinhalte sein:

gestaltungsinhalte.jpg

Bezogen auf jeden Gestaltungsinhalt entstehen nun Beziehungen zwischen den Organisationseinheiten und Interessengruppen. Sie lassen sich in einem Systemdiagramm aufzeigen. Nach dieser Betrachtung kann dann endgültig die Systemgrenze festgelegt werden.

Kernfrage: Welche Beziehungenwerden durch die Gestaltungsinhaltezwischen den Organisationseinheiten, Interessengruppen, Beteiligten aufgebaut

<media 166>Bubble-Chart</media>

Die Nummerierung zeigt auf, welche Organisationsheiten von den Gestaltungsinhalten berührt sind. Damit ist der erste Schritt des Systemdenkens vollzogen und das Projekt nach außen abgegrenzt.

Einflussgrößen ermitteln

Jedes System ist in eine Umgebung mit unterschiedlichsten Einflussfaktoren (rechtlich, ökonomisch, ökologisch, wissenschaftlich, technisch, kulturell und politisch) eingebettet, in der und mit der es lebt. Durch die Erfassung dieser Faktoren lässt sich ein vollständiges und abgerundetes Bild der Situation gewinnen, was besonders zu Beginn eines Projektes eine wichtige Rolle spielt. Später wird durch diese ganzheitliche Betrachtung die Gestaltung integrationsfähiger Lösungen gefördert sowie deren Einbettung in ihr Umfeld erleichtert.

Im Rahmen einer Einflussgrößenanalyse sind drei grundlegende Fragen zu beantworten:

  • Welche Einflussgrößen wirken auf das Projekt ein?
  • Welche Trends können für diese Einflussgrößen prognostiziert werden?
  • Welche Auswirkungen auf das Projekt lassen sich daraus ableiten?

Um diese Schlüsselgrößen zu ermitteln, können folgende Arten von Restriktionen und Rahmenbedingungen hinterfragt werden:

<media 235>Einflussgrößen ermitteln</media>

rest1.jpg

Unter- und Teilsysteme abgrenzen

In diesem Schritt wird der Projektgegenstand in kleinere Einheiten zerlegt. Dies kann in diesem Beispiel in zwei Richtungen geschehen:

  • Unterteilen der (Organisations)-einheiten (Untersysteme)
  • Verfeinern der Beziehungen nach funktionaler Sicht (Teilsysteme).

So kann sinnvoll sein, die Kunden nach Kundengruppen zu unterscheiden, den Vertriebsbereich in seine Abteilungen und Regionalbüros zu gliedern und die Bestandteile des neuen Call-Centers aufzuzeigen, um präziser die Ansprechpartner herauszuarbeiten und besser Aufgaben ableiten zu können. Es handelt sich immer um hierarchische Gliederungen, die in Form von Tabellen oder Strukturbildern dokumentiert werden.

<media 607>Tabelle Teil 1</media>

<media 608>Tabelle Teil 2</media>

<media 609>Tabelle Teil 3</media>

Jede Unterteilung sollte den Oberpunkt möglichst vollständig abdecken.

Ebenso lassen sich die im ersten Schritt nach Funktionen des Systems gegliederten Gestaltungsinhalte über ein Mind Map verfeinern. Dies bietet eine hohe Flexibilität für Ergänzungen, Erweiterungen oder andere Veränderungen und prägt sich gut ein.

<media 429>Mind Map</media>

Um die Gestaltungsinhalte sauber abzugrenzen, sollten insbesondere bei Prozessen (dies sind Teilsysteme!) immer die auslösenden Geschäftsereignisse, die angesprochenen Organisationseinheiten und das Endergebnis aufgelistet werden.

Am Ende stehen immer Strukturpläne, die eine hierarchische Zerlegung des Projektgegenstandes (vom Groben ins Detail) zeigen. In der Praxis findet man auf Projektarten bezogene Sonderformen:

Produktstrukturplan Enthält die Einzelteile des künftigen Produktes.

Systemstrukturplan (SSP) Von einem Systemstrukturplan spricht man bei der technischen Beschreibung und Strukturierung von Hard- und Software-Systemen. Er enthält die Auflösung in technische Komponenten, die technologischen Abschnitten zugeordnet werden.

Anlagenstrukturplan (ASP) Der Begriff Anlagenstrukturplan wird im Anlagenbau verwendet.

Objektstrukturplan (OSP) Der Objektstrukturplan ist ein erweiterter Produktstrukturplan, der neben den Einzelteilen des künftigen Produktes auch bereits die zusätzlich während der Projektdurchführung entwickelten Zwischenprodukte wie Funktionsmuster, Prüfbauten, Testprogramme, Hilfsmittel enthält. Damit lässt sich klar trennen, was (letztendlicher) Bestandteil des Produktes ist und was nur auf dem Weg dorthin benötigt wurde.

Funktionsstruktur Die Funktionsstruktur bildet eine planerische Vorstufe der eigentlichen Produktstruktur; sie enthält eine Gliederung der Funktionen, die das künftige Produkt leisten soll, ohne Berücksichtigung welcher Teil des Produktes die Funktion erfüllt.

In Standardproduktstrukturplänen werden die Ebenen der Gliederung bezeichnet und die Elemente der Ebenen durch ein hierarchisches Nummernsystem unterschieden. Dieses Nummernsystem hat den großen Vorteil, dass später produktteilbezogene Projektdaten beliebig nach oben komprimiert werden können.

<media 600>Systeme</media>

Ziele definieren

Bedeutung von Zielen in Projekten

Unter einem Ziel wird ein angestrebter Zustand, eine erwünschte Wirkung verstanden. Ziele beschreiben also künftige Ergebnisse, die durch bestimmte Maßnahmen oder Lösungen erreicht werden. Sie setzen den Qualitätsmaßstab für die Ergebnisse fest, indem sie erlauben, die Güte der Ergebnisse zu bestimmen.

Über Ziele lassen sich auch die Interessen der verschiedenen Interessengruppen ( Stakeholder ) eines Projektes ausdrücken, um Lösungen zu suchen, die möglichst breit akzeptiert werden.

<media 736>Ziele und Lösungen</media>

Nicht immer kann eindeutig unterschieden werden, ob ein Ziel oder eine Lösung vorliegt. Es gilt der Grundsatz, dass mit zunehmender Detaillierung - im Projektfortschritt - die Ziele immer lösungsnäher werden.

Ziele haben einen hohen Stellenwert für das Projektmanagement, denn sie haben folgenden Zweck:

<media 747>Zweck von Zielen</media>

Obgleich Ziele für jedes Projekt erforderlich sind, ist das Fehlen von Zielen einer der häufigsten Mängel im Projekt. Außerdem sind die Ziele den Beteiligten zu Beginn nur unzureichend bekannt. Ursachen hierfür sind:

  • Der Auftraggeber ist sich über seine Ziele selbst nicht im Klaren - Störgefühl löst Projekt aus
  • der Auftraggeber nennt seine Ziele nicht, weil er sie für selbstverständlich hält
  • eine gewünschte Lösung steht im Vordergrund, über Ziele wurde noch nicht nachgedacht
  • unterschiedliche Gruppen verfolgen mit einem Projekt bestimmte Ziele, die im Projekt nicht alle bekannt sind
  • klare Aussagen zu Zielen werden bewusst vermieden, um später nicht anhand der Ziele gemessen werden zu können
  • Auftraggeber oder Entscheider sind sich über die zu verfolgenden Ziele nicht einig und vermeiden deswegen klare Aussagen
Anforderungen an Ziele

Ziele, die sich auf die Lösung selbst beziehen, werden als Systemziele bezeichnet (z.B. ausbaufähige ACD-Anlage). Daneben gibt es sogenannte Vorgehensziele, die den Projektverlauf betreffen (z.B. schneller Abschluss des Projektes). Zwischen den verschiedenen Zielkategorien können Zielkonflikte auftreten. Ein klassischer Zielkonflikt – sogenannte "magische Dreieck " – besteht zwischen den Zielen:

  • Kurze Durchlaufzeit des Projektes (Vorgehensziel)
  • niedrige Kosten des Systems
  • hohe Qualität der Lösung.

Sollen Ziele wirksam sein, sind einige Forderungen zu erfüllen.

anfziele.jpg

Zielfindungsprozess

Die Schritte des Zielfindungsprozesses stellen sicher, dass diese Forderungen erfüllt werden können. Erste Zielvorstellungen sind im Auftrag bereits enthalten. Hierbei handelt es sich jedoch oft lediglich um die Sicht des Auftraggebers und eventuell aus der Strategie abgeleitete Ziele. Aus den Missständen in der Ausgangslage lassen sich ebenfalls erste Ziele ableiten.

findeziel.jpg

Eine systematische Erläuterung der Schritte finden Sie im schon erwähnten Buch von Götz Schmidt (s.o.). An dieser Stelle soll lediglich auf die Stakeholder-Analyse zum Finden von Zielen eingegangen werden.

Stakeholder-Analyse

Die Stakeholder-Analyse besteht im Kern aus drei Fragen:

  • Welche Personen bzw. Personengruppen und Institutionen müssen als potenzielle Stakeholder des Projektes betrachtet werden?
  • Welchen Einfluss haben die potenziellen Stakeholder, d.h. welche Macht steht den Stakeholdern in Bezug auf das Projekt zur Verfügung?
  • Wie werden sich die relevanten Stakeholder in Bezug auf das Projekt verhalten?

Zunächst sind die projektrelevanten Stakeholder zu identifizieren. Dies können sein:

<media 577>Stakeholder</media>

Nach der Sammlung der internen und externen Stakeholder geht es darum, zu erkennen inwieweit und in welchem Ausmaß sie den Projekterfolg fördern oder behindern können und was in Bezug auf die kritischen Erfolgsfaktoren getan werden kann. Hierfür muss zuerst die Bedeutung der Stakeholder klassifiziert werden (A, B, C - Stakeholder) sowie die Hauptinteressen der bedeutendsten Stakeholder formuliert werden.

Erkenntnisse können damit gewonnen werden in Bezug auf:

  • Zu erwartende Handlungsmuster der Stakeholder
  • Projektmarketingmaßnahmen
  • geeignete Strategien im Umgang mit den Stakeholdern
  • welche Ziele, Bedürfnisse und Visionen bei der Lösungsfindung zu berücksichtigen sind
  • potenzielle Konflikte
  • kritische Erfolgsfaktoren bzw. Risiken
  • die Zusammensetzung der Projektgruppe und des Lenkungsausschusses sowie die Besetzung der Projektleiterrolle.

Zielkatalog für das Beispiel "Call-Center für den Kundenservice"

<media 739>Zielkatalog</media>

(Pfetzing/Rohde, a.a.O., S. 138-177)