Saeulen

Folge 14: IT Projektmanagement, was ist daran besonders…?

Management ist die schöpferischste aller Künste. Es ist die Kunst, Talente richtig einzusetzen.

Robert McNamara

 

Nachdenklich?
Andreas Haberer nachdenklich?

IT Projektmanagement, was ist daran besonders…?

Die IT an sich ist ein beachtlich großes Spielfeld und wir beschäftigen uns bei der Bundesvereinigung IT Projektmanagement ausschließlich mit dem Managen von IT Projekten und alles was damit zu tun hat. Wenn wir also all unsere Aufmerksamkeit auf dieses Thema richten stellt sich berechtigter Weise die Frage, was IT Projektmanagement eigentlich so besonders macht, oder zumindest wo es sich vom Projektmanagement anderer Branchen unterscheidet?

Könnte ein Projektmanager aus dem Bauwesen theoretisch auch die Projektleitung eines IT Projektes übernehmen? Ich würde mich da zu einem klaren JEIN verleiten lassen. Bis zu einem gewissen Grad kann ein methodisch geschulter und versierter Projektmanager, ohne jegliche IT Kenntnisse auch ein IT Projekt steuern. Doch wie in jeder anderen Branche, stößt man auch hier sehr schnell an die Grenzen. Zur Ehrenrettung aller Bau Projektmanager: das gilt natürlich auch andersherum für IT Projektmanager die ein Bauprojekt leiten wollen.

Stellen wir also fest, dass es in der IT Branche, wie auch in anderen Branchen, über PM Methoden Wissen hinaus eines fundierten Fachwissens bedarf. Gut- aber das ist nichts bahnbrechend Neues. Auch in der Medizinbranche, im Flugzeugbau oder in der Raumfahrt benötigen Projektmanager technisches Fachwissen.

Kann man dann wenigstens resümieren, dass sofern man über Basis IT- und Projektmanagement Fachwissen verfügt, man dann für das Management aller Arten von IT Projekte geeignet ist? Auch hier wieder ein klares JEIN.

Ich habe mich vor über 20 Jahre selbständig gemacht und habe IT Projekte in ganz unterschiedlichen Disziplinen und für ganz unterschiedliche Branchen geleitet. Dabei wurde ich immer wieder vor ganz neue Herausforderungen gestellt. Herausforderungen in IT Projektdisziplinen wie

  • Softwareentwicklung für Desktopsysteme,
  • Softwareentwicklung für Webentwicklung,
  • Entwicklung von Embedded Systeme also Hard- und Software und deren Integration in ein Gesamtsystem
  • IT Infrastrukturprojekte
  • Organisationsprojekte uvm.

Anhand der Beispiele bekommt man ein Gefühl dafür, dass überall ganz unterschiedliche Erfahrungsschwerpunkte und Fachwissen erforderlich sind. Hinzu kommt, dass jede einzelne Branche wie Banken, Versicherungen, Automotive usw. ebenfalls wieder ganz unterschiedliche Herangehensweisen, Hintergrundwissen und Praxiserfahrungen erfordern. Dann die IT interagiert in der Regel in irgendeiner Form mit den Prozessen des Anwenderkreises und die gilt es zu verstehen.

Als wäre das nicht schon verwirrend genug, kommen nun die Projektmanagementlehren ins Spiel mit zahlreichen Vorgehensmodellen und Projektmanagementmethoden. Einige diese Methoden und Vorgehensmodelle nehmen schon fast religiöse Züge an und versprechen, richtig und vollständig angewandt, das Allheilmittel für den sicheren Projekterfolg zu sein.

Ich glaube- es gibt so etwas wie eine „beste Methode“ nicht. Zumindest ist das mein bisheriges Fazit aus über 20 Jahren IT Projekterfahrung.

Das soll nicht heißen, dass ich nichts von Projektmanagementzertifizierungen halte. Oh nein, ganz im Gegenteil. Meines Erachtens ist es die einzige vernünftige Methode sich einen messbaren und nachweisbaren Standard an Projektmanagementfachwissen anzueigenen. Ich halte nur nichts davon, eine Zertifizierung zu machen und diese dann, warum auch immer, zum Allheilmittel zu erklären.

