IT Projektmanagement

Wie bereits Paul Watzlawik sagte: Man kann nicht nicht kommunizieren. Was aber muss ich wie an wen über welche Kanäle im Unternehmen kommunizieren, um eine positive Wahrnehmung des Projektes zu sichern? Ich fasse eine Vielzahl solcher Maßnahmen unter dem Überbegriff "Projektmarketing" zusammen. Bei diesem zweiten Teil geht es um die konkrete Umsetzung des Projektmarketings, Projektmarketingstrategien, die Beziehung zwischen Projektmarketing und Stakeholdermanagement, Qualitätssicherungsaspekte und natürlich Kosten, die für Projektmarketing einzuplanen sind. Wenn Sie als Auftraggeber oder Projektleiter arbeiten, sollten Sie diese Podcastserie auf keinen Fall verpassen. Weitere Informationen finden Sie unter www.Bundesvereinigung-ITPM.de

Das Projekt ist zu Ende! Alle Anforderungen sind erfüllt und die Abnahme war erfolgreich. Nun kann das Projektergebnis endlich produktiv gehen. Doch die Rechnung wurde nicht mit den Anwendern gemacht. Sie wurden über den Projektverlauf hinweg nie wirklich befragt, wurden kaum in das Projekt eingebunden und fühlten sich insgesamt übergangen. Innerer Protest machte sich bereits früh breit. Die Konsequenz daraus: Das Projektergebnis wird zwar eingeführt, aber keiner arbeitet damit. Das Projekt wurde in Time, in Budget und in Quality erfüllt. Theoretisch ein voller Erfolg und aber praktisch ein Fehlschlag, denn die Akzeptanz tendiert gegen null. Was ist da nur passiert? Die Projektleitung hat versäumt die zukünftigen Anwender ins Boot zu holen. Diejenigen, die zukünftig mit dem Projektergebnis arbeiten sollen und das eigentliche Businesswissen haben, fühlten sich übergangen. Ihre Kritik wurden beiseite gewischt…die Projektleitung glaubte zu Wissen was für die Anwender gut ist. Doch die Anwender haben sich zwischenzeitlich andere Lösungen geschaffen…egal wie toll das Projektergebnis auch sein mag…wenn es von den Anwendern nicht abgenommen wird, ist es post mortem ein Fehlschlag. Aber was kann man tun um solche Fehler zu vermeiden? Die Antwort liegt im Stakeholdermanagement- konkret im Projektmarketing. In den nächsten beiden Folgen beschäftigen wir uns primär mit diesem Thema. Ich wünsche Euch im Voraus schon viel Spaß und allzeit grüne Meilensteine! Grüße Andreas Haberer Weitere Informationen finden Sie unter www.Bundesvereinigung-ITPM.de

Ziel aller unternehmerisch denkenden IT-Freelancer ist es, eine möglichst hohe Jahresauslastung zu erreichen. Das ist allerdings bei genauer Betrachtung gar nicht so einfach. Ist man in einem laufenden Projekt gebunden, dann steckt man dort häufig zu mehr als 100% der verfügbaren Zeit fest. Dazu kommt, dass vom Auftraggeber häufig eine „optionale Verlängerung“ vertraglich in Aussicht gestellt wird. Erschwerend kommt oben drauf, dass diese „Option“ oftmals erst wenige Tage vor Ablauf gezogen wird. Es ist also gar nicht so einfach, sich auf der einen Seite rechtzeitig um ein Folgeprojekt zu bemühen wenn man auf der anderen Seite weiß, dass der aktuelle Auftraggeber evtl. auf den letzten Drücker kommt und das laufende Projekt verlängern möchte-, was selbstverständlich die bequemste Art der Auftragsakquise ist. Doch was ist, wenn die erhoffte Verlängerung am Ende ausbleibt? Und das wird ohne Zweifel irgendwann passieren, denn es ist die Basis unseres Geschäftsmodells, das man uns unkompliziert einsparen kann, indem man ein Auftrag eben einfach nicht mehr verlängert. Egal ob Sie sich frisch selbständig gemacht haben und jetzt einen Auftrag suchen- oder ob Ihr letzter Auftrag gerade ausgelaufen ist. Wenn das so ist, schalten wir um auf den Modus „Projektakquise“. Und in diesem Modus heißt es, selbst aktiv zu werden. Ein dafür unverzichtbares Mittel ist das CV, oder Skill-Profil. Es ist Ihre Eintrittskarte zum nächsten Projekt. Weil das für alle IT Freelancer gilt, ist der Inhalt auch so wichtig. Denn damit machen sie Ihre Expertise für Ihre Zielgruppe sichtbar. Kleinste Änderungen am CV können bereits darüber entscheiden, ob Sie in die engere Wahl bei der Kandidatenauswahl kommen, oder nicht. Verpassen Sie daher die heutige Folge in dem wir uns die Frage stellen, wie ein wirksames IT Freelancer Profil eigentlich aussehen muss. Weitere Informationen finden Sie unter www.Bundesvereinigung-ITPM.de

In Deutschland wird vor allem die IT Branche seit Jahren immer wieder durch das Thema „Scheinselbständigkeit“ in Unruhe versetzt. Es gab in der Vergangenheit keine klaren gesetzlichen Kriterien, anhand derer man ausschließen konnte, als Selbständiger oder Freiberufler selbst als "scheinselbständig" zu gelten. Im November 2015 wurde nun ein Gesetzesentwurf vorgestellt, der Klarheit in diese Rechtsunsicherheit bringen sollte. Liest man diesen Entwurf, hat man das Gefühl, dass nicht nur der klassische Dienstvertrag abgeschafft und kriminalisiert werden soll, man könnte fast meinen dass hier eine regelrechte Hexenjagd auf selbständige IT'ler angebahnt wird. Wer hat daran Interesse? Wollte unsere Regierung nicht gerade dieses Spezialistentum fördern? In der heutigen Folge unseres Podcasts geht es um die heute bereits spürbaren Auswirkungen dieses Gesetztes in der IT Branche und um den Sachstand dieses neuen Gesetzes. Weitere Informationen finden Sie unter www.Bundesvereinigung-ITPM.de

Vom berühmten chinesischen Philosoph Konfuzius stammt das folgende Zitat: Der Mensch hat drei Wege klug zu handeln: Erstens durch Nachdenken: Das ist der edelste. Zweitens durch Nachahmen: Das ist der leichteste. Drittens durch Erfahrung: Das ist der bitterste. Nun sind ein paar Tage vergangen, seit Konfutius diese Weisheit auf die Welt losgelassen hat und in Bezug auf Projekte wurden viele, ja- zum Teil auch bittere Erfahrungen gemacht. Glücklicherweise nicht umsonst, denn aus vielen dieser Erfahrungen wurden Lehren gezogen. Über Jahre und Jahrzehnte hinweg entwickelten sich Werte, Kompetenzen, Prozesse und Methoden die Einfluss auf das Gelingen von Projekte zu haben scheinen. Diese Lehren wurden angewandt und über Jahrzehnte hinweg weiter verbessert. Heute finden wir viele dieser Erkenntnisse in diversen Projektmanagement Zertifizierungen wieder. Diese Zertifizierungen erlangen einen immer größeren Stellenwert in der Wirtschaft. Ein selbständiger IT Projektmanagementberater kann es sich kaum noch leisten, keine Zertifizierung vorweisen zu können. Aber auch für angestellte Projektmanager und Projektmitarbeiter wird zertifiziertes und damit nachgewiesenes Projektmanagementwissen immer wichtiger. Doch welche Zertifizierung macht Sinn? Wo genau liegt eigentlich der Unterschied? Gibt es für die IT Branche eine Zertifizierung die man vorziehen sollte? In den nächsten beiden Folgen meines Podcastes werde die gängigen Projektmanagementzertifizierungen einmal für Sie gegenüberstellen. Weitere Informationen finden Sie unter www.Bundesvereinigung-ITPM.de

"Und eine Lust ist's, wie er alles weckt und stärkt und neu belebt um sich herum, wie jede Kraft sich ausspricht, jede Gabe gleich deutlicher sich wird in seiner Nähe! Jedwedem zieht er seine Kraft hervor, die eigentümliche, und zieht sie groß. Lässt jeden ganz das bleiben, was er ist. Er wacht nur drüber, dass er's immer sei, am rechten Ort: So weiß er aller Menschen Vermögen zu dem seinigen zu machen." Schiller, Wallenstein, Die Piccolomini, In der vergangen Woche hatten wir uns mit dem Thema Führung beschäftigt und uns gefragt, wie Führung entsteht und wie kommt es überhaupt dazu, dass Menschen ihre Souveränität aufgeben und sich anderen unterordnen? Wir fragten uns, warum das einigen Führungskräften gelingt, aber anderen nicht? Erfahren Sie im zweiten Teil dieser Folge wie es weitergeht mit diesen uralten Wirkprinzipien durch die Führung überhaupt er möglich wird. Erfahren Sie wie Sie es schaffen ein Projektteam hinter sich zu vereinen und auf gemeinsame Ziele auszurichten. Weitere Informationen finden Sie unter www.Bundesvereinigung-ITPM.de

Vom französische Feldherr und Kaiser Napoleon Bonaparte stammt das Zitat: "Es gibt keine schlechten Mannschaften, Marschall. Es gibt nur schlechte Offiziere." Als erfahrener Kriegsherr und Kaiser kannte und schätzte Napoleon also den Wert und die Wichtigkeit seiner Führungskräfte. Auch als IT-Projektleiter hat man die Führungsverantwortung für das Projektteam und die zu erreichenden Projektziele. Aber was bedeutet eigentlich Führung? Wie entsteht Führung und wie kommt es überhaupt dazu, dass Menschen ihre Souveränität aufgeben und sich anderen unterordnen? Warum gelingt das einigen Führungskräften, aber anderen nicht? Erfahren Sie in dieser Folge die uralten Wirkprinzipien durch die Führung überhaupt erst möglich wird. Erfahren Sie wie Sie es schaffen ein Projektteam hinter sich zu vereinen und auf gemeinsame Ziele auszurichten. Weitere Informationen finden Sie unter www.Bundesvereinigung-ITPM.de

In der heutigen Sendung möchte ich ihnen zeigen, wieviel Spaß es macht sich einmal aktiv in die Rolle eines Projektsaboteurs hinein zu versetzen. Daraus ergeben sich erstaunliche Erkenntnisse. Hören Sie selbst, was ich im Seminar einer Kollegin vor einigen Wochen erleben durfte. Weitere Informationen finden Sie unter www.Bundesvereinigung-ITPM.de

Führung gehört zu den elementarsten Aufgaben eines Projektleiters. Doch führen ist nicht etwas, das man sich aus Büchern heraus alleine aneignen kann. Sicher gibt es Naturtalente, die einfach eine Führernatur sind. Doch auch als normalsterblicher kann man es zu passablen Führungseigenschaften bringen. Führung insgesamt hat eine Reihe von Aspekte. Einer davon ist die Kommunikation. Die heutige Folge 20 trägt den Titel „Der Projektmanagementflüsterer“ und es geht dabei um eine sehr spannende Erfahrung, die ich im Bereich der non-verbalen Kommunikation gemacht habe. Weitere Informationen finden Sie unter www.Bundesvereinigung-ITPM.de

Im 2. Teil dieser Folge geht es um das Risikomanagement in der Praxis. Was ist beim Risikomanagement in den einzelnen Projektphasen zu beachten? Wie identifiziert man Risiken richtig und wie bewertet man diese? Was ist ein Risikoregister und wie geht man damit um? Und wie misst man ein erfolgreiches Risikomanagement? Diese und andere Fragen werden in der heutigen Folge behandelt. Als kleines Geschenk an unsere Hörer haben wir einen kostenlosen Download für Sie bereitgestellt. Es ist eine Checkliste zur Projektdiagnose. In der Folge 9 haben wir dieses Thema ausführlich behandelt und diese Checkliste ist ein nützliches Hilfsmittel, wenn Sie neu in ein Projekt einsteigen und den Status Quo feststellen möchten. Hier können Sie die Checkliste herunterladen: http://www.bundesvereinigung-itpm.net/downloads/ Als 2. Geschenk stammt von Gerhard Wirnsberger, der sich in der Folge 16 vorgestellt hat. Mit seinen Seminaren zum Thema IT Projektmanagement und Kommunikation bietet er Ihnen, als Hörer unseres Podcasts, einen Rabatt von 20% auf seine Seminare an! Alle Informationen zu seinen Seminaren finden Sie unter www.wirnsberger.biz Weitere Informationen finden Sie unter www.Bundesvereinigung-ITPM.de

Nachdem mich 2 Hörerzuschriften mit der Bitte erreicht haben, doch mal eine Podcastfolge über das Thema Risikomanagement zu machen, habe ich mich entschlossen die Folge heute und nächstes Mal ganz diesem Thema zu widmen. Risikomanagement ist eine präventive Maßnahme, sowohl für Unternehmen und insbesondere für Projekte. Es ist das Radar der Projektleitung. Risikomanagement dient dazu, besonnen potenzielle Projektrisiken zu beleuchten und sie durch geeignete Maßnahmen entweder unwahrscheinlicher machen, oder die Auswirkungen beim Eintritt maximal zu vermindern. Dafür ist ausreichend Zeit einzuplanen. Ein Projekt, das sich im ständigen „Firefighting Mode“ befindet, hat meist keine Zeit mehr um Risiken zu managen. Solche Projekte agieren nicht mehr, sondern sie reagieren nur noch. Im ersten Teil dieser Folge beschäftigen wir uns mit den Grundlagen des Risikomanagements. Was ist der Unterschied zwischen einem Risiko und einem Problem und wie geht man mit ihnen um? Welche Strategien gibt es mit Risiken umzugehen. Diese und noch weitere Fragen werden in dieser Folge behandelt. In der kommenden folge beschäftigen wir uns dann mit der Frage, wie Risikomanagement im Projekt effizient eingeführt wird. Weitere Informationen finden Sie unter www.Bundesvereinigung-ITPM.de

Die fehlende Unterstützung durch das Management, zählt neben anderen, zu den am häufigst genannten Ursachen für das Scheitern von Projekten. Fragt man aber konkret nach, wie diese Unterstützung genau aussehen soll, erfährt man im Verhältnis überraschend wenig konkretes. Die Rolle des Projektsponsors stellt die Schnittstelle zwischen dem Projektleiter und dem Topmanagement des Unternehmens dar. Doch was genau muss er dabei tun? Welche Verantwortungen trägt er und welche nicht? Wie genau soll er das Projekt unterstützen? Was darf ein Projektleiter vom Projektsponsor erwarten und was ist dabei zu beachten? In der heutigen Folge unseres Podcasts "IT Projektmanagement" beschäftigen wir uns mit dieser und weiteren Fragen zu diesem Thema. Weitere Informationen finden Sie unter www.Bundesvereinigung-ITPM.de

Ich freue mich heute Gerhard Wirnsberger im Interview begrüßen zu dürfen. Gerhard Wirnsberger ist Jahrgang 1967 und gehört zu den führenden Projektmanagement-Experten im deutschsprachigen Raum. Er ist Ingenieur für Nachrichtentechnik, Diplom-Informatiker (FH), ausgebildeter Moderator und NLP-Trainer sowie zertifizierter Senior Project-Manager Level B (IPMA). Darüber hinaus absolviert er ein Studium der Psychologie an der renommierten University of Southern Queensland in Australien. Nach seiner mehr als zehnjährigen Erfahrung als verantwortlicher Projektleiter in einem internationalen Konzern der Elektroindustrie und zahlreichen Großprojekten in Deutschland, Europa und Asien, gibt er nun sein Praxiswissen als Berater, Trainer und Coach mit den Schwerpunkten • IT Projekt- und Programmanagement • Kommunikation im Projektmanagement • und Konfliktmanagement weiter Gerhard Wirnsberger erreichen Sie im Internet unter www.Wirnsberger.biz, in Xing und in LinkedIn Gerhard Wirnsbergers Buchempfehlungen: Katja Nagel: Professionelle Projektkommunikation Tom DeMarco: Bärentango, mit Risikomanagement Projekte zum Erfolg führen. Weitere Informationen finden Sie unter www.Bundesvereinigung-ITPM.de

Worin liegt die eigentliche Rolle des Managements? Im intelligenten Reagieren auf Veränderungen. Jean-Jacques Servan-Schreiber Die Folge 15: IT Projektmanagement, was macht es eigentlich besonders…Teil II Herzlich willkommen zum Zweiten Teil unseres Podcastes in dem wir uns mit der Frage beschäftigen, was IT Projektmanagement eigentlich so besonders macht. Dabei betrachteten wir Vorgehensmodelle, Methoden und deren Anwendung. Aber auch auf Rahmenbedinungen die zu beachten und klären sind um die richtigen Methoden und Vorgehensmodelle zu wählen. Die erste Folge dieses Podcasts endete mit der Betrachtung der unterschiedlichen IT Projektmanagementdiziplinen und deren Anforderungen an den Projektmanager. Betrachtet haben wir • Embedded System Entwicklung und • IT Infrastrukturprojekte Im Zweiten Teil dieser Folge möchte ich die begonnen Gedankengänge weiterführen und auch die anderen Arten betrachten: • Softwareevaluierungsprojekte • IT Rollout Projekte • Migrationsprojekte • Customizing Projekte • IT Umzugsprojekte • Oder Organisationsänderungsprojekte Softwareevaluierungsprojekte Bei dieser IT Projektart geht es primär um den Kauf eines Softwareproduktes und darum das am besten für die Anforderungen des Unternehmens geeignetste Produkt zu finden. Nehmen wir als Beispiel die Einführung eines CRM Systems im Unternehmen. Es gibt auf dem Markt eine Vielzahl von Systemen, mit einer großen Menge sich überschneidender Funktionen, aber auch Produkte die unterschiedliche Schwerpunkte setzten und damit unterschiedliche Stärken haben. Klassischerweise beginnt ein solches Projekt mit der Bedarfsermittlung in Form von Interviews. Die zukünftigen Anwender werden bezüglich ihrer Anforderungen befragt und deren Arbeitsablauf wie er heute ist dokumentiert oder sogar modelliert. Auf diese Weise erhält der Interviewer am Ende ein recht genaues Bild wo die Schwerpunkte liegen. Diese lassen sich dann beispielsweise auf eine Anforderungsmatrix übertragen. Zu den Anforderungen der zukünftigen Anwender kommen noch Anforderungen des Managements hinzu. Beispielsweise, kein Produkt, dessen Hersteller nicht wenigstens 200 Mitarbeiter hat, oder mindestens 2000 Referenz Installationen vorzuweisen hat, usw.. Im nächsten Schritt ist es wichtig, diese gesammelten Anforderungen zu gewichten. Denn nicht jede Anforderung ist gleich wichtig und ein Produkt wegen einer nebensächlichen Anforderung aus dem Raster fallen zu lassen, dient niemandem. Ist die Anforderungsarbeit geleistet, beginnt im nächsten Schritt die Marktsondierung. Zunächst im Groben- welche Produkte kommen aufgrund der Anforderungen überhaupt in die engere Wahl, welche sind maximal zweite Wahl und welche fallen ganz raus. Ist diese Arbeit getan und die Entscheidungen dazu dokumentiert, beginnt die Phase der Kontaktaufnahme mit den Produktherstellern. Es empfiehlt sich Referenzadressen zu Installationen mit vergleichbaren Anforderungen einzuholen. In der Regel sind diese Referenzadressen zumindest zu einem Telefongespräch- wenn nicht sogar zu einem Treffen bereit. Diese Termine und die Anwendererfahrungen sind sehr wertvoll und hier erhält man oftmals auch wertvolle Praxistipps. Als nächstes stehen die Präsentationstermine der Hersteller auf der Tagesordnung. Hier holt man sich eine komprimierte Einführung in das jeweilige Produkt, stellt gezielte Fragen und erhält ein Gefühl für die Bedienbarkeit des Produktes. Bei diesen Terminen sollten die Vertreter der zukünftigen Anwender dabei sein um deren Fragen zu klären und deren Meinungsbild am Ende mit zu berücksichtigen. Die Hersteller bekommen bei Bedarf am Ende noch einen Fragenkatalog zum Ausfüllen mit. der dann die einzelnen Produkte vergleichbarer macht. Mit Hilfe der Anforderungen und deren Gewichtung und der Erfüllung der einzelnen Hersteller, hat man am Ende ein valides Ergebnis mit einer Entscheidungsvorlage zur Produktbeschaffung. Anforderungen an den Projektmanager Bei dieser Projektart sollte der Projektmanager über eine ausgeprägte Kommunikationsfähigkeit verfügen, um bei den Interviews nicht nur die richtigen Fragen zu stellen, sondern auch um die Informationen und Hinweise zu erkennen, die sich hinter den Antworten verbergen. Ferner sollte er die fachlichen Hintergründe kennen und verstehen, die mit Hilfe der zu beschaffenden Software gelöst werden sollen. Der Projektmanager sollte zumindest grundsätzlich die am Markt befindlichen Softwareprodukte kennen. Idealerweise hat er eigene Erfahrungen mit den Produkten. Es ist aber unbedingt notwendig bei diesen Projekten Neutralität zu wahren. Der Knochen muss dem Hund schmecken- nicht dem Metzger. Es geht nicht darum, den Auftraggeber von der eigenen Lieblingssoftware zu überzeugen, sondern neutral, das gemäß Anforderungen beste Produkt für den Auftraggeber zu finden. IT Rollout Projekte Bei IT Rollout Projekten gibt es wiederum eine Reihe von Facetten. Häufig vermischen sich bei diesen Projekten auch die Grenzen zwischen Rollout und Migrationsprojekten. Vor wenigen Jahren gab es eine Phase in der ich teilweise mehrfach pro Monat zur Leitung von Windows 7 Rolloutprojekten angefragt wurde. Auch hier gibt es ganz unterschiedliche Anforderungen und damit Herangehensweisen. Die einfachste Variante wäre die Installation auf neuen Rechnern. Nachdem der neue Rechner vor Ort aufgebaut und angeschlossen ist, werden mit Hilfe von Netzwerkinstallationen Betriebssysteme- und mit Softwareverteilsystemen individuelle Softwareprodukte nachinstalliert. Alternativ können auch Festplattenimages auf die Rechner gespielt werden die dann per Powershell Scripte individuell konfiguriert werden. Das geht bis zu komplexen Installationen und Konfigurationen die, je nach Anforderung, pro Arbeitsplatz individuell händisch zu bearbeiten sind. Noch anspruchsvoller wird es, wenn alte Betriebssystemversionen upzudaten sind, sofern die Hardwareanforderungen dies zulassen. Bis zur Einstellung des Supports von Windows XP im April 2014 ist ein regelrechter Boom an Migrationsprojekten gestartet. Am 13. Januar 2015 wurde offiziell der sogenannte „Mainstream Support für Windows 7“ eingestellt. Microsoft garantiert allerdings den „extended Support für Windows 7“ noch bis zum 14. Januar 2020. Mit diesem extended Support werden zumindest wichtige Sicherheitsupdates weiterhin bereitgestellt. Momentan, also im März 2015, besteht also noch kein Grund um hektisch zu werden. Bleibt abzuwarten wie sich der „Windows 8“ Nachfolger „Windows 10“ am Markt behaupten wird. Gerade im Vorfeld solcher Projekte sind eine Reihe Fragen zu klären. • Ist alle Software, die unter dem alten Betriebssystem lief auch von deren Herstellern für das neue Betriebssystem freigegeben? • Sind Individualentwicklungen unter dem neuen Betriebssystem lauffähig? • Gibt es Treiber für Drucker, Scanner oder sonstige im Unternehmen befindliche Geräte? • Wenn nicht, stehen dann auch noch Neubeschaffungen an? • Gibt es alte Softwarelösungen die nicht unter dem neuen Betriebssystem lauffähig sind und die weder updatebar noch verzichtbar sind? • Können solche Systeme in eigenen DMZ (Demiliterized Zone) die also abgeschottet sind und keine Internetverbindung haben, laufen? Natürlich zählen in den letzten Jahren auch der Rollout von Mobile Devices, also Tablett PCs oder Smartphones mit in diese Kategorie von IT Projekten. BYOD Rollout, also „Bring your own Device“, stellt hier sicherlich eine weitere Unterkategorie von IT Rolloutprojekten dar. Gerade hierbei spielen Sicherheitsaspekte eine große Rolle. Anforderungen an den Projektmanager Bei dieser Projektart sollte der Projektmanager über fundierte Produktkenntnisse verfügen. Alleine damit wird schon klar, dass sich auch hier wieder die Reihen der Spezialisten gabeln. Es erfordert einiges an Erfahrung, steht man vor der Herausforderung eine komplette Infrastruktur mit neuen Geräten auszustatten. Dies stellt Ansprüche sowohl an logistische Fähigkeiten, als auch an eine gründliche Anforderungsanalyse. Denn nur wenn klar ist, was in die Zielumgebung muss, wie vollständige Funktion dort getestet werden kann und dies auch ist, ist der Betrieb nach dem Rollout sichergestellt. Wie erwähnt müssen bei diesen Projekten IT Security Kenntnisse und gute Netzwerkkenntnisse vorhanden sein. Migrationsprojekte Jede Software hat nur eine begrenzte Halbwertszeit und soll beispielsweise wegen toller neuer Funktionalität, oder z.B. wegen geänderten gesetzlichen Regelungen durch eine neue Version abgelöst werden. Je nachdem wie diese Software bislang in die Systemlandschaft des Unternehmens eingebettet war, muss man sowohl das Produkt selbst, als auch das Umfeld und hier im Besonderen die Schnittstellen zum Umfeld betrachten. Sind neue Schnittstellen zu programmieren? Wurden individuelle Änderungen- also Customizings an der alten Software durchgeführt und müssen diese Änderungen nun an der neuen Software ebenfalls wieder programmiert werden? Eine besondere Herausforderung stellt die Datenübernahme in das neue System dar. Oftmals wird diese Datenübernahme dazu genutzt, sich von Altlasten, also Datenmüll zu trennen um das „neue System“ auf einem sauberen Datenstand aufzusetzen. Hieran erkennt man, dass Migrationsprojekte sehr schnell in einzelne Teilprojekte zerfallen müssen um die individuellen Anforderungen zu steuern. Anforderungen an den Projektmanager Zu den Herausforderungen wie sie sich aus einer klassischen Softwareentwicklung ergeben, kommen bei Migrationsprojekten noch dazu, dass der Projektmanager sowohl das abzulösende Produkt, also den Istzustand, als auch den Zielzustand kennen sollte. Je mehr Schnittstellen zu berücksichtigen sind, umso komplexer wird ein solches Projekt. Je mehr komplexe Datenstrukturen auf ein Zielsystem mit ganz anderen Datenstrukturen zu übertragen sind, umso höher sind die Anforderungen diese in das Zielsystem zu überführen. Customizing Projekte Klassisch fällt hier sicher ein großer Walldorfer Softwarehersteller ein, dessen Software nach der Basisinstallation individuell an die Bedürfnisse und Anforderungen des Kunden nach dessen Vorgaben angepasst werden. Diese Möglichkeit schafft die Symbiose eines Standardproduktes und die Flexibilität einer Individualentwicklung. Dieses Customizing muss allerdings gesteuert werden wie eine klassische Softwareentwicklung, allerdings mit dem Wissen, welche Funktionalität das Basispaket bereits enthält, welche Schnittstellen existieren und welche entwickelt werden müssen. Anforderungen an den Projektmanager Grundsätzlich handelt es sich auch hier wieder um Softwareentwicklung, allerdings in Bezug auf die Anpassungsmöglichkeiten des betreffenden Produktes. Der Projektmanager sollte das Produkt und die Möglichkeiten der Adaptierung zumindest in groben Zügen kennen. IT Umzugsprojekte Häufig werden IT Umzugsprojekte belächelt und als etwas abgetan, was man nebenbei mitmachen kann. Doch wer so denkt, unterschätzt die mögliche Komplexität eines Umzugsprojektes. Es beginnt bereits bei der Planung. Die Anforderungsanalyse an den Zielstandort ist ein zwingender Schritt, um den Umzug erfolgreich durchzuführen. Die Schaffung der notwendigen Infrastruktur am Zielstandort, angefangen von der notwendigen Stromversorgung, der Klimatisierung, der Datennetzanbindung, bis hin zu Zugangskontrolle und Brandmeldesysteme sind notwendige Voraussetzungen die vor dem eigentlichen Umzug zu schaffen sind. Abgesehen, ob der Umzug offline passieren darf, also ein System darf vom Netz gehen, oder Online passieren muss- das System muss trotz Umzug verfügbar sein, müssen ganz unterschiedliche Vorgehensweisen gewählt werden. Für die einzelnen Systeme die auf der umzuziehenden Infrastruktur laufen, müssen Testpläne erstellt werden. Hierzu sind die Produkt- oder Systemowner zu befragen, sofern keine Testpläne vorliegen. Es ist ratsam, sich für den eigentlichen Transport ein spezialisiertes Unternehmen zu holen, dass auf den Umzug von IT Inftrastrukturkomponenten spezialisiert ist. Diese Firmen sind technisch in der Lage, ein Patchfeld oder die Patchung eines Switches zu dokumentieren, die Kabel zu entfernen, das Gerät aus dem Datenschrank auszubauen und transportsicher zu verpacken. Am Zielstandort werden die Geräte gemäß Planung verbaut und gemäß Dokumentation gepached. Bei diesen Umzugsfirmen handelt es sich also nicht um Hilfskräfte die Datenschränke schleppen, sondern um IT Umzugsprofis. Je nach Priorität gehen die Geräte nach mechanischer Montage wieder in Betrieb und die Systeme wieder ans Netz. Die im Vorfeld definierten Testpläne der einzelnen Systeme werden nun abgefahren um die Funktionalität der umgezogenen Systeme zu validieren. Anforderungen an den Projektmanager Der Projektmanager solcher Projekte sollte ohne Frage über logistische Erfahrungen verfügen. Das ist vor allem bei der Vorbereitung und bei der Koordination der einzelnen Arbeitsschritte wichtig. Die Priorisierung, was wann offline gehen kann, wie die Priorisierung zum Wideranlauf gestaltet wird und wie die Inbetriebnahme erfolgt, erfordert einiges an Verständnis des Gesamtsystems und vor allem Koordinations und Kommunikationskompetenzen um die unterschiedlichen (Teil-)Interessen in einem solchen Umzug miteinander zu vereinen. Organisationsänderungsprojekte Klassisch wäre hier beispielsweise die Einführung von ITIL Prozessen im Rechenzentrum zu nennen, oder eine Organisationsänderung im Unternehmen, die in Folge einer neuen Software notwendig ist. ITIL ist ein Framework mit best practice Prozessen für das IT Servicemanagement. Diese Prozesse sind heute Defacto Standard in Rechenzentren. Der Incidentmanagementprozess sieht beispielsweise einen Single Point of Contact (SPOC) vor, bei dem alle Incidents zentral gemeldet werden. Es handelt sich hierbei wohlgemerkt um eine Rolle die durchaus mehrfach besetzt sein kann. Aber alleine diese kleine Änderung ist bereits eine große Herausforderung an eine Unternehmensorganisation. War man doch gewohnt den Kollegen vom Clientmanagement direkt anzurufen wenn man ein Problemchen hat und jetzt soll man beim SPOC anrufen der nur ein Ticket aufmacht? Oder nehmen wir an, ein Unternehmen hat erkannt, welches Potenzial in der Einführung eines geregelten Lizenzmanagementprozesses steckt. Die bisher dezentral verstreut liegenden Softwarelizenzen werden nun zentral gehalten und automatisch abgeglichen. Das Lizenzmanagement muss in diesem Fall dem Einkauf vorgeschaltet werden. Soll Software beschafft werden, muss zunächst der Lizenzmanager prüfen, ob eine freie Lizenz für diese Anforderung genutzt werden kann, oder ob eine externe Beschaffung notwendig ist. Nur im letzten Fall geht die Anforderung an den Einkauf weiter. Anforderungen an den Projektmanager Der Projektmanager sollte die einzuführenden Prozesse sehr gut verstehen und idealerweise Kenntnisse über den Istzustand verfügen. Gerade bei Organisationsprojekten muss peinlich genau darauf geachtet werden, dass das Projekt in der Unternehmenshierachie „richtig aufgehängt“ ist. Das bedeutet, betreffen die Änderungen alle Abteilungen im Unternehmen, macht es keinen Sinn einen der Abteilungsleiter zum Projektauftraggeber zu bestimmen. In diesem Fall ist es erforderlich, das Projekt mindestens auf Bereichsleitungsebene anzusiedeln um überhaupt die notwendige Hebelwirkung zu erzielen. Die Aufzählung an IT Projektmanagementdisziplinen liese sich sicherlich noch weiter führen, aber ich denke wir können es an dieser Stelle damit belassen. Viele der Kollegen werden in der beruflichen Praxis häufig nur mit der einen, oder anderen dieser Herausforderungen konfrontiert. Doch die IT ist viel mehr und das ist es, was es so spannend macht und das ist es warum ich diesen Beruf so liebe. Das Managen von IT Projekten wird niemals zur Routine und gerade weil es so viele Facetten gibt, macht es Sinn sich innerhalb dieser zu spezialisieren. Denn das, was man immer wieder tut, beherrscht man irgendwann in Perfektion. Genau solche Menschen möchten wir von der Bundesvereinigung IT Projektmanagement gerne kennen lernen und Ihre Expertise vorstellen. Um die eingangs gestellte Frage noch einmal aufzugreifen: Gerade dieser Facettenreichtum, macht IT Projekte zu etwas ganz besonderem. Damit bedanke ich mich dass Sie auch heute wieder dabei waren und wünsche Ihnen in Ihren Projekten lauter grüne Meilensteine Ihr Andreas Haberer Weitere Informationen finden Sie unter www.Bundesvereinigung-ITPM.de

