Der Nutzen zählt! Qualität und Rationalisierung durch den IT-PM Prozess in der Würth Gruppe

Transkript

1 Pmforum der GPM: < Best Practice im Projektmanagement > Oktober 2004 Meistersingerhalle Nürnberg Vortrag, , Uhr (45 min), Thema: Der Nutzen zählt! Qualität und Rationalisierung durch den IT-PM Prozess in der Würth Gruppe _pjmsp_Lecture_PmForum-Nuernberg.docSeite 1 von

2 Inhaltsverzeichnis 1 Qualität & Rationalisierung in IT-Projekten Definition von Qualität und Wirtschaftlichkeit in IT-Projekten Rationalisierung im Projektmanagement der Würth Phoenix Das globale Handlungsmodell des PjMSP Die Grundlagen Das Prozessmodell des Projektmanagements Ziele, Vorgehensweise und Wirkung der Standards im Projektprozess Der Projekt Management Standard Prozess (PjMSP ) Übersicht der Prozesselemente Gesamtdarstellung PjMSP Der Planungsprozess im PjMSP Das Projektdatenflussmodell Struktur des Projektdatenflussmodells Die Würth Phoenix Prozess-Vorlagen und die Resourcen-Datenbank Die Durchführungsphase des PjMSP Standardisierte Projektsteuerung Beispiel: Vertrags- und Claimmanagement Auszug aus dem Standard-PjM-Arbeitspaket Projektsteuerung Das Arbeitspaket als Kernelement für die Projektausführung Kontrolle im PjMSP Das tragende Kontrollelement ist der Vorgang Der Vorgang im Arbeitspaket Die Aufbau-Organisation des PjMSP Identität von Projekt- und Unternehmenszielen PM-Organisation bei Würth Phoenix: WoP-Resp, PjMgr, PjCO, PjMO Der Kundennutzen: Hohe Ergebnisqualität und grosse Transparenz Kommunikation der Qualität Ständig der komplette Überblick: das gläserne Projekt Perspektive für die Vergrösserung des Kundennutzens _pjmsp_Lecture_PmForum-Nuernberg.docSeite 2 von

3 Autor Clemens Drilling, Würth Phoenix s.r.l., Bozen/Italien Nach dem Studium der Nachrichtentechnik in Stuttgart und Darmstadt 1990 Start als Systementwickler im Daimler Benz Konzern, Stuttgart. Aufgaben in der Entwicklung von Fahrzeug- Diagnosesystemen, später Beratung, Projektleitung und Abteilungsleitung. Beteiligung an gemeinsamen internationalen Projekten der europäischen Automobilindustrie Wechsel nach Hamburg und Übernahme der Entwicklungsleitung eines Softwarehauses im Bereich Alten- und Krankenpflege. Aufbau eines Projektmanagementsystems für Entwicklungsprojekte. Ab dem Jahr 2000 als Technischer Leiter verantwortlich für alle Implementierungsprojekte elektronischer Anlagen und Mess-Systeme in der holzverarbeitenden Industrie beim Weltmarktführer in Brixen/Südtirol.. Leitung von Projekten in Europa und Südamerika. Seit 2002 Leiter des internationalen Projektmanagements der Würth Phoenix Gruppe in Bozen. In 2004 Entwicklung und Implementierung des Project Management Standard Process PjMSP _pjmsp_Lecture_PmForum-Nuernberg.doc Seite 3 von

4 1 Qualität & Rationalisierung in IT-Projekten 1.1 Definition von Qualität und Wirtschaftlichkeit in IT-Projekten Grundsatz: Es gibt keinen Widerspruch oder Konflikt zwischen Qualität, Normeinhaltung und Wirtschaftlichkeit. In diesem Wirkungsdreieck ist Projektmanagement der Katalysator und das Werkzeug zur Umsetzung der Rationalisierungspotentiale und zur Absicherung der Vorgehens- und Ergebnisqualität. Abbildung 1: WIrkungsdreieck Normen-Qualität-Projektmanagement Es sind prinzipiell alle relevanten Standards gemeint, d. h. im Einzelfall sowohl die jeweiligen Fachnormen, also hier die IT-Normen, als auch die Projektmanagement-, Geschäftsprozess- und Organisationsnormen, durchaus in einer internationalen Mischung. Die Verifikation der Normen geschieht einerseits durch die Prüfung (Auditierung) der Implementierung der Normen in den Geschäftsprozessen und andererseits durch die Anwendung in den Projektprozessen. Relevanznachweis: Prinzipiell und branchenneutral liefern Normen die gesicherten Erkenntnisse nach dem Stand von Wissenschaft und Technik. Die Verifikation der Normeinhaltung über die Kalibrierung (Zertifizierung) schafft das notwendige Vertrauen, sowohl beim Kunden als auch Projekt-intern hinsichtlich der Handlungssicherheit in den Geschäfts-/Projekt- Prozessen _pjmsp_Lecture_PmForum-Nuernberg.doc Seite 4 von