Nein, meiner Meinung nach sollte ein IT Projektmanager über einen bunten Blumenstrauß an Methodenwissen und Vorgehensmodellen verfügen. Für manche Projekte passen diese Methoden und Vorgehensmodelle perfekt, für andere müssen sie getailored werden und manchmal ist es notwendig einen Mix aus allem einsetzen und bei Bedarf an die Rahmenbedingungen anzupassen. Steht man vor der Frage, in welche Ecke der Werkzeugkiste man fassen muss, ist es hilfreich die folgenden Fragen zu stellen:

  1. Handelt es sich um eine Auftragsentwicklung für einen Kunden?
  2. Handelt es sich um ein InHouse Projekt für eine andere Abteilung?
  3. Handelt es sich um ein Projekt dessen Ergebnis dem eigenen Team dienen soll?

Betrachten wir uns die eben gestellten Fragen genauer:

  1. Handelt es sich um eine Auftragsentwicklung für einen Kunden?
    1. Dann muss ein geeignetes Vertragswerk erstellt werden, welches den Auftrag klar und messbar formuliert
    2. In der klassischen Vorgehensweise, die in vielen Fällen angebracht ist, ist dann ist ein Lastenheft (regelt das WAS) und ein Pflichtenheft (regelt das WIE) zu erstellen die jeweils wiederum Vertragsbestandteil sind.
    3. Die Pflichten sind nach Umsetzungen durch Prüfspezifikationen und Prüfprotokolle nachzuweisen. Die Nachweise gemäß Meilensteinplanung können zahlungsbegründend sein.
    4. Welche Risiken stecken in dem Projekt und wie muss man diesen begegnen?
    5. Alternativ werden bei Agilen Vorgehensweisen oft auch eine vereinbarte Anzahl von sogenannten SPRINTS verkauft. Gerade wenn es sich um Entwicklungsprojekte mit hohem Innovationsanteil handelt, bei dem das WIE noch gar nicht klar formuliert werden kann, weil noch viel zu viel Forschungsarbeit notwendig ist, bieten sich Agile Vorgehensweisen an.Die in der IT gängigste Agile Methode ist sicherlich SCRUM. Ein SPRINT hat in der Regel eine Dauer von 2 bis 4 Wochen und am Ende eines SPRINTS steht eine lauffähige (Teil-)Produktversion anhand derer der Kunde die neuen Features begutachten kann. Vertraglich kann das so geregelt sein, dass ein SPRINT einen festen Preis hat. Der Auftragnehmer gibt zuvor eine valide Schätzung ab, in wie vielen SPRINTS er das gewünschte Ziel voraussichtlich erreichen wird. Da stets eine lauffähige Version nach einem SPRINT vorliegt, hat der Auftraggeber die Wahl noch einen weiteren SPRINT mit zusätzlicher Funktionalität zu beauftragen, oder den erreichten Entwicklungsstand erst einmal einzuführen. Soviel zumindest zur Theorie agiler Vertragsgestaltungen.
  2. Handelt es sich um ein InHouse Projekt für eine andere Abteilung?
    1. Hier hängt das Vorgehen von der Unternehmensstruktur und Organisation ab.
    2. Arbeiten die Abteilungen als Cost- oder Profitcenter?
    3. Hat die „Auftraggeber Abteilung“ vielleicht den gleichen Bereichsleiter der auch noch der Projektsponsor ist?
    4. Wer ist der Projektsponsor und wo in der Unternehmenshierarchie ist er angesiedelt?
    5. Wie hoch ist der Innovationsgrad der in diesem Projekt steckt?
    6. Wie oft wurden ähnliche Projekte schon gemacht, wie hoch ist also der Routineanteil?
    7. Welche Risiken stecken in dem Projekt und wie muss man diesen begegenen?
  3. Handelt es sich um ein Projekt dessen Ergebnis dem eigenen Team dienen soll?
    1. „Schmitt, wo ich Sie gerade sehe- wir haben da das Problem XY in unserer Abteilung. Setzen Sie da mal ein Projekt auf, nehmen Sie den Meier und den Müller dazu und lösen Sie es“. So oder so ähnlich gab es schon tausende Projektaufträge. Ich kann jedem nur empfehlen es bei solchem „Zuruf“ nicht zu belassen, sondern sehr wohl die Ziele schriftlich zu formulieren und bestätigen zu lassen. Häufig wird aber leider einfach begonnen, da selbst der „Chef“ keine Lust auf Formalien hat…“Das Problem ist doch klar, der Schmitt wird schon wissen was zu tun ist“. Handelt es sich um ein Projekt das in wenigen Tagen erlegt ist und man stellt erst am Ende fest dass der Chef eigentlich etwas anderes wollte, ist nicht viel Geld kaputt gemacht. Handelt es sich aber um ein komplexeres Projekt über mehrere Monate und einer Vielzahl von Mitarbeitern und stellt man auch hier erst am Ende fest, dass man zwar die Leiter erklommen hat, dass diese Leiter aber an der falschen Hauswand stand, dann wird es teuer. Spätestens wenn sich solche Projekte häufen, wird es teuer und man muss die methodische Vorgehensweise dringend überdenken.