Management ist die schöpferischste aller Künste. Es ist die Kunst, Talente richtig einzusetzen. Robert McNamara Die IT an sich ist ein beachtlich großes Spielfeld und wir beschäftigen uns bei der Bundesvereinigung IT Projektmanagement ausschließlich mit dem Managen von IT Projekten und alles was damit zu tun hat. Wenn wir also all unsere Aufmerksamkeit auf dieses Thema richten stellt sich berechtigter Weise die Frage, was IT Projektmanagement eigentlich so besonders macht, oder zumindest wo es sich vom Projektmanagement anderer Branchen unterscheidet? Könnte ein Projektmanager aus dem Bauwesen theoretisch auch die Projektleitung eines IT Projektes übernehmen? Ich würde mich da zu einem klaren JEIN verleiten lassen. Bis zu einem gewissen Grad kann ein methodisch geschulter und versierter Projektmanager, ohne jegliche IT Kenntnisse auch ein IT Projekt steuern. Doch wie in jeder anderen Branche, stößt man auch hier sehr schnell an die Grenzen. Zur Ehrenrettung aller Bau Projektmanager: das gilt natürlich auch andersherum für IT Projektmanager die ein Bauprojekt leiten wollen. Stellen wir also fest, dass es in der IT Branche, wie auch in anderen Branchen, über PM Methoden Wissen hinaus eines fundierten Fachwissens bedarf. Gut- aber das ist nichts bahnbrechend Neues. Auch in der Medizinbranche, im Flugzeugbau oder in der Raumfahrt benötigen Projektmanager technisches Fachwissen. Kann man dann wenigstens resümieren, dass sofern man über Basis IT- und Projektmanagement Fachwissen verfügt, man dann für das Management aller Arten von IT Projekte geeignet ist? Auch hier wieder ein klares JEIN. Ich habe mich vor über 20 Jahre selbständig gemacht und habe IT Projekte in ganz unterschiedlichen Disziplinen und für ganz unterschiedliche Branchen geleitet. Dabei wurde ich immer wieder vor ganz neue Herausforderungen gestellt. Herausforderungen in IT Projektdisziplinen wie • Softwareentwicklung für Desktopsysteme, • Softwareentwicklung für Webentwicklung, • Entwicklung von Embedded Systeme also Hard- und Software und deren Integration in ein Gesamtsystem • IT Infrastrukturprojekte • Organisationsprojekte uvm. Anhand der Beispiele bekommt man ein Gefühl dafür, dass überall ganz unterschiedliche Erfahrungsschwerpunkte und Fachwissen erforderlich sind. Hinzu kommt, dass jede einzelne Branche wie Banken, Versicherungen, Automotive usw. ebenfalls wieder ganz unterschiedliche Herangehensweisen, Hintergrundwissen und Praxiserfahrungen erfordern. Dann die IT interagiert in der Regel in irgendeiner Form mit den Prozessen des Anwenderkreises und die gilt es zu verstehen. Als wäre das nicht schon verwirrend genug, kommen nun die Projektmanagementlehren ins Spiel mit zahlreichen Vorgehensmodellen und Projektmanagementmethoden. Einige diese Methoden und Vorgehensmodelle nehmen schon fast religiöse Züge an und versprechen, richtig und vollständig angewandt, das Allheilmittel für den sicheren Projekterfolg zu sein. Ich glaube- es gibt so etwas wie eine „beste Methode“ nicht. Zumindest ist das mein bisheriges Fazit aus über 20 Jahren IT Projekterfahrung. Das soll nicht heißen, dass ich nichts von Projektmanagementzertifizierungen halte. Oh nein, ganz im Gegenteil. Meines Erachtens ist es die einzige vernünftige Methode sich einen messbaren und nachweisbaren Standard an Projektmanagementfachwissen anzueigenen. Ich halte nur nichts davon, eine Zertifizierung zu machen und diese dann, warum auch immer, zum Allheilmittel zu erklären. Nein, meiner Meinung nach sollte ein IT Projektmanager über einen bunten Blumenstrauß an Methodenwissen und Vorgehensmodellen verfügen. Für manche Projekte passen diese Methoden und Vorgehensmodelle perfekt, für andere müssen sie getailored werden und manchmal ist es notwendig einen Mix aus allem einsetzen und bei Bedarf an die Rahmenbedingungen anzupassen. Steht man vor der Frage, in welche Ecke der Werkzeugkiste man fassen muss, ist es hilfreich die folgenden Fragen zu stellen: 1. Handelt es sich um eine Auftragsentwicklung für einen Kunden? 2. Handelt es sich um ein InHouse Projekt für eine andere Abteilung? 3. Handelt es sich um ein Projekt dessen Ergebnis dem eigenen Team dienen soll? Betrachten wir uns die eben gestellten Fragen genauer: 1. Handelt es sich um eine Auftragsentwicklung für einen Kunden? a. Dann muss ein geeignetes Vertragswerk erstellt werden, welches den Auftrag klar und messbar formuliert b. In der klassischen Vorgehensweise, die in vielen Fällen angebracht ist, ist dann ist ein Lastenheft (regelt das WAS) und ein Pflichtenheft (regelt das WIE) zu erstellen die jeweils wiederum Vertragsbestandteil sind. c. Die Pflichten sind nach Umsetzungen durch Prüfspezifikationen und Prüfprotokolle nachzuweisen. Die Nachweise gemäß Meilensteinplanung können zahlungsbegründend sein. d. Welche Risiken stecken in dem Projekt und wie muss man diesen begegnen? e. Alternativ werden bei Agilen Vorgehensweisen oft auch eine vereinbarte Anzahl von sogenannten SPRINTS verkauft. Gerade wenn es sich um Entwicklungsprojekte mit hohem Innovationsanteil handelt, bei dem das WIE noch gar nicht klar formuliert werden kann, weil noch viel zu viel Forschungsarbeit notwendig ist, bieten sich Agile Vorgehensweisen an. Die in der IT gängigste Agile Methode ist sicherlich SCRUM. Ein SPRINT hat in der Regel eine Dauer von 2 bis 4 Wochen und am Ende eines SPRINTS steht eine lauffähige (Teil-)Produktversion anhand derer der Kunde die neuen Features begutachten kann. Vertraglich kann das so geregelt sein, dass ein SPRINT einen festen Preis hat. Der Auftragnehmer gibt zuvor eine valide Schätzung ab, in wie vielen SPRINTS er das gewünschte Ziel voraussichtlich erreichen wird. Da stets eine lauffähige Version nach einem SPRINT vorliegt, hat der Auftraggeber die Wahl noch einen weiteren SPRINT mit zusätzlicher Funktionalität zu beauftragen, oder den erreichten Entwicklungsstand erst einmal einzuführen. Soviel zumindest zur Theorie agiler Vertragsgestaltungen. 2. Handelt es sich um ein InHouse Projekt für eine andere Abteilung? a. Hier hängt das Vorgehen von der Unternehmensstruktur und Organisation ab. b. Arbeiten die Abteilungen als Cost- oder Profitcenter? c. Hat die „Auftraggeber Abteilung“ vielleicht den gleichen Bereichsleiter der auch noch der Projektsponsor ist? d. Wer ist der Projektsponsor und wo in der Unternehmenshierarchie ist er angesiedelt? e. Wie hoch ist der Innovationsgrad der in diesem Projekt steckt? f. Wie oft wurden ähnliche Projekte schon gemacht, wie hoch ist also der Routineanteil? g. Welche Risiken stecken in dem Projekt und wie muss man diesen begegenen? 3. Handelt es sich um ein Projekt dessen Ergebnis dem eigenen Team dienen soll? a. „Schmitt, wo ich Sie gerade sehe- wir haben da das Problem XY in unserer Abteilung. Setzen Sie da mal ein Projekt auf, nehmen Sie den Meier und den Müller dazu und lösen Sie es“. So oder so ähnlich gab es schon tausende Projektaufträge. Ich kann jedem nur empfehlen es bei solchem „Zuruf“ nicht zu belassen, sondern sehr wohl die Ziele schriftlich zu formulieren und bestätigen zu lassen. Häufig wird aber leider einfach begonnen, da selbst der „Chef“ keine Lust auf Formalien hat…“Das Problem ist doch klar, der Schmitt wird schon wissen was zu tun ist“. Handelt es sich um ein Projekt das in wenigen Tagen erlegt ist und man stellt erst am Ende fest dass der Chef eigentlich etwas anderes wollte, ist nicht viel Geld kaputt gemacht. Handelt es sich aber um ein komplexeres Projekt über mehrere Monate und einer Vielzahl von Mitarbeitern und stellt man auch hier erst am Ende fest, dass man zwar die Leiter erklommen hat, dass diese Leiter aber an der falschen Hauswand stand, dann wird es teuer. Spätestens wenn sich solche Projekte häufen, wird es teuer und man muss die methodische Vorgehensweise dringend überdenken. So gesehen gibt es also nicht nur eine Reihe von Rahmenbedingungen in der IT die für sich genommen jeweils ganz unterschiedliches Know How und Erfahrung erfordern, jede Disziplin kann in unterschiedliche Rahmenbedingungen eingebettet sein. Betrachten wir uns diese IT Projektdisziplinen etwas genauer und was dahinter steckt. Ich lasse dabei die zuvor erwähnten Rahmenbedingungen weg, um uns den einzelnen Facetten erst einmal von hoher Flughöhe her zu nähern. IT Projektdisziplinen Mir ist immer wieder unverständlich, warum selbst die IT Projektmanagement Fachliteratur, IT Projekte so häufig auf die Softwareentwicklung reduziert. Neben der klassischen Softwareentwicklung gibt es • Embedded System Entwicklung • IT Infrastrukturprojekte • Softwareevaluierungsprojekte • IT Rollout Projekte • Migrationsprojekte • Customizing Projekte • IT Umzugsprojekte • Oder Organisationsänderungsprojekte Doch betrachten wir uns diese IT Projektdisziplinen und deren jeweilige Anforderungen an den Projektmanager im Einzelnen: Softwareentwicklungsprojekte Damit meine ich die klassische Individualsoftwareentwicklung. Diese kann eine Auftragsentwicklung mit einem Auftraggeber und einem Auftragnehmer sein, oder es handelt sich um eine Eigenentwicklung wie z.B. einem Start-up Unternehmen das nach der Entwicklung mit einem Produkt an den Markt geht. Im ersten Fall hat ein Auftraggeber hat ein Problem, dass mit Hilfe einer Softwareproduktes gelöst werden soll. Beispielsweise wäre hier eine Software zu entwickeln, mit deren Hilfe Datenhaltung in einem Rechenzentrum zentralisiert wird die heute verstreut in einzelnen Exceltabellen herumliegt. Aber auch die Entwicklung komplexer Webanwendungen oder Portale falle und unter diese Kategorie. Im zweiten Fall wird eine Produktidee verwirklicht. Häufig mit Hilfe von Venture Capitals oder Business Angels welche die Finanzierung übernehmen und in die Projektidee investieren. Anforderungen an den Projektmanager Bei dieser Projektart sollte der Projektmanager zum technischen Verständnis über Entwicklungserfahrung und Softwarearchitekturkenntnisse verfügen. Wichtig ist die Geschäftslogik hinter dem zu entwickelnden System zu verstehen und je nach Rahmenbedingungen das Vorgehen festzulegen. Im Fall von Fremdfinanzierung spielt der Return of Invest (ROI) bzw. der Business Case eine große Rolle und muss ständig überprüft werden um die Investoren stets über den aktuellen Stand auf dem Laufenden zu halten. Embedded System Entwicklung Hierbei handelt es meist sich im die Kombination aus Hardware und Softwareentwicklung. Die Entwicklung von Smartphones, VOIP Telefone, Navigationssysteme, CTI Computer Telefon Integration, oder Druckmaschinen fallen unter diese Rubrik. Die besondere Herausforderung liegt in der Anforderungsermittlung, der koordinierten Entwicklung der Hardware- und der einzelnen Softwareschichten, sowie die anschließende Integration von Hard und Software zu einem Gesamtsystem. Anforderungen an den Projektmanager Bei dieser Projektart sollte der Projektmanager zum technischen Verständnis über Hard- und Softwareentwicklungs und Architekturkenntnisse verfügen, sowie Erfahrung in der Systemintegration mitbringen. IT Infrastrukturprojekte Bei diesen Projekten handelt es sich häufig um typische Rechenzentrums- oder Datacenter Projekte. Ein Kunde, nehmen wir als Beispiel eine Bank, nutzt einen Rechenzentrumsdienstleiter als Hoster seiner Infrastruktur welche dieser als Dienstleistung anbietet. Benötigt eben diese Bank z.B. 500 neue eMail Postfächer für deren Mitarbeiter, wird im Rechenzentrum ein Projekt aufgesetzt um die Infrastruktur bereit zu stellen. Nach der Planung und Dimensionierung werden physische Server bereitgestellt, oder virtuelle Server aufgesetzt, es werden Mailserver und Datenbankserver aufgesetzt und eingerichtet, es werden Firewall und Routerkonfigurationen durchgeführt, es werden VPNs eingerichtet, Zertifikate und Schlüssel für die gesicherte Kommunikation generiert, Datensicherungen für Mailserver und Datenbankserver eingerichtet und Virenschutz installiert. Je nach vereinbarter Verfügbarkeit dieses Systems, welche in der Regel in Form von SLAs definiert werden, müssen Redundanzen geschaffen werden um potenzielle Ausfallzeiten auf ein Minimum zu reduzieren. Anforderungen an den Projektmanager Bei dieser Projektart sollte der Projektmanager über fundierte IT Infrastrukturkenntnisse verfügen. Er sollte das ISO/OSI Schichtenmodell beherrschen, die grundsätzliche Funktionsweise aktiver und passiver Netzwerkkomponenten beherrschen sowie über ein Systemverständnis verfügen. Sehr wichtig ist ebenfalls ein fundiertes Wissen zu IT Servicemanagementprozessen nach ITIL. An dieser Stelle möchte ich den Ersten Teil dieser Folge enden lassen und freue mich schon in der nächsten Woche auf den 2. Teil. Ich hoffe es hat Ihnen bis hierhin Spaß gemacht und Sie sind auch in der nächsten Woche wieder mit dabei. Bitte denken Sie daran, dass noch bis Ende März 2015 die Interview Aktion läuft. Das bedeutet, dass ich mit Ihnen ganz persönlich ein Interview zu einem Thema Ihrer Wahl aus dem Bereich IT Projektmanagement führe. Lassen Sie uns teilhaben an Ihrer praktischen Berufserfahrung. Was ist Ihnen in Ihrer Laufbahn besonders gut gelungen und was waren die Erfolgsfaktoren dazu. Wo ist vielleicht eines Ihrer Projekte gescheitert und was haben Sie daraus gelernt? Vielleicht haben Sie auch ein Spezialgebiet auf dem Sie ganz besonders viel Erfahrung haben. Ein Interview ist nicht nur für selbständige interessant um die eigenen Dienstleistungen kostenfrei und langfristig zu bewerben, sondern Sie machen damit auch als Angestellter Ihre Expertise sichtbar und profilieren sich für sich und Ihren Arbeitgeber. Alles was Sie dazu tun müssen ist noch bis Ende März 2015 unseren Newsletter zu abonnieren und mir eine Bewerbungsmail mit dem Thema zu senden, über das Sie sprechen möchten. Keine Sorge, ich nehme Ihnen dabei fast alles ab und es läuft für Sie ganz unkompliziert. Also, ich freue mich auf Ihre Bewerbung und ich freue mich auf den zweiten Teil dieser Folge in der kommenden Woche. Bis dahin wünsche ich Ihnen viele grünen Meilensteine Ihr Andreas Haberer Weitere Informationen finden Sie unter www.Bundesvereinigung-ITPM.de

