Notleidende by Web Support

Hessisches Ministerium für Wirtschaft, Verkehr und Landesentwicklung www.hessen-it.de

Notleidende Projekte Eine Hilfestellung für IT-Projekte in sieben Akten

Band 64

Hessen

Notleidende Projekte Eine Hilfestellung für IT-Projekte in sieben Akten Hessen-IT Band 64

Peter Steffan Bernd Kloos Sümeyya Can Thomas Hempel Prof. Dr. Achim H. Kaufmann

Hessisches Ministerium für Wirtschaft, Verkehr und Landesentwicklung

HA Hessen Agentur GmbH Hessen-IT Abraham-Lincoln-Straße 38–42 65189 Wiesbaden Telefon Telefax E-Mail Internet

0611 774-8481 0611 774-8620 info@hessen-it.de www.hessen-it.de

Redaktionsteam: Peter Steffan Peter Steffan Project Consulting Group Unternehmergesellschaft (haftungsbeschränkt) Bernd Kloos Managementberatung Bernd Kloos Sümeyya Can Cassini Consulting Frankfurt GmbH Thomas Hempel Fachhochschule Gießen-Friedberg Prof. Dr. Achim H. Kaufmann, Fachhochschule Gießen-Friedberg und Peter Steffan Project Consulting Group Unternehmergesellschaft (haftungsbeschränkt) Eva Frantz redaktionsbüro frantz Gabriele Gottschalk Hessisches Ministerium für Wirtschaft, Verkehr und Landesentwicklung Wolf-Martin Ahrend HA Hessen Agentur GmbH Christian Flory HA Hessen Agentur GmbH

Alle Rechte vorbehalten. Nachdruck, auch auszugsweise, verboten. © Hessisches Ministerium für Wirtschaft, Verkehr und Landesentwicklung Hessen-IT c/o HA Hessen Agentur GmbH Wiesbaden 2010 Layout/Satz: WerbeAtelier Theißen, Lohfelden Druck: Werbedruck Schreckhase, Spangenberg ISBN 978-3-939358-64-0 Bibliografische Informationen der Deutschen Bibliothek: Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.

Liebe Leserinnen und Leser, immer wieder geraten ambitionierte Projekte ins Stocken oder führen nicht zu dem Ergebnis, welches sich die Initiatoren gewünscht haben. Manche Projekte werden deshalb entweder schnell wieder abgebrochen oder führen zu zusätzlichem Ressourcenverbrauch. Die Gründe für das Scheitern werden oftmals gar nicht größer betrachtet oder reflektiert. Fehler pflanzen sich von Projekt zu Projekt fort. Diese Broschüre möchte deshalb Hilfestellung leisten und einen Überblick über ein strukturiertes Projektmanagement geben, damit mit Blick auf die geleistete Arbeit das Projekt zum Erfolg wird. Daher stellt die vorliegende Schrift die wichtigsten Grundregeln des Projektmanagements anwenderorientiert zur Verfügung. Die Autoren sind Mitglieder des Forums Hessen-IT, das sich aus hessischen Anbietern von IT-Dienstleistungen und -Produkten zusammensetzt. Ein Ziel dieses Arbeitskreises ist die Bündelung und Vermittlung von Expertenwissen im Umgang mit Informationstechnologien. Daher beziehen sich die Inhalte der Veröffentlichung auch insbesondere auf das Management von IT-Projekten. Ich freue mich, dass die Arbeit von Hessen-IT und des Arbeitskreises solche Früchte wie die vorliegende Veröffentlichung trägt. Gleichzeitig wünsche ich Ihnen, dass Sie durch die Lektüre ein Werkzeug an die Hand bekommen, welches es Ihnen ermöglicht, Ihre Projekte so zu managen, damit diese den gewünschten Erfolg erzielen.

Dieter Posch, Hessischer Minister für Wirtschaft, Verkehr und Landesentwicklung

Notleidende Projekte

Prolog – Das Elend der notleidenden Projekte ........................... 1

Erster Akt – Ein Projektmeeting ...................................................... 7 Mangelnde Vorbereitung des Meetings ...................................... 10 Ineffiziente Meeting-Durchführung ............................................... 11 Fehlende Aufgaben- und Projekt-Priorisierung ........................... 12 Zusammenfassung .......................................................................... 13 Maßnahmen für eine professionelle Meeting-Vorbereitung ..... 14 Ein Meeting effizient leiten ............................................................. 20 Prioritäten für Aufgaben und Projekte definieren ....................... 26

Zweiter Akt – Überraschende Kundenanforderungen ............. 29 Unklare Anforderungen .................................................................. 32 Ständig wechselnde Anforderungen ............................................ 34 Mangelndes Anforderungsmanagement ..................................... 35 Zusammenfassung .......................................................................... 36 Methodisches Erheben von Anforderungen ............................... 37 Qualitätskriterien für Anforderungen ........................................... 39

Dritter Akt – Termin beim Chef ..................................................... 43 Fehlende Entscheidungen und Maßnahmen zur Entscheidungsunterstützung ......................................................... 46 Fehlende Ressourcenzuordnung ................................................... 47 Ad-hoc-Berichte ............................................................................... 48 Zusammenfassung .......................................................................... 49 Zielgerichtete Entscheidungsvorbereitung ................................. 50 Zielgerichtete Entscheidungsunterstützung ................................ 52 Gesicherte Ressourcenplanung ..................................................... 54 Aufbau eines geregelten Berichtswesens .................................... 58

Vierter Akt – Geheimniskrämerei in der Entwicklung .............. 62 Mangelhafte Projektplanung .......................................................... 64 Unzureichende Projektsteuerung .................................................. 65 Vertuschung, Lügen, Sabotage ...................................................... 66 Zusammenfassung .......................................................................... 67 Maßnahmen für gutes Projektmanagement ................................ 68 Grundlagen für eine praktikable Projektsteuerung .................... 72 Maßnahmen gegen Vertuschung, Lügen, Sabotieren ................ 76

Fünfter Akt – Statusbericht beim Kunden .................................. 80 Mangelhafte Kommunikation mit dem Kunden .......................... 83 Mangelhafte Angebote / Verträge ................................................. 84 Zusammenfassung .......................................................................... 85 Maßnahmen für eine bessere Kommunikation ............................ 86 Maßnahmen für bessere Angebote / Verträge ............................. 88

Sechster Akt – Risiken verdrängen .............................................. 92 Risiken werden nicht identifiziert und analysiert ......................... 94 Zu Risiken werden keine Maßnahmen der Steuerung ergriffen .................................................................. 95 Zusammenfassung .......................................................................... 96 Risikomanagement als Teil des Projektmanagements ................ 97 Maßnahmen des Risikomanagements ....................................... 101

Siebter Akt – Unerwartetes Projektreview ............................... 103 Fehlende Projektreview-Grundlagen .......................................... 106 Mangelhafte Review-Planung ...................................................... 107 Missachtung der Review-Ergebnisse .......................................... 108 Falsches Prüfverfahren .................................................................. 109 Zusammenfassung ........................................................................ 110 Projektreview-Basis schaffen ........................................................ 111 Voraussetzungen für ein Projektreview ...................................... 112 Effiziente Projektreview-Durchführung ....................................... 114 Auswertung und Umsetzung der Maßnahmen ......................... 119 Weitere managementbezogene Projektprüfverfahren ............ 121

Epilog ............................................................................................. 124 Literaturhinweise .......................................................................... 126

Die Aktionslinie Hessen-IT .......................................................... 127 Schriftenreihe Hessen-IT ............................................................. 129

2010

Schriftenreihe Hessen-IT: Neuerscheinungen Notleidende Projekte – Eine Hilfestellung für IT-Projekte in sieben Akten Die Gamesbranche – ein ernstzunehmender Wachstumsmarkt (2. aktualisierte Auflage)

SOA – mehr als nur flexible Softwarearchitekturen

2009

Ambient Mobility – Intelligente Produkte und Umgebungen

2008

Satellitennavigation in Hessen – Ideen über All

Leitfaden zur Patentierung computerimplementierter

Hessen

für mobile Bürger und Unternehmen Rating für IKT-Unternehmen (2. aktualisierte Auflage, Januar 2009)

Erfindungen (2. aktualisierte Auflage) Telekommunikationsanbieter in Hessen 2008

Die komplette Schriftenreihe finden Sie im Anhang oder im Internet unter www.hessen-it.de (Bestellmöglichkeit und Download als PDF-Datei)

www.hessen-it.de

Prolog – Das Elend der notleidenden Projekte Seit der erfolgreichen Mondlandemission von Apollo 11 im Jahr 1969 kennt und nutzt man eine ständig wachsende Sammlung von Methoden und Werkzeugen zur Umsetzung von Projekten – auch bekannt als Projektmanagement. Projekte ohne einen signifikanten Anteil der Informationstechnologie gibt es heute nur noch in wenigen Ausnahmefällen. Deshalb findet man sehr oft die IT als für das Projektmanagement quasi zuständig erklärt. Dies ist zwar methodisch weder begründet noch korrekt, dennoch ist es Fakt, weshalb es höchst erstrebenswert ist, gerade in der IT ein hohes Maß an Projektmanagementverständnis und Know-how zu haben. Trotz des recht langen Erfahrungshorizonts geraten auch vergleichsweise einfache Projekte immer wieder in Not – nicht wenige davon scheitern letztendlich sogar. Warum ist das so? Warum kann man nicht frühzeitig erkennen, ob ein Projekt in Schieflage gerät? Ein wesentlicher Bestandteil des Projektmanagements ist die Projektsteuerung, das Lenken und Beeinflussen des Projektfortganges mit dem Zweck, das Ziel des Projekts im Rahmen der Vorgaben zu erreichen. Und das funktioniert trotz mehr als vierzig Jahren noch nicht reibungslos? Mit der Schifffahrt verglichen wäre das ähnlich einem regelmäßigen Kentern von Frachtern an der Loreley, ein immer wiederkehrendes Zusammenstoßen von Luxuslinern mit Eisbergen. Aber dem ist nicht so. Die Technik wurde permanent verbessert, ausgefeilte Frühwarnsysteme etabliert. Auch der Methoden- und Werkzeugkoffer für das Projektmanagement wird permanent verbessert, was zur Entwicklung von komplexen Planungsund Steuerungsmethoden und Steuerungsinstrumenten führte. Sucht man hier ein Pendant in der Schifffahrt, würde dies vermutlich zu einer Schiffsbrücke mit derart vielen Instrumenten führen, dass der Kapitän vor lauter Apparaturen den Fluss oder das Meer nicht mehr sehen könnte. Aber vielleicht ist genau das unser Problem im Projektmanagement?

Prolog – Das Elend der notleidenden Projekte

Nicht wenige Projektleiter verkaufen ihre Seele an Planungs- und Steuerungssysteme. Doch schnell wird dadurch aus einem Projektleiter ein bürokratischer Projektverwalter. Dieser Typus eines Projekt-Bürokraten vertraut immer eher auf seine Projektverwaltungssysteme als auf offensichtliche Warnsignale aus seinem Projekt-Umfeld, wohl wissend, dass seine Systeme nur von den bereits erfassten Informationen leben und nur aufgrund dieser auch warnen könnten. Doch wenn diese Systeme nicht hinreichend mit Informationen ausgestattet werden, dass zum Beispiel eine Loreley oder ein Eisberg eine Gefahr darstellen könnten, und wenn der Projektverwalter vor lauter Systemeingaben die Warnsignale nicht mehr hören kann, dann haben diese Systeme ihre Wirkung verfehlt. Was nicht an den Systemen selbst liegen muss. Diese können nur das widerspiegeln, was ihnen an Daten zur Verfügung gestellt wurde. Und um zeitnah bei aufkommenden Risiken und Problemen warnen zu können, müssen diese Systeme permanent und sehr umsichtig gepflegt werden. Jetzt könnte für den Leser der Eindruck entstanden sein, man solle keine Projektmanagementsysteme nutzen, aber dem ist nicht so. Der Einsatz dieser Systeme in der täglichen Arbeit des Projektleiters ist wichtig und kann ohne weiteres zum Erfolg eines jeden Projekts beitragen. Mit diesem Handbuch soll eher auf ein altbekanntes „Werkzeug“ hingewiesen werden, dass man weder kaufen noch installieren muss, für das keine Handbücher existieren – und doch ist es ratsam, hin und wieder die „Arbeit“ mit diesem „Werkzeug“ zu trainieren. Dieses „Werkzeug“, das zur Grundausstattung eines jeden Projektleiters gehört, ist nichts anderes als der eigene „gesunde Menschenverstand“, die eigene Fähigkeit zu beobachten und zuzuhören. So kann man mögliche Risiken und Gefahrenpotenziale für das eigene Projekt erkennen – ohne PC und aufwendige Projektmanagementsoftware.

www.hessen-it.de

Zum Erkennen dieser Indikatoren bedarf es gewiss eines kontinuierlichen Trainings, zunächst als „Erfahrung“, später auch als „Seniorität“ bezeichnet. In diesem Ratgeber möchten wir anhand von Dialogen – zusammengefasst nach thematischen Aspekten, niedergeschrieben als sieben Akte eines Bühnenstücks – aufzeigen, wie sich in Projekt-Alltagssituationen Indikatoren bestimmen lassen, die jeden Projektleiter zu einer erhöhten Wachsamkeit auffordern sollten. Zu jeder dieser Situationen haben wir Maßnahmen beschrieben, mit denen gegen diese Geschehnisse zu steuern und das vermeintlich in Not geratene Projekt wieder „in die Mitte des Kanals“ oder „aufs offene, eisfreie Meer“ zu lenken wäre.

Was ist ein Projekt? Nicht jedes Vorhaben in einem Unternehmen ist ein Projekt, sondern vielleicht eine Aufgabe oder eben schlicht Tagesarbeit. Für diesen Ratgeber legen wir folgende Definition zugrunde: Ein Projekt a ist einmalig a betrifft mehrere Unternehmens- oder Organisationsbereiche a hat klare Ziele a hat einen Anfangs- und einen Endtermin a hat klare Abgrenzungen zu anderen Aufgaben und Projekten a ist komplex, aber lösbar a hat einen kostenverantwortlichen Auftraggeber.

Prolog – Das Elend der notleidenden Projekte

Die Protagonisten In den Geschichten treten rein erfundene Akteure auf, die in einem Projekt typischerweise vorkommende Rollen oder Instanzen repräsentieren. In der Summe stellen sie ein Projektensemble dar, wie es ähnlich in vielen realen Projekten vorkommen könnte. Auch wenn es so scheint, als wären unsere Charaktere leicht überzeichnet, so möchten wir vorausschicken, dass in der realen Welt des Projektmanagements durchaus Menschen anzutreffen sind, die diese Fantasiefiguren noch sehr blass und leidenschaftslos erscheinen lassen. Lernen Sie jetzt unsere Akteure und deren Geschichte kennen:

Die Krott Bank ist ein renommiertes Bankhaus mit langer Familientradition. Die Bank unterhält eine IT-Abteilung und ist stets bestrebt, notwendige Soft-

krott bank

ware-Entwicklungen im eigenen Hause durchzuführen. Die wirtschaftliche Situation der Krott Bank war über Jahrzehnte tadellos, jedoch wurden notwendige Anpassungen auf veränderte Marktsituationen nicht rechtzeitig umgesetzt, so dass seit einigen Jahren die wirtschaftliche Entwicklung eher negativ verläuft.

Dr. Tiberius Krott (Chef der Krott Bank) führt die Krott Bank seit über zehn Jahren. Er ist rhetorisch sehr versiert und versteht es, jedem, der mit ungelösten Problemen zu ihm kommt, mit einem anerkennendem Schulterklopfen, zwei zusätzlichen Aufgaben und den immer noch ungelösten Problemen wieder zurück zu schicken. Dr. Krott ließ vor drei Jahren in der bankeigenen IT-Abteilung die Entwicklung einer Software-Plattform für die Verwaltung von Finanzprodukten – Codename „SPÜFI“ – starten. Aufgrund der wirtschaftlichen Entwicklung war Dr. Krott gezwungen, diese Software-Plattform auch Mitbewerbern anzubieten, um so den eigenen Anteil an den Entwicklungskosten zu senken. Erster Kunde ist das Finanzportal Ex & Hopp.

www.hessen-it.de

Hückel Van Hopp (Chef von Ex & Hopp und Kunde der Krott Bank) ist Inhaber des Finanzportals Ex & Hopp. Er lebt nach dem Motto „Selber essen macht fett“ – nur den anderen nichts gönnen. Skrupel kennt und hat er nicht. Verträge sind für ihn das A und O. Van Hopp ist der typische „Über-den-Tisch-Zieher“. Gründe für Probleme interessieren ihn nicht. Vertrag ist Vertrag – basta! Die Krott Bank will er ausnehmen wie eine Weihnachtsgans.

Der Vertrag (zwischen Krott Bank und Ex & Hopp) sieht vor, dass die Krott Bank ihre selbst entwickelte Software-Plattform für die Verwaltung von Finanzprodukten („SPÜFI“) um die zusätzlichen Anforderungen von Ex & Hopp erweitert und für Ex & Hopp den Betrieb der Plattform übernimmt. Zwei wesentliche Teilaufgaben sind die „technische Anbindung“ der Krott Bank an das Finanzportal von Ex & Hopp sowie die Erstellung eines Prototypen. Für den Fall von Zeitüberschreitungen und / oder Funktionsmängeln musste Dr. Krott hohe Konventionalstrafen akzeptieren.

Maximilian Beißer (Abteilungsleiter der Krott Bank) ist seit knapp einem Jahr in der Krott Bank und leitet den Vertrieb. Er will sich im Kreis der Abteilungsleiter profilieren und vor allem schnelle Erfolge, mehr Geld, einen schnelleren Wagen und einen besseren Job. Fachlich ist er durchaus versiert, aber er verkörpert das, was gerne als „linke Bazille“ bezeichnet wird. Er beherrscht die entsprechenden Methoden wie „Herrschaftswissen hüten“, „Glatt-insGesicht-Lügen“ und „Gerüchte streuen“. Auf dieser Klaviatur spielt er perfekt. Zu seinen Aufgaben zählt die Mitgestaltung von „SPÜFI“ unter vertrieblichen Gesichtspunkten.

Prolog – Das Elend der notleidenden Projekte

Torsten Taucher (Software-Entwickler der Krott Bank) ist seit fünf Jahren in der IT tätig. Er ist ein guter Techniker, der sich mangels betrieblicher Weiterbildung sein Wissen autodidaktisch während der Arbeitszeit aneignet. Darauf legt er größten Wert! Er dokumentiert nicht gerne und versucht immer, diesen Schritt zu umgehen. Er ist nicht faul, reißt sich aber auch kein Bein für seine Projekte aus, schließlich hat er seine Hobbys: Tanzen und Tauchen. Spricht man ihn darauf an, ist er glücklich. Er tröstet sich damit, dass ohne ihn sowieso nichts läuft. Früher oder später wird das jeder erkennen und dann wird endlich er Projektleiter, anstelle von Schröder.

Schröder (Projektleiter der Krott Bank) ist seit fünf Jahren in der Krott Bank, kennt sich im Unternehmen gut aus. Er ist ein aufstrebender IT-Gruppenleiter. Im Grunde ein guter Kerl, der es jedem recht machen will. Vielleicht der Grund, warum er „SPÜFI“ übertragen bekam. Das notwendige Handwerkszeug für erfolgreiches Projektmanagement beherrscht er mangels Ausbildung nur dürftig. Nach oben hat er Durchsetzungsprobleme, nach unten ist er oft zu gutmütig. Das rächt sich und er bekommt dafür immer wieder von oben, unten, links und rechts auf die Mütze.

Die Protagonisten werden uns im Rahmen unseres Stückes „Das Elend des notleidenden Projekts in sieben Akten“ begleiten, in denen ganz gewöhnliche Projektsituationen dargestellt und von unseren Protagonisten mit Dialogen zum Leben erweckt werden. Diese sieben Akte sollen dazu dienen, das Auge und das Ohr des geneigten Lesers für mögliche Indikatoren, die auf eine heranziehende Not verweisen könnten, zu schärfen. In den jeweils folgenden Abschnitten analysieren wir diese Indikatoren und stellen abschließend zu jedem Akt ein Paket von „Rettungsankern für den Projektleiter“ vor, um diese Situationen zukünftig professionell meistern zu können. Wir hoffen, Ihnen an der einen oder anderen Stelle Hinweise für Ihre erfolgreiche Projektarbeit vermitteln zu können, auf jeden Fall wünschen wir Ihnen viel Spaß beim Lesen. 6

www.hessen-it.de

Erster Akt Ein Projektmeeting

In jedem Projekt gibt es Besprechungstermine, heute eher als Meetings bezeichnet, leider sehr oft als Plauderstunde oder Kaffeekränzchen missverstanden. Aber lesen Sie selbst:

Schröder sucht gehetzt einige unsortierte Unterlagen zusammen, greift sein Notebook und hastet in den Besprechungsraum. Obwohl bereits zehn Minuten zu spät, ist er – wieder mal – der erste. Nach und nach treffen Taucher und Beißer ein, das Meeting startet mit 20 Minuten Verspätung.

Schröder (starrt auf sein Notebook): „Ja … guten Tag, meine Herren … danke, dass Sie … “

Beißer (unterbricht Schröder): „Ist gut Schröder, kommen Sie mal zu den Fakten. Wir müssen das Anbindungsproblem mit Ex & Hopp sofort lösen und den SPÜFI-Prototypen ganz schnell fertig stellen, sonst kündigt Van Hopp den Vertrag und wir verlieren 250.000 Euro. Sie alle kennen doch die Vorgaben unseres Vorstandes. Um Marktführer zu werden – was erklärtes Ziel ist – müssen wir die individuellen Wünsche eines jeden Kunden schnellstens erfüllen. Bei meiner früheren Firma war dies jedenfalls kein Problem. Da müssen die Herren von der IT endlich aus dem Quark kommen, und damit meine ich Sie, Schröder … “

Schröder (schaut schweigend in die Runde. Er mag diese Situationen nicht, versucht sich um eine Antwort zu drücken und wartet ab, ob Taucher auf Beißers Äußerung reagiert.)

Erster Akt – Ein Projektmeeting

Taucher (denkt sich seinen Teil zu Beißer): „Wir arbeiten parallel an knapp 40 älteren Problemstellungen. Für Ex & Hopp haben wir gerade einmal die erste Version des SPÜFI-Prototypen fertig, der auch bereits beim Kunden zum Test ist. (Taucher blickt zu Schröder und hofft auf dessen Unterstützung, aber ohne Erfolg.) Ohne eine Ausbildung für diese neue Programmiersprache dauert das halt alles seine Zeit. Außerdem, was wollen Sie denn eigentlich fertig haben? Heute dies und morgen das? Jeden Tag was anderes! So kann man nicht arbeiten … “

Beißer (seine Stimme überschlägt sich. Er ist kurz davor, die Fassung zu verlieren): „Das ist es ja eben. Nichts wird fertig. Wie will man da erfolgreich Vertrieb machen? Tun Sie doch mal was!! Schaffen, Taucher, schaffen!! Selbst für den Auftrag für die Firma ‚0815‘ ist noch nichts getan, und das wurde schon vor sechs Monaten bei Ihnen beauftragt.“

Taucher (regt sich auf, nimmt sich aber zusammen): „Das stimmt nicht, die schriftliche ‚0815‘-Anforderung ist höchstens zwei Monate alt, dann kam Ex & Hopp dazwischen.“

Schröder (tippt auf der Tastatur seines Notebooks herum und starrt auf den Bildschirm): „Meine Herren. Wir sollten uns doch auf die Probleme konzentrieren. Außerdem hatten wir, glaube ich, schon beim letzten Meeting über ‚0815‘ gesprochen.“ (Er sucht weiter verzweifelt in seinem Notebook nach einer E-Mail an Beißer, in der die Situation zu ‚0815‘ bereits behandelt wurde. Dann verfällt er ins Grübeln, dass man eigentlich wieder nicht weitergekommen ist und er noch zum Chef muss.)

www.hessen-it.de

Taucher (schüttelt wortlos den Kopf und denkt, dass dies ein richtiger Saftladen ist. Schröder jedenfalls würde sich nicht mehr lange halten. So gesehen hätte das ja auch was Gutes für ihn selbst.)

Beißer (steht auf, deutet mit dem Kugelschreiber auf Schröder und redet beim Verlassen des Raumes): „So wird das nichts, Schröder, so nicht. Wir sehen uns später wegen ihrer komischen Anforderungsliste.“

So oder so ähnlich spielen sich leider sehr viele Projekt-Meetings ab. Vielleicht durften auch Sie schon an solchen doch recht amüsanten Veranstaltungen teilnehmen? Auf den ersten Blick bekommt man zwar keinen panischen Gesichtsausdruck, wenn man sich vorstellt, ein Beteiligter in dieser Runde gewesen zu sein, aber wer schon viele Jahre Projekterfahrung hat, ahnt die verborgenen Potenziale für eine Schieflage dieses Projekts. Nun könnte man sich selbst beruhigen und sagen, dass die Einzelinteressen und Befindlichkeiten der Protagonisten nicht von wirklicher Bedeutung sind, sondern einzig und allein das Erreichen der Ziele. Vordergründig gesehen wird von Beißer genau dieser Versuch unternommen. Doch eher möchten wir die Behauptung aufstellen, dass Projekte, in denen Meetings dieser Art nicht die Ausnahme, sondern die Regel darstellen, Probleme bekommen werden, Probleme bereits haben, oder gar schon in Not sind. Es ist wirklich erstaunlich, wie vergleichsweise einfach sich in diesem ersten Akt die Indikatoren für eine heranziehende Not im Projekt erkennen lassen. Analysieren wir jeweils einige Aspekte der Dialoge und zeigen auf, wie und woran sich sehr einfach erkennen lässt, welche Elemente hier zur möglichen Schieflage des Projekts beitragen:

Erster Akt – Ein Projektmeeting

Mangelnde Vorbereitung des Meetings Was geschah? Analyse der Ereignisse – Indikatoren für die heraufziehende Not Schröder sucht gehetzt einige unsortierte Unterlagen Schröder … (Er sucht weiter verzweifelt in seinem Notebook nach einer E-Mail an Beißer …) Ohne hier tiefer einsteigen zu müssen, sind dies eindeutige Indikatoren für eine mangelnde Meeting-Vorbereitung. Wie lassen sich diese Indikatoren erkennen? Es ist vielleicht erstaunlich, aber zum Erkennen dieser Indikatoren muss man lediglich

beobachten und zuhören.

