Einführung

In dieser Rubrik können Sie sich über Best-Practice-Ansätze im Projektmanagement informieren. Es werden Modullösungen beschrieben, bei denen Sie erfahren, welchen Zweck sie erfüllen, in welchen PM-Prozessen sie typischerweise Anwendung finden und wie eine mögliche Lösung konkret aussehen kann. Sie müssen jedoch beachten, dass die dargestellten Lösungen die prinzipiellen Bedarfe im Projektmanagement sehr gut treffen, aber natürlich nicht alle Projektspezifika oder Vorgaben aus den unternehmensspezifischen Prozessen abdecken können. Hier müssen die PM Governance eines Unternehmens oder auch der einzelne Projektleiter stets überprüfen, welche Informationsbedarfe notwendig und bedeutsam für den Projekterfolg sind. Die beschriebenen Module erheben somit keinen Anspruch auf Vollständigkeit und Relevanz in Projekten. Nehmen Sie Kontakt mit uns auf, sollten Sie Fragen zu den beschriebenen Lösungen haben.

ISO 21500 - Vorgehensmodell

Zur einfachen Strukturierung der nachfolgenden PM-Toolbox wird der Methodenframe der ISO 21500 aus dem Jahre 2012 verwendet. Dieser lehnt sich stark an den amerikanischen Standard des PMBoK Guide V5. Einen Vergleich beider Standards finden Sie im Artikel PMBoK Guide vs. ISO 21500.

Die ISO 21500 verfügt über 5 Prozessgruppen. Im Projektmanagement-Modell sind die Wechselwirkungen zwischen den Prozessgruppen innerhalb der Projektgrenzen dargestellt. Dies beinhaltet auch die repräsentativen Inputs und Outputs der Prozesse innerhalb der Prozessgruppen. Das Schaubild ist inhaltlich unverändert aus der ISO 21500 entnommen.

 

ISO 21500 - Prozesse

Die ISO 21500 umfasst neben den 5 Prozessgruppen insgesamt 10 Themengruppen. Im weiteren sind die Best-Practice-Ansätze genau nach diesen Themengruppen gegliedert. Zudem wird beschrieben, welche PM-Prozesse im Einzelnen betroffen sind und was mit dem Einsatz eines Lösungsmoduls bezweckt wird. Die Übersicht zeigt eine Matrix mit insgesamt 39 PM-Prozessen, zugeordnet zu den jeweiligen Prozess- und Themengruppen. Im Artikel Mit der ISO 21500 im Cockpit auf Kurs bleiben…! finden Sie eine detaillierte Beschreibung zu einem PM-System, das bei einem Kunden mit genau diesen PM-Prozessen eingeführt worden ist. Für die Prozessgruppen gelten folgende Abkürzungen:


I = Initiierung / P = Planung / U = Umsetzung / C = Controlling / A = Abschluss

 

Integration

Projektauftrag

Betroffene Prozesse: Erstellen des Projektauftrags (I)

Das Erstellen eines Projektauftrags hat den Zweck, z.B. ein Akquisitions- oder Umsetzungsprojekt formell zu genehmigen, damit es offiziell starten kann. Dazu werden dem Projektleiter Rechte und Pflichten vom Projektsponsor übertragen. Es sind die projektspezifischen Rahmenbedingungen möglichst genau zu benennen. Hierzu gehören die Projektziele mit einer Nutzenbeschreibung, die wesentlichen Projektinhalte und bereits erkennbare Risiken. Ebenso sind die zeitlichen und finanziellen Vereinbarungen zu dokumentieren. In diesem Zusammenhang sind bereits vorgegebene bzw. erkennbare Meilensteine aufzunehmen. Der Projektleiter bewertet die Machbarkeit des Projektauftrags und benennt offenkundige Schwächen bzw. Einschränkungen. Bestehen wichtige oder besondere Auflagen für das Projekt, so sind diese zu dokumentieren. Nicht zuletzt ist der Berichtszeitraum für dieses Projekt festzulegen.