In allen menschlichen Dingen zeigt sich bei genauer Prüfung, dass man nie einen Übelstand beseitigen kann, ohne dass ein anderer daraus entsteht. Wir müssen daher bei all unseren Entschlüssen erwägen, wo das kleinere Übel liegt, und den danach gefassten Entschluss für den besten halten, weil alles auf der Welt seine Schattenseiten hat. Niccolò Machiavelli, 1469 – 1527, ital. Politiker und Philosoph 1.1 Die Folge 13 Wie trifft man effektive Entscheidungen Hallo und herzlich willkommen zur Folge 13 unseres Podcasts „IT Projektmanagement“. Bevor ich zum eigentlichen Thema komme, möchte ich noch einmal über die aktuell laufende Aktion informieren. Ich biete Ihnen nur im März die Möglichkeit eines kostenlosen Interviews an. In diesem Interview unterhalten wir uns über Ihre Erfahrungen und Schwerpunkte im Bereich des IT Projektmanagement. Dabei ist es völlig egal, ob Sie angestellt, oder selbständig sind. Als Angestellter unterstreichen Sie Ihre Kompetenz und haben einmal die Gelegenheit über Ihre Erfolge zu berichten. Als Selbständiger haben Sie die einmalige Gelegenheit eine langfristige und nachhaltige Marketing und Image Maßnahme für sich und Ihr Unternehmen zu platzieren. Nachhaltig deswegen, weil ein Podcast auch Jahre nach der Produktion noch gehört wird und somit langfristig für Ihre Leistungen wirbt. Wenn Sie interessiert sind, gehen Sie auf unsere Hompage www.Bundesvereinigung-ITPM.net und abonnieren Sie dort unseren Newsletter in dem Sie alles Weitere erfahren. Ich freue mich schon auf Sie. Doch nun zu unserem eigentlichen Thema. In der letzten Folge ging es darum, wie schwierig es manchmal ist, sich dazu durchzuringen eine Entscheidung zu treffen. Doch selbst wenn ich mich durchringe eine Entscheidung zu treffen, wie mache ich das richtig? Meine Tochter geht in die 12 Klasse eines Wirtschaftsgymnasiums und seit etwa 2 Jahren intensivieren sie im Fach Wirtschaftsinformatik das Programmieren. Es war noch recht am Anfang als ich ihr über die Schulter schaute und sie gerade ein Übungsprogramm debuggte, das durch eine Reihe von If und Case Konstrukte lief, also durch einen Entscheidungsbaum. Ich schmunzelte und stellte dabei wieder einmal fest, dass es so ein Computerprogramm doch sehr einfach hat, klare Entscheidungen zu fällen. Wenn im echten Leben die Kriterien auch immer so knallhart auf dem Tisch liegen würden, dann wären die Entscheidungen im Job häufig sicher einfacher. Entscheidungen zu treffen ist, in der Praxis oft kein triviales Thema. Und doch ist klar, dass wir als Projektmanager eine Führungsaufgabe haben und nur wer Entscheidungen trifft, ist eine Führungskraft. Demzufolge bedeutet im Umkehrschluss aber auch, dass derjenigt- ganz ungeachtet seines Rangs, seines Titels oder sonstiger Reputation, der keine Entscheidungen trifft, auch keine Führungskraft ist. Als Entscheidungsträger müssen wir also nicht nur zu Entscheidung legitimiert sein, wir sind demnach auch verpflichtet von dieser Legitimation nach bestem Wissen und Gewissen Gebrauch zu machen. In der beruflichen Praxis geht es aber nicht darum möglichst viele-, sondern die Wichtigen Entscheidungen zu treffen. Wer effektiv in seinen Entscheidungen sein möchte versucht Klarheit darüber zu gewinnen, was von strategischer Bedeutung und nachhaltig ist. Auf das Verständnis, worum es in der Entscheidung eigentlich geht und welchen Gegebenheiten sie Rechnung tragen muss, kommt es an. Es geht also um die Wirkung und nicht darum besonders einfallsreich zu sein. Das Gute daran ist, dass die Richtige Entscheidung meist irgendwo zwischen dem richtigen- und dem falschen Kompromiss liegt. Das ist sicher gut zu wissen, macht es aber nur bedingt einfacher. Das wichtigste an einer Entscheidung ist, dass diese auch in eine Handlung mündet. Solange das nicht sichergestellt wird, hat man keine Entscheidung sondern bestenfalls eine Absichtserklärung. Diese Handlungen sollten so einfach und praxisgerecht wie möglich sein. 1.2 Aber ist eine Entscheidung wirklich nötig? Leider vergessen viele diese, eigentlich recht einfache Frage zu stellen. Eine Alternative besteht immer darin, nichts zu tun. Ein IT Projekt ist immer auch ein System und eine Entscheidung ist mit einem chirurgischen Eingriff in dieses System vergleichbar. Ein guter Entscheidungsträger fällt nicht mehr unnötige Entscheidungen, wie ein guter Chirurg unnötige Operationen durchführt. Eine Entscheidung ist dann erforderlich, wenn eine Situation, ohne Entscheidung außer Kontrolle zu geraten droht. Für eine sich bietende Chance gilt da übrigens das Gleiche. Auf der anderen Seite gibt es Situationen von denen man ohne übertriebenen Optimismus sagen kann, dass sie sich alleine regeln werden. Lautet die Antwort auf die Frage „was passiert, wenn wir nichts unternehmen- also keine Entscheidung treffen“: „Nichts“, dann sollte man auch nichts unternehmen. Häufig sind Situationen zwar störend, haben aber langfristig keinerlei Folgen. Wenn die Beseitigung eines Problems nichts nutzen wird, dann ist es besser keine Entscheidung zu treffen. Zumindest sollte das Risiko des Eingriffs, dem Risiko der Untätigkeit gegenübergestellt und abgewogen werden. Peter F Drucker sagt dazu: „Handle, wenn der Nutzen die Kosten und Risiken deutlich überwiegt. Handle, oder bleibe untätig, aber versuche Dich nicht abzusichern oder Kompromisse zu schließen“. Entfernt ein Chirurg nur eine Mandel, dann sind die Risiken ebenso hoch, als hätte er die OP gleich richtig gemacht. Zumal der Patient nur die Schmerzen und keinen langfristigen Nutzen haben wird. Dasselbe gilt für den Entscheider. Der Effektive Entscheider handelt, oder lässt es sein. 1.3 Doch was genau ist eigentlich eine Entscheidung? Schauen wir dazu nach was Wikipedia sagt: „Eine Entscheidung ist eine Wahl zwischen Alternativen oder zwischen mehreren unterschiedlichen Varianten von einem oder mehreren Entscheidungsträgern in Zusammenhang einer sofortigen oder späteren Umsetzung. Eine Entscheidung kann spontan bzw. emotional, zufällig oder rational erfolgen.“ 1.4 Kopf, oder Bauch…wer hat jetzt entschieden? Ich entscheide mich den ganzen Tag- häufig ohne dass es mir wirklich bewusst wird. Das beginnt schon am frühen Morgen: Stehe ich auf, oder bleibe ich noch ne Runde liegen? Welches Hemd ziehe ich heute an? Trinke ich noch eine Tasse Kaffee, oder fahre ich gleich los? Die Wissenschaft ist sich einig, dass solche Entscheidungen meist auf einer Reihe von inneren Abwägungen basieren. Es ist also wirklich beeindruckend wie geschwätzig mein inneres Selbst schon so früh am Morgen ist… Diese Abwägungen interagieren mit Erfahrungen die tief in unserem Unterbewusstsein gespeichert sind. Je mehr und intensivere Erfahrungen wir also gemacht haben, umso größer sind die inneren Abgleichmöglichkeiten bei einem Entscheidungsprozessen. Genau das versteht man darunter, wenn man vom „Bauchgefühl“ spricht. Wenn man eine Entscheidung rational fällt, also mit dem bewussten Anteil unseres Denkens und ein „ungutes“ Gefühl kommt damit hoch, dann ist das die Art, wie sich unser Unterbewusstsein bemerkbar macht. Der Abgleich mit den eigenen Erfahrungen prüft also rational gefällte Entscheidungen und warnt uns vor möglichen Fehlentscheidungen gemäß der eigenen Erfahrungen. Viele der alltäglichen Entscheidungen sind tatsächlich solche Bauchentscheidungen, sei es der Griff nach der sogenannten „Quengelware“ im Supermarkt, also das Zeug dass links und rechts der Kasse aufgetürmt ist während man wartet, oder seien es andere spontane Entscheidungen über die wir nicht groß nachdenken, oder sie rational abwägen. Nur bei wirklich wichtigen Entscheidungen, zieht der Mensch rationale-, also verstandesgemäße und bewusste Informationen hinzu. Häufig sind es aber genau diese Art von Entscheidungen, die uns in der täglichen Berufspraxis begegnen. Denn von solchen Entscheidungen hängt unter Umständen der Erfolg, oder Misserfolg unseres Projektes ab. Leider kenne ich keinen Kollegen, der immer nur richtige Entscheidungen trifft, wahrscheinlich wäre es auch sinnfrei nach so jemandem zu suchen. Die Kunst besteht also darin, mehr Richtige, als Falsche Entscheidungen zu treffen. Na, das klingt ja einfach. 1.5 Doch wie geht man dazu vor? Man sollte meinen, dass eine Entscheidung umso leichter fällt und damit schneller gefällt werden kann, je kleiner die Unsicherheit ist und umso mehr Informationen zur Entscheidung vorliegen. Aber stimmt demnach der umgekehrte Fall, dass eine Entscheidung umso länger abgewägt werden muss, je größer die damit verbundenen Ungewissheiten und die sich aus der Entscheidung ergebenden Konsequenzen sind. Man sollte meinen, dass solche Entscheidung automatisch nun einen rational durchgeführten Entscheidungsprozess durchlaufen müssten. Doch ist das wirklich so? Ein Notarzt in der Notaufnahme trifft blitzschnelle Entscheidungen, die sich in aller Konsequenz auf das zukünftige Leben des Patienten auswirken werden. Solche Entscheidungen sind wichtig und haben dramatische Auswirkungen- doch der Notarzt muss solche Entscheidungen oft innerhalb von Sekunden und auf Basis der jetzt zur Verfügung stehenden Informationen fällen. Es liegt auf der Hand, dass für solche Entscheidungen auf die eigenen Erfahrungswerte zurückgegriffen werden muss, die im nicht rationalen Teil unseres Hirns abgelegt sind. Demnach ist es die Erfahrung, die eine zwingende Voraussetzung ist, schnelle Entscheidungen zu treffen. Die Folgen dieser Entscheidung werden sehr schnell sichtbar und durch dieses Feedback wird die getroffene Entscheidung bewertet- was zukünftige Entscheidungen beeinflussen wird. Da die zur Verfügung stehenden Informationen häufig nicht ausreichend und damit belastbar für eine Entscheidung sind, stützt sich der Arzt auf eine Hypothese- und auf Basis dieser Hypothese entscheidet er. Ich habe den höchsten Respekt vor Ärzten in der Notaufnahme und all den Menschen, die mit ihren täglichen Entscheidungen über das Leben anderer entscheiden. Glücklicherweise entscheiden unsere Entscheidungen als IT Projektmanager meist nicht über Leben und Tod. Daher ist unsere Berufsgruppe auch meist nicht in der Zwangslage Entscheidungen innerhalb von wenigen Sekunden oder noch weniger treffen zu müssen. Wenn es der Entscheidungsrahmen also zulässt, ist es ratsam eine Entscheidung sorgsam abzuwägen- aber dann am Ende nochmal auf das Bauchgefühl zu hören. Eine Entscheidung ist also das Ergebnis eines „Kostenvergleichs“ der Vor- und Nachteilen der jeweiligen Alternativen. Fällt der Entscheider eine Entscheidung nicht, resultiert dies meist aus erkanntem Unwissen bzw. der Unklarheit über die Konsequenzen der favorisierten Möglichkeit. Entscheidungsschwäche resultiert aus der unbewussten Ablehnung der mit der Lösung verbundenen Nachteile. Aber wie eingangs gesagt, ist auch die bewusste Nicht-Entscheidung eine Entscheidung und diese darf nicht von vorne herein ausgeschlossen werden. Jede Entscheidung zieht Konsequenzen nach sich und hat das Ziel den Status Quo zu verändern, sonst bräuchte man ja die Entscheidung nicht. Man sollte einen notwendigen Entscheidungsbedarf möglichst früh sichtbar machen. Meist kann in der Entstehungsphase eines Problems, dies noch mit recht wenig Aufwand abgeschwächt oder beseitigt werden. Je länger ein Problem gärt, umso größer sind meist die Auswirkungen und umso wirkungsloser können dann nur noch Entscheidungen sein. 1.6 Wie geht man vor, wenn man Effektive Entscheidungen treffen will? Es macht Sinn, sich insgesamt über ein paar Punkte Klarheit zu verschaffen: 1. Da ist die Klärung, was die Grenzbedingungen sind, welche die Entscheidung erfüllen muss? o Eine Entscheidung, egal wie brillant sie auch sein mag, ist wirkungslos wenn sie ihre Grenzbedingungen nicht erfüllt. Die Frage dazu lautet, was wird mindestens benötigt, um das Problem zu lösen? Friedmund Malik spricht in diesem Zusammenhang von Mindestanforderungen an eine Entscheidung o Welche Ziele sollen mit der Entscheidung erreicht werden? o Grenzbedingungen dürfen nicht unvereinbar miteinander sein. Wenn Sie über ein Vorgehen im Projekt entscheiden müssen und die eine Grenzbedingung fordert, jedes erdenkliche Feature zu bieten, eine zweite fordert, dass der Preis aller Mitbewerber unterboten werden muss, wird das schwierig. Man kann zwar nicht völlig ausschließen, dass eine derartige Entscheidung doch von Erfolg gekrönt wird. Aber das Problem mit Wundern besteht nicht darin dass sie selten sind, sondern dass man sich nicht auf sie verlassen kann. 2. Sich auf die richtigen Lösungen für die gegebenen Rahmenbedingungen konzentrieren, ohne gleich über Kompromisse nachzudenken fällt oft nicht leicht. Viele bringen hier schon sehr früh vermeintliche Zugeständnisse ins Spiel die man für notwendig erachtet, um die erforderliche Akzeptanz zu gewinnen. o Am Ende muss man bei einer Entscheidung meist einen Kompromiss eingehen. Das Problem ist, konzentriert man sich zu früh auf Kompromisse, so ist man nicht in der Lage zwischen dem Richtigen und dem Falschen Kompromiss zu unterscheiden und wird am Ende den Falschen eingehen. o Man gewinnt zu diesem Zeitpunkt nichts, wenn man sich mit der Frage beschäftigt, was akzeptabel ist. Man beraubt sich statt dessen damit dem Blick auf die richtige Lösung 3. Erst jetzt denkt man über die Maßnahmen nach, die zur Umsetzung der zu treffenden Entscheidung notwendig sind. o Wer muss von der getroffenen Entscheidungen wissen? o Welche Maßnahmen sind zu ergreifen und wer hat dabei was zu tun? o Wie müssen die Maßnahmen gestaltet sein, damit die Menschen die diese umsetzten müssen dazu im Stande sind? 4. Feedback einholen, anhand derer die Wirksamkeit und die Richtigkeit der getroffenen Entscheidung gemessen werden kann. o Entscheidungen werden von Menschen gefällt und Menschen begehen Fehler o Das Problem mit Berichten und Statistiken ist, dass diese aus einem ganz bestimmten Blickwinkel erstellt wurden. Die einzige zuverlässige Methode Feedback einzuholen liegt darin, persönlich nachzusehen. o Es geht hier nicht darum, dass dem Mitarbeiter zu misstrauen. Die Erfahrung zeigt, dass man der Kommunikation misstrauen muss. Gibt es eine Art „Best practice“ um gute Entscheidungen zu treffen? Ja, die gibt es. Die FOR-DEC Methode zur Entscheidungsfindung fasst im Wesentlichen das zuvor gesagte in ein Vorgehensmodell zusammen. Die Methode hat sich in den letzten Jahren vor allem in der Luftfahrt bewährt. Zwischen den ersten- und den letzten drei Buchstaben ist ein Bindestrich, der damit auch die Zweiteilung des Entscheidungsprozess kennzeichnet. Die Buchstaben des Akronyms bezeichnen die einzelnen Schritte, die zur Entscheidungsfindung führen. Sie stehen für Facts, Options, Risks & Benefits- Decisions, Execution, Check. Facts: Welche Situation liegt vor? Options: Welche Handlungsoptionen bieten sich an? Risks & Benefits: Welche Risiken und Nutzen sind mit den jeweiligen Handlungsoptionen verbunden? - Decision: Welche Handlungsoption wird gewählt? Execution: Ausführung der gewählten Handlungsoption. Check: Führt der eingeschlagene Weg zum gewünschten Ziel? Der Bindestrich "-" trennt die Phasen der Situationsanalyse vom restlichen Entscheidungsprozeß. Er symbolisiert quasi einen kurzen Moment des Innehaltens, bevor die favorisierte Option umgesetzt wird. Dieser Moment kann in Situationen, in denen es auf eine sehr präzise Situationsdiagnose ankommt, verhindern dass durch Hektik, oder starke Vorannahmen wichtige Elemente übersehen werden. Es wird angenommen, dass Entscheidungen robuster gegen vorschnelle Impulse und Gefühlseinflüsse sind, wenn sie nach dieser Regel getroffen werden. In dynamischen Situationen wie zuvor beschrieben, könnte allerdings auch ein Nachteil dadurch entstehen, dass Entscheider ohne Zeitgefühl versuchen, immer die "optimale" Lösung zu finden. Wenn in zeitkritischen Situationen Handlungsdruck besteht, sollte zunächst eine Option gewählt werden, die die Sicherheitslage steigert und möglichst weitere Zeitreserven bringt. Aktuell findet FOR-DEC hauptsächlich im Luftverkehr und in der Medizin Anwendung. Das Prinzip der strukturierten Entscheidungsfindung ist allerdings universell anwendbar. Allerdings bin ich mit dem „F“ in dieser Methode, also Facts, nicht ganz einverstanden. Eine Entscheidung erfordert eine Wahl zwischen Alternativen. Selten ist die zu treffende Situation so schwarz weiß dass man zwischen richtig und falsch entscheiden muss. Meist liegt die Wahl eher bei „fast richtig“ und „wahrscheinlich falsch“. Auch in den meisten Fachbüchern über Entscheidungen liest man, dass man zuerst nach den Fakten suchen soll. Meine Erfahrung sagt mir, dass man in der Regel nicht mit Wissen, sondern mit Meinungen beginnt. Dabei handelt es sich um Hypothesen die selbstverständlich erst einmal nur geringen Wert haben, solange sie nicht in der Realität überprüft wurden. Es ist kaum möglich als erstes die Fakten zu erheben. Ereignisse an sich sind keine Fakten in diesem Sinn. Wenn ich jemanden beauftrage, nach den Fakten zu suchen, wird er das naheliegende tun und die Fakten suchen, die in sein Weltbild passen. Am Anfang steht eine Meinung und das ist gut so. Denn mit Hypothesen können wir alle umgehen. Hypothesen widerspricht man nicht, sondern man überprüft sie. So findet man heraus, welche haltbar und welche den ersten Test nicht bestehen. Die besten Lösungen in meiner beruflichen Praxis sind dort entstanden, wo unterschiedliche Meinungen und unterschiedliche Hypothesen leidenschaftlich ausdiskutiert worden. Man fördert damit also zunächst die Entwicklung unterschiedlicher Meinungen, die anschließen besprochen, dokumentiert und durchdacht werden müssen. Werden solche Diskussionen richtig moderiert, können sie die Teilnehmer zu kreativen Höchstleitungen antreiben. Doch achten Sie stets darauf, dass Sie nicht die eigene Meinung automatisch zur richtigen erklären. Ebenso wenig gehen Sie davon aus, dass Sie Recht haben und die anderen im Unrecht sind. Zeigen Sie stattdessen von Anfang an Interesse daran herauszufinden, warum der Gegenüber anderer Meinung ist. Vermeiden Sie es unbedingt den Gegenüber für einen Dummkopf, oder Störenfried zu halten. Gehen bis zum Beweis des Gegenteils davon aus, dass er kompetent und wohlmeinend ist. Es gibt stets mehrere Realitäten und jeder betrachtet ein Problem aus seiner eigenen Erfahrung und Perspektive heraus. Versuchen Sie herauszufinden, was sieht der Gegenüber, dass seine Position haltbar, vernünftig und intelligent macht. Bemühen Sie sich also in erster Linie um Verständnis. Erst wenn dieses Verständnis erreicht ist, beginnt sie darüber nachzudenken, wer im Recht und wer im Unrecht ist. Weitere Informationen finden Sie unter www.Bundesvereinigung-ITPM.de

Max Grundig, einer der erfolgreichsten deutschen Nachkriegsunternehmer, wurde einmal gefragt: 'Sagen Sie bitte, Herr Grundig, nach welchen Kriterien treffen Sie eigentlich Ihre Entscheidungen?' Da lehnte sich der Patriarch zurück, tippte zunächst mit dem Finger an die Stirn und deutete dann auf seinen Solarplexus: 'Ich überlege. Mein Bauch entscheidet.' 1.1 Die Folge 12: Entscheidungen treffen Hallo und herzlich willkommen zur Folge 12 unseres Podcastes IT Projektmanagement. Nachdem es in den letzten beiden Folgen um ein Interview zum Deutschen Project Excellence Award ging, sind wir heute wieder ganz unter uns. Wir haben übrigens aktuell eine Aktion laufen. Wenn Sie möchten, führen wir zusammen ein Interview durch im Rahmen dessen Sie sich, Ihr Spezialgebiet und Ihre Leistungen präsentieren dürfen. Das alles völlig kostenlos. Wir interessieren uns dabei für Erfahrungen im IT Projektmanagement, aber auch mit IT Projektmanagern. Engagieren Sie externe Projektmanager in Ihrem Unternehmen? Worauf legen Sie da besonderen Wert? Sind Sie vielleicht ein Bodyleasingunternehmen und vermitteln IT Projektmanager? Welche Erfahrungen haben Sie dabei gemacht? Haben Sie als Teammitglied unterschiedliche Erfahrungen mit IT Projektmanagern gemacht? Ich bin sehr gespannt. Vielleicht haben Sie aber auch einfach ein sehr spannendes, oder besonders erfolgreiches Projekt hinter sich und wollen uns davon berichten…ich freue mich drauf. Sie beschäftigen IT Projektmanager in Ihrer Abteilung, oder Ihrem Unternehmen? Was ist Ihnen dabei besonders wichtig? Alles was Sie tun müssen um mitzumachen, ist sich bis 31.März 2015, sofern nicht schon längst geschehen, in unseren Newsletter einzutragen. Wie sie sicher wissen, können Sie das unter www.Bundesvereinigung-ITPM.net tun. Schicken Sie mir danach eine eMail mit einem kurzen formlosen Bewerbungsschreiben, was der Inhalt unseres Interviews sein soll. Im Interview dürfen sie dann auch richtig Werbung für sich machen, schließlich sind wir genau dafür da. Beachten Sie bitte, dass die Aktion nur im März 2015 gilt. Die Entscheidung welche Themen wir zum Interview annehmen und ob wir ein Interview am Ende tatsächlich veröffentlichen behalten wir uns vor. Der Vollständigkeit halber: „Der Rechtsweg ist ausgeschlossen ;-)“. Also, keine Hemmungen, ich freue mich auf Ihre Bewerbung. So- und nun zu unserem eigentlichen Thema, nämlich der Frage, warum es oft so schwer ist Entscheidungen zu treffen. Im Dezember 2003 rückte ein lang ersehnter Traum ganz plötzlich in greifbare Nähe. Viele Jahre hatten meine Frau und ich schon erfolglos versucht, ein bezahlbares gebrauchtes Haus oder ein Baugrundstück in unserem Ort zu finden. Urplötzlich wurde uns von der Gemeinde in einem frisch ausgerufenen Neubaugebiet ein Grundstück angeboten. Wir hatten in diesem Neubaugebiet praktisch freie Auswahl, weil wir tatsächlich die ersten Interessenten waren. Wir erfuhren, dass die Erschließung erst 6 Monate später fertig sein wird. Erst dann müssen wir zahlen und können dann unmittelbar mit dem Bau beginnen. Zusammen mit meiner Frau und unserem Steuerberater berieten wir uns kurz und sagten zu. In den Folgemonaten kümmerten wir uns um eine Vielzahl von Dingen für den anstehenden Hausbau. Darunter natürlich auch die anstehende Finanzierung. Ein sehr enger Freund und Fachmann auf diesem Gebiet unterstütze uns dabei und handelte ein Angebot für mich aus, dass für die damalige Zeit und dem Umstand geschuldet dass wir ja selbständig sind, sehr ordentlich war. Ich hatte das Finanzierungsangebot schriftlich und ging, unerfahren wie ich leider damals noch war, davon aus, dass damit nun alles notwendige in die Wege geleitet ist. In den folgenden Monaten fragte ich meinen Freund hin und wieder ob ich noch etwas machen muss, aber ich wurde damit beruhigt, dass ja noch Zeit ist. Einige Monate später bekam ich das GO von der Stadt und ich gab wiederum meinem Rohbau Unternehmer grünes Licht, dass der Keller ausgehoben werden kann. Es war ein herrlicher Sommermorgen und ein mindestens genauso tolles Gefühl, als der Radlader und die Lastwagen ankamen, um nun endlich mit dem Bau unseres Hauses zu beginnen. Etwa zu gleichen Zeitpunkt nahm ich Kontakt mit dem Baufinanzierer auf und bat sie doch langsam in die Gänge zu kommen und mir die restlichen Unterlagen zu schicken…schließlich ist bald die erste Zahlung fällig. Einige Tage später traf es mich dann wie die Rechte von Vitali und eine Linke Wladimir Klitschko gleichzeitig. In einem Schreiben des Baufinanzierers bedauerte man, dass man meine Finanzierung ablehnen müsse, da die Risikoprüfung zu einem negativen Ergebnis gekommen ist. Was sollte ich jetzt tun? Mittlerweile war die Baustelle komplett eingerüstet. Die Baugrube für den Keller war ausgehoben, ein Kran stand fertig aufgebaut auf unserem Grundstück und alles war bereit loszulegen. Alleine die bis dahin aufgelaufenen Kosten würden mich ohne Finanzierung wahrscheinlich ruinieren. Ich wusste nicht was ich tun sollte und war wirklich am Boden. An diesem Abend saß ich mit einem Freund mit einer Kiste Bier in der Baugrube und hätte mich am liebsten beerdigen lassen. Ich habe damals dieses bittere Gefühl kennen gelernt, dass Dir sagt, das jetzt alles aus ist. Ich hatte keine Idee wie ich aus der Nummer wieder heraus kommen sollte. An diesem und in den nächsten Tagen hatte ich eine regelrechte Schockstarre und steckte buchstäblich den Kopf in den Sand. Ich war ein Opfer- zumindest fühlte und verhielt ich mich so. Ich fühlte mich falsch beraten und um meine Finanzierung betrogen. Ja vielleicht sogar um meine Zukunft betrogen. Ich konnte alle benennen die daran Schuld hatten, dass ich in dieser Situation war. Ich versank in meiner Opferrolle und es dauerte zwei oder drei Tage bis ich mir das erste Mal die entscheidende Frage stellte „an der gegeben Situation kann ich jetzt wirklich nichts mehr ändern, was mache ich jetzt um da rauszukommen!?“ Hätte ich mich weiter nur mit der Vergangenheit beschäftigt, die Fehler bei anderen gesucht und die Ungerechtigkeit beklagt, die mir widerfahren ist und nicht begonnen mich an der eigenen Nase zu fassen, hätte die Situation sehr schlimm für meine Familie und mich ausgehen können. In dem Moment, als ich mich zum ersten Mal ernsthaft fragte, wie ich aus der Nummer herauskomme, traf ich eine Entscheidung, dass ich mich mit der Situation nicht abfinden werde und egal was passiert, einen Weg heraus finde. Hätte ich damals nicht die Entscheidung getroffen, alle Hebel in Bewegung zu setzen, um da heraus zu kommen, wer weiß was aus uns geworden wäre. Ich stachelte mich richtig an, setzte mich an meinen Rechner und suchte mir alle online Baufinanzierer heraus die ich finden konnte. Ich bereitete Berge von Antragsunterlagen auf, kopierte und versandte sie. Ich nahm Kontakt mit dem Baufinanzierer auf der mich abgelehnt hatte und machte dort ordentlich Rabatz meinen Antrag erneut zu prüfen. Ja, ich vereinbarte sogar einen Termin mit dem Direktor der damaligen Hausbank meiner Firma. Ich schlug dort im teuren Anzug und teurer Uhr zu diesem Termin auf und erklärte hochmütig, dass ich gerade ein Haus baue und meiner Hausbank natürlich auch die Möglichkeit geben will daran mitzuverdienen. Schließlich arbeiten wir schon lange erfolgreich zusammen…ich war bereit alles zu versuchen. Ich gebe zu, das war eine klassische Blenderaktion, aber ich ließ nichts unversucht. Dann kam irgendwann der lang ersehnte Anruf einer der online Banken und ich wurde zur ersten verbindlichen Finanzierungszusage beglückwünscht. Plötzlich lief es rund. Auch meine Blenderaktion bei meiner Hausbank hatte Früchte getragen, zwar waren die Konditionen nicht wirklich gut aber ich hatte nun Zwei zusagen. Zu guter Letzt meldete sich sogar mein ursprünglicher Finanzierer und teilte mit, dass bei der Berechnung Einnahmen vergessen hätte und man die Finanzierung nun doch macht. Tatsächlich kamen in den nächsten Tagen noch einige hinzu und am Ende stand ich noch sehr viel besser da als ich zunächst erwartet hatte. Sie glauben nicht, was mir ein Stein vom Herzen viel, als endlich die unterschriebene Baufinanzierung auf meinem Schreibtisch lag. Was haben meine Hausbauprobleme in einem Podcast über IT Projektmanagement zu suchen? Mir geht es um die Entscheidung die ich damals getroffen habe und um den Umstand, dass ich mich förmlich am eigenen Schopf aus dem Schlamassel gezogen habe. Eine Entscheidung zu treffen ist nämlich gar nicht so einfach. Sich in einer solchen Situation aus der Opferrolle zu lösen, ist noch schwerer. Und je mehr ich Jahre danach über diese Zeit reflektierte, mich daran erinnerte wie sehr ich am Boden war, umso stolzer bin ich darauf mit dieser einen Entscheidung alles zum Guten gewendet zu haben. Irgendwie erinnert im Nachhinein betrachtet das Ganze an eine Szene die ich einmal in unserem Freibad beobachtet habe. Wir haben dort einen 3 Meter Sprungturm und eine Reihe etwa 10 jähriger Jungs machten regen Gebrauch davon. Alle waren gesprungen, nur einer stand noch da oben. Er zitterte weil er schon so lange stand dass er frohr, aber er sprang nicht. Er kam aber auch nicht runter. Er traf die Entscheidung nicht- zu springen-, oder unter dem sicheren gejohle seiner Freunde die Treppe wieder herunter zu gehen. Seine Freunde unten im Wasser hatten auf jeden Fall einen Heiden Spaß dabei, den kleinen Kerl da oben stehen und zittern zu sehen. Im Sprung verliert man sämtliche Kontrolle und davor hat jeder Angst. Genauso geht es vielen von uns. Die Angst davor die Kontrolle zu verlieren hindert uns daran eine Entscheidung zu treffen. Kennen wir das nicht alle? Wenn man so langsam und insgeheim erkennt, dass man auf das falsche Pferd gesetzt hat und trotzdem daran festhält? 1.2 Mein Ziel… Sicher, es ist wichtig konsequent die Projektziele zu verfolgen und es wäre töricht bei der ersten Projektkrise gleich das ganze Projekt in Frage zu stellen, oder einen Mitarbeiter der einmal etwas verbockt hat deshalb gleich aus dem Projekt zu nehmen. Die Balance zwischen starrsinnigem Verfolgen von Zielen und erkennen wann man aussteigen, oder eine Kehrwende einschlagen muss, ist verdammt schwer. Doch manchmal ist es notwendig, die eigenen Ziele, den sich verändernden Rahmenbedingungen anzupassen. Wenn man seine Ziele mit Leidenschaft verfolgt hat und zugeben muss, dass diese Ziele nicht mehr gültig sind, geht man buchstäblich in die Knie- und wer holt sich schon gerne blutige Knie. Deshalb hält man lange und verbissen an einem solchen Ziel fest, auch wenn es eigentlich dafür schon lange keinen echten Grund mehr gibt. Aus einer internationalen Perspektive heraus betrachtet, sagt man uns Europäer nach, dass wir eher wenig „ambiguitätstolerant“ sind. Ambiguitätstoleranz, oder auch als Unsicherheits- oder Ungewissheitstoleranz bezeichnet, versteht man die Fähigkeit, mehrdeutige Situationen und widersprüchliche Handlungsweisen zu ertragen. Ambiguitätstolerante Personen sind in der Lage, Ambiguitäten, also Widersprüchlichkeiten, kulturell bedingte Unterschiede oder mehrdeutige Informationen, die schwer verständlich oder sogar inakzeptabel erscheinen wahrzunehmen, ohne darauf aggressiv oder negativ zu reagieren. Das heiß nichts anders, als das wir westlich orientierte Menschen uns schwer tun mit Veränderungen. Bietet man uns statt einer, plötzlich zwei Karotten an, stehen wir wie ein Esel dazwischen und verhungern eher, als dass wir uns entscheiden. Koreaner beispielsweise sind in dieser Situation da deutlich geschmeidiger. Vielen fällt es einfach schwer, die Verfolgung der bisherigen Ziele abzubrechen, obwohl diese mittlerweile unsinnig oder obsolet geworden sind. Es ist eine Tatsache, dass sie sich lieber der Illusion hingeben, sie seien noch auf dem richtigen Weg. Projektmanagementmethoden wie PRINCE2 beispielsweise haben das erkannt und sehen aus diesem Grund am Ende jeder Phase die Überprüfung des Businesscase und damit der gesteckten Ziele vor. Sind diese noch immer gültig? Stimmen die Rahmenbedinungen noch? Sind die Annahmen auf Basis dessen das Projekt gestartet wurde noch immer valide? Entsprechen die Ziele noch immer der Unternehmensstrategie? Leider stellt sich nicht jeder Projektleiter, oder auch die Projektsponsoren diese Frage. Leider hat nicht jedes Unternehmen, vor allem für lang laufende Projekte über mehrere Monate oder gar mehrere Jahre, eine regelmäßige Überprüfung dieser Art fest im vorgeschriebenen Vorgehensmodell verankert. Der Projektleiter muss sich diese Frage daher selbst regelmäßig stellen: „sind wir noch auf dem richtigen Weg?“ Wenn diese Frage nicht mit ja beantwortet werden kann, dann ist eine Entscheidung fällig. Das ansonsten schon selbstzerstörerische Verhalten ist nicht nur für das Projekt und das Unternehmen schädlich, sondern schädigt die Teammoral und nicht zuletzt am Ende die Reputation des Projektleiters. Wie gefährlich die Haltung „Augen zu und durch“ sein kann zeigt eine kleine Geschichte: „Die Ingenieure sitzen vor ihrem Schaltpult. Ein geplanter Stresstest soll die Funktionsfähigkeit der Anlage verifizieren und zeigen, dass die Turbinen auch bei einem Stromausfall noch genügend Strom für die Notkühlung der Kraftwerksaggregate liefern. Doch plötzlich kommt es zu einem Bedienungsfehler der die Kühlleistung unerwartet stark abfallen lässt. Die Situation droht außer Kontrolle zu geraten. Die Ingenieure hätten abbrechen können, doch der leitende Ingenieur wollte den Plan erfüllen und befiehlt noch ein paar Minuten auszuhalten, dann wäre wieder alles gut. Wir schreiben den 26. April 1986 und wir sind in Tschernobil. Wie diese Geschichte ausging, wissen wir alle.“ Sicher, das ist ein extremes Beispiel von „an einem eigeschlagen Weg festzuhalten um die Ziele zu erreichen.“ Das Sture Festhalten an althergebrachtem hat aber schon manch einem den Hals gekostet. Nehmen wir beispielsweise die Firma Kodak, einst Weltmarktführer auf dem Bereich der analogen Fotografie bzw. der Filme und Fotopapiere. Bereits um das Jahr 1900 hatten sie eine massentaugliche Kamera auf den Markt gebracht und von da an hechelte die Konkurrenz Kodak eigentlich nur träge hinterher. An der Weltmarktführerschaft konnte niemand rütteln. Im Jahr 1970 legte ein Kodak Mitarbeiter seinem Chef einen 4 Kg schweren Koffer auf den Tisch und präsentierte die erste digitale Fotokamera der Welt. Sie fotografierte schwarz weiß mit einer phänomenalen Auflösung von 0,1 Mega Pixel. Es war eine Eigenentwicklung von Kodak, doch man entschied sich gegen dieses Gerät. Man tat diese Erfindung als neumodischen Schnick Schnack ab, der das eigene Unternehmen nur gefährden konnte. Wozu sollte man etwas entwickeln, das die eigentlichen Kernprodukte des Unternehmens attakieren würde. Wer würde noch Fotopapier brauchen, brächte man eine Digitalkamera auf den Markt? Das Geschäft mit dem Fotopapier und den Filmen brummte und es gab keinen Grund an diesem Geschäft etwas zu verändern. Mit einer Digitalkamera würden sie sich selbst kanibalisieren, das war ihnen klar. In ihrer Arroganz kamen sie gar nicht auf die Idee, dass auch andere diese Technik weiterentwickeln könnten. Man schloss die Erfindung weg und überließ den Markt und die Entwicklung einer massentauglichen Digitalkamera der Konkurrenz. Die Chance die sich damals bot, wurde einfach vorbeiziehen lassen. Als die Führungsebene endlich ihren Fehler erkannte, war es längst zu spät. 2003 strich Kodak weltweit 47.000 Arbeitsplätze. Im Jahr 2012 meldete das Unternehmen Insolvenz an. 1.3 Die Angst davor das bereits investierte zu verlieren. Wir wollen nicht von dem einmal eigeschlagen Weg abweichen, schon gar nicht wenn es sich irgendwann einmal gelohnt hatte drauf zu gehen. Selbst wenn diese goldenen Zeiten längst vorbei sind, wollen wir an unseren Zielen festhalten, auch wenn klar ist dass das nicht mehr lange gut geht. Warum ist es so schwer eine Entscheidung zu treffen, obwohl man sieht dass das Ziel das man bislang verfolgt hat, so nicht mehr valide ist? Naja, wer vor einer wichtigen Entscheidung steht lässt seinen Blick auch immer in die Vergangenheit schweifen. • Wir haben doch schon so viel investiert. • Wir haben schon so viel erreicht. • Ich habe so hart für die Budgeterweiterungen gekämpft. • Ich habe so viele Versprechungen gemacht • Wir haben das Ziel mit so hoher Leidenschaft verfolgt. • Ich habe extra den Spezialisten dafür eingekauft, • und und und Lieber verfolge und erfülle ich meine Ziele…ich kann ja so tun, als hätte ich nicht gemerkt das sie schon lange nicht mehr gültig sind. Es reicht schon, dass in der Vergangenheit etwas in das Projekt investiert wurde, um den Blick auf die Realität mit solchen Rückblicken zu vernebeln. Ganz von der Hand zu weisen ist das natürlich nicht. Eine einmal getätigte Investition in den Wind zu schießen fällt niemandem leicht. Aber kaum einer ist davor gefeit, auf einem toten Pferd sitzen zu bleiben. Eine alte Weisheit der Dakota Indianer sagt „Wenn Du merkst, dass Du ein totes Pferd reitest, dann steige ab“. Aber was machen wir? • Wir besorgen uns eine stärkere Peitsche • Wir wechseln den Reiter aus • Wir behaupten, „so haben wir das Pferd schon immer geritten“ • Wir gründen eine Task Force zur Widerbelebung des toten Pferds • Wir machen Exkursionen um zu sehen, wie anderswo tote Pferde geritten werden • Wir machen zusätzliche Mittel locker um die Leistung des Pferdes zu erhöhen • Wir besuchen Seminare um besser reiten zu lernen • Wir ändern die Kriterien für die Definition „Pferd ist tot“ …zugegeben, das war jetzt nicht ernst gemeint, aber es hat sich so schön angeboten. Was ich eigentlich damit sagen will ist, dass man auch bereit sein muss, eine einmal getätigte Investition abzuschreiben. Etwas als „Lehrgeld“ zu verbuchen. Oder um mich selbst zu zitieren „man muss auch mal loslassen können“. Denn die Sinnhaftigkeit einer Entscheidung hat überhaupt nichts damit zu tun, wieviel bereits in ein Vorhaben investiert wurde. Egal wie hoch das Engagement in der Vergangenheit war, sobald sich herausstellt, dass Du auf das falsche Pferd gesetzt hast ist klar, wie die Entscheidung aussehen muss. Zusammengefasst lassen sich aus dem bisher gesagten also Zwei typische Gründe für das nicht Entscheiden identifizieren: • Das starrsinnige Festhalten an einmal verfassten Zielen • Die Angst davor, dass bereits investierte zu verlieren. Gibt es da noch mehr? 1.4 Ankommeritis Es ist schon ein paar Jahre her, da fuhr ich mit meiner damaligen Freundin in den langersehnten Sommerurlaub in den Süden. Ich hatte noch bis spät in den Abend gearbeitet und verkündete optimistisch, dass ich die Nacht durchfahre und wir morgen Früh am Ziel sein werden. Meine Freundin machte es sich auf dem Beifahrersitz bequem- und schlief ein. Kurz vor Morgengrauen wurde es hart. Ich machte immer wieder das Fenster auf, um frische Luft herein zu lassen. Nur noch 200Km, die schaffe ich doch auch noch. 100Km später wurde es brenzlig. Ich hatte schon mehrfach Sekundenschlaf auf dem ich hochgeschreckt bin. Aber jetzt wo ich so kurz vor dem Ziel bin, will ich doch keine Pause mehr machen…ich bin in Rekordzeit bis hierher gekommen…jetzt eine Pause machen, macht mir meinen ganzen Schnitt kaputt…nicht mal mehr eine Stunde…das schaff ich auch noch. So wie viele, litt auch ich damals unter Ankommeritis…ich kannte das damals nicht, habe daraus gelernt und hab das danach so auch nie wieder gemacht. Aber die Ankommeritis bedeutet, dass die Tatsache, dass ich in Richtung meines Zieles schon eine ganze Weile unterwegs bin, mich umso mehr vorantreibt, je näher ich dem Ziel komme. Das heißt, das Ziel selbst entfaltet eine magnetische Wirkung. Ich hab doch schon so viel hinter mir, da schaffe ich das letzte Stückchen doch auch noch. So nah vor dem Ziel, dann doch noch eine Pause einzulegen, bedeutet quasi eine übermenschliche Anstrengung. 1.5 Soziale Aspekte eine Entscheidung zu treffen Entscheidungen haben aber auch noch eine soziale Komponente. Wenn ich eine Entscheidung treffe, kann ich davon ausgehen, dass nicht jedem diese Entscheidung gefallen wird. Wenn man über die Konsequenzen einer notwendigen Entscheidung nachdenkt, wird es einem oft mulmig im Bauch. • Man wird mich dafür kritisieren • Man wird mich angreifen • Ja, vielleicht wird man mich sogar anschreien. Wenn ich eine Entscheidung bewusst und überlegt gefällt habe, muss ich das aber aushalten. Das ist nicht leicht, aber niemand hat gesagt dass es leicht ist. Sie entscheiden sich ein Projekt zu stoppen? Das kann zur Folge haben, • dass Mitarbeiter ihren Arbeitsplatz verlieren, • sich getätigte Investitionen in nichts auflösen. • Vielleicht werden Sie sogar als Verlierer da stehen. • Sie hatten einst so sehr für dieses Projekt gekämpft, • Versprechungen gemacht • und nun müssen sie zugeben, dass Sie sich geirrt haben. Diese Situationen müssen Sie aushalten können. Der wahre Grund, warum das so weh tut ist dass wir uns plötzlich ausgeschlossen fühlen. Ausgeschlossen aus einer Gruppe, zu der wir eben noch gehörten und nun nach der Entscheidung nicht mehr: Das Projektteam, die Abteilung, das Unternehmen, ja- vielleicht sogar die Freunde und Kollegen. 1.6 Entscheidung = Risiko Wer entscheidet geht auch immer ein Risiko ein. Nämlich das Risiko sich falsch zu entscheiden. Wer glaubt im Leben keine Fehler zu machen, wird vom Leben enttäuscht werden. Im Nachhinein weiß man es immer besser wie man es richtig gemacht hätte, oder wie man besser entschieden hätte. Aber in dem Moment wo Sie entscheiden, treffen Sie die Entscheidung auf Basis der Informationen die vorliegen. Auf Basis all der bekannten Fakten und in diesem Moment gültigen Rahmenbedingungen, treffen Sie immer, die für diesem Moment richtige Entscheidung. Niemand wird sich nach Abwägung der Kosten und des Nutzen freiwillig für die zweit-, oder drittbeste Option entscheiden. Ob das auch am nächsten Tag so ist, weiß freilich niemand. Bedingungen und Situationen verändern sich. Die einzige Konstante im Universum ist und bleibt nun Mal die Veränderung. Was gestern noch richtig war, muss heute nicht mehr richtig sein. So ist das nun mal. Wer entscheidet, kann sich nie sicher sein, ob er falsch entscheidet. 1.7 Besser nicht entscheiden? Aber Hallo, bedeutet dass ich mit jeder Entscheidung in Gefahr laufe eine falsche Entscheidung zu treffen? Ist es dann nicht besser, sich alle Optionen offen zu halten und nicht zu entscheiden? Es mag sein, dass es manchmal Gründe dafür gibt, eine zu treffende Entscheidung hinauszuzögern, weil sich die Rahmenbedingungen gerade stark verändern. Doch wer den Zeitpunkt der Entscheidung verpasst, erreicht unter Umständen sehr schnell einen „Point-of-no-return“ und manövriert ein Projekt damit unter Umständen in eine Lage, aus der man nur noch mit einem Projektabbruch herauskommt. Doch wer an der Weggabelung stehen bleibt, sich für alle Zeiten die Optionen für Weg A, Weg B und Weg C offen halten will, der kommt in seinem Projekt, oder auch in seinem Leben, keinen Schritt vorwärts. Klingt eigentlich alles plausibel. Aber warum fallen dann Entscheidungen oft so schwer? Wer Entscheidet, entscheidet sich nicht nur für etwas, sondern auch gegen all die anderen Optionen. Geh also raus aus der Deckung und wage den Sprung in das Ungewisse. Eine Entscheidung ohne Risiko, ist keine Entscheidung. Trainieren Sie zu entscheiden. Das kann man auch in den Alltag sehr gut einbauen. Zum Beispiel bei der Auswahl des Essens im Restaurant, beim Kauf neuer Schuhe, oder was es heute Abend zuhause zum Essen gibt. Trainieren Sie Ihren Entscheidungsmuskel, damit haben Sie ein mächtiges Werkzeug, das Ihnen bei Ihrer alltäglichen Arbeit hilft. Weitere Informationen finden Sie unter www.Bundesvereinigung-ITPM.de