Einerseits wird in Projekten versucht, hochkomplexe Problemstellungen zu lösen, heterogene Teams zu führen, große Budgets zu verwalten und ggf. Entscheidungen mit erheblichen Auswirkungen auf den Erfolg des Unternehmen zu treffen – doch die einfachsten organisatorischen Grundlagen zur Vorbereitung eines Meetings werden missachtet? Ein Meeting ist eine sehr teure Veranstaltung. Jede Minute kostet Geld. Die Formel ist ganz einfach: Zeit multipliziert mit der Anzahl der Teilnehmer, multipliziert mit dem Stundensatz. Wird diese Zeit vertan, darf man von „Geld aus dem Fenster werfen“ sprechen. Schröder, unser Projektleiter und tragischer Held in einer Person, handelt hier nicht einem professionellen Projektleiter angemessen. Dabei braucht es nicht viel, ein Meeting professionell vorzubereiten, wie wir im Abschnitt „Maßnahmen

für eine professionelle Meeting-Vorbereitung“ aufzeigen werden.

www.hessen-it.de

Ineffiziente Meeting-Durchführung Was geschah? Analyse der Ereignisse – Indikatoren für die heraufziehende Not Beißer (unterbricht Schröder) … Schröder (schaut schweigend in die Runde) … Taucher blickt zu Schröder und hofft auf dessen Unterstützung, aber ohne Erfolg. Diese Geschehnisse in einem Meeting sind eindeutige Indikatoren für eine ineffiziente Meeting-Durchführung. Wie lassen sich diese Indikatoren erkennen? Es ist vielleicht schon wieder erstaunlich aber zum Erkennen dieser Indikatoren muss man lediglich beobachten und zuhören.

Niemand wird in Zweifel ziehen, dass das Führen eines PKW nur mit einer hinreichenden Ausbildung sinnvoll ist, um die Gefahr von Unfällen zu minimieren. In Projekt-Meetings aber, deren Teilnehmer sich auf Grund ihrer einmaligen Aufgabe ständig mit neuen Themen und Problemen zu befassen haben, scheint keine spezielle Ausbildung für einen „MeetingFührerschein“ notwendig zu sein. Auch in der Rolle des Projekt- bzw. Meeting-Leiters muss man gerüstet sein, um mögliche Meeting-Unfälle zu vermeiden. Sowohl für Konfliktsituationen als auch für das unpassende Verhalten von Kollegen muss man als Meeting-Leiter vorbereitet und bestenfalls ausgebildet sein. Ist dies nicht der Fall, geraten Meetings leicht außer Kontrolle, geplante Ergebnisse werden nicht erzielt, das Meeting degeneriert zur Farce. Eine erste Hilfestellung dazu findet sich im Abschnitt „Ein Meeting effizient leiten“.

Erster Akt – Ein Projektmeeting

Fehlende Aufgaben- und Projekt-Priorisierung Was geschah? Analyse der Ereignisse – Indikatoren für die heraufziehende Not Taucher: „Wir arbeiten parallel an knapp 40 älteren Problemstellungen …“ Beißer: „ … Selbst für den Auftrag für die Firma ‚0815‘ ist noch nichts getan und das wurde schon vor sechs Monaten bei Ihnen beauftragt … “ Taucher: „Das stimmt nicht, die schriftliche ‚0815‘-Anforderung ist höchstens zwei Monate alt, dann kam Ex & Hopp dazwischen.“ Niemand kann alles auf einmal erfüllen. Wenn eine Vielzahl von Aufgaben, wie hier knapp 40 „ältere Problemstellungen“, ansteht, ist es notwendig, eine Reihenfolge festzulegen. Ist dies nicht der Fall, sind dies eindeutige Indikatoren für eine fehlende Aufgaben- und

Projekt-Priorisierung. Wie lassen sich diese Indikatoren erkennen? Es ist schon wieder aufs äußerste erstaunlich, aber zum Erkennen dieser Indikatoren muss man lediglich beobachten und zuhören.

Ein beliebtes Projektspiel: Jeder argumentiert nach seinem Gusto, denn niemand kann die Argumente nachprüfen. Es steht jeweils Aussage gegen Aussage, ohne die leiseste Chance zu einer objektiven Betrachtung. Hinter solchen Dialogen verbergen sich meist fundamentale Projektprobleme. Einem erfahrenen Projektleiter würden sich hier die Nackenhaare sträuben, nicht jedoch unserem lieben Schröder. Eine allgemein gültige und akzeptierte Grundlage zur Vermeidung dieser Situation – technisch ausgedrückt eine „Datenbasis“ – wäre eine Verwaltungssystematik für Aufgaben und Projekte in Verbindung mit der Festlegung von Dringlichkeiten (Prioritäten), die allen bekannt sind und von den Entscheidern getragen werden. Liegt dies als „Nachschlagewerk“ vor, sind solche Diskussionen obsolet. Mit welchen einfachen Schritten diese „Datenbasis“ erstellt werden könnte, findet sich im Abschnitt „Prioritäten für Aufgaben

und Projekte definieren“.

www.hessen-it.de

Zusammenfassung des Notfalls „Ein Projektmeeting“ Fassen wir zusammen: Anhand des ersten Aktes unseres Stückes aus dem realen Projektleben lassen sich die ersten Indikatoren für eine heraufziehende Not identifizieren. Schröder ist nicht nur im Theaterstück ein geprügelter Hund, auch wir müssen streng mit ihm sein, damit Sie als Leser Ihre Sinne schärfen können und fortan über Situationen wie diese nur noch lächeln und sie gekonnt meistern werden. a Schröder war, aus welchen Gründen auch immer, auf das Meeting nicht vorbereitet. Was hier hilft, sind Maßnahmen für

eine professionelle Meeting-Vorbereitung. a In einem der „Beißer“ dieser Welt hat Schröder seinen Meister gefunden. Er wird von ihm überrannt, mit unbewiesenen Behauptungen in die Enge gedrängt und kann sich aufgrund fehlender Informationen nicht wehren. Was hier hilft, sind Spielregeln, ein Meeting effizient zu leiten. a Sobald mehr Aufgaben zu erfüllen sind als Ressourcen zur Verfügung stehen, um diese Aufgaben sofort umsetzen können, wird aus einem subjektiven Verständnis für eine subjektive Dringlichkeit sehr schnell eine endlose Diskussion, das Ad-hoc-Verändern von fiktiven Abarbeitungsfolgen durch ein lapidares „Das ist jetzt am Wichtigsten“. Um dem zu entgehen hilft nur, Prioritäten für Aufgaben und Projekte zu

definieren.

NOT a Mangelnde Vorbereitung des Meetings a Ineffiziente Meeting-Durchführung a Fehlende Aufgaben- und Projekt-Priorisierung

HILFE a Maßnahmen für eine professionelle Meeting-Vorbereitung a Ein Meeting effizient leiten a Prioritäten für Aufgaben und Projekte definieren

Erster Akt – Ein Projektmeeting

Maßnahmen für eine professionelle Meeting-Vorbereitung Das Thema „Meeting-Vorbereitung“ betrifft nicht nur den Leiter des Meetings, auch die Teilnehmer sollten sich entsprechend vorbereiten und dadurch den Meeting-Leiter unterstützen. Aber betrachten wir zunächst die Punkte für eine professionelle Vorbereitung des Meeting-Leiters und die organisatorische Vorbereitung für das Meeting selbst.

Vorbereitung des Meeting-Leiters Einladung Die Teilnehmer sind rechtzeitig und „ordentlich“ einzuladen. Dazu gehört die Angabe der wichtigsten Informationen über den Grund des Meetings, damit jeder Eingeladene sich seinerseits vorbereiten kann. Das sind ein aussagekräftiger Meeting-Titel, die zu behandelnden Besprechungspunkte (Agenda) bzw. das Ziel des Meetings, die Ortsangabe, das Datum, Beginn und Dauer des Meetings sowie die Teilnehmerliste. Für jeden Teilnehmer sollte aufgeführt sein, in welcher Rolle (Projektleiter, Protokollant, Vertriebsleiter, Spezialist, etc.) er an dem Meeting teilnimmt. Mit E-Mail und „elektronischem Termin“ mit Sicherheit kein Problem.

Raum buchen „Äh, wo gehen wir denn mal schnell hin, unser Raum ist heute leider belegt“ ist in der Tat nicht professionell. Daher im Vorfeld den Raum buchen und je nach Dauer und Teilnehmer ggf. eine adäquate Bewirtung bestellen.

Standard-Raumausstattung Dazu zählen ein Flip-Chart mit ausreichendem unbeschriebenem (!) Papier, eine genügende Anzahl schreibender (!) Stifte, ein funktionsfähiger Beamer sowie ein Netzwerk- oder Internetanschluss. Je nach Inhalt des Meetings kann auch eine Metaplanwand mit gut gefülltem Moderationskoffer sehr nützlich sein.

www.hessen-it.de

Relevante größere Dokumente kann man nicht während des Meetings einfach auf den Tisch legen oder mit dem Beamer „an die Wand werfen“ und hoffen, dass darüber befunden und entschieden wird. Größere Dokumente sind daher mindestens zwei bis drei Werktage vor dem Termin an die Teilnehmer zur Durchsicht zu senden. Dann hat jeder die Chance, sich vorzubereiten.

Relevante kleinere Dokumente kann man vor dem Meeting in der Anzahl der Teilnehmer (plus Reserve) ausdrucken und / oder via Notebook und Beamer im Meeting präsentieren. Beamer-Präsentationen sollten schon vor Beginn der Veranstaltung am Notebook geladen und getestet werden, denn jeder kennt vermutlich das folgende Spiel: Alle starren auf den Referenten, mühsam startet das Notebook, die ersten Witze werden gemacht, langsam öffnet sich die Präsentation, der Beamer wird angeschlossen und verstellt die Auflösung des Notebooks, die Grafiken auf der Präsentation sind nicht mehr zu erkennen, die (An-)Spannung des Referenten steigt ins Unermessliche, Versuche einer Anpassung der Auflösung führen zu einem schwarzen Bild, die Bemerkungen werden zynischer und das Gelächter lauter …

Nils, photocase.com

Wollen Sie das wirklich live erleben?

Erster Akt – Ein Projektmeeting

Rettungsanker Einladung zum Meeting Die Teilnehmer sind rechtzeitig und professionell einzuladen. Dazu zählt die Angabe der wichtigsten Informationen, damit der Eingeladene sich seinerseits gezielt auf das Meeting vorbereiten kann: a Aussagekräftiger Titel für das Meeting im Betreff der Einladung a Datum, Beginn, Dauer und Ort des Meetings a Teilnehmerkreis und Rolle der Teilnehmer im Meeting (Warum ist Wer eingeladen) a Art des Meetings (z. B. Abstimmung, Status, Workshop – Ad-hoc-Meeting oder regelmäßiges Meeting) a Leiter des Meetings und – soweit bekannt – Protokollant a Ziel und Agenda

Rettungsanker Organisation von Raum, Ausstattung und Bewirtung Rechtzeitig vor der geplanten Veranstaltung einen Besprechungsraum buchen (oder reservieren) und entsprechend der Art des Meetings ausstatten lassen: a Strom und Netzwerkanschluss für das Notebook a Beamer oder Monitore für Präsentationen über das Notebook a Flip-Chart oder Whiteboard mit ausreichend (unbeschriebenem!) Papier sowie (schreibenden!) Stiften a Für Workshops eventuell Metaplanwände und ein (gut gefüllter!) Moderatoren-Koffer Bei Meetings ab 30 Minuten Dauer kann es hilfreich für die Konzentrationsfähigkeit der Teilnehmer sein, Getränke (Mineralwasser und ggf. Kaffee) anzubieten.

www.hessen-it.de

Rettungsanker Präsentation und Dokumente Ein Meeting kann umso zielgerichteter gestaltet werden, je besser die Teilnehmer die Möglichkeit haben, sich auf das Meeting vorzubereiten. a Bereitzustellende Dokumente der Teilnehmer drei Tage vor dem Meeting bei den Teilnehmern einfordern. a Präsentationsunterlagen und umfangreiche Dokumente (mehr als drei Seiten) dem Teilnehmerkreis spätestens zwei Tage vor dem Meeting zur Verfügung stellen. a Für das Meeting Ausdrucke entsprechend der Teilnehmerzahl erstellen und vor dem Meeting als Tischvorlagen verteilen. Präsentationen über Notebook / Beamer vor dem Beginn des Meetings am Notebook laden bzw. öffnen und Beamer-Einstellungen testen.

Vorbereitung der Meeting-Teilnehmer Aber nicht nur der Meeting-Leiter sollte gut vorbereitet sein, gleiches gilt auch für die Teilnehmer des Meetings, die zum Erfolg der Veranstaltung beitragen wollen.

Aufgabenliste prüfen Nehmen wir an, in jedem vorangegangenen Meeting ist eine Aufgabenliste geführt worden, so sollte jeder Teilnehmer rechtzeitig (am besten direkt nach dem letzten Meeting, jedoch rechtzeitig vor dem kommenden) die Aufgabenliste auf eigene Aufgaben und deren termingerechte Bearbeitung prüfen und die für das anstehende Meeting relevanten Ergebnisse zusammenstellen.

Erster Akt – Ein Projektmeeting

Relevante größere Dokumente Möchte man als Teilnehmer umfangreiche Dokumente (ab drei Seiten) einbringen, so sollten diese knapp fünf Werktage vor dem Meeting über den Meeting-Leiter oder in Absprache mit ihm direkt an die anderen Teilnehmer zur Durchsicht verteilt werden.

Relevante kleinere Dokumente sind für eine Präsentation im Meeting im Vorfeld in elektronischer Form an den Meeting-Leiter zu übermitteln und als Tischvorlage in entsprechender Anzahl zu kopieren.

Zusammenstellen der Basisunterlagen ist auch eine Aufgabe für jeden Teilnehmer an einem Meeting: a Papier und Stift für Notizen. Funktioniert immer, auch ohne Strom. a Ausdruck der Einladung. Sie enthält – vorausgesetzt, der MeetingLeiter hat den obigen Abschnitt befolgt – interessante Informationen über die zu behandelnden Themen, Namen der anderen Teilnehmer, vielleicht sogar deren Rolle im Meeting. a Protokoll des letzten Meetings, schon mit eigenen Anmerkungen versehen. a Tischvorlagen in der Anzahl der Teilnehmer (plus eine Reserve) – abgestimmt mit dem Meeting-Leiter, damit aus der möglichen Vielzahl von Tischvorlagen das Meeting nicht zum Lesekreis verkommt. a Eine priorisierte Liste der eigenen Themen. Für den Fall, dass die Zeit knapp wird, bringt man so die eigenen Themen in der richtigen Reihenfolge vor und kann sich sicher sein, dass die wesentlichen Punkte besprochen werden. a Terminkalender oder PDA für die Vereinbarung von Folgeterminen. So ausgestattet kann man in jedem Meeting als Teilnehmer überzeugen und zur erfolgreichen Gestaltung beitragen.

www.hessen-it.de

Rettungsanker Abstimmung der Meeting-Teilnehmer mit dem Meeting-Leiter Im Vorfeld des Meetings sind bei Bedarf einige Punkte mit dem Meeting-Leiter abzustimmen: a Unterlagen zu erfüllten Aufgaben an den Meeting-Leiter weiterleiten. a Größere Dokumente ca. fünf Arbeitstage vor dem Meeting beim Meeting-Leiter einreichen. a Verteilung von kleineren Dokumenten in Papierform oder als Präsentation mit dem Meeting-Leiter abstimmen. Durch Beachtung dieser wenigen Punkte liefert jeder Meeting-Teilnehmer einen wesentlichen Beitrag zur Unterstützung des MeetingLeiters und somit für die erfolgreiche Vorbereitung des Meetings.

Rettungsanker Basisunterlagen für Meeting-Teilnehmer Ein Meeting kann umso zielgerichteter gestaltet werden, je besser jeder Teilnehmer auf das Meeting vorbereitet ist. a Papier und Stift für Notizen a Ausdruck der Einladung a Protokoll des letzten Meetings a Tischvorlagen in der Anzahl der Teilnehmer (plus eine Reserve) a Priorisierte Liste der eigenen Themen a Terminkalender oder PDA für die Vereinbarung von Folgeterminen.

Erster Akt – Ein Projektmeeting

Ein Meeting effizient leiten Meetings brauchen einen geregelten Ablauf, sonst werden die „richtigen“ und „wichtigen“ Themen nicht in einem vertretbaren Verhältnis behandelt, sondern das Meeting zerläuft zu einem Kaffeeklatsch. Dabei ist es nicht schwer, ein Meeting professionell zu führen, wenn man sich an ein paar Formalismen hält:

Geregelter Meeting-Ablauf Nicht nur inhaltlich, auch organisatorisch trägt der Meeting-Leiter die Verantwortung für den erfolgreichen Ablauf der Veranstaltung. Je regelmäßiger diese organisatorischen Rituale vollzogen werden, desto einfacher akzeptieren die Teilnehmer die damit verbundenen Spielregeln für Meetings:

Die Begrüßung durch den Meeting-Leiter ist das Eröffnungszeremoniell eines Meetings. Dadurch wird klargestellt, dass ab diesem Zeitpunkt bilaterale Gespräche unterbleiben. Wem das nicht klar ist, dem muss man das erklären – und zwar sofort. Weiter ist die Begrüßung wichtig für neue Teilnehmer dieses Kreises. Der Meeting-Leiter kann je nach Situation entscheiden, ob sich nur neu hinzugekommene Teilnehmer oder der gesamte Teilnehmerkreis vorstellen – allerdings kurz und auf das Wesentliche beschränkt. Denn schon hier lauert die Gefahr, dass Teilnehmer, die bei anderer Gelegenheit unscheinbar wirken, diese Gelegenheit zur umfassenden Darstellung des eigenen Lebenslaufs nutzen.

Protokollant festlegen Es soll schon Meetings gegeben haben, in denen ein aufmerksamer Teilnehmer nach einer Stunde die Frage stellte, ob denn schon ein Protokollant bestimmt wurde. Zu so fortgeschrittener Zeit wird es sehr schwer, das Geschehene zu rekonstruieren. Bei wiederkehrenden Meetings wird entweder ein Teilnehmer zum Protokollanten auf Dauer benannt, oder es wird zu Beginn eines jeden Meetings ein Teilnehmer als Protokollant bestimmt.

www.hessen-it.de

Zusammenfassung der Ergebnisse Nach der Abarbeitung der zu behandelten Themen fasst der Meeting-Leiter die Ergebnisse kurz zusammen und sichert sich so die Zustimmung der Teilnehmer zu den Ergebnissen. Spätestens im Verlauf dieser Zusammenfassung werden vermeintliche Missverständnisse aufgeklärt. Soweit nicht im Vorfeld geschehen, werden die nächsten Termine und der jeweilige Teilnehmerkreis vereinbart.

Die Verabschiedung ist wie die Begrüßung ein Zeremoniell. Dazu gehört der Dank an die Teilnehmer. Ab sofort sind bilaterale Gespräche wieder erlaubt und sogar erwünscht. Schließlich haben sich alle für die Dauer des Meetings stark diszipliniert – hoffentlich.

Rettungsanker Maßnahmen für eine effiziente Meeting-Leitung Meetings brauchen einen geregelten Ablauf, sonst werden die richtigen und wichtigen Themen nicht in einem guten Verhältnis behandelt: a Begrüßung der Teilnehmer durch den Meeting-Leiter a Vorstellung der (neuen) Teilnehmer a Protokollant festlegen a Bearbeitung der Punkte auf der Agenda a Zusammenfassung der Ergebnisse a Nächsten Termin fixieren a Verabschiedung der Teilnehmer

Erster Akt – Ein Projektmeeting

Mit Moderations-Know-how zur professionellen Meeting-Moderation Projektleiter zu sein heißt nicht automatisch, alle Techniken für diese Aufgabe sofort und ohne Ausbildung nutzen zu können. Eine rein fachliche Qualifikation, z.B. „Wie programmiere ich ein paar knackige „stored procedures“ auf einem Datenbankserver?“, hat nichts mit dem Beherrschen von kritischen Meeting-Situationen, z. B. „Wie führe ich zwei Streithähne zu einem konstruktiven Ergebnis?“, zu tun. Unser lieber Schröder hat offensichtlich keine Chance erhalten, eine Moderationsausbildung zu besuchen, und dementsprechend entgleitet ihm auch sein Projektmeeting. Das ist ähnlich einem Autofahren ohne Führerschein – auch das führt unweigerlich zu verhängnisvollen Situationen. Nun können wir mit dieser Broschüre keine Moderationsausbildung ersetzen und schon gar nicht die nötige Praxis vermitteln, denn hier sind Übung und Zeit notwendig. Wir geben hier einige nützliche Hinweise, die zu einer erfolgreichen Meeting-Moderation beitragen:

Agenda anpassen Wer mit starker Autorität seine Meetings führt, vergibt schnell die Chance, aktuelle Probleme zu erkennen. Klug ist es, vor der standardisierten Abarbeitung der Agenda-Punkte die Teilnehmer zu fragen, ob es Änderungswünsche gibt. Und tatsächlich kommt es manchmal vor, dass sich ein sonst sehr ruhiger und zurückhaltender Teilnehmer mit einem wichtigen Thema meldet, das fachlich energisch diskutiert, zu dem mit stichhaltigen Argumenten ein Ergebnis gefunden und letztendlich eine bahnbrechende Entscheidung getroffen wird. Das sind Sternstunden der Moderation, die jedem Meeting-Leiter die Tränen der Begeisterung in die Augen treiben können.

www.hessen-it.de

Zeit zuweisen Liegen Themen zur Diskussion vor, die vermeintlich einen größeren Zeitrahmen in Anspruch nehmen könnten, so ist es gut, die Teilnehmer vorher nach einer Zeiteinteilung für die betroffenen Themen zu fragen. Das kann sowohl zu einer zeitlichen Begrenzung als auch zu einer Themenverschiebung führen. Wie auch immer das Ergebnis aussehen wird, es spiegelt die Relevanz der Themen besser wider und führt so zu zeitlich begrenzten Meetings, die enden, bevor die Teilnehmer das Interesse oder gar die Kraft für eine Teilnahme verlieren.

Widerstände und Konfliktsituationen aktiv moderieren Mit Sicherheit so etwas wie die Kür der Meeting-Moderation: Man stelle sich vor, zwei Teilnehmer streiten sich um „des Kaisers Bart“. Und das mit einer Vehemenz, die jeglichen Schlichtungsversuch im Ansatz erstickt. Die geplante Agenda wird aus den Angeln gehoben, Entscheidungen verweigert. Hier zeigt sich, wer die Moderation beherrscht. Aber seien Sie getrost, selbst Profis beim Fernsehen haben manchmal keine Chance, wenn zwei Streithähne aneinander geraten sind. Diese Herausforderung zu meistern erfordert Erfahrung, vielleicht auch Gelassenheit und Seniori-

photocase.com

tät, um die Leitung der Veranstaltung zurück zu erobern.

Erster Akt – Ein Projektmeeting

Status der offenen Punkte und Aufgaben aktualisieren Eine Aufgaben- oder Offene-Punkte-Liste aus dem letzten Protokoll wirkt nur dann, wenn der Status zu diesen Punkten auch neu festgestellt wird. Resultieren daraus z. B. Terminänderungen, andere Verantwortlichkeiten, mehr Ressourcen, andere Prioritäten oder veränderte Inhalte, so sind diese im Verlauf des Meetings in der Aufgabenliste zu aktualisieren, damit sie im nächsten Meeting kontrolliert werden können. Und sollte sich irgendwann ein Teilnehmer über die vielen offenen Punkte beschweren, so sei ihm gesagt, dass die Liste sich automatisch verkürzt, sobald die Aufgaben abgearbeitet und erledigt sind.

Entscheidungen herbeiführen Eine sehr wichtige Aufgabe des Meeting-Leiters ist es, Beschlüsse aus den Aussagen der Teilnehmer zur gegebenen Zeit zu moderieren. Oft ist den Beteiligten gar nicht klar, dass sie einen Beschluss gefasst haben. Der Moderator hat deshalb die Pflicht, das Gesagte in Sätzen wie „Wollen wir jetzt das Gesagte als Beschluss zusammenfassen?“ den Teilnehmern widerzuspiegeln und einer Entscheidung zuzuführen. Macht er das nicht, kann später jeder seine Sicht der Dinge als Beschluss auffassen oder der Meinung sein, es gäbe noch keinen Beschluss dazu. Ein häufiger Grund für sehr stark differierende Aussagen zu den Ergebnissen eines Meetings.

Aufgaben vereinbaren und zuweisen Resultieren aus dem Verlauf des Meetings Aufgaben, so müssen diese mit dem Meeting-Leiter vereinbart werden. Es macht keinen Sinn, jemandem eine Aufgabe aufs Auge zu drücken oder – noch besser – eine Aufgabe einem Abwesenden zu übertragen. Man vergibt sich dadurch die Chance, dass ein Teilnehmer die betreffende Aufgabe vielleicht sogar gerne übernehmen würde und die Verantwortung dafür sogar in seinem eigenen Bereich sieht. Deshalb gilt, Aufgaben wenn möglich anbieten und anschließend einen Termin für die Erfüllung der Aufgabe mit dem Verantwortlichen vereinbaren.

www.hessen-it.de

Rettungsanker Wesentliche Aspekte einer Meeting-Moderation Ein Moderator muss steuernd in den Verlauf eines Meetings eingreifen, wenn das Ziel der Veranstaltung im Rahmen der gegebenen Zeit erreicht werden soll. Wesentliche Punkte einer professionellen MeetingModeration sind: a Agenda-Punkte oder Besprechungsabfolge aufgrund aktueller Gegebenheiten und Prioritäten am Beginn des Meetings anpassen. a Einzelnen Themen ein Zeitfenster zuweisen. a Auftretende Widerstände konstruktiv angehen. a Status zu offenen Punkten aus dem letzten Protokoll erfragen und neu festhalten. a Beschlüsse moderieren und dokumentieren. a Aufgaben vereinbaren und Verantwortlichen zuweisen, Erfüllungstermine festhalten.

Erster Akt – Ein Projektmeeting

Prioritäten für Aufgaben und Projekte definieren Um eine ordentliche Aufgaben-Priorisierung durchführen zu können, bedarf es einer Datenbasis, die aus den Bereichen Stundenschreibung, Kapazitätsplanung, Aufwandschätzungen und Skillprofile (Fachkenntnisse) besteht. Aus der Stundenplanung ergeben sich die bereits erbrachten Leistungen für eine Aufgabe. Die Kapazitätsplanung ermittelt die tatsächlich verfügbaren Tage pro Ressource. Die Aufwandschätzung ermittelt den wahrscheinlichen zeitlichen Aufwand zur Erledigung einer Aufgabe sowie das dazu benötigte Fachwissen. Die Skillprofile geben Auskunft über verfügbares Wissen im Projekt. Auf Grund dieser Informationsbasis kann nun eine Aufgaben- und Projekt-Priorisierung vorgenommen werden. Dabei ist es von nebensächlicher Bedeutung, mit welchem System diese Daten verwaltet werden. Oft ist eine Tabellenkalkulation eine praktikable Lösung. Wichtiger dagegen ist die Frage, ob die Daten überhaupt erhoben und verwaltet werden. Im Folgenden sind die wichtigsten Stichpunkte zu den jeweiligen Werkzeugen für eine erfolgreiche Priorisierung von Aufgaben und Projekten dargestellt:

Rettungsanker Stundenschreibung Eine Stundenschreibung ist die Grundlage für die Erfassung der geleisteten Arbeit und deren Zuordnung zu erfüllten Aufgaben: a Name und Organisationseinheit des Leistungserbringers a Datum der erbrachten Leistung a Dauer der erbrachten Leistung a Beschreibung der erbrachten Leistung a Zuordnung der erbrachten Leistung zu Kategorien wie Tagesarbeit, Aufgaben- und Projektnummer a Zuordnung der erbrachten Leistung zum Auftrag / Kostenstelle etc.

www.hessen-it.de

Rettungsanker Kapazitätsplanung Die folgende Summe zeigt die wesentlichen zu berücksichtigenden Aspekte, um eine bessere Kapazitätsgrundlage zu erhalten. Anzahl der Arbeitstage im jeweiligen Monat — Urlaubstage im jeweiligen Monat — Ø Anteil Krankheitstage im jeweiligen Monat — Anteil Ausbildungstage, Marktanalysen etc. im jeweiligen Monat — Ø Anteil Tagesarbeit pro Monat — Ø Anteil Eigenorganisation im jeweiligen Monat

= freie Kapazität pro Monat

Rettungsanker Aufwandschätzung Sehr oft werden Aspekte einer Aufwandschätzung nicht berücksichtigt, was typischerweise zu einer (zu) niedrigen Aufwandschätzungen führt: Analyseaufwand + Entwicklungsaufwand (multipliziert mit persönlichem Kenntnis-Faktor) + Ausbildungsaufwand + Kommunikationsaufwand (40– 80 % des Entwicklungsaufwands) + Dokumentationsaufwand (15– 30 % des Entwicklungsaufwands) + Qualitätssicherung (20– 40 % des Entwicklungsaufwands) + Produktionseinführung (5–10 % des Entwicklungsaufwands)

= Summe des geschätzten Aufwands

Erster Akt – Ein Projektmeeting

Rettungsanker Skillprofile (Fachkenntnisse) Nicht jede Ressource kann jede anfallende Aufgabe auf Grund von unterschiedlicher Ausbildung und Know-how erledigen, gleich gut erledigen oder gleich schnell erledigen. Deshalb ist es gut, sich einen Überblick über das verfügbare Wissen im Unternehmen zu verschaffen. a Erworbene Ausbildungsgrade und Titel mit Datum a Erworbene Zertifikate mit Datum a Unternehmenslaufbahn a Eintrittsdatum a Pro Aufgabengebiet / Abteilung die Dauer und Schwerpunkte a Persönliche Fähigkeiten / Hobbys (falls vom Mitarbeiter genehmigt)

Mit Hilfe dieser Informationen kann ein Priorisierungsgremium – und sei es nur der Projektleiter mit dem Chef, besser ein IT-Ausschuss des Unternehmens – anhand der folgenden Punkte eine eindeutige Priorisierung der anstehenden Aufgaben und Projekte vornehmen: a Strategische Bedeutung für das Unternehmen a Umsetzung aufgrund von Gesetzesvorgaben a Verfügbarkeit der notwendigen Fachkenntnisse a Laufzeit sowie Start, Ziel und Enddatum Eine gute Priorisierung darf in keinem Fall nur in „A“, „B“ oder „C“ unterscheiden. Gilt die Regel, dass „A“ das Zeichen für „sehr wichtig“ oder „sehr hoch“ bedeutet, so muss in jedem Fall, sobald mehr als eine Aufgabe der Klasse „A“ existiert, auf die einfache Vergabe von Prioritäten nach Nummern von 1 bis n gewechselt werden. All diese Instrumente vorausgesetzt, hätte Schröder sofort und erfolgreich in das Geschehen und den Verlauf des Meetings eingreifen können, um für alle Teilnehmer transparent und nachvollziehbar Klarheit zu schaffen und bis zum Ende der Veranstaltung als der wirkliche Meeting-Leiter zu fungieren. Aber der Umfang dieser Broschüre lässt vermuten, dass es noch weitere Verbesserungspotentiale für Schröder zu entdecken gibt. 28

www.hessen-it.de

Zweiter Akt Überraschende Kundenanforderungen

Selten – eigentlich nie – ergibt sich in Projekten die Möglichkeit, zu Beginn die Kundenanforderungen vollständig aufzunehmen und danach die Umsetzung mit der Gewissheit zu beginnen, dass sich im Laufe des Projekts keine „Anforderungsmutationen“ ergeben werden. Da diese Situation mit einer an 99,9 Prozent grenzenden Wahrscheinlichkeit nicht eintreffen wird, ist es umso wichtiger, der Anforderungserhebung die entsprechende Aufmerksamkeit zu widmen. Die Frage ist nicht, wie man Anforderungen oder Anforderungsveränderungen („heute so und morgen so“) verhindern kann, sondern wie der Projektleiter zu jedem Zeitpunkt im Projekt mit Anforderungen umgeht. Aber gestalten wir den Einstieg in dieses Thema nicht zu schwierig, nehmen wir an, das Projekt befindet sich in einer frühen Phase und es gilt, die grundlegenden Anforderungen an die angestrebte „SPÜFI-Lösung“ zu erfassen. Lesen Sie selbst, was auf Schröder in Gestalt unseres wohlbekannten Kollegen Beißer zukommt:

Schröder sitzt im Besprechungsraum, ein paar Blätter einer ausgedruckten Liste liegen neben ihm, er macht Notizen auf diesen Blättern. Nach zehn Minuten trifft Beißer ein.

Schröder (schaut von seinen Blättern auf): „Herr Beißer, ich denke, Sie haben die finale Anforderungsliste zu ‚SPÜFI‘ schon gelesen, wir haben da noch einige Fragen, bevor wir die Liste heute abschließen. Wie ist das zum Beispiel mit den Kontoauszügen, wie viele Auszüge sollten pro Tag per E-Mail verschickt werden und was machen wir mit dem Format dieser Auszüge?“

Beißer (schüttelt fassungslos den Kopf, verdreht die Augen und blickt fast verächtlich an Schröder vorbei): „Schröder, so geht das nicht! Ich habe Ihnen schon x-mal gesagt, dass diese Auszüge genau so oft verschickt werden müssen, wie die Praxis es erfordert, ganz einfach.“ 29

Zweiter Akt – Überraschende Kundenanforderungen

Schröder (blickt fast hilflos auf Beißer): „Ja, das ist mir schon klar, aber wir brauchen von Ihnen als fachlichem Spezialisten diese Angaben für ein Mengengerüst, sonst wird unsere Software-Plattform später vielleicht zu klein und zu langsam oder zu groß und zu teuer.“

Beißer (übt weiter das verächtliche Blicken auf Schröder): „Schröder, das ist ihr Problem, Sie sind der Tekki – ach, und weil wir gerade bei den Auszügen sind, denken Sie an die Werbefläche auf den Auszügen, flexibel in der Größe.“

Schröder (bekommt das Gefühl, hier überrannt zu werden): „Letzte Woche sagten Sie doch, auf den Auszügen wird es keinerlei Werbung geben, jetzt muss es eine variabel gestaltbare Fläche für die Werbung sein?“

Beißer (verliert die Geduld und wird laut): „Schröder, dann habe ich meine Meinung einfach geändert. Heute muss man flexibel auf den Markt reagieren, und das gilt auch für Sie, Schröder. Sehen Sie zu, dass diese Anforderungen noch aufgenommen und umgesetzt werden, sonst muss ich zu Dr. Krott! Hier sind meine Skizzen, da können Sie sehen, wie man das machen könnte.“ (Er wirft Schröder drei Zettel zu.)

Schröder (blickt verzweifelt auf die drei handschriftlichen Seiten von Beißer): „Herr Beißer, diese neuen Anforderungen können wir unmöglich bis morgen in die Anforderungsliste übernehmen. Da gibt es bestimmt noch jede Menge Unklarheiten und eine Menge an Rückfragen. Dafür brauchen wir mindestens zwei Tage.“

www.hessen-it.de

Beißer (winkt ab und übt wieder den verächtlichen Blick): „Papperlapapp, Schröder. Sie sollen hier kein Kunstwerk abliefern, sondern lediglich diese Anforderungen bis morgen in der Liste aufnehmen. Und machen Sie das bloß ordentlich!“

Schröder (resigniert und denkt darüber nach, dass Beißer nun zum vierten Mal seine Anforderungen geändert hat, und diesmal einen Tag vor der geplanten Vorlage beim Chef. Wie das zu schaffen sein soll, ist ihm ein Rätsel.)

Dies ist nicht der richtige Zeitpunkt, Mitleid mit Schröder zu empfinden, nur weil der vermeintlich schlitzohrige Kollege Beißer sich so arrogant und herablassend verhält. Das ist nicht das Thema dieses Aktes. Es geht um die Dinge, die in diesem Akt nicht passiert sind. Weder sind die für Schröder wichtigen Informationen zur funktionalen Gestaltung von SPÜFI geflossen, noch hat Schröder sein Ziel, die Anforderungsliste zu finalisieren, erreicht. Vielleicht hatte Beißer nur einen schlechten Tag und vielleicht würde das Gespräch an einem anderen Tag positiver verlaufen – vielleicht aber auch nicht. Wahrscheinlicher ist, dass sich „Abstimmungen“ wie diese im Laufe des Projekts wiederholen werden, wenn die notwendigen Gegenmaßnahmen ausbleiben. Doch bevor mögliche Maßnahmen benannt werden, sollten wir zunächst die Indikatoren für die heranziehende Not im zweiten Akt unseres Dramas erkennen und beschreiben:

Zweiter Akt – Überraschende Kundenanforderungen

Unklare Anforderungen Was geschah? Analyse der Ereignisse – Indikatoren für die heraufziehende Not Schröder: „… wie viele Auszüge sollten pro Tag per E-Mail verschickt werden …?“ Beißer: „… Ich habe Ihnen schon x-mal gesagt, dass diese Auszüge genau so oft verschickt werden müssen, wie die Praxis es erfordert, ganz einfach.“ Lassen sich Anforderungen des Kunden qualitativ und quantitativ nicht erfassen, sind dies eindeutige Indikatoren für unklare

(und nicht bewertbare) Anforderungen. Wie lassen sich diese Indikatoren erkennen? Sicherlich haben Sie es längst erraten, zum Erkennen dieser Indikatoren muss man lediglich

beobachten und zuhören.

www.hessen-it.de

Stellen Sie sich vor, Sie gehen in ein Lokal und bestellen „so viel zu trinken, wie man eben Durst hat“. Was wird die „Servicemitarbeiterin Restaurantbetrieb“ bringen? Ein frisch gezapftes Pils für den Herrn, ein kühles Schlückchen Prosecco für die Dame oder vielleicht doch einen 5-LiterEimer mit Leitungswasser? Das gleiche Problem wie die Servicekraft haben im Falle der Softwareentwicklung die Programmierer und Projektleiter. Der tatsächliche Wunsch, die „Anforderung“, ist nicht klar beschrieben. Im schlimmsten Fall werden diese unklaren Anforderungen – präziser bezeichnet als „Anforderungslücken“ – von Programmierern, Projektleitern, Analysten oder Beratern mit gut gemeinten Annahmen aufgefüllt. Doch spätestens bei der Einführung eines auf solche Annahmen hin entwickelten Systems ist mit großer Enttäuschung bei den Beißern dieser Welt zu rechnen. Der Wunschgedanke eines Projektteams ist selten deckungsgleich mit den tatsächlichen Vorstellungen des Kunden. Und wer will schon Leitungswasser, wenn er eigentlich an ein kühles Pils gedacht hat? Je länger solche Annahmen im Projekt fortleben und je später die Präzisierung der (fachlichen) Anforderungen von Seiten des Kunden vorgenommen wird, desto kostspieliger wird es, die spätere Enttäuschung des Kunden aufgrund dieser „angenommenen Anforderungen“ mit Nachbesserungen zu beheben. Dies zu vermeiden und Anforderungen mit der notwendigen Detaillierung zu erheben, ist im Abschnitt „Methodisches

Erheben von Anforderungen“ dargestellt.

Zweiter Akt – Überraschende Kundenanforderungen

Ständig wechselnde Anforderungen Was geschah? Analyse der Ereignisse – Indikatoren für die heraufziehende Not Schröder: „ … Letzte Woche sagten Sie doch, auf den Auszügen wird es keinerlei Werbung geben … “ Beißer: „ … Schröder, dann habe ich meine Meinung einfach geändert.“ Wenn vermeintlich erhobene Anforderungen aufgrund einer fehlenden Dokumentation (z. B. durch Protokolle) als unverbindlich angesehen und bei nächster Gelegenheit neue Anforderungen formuliert werden, so sind dies eindeutige Indikatoren für ständig wechselnde

Anforderungen. Wie lassen sich diese Indikatoren erkennen? Ganz einfach, zum Erkennen dieser Indikatoren muss man lediglich beobachten und zuhören.

Seine Meinung zu ändern und kund zu tun, ist eine der Grundfesten unserer Demokratie. Dies sollte jedoch nicht verwechselt werden mit einer „Heute hü und morgen hott“-Philosophie und fehlender Verbindlichkeit in den Aussagen. Software-Entwicklung benötigt eine gewisse Kontinuität, Klarheit und Präzision und Verbindlichkeit über die notwendige Zielrichtung, in der solch ein kostspieliges Vorhaben vorangetrieben werden sollte. Nur so können sich Qualität, Termintreue und Zieltreue nachhaltig im Projekt entfalten und die Zufriedenheit des Kunden – in der Erwartung, dass er bekommt, was er wollte – im Voraus fördern. Dass es ein weiter und steiniger Weg für einen Projektleiter ist, bis eine finale Anforderungsliste oder ein Lasten- und Pflichtenheft vorliegen, ist unbestritten. Doch muss dieser Weg von allen Beteiligten beschritten werden, um die notwendige Klarheit und Präzision zu erreichen. Wie dies zielgerichtet erreicht werden kann, beschreibt der Abschnitt „Qualitäts-

kriterien für Anforderungen“.

www.hessen-it.de

Mangelndes Anforderungsmanagement Was geschah? Analyse der Ereignisse – Indikatoren für die heraufziehende Not Schröder: „ … diese neuen Anforderungen können wir unmöglich bis morgen in die Anforderungsliste übernehmen. Da gibt es bestimmt noch jede Menge Unklarheiten und eine Menge an Rückfragen. …“ Beißer: „ … Papperlapapp, Schröder. Sie sollen hier kein Kunstwerk abliefern, sondern lediglich diese Anforderungen bis morgen in der Liste aufnehmen … .“ Werden Anforderungen umgewertet, das heißt ohne Angaben zu Implikationen in Bezug auf Zeit, Kosten und Ressourcen einfach aufgenommen, sind dies eindeutige Indikatoren für ein mangelndes

Anforderungsmanagement. Wie lassen sich diese Indikatoren erkennen? Mit Sicherheit wissen Sie es längst. Ja, zum Erkennen dieser Indikatoren muss man lediglich

beobachten und zuhören.

Das Leben ist kein Ponyhof, ein Projekt kein Wunschkonzert und goldene Wasserhähne kosten extra. Das einfache Zusammentragen von Anforderungen, d. h. das Niederschreiben in einer Liste, ist mit Sicherheit eine notwendige Voraussetzung, um Ziele eines Projekts zu definieren. Damit aus einem Projekt kein Wunschkonzert wird, muss die Bewertung dieser Anforderungen damit einhergehen. So kann sichergestellt werden, dass zwei weitere grundsätzliche Eckpfeiler eines Projekts mit folgender Frage bestimmt werden: Wie viel Zeit wird die Umsetzung dieser Anforderungen in Anspruch nehmen und welche Kosten werden damit verbunden sein? Liegen diese Informationen vor, gilt es eine wichtige Entscheidung für jede dieser Anforderungen zu treffen: Aufgrund der Ziel-, Zeit- und Kostenaspekte wird eine Anforderung umgesetzt oder aber für das Projekt abgelehnt. Wie sich dieser Ablauf zur Bewertung von Anforderungen gestaltet, finden Sie im Abschnitt „Einführung eines Anforderungsmanagement-

Prozesses“.

Zweiter Akt – Überraschende Kundenanforderungen

Zusammenfassung des Notfalls „Überraschende Kundenanforderungen“ Auch wenn es inzwischen schwer fällt, sind wir wieder aufgefordert, Strenge mit Schröder walten zu lassen, ungeachtet des zweifelsfrei nicht gerade kollegialen Verhaltens von Beißer. Darum fassen wir kurz zusammen, welche wertvollen Erkenntnisse in diesem Akt verborgen sind: a Schröder hat im Verlauf des Gesprächs keine der unpräzisen Angaben von Beißer hinterfragt, um die notwendigen Vorgaben für eine zielgerichtete Entwicklung zusammenstellen zu können. Was hier hilft, sind die Regeln für ein methodisches Erheben von Anforderungen. a Nicht genug, dass Beißer auf die Präzisierung von Informationen verzichtet, er ändert bereits definierte Vorgaben ab und lässt keinerlei Vorbehalt von Schröder zu. Was hier hilft, die Hilflosigkeit Schröders aufzulösen, ist die Einführung der Dokumentation der Anforderungserhebung. a Dennoch wird es nicht ausreichen, Anforderungen zu erheben und zu dokumentieren. Im Sinne eines Projekts, das ein vorgegebenes Ziel unter Berücksichtigung von Zeit und Kosten erreicht, ist es ebenso von Bedeutung, Anforderungen im Rahmen eines definierten und allen Beteiligten bekannten Prozesses zu validieren. Was hier hilft, ist die Einführung eines Anforderungsmanagement-Prozesses.

NOT a Unklare (und nicht bewertbare) Anforderungen und Zielvorgaben a Ständig wechselnde Anforderungen a Mangelndes Anforderungsmanagement

HILFE a Methodisches Erheben von Anforderungen (Anforderungsmanagement) a Qualitätskriterien für Anforderungen a Einführung eines Anforderungsmanagement-Prozesses

www.hessen-it.de

Methodisches Erheben von Anforderungen (Anforderungsmanagement) Wesentliche kritische Faktoren des Anforderungsmanagements sind: Unklare Anforderungen und Zielvorgaben, schlechte Qualität der Anforderungsdokumentation, hohe Komplexität, ständiger Wechsel der Anforderungen und Kommunikationsprobleme. Diese fünf Themen werden im Folgenden näher beschrieben und einige Lösungsvorschläge gemacht.

Klare Anforderungen und Zielvorgaben Unklar formulierte Anforderungen führen zu falschen oder zu optimistischen Planungen, da der eigentliche Aufwand und die Komplexität nicht erkannt werden. Drastische Folgen sind im späteren Verlauf Budget- und Terminüberschreitungen. Dies kann bis zu einem Projektabbruch führen. Klare Anforderungen und Zielvorgaben hingegen senken das Projektrisiko. Ein Projektleiter, der nicht klar definierte Projektziele mit unscharfen Anforderungen dennoch plant und verfolgt, handelt eigentlich fahrlässig. Vergleichbar mit einem Schiff ohne Ruder weiß er weder „wie“ noch „wohin“ die Reise geht und läuft damit stets Gefahr, Schiffbruch zu erleiden! Vornehmste Aufgabe eines Projektleiters ist es deshalb – entgegen der Meinung von Beißer –, Klarheit über die Anforderungen herbeizuführen.

Adäquate Qualität der Anforderungsdokumentation Ein Kernproblem ist die Mehrdeutigkeit in der Dokumentation von Anforderungen. Jeder Leser fasst die Anforderungen für sich anders auf und hat unterschiedliche Vorstellungen, wie das Ergebnis am Ende aussehen soll. Dies hat zur Folge, dass das erwartete Ergebnis des Anforderungsstellers nicht mit dem vom Entwickler gelieferten übereinstimmt. Der Entwickler hat dann vielleicht eine tolle Lösung für ein leider nicht vorhandenes Problem realisiert. So verschwenden die Projektbeteiligten mit mehrdeutigen Anforderungen unnötig Zeit und Geld. Bleibt zu hoffen, dass spätestens in der Testphase einer der Tester (ggf. der Anforderungssteller) bemerkt, dass seine Anforderungen nicht wunschgemäß erfüllt worden sind. 37

Zweiter Akt – Überraschende Kundenanforderungen

Doch wie vermeidet man die Mehrdeutigkeit und wie erfährt man, was der Anforderungssteller meinte? Der Analytiker (Anforderungserheber) darf nicht nur einen, sondern er muss mehrere Know-how-Träger zu dem gleichen Sachverhalt befragen. Denn das Fachwissen ist meist auf mehrere „Köpfe“ entlang der Unternehmensprozesse verteilt und Informationen, die aus Sicht des einen kaum Relevanz haben, sind für den anderen von großer Bedeutung.

Hohe Komplexität Die Erwartungshaltung gegenüber den zu entwickelnden Ergebnissen wird im Projektverlauf immer komplexer. Das ist völlig normal, denn je intensiver man sich mit einer Materie beschäftigt, desto mehr Ideen und Wünsche entstehen. Das wäre nicht weiter schlimm, aber damit stehen auch die Anforderungen in immer komplexeren, wechselseitigen Abhängigkeiten. Und nicht selten führt das zu „Gordischen Anforderungsknoten“. Das Niederschreiben der Anforderungen mehrerer Anforderungssteller mit verschiedenen Kompetenzen und unterschiedlichem Wissen erfordert deshalb Zeit und die Bereitschaft, sich in alle Anforderungssteller hineinzuversetzen.

Tipp: Oft ist eine weniger komplexe Lösung die bessere Lösung.

Wechselnde Anforderungen Es ist normal, dass sich Anforderungen während des Projekts verändern. Um schleichende Änderungen dennoch managen zu können, benötigt man klare Projektziele. Stellt man die geänderten Anforderungen den Projektzielen gegenüber, kann man sehr schnell unnötige Anforderungen von nötigen unterscheiden. Diese Gegenüberstellung hilft oft auch den Anforderungsstellern, unter Berücksichtigung des Zeit- und Mittelaufwandes, den sie zu vertreten haben, bessere Entscheidungen zu treffen, zu akzeptieren und mitzutragen.

www.hessen-it.de

Differentes Verständnis von Fachbegriffen Projektbeteiligte sprechen nicht immer die gleiche Sprache! Es werden dieselben Formulierungen für unterschiedliche Sachverhalte oder unterschiedliche Formulierungen für denselben Sachverhalt verwendet. So kann eine Sprachbarriere zwischen den Projektbeteiligten entstehen. Je nach Kenntnissen, Umfeld und Fachgebiet differiert der Sprachgebrauch der Beteiligten. Um differentem Verständnis von Fachbegriffen zu begegnen, müssen die wichtigsten im Projekt verwendeten Fachbegriffe standardisiert, z. B. in einem Glossar dokumentiert und an alle Projektbeteiligten kommuniziert werden. So schafft man eine für alle gleiche Verständnisbasis. .

Qualitätskriterien für Anforderungen Rettungsanker a vollständig a korrekt und verständlich Eine Anforderung ist erst dann korrekt, wenn der Anforderungssteller seine Vorstellungen beim Lesen komplett wiederfindet und versteht. a klassifizierbar Klassifizierte Anforderungen bieten die Möglichkeit, alle Anforderungen zu einem Thema auf einen Blick zu erfassen und deren Gesamtbedeutung zu erkennen. a bewertbar Nur sehr selten können Anforderungen zu 100 Prozent erfüllt werden. Bei konkurrierenden Anforderungen hilft eine Bewertung hinsichtlich des zu erwartenden Aufwands, des Nutzens, des Beitrags zur Unternehmensstrategie oder schlicht der gesetzlichen Notwendigkeit. a konsistent Unabhängig von der Art oder dem Abstraktionsgrad muss jede einzelne Anforderung gegenüber den anderen konsistent und widerspruchsfrei sein, sodass keine Verwirrungen entstehen. 39

Zweiter Akt – Überraschende Kundenanforderungen

Rettungsanker (Fortsetzung) a prüfbar Zur Prüfbarkeit einer Anforderung sollte das Ergebnis messbar sein und eine Maßeinheit besitzen. Erfahrungsgemäß bereitet dies in der Praxis Schwierigkeiten. Anforderungen wie „Die Applikation soll schneller reagieren“ oder „Die Oberfläche soll schöner gestaltet werden“ sind Negativbeispiele und stellen nicht messbare Beispiele dar. Messbar hingen wäre: „Eine Antwortzeit von maximal 1 Sekunde“ oder „Die Oberfläche soll dem Entwurf Nr. 2 der Design-Agentur Maier entsprechen, siehe Anlagen“. a verfolgbar Erhält jede Anforderung eine eindeutige Anforderungsnummer, die über die gesamte Projektlaufzeit hinweg unverändert bleibt, können sich Anforderungssteller und Anforderungsmanager immer auf die gleiche Anforderung beziehen. a gültig und aktuell Anforderungen ändern sich, werden zusammengefasst oder entfallen. Für die Anforderungssteller ist es deshalb wichtig, nachvollziehbar festzuhalten, was aus ihrer Anforderung wurde und welche Fassung gerade aktuell ist. a realisierbar Nicht alle gewünschten Anforderungen sind im Projektrahmen umsetzbar. Werden IT-technische Grenzen erreicht, sind Anforderungen im System oft nur mit sehr hohem Aufwand durchführbar. a finanzierbar und notwendig Die Wichtigkeit und die Dringlichkeit einer Anforderung sollte deren Kosten gegenübergestellt werden. Dabei sollte man sich mindestens diese drei Fragen stellen: 1. Um welche Art der Anforderung handelt es sich (funktional / nicht funktional)? 2. Ist es eine „Muss-“, „Soll-“ oder „Kann-“ Anforderung? 3. Welche Risiken / Auswirkungen könnten entstehen, wenn die Anforderung nicht umgesetzt wird? 40

www.hessen-it.de

Einführung eines Anforderungsmanagement-Prozesses Die Qualität der Projektergebnisse hängt direkt mit der Qualität des Anforderungsmanagements zusammen. Dennoch wird es in der Praxis häufig vernachlässigt. Nicht, weil das Anforderungsmanagement komplex und schwer durchzuführen wäre, sondern weil seine Wichtigkeit oft unterschätzt wird.

Erste Phase: Ermitteln Die Ermittlung der vollständigen Anforderungen ist eine Herausforderung. Denn hier steht der Mensch im Mittelpunkt. Zunächst sollten deshalb alle durch die Projektaktivitäten Betroffenen (umgangssprachlich „Stakeholder“) identifiziert und befragt werden. Denn genau diese Personen verfügen über die wirklich projektrelevanten Informationen. Durch den gezielten Einsatz von Ermittlungstechniken gelangt man so an die notwendigen Anforderungen. Interviews, Fragebögen, Beobachtungen, Brainstorming etc. sind typische Ermittlungstechniken, die je nach Projektsituation und -bedarf eingesetzt werden.