5 Projekte basieren einerseits methodisch ebenfalls auf internationalen Standards und sind andererseits durch die darauf aufbauenden PM-Prozesse mit der ständige Kontrolle der Einhaltung von Terminen, Kosten, Leistungen und Zielen ein Garant für eine effektive, erfolgreiche Vorgehensweise zur Zufriedenheit des Auftraggebers. Rationalisierung, d. h. die Steigerung der Wirtschaftlichkeit, bei der Herstellung von Produkten und/oder der Erbringung von Dienstleistungen ist ein nachhaltiger Erfolg einer kontinuierlichen Anwendung dieser Strategie. Die Verifikation der Qualität des Projektmanagements geschieht anhand der PM- Normen (DIN 69xxx, DIN EN 10006,7, PMBoK-Guide, Prince2) IT-Normen die Grundlage für die Systementwicklung und den -betrieb DIN ISO IEC IT - Software Erzeugnisse Qualitätsanforderungen und Prüfbestimmungen ISO IEC Teil 1-6 Software Product Evaluation ISO/IEC IT Software Life Cycle Process DIN Software - Fehler und ihre Behandlung in Vertragsverhältnissen DIN ISO 9000 Teil 3 Qualitätsmanagement- und Qualitätssicherungsnormen - Leitfaden für die Anwendung von ISO 9001 auf die Entwicklung, Lieferung und Wartung von Software Weiterhin für die Zielabsicherung: DIN EN Wertanalyse (Value Management) _pjmsp_Lecture_PmForum-Nuernberg.doc Seite 5 von

6 1.2 Rationalisierung im Projektmanagement der Würth Phoenix Rationalisierung wird definiert als das Erreichen eines Zieles gleichbleibender Qualität mit reduzierten Mitteln. Würth Phoenix hat als IT-Unternehmen der Würth-Gruppe den Projektmanagement Standard Prozess PjMSP definiert und eingeführt. Mit der Einführung des PjMSP wird erhebliches Rationalisierungspotential im obigen Sinne in der täglichen Projektpraxis realisiert. Die Teilprozesse im Projektmanagement werden beschleunigt. Der Aufwand in der Planung wird um bis zu 30% reduziert, weil mit den Prozess-Templates auf die Ergebnisse (und Erfahrungen) früherer Projekte zurückgegriffen werden kann und basierend auf diesen eine schnelle Adaption an die gegenwärtigen projekt-individuellen Rahmenbedingungen möglich ist. Durch die starke Automatisierung werden die Kosten der Aktivitäten in der Durchführungs- und insbesondere Conrollingphase im Mittel auf 60% gedrückt. Der Abstimmungsaufwand zwischen den Fachteams verringert sich. Bei Würth Phoenix werden Kundenprojekte in Zusammenarbeit von Projektmanagement, Beratung, Analyse, Implementierung, Integration und IT-Service Management durchgeführt. Der PjMSP beschreibt mit seiner Struktur auch die prozessuralen Schnittstellen zu den Fachteams und verbessert damit erheblich deren Zusammenarbeit, was letztendlich den Rationalisierungseffekt bewirkt. Die fachlichen Abstimmungen in jeder Projektphase werden schneller als zuvor durchgeführt, die Qualität hat sich zudem deutlich gesteigert. Der Kommunikationsaufwand zwischen den verschiedenen Standorten reduziert sich. Würth Phoenix arbeitet heute an 10 Standorten weltweit, von der Produktentwicklung in China bis hin zu den Integrationszentren in Europa und Nordamerika. An Kundenprojekten sind i.d.r. bis zu 40 Mitarbeiter aus mehreren dieser Standorte beteiligt. Der PjMSP wurde gleichsam als gemeinsame Prozess-Sprache im Projektmanagement eingeführt und bewirkt einen deutlichen Synchronisationseffekt hinsichtlich Begriffen und Vorgehen. Das Glossar wie auch die Prozesse sind im Projektmanagement Handbuch weltweit eindeutig formuliert. Die Einarbeitung von Prozessbeteiligten Kunden gleichermassen wie neue Mitarbeiter hat sich gerazu dramatisch verkürzt. Das detaillierte schriftliche Material, die vorliegenden Dokument- und Prozess-Templates sowie das spezifisch angebotene PjMSP Training an der Akademie der Würth Phoenix haben daran einen starken Anteil. Dauerte die Ausbildung neuer Projektmanager vorher mehrere Monate, so kann diese Aufgabe heute nach 4-6 Wochen als abgeschlossen angesehen werden. Damit kann das starke und schnelle Wachstum der Würth Phoenix auch im Projektmanagement realisiert werden _pjmsp_Lecture_PmForum-Nuernberg.doc Seite 6 von