Im Zweiten Teil des Interviews mit Benedict Gross erklärt er, wie einfach es mit dem neuen "Project Excellence Modell" der GPM geworden ist, sich beim Award zu bewerben. Sie erfahren auch, wie Sie das PE Modell nutzen können, um ein Selbst-Assessment durchzuführen und eine Bewertung Ihrer Projektleistungen in Eigenregie durchzuführen. Freuen Sie sich auf den Zweiten Teil des Interviews und erfahren Sie, wie auch Sie vielleicht bald zum auserlesenen Kreis der Finalisten zum "Deutschen Project Excellence Award" der GPM gehören. Weitere Informationen finden Sie unter www.Bundesvereinigung-ITPM.de

Es muss da etwas geben, das normale Projekte von außergewöhnlichen unterscheidet. Einen Unterschied zwischen Befriedigung und Begeisterung bei der Zielerreichung. Der Grund, warum von manchen Projekten noch jahrelang erzählt wird, warum sie Startpunkte von Karrieren markieren, Beginn von Freundschaften waren, Unternehmen verändert und markante Spuren in der Gesellschaft hinterlassen haben – und andere Projekte dagegen einfach nur abgewickelt werden. Die GPM nennt dieses Phänomen Project Excellence und vergibt seit 18 Jahren den Deutschen Project Excellence Award (DPEA) an Projekte mit herausragenden Leistungen. Das zugrundeliegende Project Excellence Modell wurde jetzt komplett überarbeitet – und doch im Kern erhalten worden . In neun Haupt- und 23 Teilkriterien beschreibt das Modell Aspekte, die ein Projekt excellent machen und dies unabhängig von etablierten Standards. Ich freue mich, dass ich heute für Sie Benedict Gross, den Programmleiter des „Deutschen Project Excellence Awards“ der GPM zu einem Interview gewinnen konnte. Seit seiner ersten Assessorenschulung im Jahr 2008 ist er von der Idee des Project Excellence Modells begeistert und hat seit 2011 an dessen Weiterentwicklung mitgearbeitet. Als Projektleiter und Berater sammelte er Erfahrung in verschiedenen Branchen, hat einen fachlichen Schwerpunkt im Krisen- und Risikomanagement und ist nach IPMA und PMI zertifiziert. Freuen Sie sich heute auf den ersten Teil unseres Interviews zum "Deutschen Project Excellence Award" Weitere Informationen finden Sie unter www.Bundesvereinigung-ITPM.de

In der Folge 06 haben wir uns mit den sozialen Aspekten beschäftigt, die auf einen Projektleiter zukommen, der neu in ein laufendes Projekt einsteigt. Doch selbstverständlich zählen neben den sozialen Aspekten natürlich vor allem auch die harten Fakten. Leider ist kein Projekt wie das andere und stets sind andere Rahmenbedingungen zu beachten. Aber es empfiehlt sich einige Grundsätzlichkeit zu beachten. Es ist wichtig bestimmte Fragen zu klären, um sich einen ersten Überblick zu verschaffen. Verschaffen Sie sich Zugang zu den relevanten Projektdokumenten und Rahmeninformationen und lesen Sie diese. In der Regel hat man Ihnen jemand zur Seite gestellt, oder man hat Ihnen einen Ansprechpartner genannt, um aufkommende Fragen zu beantworten. Nutzen sie dies und klären Sie ihre Fragen. Je nachdem, ob es sich um ein unternehmensinternes Projekt, oder ein Projekt mit externem Auftrag handelt, müssen Sie die Informationen anders bewerten. Bei einer Auftragsentwicklung, wird es spätestens am Ende des Projektes eine zahlungsverpflichtende Endabnahme des Projektergebnisses geben. Ein solches Projekt, benötigt eine ganz andere Organisationsstruktur als eine vergleichbare Entwicklung für den InHouse Bedarf. Um diese und ähnliche Entscheidungen treffen zu können, benötigen Sie Informationen. Daher sollten Sie die folgenden Fragen klären: • Folgt das Projekt bisher einem methodischen Vorgehensmodell, wie z.B. die Wasserfall-, V-Modell XT-oder einer Agilen Methode? • Wenn ja, tut es das wirklich, oder nur auf dem Papier? • Wie kam es zu dieser Entscheidung und warum? • Gibt es eine solide Vertrags- bzw. Beauftragungsgrundlage? • Gibt es so etwas wie ein Lastenheft? • Wie wurde vorgegangen, als das Lastenheft vorlag? • Wie wurden die Pflichten daraus abgeleitet? • Gibt es ein Pflichtenheft? • Gibt es Testpläne und eine Testinfrastruktur? • Werden Testsuiten in automatischen Tests abgefahren und wenn ja, wie war die Qualitätsentwicklung bislang? • Gibt es einen Projektstrukturplan? • Gibt es ein Projekthandbuch? • Wie funktioniert der Changemanagement Prozess und welche Änderungen gab es bisher und zu welchem Zeitpunkt? • Was ist mit Risiko- und Chancenanalyse und wie wird diese gepflegt? Gibt es dringenden Handlungsbedarf? • Gibt es eine aktuelle Projektumfeldanalyse (PUMA) • Sind die Nahtstellen des Projektes bekannt, also die Projektgrenzen zum Projektumfeld? • Gibt es eine Stakeholderanalyse und wie wird diese gepflegt? Wie stellt eine Kraftfeldanalyse die momentane Situation dar? • Wer unterstützt das Projekt, wer ist neutral und wo gibt es Gegner? • Werden Chancen und Risiken aktiv bearbeitet und gesteuert? • Hat das Projekt Puffer, die an die einzelnen Teilprojekte und Teams weiter gegeben werden? Wie werden diese Puffer vergeben und überwacht? • Gibt es eine Definition of Done? • Wie und unter welchen Bedingungen werden projektinterne Ergebnisse abgenommen und übergeben? • Welche Qualitätstoleranzen sind vereinbart und wie sind die Erfahrungswerte damit? • Wie werden Arbeitspakete an Teilprojekte oder Teams vergeben und überwacht? • Wie erfolgt die Fortschrittsmessung der Arbeitspakete und wo sind diese dokumentiert? • Welche Zwischenergebnisse sind abzustimmen, wer ist dazu notwendig? • Wo sind die Usecases dokumentiert? • Wo in der Unternehmenshierarchie ist das Projekt organisatorisch aufgehängt und ist das den Projektzielen angemessen? • Wird im Unternehmen Projektmarketing betrieben, um auch innerhalb der Organisation sichtbar zu bleiben? Insbesondere, wenn es sich um ein Veränderungsprojekt handelt? • Wie bekannt im Unternehmen sind die Ziele und der Nutzen des Projektes? • Gibt es auf Projekt-, Programm- oder Unternehmensebene ein Projektcontrolling und wo stehen wir da? • Was hält das Projektteam und was halten die zukünftigen Anwender von den Zielen und dem angestrebten Nutzen? • Wie realistisch empfindet das Projektteam den gegebenen Zeithorizont? • Gibt es eine Kommunikationsmatrix in der auch Eskalationswege festgelegt sind? • Wer berichtet wann an die Projektleitung und wohin hat die Projektleitung bislang was berichtet? • Welche Fortschritte hat das Projekt, über welchen Zeitraum hinweg gemacht und wie ist die weitere Prognose? • Wie werden die zukünftigen Nutzer in das Projekt eingebunden? • Welche Werkzeuge werden bislang zur Projektsteuerung eingesetzt? Auf Basis der aus den Dokumenten und geführten Gesprächen gewonnenen Erkenntnisse, versuchen Sie nun die gefundenen Antworten in eine Struktur zu bringen. Dazu gehe ich mit Ihnen eine Checkliste zur Projektdiagnose durch. Notieren Sie sich, ob Sie die gefunden Information für „OK“ erachten, „ob besondere Beobachtung“ erforderlich ist, oder „ob dringender Handlungsbedarf“ besteht. 1. Projektziele o Sind die Projektziele klar definiert? o Hält das Projektteam die Ziele für erreichbar? o Sind die Projektziele nach wie vor für das Unternehmen relevant? o Würden die Erreichung der Ziele im Unternehmen wahrgenommen werden? o Wie wurde in der Vergangenheit mit Zielkonflikten zwischen Stakeholder umgegangen? 2. Business Case o Wurde der Nutzen des Projektes finanziell bewertet oder auf andere Weise messbar gemacht? o Sind die Kostenschätzungen vollständig und wird regelmäßig ein Ist/Soll Abgleich durchgeführt? o Erscheint die Kostenabschätzung realistisch? o Erscheint der angestrebte Nutzen realistisch? 3. Stakeholder o Sind die relevanten Stakeholder und deren Einfluss auf das Projekt bekannt? o Sind die Projektsponsoren in der Unternehmenshierarchie richtig gewählt? o Wird aktiv mit den Stakeholdern gearbeitet (Reporting, Workshops, Infos usw.) und sind sie ausreichend in das Projekt eingebunden? o Sind die unterschiedlichen Prioritäten und Interessen der Stakeholder klar? 4. Minimaler Projektumfang o Ist der Fokus der angestrebten Lösung so klein wie möglich, aber so groß wie nötig, um das angestrebte Projektziel zu erreichen? o Gibt es Prozesse, um den Projektumfang auch im laufenden Projekt stabil zu halten (Änderungsprozess, …). Wie wurde in der Vergangenheit mit Änderungen umgegangen? 5. Existiert eine robuste Vertragsgrundlage? o Sind Rechte und Pflichten der Vertragspartner hinreichend geklärt? o Sind Zwischenprodukte, oder Zwischenlieferungen und deren Abnahmekriterien hinreichend geklärt? o Sind Eskalationswege klar festgelegt? o Wie ist der Umgang mit ChangeRequests geregelt? 6. Erachten Sie das Projektteam für geeignet? o Steht Personal entsprechend der zeitlichen Projektanforderungen zu Verfügung? o Steht Personal entsprechend der geforderten Qualifikationen zur Verfügung? o Sind die Rollen innerhalb des Projektes klar besetzt? o Bestehen Ressourcenkonflikte mit anderen Projekten, oder Abteilungen? o Ist ein angemessen Reporting aufgesetzt? o Ist ein Kommunikationsplan erstellt und wird dieser gelebt? o Wie weit ist die Teamentwicklung schon fortgeschritten:  Wie schnell findet man Lösungen im Team?  Wie konstruktiv ist der Umgang miteinander?  Unterstützen sich die Projektmitarbeiter im Bedarfsfall?  Ist die Organisation innerhalb des Projektes klar definiert? 7. Unterstützung durch den Chef und die Unternehmensleitung o Genießt das Projekt in der Unternehmensleitung Beachtung? o Wurde die Unternehmensleitung regelmäßig in den Projektfortgang eingebunden und trägt sie Entscheidungen mit? o Wurde der direkte Auftraggeber / Chef regelmäßig in den Projektfortgang eingebunden und trägt er Entscheidungen mit? o Ist zu erwarten, dass sich der Chef im Krisenfall vor den Projektleiter stellen wird? 8. Wurden die zukünftigen Nutzer bereits frühzeitig in das Projekt mit eingebunden? o Fliesen die detaillierten Erfahrungen und Anforderungen der Nutzer in die Konzeption der Lösung? o Werden Nutzer rechtzeitig auf die anstehenden Veränderungen vorbereitet? 9. Wie verlässlich waren die Projektplanungen in der Vergangenheit? o Besteht hinreichend Transparenz über verbrauchte Resourcen? o Ist das Restbudget realistisch ermittelt? o Gibt es Abhängigkeiten zu anderen Projekten, Unterauftragnehmer, Zulieferer usw.? o Sind Meilensteine abgestimmt und aktuell? Wie hat sich diese Planung im bisherigen Verlauf des Projektes verändert? o Ist der Projektplan realistisch und sehen das auch das Projektteam und die Stakeholder so? o Wie wird inhaltlich der Projektfortschritt kontrolliert? o Sind die wesentlichen Einflussfaktoren des Projektbudgets bekannt? o Ist das Gesamtbudget für das Projekt vollumfänglich geplant und genehmigt? o Existieren ausreichend Risikopuffer für das Projekt? 10. Welche Werkzeuge, Methoden und Verfahren werden bislang für das Projektmanagement angewendet und gibt es Verbesserungsbedarf? o Wurde ein Vorgehensmodell gewählt und was waren die konkreten Gründe für die Entscheidung? o Ist ein ausreichendes Qualitätsmanagement etabliert? o Ist ein ausreichendes Risikomanagement etabliert? o Sind Tools, Werkzeuge und Hilfsmittel dem Projekt angemessen? Mit Hilfe dieser Projektdiagnose Checkliste sollten Sie in der Lage sein, sich ein recht umfangreiches Bild zum Status Quo des Projektes zu machen. Damit sollten Sie sich dann auch ein erstes Urteil zur derzeitigen Projektdiagnose erlauben. Sind die Rahmenbedingungen des Projektes der Situation angemessen, oder müssen und können diese Verändert werden? Ist die Organisation des Projektes den Anforderungen und Rahmenbedingungen angemessen? Auf Basis dieser und weiterer Antworten können Sie nun beginnen Ihre Leitungsfunktion konsequent in Angriff zu nehmen. So Ihr lieben, das war‘s wieder mal für heute. Ich will noch nicht zu viel verraten, aber wenn alles nach Plan klappt, habe ich in der nächsten Woche einen echten Projektmanagement Hochkaräter für Sie im Interview. Das wird definitiv Spannend und jede Menge Mehrwert für Sie alle bieten. Verpassen Sie deshalb die nächste Folge nicht und denken Sie daran, unseren Podcast in den sozialen Netzen zu teilen, uns tolle Bewertungen zu geben und unseren Newsletter zu abonnieren. Ich wünsche Ihnen und Ihrem Projekt lauter grüne Meilensteine Ihr Andreas Haberer Weitere Informationen finden Sie unter www.Bundesvereinigung-ITPM.de