Projektpläne

Betroffene Prozesse: Erstellen des Projektpläne (P) / Controlling der Projektarbeiten (C)

Mit dem Erstellen der Projektpläne soll dokumentiert werden, welche Lieferleistungen im Projekt unter welchen Rahmenbedingungen zu erbringen sind, was von wem zu leisten ist, wie die Bereitstellung erfolgen soll, was es kosten wird und wie und wann das Projekt umzusetzen, zu steuern und abzuschließen ist. Alle Basispläne sollten vor Beginn einer Umsetzung von Arbeitspaketen erstellt und vereinbart sein, um eine möglichst hohe Zustimmung für die zu erwartenden Lieferobjekte von allen relevanten Stakeholdern zu erhalten. Welche Basispläne benötigt werden, wird in den nachfolgenden Themengruppen beschrieben. Alle Projektteilnehmer haben sich an die vereinbarten Projektpläne zu halten und Störungen oder Änderungsbedarfe unverzüglich aufzuzeigen.

 

Hierzu gehören u.a.:

Business Case
Pflichtenheft
alle Basispläne
Projektmanagementplan

Fortschrittsanzeige und Aufgabenliste

Betroffene Prozesse: Koordinieren der Projektarbeiten (U) / Controlling der Projektarbeiten (C)

Das Koordinieren der Projektarbeiten ist die integrative Managementschnittstelle zwischen dem Kunden, dem Projektsponsor, dem Projektleiter, dem Kernteam bzw. dem Projektteam, dem Lieferanten und ggf. anderen Stakeholdern. Es ist sicherzustellen, dass der Projektfortschritt auf Basis der definierten Arbeitspakete und ihres Erledigungsgrads überwacht wird, Abweichungen ggü. den gültigen Projektplänen von allen Betroffenen akzeptiert und gemäß Änderungsverfahren neu vereinbart werden, und dass die geplanten Arbeitspakete vollständig zum Abschluss gebracht werden. In der Aufgabenliste werden alle allgemeinen Aufgaben von Teammitgliedern sowie Klärungsbedarfe genereller Art erfasst, behandelt und verfolgt. Änderungen bzw. Ergänzungen sind in regelmäßigen Statusmeetings nachzuhalten. Dabei sind Verantwortlichkeiten und Zieltermine konkret festzulegen.

 

Projektbericht

Betroffene Prozesse: Koordinieren der Projektarbeiten (U) / Controlling der Projektarbeiten (C)

Der Projektbericht des Projektleiters dient dem regelmäßigen, detaillierten Aufzeigen der Gesamtsituation im Projekt und schafft damit Transparenz in Fortschritt und Zielerreichung zum gegebenen Betrachtungszeitpunkt. In der Regel berichtet der Projektleiter seinem Projektauftraggeber bzw. Sponsor. In der Praxis hat es sich bewährt, diesen Bericht auch projektintern zu verteilen, um einen breiten Konsens in der inhaltlichen Bewertung zu erzielen. Als Best-Practice hat sich die plakative Darstellung der Kritikalität des Projektzustands erwiesen. Die rote Einstufung sollte erst dann erfolgen, wenn das Projektteam keine Möglichkeiten mehr sieht, den Zustand im Rahmen der vereinbarten Ziele und Kennzahlen zu verbessern. Meistens ist damit auch ein Änderungsantrag verknüpft. Im Projektbericht ist detailliert auf die qualitative, kommerzielle, terminliche und ressourcenbezogene Situation einzugehen und diese im Einzelnen zu bewerten. Nicht zuletzt dient dieser Bericht auch dazu, einen Ausblick auf die kommenden Aktivitäten zu werfen. Ein Projektbericht hat es immer verdient, mit dem Sponsor und ggf. anderen Stakeholdern besprochen zu werden.

 

Projektstatus

Betroffene Prozesse: Koordinieren der Projektarbeiten (U) / Controlling der Projektarbeiten (C)