Zweite Phase: Formulieren Sind die erforderlichen Anforderungen in der Ermittlungsphase gesammelt, werden sie eindeutig, testbar und verständlich dokumentiert. Die Dokumentationstechnik muss für alle Leser eindeutig und leicht zu verstehen sein.

Dritte Phase: Validieren Die gesammelten und beschriebenen Anforderungen werden in der Validierungsphase so lange modifiziert, bis alle Stakeholder (umgangssprachlich „Betroffene“) Einigkeit darüber erzielen. Die validierten Anforderungen werden in einem symbolischen Akt mit einer Abnahme genehmigt. Dieser scheinbar kleine Akt führt dazu, dass ab diesem Moment die Anforderungen von den Anforderungsstellern wirklich getragen und oft sogar gemeinsam mit dem Projektteam verteidigt werden.

Zweiter Akt – Überraschende Kundenanforderungen

Rettungsanker Anforderungsmanagement Nicht kompliziert, aber häufig unterschätzt. Gehen Sie strukturiert vor: a Anforderungen ermitteln a Anforderungen formulieren und dokumentieren a Einigkeit über die Anforderungen mit allen Beteiligten erzielen

Selbst mit einfachen Werkzeugen wie z. B. einer Textverarbeitung oder einer Tabellenkalkulation hätte Schröder ein hinreichendes und für jeden verständlich nachvollziehbares Anforderungsmanagement aufbauen und umsetzen können. Stattdessen muss er sich weiter von Beißer vorführen lassen, anstatt seinerseits dessen „Heute hü und morgen hott“-Philosophie klar und dokumentiert aufzeigen zu können. Für Beißer ist das sehr angenehm, denn er kann weiter alles auf den gesetzten Sündenbock Schröder abschieben und von seinen eigenen Mängeln elegant ablen-

ken. Schauen wir, wie es Schröder weiter ergeht.

www.hessen-it.de

Dritter Akt Termin beim Chef

Schröder hastet zu einem der unregelmäßigen und spontanen Meetings mit Dr. Krott, setzt sich mit seinem Notizblock an den Besprechungstisch in Dr. Krotts Büro.

Dr. Krott (bleibt an seinem Schreibtisch sitzen und blättert in Unterlagen): „Guten Tag, Schröder. Ich hoffe die Anbindung für Ex & Hopp ist bald fertig. Van Hopp hat angerufen und sich erkundigt, wann es denn endlich losgeht. Bitte enttäuschen sie mich da nicht, das wäre ein schwerer Schlag für die Bank. Ich kann mich doch auf Sie verlassen, Schröder?!“

Schröder (versucht in Gedanken zu sortieren, welche Themen er heute unbedingt ansprechen muss): „Tja, wir haben da noch ein paar Ressourcenprobleme, da der ‚0815‘-Auftrag noch nicht ganz fertig ist. Und Abteilungsleiter Beißer macht schon mächtig Druck. Wir bräuchten da eine Entscheidung, ob Entwickler Taucher jetzt an ‚0815‘ oder für Ex & Hopp arbeiten soll.“

Dr. Krott (zieht die linke Augenbraue hoch und denkt sich, wenn dies alle meine Probleme wären, hätte ich keine): „Mein lieber Schröder, Sie können sich ja vorstellen, dass wir auf keinen Kunden verzichten können. Und denken Sie an die Konventionalstrafen bei dem Ex & Hopp-Projekt! Reden Sie mal mit Taucher. Dann muss Taucher einfach ein paarmal länger arbeiten.“

Dritter Akt – Termin beim Chef

Schröder (malt Blumen in sein Notizbuch und grübelt leise vor sich hin, ohne ein Wort zu sagen, und denkt, dass er das ja schon probiert hat. Taucher ist schon demotiviert genug. Und wer soll jetzt ‚0815‘ machen? Am Ende muss ich das selbst erledigen und das Wochenende ist wieder hin. Und wehe, ich werde nicht fertig!)

Dr. Krott (nutzt die Stille und wechselt das Thema): „Ach, da fällt mir ein, Van Hopp möchte, dass wir übermorgen um 9 Uhr zu ihm kommen und über den aktuellen Projektstatus berichten. Bitte, machen Sie uns einen Bericht dazu bis übermorgen fertig, damit wir ihm zeigen können, dass wir alles im Griff haben.“

Schröder (denkt, dass ihm das gerade noch fehlt. Das kostet mich fast den ganzen Tag, an dem wieder kein Schlag an den aktuellen Aufgaben gearbeitet wird): „Bis übermorgen? Ich werde es probieren. Aber was wollen wir ihm denn berichten? Van Hopp hat doch gerade erst den ersten Prototyp zum Testen installiert bekommen.“

Dr. Krott (blättert weiter in irgendwelchen Unterlagen und klappt schließlich einen Ordner zu, greift nach seiner Aktentasche): „Sie schaffen das schon, Schröder. Tut mir leid, aber ich muss jetzt dringend weg zu einem Kundentermin. Das geht vor, Schröder, das verstehen Sie doch.“

www.hessen-it.de

Schröder (fühlt sich verlassen und denkt, das es wieder keine Entscheidung gibt und wieder keine Ressourcen): „Ja natürlich, Herr Dr. Krott. Aber beim nächsten Mal müssen wir dringend noch einige Punkte besprechen.“

Dr. Krott (winkt ab): „Machen wir, Schröder, machen wir. Wann kommt morgen diese Anforderungsliste?“ (Er blickt auf seine neue Armbanduhr) „Oh, ich muss gehen, auf Wiedersehen, Schröder … und denken Sie an den Bericht!“

Schröder (fühlt sich mehr als verlassen, packt sein Notizbuch und macht sich auf den Weg zu Taucher.)

Man muss es nur wollen, dann kann man selbst einen hoch motivierten und guten Projektleiter kaputt machen. Und Schröder ist erst ganz am Anfang, vielleicht in ferner Zukunft hoffentlich ein guter Projektleiter. So wie er versucht, eine Entscheidung von Dr. Krott zu bekommen, kann er noch sehr lange darauf warten. Er hat es mit Dr. Krott aber auch nicht leicht, denn dieser kommt seiner Aufgabe als Chef und Manager nicht nach, drückt sich vor Entscheidungen und glaubt dabei noch clever zu handeln, wenn er Schröder mit noch mehr Aufgaben und Problemen wieder zurück an die Arbeit schickt. Dr. Krott ist ein charmanter Drückeberger, den die Wucht seiner Managementinkompetenz früher oder später noch sehr hart treffen wird. Im Folgenden analysieren wir wieder einige Aspekte des Dialogs, zeigen anschließend auf, wie und woran man sehr einfach Indikatoren für drohende Not erkennen kann und stellen letztlich wieder einige Maßnahmen zur Behebung vor.

Dritter Akt – Termin beim Chef

Fehlende Entscheidungen und Maßnahmen zur Entscheidungsunterstützung Was geschah? Analyse der Ereignisse – Indikatoren für die heraufziehende Not Schröder: „ … Wir bräuchten da eine Entscheidung, ob Entwickler Taucher jetzt an ‚0815‘ oder für Ex & Hopp arbeiten soll … “ Dr. Krott: „ … Reden Sie mal mit Taucher. Dann muss Taucher einfach ein paar Mal länger arbeiten.“ Die Frage war nicht, wie lange Taucher arbeiten soll, die Frage war, an welchem Projekt Taucher arbeiten soll. Dies sind eindeutige Indikatoren für eine fehlende Entscheidung. Wie lassen sich diese Indikatoren erkennen? Es ist vielleicht erstaunlich, aber zum Erkennen dieser Indikatoren muss man lediglich

beobachten und zuhören.

Dr. Krott drückt sich geschickt vor einer klaren Entscheidung und Schröder hat nicht die leiseste Ahnung, wie er seinen Chef zu einer Entscheidung führen könnte. Dabei bedarf es keiner Magie um Menschen zu einer Entscheidung zu führen. Denn jeder Mensch kann sich nur dann entscheiden, wenn er Alternativen hat, wenn er die jeweiligen Konsequenzen kennt, eine Empfehlung bekommt und rechtzeitig informiert wird. Beherzigt man diese Kriterien, kann ein Entscheider entscheiden und er tut es dann in aller Regel auch. Wie man das praktisch angeht, wird im Abschnitt „Zielgerichtete

Entscheidungsvorbereitung und -Unterstützung“ gezeigt.

www.hessen-it.de

Fehlende Ressourcenzuordnung Was geschah? Analyse der Ereignisse – Indikatoren für die heraufziehende Not Schröder: „ … Tja, wir haben da noch ein paar Ressourcenprobleme, da der ‚0815‘-Auftrag noch nicht ganz fertig ist.“ Dr. Krott: „ … Reden Sie mal mit Taucher. Dann muss Taucher einfach ein paarmal länger arbeiten.“ Schröder (… Am Ende muss ich das selbst erledigen und das Wochenende ist wieder hin. Und wehe, ich werde nicht fertig!) … Aus dem Gespräch lässt sich erkennen, dass für die Anzahl der Aufgaben nicht ausreichend Ressourcen zur Verfügung stehen, um im gesetzten Zeitrahmen das Ziel zu erreichen. Dies sind eindeutige Indikatoren für eine fehlende Ressourcenzuordnung. Wie lassen sich diese Indikatoren erkennen? Bitte nicht wundern, aber zum Erkennen dieser Indikatoren muss man lediglich beobachten

und zuhören.

Hätte Schröder seine Kapazitätsplanung und seine Aufgabenpriorisierung (s.o.) erstellt, könnte er sein Ressourcenproblem bereits viel deutlicher und diskussionsfreier darstellen. Er hat aber auch keine Ressourcenplanung für die laufenden Projekte gemacht, sonst hätte er sie für den Termin mit Dr. Krott vorlegen können. Aber Schröder hat weder diese noch Ressourcenvereinbarungen getroffen. Unserem charmanten Drückeberger Dr. Krott kommt das gerade recht und er wimmelt Schröder locker mit einer bauernschlauen Phrase ab. Wie man Ressourcen einfach planen und Ressourcenvereinbarungen treffen kann, wird im Abschnitt „Gesicherte Ressourcenplanung“ behandelt.

Dritter Akt – Termin beim Chef

Ad-hoc-Berichte Was geschah? Analyse der Ereignisse – Indikatoren für die heraufziehende Not Dr. Krott: „ … Bitte, machen sie uns einen Bericht dazu bis übermorgen fertig, damit wir ihm zeigen können, dass wir alles im Griff haben.“ Werden häufiger kurzfristig und ohne Orientierung an oder Rückgriff auf vorherige Berichte regelmäßig wiederkehrende (Status-) Berichte für unterschiedliche Empfänger von Seiten des Managements angefordert, kann dies schnell notwendige Ressourcen binden. Dies sind eindeutige Indikatoren für (zu viele) Ad-hoc-Berichte. Wie lassen sich diese Indikatoren erkennen? Man könnte es erahnen, zum Erkennen dieser Indikatoren muss man lediglich beobachten und zuhören.

Dr. Krott lässt Schröder keine Chance. Er will auch nicht wissen, was Schröder in der Zeit bis zur Berichterstellung alles liegen lassen muss und welche Konsequenzen das hat. Den Preis für dieses mangelhafte Management muss Dr. Krott allerdings in jedem Fall zahlen. Durch seine Managementmethode erfährt er dies erst viel später, und der Bezug zur eigenen Fehlbarkeit lässt sich kaum mehr herstellen. Aber auch Schröder hat keine Idee, wie er effizient Bericht erstatten könnte. Wie man zweckdienliche Berichte ohne großes Zeitinvestment erstellen kann, wird im Abschnitt „Aufbau eines geregelten Berichtswesens“ gezeigt.

www.hessen-it.de

Zusammenfassung des Notfalls „Termin beim Chef“ Fassen wir zusammen: Auch anhand des dritten Aktes unseres Stückes lassen sich Indikatoren für eine heraufziehende Not identifizieren. So schön es auch wäre: Meistens liegt es nicht beim Chef, wenn es keine Entscheidung gibt, sondern an dem, der die Entscheidung möchte. Wie in unserem Falle bei Schröder. a Dr. Krott entscheidet nicht und Schröder kann ihn nicht zu einer Entscheidung führen. Hier hilft Zielgerichtete Entscheidungs-

vorbereitung und -unterstützung. a Schröder hat keine Vorstellung, welche Ressourcen ihm überhaupt zur Verfügung stehen können, geschweige denn, wie er diese planen soll. Abhilfe schafft der Abschnitt Gesicherte Ressourcenplanung. a Sich häufende Ad-hoc Berichte werden Dr. Krott kaum helfen, und Schröder bringen sie weiter in Zeitnot. Der Aufbau eines geregelten

Berichtswesens kann die heraufziehende Not lindern.

NOT a Fehlende Entscheidung a Fehlende Ressourcenzuordnung a (Zu viele) Ad-hoc-Berichte

HILFE a Zielgerichtete Entscheidungsvorbereitung und -unterstützung a Gesicherten Ressourcenplanung a Aufbau eines geregelten Berichtswesens

Dritter Akt – Termin beim Chef

Zielgerichtete Entscheidungsvorbereitung Drei Alternativen darstellen Zu jeder Entscheidung müssen mindestens drei Alternativen erarbeitet werden. Denn eine Alternative ist keine, sondern bedeutet Zwang. Zwei Alternativen stellen immer ein Dilemma dar. Erst ab drei Alternativen kann sich ein Entscheider wirklich entscheiden. Entscheidungen müssen nachvollziehbar sein. Deshalb ist es ratsam, diese immer schriftlich auszuarbeiten.

Konsequenzen aufzeigen Zu jeder Alternative müssen die Konsequenzen hinsichtlich der Kosten, Termine und Inhalte der Varianten klar aufgezeigt werden. Das führt oft dazu, dass der Entscheider (endlich) erkennt, dass es keine glückselig machende Lösung gibt, sondern dass jede Entscheidung ihre Vor- und Nachteile hat.

Empfehlung des Projektteams Wenn eine Alternative als „vom Projektteam empfohlen“ und bei Nichtentscheidung als „so umgesetzt“ deklariert wird, werden auch die Konsequenzen einer Nichtentscheidung aufgezeigt. Der Entscheider hat dann ja immer noch das Recht, darüber hinaus zu beschließen. Bei einigen Entscheidern allerdings führt diese Variante zur Entscheidung nach dem Motto: „Und scheint die Sonn’ zum Fenster rein, mach ’nen Haken dran, es wird richtig sein!“ Diese Methode spricht zwar nicht für den Entscheider, ist aber auf Grund dessen, dass das Projektteam diese Alternative gefunden hat, selten eine wirklich schlechte Entscheidung. Und sie kommt viel öfter vor, als man glauben mag.

www.hessen-it.de

Zeitnahe Vorlage einer Entscheidungs-Vorlage Je folgenschwerer bzw. umfangreicher eine Entscheidung ist, desto wichtiger ist es, die Entscheidungsvorlage rechtzeitig vor dem letzten Entscheidungstermin mit Hinweisen zur Wichtigkeit dem bzw. den Entscheidern zur Verfügung zu stellen.

Rettungsanker Entscheidungsvorbereitung Die Aufgabe, eine Entscheidung zu treffen, geht immer einher mit dem Risiko, die falsche Entscheidung getroffen zu haben. Um eine Entscheidung zu ermöglichen, ist es essenziell für den Entscheider, das Risiko für eine Fehlentscheidung wie folgt zu minimieren: a Erarbeitung von drei Entscheidungsalternativen a Bewertung der Alternativen auf Kosten, Zeit und Auswirkung auf die Zielerreichung a Eigene Empfehlung aussprechen und begründen a Zusammenfassung in einer schriftlichen Entscheidungsvorlage mit Zieldatum für die Entscheidung a Konsequenzen einer Nicht-Entscheidung (oder dem Verstreichen des Zieldatums) als „vierte Alternative“ aufzeigen a Frühzeitiges Einreichen vor dem Besprechungstermin zur Entscheidung

Dritter Akt – Termin beim Chef

Zielgerichtete Entscheidungsunterstützung a Nichtentscheidung Kommt es während eines Termins zu keiner Entscheidung, kann als letzte Möglichkeit nochmals die vom Projektteam empfohlene Alternative vorgeschlagen werden, die in diesem Fall vom Team umgesetzt wird. Greift der Entscheider jetzt nicht ein, war das seine Entscheidung. a Protokollieren Jede Entscheidung ist zugunsten der Nachvollziehbarkeit zu protokollieren. Besonders betrifft dies den zuvor beschriebenen Entscheidungstyp „Nichtentscheidung“! a Letzter Entscheidungstermin Bei allem Verhandlungsgeschick, es kommt auch vor, dass man dennoch keine Entscheidung erhält. In diesem Falle muss auf die Konsequenzen der Nichtentscheidung hingewiesen werden, und es muss sofort ein neuer Termin für die Entscheidungsfindung vereinbart werden. Weiter müssen alle an der Entscheidung Beteiligten befragt werden, welche Informationen sie für eine Entscheidung noch benötigen.

www.hessen-it.de

Rettungsanker Entscheidung unterstützen a Meeting mit Ziel für das Treffen einer Entscheidung einberufen. a Alternativen besprechen und Pro und Contra dokumentieren. a Besteht zusätzlicher Klärungsbedarf, die Fragen aufnehmen und mit Hinblick auf den avisierten letztmöglichen Entscheidungstermin einen Folgetermin vereinbaren. a Getroffene Entscheidungen schriftlich dokumentieren und an einen abgestimmten Interessentenkreis kommunizieren.

Schröder fehlt natürlich die Aufgabenpriorisierung (s.o.), mit deren Hilfe es keine Diskussion gäbe. Aber auch ohne diese verspielt er durch eine mangelhafte Entscheidungsvorbereitung die Chance auf eine Entscheidung. Und Dr. Krott kommt diese mangelhafte Vorbereitung scheinbar zu

Gute und er kann sich mal wieder vor der Entscheidung drücken.

Dritter Akt – Termin beim Chef

Gesicherte Ressourcenplanung Eine Ressourcenplanung zeigt auf, welche Mitarbeiter zu welchen Zeitpunkten an welchen Projekten arbeiten sollen. Um diese erstellen zu können, bedarf es der folgenden Informationen sowie einer Vereinbarung mit dem Ressourcensteller. a Aufwandschätzungen Sie sind Voraussetzungen, die Auskunft darüber geben, wie viele Menschtage mit welchen Skills vermutlich benötigt werden. a Skillprofile Sie geben Auskunft darüber, welche Mitarbeiter über die benötigen Skills verfügen, welche man ggf. durch Ausbildung dahin entwickeln kann oder ob externe Ressourcen benötig werden. a Kapazitätsplanungen der Ressourcensteller Diese Voraussetzungen geben Auskunft darüber, wann welche Ressource (in diesem Fall Mitarbeiter) grundsätzlich verfügbar ist. Gleiches gilt aber auch für externe Ressourcen. a Aufgabenpriorisierungen Eine weitere Voraussetzung, die Auskunft darüber gibt, wann vermutlich die Realisierung der Aufgabe, für welche ja die Ressourcenplanung gemacht werden soll, erfolgen wird. a Puffer Planung ist nicht gleich Hellsehen. Und weil das so ist, muss eine Ressourcenplanung immer mit einem Puffer versehen werden. Dieser Puffer führt dazu, dass es nicht zu oft zu hektischen und dann meist riskanten Umpriorisierungen kommt. Sie kommen dennoch, aber eben nicht so oft. a Projektantrag Eine grobe Ressourcenplanung ist bereits Bestandteil des Projektantrags. Er bietet deshalb eine gute Grundlage für eine detaillierte Ressourcenplanung.

www.hessen-it.de

Rettungsanker Voraussetzungen für eine Ressourcenplanung Für eine gesicherte Ressourcenplanung müssen folgende Informationen gegeben sein: a Realitätsnahe Aufwandsschätzung a Vollständig definierte Arbeitspakete und Aufgaben a Priorisierung der Aufgaben a Arbeitstechnische Verfügbarkeiten (Raum, Arbeitsplatz, Zugang, …) a Kapazitätsplanung der Ressourcensteller

a Berücksichtigung von Puffern

Dritter Akt – Termin beim Chef

Ressourcenvereinbarung a Schriftlich Wie schnell vergisst ein Ressourcensteller doch, dass er zu einer Ressourcenanfrage „Ja“ gesagt hatte. Dieser Fehler passiert selbst gewieften Projektleitern immer mal wieder. Es ist ja auch viel angenehmer, einem freundlichen „Ja“ Glauben zu schenken. Nicht etwa, dass der Ressourcensteller zum Zeitpunkt seines Jas nicht voller Überzeugung zugestimmt hätte, aber dummerweise ist halt doch etwas Aktuelles dazwischen gekommen. Darum: Schriftlich festhalten! a Anpassen Projekte haben immer große Unbekannte. So bald nur absehbar ist, dass die Realisierung von der Planung stärker abweichen könnte, sollte man deshalb mit dem Ressourcensteller die Ressourcenvereinbarung besprechen und möglicherweise bereits anpassen. Ein frühzeitiges Anpassen der Ressourcenvereinbarung führt selbst bei externen Mitarbeitern zu keinen Problemen, denn jede Seite kann dann frühzeitig planen. Zu späte Anpassungen führen jedoch fast immer zu Konflikten. a Fixe Termine Mit seinem Chef bzw. seiner Chefin sollte man grundsätzlich und unabhängig von der Ressourcenvereinbarung fixe Besprechungstermine vereinbaren. Wenn der Chef dann mal weg muss, sofort einen Ersatztermin anfordern. Und fällt der weg, gibt es immer noch den nächsten Jour Fixe.

www.hessen-it.de

Rettungsanker Ressourcenvereinbarung Für eine gesicherte Ressourcenplanung müssen folgende Voraussetzungen gegeben sein: a Vereinbarungen werden schriftlich festgehalten a Frühzeitige Anpassung der Ressourcenvereinbarungen bereits wenn die ersten Erkenntnisse vorliegen a Jour-Fixe-Termine vereinbaren a Arbeitstechnische Verfügbarkeiten (Raum, Arbeitsplatz, Zugang, …) sind geklärt a Kapazitätsplanung der Ressourcensteller a Berücksichtigung von Puffern

Hätte Schröder Dr. Krott die Ressourcenplanung und die Aufgabenpriorisierung vorlegen können, hätte dieser sich entscheiden müssen und wäre

photocase.com

damit seiner Aufgabe als Manager nachgekommen.

Dritter Akt – Termin beim Chef

Aufbau eines geregelten Berichtswesens Berichte dienen den Berichtsempfängern sowohl der Information als auch der Kontrolle. In einer guten Projektumgebung empfinden die Berichter den Zwang zur Berichterstellung gleichzeitig als Chance zur Selbstkontrolle. So ziehen sowohl die Ersteller als auch die Empfänger ihren Nutzen aus Berichten. Die größten Probleme ergeben sich bei einer unterschiedlichen Auffassung über den Berichtsumfang und die Häufigkeit zwischen den Parteien. a Nur die wesentlichen Punkte berichten. Nicht die Vollständigkeit des Berichts, sondern die Relevanz der Informationen ist in den allermeisten Fällen für den Empfänger interessant. a Nur einfache und standardisierte Berichte verwenden. Standardisierte Berichte bieten dem Leser den Vorteil, die Informationen immer in gleicher Lesart und damit schneller aufnehmen zu können. Das ist besonders wichtig für Managementberichte, da Manager für gewöhnlich glauben, wenig Zeit zu haben. a Stichwortpräsentationen sind besser als Textwüsten. Sie sind zum einen schneller zu erstellen als Prosatexte, und zum anderen bieten sie dem Zuhörer die Möglichkeit zur direkten Rückfrage. a Mehr Berichte = weniger Projektarbeit Dem Management sollte man in einer geeigneten Situation klar machen, dass gerade in schweren Projektphasen noch mehr Berichte nicht dem Ziel dienen, das Projekt in time, scope und budget (d.h. in der vorgegebenen Zeit, mit dem vorgegebenen Ziel und dem vorgegebenen Budget) fertig zu stellen, sondern genau dem Gegenteil. a Berichte kosten Geld und Zeit Dem Management sollte man ebenfalls erklären, dass das Gefühl einer besseren Kontrolle durch mehr Berichte nur durch einen höheren Aufwand an Zeit und/oder Budget zu erkaufen ist.

www.hessen-it.de

Rettungsanker Standardisiertes Berichtswesen Zu viele Berichte sind Zeiträuber für die Steuerungsaufgaben eines Projektleiters: a Nur wesentliche Punkte berichten a Berichte standardisieren und als Vorlagen verwenden a Stichwortpräsentationen a Zu Projektbeginn wiederkehrende Regelberichte definieren, und zwar nach Inhalt, Berichtszeitpunkt, Zielgruppe

Beispielbericht Den folgenden Statusbericht innerhalb einer Präsentation verwenden auch die Autoren dieses Ratgebers in ähnlicher Form in der täglichen Praxis. Projektleiter können einen solchen Bericht in ca. 15 Minuten erstellen. Wird die Präsentationszeit knapp, kann der Projektleiter direkt auf die Probleme bzw. offenen Punkte des Statusberichts eingehen und die vorgeschlagenen Maßnahmen zur Entscheidung führen. So werden in jedem

Krakow, Malopolska; istockphoto.com

Fall die wesentlichen Punkte vermittelt, behandelt und entschieden.

Dritter Akt – Termin beim Chef

Status Projekt „BSP

“ vom 2.3. 2010

Erledigt

und geliefert orm definiert, bestellt ttf la ktp oje Pr r fü a HW CMS erledigt a Vorstudienprojekt t CMS erledigt r Kick Off Teilprojek a Vorbereitungen fü

Nächste Schritte

n ktplattform installiere eren ryverfahren installi Backup- und Recove ieren bis 4.3.2010 testen und dokument ab 8.3.2010 mitarbeiter / innen kt oje Pr r de ng lu hu a Sc 10 jekt CMS am 12.3. 20 a Kick Off Teilpro

a Software auf Proje

Probleme / Offene

nicht verfügbar r TeilHP-Entwickler “ fü hlende Ressource „P

a Projektbüro noch a Fe

Punkte

projekt CMS

Maßnahmen

durch Vorstand , Leiter Organisation Projektleitung oder tscheidung nötig! k heute Vorstandsen ffung, zur Ressourcenbescha g un id he tsc en ds an a Vorst bis g oder Zielreduktion Laufzeitverlängerun

a Raumbeschaffung

12.3. 2010

www.hessen-it.de

Rettungsanker Vorschlag Standardbericht Folgende Punkte in einem Statusbericht zu verwenden hat sich bewährt: a Zusammenfassender Gesamtstatus a Entwicklung in Bezug auf Meilensteine, Budget, Ressourcen, Ziel a Erledigte Aufgaben der Berichtsperiode a Geplante Aufgaben der kommenden Periode a Risiken / Probleme sowie Maßnahmen a Offene Punkte / Klärungsbedarf / Entscheidungen