7 2 Das globale Handlungsmodell des PjMSP 2.1 Die Grundlagen Das Prozessmodell des Projektmanagements Projektmanagement ist von einer Spezialdisziplin zu einer Profession geworden. Entscheidend für den Durchbruch sind die Wahrnehmung der Erfolgsursachen, auf den Grundlagen Soziale und Methodenkompetenz ist es das zielführende Prozessdenken vom Auftrag zum Ergebnis und das ganzheitliche Denkmodell für die Integration der Umwelt, dargestellt im Prozessmodell-Schaubild. Abbildung 2: das Kernprozessmodell des Projektmanagements Ziele, Vorgehensweise und Wirkung der Standards im Projektprozess Die Einführung von Projektmanagement in einem Unternehmen hat die Ziele: Verbesserung der Wirtschaftlichkeit (Rationalisierung), Erhöhung der Kundenzufriedenheit, Wettbewerbsfähigkeit, hoffentlich unter den vorstehend in 2.1 genannten Ansätzen. Damit diese firmenspezifischen unternehmerischen Ziele nachhaltig wirksam und reproduzierbar verwirklicht werden können, bedarf es einheitlicher allgemeingültiger Regelungen (Standards) für Begriffe, Dokumente, Werkzeuge, Strukturen, Zusammenhänge, Aufbau- und Ablauforganisation sowie der Arbeitsabläufe als Grundlage für die Geschäftsund Projektprozesse, was normalerweise in einem Projektmanagement Handbuch PMHB, speziell für eine Firma, zusammengetragen wird. Daraus ergibt sich auch, dass ein PMHB genau so wenig dem andere gleicht, wie die Unternehmen, für die sie aufgestellt werden. Damit das PMHB die Projektprozesse wirksam unterstützen kann, müssen die Regeln durch Workflows und Templates operationalisiert werden. Das ist die Verknüpfung von Prozess _pjmsp_Lecture_PmForum-Nuernberg.doc Seite 7 von

8 und Standards. Die zielführende Flexibilisierung der Projektprozesse, die auf die unterschiedlichsten Kundenauftragsziele ausgerichtet werden müssen, bedingt genau so variable Arbeitsmethoden- und mittel. Abbildung 3: Wirkung der Standards im Projektprozess _pjmsp_Lecture_PmForum-Nuernberg.doc Seite 8 von