Der Projektstatus dient dem regelmäßigen Briefing der Entscheiderebenen bei den relevanten Stakeholdern. Dieser Kreis wird oftmals Projektlenkungsausschuss oder Steering Committee bezeichnet und ist das Gremium, bei dem sich die beteiligten Projektleiter ihre Entlastung für den Berichtszeitraum und ggf. neue Vorgaben oder Abstimmungen zu bestimmten Sachverhalten einholen. In der Kommunikationsmatrix ist festzulegen, wer an diesem Regeltermin teilnehmen soll. Wie im Projektbericht macht es Sinn die klassischen Steuerfaktoren Budget / Qualität / Termine in ihrer Kritikalität eigens zu bewerten, um signifikante Defizite oder Abweichungen eindeutig zu adressieren. Im Gesamtstatus sind neben der Kritikalität die zurückliegenden Ergebnisse und Abweichungen in Kurzform darzustellen. Ergeben sich hieraus Entscheidungsbedarfe sind diese in der eigenen Rubrik aufzuzeigen. Darüber hinaus hat es sich als hilfreich erwiesen, anstehende Aktivitäten oder Meilensteine besonders zu würdigen. Es empfiehlt sich, den Status und das dazugehörige Protokoll im Anschluss an das Projektteam zu verteilen, um das Gesamtverständnis zu fördern.

 

Änderungsantrag (Change Request)

Betroffene Prozesse: Controlling von Änderungen (C) / Controlling der Projektarbeiten (C)

Das Controlling von Änderungen hat den Zweck, Änderungen am Projekt und an den Lieferobjekten zu steuern und vor der Umsetzung für die formelle Annahme oder Ablehnung dieser Änderungen zu sorgen. Dies bedingt verabschiedete oder genehmigte Projektpläne, die die Grundlage für Änderungen darstellen. Bei einer Änderung sind der Nutzen, Projektinhalte, Ressourcen, Zeitaufwand, Kosten, Qualität und Risiko zu analysieren und ihre Auswirkungen zu bewerten, bevor sie zur Umsetzung gelangen. In einem für das Projekt beschriebenen, Stakerholder-übergreifenden Änderungsverfahren muss definiert sein, wer wie Änderungen einreichen darf, wer diese Änderungen formal verfolgt und welcher Personenkreis Änderungen beschließen soll. Entscheidungen des Änderungsgremiums sind nachweislich zu protokollieren und allen relevanten Stakeholdern zur Verfügung zu stellen.

Änderungsliste (CR-Monitoring)

Betroffene Prozesse: Controlling von Änderungen (C) / Controlling der Projektarbeiten (C)

Durch das Führen und Pflegen einer Änderungsliste erhält man im Projekt eine Übersicht über die Bearbeitungsstände aller gestellten Änderungsanträge (CR). Neben der CR-Bezeichnung ist das Eingangsdatum sowie das Datum der benötigten Entscheidung durch das Änderungsgremium zu erfassen. Oft macht es Sinn, sogenannte CR-Klassen einzuführen, die den Grund des gestellten Antrags aufzeigen, wie z.B. Funktion, Anforderung, Nutzen, Kosten, Zeit. In aller Regel durchlaufen Änderungen einen 8-stufigen CR-Prozess. In der Liste ist die erreichte Stufe festzuhalten, um den Fortschritt der Änderungen darstellen zu können. Oftmals macht es Sinn, eine Priorität und den Nutzen zu bestimmen, um später ggf. Umpriorisierungen aufgrund von Engpässen leichter vornehmen zu können. Nach Entscheidung des Antrags ist das Entscheidungsdatum sowie der geplante Umsetzungstermin (GoLive) zu protokollieren. Ebenso sind die zeitlichen und finanziellen Aufwände für die Umsetzung einer Änderung zu erfassen. Über das CR-Monitoring erhält man eine visuelle Sicht auf diverse Informationen zu den Änderungsanträgen. Bei größeren Projekten empfiehlt es sich, für das CR-Management professionelle Workflow-Systeme einzusetzen.

 