Wenn Du ein Schiff bauen willst, so trommle nicht Männer zusammen, um Holz zu beschaffen, Werkzeuge vorzubereiten, Aufgaben zu vergeben und die Arbeit einzuteilen, sondern lehre die Männer die Sehnsucht nach dem weiten endlosen Meer. Antoine de Saint-Exupéry Die Folge 08: Effektivität im Projekt In der Managementliteratur liest man immer wieder die Metapher der 3 Steinmetze: Ein Mann kommt auf eine Baustelle und sieht dort 3 Steinmetze. Er fragt den ersten „Was machen Sie da?“. Der Steinmetz antwortet „das sehen sie doch, ich behaue Steine und verdiene damit meinen Lebensunterhalt“. Der Mann geht weiter zum Steinmetz und fragt auch diesen „Was machen Sie da?“. Der Steinmetz antwortet: „Sehen sie her, ich bin der beste Steinmetz im ganzen Land, keiner bearbeitet Steine so gut wie ich“! Schließlich geht der Mann weiter zum dritten Steinmetz und fragt auch diesen „Was machen Sie da?“. Der dritte Steinmetz schaut sich mit glänzenden Augen um und sagt „ich trage dazu bei, eine Kathedrale zu bauen“. Alle 3 Steinmetze tun das Gleiche. Was sie elementar voneinander unterscheidet ist die jeweilige Einstellung. Der erste Steinmetz macht einfach nur seinen Job. Diese Art von Mitarbeitern tun genau das, was von Ihnen verlangt wird und leistet genau so viel wie es sein muss. Auch wenn sie fachlich zu Spitzenleistungen fähig wären, ist die Eigenmotivation meist eher gering, sich übermäßig einzubringen. In der Regel bringt diese Art von Mitarbeiter zwar ordentliche Leistungen, darüber hinaus darf aber nicht viel erwartet werden. Problematisch ist der Typus des zweiten Steinmetzes. Dieser ist damit zufrieden, einen kleinen Spezialbereich zu beherrschen, während er für alle anderen Bereiche nur Geringschätzung übrig hat. Er interessiert sich nicht für das große Ganze und welche Randbedingungen sonst noch existieren. Darum sollen sich andere kümmern. Er interessiert sich lediglich für sein Fachgebiet. Solche Mitarbeiter sind eher schwierig und in der Regel kaum, bis überhaupt nicht steuerbar. Allerdings sind sie von hoher fachlich Kompetenz, dass man auf deren Leistungen nicht verzichten kann. Der dritte Typ stellt seine Leistung in den Dienst etwas größeren, er arbeitet an einer Vision. Diese Art von Mitarbeiter begeistert sich für seine Ziele, er tut die richtigen Dinge richtig, das heißt er ist effektiv und effizient. Er richtet den Blick nicht auf seine persönliche Tätigkeit, sondern auf den Beitrag zum Gesamtergebnis. Er wendet sich der Außenwelt zu, das heißt dem Ort, an dem das Projekt Ergebnisse erzielen wird. Sein Tun dreht sich um die Frage „was kann ich zum Gelingen des Ganzen beitragen“. Doch auch wenn sie es als Projektleiter schaffen, Ihrem Team eine Vision zu geben und sie dazu zu bewegen, das große Ganze im Blick zu haben. Als IT’ler sind wir „Wissensarbeiter“ und als Wissensarbeiter ist es unsere Aufgabe effektiv zu sein. Vom Wissensarbeiter wird erwartet, dass er die richtigen Dinge richtig tut. Genau das ist der Unterschied zwischen Effektivität und Effizienz. Sie mögen die beste Technik entwickeln, um in Windeseile eine Leiter hinaufzuklettern. Wenn diese Leiter aber an der falschen Wand lehnt, macht das Ganze keinen Sinn. Peter F. Drucker konstatiert in seinem Buch „Was ist Management“ zur Frage nach dem Wissensarbeiter wie folgt: „In den Wissenstätigkeiten sind auffällig wenige effektive Menschen tätig. Wissensarbeiter zeichnen sich im Allgemeinen durch eine hohe Intelligenz aus. Das Niveau der Kenntnisse ist zumeist sehr hoch. Doch anscheinend besteht kaum ein Zusammenhang zwischen der Effektivität und der Intelligenz. Brillante Menschen sind oft auffällig ineffizient und nicht imstande zu erkennen, dass geistige Brillanz an sich keine Leistung ist. Anderseits gibt es die ungemein effektiven Arbeitstiere, während brillante aber wenig effektive Menschen oftmals jene Art von hektischer Betriebsamkeit an den Tag legen, macht das Arbeitstier einen präzisen Schritt nach dem anderen und erreicht so deutlich schneller das Ziel. Intelligenz, Vorstellungkraft und Wissen sind ohne Frage wichtige Ressourcen. Aber um sie in Resultate umzusetzen, bedarf es der Effektivität. Leider wird darauf viel zu wenig Aufmerksamkeit gerichtet. Es ist auch kein einfaches Thema. Bei den manuellen Tätigkeiten, nehmen wir als Beispiel die Fließbandarbeit, wird lediglich Effizienz benötigt, das heißt die Fähigkeit die Dinge richtig zu machen. Diese Fähigkeit unterscheidet sich von dem Vermögen, die richtigen Dinge richtig zu machen. Manuelle Tätigkeiten sind meist leicht vergleichbar und können daher auch leicht messbar gemacht werden. Wenn der Standard darin liegt, an 50 Motoren pro Stunde eine Schraube anzuziehen, so kann jeder manuelle Arbeiter daran gemessen und durch Übung gesteigert werden. Wie aber misst und steigert man aber die Leistung eines Wissensarbeiters? Die Steigerung der Effektivität ist ohne Frage ein lohnendes Ziel. Als Projektleiter ist es an dieser Stelle meine Aufgabe, für meine Teammitglieder solche Rahmenbedingungen zu schaffen, die es ihnen erlauben ihre Fähigkeiten auch optimal einzusetzen. Ein IT Projektteam setzt sich in der Regel aus Wissensarbeitern mit Spezialkenntnissen zusammen, die genau wegen dieser Spezialkenntnissen und der Aufgabenstellung des Projektes ausgewählt wurden. Jedes Teammitglied hat seine Spezialgebiet und eigene Interessen. Tatsächlich kann ein Wissensarbeiter nur dann wirklich effektiv sein, wenn er in einer Sache wirklich gut ist, sich also spezialisiert hat. Doch für sich genommen ist jedes Spezialgebiet nur ein loses Fragment. Die Ergebnisse einer Spezialisierten Tätigkeit müssen mit der einer anderen spezialisierten Tätigkeit verknüpft werden um Resultate hervorzubringen. Als Projektleiter ist es meine Aufgabe, die Kenntnisse und Fähigkeiten meiner Mitarbeiter so zu orchestrieren und zu nutzen, dass das bestmögliche Ergebnis, gemessen an den gesteckten Zielen des Projektes, dabei herauskommt. Das bedeutet aber auch, dass der Spezialist mit den notwendigen Informationen ausgestattet werden muss, wer seine Arbeitsergebnisse nutzen wird und welche spezifischen Rahmenbedingungen einen Einfluss haben. Es ist die Aufgabe des Projektleiters jedes Teammitglied mit diesen Informationen zu versorgen. Daraus ist zu schließen, dass die Kommunikation innerhalb des Projektes, eine wesentliche Voraussetzung zur Effektivität des Projektteams darstellt. Ich vergleiche das gerne mit einem Orchester. Auch wenn der Dirigent Grundfertigkeiten zu jedem einzelnen Instrument im Orchester haben mag, jeder einzelne Musiker beherrscht wahrscheinlich sein Instrument besser, als es der Dirigent könnte. Doch erst der Dirigent formt aus einer Ansammlung von individuellen Fähigkeiten das große Ganze, das im Takt und Harmonie etwas Großartiges schafft. Die Effektivität des Einzelnen und des ganzen Teams steigert man folglich durch Praktiken und Reflexion. Nur das was wiederholt getan, analysiert, verbessert und wiederholt wird, steigert die Effektivität des Einzelnen und des Teams. Praktiken erlernt man, in dem man übt, übt und nochmal übt. Doch nicht nur die Orchestrierung innerhalb des Projektes ist notwendig um Effektiv und damit Wirksam zu werden. Wenn ein Projekt in einer Organisation ein Erfolg werden soll, ist es notwendig auch das Umfeld zu verstehen. Auch wenn ich als Techniker wenig politische Ambitionen habe, so ist es als Projektmanager doch notwendig, die sozialen Netzwerke im Unternehmen zu verstehen und im Sinne des Projektes zu nutzen. In Unternehmen gibt es zwei Arten von Netzwerken. Die Beraternetzwerke und die Vertrauensnetzwerke. Beraternetzwerke In den Beraternetzwerken sind die Spezialisten für bestimmte Themen zu finden. Sie werden um Rat gebeten, wenn es um eine fachliche Expertise geht. Sie beeinflussen damit häufig bedeutende Entscheidungen und besitzen somit eine nicht unwesentliche Macht in Unternehmen. Sie werden die wichtigsten Berater im Unternehmen nach einiger Zeit identifizieren können, da sie regelmäßig in den wichtigen Meetings eingeladen sind und dort um ihre Meinung gefragt werden. Vertrauensnetzwerke Wir vertrauen den Menschen die uns in der Vergangenheit unterstützt haben und die wir auch wiederum unterstützen. Basis dafür ist meist gegenseitige Sympathie und Wertschätzung. In den Vertrauensnetzwerken werden vertrauliche Informationen ausgetauscht und Abkommen getroffen. Diese zu erkennen ist meist schwieriger als es bei den Beraternetzwerken der Fall ist. Sie finden das durch Beobachtung heraus, oder indem sie konkret fragen wer-wem vertraut und wer wieviel Einfluss auf andere hat. Achten sie darauf, wer vor und nach Meetings noch zusammen steht und wie sie sich miteinander unterhalten Die Mitglieder dieser Netzwerke im Unternehmen, könnten zu den Stakeholdern Ihres Projektes zählen. Und selbst wenn das nicht der Fall ist, hilft ihnen die Kenntnis dieser Netzwerke dabei, ihre relevanten Stakeholder auf geeignete Weise im Sinne Ihre Projektes zu beeinflussen. Bevor Sie damit beginnen, sollten Sie zunächst eine Analyse der relevanten Interessensträger durchführen. Das englische Wort für Interessensträger lautet Stakeholder, daher spricht man von einer Stakeholder Analyse. Unter einer Stakeholder Analyse versteht man die Ermittlung der Interessensträger eines Projektes, deren Macht und Einflusspotenzial, sowie die Art und Weise der Beziehung. Gründe, warum Stakeholder an einem Projekt Interesse haben könnten beispielsweise sein: -Der Stakeholder ist gezwungen, Personal dem Projekt beizustellen -Der Stakeholder hat selbst einen Vorteil durch das Projekt, dessen Durchführung oder dessen Ergebnis -Der Stakeholder identifiziert sich mit dem, wofür das Projekt oder dessen Ziele stehen. Es könnten sein: -Manager (Team-, Abteilungs-, Bereichs-, oder Unternehmensleitung) -Meinungsführer mit hohem Einfluss -Lieferanten -Kunden -Eigentümer -Konkurrenten Es gibt verschiedene Methoden der Stakeholder Analyse. Wichtig dabei ist es, deren Haltung, sowie deren Machtpotenzial zur Beeinflussung des Projektes zu kennen. Ist dies bekannt, können Maßnahmen ergriffen werden, Fürsprecher noch enger an das Projekt zu binden und Stakeholder mit ablehnender Haltung zu einer neutraleren, oder sogar positiven Sicht hin zu bewegen. In Projekten nutzt man dazu die Projekt Umfeldanalyse. Dokumentieren sie im Projektverlauf die ergriffenen Maßnahmen zum Management Ihrer Stakeholder und bewerten sie die Wirksamkeit dieser, indem sie eine Kraftfeldanalyse fortschreiben. Wie das geht, möchte ich Ihnen kurz erklären: Schauen Sie sich die Stakeholder zuerst einmal einzeln an und überlegen sie sich, welche positiven und welche negativen Konsequenzen es für den einzelnen hat, wenn das Projekt erfolgreich umgesetzt wird. Das Ergebnis dieser Überlegungen, notieren sie für jeden Entscheider in Form eine Gewinn- und Verlustrechnung. Dazu sollten sie sich ausreichend Zeit nehmen um die Vor- und Nachteile für jeden einzelnen in Ruhe zu überdenken. Anschließend wissen sie, wer tendenziell eine positive-, wer eine neutrale und wer eher eine negative Haltung Ihrem Projekt gegenüber haben wird. Schätzen Sie anschließend ein, wieviel Einfluss, bzw. Macht die betreffende Person im Hinblick auf Ihre Projektbelange hat. Das muss sich nicht immer proportional zu der Hierarchischen Position der Person im Unternehmen sein. Vergessen sie dabei auch nicht die Frage, ob die betreffenden Personen die von Ihnen erkannten Vorteile, bzw. Nachteile auch selbst kennen. Wenn Sie beispielsweise für einen Abteilungsleiter, mit der Einführung eines neuen Softwaresystems, eine deutliche Arbeitserleichterung bringen werden, er aber nur sieht, dass sich seine Leute schon wieder in etwas neues einarbeiten müssen und damit phasenweise an Produktivität einbüsen, dann müssen Sie dafür sorgen, dass er die notwendigen Informationen auch erhält. Genauso verhält es sich mit Informationen, die den ein- oder anderen von einer neutralen, in eine extrem negative Position drängen würde sobald er davon erfährt. Sagen Sie immer stets die Wahrheit, aber sagen sie nicht immer alles was wahr ist. Tragen Sie nun alle relevanten Entscheider in ein sogenanntes Kraftfeld ein. Das ist ein Koordinatensystem dessen vertikale Achse die Position der einzelnen Stakeholder darstellt. Die Skala reicht von -5 bis +5. Je nachdem ob derjenige dafür, dagegen oder neutral eingestellt ist. Auf der horizontalen Achse ist ablesbar, wieviel Macht die betreffende Person in Bezug auf Ihr Projekt hat. Die Skala dieser Achse reicht von 0 bis 10. Tragen Sie nun die identifizierten Stakeholder als Punkte in das Feld ein. Vergessen Sie dabei sich selbst nicht. Auf dem entstandenen Bild können sie nun genau sehen, wie die Parteien für und gegen das Projekt kräftemäßig verteilt sind. Stellen sie sich nun die Frage, welche Stakeholder müssten sich an welche Stelle bewegen, dass sich das Kräfteverhältnis zugunsten des Projektes wandelt? Wen müssen sie wie beeinflussen, so dass Sie das erreichen? Ein guter Weg neutrale in positive Haltungen zu wandeln, sind Vorabinformationen. Treffen sie sich mit der betreffenden Person und stellen Sie das Projekt vor. Erläutern sie die Vorteile und fragen sie um Rat was sie tun müssen, um ihn von dem Projekt zu begeistern. Unterschätzen Sie nicht die Macht des Reportings. Achten sie darauf, dass sie ihre Stakeholder in geeigneter Weise mit in Ihre Berichterstattung aufnehmen und versorgen sie diese somit mit den relevanten Informationen. Das gilt vor allem auch für die bereits positiv gestimmten Stakeholder, um diese noch enger an sie zu binden. So, damit möchte ich mich für heute von Ihnen verabschieden und hoffe es hat Ihnen Spaß gemacht. In der vergangenen Woche hat mich eine kräftige Erkältung etwas aus der Bahn geworfen und ich bin froh dass meine Stimme heute durchgehalten hat. Die vielleicht krächzende Stimme lag also nicht an einem neuen Mikrofon, sondern nur an mir. Ach ja, da ist noch etwas: Seit dieser Woche, also Februar 2015, ist unser Podcast neben iTunes und weiteren bekannten Podcast Plattformen nun auch beim online Radiosender Stitcher verfügbar und abonnierbar. In der vergangenen Woche bekamen wir grünes Licht, unsere Beiträge mit in das eigene Portfolio aufzunehmen, was uns sehr gefreut hat. Ach ja- und seit vergangener Woche, haben wir auch unseren YouTube Kanal freigeschaltet und damit steht Ihnen ein weiterer Weg zu Verfügung unsere Beiträge zu hören. Sie sehen, wir wachsen stetig. Ich freue mich schon auf das nächste Mal und wünsche Ihnen in Ihrem Projekt lauter grüne Meilensteine, Ihr Andreas Haberer Weitere Informationen finden Sie unter www.Bundesvereinigung-ITPM.de

„Der Langsamste, der sein Ziel nicht aus den Augen verliert, geht immer noch schneller als der, der ohne Ziel herumirrt.“ Gotthold Ephraim Lessing Die Folge 07: Wir sind ein Team Teamentwicklung ist ebenso sinnvoll, wie nötig. In der Idealvorstellung erkennt man, aus meiner Sicht, ein wirklich gutes Team an den folgenden Punkten: • Das Team besteht aus miteinander harmonisierenden Persönlichkeiten mit hoher sozialer Kompetenz • Die einzelnen Teammitglieder ergänzen sich hinsichtlich ihrer Stärken, so dass im Team das Wissen und die Fähigkeiten aller ausgespielt werden können • Der Zusammenhalt innerhalb des Teams ist groß und alle setzen sich für die gemeinsame Ziele ein Um das zu erreichen müssen einige Voraussetzungen stimmen: • Es besteht eine gemeinsame Aufgabe • Die Teammitglieder kommunizieren offen miteinander • Die Teammitglieder entwickeln gemeinsame Ziele Bis aus einer „Arbeitsgruppe“ ein echtes Team wird, benötigt man Zeit. Denn es ist in der Regel ein langer Prozess, der aber stets in 4 Phasen abläuft, die immer dann auftreten, wenn ein Team neu zusammengestellt wird, oder sich die Zusammensetzung ändert. Diese 4 Phasen laufen nicht zwingend sequenziell nacheinander ab. In der Regel überschneiden sich die Phasen oder iterieren sogar: • Forming, oder Orientierungsphase o Die Leute gehen höflich miteinander um o Sie sind eher unsicher o Sind tendenziell eher zurückhaltend bei den Äußerungen o Das Gesamtverhalten ist noch eher unpersönlich und gespannt o Der Umgang miteinander könnte eher als vorsichtig betrachtet werden o In dieser Phase ist die Orientierung am Projektleiter hoch und es besteht die Erwartung, dass er die Dinge entschlossen in die Hand nimmt o Die Aufgabe des Projektleiters ist es in dieser Phase den Mitarbeitern Raum zum Kennenlernen zu geben und klare Strukturen vorgeben • Storming oder Konfronationsphase o Es gibt erste Konfrontationen o Eine Cliquenbildung kann entstehen o Konflikte und Positionskämpfe sind in dieser Phase der Teambildung ganz normal. Wichtig ist, dass diese geklärt werden und klare Vereinbarungen getroffen werden, um die Grundsteine für ein faires Miteinander zu schaffen. • Norming oder Organisationsphase o Hat man in der zweiten Phase alles richtig gemacht, beginnen sich die Teammitglieder in dieser Phase zu öffnen o Ein Harmoniestreben innerhalb der Gruppe beginnt o Regeln werden vereinbart und gelebt o Ein Wir-Gefühl untereinander entsteht o Die Umgangsformen sind wieder konstruktiv und respektvoll o Man gibt sich ehrliches Feedback • Performing oder Integrationsphase o Jetzt wird das Team ein solches und beginnt das Potenzial zu nutzen. Die Leistungsfähigkeit steigert sich o Ideenreichtum und Synergien bringen das Team nach vorne o Die Teammitglieder gehen offen und flexibel untereinander und mit den Herausforderungen des Projektes um o Es gibt eine Hilfsbereitschaft untereinander um sich zu unterstützen Ich will Ihnen heute mal etwas Persönliches über mich erzählen, was ich bislang nur wenig gemacht habe. Ich bin seit über 30 Jahre neben meinem Hauptjob als IT Projektmanager auch noch Musiker. Ich spiele Keyboards in einer kleinen Band und unsere Auftritte am Wochenende sind für mich ein idealer Ausgleich. Die Musik, im Intro und im Outro des Podcastes, habe ich übrigens selbst gemacht. Ich hoffe sie gefällt Ihnen. Ich habe zuhause im Wohnzimmer einen Flügel stehen und es gehört zu meinen persönlichen Genussabenden, wenn ich mich in aller Ruhe an meinen Flügel setzen kann und spiele. Gerne mit einem guten Glas Rotwein. Ich spiele dann bei solchen Gelegenheiten ganz für mich alleine, häufig nicht nach Noten, sondern einfach das was in mir hochkommt. Das kann ich stundenlang und ich komme nach einer Weile in einen völligen Flow, bei dem Musik dann einfach so aus mir heraussprudelt. Es war am letzten Samstag ganz genauso und ich merkte irgendwann „Mensch, das ist ja cool was ich da spiele…“ und ich fragte mich, wo das eigentlich her kommt? Da liegen 10 Finger auf der Klaviatur die in völliger Harmonie zusammen arbeiten. Jeder einzelne Finger kann das gleiche. Er kann langsam, oder schnell-, fest oder leicht- und damit laut, oder leise eine Taste herunter drücken. Kein besonderer Held also, so ein Finger. Und kein einziger meiner Finger ist für sich genommen besser als einer der anderen. So ist das bei meiner linken- und so ist das bei meiner rechten Hand. Und doch, kein einzelner Finger wäre imstande das zu leisten was meine Finger und meine Hände in völliger Harmonie und damit im Team hinbekommen. Ganz klar, das Team der linken Hand hat seine Stärken mehr im Bass Bereich der Klaviatur und beherrscht Figuren, die dort gebraucht werden. Während sich die rechte Hand mehr auf die mittleren und oberen Tonlagen versteht und den Anforderungen dort gerecht wird. Kontrolliert und koordiniert wird das irgendwie von meinem Kopf, also- um bei der Analogie zu bleiben, vom Teamleiter. Aber wenn ich so richtig im Flow bin- und das ist das interessante, dann denke ich beim Spielen nicht mehr über die einzelnen Töne nach…es fließt einfach. Da spielen Gefühle eine Rolle, da ist Intuition im Spiel und ich kann mich da richtig in Trance spielen und verspochen…das liegt dann nicht am Rotwein. Als ich mich am Samstag nach dem Spielen auf meinem Klavierhocker zurück lehnte und auch meine Finger schaute dachte ich darüber nach, dass genau so ein perfektes Team miteinander funktionieren müsste. Damit meine ich jetzt nicht mein Klavierspiel…ich spiele ganz ordentlich, aber ich bin Lichtjahre von „perfekt“ entfernt und ich kenne sehr viele die dieses wunderbare Instrument noch sehr viel besser beherrschen als ich. Nein, ich meine den Mehrwert, im Team mehr zu sein als die Summe der einzelnen-, was nur durch absolute Harmonie untereinander entstehen kann. Das meine ich damit wenn ich sage, dass mir Teamentwicklung ein so wichtiger Faktor im Projekt ist. Aber nicht nur das Vertrauen der Teammitglieder muss erarbeitet werden. Auch Ihr Auftraggeber, Ihr Chef hat Ihnen mit ihrer Beauftragung einen Vertrauensvorschuss gegeben, dem sie nun gerecht werden müssen. Zum einen werden sie natürlich durch Ihre Projekt- und Zwischenergebnisse hoffentlich positiv dazu beitragen. Wichtig ist es aber, dass Sie ihn als Mensch und als Chef akzeptieren. Ich gebe zu, das ist mir in der Vergangenheit selbst nicht immer leicht gefallen. Ich hatte Chefs die ich weder fachlich, noch menschlich respektieren konnte. Da gab es leider die ein, oder andere Situation, in der ich besser still geblieben wäre. Leider hatte ich lange Zeit Probleme damit, in solchen Situationen meinem Unmut nicht freien Lauf zu lassen. Stattdessen machte ich damals leider wenig Hehl aus meiner Missbilligung…ich war damals der Meinung, dass ich ihm keinen Respekt schulde- schließlich bin ich GmbH Geschäftsführer und mein eigener Chef. So dachte ich zumindest damals, heute sehe ich das allerdings ganz anders. Dass das irgendwann in einen Konflikt ausarten muss, liegt auf der Hand. Ich hatte Auftraggeber und Chefs die ganz hervorragend waren und es noch heute sind. Brillante Strategen, Führungskräfte und ausgezeichnete Techniker. Doch auch mit jenen Vorgesetzten, bei denen man sich ernsthaft fragen musste wie sie in diese Position gekommen sind, ist es unsere Aufgabe als professioneller IT Projektmanagementdienstleister ein Vertrauensverhältnis aufbauen. Es bringt in einem solchen Fall natürlich gar nichts, einfach so „zu tun“ als respektiere man ihn. Wenn sie nicht gerade ein noch unentdeckter Schauspielstar sind, wird er über kurz oder lang merken was sie von ihm halten. Wenn Sie denken, Ihr Chef ist ein Idiot, werden sie das über Ihre Signale und Körpersprache zeigen und er wird Sie über kurz oder lang auch für einen Idioten halten. Nein, an dieser Stelle sind sie selbst gefragt und es liegt ganz alleine an ihnen, die Schwächen und eventuellen Defizite Ihres Chefs zu akzeptieren. Akzeptieren sie das was er nicht kann und arrangieren sie sich damit. Konzentrieren sie sich auf das was er gut kann und unterstützen sie ihn in den Bereichen, in denen das nicht der Fall ist. Wenn sie ihn ehrlich unterstützen und beraten, wird er Ihrem Rat auch irgendwann vertrauen. Das braucht Zeit. Zeit in der sie mit Worten und Taten zeigen, dass sie Loyal hinter ihm stehen. Diese Loyalität müssen Sie Ihrem Chef gegenüber erbringen- und zwar egal ob er dabei im Raum ist, oder sie sich mit Dritten unterhalten. Damit meine ich nicht, dass sie zum unterwürfigen Ja-Sager werden sollen. Das was Ihr Chef gut kann, sollte zur Geltung kommen. Bei dem was er nicht so gut kann, unterstützen sie ihn. So wird Ihre Beziehung zueinander immer besser. Ganz nebenbei erhöhen Sie dabei die Wahrscheinlichkeit, einer Folgebeauftragung oder nach Projektabschluss gleich ein neues Projekt übertragen zu bekommen. Denn wenn Sie Ihrem Chef stets den Rücken freihalten und er dank Ihrer Hilfe einen guten Job macht und seine Ziele erfüllt, wird er sich daran erinnern. Sie erarbeiten sich so den Ruf einer Allzweckwaffe- jemanden, auf den man sich verlassen kann, der Probleme löst und Dinge bewegt. Einen guten Rat hat mir diesbezüglich einmal der von mir hochgeschätzte Verkaufstrainer „Mike Diersen“ gegeben: „Wenn Du es mit einem echt schwierigen Menschen zu tun hast, der Dich oder andere vielleicht sogar ungerecht behandelt und Du merkst wie es langsam in Dir hochkocht…dann denk „Ich mag Dich“ und lächle dabei, denk es nochmal und nochmal…Du wirst merken, dann geht es Dir besser“. Es klingt banal, aber ich hab es ausprobiert und es funktioniert. Probieren sie es selbst! Loyalität bedeutet auch, dass Sie Ungerechtigkeiten, oder Fehler Ihres Chefs nicht vor dem Projektteam ausfechten, sondern in einem persönlichen Gespräch mit ihm. Kritisieren sie Ihren Chef niemals vor anderen. Selbst wenn sie persönlich von ihm angegriffen werden, widerstehen sie dem Drang aufzubegehren oder Kontra zu geben. Bleiben sie souverän und selbstbewusst und klären sie das bitte im Nachgang im 4-Augen Gespräch. Wird dagegen Ihr Team oder einzelne Mitarbeiter direkt von ihm angegriffen, ist es aber sehr wohl Ihre Pflicht sich vor Ihre Leute zu stellen. Loyalität beweisen sie aber auch, indem sie Ihren Chef schützen. Wenn Sie einen Wissensvorsprung Ihrem Chef gegenüber haben, der für ihn relevant ist, so sollten sie ihn darüber in Kenntnis setzen. Berichten sie proaktiv was im Projekt gelaufen ist, wo das Projekt aktuell steht welche Risiken und Chancen Sie sehen und was die nächsten Schritte. Vermeiden sie es unbedingt sich mit ihrem Projektteam in ein dunkles Kämmerlein einzuschließen und erst einen Ton von sich zu geben, wenn das Projekt zu Ende ist. Berichten Sie regelmäßig und aus Eigenmotivation heraus ihren Projektstatus. Damit zeigen sie Professionalität. Warnen sie Ihren Chef rechtzeitig vor potenziellen Gefahren im Unternehmen und im Projekt. Zusammenfassend, es geht nicht nur darum, dass Sie einen guten Job machen. Entscheidend ist, dass Ihr Chef der Überzeugung ist, dass Sie einen guten Job machen! Und wenn Ihr Chef einen guten Job gemacht hat, dann loben Sie ihn. Auch er ist nur ein Mensch und ist für ehrlich gemeinten Lob empfänglich. Im Wesentlichen sind es also 3 Dinge die Ihr Vorgesetzter von Ihnen erwartet. Und es ist wenig überraschend dass es die gleichen 3 Dinge sind, die Sie auch von Ihren Projektmitarbeiter erwarten: • Leistung o Das ist die beste Möglichkeit Ihrem Chef den Rücken freizuhalten. Bringen Sie Leistung damit Ihr Vorgesetzter seine Ziele erreicht. Leistung alleine reicht aber nicht. Als Mitarbeiter werden Sie als „schwierig und unangenehm“ wahrgenommen, wenn die beiden folgenden Punkte nicht gegeben sind • Loyalität o Gemeint ist die Loyalität gegenüber dem Vorgesetzten. Kann er sich auf Sie verlassen? o Stellen Sie sich auch Dritten gegenüber, wenn Ihr Chef nicht im Raum ist, hinter ihn und seine Entscheidungen? o Selbst dann, wenn Sie nicht 100% seiner Meinung sind? Und schließlich… • Die Anerkennung seiner Autorität o Der Vorgesetzte ist der Vorgesetzte. o Wenn Sie das nicht akzeptieren und sie ihm das durch Gesten, Körpersprache oder „noch deutlicher“ zu verstehen geben, beschwören Sie einen Konflikt herauf. o Kein Vorgesetzter kann und darf das über kurz oder lang dulden. o Akzeptieren sie die gegebene Rollenverteilung und seien sie Profi. So Ihr lieben, damit möchte ich für heute wieder mal schließen. Ich hoffe es war auch heute wieder das ein, oder andere dabei was Sie in Ihrer beruflichen Praxis verwenden können. Ich würde mich freuen. Nichts was ich hier erzähle ist neu. Das meiste davon kennen Sie wahrscheinlich. Aber sie werden mir zustimmen, dass Wissen alleine uns leider nicht weiter bringt. Ich habe noch nie Golf gespielt. Geben Sie mir ein halbes Jahr Zeit und ich werde, wenn es drauf ankommt, so ziemlich alles Relevante über Golf spielen gelesen haben, was man dazu lesen kann. Ich werden Ihnen dann auch sicher etwas über Spieltechniken und Ausrüstung erzählen können. Aber kann ich danach Golf spielen? Ich wäre sicherlich der Brüller auf dem Golfplatz. Und ganz genauso verhält es sich mit unserem theoretischen Fachwissen. Wir müssen es anwenden, ausprobieren, auf die eigenen Bedürfnisse anpassen und adaptieren. Nur angewendetes Wissen ist nützliches Wissen. Wenn sie sich theoretisches Wissen aneignen, aber nie anwenden, werden sie es sehr schnell zu großen Teilen wieder vergessen haben. Ich versuche in diesem Podcast immer wieder meine eigene Praxiserfahrung einfließen zu lassen, um Ihnen zu zeigen was bei mir funktioniert und was vielleicht nicht funktioniert hat. Ich möchte Sie mit diesem Podcast an Ihr theoretisches Wissen erinnern, denn genau das ist das Schöne an einem Podcast: Sie können ihn sich so oft anhören wie sie wollen. Und vielleicht stehen Sie ja mal vor einer Entscheidung, oder haben ein Problem und erinnern sich, dass wir das mal in einer Podcast folge besprochen haben. Dann kommen sie einfach auf unser Portal und hören sich die betreffende Folge nochmal an. Sicherlich haben auch Sie solche Praxiserfahrungen gemacht. Wenn Sie möchten, schreiben sie mir doch davon. Vielleicht kann ich das ja sogar mal in eine der nächsten Folgen einbauen. Ich freue mich schon auf die nächste Folge, denn dann stelle ich Ihnen eine kleine Handlungsliste vor mit deren Hilfe Sie schneller in Ihr Projekt finden. Bis dahin wünsche ich Ihnen viele grüne Meilensteine Ihr Andreas Haberer. Weitere Informationen finden Sie unter www.Bundesvereinigung-ITPM.de