9 2.2 Der Projekt Management Standard Prozess (PjMSP ) Übersicht der Prozesselemente Die drei Säulen des PjMSP sind: die Standards (Lernende Organisation mit PM-Handbuch, Templates, Tools, Ressourcen- DB) die Definition der Prozesse (duales Modell: Projektmanagement- und Projektprozess) die Projektakte (PM-Unterlagen, Produktdokumente) Ein PM-Standard von der Qualifizierung bis zur Operationalisierung: Die internationalen Grundlagen (IPMA, PMI) werden adaptiert und als Richtlinie (PMHB) in umsetzbarer Form (Workflow, Checklisten, Templates) mit einer Ausführungsanweisung ebenfalls zur Grundlage der Team-Qualifizierung gemacht. Die Templates sind die einerseits vereinfachte aber auch vollständige Umsetzung der Methodenanwendungen und Regeln in die tägliche Praxis, in Form von Tabellen und Arbeitsablaufbeschreibungen. Die Einsatzmittel-Informationen über Verfügbarkeit und Kosten auf der Datenbankplattform von MS Project Enterprise sichern letztendlich die Machbarkeit des Projektes. Die Nützlichkeit der Werkzeuge (Software wie Visio, Word, Excel, Powerpoint, MS Project, MS Outlook) hängt direkt von dem Grad der Anpassung (Customizing, Konfiguration) sowohl an die Anwenderbedürfnisse als auch an die Geschäftsprozesse (zb. Enterprise- Version, DB-Implementierung, Kommunikation) und der Anwenderqualifizierung ab. Für eine einfache Nutzen-Kosten-Bilanz empfiehlt sich folgende Aufstellung. Geschäftsziel Nutzen/Ergebnis Methoden Werkzeuge Mitarbeiterprofil/Skill Kosten Definition der Prozesse: Allgemein ist Projektmanagement der Regelkreis auf dem Projekt (duales Prozessmodell). Deswegen wird im PjMSP ganz klar unterschieden zwischen: Projektmanagementprozess: Die branchenneutrale PM-Methodenabfolge quer durch die Phasen Initialisierung/Planung/Ausführung (Steuerung)/Kontrolle/Abschluß, wird durch eine Zwangsfolge bestimmt, die sich aus der Logik der revolvierenden Entstehung und Qualifizierung der Projektmanagementdaten (Projektdatenflussmodell) ergibt. Projektprozess: PM steuert den eigentlichen Projektprozess, der von den fachlichen, branchenspezifischen Technologieprozessen bestimmt und den Produktdaten gesteuert ist, die die Herstellung der Produkte bzw. die Durchführung der Dienstleistungen mit den verbundenen Dokumenten ermöglichen _pjmsp_Lecture_PmForum-Nuernberg.doc Seite 9 von

10 Die Projektakte: Die Projektmanagementdaten und die Querverweise auf die Projektergebnisse (Dokumente, Produkte, Dienstleistungen) werden gesammelt und sind nach dem Prinzip jedes Datum nur einmal in der Projektakte mit der gleichen Struktur verfügbar, wie durch die Methodenfolge vorgegeben wird. Diese PM-Daten aus der Planung, Steuerung und Kontrolle des Projektes unterliegen der ständigen Änderung und Qualifizierung. Ihre Aktualität endet mit dem Projekt. Abb. 4: PjMSP - Übersicht _pjmsp_Lecture_PmForum-Nuernberg.doc Seite 10 von

11 2.2.2 Gesamtdarstellung PjMSP Abb. 5: PjMSP im Detail _pjmsp_Lecture_PmForum-Nuernberg.doc Seite 11 von

12 3 Der Planungsprozess im PjMSP 3.1 Das Projektdatenflussmodell Im Laufe des Projektlebenszyklus werden die Daten von Anfang bis Ende immer wieder originär verwendet und/oder ständig weiterentwickelt. Aus Gründen der Kontinuität und der Qualität ist es das Ziel, jedes Ergebnis nur einmal aufzuschreiben und dann durchgängig zu benutzen. Die Konsequenz ist ein Projektdatenflussmodell, in dem die ständige Transparenz, Verfügbarkeit, Operationalisierung und Kontrolle der Daten durch eine Struktur gewährleistet ist. Das Ergebnis ist die Konsistenz und Durchgängigkeit von der ersten Datengenerierung über alle Wieder- und Weiterverwendungen. Abb. 6: das Projektdatenflussmodell _pjmsp_Lecture_PmForum-Nuernberg.doc Seite 12 von