Lessons Learned

Betroffene Prozesse: Sammeln der Lessons Learned (A)

Das Sammeln der Lessons Learned hat den Zweck, das Projekt zu evaluieren und Erfahrungen zusammenzutragen, von denen laufende oder künftige Projekte profitieren können. Die Durchführung von Lessons Learned erfolgen sinnvollerweise im Rahmen einer Projektabschlussveranstaltung mit dem Projektteam und ggf. mit anderen Stakeholdern. Wichtige Erkenntnisse bzw. Erfahrungen sind schriftlich zu fixieren und in die Organisation (Abteilung, Bereich, Team, etc.) zu kommunizieren. Typischerweise werden bei Lessons Learned kurz die Rahmenbedingungen bzw. Projektinhalte skizziert, das Problem formuliert, die ursprüngliche Erwartung/Planung aufgezeigt und das Ergebnis dargestellt. Das Verbesserungspotential bzw. der erzielte Nutzen ist zu beschreiben und anschließend mit einem Verbesserungsvorschlag oder Maßnahme zu versehen.

 

Projektabschlussbericht

Betroffene Prozesse: Abschließen der Projektphasen oder des Projekts (A) / Controlling der Projektarbeiten (C)

Das Abschließen der Projektphasen oder des Projekts hat den Zweck, die Fertigstellung aller Prozesse und Vorgänge des Projekts zu bestätigen, um eine Projektphase oder ein Projekt zu beenden. Zugleich erfolgt die Entlastung des Projektteams und ggf. ein operativer Verantwortungswechsel an eine Betriebseinheit oder bei Projektabbruch zurück an die kundenverantwortliche Einheit. Mit kundenseitiger Abnahme und Übergabe (gem. Protokoll) der Projektlösung startet der Projektabschlussprozess. Der Projektmanager überprüft die Zielerreichung sowie die Lieferung bzw. Umsetzung aller Liefergegenstände und hält das Ergebnis im Abschlussbericht fest. Die Entlastung des Projektteams wird mit Freigabe des Abschlussberichts durch den Projektauftraggeber bestätigt. Vorbehaltliche Freigaben sind möglich, sofern Nacharbeiten im begrenzten Umfang notwendig sind, die die Ressourcen nur geringfügig binden.

 

Hierzu gehören u.a.:

Abschlussbericht
Finanzbericht


Stakeholder

Stakeholderanalyse

Betroffene Prozesse: Ermitteln der Stakeholder (I) / Stakeholdermanagement (U)

Das Ermitteln der Stakeholder hat den Zweck, die Personen, Teams und Organisationen zu bestimmen, die vom Projekt betroffen sind oder das Projekt beeinflussen, um daraus die Auswirkungen auf die Zielerreichung zu analysieren und die Erkenntnisse in der späteren Projektplanung und -steuerung zu berücksichtigen. Das anschließende Managen der Stakeholder umfasst eine regelmäßige Überprüfung, inwieweit die Bedürfnisse und Erwartungen aller Stakeholder getroffen werden. Abweichungen bzw. Veränderungen sind in der Stakeholderanalyse anzupassen und ggf. mit neuen Maßnahmen zu versehen. Bei der Analyse sind die möglichen Interessen und Bedenken am Projektergebnis einzelner Stakeholder zu bestimmen, die erwartete Einstellung und der mögliche Einfluss über Auswahlkriterien einzustufen. Daraus leiten sich Art und Umfang notwendiger Maßnahmen ab.

 

Inhalte

Lasten- und Pflichtenheft

Betroffene Prozesse: Definieren des Leistungsumfangs (P)