Nachdem wir uns in den vergangenen Folgen mit Themen wie das Geschäft eines selbständigen IT Projektmanagers funktionieren kann und mit dem Thema Anforderungsmanagement beschäftigt haben, möchte ich heute über die Situation eines neuen Projektleiters sprechen, der in ein laufendes Projekt einsteigt. Die Gründe dafür können recht unterschiedlich sein. Vielleicht ist der bisherige Projektleiter „um priorisiert“ worden, ist krankheitsbedingt ausgefallen, oder der Lenkungsausschuss hat sich für eine Doppelspitze in der Projektleitung entschieden. Tatsächlich hatte ich in meiner beruflichen Laufbahn nur sehr selten die Ehre ein Projekt ganz von Beginn an zu begleiten. In den allermeisten Fällen stieg ich als Projektleiter, Teilprojektleiter oder als Verstärkung der Projektleitung in ein laufendes Projekt ein. Mit dieser Situation und was man tun kann, um sich möglichst schnell ein Bild über den Projektstatus und das Umfeld in dem man zukünftig agieren muss zu verschaffen, möchte ich mich mit der heutigen Folge beschäftigen. Kommt man als externer Projektleiter neu in ein bisher unbekanntes Unternehmen, macht es Sinn zu zunächst mit einer Projekt-Umfeldanalyse einen Überblick zu verschaffen. Diese hilft Klarheit über die Rahmenbedingung und Einflussfaktoren auf das Projekt zu bekommen. Aber selbst wenn man ein Unternehmen und dessen Organisation kennt und „nur“ ein neues Projekt übertragen bekommt, gibt es im Umfeld dieses Projektes häufig Spannungen und Strömungen die man kennen und bearbeiten sollte. Auch hier kann eine Projekt-Umfeldanalyse, oder PUMA wie sie gerne abgekürzt wird, die notwendige Klarheit schaffen. Neben den formalen Aspekten des Projektumfeldes, rate ich aber auch dazu, die sozialen Aspekte des Projektes genau zu betrachten. Also, das was zwischen den Zeilen passiert- und zwar auf allen Ebenen. Auf der Ebene des Chefs, auf der der Projektmitarbeiter, aber auch auf Ebene von anderen Projekten die uns zuarbeiten, oder für die wir mit unserem Projekt Zuarbeit leisten. Das Ganze beginnt schon beim einführenden Gespräch mit dem Chef oder Auftraggeber. Ich versuche in diesen ersten Gesprächen herauszufinden, was von mir erwartet wird. Schließlich wird er oder sie am Ende darüber entscheiden, ob meine Arbeit als Erfolg oder Misserfolg betrachtet wird. Ideal ist es, im persönlichen Gespräch die Erwartungen und Ziele zu erfahren und diese gemeinsam schriftlich zu festzuhalten. Die Schriftlichkeit hat den Vorteil, dass man sich bei der Formulierung mit dem Inhalt noch einmal genau auseinandersetzt. Ich versuche bei diesem, oder diesen Gesprächen zu klären, was die Projektvision ist. Also das WARUM…welcher Nutzen soll durch das Projektergebnis entstehen. Was wird von mir erwartet, um zu helfen diese Vision wahr werden zu lassen? Bei solchen Gesprächen erfährt man auch sehr viel über die Werte Ihres Auftraggebers, also das was ihm wichtig ist: • Was hält der Chef vom Projekt, dem Projektumfeld und vom Projektteam? • Was lief bislang vielleicht nicht so gut und woran lag das? • Was kann ich in dieser Hinsicht zukünftig besser machen? • Wo sind die besonderen Stärken des Projektteams und welche davon sind weiter zu fördern? • Fragen Sie nach, was Sie über einzelne Projektmitarbeiter, oder das Projektklima wissen sollten? • Gibt es innerhalb des Projektteams vielleicht Gruppierungen, Meinungsführer, oder gar Störenfriede? • Warum holte man mich genau jetzt in das Projekt dazu, wie kam es zu dieser Entscheidung? • Was glaubt mein Auftraggeber, was das Projektteam von mir erwartet? Hören Sie bei diesen Gesprächen sehr genau zu, vor allem auch auf das, was zwischen den Zeilen gesagt wird und notieren Sie ihre Erkenntnisse. Auf diese Weise bekommen Sie die Kriterien heraus auf die er achtet und woran Ihr Auftraggeber erkennen wird, dass Sie erfolgreich Ihre Aufgabe bewältigen. Genau das muss ja auch Ihr Ziel sein. Vergessen Sie aber die letzte Frage nicht, nämlich ob Sie etwas vergessen haben zu fragen. Mit dieser letzten Frage, habe ich schon buchstäblich wahre Wunder erlebt und brachte nochmal ganz neue Aspekte in das Gesamtbild. Nach diesen Vorgesprächen kommt irgendwann der Zeitpunkt, an dem es im Projekt dann produktiv losgeht. Ich habe selbst damit gute Erfahrung gemacht, mich dem Projektteam vorzustellen und dann in lockeren Einzelgesprächen die Projektmitarbeiter näher kennen zu lernen. Verzichten Sie dabei auf schwammiges Blubbern, Motivationsreden und all das andere aufgesetzte und arroganten Managementgeschwätz. Das sorgt lediglich dafür, dass sehr schnell alle Klappen zu fahren und Sie gar nichts mehr erreichen. Seien Sie einfach Mensch, der ehrlich und offen rüber kommt. Wertschätzen Sie Ihren potenziellen Vorgänger und seien Sie optimistisch, positiv und bitten Sie für die gemeinsame Zukunft, um die Unterstützung Ihres Teams. Wertschätzen Sie das vom Team bisher erreichte und die erzielten Erfolge. Fragen Sie auch nach, was gut läuft und wo es vielleicht Verbesserungspotenzial gibt. Betrachten Sie Vorschläge auf diese Frage hin, aber bitte auch als solche- und nicht als sofortige Handlungsaufforderungen. Versprechen Sie nichts, was Sie nicht halten können. Sprechen Sie mit Ihren Mitarbeitern auf Augenhöhe, nicht von oben herab. Machen Sie klar, dass Sie kein Superheld sind, der mit einem Schlag alles in Ordnung bringen kann und danach in den Sonnenuntergang reitet. Bei diesen Gesprächen mit den Projektmitarbeitern stellt man auch sehr schnell fest, wie weit die Vorstellungen des Chefs und die Tatsächliche Welt auseinander liegt. Mein Ziel bei diesen Gesprächen ist es, Vertrauen aufzubauen, aber auch umgekehrt um zu erfahren, wo für mich die Stolpersteine liegen. Fragen sie Ihre Projektmitarbeiter danach. Beschreiben Sie was Sie von Ihrem Team erwarten, was Ihnen wichtig ist und welchen Werten Sie folgen. Ich möchte Ihnen gerne dazu gerne ein paar Beispiele nennen. Auf einer Teamcharta können Regeln stehen wie: • Wir gehen respektvoll miteinander um, bleiben stets höflich und lassen einander ausreden • Jede Einladung zu einer Besprechung beinhaltet eine Agenda. Keine Besprechung ohne Agenda • Alle Teilnehmer die zugesagt haben, erscheinen pünktlich zu Besprechung • Der Einladende ist dafür verantwortlich, dass das geplante Zeitfenster der Besprechung nicht überschritten wird • Der Einladende ist für die Erstellung des Protokolls verantwortlich. Keine Besprechung ohne Protokoll Es bringt aber nichts, solche Regeln in eine Projektcharta zu schreiben, sie irgendwo auf dem Filesystem abzulegen und maximal noch einmal per Mail darauf hinzuweisen. Planen Sie dafür einen Workshop mit Ihrem Team. Nehmen Sie dazu ruhig Ihre Punkte und ergänzen Sie diese, um die Punkte die im Team hochkommen. Verpflichten Sie das Team auf den gemeinsamen Beschluss und hängen Sie diese Charta in das Teambüro, in den Besprechungsraum oder wo auch immer Sie täglich mehrfach gesehen wird. Achten Sie bei all den Gesprächen in den ersten Wochen genau darauf: • Wer kann mit wem und wer nicht? • Wie verhalten sich die Mitarbeiter untereinander? • Wie ist die Fehlerkultur? • Wie laufen Meetings ab? Das alles sind Fragen, die Sie sich in den ersten Wochen durch intensive Kommunikation und Beobachtung beantworten können. Kein Projektteam ist wie das andere und kein Unternehmen ist wie das andere. Auch ein Projektteam- und gerade wenn das Projekt schon eine Weile läuft, ist ein individuell soziales Gefüge. Der Führungsstil der vielleicht im letzten Projekt funktioniert hat, muss deshalb mit diesem Projektteam nicht auch zwangsweise funktionieren. Lernen Sie ihre Leute kennen und passen Sie sich an. Gerade in dieser Phase sind Softskills und soziale Kompetenzen gefragt. „Neue Besen kehren gut“…getreu diesem Motto entsteht häufig ein Aktionismus, der diesem gegenseitigen Vertrauensaufbau entgegenwirkt. Unterdrücken Sie den Impuls alles gleich auf den Kopf stellen zu wollen, was Sie auf den ersten Blick alles anders machen würden. Auch wenn es sich vielleicht aufdrängt. Häufig gibt es gerade für gewachsene Strukturen und Prozesse gute Gründe die es zu beachten gilt. Versuchen Sie das erst alles zu verstehen und zu bewerten, bevor Sie darüber nachdenken Änderungen einzuleiten. Das braucht einige Zeit. Lassen Sie beim operativen Geschäft vorerst alles weiterlaufen wie bisher. Vorausgesetzt natürlich, das Team selbst schreit nicht nach einer sofortigen Änderung. Bitte immer erst verstehen und dann erst handeln. Ich selbst führe in dieser Phase immer ein „Daily-Log“, mein Projekttagebuch also. Ich bin auch nur ein Mensch und gerade in der Projekt Anfangszeit gibt es so viele Informationen und Erkenntnisse die erst einmal zu verdauen sind. Beobachtungen-, das Gelernte-, aber auch nächste Schritte in einem Daily-Log zu notieren hat sich für mich bewährt. Wenn Sie nun einige Wochen damit verbracht haben zu verstehen und potenzielle Änderungsstrategien entwickelt haben, holen Sie Ihr Team ab und beteiligen Sie aktiv an der Ausarbeitung und Einführung dieser Veränderungen. Die meisten Menschen haben gar keine Probleme mit Veränderungen, aber kaum einer mag es, vor den Kopf gestoßen zu werden, indem sie vor vollendete Tatsachen gestellt werden. Erarbeiten Sie in Workshops, auf Basis Ihrer Erkenntnisse der letzten Wochen, mit Ihrem Team zusammen das WIE! Also Butter bei die Fische, erklären Sie welche Erwartungen Sie an die gewünschten Veränderungen haben und erarbeiten Sie mit dem Team den Weg dorthin. Spätestens jetzt ist es auch nötig ein gemeinsames Verständnis für das WARUM, also der gemeinsamen Vision und was das Projektergebnis verändern, also welcher Nutzen daraus erwachsen wird. Stimmt die gemeinsame Vision und sind alle damit ehrlich einverstanden, ist das schon die halbe Miete. Das soll jetzt kein Motivations-Voodoo werden. „Man kann Mitarbeiter nicht motivieren. Die Aufgabe einer Führungskraft ist es, diese nicht zu demotivieren“ diese Aussage stammt von Fredmund Malik, dem Managementwissenschaftler und Bestsellerautor. Frederick Herzberg detailliert diese Aussage noch etwas präziser: Er unterscheidet zwischen zwei Einflussfaktoren. Die einen Faktoren sind auf den Inhalt der Arbeit bezogen, also die Motivatoren, während sich die Hygienefaktoren auf den Kontext der Arbeit beziehen. Sie werden jetzt fragen, was meint er damit? Unter Hygienefaktoren versteht er jene Faktoren, die bei positiver Ausprägung für Zufriedenheit sorgen, während es bei negativer Aufprägung sehr schnell zu wachsender Unzufriedenheit kommt. Beispiele dafür sind: • Gehalt • Führungsstil des/der Vorgesetzten • Arbeitsbedingungen • Zwischenmenschliche Beziehungen • Sicherheit des Arbeitsplatzes • Einfluss auf das Privatleben Motivatoren beeinflussen nach Herzberg die Motivation zur Leistung selbst. Also inwieweit die Motivation intrinsisch, also von innen heraus wirkt. Beispiele dafür sind: • Erfolg und Anerkennung • Arbeitsinhalte • Aufstiegsmöglichkeiten • Beförderung • Wachstum Mir selbst wurde vor einigen Jahren eine Projektleitung übertragen, bei der ich ein völlig demotiviertes Team vorfand. Es waren ca. 15 Mitarbeiter im Projektteam, allesamt qualifizierte Spezialisten auf ihren Teilgebieten. Doch was war da los? Schon bei den ersten Gesprächen mit den Mitarbeitern fühlte ich mich, als würde ich mit dem Stock auf ein Wespennest hauen. Sie gingen regelrecht auf mich los, dass es kein Wunder wäre, dass wir ein Meilenstein nach dem anderen reißen! Ich stellte dabei schnell fest, dass innerhalb des Projektteams bereits schon „Grüppchenbildungen“ gegeben hat mit Wortführern und dem Eigeninteresse, Schuld und Fehler von sich zu weisen…“den eigenen Vorgarten sauber halten!“ Sie werden sich fragen: „Was war da los und was habe ich getan?“ Nun, zunächst habe ich getan, was sich in solchen Situationen immer empfiehlt. Ich habe zugehört - und die Leute am Abend zu einem Bier eingeladen. Ich fand heraus, dass mein Vorgänger seine Führungsrolle nie wirklich wahrgenommen hat. Er hatte, trotz der Teamgröße, selbst über Gebühr operative Aufgaben übernommen und sich darin vergraben, statt diese zu delegieren. Einen gemeinsamen Teamspirit, klarer Status wo das Projekt im Moment steht, was die nächsten Schritte sind und die Strategie zu Zielerreichung…alles Fehlanzeige. Das Projektteam tappte mehr oder minder im Dunkeln. Aufgrund all dieser Umstände machten die einzelnen Mitarbeiter in Eigenregie das, was sie glaubten was als nächstes zu erledigen war. Man berichtete mir, dass es dadurch mehrfach dazu kam, dass 2 Mitarbeiter unabhängig voneinander über Tage das gleiche gemacht haben, um am Ende festzustellen, dass hier Arbeit sinnlos doppelt geleistet wurde. In den Folgewochen führte ich wieder die bis dahin völlig zum Erliegen gekommenen jour fixe ein und berichtete, zum Erstaunen des Teams, selbst über das, was im Projektumfeld passiert, was der Lenkungsausschuss von uns erwartet und all die anderen Dinge aus Besprechungen, die für das Team relevant war. Die Stimmung besserte sich zunehmend. Das gemeinsame Abendessen und anschließende Bierchen machten wir alle 1-2 Wochen. Meist ging es dabei sehr wohl um fachliche Dinge aus dem Projekt. Ich glaube man muss auch gar nicht versuchen das zu unterbinden. Aber es mischten sich bei den lockeren Gesprächen auch immer wieder private und persönliche Themen darunter und das Team wurde zunehmen ein echtes Team, dass sich gegenseitig wertschätzte und unterstützte. Sie dürfen das jetzt nicht falsch verstehen. Auch wenn die gute Zusammenarbeit zwischen Projektleiter und Projektteam von entscheidender Bedeutung sein kann, es geht mir dabei nicht darum, „everybody’s Darling“ zu werden. Mir geht es um gegenseitiges Vertrauen und ein WIR Verständnis aufzubauen. Nur dann, ist die Leistungsfähigkeit des Teams größer als die Summe der einzelnen Teammitglieder. In der nächsten Folge, möchte ich mich mit Thema Teamentwicklung beschäftigen, wie Sie ein Vertrauensverhältnis zu Ihrem Chef oder Vorgesetzten aufbauen und wie Sie in ein neues Projekt hinein finden. Ich hoffe, dass Sie dann auch wieder dabei sind und wünsche Ihnen bis dahin lauter grüne Meilensteine Ihr Andreas Haberer Weitere Informationen finden Sie unter www.Bundesvereinigung-ITPM.de

Muss man Anforderungen in verschiedene Arten unterteilen Ja, man muss unterscheidet zwischen den verschiedenen Sichten auf Anforderungen und zwischen Anforderungsarten. Bei den Anforderungssichten unterscheidet man zwischen • Marktanforderungen o Beschreibt die Anforderungen an ein Produkt aus Sicht des Kunden. Sie beschreiben aus Sicht des Kunden, warum ein Projekt überhaupt durchgeführt wird. Marktanforderungen werden im Lastenheft dokumentiert. • Produktanforderungen o Produktanforderungen beschreiben Anforderungen an ein Produkt aus Sicht der Lösungsrealisierung. Produktanforderungen beschreiben die Eigenschaften aus Lösungssicht. Sie werden daher häufig auch als Funktionen, Eigenschaften, oder Systemanforderungen bezeichnet. Produktanforderungen werden im Pflichtenheft dokumentiert. • Komponentenanforderungen o Wie der Name schon erahnen lässt, beschreiben Komponentenanforderungen die Anforderungen an eine Komponente des zu realisierenden Produkts. Sie beschreibt, wie die Produktanforderungen durch eine Komponente des Produktes realisiert wird. Komponentenanforderungen werden häufig auch im Pflichtenheft, oder aber in den Feinspezifikationen, oder Fachkonzepten dokumentiert. Bei der Darstellung der Sichten auf Anforderungen, habe ich bewusst darauf Bezug genommen, wo diese in der Regel zu dokumentieren ist. Ich erlebe in der Praxis immer wieder eine gewisse Unsicherheit was nun in einem Lastenheft- und was nun in einem Pflichtenheft zu dokumentieren ist. Diese Unsicherheit geht soweit, dass ich erlebe, dass Lasten- und Pflichtenheft synonym behandelt werden- und genauso sehen dann die Dokumente aus. Lassen Sie mich an einem kleinen Beispiel verdeutlichen, wie man Lasten- und Pflichtenhefte inhaltlich voneinander differenzieren kann. Ich möchte dazu einen kleinen Ausflug in eine andere Branche machen. Ich nehme an, sie alle haben ein Auto, oder kennen sich zumindest halbwegs damit aus. Angenommen ich möchte mir ein Auto bauen lassen und eine meiner beispielhaft formulierten Anforderungen lautet: Requirement 001: „Der Fahrer muss während der Fahrt, blendungsfrei, den rückwärtigen Verkehr beobachten können, ohne dass er dafür den Kopf drehen muss.“ Dann könnten die Pflichten dazu wie folgt aussehen: • Pflicht 001: Es wird ein Innenspiegel an der Windschutzscheibe montiert, der eine automatische Abblendfunktion hat. o Bezug: Requirement 001 • Pflicht 002: Es wird ein linker Außenspiegel montiert der elektrisch beheizbar und vom Fahrersitz aus fernbedient elektrisch verstellbar ist o Bezug: Requirement 001 • Pflicht 003: Es wird ein rechter Außenspiegel montiert der elektrisch beheizbar und vom Fahrersitz aus fernbedient elektrisch verstellbar ist o Bezug: Requirement 001 Das ganze würden wir jetzt noch weiter herunterbrechen, indem wir in den Feinspezifikationen des Innenspiegels und der Außenspiegel die technischen Details der Spiegel beschreiben. Also die Servomotoren der elektrischen Spiegelverstellung und die Mechanik. Das Gehäuse und die Art der Spiegel usw. Alle Automobilbauer mögen mir an dieser Stelle hoffentlich meine Laienhafte Darstellung verzeihen, aber ich finde diesen konstruierten Anforderungsbaum sehr leicht verständlich um die Unterschiede zwischen Lastenheft, Pflichtenheft und Feinspezifikationen darzustellen. Aber nun zurück zu den Anforderungsarten. Bei den Arten von Anforderungen unterscheidet man zwischen • Funktionalen Anforderungen o  Funktionale Anforderungen aus Anwendersicht • Beispiele dafür sind Benutzeroberfläche, Anwendungsfälle oder Verarbeitungsergebnisse  Funktionale Anforderungen aus interner Sicht • Beispiele dafür sind Architektur, Anforderungen die wiederverwendete Komponenten stellen, verwendete Datenbanken, verwendete Programmschichten, Betriebssystem oder Verschlüsselungen. o Funktionale Anforderungen sind konkrete Funktionen und Ablaufszenarien die beschreiben, wie ein System auf bestimmte Eingangsparameter zu reagieren hat. Dazu zählen auch Geschäftsprozesse, Workflows und Anwendungsfälle (Usecases). • Qualitätsanforderungen o Eine Qualitätsanforderung beschreibt eine qualitative Eigenschaft, die das betrachtete System, oder einzelne Funktionen des Systems aufweisen müssen. Sie werden manchmal auch als „nicht-funktionale Anforderungen“ bezeichnet. o Auch bei Qualitätsanforderungen unterscheidet man zwischen  Qualitätsanforderungen aus Anwendersicht • Beschreibt in der Regel den Zusatznutzen aus Auftraggeber Sicht. Beispiele dafür sind Anforderungen an Informations- und Datensicherheit, Erfüllung von Normen und Standards, oder Benutzbarkeit aus Sicht des späteren Anwenders.  Qualitätsanforderungen aus interner Sicht • Dies sind Anforderungen, die vor allem aus Entwicklersicht eine Rolle spielen. Dazu gehören beispielsweise konkrete Anforderungen an Architektur oder Stromverbrauch, aber auch Codequalität, Dokumentation und Validierbarkeit. • Randbedingungen o Dabei handelt es sich um organisatorische, oder technische Anforderungen die sich auf die Systemrealisierung auswirken. Sie ergänzen funktionale Anforderungen und Qualitätsanforderung. o Beispiele dafür sind zu beachtende Gesetze, Normen, Geschäftsprozesse, Richtlinien usw. Das Problem vieler Anbieter ist, dass viel zu häufig Funktionen und zu wenig Visionen verkauft werden. Steve Jobs war mit Appel an dieser Stelle ganz sicher eine glanzvolle Ausnahme. Als Ingenieure und Techniker sind wir es gewohnt in technischen Problemlösungen zu denken. Wir finden Lösungen und implementieren diese. Allerdings führen diese Lösungen nicht automatisch zum Markterfolg. Das überrascht uns dann, wo diese Lösung doch so viele spannende und interessante Feature hat. Dann muss man sich fragen, ob man die Lösung wirklich am Bedarf ausgerichtet wurde, oder wurden wir da nicht einfach vom „Machbaren“ angespornt- egal ob es jemand braucht? Schaffen wir Visionen einer besseren Zukunft für den Anwender oder erstickt dieser lediglich in Komplexität und Funktionalität? Ein Projekt ist dann erfolgreich, wenn es den Bedürfnissen seiner Benutzer und seiner Umgebung gerecht wird. Anforderungen formulieren diese Bedürfnisse und das Anforderungsmanagement ist die Disziplin, welche die Behandlung von Anforderungen über den kompletten Projektzyklus hinweg steuert. Zu einer Anforderung gehört allerdings auch immer die Perspektive aus der sie beschrieben wurde dazu. Bei der Formulierung von Anforderungen ist es daher immer ratsam, diese aus dem Kontext heraus auch zu begründen. Nur so ist es bei komplexen Anforderungskatalogen und Projekten die sich über einen längeren Zeithorizont hinweg ziehen möglich, zu verstehen warum diese Anforderung einst so formuliert wurde wie sie ist, was der Anforderer damit bezwecken wollte und welche Auswirkung eine potenzielle Änderung dieser Anforderung auf die ursprüngliche Intension hätte. Aber bei aller Kritik, es gibt auch genügend Projekte die ganz hervorragende Arbeit leisten, hervorragend gemanagte werden und ihre Ziele erreichen. Erfolg ist machbar! Das haben viele Unternehmen erkannt und haben ihre Projektmanagementprozesse optimiert oder ganz neu ausgerichtet. In vielen Unternehmen gab es keinen gelebten Projektmanagementprozess. Doch das Verständnis, was mit exzellentem IT Projektmanagement an Produktivitätssteigerung und Effizienz erreicht werden kann, wird immer größer. Sicherlich leistet dazu auch die Deutsche Gesellschaft für Projektmanagement (GPM) mit ihrem alljährlichen „Deutschen Project Excellence Award“ einen wesentlichen Beitrag. Dieser Preis wird an Unternehmen und deren Projekte vergeben, die sich durch exzellentes Projektmanagement auszeichnen. Ich habe die Ehre für die GPM schon seit einigen Jahren als Projektmanagement Assessor zusammen mit meinen Kollegen die Bewerberprojekte zu auditieren und kann nur bestätigen, dass in Deutschland großartige Projektmanagement Arbeit geleistet wird. Zusammenfassend möchte ich noch einmal auf die Praxistipps aus Christof Eberts Buch „Requirements Engineering“ hinweisen und abschließend zur letzten und zur heutigen Folge wie folgt resümieren: • Trennen Sie bei der Anforderungsentwicklung zwischen der internen Sicht und der externen Sicht • Anforderungsmanagement ist sowohl bei der Entwicklung neuer Produkte, als auch bei der Änderung bestehender Produkte anzuwenden. • Anforderungsmanagement erfolgt bereits vor Projektstart und über den gesamten Projektzeitraum hinweg. • Betrachten Sie die drei Typen von Anforderungen nämlich Produktanforderungen, Marktanforderungen und Komponentenanforderungen. Vermischen Sie diese Anforderungen niemals. • Vermischen Sie auch niemals das Was und das Wie. • Beginnen Sie nicht zu früh mit der Lösung, solange noch nicht klar ist, was die wesentlichen Elemente sind. • Modellieren Sie vom Lasten- hin zum Pflichtenheft sowohl die Systemumgebung, als auch die zu entwickelnde Systemarchitektur. Letztere muss ausreichend detailliert sein, bevor man mit den Feinspezifikationen beginnt. • Betrachten Sie bei Änderungswünschen immer die Auswirkungen auf Terminplan, Kosten und bereits realisierte Komponenten. Tappen Sie niemals in die Falle, einen Änderungswunsch isoliert von deren Auswirkungen zu betrachten. • Berücksichtigen Sie alle Anforderungen. Fragen Sie die relevanten Interessensvertreter, ob etwas übersehen wurde. Machen Sie dabei klar, dass die Ermittlung von Anforderungen noch keine Garantie für deren Lieferung ist. Geliefert wird nur, was vereinbart und bezahlt ist. Soviel für heute zum Thema Anforderungsmanagement. Ich hoffe es hat Ihnen genauso viel Spaß gemacht wie mir und es war das ein- oder andere Neue für sie dabei. Ich freue mich schon auf die nächste Folge und wünsche Ihnen bis dahin lauter grüne Meilensteine. Ihr Andreas Haberer. Podcast abonnieren und bewerten Um meinen Podcast zu abonnieren und zukünftig keine Folge mehr zu verpassen, klicken Sie auf die folgenden Links: Hier klicken, um den Podcast über iTunes zu abonnieren. Hier klicken, um den Podcast für RSS Feed zu abonnieren. Wie hat Ihnen diese Folge gefallen? Ich freue mich über ehrliches Feedback und konstruktive Anregungen. Hinterlassen Sie mir doch bitte einen Kommentar auf unserer Homepage www.Bundesvereinigung-ITPM.net- Ich würde mich auch sehr freuen, wenn Sie den Podcast in iTunes bewerten. Das hilft mir den Podcast bekannter zu machen. Weitere Informationen finden Sie unter www.Bundesvereinigung-ITPM.de