Schröder hat keine Projektmanagementausbildung, darum kennt er weder die Notwendigkeit noch die Methoden einer Ressourcenplanung und eines Berichtswesens. Entscheidungen kann er nicht herbeiführen und sein Projekt gerät so immer weiter in Not. Schauen wir, wie es ihm und seinem Projekt weiter ergeht.

Vierter Akt – Geheimniskrämerei in der Entwicklung

Vierter Akt Geheimniskrämerei in der Entwicklung

Schröder schlendert mit vorgespielter Zufälligkeit zum Schreibtisch von Taucher.

Schröder (lächelt unbeholfen): „Na Taucher, wie geht es Ihnen?“

Taucher (denkt, dass Schröder das schon wissen muss, immerhin macht Abteilungsleiter Beißer ständig so unangenehm Druck, dass es einem wahrlich nicht gut gehen kann): „Geht so.“

Schröder (malt unbeholfen mit seinem Kugelschreiber – ohne Mine – auf Tauchers Schreibtisch virtuelle Blumen): „War gerade bei Krott. Er sagt, dass wir ‚0815‘ und Ex & Hopp schaffen müssen.“

Taucher (reagiert gereizt auf das virtuelle Malen von Schröder und regt sich noch mehr über dessen Aussage auf): „Jetzt fangen Sie als Projektleiter wohl auch noch an, Schröder? Ich habe es Ihnen doch schon mehrmals gesagt! Das geht nicht! Wie soll ich denn mit ‚Ex & Hopp‘ richtig anfangen, wenn ich mit ‚0815‘ nicht ansatzweise fertig bin? Die Dokumentation dafür muss auch noch jemand machen! Die Ex & Hopp-Anbindung steht noch immer nicht, und der Prototyp kann nicht mal einen Bruchteil der geforderten Funktionen. Und außerdem stürzt er ständig ab!“

Schröder (hört auf zu malen und steckt den Kugelschreiber ein): „Mann, Mann, Taucher. Wir hatten doch eine Planung gemacht. Danach sollte ‚0815‘ inzwischen fertig sein und SPÜFI für Ex & Hopp so gut wie in der Endphase.“ 62

www.hessen-it.de

Taucher (denkt, dass es ja ein unerwartetes Problem mit der für das ‚0815‘-Projekt verwendeten Open Source Software gegeben hat. Das konnte keiner vorher wissen, und es hat einfach zu lange gedauert, das Problem in den Griff zu bekommen. Aber das kann er Schröder nicht erzählen, denn der würde das sowieso nicht verstehen):„ ‚0815‘ ist ja so gut wie fertig. Aber was ist mit den Tests? Sie wollen doch die ‚0815‘-Software nicht ungetestet rausgeben, oder? Und die Doku muss auch noch jemand schreiben.“ (Taucher haut mit der flachen Hand vorsichtig auf den Tisch.)

Schröder (hebt abwehrend die Hände): „Taucher, um Gottes willen, nein, natürlich geben wir keine Software ungetestet heraus. Wie lange wird denn jetzt ‚0815‘ noch dauern? Und wie lange die Doku?“

Taucher (wirkt plötzlich nachdenklich): „Das hängt ganz von den Tests ab. Wenn die gut laufen, nächste Woche – vielleicht. Wenn nicht – tja, das weiß der Himmel. Und ich habe keine Ahnung, wer die Doku schreiben soll.“

Schröder (nimmt seinen Kugelschreiber und malt wieder virtuelle Blumen): „Was machen wir denn mit Ex & Hopp? Könnten sie da vielleicht noch mal am Wochenende … “

Taucher (springt auf und positioniert sich vor Schröder): „Ne, ne, Schröder, nicht schon wieder! Das läuft nicht!“ (Er wirft seinen Bleistift auf den Tisch und geht wortlos davon.)

Schröder (denkt sich eine Anzahl von unanständigen Worten, die hier nicht abdruckt werden können, und ruft Taucher hinterher): „Ja, ja, verstehe. War ja nur eine Frage. Ich werde es dann selbst versuchen.“ 63

Vierter Akt – Geheimniskrämerei in der Entwicklung

Mangelhafte Projektplanung Was geschah? Analyse der Ereignisse – Indikatoren für die heraufziehende Not Taucher: „ … Sie wollen die ‚0815‘-Software doch nicht ungetestet rausgeben, oder? Und die Doku muss auch noch jemand schreiben …“ Schröder: „ … Wie lange wird denn jetzt ‚0815‘ noch dauern? Und wie lange die Doku?“ Taucher: „ … Und ich habe keine Ahnung, wer die Doku schreiben soll.“ Wenn zu einem Zeitpunkt im Projekt nicht nachvollzogen werden kann, welche Aufgaben generell zu erfüllen sind und wer zur Erfüllung dieser Aufgaben beitragen kann, sind dies eindeutige Indikatoren für eine mangelhafte Projektplanung. Wie lassen sich diese Indikatoren erkennen? Als wäre es ein Wunder, aber zum Erkennen dieser Indikatoren muss man lediglich

beobachten und zuhören.

Taucher ist ein durchaus typischer Mitarbeiter, der sich – von der Unternehmenskultur geprägt – schon längst mit den Unarten des Unternehmens arrangiert hat. In Projekten wie diesem mit mangelhaftem Projektmanagement wirkt er dabei auf die anderen Projektbeteiligten gar nicht mal so schlecht. Doch tatsächlich drückt er sich vor seinen Aufgaben, er informiert seinen Projektleiter Schröder nicht selbständig und rechtzeitig über den Status seiner Aufgaben und über mögliche Planabweichungen. Doch letztlich ist Schröder als Projektleiter für eine hinreichende Projektplanung verantwortlich. Im Abschnitt „Eine Projektplanung aufsetzen“ werden die Basisvoraussetzungen für gutes Projektmanagement aufgezeigt, was unter anderem auch die Erstellung eines Projektplanes beinhaltet.

www.hessen-it.de

Unzureichende Projektsteuerung Was geschah? Analyse der Ereignisse – Indikatoren für die heraufziehende Not Taucher: „ …Wie soll ich denn mit ‚Ex & Hopp‘ richtig anfangen, wenn ich mit ‚0815‘ nicht ansatzweise fertig bin? Die Dokumentation dafür muss auch noch jemand machen! …“ Schröder: „ … Wir hatten doch eine Planung gemacht. Danach sollte ‚0815‘ inzwischen fertig sein und SPÜFI für Ex & Hopp so gut wie in der Endphase.“ Wenn Planung und Realität nicht übereinstimmen, muss steuernd in das Projekt eingegriffen werden, und ermittelt werden, wie die Vorgaben aus der Planung erreicht werden können. Findet dies nicht statt, sind das eindeutige Indikatoren für eine unzureichende Projektsteuerung. Wie lassen sich diese Indikatoren erkennen? Selbst ohne aufwendige Softwaretools kann man diese Fragestellung beantworten, denn zum Erkennen dieser Indikatoren muss man lediglich beobachten und zuhören.

Ein Schiff muss gesteuert werden, selbst wenn der Kurs am Start noch so exakt eingestellt wurde. Warum? Weil sich Wind, Wetter und Strömungen, technische Defekte und vieles mehr selbst mit den besten Methoden nicht so gut vorhersehen lassen, als dass man zu Beginn einer Reise alle diese Faktoren schon hinreichend berücksichtigen könnte. Auch ein Projekt ist eine Reise, die mit verschiedensten Einflussfaktoren zu kämpfen hat und Planabweichungen sind nicht die Ausnahme, sondern die Regel. Schröder jedoch ist so überlastet, dass er nicht einmal auf den Gedanken kommt, das Projektsteuer in die Hand zu nehmen. Vielleicht aber steuert er auch deshalb nicht, weil es Mut kostet, sich immer wieder mit unangenehmen Abweichungen auseinanderzusetzen und weil es Kraft kostet, steuernde Maßnahmen umzusetzen? Im Abschnitt „Grundlagen für eine praktikable Projektsteuerung“ wird der Projektregelkreis entwickelt, der die Methodik der Projektsteuerung aufzeigt.

Vierter Akt – Geheimniskrämerei in der Entwicklung

Vertuschung, Lügen, Sabotage Was geschah? Analyse der Ereignisse – Indikatoren für die heraufziehende Not Taucher: „ … Wie soll ich denn mit ‚Ex & Hopp‘ richtig anfangen, wenn ich mit ‚0815‘ nicht ansatzweise fertig bin?“ Taucher (… Aber das kann er Schröder nicht erzählen, denn der würde das sowieso nicht verstehen):„ ‚0815‘ ist ja so gut wie fertig.“ Auch wenn es hart klingt, aber dies sind leider eindeutige Indikatoren für Vertuschung, Lügen, Sabotage. Wie lassen sich diese Indikatoren erkennen? Es erfordert vielleicht ein sehr ausgeprägtes Feingefühl für Menschen und Worte, aber zum Erkennen dieser Indikatoren muss man lediglich beobachten und

zuhören.

Bei der Aussage „so gut wie fertig“ sollten jedem Projektleiter und jeder Führungskraft die Antennen hochgehen. Schröder versäumt es hier sträflich, Klarheit zu schaffen. Er müsste so lange nachfassen, bis ihm der Sachverhalt klar ist, oder bis er Anhaltspunkte dafür erhält, dass Taucher covert. Das erkennt er hier nicht. Taucher wiederum entzieht mit seinem Verhalten Schröder jegliche Chance, steuernd einzugreifen und zu handeln. Eventuell hätte Schröder aus seinem Netzwerk jemanden gekannt, der sich mit dieser Open-Source-Software hervorragend auskennt! Diese Chance hat Taucher vertan und das Beispiel zeigt, wie nahe Covern und Sabotieren letztlich beieinander liegen. Im Abschnitt „Maßnahmen gegen Vertuschung, Lügen, Sabotieren“ wird gezeigt, wie man mit diesen höchst gefährlichen Projektkillern umgehen kann.

www.hessen-it.de

Zusammenfassung des Notfalls „Geheimniskrämerei“ Fassen wir zusammen: Auch im vierten Akt unseres Stückes lassen sich Indikatoren für eine heraufziehende Not identifizieren. a Taucher kann sich immer wieder herausreden, weil Schröder keine Projektplanung macht. Er nutzt dabei Schröders Gutmütigkeit schamlos aus. Abhilfe schafft der Abschnitt „Eine Projektplanung

aufsetzen“. a Schröder steuert sein Projekt nicht, sondern sein Projekt treibt ihn – und wir vermuten, bald in den Abgrund. Im Abschnitt „Grundlagen

für eine praktikable Projektsteuerung“ wird gezeigt, welcher Mechanismus der Projektsteuerung zu Grunde liegt. a Große Gefahr droht, wenn Informationen zurückgehalten werden, gelogen oder gar sabotiert wird. Im Abschnitt „Maßnahmen gegen

Vertuschen, Lügen, Sabotieren“ wird gezeigt, wie man mit diesen gefährlichen Projektkillern umgehen kann.

NOT a Mangelhafte Projektplanung a Unzureichende Projektsteuerung a Vertuschung, Lügen, Sabotage

HILFE a Eine Projektplanung aufsetzen a Grundlagen für eine praktikable Projektsteuerung a Maßnahmen gegen Vertuschung, Lügen, Sabotieren

Vierter Akt – Geheimniskrämerei in der Entwicklung

Eine Projektplanung aufsetzen – Maßnahmen für gutes Projektmanagement Schröder hat keine Projektmanagementausbildung erhalten, sonst würde er nicht diesen Kardinalfehler begehen, zusätzlich zu seinen Projektmanagementaufgaben auch noch die Aufgaben von Taucher zu übernehmen. In aller Regel ist das ein Anfang vom weniger guten Ende eines Projekts. Solche Fehler münden oft in eine Überlastung der Projektleiter, ein Aufstauen von unerledigten Aufgaben und letztlich in Krankheit bis hin zum Zusammenbruch des Projektleiters. Genau so wenig wie ein guter Fußballspieler ohne Ausbildung gleich zu einem guten Fußballtrainer wird, wird auch ein guter Entwickler durch den Akt der Ernennung zu einem guten Projektleiter. Eine Ausbildung ist unverzichtbar. Dazu gehören zwei wesentliche Bereiche. Die Projektmanagement-Ausbildung und die Managementausbildung. Ersteres ist die Basis und man kann sie sich relativ schnell aneignen. Letzteres befähigt aber erst, die Projektmanagementkenntnisse in der Praxis erfolgreich anzuwenden, d. h. die richtigen Werkzeuge und Methoden zur richtigen Projektsituation im richtigen Maß einzusetzen und dabei den beteiligten Personen Rechnung zu tragen.

Zur Projektmanagement-Ausbildung gehören: a Projektmanagementsysteme Viele wollen darunter eine Projektmanagement-Software verstehen. Es wäre ja auch so schön, könnte man beides gleichsetzen. Aber tatsächlich ist und bleibt eine Software eine Computer-Anwendung und nichts anderes. Ein Projektmanagementsystem ist eine die Beteiligten verpflichtende Vorgehenssystematik, ein Verhaltenskodex und Kontrollsystem für die Dauer des Projekts. Ein solches System kann, von sehr wenigen Ausnahmen abgesehen, nicht von der Stange gekauft werden, sondern muss die Individualität des Unternehmens berücksichtigen.

www.hessen-it.de

a Projektmanagementmethoden Jede Projektmanagementmethode hat ihre Vor- und Nachteile. So ist etwa eine agile Methode, wie z. B. Scrum, für Softwareentwicklungen meistens dann passend, wenn der Anteil der noch völlig unbekannten Realisierungsverfahren eher hoch ist. Sind hingegen die vorhandenen Verfahren in ähnlicher Art und Weise bereits vorhanden, bietet sich die klassische Wasserfallmethode an. Dazwischen liegt ein breites Spektrum von bekannten Projektmanagementmethoden. Gute Projektleiter halten sich nicht sklavisch an die vorgegebene Methode, sondern passen sie in Teilbereichen an und nutzen z. B. parallel auch andere, für Teilbereiche effizientere Methoden. a Projektmanagementwerkzeuge Man kann mit einer Nagelschere einen Rasen schneiden. Ab einer gewissen Größe ist dieses Werkzeug aber nicht mehr effizient und eine Rasenschere, ein Handmäher oder ein Motormäher wäre weitaus geeigneter. Ähnlich verhält es sich auch mit der Wahl der passenden Werkzeuge für das Projektmanagement. Oft wird allerdings die Wirkung einer komplexen Projektmanagementsoftware überschätzt und der Aufwand zum Erlernen dieser Werkzeuge unterschätzt. In der Praxis führt das nicht selten zum Einsatz von überdimensionierten Projektmanagementwerkzeugen, wo Excel und Word die weitaus bessere Lösung gewesen wären.

Eine Management-Ausbildung kann helfen a Personalführung Ein Projektleiter ist eine Führungskraft auf Zeit. Ihm obliegen alle auch in der Linie notwendigen Personalthemen: angefangen bei Personalgesprächen, Probezeitvereinbarung, -bewertung und -beendung über Entgeltfindung, Zielvereinbarung, -bewertung und -vergütung bis zu Verantwortungs- und Kompetenzregelung und Weiterem mehr. Für Projektleiter gibt es zusätzlich die Problematik einer verteilten Zuständigkeit, oft innerhalb einer Organisationsmatrix. Projektleiter sollten deshalb ein gutes Maß an Führungs-Know-how haben.

Vierter Akt – Geheimniskrämerei in der Entwicklung

a Teambildung In der Linienorganisation haben Menschen gewöhnlich mehr Zeit, sich aneinander zu gewöhnen und sich zu finden, als in Projekten. Projekte verlangen von den Menschen, sich für kurze Zeit mit neuen Menschen und damit „Unbekannten“ zu arrangieren. Ein fundiertes Know-how in Teambildungsmethoden und -techniken reduziert potenzielle Fehler bei der Teambildung und der Teamumgestaltung. a Konfliktmanagement Auf Grund der höheren Anforderungen in Projekten gegenüber der Linienorganisation bauen sich Spannungen auf, die zu Konflikten zwischen den Projekteilnehmern führen können. Die Konflikte haben verschiedene Ursachentypen, die es zu erkennen gilt, um den Konflikt einer Lösung zuzuführen. Ebenso wichtig ist eine Strategie zur potenziellen Konfliktvermeidung. a Persönlichkeitsentwicklung Ein Projektleiter hat als einzelne Person „über“ sich Kunden und Chefs und „unter“ sich das gesamte Projektteam. Die Position ist also eine singuläre und sehr exponierte. Ein Projektleiter benötigt eine gute Portion Standfestigkeit, um sich sowohl mit den Anforderungen der Kunden und des Managements als auch mit den Anforderungen der Projektmitarbeiter gleichermaßen auseinanderzusetzen. Er muss täglich mit widersprüchlichen Zielen umgehen und sollte deshalb möglichst stabil in sich selbst sein. a Erfahrung … ist letztlich durch nichts zu ersetzen außer durch Erfahrung. Holen Sie sich einen „alten Hasen“ mit an Bord.

www.hessen-it.de

Rettungsanker Projektplanung Es ist noch kein Meister von Himmel gefallen, darum empfehlen wir: a Projektmanagement-Ausbildung a Managementausbildung

Vierter Akt – Geheimniskrämerei in der Entwicklung

Grundlagen für eine praktikable Projektsteuerung Regelkreis Da sich die Welt in ihrer unergründlichen Vielfalt einfach nicht immer an unsere Planungen hält, und sei es, dass Murphy die Finger im Spiel hat, müssen Projektplanungen kontrolliert und Maßnahmen gegen Planabweichungen ergriffen werden um die Projektziele innerhalb der verfügbaren Zeit und des verfügbaren Budgets zu erreichen. Der folgende sich grafisch immer weiter aufbauende Regelkreis zeigt auf, wie der Projektregelkreis funktioniert und wie man steuernd in den Projektablauf eingreift. Unabhängig von der gewählten Projektmanagementmethode legen wir folgende vereinfachte Form des zeitlichen Ablaufs (Projektphasen) eines Projektes zu Grunde, die für die Darstellung des Regelkreises ausreicht.

Projektdefinition

Projektdurchführung

Projektabschluss

Entlang dieser drei Projektphasen werden wir jetzt den Regelkreis sozusagen installieren.

Wie will man ein Projekt steuern, wenn man keinen Plan hat? In den Projektplan fließen alle relevanten Informationen wie Ziele, Budget, Ressourcen, Materialien usw. ein. Das Mengengerüst liefert Basisgrößen, welche ebenfalls in die Projektplanung einfließen. Wird auf ein Mengengerüst verzichtet, kann es leicht sein, dass man ein Projekt deutlich über- oder unterdimensioniert.

www.hessen-it.de

Projektplanung

Mengengerüst

Projektdefinition

Projektabschluss

Projektdurchführung

Die Ergebnisse der Planung fließen als initiale Stellgröße in die Projektdurchführung ein.

Die Projektdurchführung verläuft allerdings selten wie geplant. Deshalb führt die Projektkontrolle laufend einen Abgleich zwischen den von den Mitarbeitern und Systemen gelieferten Ist-Werten mit denen vom Projektplan gewollten Soll-Werten durch.

Soll

Projektplanung

Mengengerüst

Projektdefinition

Projektkontrolle (Soll/Ist-Vergleich)

Soll

Ist

Projektdurchführung

Projektabschluss

Doch die beste Überwachung nützt nichts, wenn festgestellte Abweichungen keinen Einfluss auf die Projektdurchführung haben.

Vierter Akt – Geheimniskrämerei in der Entwicklung

Und tatsächlich, in der Praxis machen viele Projektleiter Projektpläne und verankern sogar zugehörige Kontrollmechanismen, aber sie greifen nicht steuernd in den Projektablauf mit Gegenmaßnahmen ein, um das Projekt wieder auf Kurs zu bringen. Warum ist das so? Gründe gibt es viele. Oft spielt die Angst vor den Konsequenzen eine sehr große Rolle, obwohl diese in der Regel weit geringer sind, als sie es werden, wenn sich das Projekt ohne Steuerung weiter von der Planung entfernt.

Soll

Projektkontrolle (Soll/Ist-Vergleich)

Projektplanung

Änderungen Abweichungen Mengengerüst

Soll

Projektsteuerung

Ist

Maßnahmen

Projektdefinition

Projektdurchführung

Projektabschluss

Jedes Projekt bietet reichlich Früchte, die leicht zu ernten sind oder aber vertrocknen.

Ob gutes oder schlechtes Projekt: Die gemachten Erfahrungen, Erkenntnisse über die Dauer, den Aufwand bestimmter Teilaufgaben oder Prozesse und vieles andere mehr werden nur sehr selten gerettet. So starten oft neue Projekte im gleichen Umfeld, begehen die gleichen Fehler, erhalten wieder keine Antwort auf bereits gestellte und beantwortete Fragen. Die Autoren empfehlen deshalb dringend, die gemachten Erfahrungen zur Verbesserung von Folgeprojekten zu retten. Der Aufwand lohnt sich.

www.hessen-it.de

Soll

Projektkontrolle (Soll/Ist-Vergleich)

Projektplanung

Änderungen Abweichungen Mengengerüst

Soll

Projektsteuerung

Ist

Messdaten

Maßnahmen

Projektdefinition

Projektdurchführung

Projektabschluss

Rettungsanker Projektsteuerung Kein Projekt verläuft wie geplant, deshalb muss korrigierend eingegriffen werden. a Zur Projektplanung gehört auch die Projektkontrolle. a Bei Planabweichungen Maßnahmen zur Korrektur ergreifen. a Gemachte Projekterfahrungen für Folgeprojekte retten.

Vierter Akt – Geheimniskrämerei in der Entwicklung

Maßnahmen gegen Vertuschung, Lügen, Sabotieren Kein Mensch macht absichtlich Fehler. Denn macht er absichtlich Fehler, ist es ja eigentlich kein Fehler mehr, sondern er tut das, was er vorhatte, also das Richtige. Trotzdem und leider passieren Fehler immer wieder, denn wir sind Menschen und keine Maschinen, und selbst die machen Fehler.

Wirklich erfolgreiche Projekte haben immer eine fehlertolerante Kultur. Menschen in solchen Projekten haben gelernt, dass der Nachteil der unangenehmen Fehlerveröffentlichung letztlich weitaus geringer zu werten ist als der durch die frühe Fehlerbehebung erzielte Vorteil. Deshalb sind Projekte mit einer fehlertoleranten Kultur bei weitem erfolgreicher als Projekte mit verdeckten Fehlern, die sich zu unkalkulierbaren Risiken addieren. Und es gibt einen weiteren, ebenso wichtigen Grund für eine fehlertolerante Kultur. Das Arbeiten in fehlertoleranten Projekten ist deutlich vertrauensvoller, angenehmer und stressfreier als in Projekten, in denen gecovert, gelogen und sabotiert wird.

So ist Covern (Vertuschen) zu verhindern a Vertrauensvorschuss geben Menschen nähern sich unbekannten Menschen, und die treffen wir in Projekten vorwiegend, vor allem vorsichtig. Da siegt der Selbstschutzinstinkt in uns. Als Chef und Projektleiter gibt es nur einen Weg, die Distanz zu verringern, indem wir jedem zunächst einen Vertrauensvorschuss geben, statt der üblichen Portion Misstrauen. Dadurch kann man einige Menschen ermutigen, sich anstatt zu covern eher der Offenlegung von Fehlern und Versäumnissen hinzuwenden.

www.hessen-it.de

a Fehlertoleranz vorleben Eine fehlertolerante und transparente Kultur kann man leider nicht einfach verordnen und in Kraft setzen. Es gibt nur einen Weg sie zu erlangen: indem man sie aktiv vorlebt. Dieser Prozess funktioniert nicht bottom up sondern nur top down. Die Manager sind also gefragt. Erfahrene Praktiker geben deshalb, sozusagen exemplarisch, ihre eigenen Fehler und Versäumnisse wie „Termin vergessen“, „Ausarbeitung nicht rechtzeitig fertig gemacht“ etc. in Meetings zu, entschuldigen sich und gehen zur Sache, sprich zur Fehlerbehebung, über. Die Teilnehmer lernen dann sehr schnell. a Die Sache kritisieren, nicht den Menschen Wenn jemand die Reife und die Kraft besitzt, einen Fehler nicht zu vertuschen, sondern offen zu legen, dann muss man ihm dafür zunächst Respekt zollen. Denn es ist wahrlich nicht einfach zuzulassen, dass jetzt alle wissen, wer den Fehler gemacht hat. Deshalb ist definitiv zuerst für diese menschliche Leistung der ehrliche Respekt auszusprechen und anschließend die Sache, also der Fehler zu kritisieren, mögliche Maßnahmen zur Behebung und ggf. zur weiteren Vermeidung zu erarbeiten. a Andere Meinungen respektieren Viele Manager glauben, ihr Ziel am schnellsten zu erreichen, wenn sie möglichst schnell Entscheidungen treffen und diese pushen. Unsere fernöstlichen Kollegen haben längst erkannt und verankert, dass gerade in der Projektanfangsphase viele Sichten aus mehreren Blickwinkeln die Entscheidungsqualitäten erheblich verbessern. Dabei kommt es gar nicht darauf an, dass eine Meinung oder eine Idee ausgegoren und perfekt geschliffen vorgetragen wird, sondern eher auf die Menge der Möglichkeiten, aus denen man dann die gemeinsame und bessere Lösung konstruieren kann. In solchen Umgebungen wird jeder Beitrag respektiert. Dadurch verlieren die Menschen die Angst, selbst Beiträge zu liefern, und engagieren sich deutlich besser.

Vierter Akt – Geheimniskrämerei in der Entwicklung

a Kontrolle als positives Instrument Eine hohe Stufe der Unternehmenskultur hat man erreicht, wenn das Team Kontrollen mit dem Ziel verankert, Fehler möglichst frühzeitig aufzuspüren und zu beseitigen. Wenn keine Angst mehr da ist, dass ein eigener Fehler durch eine Kontrolle aufgespürt wird, sondern die Freude über das frühzeitige Erkennen überwiegt, befinden Sie sich in einem sehr guten Projektteam. In solch einer Umgebung leisten durchschnittliche Menschen mit Freude und Spaß deutlich mehr als ein Projektteam bestehend aus verängstigten Spitzenkräften.

Lügen haben kurze Beine … a Den Sachverhalt klarstellen Nach vielen Statistiken lügt jeder Mensch jeden Tag. Hier wollen wir aber nicht die große Menge der Halbwahrheiten, die vorwiegend der Selbstdarstellung dienen, betrachten, sondern Lügen, welche den Sachverhalt in einem Projekt falsch darstellen und sich deshalb negativ auf das Projekt auswirken oder auswirken können. Wird ein Projektbeteiligter beim Lügen erwischt, so ist es wichtig, nicht den Menschen zu kritisieren, sondern den Sachverhalt klar zu stellen. Dem überwiegenden Teil der Betroffenen dürfte das peinlich genug sein, und es bedarf keines weiteren Wortes über die Lüge an sich und schon gar nicht coram publico. a Lügnern nicht glauben, Aussagen sachlich überprüfen Leider gibt es auch notorische Lügner. Solchen Menschen sollte man, ohne den Menschen selbst damit negativ zu bewerten, sachlich grundsätzlich nicht mehr glauben. Auch mit solchen Menschen kann man, wenn es sein muss, zusammenarbeiten. Die Zusammenarbeit ist dann zwar weniger effizient, aber es ist möglich. Man muss dann allerdings jede Aussage sachlich überprüfen. Mögliche, aus einer Lüge resultierende sachliche Konsequenzen wie Kostenerhöhung, Zeitverzögerung etc. sollten schriftlich fixiert werden und dem Lügner aufgezeigt werden. Konsequenzen sind dann ggf. möglich.