Das Definieren des Leistungsumfangs hat den Zweck, Klarheit über den Projektinhalt zu schaffen, inklusive der Zielsetzungen, Anforderungen, Lieferobjekte und Abgrenzungen. Im Rahmen von Workshops und Abstimmungsgesprächen muss ein projektübergreifendes Lösungsverständnis geschaffen werden. Auf Basis einer detaillierten Anforderungsbeschreibung (=Lastenheft) ist ein projektspezifisches Lösungsdesign (=Pflichtenheft) zu erstellen, das von allen unmittelbar betroffenen Stakeholdern eine nachvollziehbare Zustimmung finden muss, bevor es in eine Umsetzung geht. Ein abgestimmtes Pflichtenheft gewährleistet eine zumeist objektive Überprüfbarkeit der erwarteten Lieferobjekte und ist die Grundvoraussetzung für das Starten eines von allen Beteiligten akzeptierten Änderungsprozesses. Bei einer agilen Entwicklungsmethode, wie Scrum, entspricht das Product Backlog dem Lastenheft und das Sprint Backlog dem Pflichtenheft, allerdings sehr viel kleinteiliger.

 

Hierzu gehören u.a.:

Lastenheft (Anforderungen)
Pflichtenheft (Spezifikationen)

Projektstrukturplan (PSP)

Betroffene Prozesse: Erstellen des Projektstrukturplans (P)

Das Erstellen des Projektstrukturplans hat den Zweck, eine hierarchisch gegliederte Darstellung der zur Erreichung der Projektziele auszuführenden Arbeitspakete und Aufgaben zu schaffen, wobei die Strukturierung und Detaillierung nach unterschiedlichen Kriterien erfolgen kann, wie z.B. Projektphase, Lieferobjekte, Organisation, Standort, Risiko. Eine zunächst erstellte Grobstruktur wird logisch und systematisch verfeinert, indem die Projektarbeit in immer kleinere und damit handhabbare Aufgaben und Arbeitspakete unterteilt wird. Dabei ist darauf zu achten, dass erfolgskritische Aufgaben explizit ausgewiesen sind, während Einzelschritte in sinnvolle Arbeitspakete zusammengefasst werden.

 

Hierzu gehören u.a.:

Projektstrukturplan (PSP)

Arbeitspaketspezifikationen

Betroffene Prozesse: Definieren der Arbeitspakete (P)

Das Definieren der Arbeitspakete hat den Zweck, alle Vorgänge und Aktivitäten, die im Rahmen der Arbeitspakete notwendig sind, zu beschreiben. Dies beinhaltet eine Festlegung der Verantwortlichkeit, der notwendigen Ressourcen, des Zeitraums, der Kosten sowie des Leistungsinhalts, die im jeweiligen Paket erforderlich sind. Die im Projektstrukturplan definierten Arbeitspakete und Aufgaben sind insbesondere hinsichtlich Ausprägung, Vorgehensweise und Aufwand zu beschreiben. Idealerweise werden die designierten Arbeitspaketverantwortlichen frühzeitig in dieser frühen Phase involviert. An AP-Schnittstellen hat stets eine beiderseitige Spezifikation zu erfolgen.

 

Ressourcen

Ressourcenplan

Betroffene Prozesse: Zusammenstellen des Projektteams (I) / Schätzen des Ressourcenbedarfs (P) / Festlegen der Projektorganisation (P) / Controlling der Ressourcen (C)

Das Erstellen eines Ressourcenplans dient dem Erfassen von personellen, ggf. auch materiellen Ressourcen, die für die Durchführung und den erfolgreichen Abschluss des Projekts benötigt werden. Über das Projektkernteam sind die Ressourcenbedarfe im Projekt zu identifizieren und die erforderlichen Zeiträume der zu rekrutierenden Ressourcen zu bestimmen. Nicht lösbare Ressourcendefizite (z.B. Skill, Verfügbarkeit) sind dem Projektauftraggeber aufzuzeigen, um so zu einer akzeptablen Lösung zu kommen.. Für jeden benötigten Projektmitarbeiter ist eine Auslastung über die Projektlaufzeit zu bestimmen und mit dem jeweiligen Ressourcenmanager nachweislich zu vereinbaren. Spätestens am Ende des Personalstaffingprozesses muss eine Projektorganisation vorliegen, die mit allen relevanten Stakeholdern abgestimmt ist. Während der Projektlaufzeit ist regelmäßig zu überprüfen, inwieweit die für das Ausführen der Projektarbeiten erforderlichen Ressourcen zur Verfügung stehen und entsprechend den Projektanforderungen zugeteilt sind.

 

