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

IT Projektmanagement

Folge28: Projektmarketing Teil II

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

Folge27: Projektmarketing Teil 1

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

Folge 26: Wie muss ein wirksames IT Freelancer Profil aussehen?

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

Folge 25: Scheinselbständigkeit, Hexenjagd auf selbständige IT'ler?

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

Folge 24: PM Zertifizierungen

"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

Folge 23: Führung Teil II

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

Folge22: Führung

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

Folge 21: Der Projektsaboteur

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

Folge 20: Der Projektmanagementflüsterer

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

Folge 19: Risikomanagenent, das Radar der Projektleitung Teil II

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

Folge 18: Risikomanagement, das Radar der Projektleitung

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

Folge 17: Der Projektsponsor

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

Folge 16: Interview mit IT Projektmanager Gerhard Wirnsberger

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

Folge15: IT Projektmanagement...was macht es so besonders Teil II

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

Folge 14: IT Projektmanagement…was macht es besonders?

Die „Bundesvereinigung IT Projektmanagement“ ist ein Berufsverband für IT Projektmanagementdienstleister. Wir unterstützen unsere Mitglieder bei der Qualitätssteigerung ihrer IT Projektmanagementdienstleistungen im Berufsalltag, sowie bei der Generierung neuer Aufträge. Unsere Mitglieder profitieren von einer professionellen und starken Gemeinschaft. Denn bei uns steht der Projektmanager, seine fachliche und persönliche Entwicklung, sowie sein nächstes Projekt im Mittelpunkt. Wir geben uns gegenseitig Praxiserfahrungen weiter und profitieren so von dem hohen Nutzen der durch die Mitgliedschaft entsteht. 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 Tips 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 Stakeholdermanagement? • 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. Recruitingunternehmen 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 misteriöse 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 hier. 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. Weitere Informationen zur Bundesvereinigung IT Projektmanagement finden Sie auf unserer Homepage unter Bundesvereinigung-ITPM.net Und nun: Vielen Dank dass Sie unseren Podcast abonnieren!

hubhopper

IT Projektmanagement

hubhopper