www.hessen-it.de

Saboteure müssen gehen a Projektsaboteure konsequent entfernen Es gibt auch echte Projektsaboteure, sogar mehr als man zunächst glauben möchte. Sie kommen aus allen Hierarchieebenen. Oft sind es frustrierte Menschen, die sich nach und nach weit vom Normalverhalten entfernt haben. Sie schädigen das Projekt und das Unternehmen durch verschiedene Verhaltensweisen wie Informationszurückhaltung (z. B. Fristen verstreichen lassen, Lösungen zurückhalten), Informationsverfälschung (z. B. falsche Statusmeldungen, Codemanipulationen), Formierung von Projektgegnerschaften und vieles mehr. Nach der praktischen Erfahrung der Autoren kann man solche Menschen nicht zur Veränderung bewegen. Es gibt deshalb nur den Weg der Veränderung: Der Projektsaboteur hat nichts mehr im Dunstkreis des Projekts zu suchen.

Rettungsanker So kann man Vertuschung, Lügen und Sabotage begegnen: a Fehlertolerante Atmosphäre schaffen a Sachverhalte klarstellen und Aussagen sachlich überprüfen a Saboteure aus dem Team entfernen

Schröder plant nicht, kontrolliert nicht und er greift nicht steuernd ein, wenn sein Projektschiff in unruhiges Wasser gerät. Darüber hinaus hält seine Mannschaft wahre Beweggründe zurück. Das folgende Treffen mit Van Hopp lässt nichts Gutes erahnen.

Fünfter Akt – Statusbericht beim Kunden

Fünfter Akt Statusbericht beim Kunden

Dr. Krott und Schröder sitzen im Büro von Van Hopp bei Ex & Hopp. Die Begrüßung verläuft kühl, Van Hopp scheint gereizt.

Van Hopp (leicht ungehalten): „So, die Herren, kommen wir gleich zur Sache. Wir müssen dringend über die Anbindung und den Prototypen sprechen. Unser Marketing beginnt schon mit der Werbekampagne, und wir haben immer noch keine funktionierende Anbindung zu Ihrer SPÜFI-Plattform! Dieser Prototyp ist eine einzige Katastrophe, er stürzt dauernd ab und beinhaltet nicht mal die Hälfte der vereinbarten Funktionen. Zudem sind viele Funktionen schlichtweg falsch umgesetzt. Wie stellen Sie sich das vor?“

Dr. Krott (blickt ernst und mit gerunzelter Stirn): „Schröder, sagen Sie was dazu.“

Schröder (klammert sich an die Ausdrucke seines Statusberichtes): „Herr Van Hopp, wir haben Ihnen, wie vereinbart, einen Vorab-Prototypen gegeben, damit Sie schon mal erste Tests durchführen können. Dieser Prototyp kann natürlich noch nicht alle Funktionen beinhalten oder völlig fehlerfrei sein, das ist doch klar.“

www.hessen-it.de

Van Hopp (leicht überheblich und recht ungehalten): „Schröder, da sind Funktionen drin, die haben wir gar nicht bestellt. Und andere Funktionen, die wir dringend bräuchten, fehlen einfach. Und der Rest besteht nur aus Fehlern und stürzt ständig ab. Das ist kein Prototyp, das ist eine Katastrophe.“

Schröder (klammert sich noch mehr an seinen Statusbericht): „Das kann ich so nicht ganz stehen lassen, Herr Van Hopp. Die SPÜFI-Funktionen wurden alle mit Ihren Abteilungsleitern abgesprochen. Trotzdem gab es sehr viele Nachforderungen gegenüber der ursprünglichen Planung. Das ist der Grund, warum wir noch nicht alle gewünschten Funktionen fertig gestellt haben.“

Van Hopp (blickt Schröder sehr ernst an, lässt einen Stift zwischen zwei Fingern wippen und wendet sich zu Dr. Krott): „Das ist mir egal. Wir haben einen Pauschalpreis vereinbart, und da müssen Sie einfach alle Funktionen einbauen. Dr. Krott, tun Sie lieber was, um das Projekt – wie vereinbart – rechtzeitig fertig zu stellen, sonst sehe ich hier schwarz. Denken Sie dabei an den Passus zur Konventionalstrafe.“

Fünfter Akt – Statusbericht beim Kunden

Dr. Krott (kann seine Nervosität nur schwer unterdrücken): „Ja, ja, Herr Van Hopp. Sie haben ja völlig Recht. Wir kriegen das wieder hin. Ab morgen werden wir alle Ressourcen ausschließlich für Ihr Ex & Hopp-Projekt arbeiten lassen.“

Van Hopp (lehnt sich innerlich grinsend entspannt zurück und denkt, wie wunderbar diese Situation ist. Ich muss ‚die Krotts‘ nur machen lassen, das werden sie sowieso nicht mehr schaffen. Und wenn doch, finden wir schon irgendwelche Fehler, was das Projekt unterm Strich in jedem Fall noch günstiger macht): „So stelle ich mir professionelle Zusammenarbeit vor, Krott. Genau so, hervorragend. Sie verstehen mich, das wusste ich. Gut, so schnell kann man die wichtigen Dinge regeln, dann wünsche ich Ihnen noch einen schönen Tag!“

Van Hopp, wir erinnern uns, ein typischer „Über-den-Tisch-Zieher“, brilliert. Dr. Krott und Schröder sind ihm nicht gewachsen, lassen sich von ihm gnadenlos in die Ecke treiben und letztlich stimmt Dr. Krott sogar bedingungslos den Forderungen von Van Hopp zu. Leider sind ähnlich ablaufende Besprechungen zwischen Kunde und Dienstleister in der Praxis keine Seltenheit. Ohne Dr. Krott und Schröder entlasten zu wollen, muss man doch feststellen, dass die Van Hopps dieser Welt beträchtlichen Schaden bei Dienstleistern anrichten können. Dabei muss das nicht sein.

www.hessen-it.de

Mangelhafte Kommunikation mit dem Kunden Was geschah? Analyse der Ereignisse – Indikatoren für die heraufziehende Not Van Hopp: „Schröder, da sind Funktionen drin, die haben wir gar nicht bestellt … “ Schröder: „ … Die SPÜFI-Funktionen wurden alle mit Ihren Abteilungsleitern abgesprochen. Trotzdem gab es sehr viele Nachforderungen gegenüber der ursprünglichen Planung …“ Werden sachliche Inhalte aufgrund fehlender Diskussionsgrundlagen und Nachweise vermehrt auf einer emotionalen (statt sachlichen) Ebene geführt, sind dies eindeutige Indikatoren für mangelhafte

Kommunikation. Wie lassen sich diese Indikatoren erkennen? Gerade in diesem Fall ist es recht naheliegend, zum Erkennen dieser Indikatoren muss man lediglich beobachten und zuhören.

Schröder kommt seiner Aufgabe als Projektleiter wieder einmal nicht nach. Es ist definitiv seine Aufgabe, für eine nachvollziehbare Kommunikation mit dem Kunden zu sorgen. Absprachen mit den Abteilungsleitern hätten zwingend schriftlich festgehalten und kommuniziert werden müssen. Zusätzliche Anforderungen hätten ebenso schriftlich fixiert, analysiert, bewertet und zur Entscheidung vorgelegt werden müssen. Wie man Missverständnisse und Fehlinterpretationen vermeiden kann wird im Abschnitt „Maßnahmen für eine bessere Kommunikation mit dem

Kunden“ aufgeführt.

Fünfter Akt – Statusbericht beim Kunden

Mangelhafte Angebote / Verträge Was geschah? Analyse der Ereignisse – Indikatoren für die heraufziehende Not Van Hopp: „ … Wir haben einen Pauschalpreis vereinbart, und da müssen Sie einfach alle Funktionen einbauen. … Denken Sie dabei an den Passus zur Konventionalstrafe.“ Dr. Krott: „ … Sie haben ja völlig recht. Wir kriegen das wieder hin.“ Wenn in kritischen Situationen unspezifische Anforderungen zum moralischen Druckmittel avancieren, sind dies eindeutige Indikatoren für kritische Angebote und Verträge. Wie lassen sich diese Indikatoren erkennen? Gerade in diesem Fall trifft es nur teilweise den Kern, denn zum Erkennen dieser Indikatoren ist neben dem Beobachten und Zuhören vermutlich auch ein wenig aufmerksames Lesen notwendig.

Dr. Krott hat versäumt, die Basis der Kundenerwartungshaltung im Vertrag mit Ex & Hopp möglichst genau festzuhalten sowie dedizierte Punkte unter Angabe eines gemeinsamen Findungsverfahrens als offen zu beschreiben. Durch seine Pauschalpreisvereinbarung und Schröders Versagen in der Dokumentation der Kundenbesprechungen gibt es kaum noch eine Chance für die Krott-Bank, Zusatzanforderungen bei Van Hopp geltend zu machen. Was zu guten Angeboten und Verträgen gehört wird im Abschnitt

„Ansätze zur Verbesserung von Angeboten und Verträgen“ aufgeführt.

www.hessen-it.de

Zusammenfassung des Notfalls „Statusbericht beim Kunden“ Fassen wir anhand des fünften Aktes zusammen: a Schröder versäumt es, eine nachvollziehbare Kommunikation mit dem Kunden zu pflegen und ermöglicht so unserem Schlitzohr Van Hopp, mit falschen Behauptungen Vorteile für sich herauszuschlagen. Abhilfe schafft der Abschnitt „Maßnahmen für eine bessere Kommunikation

mit dem Kunden“. a Dr. Krott hat durch den einseitigen Vertrag mit Ex & Hopp ein sehr hohes Projektrisiko generiert. Im Abschnitt „Ansätze zur Verbesserung

von Angeboten und Verträgen“ wird beschrieben, was man zum beiderseitigen Vorteil von Dienstleister und Kunde in Angeboten und Verträgen berücksichtigen sollte.

NOT a Mangelhafte Kommunikation mit dem Kunden a Mangelhafte Angebote und Verträge

HILFE a Maßnahmen für eine bessere Kommunikation mit dem Kunden a Ansätze zur Verbesserung von Angeboten und Verträgen

Fünfter Akt – Statusbericht beim Kunden

Maßnahmen für eine bessere Kommunikation mit dem Kunden Hier beschränken wir uns bewusst auf griffige praktische Maßnahmen zur Verbesserung der Kommunikation mit dem Kunden und behandeln nicht die große Palette der zur Kommunikation gehörenden Aspekte.

Projektorganisation a Ansprechpartner Bereits im Angebot, spätestens aber im Vertrag, sollten sowohl vom Dienstleister als auch vom Kunden themenbezogene Ansprechpartner definiert und die Ergebnisse schriftlich festgehalten werden. So gibt es auf jeder Seite zumindest einen autorisierten Ansprechpartner. a Protokolle Was für interne Projektmeetings gilt (vgl. S. 14 „Maßnahmen für eine professionelle Meetingvorbereitung“), gilt in besonderem Maße für Meetings mit Kunden und externen Teilnehmern. Besonders die Besprechungsprotokolle sind dem Kunden zur Kontrolle zu senden, oder besser noch, gemeinsam am Beamer zu erstellen. a Mündliche Vereinbarungen Mündliche Zusagen sind notwendig. Mündliche möglicherweise projektrelevante Vereinbarungen mit dem Kunden müssen aber schriftlich fixiert und dem Kunden zur Kontrolle vorgelegt werden.

www.hessen-it.de

a Keine Zusagen vor einer Prüfung! Mündliche Zusagen gefährden Projekte besonders dann, wenn sie zuvor nicht einmal einer groben Prüfung unterzogen wurden. Vereinbaren Sie einen wenigstens minimalen Change-Management-Prozess. Dieser kann aus einer einfachen Liste bestehen, in der alle Anforderungen gesammelt werden, die schriftlich oder mündlich formuliert worden sind. a Schriftliche Teilabnahmen mit Mängelberichten Projekte mit klassischer Phasenstruktur geraten oft zum Ende des Projekts in Not. Denn meistens befindet sich die Testphase am Ende eines solchen Projekts. Doch erst in der Testphase werden typischerweise vom Kunden einige Punkte als „anders gewollt“ erkannt. Dann allerdings ist es auf Grund der fortgeschrittenen Projektzeit oft zu spät für einen Heilungsprozess.

Wichtig ist deshalb die Vereinbarung von frühzeitigen Teilabnahmen. Dabei ist es besonders wichtig, jeden vom Kunden genannten Mangel schriftlich zu fixieren. So kann jede Änderung von noch nicht oder noch nicht korrekt realisierten Punkten klar erkannt und als Zusatzleistung verhandelt werden.

Rettungsanker Die Kommunikation mit dem Kunden verbessen: a Ansprechpartner definieren a Besprechungen mit dem Kunden protokollieren a Mündliche Zusagen vorher prüfen und schriftlich fixieren a Teilabnahmen vereinbaren

Fünfter Akt – Statusbericht beim Kunden

Maßnahmen für bessere Angebote / Verträge Risikoquellen erkennen a Prosaische Werbetexte ohne fachlichen Hintergrund gehören nicht in Verträge. Sie sind meist vieldeutig auslegbar und ein gefundenes Fressen für die Van Krotts dieser Welt. a „Wissenschaftliche“ Formulierungen, die nicht verstanden werden werden gerne benutzt, um Kompetenz auszudrücken. Letztlich hindern sie die Vertragspartner an einer übereinstimmenden Vertragsinterpretation. a Pseudojuristische Passagen ohne rechtliche Prüfung verschlimmbessern in aller Regel das gewollte Ergebnis. a Fehlende AGB kein Kommentar … a Vermeidung der Benennung von Risiken Ein Kardinalfehler. Gerade die bereits zu Beginn bekannten Risiken sollten benannt werden. In aller Regel führt dies zu beiderseitigen Anstrengungen, diese zu verhindern, was wiederum dem Projekt zu Gute kommt. a Keine prüfbaren Zwischenergebnisse a Keine Mitwirkungspflicht des Auftraggebers Dr. Krott würde es freuen, denn damit liegt die Schuld zunächst gänzlich beim Dienstleister. Von einer partnerschaftlichen Lösung kann unter solchen Bedingungen nicht mehr ausgegangen werden. Der Dienstleister aber wird Mittel und Wege suchen und finden, die Benachteiligung anderweitig wettzumachen. Dr. Krott würde sich wundern, wie kreativ Dienstleister diesbezüglich werden können. a Fehlende Abnahmeregelung Wird eine Abnahmeregelung bereits zu Beginn vereinbart, kann das Projekt auch tatsächlich enden. Erstaunlich? In der Praxis tröpfeln Projekte oft weiter, obwohl der wesentliche Kern längst erfüllt ist. Fast immer ein für beide Parteien nachteiliges Unterfangen. 88

www.hessen-it.de

Das sollte zu einem Angebot gehören a Beschreibung der Aufgabe a Bezugsdokumente a Darstellung der zu erbringenden Leistungen a Zwischen- und Endergebnis der Aufgabe

Rahmenbedingungen sollten festlegt werden a Abgrenzung des Angebots a Mitwirkungspflicht des Auftraggebers a Regelungen für die Zusammenarbeit und den Projektverlauf a Zeitraum des Projekts, Meilensteine a Änderungsverfahren

Kaufmännische Regelungen treffen a Preisangaben a Lieferung und Abnahmeregelung a Fälligkeiten und Zahlweisen

Rechtliche Aspekte berücksichtigen a Eintritt und Dauer der Gewährleistung a Zusatzverträge (Wartung und Unterstützung)

Fünfter Akt – Statusbericht beim Kunden

Kundenportfolio pflegen a Trennung von schlechten Kunden Es gibt leider Kunden mit einer wirklich schlechten Unternehmenskultur. Angebote und Verträge mit solchen Unternehmen sind keine Vereinbarungen zum gegenseitigen Nutzen, sondern Versuche einseitiger und manchmal hinterlistiger Vorteilsnahme. Doch aus stetiger Sorge um das scheinbare Unternehmensglück halten manche Unternehmen immer weiter an wirklich „schlechten“ Kunden wie Van Hopp fest. Solche Unternehmen halten den Spatz über Jahre weiter in der Hand, ärgern sich täglich über diese Kunden, hemmen ihre eigene Weiterentwicklung und trauern der Taube auf dem Dach nach. Unternehmen, die sich von schlechten Kunden getrennt haben, fragen sich meistens hinterher, warum sie das nicht schon früher getan haben. a Mitnahme entwicklungsfähiger Kunden Die allermeisten Kunden hingegen sind nicht schlecht, sondern sie sind einfach noch nicht so weit in ihrer Entwicklung wie Ihr Unternehmen. Nehmen Sie Ihre Kunden mit auf die spannende Reise Ihrer Unternehmensentwicklung. Lassen Sie Ihre Kunden daran partizipieren und nutzen Sie die Chance, aus einem Kunden einen guten Kunden werden zu lassen. a Akquisition von besseren Kunden Akquirieren Sie ganz bewusst Kunden mit einer besseren Unternehmenskultur. Nutzen Sie die besondere Chance von weiter entwickelten Kunden zu lernen, und verbessern Sie nach und nach Ihr Kundenportfolio. Verträge mit solchen Kunden sind geprägt von einer gegenseitigen Achtung, einer offenen Diskussion der Vor- und Nachteile beider Parteien zum Zwecke des gemeinsamen Vorteils.

www.hessen-it.de

Rettungsanker Die Kommunikation mit dem Kunden verbessern: a Risikoquellen identifizieren a Vollständiges Angebot, das Rahmenbedingungen, kaufmännische Regelungen und rechtliche Aspekte berücksichtigt a Passende Kunden – Kundenportfolio verbessern

Dr. Krott und Schröder haben bei Ihrem Kunden Van Hopp kläglich versagt und ihr Projekt weiter in arge Not gebracht. Aber, dieses Büchlein wäre nicht geschrieben worden, könnten unsere Protagonisten nicht doch

shironosov, istockphoto.com

noch eine Schippe drauf legen.

Sechster Akt – Risiken verdrängen

Sechster Akt Risiken verdrängen

Schröder geht mit einem aktuellen Ausdruck der Anforderungsliste zum Schreibtisch von Taucher.

Schröder (lächelt – wie so oft – unbeholfen): „Na Taucher, wie geht es unserer Anforderungsliste? Wie sieht es mit Beißers Wunsch nach Werbetexten auf den Auszügen aus?“

Taucher (blickt Schröder kritisch an): „Geht so. Das heißt, eigentlich geht es eben nicht so, wie ich mir das ursprünglich gedacht hatte. Es scheint, als lässt unser Datenmodell diesen Gimmick mit den Werbetexten nicht so einfach zu. Das müssten wir noch mal analysieren, ehe wir Beißer hier grünes Licht geben. Keine Ahnung, was sich sonst an ungeplanten Aufwänden dahinter verbergen könnte.“

Schröder (versucht, einen leichten Anflug von Panik zu unterdrücken): „Nein, nein, nein, nein, Taucher, das ist unmöglich. Keine Zeit, das geht nicht. Sie hatten mir doch heute Morgen noch gesagt, das sei alles kein Problem.“

Taucher (blickt Schröder immer noch kritisch an): „Ja, aber ausgerechnet bei diesen variablen Werbetexten auf den Kontoauszügen könnte es ein Problem geben. Ich bin davon ausgegangen, dass die Anforderungen alle vorliegen würden, als wir letzte Woche mit dem Datenmodell angefangen haben. Und das ist jetzt in Datenbank-Beton gegossen.“

www.hessen-it.de

Schröder (schaut Taucher verdutzt an): „Was? Moment. Wir werden Beißers Werbung nicht umsetzen können? Da müssen wir mit Beißer über dieses Risiko reden?!“

Taucher (blickt Schröder noch kritischer an): „Moment, Schröder, ich sagte ‚könnte‘. Mal nicht die Pferde scheu machen, wir haben hier genug Stress. Und über ungelegte Eier sollte man nicht reden. Wir fangen erst mal an, und wenn wir zur Werbung kommen, prüfen wir das noch mal. Das schafft uns eine Zeit lang Luft.“

Schröder (fühlt sich nicht wohl, als er sich reden hört): „Na gut, Taucher, ich verlasse mich da auf Sie, dass das mit der Werbung gut geht. Dann machen Sie einfach mal und Schwamm drüber.“

Schröder lässt sich einlullen, ignoriert schließlich die von Taucher genannten Risiken und hofft verzweifelt, mit der Vogel-Strauß-Methode alles im Griff zu haben. Aber diese Hoffnung bewirkt nur, dass das Projekt, falls die Risiken doch eintreten sollten, in arge Gefahr gerät.

Sechster Akt – Risiken verdrängen

Risiken werden nicht identifiziert und analysiert Was geschah? Analyse der Ereignisse – Indikatoren für die heraufziehende Not Taucher: „ … Es scheint, als lässt unser Datenmodell diesen Gimmick mit den Werbetexten nicht so einfach zu … Keine Ahnung, was sich sonst an ungeplanten Aufwänden dahinter verbergen könnte.“ Schröder: „ … Wir werden Beißers Werbung nicht umsetzen können? Da müssen wir mit Beißer über dieses Risiko reden?“ Taucher: „ … Moment, Schröder, ich sagte ‚könnte‘. Mal nicht die Pferde scheu machen.“ Wenn Projektrisiken besprochen, aber anstatt erfasst, analysiert und behandelt zu werden, klein geredet werden, ist das ein klarer Indikator für fehlendes Risikomanagement. Um solche Indikatoren erkennen zu können, genügt einfachstes

Beobachten und Zuhören. Halten Sie mal die Ohren in der Kaffeküche offen und fragen dann nach, wie mit dem Risiko umgegangen wird.

Viele Projektleiter gehen das Thema Risikomanagement, wie Schröder, nicht oder nur oberflächlich an, weil sie das Managen der Risiken mehr mit der Realität konfrontiert, als es ihnen lieb ist! Schröder vergibt die Chance, das von Taucher identifizierte Risiko aufzunehmen, gemeinsam Gegenmaßnahmen zu planen und arbeitet einfach auf gut Glück weiter. Doch das Glück hat auch Schröder nicht gepachtet. Früher oder später wird sein Risiko von gestern sein Problem von heute werden. Im Abschnitt „Risikomanagement als Teil des Projektmanagements“ wird gezeigt, wie man Risiken identifizieren und bewerten kann.

www.hessen-it.de

Zu Risiken werden keine Maßnahmen der Steuerung ergriffen Was geschah? Analyse der Ereignisse – Indikatoren für die heraufziehende Not Taucher: „ … Und über ungelegte Eier sollte man nicht reden. Wir fangen erst mal an, und wenn wir zur Werbung kommen, prüfen wir das noch mal. Das schafft uns eine Zeit lang Luft.“ Wenn Projektrisiken erkannt, aber anstatt Maßnahmen zu diskutieren die Risiken abermals klein geredet werden, ist das ein klarer Indikator dafür, dass zu Risiken keine Maßnahmen der Steuerung ergriffen werden. Um solche Indikatoren zu erkennen, genügt wieder einfachstes

Beobachten und Zuhören.

Risikomanagement gleicht einer Versicherung. So lange kein Schadenfall eintritt, scheint sie überflüssig. Wenn man im Auto ohne Ersatzreifen in abwegiger Gegend fährt, kann das gut gehen. Ein simpler Plattfuß jedoch beendet die Reise dann radikal. Die Wahrscheinlichkeit, dass ein Reifen platzen kann, ist hoch, die Gegenmaßnahme relativ simpel – man nimmt einen Ersatzreifen mit. Ähnlich verhält es sich im Projekt. Treten Projektrisiken ein, ohne dass es bereits vorgedachte/vorbereitete Gegenmaßnahmen gibt, reduzieren sich die Möglichkeiten dramatisch, einfach weil dann die Zeit fehlt. Dies führt dazu, dass Projekte aus relativ simplen Gründen in Not geraten und sogar scheitern. Zumindest erhöht sich aber der Entscheidungsdruck erheblich und an Stelle des Risikomanagements tritt dann meist ein Krisenmanagement. Im Abschnitt „Maßnahmen des Risikomanagements“ werden die grundsätzlichen Möglichkeiten zur Gegensteuerung aufgezeigt.

Sechster Akt – Risiken verdrängen

Zusammenfassung des Notfalls „Risiken verdrängen“ Fassen wir zusammen: Auch anhand des sechsten Aktes kann man wieder problemlos Indikatoren für die heraufziehende Projektnot erkennen. a Schröder hat keine Erfahrung mit Risikomanagement. Hier hilft

Risikomanagement als Teil des Projektmanagements. a Risiken zu kennen und nichts zu unternehmen ist fatal, aber leider oft normal. Wie es geht, zeigt „Maßnahmen des Risikomanagements“.

NOT a Es gibt kein Risikomanagement, Risiken werden nicht identifiziert und analysiert a Zu Risiken werden keine Maßnahmen der Steuerung ergriffen

HILFE a Risikomanagement als Teil des Projektmanagements a Maßnahmen des Risikomanagements

www.hessen-it.de

Risikomanagement als Teil des Projektmanagements Risikomanagement, auch Riskmanagement genannt, ist keine Option, sondern Bestandteil des Projektmanagements. Es beinhaltet die Erfassung und Auswertung, die Planung und die Durchführung der Risikogegenmaßnahmen sowie das Risikocontrolling. Ein Risiko kann positiv oder negativ vom Ziel abweichen. Dies bedeutet, dass ein Risiko als Gefahr oder Chance gesehen werden kann. Die Chancen und Risiken sollten in einem ausgewogenen Verhältnis zueinander stehen. Aber Gefahren, deren Eintrittswahrscheinlichkeit hoch sind, sollten schnellstmöglich identifiziert und mit Gegenmaßnahmen ausgeräumt werden. Die rechtzeitige, möglichst vollständige Identifikation von Risiken, die Risikominimierung und die Optimierung möglicher positiver Zielabweichungen ist das Ziel des Risikomanagements. Die Vorgehensweise beim Managen von Risiken erfolgt in drei Phasen.

Risiken identifizieren Die Risikoerfassung ist die systematische Risikoerhebung, die auf das Projekt und damit auf das Unternehmen einwirkt. Dafür müssen alle Projektarbeitspakete und Projektphasen, für die Risiken erwartet werden, berücksichtigt werden. Für die Identifikation der Risiken werden in der Praxis folgende Methoden angewandt:

Sechster Akt – Risiken verdrängen

Rettungsanker Risiken identifizieren a Mitarbeiterbefragung Durch die Mitarbeiterbefragung können viele Aspekte aus der täglichen Erfahrung am besten erfasst und eingeschätzt werden. Doch besteht dabei die Gefahr der Verfälschung durch psychologische Aspekte. a Prüflisten Systematische Erfassung der benötigten Informationen per Checklisten. a Dokumentenanalyse Risiken aus bereits vorhandenen Verträgen, Behördenbescheiden oder Planungsunterlagen sowie dem betrieblichen Rechnungswesen überprüfen. a Organisationsanalyse Risiken aus einer unzureichenden Aufbau- und Ablauforganisation erkennen. a Besichtigungsanalyse Besichtigung des realen Geschehens, der Arbeitsweise. a Beobachtung der externen Faktoren Z. B. durch Marktrecherchen und Technologierecherchen.

Die Risikoidentifikation ist ein laufender Prozess und keine einmalig zu bewältigende Aufgabe. Während der gesamten Projektlaufzeit ist es Aufgabe des Projektleiters, mögliche Risiken zu identifizieren und je nach Risiko Maßnahmen zur Ausräumung zu erarbeiten oder zu initiieren.

www.hessen-it.de

Risiken bewerten Hat man alle Risiken erfasst, werden sie jetzt nach ihrem Erwartungswert analysiert und klassifiziert. Die qualitative Bewertung beruht primär auf einer erfahrungsbezogenen und subjektiven Einschätzung und reicht oft aus. Die quantitative Bewertung beruht auf mathematisch-statistischen Methoden. Sind Eintrittswahrscheinlichkeit und Schadenshöhe eines Risikos auf Basis der objektiven Daten nicht ermittelbar, kann die Einstufung über eine qualitative Bewertung erfolgen. Beispielhafte Einteilung für Eintrittswahrscheinlichkeiten eines Risikos:

sehr wahrscheinlich wahrscheinlich möglich unwahrscheinlich / unmöglich Trägt man jetzt die Eintrittswahrscheinlichkeiten und die Schadenhöhen in eine Skala ein, könnte eine Risikomatrix so aussehen:

Schadenshöhe

1 000 000 € 100 000 € 10 000 € 1 000 € 0€ unmöglich

unwahrscheinlich

p hoher Handlungsbedarf p mittlerer Handlungsbedarf

möglich

wahrscheinlich

sehr wahrscheinlich

p geringer Handlungsbedarf p kein Handlungsbedarf

Sechster Akt – Risiken verdrängen

Jetzt wird der Handlungsbedarf klar, aber es fehlen noch die Angaben über die Bedeutung der Risiken selbst. Diese werden in Risikoklassen eingeteilt.

Risikoklasse A:

Die Risiken sind immens, und die Existenz des Unternehmens wird durch das Projekt bedroht, Projekt sollte sofort abgebrochen werden.

Risikoklasse B:

Eindeutige Überschreitung des geplanten Projektbudgets (i.d.R. über 50 %).

Risikoklasse C:

Signifikante Überschreitung des geplanten Projektbudgets (i.d.R. bis zu 30– 50 %).

Risikoklasse D:

Erheblicher Mehraufwand als geplant.

Risikoklasse E:

Geringerer Mehraufwand als geplant.

Zusammengeführt hat man nun eine gute Entscheidungsgrundlage, welche Risiken man bewusst hinnehmen möchte und gegen welche Risiken man etwas unternehmen möchte. Die Entscheidung, zu welchen Risiken letztlich Maßnahmen ergriffen werden oder nicht, ist ab einer entsprechenden Tragweite immer Aufgabe eines Projektlenkungsausschusses und keinesfalls eine einsame Entscheidung des Projektleiters so wie Schröder das macht.

Rettungsanker Risikomanagement ist Bestandteil des Projektmanagements a Risiken umfassend identifizieren a Eintrittswahrscheinlichkeiten der Risiken bewerten a Handlungsbedarf ermitteln a Risikoklassen zur Entscheidungsfindung zuordnen

100

www.hessen-it.de

Maßnahmen des Risikomanagements Nachdem die Risiken nach ihren Gefahrenstufen ausgewertet und klassifiziert wurden, werden Risikomaßnahmen geplant und ggf. umgesetzt. Dabei gibt es viele Wege, Risiken und damit die möglichen Gefahren zu umgehen.

Risikovermeidung Bei der Risikovermeidung müssten Sie i.d.R. auf risikoreiche Tätigkeiten verzichten. Durch diese konservative Haltung entstehen zwar keine Risiken, jedoch auch keine Gewinnchance. Je nach Unternehmenskultur und -strategie kann diese Maßnahme häufiger oder seltener berücksichtigt werden. Aus unserer Erfahrung können wir Ihnen empfehlen, diese Strategie nur auf einzelne Risiken bzw. nur in Ausnahmefällen anzuwenden und nicht etwa versuchen, das gesamte Risikoportfolio zu vermeiden.

Risikoverminderung Die Eintrittswahrscheinlichkeit und die Höhe des Verlustes soll mit der Risikoverminderung verringert werden. Diese Maßnahme wird bei quantifizierbaren Risiken durchgeführt. Der Katalog beschreibt, welche Risiken bis zu welcher Höhe eingegangen werden dürfen und wie diese Risiken zu behandeln sind.

Risikoüberwälzung Durch die Überwälzung werden die identifizierten, ausgewerteten und klassifizierten Risiken nicht verändert, sondern aus dem Projekt ausgelagert und an Dritte übertragen. Typische Beispiele sind Versicherungen oder externe Dienstleister.

101

Sechster Akt – Risiken verdrängen

Risikoakzeptanz Ist die Risikoreduzierung, -transfer und -überwälzung des Risikos nicht möglich, muss das Risiko akzeptiert werden. Wichtig ist dabei die bewusste Risikoakzeptanz. Doch Sinn macht sie nur dann, wenn der Nutzen, für den das Risiko eingegangen wird, höher als das Risikopotenzial ist. Erst dann ist die Strategie wirtschaftlich und sinnvoll eingesetzt.

Rettungsanker Risikomanagement als Chance: a Risiken vermeiden (konservativ und wenig gewinnbringend) a Risiken vermindern a Risiken auslagern a Risiken bewusst akzeptieren

Schröder dilettiert weiter, die tatsächlich im Projekt verborgenen und unbehandelten Risiken dürften immens sein und mehrfach dazu ausreichen, das SPÜFI-Projekt zu kippen. Aber geben wir ihm noch eine Gnadenfrist und schauen zu, was Dr. Krott aus dem Hut zaubert.

102

www.hessen-it.de

Siebter Akt Unerwartetes Projektreview

Seit dem Termin bei Van Hopp wird Dr. Krott das Gefühl nicht mehr los, dass Schröder sein Ex & Hopp-Projekt nicht richtig im Griff hat. Auf dem Golfplatz erzählt er seinem Golfpartner von seinen Sorgen. Der rät ihm – ohne weitere Erklärungen – zu einem Projektreview. Dr. Krott ist begeistert und schreitet am nächsten Tag zur Tat – er bittet Schröder in sein Büro.

Dr. Krott (sucht noch nach Worten, das Thema ‚Review‘ geschickt zu platzieren): „Guten Tag, Schröder. Wie steht es denn um das Ex & Hopp-Projekt? Das läuft doch, oder? Sie haben doch alles im Griff, oder?“

Schröder (ist von dem Einstieg in das Meeting überrascht, er fühlt sich plötzlich unvorbereitet und ertappt): „Tja, wir haben alles im Griff und kommen gut voran, aber da ist ja auch noch ‚0815‘.“

Dr. Krott: „Ja, ja, schon gut, Schröder, schon gut. Das müssen wir anders machen, Schröder, ganz anders. Wissen Sie was, ich habe da eine Idee, Schröder, die wird ihnen gefallen. Schröder (kurze, dramaturgische Pause), wir machen ein Projektreview, das wird Ihnen helfen. Danach werden Sie wissen, wo Sie stehen. Nichts großes, einfach nur ein Projektreview, Sie wissen ja, ganz einfach.“

Schröder (fühlt einen riesigen Berg an Arbeit über sich zusammenbrechen): „Herr Dr. Krott, wir sind mitten in der laufenden Programmierung zu SPÜFI und den Tests für das Projekt ‚0815‘, also mehr als ausgelastet. Wie stellen Sie sich das vor? Das ist einfach zu kurzfristig.“

103

Siebter Akt – Unerwartetes Projektreview

Dr. Krott (wird fordernd): „Schröder, das ist doch nur zu Ihrem Besten. Sie müssen doch wissen, wo es lang geht. Suchen Sie einfach die wichtigsten Unterlagen zusammen und erstellen Sie bis Anfang nächster Woche einen ordentlichen Reviewbericht. Dann schauen wir gemeinsam noch mal darüber.“

Schröder (fühlt sich unter diesem riesigen Berg an Arbeit begraben): „Das habe ich verstanden, aber wir müssen auch dringend mit SPÜFI und ‚0815‘ weiter machen … “

Dr. Krott (wird nachhaltig fordernd): „Schröder, das hat jetzt höchste Priorität, einfach machen, nicht lange fragen, liefern Sie alle Unterlagen für dieses Review. Sie schaffen das schon. Sie wollen doch nicht, dass wir so einen (lacht) teuren Prüfer einkaufen, oder? Ich vertraue Ihnen. Und wenn Sie dann wieder wissen, wo Sie stehen, dann wissen Sie auch wieder, wo es langgeht, Schröder. Auf Wiedersehen.“

Eine Woche später, nachdem Schröder seine Reviewergebnisse vor Dr. Krott und Beißer präsentiert hat:

Dr. Krott: „Was ist das denn bitte schön für ein katastrophaler Reviewbericht. Und erst der Aktionsplan. Total inakzeptabel, Schröder. Und das Gefasel von Projektmanagement. So geht das nicht.“

Beißer: „Ich hab’s ja schon immer gewusst. Der Schröder und seine Projektmitarbeiter, die werden das Projekt noch gegen die Wand fahren. Ich sag nur ‚Konventionalstrafe‘!“

104

www.hessen-it.de

Schröder: „Moment mal, es sind ja schon Ergebnisse rausgekommen. Und die Analyse hat nur so lange gedauert, weil ich das ganz allein machen musste. Taucher ist halt total überlastet.“

Dr. Krott: „Ich weiß nur, dass sich jetzt sofort was ändern muss, denn die Konventionalstrafe können wir uns nicht leisten. Für eine erneute Prüfung ist es jetzt auch schon zu spät. Wir stellen jetzt mal ganz fix eine Handvoll Mitarbeiter ein und dann stemmen wir das schon.“

Schröder: „Aber was ist mit den Ergebnissen des Reviewberichts? Sollten wir da nicht mal schauen, was man davon gebrauchen könnte?“

Dr. Krott: „Das bringt doch alles nichts, Schröder. Es steht ja nichts Konstruktives im Reviewbericht. Oder meinen Sie im Ernst, in der jetzigen Situation würde uns ein Projektmanagementsystem nützen? Und den Rest hätten Sie mir auch einfach sagen können.“ (Denkt: Schröder schafft´s nicht. Ich werd´ mich nach einem anderen Projektleiter umsehen müssen. Vielleicht Taucher!)

Dr. Krott spürt, dass sein Ex & Hopp-Projekt in arger Not ist – wir wissen es besser, es ist faktisch gescheitert. Ein Projektreview ist sicher eine gute Methode, um eine Standortbestimmung mit anschließender Erarbeitung von Korrekturmaßnahmen durchzuführen. Aber, Dr. Krott praktiziert wieder einmal nach dem Verfahren "blinder Aktionismus". Denn wie man ein zweckdienliches Projektreview angeht und umsetzt, davon hat er nicht den blassesten Schimmer und die Review-Ergebnisse missachtet er.

105

Siebter Akt – Unerwartetes Projektreview

Fehlende Projektreview-Grundlagen Was geschah? Analyse der Ereignisse – Indikatoren für die heraufziehende Not Dr. Krott: „Schröder, das ist doch nur zu Ihrem Besten. Sie müssen doch wissen, wo es lang geht. Suchen Sie einfach die wichtigsten Unterlagen zusammen und erstellen Sie bis Anfang nächster Woche einen ordentlichen Reviewbericht.“ Wenn ein Review von einem Projektleiter oder einem anderen Projektbeteiligten durchgeführt werden soll, ist das ein klarer Indikator für fehlende Projektreview-Grundlagen. Um diesen Indikator zu erkennen, genügt wieder einfachstes

Beobachten und Zuhören.

Je notleidender ein Projekt ist, desto stärker steigt das Bedürfnis nach Kontrolle im Management. Dr. Krott folgt dieser Regel konsequent. Und er glaubt tatsächlich, lediglich durch die Kenntnis des am Golfplatz gehörten Begriffs „Projektreview“ sein Ex & Hopp-Projekt wieder kontrollieren zu können. Es wäre ja auch zu schön. Aber selbst ohne die Betrachtung der Überlastungssituation von Schröder macht es definitiv keinen Sinn, dass Schröder sich sozusagen selbst überprüfen soll. Warum lassen wir Autoren unsere Texte wohl von Dritten überprüfen? Weil wir selbst blind für unsere eigenen Fehler sind. Aber Dr. Krott sieht nur die Kosten für externe Prüfer, scheut sie und vergibt dadurch abermals eine Chance. Welche Grundlagen zu einem erfolgreichen Projektreview gehören und welche weiteren Projektprüfverfahren es gibt, wird im Abschnitt „Projek-

treview-Basis schaffen“ gezeigt.

106

www.hessen-it.de

Mangelhafte Review-Planung Was geschah? Analyse der Ereignisse – Indikatoren für die heraufziehende Not Dr. Krott: „Wir machen ein Projektreview, das wird Ihnen helfen. Danach werden Sie wissen, wo Sie stehen. Nichts großes, einfach nur ein Projektreview, Sie wissen ja, ganz einfach.“ Wenn versucht wird, den Review-Aufwand noch vor der Planung klein zu reden, ist das ein Indikator, der eine mangelhafte Review-Planung erahnen lässt. Wie lassen sich diese Indikatoren erkennen? Wieder einmal dürfte klar sein, dass man zum Erkennen dieser Indikatoren lediglich

beobachten und zuhören müsste.

Dr. Krott drückt sich wieder einmal vor dem Führungskräfte-Dilemma. Führungskräfte stehen oft vor Entscheidungen, deren Konsequenzen, gleich welche Variante sie wählen, gleichermaßen unangenehm sind. But, that's the job! Was Dr. Krott versucht, gleicht der Quadratur des Kreises. Er will für ein hoch kritisches Projekt, in kürzester Zeit und möglichst ohne Geld eine optimale Entscheidungsbasis über das Review erhalten. Schröder hat keine Chance. Er wird unter diesen Bedingungen kein gutes Review planen und durchführen können, selbst wenn er wüsste, wie er was zu tun hätte. Uns geht es besser. Die wesentlichen Aspekte für eine gute ProjektreviewPlanung und Umsetzung werden im Abschnitt „Effiziente Projektreview-

Durchführung“ behandelt.

107

Siebter Akt – Unerwartetes Projektreview

Missachtung der Review-Ergebnisse Was geschah? Analyse der Ereignisse – Indikatoren für die heraufziehende Not Schröder: „Aber was ist mit den Ergebnissen des Reviewberichts? Sollten wir da nicht mal schauen, was man davon gebrauchen könnte?“ Dr. Krott: „Das bringt doch alles nichts, Schröder. Es steht ja nichts Konstruktives im Reviewbericht.“ Wozu der ganze Aufwand eines Reviews, wenn die erarbeiteten Maßnahmen missachtet und nicht umgesetzt werden? Ein klarer Indikator für Missachtung der Review-Ergebnisse. Auch dieser Indikator lässt sich ganz einfach durch Beobachten und

Zuhören erkennen!

Dr. Krott sollte das in argen Nöten befindliche Projekt unterstützten. Stattdessen zwingt er Schröder, der ohnehin schon übermäßig belastet ist, ein Review durchzuführen und erdreistet sich dann, die Ergebnisse mit einem Fingerschnipp vom Tisch zu wischen. Dr. Krott ist schon ein grottenschlechter Manager! Auch wenn Review-Ergebnisse nicht den eigenen Erwartungen entsprechen, sollten dennoch eigene Wünsche und Vorstellungen dem Wohl des Projekts und des Unternehmens untergeordnet werden. Aber das sind Unbekannte für Dr. Krott. Wie man erarbeitete Review-Ergebnisse optimal nutzt, wird im Abschnitt

„Auswertung und Umsetzung der Maßnahmen“ skizziert.

108

www.hessen-it.de

Falsches Prüfverfahren Was geschah? Analyse der Ereignisse – Indikatoren für die heraufziehende Not Dr. Krott: „Und das Gefasel von Projektmanagement. So geht das nicht.“ Dr. Krott: „ … Oder meinen Sie im Ernst, in der jetzigen Situation würde uns ein Projektmanagementsystem nützen?“ Die Prüfung des Projektmanagements ist nicht Gegenstand eines Projektreviews, sondern eines Projektaudits. Wird das verwechselt, ist es ein klarer Indikator für ein falsches Prüfverfahren. Und wieder ein Indikator, mühelos erkennbar durch Beobachten und Zuhören.

Schröder hat es sicher gut gemeint, und Dr. Krott hätte gut daran getan, zeitgleich mit dem Projektreview auch ein Projektaudit durchzuführen. Letzteres hätte aber – und wir wissen es ganz genau – von einem externen Auditor durchgeführt werden müssen. Für Dr. Krott wäre eine Menge auch ihn betreffende Mängel zu Tage gefördert worden. Weitere managementbezogene Projektprüfverfahren werden im gleichnamigen Abschnitt kurz vorgestellt.

109

Siebter Akt – Unerwartetes Projektreview

Zusammenfassung des Notfalls „Unerwartetes Projektreview“ Fassen wir zusammen: Auch im letzten Akt begegnen uns abermals leicht erkennbare Indikatoren, aus denen man die heraufziehende Projektnot ableiten kann. a Dr. Krott kennt nur den Begriff Projektreview. Was wirklich dahinter steckt, wird im Abschnitt „Projektreview-Basis schaffen“ gezeigt. a Schröder bekommt weder Zeit noch Unterstützung. Er hat keine Chance. Wir schon. Welche wesentlichen Aspekte zu einer „Effizienten

Projektreview-Durchführung“ gehören, wird im gleichnamigen Abschnitt vorgestellt. a Warum überhaupt ein Review, wenn die Ergebnisse dann mit einem Fingerschnipp verworfen werden? Ein guter Weg wird im Abschnitt

„Auswertung und Umsetzung der Maßnahmen“ skizziert. a Schröder hat es gut gemeint, aber Projektreview ist nicht gleich Projektaudit. Im Abschnitt „Weitere managementbezogene Projekt-

prüfverfahren“ wird der Unterschied erklärt. NOT a Fehlende Grundlagen für ein Projektreview a Keine Review-Planung, kein geordneter Reviewprozessablauf a Missachtung der Review-Ergebnisse a Falsches Prüfverfahren: Unterschied zwischen Projektreview und Projektaudit nicht bekannt

HILFE a Schaffen der Basis-Voraussetzungen für ein Projektreview a Eine effiziente Prüfplanung und -vorbereitung erstellen a Auswertung und Umsetzung der erarbeiteten Maßnahmen a Das richtige Projektprüfverfahren nutzen: Projektreview für die Inhalte, Projektaudit für die Prozesse und Projektretrospektive für zukünftige Verbesserungen 110

www.hessen-it.de

Projektreview-Basis schaffen Ein Projektreview ist ein Prüfverfahren, das dem Management regelmäßig Ergebnisse zum Projektstatus hinsichtlich der Einhaltung einer sach-, termin- und kostengerechten Projektabwicklung als Entscheidungsgrundlage liefert. Im Reviewplan werden die Prüfungen und die Prüfungsinhalte bereits während der Projektplanungsphase festgelegt und allen Beteiligten bekannt gemacht. Bei der Durchführung des Projektreviews werden externe Auditoren empfohlen, da sie – im Gegensatz zu Internen – nicht befangen sind bzw. sein sollten, nicht den Arbeitsprozessen des Projektes entzogen werden und über Projektreview-Know-How verfügen. Ein Projektreview dient jedoch nicht nur dem Auffinden von negativen, sondern soll auch die positiven Aspekte des laufenden Projekts aufzeigen. Hierzu zählen u. a. die Erfahrungen, die im Laufe des Projekts gesammelt wurden, wodurch die Durchführung von nachfolgenden Projektphasen oder Projekten effizienter gestaltet und so optimiert werden kann. Geplante und allen Projektbeteiligten im Voraus bekannt gemachte Reviews sind ausgezeichnete Verfahren, unabhängige Kontrollpunkte im Projektverlauf zu setzen. Bei einer sauberen Durchführung sind sie dem gesamten Projektteam ein Ansporn und fördern eine fehlertolerante Umgebung.

111

Siebter Akt – Unerwartetes Projektreview

Sonderfall: Unplanmäßiges Projektreview Kurzfristig ein ungeplantes Projektreview während einer Projektphase zu fordern, stört nicht nur den Projektablauf, sondern verunsichert und belastet auch die Projektmitarbeiter stark. Kurzum, besonders ungeplante Reviews kosten Geld und vor allem Zeit. Im Gegensatz zum geplanten Review sind leider ungeplante Projektreviews viel häufiger anzutreffen. So auch bei unserem Ex & Hopp-Projekt. In wirklich kritischen Projektsituationen haben sie dennoch ihre Berechtigung. Leider mutieren sie nicht selten zu einer unkontrollierten Mischung aus Projektreview und -audit, da es auf Grund dringender Probleme meistens nur eine ungenügende Vorbereitung gibt. Darunter leidet dann die Sensibilität, mit der das Review durchgeführt wird. Man kann das Gefühl eines ungeplanten Reviews in etwa mit dem Gefühl vergleichen, das wir bei einem unangekündigten Test in der Schule hatten. Und als erwachsene Menschen fühlen wir uns immer noch genauso in unserer Selbstbestimmtheit verletzt. Geplante Reviews hingegen gleichen geplanten Klausuren, auf die man sich vorbereiten kann. Um Kollateralschäden zu vermeiden, sollte deshalb, wenn schon ein ungeplantes Projektreview notwendig wird, unbedingt die Hilfe eines erfahrenen, externen Auditoren in Anspruch genommen werden.

Voraussetzungen für ein Projektreview a Klare Zielsetzung Genau wie mit den Projektzielen verhält es sich auch mit den Reviewzielen. Es sollte allen Beteiligten klar sein, was mit dem Projektreview erreicht werden soll und wo dessen Schwerpunkte liegen sollen.

112

www.hessen-it.de

a Prüfkultur Allen Beteiligten muss vermittelt werden, dass ein Projektreview ein konstruktives Forum ist und Schuldzuweisungen – wie sie Beißer vorbringt – völlig fehl am Platz sind (vgl. oben zum Thema fehlertolerante Kultur, Seite 76 ff). Aber ohne ein aktives Vorleben des Managements geht das nicht, und erfahrungsgemäß tun sich die Manager recht schwer damit. Die Mitarbeiter des Unternehmens spiegeln in aller Regel den Reifegrad des Managements wieder. So wundert es kaum, dass in Unternehmen ohne hinreichende Kultur Ergebnisse von Reviews oft nicht umgesetzt werden und am häufigsten schlicht der Projektleiter entlassen – wie es wohl auch Schröder ergehen könnte – und durch einen anderen ersetzt wird. Dem Projekt dient das in den wenigsten Fällen. a Quantifizierbare Anforderungen Wurden die Projektanforderungen nicht quantifiziert, kann ein Projektreview zwar den Status festhalten, aber kaum eine fundierte Aussage über die Qualität treffen. Leider wird das in vielen Reviews nicht beachtet und führt deshalb dazu, dass es dem Gutdünken der Prüfer obliegt, ein positives oder negatives Urteil zu fällen. Und leider richtet sich das Ergebnis manchmal auch danach, was der Vorstand bzw. Aufsichtsrat hören möchte. Zumindest, wenn es sich um Prüfer ohne Rückgrat handelt.

Rettungsanker a Eine Projektreview-Basis schaffen a Projektreview zur Prüfung der Projektzielerreichung a ungeplante Projektreviews nur in sehr kritischen Projektsituationen erwägen (dann möglichst sensibel und mit externen Auditoren, sonst drohen Kollateralschäden) a Projektreviewplan zu Beginn erstellen und allen bekannt machen

113

Siebter Akt – Unerwartetes Projektreview

Effiziente Projektreview-Durchführung Projektprüfplan Fest vordefinierten Projektreviews müssen in einem für alle Involvierten zugänglichen Prüfplan (Abb. unten) einsehbar sein, so dass sich alle Prüfbeteiligten jeweils adäquat vorbereiten können. Keinesfalls sollte man einen Projektmitarbeiter oder Projektleiter mit einer Prüfung einfach „überfallen“.

Projektdurchführung Projektbeginn

Analyse

Entwurf

Realisierung

Einführung

Projektende

Projekt-Controlling

Projektretrospektive Projektreview Projektaudit Projektabschlussbewertung … Geplant: Phasenende Geplant: Phasenmitte Ungeplant

Fiktiver Projektprüfplan

114

www.hessen-it.de

Projektreviewablauf Der Prozessablauf eines Projektreviews unterteilt sich in die fünf Phasen Planung, Vorbereitung, Durchführung, Analyse und Umsetzung (Abb. unten). Nach der Erfassung des aktuellen Status wird auf der Grundlage des resultierenden Reviewberichts den Entscheidungsträgern eine Ent-

Ergebnisse

Tätigkeiten

scheidungsgrundlage für das weitere Fortfahren im Projekt gegeben.

1. Phase

2. Phase

3. Phase

Mit den Beteiligten den Reviewablauf planen.

Reviewteam: – Erstellen der Fragen

1. Präsentation 2. Fragen 3. Risikoanalyse

Projektleiter: – Vorbereiten

Planung

Vorbereitung

Angaben über: – was – wann – wie – wo gemacht wird.

Reviewteam: – Fragebogen Projektleiter: – Projektunterlagen

4. Phase

5. Phase

Analyse der Unterlagen.

Modifizieren d. Projektplanung

Reviewbericht erstellen.

Checklisten erstellen.

Review

– Protokoll – Kopien der relevanten Unterlagen – Risikochart – usw.

Analyse

Reviewbericht

Umsetzung

– Modifizierter Projektplan – Arbeitsaufträge – Neue, geänderte Ergebnisse

Projektreview-Ablauf (5 Phasen). Quelle: Jenny, Projektmanagement in der Wirtschaftsinformatik