Hierzu gehören auch:

Projektorganisation
Ressourcenvereinbarungen


Termine

Meilensteinplan

Betroffene Prozesse: Erstellen des Projektauftrags (I) / Erstellen des Terminplans (P) / Termincontrolling (C)

Das Erstellen eines Meilensteinplans dient dem Erfassen wichtiger Projektecktermine, die bereits in der frühen Phase der Projektgenerierung vorgegeben oder erkennbar sind. Ein grober Meilensteinplan sollte Teil des Projektauftrags sein, weil damit Planungsprämissen für die weitere Projektarbeit in aller Regel vorgegeben werden. Während der Detailplanung ist der grobe Meilensteinplan zu verifizieren, ggf. anzupassen bzw. zu erweitern. Der Meilensteinplan ist ein einfacher Übersichtsplan, der das Erreichen wichtiger Projektergebnisse oder Ereignisse auf einer Zeitachse abbildet. Er ist das Rückgrat des Projektzeitplans und muss in diesem natürlich identisch implementiert sein. Während der Projektlaufzeit sind anstehende Meilensteine stets kritisch zu prüfen und müssen bei Gefährdung oder Überschreitung im Projektlenkungsausschuss explizit behandelt und ggf. neu entschieden werden.

 

Hierzu gehören u.a.:

Meilensteinplan

Projektzeitplan

Betroffene Prozesse: Festlegen der Abfolge von Arbeitspaketen / Aktivitäten (P) / Schätzen der Dauer von Arbeitspaketen / Aktivitäten (P) / Erstellen des Terminplans (P) / Termincontrolling (C)

Das Erstellen des Zeitplans hat den Zweck, die Zeitpunkte für Beginn und Ende der Arbeitspakete und Aktivitäten zu berechnen und auf der Zeitachse zu terminieren. Der grobe Meilensteinplan wird auf Umsetzbarkeit verifiziert und ggf. weiter verfeinert. Die logischen Abfolgen und Dauern der Arbeitspakete und Aktivitäten werden mit den Meilensteinen in Abhängigkeit gesetzt. Bei Inkonsistenzen muss geprüft werden, ob Meilensteine über den Projektlenkungsausschuss verändert oder einzelne Abläufe zeitlich optimiert werden können. Der erste abgestimmte Terminplan ist als Basisterminplan festzulegen, an dem der Projektfortschritt gemessen wird. Eintretende Risiken, Zeitverzüge oder geänderte Anforderungen erfordern ggf. eine Plananpassung mit neuen Terminen.

 

Hierzu gehören u.a.:

Projektzeitplan (z.B. MS Project)

oder


Kosten

Kostenplan

Betroffene Prozesse: Schätzen der Kosten (P) / Erstellen des Projektbudgets (P) / Kostencontrolling (C)

Das Schätzen der Kosten hat den Zweck, Planungswerte für interne und externe Kosten zu erhalten, die für das Ausführen eines jeden Projektvorgangs erforderlich sind, um hieraus die benötigten Finanzmittel für das Projekt bestimmen zu können. In Folge dessen ist das Gesamtbudget des Projekts zu ermitteln, das mit dem Business Case oder ggf. dem Kundenvertrag in Einklang stehen muss. Die geschätzten Einzelkosten sind im Kostenplan in strukturierter Form zusammenzuführen und in einem Basiskostenplan zu fixieren, gegen den später die auflaufenden Kosten gespiegelt werden. Veränderte Plankostenwerte führen zu Anpassungen im Kostenplan, die in der Regel über einen Änderungsantrag genehmigt werden müssen.

 

Hierzu gehören auch:

Business Case
Lieferantenverträge
Preislisten