So gesehen gibt es also nicht nur eine Reihe von Rahmenbedingungen in der IT die für sich genommen jeweils ganz unterschiedliches Know How und Erfahrung erfordern, jede Disziplin kann in unterschiedliche Rahmenbedingungen eingebettet sein. Betrachten wir uns diese IT Projektdisziplinen etwas genauer und was dahinter steckt. Ich lasse dabei die zuvor erwähnten Rahmenbedingungen weg, um uns den einzelnen Facetten erst einmal von hoher Flughöhe her zu nähern.

IT Projektdisziplinen

Andreas Haberer
Projektdisziplinen

Mir ist immer wieder unverständlich, warum selbst die IT Projektmanagement Fachlite ratur, IT Projekte so häufig auf die Softwareentwicklung reduziert.

Neben der klassischen Softwareentwicklung gibt es

  • Embedded System Entwicklung
  • IT Infrastrukturprojekte
  • Softwareevaluierungsprojekte
  • IT Rollout Projekte
  • Migrationsprojekte
  • Customizing Projekte
  • IT Umzugsprojekte
  • Oder Organisationsänderungsprojekte

 

Doch betrachten wir uns diese IT Projektdisziplinen und deren jeweilige Anforderungen an den Projektmanager im Einzelnen:

Softwareentwicklungsprojekte

Damit meine ich die klassische Individualsoftwareentwicklung. Diese kann eine Auftragsentwicklung mit einem Auftraggeber und einem Auftragnehmer sein, oder es handelt sich um eine Eigenentwicklung wie z.B. einem Start-up Unternehmen das nach der Entwicklung mit einem Produkt an den Markt geht.

Im ersten Fall hat ein Auftraggeber hat ein Problem, dass mit Hilfe einer Softwareproduktes gelöst werden soll. Beispielsweise wäre hier eine Software zu entwickeln, mit deren Hilfe Datenhaltung in einem Rechenzentrum zentralisiert wird die heute verstreut in einzelnen Exceltabellen herumliegt. Aber auch die Entwicklung komplexer Webanwendungen oder Portale falle und unter diese Kategorie.

Im zweiten Fall wird eine Produktidee verwirklicht. Häufig mit Hilfe von Venture Capitals oder Business Angels welche die Finanzierung übernehmen und in die Projektidee investieren.

Anforderungen an den Projektmanager

Bei dieser Projektart sollte der Projektmanager zum technischen Verständnis über Entwicklungserfahrung und Softwarearchitekturkenntnisse verfügen. Wichtig ist die Geschäftslogik hinter dem zu entwickelnden System zu verstehen und je nach Rahmenbedingungen das Vorgehen festzulegen. Im Fall von Fremdfinanzierung spielt der Return of Invest (ROI) bzw. der Business Case eine große Rolle und muss ständig überprüft werden um die Investoren stets über den aktuellen Stand auf dem Laufenden zu halten.

Embedded System Entwicklung