13 3.1.1 Struktur des Projektdatenflussmodells Die ersten Projektdaten (Planungselemente) entstehen innerhalb der Planungsphase in zwei Abschnitten, in denen sie schrittweise verbessert und ergänzt werden, was durch den Aufbau der Templates und den vorgegebenen Arbeitsablauf unterstützt wird. Planung Methoden Methodenbeschreibung Grobpl anung Erzeugung der Planungselemente Phasenplan Auftragsanalyse Organisation Zielidentifikation Umfeldidentifikation Stakeholderidentifikation Risikoidentifikation Anordnung der Planungselemente auf der Zeitachse Abnahme Grobplanung Erzeugung der Planungselemente - Datenflussbeschreibung: a) Auftragsanalyse: Die Anforderungen/Vertragsgegenstände werden direkt sowohl in die Organisation als auch in die Ergebnisziele übernommen, genau so gehen die Ausführungs- /Rollenbeschreibungen direkt in die Organisationsvorgaben für die Rollen und die Kompetenzanforderungen ein. Kosten/Aufwand, Zeitplan und Qualität werden in den Vorgehenszielen direkt eingesetzt. b) Organisationsplan: Ausser der Zuordnung von Organisationen/Instanzen und Kompetenzprofilen zu den Auftragsabforderungen, werden die letzten durch Standardelemente ergänzt, die wiederum in die Ergebnisziele übernommen werden. c) Zielidentifikation: Die Anforderungen aus dem Vertrag und der Organisation finden sich alle in den Ergebniszielen wieder, die durch die Vorgehensziele operationalisiert werden, unter Benutzung der vorherigen qualitativen Beschreibung. Hier besteht die erste Verbindung zu späteren Arbeitspaketen, in denen diese ausführbaren Zieldefinitionen in Vorgänge umgesetzt werden. d) Umfeldidentifikation: Die Beschreibung und Operationalisierung der Ergebnisziele durch die Vorgehensziele enthält alle Objekte, die hier mit den dazugehörenden Dokumenten zusammengestellt werden und dadurch die Liefergegenstände des Projektes beschreiben, die Inhalt der Arbeitspakete sind. e) Stakeholder- und Risiko-Identifikation: Alle bisher ermittelten Planungselemente haben einen Bezug zu einem Stakeholder und/oder sind mit einem Risiko behaftet. Die Abwicklung der jeweiligen Aktionen wird in den entsprechenden Arbeitspaketen vorgenommen _pjmsp_Lecture_PmForum-Nuernberg.doc Seite 13 von

14 Beispiel: Datenentstehung und transfer in der Grobplanung. Code Demand Amount Schedule Quality / performance Execution (R) or (E) OA01 What? EUR/workdays/etc. When? How? Who/Responsible/Executing ProjectOrganizationPlan work-item or project roles Work items (OA xy ) Cross Functions (CRF xy ) Roles (ROL xy ) Organizational Structure of Würth Phoenix BI- PjM BI-FIT BI-IMP BI- INT BI- ISM SWS Executive management... Cu sto me r Su ppl ier Skills Competence Overall skills special skills Tool usage competence Final targets Process targets Code WHAT Date, amount and unit Priority ranking A, B, C Code WHO (R)esponsible (E)xecutive HOW Method WHEN Start-End WHY Benefit in EUR or other unit WBS-Code Environment element Document / Deliverable Responsible resource References WBS code Work package Code Description Name Code Description Target Stakeholder Risks WBS-Code Stakeholder identification (restricted access rights) SH-Code Priority: A, B, C Stakeholder-identification Comes out of: - Organization - Final or process target - Environment element - Externals Benefit or damage For the project Benefit or damage For the stakeholder Plan of action (A)ction Description (R)esponsible person (D)ate WBS-Code Risk identification and evaluation table Code Priority: A,B,C Risk-identification Comes out of: - Organization - Final or process target - Environment element - Stakeholder Risk costs Probability and date of occurrence Plan of Action (A)ction (R)esponsible person (D)ate WBS-Code Diese Planungselemente werden im Phasenplan auf der Zeitachse angeordnet und im Projektstrukturplan zu ausführbaren Arbeitspaketen detailliert und zusammengestellt _pjmsp_Lecture_PmForum-Nuernberg.doc Seite 14 von