Risiko

Risikoplan

Betroffene Prozesse: Ermitteln der Risiken (P) / Risikobewertung (P) / Risikobehandlung (U) / Risikocontrolling (C)

Das Ermitteln der Risiken hat den Zweck, potentielle Gefahren, die die Projektziele bzw. den Projekterfolg negativ beeinflussen können, aufzuzeigen. Gleiches gilt auch für Chancen, die positiven Einfluss auf das Projekt nehmen können. Im Risikoplan sind zunächst alle potentiell sichtbaren Risiken zu erfassen. An diesem Prozess sollten möglichst viele Stakeholder mitwirken, um eine umfassende Sicht auf die Gefahren und Chancen im Projekt zu gewinnen. Für die erfassten Risiken sind jeweils das Schaden- bzw. Nutzenpotential mit einer Eintrittswahrscheinlichkeit zu bewerten und zu erfassen. Für jedes Risiko ist eine Maßnahme und die Verantwortlichkeit zu beschreiben. Die offenen Risiken werden in regelmäßigen Abständen überprüft und ggf. neu bewertet, eliminierte Risiken sind entsprechend zu kennzeichnen und neue Risiken aufzunehmen. Die festgelegten Maßnahmen sind unter Umständen anzupassen und im Projektteam zu kommunizieren. Gravierende Risikoveränderungen sind dem Projektauftraggeber aufzuzeigen, um die weitere Risikobehandlung und damit verbundene Maßnahmen besonders abzustimmen.

 

Hierzu gehören u.a.:

Risikoplan
Risikoanalysen
Risikoberichte


Qualität

Qualitätsplan

Betroffene Prozesse: Qualitätsplanung (P) / Qualitätssicherung (U) / Qualitätskontrolle (C)

Die Qualitätsplanung hat den Zweck, die Qualitätsanforderungen und -standards zu bestimmen, die für das Projekt und die Liefergegenstände notwendig sind und den Projektzielen entsprechen. Sie hat in enger Abstimmung mit der Erstellung des Pflichtenhefts zu erfolgen. In der frühen Planungsphase ist bereits mit dem Kunden ein Abnahmeverfahren zu definieren, weil dieses den Projektverlauf und den Terminplan beeinflussen kann. Der Projektmanager muss dafür sorgen, dass die Maßnahmen beschrieben werden, wie die Qualität des Projekts und der Liefergegenstände sichergestellt werden soll. Die Qualitätssicherung umfasst alle Prozesse, Werkzeuge, Verfahren, Techniken und Ressourcen, die zum Erfüllen der Qualitätsanforderungen erforderlich sind und erstreckt sich über die gesamte Projektlaufzeit.

 

Hierzu gehören auch:

Abnahmeverfahren
Qualitätsplan (Liefergegenstände)

Abnahme-/Übergabeprotokoll (Kunde)

Betroffene Prozesse: Qualitätskontrolle (C)

Die Qualitätskontrolle hat den Zweck, die Liefergegenstände und das Projekt auf ihren Sollzustand zu überprüfen. Während der Umsetzung ist bereits eine Testspezifikation zu erstellen, die das Testvorgehen in der Abnahmephase detailliert beschreibt. Für die Liefergegenstände sind nach der internen Qualitätskontrolle kundenseitige Abnahmen durchzuführen, entsprechend den Vorgaben in der Testspezifikation bzw. im Abnahmeverfahren. Das Ergebnis der Kundenabnahme ist in einem Abnahmeprotokoll (analog Abnahmeprotokoll Lieferant, siehe Beschaffung) zu dokumentieren. Für den Fall einer Abnahme auf einer Testinstanz, ist im Rahmen der Inbetriebnahme ein Antest der Kernfunktionalitäten erforderlich. Das Ergebnis ist auch hier in einem Übergabeprotokoll zu bescheinigen.


Beschaffung

Beschaffungsplan

Betroffene Prozesse: Planen der Beschaffung (P) / Auswählen von Lieferanten (U) / Steuern der Beschaffungen (C)