Hierbei handelt es meist sich im die Kombination aus Hardware und Softwareentwicklung. Die Entwicklung von Smartphones, VOIP Telefone, Navigationssysteme, CTI Computer Telefon Integration, oder Druckmaschinen fallen unter diese Rubrik. Die besondere Herausforderung liegt in der Anforderungsermittlung, der koordinierten Entwicklung der Hardware- und der einzelnen Softwareschichten, sowie die anschließende Integration von Hard und Software zu einem Gesamtsystem.

Anforderungen an den Projektmanager

Bei dieser Projektart sollte der Projektmanager zum technischen Verständnis über Hard- und Softwareentwicklungs und Architekturkenntnisse verfügen, sowie Erfahrung in der Systemintegration mitbringen.

IT Infrastrukturprojekte

Bei diesen Projekten handelt es sich häufig um typische Rechenzentrums- oder Datacenter Projekte. Ein Kunde, nehmen wir als Beispiel eine Bank, nutzt einen Rechenzentrumsdienstleiter als Hoster seiner Infrastruktur welche dieser als Dienstleistung anbietet.

Benötigt eben diese Bank z.B. 500 neue eMail Postfächer für deren Mitarbeiter, wird im Rechenzentrum ein Projekt aufgesetzt um die Infrastruktur bereit zu stellen. Nach der Planung und Dimensionierung werden physische Server bereitgestellt, oder virtuelle Server aufgesetzt, es werden Mailserver und Datenbankserver aufgesetzt und eingerichtet, es werden Firewall und Routerkonfigurationen durchgeführt, es werden VPNs eingerichtet, Zertifikate und Schlüssel für die gesicherte Kommunikation generiert, Datensicherungen für Mailserver und Datenbankserver eingerichtet und Virenschutz installiert. Je nach vereinbarter Verfügbarkeit dieses Systems, welche in der Regel in Form von SLAs definiert werden, müssen Redundanzen geschaffen werden um potenzielle Ausfallzeiten auf ein Minimum zu reduzieren.

Anforderungen an den Projektmanager

Bei dieser Projektart sollte der Projektmanager über fundierte IT Infrastrukturkenntnisse verfügen. Er sollte das ISO/OSI Schichtenmodell beherrschen, die grundsätzliche Funktionsweise aktiver und passiver Netzwerkkomponenten beherrschen sowie über ein Systemverständnis verfügen. Sehr wichtig ist ebenfalls ein fundiertes Wissen zu IT Servicemanagementprozessen nach ITIL.

An dieser Stelle möchte ich den Ersten Teil dieser Folge enden lassen und freue mich schon in der nächsten Woche auf den 2. Teil. Ich hoffe es hat Ihnen bis hierhin Spaß gemacht und Sie sind auch in der nächsten Woche wieder mit dabei.

Bitte denken Sie daran, dass noch bis Ende März 2015 die Interview Aktion läuft. Das bedeutet, dass ich mit Ihnen ganz persönlich ein Interview zu einem Thema Ihrer Wahl aus dem Bereich IT Projektmanagement führe. Lassen Sie uns teilhaben an Ihrer praktischen Berufserfahrung. Was ist Ihnen in Ihrer Laufbahn besonders gut gelungen und was waren die Erfolgsfaktoren dazu. Wo ist vielleicht eines Ihrer Projekte gescheitert und was haben Sie daraus gelernt? Vielleicht haben Sie auch ein Spezialgebiet auf dem Sie ganz besonders viel Erfahrung haben. Ein Interview ist nicht nur für selbständige interessant um die eigenen Dienstleistungen kostenfrei und langfristig zu bewerben, sondern Sie machen damit auch als Angestellter Ihre Expertise sichtbar und profilieren sich für sich und Ihren Arbeitgeber. Alles was Sie dazu tun müssen ist noch bis Ende März 2015 unseren Newsletter zu abonnieren und mir eine Bewerbungsmail mit dem Thema zu senden, über das Sie sprechen möchten. Keine Sorge, ich nehme Ihnen dabei fast alles ab und es läuft für Sie ganz unkompliziert. Also, ich freue mich auf Ihre Bewerbung und ich freue mich auf den zweiten Teil dieser Folge in der kommenden Woche. Bis dahin wünsche ich Ihnen viele grünen Meilensteine Ihr Andreas Haberer