Effiziente Vorbereitungen Auf der Grundlage einer guten Planung und Vorbereitung kann die Durchführung des Projektreviews strukturiert und organisiert erfolgen. Etwa zwei Wochen Zeit sollten die Beteiligten dazu haben, um sich fachlich wie mental auf das Projektreview vorzubereiten. Die bis zum Prüfzeitpunkt nicht abgeschlossenen Aufgaben sind nicht Gegenstand der Prüfung.

115

Siebter Akt – Unerwartetes Projektreview

Rettungsanker Vorbereitende Aufgaben der Reviewbeteiligten a Moderator Der Moderator, z. B. der direkte Vorgesetzte des Projektleiters, informiert offiziell alle Beteiligten über das bevorstehende Projektreview. a Projektmitarbeiter Die Projektmitarbeiter bringen die Projektergebnisse auf den aktuellen Stand und übergeben diese in aufbereiteter Form der Projektleitung sowie den Auditoren (Gutachtern). a Projektleiter Der Projektleiter erarbeitet anhand der Informationen, die er durch seine Projektmitarbeiter erhält, eine zusammenfassende Präsentation über die aktuellen Projektergebnisse aus. a Auditoren Die Gutachter formulieren die Fragen, erstellen Checklisten auf der Basis von Leistungsdaten für das Projektreview. Die Auditoren müssen frei von persönlicher und institutioneller Befangenheit sein, daher meist extern besetzt. Im Vorfeld führen sie Interviews mit Projektauftragnehmer, -geber und Stakeholdern. Sie klären mit dem Auftraggeber die durchzuführenden Aufgaben und die erwarteten Ziele. Zu beachten ist: Werden Auditoren intern besetzt, kommen deren Aufgaben zusätzlich zur Projektarbeit hinzu. Vgl. Jenny, Projektmanagement in der Wirtschaftsinformatik, 2001, S. 385f

116

www.hessen-it.de

Planungs-Meeting – der Auftakt zum Projektreview Im Planungs-Meeting unterrichtet der Moderator alle Beteiligten über den Rahmen und Ablauf des bevorstehenden Projektreviews. Es werden für alle Beteiligten die Zielbestimmung und der Prüfgegenstand des Projektreviews klar aufgezeigt. Die folgenden Fragestellungen sollten dabei geklärt werden:

a Wer kontrolliert und wer wird kontrolliert? a Wann wird kontrolliert (Tag, Zeit)? a Wo wird diese Kontrolle durchgeführt (Ort)? a Was wird kontrolliert (Aspekte)? a Welche Ziele werden mit dieser Kontrolle verfolgt? a Wie stellt sich der Ablauf des gesamten Reviews dar? a Wer kann welche Reviewergebnisse einsehen? Vgl. Jenny, Projektmanagement in der Wirtschaftsinformatik, 2001, S. 386

117

Siebter Akt – Unerwartetes Projektreview

Prüfmethoden Anhand der erhobenen und sachlich bewerteten Informationen und Datensammlungen können Projektrisiken, -probleme und -trends identifiziert werden. Sie bilden später die Ausgangslage für die Erarbeitung korrigierender Maßnahmen und Empfehlungen. Bei der Informationsgewinnung unterscheidet man zwischen der Ermittlung und der Prüfung von sachbezogenen und beziehungsbezogenen Projektfaktoren. Die sachbezogenen Faktoren, auch „hard facts“ (z. B. Kennzahlen) genannt, sind dabei eindeutiger quantifizierbar. Für sie gibt es Analysewerkzeuge wie z. B. Soll-Ist-Vergleiche und Messgrößen wie z. B. Menschtage, Euro u.v.m.. Für die beziehungsbezogenen „Soft facts“ (z. B. Projektatmosphäre) gibt es keine Messgrößen. Darum müssen sie mit geeigneten Ermittlungstechniken (z. B. offene Fragen im Einzelinterview) erfasst werden. Hard und soft facts sind gleichermaßen zu werten. Aus Sicht des Managements sind überwiegend die anvisierten Projektergebnisse für das Fortführen des Projekts ausschlaggebend. Allerdings hat die Studie SUCCESS 2006 ermittelt, dass ein homogenes (kooperatives) Projektteam einen großen Einfluss auf das erfolgreiche Abschließen eines Projekts hat.

Never change a winning team!

Rettungsanker Typische Prüfmethoden sind a Fragetechniken (offene Fragen und Präzisionsfragen) a Interviews a Fragebogen a Checklisten (Prüflisten) a Dokumentenanalyse a Earned Value Analysis (auch Ertragswert-, Arbeitswertoder Leistungswertanalyse genannt)

118

www.hessen-it.de

Auswertung und Umsetzung der Maßnahmen Auswertung der Informationserhebung Sind die potenziellen Risiken und Probleme erfasst, werden sie einer Analyse unterzogen. Daraus werden dann konstruktive Lösungsvorschläge mit Varianten erarbeitet. Die Ergebnisse und die bewerteten Lösungsvorschläge werden anschließend den Entscheidungsträgern (z. B. Lenkungsausschuss, Auftraggeber) präsentiert und in Form des Reviewberichts und eines Aktionsplans übergeben. a Reviewbericht Der Reviewbericht beinhaltet neben dem technischen Sachverhalt eine Risikobetrachtung des Projekts sowie Empfehlungen für korrigierende Maßnahmen und wichtige zu fällende Entscheidungen. a Aktionsplan Der Aktionsplan beschreibt einen Maßnahmenkatalog, der steuernde Aktivitäten beinhaltet. Werden bei der Überwachung und Kontrolle (durch Soll / Ist-Analysen) Planabweichungen festgestellt, greifen diese gegensteuernden Aktivitäten. Der Aktionsplan soll die Durchführung der getroffenen Phasenentscheidungen und / oder Qualitätsmängelbehebungen gewährleisten. Dabei müssen während der Nachkontrolle u. a. Änderungen von Prioritäten, Terminen, Budgets, Aufgabenverteilungen, Verfahren sowie des Verhaltens im Verfahren berücksichtigt und dem Projekterfolg untergeordnet werden. Vgl. Jenny, Projektmanagement in der Wirtschaftsinformatik, 2001, S. 386

119

Siebter Akt – Unerwartetes Projektreview

Umsetzung der Maßnahmen Lenkungsausschuss oder Vorstand entscheiden, welche Maßnahmen aus dem Review-Bericht mit welcher Dringlichkeit umgesetzt werden sollen. Manchmal bedeutet das auch die Einstellung eines Projekts, wenn dem Ende mit Schrecken dem Schrecken ohne Ende der Vorzug gegeben wird. Manchmal ist eben eine Konventionalstrafe zwar teuer, aber vergleichsweise günstig gegenüber einem Jahre dahin dümpelnden Projekt mit permanent laufenden Kosten. Was auch immer die Entscheider beschließen und damit verantworten, die zu treffenden Maßnahmen werden dem Projektleiter mitgeteilt. Natürlich erfolgt dies – meist nach einer mündlichen Instruktion mit der Möglichkeit für Rückfragen – auch schriftlich. Der Projektleiter ist dann für resultierende Restrukturierungen des Projekts verantwortlich. Wohl gemerkt, nicht aber für die Konsequenzen der Entscheidung! Er passt die Projektplanung hinsichtlich Zeit, Zielen, Budget, Personal, Verträgen etc. entsprechend an. Die Review-Ergebnisse dienen aber neben der Statuserhebung des Projekts auch der effizienteren und effektiveren Gestaltung kommender Projektphasen und Projekte. Deshalb sollten sie nicht brach liegen, sondern dem Unternehmen zugänglich gemacht werden. Es gibt nichts Unnützeres als einen Wissenspool, den niemand einsehen kann. Sind die Ergebnisse eines Projektreviews so katastrophal, wie sie von Dr. Krott beschrieben werden, so fordern in der Regel die Entscheidungsträger ein Projektaudit. Mit diesem werden der Projektprozess und die Projektmanagementprozesse hinterfragt und überprüft, also u. a. auch Dr. Krotts Managementmethoden.

Rettungsanker Projektreviewauswertung und -umsetzung a Erhobene Informationen analysieren und Lösungsvorschläge mit Varianten erarbeiten a Reviewbericht und Aktionsplan erstellen a Entscheidungen herbeiführen a Maßnahmen umsetzen 120

www.hessen-it.de

Weitere managementbezogene Projektprüfverfahren Außer dem Projektreview gibt es weitere Projektprüfverfahren, die der Informationsgewinnung als Entscheidungsbasis für das Management dienen.

Projektaudit Ein Projektaudit dient nicht der Beurteilung der Projektergebnisse, sondern der Beurteilung der Qualität der Projekt- und Managementprozesse. Die Prozesses werden hinsichtlich Vollständigkeit, Richtigkeit und Wirksamkeit untersucht und im Sinne eines Projektmanagementaudits der Managementprozess in Bezug auf dessen Leistung, Organisation und Standards geprüft. (Vgl. Jenny, Projektmanagement in der Wirtschaftsinformatik, 2001, S. 391)

Da das Management selbst Prüfgegenstand ist, ist notwendigerweise die Prüfung durch externe Auditoren durchzuführen. Auch Projektaudits werden zu fest vordefinierten Punkten im Projektprüfplan (Abb. Seite 114) verankert. Projektaudits können auch zeitglich mit Projektreviews durchgeführt werden. Tatsächlich wäre im Fall des Ex & Hopp-Projektes eine solche Kombination nötig gewesen, denn große Risiken liegen gar nicht in der Abarbeitung der Aufgaben, sondern vor allem in den Prozessen.

Sonderfall: Unplanmäßiges Projektaudit Wie beim Projektreview, gibt es auch beim Projektaudit eine ungeplante Variante, mit der gleichen Problematik und den damit verbundenen potenziellen Risiken.

121

Siebter Akt – Unerwartetes Projektreview

Projektretrospektive Die Projektretrospektive dient der Ermittlung, Auswertung und Sicherung gemachter Erfahrungswerte wie Vertragsgestaltung, Ablaufgestaltung und Projektführung. Die sogenannten „Lessons learned“ sollten für zukünftige Projektvorhaben gesichert werden. Vor allem der Mensch steht im Vordergrund der Projektretrospektive. Mit einer gut durchgeführten Reflexion des abgeschlossenen Projekts kann den Projektmitarbeitern daher geholfen werden, ihren Verbesserungsbedarf zu verstehen und sie zu motivieren, ihre Art zu Arbeiten zu ändern. Das Resultat sind dann durch die Mitarbeiter selbst initialisierte Prozessänderungen und -optimierungen, wodurch nicht nur der Entwicklungsprozess verbessert, sondern auch der Lerneffekt, das Wachstum und die Reife der Teilnehmer gefördert wird. In guten Unternehmenskulturen ist deshalb die Projektretrospektive ein fest institutionalisiertes Ritual. Rückblickend werden positiv und negativ gemachte Erfahrungen, Einsichten und Erkenntnisse meistens in einem Workshop reflektiert und gesichert. War das Projekt erfolgreich, werden die Leistungen der Mitarbeiter gewürdigt, vor allem aber dann, wenn das Projekt nicht erfolgreich oder gar ein Misserfolg war. Warum? Ähnlich wie bei Forschungsvorhaben, liegt es in der Natur von Projekten, dass nicht jede Idee zu einem gewinnbringenden Erfolg führt. Das bedeutet aber nicht, dass sich die Projektmitarbeiter nicht mindestens genauso stark auch in einem gescheiterten Projekt engagiert haben. Meist ist das Gegenteil der Fall. (Vgl. Kerth, Post Mortem, 2003, S. 16)

122

www.hessen-it.de

Rettungsanker Weitere Projektprüfverfahren a Projektaudit zur Prüfung der Projekt-und Managementprozesse a ungeplante Projektaudits sollten wie ungeplante Projektreviews nur mit viel Bedacht eingesetzt werden a Projektretrospektive Erfahrungssicherung, Lerneffekte, Reifegrad der Projektteilnehmer. Ob positiver oder negativer Projektabschluss, die Leistung der Projektmitarbeiter würdigen.

Wie ergeht es nun unseren Protagonisten? Tragisch, aber dennoch oft geübte Praxis ist die Entlassung des Projektleiters (bei externen Projektleitern ist die Entlassung sozusagen bereits vorab als Option vorgesehen und deshalb nicht tragisch), wie es möglicherweise auch Schröder ergehen wird. Damit werden zwar keine Probleme gelöst, im Gegenteil, Know-how geht verloren und eine Überbrückungszeit wird nötig, aber immerhin ist ein Schuldiger gefunden. Sicher hat Schröder viel zur Misere beigetragen, aber die anderen Protagonisten, allen voran Dr. Krott, haben nichts getan, sogar jegliche Hilfe verweigert, um diese Situation zu verhindern. Deshalb haben sie ebenso viel zum Misserfolg beigetragen wie Schröder. Wir lassen die Geschichte unserer Protagonisten hier enden, aber man kann sich leicht vorstellen, wie sie sich weiter entwickeln könnte.

123

Epilog

Epilog Die hier behandelten Szenarien haben aufgezeigt, dass die Indikatoren von Faktoren für notleidende Projekte in aller Regel von jedem Projektteilnehmer in ganz alltäglichen Projektsituationen wahrgenommen werden können. Dazu bedarf es, wie eingangs erwähnt, keiner komplexen Planungs- und Steuerungsmethoden und -instrumente, sondern eher einer gewissen Aufmerksamkeit zum Beobachten und Zuhören im täglichen Projektumgang – und vielleicht ein klein wenig Übung. Wenn wir also schlussendlich wesentliche Indikatoren für notleidende Projekte so leicht durch Beobachten und Zuhören feststellen können, warum gibt es dann dennoch so viele notleidende Projekte? Was hindert uns eigentlich daran, Maßnahmen zur Behebung erkannter Problemfaktoren zu planen und umzusetzen? Stehen wir uns etwa bei dem Wunsch, „in time, in scope, in budget“ ein Projekt zum Erfolg zu führen, selbst im Weg? Oder hören wir bereits zu und beobachten wir – als Manager, Projektleiter oder Betroffener – sind aber noch nicht bereit für diese Wahrheit und deren Konsequenzen? Die beispielhaft aufgezeigten Maßnahmen sind, jede für sich betrachtet, relativ leicht umsetzbar. Aber bereits einige Maßnahmen führen zu Konsequenzen, die viel mehr Veränderung beinhalten als wir vielleicht wollen, die an unserem Bekannten und Vertrauten rütteln und die deshalb letzt-

124

shironosov/istockphoto.com

lich viel stärker an unsere Persönlichkeit gehen.

www.hessen-it.de

a Gefordert ist die Bereitschaft, die reine Technik- und Methodengläubigkeit über Bord zu werfen. Denn die beste Technik und die passende Methode löst noch kein Problem. Sie sind und bleiben Werkzeuge. Nur ein vertrauensvolles, fehlertolerantes und gut zusammengestelltes Team, das in der Lage ist, Tiefschläge gemeinsam und lastenverteilt zu bewältigen, hat dauerhaften Erfolg mit guten Werkzeugen. a Gefordert ist die Bereitschaft vor allem der Manager und der Projektleiter zu erkennen, dass sie in modernen und erfolgreichen Projekten keine hierarchischen Machtpositionen zu verteidigen haben, sondern ihrer Rolle gemäße Aufgaben zu erfüllen haben. a Gefordert ist die Bereitschaft, die Unternehmenskultur nachhaltig zu verbessern. Dazu zählt in allererster Linie die Vorbildfunktion der Manager, Führungskräfte und Projektleiter bei der Eigenorganisation, der Fehlerkultur und der Transparenz ihrer Entscheidungen. a Gefordert ist die Bereitschaft, in diese Veränderungen zu investieren. Zu investieren in Zeit, Geduld, Rückschläge, das Recht, Fehler auch selbst machen zu dürfen und letztlich auch Geld für Ausbildung oder begleitende Coachingmaßnahmen. In unserer täglichen Projektpraxis sehen wir immer wieder, dass man den Lohn solcher Investments ableiten kann. Projekte mit einer guten Unternehmenskultur haben letztlich eine deutlich höhere Chance auf Erfolg. Die Projektergebnisse sind qualitativ höher. Die Projektbeteiligten empfinden ihr Mitwirken als herausfordernd und erfüllend zugleich und sie gehen ihrer Arbeit mit mehr Freude nach. Sie sind bei erfolgreichem Projektabschluss stolz auf das Geleistete und brennen darauf, wieder in einer solchen Umgebung arbeiten zu dürfen.

Für Ihr nächstes Projekt wünschen wir Ihnen ähnlich positive Erfahrungen.

125

Literaturhinweise

Literaturhinweise a Thomas Bohnic: Projektmanagement – Soft Skills für Projektleiter, Gabal Verlag Offenbach: 2007 (ISBN 3-89749-629-3)

a Manfred Burghardt: Projektmanagement, Siemens AG Berlin: 2008 (ISBN 3-89578-310-4)

a Ralf Buschermöhle, Heike Eekhoff, Bernhard Josko: Success and failure of hard- and software projects: SUCCESS 2006, BIS Verlag Oldenburg: 2006 (ISBN 3-8142-2035-2)

a Tom DeMarco: Der Termin (Roman), Carl Hanser Verlag München: 1998 (ISBN 3-446-40165-2)

a Tom DeMarco: Bärentango, Carl Hanser Verlag München: 2003 (ISBN 3-446-22333-9)

a Tom DeMarco: Adrenalin Junkies & Formular Zombies, Carl Hanser Verlag München: 2007 (ISBN 3-446-41254-5)

a Roger Fisher, William Ury, Bruce Patton: Das Harvard-Konzept, Campus Verlag: 1993 (ISBN 3-593-34804-7)

a Jürgen Hansel, Gero Lomnitz: Projektleiter-Praxis, Springer Verlag Berlin: 1983 (ISBN 3-540-56779-8)

a Bruno Jenny: Projektmanagement in der Wirtschaftsinformatik, vdf Hochschulverlag AG, Zürich: 2001 (ISBN 3-7281-2791-4)

a Norman L. Kerth: Post mortem – Projekte erfolgreich auswerten, mitp-Verlag Verlag Bonn: 2003 (ISBN 3-8266-1348-7)

a Karin Klebert, Einhard Schrader, Walter Straub: KurzModeration, Windmühle GmbH 1987 (ISBN 3-922789-23-4)

126

a Matthias Klimmer: Unternehmensorganisation, Verlag Neue Wirtschaftsbriefe: 2007 (ISBN 3-482-54972-4)

a Fredmund Malik: Führen Leisten Leben, Wilhelm Heyne Verlag München: 2001 (ISBN 3-453-19684-8)

a Pascal Mangold: IT-Projektmanagement, Elsevier GmbH, München: 2004 (ISBN 3-8274-1502-0)

a PMI: A Guide to the Project Management Body of Knowledge, B&T, 2003 (ISBN 1-930699-21-2)

a Ralph Schlieper-Damrich, Petra Kipfelsberger: Wertecoaching, Managerseminare Verlags GmbH, Bonn: 2008 (ISBN 3-936075-72-7)

a Christian Setzwein, Monika Setzwein: Turnaround-Management von IT-Projekten, dpunkt Verlag GmbH Heidelberg: 2008 (ISBN 3-89864-439-6)

a Klaus D. Tumuscheit: Immer Ärger im Projekt, orell füssli Verlag, Zürich: 2001 (ISBN 3-280-02682-2 )

a Klaus D. Tumuscheit: Erste-Hilfe-Koffer für Projekte, orell füssli Verlag, Zürich: 2007 (ISBN 3-280-05034-7 )

a Klaus D. Tumuscheit: Überleben im Projekt, orell füssli Verlag, Zürich: 1998 (ISBN 3-636-01291-3)

a Hans Wieczorrek, Peter Mertens: Management von IT-Projekten, Springer Verlag Berlin: 2007 (ISBN 3-540-48470-7)

a www.projektmagazin.de

www.hessen-it.de

Die Aktionslinie Hessen-IT

Hessen-IT ist die Aktionslinie des Hessischen Ministeriums für Wirtschaft, Verkehr und Landesentwicklung für den gesamten Informations- und Kommunikationstechnologiemarkt in Hessen. Hessen-IT bietet Informationen und Services zum Online-Markt, zu E- und M-Commerce, zu Softwareund Telekommunikationsanbietern sowie über Telearbeit. Angesprochen werden auf der einen Seite die fast 10.000 hessischen Unternehmen, die Produkte oder Dienstleistungen auf dem Informations- und Kommunikationstechnologiemarkt anbieten, auf der anderen Seite die kleinen und mittleren Anwender-Unternehmen. Anbieter-Datenbanken erleichtern die Suche nach geeigneten Dienstleistern bei der Durchführung von IT-Projekten. Gleichzeitig fungieren diese Datenbanken für Anbieter als Informations- und Kommunikationsplattform, auf der sich diese den Anwendern und potenziellen Kunden präsentieren können. Newsticker, E-Mail- und Print-Newsletter berichten regelmäßig über den IKT-Markt in Hessen. Zahlreiche Schriftenreihen und Veröffentlichungen ergänzen das Informationsangebot der Website. Die Broschüren können bequem online bestellt oder heruntergeladen werden. Hessen-IT hat verschiedene Netzwerke und Branchentreffs initiiert, in denen sich teils nichtkommerzielle Initiativen, teils kommerzielle Anbieter zusammengeschlossen haben. Regionale Multimedia- und E-CommerceZentren sowie IHKs, Handwerkskammern und andere regionale Akteure arbeiten zusammen an dem Ziel, Hessens starke Stellung im deutschen und europäischen IKT-Markt weiter zu sichern und auf dem Weg in die Informationsgesellschaft weiter voran zu bringen.

127

Die Aktionslinie Hessen-IT

Einen Überblick über diese Netzwerke und Treffen sowie Terminankündigungen zu Veranstaltungen, an denen Hessen-IT beteiligt ist, finden Sie im Online-Terminkalender auf der Website. Auch bei internationalen Messen wie der CeBIT oder bei regionalen Veranstaltungen in ganz Hessen sind kompetente Ansprechpartner der Aktionslinie präsent. Hinzu kommen Seminare und Workshops, die Hessen-IT zu verschiedenen Themen ausrichtet. Das Projektteam von Hessen-IT steht Ihnen jederzeit gerne als Ansprechpartner zur Verfügung. Besuchen Sie unsere Website unter

www.hessen-it.de

128

www.hessen-it.de

Schriftenreihe Hessen-IT (vormals Hessen-Media) Bestellmöglichkeit und Download als PDF-Datei finden Sie im Internet unter www.hessen-it.de

Wir über uns 2001

Hessen-infoline-Netzwerk (Band 26) Projektdokumentation (Band 1)

Bildung und Wissenschaft 2002

Telemedizin in Hessen – Beiträge aus dem Universitätsklinikum Gießen (Band 24)

2001

Entwicklung und Einsatz elektronischer Medien als Lehr- und Lernmittel an hessischen Hochschulen (Band 27) Kompetenzzentren und Onlinedienste im Schulwesen – Beispiele für Hessen-Media Projekte (Band 25)

2000

Die virtuelle Universität (Band 15)

E-Government 2002

Auf dem Weg zu E-Government – Hessens Kommunen im Internet (Band 37) Wirtschaftsförderung und Standortmarketing im Internet (Band 36)

Marktstudien IT-Standort Hessen 2008

Telekommunikationsanbieter in Hessen 2008 (Band 60)

2006

IKT-Markt in Hessen (Band 58)

2004

Softwareanbieter in Hessen 2004 (Band 50) Telekommunikationsanbieter in Hessen 2004 (Band 49)

2003

Online-Anbieter in Hessen (Band 2)

2002

E-Shops in Hessen (Band 28)

2000

Der Telekommunikationsmarkt in Hessen (Band 21)

129

Schriftenreihe Hessen-IT

Leitfäden für IT-Anwendungen 2010

Notleidende Projekte – Eine Hilfestellung für IT-Projekte in sieben Akten (Band 64) Die Gamesbranche – ein ernstzunehmender Wachstumsmarkt (Band 59, 2. aktualisierte Auflage) SOA – mehr als nur flexible Softwarearchitekturen (Band 63) Satellitennavigation in Hessen – Ideen über All (Band 65)

2009

Ambient Mobility – Intelligente Produkte und Umgebungen für mobile Bürger und Unternehmen (Band 61) Rating für IKT-Unternehmen (Band 53, 2. aktualisierte Auflage)

2008

Leitfaden zur Patentierung computerimplementierter Erfindungen (Band 51, 2. aktualisierte Auflage)

2007

Web 2.0 – Neue erfolgreiche Kommunikationsstrategien für kleine und mittlere Unternehmen (Band 57) Die Gamesbranche – ein ernstzunehmender Wachstumsmarkt (Band 59) In modernen Märkten überleben – Kooperationen mittelständischer Softwareunternehmen in Hessen (Band 44, 2. Auflage)

2006

Internet-Marketing nicht nur für kleine und mittlere Unternehmen (Band 52) Basel II – Rating für IT-Unternehmen (Band 53) RFID – Geschäftsprozesse mit Funktechnologie unterstützen (Band 54) Anti-Spam – Ein Leitfaden über und gegen unverlangte E-Mail-Werbung (Band 55) VoIP – Telefonieren über das Internet (Band 56) Leitfaden Webdesign – Internetpräsenzen besser planen und gestalten (Band 7, 5. Auflage)

2005

Recht im Internet (Band 33, 2. Auflage) Gefunden werden im Internet (Band 32, 2. Auflage)

2004

Wettbewerbsvorteile durch barrierefreie Internetauftritte (Band 48) Domainregistrierung international (Band 47) Wireless-LAN: Stand und Entwicklungspotenzial, Nutzungsansätze für KMU (Band 46)

130

www.hessen-it.de

2003

E-Business-Konzepte für den Mittelstand (Band 45) Leitfaden „In modernen Märkten überleben“ (Band 44) Projektleitfaden „Software-Ergonomie“ (Band 43) „Digitale Signatur“, Leitfaden zum Einsatz digitaler Signaturen (Band 42) Die Bedeutung der E-Logistik für den Mittelstand (Band 41) Management von Kundenbeziehungen im Internet (Band 40) Leitfaden „Webdesign – Internetpräsenzen besser planen und gestalten“ (Band 7)

2002

IT-Sicherheit für den Mittelstand (Band 38) E-Paymentsysteme – Bezahlen im Internet (Band 35) ASP: Mehr als nur Mietsoftware (Band 34) Recht im Internet (Band 33) Gefunden werden im Internet (Band 32) E-Learning für KMU – Neue Medien in der betrieblichen Aus- und Weiterbildung (Band 31) Telehaus Wetter – ein TeleServiceZentrum (Band 30)

2001

Kasseler Praxis-Dialog Tele@rbeit – Analysen · Erfahrungen · Positionen (Band 29)

2000

Leitfaden „Webdesign international“ (Band 22) E-Shop-Software (Band 20) Hessische Handwerker entdecken das Internet (Band 19) Leitfaden zur Anwendung eines Ratingsystems für IT-Unternehmen in Hessen (Band 18) Software-Dialog Hessen (3) (Band 17) Leitfaden „E-Shop“ (Band 16)

131

ISBN 978-3-939358-64-0