Das Planen der Beschaffung hat den Zweck, die Vorgehensweise und Verantwortlichkeiten in der Beschaffung zu planen und zu dokumentieren, um so die Beschaffungsentscheidungen zu erleichtern, Beschaffungsansätze festzulegen und Spezifikationen und Anforderungen für die Beschaffung zu erarbeiten. Im Beschaffungsplan sind die Lieferantenbedarfe zu erfassen. Es ist zu beschreiben, wie eine Lieferantenauswahl erfolgen soll und wer die Verantwortung für die Einkaufsleistung trägt. In dieser Phase ist ebenso das Abnahmeverfahren für die Lieferleistung zu beschreiben. Für das richtige Auswählen eines Lieferanten sind Informationen von Anbietern einzuholen, um eine konsistente Beurteilung von Angeboten im Hinblick auf die definierten Anforderungen zu ermöglichen. Darüber hinaus werden alle vorgelegten Informationen überprüft und begutachtet, um letztendlich die gewünschten Lieferanten zu beauftragen.

 

Hierzu gehören auch:

Anforderungsdokument
Spezifikation
Lieferantenangebot

Abnahmeprotokoll (Lieferant)

Betroffene Prozesse: Steuern der Beschaffungen (C)

Das Steuern der Beschaffungen hat den Zweck, die Leistungen von Lieferanten zu überwachen und zu überprüfen, um so die Erfüllung aller vereinbarten Projekt-anforderungen sicherzustellen. Dies beinhaltet auch die Termintreue, Qualität und Risikovermeidung. Es ist darauf zu achten, dass der Lieferant in der Projektkommunikation integriert ist, um so seinerseits Abweichungen oder Diskrepanzen während der Beschaffungsphase frühzeitig zu erkennen und aufzuzeigen. Es sind im Projekt Testpläne und -aktivitäten frühzeitig zu planen und für diese Phase geeignete Testressourcen ausreichend bereitzustellen. Die Lieferleistung eines Lieferanten ist intensiv zu testen und stets im vollen Umfang abzunehmen, bevor sie betrieblich genutzt wird. In dem Abnahmeprotokoll ist das Testergebnis zu dokumentieren und ggf. die Einschränkungen oder Auflagen zu benennen, die für die Einführung oder Inbetriebnahme von Bedeutung sind.


Kommunikation

Kommunikationsplan

Betroffene Prozesse: Planen der Kommunikation (P) / Bereitstellen von Informationen (U) / Kommunikationsmanagement (C)

Das Planen der Kommunikation hat den Zweck, den Informations- und Kommunikationsbedarf der Stakeholder zu bestimmen. Der Kommunikationsplan beschreibt die Informationserwartungen aller relevanten Stakeholder. Im Kommunikationsplan sind dazu die regelmäßig geplanten Meetings und Informationsveranstaltungen festzulegen und an alle relevanten Stakeholder zu kommunizieren. Entsprechendes gilt für das Berichtswesen im Projekt. Das Erstellen und Verteilen von Projektinformationen versteht sich grundsätzlich als Bringschuld und hat verlässlich zu erfolgen. Projektmeetings und Lenkungsauschüsse sind frühzeitig und regelmäßig zu vereinbaren und durchzuführen. Es ist stets sicherzustellen, dass bei Abwesenheit wichtiger Informationsträger Vertreter bestimmt sind, die der Informationspflicht nachkommen können. Der Projektmanager muss gewährleisten, dass der Kunde und das Projektteam ausreichend über den Projektfortschritt informiert sind. Bei auftretenden Kommunikationsproblemen sind diese unmittelbar und dauerhaft zu lösen, um Missverständnisse unter den Stakeholdern zu beseitigen und zukünftig zu vermeiden.

 

Hierzu gehören u.a.:

Kommunikationsplan
Informationsveranstaltungen
Meetings
Projektinformationen
Schulungsunterlagen
Handbücher