Anforderungsmanagement Der Fachbuchautor Christof Ebert schreibt in seinem Buch „Systematisches Requirement Engineering“: „Früher dachte ich, Termin und Budgetüberschreitungen kommen von schlechter Schätzung. Dann dachte ich, sie kommen von hoher Komplexität. Heute weiß ich, dass sie davon kommen, dass praktisch alle Projekte zu spät begonnen werden. Dann fehlt die Zeit für die Anforderungsanalyse und Planung. Damit ist das Scheitern vorprogrammiert.“ (Ebert, 2012) Die Einsicht deckt sich auch mit meinen Erfahrungen der letzten 20 Jahre. Und das unabhängig ob es sich um Auftragsentwicklungen, oder interne Unternehmensprojekte handelt. Es wird viel Zeit in die Akquise und die Verhandlungen zu einem Projekt gesteckt. Der Auftrag liegt auf dem Tisch und das Projektteam steht womöglich auch schon in den Startlöchern. Jetzt müssen sie schnell produktiv werden. Da ist die Verlockung groß, die Anforderungen nicht weiter ins Detail zu zerlegen und abzustimmen, sondern schon mal beginnen zu lassen. Aber was versteht man eigentlich genau unter einer „Anforderung“? Eine Anforderung beschreibt, was der Kunde, Auftraggeber oder Benutzer vom zu entwickelnden Produkt erwartet (Nutzen, Eigenschaften, Verhalten, Attribute, Mehrwert) „Könntest Du mir bitte sagen, welchen Weg ich von hier aus nehmen soll?“, fragt Alice im Wunderland die Katze am Wegesrand. „Das hängt vor allem davon ab, wohin Du gehen willst“, antwortet diese. „Ich weiß es nicht…“, sagte Alice. „Dann ist es egal, wohin Du gehst“, antwortet die Katze. (Carroll, 1865) Auch wenn dieser amüsante Dialog aus dieser herrlichen Geschichte witzig anmutet, steckt doch sehr viel Weisheit darin. Ohne ein klares Ziel, wird uns der Weg den wir gehen irgendwo hinbringen. Auf das IT Projektgeschäft übertragen ist es damit aber reiner Zufall wenn wir das treffen, was der Kunde eigentlich wollte. Viel höher ist die Wahrscheinlichkeit dass wir völlig daneben liegen. Fällt das in einem frühen Projektstadium auf, können mittels Changerequest vielleicht noch notwendige Änderungen eingesteuert werden. Je später im Zeitverlauf eines Projektes aber noch Änderungen durchgeführt werden, desto größer sind die Auswirkungen. Das betrifft sowohl Wechselwirkungen mit der Änderungen mit bereits realisierten Systemteilen, als auch Auswirkungen bestehende Dokumentationen und Architekturen. Damit ist ein Designfreeze so früh wie möglich anzustreben und ab dann Änderungen nur noch über einen geregelten Prozess zuzulassen. Dieser intensiv zu managende Änderungsprozess muss die Auswirkungen von ChangeRequests transparent machen. Dafür ist kompetentes Personal einzuplanen. Nur wenn die Auswirkungen und damit Risiken einer Änderung im Detail klar sind, kann über ihre Umsetzung entschieden werden. Mit diesem kleinen Ausflug in das Änderungsmanagement wird klar, dass es deutlich besser ist, Änderungen nach Möglichkeit zu vermeiden. Ist diese Aussage aber richtig, wenn man sich moderne agile Entwicklungsmethoden ansieht, die Änderungen willkommen heißen? Ich glaube ja, denn auch bei agilen Methoden sind klare Anforderung die Basis für den Projekterfolg. Doch Anforderungen sind per Definition unsicher. Christof Ebert schreibt dazu in seinem Buch, dass sich Anforderungen mit einer monatlichen Rate, die 1-5% des gesamten Projektauftrags betragen ändern. Das heißt, dass von Anforderungen, die mit insgesamt 100 Personenwochen Projektaufwand abgeschätzt wurden, sich pro Monat Anforderungen im Umfang von bis zu 5 Wochen ändern! Diese 5 Wochen relative Änderung sind nicht immer mit 5 Personenwochen Aufwand zu erledigen. Stellen Sie sich vor, dass die Änderung erst kommt, nachdem die Anforderung bereits integriert ist. Dann kann eine Änderung ein Vielfaches des ursprünglich dafür notwendigen Aufwands betragen. Diese Hebelwirkung unterstreicht nochmals den Geschäftsnutzen eines systematischen Requirement Engineerings. Was über dieser 5% Änderungsrate pro Monat liegt, gefährdet den Projektverlauf massiv und die daraus resultierenden Projektrisiken können nur mit iterativen oder agilen Vorgehensweisen kompensiert werden. Die Standish Group erstellt seit 1994 alljährlich den Chaos Report der sich mit dem Erfolg- bzw. Misserfolg von IT Projekten beschäftigt. Sie gehört zu den bekanntesten und wichtigsten Langzeitstudien im Bereich Projektmanagement, seit 1994 wurden über 40.000 Einzelprojekte wissenschaftlich untersucht. Die Studie unterteilt in Typ1, Typ2 und Typ3 Projekte. • Typ 1 • Projekt erfolgreich abgeschlossen: Das Projekt wurde rechtzeitig, ohne Kostenüberschreitung und mit dem ursprünglich geforderten Funktionsumfang abgeschlossen. • Typ 2 • Projekt teilweise erfolgreich: Das Projekt wurde abgeschlossen, es kam jedoch zu Kosten- und/oder Zeitüberschreitungen oder es wurde nicht der vollständige geplante Funktionsumfang erreicht. • Typ 3 • Projekt nicht erfolgreich: Das Projekt wurde abgebrochen. Die Studie untersucht Ursachen für Erfolg und Misserfolg und stellt eine Korrelation zwischen Erfolgswahrscheinlichkeit und Projektgröße fest. Die festgestellten Haupterfolgsfaktoren sind: 1. Einbindung der Endbenutzer 2. Unterstützung durch das obere Management 3. Klare Anforderungen Die Hauptpunkte, die zum Scheitern der Projekte führen sind: 1. fehlende Zuarbeit durch Benutzer 2. unvollständige/unklare Anforderungen 3. häufige Anforderungsänderungen (http://de.wikipedia.org, 2015) Auch wenn die Studie in den letzten Jahren stark unter Kritik stand und vor allem die von der Standish Group unbelegten Abbruchzahlen angezweifelt werden, die Studie bestätigt das Paradigma moderner Projektmanagementsysteme, klare Anforderungsdefinition und intensive Einbindung der aller Stakeholder in das Projekt zu forcieren. Interessant in diesem Zusammenhang ist auch die Beobachtung, dass in Krisenzeiten wie in den Jahren 2001 nach dem 11. September und 2008 in der Wirtschaftskrise die vermeintlich unnötigen Ausgaben für Anforderungsmanagement und Reviews drastisch reduziert wurden. Dies hatte jeweils dramatischen Einfluss auf die Projekterfolge der betreffenden Jahre. Christof Ebert resümiert in seinem Buch „Technologische Herausforderungen sind keine gravierenden Projektrisiken. Schlechtes Projektmanagement dagegen schon.“ (Ebert, 2012) Doch wo sind die Schwierigkeiten zu klaren Anforderungen zu kommen? Da ist wie oben bereits erwähnt häufig einfach der Zeitfaktor. Doch wie wichtig es für den Anforderungsmanager ist, Anforderungen immer weiter herunter zu brechen und zu hinterfragen zeigt die Praxis. Mit den folgenden Beispielen möchte ich das etwas deutlicher machen: • Beispiel1: Der Auftraggeber erwähnt Funktionen nicht, weil sie für ihn selbstverständlich sind o Hier muss die Devise lauten, „denken Sie nicht für Ihren Auftraggeber, sondern lassen Sie es sich erklären“. Der Auftraggeber und seine Vertreter sind in der Regel die Spezialisten für das was am Ende herauskommen soll. Als Anforderungsanalyst lässt man sich hier häufig schnell dazu verleiten zu glauben verstanden zu haben und nicht weiter fragen. Sprechen Sie aus was Sie glauben verstanden zu haben und lassen Sie sich ihre Auffassung bestätigen. Sie kennen die Bedürfnisse des Kunden und das was er braucht, niemals so gut wie er selbst. Eine der Schlüsselregeln im Requirement Engineering besagt, dass man dem Kunden das liefern muss was er will und nicht das, was er (vermeintlich) braucht. • Beispiel2: Schwammig formuliere Anforderungen o Schwammige Formulierungen sind irgendwie tierisch bequem- für beide Seiten. Deshalb sind sie ja auch so beliebt. Der Auftraggeber soll sich festlegen- weiß aber im Detail vielleicht gar nicht so genau was er will. Gut wenn die Formulierung da butterweich formuliert ist und man da am Ende noch jede Menge Interpretationsspielraum hat was eigentlich gemeint war. o Auf der anderen Seite ist da natürlich die Auftragnehmer Seite. Auch hier sind schwammige Formulierungen eine bequeme Sache- vor allem wenn man noch nicht so genau weiß wie man es machen will und was das Ergebnis wirklich alles können wird. o Schwammige Anforderungen sind also allseits beliebt- zumindest in der Definitionsphase der Anforderungen. Spätestens wenn es an die Realisierung geht, fallen diese mit aller Gewalt auf die Füße. Dann hagelt es Changerequests und Designfehler wegen unklarer Anforderungslage • Beispiel3: Anforderungen die erst spät klar werden o Je innovativer und komplexer ein Projekt ist, desto höher ist die Wahrscheinlichkeit, dass sowohl von Auftraggeber- als auch von Auftragnehmer Seite Anforderungen erst sehr spät in der Realisierungsphase klar werden. Dieser Gefahr entgegnet man durch eine gründliche Anforderungsanalyse in der die künftigen Anwendungsszenare durchgespielt und immer wieder auf Konsistenz geprüft werden. Daraus ergeben sich die 3 Hauptrisiken des Anforderungsmanagements: • Fehlende Anforderungen o Es ist wichtig zu aller erst den Business Case des Kunden zu verstehen. Mit dem Verständnis für den Business Case, wird der Nutzen klar, der für den Kunden nach erfolgreicher Projektrealisierung entstehen soll. o Das blose Abfragen all dieser Anforderungen macht eine Anforderungsspezifikation aber noch lange nicht vollständig. Es ist wichtig den Grund, die Querbeziehung zwischen den Anforderungen und die Perspektive aus der heraus die Anforderung formuliert wurde zu verstehen. • Falsche Anforderungen o So wie man vergeblich nach fehlerfreier Software sucht, so muss man auch von fehlerhaften Anforderungen ausgehen. Doch qualitativ unzureichende Anforderungen die widersprüchlich-, inkonsistent-, lückenhaft sind, oder Denkfehler aufweisen führen nicht nur zu ständigen ChangeRequests, sie reduzieren auch die Arbeitsmotivation des Projektteams das durch solche Anforderungen zunehmend orientierungsloser wird. o Nur durch frühzeitiges validieren und verifizieren der Anforderungen, werden Fehler aufgedeckt. Die späteren Anwendungsszenare sind immer und immer wieder durchzuspielen um solche Fehler aufzudecken. o Am besten machen das erfahrungsgemäß die Tester. Diese haben ein Händchen für das Fehlerpotenzial und entdecken bei Reviews sehr viel mehr Fehler als Projektmanager oder Architekten. Darüber hinaus, ist es ein hervorragendes Training für die eigentlichen Tests, denn dadurch sind die Anwendungsszenare bestens bekannt. • Sich ändernde Anforderungen o Anforderungen deren Änderungen nicht kontrolliert werden, führen zu Termin und Kostenüberschreitungen und haben negativen Einfluss auf die Qualität o Auf keinen Fall dürfen Änderungen durchgeführt werden, deren Auswirkungen nicht analysiert und bewertet wurden. o Ab der zweiten Projekthälfte ist es ratsam, nur noch sehr wichtige Änderungen ohne größere Auswirkungen zuzulassen. o Ich wurde kürzlich von einem sehr jungen Softwareentwickler gefragt, ob man meiner Meinung nach jedes Projekt und sei es noch so klein, managen muss? Ich antwortete ihm, dass selbst ein Kleinstprojekt ein funktionierenden Änderungsmanagement benötig. Nur so ist dokumentiert, welche Anforderungen aktuell gültig sind und wo Änderungen anstehen. Hast Du Deinem Kunden erst einmal einen Termin auf Basis der vereinbarten Anforderungen versprochen, wirst Du es häufig erleben dass schon kurze Zeit danach die ersten Änderungswünsche hereinschneien. Das ist zwar ganz normal- muss aber abgefangen werden. Denn meist handelt es sich ja nur um „Kleinigkeiten“ die man doch noch so mitmachen kann. Doch auch vermeintliche Kleinigkeiten haben Wechselwirkung mit anderen Systemteilen, erhöhen die Komplexität und den Testaufwand. Ehe man sich versieht baut man sich mit einer solchen Kleinigkeit einen Fehler an ganz anderer Stelle ein. Und wenn man es erst einmal zugelassen hat, dass der Auftraggeber noch Anforderungen nachschieben darf, wird man das sehr schnell kaum noch unterbinden können. Und wie soll das Projekt dann zum vereinbarten Termin fertig werden? Änderungen erzeugen Aufwand für Realisierung, Test und Dokumentation und der muss sich auf die benötigte Realisierungszeit niederschlagen. Man müsste sich ja unterstellen lassen, den Aufwand nicht ehrlich kalkuliert zu haben, wenn Änderungen möglich sind, ohne dass dies Auswirkung auf Zeit und Geld hat. Nur wer Änderungen kontrolliert, hat die Möglichkeit die Erreichung der Projektziele zu kontrollieren. So, für heute möchte ich damit Schluss machen. In der nächsten Folge greifen wir dieses Thema wieder auf ich möchte Ihnen dann etwas über die verschiedenen Arten von Anforderungen erzählen. Bis dahin wünsche ich Ihnen viele grüne Meilensteine tschüss und bye bye Ihr Andreas Haberer Literaturverzeichnis Carroll, L. (1865). Alice im Wunderland. USA: Bassermann, Edition, 2014. Ebert, C. (2012). Systematisches Requirements Engineering. Stuttgart: dpunkt.Verlag Heidelberg. http://de.wikipedia.org. (1. 01 2015). Von http://de.wikipedia.org/wiki/Chaos-Studie: http://de.wikipedia.org/wiki/Chaos-Studie abgerufen Weitere Informationen finden Sie unter www.Bundesvereinigung-ITPM.de

In der letzten Folge unseres Podcastes habe ich darüber erzählt, wie das Geschäftsmodell eines selbständigen oder freiberuflichen IT Projektmanagers funktioniert, welche Rolle Bodyleasing Firmen dabei spielen, warum konstantes Lernen und Wachsen so wichtig ist und was ich dafür tue, um meine Auftraggeber zu begeistern. In der Summe führen all diese Maßnahmen bei uns dazu, dass wir seit nunmehr 20 Jahre erfolgreich am Markt sind und wir die größten deutschen Unternehmen und Behörden zu unseren Kunden zählen dürfen. Das gelingt mir freilich nicht immer und ich will mit dem was ich erzähle auch nicht behaupten dass ich alles besser weiß und Ihr wie ein Kochrezept alles einfach nur so nachmachen müsst und dann sind Eure Auftragsbücher voll. Ich möchte Euch Ideen und Anregungen geben und wenn Ihr in jedem Podcast nur eine Idee mitnehmt die Euch weiter bringt, dann hat sich das Hören dieser Folge schon wieder gelohnt. Also damit nochmal zusammenfassend ein Fazit zur letzten Folge: Sie sind Ihr wichtigstes Produkt im Unternehmen, Weiterbildung ist unabdingbar Und das kann harte Arbeit an sich selbst sein. Eine Arbeit die man leisten muss, wenn man sich von der Masse abheben will. Dafür ist beständige Weiterbildung und Training notwendig. Leider kostet Weiterbildung nicht nur Geld, sondern konkurriert in der Regel auch mit dem produktiven Projekteinsatz. Ein Tagesseminar kostet im Schnitt etwa 1000€. Hinzu kommt der Ausfall an Einnahmen für diesen Tag. Darüber hinaus, verlangt der Auftraggeber häufig die 100% Verfügbarkeit. Er verlangt, dass der externe Mitarbeiter bereits weitergebildet ist und er nicht noch im laufenden Projekt dafür auf seine wertvolle Arbeit verzichten muss. Ein System, das mir das alles abnimmt… Wie in der Folge 1 unsers Podcasts erwähnt, bin ich in diesem Geschäft bereits seit 1993. Seither mache ich IT Projekte. Irgendwann ist mir dabei selbst aufgefallen, dass ich es seit Jahren schaffte, von einem Projekt ins nächste zu wechseln. Ohne auch nur einen Tag ungewollten Leerlauf. Dass das nicht unbedingt üblich ist, sah ich bei vielen meiner Kollegen. Einige konnten mit der Situation ohne Auftrag dazustehen gar nicht umgehen und wechselten in eine Festanstellung. Andere verloren tatsächlich dabei sogar das eigene Haus. Ich begann zu überlegen was ich anders machte und irgendwann begann ich es aufzuschreiben. Oberflächlich betrachtet waren alles erstmal nur Kleinigkeiten. Aber die Summe der Dinge die ich schon immer anders machte, macht es aus! Betrachtet man unser Business mit etwas Distanz haben wir als externe IT Projektmanager, genau wie alle anderen externen Berater, im Wesentlichen die folgenden Probleme: • Wie finde ich, möglichst ohne Leerlaufzeit einen Anschlussauftrag? • Weiterbildung ist unverzichtbar, aber neben den Seminargebühren kostet sie auch den Ausfall des Tageseinkommens. Wie soll ich das machen, wenn ich die ganze Zeit über bei meinem Kunden Vorort bin? • Wie schaffe ich es, mich als Person zu einer Marke zu machen? • Macht Werbung und Marketing für mich Sinn, wenn ich über Monate ausgebucht bin, und in der Regel noch nicht einmal verlässlich sagen kann ab wann ich wieder verfügbar bin? • Networking mit Unternehmen, Bodyleaser und Kollegen ist elementar wichtig. Wie soll ich das machen, wenn ich im Kundenprojekt eingespannt bin? • Muss ein Anteil der Provision an einen Vermittler, Recruiter oder Bodyleaser abgegeben werden? • Wie sichere ich mich und meine Leistungen auf bezahlbare weise vor Risiken ab? Heute schreiben wir den 18. Dezember 2014. Im Jahr 1993 habe ich meine Firma gegründet und ich sage nicht ganz ohne Stolz, dass ich in dieser Zeit gerade einmal 3 Wochen am Stück ohne Auftrag war. Vor 3 Jahren ist meine Frau Sandra Haberer als IT Projektmanagerin mit in unser Unternehmen eingestiegen. Als auch bei ihr und unseren danach eingestellten IT Projektmanagern unser System auf Anhieb funktionierte begannen wir darüber nachzudenken, unser Wissen und unsere Erfahrung an andere IT Projektmanager weiter zu geben. Seit nunmehr einem Jahr arbeiten wir intensiv an der „Bundesvereinigung IT Projektmanagement“ und freuen uns damit zum 15. Dezember 2015 offiziell an den Start zu gehen. Als Partner der Bundesvereinigung IT Projektmanagement stehen Ihnen nicht nur eine Vielzahl von IT Projektmanagement Profis zur Seite, sondern Sie profitieren von einem System das von Praktikern für Praktiker geschaffen wurde. Unsere Partner stehen für Qualität und Professionalität im IT Projektmanagement. Unsere Partner sind IT Projektmanagement Assistenten, IT Projektleiter, IT Programmmanager, IT Teamleiter, Projektcontroller, Qualitätssicherer und alle anderen die mit Projektmanagementaufgaben betraut sind, oder im Projektmanagement unterstützen. Das bedeutet, dass nicht nur selbständige IT Projektmanagementdienstleister von einer Partnerschaft profitieren, sondern vor allem auch angestellte IT Projektmanager. Denn bei unseren Inhalten bündelt sich Praxiserfahrung wie sonst kaum irgendwo. Eine Partnerschaft in der Bundesvereinigung IT Projektmanagement steht für Kompetenz, Effizienz und Seriosität im IT Projektmanagement. Werden wir konkret: • Profil Distribution o Im Laufe unserer beruflichen Praxis über viele Jahrzehnte hinweg haben wir eine Datenbank mit Unternehmen, die externe IT Projektmanager beschäftigen geschaffen. In dieser Datenbank verwalten wir auch Recruiting und Bodyleasingfirmen in Deutschland, Österreich und der Schweiz. Als Bundesvereinigung IT Projektmanagement kümmern wir uns um die maximale Verbreitung und Aktualität der Profile unserer Partner und bewerben diese bei Ihren potenziellen Auftraggebern. o Endlich haben Sie einen Hebel mit echter Durchschlagskraft. Mit wenigen Klicks setzen Sie sich auf „Verfügbar“ und lösen damit einen Prozess aus, der Hunderte von Unternehmen Recruiter und Bodyleaser darüber informiert dass Sie zur Verfügung stehen. • Wir werben für Ihre Leistungen o Die Profile unserer Partner sind über unser Portal nach vorheriger Anmeldung einsehbar und direkt (!) kontaktierbar und beauftragbar! Die Bundesvereingigung IT Projektmanagement schaltet sich nicht automatisch als Vermittler zwischen Auftraggeber und IT Projektmanager. Unsere Aufgabe ist es, Sie für den Markt so attraktiv wie möglich zu machen. Ihr Profil ist für den Markt also vollkommen transparent und Sie können sowohl von Bodyleasern, als auch von Unternehmen direkt kontaktiert werden. o In Ihrem Profil legen Sie Stärken an, für die Sie sich auszeichnen. Ihre Stärken können von früheren Auftraggebern nach einem „5 Sternchen Rating“ bestätigt werden. Das ist praxisorientierte Qualitätssicherung. o Als Mitglied in der Bundesvereinigung IT Projektmanagement erwarten wir von unseren Partnern eine anerkannte Projektmanagement Zertifizierung, die innerhalb eines Jahres vorzulegen ist. Mit der Vorlage des Zertifikates sind Sie berechtigt in Ihrer email Signatur „Zertifizierter (Junior, Senior, oder Prinzipal) IT Projektmanager der Bundesvereinigung IT Projektmanagement“ zu tragen. o Änderungen an Ihrem Profil, machen wir über unsere Social Marketing Kanäle an die wir automatisiert angebunden sind publik. Da wir bezahlte Werbung in diesen Kanälen schalten, erreichen wir eine maximale Reichweite die Ihnen zugutekommt. o Wir bieten unseren Partnern ein Werbevideo an, das nach der Erstellung auch über unseren YouTube-Channel erreichbar ist. Heben sie sich damit von Ihren Mitbewerbern ab und nutzen Sie dieses sehr effiziente Medium um Ihre Stärken in das richtige Licht zu rücken. o Aber hier ist ganz wichtig: Wir sind kein Bodyleasing- also kein Recruiting Unternehmen, dass an Ihrem Projekteinsatz verdient. Das möchte ich noch einmal explizit hervorheben. Wir finanzieren uns über die Mitgliedsbeiträge unserer angeschlossenen Partner. Somit können wir uns voll und ganz darauf konzentrieren, Sie in das rechte Licht für Ihre potenziellen Auftraggeber zu rücken. • Weiterbildung auf Ihre Bedürfnisse zugeschnitten o Wir sorgen dafür, dass Sie sich dann weiterbilden können, wenn Sie Zeit dafür haben. Sei es auf Reisen, oder nach Feierabend abends im Hotel. o Die kostenfreie Variante dieser Trainings für Jedermann hören Sie hier in Form unseres Podcastes. In unserem Partnerbereich finden Sie Webcasts in denen wir Trainings zu praktischen Problemstellungen liefern, deren Hürden und deren möglichen Lösungen berichten. o Projektanbieter haben auf diese Weise die Gewähr dass unsere Partner stets auf dem aktuellen Weiterbildungsstand sind und damit die Qualität der eigenen Arbeit sichern. • Wir stehen für IT Projektmanagement o Wir bewerben unser Portal in der freien Wirtschaft und sorgen durch Marketingmaßnahmen für ein Image das für Qualität und Seriosität im IT Projektmanagement steht o In wenigen Jahren wollen wir zur Plattform Nr.1 für IT Projektmanager werden. o Ich empfehle: seien auch Sie mit dabei und präsentieren Sie Ihr Profil mit Ihren Erfahrungen und Spezialisierungen in unserem Partnerbereich. Leider höre ich immer wieder: Fortbildung, das brauche ich nicht. Ich habe einen Master, ein Diplom, promoviert, oder vor 10 Jahren mal eine PM Zertifizierung gemacht…“das ist doch alles Geldmacherei, das mache ich nicht mehr“. Ich schüttle mich, wenn ich so etwas höre. Die IT Branche gehört ohne Zweifel mit zu den sich am schnellsten ändernden Branchen in der Wirtschaft und doch glauben viele Weiterbildung wäre für sie nicht notwendig? Ich kann diese negative Haltung bei angestellten schon nicht verstehen- bei Selbständigen oder Freiberuflern gleicht das einem unternehmerischen Harakiri. Schauen wir uns doch mal an wie sich das Weltwissen so verändert hat: o Das Jahr 200 vor Christus: die weltbekannte Bibliothek von Alexandria umfasst nahezu 700.000 Buchrollen. o Rund 2.200 Jahre später im Jahr 2007: Die größte Wissenssammlung der Welt, die "Library of Congress" in Washington, D.C., wuchert mit mehr als 112 Millionen Büchern und Dokumenten über Regalbretter von 857 Kilometer Länge. o Wissen wird heute in immer kürzerer Zeit geschaffen, gleichzeitig steigt die Verbreitungsgeschwindigkeit. Für eine bestimmte Datenmenge, die heute in einer Sekunde global übertragen werden kann, benötigte man 1997 noch 30 Tage. o Einst besaßen Gelehrte wie Sokrates, Da Vinci und Newton noch einen großen Teil des menschlichen Wissens, heute versteht ein Mathematiker die Rechnungen seines Kollegen nicht mehr, der naturwissenschaftliche Lehrstoff an den Universitäten muss alle zehn Jahre neu geschrieben werden. o Zwischen 1800 und 1900 hat sich das Wissen der Menschheit verdoppelt. Zwischen 1900 und 2000 verzehnfacht. Alle vier Minuten gibt es heute eine neue medizinische Erkenntnis, alle drei Minuten wird ein neuer physikalischer Zusammenhang gefunden, jede Minute eine neue chemische Formel. o Laut einer Studie von Statista.com ist die Anzahl der Internetbenutzer von 1997 mit 121 Millionen Nutzer auf heute 2,925 Mrd. Nutzer angewachsen. Die Prognose bis 2018 geht von 3,6 Mrd. Nutzern weltweit aus. o Dieses Wachstum wird dann vor allem in China und Indien stattfinden. Durch den Eintritt von China und Indien in die Wissensgesellschaft, wird sich das Wachstum des menschlichen Wissens nochmals beschleunigen. o Ab 2050 wird sich bereits das Wissen der Menschheit täglich verdoppeln und man wird die Verdoppelung des Wissens in Stunden berechnen. Und da sag mir einer er braucht keine Weiterbildung? o Wir veranstalten jährlich den Kongress der Bundesvereinigung IT Projektmanagement. Um zu vermeiden, dass unseren Partnern ein Umsatzausfall durch die Teilnahme entsteht, veranstalten wir diesen Kongress jeweils an einem Wochenende. Die Teilnahme am Kongress ist für unsere Partner kostenfrei. Anreise ist Freitagabend, wo wir bei einer kleinen Welcome Party Networking betreiben und uns in entspannter Umgebung kennen lernen. Samstag und Sonntag findet der eigentliche Kongress mit spannenden Themen für den IT Projektmanagement Berufsalltag statt. • Tools für Ihren Projektalltag o Unseren Partnern stehen im Partnerbereich jede Menge Vorlagen, Checklisten und nützliche Tools für den Projektalltag zur Verfügung. Der Einsatz dieser Hilfsmittel unterstreicht Ihre Professionalität gegenüber Ihrem Auftraggeber, spart Ihnen Zeit und damit bares Geld. All das sind nur Auszüge unserer Leistungen für unsere Partner. Informieren Sie sich, abonnieren Sie unseren Podcast und abonnieren Sie unseren Newsletter um zu verfolgen wie es bei uns weiter geht. In diesem Sinne freue ich mich schon auf die nächste Folge und wünsche Ihnen bis dahin lauter grüne Meilensteine, Ihr Andreas Haberer. Weitere Informationen finden Sie unter www.Bundesvereinigung-ITPM.de

Es war der 29. August 2011, der Projektleiter des IT Infrastrukturprojektes war wenige Tage zuvor aus seinen wohlverdienten Sommerferien zurückgekommen und saß, wie so oft, im Konferenzraum des Rechenzentrums seines Auftraggebers. Um den edlen Besprechungstisch saßen auf den bequemen Ledersesseln hochrangige Linienmanager des Rechenzentrums und Auftraggebers. Der externe Projektleiter hatte die Verantwortung für dieses Projekt bereits seit über 3 Jahre. Die Hauptinbetriebnahme des zu liefernden Systems wurde bereits einen Monat zuvor erfolgreich abgeschlossen. Es gab nun noch eine Reihe von „Nacharbeiten“ zu erledigen, die aufgrund von Abhängigkeiten erst nach der formalen Inbetriebnahme möglich waren. Plan war, diese Nacharbeiten in den nächsten Wochen durch den Projektleiter und sein Team noch umzusetzen. Das Projektteam selbst bestand, mit Ausnahme von 2 Mitarbeitern, komplett aus selbständigen externen Mitarbeitern. Aus diesem Grund war für die Folgebeauftragung der „externen“ auch ein zusätzliches Budget zu genehmigen. Da diese Genehmigungsentscheidungen auch in der Vergangenheit immer recht kurzfristig getroffen wurden, pikierte man sich im Projektteam zwar über dieses rücksichtslose Verhalten den externen gegenüber, aber alle gingen davon aus, dass wieder wenige Tage vor Ablauf der Frist die Verlängerungsbeauftragung kommt. Schließlich waren die besagten „Nacharbeiten“ für den Projekterfolg mit entscheidend. Im Projektteam war man es mittlerweile gewohnt, dass die Entscheidungsmühlen nicht immer unter Volllast liefen. Der IT Projektleiter, nennen wir ihn „Andreas Haberer“, war aufgrund seines vorherigen Urlaubs, durch seine Mannschaft bezüglich Projektstatus gut gebrieft worden. Im Statusmeeting nach seinem Vortrag, waren alle mit dem Projektstand höchst Zufrieden denn wir hatten alle Projektziele erreicht und waren im geplanten Soll. Die Stimmung war gut und als sich die Versammlung gerade auflöste und ich meine Unterlagen zusammen packte, kam der verantwortliche Bereichsleiter des Rechenzentrums auf mich zu. „Andreas, ach übrigens, das zusätzliche Budget für die Nacharbeiten wurde nicht genehmigt“, sagte er im fast beiläufigem Ton. Ich fragte ihm was er zu tun gedenke, denn die verbleibenden Arbeiten waren wichtig und es war immer klar, dass das Rechenzentrumspersonal aufgrund bereits existierender Überlastung diese Aufgaben nicht noch zusätzlich stemmen können. Aber es war nichts zu machen, ohne genehmigtes Budget waren wir raus. Für mich und die meisten meiner Teammitglieder hatte diese Entscheidung zur Folge, dass nur noch wenige Arbeitstage Budget verblieben um eine Übergabe durchzuführen. In meinem Fall waren es genau noch 4 verbleibende Tage. „Wir haben keine Wahl, bitte sorge dafür, dass der Know How Transfer an die internen Leute geordnet durchgeführt wird, so dass diese dann weiter machen können“, bekam ich zu Antwort und er ließ mich mit einem aufmunternden Nicken und einem kurzen Augenzwinkern im Konferenzraum stehen. Ich schüttelte den Kopf, wie sollte ich es hinbekommen. Meine Teammitglieder waren alles absolute Spezialisten auf ihrem Gebiet. Es wäre schon mit genügend Zeit schwierig geworden den Know How Transfer durchzuführen. Mir ist es stets wichtig, keine unerledigten Arbeiten zu hinterlassen und einen potenziellen Nachfolger maximal einzuarbeiten. Aber wir hatten keine Wahl. Das war’s also wieder mal…auch dieses Projekt war in den vergangenen 3 Projektjahren für mein Projektteam und mich zu unserem Baby geworden. Auf der einen Seite ist man natürlich stolz wenn sich dieses Baby nun im echten Leben beweisen muss. Natürlich sind wir externen Mitarbeiter dafür da, dass man sich auch kurzfristig von uns lösen kann. Das unterscheidet uns ganz deutlich von internen Mitarbeitern. Zu diesem Zeitpunkt war ich bereits seit über 17 Jahre selbständig und hatte jede Menge Praxiserfahrung mit IT Projekten bei einer Reihe deutscher Großbanken, Automobilherstellern, großen deutschen Softwareherstellern und öffentlichen Auftraggebern. Ganz ehrlich, trotz dieser langen Berufserfahrung bleiben noch immer einige Schrecksekunde wenn ich damit konfrontiert werde, dass mein Engagement nun endet. Je länger man dieses Geschäft macht, umso kürzer wird die Schrecksekunde, aber ich glaube ganz werde ich die nie los. Nun war klar, ich muss mich um einen Folgeauftrag kümmern. In den nun folgenden Tagen setzte ich alles daran, den auserkorenen internen Kollegen auf den aktuellen Stand zu bringen. Alle mündlichen und schriftlichen Abmachungen für die Arbeiten der nächsten Wochen mussten geordnet, alle mussten über den Wechsel informiert werden und den Kollegen die unsere Arbeiten zu Ende führen sollten, musste erklärt werden wo wir stehen und wann was zu tun ist. Auch wenn sie damit in der kurzen Zeit überfordert waren hoffte ich, dass ich alle Rahmenbedingungen so hinterlassen habe, dass unsere Nachfolger die Aufgaben zu Ende führen können. Abends im Hotel machte ich mich daran, mein CV, also mein Curriculum Vitae oder Profil, zu aktualisieren und an alle mir bekannten Recruiting Unternehmen, oder Bodyleaser zu versenden. Ich hinterlegte in meinem Profil im Internet, dass ich ab sofort kurzfristig verfügbar bin und schrieb Firmen an, die mir in Frage zu kommen schienen, Bedarf an einem externen IT Projektmanager zu haben. Ich schrieb geschäftliche Kontakte per Mail und über Xing an, um bekannt zu machen, dass ich kurzfristig für ein neues Projekt zur Verfügung stehe. Mehr kann man bislang nicht tun. Dann heißt es warten auf das, was zurückkommt. Es war in den Monaten zuvor immer wieder dazu gekommen, dass Projektverlängerungen sehr spät kamen. Ich bat immer wieder darauf Rücksicht zu nehmen, dass auch ich eine gewisse Planungssicherheit benötige. Zwar habe ich Verständnis, wenn aufgrund unternehmenspolitischer Entscheidungen, Aufträge nur um jeweils 3 Monate Verlängert werden. Doch ich brauche zumindest das Lippenbekenntnis, dass die Verlängerung vorgesehen ist. Bis dahin kam diese Verlängerung dann auch irgendwann. Einige Jahre zuvor, in einem ganz anderen Projekt, war ich in einer ganz ähnlichen Situation. Unternehmenspolitische Vorgaben seien daran schuld, dass Auftragsverlängerungen nur noch monatsweise vergeben wurden. Anfangs gab es 6 Monatsverträge, dann wurde nur noch vierteljährlich verlängert, um schließlich am Ende nur noch monatsweise zu beauftragen. Das hätte also bedeutet, dass sofort wieder auf der Matte stehe um die nächste Verlängerung in 4 Wochen zu besprechen, wenn die aktuelle Verlängerung gerade durch ist. Das war keine akzeptable Lösung für mich. Ich suchte das Gespräch mit meinem Auftraggeber und erklärte ihm, dass mein Stundensatz das damit verbundene unternehmerische Risiko des Einnahmenausfalls nicht abdeckt. Endet ein Auftrag kurzfristig, muss das erarbeitete Honorar ausreichen, um auch in der Zeit ohne Auftrag die eigenen Verpflichtungen weiter bedienen- und von etwas leben zu können. Um meiner Forderung Nachdruck zu verleihen, ließ ich mich sogar zu der Drohung hinreißen, mich in den diversen Internetplattformen auf „sofort verfügbar“ zu setzen. Ich mache Andeutungen, dass dies zur Folge hätte, dass Heerscharen von Recruiting Unternehmen darüber informiert werden und auf Projektsuche für mich gehen. Wenn dann ein kurzfristiger Auftrag kommt, der mehr unternehmerische Sicherheit bietet, muss ich diese Alternative wählen. So toll das klang- und so gut ich mich mit dieser kaschierten Drohung auch fühlte, so haltlos war sie doch in Wahrheit. Wer das Geschäft wie ich nun seit über 20 Jahre macht und kennt, der weiß sehr wohl, wie abhängig wir vom Markt und insbesondere von den Recruiting Unternehmen sind. Wie funktioniert dieses Geschäft eigentlich? Recruiting Unternehmen, oder auch Bodyleaser, vermitteln selbständige IT Projektmanager in vakante Projekte. Dafür erhalten sie pro geleisteter Stunde, oder Tag einen Provisionsanteil. Klingt erstmal gut, denn das bedeutet, dass mir diese Unternehmen die Akquise und Vertriebsarbeiten leisten, die ich selbst nicht erbringen kann, weil ich im aktuellen Projekt voll eingespannt bin. Aber: Der Recruiter sucht einen passenden selbständigen IT Projektmanager für seine Projektanforderungen- und nicht eine passende Projektanforderung für einen Projektmanager. Genau darin liegt das Problem. Mir sind keine Fälle bekannt, wo sich ein Recruiting Unternehmen für mich ans Telefon geklemmt und Firmen abgeklopft hat, ob sie ein vakantes Projekt für mich hätten. In der Regel sind selbständige IT Projektmanager mit all ihren Fähigkeiten und Erfahrungen für große Unterhemen direkt nicht sichtbar. Die Recruiting Unternehmen fungieren als Makler, man könnte sogar sagen als Dämpfungsschicht zwischen dem selbständigen IT Projektmanager und dem Markt. Funktioniert unser Business auch ohne Recruiting Unternehmen? Sind Recruiting Unternehmen für unser Business also eine Hilfe, oder ein "unnötiger Mitverdiener"? Könnten wir nicht direkt mit den Markt in Verbindung treten und Aufträge direkt akquirieren? Theoretisch ja. Problem: • In der Regel sind wir in einem laufenden Projekt zu mehr als 100% eingespannt. Zeit für Marketing für die eigene Firma, Werbung für die eigene Dienstleitung, Pflege von Kundenkontakten und aktives akquirieren von neuen Projekten bleibt kaum. • Selbst wenn man die Disziplin aufbringt, auch nach dem Projekteinsatz abends noch aktiv am eigenen Unternehmen zu arbeiten, hat man das Problem, dass man seine eigene Dienstleistung zu einem Zeitpunkt nur einmal verkaufen kann. Droht ein zweiter Kunde also mit Auftrag, kann dies nur ein Auftrag sein, dessen Erledigung in der sonst üblichen „Freizeit“ passiert. Wozu also werben? • Viele, vor allem große Wirtschaftsunternehmen, dürfen aufgrund interner Richtlinien nur mit sogenannten „prefered supplier“ Verträge schießen. Die Anerkennung zum prefered supplier in dieser Unternehmensgröße ist ein formaler Akt, der aufgrund der Prüfungsrichtlinien häufig gescheut wird, oder an entsprechend hohen Qualitätspolicys häufig scheitert. Alleine deshalb schon, werden Recruiting Unternehmen als Multiplikatoren beauftragt, denn in diesem Fall erreichen die Unternehmen eine riesige Menge Dienstleister und müssen nur ein- oder zwei Recruiter zum prefered supplier machen. Im Umkehrschluss bedeutet das, dass man als Freiberufler, oder kleiner selbständiger, kaum eine Chance hat, mit diesen Unternehmen direkt in geschäftlichen Kontakt zu kommen. • Bricht ein Auftrag weg, zeichnet sich das nicht immer langfristig ab. Tritt dieser Fall ein, bedeutet das aktive Auftragssuche. Eine gute Möglichkeit bieten hier die diversen Projektbörsen im Internet, natürlich kann man auch das Telefon in die Hand nehmen und aktiv bei Unternehmen Bedarf erfragen. Doch wie kommt man an die passenden Kontakte, wie an die Entscheider? Wie findet man heraus, bei welchen Unternehmen auch direkt, also ohne Recruiter beauftragen und wie kommt man an diese heran, wenn man im laufenden Projekt bereits voll ausgelastet ist? • In der Regel wird man aber das eigene Profil, oder CV aktualisieren und schnellstmöglich an die bekannten Recruiter versenden. Dies in der Hoffnung, dass den Keyaccountmanager den Recruiting Unternehmen gerade ein passendes Profilgesuch vorliegt, dass zu einem passt. • Abhängig von der eigenen Erfahrung, den regionalen Gebundenheiten und den fachlichen Schwerpunkten, dauert es mit Hilfe von Recruiting Unternehmen i.d.R. 2-6 Monate, um ein neues Projekt zu finden. Grund dafür ist natürlich, dass man in der Regel nur eine begrenzte Anzahl von Recruiting Unternehmen direkt erreicht, dass deren Keyaccount Manager zum passenden Zeitraum eine passende Anfrage vorliegen muss und natürlich an dem bereits oben beschrieben Umstand, dass der Recruiter keinen Auftrag für den selbständigen IT Projektmanager sucht, sondern den selbständigen IT Projektmanager für den Auftrag. Das macht für die selbständigen IT Projektmanager einen gewaltigen Unterschied. In der Regel ist dieses Geschäft leidenschaftslos und der selbständige IT Projektmanager ist lediglich die Handelsware die an existierende Bedarfe das Marktes vermittelt werden. Hier gibt es sicher Ausnahmen, aber ich sprach ja von der Regel. Fazit: Wir können auf Recruiting Unternehmen nicht verzichten, ganz im Gegenteil. Es ist notwendig sie als wichtige Partner zu sehen und gerade wegen des „leidenschaftslosen Vorgehens“ aktiv mit aktuellen Informationen zu versorgen. Recruiting Unternehmen sind für uns Freiberufler und Selbständige als Vertriebsabteilung zu sehen, die dafür natürlich bezahlt werden muss. Die eigenen Möglichkeiten, aus einem laufenden Projekt heraus im direkten Anschluss an einen lukrativen und interessanten Folgeauftrag aus eigener Energie heraus zu kommen, gleicht eher einem Glücksgriff. Wie machen wir uns für Recruiting Unternehmen attraktiv? Wenn es ohne sie nicht geht, dann also richtig mit ihnen. Und wenn wir als Dienstleister schon eine Handelsware sind, wie können wir uns dann möglichst attraktiv machen? Nun, eine wesentliche Basis für den Erfolg ist natürlich die Erwartungen des eigentlichen Auftraggebers über zu erfüllen. Wir müssen als „externe Dienstleister“ stets versuchen besser zu sein als das, was man üblicherweise erwartet. Erwartungen übertreffen, lautet hier die Devise. Das bedeutet aber nicht, im Projekteinsatz hektisch umher zu flitzen, jeden darauf hinzuweisen wie viel Arbeit man doch hat und wie schwer alles ist. Ganz im Gegenteil. Erlischt nicht der ganze Zauber solcher Kollegen wenn man ihnen bei ihrem Wehklagen zuhört? Ich will damit sagen, Zufriedenheit des Auftraggebers ist Voraussetzung den Auftraggeber zu halten und an sich zu binden. Das bedeutet, nach Ablauf der laufenden Beauftragung, eine Verlängerung zu bekommen. Auch von den Bodyleasern wird die Zufriedenheit des Auftraggebers abgefragt und geht in die QM Bewertung. Also macht es doppelt Sinn Erwartung über zu erfüllen. Der Bodyleaser wird den IT Projektmanager gerne wieder vermitteln weil die gute Arbeit auch auf das vermittelnde Unternehmen zurück fällt- und der Auftraggeber wird einen guten Mann- oder gute Frau, nicht so schnell hergeben und versuchen ihn auch im nächsten Projekt zu halten. Häufig verlängert der Auftraggeber natürlich schon im Eigeninteresse. Der Auftraggeber hat in den ersten Monaten in die Einarbeitung investiert. Je komplexer das IT Projekt ist, desto länger ist die Anlaufphase. Das aufgebaute Know How möchte man natürlich halten und im Projekt weiter darauf aufbauen. Aber wie oben schon gesagt, Magie kommt dann ins Spiel, wenn die Erwartungen des Auftraggebers regelmäßig übererfüllt werden. Dann macht es Spaß einen externen zu verlängern. Auch der Keyaccounter des vermittelnden Recruiting Unternehmen hat daran Spaß. Denn wer hört es nicht gerne, wenn man dafür gelobt wird, genau den richtigen Mann für die Projektanforderungen gefunden zu haben. Somit fühlen sich alle wohl. Recruiting Unternehmen leben davon, über aktuelle Profildaten, also Schwerpunkt, Projekterfahrungen und Verfügbarkeitsdaten zu verfügen. Beim Ergebnisranking der Datenbanken landet man weiter vorne, oder weiter hinten- je nachdem wie aktuelle die Daten sind. Tja und vielmehr gibt es eigentlich auch gar nicht zu sagen wie die Geschäftsanbahnung in Zusammenarbeit mit einem Recruiting Unternehmen funktioniert. Schaue ich mir meine Anfangszeiten und viele meiner Kollegen und Kolleginnen an beobachte ich außerdem, dass der Faktor Networking massiv unterschätzt. Meist wird erst dann „genetworked“ wenn man plötzlich ohne Auftrag, unter massivem Druck steht. Veranstaltungen bei denen ein persönliches Kennenlernen mit den Keyaccountern der Recruiting Unternehmen möglich ist, sind bares Geld wert wenn es drauf ankommt. Mit vielen Recruiting Unternehmen zusammenarbeiten Zu guter Letzt kann ich nur den Rat mitgeben, mit möglichst vielen Recruiting Unternehmen zusammen zu arbeiten. Ich darf mich noch einmal selbst zitieren, wenn ich sage, dass die Recruiting Unternehmen jeweils das passende Profil für eine Anforderung suchen- und nicht umgekehrt. Je mehr Recruiter über meinen aktuellen Status informiert sind, je breiter ich meine Profilinformationen gestreut habe, umso größer ist die Wahrscheinlichkeit ein passendes Projekt angeboten zu bekommen. Weitere Informationen finden Sie unter www.Bundesvereinigung-ITPM.de

Mein erster Podcast! :-) …ich glaube nur wer das selbst schon mal gemacht hat kann sich jetzt vorstellen wie stolz ich bin. Die erste Folge meines Podcastes ist online. Es war ein langer Weg von der ersten Idee einen Podcast rund um das Thema IT Projektmanagement aufzusetzen, dem ersten Auseinandersetzen mit der Technik, bis schließlich zu dem heutigen Tag, an dem ich diese erste Folge veröffentliche. Warum IT Projektmanagement? Naja- weil ich das einfach am allerbesten kann. Ich habe mein IT Unternehmen schon bereits im Jahr 1993 gegründet. Ich gehöre als Mitte 40er praktisch schon zu den Dinosaurier in der IT Welt…zumindest gemessen an den immensen Fortschritten den die IT seit diesen Tagen gemacht hat. Meine IT Erfahrung startete in einer Zeit in der man den Quellcode eines Computerspiels noch von Hand, zusammen mit ein paar Kumpels, aus einer Zeitschrift abgetippt hat, um dann nach tagelanger Tipparbeit vom Compiler auf tausende von Fehler hingewiesen zu werden. Das waren meine Comodore64 und Amiga Zeiten…sollte das überhaupt noch jemandem was sagen. Nun ja- meine erste Festanstellung hatte ich im Anforderungsmanagement eines kleinen Softwarehauses in Mannheim. Leider war die Auftragslage nicht die allerbeste, so dass ich nach einem Jahr aufhörte und kurz darauf den Weg in die Selbständigkeit wagte. Diese Entscheidung zähle ich zu den besten meines Lebens. Mit einem Partner zusammen wuchs unser Kundenkreis recht schnell so dass wir es bereits 1995 wagten eine GmbH zu gründen. Wir eröffneten noch ein kleines Ladengeschäft und ich schrieb Software für unsere Kundenprojekte und den Ladenverkauf. Wir genossen es mit den Dingen Geld zu verdienen auf die wir Lust hatten und so schrieb ich sogar ein Steuerungssystem für eine Sonnenstudio Kette. 1997 kam dann der erste Auftrag für ein großes internationales Unternehmen. Ich fand mich plötzlich als externer Softwareentwickler bei einem Walldorfer Softwarehaus mit 3 Buchstaben wieder. Ich war einer von sehr vielen Entwickler die gleichzeitig am Prototyp des heutigen CRM Moduls arbeiten. Dieses Projekt war für mein Selbstvertrauen damals ganz wichtig. Denn plötzlich merkte ich, dass mein Wissen und mein Rat auch in einem solch großen Unternehmen, das voll mit Profis ist, wichtig und hilfreich ist. Im direkten Anschluss an dieses Projektes bot man mir an, als einer der Softwareentwickler für die KfW in Frankfurt bei der Entwicklung der Callcenter Software zu unterstützen. Dieses Projekt ging bis 1999 und wieder gelang es mir nahtlos zu in das nächste Projekt zu wechseln. Es war die EDS Rüsselsheim, das war damals der IT Dienstleister für General Motors bzw. Opel mit 110.000 Mitarbeiter kein ganz kleiner Laden. Wir entwickelten ein Produktionsplanungssystem für den Automobilbau. Das Entwicklerteam war über mehrere Kontinente verteilt und wir waren eine echt tolle Truppe. Das ich am Schreibtisch gegenüber unseres Projektleiters saß war reiner Zufall. So kam es aber, dass ich stets wusste wo er gerade war und wurde mit der Zeit ganz nebenbei sowas wie sein Assistent. Eines Tages gab es einen Zwischenfall und unser Projektleiter verließ das Projekt. Das Management in USA fragte mich ob ich mir vorstellen könnte die Projektleitung zu übernehmen. Ich fragte was ich mehr an Geld bekommen würde und man sagte mir: „Nichts“. Gut, dachte ich- dann eben für die Ehre und so leitete ich mein erstes internationales Projektteam. Dieser Job war nicht ganz anspruchslos. Aufgrund der Zeitverschiebungen musste ich häufig bereits früh morgens, bzw. spät abends noch im Büro zu sein. Meist fuhr ich morgens um 6Uhr los um bereits um 7Uhr im Büro zu sein und kam sehr häufig erst nach 22Uhr wieder raus. Aber es war eine gute und sehr lehrreiche Zeit für mich. Direkt im Anschluss wechselte ich zur Hessischen Landesbank nach Frankfurt. Zunächst sah das nach einem entspannten 8 Stundentag Programmierjob aus, den ich dringend nach dem letzten Projekt gebrauchen konnte. Ich wollte also vorerst wieder ein Programmierer- sein und bezüglich Projektleitung Pause machen. Meine Aufgabe klang recht trivial. Ich sollte eine Access 2.0 Datenbank auf Access 2000 Migrieren. Mein Vorgänger hatte bereits 3 Monate ohne Ergebnis mit dieser Aufgabe gekämpft. Nachdem ich diese Aufgabe in nicht einmal einer Woche erledigt hatte, hatte ich neue Freunde. Was soll ich sagen. ich war insgesamt von 2001 bis 2006 dort. Zwar erlebte ich hautnah das IT Outsourcing. Der Kauf der Helaba IT durch das IZB. Das Schlucken der IZB durch die Sparkasseninformatik und diese durch die Finanzinformatik, aber mein Arbeitsplatz blieb stets der gleiche. Mit den Jahren und nach dutzenden Erweiterungsprojekten ist die einstmals kleine Datenbank zu einer mächtigen Configuration Management Database für das Servicemanagement des Rechenzentrums angewachsen. Wir haben eine Vielzahl von Projekten rund um diese CMDB herum realisiert. Ich glaube alleine über diese Entwicklung könnte ich ein Buch schreiben. Auf so manches was wir da an Lösungen entwickelt haben bin ich noch heute stolz und nicht wenige Lösungen suchen noch heute ihresgleichen. In dieser Zeit habe ich auch sehr viel Datenbankarchitektur und Datenbankentwicklung also Stored Procedure Programmierung betrieben. Da meine Software primär dazu diente, den Service und Netzwerktechnikern im Rechenzentrum das Leben zu erleichtern, musste ich sehr viel für Rechenzentrums Infrastruktur, Netztechnik, Serversysteme, Firewall, Router, SAN, ITIL Prozesse und vieles mehr lernen. Das kam mir bei meinen späteren Projekten noch sehr zugute. 2006 bekam ich das Angebot in das Herkules Projekt der Bundeswehr zu wechseln und dort die Projektleitung für ein Software Entwicklungsprojekt zu übernehmen. Das war nicht nur eine große Ehre, sondern auch eine große Herausforderung- also nahm ich an. Das hieß allerdings fortan montags 250 Km in den Köln Bonner Raum fahren- und freitags wieder zurück. In dieser Zeit lernte ich Hotelzimmer nicht mehr mit Urlaub, sondern mit Arbeit in Verbindung zu bringen. Nach diesem ersten Entwicklungsprojektauftrag für die Bundeswehr übertrug man mir die Projektleitung für ein militärisches IT Rollout Projekt und als auch dies vorbei war für ein militärisches Systementwicklungsprojekt. Ich hatte engen Kontakt mit nahezu allen Sicherheitsorganen und lernte sehr viel über Hochsicherheit und Hochverfügbarkeit. 2011 hatte ich dann aber genug davon, eine Wochenendehe zu führen und in Hotelbetten zu übernachten. Ich wollte wieder zuhause schlafen. 2007 wurde meine jüngste Tochter geboren und ich merkte, dass ich bereits viel zu viel verpasst hatte. Meine militärische IT Projekterfahrung, sowie meine Erfahrung im Umgang mit den militärischen Organen verhalfen mir dann sehr schnell zu meinem nächsten Projekt. Ich bewarb mich 2011 auf die Leitung eines Entwicklungsprogramms für die Bundeswehr, das aus insgesamt 16 Projekten und weit über 100 Mitarbeitern bestand. Ich bekam den Auftrag und kam steuerte zum ersten Mal Hardwareentwicklung und embedded Systementwicklung. Diese Herausforderungen waren für mich gänzlich neu, aber ich habe mich glänzend bewährt und lerne noch immer täglich dazu. Täglich dazu lernen- also kontinuierlich wachsen und lernen. Das war eigentlich mit der Initialzünder für die Gründung der Bundesvereinigung IT Projektmanagement im Januar 2014. Mit all dem eben gesagten, wollte ich Ihnen zeigen, dass ich nicht jemand bin, der Ihnen angelesenes und theoretisches Projektmanagementwissen vorkauen möchte. Zwar habe ich mehrere Projektmanagement Zertifizierungen und auditiere seit mehreren Jahren im Auftrag der deutschen Gesellschaft für Projektmanagement Projekte für den jährlichen „Project Excellence Award“. Aber ich hänge nicht dogmatisch an einem bestimmten Vorgehensmodell oder Methode. Die Praxis hat mich gelehrt, dass man all das in seinem Werkzeugkasten dabei haben muss. Der Praktiker weiß, wann er welches Werkzeug einsetzt und welche Teile dafür gerade praktikabel sind. Ich denke ich kann zurecht sagen, dass ich in der IT schon so ziemlich alle Arten von Projekten gemacht habe. Das bedeutet aber nicht, dass ich alles besser weiß, oh nein. Ich habe in diesen Projekten viel richtig- aber auch viel falsch gemacht. Ich habe sehr viele Menschen kennen gelernt die sagen können was man tun muss um bei ganz bestimmten Projektkonstellationen erfolgreich zu sein. Und was man tun muss, um solch ein Projekt an die Wand zu fahren. Auch ich lerne ständig und besuche pro Jahr in der Regel 8-12 Seminare von jeweils zwischen 1 und 5 Tage Dauer. Aber in Bezug auf diesen Podcast freue ich mich vor allem auf all die Erkenntnisse, die ich in den nächsten Jahren aus diesem Podcast gewinnen- und mit Euch teilen werde. Ich freue mich auf all die interessanten Menschen die ich zu dem Podcast einladen und interviewen werde. Also, was dürfen Sie bei diesem Podcast erwarten? • Sie werden sich praxisgerecht weiterbilden. Ein Podcast ist deshalb eine tolle Sache, weil man ihn „nebenbei“ hören kann. Ich beispielsweise höre Podcasts während der Autofahrt. Sie können den Podcast aber auch gerne beim Joggen, Bügeln, Kinderstillen oder Autowaschen hören. Diese Tipps gibt’s direkt auf die Ohren und kommen aus der Praxis. Hören Sie aufmerksam zu und überlegen sie, ob der ein oder andere Gedankenanstoß auch Ihnen in der Projektpraxis helfen kann. • Ich werde aus meiner eigenen beruflichen Praxis rund um das Thema IT Projektmanagement berichten. Was ist beim Anforderungsmanagement und Requirement Engineering wichtig, wann plane ich wie das nun anstehende Projekt und wie setzte ich es auf? Wie steure ich effektiv mein Projektteam, wie meinen Auftraggeber, wie gehe ich mit den Projektleitern der Nachbarprojekte um? Wie betreibe ich effektives Stakeholder Management? • Ich werde Kollegen Interviewen zu deren interessante und praxisnahen IT Projekterfahrungen. Welche Vorgehensmodelle haben sie gewählt und wie hat sich das bewährt? Welche PM Tools wurden eingesetzt und was waren die Erfahrungen damit? Wir werden uns über interessante Bücher und Seminare unterhalten • Ich werde Autoren interessanter Bücher interviewen • Für die selbständigen IT Projektmanager unter Ihnen und diejenigen die es werden wollen werde ich Interviews mit Bodyleasing bzw. Recruiting Unternehmen führen um das Geheimnis zu lüften, wie man nahtlos und ohne Leerlauf von einem Projekt in das nächste geht. Ich selbst bin auf meine eigene Bilanz sehr stolz: In der Zeit von 1997 bis 2015 hatte ich gerade einmal 15 Arbeitstage keinen Auftrag! Und diese 3 Wochen habe ich dann mit Weiterbildung vollgepackt! • Ich werde Interviews mit Anbietern von IT Projekten führen und mich mit diesen über ihre Erfahrung mit externen IT Projektmanagern unterhalten Für wen ist dieser Podcast gedacht? Nun, eigentlich für jeden der etwas mit IT Projektmanagement zu tun hat. Damit meine ich nicht nur Projektleiter, sondern auch Projektmanagement Assistenten, Projekt Planer, Projekt Controller, Projekt QS beauftragte usw. Aber selbst einem Techniker kann es helfen, die oftmals unergründliche Welt des Projektmanagements besser zu verstehen. Wenn Sie mit dem Gedanken spielen, sich im Bereich IT Projektmanagement selbständig zu machen, dann sind Sie jedenfalls goldrichtig bei uns. Wie Eingangs geschildert bringe ich einiges an Erfahrung mit, wie das Geschäftsmodell eines selbständigen IT Projektmanagementdienstleisters funktioniert und diese Erfahrung teile ich gerne mit Ihnen. Insgesamt möchte ich eine Folge auf etwa 30 min begrenzen. Da ich aber auf entsprechenden Tiefgang nicht verzichten möchte, plane ich mehrteilige Folgen zu einzelnen Themen. Ich glaube dass das funktionieren kann und bin auf Ihr Feedback dazu gespannt. Wenn Sie jetzt sagen, whow- das klingt cool, dann bitte abonnieren Sie diesen Podcast. Damit erhalten Sie jede neue Folge ganz automatisch auf Ihr Smartphone oder Tablet. Bitte geben Sie mir ganz viel Feedback zu den einzelnen Folgen. Denn nur mit Ihrem Interesse und Ihrer Hilfe können wir alle zusammen echten Mehrwert aus diesem Podcast generieren. Und das völlig kostenlos. Genial, oder? Sind auch Sie im IT Projektmanagement tätig? Dann vernetzen Sie sich mit uns. Wir sind alles IT Projektmanager bei der Bundesvereinigung IT Projektmanagement und unsere Gemeinschaft wächst kontinuierlich. Ich freue mich auch Sie bald auf einer unserer IT Projektmanagement Tagungen persönlich kennen zu lernen. Sie werden sehen, dann profitieren auch Sie von dieser Gemeinschaft. In der nächsten Folge dieses Podcasts möchte ich Ihnen die Bundesvereinigung IT Projektmanagement vorstellen und warum es so wichtig ist, vor allem als Selbständiger sich im größten und schlagkräftigsten Berufsverband für IT Projektmanagementdienstleister zu organisieren. Seien Sie also wieder mit dabei, ich freue mich auf Sie. :-) Weitere Informationen finden Sie unter www.Bundesvereinigung-ITPM.de