IT Projektmanagement

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