15 3.2 Die Würth Phoenix Prozess-Vorlagen und die Resourcen-Datenbank Die Erfahrungen mit IT-Projekten belegen, dass Fehler, die während der Planungsphase gemacht werden, am Ende eines Projektes das meiste Geld kosten nicht selten werden Projekte aufgrund von Planungsfehlern ganz abgebrochen. Im Projektmanagement von Würth Phoenix wird deshalb besonderer Wert darauf gelegt, dass alle Planungsaktivitäten auf Basis bereits existierender Erfahrungen stattfinden. Diese Qualitäts- und Rationalisierungsstrategie findet ihre Umsetzung in Prozess-Vorlagen. Solche Vorlagen existieren für praktisch alle Planungselemente des PjMSP, so auch für den Projektphasenplan. Hier sind die typischen Phasen von Würth Phoenix Projekten definiert wie auch die zugehörigen Meilensteine und Liefergegenstände. In dieser Form ist der Phasenplan auch zentrales Kommunikationsmittel mit dem Kunden. Die Prozess-Vorlage Projektstrukturplan ist bei Würth Phoenix grundsätzlich phasenorientiert, was zum einen der Denkweise der meisten Kunden entgegenkommt und außerdem gestattet, den Strukturplan aus dem Phasenplan heraus zu entwickeln, ja sogar beide Pläne im gleichen Werkzeug darzustellen und weiterzuentwickeln. Die integrierte Weiterentwicklung im gleichen Werkzeug ist eine wesentliche Voraussetzung zur Rationalisierung. Eine dritte wichtige Prozess-Vorlage ist das Arbeitspaket, in welchem eine Gruppe von Aktivitäten sinnvoll zusammengefasst wird. Der Nutzen der Prozess-Vorlagen und damit ihr Rationalisierungspotential ist desto stärker, je öfter ähnliche Projekte durchgeführt werden, denn je mehr Vorlagen für Fachapplikationen vorliegen, um so verlässlicher ist die Planung der Kundenaufträge. Die Benutzung und das Management der Prozess-Vorlagen bedingt eine adäquate Qualifizierung für den PjMSP. Die Prozess-Vorlagen sind gleichsam der strukturelle Ort der lernenden Organisation, sie werden mit jedem Projekt verfeinert und im Sinne von Best Practices im Projektmanagement optimiert. Unterstützt wird dieser Prozess durch die Tatsache, dass Würth Phoenix immer wieder wenn auch nicht die gleichen, so doch ähnliche Projekte durchführt, nämlich die Einführung seiner (ERP-) Produkte und den damit verbundenen Migrationsaufgaben. Damit basiert die Rationalisierungsstrategie der Würth Phoenix auf den folgenden Ebenen: Ebene 1: Die konsequente weltweite Verwendung des Handlungsmodells PjMSP Ebene 2: Die Verwendung und kontinuierliche Optimierung der Prozess-Vorlagen für Phasen- und Strukturpläne für die Grobplanung. Ebene 3: Die Verwendung und kontinuierliche Optimierung der Prozess-Vorlagen für aller Arten von Arbeitspaketen für die Feinplanung. Ebene 4: Die Durchführung der Ressourcenzuordnung zu Aktivitäten mithilfe einer Resourcen-Datenbank. Insbesondere die Realisierung der Ebene 4 ist nur unter Einsatz eines Werkzeuges sinnvoll denkbar. Die Resourcen-Datenbank der Würth Phoenix enthält für alle potentiellen _pjmsp_Lecture_PmForum-Nuernberg.doc Seite 15 von

16 Projektmitarbeiter (zur Zeit etwa 200 Mitarbeiter) das individuelle Qualifikations- und Erfahrungsprofil sowie die für neue Projekte zur Verfügung stehenden Zeiten. Es ersetzt natürlich nicht das persönliche Gespräch im Vorfeld einer festen Projektzuordnung, ist jedoch zur Planungsunterstützung sehr wertvoll _pjmsp_Lecture_PmForum-Nuernberg.doc Seite 16 von

17 4 Die Durchführungsphase des PjMSP 4.1 Standardisierte Projektsteuerung Die Freigabe des Projektprozesses durch den Auftraggeber ist erfolgt, ebenso die Projektdurchführungsplanung. Alle PM-Tätigkeiten in der Projektdurchführung haben das Ziel, die Herstellung/Durchführung der im Kundenauftrag festgelegten Produkte, Dienstleistungen und Dokumente zu unterstützen, neben dem Projekt-Kontrolle (s.u.) Neben der Ausführung der Planungen gibt es zusätzliche Aufgaben für den PMgr.: Issue Management für ungeplante Ereignisse Änderungsantrags Management für ungeplante Änderungen in den Planungselementen Workflow chart Input Workflow Output Project Folder Perform the PjM-tasks related to Projectfolder: 1 st baseline execution: plan PjM WoP 1. Purchase & Solicitation Documentation of suppliers and deliverables PjM-Execution 2. Team-member qualification Action-item-list 3. Issue management Issue list transfer to WoP 4. Communication management Communication deliverables 5. Jour Fixes Meetings list and protocolls 6. Stakeholder Actions Stakeholder action item list 7. Risk Actions Risk action item list 8. Contract & Claim management Contracts, Changes and Claim documentation 9. Document management Document item and version list 10. Change Request management Change Requests documentation and transfer to WoP Die einzelnen Aufgaben und Tätigkeiten sind, wie in der Planung, mit Workflows, Checklisten und Templates hinterlegt. Diese Daten werden 1:1 mit den dazu gehörenden Arbeitspaketen verknüpft, so daß die Integration vom Planung, Steuerung und Kontrolle gewährleistet ist _pjmsp_Lecture_PmForum-Nuernberg.doc Seite 17 von

18 4.1.1 Beispiel: Vertrags- und Claimmanagement Step 8 Contract & Claim Mgmt 8.1 Contract management: all related activities for generating contracts have to be defined in single work packages see template The table Contract Analysis is a accumulated view on all contracts from the ProjectFolder which is a task of the PjMgr. 8.2 Claim Management: is the management of outstanding debits because of changes. In projects changes (see also 1.10 change request management) generate variances in costs, time, quality. But all changes should lead to work package additions which are traceable. The table Contract Change Management is a accumulated view on all contract changes from the Project Folder which is a task of the PjMgr. Contract Analysis list of all contracts in the project WBS- Code of Contract /related WoP CONTRACT Name No. TYPE Reference: Environment, Target, Organization WHAT Contents Chances & risks of contract fulfillment RESTRICTIONS Definitions rules, laws FORM (R)esponsible (E)xecution Table 1: Contract management table Contract change management WBS-Code of Contract /related WoP Contract changes content Source for changes Additional costs Quality impact Project prolongation (R)esponsible (E)xecution Approval objective Approval legal Table 2: Contract change management table Claim management WBS-Code of Contract /related WoP Total costs of each change Invoice Recipient (R)esponsible (E)xecution Table 3: Claim management table _pjmsp_Lecture_PmForum-Nuernberg.doc Seite 18 von

19 4.1.2 Auszug aus dem Standard-PjM-Arbeitspaket Projektsteuerung Project code Work Package (WoP) WBS-Code Projektsteuerung Version 1 date1 Sum Duration 1d Responsible Version 2 Sum Work 0d Version 3 Work Package Information Cost of communication address NicName Cost/h ressources [ ] fix costs [ ] mamy@firma.abc MAMY 777 name2@firma.abc NA MAMY cost of material Predesessor wbs-codes Successor wbs-codes Interface wbs-codes Data Input wbs-codes Signature Project Manager WoP Responsible Date List of deliverables WBS-Code Deliverable Delivery Date D1: nameofdocument date D2: nameofobject date D3: Vertragstabelle endofwop D3: Vertragsänderungentabelle endofwop D3: Claimmangementtabelle endofwop WBS-Code Final-&Process targets Duration Work Execution from to [d] Resources Start of work package start start 0 MAMY Coordinate work package activities from to 10 MAMY Auftragsanalyse From To 10 NA Vertragsänderungen From To 10 NA Claimmanagement From To 10 NA final report of work package start end 5 MAMY end of work package end end 0 MAMY WBS-Code Stakeholder- & Risk Actions Duration Work Execution from to [d] SH-Code, name of action start end 55 MAMY MAMY _pjmsp_Lecture_PmForum-Nuernberg.doc Seite 19 von

20 4.2 Das Arbeitspaket als Kernelement für die Projektausführung Durch das Arbeitspaket als Strukturelement des PjMSP findet sowohl eine arbeitstechnische wie auch begriffliche Entmischung der IT Organisationseinheiten (Beratung, Analyse, Projektbüro,...) einerseits und dem Projektmanagement andererseits statt. Es wird damit eine durchgängige Referenzierung aller Prozesselemente im Projektablauf in einer sachgemäßen Detaillierung möglich, die eine verursachungsgerechte Planung, Durchführung und Kontrolle von Terminen, Kosten und Ressourcen bewirkt. Die Gesamtheit der Arbeitspakete enthält (die Referenz auf) alle Planungselemente des PjMSP. Würth Phoenix setzt als Werkzeug zur Implementierung des PjMSP die Enterprise Version von Microsofts MS-Project ein. Jedes Arbeitspaket wird als separate MS-Project-Datei erstellt. Die Strukturvorgaben für Arbeitspakete liegen als MS-Project Prozess-Vorlagen im Projektarchiv des Servers. So wird beispielsweise zwingend vorgegeben, dass jedes Arbeitspaket einen Start- und Ende- Meilenstein enthält, dass die erste Aktivität die Anpassung und Freigabe des Arbeitspaketes durch den Arbeitspaket-Verantwortlichen ist, dass dieser Aktivität der Sammelmeilenstein Liste der Arbeitspaketergebnisse folgt, der alle Ergebnisse dieses Arbeitspaketes enthält, usw. In der Projektdatei Master Schedule werden als Sammelvorgänge die Phasen des Projekts aus dem Phasenplan eingetragen. Da der Projektstrukturplan stets phasenorientiert ist, können die Arbeitspaket-Dateien dann unter die einzelnen Phasen importiert werden. Damit enthält eine einzige Datei komplett alle Elemente (bzw. Referenzen auf Elemente) der Projektplanung: Phasen, Meilensteine, Struktur, Arbeitspakete, Liefergegenstände, Aktivitäten, Ressourcen, Kosten, Zeitdauern und Arbeitsaufwände des gesamten Projektes. Bei Würth Phoenix besteht ein Projekt im Mittel aus Arbeitspaketen in 6-10 Projektphasen zeitlich verteilt. Import- und Exportfunktionen von Würth Phoenix ermöglichen den Austausch von Arbeitspaketdateien entweder als MS-Projectoder Exceldateien, je nachdem ob der jeweils Arbeitspaket-Verantwortliche über die entsprechende Lizenz verfügt oder nicht. Die beschriebene Implementierung des PjMSP durch das Werkzeug macht die Durchführung des PjMSP bzw des Projektes auf Basis des PjMSP erst möglich. Ohne die automatisierte Zusammenfassung des Projektes in einer Datei wäre die kontinuierliche Pflege und Weiterentwicklung der Arbeitspakete mit einem vertretbaren Aufwand nicht möglich. Abb. 7: die PjMSP Netzwerkstruktur Client-Server _pjmsp_Lecture_PmForum-Nuernberg.doc Seite 20 von

21 5 Kontrolle im PjMSP 5.1 Das tragende Kontrollelement ist der Vorgang Nur die Kontrolle der einzelnen Vorgänge (bottom up) bietet die verläßliche Grundlage zur Projektsteuerung. Aber auf keinen Fall ist es die Aufgabe des Projektleiters, jeden Vorgang selbst zu prüfen. Das liegt in der Verantwortung des Ausführenden und des Arbeitspaketverantwortlichen. Letztendlich entscheidet die Kundenabnahme des Arbeitspaketergebnisses. Die Vorgangs-/Team-scharfe Effizienzeinschätzung gibt die Möglichkeit für verursachungsgerechte Maßnahmen zur Einhaltung von Zeit, Kosten und Leistung bei Abweichungen. Im Gegensatz dazu werden durch top-down Projektquerschnittskennzahlen alle Teams über einen Kamm geschert. Welche Instanz im Projekt in welchem Detaillierungsgrad kontrolliert, ist fallweise festzulegen und liegt in der Verantwortung des Projektleiters. Es gilt allerdings der Grundsatz, ohne Daten keine Information und schon gar keine Prognose über den Projektverlauf. Zusammenfassung: Die Verfolgung der TKL-Daten und deren Abweichung vom Basisplan Die Ermittlung von Wirkungen und Prognosen aus dem SOLL-IST-Vergleich, Die Einleitung von Folgeaktionen zur TKL-Einhaltung, Die Einhaltung der Würth-Phoenix PjM Standards, Die Kommunikation aller relevanten Kontrolle Daten. Beispiel aus dem Würth Phoenix Operations Manual Workflow chart Input Workflow Output Project Folder 1 st baseline plan PjM WoP PjM- Kontrolle Perform the PjM- Kontrolle-tasks: Projectfolder: 1. TCP-Kontrolle and EVA Status reports, prognosis, changes and calibration 2. MTA & CTA Graphic status presentations 3. WoP revision WoP status list 4. Stakeholder Balance Stakeholder Balance document 5. Risk Balance Risk Balance document 6. PJM Quality Mgmt Checklist 7. Individual Target agreements review P2P project to person agreement _pjmsp_Lecture_PmForum-Nuernberg.doc Seite 21 von

22 5.2 Der Vorgang im Arbeitspaket Abb. 8: Beispiel PM-Arbeitspaket Initiation, Planung und IST-Datenerfassung In dieser Form entspricht das Arbeitspaket dem WP Standard, ergänzt um wenige Projektspezifische Vorgänge. Da nicht alle Projektmitarbeiter über einen MSProject Web Zugang verfügen, um die IST-Daten on-line einzugeben, werden die urspünglichen Arbeitspakete um die Tabelle für die monatsweise IST-Datenerfassung ergänzt. Jedes Teammitglied meldet seine IST-Daten an die Projektleitung, immer mit der gleichen Tabelle, so daß alle Beteiligten die identische Information haben. Abb. 9: Beispiel PM-Arbeitspaket Initiation Stichtag-Fertigstellungswerte und -Prognosen _pjmsp_Lecture_PmForum-Nuernberg.doc Seite 22 von