Linux-Projekte erfolgreich managen

Die Dinge sind nie so, wie sie sind. Sie sind immer das, was man aus ihnen macht. Jean Anouilh Gratis-Online-Buch von F...

Author: Obels Frank

84 downloads 1399 Views 3MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Die Dinge sind nie so, wie sie sind. Sie sind immer das, was man aus ihnen macht. Jean Anouilh

Gratis-Online-Buch von Frank Obels (Copyright 2003 Frank Obels, Online-Version Copyright Frank Obels)

Version: 0.1

Kostenloses Gratisexemplar überreicht durch: INCONET – Informationssysteme, Communication und Netzwerkberatung GmbH Seligenstädter Str. 100 D-63791 Karlstein FreeCall: 0800 – 46 26 638 http://www.inconet.de

Gratisdokument von www.inconet.de

Was Sie unbedingt wissen müssen zur Online-Version dieses Buches… Sehr geehrte Damen und Herren, verehrte Internetsurfer, Das Buch, das Sie gleich zu lesen beginnen, ist die erste Pre-Release-Version des gleichnamigen Fachbuchs von Frank Obels, das im Oktober 2003 erscheinen wird. INCONET veröffentlicht diese „early book version“, um Anregungen und Wünsche der Leser optimal berücksichtigen zu können. Insofern befindet sich dieses Buch erst am Anfang seines Weges und Sie haben die Chance, diesen Weg mitzugestalten. Ein gewisser Herr Eric S. Raymond hat unsere Vorgehensweise in die passenden Worte gefasst: „Release early - Release often - And listen to your customers“. Die Frage, die man uns im Vorfeld der Buchankündigung immer wieder gestellt hat, lautet: «ist es wirklich nötig, ein Projekthandbuch für Linux zu schreiben?» Wir haben diese Frage direkt an den Autor weitergegeben und hier ist seine erstaunliche Antwort: «Nein, wenn Sie einen gestandenen Projektmanager vor sich haben, so wird dieser mit jedem Projekt glücklich werden – auch wenn die Vorzeichen auf Linux stehen. Dieses Buch ist aber nicht für Profis geschrieben, sondern für die vielen Menschen, die eine nichttechnische Betrachtung des Themas Linux benötigen. Bis zum heutigen Tag können viel zu wenig Menschen etwas mit dem Thema Linux anfangen. Gleichzeitig nimmt die Zahl der Linux-Projekte zu und immer wieder rufen mich Kollegen an, die zu plötzlichen Projektleiterehren im Linux-Umfeld gekommen sind, wo sie denn entsprechende Informationen finden könnten. Für diese Menschen ist dieses Buch geschrieben. Linux ist etwas Neues und damit für IT-Verantwortliche und ihre Manager auch etwas „Unheimliches“ – das ist die emotionale Komponente der Wahrnehmungen aus der Praxis. Linux wird selten in einem Unternehmen eingeführt, weil man es rundherum mag, sondern weil es andere auch machen, weil man Geld sparen will und sich noch eine Reihe weiterer Vorteile verspricht. Aber es sind ausgewachsene Sorgen vorhanden, weil man noch immer das Freak-Image von Linux im Hinterkopf hat und nicht einmal weiß, was denn da für Menschentypen auf einen zukommen, die sich Linux-Spezialisten nennen. Dieses Buch will einen Einblick geben, was es mit Open Source und den Themen darum herum auf sich hat und was dies für den Projektverlauf bedeuten kann. Mehr will dieses Buch gar nicht vermitteln, und wenn die Leser schließlich zu dem Ergebnis kommen, dass das Thema ja gar nicht „so wild“ ist, dann ist wieder ein Stückchen der Sorge vor dem Unbekannten gewichen. Dies ist das Anliegen der nachfolgenden Seiten: an der einen oder anderen Stelle eine Hilfe zu sein.

Seite 2

INCONET – Informationssysteme, Communication und Netzwerkberatung GmbH

© Frank Obels

Version 0.1 „Linux-Projekte erfolgreich managen“

Die Botschaft an die Leserinnen und Leser ist daher auch denkbar einfach: Entnehmen Sie diesem Buch das, was Ihnen wichtig erscheint. Und den Rest lassen Sie einfach als Zeitdokument stehen!» Danke an den Autor und Ihnen nunmehr viel Spaß mit seinen Ausführungen. Wenn Sie einen Kommentar über dieses kleine E-Book loswerden möchten, dann freuen wir uns, ist dieser Kommentar auch noch konstruktiver Natur, dann freuen wir uns sehr. INCONET – Informationssysteme, Communication und Netzwerkberatung GmbH Karlstein, im August 2003

© Frank Obels


Seite 3


Linux-Projekte erfolgreich managen! Projektmanagementleitfaden für Einsteiger Autor: Frank Obels Version: 0.1

Seite 4


© Frank Obels


Der Inhalt [0]

Vorwort

[1]

Einleitung

[2]

Linux-Software für den Unternehmenseinsatz

[3]

Erfolgreiches Projektmanagement

Hinweis Soweit in diesem Buch personenbezogene Begriffe verwendet werden, kommt diesen ausdrücklich keine geschlechtsspezifische Bedeutung zu. Zur einfacheren Lesbarkeit wurde eine diesbezügliche Ungenauigkeit akzeptiert.

© Frank Obels


Seite 5


Inhaltsverzeichnis 0Vorwort...............................................................................................................................9 0.1Für wen ist dieses Buch?............................................................................................. 10 0.2Warum noch ein Buch über Projektmanagement?...................................................... 10 0.3Zielsetzung dieses Buches...........................................................................................11 0.4Was dieses Buch nicht ist............................................................................................11 0.5Aufbau dieses Buches..................................................................................................12 1 Einleitung....................................................................................................................... 14 1.1Die gute Nachricht vorneweg...................................................................................... 14 1.2Projektmanagement in Linux-Zeiten........................................................................... 15 1.3Open Source-Software.................................................................................................16 1.3.1Die Geschichte von Open Source-Software......................................................... 16 1.3.2Die Open Source-Kriterien...................................................................................19 1.3.3Ein Paradigmenwechsel vollzieht sich................................................................. 20 1.3.4Wie entsteht ein Open Source-Projekt – wer leitet es?........................................ 21 1.3.5Zehn Mythen über Open Source Software........................................................... 22 1.3.6Hintergründe zu Linux......................................................................................... 30 1.4Das Für und Wider von Open Source-Software..........................................................30 1.4.1Vorteile von Open-Source....................................................................................31 1.4.2Schwächen und Probleme.................................................................................... 33 1.4.3Die Kosten von Open Source-Software............................................................... 37 1.5Linux-Anmerkungen mit auf den Weg........................................................................39 1.5.1Der Sprung ins kalte Wasser................................................................................ 40 2 Linux-Software für den Unternehmenseinsatz............................................................... 41 2.1Linux-Distributionen................................................................................................... 41 2.1.1Die großen und bekannten Allround-Distributionen............................................42 2.1.2Derivatdistributionen............................................................................................45 2.1.3Spezialdistributionen............................................................................................ 46 2.2Open Source-Software für die Projektdurchführung...................................................48 2.2.1Eine neue Dienstleistung: Open Source Software Scout......................................48 2.2.2Freie Software zur internen Projektdurchführung................................................ 49 2.2.3Der Open Source Software-Auswahl-Prozess......................................................53 2.2.4ASP-Lösungen für das Projekt............................................................................. 54 2.3Open Source Alternativen zu kommerziellen Applikationen......................................55 2.3.1Finanzbuchhaltung für kleine Unternehmen........................................................ 55 2.3.2Customer Relationship Management................................................................... 56 2.3.3Enterprise Resource Planning...............................................................................57 2.4Software für den Server...............................................................................................58 2.4.1Konkurrenz für den Microsoft Exchange Server..................................................58 2.4.2Webserver.............................................................................................................59 2.4.3Datenbankserver................................................................................................... 61 2.4.4Samba-Server....................................................................................................... 61 2.4.5Sonstige Server-Software..................................................................................... 62 Seite 6


© Frank Obels


2.5Software für den Desktop............................................................................................63 2.5.1SuSE Linux Desktop-Produkte............................................................................ 63 2.5.2Office-Pakete........................................................................................................65 2.5.3Mail-Clients..........................................................................................................68 2.5.4Webbrowser..........................................................................................................70 2.5.5Thin Clients als Desktop-Alternative................................................................... 73 2.6Emulationssoftware zur Integration von Spezialanwendungen...................................75 2.6.1Integration von DOS-Anwendungen ................................................................... 75 2.6.2Virtueller PC.........................................................................................................76 2.7Software für die „Kleinigkeiten“.................................................................................77 2.7.1Organizer und PDA.............................................................................................. 78 2.7.2Handies.................................................................................................................78 3 Erfolgreiches Projektmanagement..................................................................................80 3.1Die Grundlagen........................................................................................................... 81 3.1.1Einführung in das Projektmanagement................................................................ 81 3.1.2Projektphasen und -verlauf...................................................................................83 3.1.3Projektorganisation...............................................................................................85 3.1.4Typische Rollen im Linux-Projekt....................................................................... 87 3.1.5Projektumwelt und –umfeld................................................................................. 95 3.1.6Projektmanagementprozess................................................................................ 100 3.1.7Warum scheitern Projekte.................................................................................. 102 3.2Vorprojektphase........................................................................................................ 103 3.2.1Projektinitiierung................................................................................................103 3.2.2Grobplanung....................................................................................................... 103 3.2.3Projektentscheidung........................................................................................... 104 3.3Projektdefinition........................................................................................................105 3.3.1Design der Projektorganisation.......................................................................... 105 3.3.2Das Kick-off Meeting.........................................................................................106 3.3.3Definition der Projektziele................................................................................. 108 3.3.4Der Projektauftrag.............................................................................................. 110 3.4Projektplanung...........................................................................................................112 3.4.1Projektstrukturplan (PSP)...................................................................................113 3.4.2Methoden der PSP-Erstellung............................................................................ 115 3.4.3Prinzipien der PSP-Erstellung............................................................................ 116 3.4.4Arbeitspaketspezifikation...................................................................................117 3.4.5Meilensteine....................................................................................................... 119 3.4.6Terminplanung................................................................................................... 121 3.4.7Aufwandsschätzung und Ressourcenplanung.................................................... 125 3.4.8Kostenplanung....................................................................................................127 3.4.9Kommunikationsplanung und -management .....................................................130 3.4.10Risikoplanung und -analyse............................................................................. 133 3.4.11Qualitätsplanung...............................................................................................135 3.5Projektdurchführung..................................................................................................137 3.5.1Was es bei der Projektdurchführung zu tun gibt................................................ 139 3.5.2Durchführungs- und Erfolgskontrolle................................................................ 139 3.5.3Projektstatusbericht............................................................................................ 141 3.6Projektabschluss........................................................................................................ 141 3.6.1Vorbereitung des Projektabschlusses................................................................. 142 3.6.2Die Übergabe als Projektabschluss.................................................................... 144 3.6.3Off topic: Das Optimierungsprojekt...................................................................146 © Frank Obels


Seite 7


3.7Praxis-Empfehlungen für Projektmanager................................................................ 147 3.7.1Die Top 20-Erfolgsregeln...................................................................................147 3.7.2Umgang mit diffusen Vorstellungen.................................................................. 150 3.7.3Entscheidungen werden nicht getroffen............................................................. 152 4 Alltagshilfen zum Schluss............................................................................................ 155 4.1Und nun setzen Sie Ihr Wissen um!.......................................................................... 155 4.2Besondere Tipps für „Frischgebackene“!..................................................................156 4.3Die Strategie für den Erfahrenen!..............................................................................156 4.4Und schließlich dies noch!........................................................................................ 157

Seite 8


© Frank Obels


0

Vorwort

Der wahre Zweck eines Buches ist, den Geist hinterrücks zum eigenen Denken zu verleiten. Marie von Ebner-Eschenbach

Projekte werden häufig als etwas Unheimliches oder Unabwendbares angesehen, dem ein Unternehmen, ein Projektauftraggeber, ein Projektleiter oder jedes einzelne Mitglied des Projektteams völlig hilflos ausgeliefert sind. Zu dieser ohnehin nicht sehr positiven Wahrnehmung gesellt sich nun das IT-Phänomen Linux. Kaum ein Thema war in der IT-Geschichte so sehr mit Mythen, freien Erfindungen, Vorurteilen, Unkenntnis und Ängsten verbunden. «Niemand mit gesundem Menschenverstand reißt sich um ein Linux-Projekt, für das es noch keine Erfahrungswerte aus ähnlichen Projekten gibt», so die einhellige Meinung meiner Kollegen. Das Anliegen dieses Buches ist es, dem Einsteiger in die Thematik Projektmanagement, sowie dem Projektmanager, der sich freuen darf, bald die Verantwortung für ein LinuxProjekt zu übernehmen, eine Praxishilfe zu sein. Viele Publikationen zum Thema Linux drängen derzeit auf den Markt. Es sollte Linux also bald gelingen, das Image des Unbekannten abzulegen. Interessant wird sich die Frage gestalten, was sich in einigen Jahren hinter dem Begriff Linux verbergen wird. Immer noch ein freies Betriebssystem? Werden die Rechte an Linux von einem Unternehmen erworben und wird somit aus Linux eine proprietäre Angelegenheit?

© Frank Obels


Seite 9


0.1

Für wen ist dieses Buch?

Dieses Werk ist ein Leitfaden für alle diejenigen, die sich zum einen für Projektmanagement interessieren und zum anderen die Besonderheiten eines LinuxProjekts kennen lernen möchten. Die typischen Leser dieses Buches werden sein:      

Projektleiter, Teilprojektleiter und interessierte Projektteammitglieder Führungskräfte und Vorgesetzte von Projektleitern Projektauftraggeber sowie Projektstakeholder im allgemeinen Abteilungsleiter und Manager, deren Mitarbeiter einem Projekt zugeordnet werden Trainer, die Projektmanagement unterrichten Berater und Spezialisten, die im Projektmanagementkontext Dienstleistungen erbringen.

Dieses Buch ist weder vollständig noch „all umfassend“ und ist auch kein Projekthandbuch im strengen Sinne der Definition. Es stützt sich auf meine Erfahrungen aus nunmehr dreizehn Jahren Projektmanagement und möchte diese, zusammen mit den wertvollen Erkenntnissen aus drei umfassenden Linux-Projekten, an Sie weitergeben. Besondere Berücksichtigung finden weiterhin die typischen Fragestellungen der Teilnehmer meiner Projektmanagementseminare.

0.2

Warum noch ein Buch über Projektmanagement?

Nun, das vorliegende Werk ist auch eine Einführung in das Thema Projektmanagement und derer gibt es viele – das ist wahr. Aber es „plaudert“ eben auch, bei passender Gelegenheit, aus der Linux-Projekt-Praxis. Und zu diesem Thema gibt es offensichtlich einigen Erklärungsbedarf, wenn ich die vielen Hilferufe von Unternehmern, IT-Verantwortlichen, Führungskräften und Projektmanagern recht interpretiere. Es scheint als gäbe es ausreichende Literatur zu den technischen Themen von Linux, ebenso zu IT-Projektmanagement an sich. Was aber zu fehlen scheint, ist eine nichttechnische Betrachtung von Linux, die mit Durchführungsempfehlungen für die Praxis ausgestattet ist. Dieses Buch will in diesem Bereich ein wenig Pionierarbeit leisten, damit dann schließlich Andere kommen können und es besser machen. Gelänge es, diesen Prozess anzustoßen, so wäre dem Thema Linux damit sehr geholfen, denn was nutzt das schönste IT-System ohne eine entsprechende Lobby. Ist schon das Thema Projektmanagement anspruchsvoll genug, weil es sich überwiegend auf der „nicht-handwerklichen“ Ebene abspielt, so scheint der Projektmanager-Nachwuchs obendrein erhebliche Schwierigkeiten mit dem Menschenbild „Open-Source-Entwickler“ zu haben. Und jeder echte Linux-Fan identifiziert sich mit dieser „Gattung“ Mensch.

Seite 10


© Frank Obels


Die Erwartungshaltung des höheren Managements gegenüber Linux scheint dem zukünftigen Projektleiter ebenfalls erschwerend entgegenzuwirken. Kurzum, Anfänger und gestandene Profis haben offensichtlich einige Mentalprobleme mit dem Thema Linux. Dies ist jedoch völlig unnötig, wie ich Ihnen aus mehreren kleinen und den drei großen Linux-Projekten berichten darf. Womit ich mein Buch bereits beenden könnte, denn das Wesentliche ist gesagt. «Die Botschaft hör’ ich wohl, allein, mir fehlt der Glaube», so ungefähr lauten die Reaktionen, wenn ich Kollegen von der einfachen Migration auf Linux berichte. Also habe ich mich entschlossen, mich hinzusetzen und einige, mir wesentlich erscheinende, Aspekte zu diesem Thema niederzuschreiben.

0.3

Zielsetzung dieses Buches

Dieses Buch stellt in erster Linie ein Praxiswerk im Bereich Projektmanagement dar, mit dem Fokus auf Besonderheiten in der Linux-Projektarbeit. Konzipiert als unterhaltsamer, und in lockerer Ausdrucksweise geschriebener, Praxisleitfaden, behandelt dieses Werk eine erhebliche Themenbreite, von den Eigenarten der Linux-Welt bis hin zum optimalen Projektverlauf. Nach meinen Erfahrungen wird das hier vorgestellte Themenspektrum von einem Projektleiter im IT- und insbesondere Linux-Umfeld gefordert sein. Dieses Buch will Sie dabei unterstützen, dass Sie mit dem Geforderten nicht überfordert sind! Egal, ob Sie Manager in der Linie oder Projektleiter sind, Sie werden nach der Lektüre dieses Buches die Praxis-Optionen von Linux-Projekten verstanden haben. Die übrigens gar nicht so bedeutend sind, wie von manchem Berater immer wieder gerne postuliert. Nach dem gründlichen Durcharbeiten der folgenden 157 Seiten (das nennt man Motivation!) werden Sie sich gut vorbereitet fühlen, ein Linux-Projekt erfolgreich anzugehen.

0.4

Was dieses Buch nicht ist

Dieser Abschnitt wendet sich an diejenigen „Kritiker“, die gerne durch vernichtende Kommentare ihr Selbstwertgefühl anheben und ihren Kompetenzanspruch unterstreichen wollen.

© Frank Obels


Seite 11


Zunächst zu dem gerne vorgebrachten Argument, dass der Inhalt nicht halte, was der Titel verspricht. Um dies zu vermeiden, steht Ihnen bereits das erste Pre-Release dieses Buches zum kostenlosen Download zur Verfügung. Niemand muss also die Katze im Sack kaufen. Dieses Buch ist auch kein Lehrbuch, derer gibt es reichlich! Klappen Sie dieses Buch bitte auf der Stelle wieder zu, wenn Sie ein fertiges „Kochbuch“ zum Thema Linux-Projektmanagement erwarten. Dieses Buch gibt Ihnen Hinweise auf die Projektpraxis eines Linux-Vorhabens. Doch schon allein der Begriff „Linux-Projekt“ ist als Allgemeinbegriff schwer zu greifen. Was ist ein Linux-Projekt? Eine Server-Migration? Eine Desktop-Migration? Ein Umbau auf Parallelbetrieb? Der Aufbau eines Linux-Clusters, zum „Anbau“ an Mainframes oder Midrange-Systeme? Softwareentwicklung? Web-Development? Dieses Buch ist keine Handlungsempfehlung, sondern eine Denkempfehlung, versehen mit den notwendigen Informationen. Eine gehirnschonende „Nachmach-Studie“ stellt dieses Buch nicht dar!

0.5

Aufbau dieses Buches

Lassen Sie uns einen Blick auf den Aufbau und die Gliederung dieses Buches werfen. Kapitel 1 (Einleitung) ist eine Einführung in die Thematik Open Source. Es gibt derart viele Ansichten und „Glaubenssätze“ zum Thema Open Source und Linux, die Ihnen ganz oder teilweise in Ihrem Projekt begegnen werden, dass Sie in der Lage sein sollten, diesen fundiert zu begegnen. Gerade weil der Großteil eines Projektes im „unsichtbaren“ psychosozialen Bereich verläuft, werden Ihnen die Erkenntnisse aus diesem Kapitel eine gute Unterstützung bieten. Kapitel 2 (Linux-Software für den Unternehmenseinsatz) möchte dem Linux-Unbedarften einmal aufzeigen, was es denn alles an Open-Source-Software rund um das Thema Linux gibt. Wenn Sie in einem Projekt beurteilen müssen, ob ein kommerzielles Softwareprodukt durch ein „freies“ ersetzt werden kann, erhalten Sie in diesem Kapitel wertvolle Hinweise. Kapitel 3 (Erfolgreiches Projektmanagement) ist eine Reise durch die Projektmanagementlehre. Es werden die wichtigen Themen für ein Linux-Projekt aufgegriffen. Diese Lehrreise wird durch zahlreiche Praxistipps aufgelockert und werden Ihnen viele Anregungen für Ihr Projekt geben. Nun wünsche ich Ihnen einen ordentlichen Lesegenuss und viel Erfolg in Ihrer Projektarbeit. Frank Obels Seite 12


© Frank Obels


1

Einleitung

Alles Fertige wird angestaunt, alles Werdende wird unterschätzt. Friedrich Nietzsche

1.1

Die gute Nachricht vorneweg

Allein die Tatsache, dass es Linux heute mit einer gewissen Marktbedeutung gibt, hat den bestehenden IT-Markt ordentlich in Bewegung gebracht. IT-Entscheider und Unternehmer sind aus ihrer Lethargie erwacht und stellen plötzlich fest, dass Software-Monokulturen kein Naturgesetz oder Schicksal sein müssen, dem man sich klaglos unterordnen muss. Linux und Open Source-Software stellen eine Alternative zu Etabliertem dar. „Überall“ wird heute über Linux diskutiert. Die Offenlegung von Quellcodes, also den Bauplänen und Konstruktionsunterlagen der Software, gibt dem kundigen IT-Verantwortlichen die Möglichkeit der Prüfung auf die eigenen Ansprüche, ebenso wie die Anpassungsmöglichkeit an spezifische Bedürfnisse. Es ist ein gutes Gefühl, eine solche Möglichkeit zu haben, genutzt wird sie im Regelfall selten. IT-Managern steht es frei, sich gegen Linux zu entscheiden, wenn es nicht den Ansprüchen einer Unternehmens-IT entspricht – das scheint die Mediendiskussion zeitweise zu übersehen. Man muss sich nicht für Linux entscheiden – niemand zwingt einen. Doch seit die Europäische Union die Empfehlung ausgesprochen hat, bevorzugt Open Source Software einzusetzen, seit die Stadt München sich uneingeschränkt für Linux ausgesprochen hat, wird immer mehr Zweiflern bewusst, dass es wohl bei Open Source doch nicht nur um Spielzeuge begeisterter Informatik-Menschen geht, sondern um Systeme von Profis für den professionellen Einsatz.

© Frank Obels


Seite 13


Die gute Nachricht lautet noch immer, dass niemand sich einfach so für Open SourceSoftware entscheiden muss. Doch wenn eine Entscheidung für Linux & Co. gefallen ist, erwartet das Unternehmen und seine Verantwortlichen viel Neues und Spannendes. Bleibt noch die gute Nachricht für angehende Projektmanager im Linux-Umfeld zu erwähnen: vor Ihnen liegt ein Buch, das Sie von der Projektseite her an das Thema Open SourceSoftware heranführen möchte, und Ihnen zeigen kann, wie Sie ein Linux-Projekt, einfach und erfolgreich, dem (hoffentlich) definierten Ziel entgegenführen.

1.2

Projektmanagement in Linux-Zeiten

Glaubt man den Medien, Befragungsinstituten, Herstellern, Distributoren, Messebesuchern und Anwendern – dann unterliegt Linux einer ständig wachsenden Verbreitung. Für viele IT-Verantwortliche im Unternehmen stellt Linux etwas Neues dar, der Umgang mit diesem Neuen erscheint unsicherer als sonst. Paart man diese Unsicherheit mit dem ohnehin allzu oft nur rudimentär vorhandenen Projektmanagement-Know-how der Fachabteilungen, so erhält man die optimale Mixtur für eine erfolglose Linux-Migration. Wer heute als Projektmanager in der Verantwortung für ein Linux-Projekt steht, muss die teilweise grenzenlos erscheinenden Möglichkeiten von Linux kennen und sie in seine Strategieüberlegungen mit einbeziehen. Dabei gilt es Mythen von Tatsachen zu unterscheiden, das Für und Wider von Open Source-Software zu kennen und sich bewusst zu machen, dass gerade hinsichtlich der Projektpsychologie neue Spielregeln zu erlernen sind. Ganz zufällig hat die Zunft der Persönlichkeitstrainer, im richtigen Moment, das Fehlen einer wichtigen Führungsqualität bei vielen (Projekt-)Managern klar erkannt. Das Zauberwort nennt sich Emotionale Intelligenz. Und so konnte ich kürzlich lesen, dass mit dem bisherigen Repertoire an eingefahrenem Denken eines altbewährten Projektmanagers ein anspruchsvolles Linux-Projekt nicht zu bewältigen sei. Ich hatte weder in meinen Projekten, noch in meinen Vorträgen und Seminaren den Eindruck, dass Projektmanager ein eingefahrenes Denken auszeichnet. Also interpretiere ich den Zeitungsbeitrag dahingehend, dass ein neues Zusatzdenken, im Sinne einer Horizonterweiterung, sicherlich bei einem Linux-Projekt nichts schadet. Also lassen Sie uns dieses Zusatzdenken nunmehr gemeinsam entwickeln. Beginnen möchte ich mit der wichtigsten Open Source-Philosophie: Open Source-Software wird von ihren Entwicklern als Gemeingut betrachtet. Dies sollten Sie vor Ihrem nächsten Projekt verstanden haben.

Seite 14


© Frank Obels


Lassen Sie uns an dieser Stelle auch gleich klären, was sich hinter diesem Begriff „Source“, auch „Sourcecode“ oder „Quellcode“ genannt, verbirgt: Computerprogramme sind eigentlich Textdateien, so wie ein Brief beispielsweise. Nur schreibt der Programmierer in diesem Falle nicht einem Menschen, sondern der Hardware (dem Prozessor) eines Computers. Er benutzt dazu eine klar strukturierte Sprache, die aus Befehlen besteht. Diese Befehle schreibt er einen nach dem anderen auf und der Computer wird diese später brav ausführen. Eine solche Liste (Datei) von Befehlen nennt sich Programm und wenn dieses noch unverändert vorliegt, kann jeder, der die Programmierbefehle versteht, die Befehlsabläufe einsehen und ändern. Da der Computer aber keine Textdateien interpretieren kann, muss man ihm diese Befehlsansammlung in ein anderes Format (die sogenannte Maschinensprache) übersetzen. Der Nachteil dabei ist, dass jetzt niemand mehr (außer dem Computer) diese umgewandelte Datei verstehen (oder einsehen) kann, denn sie besteht nur noch aus Binärzeichen.

1.3

Open Source-Software

„Jeder“ (auch die Microsoft Corporation, Redmond) spricht heute über Open SourceSoftware. Vorbei die Zeiten, da sich ausschließlich IT-Spezialisten für dieses Thema interessierten. Heute hat sich auch das Top-Management mit „offener Software“ zu beschäftigen, begünstigt durch wirtschaftlich schwierigere Zeiten. Die Einsatzgebiete von Open Source Software sind groß. Sie umfassen den DesktopBereich, Server-Bereich und den Embedded-Bereich. Im Server-Bereich wird Open Source-Software als Betriebssystem (Linux), Web Server, Anwendungsserver und Datenbankserver eingesetzt. Im Desktop-Bereich erfolgt der Einsatz als Betriebssystem (Linux), Standard-Office-Anwendung, Bildbearbeitung, Datenbank, Internet-Anwendung und Entwicklungsumgebung. Doch was es mit Open Source-Software wirklich auf sich hat, ist nach wie vor für viele Menschen unklar. Deshalb wollen wir uns zunächst einmal mit einigen grundlegenden Informationen rund um die Open Source-Software beschäftigen.

1.3.1 Die Geschichte von Open Source-Software Software, man mag es kaum glauben, war einmal nur eine kostenlose Beigabe eines Hardware-Herstellers bei der Auslieferung von neuen Rechnersystemen. Die Hersteller verdienten ausschließlich über die Zahl der verkauften „Boxen“. Der Quellcode war für die Welt der begeisterten Programmierer frei zugänglich und damit frei einsehbar, und auf eigenes Risiko auch frei veränderbar.

© Frank Obels


Seite 15


Mit Hilfe dieser Programmierer, die in keinem Angestelltenverhältnis zu den HardwareHerstellern stehen mussten, entstanden vor allen Dingen Anwendungsprogramme. Dies alles war bis zur Mitte der sechziger Jahre so. Dann jedoch begannen die großen Hardware-Hersteller, wie etwa IBM, eine neue Richtung einzuschlagen. Der Quellcode wurde nicht mehr zusammen mit dem Betriebssystem der Großrechner ausgeliefert. Man hatte eine neue Chance Geld zu verdienen gewittert. Da die großen Hardwareunternehmen im Laufe der Zeit in ausreichendem Maße eigene Computerspezialisten ausgebildet hatten, sah man sich in der Lage, auf die externen Entwickler verzichten zu können. Software wurde eine eigenständige Geldeinnahmequelle. Dies stellten auch viele der „freien“ Programmierer fest, die mit der von ihnen entwickelten Software erhebliche Einkünfte erzielten. So entstand zu Beginn der siebziger Jahre das bis heute bekannte Modell, sich mit Hilfe von Lizenzverträgen, und dem damit verbundenen eingeschränkten Nutzungsrecht für den Kunden, fröhlich sprudelnde Geldquellen zu sichern. Die Weitergabe von Software war entweder stark eingeschränkt oder gänzlich verboten. Und so wurden die Quellcodes zu den bestgehütetsten Geheimnissen der neuen Unternehmergeneration. Bereits zu Beginn der achtziger Jahre gab es praktisch keine frei verfügbaren Quellprogramme mehr. Hard- und Software hatten sich längst als getrennte Industrien etabliert und Software wurde nur noch hinter hermetisch abgeriegelten Labortüren produziert. Wenn Sie zu der älteren IT-Generation meiner Leser gehören, dann spüren Sie vielleicht, gerade in diesem Moment, auch so eine ganz schwache Leere in sich, so als hätte man der Welt damals etwas endgültig weggenommen. So fühlten sich tatsächlich viele Programmierer der damaligen Zeit, Fassungslosigkeit machte sich breit. Für die Computeranwender hatte die skizzierte Entwicklung zur Folge, dass sie sich bei Programmfehlern oder Änderungswünschen nunmehr immer an den Softwarehersteller wenden mussten, der sich jeden Handschlag üppig bezahlen ließ. Und so machte sich neben Fassungslosigkeit schnell auch eine erhebliche Unzufriedenheit breit. Der wohl unzufriedenste unter ihnen war ein gewisser Richard Stallman vom renommierten MIT (Massachusetts Institute of Technology). Dieser Herr Stallman rief 1984 ein Projekt ins Leben, das sich GNU (GNU is not Unix) nannte und zum Ziel hatte, ein „freies“ unix-artiges Betriebs-system zu schaffen. Dabei sollte GNU, in Verbindung mit einem Betriebssystem-Kern, ein komplettes Betriebssystem, viele nützliche Anwendungsprogramme und eine vollständige Software-Entwicklungsumgebung umfassen. Das Ziel Stallmans war es, die offene Zusammenarbeit von Software-Entwicklern, so wie er sie selbst es noch Ende der sechziger Jahre erlebt hatte, durch das GNU-Projekt erneut zu ermöglichen. Stallman betrachtete es als sein natürliches Recht, seine Programme mit seinen Freunden und Kollegen zu teilen. Zum Nutzen aller Computeranwender sollten Quellcodes vervielfältigt, verändert und weitergegeben werden dürfen.

Seite 16


© Frank Obels


Um seine Ideale zu bewahren und zu fördern, gründete Stallman zusammen mit Freunden 1985 die Free Software Foundation, kurz FSF. Die FSF ist heute der institutionelle Rahmen für GNU und erarbeitete ein formelles Lizenzprozedere, mit dem sich die Freiheit an der Software erhalten ließ und gleichzeitig das Urheberrecht gesichert wurde. Diese ist heute in der Version 2 von 1991 uns allen unter der Bezeichnung GNU General Public License (GPL) bekannt. Ein Anwender darf also nun, gemäß GPL, Software, die GPL-lizenziert ist, modifizieren, kopieren und verbreiten – vorausgesetzt, dass seine „abgeleitete“ Software wiederum unter der GPL veröffentlicht wird. Lizenzrestriktionen der „eigenen“, ursprünglichen GPLSoftware sind verboten. Stallman nennt diesen Ansatz Copyleft, als Anspielung auf das ihm so unbequeme Copyright. Bekannteste Beispiele für GPL-lizenzierte Software sind der Linux-Kernel, die Benutzeroberflächen KDE und Gnome, die gesamte GNU-Software (vom Compiler bis zum Schachprogramm) und eben auch StarOffice (Sun Microsystems, ehemals Star Division) respektive OpenOffice. Nehmen Sie an dieser Stelle bitte auch die Erfahrung mit, dass es rund um die GPL einige Abgrenzungsschwierigkeiten gibt, wie weit man den Begriff „abgeleitete Software“ fasst. Dies fängt beim Linux-Kernel und der Abgrenzung zu Anwendungsprogrammen bereits an. Sofern Sie Rechtsanwalt sind, lächeln Sie doch bitte einen kleinen Moment – und danken Sie dem Universum für Linux – es wird noch einiges an „Aufträgen“ auf Ihre Branche in punkto Open Source-Software und diesbezüglichen Rechtsfragen zukommen. Die Firma SCO versucht dies in jüngster Zeit pressewirksam zu demonstrieren. Der Begriff der freien Software führte, dank der mehrfachen Bedeutung des Wörtchens „free“ in der englischen Sprache zu einigen Fehlinterpretationen. So wurde das Wort „frei“ immer weniger im Sinne von „Freiheit“, sondern mehr im Sinne von „kostenlos“ ausgelegt. Unternehmen mit einem grundsätzlich vorhandenen Interesse an GPL-lizenzierter Software ließen sich durch das aufkommende „Freibier-Image“ von freier Software derart abschrecken, dass sie kein Vertrauen in eine derartige Software mehr für den Einsatz im Unternehmensumfeld hatten. Die Jahre vergingen, die Software-Branche entwickelte sich prächtig und die Firma Microsoft begann die Herrschaft über ein kleines Hardware-System, genannt PC, durch seine Software zu übernehmen. Manchmal hörte man noch etwas von „freier Software“, aber eher selten. Zwar hatte das GNU-Projekt mit den Jahren einen erheblichen Umfang angenommen, aber es fehlte ihm das wesentlichste Element, der Betriebssystemkern. Dieses Problem begann sich mit einer E-Mail eines jungen finnischen Studenten, im ebenfalls jungen Internet zu lösen. Linus Torvalds stellte 1991 im Internet den Prototypen eines selbst entwickelten Unix-ähnlichen Betriebssystemkerns vor, nannte das Ganze Linux und bat um zahlreiche Kommentare und Verbesserungsvorschläge.

© Frank Obels


Seite 17


Stallman sah sein Ziel erreicht. Mit dem Erscheinen von Linux war das letzte fehlende Element, der Kernel, für das GNU-System verfügbar und somit stand ein komplett freies Betriebssystem zur Verfügung. Linux erreichte in kürzester Zeit eine Beliebtheit und Verbreitung, wie sie bei freier Software bis dahin unbekannt war. Viele Benutzer entschieden sich für Linux. Mit Linux rückte die freie Software auch wieder in das Blickfeld der kommerziellen Welt. Mehr und mehr kommerzielle Software wurde auf Linux portiert, die Grenzen zwischen freier und nicht-freier Software wurden fließender. Stallman gefiel diese Entwicklung gar nicht, denn er sah mit Sorge die Beteiligung der kommerziellen Unternehmen am Phänomen Linux. Insbesondere der neue Ansatz, freie Software „verkaufen“ zu dürfen, führte zu erheblichen Differenzen, unter anderem mit dem Software-Experten Eric Raymond. Dieser hatte die Entwicklungsmethode der Linux-Kernel-Gemeinde beleuchtet und war von der Effizienz und Wirtschaftlichkeit der offenen Softwareentwicklung begeistert. 1998 schlug Raymond vor, Software mit offenem Quellcode als Open Source-Software zu bezeichnen und ein Lizenzmodell zu entwickeln, dass sich von den Einschränkungen der (kommerziellen) Nutzung befreite. Auch Linus Torvalds beteiligte sich an der Definition des neuen Open Source-Modells.

1.3.2 Die Open Source-Kriterien Wenn sich eine Software mit dem Attribut „Open Source“ schmücken möchte, müssen die Lizenzbedingungen, unter denen diese Software veröffentlicht wird, in allen Punkten den Anforderungen der Open Source Definition entsprechen. Nachfolgend finden Sie eine Auswahl der Kriterien, die Sie für Ihr Linux-Projekt interessieren mag. Die vollständige Übersicht aller Kriterien finden Sie im Original unter http://www.opensource.org.

Freie Weiterverbreitung Der Verkauf oder die Weitergabe der Software muss ohne Einschränkungen möglich sein. Die Lizenz der Software darf keinerlei Nutzungsgebühr verlangen. Verfügbarkeit des Quellcodes Die Software muss den Quellcode beinhalten. Die Verbreitung als Quellcode als auch in kompilierter Form muss gestattet sein. Sollte ein Teil der Software ohne Quellcode verbreitet werden, so muss der kostenlose Download via Internet möglich sein. Ein entsprechender Hinweis hat deutlich zu erfolgen.

Seite 18


© Frank Obels


Auf der Software basierende Weiterentwicklungen Basiert eine Software ursprünglich auf Open Source und möchte nun ebenfalls zu Open Source werden, so müssen die Lizenzbedingungen des zugrunde liegenden Werks übernommen werden. Keine Diskriminierung von einzelnen Personen oder Gruppen Um das Maximum aus der Open Source-Softwareentwicklung herauszuholen, müssen möglichst viele verschiedene Menschen das Recht haben, Beiträge zu Open SourceSoftware zu leisten. Daher darf niemand aus dem Verfahren ausgeschlossen werden. Keine Einschränkungen für bestimmte Anwendungsbereiche Die Lizenz der Software darf niemanden in der Nutzung der Software auf ein bestimmtes Einsatzgebiet beschränken. Sie darf beispielsweise nicht die kommerzielle Nutzung verbieten. Die Lizenz darf nicht für ein bestimmtes Produkt gelten Die zur Software gehörenden Rechte müssen unabhängig von einer bestimmten Softwaredistribution sein. Wird das Programm außerhalb einer solchen Distribution genutzt oder verbreitet, so gelten für den Benutzer dieselben Rechte, die in der Originaldistribution bestehen.

1.3.3 Ein Paradigmenwechsel vollzieht sich

Wer sich auf Open Source einlässt, sollte sich auf einen Paradigmenwechsel einstellen. Open Source wird gerne als Kulturwandel in IT-Bereich bezeichnet. Es ist unbestritten, dass Open Source andersartige Geschäftsmodelle und veränderte Rechtsbeziehungen mit sich bringt. Der Konsument bekommt zunächst viele Open Source-Programme kostenlos, muss aber als Unternehmer eine völlig neue Art von Folgekosten berücksichtigen oder neue Gewährleistungsrichtlinien kennen lernen.

© Frank Obels


Seite 19


Als „Projektmenschen“ sollten wir uns vergegenwärtigen, dass Software, die frei verfügbar ist, eine starke Anziehungskraft ausübt. Die Reaktionen des menschlichen Umfeldes sind in zwei Grundrichtungen gespalten: bei den einen kennt die Begeisterung keine Grenzen und Open Source wird als die Lösung aller IT-Probleme angesehen – bei den anderen überwiegt ein starkes Unwohlsein, da sie befürchten, auch aus Unkenntnis der Materie, ihr gesamtes Weltbild ändern zu müssen oder Schiffbruch zu erleiden. In der heutigen (wirtschaftlich schwierigen) Zeit ist die Angst vor misslungenen ITProjekten groß. In Ihrem Projekt werden Ihnen Vertreter beider Gruppen begegnen, unter Umständen mit ausgeprägter Rivalität zueinander. Beide werden Ihre Ansichten nicht nur in der Öffentlichkeit diskutieren, sondern alle möglichen Probleme sehr gerne auf Sie als Projektverantwortlichen projizieren. Hier haben Sie möglicherweise ein wenig Sprengstoff zu entschärfen und auf ausgelegte Tretminen zu achten. Erfahrungsgemäß stellt die Haltung des Top-Managements eine weitere Hürde dar. Sie sollten als Projektleiter frühzeitig klären, aus welcher Richtung „der Wind bläst“.

1.3.4 Wie entsteht ein Open Source-Projekt – wer leitet es? Am Anfang eines Open Source-Projektes steht häufig der Ärger von Softwareentwicklern über Probleme mit einer Software oder fehlende Funktionalität. Richard Stallman wollte am MIT einen Druckertreiber dazu bringen, bei Papierstau oder ähnlichen Betriebsproblemen, eine Mitteilung an alle Benutzer im Netzwerk zu schicken, dass der Drucker momentan nicht betriebsbereit sei. Doch der Druckerhersteller verweigerte den Einblick in den Quellcode und Stallman musste einen komplett neuen, eigenentwickelten Druckertreiber „nachbauen“. Ich erinnere mich noch gut, wie ich unbedingt, in einem Projekt meinem Kunden eine spezielle Projektabrechnungssoftware zur Verfügung stellen wollte. Aber es gab nur schlechte Ansätze, und ausschließlich kommerzieller Natur. Also programmierten wir im Team eine solche Software „mal eben“ selbst. Es sind diese Mangelzustände, die zumeist zur Geburt eines Open Source-Projektes führen. Ein Software-Entwickler möchte ein bestimmtes Problem lösen, das ist im Regelfall der Ausgangspunkt. Also schreibt er ein Programm und veröffentlicht bereits die ersten Versionen mitsamt Quellcode im Internet. Sofern die Lösung des Problems auch für andere interessant ist, wird er schnell Wegbegleiter finden, die die Software mitentwickeln oder aber als freiwillige Software-Tester zur Verfügung stehen. Je größer die „Gemeinde“, umso mehr Fehler können gefunden werden (vor allen Dingen in völlig unterschiedlichen IT-Umgebungen) und umso schneller schreitet die Entwicklung voran. Dies schließt den Funktionsumfang mit ein, denn häufig entdecken andere Softwareentwickler ihre Funktionswünsche und implementieren diese. Und das alles ohne eine Leitungsinstanz, einfach so, jeder mit jedem?

Seite 20


© Frank Obels


Zusammenarbeit bei einem Open Source-Projekt Verstehen wir den Begriff Leitungsinstanz in seiner hierarchischen Bedeutung, so sind Open Source-Projekte zumeist tatsächlich ohne Leitung. Häufig ist der Gründer eines Open Source-Projektes auch der Projektleiter. Um die Projektleitung bildet sich ein Team von Programmierern, das sich besonders für das Thema interessiert. Sollte das Projekt größer werden, so werden diese Teammitglieder zu „Förderern“ oder modern ausgedrückt zu Teamleitern mit der Verantwortung für einen Teilbereich. Alle Teamleiter zusammen bilden das Kernteam. Die Mitarbeit an einem Open Source-Projekt steht grundsätzlich jedem offen. In das Kernteam aufgenommen zu werden, ist für die meisten Entwickler eine besondere Auszeichnung und häufig das Ziel von jungen Softwareentwicklern, die sich so einen Namen in der Branche machen wollen. Übrigens erfolgt die gesamte Zusammenarbeit der Entwickler über das Internet. Finanzierung eines Open Source-Projektes Zunächst arbeiten die Entwickler aus Begeisterung an einem Projekt und haben keinerlei Bezahlung zu erwarten. Viele wollen ja auch ein eigenes Problem gelöst haben. Ein wesentlicher Kostenfaktor eines Open Source-Projektes ist die Anbindung an das Internet. Bei großen Projekten wird durch die hohe Teilnehmerzahl und das damit verbundene hohe Datenaufkommen sicherlich auch ein entsprechend leistungsfähiger Server benötigt. Bei Sofware-Projekten, die sich mit Portierung einer Software beschäftigen, werden unterschiedliche Hardwareumgebungen benötigt. Deshalb hat sich in den USA eine Form des Open Source-Sponsoring durch Unternehmen und Behörden etabliert. Auch in Deutschland ist in letzter Zeit ein diesbezüglicher Trend zu erkennen.

1.3.5 Zehn Mythen über Open Source Software Tim O’Reilly, Chef des bekannten O’Reilly-Verlages, hielt im Herbst 2000 eine interessante Rede vor amerikanischen Top-Managern zum Thema Open Source. Seine Ausführungen eignen sich ganz ausgezeichnet, um Ihnen zu demonstrieren, was heute, teilweise unbewusst, noch immer mit Linux assoziiert wird. In eigenen Worten und stark verkürzt, möchte ich Ihnen die wesentlichen Inhalte wiedergeben. Seit dem fulminanten Börsenstart der Firma Red Hat ist Linux vielen Menschen ein Begriff geworden. Und erstmals fragten sich die Menschen, woher denn dieses Linux komme, ob es auch wie das Internet aus dem „Nichts“ kam und ebenso wie das Internet nun auch unser

© Frank Obels


Seite 21


Alltagsleben verändern würde. Und plötzlich hatten viele Menschen etwas über Linux zu sagen. Zumeist unrichtig, aber dafür umso reißerischer in der Darstellung. Die Medien stilisierten (und tun dies noch) Linux zum kleinen Angreifer gegen den mächtigen Riesen Microsoft. Sie sollten als Projektleiter eines Linux-Projektes wissen, was in das Reich der Mythen gehört. Also schlage ich Ihnen vor, dass wir uns die Top 10 dieser Mythen einmal anschauen.

Mythos Nr. 1: Linux greift Windows an - Red Hat ist ein weiterer Gegner Microsofts. Schlägt man die Zeitungen auf, so bekommt man den Eindruck, dass die gesamte Open Source Welt gegen Microsoft angetreten ist. Ich will nicht ausschließen, dass vereinzelt dieser Traum geträumt wird, generell jedoch ist einem „Linuxer“ Microsoft erst einmal egal. Es ist durchaus üblich, Microsoft-Produkte als Ideenmotor für eigene Open Source-Produkte heranzuziehen, die guten Funktionen zu übernehmen, die Schwächen zu verbessern und insgesamt besser zu werden als das kommerzielle Vorbild. Lassen Sie sich also in Ihrem Linux-Projekt keinen „Welten-Krieg“ einreden. Aus LinuxSicht ist dieser ohnehin unerwünscht. Die Open-Source-Welt möchte sich ungestört entwickeln dürfen und will sich nicht in etwas hineinziehen lassen, was ohnehin keinem dient. Ihr Kunde erwartet im übrigen eine vernünftige Lösung von Ihnen als Projektprofi und keinen Ideologiekampf mit ungewissem Ausgang.

Mythos Nr. 2: Open Source-Software ist unzuverlässig und niemand bietet Support. Sollten Sie einem Menschen begegnen, der diese Aussage zum Besten gibt, so fragen Sie ihn, ob er denn das Internet benutze. Denn wenn Open Source-Software so unzuverlässig ist, dann ist es das Internet allemal. Denn schließlich beruhen wesentliche Mechanismen des Internet auf Open Source. Zum Beispiel die sogenannte Domain-Verwaltung, das Domain Name System. Jede einzelne Internet-Adresse - sowohl Web- als auch e-MailAdresse - hängt vom Domain Name System, kurz DNS, ab. Schauen wir uns das an. Wenn Sie eine Web-Adresse aufrufen, beispielsweise www.inconet.de, so ist „.de“ die TopLevel-Domain Deutschlands, „.inconet“ ist die Domain, die sich die Firma INCONET aus Karlstein ausgesucht hat. Der Mechanismus, der weltweit dafür sorgt, dass wir den richtigen Rechner durch die Eingabe einer Webadresse finden, funktioniert über ein Open Source-Programm namens BIND. Wenn man sich die heutige Bedeutung des Internet vor Augen führt, ist BIND nachweislich eines der wichtigsten Programme der Welt.

Seite 22


© Frank Obels


Wenn Sie www.inconet.de aufrufen, erscheint eine nette kleine Website. Dies wird durch einen sogenannten Webserver ermöglicht, den der ausgewählte Provider verwendet. Sie ahnen es schon, auch dieser ist ein Open Source Programm, in fast allen Fällen handelt es sich um das Programm Apache. Nehmen Sie Webadressen der Großen, wie Yahoo, Ebay oder Amazon, die alle enorm viele Webseitenaufrufe bewerkstelligen müssen, so finden Sie dort Apache. Das ist aber noch nicht alles. Praktisch jede e-Mail, die über das Internet geschickt wird, verwendet das Open Source Programm sendmail, im Regelfall wiederum bei den Providern zu finden. Viele Firmen wissen nicht einmal, dass sie, respektive ihr Provider, sendmail verwenden. Wir sprechen diesbezüglich von einer Verwendungshäufigkeit von über 70 Prozent, wobei auch die übrigen 30 Prozent fast ausschließlich auf Open Source Software basieren. Noch einen Punkt sollten wir uns anschauen. Ihr Unternehmen hat seine EDV sicherlich in irgendeiner Form vernetzt und die Wahrscheinlichkeit ist gross, dass dieses Netzwerk TCP/IP-basierend ist. Auch Microsoft selbst benutzt dieses Netzwerkprotokoll. Und das ganze Internet basiert auf TCP/IP. Das TCP/IP-Protokoll, das von den meisten kommerziellen Internet-Softwarepaketen verwendet wird, basiert auf „öffentlichem“ Code. Auch die Internet Engineering Task Force oder IETF - jene Körperschaft, die alle Internet-Standards beschließt - operiert nach einem Prozess, der mit Open Source viel gemeinsam hat. Also, was sagen Sie nun jemandem, der Ihnen in Ihrem Projekt erzählen möchte, Open Source sei unzuverlässig? Bevor wir auf das Support-Thema kommen, hier noch die Anmerkung, dass es sich bei den meisten Open Source Anwendungen auch nicht um „Software-Eintagsfliegen“ handelt. Viele dieser Programme wurden und werden beständig weiterentwickelt, immer noch verfeinert und vor allen Dingen über Jahre hinweg betreut. Über eine solche Zeitspanne hinweg haben viele der kommerziellen Anwendungen das digitale Ableben erleben müssen. Nun zum Thema Support. Wenn Sie sich eine Software von einem Open Source Anbieter herunterladen, so werden Sie diese sicherlich nicht sofort als „mission critical application“ einsetzen. Support haben Sie dennoch schon vom Softwareanbieter. Stellen Sie aber professionell Ihre IT um, zum Beispiel im Rahmen eines Linux-Migrationsprojektes, so bieten Ihnen der Berater, der Linux-Distributor, das Systemhaus und viele mehr weitreichenden Support an. Sie können in der Support-Landschaft derzeit alle wichtigen Vertreter finden, von den Big Company-Supportern wie IBM, HP, Sun oder Silicon Graphics, über erfolgreiche Startups wie Red Hat bis hin zu einer schier „unendlichen“ Zahl an Systemhäusern.

© Frank Obels


Seite 23


Mythos Nr. 3: Vielleicht verwenden kleine Firmen Open Source-Software – die Großen aber nicht. Wir haben eben gerade bereits am Beispiel von Yahoo und dem Webserver Apache gesehen, dass diese Aussage nicht stimmt. Schauen wir uns einmal an, wie es in der Serverlandschaft der großen Unternehmen aussieht, so können Sie jederzeit den Medien entnehmen, wie viele Server Open Source Software „fahren“. Tim O’Reilly zeigt am Beispiel seiner Buchverkäufe zum Thema Perl, dass praktisch jedes Großunternehmen offensichtlich Perl in der IT-Entwicklung einsetzt. Perl wiederum ist die führende OpenSource-Programmiersprache. Aber lassen Sie uns ruhig auch einmal in eine andere Ecke schauen, beispielsweise dem Themenkomplex Multimedia. Der berühmteste Vertreter der Open Source Software ist derzeit ein freier Clone von Adobe Photoshop mit dem Namen GIMP. Diese Software ersetzt in vielen Großunternehmen die kommerziellen Produkte, da sich die Fachleute einig zu sein scheinen, dass allein der Funktionsumfang erheblich größer ist als bei vergleichbaren Produkten. Da nimmt man gerne in Kauf, dass dieses Produkt kostenlos ist. Zur Generierung von Trickeffekten setzen große Filmproduzenten auf Linux, sei es bei „Juressic Park“ oder bei „Titanic“. Aus meiner Projekterfahrung weiß ich zu berichten, dass Groupwarelösungen, TroubleTicket-Systeme, Projektmanagementsoftware und 3D-Programme in Deutschlands großen Unternehmen in der Open Source Variante eingesetzt werden. Mythos Nr 4: Open Source ist der Feind des geistigen Eigentums. Schauergeschichten über die General Public License (GPL) und ihre Nachfolger gibt es reichlich – die Meinung, dass ein Unternehmen nunmehr alle seine Software verschenken müsse, ist die irrigste aller Aussagen. Ich möchte Ihnen dies am Beispiel eines kleinen Softwarehauses einmal erläutern. Richtig ist, dass Software, die GPL-basierten Code beinhaltet, unter denselben Auflagen veröffentlicht werden muss. Allerdings sind jederzeit proprietäre Erweiterungen möglich und zumeist auch nötig. Open Source Software wird also auf die Individualbedürfnisse des Kunden angepasst. Dieser erhält den Quellcode, in welchem klar ersichtlich ist, wer die geistigen Väter der Software sind – das Softwarehaus „hängt“ sein Programmierwerk einfach „dran“. Die Rechte eines Jeden sind gewahrt. So geschieht dies heute insbesondere im E-Commerce-Bereich, wo beispielsweise für Shoplösungen GPL-lizenzierte Programme als Basis eingesetzt werden. Die obige Aussage ist aber auch deshalb unseriös, weil der gesamte Lizenzierungsprozess sich noch im Fluss befindet. Firmen wie Netscape, IBM, Apple und viele kleinere Entwickler sind dabei Lizenzen zu schaffen, die dem Schöpfer der Software eine Reihe von Urheberrechten sichern, den Quellcode aber „offen“ gelegt haben, um außenstehende Entwickler einzubinden.

Seite 24


© Frank Obels


Mythos Nr. 5: Open Source dreht sich nur um Lizenzen. Zunächst einmal geht es bei Open Source um ein Kooperationsmodell der Softwareentwicklung per Internet. Für Sie als Projektmanager in einem Linux-Projekt ist sehr wichtig zu wissen, dass Open Source im wesentlichen eine Methode zur SoftwareEntwicklung ist – aber keine politische Ideologie. Wie bereits gesagt, es werden laufend neue Vorschläge unterbreitet, wie man die Rechte des Einzelnen in Form von Lizenzen schützen kann – aber das ist nicht der Kernpunkt. Was Sie, lieber Leser, von Open Source lernen können, auch für Ihr nächstes Projekt, ist die Technik der vernetzten Zusammenarbeit. Dies ist für mich der größte Verdienst der Open Source-Gemeinde. Open Source-Softwareprojekte haben Techniken entwickelt, die alle gewinnbringend auf jedwede Form der Softwareentwicklung angewendet werden können. Zu nennen wären diesbezüglich die Verwendung von Mailing-Listen zur Fachdiskussion, verteilte Zugriffe auf Versionskontrollsoftware, Techniken zur Kritik durch Gleichgesinnte ("peer-review"), Methoden zur Erörterung und Abstimmung von Features, rasches Reagieren auf User Feedback und Gelegenheiten zur Mitbestimmung durch alle Benutzer. Mythos Nr. 6: Wenn ich meine Software der Open Source-Gemeinde aushändige, werden plötzlich Tausende von Entwicklern gratis für mich arbeiten. Welch schöner Traum, nicht wahr? Linux kann sich auf Tausende von aktiven Entwicklern berufen – das ist wahr. Aber unter dem Begriff „Linux“ vereinen sich auch einige Hundert Projekte. Lassen Sie uns deshalb kurz das Prinzip der Softwareentwicklung anschauen. Die meisten Open Source-Projekte bestehen im Kern aus wenigen aktiven und interessierten Teilnehmern, die Problemberichte, Bug Fixes und gelegentliche Ergänzungen liefern. Diese Zahl ist nicht so beeindruckend. Dafür besteht ein solches Open SourceProjekt aber aus vielen Tausenden oder Zehntausenden von Benutzern. Das Phänomen dabei ist nun, dass einige der Benutzer aus der sogenannten äußeren Zone in die innere Zone wandern können. Dies geschieht bei Bedarf, meist nicht von langer Dauer aber dafür um so effektiver. Vergleichen können Sie das vielleicht mit den Spenden-Aufruf-Unterhaltungssendungen im Fernsehen. Da spenden gut und gerne (je nach Thema) eine Million Zuschauer kleine Beträge (leisten also einen kleinen, aber gleichwohl wichtigen Beitrag). Die wirklich hohen Beträge werden aber nicht durch die Masse, sondern im Regelfall durch wenige einzelne Zuschauer gespendet. Wenn man als Unternehmen ein solches Modell der Softwareentwicklung erträumt, gilt es eine wichtige Lektion zu lernen: Wenn man die Zusammenarbeit mit einer „Gemeinde“ sucht, dann sollte es auch genau die „Gemeinde“ der Benutzer des Produktes sein und nicht irgendeine "Open SourceGemeinde". Die meisten Softwareentwicklungsunternehmen machen sich aber leider nicht einmal die Mühe, ihre (späteren) Benutzer klar zu definieren.

© Frank Obels


Seite 25


Mythos Nr. 7: Open Source hat nur für Programmierer Bedeutung, da die meisten Benutzer ohnehin niemals den Quellcode ansehen. Es ist so, dass ein Geschäftsführer, Top-Manager oder auch Sie, als Projektleiter, sich wahrscheinlich eher weniger stark für den Source Code interessieren werden. Der offene Quellcode ist „lediglich“ der Garant dafür, nicht mehr länger einem Anbieter allein ausgeliefert zu sein. Im wirklichen (seltenen) Problemfalle kann man das Problem selbst lösen respektive sich an einen anderen Anbieter wenden oder auch gleich mehrere davon. Für mich ist der wahre Vorzug von Open Source ein anderer, nämlich der eines jeden freien Marktes: Wettbewerb zwischen mehreren Anbietern – und das bewirkt niedrigere Preise, kürzere aber stärkere Innovationszyklen und schließlich große Spezialisierungsmöglichkeiten, die den Bedarf neuer Nischen bedienen. Open Source hat nicht nur für Software-Hersteller Bedeutung. Es ist eine Möglichkeit, Ihren internen Benutzern und Kunden bessere Dienstleistungen zu bieten, und das durch vernetzte Kooperation, wie sie von den besten Software-Entwicklern erprobt wurde. Mythos Nr. 8: Mit freier Software kann man kein Geld verdienen. Wenn ich mir die Heerscharen an Softwareentwicklern in den großen Unternehmen anschaue, dann frage ich mich, ob diese Aussage nicht am Thema vorbeigeht. Die meiste Software wird in den Unternehmen für den Eigengebrauch entwickelt – unter anderem deshalb weil die sogenannte Standardsoftware nicht ausreichend individualisierbar ist. Dies ändert sich mit Open Source Software gewaltig, denn diese „Standardsoftware“ ist kostenlos und das Unternehmen hat einen erheblich geringeren Anpassungsaufwand, der noch zu alledem jetzt erstmals überhaupt möglich wird. Ich bezeichne diesen geringeren Programmieraufwand durchaus als Möglichkeit zum Geld verdienen für ein Unternehmen. Nur setze ich nicht an der Umsatzseite sondern an der Kostenseite an. Und das eben bereits dargestellte Softwarehaus verdient an den Individualanpassungen für seine Kunden ebenfalls prächtig. Lassen Sie mich obige Aussage deshalb etwas modifizieren: Durch freie Software verringert sich die Marge der bis dato etablierten Anbieter „proprietärer“ Software. Open Source-Software wird die Summen verringern, die für existierende kommerzielle Software ausgegeben werden. Hardware-Hersteller springen dagegen gerade freudig auf den Open Source-Zug auf, denn immerhin brauchen sie hier die ansonsten üblichen „Steuern“ (eine Art Lizenz der Betriebssystemanbieter) nicht zu bezahlen.

Seite 26


© Frank Obels


Mythos Nr. 9: Die Open Source-Bewegung ist nicht von Dauer; die Leute werden aufhören, freie Software zu entwickeln, sobald sie sehen, dass andere viel Geld mit ihrer Arbeit verdienen. Kommt diese Aussage etwa aus einer mit Existenzängsten umgebenen „alten Softwareentwicklerwelt“? Schaut man sich die die grandiosen neuen Möglichkeiten (Geschäftsmodelle) an, wie man mit freier Software Geld verdienen kann, so besteht zu Recht Zweifel an der Aussage, Open Source sei nicht von Dauer. Wenn man sich die Beteiligten an den Open Source-Projekten betrachtet, dann erkennt man ein sehr großes Kontingent von Menschen, die Open Source-Projekte durch ihre (freie) Teilnahme finanzieren, und zwar, weil sie die Software bei ihrer Arbeit verwenden wollen oder einen anderen Weg gefunden haben, damit Gewinne zu machen. Viele meiner technisch angehauchten Beraterkollegen entwickeln bei Open Source mit, um ihren Marktwert zu erhöhen, was ihnen auch prächtig gelingt, wie ich beobachten darf. Firmen entwickeln gerne bei Open Source-Projekten mit, da sie sehr schnell neue Services verkaufen können. So geschehen bei den Internetprovidern, die mit immer neuen ApacheFeatures ihren Kunden ständig neue Dienste anbieten. Zugriff auf den Server-Code zu haben, war und ist für ihr Geschäft lebenswichtig und so war und ist es sinnvoll, die Weiterentwicklung „durch Mitmachen“ zu bezahlen. Mythos Nr. 10: Open Source kann nur imitieren, was die kommerzielle Welt erfindet. Es ist unbestritten, dass im Desktop-Bereich mit KDE und Gnome versucht wird, den etablierten Desktop-Look nachzuempfinden, allerdings beschränkt sich diese Aussage auf das reine „Look & Feel“. Von der Funktionsvielfalt her betrachtet, sind die beiden Vertreter bereits heute jedem kommerziellen Ansatz weit voraus. Ich stelle allerdings die Frage, ob mit dieser Aussage das gesamte Open Source-Phänomen bereits hinreichend abgehandelt ist. Welche Bedeutung hat denn der Desktop heute noch und welche Bedeutung wird er in Zukunft haben? Ist es nicht so, dass die wirklich spannenden und großen Anwendungen gar nicht mehr Desktop-basiert sind? Application Service Providing heißt eines der neuen Zauberworte und bedeutet das (kostenpflichtige) Anbieten von webbasierten Anwendungen im Internet. Amazon, Ebay, Online-Banking, Online-Brokering, Online-Shopping, Online Learning, Virtual Universities - neue Funktionalität wird heute über das Web geliefert. Und sind nicht selbst die Dateimanager der freien und kommerziellen Betriebssysteme heute webbasiert? Es wäre zu diskutieren, inwieweit wir zukünftig überhaupt noch von Anwendungen sprechen werden. Bedeuten Begriffe wie „Services“ oder „Prozesse“ nicht heute schon mehr als nur das Benutzen einer Anwendung?

© Frank Obels


Seite 27


Betrachtet man sich das Unternehmen IBM zu den frühen Zeiten des PCs, so hat IBM durch die Veröffentlichung der PC-Spezifikation die Eintrittshürden in diesen Markt dramatisch gesenkt. Und plötzlich konnte ein Jeder PCs bauen, so wie Michael Dell in seinem Studentenwohnheim. Was schließlich zu einem Millardenunternehmen führte. Daneben entstanden plötzlich echte Software-Firmen, was eine Firma Microsoft berühmt (und reich) machte. Was für eine Überraschung für IBM, die irrtümlicherweise dachte, dass Hardware mehr als Software zählte. Sind wir jetzt an dem Punkt angelangt, an dem wir die wahre Bedeutung von Open Source erkennen können? Ein Absenken der Eintrittshürden erhöht die Wahrscheinlichkeit von Überraschungen? Dann lassen sich mich zum Abschluss dieser Mythenbetrachtung etwas philosophieren: Open Source erlaubt uns somit wieder echte Innovationen – nicht nur weil die Entwicklungsmethode gewaltige Vorteile bietet – sondern weil viele Mitspieler unerwartete Wendungen herbeiführen können. Klassische Software-Firmen hätten das Web nicht erfinden können, weil sie zuviel zu verlieren hatten. Es war die Verfügbarkeit von freier Software und offenen Standards, die Menschen außerhalb dieser Branche in die Lage versetzte, das nächste große Paradigma zu schaffen. Das wirkliche Geheimnis von Open Source wäre dann, dass sie der neueste TechnologieDurchbruch wäre, die existierende Anbieter entmachtet und neue Ideen hereinlässt. Wird es also keine Software-Branche mehr, wie sie bisher war, in Zukunft geben? Ich stimme Tim O’Reilly zu, wenn er sagt, dass die Software-Industrie, wie wir sie kennen, weiterhin blühen und gedeihen wird. Der Software-Gegenstand wird sich verlagern und hat sich nach meiner Beobachtung bereits verlagert. O’Reilly erwartet sogar, dass viele Applikationen, die ursprünglich in der Open Source-Gemeinde entwickelt wurden, irgendwann in den nächsten paar Jahren proprietär werden, weil sich viele Hersteller von Web-Applikationen, die ihren Wohlstand auf einem offenen Fundament aufbauen, sich selbst schützen werden wollen. Ich persönlich sehe es als wichtig für die Software-Branche an, zu der richtigen Balance zwischen offen und proprietär zu gelangen. Das dies funktioniert, hat der Markt längst bewiesen. Denn befinden sich nicht im Kern des offenen Internets proprietäre Router der Firma Cisco Systems? Wenn Sie als Projektleiter in ein Linux-Projekt geraten, dann sollten Sie einfach wissen, dass die Medienwelt eine Diskussion führt, die manchmal an der Realität vorbeiführt, gleichwohl aber auf Ihre Gesprächspartner und Auftraggeber abfärben wird. Effizient wäre, aus beiden Welten das Beste zu entnehmen. Open Source ist wie ein Stein, der in einen See geworfen wird. Die Wellen breiten sich weiter aus, auch wenn man den Stein nicht mehr sehen kann, der sie hervorgerufen hat.

Seite 28


© Frank Obels


Sie sollten „vorsichtshalber“ davon ausgehen, dass die Open-Bewegung uns erhalten bleiben wird. Sie hatte bereits großen Einfluss, der sich aber noch erheblich vergrößern wird. Halten Sie die Augen offen und bereiten Sie sich auf noch mehr erfreuliche Überraschungen vor!

1.3.6 Hintergründe zu Linux Man sagt immer, Linux sei wie Unix. Ist das nun richtig oder falsch? Beides! Sind das nicht immer die besten Antworten? Die Geschichte von Unix begann in den sechziger Jahren. Mitte der 70er Jahre war aus Unix ein leistungsfähiges Multitasking-Betriebssystem für Minicomputer und Großrechner geworden. Obwohl sich Unix in verschiedene Richtungen durch verschiedene Herstellerinteressen entwickelte, war und ist Unix weltweit ausgesprochen beliebt. Seine Stabilität gilt als wichtigstes Qualitätskriterium. Als der PC entstand, war Unix auch schnell für diese Plattform verfügbar. Der Ihnen schon bekannte Linus Torvalds ärgerte sich 1991 über den hohen Preis von Unix, das er für seinen gerade frisch erstandenen PC einsetzen wollte. Also begann er, sein eigenes kleines Betriebssystem zu schreiben, indem er Unix „nachbaute“. Linux wurde zu einer eigenständigen und freien Re-Implementierung von Unix, enthält aber keinerlei Programmcode von UNIX! Entscheiden Sie nun bitte selbst, inwieweit Linux gleichbedeutend mit Unix ist.

1.4

Das Für und Wider von Open Source-Software

Für viele Entscheider sind Linux und die gesamte Open Source-Softwareentwicklung noch immer Bastelecken der modernen IT-Welt. Sollten Sie Projektleiter eines Linux-Projektes sein, so kann es Ihnen passieren, dass gerade Ihr Projekt dem einen oder anderen Machtfaktor im Unternehmen nur dazu dienen soll, zu beweisen, dass Open Source eben doch nur „Kinderkram“ ist und mit professioneller IT nichts zu tun hat. Anwender und Manager interessieren sich im Regelfall nicht besonders dafür, ob sie eine Software im Quelltext oder im Binärformat erhalten. Im Regelfall ist es erheblich interessanter, wie groß der Grad der Abhängigkeit von einem bestimmten Anbieter sein wird, wenn die Software in unternehmenskritischen Bereichen eingesetzt wird. Besonders wird es das Management interessieren, ob denn der Geschäftspartner auch weiterhin am Markt sein wird und wie man sich gegen einen plötzlichen Konkurs des Partners „absichern“ kann.

© Frank Obels


Seite 29


Seien Sie sich also bitte immer bewusst, dass es nicht damit getan ist, die Sachargumente bezüglich Open Source, so wie nachstehend, zu diskutieren. Sie sind dann ein erfolgreicher Projektleiter, wenn Sie mit den Sorgen Ihres Kunden umgehen können.

1.4.1 Vorteile von Open-Source Die Vorteile von Open Source-Software sind teilweise technischer Natur, teilweise beruhen sie auf den Grundprinzipien von Open Source. Höhere Qualität Mit seinem Essay „The Cathedral and the Bazaar“ hat Eric Raymond wesentlich dazu beigetragen, dass Open-Source-Software auch bei Nicht-Spezialisten als qualitativ sehr hochwertig gilt. Raymond begründet seine „Qualitätsbegeisterung“ mit einer Tatsache, die er „peer-review“ nennt. Danach ist es für ihn ein unschätzbarer Vorteil, dass Open-SourceProgramme anhand ihres Quellcodes von anderen Experten, überall auf der Welt, beurteilt werden können und auch werden. Diese kritischen Überprüfungen führen zum sehr schnellen Entdecken und Beseitigen etwaiger Fehler. Die Wahrscheinlichkeit, dass ein Fehler entdeckt wird, ist bei einigen Tausend Programmierern nun mal größer als bei einigen wenigen. Böse Zungen behaupten ja gar, dass bei manchem Betriebssystem ein Code-Review erst gar nicht statt findet und der Nutzer der Software als Testinstanz herangezogen wird. Da dies zumindest bei Open-Source-Software aus eben geschildertem Grund nicht der Fall ist, eignen sich diese Programme besonders für Infrastruktur- und Basisanwendungen wie Betriebssystemskern, Hardwaretreiber oder Netzwerkdienste.

Höhere Sicherheit Es ist sicherlich einleuchtend, dass das eben gezeigte peer review-Prinzip auch hinsichtlich der Sicherheit von Software einen gewaltigen Vorteil hat. Ernsthafte Sicherheitsüberprüfungen sollten sich gerade auch auf den Quellcode beziehen – und dort auf vorhandene Implementierungs- oder Algorithmenfehler. Die Tatsache, dass dies weltweit bei Open Source-Software möglich ist, führt dazu, dass führende Sicherheitsorganisationen Open-Source-Anwendungen als sehr sicher einzustufen. Die fehlende Einsichtnahmemöglichkeit bei vielen kommerziellen Betriebssystemen und Anwendungen gilt denn auch als größtes Sicherheitsrisiko, nach Ansicht der Experten.

Wiederverwendbarkeit Anhand eines vorliegenden Quellcodes lassen sich die Problemlösungsansätze nachvollziehen und man hat die Möglichkeit, aus dem Lösungsansatz zu lernen.

Seite 30


© Frank Obels


Dies führt dazu, dass man eine vorhandene und für gut befundene Lösung immer wieder verwenden wird und nicht „das Rad neu erfindet“. So können sehr schnell immer komplexere Softwaregebilde entstehen, da die Zahl der vorhandenen „guten“ Module ständig wächst. Wir sprechen, vielleicht ohne es zu realisieren, von dem menschlichen Innovationsprinzip und der Grundvoraussetzung technischen Fortschritts. Dann sollten wir auch festhalten, dass dieses Innovationsprinzip mit „geschlossener“ Software so nicht möglich ist.

Keine Exklusivrechte an einer Software Da Open Source-Software allen zur Verfügung steht, ist die Gefahr, dass einzelne Programmierer oder Unternehmen eine bestimmte Richtung in der Entwicklung vorgeben, minimiert. Die Kunden haben somit die Chance, ein Produkt zu erhalten, das bereits weitestgehend ihren Anforderungen entspricht.

Höhere Reife Ein wesentliches Erfolgskriterium für kommerzielle Produkte ist der richtige Moment der Markteinführung. Da bieten sich Messen an, Firmenjubiläen oder Ereignisse, die durch Mitbewerber vorgegeben wurden. Dieses „Marketing-Timing“ ist jedoch selten mit dem „Entwicklungs-Timing“ eines Produktes gleichlaufend. Dadurch, dass durch kurze Time-to-Market-Strategien immer häufiger „halbfertige“ Produkte an den Konsumenten herangetragen werden, entsteht ein kaum zu beziffernder ökonomischer Schaden, da die halbfertigen Produkte erhebliche Probleme beim Benutzer verursachen können (und dies leider auch häufig tun). Open Source-Software betrachtet die Qualität und Reife seiner Produkte als eine der wichtigsten Eigenschaften – und da man in erheblich geringerem Maße Marketinggesetzen zu folgen hat – verspricht die technische Orientierung einen erheblich höheren Reifegrad.

Keine oder geringe Lizenzkosten Gerade in der heutigen, wirtschaftlich etwas angespannten, Situation gilt das Kostenargument als eines der Zugpferde für Linux und den gesamten Open Source-Markt. Behörden und der gesamte öffentliche Dienst schätzen es in Zeiten knapper Budgets sehr, dass weder für das Betriebssystem noch für die vielen Anwendungen eine Lizenzgebühr erhoben wird. Selbst in nur mittleren IT-Umgebungen können die diesbezüglichen Einsparungen schnell die Millionengrenze überspringen.

© Frank Obels


Seite 31


Keine Lizenzierungssorgen mehr Ein Verstoß gegen die Lizenzverträge klassischer kommerzieller Software wird als kriminelle Handlung angesehen. Der administrative Aufwand, jedes Betriebssystem und jede Anwendungssoftware lizenzrechtlich einer „Buchführung“ zu unterziehen, ist hoch. Der Markt bietet seit geraumer Zeit spezielle Lizenz-Management-Programme, um dieser Datenflut und –pflege Herr zu werden – zu entsprechendem Preis. Die IT-Verantwortlichen unter Ihnen mögen auch das Problem kennen, dass Produktivsysteme plötzlich ausfallen zu scheinen – ohne technisch ersichtlichen Grund. Da mag es dann gewesen sein, dass ein Stückchen Software, in einer Situation hoher Systembelastung, aufgrund der bestehenden Lizenzsituation keine weiteren Verbindungen oder Transaktionen mehr zuließ, obwohl dies technisch ohne weiteres möglich gewesen wäre. Ich habe IT-Systeme erleben dürfen, die nur aus diesem Grund bis zu 2 Tage Stillstand vermeldeten, denn die Beschaffung neuer Lizenzen dauerte entsprechend lang. Hier greift ein ganz wesentlicher Vorteil von Linux – es kennt lizenzrechtlich keine Userzahlbegrenzung oder Restriktionen in der Anzahl realisierter Installationen. Ein unbestreitbares Plus, auch für die Verfügbarkeit von IT-Umgebungen.

Hohe Wartungsfreundlichkeit Die starke Netzwerk- und Internetorientierung von Linux macht es dem Administrator leicht, von anderen Rechnern, aus dem Internet oder sonst wo auf der Welt auf LinuxRechner zuzugreifen, diese zu administrieren und Software aufzuspielen oder Wartungsarbeiten durchzuführen. Vielfach können IT-Abteilungen diesbezüglich erheblich Personal einsparen. Da Linux nicht nur mit allen Kommunikationslösungen sondern auch mit vielen Sicherheitsmechanismen daher kommt, werden Wartungsarbeiten ausgelagert und von externen Firmen via Fernwartung übernommen. Übrigens müssen Sie nicht zusammenzucken, wenn Sie Fernwartung oder Wartung per Internet lesen: dank der Technologie SSH ist das Sicherheitsrisiko vergleichsweise gering.

1.4.2 Schwächen und Probleme Der größte Irrtum von Linux-Einsteigern besteht darin, dass sie erwarten, bei Open Source eine Anwendung in der gleichen optischen Ausstattung zu bekommen wie bei kommerzieller Software. Viele Open Source-Projekte legen mehr Wert auf Funktionalität als auf Ergonomie oder Handbuch. Insofern erscheinen Open Source-Anwendungen häufig als „Halbfertige Erzeugnisse“ in den Augen der Benutzer. Machen Sie sich dieses bitte klar, denn Sie werden in Ihrem Projekt darauf angesprochen werden.

Seite 32


© Frank Obels


Gewährleistung und Haftung Für Ihren Kunden und für Sie als Projektleiter ist die Gewährleistungsfrage sicherlich eine der wichtigsten. Und diese ist bei Open Source nicht befriedigend beantwortet. Zunächst gibt die General Public Licence (GPL) eine Antwort. Danach wird die Gewährleistung ausgeschlossen, die GPL enthält weiterhin den expliziten Hinweis: «Das volle Risiko bezüglich Qualität und Leistungsfähigkeit des Programms trägt der, der sie einsetzt.» Eine solche Aussage ist für jeden verantwortungsbewussten IT-Manager untragbar. Ich bin kein Rechtsanwalt, meine aber verstanden zu haben, dass nach deutschem Recht eine Haftungsverpflichtung dafür übernommen werden muss, dass eine Ware oder eine Dienstleistung ohne Mängel erbracht wird. Für Software hieße dies, dass das jeweilige Programm ordnungsgemäß funktionieren muss. Unterstellt man, dass das kostenlose Herunterladen aus dem Internet einer „Schenkung“ entspräche, so könnte man diesen Punkt als geklärt ansehen, denn diesbezüglich besteht eine Gewährleistung nur im Falle grob fahrlässigen Handelns. Wie verhält es sich aber, wenn ich bei einem Distributor wie SuSE oder Redhat die Software „gekauft“ habe – ist der GPL-Haftungsausschluss dann noch mit deutschem Recht vereinbar? Ich umgehe in meinen Linux-Projekten derartige Fragestellungen, indem ich mir einen Dritten suche, der die Haftung für Einzelprodukte übernimmt. Einen solchen Anbieter zu finden, ist zwischenzeitlich einigermaßen einfach zu bewerkstelligen. Zu schnelle Release-Zyklen bei Linux Das wohl größte Ärgernis für Linux-Kunden dürfte sein, dass Sie binnen kürzester Zeit Ihre mit Stolz erworbene Distribution verschrotten können, weil es eine neue gibt. Man muss ja nicht jeden Versionswechsel mitmachen, höre ich Sie sagen? Stimmt, allerdings aus meiner Sicht mit bestimmten Einschränkungen. Zum einen war es bisher so, dass einige Distributionen relativ schnell den Support für „alte“ Versionen eingestellt haben. Zum anderen gibt es Distributionen, die das „Mitmachen“ jedes Updates erfordern, sofern dieses Update denn hundertprozentig klappen soll. Beim Überspringen von Releases ist ansonsten viel manuelle Nacharbeit oder eine vollständige Neuinstallation erforderlich. Viel unnötiger und kostspieliger Administrationsaufwand für den Kunden. Der Kunde nimmt den Eindruck mit, dass es sich bei Linux um ein Softwarepaket handelt, das mit „heißer Nadel“ gestrickt wurde – anders kann sich dieser Kunde, der die Hintergründe nicht kennt, den schnellen Versionswechsel nicht erklären. Während eines Linux-Desktop-Projekts erlebte ich zwei Releasewechsel, die wir brav mitmachen mussten, denn schließlich sollte das Projektergebnis ja nicht mit dem Tag der Abgabe bereits völlig überholt sein.

© Frank Obels


Seite 33


Rechnen Sie bitte mit diesem Faktor in Ihrem Projekt, es erspart Ihnen viel Ärger und Zeitverlust. Dokumentation Viele kommerzielle Programme haben eine mehr oder weniger brauchbare Benutzeranleitung, häufig in gedruckter Form. Open Source Software kann und will diesbezüglich in vielen Fällen nicht mithalten. So ist der Quellcode teilweise sehr professionell dokumentiert, aber Handbücher dürfen sie nicht „automatisch“ erwarten. Viele Open Source-Projekte arbeiten an diesem Mangel, aber bitte vergessen Sie den Ursprungsgedanken der Open Source-Philosophie nicht: professionelle Software von Spezialisten für Spezialisten. Zu wenig professionelle Software Es ist fast unerheblich, welche Zeitschrift sie lesen, noch immer findet sich die Aussage, dass es in der Open Source-Welt und für Linux als Betriebssystem zu wenig professionelle Software gibt. Aus Sicht der Redakteure und vieler Anwender ist dies so – allerdings ist eine pauschale Aussage keineswegs seriös. Ich gehe in meiner Aussage so weit, dass ich behaupte, es gibt sogar zu viel Software aus dem Open Source-Umfeld – und niemand hat mehr den Überblick. Insofern ist für Sie als Projektleiter wichtig zu wissen, dass sich zu wenig professionelle Software auffinden lässt (gleichwohl gibt es sie). Eine Internetrecherche von einigen Tagen ist notwendig (aber ausgesprochen mühsam) oder das „Anheuern“ eines Open SourceSoftware-Scouts. Mangelnde Hardwareunterstützung Dieses Thema ist leider solange aktuell, solange die Open Source-Welt gezwungen ist, jeden Treiber für neue Hardware mühsam „nachzuprogrammieren“, da der Hardwarehersteller keinen technischen Einblick gewährt. Sie sollten in Ihrem Projekt vor allen Dingen bei sehr neuer PC-Hardware vorsichtig sein, da es hier einige Wochen dauern kann, bis die Linux-Gemeinde den entsprechenden Treiber fertiggestellt hat. Hilfe ist in Sicht, denn immer mehr Hardwarehersteller entwickeln endlich auch für Linux ihre Treiber.

Keine Ready-to-run Software Ich bin immer wieder begeistert, wie erfolgreich die großen Distributoren es schaffen, die Installation und Konfiguration eines Linux-Systems zu vereinfachen. Kennt man die unzähligen Möglichkeiten von Linux, dann weiß man diesen Aufwand und das bisher Erreichte zu würdigen.

Seite 34


© Frank Obels


Aus Anwendersicht aber stellt sich dies anders dar: Linux ist ein Betriebssystem, an das man Hand anlegen muss – und das will der Normal-Linux-User eigentlich nicht. Er möchte den Komfort eines proprietären Betriebssystems, und davon ist Linux im Desktopbereich noch immer weit entfernt. Möchten Sie eine Open Source-Software installieren, so kann es auch hier Schwierigkeiten geben, weil vielleicht die Rechte im Dateisystem nicht stimmen oder Bibliotheken fehlen. Auch hier sind die „Proprietärkollegen“ teilweise überlegen.

Keine Support-Eindeutigkeit Die zentrale Frage des Kunden beim Einsatz von Open Source-Software lautet: Wer bietet mir Support im Problemfalle? Im Falle des Betriebssystems Linux hat sich die Situation sehr verbessert, hier finden der Kunde und Sie, für Ihr Projekt, entsprechende Dienstleister. Wenn Sie beispielsweise eine, auf Open Source basierende, Finanzbuchhaltungssoftware einsetzen wollen, finden Sie im Idealfall ein Unternehmen, das Ihnen diesen Support anbietet. Ihr Management wird Sie aber fragen, warum es denn das hohe Risiko der Abhängigkeit von einem einzigen, noch dazu unbekannten, Anbieter eingehen soll. Und schon ist der Open Source-Gedanke aus Ihrem Unternehmen verbannt. Solange das Management keine „Partnerliste“ für Open Source-Software vorfindet, wird es kaum für „Experimente“ zu begeistern sein. Diesbezüglich muss noch ein völlig neuer Angebotsmarkt entstehen, der sich in die Sparten Beratung, Installation/Konfiguration, Wartung/Support, Schulungen und Individualanpassungen aufteilt. Richten Sie sich als Projektleiter auf derartige Fragen des Managements ein.

Beschaffung von Informationen Linux und Open Source fehlen zentrale Anlaufstellen, nennen wir sie Portale, wo Führungskräfte und Entscheider schnell kompetente Informationen erhalten, und wo der Kleinunternehmer mit einem Blick sieht, wie sein Problem bereits von anderen gelöst wurde. Technische Informationen sind bereits erheblich einfacher zu finden, auch in durchaus annehmbarer Qualität. Leider bestätigt dies aber die vorhandene Wahrnehmung, dass Linux wohl doch noch immer ein Bastlersystem ist, wenn nicht in gleicher Zahl Business Cases und Success Stories zur Verfügung stehen. Wirklich hilfreiche, für Entscheider aufbereitete Informationen, sind schwer zu finden. Also wird es sich das Management Ihres nächsten Projektes einfach machen und diese Informationen von Ihnen einfordern. Berücksichtigen Sie bitte auch diese Tatsache bei Ihrer Zeitplanung. Als Linux-Projektleiter werden Sie schnell in die Rolle eines Linux-Botschafters oder Linux-Anwalts gedrängt, der offene Fragen hinreichend zu beantworten hat.

© Frank Obels


Seite 35


Außenwirkung Es mag sein, dass ich an dieser Stelle der Linux-Gemeinde etwas wehtue. Nach meiner Wahrnehmung stellt das größte Problem von „Linux and friends“ die teilweise laienhafte Außendarstellung seiner „Vertreter“ dar. Schaut man sich an, wie professionell der Auftritt der mit kommerziellen Software-Industrie ist, so ist die Unsicherheit in den Unternehmen bezüglich des Einsatzes von Linux in einem professionellen Umfeld verständlich. Ausnahmen bestätigen zwar die Regel – aber es sind zu wenige Ausnahmen. Linux versteht es nicht, Verständnis für sein Konzept am Markt aufzubauen, die „LinuxVerbände“ sind mit sich selbst beschäftigt, eine Linux-Lobby ist nicht erkennbar und führende Linux-Propagandisten sucht man vergeblich. Der Kunde nimmt Linux nicht als eine Gesamtbewegung wahr, sondern als Spielwiese vieler Einzelkämpfer. Es bleibt für ihn zu hoffen, dass er auf den richtigen Einzelkämpfer setzt. Als Projektleiter haben Sie die Ehre, dass dieses „Image“ auf Sie übertragen wird und Ihre Aufgabe wird es sein, im Interesse Ihres Projektes, das Gegenteil zu „beweisen“. Und wiederum sollte Ihnen klar werden, wo die Schwierigkeit in einem Linux-Projekt liegt (gegenüber anderen IT-Projekten): Sie „kämpfen“ über die Maßen gegen psychoemotionale Faktoren.

Plötzliches Sterben eines Open Source-Projekts Wenn Sie voller Begeisterung die Homepage eines Open Source-Projektes besuchen, so kann es sein, dass diese seit Jahren nicht mehr aktualisiert wurde. Wenn Sie jetzt beginnen, sich ernsthaft Sorgen um die „Lebendigkeit“ dieses Projektes machen, so ist dies zumeist berechtigt. Überlastung des Projektleiters, Fortführung in anderen Projekten, keine Resonanz mehr aus dem Entwicklerkreis – die Liste der möglichen Gründe ist lang. Diese Unsicherheit im Open Source-Umfeld sollten Sie einkalkulieren. Wenn Sie die Software dennoch haben wollen, so steht sie Ihnen ja zur Verfügung. Jetzt müssen Sie nur noch auf die Suche gehen und sich ein Softwarehaus suchen, das Ihnen das Produkt auf Ihre Bedürfnisse hin weiterentwickelt.

1.4.3 Die Kosten von Open Source-Software Ist also nun Open Source das Kostenparadies für Unternehmen, das es rechtfertigt, alle Open Source-Schwächen zu übersehen und im Sinne der Gewinnmaximierung in jedem Falle „Linux and friends“ einzusetzen?

Seite 36


© Frank Obels


Anschaffungskosten Open Source bietet im Regelfall nicht zu bestreitende Kostenvorteile hinsichtlich der Beschaffungs- und Lizenzkosten, sowohl beim Betriebssystem Linux, als auch bei den entsprechenden Anwendungsprogrammen. Nun gesellen sich nach meiner Definition weitere Kostenbestandteile hinzu, die ich alle unter dem Begriff Anschaffungskosten sehe:  Beratungskosten (für Grundsatz- und Strategiefragen),  Planungs- und Entwicklungskosten,  Systemkosten (Hardwareanschaffungen, Softwareanpassungen, Datenmigration),  Systemeinführungskosten (Installation, Integration, Schulungen). Beratungskosten im Open Source-Umfeld schlagen mit ähnlichen Stunden- oder Tagessätzen zu Buche, wie im bisherigen kommerziellen Umfeld auch. Da Informationsbeschaffung und –bewertung im Open Source-Umfeld aufwendiger sind, sind auch die Kosten entsprechend höher. Planung und Entwicklung bezieht sich auf Fragestellungen, ob eine vorhandene Systemumgebung angepasst werden muss, neue Betriebs- und Testkonzepte zu erstellen sind oder eine eigene Entwicklungsumgebung aufgebaut werden sollte. Auch hier sehe ich, je nach Projektart, einen erheblichen Kostenfaktor. Bitte gehen Sie in einem Linux-Projekt niemals davon aus, dass Sie eine Produktionsumgebung ausschließlich mit Open Source-Software aufbauen können. Wenn es denn einmal so ist, beispielsweise in sehr homogenen Verwaltungsumgebungen, so freuen Sie sich über dieses Geschenk. Im Regelfall kommt es zu einem Mix aus Open Source-Anwendungen und kommerzieller Software, die unter Linux lauffähig ist. Und in diesem Fall erhöhen sich sowohl die Entwicklungs- als auch die Systemkosten erheblich. Anpassungen von Softwareschnittstellen, Erstellen von Treibern und die Erweiterung von Softwaremodulen stehen im Regelfall bei „gemischten“ Umgebungen immer an. Und obwohl Linux bezüglich seiner Hardwareansprüche als genügsam gilt, was ich übrigens im Desktopbereich nicht gelten lasse, müssen Sie sich damit beschäftigen, ob Kompatibilität und optimales Leistungsverhalten für die neue Umgebung gegeben sind. Auch den Systemeinführungsaufwand rechne ich heute den Anschaffungskosten zu, denn genau dieser Punkt wird liebend gerne vergessen. Insbesondere die Themen Schulung, Stichtagsumstellungen oder System-Parallelbetrieb lassen sich kostenmäßig teilweise schwer beziffern, was dazu führt, dass man sie bei der Kostenbetrachtung unter den Tisch fallen lässt. Tun Sie das bitte nicht – in Ihrem Interesse!

© Frank Obels


Seite 37


Betriebskosten Die Betriebskosten einer Open Source-Umgebung sind im Regelfall günstiger als bei den kommerziellen Kollegen. Insbesondere bezüglich Systembetreuung und Administration sowie dem großen Themenpunkt Wartung ergeben sich signifikante Vorteile. Diese lassen sich auf die hohe Stabilität und die enormen Möglichkeiten der Automatisierung zurückführen. Das größte Einsparungspotential liegt im Bereich der Wartung und Systempflege. Der Bereich der Systemerweiterungen ist so stark von den individuellen Gegebenheiten, wie beispielsweise dem Grad der Homogenität der IT, abhängig, dass eine diesbezüglich konkrete Aussage sehr schwammig ist. Durch die hohe Stabilität einer Open Source-Umgebung und das einfache Wiederherstellen im Absturzfalle werden die Personalkosten im IT-Bereich reduziert werden können, denn Sie kommen mit erheblich weniger „manpower“ aus.

Schulungen Diesbezüglich denke ich insbesondere an Anwenderschulungen im Umgang mit dem neuen System. Sie können diesen Punkt also streichen, wenn in Ihrem Projekt lediglich einige Server zu migrieren sind.

Meine Empfehlung Gerade bei der Kostenbetrachtung lautet meine eindeutige Empfehlung: holen Sie sich einen Berater ins Haus, der Ihnen die wirklichen Kosten einer Migration einmal detailliert ausrechnet. Ohne individuelles Rechnen lässt sich keine seriöse Aussage treffen. Die Investition in einen Berater lohnt sich alleine schon deshalb, weil Sie dann auch einmal sehen, was Ihre IT bisher gekostet hat – für manchen Manager, das erste Mal, dass er eine solche Aufstellung erhält.

1.5

Linux-Anmerkungen mit auf den Weg

Unsere Einführung in das Thema Open Source und Linux neigt sich dem Ende zu. Ab Kapitel 2 machen wir Ernst und gehen Schritt für Schritt die Linux-Projektwelt durch. Wie geht es Ihnen, nach dem bisher Gelesenen? Er- oder entmutigt? Nachfolgende Anmerkungen möchte ich Ihnen an dieser Stelle noch mitgeben.

Seite 38


© Frank Obels


1.5.1 Der Sprung ins kalte Wasser Es gibt keinen mir bekannten Lehrberuf Linux-Projektmanager und auch keine diesbezüglich einheitliche, tiefgehende Ausbildung. Sie werden also mehr oder minder vorbereitet (oder gänzlich unvorbereitet) zu Ihrem ersten Linux-Projekt kommen. Dieses „Hineinrutschen“ in eine teilweise neue Welt gleicht dem berühmten und viel zitierten Sprung ins kalte Wasser. Also springen Sie! Aus eigener Erfahrung weiß ich, dass es nur 2 Möglichkeiten für Sie gibt. Entweder Sie ertrinken (sofern Sie dieses Buch nicht gründlich gelesen haben und seine Ratschläge nicht befolgt haben) oder Sie lernen sehr schnell schwimmen (wobei Ihnen dieses Buch ja helfen will). Einen ersten Teil des speziellen Wissens, was Sie in einem Linux-Projekt erwarten kann, haben Sie bereits erfolgreich hinter sich gebracht. Im nachfolgenden Teil konzentrieren wir uns auf Linux und danach erleben Sie, wie klassisches Projektmanagement der Praxis aussehen kann. Und einen Teil der ganz großen Fallstricke finden Sie auf den nächsten 100 Seiten vermerkt. Vor allen Widrigkeiten dieser Welt können Sie sich ohnehin nicht schützen ;-) In einem Linux-Projekt Projekt läuft sehr viel (mehr als bei anderen Projekten) auf der unsichtbaren soziopsychologischen Ebene ab, die Sie nur mit viel Erfahrung brauchbar beeinflussen können.

© Frank Obels


Seite 39


2

Linux-Software für den Unternehmenseinsatz

Die Menschen sind sehr offen für neue Dinge - solange sie nur genau den alten gleichen. Charles F. Kettering

Sie werden sich in einem Linux-Projekt schwer tun, wenn Sie nicht wenigstens die gängigsten Anwendungsprogramme unter Linux kennen. Sie sollten ein Gefühl dafür bekommen, welche wichtigen Distributionen es gibt, welche typische Serversoftware im Augenblick im Gespräch ist und welche Programme auf dem Desktop zum Umstieg einladen.

2.1

Linux-Distributionen

Linux ist freie Software – und so gibt es keine Instanz oder Organisation, die für die Freigabe und Verteilung der Software verantwortlich zeichnet. Es steht jedermann frei, sich „seine“ Linux-Software zusammenzustellen und auch anschließend zu verteilen, solange die Vorgaben durch die GPL beachtet werden. Jene GPL erlaubt auch, für die „Mühe“ des Zusammenstellens und die anschließende Verteilung eine Gebühr zu verlangen. Eine Distribution bietet Ihnen zahlreiche zusammengestellte Tools, Anwendungen und ganze Softwarepakete rund um das eigentliche Linux, dem Kernel – und präsentiert auf mehreren CDs ein lauffähiges Betriebssystem. Bei den Großen der Branche gehören Handbücher und Installationssupport dazu, fast alle Applikationen stehen unter GPL oder verwandten Lizenzbestimmungen.

Seite 40


© Frank Obels


Die meiste Software, die Sie in einer Distribution vorfinden, könnten Sie sich auch kostenlos via Internet herunterladen und selbst installieren, den Linux-Kernel eingeschlossen. Dies erfordert allerdings Zeit und Linux-Know-how. Und genau an diesem Punkt setzen viele der großen Distributionen an. Mit Hilfe komfortabler Installationstools und vielen weiteren Hilfsprogrammen die Linux-Installation schneller, einfacher, übersichtlicher und reproduzierbarer. Die Haupteinnahmequellen der Distributoren stellen Support, Schulung und Individualanpassungen dar. Wenn Sie jemanden kennen, der bereits eine Linux-Version gekauft hat, so darf er diese kostenlos an Sie weitergeben. Wenn Sie Ihr ganzes Unternehmen mit Linux ausrüsten wollen, dürfen Sie dies mit einer einzigen Kopie tun. Aber Vorsicht, die Distributoren lassen sich immer wieder etwas einfallen, damit man sie nicht zu einfach umgehen kann. Wie oben bereits erwähnt, stehen die meisten Applikationen einer Distribution unter dem GPL-Dach. Leider eben nicht alle. Um sich mit ihrer Distribution von anderen zu unterscheiden, fügen die Distributoren gerne kommerzielle Pakete hinzu, die Sie wahrscheinlich nicht beliebig kopieren dürfen. Aber das würden Sie beim Installieren bemerken, denn es muss ein deutlicher Hinweis auf die kommerzielle Eigenschaft einer Software erfolgen. Es ist wichtig, sich sehr früh darüber Gedanken zu machen, welche Distribution geeignet ist, in einer Produktivumgebung zum Einsatz zu kommen und wie die politische und strategische Großwetterlage zu diesem Thema aussieht. Kriterien könnten beispielsweise Supportleistungen, Partnernetzwerke und Schulungsangebote oder auch die internationale Bedeutung für bestimmte kommerzielle Produkte, wie beispielsweise SAP, sein.

2.1.1 Die großen und bekannten Allround-Distributionen Die nachfolgend aufgeführten Distributionen kann man als Allzweckkönner bezeichnen, was insbesondere bedeutet, dass sie sowohl für den Serverbereich geeignet sind als auch für den Desktopseinsatz alles an Software mitbringen. Red Hat Linux Red Hat Linux von Red Hat, Inc. ist vielen Menschen durch den fulminanten Börsenstart von Red Hat ein Begriff geworden. Der weltweite Marktanteil soll bei über 50 Prozent liegen, in den USA gilt Red Hat als Quasi-Standard. In jedem Falle handelt es sich bei Red Hat um die kommerziell erfolgreichste Linux-Distribution. Die Red Hat LinuxBestandteile sind zum großen Teil kommerzieller Natur und unterliegen somit keiner GNU- oder Open Source Lizenz – dennoch pflegt Red Hat den Open Source-Aspekt von Linux im wesentlichen. Red Hat bietet einen ausgezeichneten Support und verfügt wohl die größte Systempartnerliste.

© Frank Obels


Seite 41


Sollten Ihr Projekt oder Ihr Kunde überwiegend international ausgerichtet sein, ist Red Hat eine gute Wahl. Mit einem eigenen Zertifizierungsstandard gewährt Red Hat auch in Deutschland eine recht ordentliche Ausbildungsqualität. Einen wichtigen Beitrag zur Linux-Entwicklung, über viele Distributionen hinweg, leistete Red Hat mit dem „RPM Package Manager“. Diese GPL lizenzierte Software dient der komfortablen Installation von Software unter Linux und wird von vielen anderen Distributionen eingesetzt. In der Zwischenzeit hat sich sogar eine recht bekannte Suchmaschine für RPM-Software im Internet etabliert (www.rpmseek.com). Red Hat Linux bereitet auch für den Linux-Einsteiger keine Probleme, das Installationstool Anaconda wird nach meiner Wahrnehmung allerdings von den Install-Programmen anderer Distributionen teilweise übertroffen. Aufgrund der Tatsache, dass Red Hat Linux „teil-kommerzialisiert“ ist, haben viele ITEntscheider das größte Vertrauen in diese Distribution. Dies sollten Sie für Ihr Projekt wissen. Red Hat Linux gibt es in verschiedenen Sprachen, auch in Deutsch.

SuSE Linux Bei SuSE Linux handelt es sich um eine deutsche Distribution, entsprechend groß ist der Verbreitungsgrad in Deutschland und auch Europa. Die Linux-Gemeinde lastet dem Distributor SuSE an, dass er in der Vergangenheit innerhalb einer SuSE-Distribution Veränderungen am Linux-Originalkernel vorgenommen hat. Dies führte dazu, dass Kernel-Updates oder das Einspielen eines neuen Kernels zum Problem wurden, da der veränderte SuSE-Kernel schon fast Proprietär-Charakter besaß. So musste man sich auf die von SuSE bereitgestellten Kernel beschränken, was nichts mehr mit dem Open Source-Gedanken zu tun hatte. In jüngerer Zeit hat sich dieses Problem entschärft, aber SuSE hat noch immer den Ruf, nicht Open Source-konform zu sein. So stehen Teile der Distribution nicht unter der GNU/GPL. Auch die Tatsache, dass sich SuSE-Linux aus mehreren verschiedenen Standardrichtungen innerhalb des Systems zusammensetzt, begeistert die Anwender nicht sonderlich. So folgt beispielsweise die Festplattenverwaltung einem gänzlich anderen Standard als die Systeminitialisierung. Dies führt dazu, dass ein Systemverwalter, der SuSE Linux beherrscht, nicht ohne weiteres mit den anderen Distributionen zurecht kommt. Ein solch kommerzielles und abgeschlossenes System (im Kompatibilitäts-Sinne) widerspricht dem Open Source-Gedanken und ist daher nicht gerne gesehen.

Seite 42


© Frank Obels


Für Ein- und Umsteiger gilt SuSE-Linux gleichwohl als das Idealsystem, gerade die Installation verläuft „spielend“ leicht. Leider wird bei SuSE eine derartige Vielzahl an Software installiert, dass das System reichlich überladen wird. Nur eine langwierige Software-Einzelauswahl lindert dieses Problem. Für viele deutsche Unternehmen ist SuSE-Linux die erste Wahl, man traut einem einheimischen Produkt und liest auch lieber deutschsprachige Handbücher. Da es obendrein kinderleicht zu installieren ist, werden Berührungsängste stark gelindert. Es mag gerade aus diesem Grunde für Ihr Projekt überlegenswert sein, zumindest eine Voruntersuchung mit SuSE-Linux durchzuführen. Bemerkenswert ist die im Internet zugängliche Wissensdatenbank von SuSE. Das gesamte Support- und Projekt-Know-how des Unternehmens ist in diesem Pool enthalten und leistet im Problemfalle wertvolle und schnelle Hilfe.

Debian/GNU Linux Es gibt zwei große Besonderheiten bei Debian/GNU Linux. Zunächst ist es die einzige der großen Linux-Distributionen, hinter der keine Firma steht. Dies sollten Sie als Projektleiter Ihrem Auftraggeber bitte auch sagen, denn gerade in diesem Punkt bestehen in Deutschland vielfältigste Ängste. Die zweite Besonderheit ist, dass Debian/GNU Linux für derzeit elf unterschiedliche Hardwarearchitekturen verfügbar ist. Debian kann den Linux-Kernel verwenden, es existieren aber auch für andere Kernel wie Hurd oder FreeBSD entsprechende Varianten. Das Debian- Projekt wird derzeit von etwas über eintausend Entwicklern weltweit unterstützt und gilt als Musterknabe des Open Source-Ansatzes. Eine „Kontaminierung“ durch unfreie Software ist strengstens untersagt. Anfänger werden aufgrund benötigter Hardware-Kenntnisse beim „Aufsetzen“ eines Debian/GNU-Systems stärker gefordert als bei anderen Distributionen.

Mandrake Linux Mandrake Linux stammt aus Frankreich und basierte ursprünglich auf Red Hat Linux. Heute handelt es sich um eine eigenständige Distribution, die als sehr benutzerfreundlich gilt. Mandrake Linux ist ein gutes Beispiel für die noch immer vorhandenen Vorbehalte gegenüber Linux hinsichtlich der wirtschaftlichen Stabilität. Der Anbieter MandrakeSoft musste zu Jahresbeginn 2003 Gläubigerschutz beantragen. Auch wenn die kritische Lage noch nicht ausgestanden ist – Mandrake Linux zählt unverändert zu den wichtigsten kommerziellen Distributionen.

© Frank Obels


Seite 43


SCO Group Linux (ehemals Caldera) Auch bei dieser Distribution gibt es spannendes zu beobachten. Die älteren Semester kennen diese Distribution unter dem Namen Caldera, eine der wenigen Überlebenden aus der Frühzeit von Linux. Diese Distribution galt lange Zeit als heimliches Ideal für den Desktop-Bereich. Die „kleine“ Firma Caldera übernahm im Jahr 2000 die „große“ Firma SCO, was für erhebliches Aufsehen in der Branche sorgte. Zwei Jahre später entschied man sich, den bekannteren Namen SCO wiederzubeleben und nannte sich fortan SCO Group und die Linux Distribution entsprechend SCO Group Linux. Die SCO Group machte von sich Reden, als man im Jahre 2003 IBM eine MilliardenKlage anhing, mit der Begründung, dass IBM im Rahmen seiner Linux-Initiative geistiges Eigentum der SCO Group gestohlen haben sollte. Die Branche reagierte empört und zweifelte an der Seriösität der SCO Group, insbesondere nachdem bekannt wurde, wie eng die finanziellen Verflechtungen zwischen Microsoft und SCO respektive ehemals Caldera waren und sind.

Slackware Linux Slackware Linux ist der „alte Herr“ der Linux-Distributionen. Software wird in „Rohform“ installiert (sogenannte Tarballs), Paketierungsmechanismen wie RPM gibt es nicht. Verwaltungs- und Konfigurationstools fehlen weitestgehend, Soft- und Hardware werden von Hand installiert und konfiguriert. Erfahrene Administratoren schätzen Slackware sehr, denn die Einfachheit bringt einen ganz entscheidenden Vorteil: das System ist enorm stabil und zuverlässig. Umkehrschluss: wenn Sie in Ihrem Projekt eine große, „teil-kommerzielle“ Distribution einsetzen und Sie in Ihrem Team „alte Linuxhasen“ haben, so werden diese bei jeder technischen Problemsituation zu berichten wissen, „dass das mit «Slack» nicht passiert wäre“.

2.1.2 Derivatdistributionen Gehen wir an den Anfang der Distributionen zurück, so gab es dort nur eine kleine Gruppe von Verfechtern unterschiedlicher Richtungen. Schaut man sich heute die gegen einhundert gehende Zahl von Distributionen und „Distributiönchen“ an, so ist klar, dass nicht jede eine eigenständige Entwicklung hinter sich hat. Vielmehr basieren viele kleinere Distributionen auf einer anderen und haben lediglich ihr Augenmerk auf etwas anderes gelegt als das „Original“. Die Abkömmlinge hier alle aufzuzählen, sehe ich als nicht sehr sinnvoll an.

Seite 44


© Frank Obels


Interessanterweise gibt es nahezu keine Derivate von SuSE Linux – Fachleute sehen dies in der GPL-feindlichen Lizenzpolitik von SuSE begründet.

2.1.3 Spezialdistributionen Spezialdistributionen sind auf eine einzige oder einige wenige Aufgaben hin optimiert worden und sind diesbezüglich anerkannt für höchsten Qualitätsanspruch. Sie eignen sich für andere Einsatzgebiete als die benannten praktisch kaum noch. In Ihrem Projekt kann es sehr interessant sein, sich bestimmter dieser Spezialdistributionen zu bedienen. Firewallsysteme, Terminalserver, Thin Clients oder Host-Services wären hier einige Stichworte. Ich möchte Ihnen nachstehend eine Auswahl der in der Linux-Praxis häufig eingesetzten Spezialdistributionen zeigen.

Linux Router Project (LRP) LRP ist eine sogenannte Mini-Distribution, die auf einer Standard-Diskette Platz findet. Mit LRP können Sie „alte“ PC-Hardware nutzen, um kostenlos, sehr leistungsfähige Netzwerkkomponenten aufzubauen. Klassische Einsatzgebiete sind die Verwendung als Router, Switch, RAS-/Radius-Server, DS1 WAN Router, Secondary Nameserver oder Firewall. In Zeiten knapper IT-Budgets nutzen insbesondere kleine und mittlere Unternehmen gerne diese Option, anstatt einige tausend Dollar für ein vergleichbares kommerzielles Gerät auszugeben.

Coyote Linux Ebenfalls sehr beliebt bei kleineren Unternehmen ist die „Coyote Linux floppy firewall“. In diesem Falle benötigt Ihr alter 486-Rechner nicht einmal eine Festplatte, alles geschieht von der Diskette aus. Coyote wendet sich an alle Anwender, die sich einen zentralen Internetzugang teilen wollen und dies bei höchster Leistungsfähigkeit und Sicherheit. Dabei werden sowohl Wählverbindungen wie auch DSL unterstützt.

Fli4L - the on(e)-disk-router Fli4l ist ein Linux-basierender ISDN-, DSL- und Ethernet-Router, der ebenfalls nur eine Diskette zum Arbeiten benötigt. Ein 486er mit 16MB RAM ist dafür ausreichend.

© Frank Obels


Seite 45


KNOPPIX KNOPPIX ist eine komplett von CD lauffähige Zusammenstellung von GNU/LinuxSoftware. Der große Vorteil dieser Distribution ist, dass Sie auf jedem beliebigen NichtLinux-Rechner „mal eben“ ein Linux-System vorführen können. KNOPPIX kann als Linux-Demo, Schulungs-CD, Rescue-System oder als Plattform für kommerzielle Software-Produktpräsentationen angepasst und eingesetzt werden. Es ist keinerlei Installation auf Festplatte notwendig und es ist sehr einfach, seine eigene Software auf eine eigene CD zu bringen – bis zu 2 Gigabyte lauffähige Software, laut KNOPPIX-Erfinder Klaus Knopper. Praxistip: Sie sollten als Projektverantwortlicher KNOPPIX in der Schublade haben. Wenn es nämlich darum geht, Hardwareverträglichkeit unter Linux zu testen, so ist die schnellste Variante für einen Ersteindruck, die KNOPPIX-CD einzulegen und die LinuxVerträglichkeit zu überprüfen. Das gilt sowohl für neue als auch für vorhandene Systeme.

MSC.Linux MSC.Linux ist eine speziell auf Cluster-Systeme ausgelegte Distribution. Neben der einfachen und schnellen Installation sind insbesondere die umfangreichen ClusterManagementtools erwähnenswert.

Weitere 200 Distributionen Schaut man sich unter http://www.linux.org/dist/list.html die dort hinterlegte Liste der bekannten Distributionen an, so liegt man ungefähr bei 190 Distributionen. Da ich einige weitere noch kenne, liegt die Zahl in jedem Falle über zweihundert. Das muss Sie nicht weiter beeindrucken. Es ist gut zu wissen, dass es für viele Spezialfälle eine auf diesen Spezialfall optimierte Distribution gibt und dass es sich lohnt, in einem Linux-Projekt einmal einen Tag mit „Distributionsrecherche“ zu verbringen. Sie finden spezielle Multimedia-Distributionen, viele Distributionen mit vorkonfigurierten Firewalls und Routern „out-of-the-box“, vorkonfigurierte Mail- und Workgroup-ServerDistributionen, Mini-Distributionen, Distributionen für Spielekonsolen, Distributionen für Linux-Cluster, echtzeitfähige Linux-Distributionen, Schuldistributionen und vieles mehr.

Seite 46


© Frank Obels


2.2

Open Source-Software für die Projektdurchführung

Zunächst einmal geht es in einem Linux-Projekt um die Frage, welche Software denn überhaupt für Linux zur Verfügung steht. Da vor jedem seriösen Projekteinstieg eine Machbarkeitsstudie stehen sollte, halte ich, aus meiner Erfahrung heraus, diese Frage für die wichtigste überhaupt. Dabei gilt es nicht zu klären, welche Office-Pakete es für Linux gibt oder ob es eine Groupware-Lösung unter Linux gibt. Derartige Themen fallen bei mir unter die „BanalAbteilung“, da auch jederzeit der einschlägigen Fachpresse zu entnehmen. Wie aber steht es mit „mission critical Anwendungen“, Finanzbuchhaltung, PPS-Software und den vielen anderen unternehmenswichtigen Applikationen? Es ist das Ziel der nachstehenden Kapitel, Ihnen einen Eindruck zu vermitteln, was heute mit Linux geht und was nicht. Dabei erheben die Ausführungen nicht den Anspruch, eine Machbarkeitsstudie darzustellen, vielmehr, einen Einstieg in das Thema zu ermöglichen. Aus der Praxis heraus stellt sich dann Frage, wie es um die Lizenzierung der Softwareangebote steht. Ist es GPL- oder Open-Source-Lizenz-Software oder eine echte kommerzielle Lösung oder einer der vielen Mittelwege? Wie steht es um den Support?

2.2.1 Eine neue Dienstleistung: Open Source Software Scout Sie finden in den nachstehenden Abschnitten wertvolle Hinweise auf Informationsquellen im Internet bezüglich Open Source Software. Die jüngsten Erfahrungswerte zeigen jedoch, dass viele Projektverantwortliche überfordert sind, sich durch die Vielzahl an Open Source Projekten durchzuhangeln, die Software herunterzuladen, zu installieren, zu testen, auf Stabilität hin zu beurteilen und schließlich für den Projekteinsatz für geeignet oder ungeeignet zu befinden. Clevere Unternehmer haben diesbezüglich eine Marktlücke erkannt und bieten ihre Erfahrung im Open Source Umfeld als Dienstleistung an. Als Projektleiter können Sie einem derartigen Berater Ihren Wunsch oder Ihr Problem schildern und dieser arbeitet für Sie innerhalb weniger Tage eine Übersicht geeigneter Software aus, stellt Ihnen diese Software in einem geschützten Bereich fertig installiert online zum Test zur Verfügung und gibt eine technische Beurteilung und unternehmerische Empfehlung zu den Produkten ab. Sofern Sie eines der Produkte einsetzen wollen, bietet der „Scout“ Ihnen einen entsprechenden Workshop an, der Sie mit allen Fragen des Praxiseinsatzes vertraut macht. Ich kann Ihnen die Inanspruchnahme einer solchen Dienstleistung sehr empfehlen, da Ihre technischen Projektspezialisten viel Zeit und Arbeit mit diesem Thema sparen.

© Frank Obels


Seite 47


Gerade das Online-Stellen einer lauffähigen Version, mit der Sie sofort loslegen können sowie der ausschließlich auf Ihr Projekt zugeschnittene Workshop machen diese Dienstleistung zu einer wertvollen Projektunterstützung. In Deutschland ist mir als Anbieter einer solchen Dienstleistung die Firma INCONET bekannt. Eine Internetrecherche wird sicherlich weitere Anbieter ergeben.

2.2.2 Freie Software zur internen Projektdurchführung Die erste Adresse, wenn es um einen Überblick in freier Software geht, stellt die Homepage von GNU selbst dar (www.gnu.org). Dort finden Sie eine derartige Vielzahl von Software, dass es Ihnen erst den Atem verschlägt und nach einiger Zeit dann die Lust am Suchen nimmt. Als wichtiges Auswahlkriterium dient mir in meinen Projekten stets das Vorhandensein einer guten Dokumentation. Bitte machen Sie sich an dieser Stelle noch einmal klar, dass wir davon reden, ein „Softwareprojekt“ in den Produktivbetrieb eines Unternehmens zu überführen. Um ein solches Vorhaben erfolgreich zu gestalten, ist die Dokumentation ein ganz wesentliches Element. Ich schlage Ihnen nunmehr vor, wir werfen einen Blick auf die Themenbereiche, Tools und Applikationen, die Sie im Rahmen Ihres Linux-Projektes sinnvoll einsetzen können, um sich das Leben erheblich zu erleichtern oder aber dem Auftraggeber und den vielen Stakeholdern ein mehr als gutes Gefühl bezüglich des Projektverlaufs zu geben. Ich war für Sie einmal als „Mini-Open-Source-Software-Scout“ tätig und habe, alphabetisch nach Bereichen sortiert, einmal eine kleine Open Source-Auswahl zusammengetragen.

Contentmanagementsysteme für das Projekt-Web Ich gelte als ein absoluter Verfechter von Projektöffentlichkeitsarbeit. Diesbezüglich gibt es bei mir kein Projekt, das ohne eine entsprechende Projektwebsite verläuft. Die Kunden sind begeistert und es bleibt die Frage, wie man eine solche Webseite einfach und effektiv gestaltet. Contentmanagementsysteme haben sich hier sehr bewährt. Diese kommen mit einem fertigen Seitenaufbau und vorgefertigten Modulen und Sie brauchen sich nur noch um den Inhalt zu kümmern. Ohne Fachkenntnisse, wie man Webseiten programmiert oder eine Datenbankanbindung vornimmt. In wenigen Stunden „steht“ somit Ihr Projekt-Intranet. Die meisten dieser Systeme benötigen eine Webserverumgebung mit PHP und der Datenbank MySQL. Dies sollten Sie sich auf einem separaten Server im Intranet einrichten lassen.

Seite 48


© Frank Obels


Die nachstehend genannten Produkte verfügen über die Mindestausstattung, die ich bei einem Contentmanagementsystem für den Projekteinsatz erwarte:         

Ankündigungen Online-Umfragen F.A.Q. (frequently asked questions) Bildergalerie Online-Formulargestalter Termin- und Ereigniskalender Adressenverwaltung Spracheinstellung Darstellung jeder Seite als Druckversion

Name

Beschreibung

phpWebSite Projekt der Appalachian State University und entwickelt sich, dank großer Entwicklerzahl, rasant. Die derzeit bestehende Version ist bereits sehr gut für ein Projektweb einsetzbar. OpenCMS ist in Java geschrieben und sicherlich eines der openCMS stärksten Tools am Markt. Jedoch ist Java ein Hindernis, wenn man doch einmal schnell im Quellcode etwas ändern möchte. mambo OS Sehr weit fortgeschrittenes System, dass neben der Vielzahl der Möglichkeiten durch eine sehr elegante Installationsroutine besticht. Der Benutzer kann sich selbst sein Seitenlayout wählen, was die Akzeptanz erheblich im Projekt erhöht. XOOPS kommt ebenfalls mit einer Installationshilfe daher und ist XOOPS sehr gut zu gebrauchen. Besonders hübsch ist die Verwaltungsfunktion projekteigener Besprechungsräume, auch wenn in der Praxis eher selten einsetzbar. Im Browser müssen Javascript und Cookies aktiviert sein, dies ist nicht in allen Unternehmen machbar. Es handelt sich hier um das vielleicht ausgereifteste Tool auf dem TYPO3 Open Source Markt. Die Content-Gestaltung erfolgt über einen leistungsstarken Rich Text Editor. Dies in einem Browser zu bewerkstelligen, gelingt aber derzeit nur dem Microsoft Internet Explorer. Daher ist das Produkt für ein Linux-Projekt weniger geeignet. Ebenfalls sehr ausgereiftes CMS, in einem Projekt gut zu PHPX verwenden ist das Ticketing-System, mit dem Aufgabenzuweisungen sehr schnell vorgenommen werden können.

Bewertung 100 % 100 % 120 %

100 %

70 %

100 %

Eine Besonderheit der Contentmanagementsysteme sind die sogenannten Nuke-Systeme. Diese eignen sich insbesondere dann, wenn Sie eher ein reinrassiges Informationsportal zur Projektöffentlichkeitsarbeit einsetzen möchten. Die berühmtesten Vertreter sind hier phpNuke und postNuke. Informationen zu den genannten Systemen finden Sie auf den Sourceforge-Internetseiten.

© Frank Obels


Seite 49


Groupware-Lösungen für das Projektteam Eine Groupware-Lösung für Ihr Projektteam sollte Ihnen die Zusammenarbeit und Aufgabenzuweisung so angenehm wie möglich machen. Auch hier möchte ich Ihnen wiederum sechs Vertreter vorstellen, die sich für den internen Einsatz in Ihrem Projekt bestens eignen. Name

Beschreibung

Bewertung

TUTOS

TUTOS steht für „The Ultimate Team Organisation Software“ und wird seinem namentlichen Anspruch auch hinreichend gerecht. Das Bug-Tracking-Modul lässt sich auch als Ticket-System missbrauchen. OpenGroupware war zunächst die Eigenentwicklung eines kleinen Internetproviders. Das war vor 7 Jahren. Seit einigen Monaten erst ist OpenGroupware „offen“. Der Funktionsumfang ist völlig ausreichend, das Produkt ist technisch ausgereift. Viele Add-ons (also Zusatzfunktionalitäten) sollen kostenpflichtig werden, was für Ihr Projekt nicht so schön ist. Sehr mächtiges und ausgereiftes System, das sich für den internen Projekteinsatz sehr gut eignet. Ein großer Funktionsumfang zeichnet dieses Produkt aus. Besonders hilfreich sind das Request-System, das ein normales Trouble-Ticket-System ersetzen kann und die Zeitkarte, mit der genau festgehalten werden kann, wie viel Zeit man mit einer Aufgabe verbracht hat. Dieses noch junge Projekt hat den Anspruch das Lotus Notes der Open Source-Welt zu werden. Für den internen Projekteinsatz bereits jetzt sehr gut geeignet. Ihre Teamkollegen werden sicherlich die länderspezifisch hinterlegten Ferienzeiten mögen. Im Erscheinungsbild etwas eigenwillig, ansonsten eine sehr gut zu verwendende Lösung. Für externe Projektleiter ist die Möglichkeit, die Kundenorganisation abzubilden, sehr wertvoll.

100 %

OpenGroupware

phpGroupware PHProjekt

Open Source Groupware

PHPCollab

90 %

110 % 100 %

100 %

100 %

Ticket-Systeme In einem Projekt gibt es eine Unmenge an Aufgaben zu bearbeiten, auf Anfragen der Fachabteilungen oder Hersteller zu reagieren oder interne Problemstellungen zu bewältigen. Deshalb sollten Sie sich als Projektleiter eine zentrale interne Sammelstelle für alle diese Fälle einrichten. An dieser zentralen Sammelstelle können Sie die Probleme lösen lassen, die diesbezüglichen Lösungsschritte dokumentieren und jederzeit nachvollziehen, den Zeitaufwand zur Problemlösung auswerten und sich so auch nebenbei ein kleines Expertensystem aufbauen. Das Schönste: auch für diese Aufgabe gibt es unter Open Source sehr leistungsfähige Software, von der ich Ihnen nachfolgend wieder einige vorstellen möchte.

Seite 50


© Frank Obels


Der Markt nennt diese Systeme Trouble Ticket Systeme (TTS). Alles, was an diese Sammelstelle herangetragen wird, egal ob telefonisch, per E-Mail oder Fax und schließlich auf Papier, wird in das System integriert und erhält eine Bearbeitungsnummer. Der Fall, der durch diese Bearbeitungsnummer repräsentiert wird, nennt sich ticket. Für die Detailinteressierten unter Ihnen sei auf RFC 1297 verwiesen. Name

Beschreibung

Bewertung

OTRS

Das Open Ticket Request System ist in der Praxis sehr bewährt. Wertvoll ist der Eskalationsmechanismus, der es erlaubt, projektkritische Vorfälle sehr professionell „weiterzukommunizieren“. Der Request Tracker nennt sich selbst führend im TTSSegment. Das seit 1996 bestehende Tool ist ausgereift, ohne Zweifel. Was für mich am Anfang sehr hilfreich war, ist die gute Dokumentation. Hier einmal eine weniger umfangreiche Software, die in kleineren Projekten aber durchaus ausreichend ist. Ich würde das System eher als eine Luxus-ToDo-Verwaltung bezeichnen. Schön ist die sehr einfache Installation. Dieses Produkt beeindruckt durch eine umfangreiche Ausstattung. Der Basisteil ist „frei“, spezielle Funktionen müssen gekauft werden. Wenn Sie es in Ihrem Projekt vollautomatisch mögen, dann schauen Sie sich das PagerGateway an, welches Ihnen prioritätengesteuert SMSNachrichten schickt. MyHelpDesk basiert auf OneOrZero, hat aber die Feature-Liste an vielen Stellen geändert. Es ist für den internen Projekteinsatz bestens geeignet, kommt aber ebenfalls nicht an OTRS und RT heran.

120 %

RT

PHP Ticket

OneOrZero Helpdesk

MyHelpDesk

110 %

70 %

100 %

90 %

Projektmanagement In der Open Source-Welt strengt man sich kräftig an, um den derzeitigen „Standard“ von Microsoft, MS-Project, wenigstens teilweise zu erreichen. Damit ist gesagt, dass dies bisher nicht erreicht wurde. Für mich ist in der Projektpraxis erschreckend, wie viele Menschen wie wenig von einer leistungsstarken Software wie MS-Project nutzen. Dies im Hinterkopf, gibt es im Open Source-Markt insbesondere eine Lösung, die in der Projektpraxis recht tauglich ist und obendrein dem Vorbild aus Redmond ein wenig ähnlich ist. MrProject eignet sich zur Projektplanung und zur Projektüberwachung recht gut. Auf der Homepage ist zu lesen, dass MrProject sich gegen verfügbare proprietäre Tools richtet. Insbesondere die Gantt-Darstellung wirkt professioneller als bei allen anderen mir bekannten Open Source-Ansätzen.

© Frank Obels


Seite 51


Dokumentationssystem DocBook Wie erstellt man am besten technische Dokumente, wie dokumentiert man am besten das Projekt? Ich habe lange Zeit mit den gängigen Textverarbeitungsprogrammen und Tabellenkalkulationen gearbeitet – das ist für den internen Gebrauch durchaus ausreichend. Heute jedoch bewegen wir uns zunehmend im Bereich des Online-Publishing und eine Online-Dokumentation ist dabei ebenso Standard wie das Konvertieren in zahlreichste Dokumentenformate. Bei DocBook handelt es sich um eine XML/SGML-Sprache, die geeignet ist, um verschiedenste Formen von Dokumenten zu erstellen, wie: Hilfesysteme, Webseiten, Bücher, FAQs, Fachartikel, technische Dokumentationen, Projektunterlagen, Gesprächsprotokolle, Bedienungsanleitungen und andere Dokumente. DocBook ist frei, plattformunabhängig und leicht zu erlernen. Dokumente, die mit DocBook erstellt wurden, können leicht in eine Vielzahl verschiedener Ausgabeformate umgewandelt werden, beispielsweise HTML Seiten, PDF und PostScript Dokumente, Windows- und Java-Hilfen oder RTF-Dateien. Für die Umwandlungsarbeit sind viele kostenlose Programme verfügbar. Das Internet ist voll von guten Anleitungen, wie man mit DocBook am produktivsten arbeitet. Wer es gerne ein wenig „fauler“ mag, der startet mit OpenOffice. Dieses ist von Hause aus XML-basierend und erlaubt, mit Hilfe eines kleinen Templates, XML-Output bequem zu produzieren, der dann nach Belieben weiter verarbeitet werden kann. XML ist in großen Unternehmen bereits der vorherrschende Dokumentationsstandard.

2.2.3 Der Open Source Software-Auswahl-Prozess Wenn Sie in Ihrem Team einen „internen“ Open Source Software-Scout“ benennen und auf die „Jagd“ schicken wollen, dann möchte ich Ihnen einige Empfehlungen mit auf den Weg geben. Wenn Sie an den zentralen Open Source-Quellen freashmeat.net oder sourceforge.net angekommen sind, werden Sie feststellen, dass es für nahezu jeden Bereich eine große Auswahl an Software gibt. Sie können entweder Monate damit verbringen, jede Software für Ihre Zwecke zu testen oder auf gewisse Indikatoren achten: Popularität Die Popularität gibt Ihnen Auskunft über den „Beliebtheitsgrad“ der Software. Achten Sie zunächst auf die Zahl der Downloads, diese sollte hoch sein. Diejenigen, die diese Software getestet haben, bewerten das Programm anschließend. Daraus resultiert die Popularität, für Sie ein erster Orientierungspunkt.

Seite 52


© Frank Obels


Vitalität Die Vitalität zeigt Ihnen, wie erfolgreich die Software über einen längeren Zeitraum war und wie das diesbezügliche Potential für die Zukunft eingeschätzt wird. Eine Anwendung, die seit einem längeren Zeitraum existiert und regelmäßig mit Updates versehen wurde, erfüllt mit hoher Wahrscheinlichkeit die Voraussetzungen für den professionellen Unternehmenseinsatz. Im übrigen hat eine vitale Software den Vorteil, dass die „Kinderkrankheiten“ der Software überwunden sein dürften. Online-Demo Eine weit vorangeschrittene Software bietet häufig die Möglichkeit einer OnlineTestumgebung. So können Sie sehr schnell einen Eindruck gewinnen, ob Ihnen die Software bezüglich Handhabung und Funktionsumfang so sehr gefällt, dass Sie sie in die engere Auswahl nehmen können.

Referenzen Ist eine Software sehr weit ausgereift, werden Sie Websites oder Unternehmen benannt finden, die diese Software erfolgreich einsetzen. Achten Sie dabei darauf, ob diese Unternehmen vielleicht aus Ihrer Branche kommen oder rufen Sie dort einfach mal an. Open Source-Menschen sprechen gerne miteinander, Sie brauchen einen freundlichen Anruf also nicht zu scheuen.

2.2.4 ASP-Lösungen für das Projekt Je nach Projektart kann es Ihnen passieren, dass Sie bestens mit Open Source-Software für die Projektarbeit vorort ausgerüstet sind. Und wenn Sie mal aus der Ferne auf diese Ressourcen zugreifen möchten oder müssen? Dann beginnen im Regelfall eine Menge Menschen die Frage nach der Zugriffssicherheit zu stellen und es mag sein, dass dieses Thema sich in Ihrem Unternehmen nicht ohne weiteres realisieren lässt. Dann ist es gut zu wissen, dass es im Internet hilfreiche Anwendungen gibt, wo Sie eine Kopie Ihrer Projektdaten lagern können, um jederzeit und von überall her Zugriff auf diese zu haben. Die ASP-Lösungen (Application Service Providing) sind eine feine Sache, sofern man dem ASP-Anbieter nicht misstraut. Es sollte also zumindest kein Mitbewerber Ihres Unternehmens sein.

© Frank Obels


Seite 53


2.3

Open Source Alternativen zu kommerziellen Applikationen

In Zeiten von Kostendruck und wirtschaftlichen Herausforderungen haben sich Manager und Unternehmer sicherlich schon des öfteren bei dem Gedanken erwischt, mit Open Source Software zu liebäugeln. «Die Botschaft hör ich wohl – allein mir fehlt der Glaube» umschreibt die derzeitige Situation, nach meiner Wahrnehmung, sicherlich treffend. Unbeantwortet im Raum steht das „WIE?“ – und um diese Frage zu beantworten, setzt man einen, häufig externen, Projektleiter und Berater ein. Sollte dieser Auserwählte dann keinerlei Linux-Erfahrung haben, so wird sein Job sicherlich alles andere als lustig sein. Dabei spreche ich noch gar nicht von den generellen Symptomen eines Projektmanagers, die sich bei dem Gedanken an unhaltbare Termine und lächerlich geringen Budgets so einstellen. Ich halte es deshalb für hilfreich, dass wir uns ganz kurz einmal einige Softwarevertreter aus den wichtigen Unternehmensbereichen anschauen. Diesbezüglich kommen nun auch einmal die kleineren und mittleren Unternehmen in den Genuss einer „Linux-Aussage“. Viele Programme erheben den Anspruch sogenannter integrierter Anwendungen und lassen sich schlecht sinnvoll kategorisieren.

2.3.1 Finanzbuchhaltung für kleine Unternehmen Gerade für kleinere Unternehmen ist dieses Thema schwierig. Die kommerziellen Lösungen sind häufig unzureichend, was die Anpassungsfähigkeit an die Individualbedürfnisse eines mittelständischen Unternehmens anbelangt.

Calamar Ich setze bei vielen Kunden recht erfolgreich das Programm Calamar ein. Es enthält die wesentlichen Funktionen einer ordentlichen Finanzbuchhaltung. Mandantenfähigkeit, Benutzerverwaltung, Passwortschutz, Mehrzeilenbuchungen, automatische Mehrwertsteuerabrechnung, Kostenstellensystematik sowie eine flexible Auswertung für Bilanz und Gewinn- und Verlustrechnung bietet Calamar in der aktuellen Version. Calamar ist in Java realisiert, was eine Hürde bezüglich der einfachen Anpassungsfähigkeit setzt. Dafür glänzt es mit weitestgehender Plattformunabhängigkeit. Das Produkt ist in Deutsch erhältlich, allerdings seit Sommer 2002 nicht wesentlich weiterentwickelt.

Seite 54


© Frank Obels


GnuCash GnuCash stammt aus dem Bereich der Finanzverwaltung im Privatleben und hat sich inzwischen zu einem Finanzbuchhaltungspaket für kleine Unternehmen gemausert. GnuCash ist in C geschrieben und das Projekt ist seit Anbeginn sehr aktiv. Es liegt in Deutsch vor.

SQL Ledger SQL-Ledger ist ein System für Auftragsabwicklung, Finanzbuchhaltung und Lagerverwaltung. Bestechend an diesem Programm ist die Einfachheit der Bedienung. Eine sehr gute Schnittstellendokumentation erleichtert die individuelle Anpassung an die Unternehmensgegebenheiten. SQL Ledger ist in einigen deutschen Unternehmen erfolgreich im Einsatz.

Tudo Tudo (ehemals Qttudo) ist ein seit 1997 bestehendes Projekt mit einer ausgereiften Finanzbuchhaltung. Darüber hinaus möchte ich Tudo bereits als Warenwirtschaftssystem bezeichnen. Das deutsche Produkt deckt die Bedürfnisse eines kleinen und auch größeren mittelständischen Unternehmens vollständig ab.

2.3.2 Customer Relationship Management Customer Relationship Management ist das Modewort momentan in der Marketing-Welt. Wann immer wirtschaftlich schwierige Zeiten herrschen, wird die Bedeutung des Kunden „wiederentdeckt“ und entsprechende Tools zum optimalen Kundenumgang propagiert. Kommerzielle Ansätze sind viele auf dem Markt zu finden, auch für Linux. Ein kleines mittelständisches Unternehmen wird angesichts der durchweg hohen Preise aber sicherlich dankbar sein, wenn es im Open Source-Umfeld eine „freie“ Variante fände. EdenCRM EdenCRM bietet die grundlegenden Funktionen für ein Kundenmanagement und eignet sich daher zumindest als Einstiegslösung, um dann später zu entscheiden, auf eine komplexe Lösung, wie das später vorgestellte Compiere, umzusteigen. Mit EdenCRM lassen sich Kundenanfragen vernünftig dokumentieren und einfach beantworten.

© Frank Obels


Seite 55


Weiterhin sind eine ordentliche Stammdatenpflege, eine Kundenprofilanalyse, ein Kundenbindungsprogramm, eine Schnittstelle zur Call-Center-Unterstützung sowie mobiles und stationäres Vertriebsmanagement integriert. In einem CRM-Großprojekt eignet sich EdenCRM sehr gut zur Grundlagenschulung in Sachen Prozesse im Customer Relationship Management.

2.3.3 Enterprise Resource Planning

Compiere Compiere nennt sich selbst die Nummer 1 der Open Source ERP- und CRM-Software. Gemessen an der Anzahl der Downloads ist Compiere eines der erfolgreichsten Projekte im Bereich Open Source. Der Ansatz ist professionell, die Ausstattungsliste ist beeindruckend. Es handelt sich um ein hoch integriertes System, das alle Aspekte betriebswirtschaftlicher Software unter einer Oberfläche enthält. Der Initiator des Projektes Compiere, Jörg Janke, blickt auf einige Erfahrung bei SAP, Oracle und Unisys zurück. Dies wissend verwundert es nicht, dass ein Unternehmen, dass Compiere einsetzen will, sich an die Software anpassen muss und nicht umgekehrt. Compiere „denkt“ in strikten Geschäftsprozessen. Sieht die Organisation des Kunden diesbezüglich anders aus, so kann sich dieser Kunde vom bisherigen Organisationsmodell seines Unternehmens verabschieden. Doch wie wir dies seit Jahren aus dem SAP-Umfeld her erleben, ist dies kein wirkliches Problem. Compiere stellt hohe Systemanforderungen, sowohl serverseitig als auch an den Client. Hier ist neben Java insbesondere die erforderliche Oracle-Datenbank zu erwähnen. Weiterhin stellt Compiere hohe Anforderungen an Benutzer und Berater. Das System ist derart komplex, dass Support und Training einen besonderen Stellenwert einnehmen. Ich vermute diesbezüglich ein rundherum wohlüberlegtes Geschäftsmodell. Um es zusammenzufassen: Wer "eben mal schnell" eine Finanzbuchhaltung oder betriebswirtschaftliche Standard-Software braucht, für den ist Compiere sicher nicht die richtige Wahl. Interessant wird das System, wenn ohnehin an eine Restrukturierung des Unternehmens gedacht ist, wenn ein hoch komplexes und dynamisches Netz aus Kunden, Lieferanten und Partnern besteht oder auch bei Neugründungen mit anfänglich hohem Expansionsbestreben. Zudem ist eine nicht zu geringe Java-Kompetenz im Unternehmen geradezu ein Muss.

Seite 56


© Frank Obels


2.4

Software für den Server

Wenn sich auch viele IT-Verantwortliche daran gewöhnt haben, in den Fesseln eines Quasi-Monopolisten und seiner Lizenzpolitik zu leben, so scheint im Bereich der Mailund Groupware-Server ein gewisses Erwachen stattzufinden. In anderen Bereichen gab es sogar echten Wettbewerb, wie am Beispiel der Webserver zu beobachten ist.

2.4.1 Konkurrenz für den Microsoft Exchange Server Eigentlich war es längst überfällig, doch erst in der jüngeren Vergangenheit kommen ernstzunehmende Konkurrenten für den Microsoft Exchange Server auf den Markt. Dabei sind doch gerade Mail und Kommunikation eine Linux-Domäne. Für viele Microsoft-Kunden steht in der nächsten Zeit ein Wechsel von Microsoft Exchange 5.5 auf entweder das Nachfolgeprodukt Microsoft Exchange 2000 oder eine entsprechende Alternative an. Sollte Ihr nächstes Projekt in diesem Bereich liegen, so erhalten Sie nachstehend einen kleinen Überblick. SuSE Linux Open Exchange Server (SLOX) Der Distributor SuSE hat mit seinem Open Exchange Server ein Produkt geschaffen, das es erlaubt, bestehende Microsoft Exchange-Server auf Linux zu migrieren und dabei die Programme auf dem Desktop, wie etwa Microsoft Outlook weiterverwenden zu können. Das ist eine feine Sache für die Unternehmen, die sich schrittweise mit Linux anfreunden wollen und dem Benutzer einen „Umstieg“ für den Moment ersparen wollen. Apropos sparen: Microsoft verwendet zur Berechnung der Lizenzgebühren die Anzahl der eingerichteten Postfächer auf dem Server, SuSE dagegen die Zahl der gleichzeitig angemeldeten Benutzer. Bei SLOX ist „natürlich“ das Betriebssystem (Linux) im Paket enthalten, bei Microsoft Exchange „natürlich“ nicht. Der Funktionsumfang in punkto täglicher Gebrauch ist als gleichwertig anzusehen, eine Datenübernahme der Mails, Kontakte, Aufgaben und Termine ist kein Problem. Sie können davon ausgehen, dass eine Migration in einigen Tagen (je nach Anzahl der Server) erfolgreich erledigt ist. SLOX verfügt über eine sehr schöne Webmail- und Groupware-Komponente mit entsprechenden Frontends. Allerdings handelt es sich dabei um sogenannten Closed Source, insofern hat der Begriffsbestandteil Open im Produktnamen hier sicherlich nichts mit Open Source zu tun.

© Frank Obels


Seite 57


Samsung Contact Server Der Samsung Contact Server wurde von Samsung weiterentwickelt und stellt eine neue Generation der Openmail-Technologie dar. Somit hat der Samsung Contact Server eine makellose Vergangenheit, denn bei OpenMail handelt es sich um eine E-Mail- und Kommunikationslösung von Hewlett-Packard, die insbesondere bei Großunternehmen im Einsatz war. Bynari Insight Server Der Insight Server steht in einer kleineren Standard Edition und einer großen EnterpriseVariante zur Verfügung. Auch wenn ich nicht mit der Firma Bynari persönlich gesprochen habe, so unterstelle ich, dass der Insight Server ebenfalls „mental“ die Ablösung einer vorhandenen Microsoft Exchange-Umgebung vorsieht. Der Insight-Server ist jedoch in der Lage, als Erweiterung bestehender ExchangeInfrastrukturen zu fungieren. Einige meiner Kollegen haben diesbezüglich nur Gutes zu berichten.

2.4.2 Webserver Die nachfolgende Adresse sollten Sie kennen, wenn Sie bei der Thematik Webserver wirklich mitreden wollen: http://www.netcraft.com/Survey/. Die nachstehende Grafik ist der genannten Adresse entnommen und zeigt Ihnen auf einen Blick die Verteilung aller öffentlich erreichbaren Webserver auf die verschiedenen Anbieter.

Seite 58


© Frank Obels


Abbildung 1: Öffentlich erreichbare Webserver nach Marktanteilen

Apache Webserver Aus der Grafik ist klar erkennbar, dass Apache der derzeit am weitesten verbreitete Webserver ist. Apache ist obendrein wohl eines der erfolgreichsten „freien“ SoftwareProjekte. Wenn Sie also vor die Frage des „richtigen“ Intranet- oder Internetservers gestellt werden, haben Sie nun zumindest die Nummer 1 kennengelernt. Interessant ist dabei, dass der Erfolg von Apache auf ganz leisen Sohlen daherkam. Es waren nicht die großen Schlagzeilen, sondern einfache Mund-zu-Mund-Propaganda über das Internet, die Apache zu diesem Erfolg verhalfen. Dabei darf nicht unerwähnt bleiben, dass sich Apache durch zwei Eigenschaften auszeichnet: zum einen durch eine beeindruckende Stabilität, zum anderen durch die schnelle Umsetzung der Benutzerwünsche. So einfach kann also Erfolg sein! Sie haben mit dem Beispiel Apache nun auch eine sehr wirkungsvolle Argumentation, falls Sie gebeten werden, doch wenigstens ein Open Source-Projekt von erheblicher Bedeutung zu benennen.

© Frank Obels


Seite 59


2.4.3 Datenbankserver Der Einsatz von Linux als Datenbankserver ist eine der am häufigsten genutzten Anwendungen in der Unternehmenspraxis. Praktisch alle kommerziellen Datenbanken sind für Linux verfügbar, die freien Datenbanken ohnehin. Das berühmteste Open Source-Datenbankprojekt ist MySQL. Bisher wurde es überwiegend in Verbindung mit dynamischen Webseiten und den entsprechenden Script-Sprachen wie PHP verwendet. MySQL ist aber dabei, sich zu einer umfassenden relationalen Datenbank zu mausern, ohne dabei seine bekannte Stabilität zu verlieren. Dies hat auch das Softwarehaus SAP erkannt und ist mit MySQL eine strategische Partnerschaft eingegangen.

2.4.4 Samba-Server Mit dem Thema Samba kommen Sie in Berührung, wenn Ihr Kunde in ein bestehendes Linux-Netzwerk Rechner mit dem Betriebssystem Microsoft Windows integrieren möchte. Dann stellt sich die Frage, wie Sie die beiden wichtigsten Dienste, den Datei- und DruckService diesen Windows-Rechnern zur Verfügung stellen. Technisch gesehen, gibt es diesbezüglich mehrere Lösungen, doch praktisch, im Sinne der Benutzerakzeptanz, bleibt nur die Samba-Lösung. Unter Windows erlaubt der Dateiservice das Ablegen meiner Daten auf einem anderen Rechner, im Regelfall einem Server, über sogenannte Netzwerklaufwerke oder „Shares“. Andere können auf diese Laufwerke zugreifen. Technisch gesehen bedarf es dazu des SMB-Protokolls. Stellen Sie sich das als Nichttechniker einfach als eine Abmachung, wer sich wie zu verhalten hat, vor. Der Windows NT-Server macht den Rest. Das Open Source-Paket Samba stellt nun den Windows-Rechnern einfach dieses Protokoll und somit die Datei- und Druckdienste zur Verfügung. Für einen Windows-Client verhält sich ein Linux-Server, auf dem Samba läuft, wie ein Windows NT-Server und ist auch in der Lage, die zentrale Benutzeranmeldung innerhalb der sogenannten „Domänen“ zu übernehmen. Diesbezüglich muss er nur als Domain-Controller fungieren. Der Samba-Server stellt dem Windows-Client auch die gewohnten Drucker zur Verfügung, einschließlich Netzwerkfunktionalität. Die Konfiguration eines Samba-Servers ist für einen guten Administrator kein Problem und somit ist das Ablösen des Microsoft Primary Domain Controllers unproblematisch. Aber ich möchte an dieser Stelle noch einmal betonen, dass um Themen wie Serverablösungen „Glaubenskriege“ geführt werden. Sie werden es sich in Ihrem Projekt nicht so einfach machen können, wie ich mit diesem Buch. Ich kann hier einfach etwas erzählen und bekomme wesentliche Kritik- und Unmutsäußerungen vielleicht nicht einmal mit, Sie in Ihrem Projekt werden es da wahrscheinlich schwerer haben.

Seite 60


© Frank Obels


2.4.5 Sonstige Server-Software Damit bei dem Wort Linux-Server keine Missverständnisse entstehen, möchte ich an dieser Stelle anmerken, dass der Begriff Server als Software und nicht als Hardware zu verstehen ist. Es ist also nicht notwendig, für jedes Serverprogramm eine eigene Serverhardware vorzusehen. Das ist ja das Schöne, was viele IT-Menschen so an Linux mögen. Nameserver Das Domain Name System (DNS) ermöglicht die Übersetzung der numerischen Rechneradressen in sprechende Namen, so dass Sie www.bundeskanzler.de eingeben können, ohne die Rechneradresse des Bundeskanzleramts zu kennen. Das Programm „bind“ ist der am häufigsten eingesetzte DNS-Server unter Linux. Da auch für die Namensauflösung in einem Intranet ein DNS-Server benötigt wird, mag es sein, dass Sie ihn in Ihrem Linux-Projekt kennenlernen werden. Gateways und Router Die guten Netzwerkeigenschaften von Linux haben dazu geführt, dass viele Kunden Internetgateways oder Router unter Linux realisiert haben. Selbst kleine Firmen nutzen heute problemlos einen Linux-Rechner als ISDN- oder DSL-Server. Firewall Sicherheitslösungen unter Linux sind sehr beliebt. Wie Sie bereits erfahren haben, gibt es diesbezüglich spezielle Distributionen, die für die spezielle Aufgabe optimiert wurden. Neben der klassischen Firewall finden sich in den Unternehmen VPN-Lösungen unter Linux. Remote Access-Server Die Remote Einwahl ins Unternehmensnetz ist ebenso umstritten wie beliebt, heute insbesondere per PDA oder Handy. Der Microsoft RAS-Server ist in vielen Unternehmen vorherrschend. Im Zuge eines neuen Linux-Bewusstseins stellen immer mehr Kunden die Anforderung, die bestehende Microsoft-Lösung durch Linux zu ersetzen. Unter Linux stehen diesbezüglich leistungsstarke und sichere Produkte zur Verfügung. Novell-Server Linux bietet die Möglichkeit einen Novell-Server zu emulieren oder mit bestehenden Novell-Netware-Servern „zusammenzuarbeiten“.

© Frank Obels


Seite 61


LDAP-Server LDAP ermöglicht das unternehmensweite Bereitstellen von Verzeichnisdiensten. Da LDAP auch den Active-Directory-Dienst von Microsoft emulieren kann, lassen sich mit LDAP „plattformübergreifend“ zentrale Adressverzeichnisse aufbauen, auf die mit den verschiedensten Clients zugegriffen werden kann.

2.5

Software für den Desktop

Die nachfolgend präsentierte Softwareübersicht möchte Ihnen einen Eindruck vermitteln, ob das Thema Linux-Desktop bereits professionellen Ansprüchen genügt. Laut einer Studie der Berliner relevantive AG ist Linux auch im Desktopbereich „konkurrenzfähig“. Nicht alle am Markt befindlichen Lösungen wurden aufgeführt, sondern nur diejenigen, bei denen ich ein Quäntchen Erfahrung sammeln durfte.

2.5.1 SuSE Linux Desktop-Produkte Der deutsche Distributor SuSE Linux AG bietet zwei Paketlösungen, die ich mit Ihnen als erstes anschauen möchte. Ziel beider Produkte ist es, dem Umstiegswilligen die „easy-touse“ Software anzubieten. Unter dem Begriff Umstieg versteht SuSE auch die Möglichkeit der Weiternutzung bisheriger Microsoft Office-Programme. SuSE Linux Office Desktop Der SuSE Linux Office Desktop (SLOD) wurde auf kleinere Unternehmen und Privatanwender ausgerichtet, die auch ohne Vorkenntnisse auf Linux umzusteigen in der Lage sein sollten. Die vertraute Windows-Anwendung sollte dabei auch mit Linux weitergenutzt werden können. Um dies zu erreichen, hat SuSE eine ganz normale Distribution um 2 kommerzielle Softwareprodukte erweitert, die die typischen Probleme des „Umsteigers“ beheben sollen. Da wäre zum einen die Herausforderung, auf einem PC mit vorinstalliertem Betriebssystem, die Festplatte so aufzuteilen, dass für Linux ein freies Plätzchen entsteht, ohne dem bereits installierten Betriebssystem zu nahe zu treten. Das diesbezügliche Stichwort: Verkleinerung von Partitionen. Und zum anderen benötigt man ein Produkt, das es ermöglicht unter Linux eine Microsoft Windows Welt laufen zu lassen.

Seite 62


© Frank Obels


Der Acronis OS Selector ermöglicht die Repartitionierung bestehender FAT- und NTFSFilesysteme, um Platz für Linux zu schaffen. Die Ausführung von Windows-Binaries übernimmt die Software Crossover Office. Für den Projekteinsatz bin ich mit dieser Software nicht glücklich, denn Sie hält nicht das, was sie dem unbedarften Anwender verspricht. Denn wieder einmal stellt sich ein typischer Windows-Nutzer offensichtlich etwas anderes vor als der Distributor SuSE. Zuerst einmal realisiert der Anwender gar nicht, dass es sich um eine klassische Distribution handelt, die lediglich minimal erweitert wurde. Dies weckt eine Hoffnung, die Sie als Projektleiter gegebenenfalls „ausbaden“ müssen. In einem Migrationsprojekt stellt sich die Frage, ob es Sinn macht, neben Windows noch Linux (oder umgekehrt) zu installieren. Denn nur zu diesem Zweck dient der Acronis OS Selector. Psychologisch halte ich dies für ein Linux-Projekt für keinen guten Ansatz. Eine vollständige Microsoft-Office-Umgebung unter Linux zu emulieren, trifft auch nicht meinen Geschmack, ist aber durchaus in der Praxis zu finden. Bliebe die Frage, ob das Produkt Crossover die richtige Wahl darstellt. Diese Frage diskutieren wir in dem Kapitel Emulationssoftware. Mein größter Kritikpunkt an SuSE Linux Office Desktop ist das „look & feel“ nach der Standardinstallation. Der neue Linux-Benutzer darf, aus Sicherheitsgründen, kaum eine Aktion ausführen, ohne per Popup-Fenster nach dem root-Passwort gefragt zu werden. Das Ergebnis ist schlicht und ergreifend Ablehnung des neuen Produkts. Ein gelungener Volltreffer für Sie als Projektleiter, falls Sie sich bei diesem Produkt schon einmal über die Schulter haben schauen lassen. Die Lösung des Problems ist zwar einfach, aber im Handbuch mit keiner Silbe erwähnt. Viele mittelständische Unternehmen haben sich über die Microsoft-Jahre mit der Datenbank Microsoft Access Individuallösungen geschaffen. Leider hat Crossover gerade mit diesem Office-Teil seine liebe Mühe. Womit Sie einen weiteren Wermutstropfen aufzuwischen haben. Das Freigeben von Verzeichnissen im Netzwerk funktioniert mittels NFS, das WindowsSMB-Netz wird nicht unterstützt. Womit auch kein Windows NT-Server (oder Windows 2000 Server) sichtbar wird und die Windows-Kollegen auch keins der freigegebenen Verzeichnisse „sehen“ können. Microsoft Outlook stürzt bei der Nutzung spezifischer Microsoft Exchange-ServerFeatures ab. Da alle diese Ungereimtheiten auf Sie als Projektleiter „projiziert“ werden, empfehle ich, auf dieses Produkt zu verzichten.

© Frank Obels


Seite 63


SuSE Linux Desktop Das Produkt ist für den Einsatz in großen Unternehmen und Behörden mit vernetzten Standorten vorgesehen. SuSE garantiert, dass dieses Produkt für die nächsten fünf Jahre gepflegt wird, außerdem gibt es eine verlängerte Support-Garantie. Das hier zugrundeliegende Gedankenmodell geht davon aus, dass Linux im Serverbereich andere Mitbewerber bereits vertrieben hat und man nunmehr den Desktop mit einer Produktumgebung ausstattet, die optimal mit dem im Keller befindlichen SuSE Linux Enterprise Server zusammenarbeitet. Diese optimale Abstimmung soll unter anderem durch die gemeinsame Code-Basis unterstrichen werden. Auch der SuSE Linux Desktop will dem Linux-Umsteiger ermöglichen, die bisherigen Windows-Programme weiterhin unter Linux nutzen zu können. Die Softwareausstattung ist ähnlich wie bei SuSE Linux Office Desktop, auch hier werden StarOffice, OpenOffice und CrossOver Office mitgeliefert. Der SuSE Linux Desktop ist ausschließlich zusammen mit einem Wartungsvertrag zu bekommen. In der kleinsten Variante sprechen wir von fünf Clients.

2.5.2 Office-Pakete Sie haben sicherlich bemerkt, dass ich kein zu großer Anhänger der oben genannten Paketlösungen bin, zumal, wenn sie sich von einer Standard-Distribution kaum unterscheiden. Ich lade Sie deshalb ein, sich mit mir nun die wichtigsten „Einzel-Applikationen“ im Desktop-Bereich anzusehen und diesbezüglich mit dem unbestreitbar wichtigsten Segment, den Office-Paketen zu beginnen. Seit sich die Stadt München für eine Linux-Migration ihrer Verwaltungsrechner entschieden hat, ist das Thema Linux auf dem Desktop wieder in aller Munde. Dabei kann man sich in deutschen Unternehmensbüros noch immer schlecht vorstellen, dass es einen vollwertigen Ersatz für „das“ klassische Office-Paket schlechthin gibt. Ob es der Linux-Gemeinde gefällt oder nicht, die Firma Microsoft hat hier mehr als nur einen Standard geschaffen. Um es vorwegzunehmen, einige der freien Office-Alternativen stehen dem kommerziellen Vorbild in nichts nach, übertreffen es teilweise sogar. So können Sie in der neuen OpenOffice-Version einfach auf Knopfdruck aus Ihren Dokumenten oder Präsentationen eine PDF-Datei generieren. Das ist nur eine von vielen Annehmlichkeiten. Auch dieses PDF-Dokument ist durch den angenehmen Knopfdruck entstanden.

Seite 64


© Frank Obels


Gibt es einen Haken? Ja - das Thema Konvertierung ist noch immer nicht umfassend gelöst. Zum einen lässt sich Microsoft nicht in die Karten schauen, was bedeutet, dass die Open Source-Entwickler Mühe haben, jede Gestaltungsmöglichkeit eines Dokuments „sauber“ in das Open Source-Dateiformat umzuwandeln. Weiterhin sind sehr viele TrueType-Schriften keine „freien“ Schriften, so dass auch hier „die Gemeinde“ neue Schriften entwickeln muss. Dem Anwender sind diese Probleme, zu Recht, aber einigermaßen egal und ein OfficePaket ist für ihn dann eine Alternative, wenn es das Gleiche kann, wie sein bisheriges Produkt und die Übernahme der bestehenden Daten einwandfrei funktioniert. Schauen wir uns an, welche Produkte diesbezüglich welchen Stand erreicht haben.

OpenOffice Da sich die Fachleute nicht einig werden, ob nun OpenOffice auf StarOffice beruht oder ob es umgekehrt ist, erkläre ich hiermit OpenOffice zum Open Source-Zweig der Firma Sun Microsystems hinsichtlich seines Office-Paketes StarOffice. Zu schwierig? Die hanseatische Firma Star Division versuchte vor einiger Zeit, mit seinem Produkt StarOffice dem Microsoft-Produkt MS-Office Konkurrenz zu machen. Dies misslang im Endergebnis, worauf die Firma Sun Microsystems den Verlierer samt Produkt kurzerhand kaufte. Sun gab den Quellcode von StarOffice frei und ein neues Open Source-Projekt war geboren: OpenOffice. Heute sprechen wir bei OpenOffice von einer vollwertigen, kostenlosen, Alternative zu den Office Produkten von Microsoft. Das „Aussehen“ („look & feel“ nennen das die Fachleute wohl) ist sehr ähnlich, nur wenige Menüpunkte unterscheiden sich wesentlich vom kommerziellen Vorbild. Open Office ist nicht nur für Linux, sondern auch für Windows verfügbar. Es besteht aus der Textverarbeitung Writer, der Tabellenkalkulation Calc, der Präsentations-Software Impress und dem Malprogramm Draw. Eine E-Mail-Terminkalender-AdressbuchAufgaben-Software fehlt, ebenso eine Datenbankumgebung, beides ist nicht schlimm, da es hier sehr komfortable eigenständige Produkte aus dem Open Source-Umfeld gibt. Die Installation ist einfach und in zehn Minuten erledigt, eine Zwangsregistrierung gibt es nicht. Als ein wesentlicher Nachteil wird bei OpenOffice oft die fehlende Rechtschreibkorrektur angeführt. Dies ist nicht ganz richtig, eine Rechtschreibkorrektur steht zur Verfügung, muss allerdings einmalig nachinstalliert werden. Dies hat lizenzrechtliche Gründe. Von der Qualität können Sie sich anhand dieses Pre-Releases ein Bild machen: ich habe das Standardwörterbuch über den Text laufen lassen. Wenn Sie also Orthografie-Fehler finden, lasten Sie das bitte nicht mir an ;-) Sehr schnell gewöhnt man sich an die automatische Wortergänzung. Lange Worte werden gespeichert und beim nächsten Gebrauch automatisch angeboten. Die Texterstellungsgeschwindigkeit erhöht sich deutlich dank dieses Mechanismus.

© Frank Obels


Seite 65


Der Import von MS Office-Dateien funktioniert problemlos, ebenso der Export. Häufig muss man aber gerade in der Projektarbeit bei den Microsoft-Formaten bleiben, zumindest vorübergehend. Um sich hier die Konvertiererei zu ersparen, kann man OpenOffice so einstellen, dass OpenOffice automatisch alle Dateien im Microsoft-Format speichert. So merken meine Kunden nicht, dass ich statt eines teuren Office-Pakets „nur“ die kostenlose Alternative verwende. Am liebsten verwende ich bei OpenOffice den „PDF-Knopf“, mit dem Sie Ihr Dokument in das im Internet weit verbreitete PDF-Format umwandeln können. Open Office bietet für Unternehmen einen strategischen Vorteil hinsichtlich des Dateiformats. Statt eines proprietären Formats benutzt OpenOffice den offenen Standard XML. Daher kann der Anwender sicher sein, seine Dokumente auch in fernerer Zukunft mit anderen Anwendungen als OpenOffice öffnen zu können. OpenOffice ist aus meiner Sicht uneingeschränkt zu empfehlen und es kann Ihnen als Projektleiter passieren, dass man von Ihnen den Einsatz von OpenOffice in Ihrem Projektbüro erwartet. Dies bietet manch interessiertem Kollegen nämlich die Gelegenheit, einmal völlig gefahrlos zu beobachten, was das Produkt denn wirklich kann.

StarOffice Sun Microsystems wusste, dass Unternehmen sehr schnell die Support-Frage stellen würden, die OpenOffice nicht in kommerzieller Manier beantworten können würde. Deshalb bietet Sun das Produkt StarOffice unter seinem Namen an und verkauft nun, wenn ich das einmal so ausdrücken darf, ein OpenOffice mit Support. Der Preisvorteil gegenüber dem Microsoft-Pendant ist erheblich. StarOffice bietet eine integrierte Rechtschreibprüfung, die von einem Dritthersteller zugekauft werden muss. Ansonsten bestehen nur geringe Funktionsunterschiede zu OpenOffice. Somit ist StarOffice die richtige Wahl, wenn man seinen Chef oder Auftraggeber nicht davon überzeugen kann, dass das kostenlose Programm OpenOffice so gut ist wie das Office-Paket vom Weltmarktführer Microsoft.

Applixware Office Applixware war eines der ersten kommerziellen Office-Pakete im Linux-Umfeld. Mit dem Erscheinen von OpenOffice gingen die Verkaufszahlen von Applixware stetig zurück. Die letzte Version stammt aus dem Jahre 2000. Da das Produkt noch immer im Internet erhältlich ist, findet es hier Erwähnung. Für den Einsatz im Projekt ist es ungeeignet, weshalb ich darauf verzichte, näher auf die Features einzugehen.

Seite 66


© Frank Obels


KOffice KOffice ist ein integriertes, freies Büropaket für das K Desktop Environment (KDE). Das KOffice-Projekt ist aus dem KDE-Projekt hervorgegangen und somit eng mit diesem verzahnt. KOffice lässt sich mit etwas zureden auch unter anderen grafischen Oberflächen, wie Gnome, installieren. Der Funktionsumfang bleibt hinter dem von OpenOffice zurück. Die Presse drückt dies zuweilen etwas härter aus und bescheinigt KOffice die Untauglichkeit für den Praxiseinsatz. Sie werden es also in einem Desktop-Migrationsprojekt nicht unbedingt als erste Wahl einsetzen. Diese Aussage basiert auf einer Momentaufnahme, nämlich zu dem Zeitpunkt, an dem ich diese Zeilen schreibe. Open Source-Projekte entwickeln sich bekanntermaßen sehr schnell. Es mag also durchaus lohnend erscheinen, sich dieses Produkt, wenn Sie in der LinuxProjektverantwortung stehen, noch einmal anzuschauen. Dies auch vor dem Hintergrund, dass es ja nicht immer die Maximallösung sein muss. Nach meiner Beobachtung nutzen ohnehin die wenigsten Anwender die Funktionsvielfalt eines Office-Pakets wie Microsoft Office oder auch Open Office.

Weitere Office-Pakete Die amerikanische Firma ThinkFree bietet ein gleichnamiges kommerzielles Office-Paket an, welches auf Java basiert. Dies bedeutet, dass eine bereits installierte Java-LaufzeitUmgebung benötigt wird. ThinkFree zeichnet sich durch eine hohe Stabilität bei eher geringem Funktionsumfang aus. Hancom Office ist der Name des Office-Pakets der koreanischen Firma Hancom Linux. Das Produkt kann in Projekten mit asiatischem Bezug durchaus einen Blick wert sein, denn es „versteht“ Japanisch und Chinesisch sowie weitere asiatische Sprachen.

2.5.3 Mail-Clients Die IT-Welt ist wohl noch immer die sich am schnellsten drehende. In diesem Abschnitt wollte ich Ihnen unter anderem von dem Produkt Ximian Evolution berichten, dem vielleicht leistungsstärksten freien Pendant zu Microsoft Outlook.. Doch während dieses Buch entsteht, wurde die Herstellerfirma Ximian kurzerhand von Novell gekauft. Somit wird wahrscheinlich die Zukunft dieses bisher freien Mail-Clients gerade neu definiert. Ich führe dieses Produkt dennoch auf, denn vielleicht darf Ximian Evolution ja frei bleiben!

© Frank Obels


Seite 67


Ximian Evolution Sofern Sie also noch das Glück haben, Ximian Evolution “frei” zu erleben, sollten Sie sich dieses Produkt genau ansehen. Evolution ist ein E-Mail-Client, eine Groupware Applikation und eine CRM-Umgebung, die nicht nur ähnlich wie Microsoft Outlook aussieht, sondern auch speziell für die Zusammenarbeit mit bestehenden Microsoft Exchange-Servern konzipiert wurde. Evolution erhielt in den USA praktisch jede bedeutende Auszeichnung (award), die in diesem Marktsegment vergeben werden. Die nachfolgende Grafik stammt von den Webseiten des Anbieters Ximian und vermittelt einen kleinen Eindruck, wie Evolution sich im Bereich E-Mail präsentiert.

Abbildung 2: Ximian Evolution E-Mail Screenshot

Seite 68


© Frank Obels


Mozilla Thunderbird Mozilla werden Sie im nächsten Abschnitt als Webbrowser kennenlernen. Den dort enthaltenen integrierten E-Mail- und Newsreader hat man vor kurzem bei Mozilla zu einem eigenständigen Open Source-Produkt gemacht. Das Produkt ist so jung, dass ich noch keinerlei Erfahrung im Projekteinsatz zu bieten habe. Im derzeit vorliegenden Umfang eignet sich Thunderbird als Ersatz für ein Produkt Microsoft Outlook sicherlich noch nicht, ist aber auf dem besten Wege dorthin.

Balsa Bei Balsa handelt es sich um einen sehr robusten E-Mail-Client, der zahlreiche Ausstattungsmerkmale mitbringt. Balsa läuft bevorzugt unter der Desktop-Variante GNOME. Balsa lässt sich am besten als stand-alone E-Mail-Client bezeichnen, der ebenso wie Thunderbird, keine Groupware-Eigenschaften besitzt.

KMail KMail ist der integrierte E-Mail-Client des KDE-Desktops. Wann immer Sie nicht die Funktionalität eines Microsoft Outlook-Clients benötigen, ist KMail einen Blick wert.

2.5.4 Webbrowser Es war einmal ein sogenannter Browserkrieg – und den gewann eindeutig die Firma Microsoft mit ihrem Produkt Internet Explorer. Und schauen wir uns heute WebseitenStatistiken an, so werden noch immer bis zu 80 Prozent aller Internetseiten mit diesem Internet Explorer betrachtet. Wir sprechen hier wieder einmal mehr von einem QuasiStandard, was mir den Zorn der Linux-Gemeinde wieder einmal sichert. Um Inhalte von Webseiten in jedem Browser gleich aussehen zu lassen, gibt es einen HTML Standard. Dieser liegt in der Zwischenzeit in der Version 4 vor. Gleich sehen die Webseiten in den unterschiedlichen Browsern deshalb aber immer noch nicht aus. Ein Standard allein nutzt eben noch nichts. Dies hat dazu geführt, dass sich viele Webmaster bei der Seitenprogrammierung daran orientieren, wie ihre Seiten unter dem Internet Explorer aussehen. Nehmen wir einmal an, der Internet Explorer wäre nicht ganz standardkonform, ein beliebiger Linux-Browser aber schon. Was hätte das zur Folge? Die Seiten sähen unter Linux schlecht aus, denn unser Webmaster hatte ja alles bezüglich des Internet Explorers optimiert. © Frank Obels


Seite 69


Womit Sie sich mitten in der Internetpraxis befinden. Es gibt einige sehr gute Linux-Browser und doch sehen viele Webseiten unter Linux anders aus, dies wird „natürlich“ Linux angelastet. Wundern Sie sich also bitte nicht, dass die Anwender nach einer vollständigen DesktopMigration „browser-unglücklich“ geworden sind. Ich habe diesbezüglich ernsthafte Akzeptanzprobleme erlebt. Ansonsten sollte Ihre Projektplanung Stellung dazu nehmen, ob Sie einen reinen (schlanken) Browser einsetzen wollen oder einen integrierten Browser, der E-Mail- und News-Client beherbergt und die gängigen Mailprotokolle POP-3 und IMAP beherrschen soll. Schauen wir uns diejenigen Webbrowser unter Linux an, die Sie nach meiner Meinung kennen sollten.

Beonex Communicator Der Beonex Communicator ist ein Mozilla Abkömmling, den es sowohl für Windows als auch für Linux gibt. Der Beonex Communicator besteht aus dem eigentlichen Browser, einem E-Mail- und News-Client sowie einem Editor für Webseiten. Der E-Mail-Client beherrscht sowohl IMAP als auch POP-3 und lässt sich für beliebige Mail-Accounts konfigurieren. Sofern Sie auf Sicherheiten beim Surfen Wert legen, hat der Beonex Communicator einiges mehr zu bieten als die „Mitbewerber“. Bevor Sie diesen Browser in einer Produktivumgebung einsetzen wollen, testen Sie ausgiebig die Zusammenarbeit mit Java-Umgebungen und Javascript.

Mozilla Mozilla ist eigentlich das Ergebnis des Verlierers des oben angesprochenen Browserkrieges. Die Firma Netscape, zu den Anfangszeiten des World Wide Web dominierend im Browser-Markt mit dem Netscape Navigator, entschloss sich 1998, als abzusehen war, dass man nicht nur gegen Microsoft im Browserkampf verlieren würde, sondern auch die Finanzen der Firma gegen Null tendieren würden, den Source-Code des Netscape Navigator freizugeben. Nach dem Vorbild von Linux sollte so wenigstens die Weiterentwicklung gesichert werden. Unter dem Namen Mozilla wurde der Source-Code, von proprietären Bestandteilen befreit, ins Internet gestellt. Soweit der Kurz-Geschichtskurs.

Seite 70


© Frank Obels


Mozilla selbst ist in einer Art und Weise entworfen, die es einfach macht, aus diesem Browser neue Browser zu entwickeln. Dank Open Source-Eigenschaft von Mozilla ist dies auch rechtlich kein Problem und so haben sich einige Browser am Linux-Markt etabliert, die von Mozilla abstammen, aber Funktionen entweder entfernt oder hinzugefügt haben. Der oben genannte Beonex Communicator ist ein solches Beispiel. Mozilla ist ein Allround-Internet-Client. Neben der Browserfunktion bietet er einen sehr komfortablen Mailer. Chatten und das Stöbern in Newsgroups sind ebenfalls kein Problem. Sie machen in Ihrem Linux-Projekt nichts falsch, wenn Sie sich für den Einsatz dieses Browsers entscheiden, der übrigens auch unter Windows läuft. Gerade bezüglich StandardKonformität in Sachen HTML ist dieses Browser-Paket ein Vorbild.

Netscape Im Jahre 1998 übernahm die Firma AOL das Hause Netscape. Man zog die Konsequenzen aus dem verlorenen Browserkrieg und die praktisch fertige Netscape 5.0-Version wurde nicht mehr veröffentlicht. Stattdessen setzte man auf Mozilla. Man entschloss sich, zu gegebenem Zeitpunkt wieder neue Netscape-Versionen zu veröffentlichen, was zwar Ende 2000 geschah, aber auch keinen Erfolg mehr brachte. Microsoft hatte seine Stellung durch die umstrittene Integration des Internet Explorers ins Betriebssystem Windows zu sehr gefestigt. Mangelnde Stabilität und Geschwindigkeit von Netscape taten ein übriges. Wichtig für Sie, auch Netscape ist ein Mozilla-Abkömmling. Nach meinem persönlichen Dafürhalten gibt es keinen Grund, Netscape den Vorzug gegenüber Mozilla zu geben. Zum einen ergeben sich Geschwindigkeitsnachteile, zum anderen ist der Softwareumfang 4 mal größer als der von Mozilla. Viele Netscape-Funktionen sind eigentlich nur für AOL-User nutzbar.

Opera Wenn zwei sich streiten, freut sich der Dritte. So dachte wohl eine kleine Firma in Norwegen. Während Microsoft und Netscape Browserkrieg spielten, brachte die frischgegründete Firma Opera Software einen gleichnamigen Webbrowser als kostenpflichtige Shareware auf den Markt. Bis heute ist Opera ein Nischenprodukt, welches allerdings insbesondere durch seine Schnelligkeit sehr auffällt. Ich benutze den Opera-Browser gerne zur Darstellung unseres Projekt-Intranets, da wir dort keine moderne „Spielereien“ wie Javascript und Flash einsetzen. Opera benötigt kaum Ressourcen, was auf einem „vollbepackten“ Projektbürorechner schon ein großer Vorteil sein kann.

© Frank Obels


Seite 71


Fazit Ich sehe keine Notwendigkeit, hier den ein oder anderen Linux-Browser zu präferieren. Auch wenn ich persönlich Mozilla sehr mag, überlasse ich in einem Projekt stets den Anwendern die Entscheidung. In unserem Projekt-Intranet können sich die Benutzer an einer Abstimmung beteiligen und die Vor- und Nachteile aus ihrer Sicht beschreiben. Das schafft Motivation und bringt im Regelfall auch noch den ein oder anderen wertvollen Hinweis.

2.5.5 Thin Clients als Desktop-Alternative Wenn Sie in einem Projekt die Aufgabe haben, auf Linux als Desktop-Betriebssystem umzustellen, so haben Sie in den vorangegangenen Kapiteln erfahren, welche „freien“ Programme und Lösungen für einen typischen Büroarbeitsplatz zum unschlagbar günstigen Preis zur Verfügung stehen. An dieser Stelle möchte ich Ihnen den Ansatz der Thin Clients vorstellen, der den interessanten Vorteil der einfachen, sicheren und kostengünstigen Verwaltung vieler PCClients mit sich bringt. Insbesondere in großen IT-Umgebungen ist die Frage nach der Administration der Arbeitsplatzsysteme eine ständige Herausforderung. Mittels Paketierungslösungen und anderen Ansätzen träumt man davon, die Arbeitsplatzrechner auf einem einheitlichen Softwarestand halten zu können oder aber den Administrationsaufwand für unterschiedliche Systeme wenigstens so weit wie möglich reduzieren zu können. Die Verwaltung einiger hundert oder gar tausend PC-Arbeitsplätze, zuzüglich entsprechender Notebooks, ist ein anspruchsvolles Unterfangen. Klären Sie, wenn Sie vor einer solchen Planungsaufgabe stehen, unbedingt die folgenden Fragen: was spricht gegen eine zentrale Softwareinstallation und –aktualisierung auf entsprechenden Servern, wie können unterschiedliche Software- und Systemkonfigurationen verwaltet werden, wie können unterschiedliche Benutzerprofile auf unterschiedliche Arbeitsplätze projiziert werden? Sollten Sie feststellen, dass die obigen Fragen Ihnen erhebliche Kopf- und Budgetschmerzen bereiten, dann sollten Sie überprüfen, ob Ihnen ein leistungsfähiges lokales Netzwerk zur Verfügung steht und ob viele Arbeitsplätze gleichartiger Natur sind (das wird oft bestritten und ist zumeist doch so). Wenn dem so ist, sollten Sie sich den Ansatz der Thin Clients anschauen. Thin Clients sind Arbeitsplatzrechner, auf denen keinerlei Programme mehr installiert sind und keine Benutzerdaten gespeichert werden. Alles, was ein solcher Arbeitsplatzrechner benötigt, holt er sich über das Netz von zentralen Servern. Ein solcher Client dient

Seite 72


© Frank Obels


eigentlich nur noch, wie die aus guter alter Zeit bekannten Terminals, zur Bildschirmdarstellung und zur Verarbeitung der Benutzeraktionen über Tastatur und Maus. Durch die Verwendung der grafischen Serversoftware (X Window) werden alle grafischen Unix- und Linux-Anwendungen unterstützt, auch auf Windows-Anwendungen kann über entsprechende Protokolle zugegriffen werden. Der gesamte typische Softwareteil eines Büroarbeitsplatzes kann so sehr schnell und einfach verwaltet werden. Ist an einem Arbeitsplatz „Spezialsoftware“ in Einzelfällen notwendig, so kann diese lokal installiert werden. Das häufigste Beispiel ist die Synchronisationssoftware für PDA und Palmtop. Sollten Sie mehrerer solcher Fälle haben, lässt sich auch diese Software zentral installieren und über Benutzerprofile wird festgelegt, welcher PC beim Bootvorgang diese Software erhält. Sie haben hier einen Ansatz, der jedes Management sehr einfach überzeugt. Nachfolgend stelle ich Ihnen die wesentlichen Vorteile für Ihre Entscheidungsvorlage dar: 1. Die Software auf den Arbeitsplätzen wird lediglich auf den Applikationsservern installiert, dort aktualisiert und gewartet. Die bisherige Verteilung auf die Clients entfällt. 2. Dadurch werden schnelle und einfache Software-Release-Wechsel ermöglicht. 3. Sie können bisherige Arbeitsplatzsysteme zu Thin Clients umfunktionieren und auch ältere PC-Hardware weiter benutzen, da die Hardwareanforderungen geringer sind. 4. Bei Neuanschaffung von „echten“ Thin Clients werden Sie den deutlichen Preisvorteil schätzen lernen, ein Thin Client liegt preislich zwischen 200 und 500 Euro. 5. Thin Clients (nicht umfunktionierte PCs) haben einen erheblich geringeren Platzbedarf und sind praktisch geräuschlos. 6. Durch die geringen Hardwareanforderungen und zahlreiche Bauart-Vorteile ergibt sich eine erhebliche längere Nutzungsdauer. 7. Dank der zentralen Applikations- und Datenvorhaltung ergeben sich deutliche Vereinfachungen für die Datensicherung; das Sichern der Büroarbeitsplätze entfällt. 8. Vorteile ergeben sich für die Benutzerverwaltung, da diese ebenfalls zentral erfolgt und ein lokales Anmelden am Client nicht vorgesehen ist. 9. Die Benutzer sind wirklich unabhängig von ihrem Arbeitsplatz, da auch die Daten zentral gehalten werden und es keine lokalen „Geheimfächer“ mehr gibt. 10. Thin Client-Umgebungen sind einfach skalierbar. Zusätzliche Clients werden einfach nur aufgestellt und sind sofort einsatzbereit. Serverseitig können bei Bedarf einfach weitere Applikationsserver aufgestellt werden. Sollte Sie dieses Thema wirklich interessieren, so heißt Ihr Schlagwort für die Suchmaschine zunächst „Linux Terminal Server Project (LTSP). Auf den dortigen Webseiten finden Sie wirklich alles, was Sie zum Aufbau einer Thin Client Umgebung benötigen, sowohl Software als auch erstklassige Dokumentation. Sollten Sie eine gemischte Linux-Windows-Umgebung vorfinden, suchen Sie im Internet bitte nach dem Stichwort „Univention“. Dieser Ansatz geht noch etwas über den klassischen Thin Client Ansatz hinaus.

© Frank Obels


Seite 73


Praxistip: In jedem größeren IT-Projekt macht es Sinn, für die Projektgruppe eine „Mini-Thin Client-Umgebung“ aufzubauen. Insbesondere in hochpolitischen Umgebungen werden Sie es zu schätzen wissen, wenn Sie Herr einer eigenen, gesicherten Umgebung sind und Ihre teilweise hochsensiblen Daten nicht auf, Ihnen unbekannten Servern liegen und von, Ihnen unbekannten Administratoren verwaltet. Häufig macht eine solche kleine Thin Client-Umgebung auch manchen Stakeholder neugierig und es gelingt Ihnen unter Umständen sehr elegant, „Freunde“ für dieses Thema zu finden.

2.6

Emulationssoftware zur Integration von Spezialanwendungen

Häufig bestehen in Unternehmen Spezialanwendungen, die nicht ohne weiteres auf Linux portiert werden können, zumindest nicht kurzfristig. Womit wir bei der Frage nach der Integrationsmöglichkeit derartiger Software angekommen wären. Ihr Kunde oder Projektauftraggeber erwartet zu Recht, dass Sie ihn von der Frage des Betriebssystems für derartige Anwendungen befreien und das Problem lösen.

2.6.1 Integration von DOS-Anwendungen Linux läuft überwiegend auf Intel-basierenden Rechnerarchitekturen. Auf diesen Rechnern war lange Zeit das Betriebssystem DOS vorherrschend und es liegt auf der Hand, dass bestimmte Spezialanwendungen bis in heutige Zeit hinein überlebt haben. Wenn ich an dieser Stelle von DOS spreche, meine ich damit auch die „grafischen Erweiterungen“ von DOS, die wir als Windows 3.x, Windows 95 und Windows 98 von der Firma Microsoft kennen. Diese Windows-Versionen basieren auf DOS. Wie also können Applikationen, die eines dieser Betriebssysteme zwingend benötigen, in eine Linux-Migration, eingebunden werden? Bitte beachten Sie, dass wir nunmehr an einem sensiblen Punkt angekommen sind, denn die augenscheinliche Unmöglichkeit der Integration von DOS-Anwendungen wird als ein wichtiges Argument gegen die Einführung von Linux herangezogen. Mit Samba haben wir bereits einen sehr zuverlässigen Mechanismus zur Integration kennengelernt. In diesem Abschnitt schauen wir uns die Möglichkeiten der DOS-Emulation kurz an, beschränkt auf die praxisrelevanten Lösungen.

Seite 74


© Frank Obels


DOSemu Es ist unschwer zu erraten, dass DOSemu für DOS-Emulation steht. DOSemu emuliert einen einfachen Intel-Rechner auf Ihrem Linux-PC – und dieser bootet DOS. Somit ist DOSemu nicht nur ein Programm, das es innerhalb von Linux ermöglicht verschiedene DOS-Anwendungen zu starten, es ist eigentlich ein DOS-PC innerhalb von Linux. DOSemu ist mit einem komfortablen Konfigurationswerkzeug ausgestattet und ist geeignet, den größten Teil der verfügbaren DOS-Programme unter Linux zu verwenden. Auch ältere Versionen von Microsoft Windows sind unter DOSemu lauffähig, da diese ja noch auf DOS „aufsetzten“. Sollten Sie in Ihrem Projekt DOS-Anwendungen berücksichtigen müssen, so ist DOSemu immer einen Versuch wert.

WINE Das WINE-Projekt hat zum Ziel, Programme, die auf Microsoft Windows basieren, unter Linux lauffähig zu machen. Dabei ist WINE weniger ein Emulator als mehr der Versuch einer Windows-Implementierung unter Linux. Daher wird auch nicht, wie bei DOSemu, eine Art „virtuelle Box“ geschaffen, in der sich alles abspielt, sondern dieser Ansatz sieht vor, Windows-Programme wie Linux-Programme direkt ablaufen zu lassen. Und das funktioniert mehr oder weniger gut. Die sogenannten „WIN16-Anwendungen“, also Programme der ersten Windows-Versionen funktionieren ganz gut. Bei der Verwendung späterer Windows-Versionen sollten sie vorsichtshalber mit Einschränkungen rechnen. Von den bestehenden Stabilitätsproblemen einmal abgesehen, ist es bemerkenswert, dass durch den Einsatz von WINE kein „spürbarer“ Geschwindigkeitsverlust einer WindowsApplikation zu erkennen ist. WINE ist derzeit nicht geeignet, in Produktionsumgebungen eingesetzt zu werden.

2.6.2 Virtueller PC Warum soll man sich auf das Emulieren von Betriebssystemen oder Teilen davon beschränken? Schöner wäre es doch, gleich einen ganzen PC zu emulieren oder, um noch unverschämter zu sein, beliebig viele. Womit wir beim Gedankenansatz des sogenannten Virtuellen PCs angelangt wären. Lassen Sie uns nachstehend kurz betrachten, was dieser Ansatz für Ihr Projekt bedeuten kann.

© Frank Obels


Seite 75


Ich schätze in Linux-Projekten den Vorteil einer sehr bequemen und sicheren Testumgebung. Stellen Sie sich beispielsweise vor, Sie wollten, in einer gemischten Windows-Linux-Umgebung, Client- und Server-Tests durchführen. Nach dem Ansatz des virtuellen PCs lassen Sie eine „Instanz“ zum Server werden, eine andere „Session“ zum Client und über den realen PC können Sie etwa Performance Messungen vornehmen. Lassen Sie uns kurz anschauen, was das Produkt VMWare heute in der Praxis zu leisten in der Lage ist.

VMWare Workstation Mit VMWare Workstation wird ein kompletter x86-PC innerhalb eines Betriebssystems emuliert. Es wird ermöglicht, ein sogenanntes „Gast-Betriebssysteme“ auf einem Basisbetriebssytem laufen zu lassen. So könnte beispielsweise Linux unter WindowsNT laufen oder, für uns interessanter, ein Windows-Betriebssystem unter Linux. VMWare stellt den virtuellen PC zur Verfügung, was bedeutet, dass das GastBetriebssystem wirklich installiert werden muss. VMware Workstation ermöglicht den Aufbau komplexer Netzwerke innerhalb eines einzelnen PCs. Dadurch können virtuelle Maschinen mit anderen virtuellen Maschinen, dem Basisbetriebssystem und anderen Netzwerken kommunizieren. Unterstützte Gast-Betriebssysteme sind zur Zeit: • • • •

Windows XP Windows 2000 Windows NT 4.0 Windows Me

• • • •

Windows 98 Windows 95 Windows 3.1 MS-DOS 6

Meine Erfahrungen mit VMWare Workstation sind sehr gut. Für ein Projekt muss sich der diesbezügliche Einsatz jedoch rechnen, denn sowohl VMWare als auch das GastBetriebssystem stellen eine entsprechende Kostengröße dar.

2.7

Software für die „Kleinigkeiten“

Es sind häufig die Kleinigkeiten, die die großen Probleme verursachen, dies ist eine bekannte Weisheit. Wenn Sie in einem Unternehmen eine Linux-Desktop-Migration durchführen wollen und den Anwendern dadurch beispielsweise die Möglichkeit der PDASynchronisation nehmen, weil Linux „das nicht kann“, dann ist Ihr Projekt entweder gescheitert oder die Unternehmensleitung muss Sie massiv unterstützen.

Seite 76


© Frank Obels


2.7.1 Organizer und PDA Organizer und PDA auch unter Linux mit dem Desktop-Rechner zu synchronisieren stellt heute kein unlösbares Problem mehr dar. Eine entsprechende Suchmaschinenrecherche bringt sehr schnell gute Resultate. Sehr konkret kann ich an dieser Stelle nicht werden, da viel davon abhängt, welche Desktop-Applikation Sie verwenden wollen oder müssen. Palm Pilot Modelle Eine vollständige Integration konnte zwischen den Anwendungen des GNOME-Desktops, Kalender, Adressbuch, E-Mail-Client, und den Palm Pilot-Modellen erreicht werden. Sogar ein entsprechendes HotSync-Symbol erscheint auf dem Desktop. Mit kpilot und anderen stehen auch unter dem KDE die entsprechenden komfortablen Tools zur Verfügung. PSION Modelle Auch die typischen Palmtops wie revo oder 5mx sind kein Problem. Allerdings findet die Zusammenarbeit häufig im Konsolenmodus durch das Eingeben der entsprechenden Befehle statt und ist damit nicht so komfortabel wie bei den Palm-Modellen. Dies mag für ein Desktop-Migrationsprojekt nicht so schön sein, denn ein Programm mit grafischer Oberfläche ist mir nicht bekannt. In so einem Falle würde ich zunächst den Emulator WINE bemühen, um zu entscheiden, ob für diesen speziellen Fall WINE eingesetzt werden kann. Compaq iPAQ Für die iPAQ-Modelle gibt es nicht nur die entsprechenden Synchronisationstools, sondern auch die Möglichkeit, den iPAQ selbst auf Linux zu migrieren. In diesem Zusammenhang sei auf das Opie-Projekt (Open Palmtop Integrated Environment) hingewiesen, der ersten vollständig Open Source basierten graphischen Plattform für Linux PDAs.

2.7.2 Handies Nokia Für Nokia gibt es eine Fülle von Tools, unter anderem aus dem gnokii-Projekt. Dieses hat eine sehr schöne Software erschaffen, die mit den meisten Nokia-Modellen problemlos zusammenarbeitet. So kann selbst die beliebte SMS komfortabel aus der grafischen Oberfläche verschickt werden.

© Frank Obels


Seite 77


Siemens Besitzer von Siemens-Handies haben ebenfalls viel Glück: es gibt unter Linux eine Reihe schöner und hilfreicher Programme. An dieser Stelle sei vor allem auf das Programm „gscmxx“ verwiesen. Mit einer derartigen Applikation auf dem Linux-Desktop kann eine Migration ja nur gelingen.

Seite 78


© Frank Obels


3

Erfolgreiches Projektmanagement

In einem Projekt haben Sie immer drei Gruppen von Menschen: Die erste Gruppe bestimmt das Geschehen; die zweite Gruppe beobachtet das Geschehen; und der große Rest möchte gern wissen, was geschehen ist.

Unbekannter Autor

Das „Handwerkszeug“ des Projektmanagements, also wie man ein Projekt plant und abwickelt, ist durch viele gute Fach- und Lehrbücher hinreichend beschreiben. Insofern verzichte ich darauf, die gesamten institutionalen und funktionalen Bestandteile, die zur Projektdurchführung benötigt werden, ausführlich zu behandeln. Ohnehin unterliegt einzig die Projektumgebung einer fortschreitenden Änderung, deshalb beschäftigen wir uns in diesem Kapitel auch schwerpunktmäßig mit den Zentraldeterminanten einer Projektumgebung. Die entsprechenden Grundlagen werden „nebenbei“ zur Erhöhung des Leseverständnisses vermittelt. Die klassischen Projektbomben, denen eine besondere Bedeutung in einem Linux-Projekt zukommt, seien gleich zu Beginn benannt: 1. Zielsetzung des Projektes und die diesbezügliche Abgrenzung fehlen oder erlauben zuviel Interpretationsspielraum. 2. Das sogenannte „staffing problem“ wird nicht ausreichend beachtet und das Projekt erleidet Personalprobleme unterschiedlichster Art. 3. Projektplanung und Durchführungsüberwachung erfolgen nicht in dem erforderlichen Maße. 4. Die Hardwareverträglichkeit und Softwarekompatibilitäten wurden nicht hinreichend getestet. 5. Die Benutzer lehnen das Projektergebnis ab.

© Frank Obels


Seite 79


Es ist erstaunlich, welche Vielfalt an Interpretationen bezüglich der Begriffe Projekt und Projektleiter in den Unternehmen, Behörden und Medien existiert. Die oben genannten Projektbomben können sämtlich durch einen erfahrenen Projektleiter entschärft werden.

3.1

Die Grundlagen

Die nachfolgenden Grundlagen bilden nicht die gesamte verfügbare Themenbreite ab, die es zum Thema Projektmanagement gibt. Diese Vielfalt würde allein einige Bücher füllen. Deshalb beschränke ich mich auf das mir wesentlich Erscheinende.

3.1.1 Einführung in das Projektmanagement Verfolgt man die Presse, so gehen Projekte offensichtlich auch einmal schief. Zu beobachten ist, dass immer häufiger von Projekten gesprochen wird. „Projekte machen“ ist also scheinbar eine moderne und gute Sache. In der Tat sind Projekte aus der Unternehmenswelt kaum noch wegzudenken. Reorganisationsmaßnahmen, größere Marketingoffensiven, IT-Systemeinführungen oder Produktentwicklungen, alles das wird als gleichermaßen heute als Projekt abgewickelt. Warum aber macht man aus vielem ein Projekt, wenn doch derart viele Projekte schieflaufen? Warum verdrehen Mitarbeiter die Augen, wenn Sie hören, die Unternehmensleitung habe schon wieder ein neues Projekt initiiert? Ist Projektarbeit nichts weiter als das „In-den-Sand-Setzen“ einiger unbenötigter Millionen des Firmenbudgets? Oder gar ein Steuerminderungsprogramm? Dieses Kapitel wird Ihnen einige der gestellten Fragen beantworten und Ihnen stellenweise auch eine leicht unbequeme Ansicht präsentieren. Auch wenn die Literatur voll ist von möglichen Erklärungen, warum Projekte scheitern, es gibt letztlich nur einen Grund: eine unzureichende „Ausstattung“ des Projektleiters.

Was ist denn ein Projekt? Insbesondere frisch beginnende Projektmanager haben einige Schwierigkeiten mit der Verwendungsfülle des Terminus Projekt in der Praxis, denn schließlich haben sie eine „Definition“ des Begriffs Projekt ähnlich der nachstehenden Formulierung gelernt.

Seite 80


© Frank Obels


Demnach ist ein Projekt:  eine zeitlich begrenzte,  einzigartige oder neuartige,  komplexe und zumeist riskante Aufgabenstellung, die  über klare Ziele verfügt,  von begrenzter Lebensdauer ist,  und mit knappen Ressourcen haushalten muss. Gerade für externe Projektmanager charakterisiert der Begriff Projekt auch eine Art Vertrag oder Vereinbarung. In diesem Falle übernimmt der Projektmanager die Durchführungsverantwortung für eine komplexe, neuartige, riskante und für das Unternehmen sehr wichtige Aufgabe und vereinbart diesbezüglich sehr konkrete Ziele bezüglich des Leistungsumfangs, der Termine, der Ressourcen und der Kosten. Wenn ich ein wenig ungenau sein darf, ist ein Projekt ein Werkvertrag zwischen einem Projektauftraggeber und dem Projektteam, wobei der Projektauftrag und die Projektplanung das Pflichtenheft dieses Werkvertrages darstellen. Das klassische Liniengeschäft im Unternehmen sehe ich dagegen, wenn ich bei einer kleinen Ungenauigkeit verbleibe, als typischen Dienstvertrag an. Die wichtigsten Projekterfolgskriterien werden sicherlich die Komplexität, die zeitliche Begrenzung und das Vorhandensein klarer Ziele sein. Stellen Sie als Projektmanager Ihrem möglichen Projektauftraggeber doch einfach die Frage, warum das Vorhaben nicht aus der Linie heraus abgearbeitet wird. Sie lernen so nicht nur sein Projektverständnis kennen, sondern insbesondere auch wichtige „menschliche und organisatorische“ Ansichten des Auftraggebers und seiner Projektwelt. Typische Projektaufgaben im Linux-Umfeld sind beispielsweise Migrations- und RolloutProjekte, etwa die Umstellung von Betriebssystem A (oder M.) auf Linux über einen Zeitraum von 11 Monaten über alle Filialen einer Bank oder etwa der Umzug eines Rechenzentrums von Standort A nach Standort B ohne jedwede Betriebsunterbrechung und gleichzeitige Migration der Midrange-Systeme auf Linux.

Und was ist Projektmanagement? In der Praxis findet sich auch diesbezüglich eine Fülle herrlichster Interpretationen. Aber zum Trost für die Formalisten unter Ihnen, es gibt mit DIN 69 901 eine offizielle Definition: Projektmanagement ist die Gesamtheit aller Führungsaufgaben, Mittel und Organisationen, die für die erfolgreiche Projektabwicklung notwendig ist.

© Frank Obels


Seite 81


Damit Sie die Dimension für ein IT-Projekt und insbesondere für Ihr kommendes LinuxProjekt richtig ermessen können, sollten Sie sich das nachfolgende Verständnis, das am Markt durchgängig existiert, als Überprüfung Ihres eigenen Selbstverständnisses, „genießen“: Projektmanagement bezeichnet die Anwendung und den Einsatz - von Wissen und Erfahrung, - von persönlichen Fähigkeiten, Sozialkompetenz sowie spezifischen Fach-Knowhows, - der richtigen Techniken und Tools, - der richtigen Spezialisten und Generalisten, auf alle Aktivitäten, die zur Erreichung eines definierten Projektziels erforderlich sind. Und nur das erwartet man von Ihnen.

3.1.2 Projektphasen und -verlauf Zur besseren Bearbeitung eines Projektes unterteilt man dieses in zeitliche Abschnitte. In der Vorprojektphase findet im weitestgehenden Sinne die Vorbereitung des möglichen Projektes statt. Dazu gehören die Erstellung eines groben Projektplans und eine detaillierte Beschreibung möglicher Projektziele und Vorteile für das Unternehmen. In der Vorprojektphase werden die Investitionssumme, Termine und Ressourcen grob geschätzt und in Linux-Projekten gehören in diesen Bereich Machbarkeitsstudien oder andere technische Vorüberlegungen in Konzeptform. Häufig wird in der Vorprojektphase bereits ein designierter Projektleiter positioniert. Dieser hat noch nichts zu leiten, aber immerhin schon einmal etwas zu verantworten. Nachdem der Startschuss gefallen ist, wird begonnen, das Projekt zu definieren.

Abbildung 3: Beispielphasen eines Projektverlaufs

Seite 82


© Frank Obels


Projektphasen wollen die Bearbeitung des Projektes erleichtern und es wurden unzählige Phasenmodelle entwickelt. Es gibt kein richtiges oder falsches Modell. Im IT-Bereich gibt es immer wieder Stimmen, die fordern, für IT-Projekte auf eine Phasenstrukturierung zu verzichten. Lassen Sie sich darauf nicht ein! Zumeist wollen sich diese Menschen nur ihre technische Spielwiese retten. Die oben gezeigte grundsätzliche Projektstrukturierung wird in meinen Projekten von einer IT-spezifischen Unterteilung überlagert. Dies hat für mich den Vorteil, dass sich die ITMenschen in Ihrer Denkumgebung bewegen können, die Projektmanager, das Projektteam und die Stakeholder aber in Ihrer Sicht verbleiben können. Da ich grundsätzlich immer beide Sichten anbiete, darf jeder ganz für sich entscheiden, welchen Betrachtungswinkel er jeweils anlegen möchte. Ich zeige Ihnen mein Modell auf der nächsten Seite, wobei Sie bitte berücksichtigen möchten, dass Sie völlig frei sind, Ihr eigenes Modell zu entwerfen. Dies hängt auch immer von der Art Ihres Projektes ab. Wichtig ist, dass Ihr Projekt eine Struktur hat, die nachvollziehbar und allen Projektteilnehmern bekannt ist. Am besten Sie suchen sich eines der vielen vorgegebenen Modelle heraus und verändern es entsprechend Ihrer Bedürfnisse.

Abbildung 4: Beispielphasen eines Projektverlaufs mit überlagerter IT-Sicht

Es hat sich in der Praxis sehr bewährt, jede Projektphase mit einem Meilenstein beginnen und enden zu lassen. Ist man an einem Meilenstein angekommen, sollte das Projektteam die weitere Vorgehensweise besprechen, wobei immer zu überprüfen ist, ob das Projekt fortgesetzt oder abgebrochen werden soll. Ich bezeichne Meilensteine deshalb auch gerne als die Ausstiegsmöglichkeiten aus einem Projekt. Sie werden sicherlich innerhalb der Phasen weitere Meilensteine, insbesondere während der Projektdurchführungsphase setzen. Beschränken Sie sich in der Zahl der Meilensteine auf ein Höchstmaß von 15 Meilenstein insgesamt.

© Frank Obels


Seite 83


Betrachten Sie Meilensteine bei Projekten mit einer Laufzeit von mehr als 2 Jahren als echte Sollbruchstellen. Da sich über einen so langen Zeitraum „garantiert“ einzelne Umgebungsvariablen ändern werden, sollten Sie sich als Projektleiter und Ihrem Kunden als Geldgeber immer einige wohldefinierte Abbruchstellen festgelegt haben.

3.1.3 Projektorganisation Ein wesentlicher Erfolgsfaktor in IT- und Linux-Projekten ist die Festlegung von Verantwortlichkeiten, Informations- und Kommunikationsstrukturen, Entscheidungsbefugnissen und Aufgabenbereichen. Die so definierten Zusammenhänge und Rahmenbedingungen haben für alle Beteiligten verbindlichen Charakter. Das entstandene Gesamtkonstrukt bildet die Organisation eines Projektes ab. Für viele Projektmanager ist an dieser Stelle die Projektorganisationsarbeit beendet – leider! Da ein Projekt kein isoliertes Eigenleben führen kann, sollten Sie sich daher immer brennend dafür interessieren, wie der organisatorische Hintergrund des Projektmanagements in Ihrem Unternehmen gelöst wurde. Der Begriff Organisation findet heute gerne die Verwendung einer Beschreibung, wie die Teile eines Ganzen untereinander und zu diesem Ganzen orientiert sind und zusammenwirken. Wenn wir eine solche "Definition" unterstellen, ergeben sich ein eher statischer Organisationsaspekt sowie ein dynamischer Anteil. Wir sprechen in diesem Zusammenhang auch von Aufbau- und Ablauforganisation. Die Projektorganisation kann aus beiden Perspektiven betrachten werden. Sie ist zugleich ein statisches und ein dynamisches Phänomen. Es lassen sich drei typische Grundformen des Projekt-Managements unterscheiden: Stabs-Projektorganisation, Matrix-Projektorganisation und die sog. Reine ProjektOrganisation.

Stabs-Projektorganisation Sie ist die einfachste und damit „preiswerteste“ Organisationsform, da ausschließlich den Stabsstellen die Projekte zugewiesen werden. Dies bedeutet eine sehr geringe Zuordnung personeller oder materieller Ressourcen. Der Projektfortschritt ist sehr langsam, eignet sich für Projekte mit geringer Bedeutung. Projekte werden generell „aus der Linie gefahren“.

Seite 84


© Frank Obels


Abbildung 5: Schematische Darstellung Stabs-Projektorganisation

Matrix-Projektorganisation An die Stelle der Stabsstellen werden Projektmanager „gesetzt“ – heute auch gerne als Querschnittsfunktion bezeichnet. Es kommt zu vielen Reibungsverlusten. Je mehr Linien in einem Querschnittsprojekt berührt werden, umso schwerfälliger wird der Projektverlauf. In der Literatur wird häufig darauf hingewiesen, dass diese Organisationsform eher selten sei! Das Gegenteil ist der Fall, diese Struktur erlebt in der jüngeren Vergangenheit geradezu einen Boom. Es ist in unseren Unternehmen derzeit sehr modern Querschnittsfunktionen „einzubauen“, insbesondere im IT-Servicemanagement. Dennoch Vorsicht: Eine sehr diffizile Angelegenheit, ideal für externe Projektleiter, da keine Interessenskonflikte mit der Linie bestehen.

Abbildung 6: Schematische Darstellung Matrix-Projektorganisation

© Frank Obels


Seite 85


Reine Projektorganisation Dies ist die effizienteste Form der Projektorganisation, ohne Linieneinflüsse und mit maximaler Ressourcenzuordnung. Es werden sehr schnelle Projektfortschritte erzielt. Die reine Projektorganisation ist, aufgrund der Kostenintensität, nur für wirklich wichtige oder dringende Projekte geeignet.

Abbildung 7: Schematische Darstellung der reinen Projektorganisation

In natura werden Sie eine schier unübersehbare Menge an Mischformen antreffen. Ich kann Ihnen sehr empfehlen auf vorhandene Querschnittsfunktionen ähnlich der Matrixorganisation zu achten. Hier kann sehr viel Brisanz und Projekterschwernis vorhanden sein. Im Rahmen der Stakeholderanalyse kommen wir darauf noch einmal zu sprechen.

3.1.4 Typische Rollen im Linux-Projekt Der Begriff Rolle bezeichnet die Gesamtheit der Erwartungen an eine Position oder Stelle. Sie können sich dies vereinfacht als eine Art Stellen- und Aufgabenbeschreibung für eine Projektposition vorstellen. Das Ziel der Definition von Projektrollen ist vordergründig die Schaffung von Klarheit bezüglich der Zusammenarbeit im Projektteam und damit der Aufgaben und Kompetenzen sowie Verantwortlichkeiten.

Seite 86


© Frank Obels


Abbildung 8: Beispieldesign einer Projektrollenstruktur

Auftraggeber und Projekteigner Den Auftraggeber Ihres Projektes sollten Sie kennen – er gilt allgemein als der wichtigste Projektbeteiligte. Er kann eine Person oder eine Personengruppe sein, erteilt den Auftrag und ist der Vertragspartner, der über den Erfolg des Projektes endgültig entscheidet. Häufig stellt der Auftraggeber auch die finanziellen Mittel zur Verfügung. Je nach Gegebenheit kann man zwischen internem und externem Auftraggeber unterscheiden. Lassen Sie uns ein Beispiel anschauen: Der Vorstand eines Unternehmens beschließt, eine neue Konzernzentrale zu bauen. Er ist somit Auftraggeber des Projektes „Neubau der Zentrale“. Der Vorstand benennt einen der Bereichsleiter zum Projekteigner, nennen wir diesen einmal den „Internen Bauherren“. Diese Sonderform ist bei größeren Unternehmen durchaus üblich. Der Projekteigner hat in diesem Fall die Rechte und Pflichten des Auftraggebers geerbt und ist nun interner Auftraggeber für das Projekt. Die bauliche Erstellung des Gebäudes wird vom Vorstand an eine Tochtergesellschaft zur Durchführung übergeben, wobei der Vorstand diese Aufgabe nicht weiterdelegiert und gegenüber der Tochtergesellschaft nunmehr externer Auftraggeber ist. Derartige Konstrukte sind auch im Linux-Umfeld anzufinden. In einem meiner letzten Projekte hatte sich der Kunde eine ausgesprochen hübsche Besonderheit einfallen lassen: Der Finanzvorstand einer französischen Bank war der Auftraggeber für ein IT-Projekt, das aus dem Umzug der IT in ein anderes Gebäude bestand und zwei parallelen Migrationsvorhaben, die mit dem Bezug des neuen Gebäudes abgeschlossen sein mussten. Zum einen sollten alle Großrechnersysteme abgelöst und durch Unix-Cluster ersetzt werden, zum anderen die gesamte Client-Funktionalität auf Linux abgebildet werden.

© Frank Obels


Seite 87


Der Vorstand ernannte zwei Projekteigner für diese Aufgaben, einen Projektleiter und zwei Projekt-Coaches. Welche Konstruktion Sie auch immer in der Praxis antreffen werden, der Auftraggeber oder der Projekteigner werden immer Mitglied des Lenkungsausschusses eines Projektes sein. Dort haben diese auch im Regelfall die letzte Entscheidungsbefugnis.

Lenkungsausschuss (steering committee) Im Lenkungsausschuss (Lenkungsgremium, Steuerungsgremium) werden grundlegende Entscheidungen bezüglich des Projektes getroffen. Dieser Ausschuss legt strategische Ziele fest und greift bei ernsthaften Problemen steuernd in das Projekt ein. Sie finden dort neben dem Auftraggeber immer auch den Projektleiter sowie alle diejenigen Projektbeteiligten, die für das Projekt von herausragender Bedeutung sind. Im Regelfall tagt der Lenkungsausschuss das erste Mal, wenn es um die Verabschiedung des Projektauftrages als Auftaktveranstaltung des Projektstarts geht. Ab dann sollte der Lenkungsausschuss zu festgelegten Zeitpunkten einberufen werden. Diese Zeitpunkte orientieren sich üblicherweise an der Meilensteinplanung. Als Projektleiter sollten Sie festlegen lassen, wie der Lenkungsausschuss Entscheidungen treffen soll. Dies kann anhand von Entscheidungsvorlagen, einer besonderen Form des Projektstatusberichts, erfolgen oder aber einfach während einer Sitzung aufgrund der Schilderungen des Projektleiters. In der Praxis gibt es hier keine allgemeingültige Regelung, das Instrument der Entscheidungsvorlage ist gleichwohl häufig anzutreffen. Auch der Projektabschluss erfordert eine entsprechende Sitzung des Lenkungsausschusses, in der formal das Projektende festgestellt wird - und den Verantwortlichen Entlastung erteilt wird.

Projektleiter Der Projektleiter ist die zentrale Figur in der Verantwortung, Planung und Steuerung des Projektes. Er gestaltet die Kommunikation und das Miteinander im Projekt, führt die Definition und Grobplanung des Projektes durch und koordiniert und überwacht fortlaufend das Projekt. Ungünstig ist es, wenn der Projektleiter zugleich Fachverantwortlicher für die ITFragen des Projektes ist. Dieses Modell wird in der Praxis gerne gewählt, da man vordergründig durch diese Personalunion „Geld“ sparen kann. Wenn ein Projektleiter seine Leitungsfunktion vernachlässigen muss – können Sie das Projekt schon als gescheitert betrachten. Nicht umsonst gilt im Projektmanagement die Regel, dass ein Projektleiter nicht „arbeiten“ (fachlich) sollte. Der Projektleiter sollte primär Moderator, Motivator und Mediator (Konfliktlöser) für das Gesamtprojekt sein – und es „im Griff“ haben. Es kommt häufig vor, dass ein Unternehmen nicht über ausreichend qualifizierte Personalressourcen verfügt, um einen internen Projektleiter für ein Projekt einzusetzen. Seite 88


© Frank Obels


Es ist deshalb durchaus üblich, sich einen externen Projektleiter „einzukaufen“. Je gefährlicher und „politischer“ ein Projekt, umso höher die Bereitschaft der Geschäftsführung, einen externen Berater als Projektleiter zu verpflichten. Auch kann es vorkommen, dass aus unternehmensinternen Gründen der Projektleiter aus dem Unternehmen kommt, ihm aber ein externer Projektleiter zur Seite gestellt wird. Tritt dieser aktiv im Projekt auf, so wird er häufig Projektkoordinator genannt, bei einem Beratungsfokus auf die Person des internen Projektleiters nennt man diesen Projekt-Coach.

Projektkoordinator (Project Coordinator) Wie bereits oben erwähnt, ist ein Projektkoordinator häufig ein externer Projektleiter, der aber aus unternehmensinternen Gründen nicht als (interner) Projektleiter auftreten darf. Dieses Phänomen beobachte ich sehr häufig in Unternehmen, die eine starke Linienorganisation leben und neben der Linie keine Führungs- bzw. Leitungspositionen kennen. Also muss der Projektleiter „aus der Linie“ sein. Bitte beachten Sie: das Projekt wird in diesem Fall quasi „aus der Linie gefahren“. Die entsprechenden Probleme sind vorprogrammiert. Dem Projektkoordinator wird also, je nach Anknüpfungshöhe des Projektes, eine Führungskraft des Unternehmens als nomineller Projektleiter vorgesetzt. Die Tätigkeit des Projektkoordinators ist durch diese Konstruktion von vornherein mit erheblichen Einschränkungen für die Steuerung des Projektes versehen, alleine schon durch die Tatsache bedingt, keinerlei disziplinarische Mittel zur Projektsteuerung zur Verfügung zu haben.

Projekt-Coach Für das Aufgabenspektrum des Coachings eines Projektmanagers gibt es sogar eine offizielle Definition nach DIN 69905. Dort wird die "Betreuung, Unterstützung, Förderung, Anleitung und Training von im Projektmanagement Tätigen bei der praktischen Arbeit" in den Vordergrund gestellt. Ich konnte mir darunter nie so richtig etwas vorstellen, weshalb ich Ihnen an dieser Stelle eine eigene Umschreibung der Tätigkeit eines Coaches anbiete. Suchen Sie sich die für Sie passendere heraus. Unter Coaching verstehe ich eine Technik, bei der ein Berater oder Coach dem zu Beratenden die Gelegenheit gibt, über seine Probleme zu sprechen. Es findet keinerlei Bewertung durch den Coach statt. Die Hauptwerkzeuge des Beraters sind aktives Zuhören sowie das Lenken durch gezieltes Fragen. Damit wird Coaching eine Hilfe zur Selbsthilfe. Ein guter Coach macht den zu Beratenden unabhängig. In einem, auch politisch, hochsensiblen Linux-Projekt darf es nach meiner Erfahrung gar nicht anders sein, da ansonsten die Glaubwürdigkeit des zu Beratenden, also dem Projektleiter, leidet. In jeder Phase des Coachings muss der „Gecoachte“ genau das

© Frank Obels


Seite 89


Ausstrahlen, was er selbst verstanden hat. Ratschläge sind das falsche Mittel, denn in dem Begriff steckt das Wort „Schläge“. Und stellen Sie sich mal bitte die Ausstrahlung eines Geschlagenen vor. Der Job eines Projekt-Coaches ist in zweierlei Hinsicht ein besonderer: zum einen muss er etwas bewegen, indem er sich zurück nimmt, zum anderen projizieren der Projektauftraggeber und das Linienmanagement auf ihn die Verantwortung, indirekt für den Projekterfolg mit verantwortlich zu sein. Ich werde immer wieder gefragt, warum es mir nicht gereicht hat, einfach nur Berater zu sein, sondern warum ich mich in zahlreichen Mentaldisziplinen habe ausbilden lassen. Die Antwort ist sehr einfach: die meisten Projekte scheitern leider noch immer aufgrund von Problemen auf der psychosozialen Ebene. Und als Projekt-Coach und als Projektleiter haben Sie genau diese Ebene bei Ihrem Klienten zu „bearbeiten“. Und wie wollen Sie dies bewerkstelligen, wenn Sie die grundlegende Funktionsweise des Psychosozialen nicht kennen. Im Gegensatz zu den USA ist aber die „Psychoschiene“ in Europa nur sehr rudimentär ausgebildet, auch das weit verbreitete Führungskräfte-Coaching hierzulande enthält kaum diesbezügliche Elemente. Zurückkehrend zu den Fachaufgaben eines Projekt-Coaches geht es dabei also nicht um die Beratung bei typischen Führungsaufgaben, sondern insbesondere um den adäquaten Einsatz von Projektmanagementmethoden. Dies um so mehr, wenn der interne Projektleiter starke Fachkompetenz besitzt, die Projektmanagementmethodik jedoch noch nicht so stark entwickelt ist.

Projektbüro (Project Office) Und noch eine Projektrolle, die in fast jedem Projekt unterschiedlich interpretiert wird. In der Literatur findet sich noch immer die Erklärung, ein Projektbüro sei ein stark erweitertes Projektsekretariat, das die verwaltungstechnische Unterstützung eines oder mehrerer Projekte darstellt. Sofern dieses Projektsekretariat über tiefe Projektmanagementkompetenz verfügt, kennt die Praxis derartige Einrichtungen tatsächlich unter dem Begriff Projektbüro. Häufig repräsentiert der Begriff Projektbüro jedoch innerhalb der Unternehmen eine Art „Projectmanagement-Competence-Center“, also eine fest etablierte Stelle, die interne Projektmanagement-Dienste anbietet. Externe Dienstleister haben längst erkannt, dass Unternehmen einen großen Bedarf an dem „Produkt“ Projektbüro haben und bieten heute praktisch jede Ausgestaltung des „Projektbüros“ an. Unabhängig davon, ob ein Projektbüro nun interner oder externer Natur ist, es gibt einige typische Aufgaben, die beiden Varianten gemeinsam sind. Das Projektbüro übernimmt zunächst die typischen Planungsaufgaben in der Durchführung, ist für die Erarbeitung und Einhaltung von Projektmanagement-Standards verantwortlich, führt das Projekthandbuch und alle Dokumentations- und Ablagesysteme,

Seite 90


© Frank Obels


übernimmt teilweise sogar kleine Coaching-Aufgaben für die Projektteammitglieder, führt Schulungen durch und – ist für alles da, was die Projektarbeit erleichtert. Sehr große Projektbüros fungieren als Multiprojektmanagement-Centren, die nicht nur viele Projekte gleichzeitig begleiten, sondern auch Querschnittsfunktionen übernehmen und Priorisierungen der einzelnen Projekte vornehmen.

Entscheidungsgremien Viele Projektmanager verbinden mit diesem Begriff noch immer eine Verwandtschaft zum Lenkungsausschuss. Bitte vergessen Sie es gleich wieder. Dies kann bei sehr großen Projekten tatsächlich der Fall sein, aber Sie wären überrascht, wenn Sie wüssten, wie viele „nicht-große“ Projekte es gibt. Seltsamerweise schreiben die Autoren gerne nur über Großprojekte. Dies trifft, wenn ich ehrlich bin, auch auf mich zu. Gerade in einem Linux-Projekt werden eine Menge Entscheidungen zu treffen zu sein, die man lieber einem Gremium statt einer Einzelperson überlassen möchte. So richte ich beispielsweise in jedem meiner Projekte einen Technologiebeirat ein, der sich aus ausgewiesenen IT-Fachleuten des Projektes und den Fachabteilungen zusammensetzt. Dieser Technologiebeirat trägt die fachliche IT-Verantwortung in meinen Projekten. Da ich ein starker Anhänger des Themenbereiches Projektmarketing bin, leiste ich mir ein weiteres Entscheidungsgremium, das über die Öffentlichkeitsarbeit eines Projektes befindet. Bauen Sie die Entscheidungsgremien, die Sie für notwendig halten, gleich zu Projektbeginn in Ihre Projektorganisation „sichtbar“ ein und definieren Sie detailgetreu die entsprechenden Prozesse. Bei Linux-Projekten empfehle ich Ihnen in jedem Fall ein Entscheidungsgremium einzurichten, das wir nachfolgend einmal „Technical Design Board“ nennen wollen. In diesem Board sollten Sie die Hersteller Ihrer IT-Systeme versammeln und dort die Verantwortung bezüglich eines reibungslosen technischen Zusammenspiels konzentrieren.

Qualitätsmanager Die Empfehlungen eines Entscheidungsgremiums gilt es umzusetzen und auf eine diesbezüglich festgelegte Qualität zu achten. Diese Position sollten Sie in einem LinuxProjekt unbedingt besetzen. Der Qualitätsmanager ist für den Aufbau und die Überwachung eines umfassenden Qualitätsmanagements im Projekt zuständig. Er hat Tests mit zu planen, zu steuern und zu überwachen. Der Qualitätsmanager berichtet an den Projektleiter. Sofern Sie, wie nachfolgend beschrieben, ein Testteam einrichten, so berichtet dieses an den Qualitätsmanager.

© Frank Obels


Seite 91


Testteam Auf ein starkes Testteam verzichte ich in keinem meiner IT- und Linux-Projekte. Seine Aufgabe besteht darin, Herstelleraussagen zu überprüfen, Funktions- und Kompatibilitätstests durchzuführen und jede mögliche technische Eventualität geplant und getestet zu haben. Gerade beim Thema Linux ist das Testteam von herausragender Bedeutung.

Projektmitarbeiter „Das Kapital eines Projektes“ werden die Projektmitarbeiter und Teammitglieder häufig genannt. Die Projektmitarbeiter sollten über vielfältige Fachqualifikation verfügen und zur fachlichen Lösung der Herausforderung beitragen können. Die sogenannten „soft skills“ sollten zumindest erkennbar sein, damit das Projektklima nicht zu sehr belastet wird. Linux-Spezialisten sind ein ganz besonderer Menschenschlag (was keineswegs negativ gemeint ist). Seien Sie sich als Projektleiter bewusst, dass Sie mit der enormen Fachkompetenz und dem Ehrgeiz häufig einen Mangel an Verbalkommunikation „einkaufen“. Linux-Menschen schreiben lieber E-Mails als einen Vortrag zu halten und programmieren lieber als zu dokumentieren. Es liegt an dem Projektmanager, die Stärken dieser Mitarbeiter „passend“ einzusetzen. Grundsätzlich sollten die Projektmitarbeiter so früh wie möglich in das Projekt integriert werden, sofern möglich bereits in der Vorprojektphase oder der Voruntersuchung. Neben den fachlichen Beiträgen, die diesbezüglich zu erwarten sind, dient ein frühes Einbeziehen auch der persönlichen Identifikation mit dem Projekt. Linux-typische Projektmitglieder können Systemanalytiker und Systemarchitekten sein, Datenbankspezialisten oder auch Konfigurationsmanager. Inwieweit Sie diese zu eigenständigen Projektrollen machen, hängt ganz von der Art und Größe Ihres Projektes ab.

Externe Dienstleister Ich habe noch kein größeres IT- oder Linux-Projekt erlebt, das ohne die externe Unterstützung von Beratern auskam. In dieser Projektrolle „sammeln“ sich auch Hard- und Softwarelieferanten sowie Linux-Systemspezialisten. Häufig sind Lieferanten eine besondere Risikobetrachtung wert, ebenso eine restriktive Vertragsgestaltung empfehlenswert. Nichts ist in einem Linux-Projekt schlimmer, als zu spät gelieferte Systeme, falsch konfigurierte Komponenten oder Produktlinienänderungen und damit die Unmöglichkeit zur Erbringung der vereinbarten Vertragsleistung.

Seite 92


© Frank Obels


Arbeitsgruppen Arbeitsgruppen können während des gesamten Projektes oder nur einer Teilphase bestehen und werden gebildet, um völlig eigenständig bestimmte Themen- oder Aufgabenbereiche zu lösen. Ein beliebtes Thema für eine Arbeitsgruppe bei einer Client-Migration auf Linux ist beispielsweise die unternehmensweite Umstellung aller Powerpoint-Präsentationsvorlagen auf StarOffice oder OpenOffice. Der Einsatz von Arbeitsgruppen bietet sich bei eindeutig abgrenzbaren Teilaufgaben, fachtechnischer Natur, sehr an – die Betreuung kann von einem einzelnen Projektmitarbeiter übernommen werden.

Dokumentation der Projektrollen Nachstehend finden Sie eine einfache Tabelle zur Anregung, wie Sie die von Ihnen besetzten Projektrollen am besten dokumentieren können. Hier steht der Name Ihres Projektes

Projektorganisation Projektrolle Projektauftraggeber Projektleiter Projektteammitglieder

Projektmitarbeiter

Projektcoach

Stand: das.gewünschte.Datum Name Aufgabenbereiche »…

Zeitanteil 100 %

»… »… »… »… »… »… »… »… »…

30 %

»… »…

Sofern es Ihr Projekteigner ermöglicht, bringen Sie solche Formulare und weitere typische Projektdokumentation in eine Projekt-Intranet-Site. Auch das Erstellen der Formulare lässt sich online erledigen. Die Akzeptanz Ihrer „Community“ ist dann, gerade in Linux-Projekten, als sehr hoch anzunehmen.

© Frank Obels


Seite 93


3.1.5 Projektumwelt und –umfeld Im nächsten Schritt sollten Sie sich schnell klar darüber werden, was um Ihr Projekt herum so alles passiert. Schauen Sie sich diese Nachbarschaft genau an. Sie sollten nicht nur die Vorgeschichte Ihres Projektes kennen (das Sie vielleicht gar nicht von Anfang an erleben durften), sondern auch die „Nachgeschichte“, also was mit dem „Produkt“ nach Projektende geschehen soll, ob es Folgeprojekte geben wird oder welche anderen Informationen für wichtig gehalten werden. Die einfachste und bewährteste Methode ist die gemeinsame Entwicklung der Analysen an einem Flipchart. Die Ergebnisse fotografieren Sie mit einer Digitalkamera ab. Bezüglich der gemeinsamen Entwicklung bieten sich die Methoden Brainstorming und Brainwriting an, als Darstellungsinstrument sind Mindmaps nach wie vor die erste Wahl. Was ist das Ziel? Es soll, möglichst umfassend, festgestellt und dokumentiert werden, welche Erwartungen an das Projekt gestellt werden, welche Interessen und Haltungen bezüglich des Projektthemas, des Projektes, des Projektleiters bestehen und was diese Daten für einen positiven oder negativen Projektverlauf bedeuten können. Kontextanalyse Die Kontextanalyse hat zum Ziel, die Bedingungen rund um das Projekt zu ergründen und daraus wichtige Rückschlüsse für die Projektsteuerung zu ziehen. Es gibt eine sachliche, zeitliche und soziale Ebene der Kontextanalyse. Häufig bleibt unerwähnt, dass der Projektkontext im Umkehrschluss zur exakten Projektabgrenzung dienen kann und muß.

Sachlicher Projektkontext In der Analyse des sachlichen Kontextes werden  die Bedeutung des Projekts im und für das Unternehmen betrachtet,  der Zusammenhang zwischen der Unternehmensstrategie und dem Projekt herausgearbeitet,  die Beziehung zwischen dem Projekt und anderen Projekten untersucht und  der Zusammenhang zwischen Projekt und dem zugrunde liegenden Business Case untersucht.

Seite 94


© Frank Obels


Abbildung 9: Betrachtungsparameter der sachlichen Kontextanalyse

Bei Linux-Projekten sollten Sie in jedem Fall mögliche Zusammenhänge mit anderen Projekten untersuchen. Die Beziehungen zu derartigen Projekten können synergetischer oder konkurrierender Natur sein.

Zeitlicher Projektkontext Durch die Definition des Projektstart- und -endtermins ist Ihr Projekt zeitlich eingegrenzt. Die Kenntnis über die Ereignisse oder die Motive, die zum Projekt geführt haben, sind wichtig für das Verständnis bezüglich des Projekts und der Entwicklung der „passenden“ Projektstrukturen. Ein vollständiger Informationstransfer aus der Vorprojektphase in das Projekt ist daher elementar. Auch die Erwartungen, die nach dem Projekt an das Projektprodukt gestellt werden oder weitere mögliche Konsequenzen, werden Ihre Strategien zur Gestaltung der Projektumwelt-Beziehungen beeinflussen.

Abbildung 10: Betrachtungsgegenstand der zeitlichen Kontextanalyse

© Frank Obels


Seite 95


Häufig ist bei Linux-Projekten zu beobachten, dass im Vorfeld ein erbitterter Kampf zwischen zwei IT-Bereichen stattgefunden hat, wobei das eine „Lager“ ein kommerzielles Betriebssystem upgraden wollte und die Gegenpartei auf Linux migrieren wollte. Auch wenn sich Linux durchgesetzt hat, müssen Sie, als Projektleiter die „Anderen“ mit ins Boot kriegen. Das können Sie bei der Rollen- und Teambesetzung sofort berücksichtigen. Sozialer Projektkontext Die soziale Projektkontextanalyse versucht nun ihrerseits, die Beziehungen zur Projektumwelt und seinen Vertretern abzubilden. Hier wird also bereits das erste Mal untersucht, wer welche Rolle spielt. Projektabgrenzung und –kontext im Gesamtzusammenhang Führen Sie sich bitte zunächst noch einmal die Betrachtungszusammenhänge vor Augen. Die sachliche Kontextanalyse kann in einem Linux-Projekt anspruchsvoller sein als in anderen Projekten. Bezüglich der Analyse der Zusammenhänge werden Sie hier Hard- und Softwarerichtlinien der Hersteller zu berücksichtigen haben. Auch die Abhängigkeiten zu anderen IT-Projekten werden eine gewichtige Rolle spielen. Sie können beispielsweise keine Migration der E-Mail-Clients auf Linux vornehmen ohne die Auswirkungen eines gleichzeitig „laufenden“ Infrastrukturprojektes zu berücksichtigen.

Abbildung 11: Überblick Projektabgrenzung und -kontextanalysen

Seite 96


© Frank Obels


Projektumfeldanalyse (Stakeholderanalyse) Von der sozialen Kontextanalyse ist es nur ein kleiner Schritt zur Projektumfeldanalyse, die ich auch gerne als Stakeholder-Analyse bezeichne. Ich weiche von der gängigen Lehrmeinung ab, wenn ich die Projektumfeldanalyse als besonders detaillierte und tiefgehende soziale Kontextanalyse bezeichne. Es geht jetzt nicht mehr nur darum, wer sich für das Projekt „interessiert“, sondern Tendenzen, Strömungen und Einstellungen, die auf das Projekt projiziert werden, tiefer zu analysieren. Sollten Sie diesen Punkt für nicht so wichtig halten, beschweren Sie sich bitte während des Projektverlaufs nicht, wenn Sie über diesen Punkt stolpern werden. Anhand der untenstehenden Grafiken können Sie sich noch einmal den Ablauf vergegenwärtigen.

Abbildung 12: Ablaufschema einer Projektumfeldanalyse

© Frank Obels


Seite 97


Projektstakeholder sind Einzelpersonen, Gruppen oder Institutionen, die ein sichtbares oder verstecktes Interesse an Ihrem Projekt haben. Im Regelfall bezieht sich dieses Interesse auf den Verlauf des Projektes, das Projektergebnis oder aber auch die Entwicklungsrichtung des Projektes. Die Stakeholderanalyse ist eine vorgelagerte Risikobetrachtung, allerdings direkt auf Menschen bezogen. Neben den klassischen Stakeholderpositionen „Promotor“ und „Opponent“ sollten Sie auf die dritte Kategorie, die „Hoppers“ achten. Diese können heute auf Ihrer Seite sein und morgen gegen Ihr Projekt agieren. Das wichtigste bei der Projektumfeldanalyse ist es, möglichst das Gesamtbild zu entwickeln. Dazu gehören auch Allianzen (insbesondere Seilschaften), Abhängigkeiten und bestehende Feindschaften.

Belassen Sie es in Ihrem Interesse nicht bei einer einmaligen Projektumfeldanalyse. Ein soziales System ändert sich fortlaufend. Wiederholen Sie also regelmäßig die Stakeholderanalyse. Ihr professionelles Projektmarketing muss sich in späteren Analysen messen lassen können, indem die „Gegner“ weniger werden. Denken Sie an einen Maßnahmenkatalog.

Sie können sich zur Projektumfeldanalyse ein einfaches Formular entwerfen, in dem Sie die wesentlichen Tendenzen übersichtlich erfassen können. Nachstehend eine diesbezügliche Anregung. Hier steht der Name Ihres Projektes

Projektumfeldanalyse Personen-Gruppen-Betrachtung Personen Interessensgruppen

Seite 98

Stand: das.gewünschte.Datum Einstellung Macht+ Erwartungen position - Befürchtungen 


Maßnahmen wer - wann - was

© Frank Obels


Hier steht der Name Ihres Projektes

Projektumfeldanalyse Einflußgrößen-Betrachtung Sachlich-Inhaltliche

Stand: das.gewünschte.Datum Art des Konsequenzen

Maßnahmen

Einflußgrößen

Einflusses

wer – wann - was

3.1.6 Projektmanagementprozess Sie finden nachstehend die Darstellung des klassischen Projektmanagementprozesses, der mit dem Projektauftrag startet und mit der Projektabnahme endet.

Abbildung 13: Der Projektmanagementprozess

© Frank Obels


Seite 99


Der Projektstart Das ganz klare Ziel des Projektstarts muss es sein, das Know-how aus der Vorprojektphase nunmehr ins Projekt zu transferieren und dort zu etablieren und zu organisieren. Es müssen Projektziele vereinbart werden, Projektpläne erstellt werden, eine schlagkräftige Projektorganisation designed werden und das „soziale Projektsystem“ etabliert werden. Ein vorsichtiger Projektmanager wird die Planung von Maßnahmen zu Risikomanagement und – vermeidung durchführen, ein gemeinsames „Big Project Picture“ entwerfen, das auch die „Marschrichtung“ für das gesamte Projektumfeld darstellt. Von erheblicher Bedeutung sind die Initiierung erster Projektmarketingmaßnahmen und die Organisation der Projektdokumentation. Mit dem Projektstart lassen sich viele junge Projektmanager mächtig unter Druck setzen und beginnen, „drauf loszurennen“. Lassen Sie sich Zeit für eine solide Planung und den Aufbau Ihres sozialen Systems.

Projektcontrolling Hier geht es um die fortlaufende Feststellung „wo das Projekt steht“ sowie den richtigen Einsatz steuernder Maßnahmen, falls das Projekt in die eine oder andere Richtung „entgleitet“. Zentrales Instrument ist der Projektfortschrittsbericht. Im Regelfall verbindet das Unternehmen mit dem Begriff Controlling auch einen Bezug zur Wirtschaftlichkeit, die dann über alle Phasen eines Projektes ermittelt und überprüft wird.

Projektabweichung Hinter diesem ausgesprochen hübschen Begriff verbirgt sich der Umgang mit Projektkrisen und neuen Projektchancen, häufig an den Phasenübergängen des Projektes zu finden. Der Prozessverlauf ist grundsätzlich schwer gestaltbar, denn eine Projektkrise oder –chance stellen sich überraschend ein. Ich nenne in meinen Seminaren diesen Prozess deshalb auch „worst case scenario management“, denn Sie können sich im Regelfall nur auf das Entwickeln von Szenarien zur „Vorsorge“ oder „Schadensbegrenzung“ beschränken.

Seite 100


© Frank Obels


Projektabschluss Sie werden später noch sehen, dass dieser Prozess von erheblicher Bedeutung ist, denn es geht immerhin am Ende der Prozessschritte um die Abnahme des Projektergebnisses durch den Projektauftraggeber. Bis zu diesem Punkt müssen Sie mögliche Restarbeiten identifizieren und deren Fertigstellung planen, die Dokumentation abschließen, unter Umständen einen business case aus den Projekterfahrungen formulieren, die Nachprojektphase einleiten und den Transfer allen Know-hows und aller Erfahrungen in die Linie veranlassen.

Projektkoordination Projektkoordination ist der Prozess, der Sie vom Projektstart bis zum Projektabschluss in Bewegung hält. Seine Aufgabe ist es, die laufende Sicherung des Projektfortschritts und der Informationsversorgung der Projektteams zu gewährleisten. Und was macht man nun in der Projektkoordination? Stellen wir uns für einen Moment vor, nicht der Projektleiter sondern eine weitere Person würde diese Position innehaben. Dieser Projektkoordinator würde sich um die Qualitätssicherung der (Zwischen-)Ergebnisse von Arbeitspaketen und die laufende Kommunikation der Projektmanager mit dem Projektteam und dem Projektauftraggeber kümmern. Der Projektkoordinator gestaltet unaufhörlich die Beziehungen zu allen projektrelevanten Umwelten, disponiert die Projektressourcen und ist verantwortlich für das permanente Projektmarketing.

3.1.7 Warum scheitern Projekte Lassen Sie mich diesen Abschnitt mit den Erfahrungen der Bibel beginnen. Da steht zu lesen, dass Gott den Menschen erschuf, erst Mann, dann Frau. Schon dieses „Ur-Paar“ verursachte die hinlänglich bekannten Probleme. Als aus dem Paar eine Familie wurde, ich nenne diese ab jetzt Gruppe, entstanden massive Gruppenprobleme. Es kam zu Reibereien und schließlich zerbrach die Gruppe, nachdem Kain den Abel erschlug und ins Land Nod, jenseits von Eden, verbannt wurde. Seit diesem Tag gibt es Probleme innerhalb von Gruppen und der diesbezüglichen Zusammenarbeit. Gruppenarbeit dreht sich stets um zwei Dinge: die Aufgabe und die Art und Weise, wie diese bewältigt werden kann. Letzteres nennt man heute Prozessmanagement. Schon zu Beginn dieses Buches sprach ich von den psycho-sozialen Faktoren eines Projektes.

© Frank Obels


Seite 101


3.2

Vorprojektphase

Vor dem tatsächlichen Beginn eines Projekts steht die Vorprojektphase. Sie gehört noch nicht zum eigentlichen Projekt sondern dient lediglich der Vorbereitung der Projektentscheidung durch den späteren Projektauftraggeber. Nicht zwingend wird aus jeder Vorprojektphase auch ein Projekt! Unternehmen mit einer ausgeprägten Projektkultur haben eine hohe Quote "abgewiesener" Vorprojekte. Dies zeigt, dass die mit der Projektentscheidung betrauten Auftraggeber Prioritäten setzen und nur unternehmensbedeutsame Projekte bewilligen. Die Vorprojektphase unterteilt sich in der Regel in die  Projektinitiierung,  Grobplanung und  Projektentscheidung.

3.2.1 Projektinitiierung Eine Projektidee entsteht auf die unterschiedlichsten Art und Weisen, entweder durch einen Impuls innerhalb des Unternehmens oder von Außen kommend. Die Mitarbeiter eines Unternehmens sollten immer das Recht haben (übrigens auch die Pflicht), Projekte in ihrem Fachbereich zu initiieren. Dabei sollten die Mitarbeiter die Projektkriterien kennen, damit sie diese für ihre Projektidee überprüfen können. Wird eine Idee grundsätzlich für nicht uninteressant gehalten, kann die Grobplanung erfolgen.

3.2.2 Grobplanung Die Grobplanung konkretisiert und strukturiert die Projektidee. Sie sollten sich zuallererst eine Checkliste aufbauen, was in Ihrem Unternehmen von einer Projektgrobplanung an Inhalten erwartet wird.

Eine Projektgrobplanung kann folgenden Inhalt haben: 

Beschreibung des möglichen Projekts  Wer hatte die Idee/Was führte zu der Idee?  Auf welchen Sachverhalten/Dokumenten/Studien/Projekten gründet die Idee?  Kurzbeschreibung der Ausgangs- oder Problemsituation  Welche Priorität wird vorgeschlagen, Begründung?  Bestehen Querverbindungen zu anderen Projekten?  Beschreibung des Nutzens dieses Projektvorschlags!

Seite 102


© Frank Obels


 Beschreibung des vorgeschlagenen Inhalts!  Beschreibung der Projektziele, Teilprojektziele und „Nicht-Ziele“  Abgrenzung des Projektes und Projektkontextbeschreibung!  Beschreibung der Messgrößen eines Projekterfolgs!  Verweis auf bestehende Business Cases! 

Beschreibung einer möglichen Projektorganisation  Beschreibung einer möglichen Projektorganisation  Beschreibung der benötigten Skills der aufgeführten Projektrollen!  Vorschlagsnamensliste zur Besetzung der Projektrollen!  Beschreibung und Begründung der benötigten Ressourcen!  Darstellung, in welchen Bereichen externe Unterstützung benötigt wird!  Vorschlagsliste der externen Dienstleister (z.B. bewährte externe Partner).



Darstellung der voraussichtlichen Eckdaten des Projektvorschlags  Darstellung eines groben Terminplans mit Projektbeginn und –ende.  Darstellung möglicher Meilensteine!  Darstellung möglicher Vorgänge, Tätigkeiten, Abhängigkeiten.  Darstellung der geschätzten Projektkosten, Sachaufwände und Betriebskosten!  Beschreibung, ob und welche Wartungs- oder Pflegeverträge abzuschließen sind!



Betrachtung möglicher Risiken des Projektvorschlags  Kurzdarstellung möglicher Projektrisiken und Chancen!  Eintrittswahrscheinlichkeit und Auswirkung der Risiken!  Beschreibung etwaiger Erfahrungswerte!

Betrachten Sie diese Auflistung bitte als Anregung und nicht als „Romanvorlage“. Die Grobplanung dient einer Führungskraft aus dem Unternehmen als Entscheidungsvorlage, ob der Projektvorschlag weiterverfolgt werden soll. Und Manager lieben nun einmal eine Darstellung im Stile des sogenannten Executive Summary". In Ihrem eigenen Interesse beschränken Sie sich auf wenige DIN A4 Seiten, drei Seiten erachte ich als das absolute Höchstmaß.

3.2.3 Projektentscheidung Der Fachvorgesetzte oder spätere Projektauftraggeber trifft anhand weiterer unternehmerischer Kriterien die Entscheidung, ob der Projektvorschlag weiterverfolgt wird oder nicht. Führungskräfte sollten die Entscheidung für oder wider eine Projektidee nach Möglichkeit mit dem Projektideegeber treffen. Ist dies nicht möglich, sollte für den Ideeninitiator zumindest nach einem Gespräch klar ersichtlich sein, warum sich gegen das Projekt entschieden wurde. Geschieht dies nicht, werden die Mitarbeiter früher oder später keine neuen Projektideen mehr „produzieren“ sondern sich in erheblichem Frust „baden“. Auch bei positivem Bescheid sollte der Mitarbeiter ein kurzfristiges Feedback erwarten dürfen.

© Frank Obels


Seite 103


Verlieren Sie nach einer Entscheidung zugunsten eines Projekts nicht unnötig Zeit und beginnen Sie zügig mit der Umsetzung.

3.3

Projektdefinition

Wir befinden uns bereits in der ersten echten Projektphase – und Sie haben es kaum gemerkt, oder? In dieser Phase wird alles unternommen, um das Projekt hinreichend detailliert zu beschreiben und abzugrenzen. Dabei spielt nun die Messbarkeit und das konkrete Formulieren von Projektzielen eine ganz erhebliche Rolle. Die Projektdefinition ist am Ende eine klare und verbindliche Vereinbarung zwischen dem Projektauftraggeber und dem Projektleiter und soll ein gemeinsames Verständnis über die wesentlichen Projektzusammenhänge herstellen. Die Projektdefinition wird schriftlich verfasst und ist erster wichtiger Bestandteil der zu eröffnenden Projektakte. Bei der Definition des Projekts sind die Richtlinien und Vorgehensweisen zu berücksichtigen, die sich aus der Projektkultur des betreffenden Unternehmens ergeben. Rufen Sie sich bitte nochmals in Erinnerung, was ich bezüglich der Bedeutung der frühen Projektphasen für Ihr Linux-Projekt ausführte. In dieser ersten „offiziellen“ Projektphase säen Sie bereits, was später zu Erfolg oder Misserfolg werden wird.

3.3.1 Design der Projektorganisation Die Organisationsaspekte eines Projektes haben wir bereits angesprochen. Das dort vorgestellte Formblatt kann Ihnen nun weiterhelfen. An dieser Stelle möchte ich insbesondere auf die Zusammensetzung des Projektteams eingehen. Es ist ein beliebter Fehler, eine wohl ausschauende Projektorganisation zu Papier zu bringen, ohne sich bezüglich wichtiger Faktoren wie der Mitarbeiterauswahl Gedanken zu machen. Qualifikation der Mitarbeiter Ein Linux-Projekt steht und fällt mit der richtigen Mitarbeiterqualifikation. Sollten Ihnen hochqualifizierte Kollegen in nicht ausreichendem Maße zur Verfügung stehen, planen Sie ein entsprechendes Zeitfenster für Schulungen ein. Achten Sie insbesondere auf überqualifizierte Mitarbeiter. Deren Unterforderung im Projekt wird schnell zu einem „Klimaproblem“ führen. Freistellung der Mitarbeiter Ihre Teamkollegen sollten sich bei einem Linux-Projekt vollständig auf die anspruchsvolle Aufgabe konzentrieren können. Fordern Sie die absolute Freistellung vom Tagesgeschäft beim Projektauftraggeber ein.

Seite 104


© Frank Obels


Belastbarkeit und Motivation der Projektmitarbeiter Die Frage nach der Motivation und Belastbarkeit der Mitarbeiter ist für ein Linux-Projekt von entscheidender Bedeutung. Sie können keine Mitarbeiter brauchen, die versteckte Widerstände gegen das Thema haben oder nicht bereit sind, sich über das Maß hinaus für das Projekt zu engagieren. Soziale Kompetenz der Projektkollegen Auch wenn diese praktisch nicht abfragbar ist, sollten Sie einen Eindruck bekommen können, ob die Bereitschaft besteht, sich in das Team zu integrieren. Im Linux-Umfeld haben Sie gute Chancen Einzelkämpfermentalitäten mit nur sehr schwach ausgeprägten Kommunikationsfähigkeiten anzutreffen. Ein ausgesprochen wichtiger Aspekt der Projektorganisation ist die Einbindung eines oder mehrerer Lieferanten, dies werden in Linux-Projekten zumeist Hard- oder Softwarelieferanten sein. Diese bringen im Regelfall ein eigenes Projektteam mit, oft mit einem eigenen Projektleiter. Da es keine Über- oder Unterordnung für diese Fälle gibt, besteht nunmehr eine gleichgewichtige Kunden-Lieferanten-Beziehung. Diese Tatsache müssen Sie in Ihrer Projektorganisation berücksichtigen.

Junge Projektleiterkollegen machen häufig einen Kardinalfehler bei der Projektorganisation bezüglich ihrer eigenen Person. Sie übernehmen fachliche Aufgaben und arbeiten aktiv im Projektteam mit. Unbeabsichtigt vernachlässigen sie damit ihre Aufgaben als Projektmanager, was erst zu einem stetig anwachsenden Arbeitsaufwand im Team führt, dort dann zu Unzufriedenheit und schließlich gar zum Autoritätsverlust des Projektleiters. Sorgen Sie daher dafür, dass Sie als Projektleiter keine fachlichen Aufgaben innerhalb des Projektes übernehmen. Und schließlich ein Wort zur Größe des Projektteams. Je größer ein Projektteam wird, umso stärker steigt (überproportional) der Koordinationsund Kommunikationsaufwand. Eine Teamgröße von acht bis zehn Mitarbeitern lässt sich noch gut bewältigen. Ist das in Ihrem Projekt so nicht möglich, denken Sie über die Bildung von Teilprojekten nach, ebenso über eine Unterteilung in Kern- und erweitertes Projektteam.

3.3.2 Das Kick-off Meeting Was früher einmal Projektstartsitzung hieß, bezeichnet heute, unter dem Namen „Kick-off Meeting“, die Auftaktveranstaltung für alle am Projekt Beteiligten. Es bietet die Möglichkeit, sich kennen zu lernen und die Zielsetzung des Projektes sowie die geplante Vorgehensweise vorgestellt zu bekommen.

© Frank Obels


Seite 105


Sie sollten sich für dieses Auftaktmeeting eine detaillierte Agenda erstellen und diese im Vorfeld versenden. Das Kick-off Meeting ist nunmehr Ihr erster großer „Auftritt“ als Projektleiter. Sie befinden sich im Spannungsfeld der Erwartungen der Projektmitarbeiter und der Lenkungsausschussmitglieder, die ebenfalls anwesend sein müssen. Bereiten Sie bitte entsprechend eine Teilnehmerliste vor. Und bitte: lassen Sie sich nicht einreden, die Mitglieder des Lenkungsausschusses müssen am Kick-off nicht teilnehmen. Ihre Projektteams und die externen Partner und Lieferanten erwarten dieses Symbol der absoluten Unterstützung und Bedeutung – und würden das Gegenteil unterstellen, wenn der Lenkungsausschuss nicht vollständig anwesend wäre.

Agenda Kick-off Meeting Bisheriger Projektname: Datum: Ort der Sitzung: Dauer der Sitzung: Eingeladene Teilnehmer: Mögliche Tagesordnungspunkte: - Begrüßung - Vorstellung des Projektes: Aufgaben und Ziele bisher - Vorstellungsrunde Anwesende (Erwartungen, Funktion/Rolle, individuelle Ziele, Qualifikation) - Rückblick auf die Vorprojektphase - Gemeinsame Analyse der Problemstellung - Organisatorisches (Projektorganisation, Protokollierung, regelmäßige jour-fixe’s) - Festlegung des endgültigen Projekttitels - Konkretisierung der Projektziele (Qualität, Zeit, Kosten) - Projektabgrenzung und Projektkontextanalyse - Weitere Rahmenbedingungen des Projekts - Formulierung des Projektauftrags - Festlegung der Projektrichtlinien - Besprechung des Projektplans - Klärung der weiteren Vorgehensweise (Aufgaben, Termine) - Klärung offener Punkte - Verabschiedung

Abbildung 14: Checkliste für das Kick-off Meeting

Seite 106


© Frank Obels


Da Sie in einem Linux-Projekt praktisch immer (Stand 2003) mit Externen zu tun haben, nutzen Sie den formalen Druck eines Kick-offs auch dazu, die Spielregeln bezüglich der Aufwandsdokumentation der Externen und Lieferanten festzulegen. Es wird Ihnen in einer solchen hochkarätigen Runde, noch dazu bei einem Mangel an gegenseitiger Vertrautheit, niemand ernsthaft widersprechen, wenn Sie gewisse Richtlinien vorgeben. Das Internet ist voll von „Online-Fertigangeboten“ bezüglich der Erfassung des Projektaufwands. Unter www.timelancer.de finden Sie ein Beispiel, wie einfach und effizient so eine Aufgabe realisiert sein kann. Achten Sie besonders auf das flexible Verteilen der Aufwände auf beliebig viele Kostenstellen – Ihr Controller kommt ohnehin früher oder später mit diesem Wunsch.

3.3.3 Definition der Projektziele

Kein Projekt ohne absolut eindeutige Projektziele! Die meiste Arbeit diesbezüglich sollte bereits im Kick-off Meeting erfolgt sein. Jetzt kommt der letzte Feinschliff, die optische Aufbereitung, ein abschließender Check auf Widerspruchsfreiheit und schließlich die Überprüfung hinsichtlich der Messbarkeit der Projektziele. Nur so ist am Ende eine objektive Projektbewertung möglich. Sollten Sie dieses Thema nicht gewissenhaft und umfassend abschließen, haben Sie das Projekt mit höchster Sicherheit in die Nähe des Scheiterns gerückt. Das bestätigen nicht nur die Statistiken, sondern auch die Praktiker. Eine besondere Herausforderung ist die Unterteilung der Projektziele. Neben den inhaltlichen Zielen, die die fachlichen Ergebnisse des Projektes qualitativ und quantitativ beschreiben (wichtig sind die Qualitätsziele), sind – im Hinblick auf die Projektabwicklung – Ziele für den Zeit- und Ressourcenbedarf zu definieren. Sie finden in der Literatur diesbezüglich den Hinweis auf das Spannungsfeld der Ziele zueinander, dargestellt in einem grafischen Dreieck. Man möchte damit erklären, dass, wenn man einen der Bereiche (beispielsweise erhöhte Qualität) verändert, dies zwingend Auswirkungen auf einen oder beide der anderen Bereiche haben muss (beispielsweise höhere Kosten und längere Dauer).

© Frank Obels


Seite 107


Abbildung 15: Spannungsfeld der Projektziele

Projektziele sollten in Teilziele und/oder messbare Erfolgskriterien unterteilt werden. Es sollte immer versucht werden, Projektziele so weit wie möglich in konkreten Zahlen und Fakten auszudrücken, da sie wesentliche Steuerungsgrößen für die Projektlenkung und das Projektcontrolling darstellen.

Projekt: Ziele:

1. Projektziel 1.1. Teilziel 1.2. Teilziel 1.3. Teilziel

2. Projektziel 2.1. Teilziel 2.2. Teilziel 2.2.1. Erfolgskriterium

3. Projektziel 3.1. Teilziel 3.2. Teilziel ….. Abbildung 16: Formularvorschlag Projektzieleplan

Seite 108


© Frank Obels


Wenn Sie alle Projektziele aufgestellt haben, können Sie diese anhand der folgenden Checkliste prüfen:        

Die Projektziele und die daraus abgeleiteten Teilziele sind vollständig. Die Formulierungen sind unmissverständlich und lassen keine unterschiedlichen Interpretationen zu. Es bestehen keine Widersprüche zwischen den Zielen. Alle Ziele sind erreichbar und damit realistisch. Die Projekt- und Teilziele sind lösungsneutral formuliert. Die Projekt- und Teilziele sind mess- und kontrollierbar. Die Projektziele wurden schriftlich dokumentiert und sind für das Projektteam akzeptabel und erstrebenswert. Die Ziele sind mit dem Auftraggeber abgestimmt!

Formulieren Sie nicht zu viele Projektziele – Sie wollen Ihre Ziele doch sicherlich auch erreichen. Verwenden Sie Ihre Energie besser auf die Konkretisierung und Detaillierung der Ziele und Erfolgskriterien. In der Praxis hat es sich bewährt, die Ziele in „Muss“- und „Kann“-Ziele zu unterteilen.

3.3.4 Der Projektauftrag Der Projektauftrag bildet den Abschluss der Projektdefinition und sollte, nach all den gesammelten Informationen, das Dokument sein, das die gesamte Beschreibung des Projektes inklusive der Projektfreigabe enthält. Es ist in einem Projekt sehr hilfreich, wenn zwischen dem Projektauftraggeber und dem Projektleiter das gemeinsame Verständnis vorhanden ist, den Projektauftrag als Vertrag anzusehen. Und ein Vertrag ohne Unterschriften gilt in der Projektpraxis als nicht abgeschlossen (die Rechtsanwälte unter Ihnen sehen mir diese Ungenauigkeit bitte nach) – bedenken Sie das bitte. Und vielleicht erinnern Sie sich, dass Verträge unmissverständlich und klar formuliert sein sollten, damit es nicht zu späteren Streitigkeiten kommt.

© Frank Obels


Seite 109


Ein Projektauftrag enthält in der Regel folgende Punkte:         

Projekttitel, Projektnummer Projektstart- und Endereignis, -termine Beschreibung der Ausgangs-/Problemsituation und des Projektes Projektziele und Hauptaufgaben Projektorganisation (Auftraggeber, Lenkungsgremium, Projektleiter, Projektmitarbeiter, externe Dienstleister, etc.) Projektressourcen und Kosten wesentliche Termine, Meilensteine, Projektphasen Projektrisiken und –chancen Projektfreigabe.

Es ist Ihr Fingerspitzengefühl, das den „Tiefegrad“ eines solchen Dokuments festlegt. Sie finden nachstehend ein Arbeitsformular, das ich gerne als Kurzinformation an mir wichtige Projektunbeteiligte weiterreiche.

Abbildung 17: Beispiel eines Projektauftragformulars

Seite 110


© Frank Obels


3.4

Projektplanung

Die Projektplanung setzt formal erst ein, wenn der Projektauftrag ausdrücklich genehmigt und unterschrieben wurde. Die Projektplanung ist der Einstieg in die Frage „und was machen wir nun?“ Das zukünftige Handeln soll so früh und so präzise wie möglich gedanklich vorweggenommen und dokumentiert werden. In den diversen Lehrbüchern erhalten Sie mit großem Nachdruck den Hinweis, wie wichtig eine gewissenhafte Projektplanung für den Projekterfolg ist. In jedem Fall sollten Sie mitnehmen, dass in der frühen Phase der Projektplanung noch alles möglich ist. Sie haben nur in dieser Phase die größte Entscheidungsfreiheit bei minimalen Projektkosten. Haben Sie sich entschieden, Ihrem Haus ein Walmdach aufzusetzen und fällt Ihnen mitten in der Projektdurchführung ein, dass Sie doch lieber ein Flachdach hätten, so wird das halt teurer als wenn Ihnen das während der Planungsphase eingefallen wäre. Sie finden nachstehend einmal aufgeführt, welche Fragen Sie sinnvollerweise während der Projektplanungsphase stellen (und beantworten) sollten. W-Frage

Aufgabe

Ergebnis

Projekt strukturieren

Projektstrukturplan (PSP)

(wer, was, warum, wann, wie, wo)

Was ist im Projekt zu tun?

Projekt PSP Methode Projekt PSP Prinzip Wer macht was?

Verantwortungen (und teilweise Ressourcen) zuordnen

Vorgangsplan Arbeitspakete Arbeitspaketdefinition

Was sind wichtige Ergebnisse?

Meilensteine bestimmen

Arbeitspaketliste Meilensteinplan

Wann will ich diese überprüfen? Wann müssen die Arbeiten ausgeführt werden?

Ablauf definieren

Meilensteindefinition Terminplanung Balken- und Netzplan Abhängigkeitenplan

Welche Voraussetzungen und Abhängigkeiten bestehen?

Puffer- und Pfadplan Vorwärtsrechnung

Wie stellen sich Aufwand und Kosten dar?

Aufwand ermitteln

Rückwärtsrechnung Ressourcenplan

Kosten ermitteln

Aufwandsschätzung Kostenplan

Wo kann ich optimieren? Wie sieht das im Gesamtzusammenhang aus? Welche Projektrisiken bestehen?

© Frank Obels

Pläne straffen Gesamtplan erstellen

Kostenschätzung Planoptimierung Projektgesamtplan

Risikobetrachtung

Risikoanalyse


Seite 111


Da eine Projektplanung immer in die Zukunft gerichtet ist, werden während des Projektverlaufs Änderungen vorzunehmen sein. Eine Projektplanung ist deshalb immer ein iterativer Prozess, eine regelmäßige Überarbeitung und Korrektur wird erforderlich sein. Bedenken Sie bitte auch, dass Sie niemals allumfassend geplant haben können. Erfahrungsgemäß bleiben etwa 20 Prozent, egal wie gut Sie planen, nicht planbar, das fängt schon bei Kleinigkeiten wie krankheitsbedingtem Personalausfall oder unerwarteten Stakeholderreaktionen an. Die Projektplanung hat zum Ziel, ein schlüssiges, zusammenhängendes Gesamtbild des Projektes zu erstellen, das sowohl die Projektausführung als auch die Projektsteuerung lenkt. Dieses Gesamtbild nennen wir für den Moment Projektplan. Der Projektplan wird verwendet:      

Zur Steuerung der Projektausführung. Zur Dokumentation der Projektplanungsannahmen. Zur Dokumentation der Projektplanungsentscheidungen. Zur Erleichterung der Kommunikation zwischen den Stakeholdern. Zur Festlegung von Inhalt, Umfang und Terminierung der Schlüsselreviews des Managements. Als Basisplan für die Messung der Projektleistung und für die Projektsteuerung.

3.4.1 Projektstrukturplan (PSP) Der Projektstrukturplan beantwortet die Frage, „was ist in einem Projekt zu tun?“ Projektinhalt und -umfang werden im Projektstrukturplan abgebildet. Der Begriff „Inhalt und Umfang“ wird innerhalb eines Projektes zweifach verwendet. Zum einen versteht man unter dem Inhalt und Umfang des Produktes die Eigenschaften, die ein Produkt oder eine Dienstleistung durch das Projekt haben soll. Zum anderen beschreibt der Begriff Inhalt und Umfang des Projektes die Arbeit, die zu leisten ist, um ein Produkt mit den festgelegten Eigenschaften liefern zu können. Der Projektstrukturplan wird gerne „Vater aller Pläne“ genannt, er ist das zentrale Planungsinstrument Ihres Projektes. Das komplexe Linux-Projekt wird in überschaubare Teilaufgaben gegliedert. Schauen wir uns zunächst ein Beispiel eines solchen Plans an, um einen Eindruck zu erhalten, was sich dahinter verbirgt.

Seite 112


© Frank Obels


Projekttitel Teilaufgabe 1

Teilaufgabe 2

Teilaufgabe 3

Teilaufgabe ...

Projektmanagement

Abbildung 18: Schematische Darstellung eines Projektstrukturplans

Zunächst kann man sich vorstellen, dass im Falle eines großen Projektes der Plan zwar eine ganzheitliche Übersicht über das Projekt ermöglicht – jedoch aufgrund der Größe etwas „unhandlich“ wird. Deshalb wird die Projektaufgabe in mehrere Teilaufgaben unterteilt, um so die Komplexität des Gesamtprojektes zu verringern und Planung, Steuerung und Überwachung zu vereinfachen. Die hierarchisch niedrigste Position in jedem Zweig der Teilaufgaben wird Arbeitspaket genannt. Letztlich spielen diese „Arbeitsaufträge“ die wichtigste Rolle. Für Projektmanager typisch ist, dass sie sich selbst nicht vergessen. Kleiner Scherz! Sie finden in Projektstrukturplänen entweder im äußersten rechten oder linken Zweig die Teilaufgabe Projektmanagement. Hier werden all jene Aufgaben aufgelistet, die im Rahmen des Projektmanagements anfallen, also beispielsweise die Projektplanung, Projektdefinition, Projektcontrolling, Dokumentation und weiteres mehr. Der Projektstrukturplan wird zunächst vom Projektleiter oder einem sehr methodenkompetenten Projektbüro erstellt und erst, wenn die generelle Strukturierung erstellt ist, wird der Projektstrukturplan mit Projektteam vorgestellt.

© Frank Obels


Seite 113


Vermeiden Sie die sofortige Einbeziehung des Projektteams in die Entwicklung des Projektstrukturplans – dies führt zumeist zu endlosen Diskussionen und Dauermeetings. Erst wenn die Grobstruktur steht, sollte das Projektteam mitwirken. Fragen Sie sich gerade, wie Sie ein derartiges Organigramm für einen Projektstrukturplan bequem und einfach erstellen können? Lösung 1: Sie nutzen die Organigramm-Funktion der großen Office-Pakete. Lösung 2: Sie arbeiten mit einem Tool, das sich „WBS Chart for Project“ nennt. Dieses Tool exportiert den Projekt-Strukturplan anschließend sogar in einige Projektmanagementprogramme. Wenn Sie möchten, finden Sie unter http://www.criticaltools.com weitere Informationen. Wenn Sie unter Linux professionelles Projektmanagement betreiben wollen (und vielleicht lesen Sie ja auch deshalb dieses Buch) dann informieren Sie sich unter http://www.startwright.com/project1.htm, was es an leistungsstarken Programmen für die Projektarbeit gibt.

3.4.2 Methoden der PSP-Erstellung Haben Sie bei obigen Ausführungen auch den Eindruck gehabt, dass wir davon ausgehen, den Projektstrukturplan immer von oben nach unten zu entwickeln? Es geht auch andersherum, deshalb lassen Sie uns einen Blick auf die Methoden „werfen“. Es werden zwei PSP-Methoden unterschieden, um einen Projektstrukturplan zu erarbeiten: Top-Down – vom Abstrakten (Projektziel) zum Konkreten (Arbeitspaket) Das Top-Down-Vorgehen wird vor allem dann gewählt, wenn schon Erfahrungen mit ähnlichen Vorhaben vorliegen. Der Top-Down-Ansatz ist die bevorzugte Methode in der Projektplanung. Eine Projektaufgabe wird grob dargestellt und über Aufgaben und Teilaufgaben bis hin zum Arbeitspaket schrittweise konkretisiert. Das oben dargestellte PSP-Schema entspräche einem sehr kleinen Projekt. Je komplexer und umfangreicher ein Projekt wird, desto mehr Ebenen (Schichten) hat der PSP. Bottom-Up – vom Konkreten (Arbeitspaket) zum Abstrakten (Projektziel) Das Bottom-Up-Vorgehen wird entweder bei Projekten mit hohem Neuheitsgrad gewählt oder aber bei Projekten, bei denen die Details bekannt sind, bevor die Gesamtplanung abgeschlossen ist. Die Details werden via Kreativitätstechniken (Brainstorming, MindMapping) gesammelt und dann schrittweise, Ebene für Ebene, geordnet.

Seite 114


© Frank Obels


3.4.3 Prinzipien der PSP-Erstellung Es bleibt die Frage zu klären, nach welchen Kriterien man den Strukturplan unterteilt. So könnte man beispielsweise einfach die Phasen des Projektes in der ersten Gliederungsebene abbilden. Stimmt! Wenn Sie aber in einem Linux-Projekt diffizile Hard- und SoftwareProbleme lösen müssen (und dafür viele Projektressourcen benötigen), dann hätten Sie diese Themenunterteilung gerne auf Ebene 1. Gut, kürzen wir die möglichen Szenarien ab und betrachten uns untenstehende Darstellung. Dort finden Sie die drei wesentlichen PSP-Prinzipien. Der vierte Fall, der gemischtorientierte Projektstrukturplan, ist die Praxis.

Abbildung 19: PSP-Prinzipien anhand des Beispiels Hausbau

Objektorientierte Projektstrukturpläne sind nach konkreten Objekten bzw. Ereignissen gegliedert (bei einem Linux-Projekt z.B. Hardware, Software, Installationen). Bei tätigkeitsorientierten (funktionsorientierten) Projektstrukturplänen werden die Teilaufgaben nach Funktionen zusammengefasst. Also bei einem Linux-Projekt etwa IstAnalyse, Soll-Konzept, Implementierung.

© Frank Obels


Seite 115


Bei phasenorientierten Projektstrukturplänen bilden verschiedene Projektphasen (z.B. Konzeption, Entwurf, Detaillierung, etc.) die Teilaufgaben des Projektes. Der gemischtorientierte Projektstrukturplan enthält Elemente aus den drei zuvor genannten Herangehensweisen. Diese Form ist in der Praxis zu finden – ich wiederhole mich.

3.4.4 Arbeitspaketspezifikation Nachdem mit dem Projektstrukturplan die Unterteilung in kleinere, leichter zu handhabende Einheiten erfolgt ist, benötigen wir jetzt die „Liefergegenstände“ dieser Einheiten. Die korrekte Leistungsdefinition ist entscheidend für den Projekterfolg. Ohne eine solche exakte Definition stehen die Chancen sehr gut, dass sich die Projektkosten unvorhersehbar erhöhen, das Projekt laufend inhaltlich modifiziert werden muss, was den Projektrhythmus stört, zu Nacharbeiten führt, die Projektdauer somit verlängert und insgesamt zu einer absoluten Demotivation und Unproduktivität führt. Sie legen an dieser Stelle unter Umständen den Grundstein für einen Projekterfolg oder Misserfolg. Von der strukturellen Darstellung kann man leicht in eine tabellarische Darstellung wechseln und hat somit den „Vorschritt“ zur genauen Arbeitspaketspezifikation schnell vollzogen.

Seite 116


© Frank Obels


Abbildung 20: Vom Projektstrukturplan zur Arbeitspaketbeschreibung

Der Hauptschritt besteht in der detaillierten Beschreibung der Arbeitspakete, der sogenannten Arbeitspaketspezifikation. Hier werden Ziele, Verantwortungen, Kosten und Termine festgelegt. Ein entsprechendes Beispiel nachstehend. Für jedes Arbeitspaket ist ein entsprechendes Formular auszufüllen.

© Frank Obels


Seite 117


Abbildung 21: Beispiel einer Arbeitspaketspezifikation

Projektmanager, die erst am Anfang ihrer Karriere stehen, haben gerne Schwierigkeiten mit der Definition von Arbeitspaketen. Die Schwierigkeit liegt dabei aber nicht im Verfahren selbst, sondern in dem Mangel an Gespür, wie man treffsicher die Aufgabenbeschreibung und –abgrenzung vornimmt. Aber wenn Sie die ersten zehn Projekte hinter sich gebracht haben, werden Sie darüber lächeln. Sie haben sicherlich bemerkt, dass die Arbeitspaketspezifikation erst zum Ende der gesamten Projektplanung vollständig abgeschlossen werden kann. Es werden ja die Ergebnisse der Zeit-, Kosten- und Ressourcenplanung benötigt, die diesbezügliche Planung wurde aber noch nicht vorgenommen. Deshalb ist hier ein stufenweisen Vervollständigen der Arbeitspaketspezifikation erforderlich.

3.4.5 Meilensteine Diesen Abschnitt Meilensteine und den nächsten Abschnitt Terminplanung hätte ich eigentlich zusammenlegen können, den beides läuft stark verzahnt miteinander ab. Eine getrennte Betrachtung erscheint mir im Sinne unseres geistigen Verdauungssystems dennoch angebracht. Meilensteine sind wichtige Ergebnisse (Teilziele), die im Verlauf eines Projektes erreicht werden sollen. Wird der Meilenstein erreicht, können Entscheidungen über den weiteren Projektverlauf getroffen werden. Dies kann so weit führen, dass die Entscheidung getroffen Seite 118


© Frank Obels


wird, das Projekt abzubrechen. Meilensteine werden deshalb auch gerne als „Ausstiegspunkte“ aus einem Projekt bezeichnet. Zwei Meilensteine kennen Sie bereits, den Projektstart und das Projektende. Zur Beschreibung eines Meilensteins müssen ein oder mehrere Ergebnisse, bitte schön nachprüfbar, und die zugehörigen Termine definiert sein. Meilensteine markieren den Anfang und den Ende eines Projektabschnitts. Neben der Möglichkeit, den Projektverlauf mit Hilfe von Meilensteinen zu überwachen, sind Meilensteine auch sehr gut geeignet, die Motivation der Projektmitarbeiter zu stärken. Dieser psychologische Aspekt zeigt, dass das Erreichen eines Meilensteins ganz erheblich die Motivation des Projektteams stärkt. Zum einen deshalb, weil man mit einem Meilenstein ein konkretes Ziel vor Augen hat (das Projekt wird überschaubar), zum anderen, weil das Erreichen eines Meilensteins ein entsprechendes Erfolgserlebnis bewirkt. Sie sehen nachstehend ein Formularbeispiel bezüglich der Dokumentation eines Meilensteins.

Abbildung 22: Beispiel einer Meilensteinspezifikation

Mit der Überprüfung des Meilensteins sind Entscheidungen verbunden, die es zu treffen gilt. Ich mache dies an drei Fragen fest (siehe drei Kreise): 1. wurde der Meilenstein rechtzeitig erreicht? 2. wurden die gewünschten Ergebnisse erreicht? 3. wird das Projekt fortgesetzt? Wie Sie sicherlich schon vermutet haben, ist die Farbe grün gleichbedeutend mit „GO!“ (alles prima), gelb gleichbedeutend mit Problem und rot gleichbedeutend mit „STOP!“. © Frank Obels


Seite 119


Im schlimmsten Fall zeigt ein Meilenstein auf, dass bestimmte Arbeitspakete erneut bearbeitet werden müssen, da die Ergebnisse nicht den Erwartungen entsprachen. Der besseren Übersicht halber sollten Sie sich sämtliche Meilensteine in einer Übersichtstabelle darstellen, dies erleichtert den Überblick ganz erheblich. Nachstehend finden Sie die Darstellung einer einfachen Tabelle, die in der Praxis vollkommen ausreichend ist. Sollten Sie Detailinformationen zu einem Meilenstein benötigen, steht Ihnen ja die Detail-Definition zur Verfügung.

Hier steht der Name Ihres Projektes

Meilensteinplan Stand: das.gewünschte.Datum Geplantes Ergebnisse/Ziele

Meilenstein-Name

Status

Datum                

…. …. …. …. …. …. …. …. …. …. …. …. …. …. …. ….

3.4.6 Terminplanung Jetzt haben wir eigentlich alles, um eine detaillierte Terminplanung beginnen zu können. Sie finden in der Literatur häufig eine andere Planungsreihenfolge, nämlich die Ressourcenplanung vor der Terminplanung. Das diesbezügliche Argument lautet, dass erst anhand der zur Verfügung stehenden Ressourcen ein verlässlicher Terminplan aufgestellt werden kann. Ich widerspreche diesen Ausführungen nicht, habe aber ein anderes Projektverständnis der Praxis.

Seite 120


© Frank Obels


Wenn ein Kunde mir im Rahmen eines Projektauftrages seinen Realisierungswunsch mitteilt, so ist es für mich selbstverständlich, dass genau die Ressourcen zur Verfügung stehen, die das Projekt erfordert. Ich realisiere Projekte gerne schnell, dies auch zu Lasten eines höheren Ressourcenbedarfs. Fragen Sie diesbezüglich dringend die Meinung Ihres Auftraggebers ab, sollte das Projekt nur über knappe Mittel verfügen, lassen Sie lieber einen Anderen sich die Finger verbrennen.

Vorgangsdefinition und Reihenfolge Aus dem Projektstrukturplan und den Arbeitspaketen ergibt sich die Vorgangsliste. Sie enthält diejenigen Vorgänge, die durchgeführt werden müssen, um die im Projektstrukturplan festgeschriebenen Liefergegenstände und Teilliefergegenstände erbringen zu können. Dabei ist es notwendig, die Vorgänge so zu definieren, dass die Projektziele erreicht werden. Bisher habe ich aber noch nicht über die Anordnungsbeziehungen der Vorgangsfolgen gesprochen. Eine Aufgabe, die eine sehr hohe Genauigkeit erfordert, damit auf der Basis der entwickelten Ergebnisse ein realistischer und machbarer Terminplan erstellt werden kann. Um die Vorgangsbeziehungen abzubilden, können Sie sich auf eine tabellarische Darstellung beschränken. Sehr bewährt hat sich jedoch die Verwendung der Netzplantechnik, also eine grafische Darstellung der Vorgangsfolgen. Ein Netzplan, der gewissenhaft aufgestellt wurde, verhindert insbesondere den „Dominoeffekt“ der Terminverzögerungen und erhöht somit die Planungssicherheit. Schauen Sie sich nachstehend die beiden grundlegenden Schritte an, wie man einen Netzplan sehr einfach erstellen kann.

© Frank Obels


Seite 121


Abbildung 23: Beispielmethodik zum Festlegen von Vorgangsreihenfolgen

Schätzung der Vorgangsdauern Die Schätzung der Vorgangsdauern ist zweifelsohne der schwierigste Teil der Zeit- und Terminplanung, dabei aber zugleich einer der wichtigsten Prozesse. Wenn Sie ein erfahrener Projektleiter sind, haben Sie es erheblich leichter als ein gerade beginnender Kollege. Generell sollte für die einzelnen Vorgänge die Person im Projektteam schätzen, die die meiste Erfahrung in diesem Punkt besitzt.

Seite 122


© Frank Obels


Es ist immer ratsam, sich den Rat von Experten einzuholen. Sie finden diese vielleicht im Unternehmen des Auftraggebers, in der Reihe der Stakeholder oder extern. Eine besondere Bedeutung hinsichtlich der Schätzdauern kommt dem Stichwort Projektarchiv zu. Sie sollten auf jeden Fall erfragen, ob ein solches im Unternehmen vorhanden ist. Aus derartigen Aufzeichnungen früherer Projekte lassen sich zumeist wertvolle Informationen extrahieren.

Entwicklung eines Terminplans Haben Sie die Dauer aller Vorgänge geschätzt, so steht die Bestimmung des Anfangs- und Endtermins für die Projektvorgänge im Vordergrund. Als Lösungswerkzeug werden Sie ein mathematisches Lösungsverfahren anwenden. Ein solches Verfahren berechnet die theoretisch möglichen frühesten und spätesten Anfangs- und Endtermine für die Projektvorgänge, ungeachtet der Einschränkungen des Einsatzmittelbestands. Neben der bereits erwähnten Netzplantechnik sind hier Stichworte wie GERT (Graphical Evaluation and Review Technique) sowie PERT (Program Evaluation and Review Technique) als zentrale Verfahren zu nennen. Lassen Sie mich das ganze Planungsszenario stark vereinfacht darstellen:

1. Sie schätzen die Bearbeitungsdauer pro Vorgang/Arbeitspaket und dokumentieren dies in einer einfachen Tabelle. Diesbezüglich geht es nur um den Zeitraum, der für die Erledigung des Arbeitpaketes zur Verfügung stehen soll – unabhängig von Mitarbeiterzahlen und –aspekten.

2. Im nächsten Schritt überprüfen Sie, ob zwischen den Vorgängen Abhängigkeiten bestehen. Sie können beispielsweise erst dann mit dem Bier trinken beginnen, wenn Sie eines haben. Diese Problematik der Vorgänger und Nachfolger dokumentieren Sie ebenfalls in der erstellten Tabelle.

3. Schließlich beginnt der Prozess des Vorwärts- oder Rückwärtsrechnens. Gibt es einen fixen Anfangstermin für Ihr Projekt, so bestimmen Sie das voraussichtliche Projektende anhand Ihrer Werte. Muss das Projekt an einem festen Endtermin abgeschlossen sein, so müssen die ermittelten Zeiten der Vorgänge angepasst werden. Das alles hört sich schlimmer an, als es ist. Inwieweit Sie mit diesen Methoden im Detail in Berührung kommen, richtet sich nach Ihren mathematischen Neigungen und der eingesetzten Projektmanagementsoftware. Es gibt am Markt ganz ausgezeichnete Software-Pakete und die „großen“ Produkte automatisieren die Berechnung der mathematischen Analyse und auch des Einsatzmittelabgleichs und ermöglichen darüber hinaus häufig die schnelle Betrachtung vieler Planungsalternativen.

© Frank Obels


Seite 123


Zur grafischen Darstellung erwartet man heute von Ihnen zumindest die Darstellung als Balkenplan, auch bekannt unter der Bezeichnung Gantt-Diagramm. Vielleicht kennen Sie diese Darstellung noch aus der Schul- und Studienzeit. Einen solchen Balkenplan erstellen Sie sich am einfachsten mit einem Tabellenkalkulationsprogramm (Spreadsheet). Da ich aber glaube zu wissen, dass Sie ohnehin eine Projektmanagementsoftware einsetzen werden (das gilt nämlich als professionell am Markt), darf ich Sie beruhigen – auch das einfachste Programm beherrscht die Gantt-Darstellung. Fälschlicherweise wird Software, die Sie ausschließlich beim Zeit- und Terminmanagement unterstützt, wohlklingend auch als Projektmanagementsoftware angepriesen.

Abbildung 24: Beispielbalkenplan

Sie haben nun die erste Terminplanung vorgenommen. Diesbezüglich sollten Sie im Hinterkopf behalten, das die im nächsten Kapitel vorgestellte Ressourcenplanung die Terminplanung beeinflussen kann. Nicht jeder kann sich meine „Projektsicht“, die erforderlichen Ressourcen als gegeben zu unterstellen, zu Beginn der Projektmanagerkarriere leisten. Mancher will dies auch später nicht. In jedem Falle gehört das Thema Terminplanoptimierung in Ihre Zuständigkeit. Diesbezüglich verweise ich auf die hervorragende Fachliteratur.

3.4.7 Aufwandsschätzung und Ressourcenplanung Was wir im Rahmen dieses Buches „künstlich“ abgetrennt haben, geht in der Praxis fließend ineinander über: Termin-, Aufwands- und Ressourcenplanung. Sofern Sie es als geübter Projektleiter nicht schon bei der Arbeitspaketdefinition erledigt haben, wird nun pro Arbeitspaket der geschätzte Arbeitsaufwand festgelegt. Hierbei geht es nicht um die Dauer, sondern -um es mal modern auszudrücken- um die Manpower.

Seite 124


© Frank Obels


Nachdem die Aufwandsschätzung steht, wird im Zuge der Ressourcenplanung festgelegt, welche Mitarbeiter in welchem zeitlichen Umfang in das Projekt eingebunden werden. Nun beginnt in Linux-Projekten das große, Entschuldigung für den Ausdruck, „Hickhack“. Die im Rahmen der Ressourcenplanung notwendigen Abstimmungsgespräche werden nur im seltensten Fall ohne Probleme verlaufen, denn die Fachabteilungen stellen ungern in größerem Maße Mitarbeiter zur freien Verfügung. Häufig hat auch die Personalabteilung eines Unternehmens noch nicht die nötige „Reife“ für die Projektbedeutung entwickeln können. Bedenken Sie bitte, wir befinden uns noch immer in der Planungsphase. Wenn Sie ein Projektleiter sind, dem man nicht gerne widerspricht, können Sie dieses „Problem“ durch entsprechende „Auftritte“ bei dem Projektauftraggeber lösen. Was machen aber die Kollegen, die vor ihrem ersten Projekt stehen und ganz einfach das „Auftreten“ nicht haben? Sollte eine Fachabteilung sich doch einmal spendabel zeigen, so seien Sie bitte, nach der entsprechenden Dankbarkeitsphase, ruhig ein wenig misstrauisch. Es ist eine beliebte Methode der Fachabteilungen, unbeliebte Mitarbeiter in Projekte abzuschieben. In der Regel beruht diese Unbeliebtheit auf mangelnder Teamfähigkeit, anderen „Charakterneurosen“ oder auch geringer Fachkompetenz. Kurzum: es mag schwer sein, das „staffing“ schnell und erfolgreich hinter sich zu bringen. Die Lösung: setzen Sie Ihre Planungen mit „fiktiven“ Mitarbeitern fort. Nein, lachen Sie nicht! Es funktioniert wunderbar. Wenn Sie einfach für den Moment die Personalsituation in einem Unternehmen „stehen lassen“ können, ersparen Sie sich nicht nur ein paar Feinde, Sie delegieren das Problem des „staffing“ indirekt einfach weg. Sie arbeiten bei Ihrer Planung mit Projektrollen und definieren, ähnlich der Stellenbeschreibung, eine Rollenbeschreibung. Jetzt kommt der Vorteil. Je detaillierter Sie sich hinsichtlich Skill und Aufgabenspektrum äußern, umso „passender“ wird der spätere Mitarbeiter sein. Da Sie die konkrete Besetzung Ihres Teams nämlich zeitlich nach hinten und damit zur Personalabteilung verschoben haben, wird diese sich, durch die gewonnene Zeit im Regelfall mit einer besonders sorgfältigen Auswahl „bedanken“. Ich überlasse es Ihrer Fantasie, weitere Vorteile aus dem Arbeiten mit Rollen zu ziehen – es gäbe da noch ein paar. Und schon können Sie ganz in Ruhe Ihre Ressourcenplanung durchführen und anschließend, als Anforderungskatalog, dem Projektauftraggeber übergeben. Dieser weiß dann ohne ein Wort von Ihnen, dass ohne die von Ihnen beschriebenen Kollegen das Projekt bereits höchst gefährdet ist. Bitte berücksichtigen Sie bei jeder Ressource Zeiten für Urlaub, Krankheit und Fortbildung. Schließlich überprüfen Sie, ob es zur Überlastung einzelner Ressourcen kommt. Besonders in Linux-Projekten geschieht dies bei den Spezialisten gerne einmal.

© Frank Obels


Seite 125


Die Frage des „staffing“ ist formal ein sehr einfacher, in der Realität aber ein durchaus schwieriger Prozess. Ich möchte Ihnen zu diesem Thema noch ein Beispiel aus einem Linux-Projekt geben, das an die Ressourcenplanung hohe Anforderungen stellte. Im Rahmen eines Firmenumzuges sollte ein Desktop-Rollout stattfinden. Es mussten 2800 Client-Systeme auf Linux umgestellt werden. Die zentrale Vorgabe lautete, den Rollout, während des Umzugs, innerhalb von 72 Stunden durchzuführen, als Crash-Maßnahme. Der Charme dieser Aufgabe bestand nicht in der „Bestückung“ der Projektteams, sondern in der Personalbeschaffung für das Rolloutwochenende. Wir errechneten einen Bedarf von 200 externen Fachkräften. Der Termin des Umzugswochenendes war nicht gesichert und so wurde dieser auch insgesamt drei Mal verschoben. Die Entscheidung für eine Verschiebung und eine Neubenennung des Termins erfolgte mit einem zeitlichen Vorlauf von einer Woche. So etwas zu planen, ist sehr beschwerlich.

3.4.8 Kostenplanung Kommen wir zu einem der spannenden Themenbereiche des Projektmanagements und der Lieblingsfrage vieler Projektauftraggeber: was kostet das Projekt? Wenn ich von Kostenplanung in Projekten spreche, dann meine ich damit zunächst die Kosten für diejenigen Einsatzmittel, die für die Ausführung der Projektvorgänge erforderlich sind. Dies bezeichne ich als Kostenplanung im engeren Sinne. Zunächst einmal sollten wir klären, wie hoch Ihre Kostenwahrheit denn sein soll. Nein, das hat nichts mit vertuschen zu tun, sondern wirft lediglich die Frage auf, inwieweit auch nicht ausgabewirksame Kosten dem Projekt zugerechnet werden. Bezüglich der ausgabewirksamen Kosten gehe ich davon aus, dass diese immer in das Budget eingerechnet werden. Da wären als typische Vertreter zu nennen: Beratungskosten, Material- und Ausrüstungskosten, Reisekosten und Verpflegung und andere externe Dienstleistungen. Ein häufiger Streitpunkt bei den nicht ausgabewirksamen Kosten sind die Personalkosten. Stellen Sie sich vor, in Ihrem Projektteam befinden sich Spezialisten aus den ITFachabteilungen. Deren Gehalt wird bezahlt, egal ob diese im Liniengeschäft oder im Projekt eingesetzt werden. Rechnen Sie diese Personalkosten nun dem Projekt hinzu? Was ist mit PCs, die ohnehin vorhanden sind und im Rahmen des Projektes Verwendung finden? Was mit Räumen, Heizung und weiterem mehr? Sie können in der Fachliteratur im Regelfall lesen, dass es im Ermessen der Entscheidungsträger des Projektes (Auftraggeber, Lenkungsgremium) liegt, ob die nicht ausgabewirksamen Kosten in das Projektbudget mit eingerechnet werden. Fragen Sie also die Verantwortlichen. Wenn diese entscheiden, im Regelfall aus „politischen“ Gründen, die nicht ausgabewirksamen Kosten unberücksichtigt zu lassen, dann empfehle ich Ihnen sehr, diese in einer „geheimen“ Kostenplanung dennoch mit einzurechnen. Warum?

Seite 126


© Frank Obels


Weil Sie persönlich nicht mehr Erfahrung sammeln können, als wenn Sie in mehreren Projekten die vollständige (Kosten-)Wahrheit sammeln. Werden Sie dann von einem Kunden gefragt, was eine Linux-Umstellung wirklich kostet (mir passiert dies), so können Sie ihm eine wirklich fundierte Aussage geben. Nach meiner Erfahrung macht es einen guten Eindruck auf den Kunden, wenn Sie ihm eine weitgehende Kostentransparenz anbieten können, selbst wenn dieser Kunde im späteren Projektverlauf darauf teilweise wieder verzichten wird. Dies hat dann aber die benannten politischen Gründe und hängt häufig mit einer nicht sehr starken Position der IT im Unternehmen zusammen. Nur die Projektkosten betrachten? Das Kostenmanagement beschäftigt sich hauptsächlich mit den Kosten, die für das Projekt relevant sind, selten jedoch mit den Kosten für den späteren „Betrieb“ des Projektergebnisses. Bei einem Linux-Migrationsprojekt oder der Softwareentwicklung können die Projektkosten beispielsweise dadurch gesenkt werden, dass Qualitätssicherungsmaßnahmen („Testläufe“) auf das nötigste beschränkt werden. Dies mag dann zu Lasten des späteren Betriebs beim Kunden gehen. Sprechen Sie Ihren Projektauftraggeber ruhig einmal auf diese erweiterte Sicht des Kostenmanagements an, insbesondere aber, wenn er „zufällig“ der spätere Betreiber des Projektergebnisses sein sollte. Bedenken sollten Sie auch, dass gerade die Projektkosten von den unterschiedlichen Stakeholdern Ihres Projektes vielleicht mit Argusaugen betrachtet werden. Berücksichtigen Sie bitte, in Ihrem Interesse, den Informationsbedarf der Projektstakeholder. Sofern die Betrachtung von Projektkosten für ein Belohnungssystem herangezogen wird, sollten Sie beeinflussbare und nicht beeinflussbare Kosten trennen, bereits in der Schätzund Planungsphase.

Ressourcenplanung (Einsatzmittelbedarfsplanung) In welchem Maße werden Maschinen, Menschen und Material für das Projekt benötigt? Im wesentlichen haben wir im vorangegangenen Abschnitt diese Frage bereits beantwortet, allerdings noch nicht unter dem Kostenaspekt. Unter Umständen müssen Sie für die Kostenschätzung/-planung den Detaillierungsgrad ändern. Diesbezüglich sind gegebenenfalls interne oder externe Linux-Fachleute hinzuzuziehen. Diese „glänzen“ dann auch gerne mit sogenannten historischen Daten.

© Frank Obels


Seite 127


Die eigentliche Kostenschätzung und -planung Die Kostenschätzung im engeren Sinne beinhaltet die Entwicklung eines Näherungsverfahrens für die Kosten der Einsatzmittel, die zur Ausführung der Projektvorgänge erforderlich sind. Eine Kostenplanung im engen Sinne ist die Zuordnung der geschätzten Gesamtkosten zu den einzelnen Arbeitspaketen, um einen Kostenbasisplan zur Messung der Projektleistung zu erhalten. Im Projektalltag wird diese strikte Trennung nicht eingehalten und somit bezeichnen beide Begriffe heute den Ansatz der Kostenermittlung. Die Kostenschätzung versucht, per Näherungsverfahren, die Kosten für den Einsatzmittelbedarf zu ermitteln. Dabei werden diverse Kostenalternativen geprüft. Lassen Sie uns nachstehend zwei Verfahren anschauen: Analogieschätzung Diese Methode wird auch Top-Down-Schätzung genannt und wird häufig in frühen Projektphasen herangezogen, wenn über ein Projekt noch sehr geringe Detailinformationen vorliegen. Dabei werden die tatsächlichen Kosten eines früheren, vergleichbaren Projektes als Grundlage für die Kostenschätzung (zumeist Projektgesamtkosten) eingesetzt. Dieses Verfahren stellt eine Art der Expertenschätzung dar (auf Erfahrung basierend), ist im Regelfall sehr kostengünstig und im allgemeinen ungenauer als andere Verfahren. Das Ergebnis wird umso genauer, je vergleichbarer die Projekte sind. Bottom-Up-Schätzung Eine in der Praxis häufig verwendete und bewährte Methode zur Kostenplanung stellt die Kostenstrukturierung dar. Diese werden Sie häufig auch unter dem Namen „Bottomup“-Verfahren finden. Dieses Verfahren schätzt die Kosten der einzelnen Arbeitspakete und fasst sämtliche Einzelschätzungen dann zu einer Gesamtschätzung der Projektkosten zusammen. Zur Kostenermittlung werden der Projektstrukturplan, die Arbeitspaketspezifikation und die Ressourcenplanung herangezogen. Für jedes Arbeitspaket wird der geschätzte Arbeitsaufwand (in Stunden) mit den Stundensätzen der verantwortlichen Mitarbeiter multipliziert. Dies ergibt die Personalkosten des Projektes. Weiterhin werden pro Arbeitspaket die „fixen“ Kosten (wie etwa externe Dienstleistungskosten) bestimmt (geschätzt) und den Personalkosten hinzugerechnet. Sofern es weitere Schätzungen gibt, werden diese ebenso hinzu addiert, bis man alle Kosten jedes einzelnen Arbeitspaketes ermittelt hat. Der Aufwand und die erzielte Genauigkeit hängen vom Umfang der jeweiligen Arbeitspakete ab. Dabei bedeuten kleinere Arbeitspakete einen höheren Schätzungsaufwand, dafür aber auch eine größere Genauigkeit. Unterscheiden Sie bitte generell die Kostenschätzung von der Preisbildung. Während erstere eine Betrachtung des quantitativen Ergebnisses ist, stellt zweitere eine unternehmerische Bewertung des Ergebnisses dar, in der die Kosten nur ein Aspekt von mehreren sind.

Seite 128


© Frank Obels


Ich werde immer wieder gefragt, ob man sich die Arbeit der Kostenbestimmung nicht per Software vereinfachen kann. Schon die Darstellung und Berechnung der Kosten per Tabellenkalkulation erleichtert diese Arbeit wesentlich, doch richtig schön wird es erst mit einer entsprechenden Projektmanagementsoftware. Was es im Open Source-Bereich diesbezüglich an Unterstützung gibt, zeigt ein Blick auf die Projektseiten von Sourceforge oder Freashmeat. Besonders hervorheben möchte ich hier die Software „Mr. Project.“

Grundsätze der Kostenplanung Kostenplanung sollte nie zwischen Tür und Angel erfolgen oder gar im Alleingang, beispielsweise durch den Projektleiter im stillen Kämmerlein. Nach Möglichkeit sollten alle „Erfahrungsquellen“ mit einbezogen werden, vor allen Dingen das gesamte Projektteam, Linux-Experten, externe Berater und Historien ähnlicher Projekte. Achten Sie bitte auf eine umfassende und verständliche Dokumentation Ihrer Kostenplanung. Ihre Planungsprämissen, Annahmen und zugrundegelegte Parameter sollten für einen aussenstehenden Dritten schnell und einfach nachvollziehbar sein. Denn nur dann wissen Sie, sollte sich eine Planungsgrundlage ändern, wo Sie mit den Änderungen ansetzen müssen. Sofern Sie Arbeitspakete an externe Dienstleister vergeben, dürfen Sie von diesen durchaus fordern, eine detaillierte Kostenaufstellung „abzuliefern“.

Steuerung der Kosten Als Ausgangswert der Kostenplanung erhalten Sie den Kostenbasisplan. Darunter versteht man ein in zeitliche Phasen unterteiltes Budget, das zur Messung und Überwachung der Kostenentwicklung über das gesamte Projekt hin dient. Bei sehr großen Projekten kann es mehrere Kostenbasispläne geben, beispielsweise je einen für bestimmte Kostenarten und unterteilt nach Kostenträgern. Auch wenn dieses Kapitel noch nichts mit der Projektsteuerung zu tun hat, so lassen Sie mich doch erwähnen, dass dieser erste Kostenbasisplan das Wertvollste für die Steuerung der Projektkosten sein wird.

3.4.9 Kommunikationsplanung und -management Wenn Sie bereits Projekterfahrung haben, dann wissen Sie, dass das Thema Kommunikation nicht nur ein sehr wichtiges ist, sondern es diesbezüglich in vielen Projekten Unzulänglichkeiten zu beobachten gibt.

© Frank Obels


Seite 129


Es ist die Aufgabe des Projektleiters dafür zu sorgen, dass Projektinformationen erstellt, gesammelt, rechtzeitig und angemessen verbreitet sowie professionell abgelegt werden. Bitte beachten Sie, dass es dabei nicht nur um die Kommunikation innerhalb Ihrer Projektorganisation geht, sondern insbesondere auch um die Außen-Information. Eine gute Projektkommunikation schafft die für den Erfolg notwendigen Verbindungen zwischen Menschen, Ideen und Informationen. Jeder am Projekt Beteiligte muss bereit und in der Lage sein, Mitteilungen in der „Projektsprache“ zu senden und zu empfangen. Insbesondere sollte jedem klar sein, welche Bedeutung die Kommunikation für das Projekt hat. Ich baue in jedem meiner Projekte eine besondere Verantwortungsgruppe für die Projektkommunikation nach Außen auf, und nenne diese Instanz Projektmarketing. Ein Linux-Projekt ohne Projektmarketing ist für mich nicht erfolgversprechend, zu groß sind die Anfangsvorbehalte im Stakeholder-Umfeld. Hier hilft nach meiner Erfahrung nur erfolgreiche Öffentlichkeitsarbeit – weshalb ich auch gerne mit den Pressemenschen meines Kunden während des Projektes zusammenarbeite. Ihre Kommunikationsplanung bauen Sie am besten in folgenden drei Schritten auf: a. Die eigentliche Kommunikationsplanung Sie stellen den Informations- und Kommunikationsbedarf der Stakeholder fest und ermitteln, wann, wer, welche Information benötigt. b. Das Informationswesen Wie wollen Sie die Information im richtigen Moment, im richtigen Umfang den Stakeholdern zur Verfügung stellen; bewährt hat sich in Linux-Projekten die Erstellung eines Projekt-Intranets, auf das jeder Stakeholder mit seinem Kennwort zugreifen kann und eine eigens für ihn dynamisch erzeugte Web-Seite erhält. In einem Linux-Projekt erwarten die Kunden dies, nach meiner Wahrnehmung, bereits von einem Linux-Projektleiter. c. Das Berichtswesen Ein Berichtswesen ist für mich lediglich eine Spezialdisziplin des Informationswesens, fast vollständig ausgerichtet auf die Projektauftraggeber und allein mit dem Fokus auf der Projektleistung (Projektfortschritt, etc.).

Der Kommunikationsplan Scheuen Sie sich bitte nicht, Ihre Kommunikationspläne auf den Webseiten Ihres Projektes vollständig zu veröffentlichen. Dadurch, dass nun jeder sehen kann, wann „er“ informiert wird, erhöhen Sie die Beteiligung unter den Stakeholdern. Glauben Sie nicht? Hier tritt ein psychologischer Effekt ein. Die Information, die Sie verteilen, gibt dem Stakeholder das Gefühl, das Projekt einschätzen zu können und frühzeitig auf gewisse Dinge reagieren zu können. Somit gibt ein gutes Informationswesen dem Stakeholder ein Gefühl der Kontrolle.

Seite 130


© Frank Obels


Wenn Sie über ein wenig Mut verfügen, können Sie das gerne einmal ausprobieren: Informieren Sie irgendwann einmal einen sehr wichtigen Stakeholder nicht. Er wird sich umgehend bei Ihnen melden. Womit Sie meine Ausführungen bestätigt finden. Nehmen Sie sich dann eine Nettigkeit wie gute Schokolade und entschuldigen Sie sich persönlich bei diesem Menschen für das Versehen. Und nutzen Sie die Chance, in diesem Gespräch die Ansichten des Stakeholders in Erfahrung zu bringen und ihn für „Ihre Sache“ zu gewinnen. Die zentralen Fragestellungen in der Kommunikationsplanung lauten:  wer braucht welche Information,  zu welchem Zeitpunkt benötigt er diese Informationen,  wie soll diese Information zugestellt werden. Bewusst oder unbewusst wird die Kommunikationsplanung bereits bei der Organisationsplanung vorgenommen, da die Organisationsstruktur eines Projektes unmittelbare und weitreichende Auswirkungen auf die Kommunikationsplanung des Projektes hat.

Informationswesen Hier geht es um die tatsächliche und rechtzeitige Bereitstellung der benötigten Informationen. Die Projektleitung hat festgelegt, ob Informationen eine Hol- oder Bringschuld darstellen und wie sich die entsprechenden Informationsverteilsysteme darstellen. Generell empfiehlt es sich, sowohl formelle als auch informelle Kommunikation mit dem Informationswesen zu unterstützen. Berichte und Formblätter repräsentieren den formellen Anspruch, spontane Gespräche, der Kummer- oder Meckerkasten oder ein Intranetforum dagegen, den informellen Aspekt. Sie sollten sich auch Gedanken bezüglich der Dateiablage und Dokumentenhistorie machen. Legen Sie diese auf einen zentralen Server? Haben alle Teammitglieder und andere Personen die gleichen Zugriffsrechte?

Berichtswesen Etwas formell strenger und mit hoher Bedeutung bezüglich der Projektleistung ist das Berichtswesen. Es geht darum, umfassend die Projekteigner und/oder auch die wichtigen Stakeholder eines Projektes darüber zu informieren, wie die Einsatzmittel zur Erreichung des angestrebten Projektergebnisses eingesetzt werden – und „wo sich das Projekt gerade befindet“. Das Berichtswesen informiert über die Termine, die Kosten und die Qualität eines Projektes, zeitweise auch über den Inhalt und Umfang – und dies zumeist in drei zeitlichen Betrachtungsrichtungen: zurückschauend, aktuell und in die Zukunft.

© Frank Obels


Seite 131


Statusberichte, Fortschrittsberichte und Prognosen übernehmen diese Aufgaben.

Kommunikationsspielregeln festlegen Kommunikation per E-Mail wird in Ihrem Projekt sicherlich stattfinden und diesbezüglich kommt es zu vielen Missverständnissen und „Angriffsformen“. Sie sollten deshalb grundsätzlich für Ihr Projekt für die verschiedensten Kommunikationsformen eine Spielregel festlegen. Sie finden nachstehend das Thema E-Mail-Kommunikation etwas ausführlicher behandelt und können aus den dortigen Ausführungen sehr leicht Ihre „Spielregel“ ableiten. Bitte gehen Sie nicht davon aus, dass jeder erwachsene Mensch ja wohl die ungeschriebenen Kommunikationsspielregeln „beherrschen“ sollte. Ebenso wie beim Telefon fehlen bei der E-Mail-Benutzung die nonverbalen Kommunikationskanäle. Der Hauptgrund für Missverständnisse bei elektronischer Kommunikation ist das Fehlen der gestischen und mimischen Zusatzinformation. Bei Kritikgesprächen, Schlechtnachrichtenübermittlung oder negativen Botschaften ist das "face-to-face" von Mensch zu Mensch ein Muss. Der Empfänger einer unangenehmen Botschaft sollte im Normalfall immer als Mensch präsent sein. Wer Negatives mit einer Email oder mit einem Brief schreibt, verwendet in der Regel eine „unfreundliche“ Sprache. Ironische Bemerkungen werden als solche schlecht erkannt. Einzelne Worte wirken zementiert und können nachträglich vom Leser willkürlich zerpflückt werden. Jedes geschriebene Wort kann auf die Waagschale gelegt oder wortwörtlich genommen werden. Achtsamkeit im Umgang mit Emails lohnt sich deshalb. Nur beim direkten Kontakt werden sprachliche und nichtsprachliche Informationen übermittelt. Der feinmaschige Austausch von unterschiedlichsten Botschaften ist es, der das Verstehen beim persönlichen Gespräch erleichtert. Unklarheiten lassen sich sofort und direkt klären. Ohne die nonverbale Kommunikation treten vor allem bei subtilen Mitteilungen Unklarheiten auf. Missverständnisse sind vorprogrammiert, wenn der Gegenüber fehlt. Projektmanagern bereitet häufig der überfüllte „E-Mail-Briefkasten“, verbunden mit dem Erwartungsdruck, die Mails schnell beantworten zu müssen, erhebliche Probleme. Regeln Sie deshalb diesen Punkt bei Ihrer Kommunikationsplanung, indem Sie etwa festlegen, dass E-Mails innerhalb von 24 Stunden beantwortet werden, nicht aber „asap“.

3.4.10Risikoplanung und -analyse Lassen Sie mich zur Einführung wiederum ein wenig aus der Praxis plaudern. Risikomanagement ist eine sehr wichtige Projektmanagement-Disziplin, ist aber in der Vergangenheit in Projekten eher selten zu finden gewesen. Deshalb schreiben zwar viele Experten darüber, doch in der Praxis setzen es nur wenige um.

Seite 132


© Frank Obels


Der psychologische Effekt spielt diesbezüglich eine große Rolle, zum einen beschäftigt man sich nicht gerne gleich zu Beginn eines Projektes mit dem, was schief gehen kann zum anderen überkommt viele Projektleiter noch immer ein flaues Gefühl, wenn sie ihrem Auftraggeber oder Kunden statt unmittelbarem Nutzen oder Erfolgsmeldungen erst einmal Risiken „verkaufen“ müssen. Es hat sich um das Risikomanagement herum in der Praxis der Begriff des „Bedenkenträgers“ etabliert, was, unmissverständlich und durchaus abfällig gemeint, den Kundenwunsch nach Lösungen anstelle von Problemen widerspiegelt. Sollte Ihr Kunde dann noch eine der gängigen Definitionen eines Risikos kennen, nämlich dass ein Risiko ein Ereignis ist, von dem überhaupt nicht sicher ist, ob es eintritt und in welcher Höhe es Schaden verursachen könnte, so wird Ihnen dieses Spiel mit Eventualitäten unter Umständen schwer angelastet. Ein Thema also, das absolut notwendig erscheint, wenn man einige Projekte hinter sich gebracht hat, aber der Kunst der Diplomatie bedarf. Übrigens muss man nicht jedes Risiko, das man identifiziert, auch gleich an die „große Glocke“ hängen.

Risikoidentifikation Dieser Teilprozess bezeichnet die Suche nach Risiken, die das spezifische Projekt beeinflussen werden können und die anschließende Dokumentation der Eigenschaften der Risiken. Die gebräuchlichsten Hilfsmittel der Risikoidentifikation sind neben den reinen Checklisten und Interviews auch Kreativitäts- und Prognoseinstrumente, etwa der Mindmapping-Ansatz oder das klassische Brainstorming. Streng genommen bezeichnet der Begriff Risiko nur die Möglichkeit, Schaden zu nehmen, also mit negativen Ereignissen. Es liegt an Ihren Neigungen und Ihrer Projekterfahrung auch die positiven Ereignisse mit in den Projektkontext aufzunehmen. Dann würden wir dies Chance nennen. Für die Philosophen unter Ihnen: Das chinesische Schriftzeichen für die Begriffe Risiko und Chance ist identisch.

Risikoanalyse Die Risikoanalyse nimmt eine Bewertung sowie eine möglichst genaue Beschreibung der Risikosituationen vor. Dabei werden die identifizierten Risiken hinsichtlich ihrer direkten und indirekten Folgen für das Projekt bewertet, sofern möglich, unter Berücksichtigung der Wechselwirkungen der Risiken unter sich.

© Frank Obels


Seite 133


Zur qualitativen und quantitativen Bewertung werden die Parameter Schadensausmaß und Eintrittswahrscheinlichkeit verwendet. Zur Bewertung der Risiken gibt es eine Vielzahl von Methodenansätzen. Die gängigste Form der Simulation bei einem Projekt ist die Monte Carlo Analyse. Auf Basis der Risikobewertung wird schließlich eine Risikoklassifikation vorgenommen, deren Klassen dann eine Aussage bezüglich des Reaktionsgrades gestatten. Durch die Sortierung der Klassen wird die Auswahl der Risiken, für die nun Maßnahmen zur Risikobewältigung ergriffen werden müssen, wesentlich erleichtert. Die Anwendung der ABC-Analyse wird häufig als Ordnungsmethode angewandt.

Entwicklung von Maßnahmen zur Risikobewältigung Nun geht es um den Umgang mit den „drohenden“ Gefahren, wobei sich in der Regel drei Kategorien als Reaktionsmöglichkeit etabliert haben:   

Vermeidung – Ausschluss der Gefahr durch Beseitigung der Ursache. Risikominderung – Senkung des zu erwartenden Geldwerts durch Senkung der Eintrittswahrscheinlichkeit, Senkung des Risikoereigniswertes oder beides. Der Abschluss einer Versicherung ist eine solche Maßnahme. Akzeptanz – Hinnahme der Konsequenzen, entweder aktiv (Vorbereitung auf die Konsequenzen) oder passiv.

Generell sollten Sie die entwickelten Maßnahmen in zwei Bereiche unterteilen:  Vorbeugende Maßnahmen – also ursachenbezogene oder Präventivmaßnahmen, mit der Absicht Risikoplanung durch Risikovermeidung oder –verminderung zu betreiben.  Korrektiv-Maßnahmen – also ein auswirkungsbezogenes Vorgehen im Sinne einer Risikovorsorge durch vollständige oder Teil-Akzeptanz, mit einem Notfallplan oder anderen Selbstvorsorgeinstrumenten.

3.4.11Qualitätsplanung Haben Sie diesen Punkt etwa gar nicht vermisst? Sie sind für ein technisches, noch dazu neuartiges Gewerk zuständig und wollen keine Qualitätsplanung vornehmen? Sagen Sie mir nicht, die wäre doch in den anderen Planungen enthalten. Sie haben es mit Linux zu tun! Das ist nicht nur anspruchsvolle IT, das bedeutet vor allen Dingen Vorbehalte, Skepsis und alles, was ich Ihnen bereits erzählt habe. Also führen Sie bitte in Ihrem Interesse eine separate Qualitätsplanung durch, die Sie auch überall gut sichtbar „liegenlassen“. Die Stakeholder und das Management sollen sich doch sicherlich gut fühlen.

Seite 134


© Frank Obels


Der Qualitätsplan sollte im wesentlichen technische und funktionelle Aussagen bezüglich des Projektergebnisses enthalten. Dabei müssen die Qualitätsmerkmale mess- und bewertbar sein. Neben den Messgrößen werden die entsprechenden Maßnahmen zur Qualitätssicherung festgelegt. Die Strukturierung eines Qualitätsplans kann sich an folgendem Muster orientieren: • • •

• •

Qualitätsplan und -ziele Qualitäts- und Testlabororganisation Qualitätsmaßnahmen • Reviews • Testarten und Testumfang • Zu testende Produktmerkmale • Richtlinien für die Tests • Audits (intern/extern) Tools und Methoden Qualitätsverfolgung

Qualitätsmerkmale für Linux-Projekte 1. Funktionalität Denken Sie beispielsweise an eine Desktop-Migration, dann kann man sich die Frage stellen, welche Funktionen, mit festgelegten Eigenschaften, der Mail-Client besitzen soll. Sind Kalender- und Groupwarefunktionen gefordert oder soll es die Funktion der Multiaccount-Abfrage geben? Zwei wichtige Anforderungen werden die Ordnungsmäßigkeit und die Sicherheit sein. Die Ordnungsmäßigkeit untersucht die Erfüllung von anwendungsspezifischen Normen und gesetzlichen Bestimmungen, die Sicherheit überprüft die Fähigkeit, vor unberechtigtem Zugriff zu schützen. 2. Zuverlässigkeit Hier geht es um die Performance der Lösung und den Reifegrad der technischen Lösung. Dies ist sowohl bei Servermigrationen wie auch bei Client-Umstellungen von zentraler Bedeutung. Auch die Fragen, wie sich das System im Fehlerfalle verhält und wie einfach und schnell eine Wiederherstellung zu bewerkstelligen ist, stehen hier im Vordergrund. 3. Benutzbarkeit Wie wird sich das Projektergebnis hinsichtlich der „Usability“ verhalten? Wie sehen die diesbezüglichen Anforderungen aus, wie hoch sind der Aufwand für die Erlernbarkeit und Bedienbarkeit des Projektergebnisses? 4. Effizienz Wie steht es mit dem Verhältnis zwischen dem Leistungsniveau des Projektergebnisses und der Größenordnung einzusetzender Betriebsmittel, sowohl unter Zeit- als auch unter Mengenaspekten.

© Frank Obels


Seite 135


5. Änderbarkeit Welche Qualität soll bezüglich des Anpassungsaufwands des Projektergebnisses erreicht werden? Wie hoch dürfen die diesbezüglichen Aufwände sein?

3.5

Projektdurchführung

Alle Ihre Planungen vergleichen Sie nun nur noch mit der Realität und reagieren bei Abweichungen adäquat. So einfach ist der Job des Projektleiters während der Projektdurchführung. Bitte beachten Sie: nach dem Eisbergmodell haben Sie erst 1/8 des Projekts, nämlich die sichtbaren Strukturen hinter sich gebracht. Jetzt kommt das Unsichtbare, was rein rechnerisch noch 7/8 ausmacht. Sollten Sie aus irgendeinem Grund Zweifel an diesem Traum vieler Projektmanager haben und gerade dieses „auf Kurs halten“ für eine anspruchsvolle Aufgabe halten, dann sind Sie sicherlich meiner Meinung, dass ein Projektleiter nicht zu arbeiten hat, sondern zu steuern. Hat schon die Planung viel Zeit verschlungen, so ändert sich dies während der Projektdurchführung für den Projektleiter nicht. Ein Linux-Projektleiter, der auch noch fachlich mitarbeitet, kann keine ausreichende Kontrolle und Steuerung seines Projektes vornehmen. Und somit wird sein Projekt leider scheitern. Permanente Präsenz – überall Insbesondere sollte der Projektleiter seine Zeit auf Besuche verwenden. Gespräche über Gespräche sind eines der Geheimrezepte des Projekterfolgs. Ein Teil der Gespräche darf durchaus formeller Natur sein, aber der überwiegende Teil sollte informeller Natur sein. Jetzt geht es darum, die Nöte, Sorgen und Beobachtungen aller Beteiligten möglichst als Erster zu erfahren. Gehen Sie mit den Menschen Mittagessen, Kaffeetrinken, Rauchen oder was Sie sonst mögen. Es geht jetzt um Fürsorge, darum, den Projektbeteiligten zu zeigen, dass Sie für sie da sind. Öffnen Sie sich und Sie werden erleben, wie sehr man sich Ihnen öffnet. Ihr Projektmotto (und das Ihres Teams) sollte jetzt lauten: «es ist nicht schlimm, wenn es an irgendeiner Stelle Schwierigkeiten gibt, aber es ist schlimm, wenn der Projektleiter nicht sofort darauf aufmerksam gemacht wird.»

Seite 136


© Frank Obels


Lassen Sie mich etwas ganz deutlich sagen: sollte es Sie Überwindung kosten, auf die Leute zuzugehen, dann hängen Sie Ihren Job an den berühmten Nagel. Besuchen Sie dann ein Kommunikationsseminar oder einen Therapeuten, der Ihnen die Blockade „wegmacht“. Projektmanagement bedeutet vor allen Dingen eines: mit den Menschen reden! Wenn Sie das nicht wollen, bliebe Ihnen auch noch, sich einen externen Berater zu holen, die eignen sich im übrigen für jeden unliebsamen Job. Vermeiden Sie, Ihre Besuche als Kontrolle aussehen zu lassen. Lassen Sie sich einen Vorwand einfallen. Wenn Sie in den Ruf des Kontrolleurs oder des „Dampfmachers“ kommen, spielt man Ihnen so gekonnt etwas vor, dass Sie Ihre Zeit für Besseres nutzen können.

Kommunizieren Sie Lösungen Wenn denn eine Abweichung auftritt, so macht das zunächst einmal wenig. Wenn Sie die Abweichung bemerken, dann funktioniert Ihre Projektkontrolle ja schließlich. Vielleicht ist es auch keine Abweichung sondern ein unvorhersehbares Problem von Außen. Dann bleiben Sie vor allen Dingen ruhig. Und rennen Sie nicht gleich zu Ihrem Projektauftraggeber. Vieles lässt sich „intern“ regeln. Wenn Sie aber zum Boss müssen, dann überlegen Sie sich genau, was Sie ihm sagen. Die Überbringer schlechter Nachrichten werden gerne aufgehängt. Sagen Sie Ihrem Projektauftraggeber aber, dass Ihr Frühwarnsystem wunderbar geklappt hat und er sich nur noch zwischen zwei oder drei „Optionen“ zu entscheiden habe, so klingt dies für den Vorgesetzten ganz anders. Bevor Sie zu dem Auftraggeber gehen, suchen Sie vorher immer Ihr Team auf, auch wenn Sie die Alternativen ohne das Team aufzeigen können. Jetzt geht um die Absprache und die Geschlossenheit der Gruppe. Chefs fragen auf dem Weg in die Kantine auch schon einmal gerne ein Projektmitglied: «Was halten Sie denn von den Vorschlägen von Herrn XY?»

Bauen Sie ein anonymes Frühwarnsystem auf Manchen Menschen fällt es schwer, mit Gerüchten oder Beobachtungen zu Ihnen als Projektleiter zu kommen und Ihnen davon zu berichten. Oft besteht die Angst, dass man zu ängstlich ist. Sie sollten für solche Fälle einen „anonymen Kummerkasten“ aufbauen. In meinen Projekten habe ich dazu einen einwahlfähigen Linuxrechner mit einem Standardbenutzer. Der gute Mensch, der eine Information los werden will, kann sich mit seinem Rechner auf dem Linux-Rechner einwählen und sich unter dem anonymen Benutzer anmelden. Dann kann er in einer kleinen Webanwendung seine Sorgen loswerden. Wie ich Ihnen bereits in diesem Buch erzählte, kann es sein, dass dieses Instrument nicht genutzt wird, falls es aber genutzt werden sollte, dann ist die Information Gold wert.

© Frank Obels


Seite 137


3.5.1 Was es bei der Projektdurchführung zu tun gibt Sie überprüfen nun, wie gut Ihr Blick in die Zukunft zum Zeitpunkt der Planung war. Das wird interessant! „Auf der anderen Seite der Pläne“ sollten Sie immer wieder zu Ihren Planungen zurückkehren und fein säuberlich dokumentieren, was sich geändert hat oder was Sie falsch eingeschätzt haben. Jetzt beginnt für mich das eigentliche Management. Für mich bedeutet dies, die Richtung weisen, das System laufend neu gestalten, selbst bei Bedarf nach vorn marschieren, Andere fortwährend überzeugen und schließlich, die richtigen Menschen anziehen. Bevor wir auf die einzelnen Punkte eingehen, möchte ich Ihnen nachstehend einen Auszug wichtiger Tätigkeiten aufzeigen: • • • • • • • •

Kontrolle des Projektumfelds und der Umgang mit Änderungen Kontrolle von Inhalts- und Umfangsänderungen des Projekts und die diesbezügliche Steuerung Kontrolle der Planungswerte und das Reagieren auf Änderungen Kontrolle der technischen und fachlichen Gegebenheiten fortlaufende Risikokontrolle Berichten und Informieren über den Projektverlauf und -fortschritt lückenlose Dokumentation Motivation, Marketing und „Psychologing“

3.5.2 Durchführungs- und Erfolgskontrolle Je früher Abweichungen zwischen der Soll- und der Ist-Situation erkannt werden, desto schneller können Maßnahmen ergriffen werden, das Projekt zurück „in den Plan“ zu bringen. Das Projektcontrolling ist die diesbezügliche Überwachungsfunktion, die sämtliche Abläufe und Arbeitsschritte fortlaufend beobachtet. Projektcontrolling geht zumeist über diese reine Kontrollfunktion hinaus, indem es vor allen Dingen auch die entsprechenden Informationen bereitstellt. Um festzustellen, ob das Projekt noch auf dem richtigen Weg ist, werden die zu erbringende Leistung, die zur Verfügung stehenden Ressourcen sowie die Termine und Zeitabhängigkeiten betrachtet. Es bietet sich an, Überprüfungen und Berichte an dem ausgewählten Phasenmodell zu orientieren. Nach jeder Phase sollte eine Betrachtung (Review) der geleisteten Arbeit erfolgen. Sofern Sie Ihre Meilenstein entsprechend gesetzt haben, stellt dieser das Arbeitsergebnis der Phase dar. Beginnen Sie keine neue Phase, bevor das Ergebnis der zurückliegenden Phase nicht abgesegnet wurde. In einem Linux-Projekt sollten Sie unbedingt Ihren Projektauftraggeber oder noch besser, den Lenkungsausschuss, über den erfolgreichen Abschluss einer Projektphase entscheiden lassen. Dies hat auch hinsichtlich des Projektmarketings eine wichtige Signalwirkung.

Seite 138


© Frank Obels


Sofern eine Projektphase als erfolgreich abgeschlossen beurteilt wurde, lassen Sie sich die Freigabe des bis hierher erstellten Produktes erteilen. Umgangssprachlich bezeichnet dies mancher auch als „Phasenabsolution“. Dies ist psychologisch wichtig, denn Sie und Ihr Team werden mit jedem Teilerfolg noch motivierter und haben gleichzeitig die Gewissheit, dass rückwirkende Änderungen des bisher erreichten Ergebnisses nur im Ausnahmefall vorgenommen werden. Die für die Erfolgskontrolle erforderlichen Maßnahmen werden entweder beim Erreichen eines definierten Meilensteins automatisch initiiert oder durch regelmäßige fortlaufende Kontrollen, unabhängig von den Meilensteinen, angestoßen. In Ihrem Interesse sollten Sie beide Varianten parallel laufen lassen. Für die Ermittlung des aktuellen Status Quo ist das Erreichte in quantitativer wie auch in qualitativer Hinsicht zu beurteilen. Die qualitative Bewertung erfolgt über den erstellten Qualitätsplan. Quantitative Bewertung des Leistungsfortschritts Die quantitative Aufwandsmessung erledigen Sie am einfachsten über die zeitliche Beurteilung. Sie haben sicherlich ein Tool, wie das von mir erwähnte Timelancer-Tool, zur „Projektarbeitszeiterfassung“ genutzt und haben somit die in das Projekt investierten Arbeitsstunden vorliegen. Diese vergleichen sie nun mit den geplanten Werten. Durch eine einfache Tabelle in Ihrer Tabellenkalkulationssoftware erreichen Sie hier schon sehr gute Ergebnisse.

Regelmäßige Arbeitssitzungen Zu einer ordentlichen Erfolgskontrolle gehören regelmäßige Arbeitssitzungen, in denen die jeweils aktuellen Arbeitspakete und Probleme gemeinsam bearbeitet werden. Derartige Statusmeetings sind keine „Quatschclubs“, sondern dienen dazu • • • • •

gemeinsam interdisziplinäre Lösungen zu erarbeiten und somit den Vorteil der Gruppe gegenüber der Einzelarbeit zur Geltung zu bringen, Erfahrungen und Informationen auszutauschen, den aktuellen Projektstatus (Zwischenergebnisse, Schwierigkeiten, Abweichungen) zu klären, den anstehenden Projektstatusbericht gemeinsam zu verfassen, dem Abstimmen des weiteren Vorgehens und der eventuellen Überarbeitung der Projektplanung(bei wesentlichen Veränderungen der Rahmenbedingungen).

Übertreiben Sie es gleichwohl nicht mit den Meetings, wöchentliche oder sogar nur zweiwöchentliche Intervalle sind zumeist völlig ausreichend.

© Frank Obels


Seite 139


3.5.3 Projektstatusbericht Das sichtbare Ergebnis der Durchführungs- und Erfolgskontrolle ist der Projektstatusbericht. Wie oft Sie diesen an den Projektauftraggeber, den Lenkungsausschuss und die sonstigen Projektbeteiligten verteilen, bedarf der Absprache mit dem Projektauftraggeber. Sofern Ihr Unternehmen projekterfahren ist, wird es sicherlich eine entsprechende Vorlage geben. In Großkonzernen läuft das Projektcontrolling oder -monitoring ohnehin toolgestützt ab, so dass Sie hier auf Vorhandenes zurückgreifen können.

3.6

Projektabschluss

»Sie haben es geschafft!« Die Bilder, die sich dem Beobachter in der Projektabschlussphase zeigen, könnten vielfältiger nicht sein. Sie reichen von stummer dankbarer Erleichterung bis hin zu emotionalen Eruptionen. Der Projektabschluss gilt als der wichtigste Meilenstein eines Projektes – und wenn Sie einmal Zeuge solcher stärksten Erleichterungsreaktionen von Projektverantwortlichen geworden sind – spüren Sie die Bedeutung dieses Meilensteins für die Psyche, ohne dass Ihnen jemand den sachlichen Beweis für eine solche Aussage geliefert hat. Das Schwierigste am Projektabschluss ist das Erreichen der Projektabnahme. Und gerade in Linux-Projekten ist dies ein sehr schwieriger Punkt. Denn Sie müssen bereits zu Projektbeginn sehr genau definieren, wie die Projektabnahme erfolgen soll. Da LinuxProjekte aber häufig ein Novum darstellen, ist dies schwieriger als bei einem Bauprojekt, das mit einer Begehung abgenommen wird. Im Linux-Umfeld sind Probelaufzeiten zu erwarten, Nachbesserungsprozeduren einzuplanen, Freigabemechanismen, Wartungsverträge, und vieles mehr. Der Projektabschluss in einem Linux-Projekt sollte, entsprechend seiner Bedeutung, als obligatorische Aktivität im kritischen Pfad Ihres Projektterminplans eingebunden sein.

Sollten Sie bei der Abnahmevorbereitung zu Projektbeginn grobe Fehler machen, wird Ihr Projekt nicht enden, da die formale Abnahme nicht erfolgen kann und somit auch kein Projektabschluss. Der offizielle Projektabschluss (wir gehen noch immer von einem erfolgreichen Projekt aus) ist aber nicht nur für das Projekt sondern insbesondere für den Projektleiter von größter Bedeutung, da im Regelfall „sauber“ abgeschlossene Projekte der persönlichen Karriere nicht schaden. Nicht enden-wollende Projekte sind nicht nur etwas sehr Mühsames für alle Beteiligten, sondern verpassen der Karriere des Projektleiters eine empfindliche Delle. Seite 140


© Frank Obels


3.6.1 Vorbereitung des Projektabschlusses Je nach Art und Größe des Projektes sollten der Projektleiter und das Projektteam die folgenden Arbeitsschritte in die Wege leiten und den rechtzeitigen Beginn und die gewissenhafte Abwicklung überprüfen: Dokumentation des Projektergebnisses Das Projektergebnis, bei Linux-Projekten sind dies häufig die technische Fachdokumentation und die Benutzerdokumentation müssen zum Projektabschluss in der vom Projektauftraggeber gewünschten Form vorliegen. Bei Softwareentwicklungs- und Serverdesign-Projekten, ebenso wie bei Linux-Migrationen, sind diese Arbeiten aufwendig. Sie sollten, je nach Projektumfang, einige Wochen diesbezüglich einkalkulieren. Lassen Sie so dokumentieren, dass ein „unbeteiligter Dritter“ (beispielsweise einMitarbeiter der Revisionsabteilung) die Dokumentationsergebnisse nachvollziehen kann. Dabei sollten alle Unterlagen aktuell sein. Während der Laufzeit eines Projektes entstehen Dokumente, die zum Zeitpunkt eines Projektabschlusses veraltet sind – misten Sie diese bitte gewissenhaft aus. Archivierung der projektspezifischen Daten Daten auf Papier oder elektronische Daten, die während des Projektes angefallen sind, sollte der Projektleiter in eine gewünschte Ablage- und Archivierungsform bringen. Lassen Sie uns diesen Punkt bitte etwas ausführlicher betrachten, denn hier sind schier unglaubliche Fehler zu beobachten, die übrigens einen externen Berater noch in der Abschlussphase schwer zurückwerfen können. Es geht bei einer gründlichen Archivierung der projektspezifischen Daten nicht nur um das Vorbereiten der Unterlagen auf den Verstaubungsvorgang, sondern auch um Fragen der Haftung und weitere rechtsrelevante Themen. Bei der Art und Weise, wie Sie archivieren, berücksichtigen Sie bitte auch den vereinbarten Vertraulichkeitsgrad der Dokumente. Schriftliche Unterlagen gehören in sauber beschriftete Ordner, elektronische Daten in entsprechende elektronische Ordner (Verzeichnisstrukturen). Neben dem Projektnamen sollte man in beiden Varianten (Papier und elektronisch) bei der Ordnerbeschriftung angeben, was in dem Ordner enthalten ist. Sollten Sie aus irgendeinem Grund das korrekte Beschriften der Ordner unterlassen, können Sie sich von Ihren Unterlagen auch gleich verabschieden – erfahrungsgemäß benötigt der moderne Büroalltag keine 2 Wochen, um Ihre Unterlagen auf Nimmerwiedersehen zu „verschlucken“.

© Frank Obels


Seite 141


Die Ablagestrukturierung der Unterlagen richtet sich ein wenig nach den Gegebenheiten Ihres Unternehmens. Eine Ablage, beispielsweise nach Datum, ist sicherlich ungeeignet, eine Ablage nach Teilprojekten, nach Stichworten, nach Funktionen sicherlich besser geeignet. Bei der Benennung der elektronischen Dateien nutzen Sie die Möglichkeiten der langen Dateinamen, die seit einiger Zeit nun ja auch „Nicht-Unix-Betriebssystemen“ zur Verfügung steht. Aus dem Dateinamen sollte hervorgehen, welchen Inhalt die Datei bietet und nicht durch Abkürzungen zu einem kryptischen Ratespiel werden. Deshalb haben Sie dieses Pre-Release ja unter dem Namen LPem_v01.pdf zur Verfügung gestellt bekommen, damit Sie gleich sehen, wie man es nicht machen sollte. Der Projektauftraggeber freut sich sehr, wenn Sie ihm die projektspezifischen Daten sämtlich – zusätzlich – auf einer CD gebrannt übergeben. Statten Sie diese CD mit einer kleinen Suchfunktion aus (z.B. über eine Eingangs-HTML-Seite) und vergessen Sie Ihren Namen nicht – und schon haben Sie auch ein wenig zu Ihrer Selbstvermarktung beigetragen. Interessant für das Wissensmanagement eines Unternehmens sind die Soll- und Ist-Daten des Projektes. Wenn Ihr Unternehmen ein aktives Wissensmanagement betreibt, sollten Sie im Vorfeld mit dem Projektauftraggeber klären, wie er sich die Ausgestaltung dieses Punktes vorstellt. Oftmals reicht eine bestimmte Ablagestruktur auf einem ShareLaufwerk, manchmal werden elektronische Bibliotheken bevorzugt.

Schulung und technische Einweisung In der Praxis bewährt hat sich der so genannte „Übergabeworkshop“. Wenn Sie einen solchen Workshop (bei mehrtägigen Schulungen) mit einer Projektabschluss-Sitzung enden lassen wollen, dann nehmen Sie die technische Einweisung im Rahmen eines erweiterten „Projektabschluss-Workshops“ vor. Gehen Sie bitte davon aus, dass es auch Nachschulungen geben wird, zu einem Zeitpunkt also, an dem das Temporärgebilde Projektteam nicht mehr existieren wird. Klären Sie deshalb rechtzeitig, wer nach Projektende diese Schulungen und Einweisungen durchführen wird.

Technische Nachbetreuung Je nach Projektergebnis und diesbezüglicher Techniklastikkeit muss die Benutzerbetreuung bezüglich fachlicher Fragen auch für die Zeit nach dem Projekt organisiert werden. In der einfachsten Form muss ein vorhandener Benutzerservice diese Aufgabe übernehmen und unter Umständen Monate vor dem Projektabschluss im Rahmen des Projektes eingelernt werden.

Seite 142


© Frank Obels


Abschließende Kosten- und Wirtschaftlichkeitsanalyse Das Projektergebnis wäre nicht vollständig, wenn nicht zum Projektabschluss eine fundierte Kostenabweichungsanalyse und eine letzte Überprüfung der Wirtschaftlichkeitsund Amortisationsberechnungen vorgenommen würden.

Abschlusspräsentation Ein erfolgreicher Projektabschluss zieht eine Abschlusspräsentation mit sich. Diese richtet sich in erster Linie an den Projektauftraggeber. Häufig wird auch der Lenkungsausschuss bei dieser Abschlussveranstaltung anwesend sein. Sie sollten frühzeitig einen Termin für die Präsentation vereinbaren. Das primäre Ziel der Abschlusspräsentation ist die Vorbereitung der Projektabnahme. Nach einer erfolgreichen Präsentation sollten Sie möglichst kurzfristig eine formale Projektabnahme erreichen können. Sie werden sich von der Illusion befreien müssen, direkt mit der Abschlusspräsentation die Projektabnahme erreichen zu wollen. Ein Projektauftraggeber wird sich dafür ein wenig Zeit nehmen wollen – Sie können nur auf einen baldigen Termin „pochen“. Inhaltlich ist es die Aufgabe der Abschlusspräsentation, letztmalig den Status des Projektes darzustellen. Nutzen Sie die Abschlusspräsentation auch als letztmalige Gelegenheit zu aktivem Marketing.

3.6.2 Die Übergabe als Projektabschluss Der offizielle Projektabschluss findet zumeist in einer besonderen ProjektabschlussSitzung statt. Ich bevorzuge bei Linux-Projekten die Durchführung eines 2-tägigen Projektabschluss-Workshops, der dann mit der Projektabschluss-Sitzung endet. Je nach Projektumfeld kann die oben erwähnte Abschlusspräsentation Bestandteil des Projektabschluss-Workshops sein. Die Teilnehmer dieser Schlussveranstaltung sind nicht nur das Projektteam, die Entscheidungsträger und Kontrollinstanzen – Sie tun gut daran, ausgesuchte Linienmanager oder Stakeholder mit in den feierlichen Rahmen zu integrieren. Als Verantwortlicher eines politisch umstrittenen Projekts haben Sie nunmehr letztmalig die Gelegenheit zu „Versöhnungsgesten“. Nutzen Sie die Gelegenheit und lassen Sie an einem solchen Tag Alle als Gewinner nach Hause gehen.

© Frank Obels


Seite 143


Die schriftliche Abschlussbasis stellt der Projektabschlussbericht dar, mit diesem erfolgt auch die hochoffizielle Entlastung des Projektleiters. Sollten noch Restarbeiten durchzuführen sein, so werden auch diese auf dem Abschlussbericht vermerkt.

Abbildung 25: Formularvorschlag für einen praxisorientierten Projektabschlussbericht

Unter dem Stichwort Wissensmanagement ist die Projektabschluss-Sitzung von großer Bedeutung. Neben der Präsentation des Endergebnisses und der anschließenden Diskussion und Bewertung, sollten Sie versuchen, den Punkt „lessons learned“ (Gelerntes aus Ihrem Projekt) gemeinsam sehr ausführlich zu behandeln.

Seite 144


© Frank Obels


Und sofern Sie den Job des Projektleiters mit diesem Projektabschluss nicht an den Nagel hängen wollen, empfehlen Sie sich doch auch bitte als Mensch – und vergessen Sie nicht die gesellige Projektfeier nach dem formellen Teil (seltsam, dass das in kaum einem der so genannten Praxisbücher vermerkt steht). Zeigen Sie ruhig in einem solchen lockeren Rahmen, dass Sie bereit sind, die geleistete Arbeit auch gebührend zu würdigen!

3.6.3 Off topic: Das Optimierungsprojekt Wenn die vollständige Migration auf Linux abgeschlossen ist, dann haben Sie grosses geleistet. Es bestehen formal keine offenen Punkte mehr, dafür aber Bereiche, die erst nach der produktiven Startphase der Systeme sinnvoll „einregelt“ werden können. Ähnliches gilt bei Softwareentwicklungsprojekten bezüglich der Eingewöhnungszeit der Benutzer und Anwender. Es hat sich bewährt, mehrere Projekte, bei denen offene Punkte erst nach einer „Einregelzeit“ abgearbeitet werden können, in einem späteren Optimierungsprojekt zusammenzufassen. Gerade bei technischen Projekten stellt das Optimierungsprojekt eine sehr elegante Methode für die Fachabteilungen und IT-Betreiber dar, Systemerweiterungen oder – änderungen in ein geeignetes Umfeld einfließen zu lassen. Optimierungsprojekte sind im Regelfall „dankbare“ Projekte. Das Projektumfeld ist motiviert, politische Einflüsse sind eher gering und zumeist sind die Projektpläne noch gut überschaubar.

© Frank Obels


Seite 145


3.7

Praxis-Empfehlungen für Projektmanager

3.7.1 Die Top 20-Erfolgsregeln Regel 1 Menschen mögen es, wenn man sich für Ihre Arbeit interessiert. Dies gilt in Projekten umso mehr. Als Projektmanager sollten Sie alle am Projekt Beteiligten aufsuchen. Sie sollten wissen, was diese Menschen zum Projektergebnis beitragen und Sie sollten diesen Menschen das Gefühl geben können, dass Sie sich für ihre Arbeit interessieren. Und Sie sollten die Vorgesetzten dieser Menschen kennengelernt haben. Regel 2 Sie sollten als Projektmanager wissen, was die Teammitglieder, externen Berater und Lieferanten „zur Höchstleistung antreibt“. Informieren Sie sich, ob es in dem Unternehmen ein Belohnungs- oder Bonussystem gibt, ob es eine besondere Form von Auszeichnungen gibt oder was Mitarbeiter sonst noch motivieren könnte. Wenn Sie ein sehr anspruchsvolles Linux-Projekt haben, dann stellen Sie, in Absprache mit den Linienmanagern, ein eigenes „Projektmotivations-System“ zusammen. Regel 3 Die IT-Welt ist klein. Und die Linux-Welt ist nur ein (kleiner) Teil davon. Behandeln Sie die Menschen, mit denen Sie im Projekt zu tun haben, respektvoll und fair. Viele von diesen Menschen werden Ihnen später wieder begegnen können, Sie wissen nur noch nicht, unter welchen Umständen. Regel 4 Es gibt brutale, widerwärtige und unbeliebte Projektmanager, die sehr erfolgreich sind. Aber es gibt kaum einen herzensguten Menschen, einen permanenten Zauderer und oberflächlichen JA-Sager, der mehr als ein Projekt überlebt hat. Sie sollten bereit sind, jeden Tag für das Projekt Ihren Job als Projektleiter zu riskieren. Sicherheitsdenken gehört nicht zur „Projektmanagerausstattung“. Ihre Projektmitarbeiter gleichwohl suchen diese Sicherheit. Regel 5 Nicht alle erfolgreichen Projektmanager haben einzig durch Kompetenz Ihre Erfolge erreicht. Und nicht alle gescheiterten Projektleiter sind inkompetent. Ein wesentlicher Faktor ist Glück. Es hat den Anschein, als ob das Glück zu den Menschen kommt, die daran glauben und hart dafür arbeiten.

Seite 146


© Frank Obels


Regel 6 Vertreten Sie Ihre Meinung. Aber seien Sie stets in der Lage, diese ändern zu können. Schaffen Sie eine Projektkultur, in der die Projektmitglieder ihre Meinung äußern können und wollen. Und schaffen Sie eine Möglichkeit, dass Projektmitarbeiter eine anonyme Nachricht an die Projektleitung schicken können. So können schlechte Nachrichten, die sich die Teammitglieder von der Seele reden möchten, rechtzeitig zu Ihnen durchdringen. Vielleicht wird diese Möglichkeit nicht genutzt werden. Aber wenn doch, ist sie von unschätzbarem Wert. Regel 7 Ein Projektmanager leitet das Projekt. Das ist alles. Gerade in Linux-Projekten findet man Projektleiter, die programmieren oder sonstige technische Ergebnisse produzieren wollen. Diese Projekte scheitern. Es wäre so, als wollte man bei sich selbst eine Herzoperation durchführen. Regel 8 Es gibt unendlich viele Möglichkeiten, einen Tag zu vertun - aber keine einzige, ihn zurück zu bekommen. Es bringt nichts, deshalb in Höchstgeschwindigkeit durch das Projektleben zu hasten. Nehmen Sie sich ruhig Zeit für den Moment. Aber schreiben Sie sich das Wort T-U-N gut sichtbar an Ihren Arbeitsplatz. Es erinnert Sie daran, dass Sie Tag-Und-Nacht an Ihrem Projekt „dranbleiben“ sollen. Rückwärts gelesen, offenbart es die wichtigste Regel im Projekt: Nicht-Unnötig-Trödeln! Regel 9 Die meisten Menschen wissen nicht, dass das Unterbewusstsein das Wort „nicht“ nicht verarbeiten kann. Sagen Sie deshalb nicht, was Sie nicht wollen, sondern beginnen Sie eine klare, zielgerichtete Sprache für Ihr Projekt. Sagen Sie, was Sie wollen. Fordern Sie dies von Ihren Teamkollegen. Alles andere führt zu Missverständnissen, obschon die gleiche Sprache gesprochen wird. Stellen Sie sich einmal eine unklare Ausdrucksweise in einem internationalen Projekt, mit der Geschäftssprache Englisch, vor. Regel 10 Ein gemeinsames Vorhaben stellt hohe Anforderungen an die Kommunikation. Ein erfolgreicher Projektleiter hält seine Partner durch regelmäßige Information auf dem Laufenden. Diese Partner sollte er vor einer wichtigen Entscheidung konsultieren und Ihre Reaktionen berücksichtigen. So entsteht „nebenbei“ ein gut funktionierendes Frühwarnsystem. Berücksichtigen Sie dabei alle Beteiligten, auch diejenigen, die nur am Rande von einer Entscheidung betroffen sind. Auch sollten Sie den Fachjargon eines Linux-Projektes schnell erlernen und die spezifischen Begriffe bei der täglichen Kommunikation bewusst verwenden. Das verschafft Ihnen eine hohe Akzeptanz aus dem Projektumfeld und ein höheres Verständnis für die Sache.

© Frank Obels


Seite 147


Regel 11 Lassen Sie laufen, was gut läuft. Managen Sie Ihr Projekt, indem Sie die Risiken managen. Und diesbezüglich kümmern Sie sich besser um die Ursachen als um die Folgen. Sehr gut bewährt hat sich eine detaillierte Risikodokumentation. Bestimmen Sie monatlich im Rotationsprinzip ein Teammitglied als Risikobeauftragten. Dieser hat die Aufgabe „schwarz zu malen“! Und achten Sie auf „workaholics“ in Ihrem Team. In die richtige Richtung gelenkt, können diese ein Segen für das Projekt sein, in die falsche Richtung aber, ein unkalkulierbares Risiko sein. Ein workaholic kann in der Anfangsphase eines Projektes ein ausgezeichneter „risk finder“ sein. Regel 12 Projekte brauchen Rituale. Rituale helfen, die Aufmerksamkeit auf die Projektziele zu konzentrieren. Das Durchführen von sehr kleinen und kurzen Teambesprechungen kann ein Ritual sein, das Auszeichnen des Mitarbeiters der Woche (für fehlerfreie Arbeit oder die beste Idee) kann ein gutes Ritual sein. Mein Lieblingsritual ist es, jedes interne Projektmeeting damit zu beginnen, dass zufällig von mir ausgewählte Kollegen uns in ihren Worten darlegen, wer eigentlich unser Kunde ist und was er von uns erwartet. Dies hilft sehr eindrucksvoll, dass jedes Teammitglied ständig das Projektziel vor Augen hat. Regel 13 Übertreiben Sie es nicht mit den Prozessen. Prozessmanagement und Prozessverbesserung sind eine gute Sache und gute technische Mitarbeiter bemühen sich ohnehin darum, ganz gleich, ob man sie dazu anhält oder nicht. Ein zu hohes Maß an Standardprozessen hält den Mitarbeiter davon ab, nach Abkürzungsmöglichkeiten zu suchen. Jeder Mensch hat seinen Grund, warum er etwas auf eine bestimmte Art und Weise macht – er will es letztlich gut machen. Nutzen Sie dieses Potential Ihres Teams. Regel 14 Scheuen Sie sich nicht, Probleme „nach oben“ zu kommunizieren. Halten Sie keine Informationen zurück. Auch wenn Ihnen das nicht klar sein sollte, aber Ihr Projektauftraggeber sitzt im gleichen Boot wie Sie. Es geht ebenso um seinen Ruf wie um Ihren. Also berichten Sie ihm alle Fakten, schlagen Sie ihm Lösungen vor und verschonen Sie ihn von Entschuldigungen. Regel 15 Entwickeln Sie ein gesundes Meetingverständnis für Ihr Projekt. Ein Meeting, das ein Arbeitsergebnis erreichen soll, kann nicht mehr als fünf bis sieben Teilnehmer haben, um zu funktionieren. Alles, was über diese Zahl hinausgeht, sollten Sie als Informationsveranstaltung bezeichnen. Meetings mit großer Teilnehmerzahl bedeuten für eine Großzahl der Teilnehmer pure Zeitverschwendung. Kommunizieren Sie nach innen und außen eine Meetingkultur, die auch entsprechend zu leben ist. Regel 16 Ein Linux-Projekt stellt hohe Anforderungen an „Eduporting“, also einem Reporting mit Lehrcharakter. Je weniger das Management von dem Thema versteht (was bei Linux der Fall ist), umso häufiger müssen Sie den Führungskräften Berichte anbieten, am besten immer mit einem kleinen „Lernhäppchen“. Diese Reports sind politisch heiß, denn Sie laufen Gefahr, dem Manager das Gefühl zu geben, dass er nichts versteht. Ablehnung wäre die Folge. Also drücken Sie sich klar und einfach aus. Und vermeiden Sie Abkürzungen.

Seite 148


© Frank Obels


Regel 17 Das Top-Management hat viele Sorgen, nur eine davon ist Ihr Projekt. Also glauben Sie nicht, dass man Ihre Berichte bereits sehnsüchtig erwartet. Fassen die Ihre Berichte kurz. Wenn Sie Wochen-Reports verfassen, dann muss der Monats-Report noch einmal alle Informationen der Wochen-Reports enthalten. Gehen Sie nicht davon aus, dass der Manager sich noch an die Wochen-Reports erinnert. Täte er dies, brauchten Sie keine Monatsreports, Quartalsberichte und Jahresdarstellungen abzuliefern. Regel 18 Freundlich sein ist gut, Freund sein aber schlecht. Lassen Sie sich während eines Projektes in kein „Lager“ ziehen und vermeiden Sie Freundschaften. Eine freundliche Distanz zu jedermann ist das oberste Gebot. Ansonsten leiden Ihre Objektivität und Ihr Ruf. Regel 19 Ein Linux-Projekt ist ein technisches Projekt, wie jedes IT-Vorhaben. Und dort heißt die Devise: «keep it small and simple.» Techniker neigen zur Detailverliebtheit, finden verspielte Dinge toll und mögen komplizierte Konstrukte. Veranstalten Sie in Ihrem Projekt einen „Vereinfachungswettbewerb“. Wem es gelingt, das Ergebnis eines Kollegen sinnvoll zu vereinfachen, kriegt einen Bonus. Dieses Spiel lieben Techniker noch mehr. Regel 20 Wenn Sie Projektleiter sind, dann treffen Sie die Entscheidungen. Solange es keine schriftliche Anweisung gibt, dass Sie irgendwelche Entscheidungen nicht treffen dürfen, entscheiden Sie! Der schlimmste Fehler wäre, das Management um eine Entscheidung zu bitten, die Sie selbst hätten treffen können. Falsche Entscheidungen, die zu einem frühen Zeitpunkt getroffen wurden, lassen sich korrigieren. Richtige Entscheidungen, die zu spät kommen, nutzen nichts mehr.

3.7.2 Umgang mit diffusen Vorstellungen Zielgerichtetes Denken und Handeln scheint für viele Menschen ein großes Problem darzustellen. Allzu oft finden Sie in einem Projekt, insbesondere bei etwas Neuem wie Linux, Menschen, die nicht wissen, was Sie wollen. Vielleicht wissen diese Menschen, was sie nicht wollen. Stellen Sie sich vor, Sie rufen bei der Bestellhotline eines Versandhauses an und bestellen „nicht einen Rock“, „nicht eine Hose“ und „nicht ein Hemd“. Das höhere Management versucht im Top-Down-Ansatz mittels Zielvereinbarungen und Zielklarheit, zumindest seine Führungskräfte, zu einer klaren Ausdrucks- und Denkweise anzuhalten. Wenn also eine Projektidee aus dem Topmanagement heraus geboren wurde, haben Sie vielleicht eine Chance, eine halbwegs konkrete Zielvorgabe zu erhalten. Da Manager nicht ohne Grund als die Köpfe der Unternehmen bezeichnet werden, mag man unterstellen, dass sie eher dem Denken zugetan sind, als die Fachabteilungen, die eher ausführenden Charakter besitzen. Habe ich mit diesen Ausführungen wieder zahlreiche neue Freunde gewonnen?

© Frank Obels


Seite 149


Wie steht es um die konkreten Vorstellungen, wenn das Projekt von einer Fachabteilung initiiert wurde? Hat dann wenigstens der Projektauftraggeber konkrete Vorstellungen? Mein Lieblingsbeispiel aus der Praxis: Stellen Sie sich bitte die IT-Abteilung eines größeren mittelständischen Unternehmens vor. Die dort selbst entwickelte Abrechnungssoftware läuft langsam und instabil. Man hat bereits stärkere Server eingesetzt, doch das Leistungsbild ist nicht zufriedenstellend. Ihr Auftrag lautet klar und präzise: sorgen Sie dafür, dass die Software wesentlich schneller und endlich stabil läuft. Sie sind das erste Mal in der Rolle des Projektleiters und wissen, dass der erfolgreiche Abschluss Ihrer Karriere gut tun wird. Nach 3 Monaten haben Sie Ihr Projekt beendet – glauben Sie. Die Software läuft eindeutig schneller und stürzt auch weniger ab. Ihr Auftraggeber erzählt Ihnen, dass ihm die Software noch immer zu oft abstürze und noch schneller laufen sollte. Das Projekt wird deshalb nochmals verlängert, bis die Performance-Parameter stimmen. Willkommen im Kreise der frustrierten Projektleiter. Sagen Sie, was Sie wollen! So verlockend das Angebot auch sein mag, nichts ist für Ihre Karriere schlimmer als der Ruf des „ewigen“ (und damit erfolglosen) Projektleiters. Dazu gehört allerdings, dass Sie nicht nur Lernen Nein zu sagen, sondern eben auch das Vorleben, was Sie von anderen erwarten. Also definieren Sie für sich, wann für Sie das Projekt und die diesbezüglichen Vorstellungen transparent sind. Wenn Sie Ihre Vorstellungen und Anforderungen klar formuliert haben, dann sorgen Sie dafür, dass alle Beteiligten den gleichen Blick auf das Projekt bekommen. Wenn Ihre Aufgabe eine Linux-Desktop-Migration ist, dann ist das zu wenig. Welche Anwendungen sollen ersetzt werden? Ist der absolut gleiche Funktionsumfang gewünscht? Dann definieren Sie diesen Funktionsumfang. Wenn sich Ziele widersprechen Gerade bei größeren Projekten erleben Sie das Phänomen, dass sich die mühsam identifizierten Ziele widersprechen. Also weiß die Fachabteilung als Gesamtheit noch immer nicht, was sie will. Wiederum viele diffuse Gefühle. Nice-to-have-Optionen. Dann ist es Ihr Job, den kleinsten gemeinsamen Nenner zu finden. Jetzt bleibt nur noch der Schritt, sich ordentlich unbeliebt zu machen. Lassen Sie jeden Teilnehmer seine Ziele begründen. Warum muss dieses Ziel erreicht werden? Welche Konsequenzen hat es für das Unternehmen, wenn dieses Ziel nicht erreicht wird? Wie könnte eine vertretbare Kompromisslösung aussehen? Machen Sie sich lieber zu diesem Zeitpunkt beliebt. Der Ärger jetzt ist um ein vielfaches geringer als der spätere „Krieg“. Vielleicht erahnen Sie jetzt auch, warum ich Ihnen empfahl, Ihre Position mit Macht ausstatten zu lassen. Bereits in einem solchen frühen Stadium brauchen Sie sie.

Seite 150


© Frank Obels


Wenn der Endkunde nicht weiß was er will Die Ursache für diffuse Vorstellungen der Fachabteilung findet sich immer wieder in der Unentschlossenheit der Endkunden, die mit dem Projektergebnis später arbeiten wollen oder sollen. Auch diesbezüglich ein Beispiel aus der Praxis: die Vertriebsabteilung eines Elektronikherstellers fordert von der IT-Abteilung eine Vertriebsunterstützungssoftware. Aus Kostengründen soll eine Open Source-CRMSoftware eingesetzt werden. Die IT-Abteilung „bombadiert“ den Vertrieb nun mit ITspezifischen Fragen und verlangt eine Beschreibung der Mindestfunktionen. Der Vertrieb ist überfordert und meldet, sich teilweise widersprechende, Anforderungen zurück. Schließlich wird die Aussage getroffen, dass man einfach nur die umfangreichste Ausstattung bezüglich der vertrieblichen Funktionen wolle. Jetzt sind wiederum die ITMenschen überfordert. Dieses Sprach- und Verständnisproblem zu lösen ist nun ihr Job. Und wiederum der Rat, Ihren Job nicht zu beginnen, bevor nicht auch der Endkunde weiß, was er will. Denn seine Akzeptanz ist Ihr Erfolg. Ihr Projektauftraggeber „verzeiht“ Ihnen viel, wenn das Projekt erfolgreich ist – also gehen Sie in Ruhe zum Anwender und nehmen seine Wünsche auf. Bliebe noch dieses zu erwähnen: wenn der Endkunde tatsächlich nicht weiß, was er will, besteht die Möglichkeit, dass er Sie mit Wünschen überhäuft. Jetzt kommt es wieder auf Ihr Geschick an, diese Wünsche auf das notwendige und sinnvolle Maß zu reduzieren.

3.7.3 Entscheidungen werden nicht getroffen Es ist ein bekanntes Problem, dass viele Projekte unter Entscheidungsblockaden leiden. In einem Linux-Projekt haben Sie entweder die Möglichkeit, dies ganz extrem zu erleben oder aber so gut wie gar nicht. Der „Glücksfall“ ist, wenn Entscheidungen in Ihrem Linux-Projekt getroffen werden. Dann haben Sie entweder ein tolles Team, was die „oberen Etagen“ mit einschließt oder es hat sich eine Projektauffassung etabliert, die davon ausgeht, dass Linux etwas so Neues ist, dass man durchaus falsche Entscheidungen treffen darf. Letzteres betrachte ich als problematisch, aber ein Projektleiter kann diesbezüglich gut gegensteuern. Doch was soll man tun, wenn Entscheidungen, von oberster Stelle, nicht getroffen werden? Warum Entscheidungen nicht getroffen werden Sie brauchen eine dringende Entscheidung, aber es ist niemand da, der sie trifft. Ausdrücke, wie «es brennt», «show stopper» oder «Projekt ist gefährdet» zeugen eigentlich zunächst einmal nur von der Verzweiflung des Projektleiters, da er nicht im richtigen Augenblick den richtigen Ansprechpartner erreicht. Die typischen Fälle sind, dass der Entscheider nicht erreichbar ist oder seine Entscheidung vertagt hat oder aber gar nicht der Entscheider ist und selbst erst nachfragen möchte.

© Frank Obels


Seite 151


Wenn Sie in dieses Problemfeld geraten, so muss ich Sie zunächst einmal fragen, was Sie denn unternommen haben, um regelmäßig die wichtigsten Entscheider griffbereit zu haben. Dies ist vor Projektbeginn zu regeln. Wie haben Sie, falls der Fall doch einmal eintritt, die Eskalationsmechanismen definiert? Oder haben Sie ein Problem, den Vorstand anzurufen? Und noch eine Frage: welche Kommunikationswege nutzen Sie für Ihr Projekt: eigene oder die der Linie? Wenn Sie die der Linie nutzen, dann frage ich Sie, wozu Sie denn überhaupt ein Projekt haben? Die Antwort lautet also: Entscheidungen werden nicht getroffen, weil Sie sich nicht rechtzeitig darum gekümmert haben, den „menschlichen Faktor“ auszuschalten. Sie sind es also, der handeln muss. Was Sie generell tun können Machen Sie sich bemerkbar! Es geht um Sie und Ihr Projekt. Sprechen Sie Missstände an, unmittelbar nach Bekanntwerden und argumentativ sauber. Einer der beliebtesten Vorwürfe an den Projektleiter lautet: «warum haben Sie das denn nicht früher gesagt?» Und wenn man Sie fragt, wer denn da hinderlich sei, benennen Sie Ross und Reiter. Wie Sie auf Dauerabwesende reagieren können Ich sorge stets für Schmunzeln, wenn ich zu Projektbeginn die Urlaubs- und sonstigen Abwesenheitszeiten der Entscheidungsträger des Projektes abfrage. Dies geht bis hin zu wirklich bösen Reaktionen. Macht nichts! Die Argumentation ist einfach und einleuchtend: aufgrund einer gewissenhaften Projektplanung lässt sich ungefähr voraussagen, wann wichtige Entscheidungen benötigt werden. Ist zu dieser Zeit der Entscheider nicht da, hat das Projekt ein Problem. Deshalb trage ich den Urlaub der wichtigsten Entscheider in den Projektplan ein und schreibe den Namen des Stellvertreters dahinter. Prima, wie das wirkt, wenn Chefs etwas transparenter werden! Alternativ fordere ich für die Abwesenheitszeiten Entscheidungsvollmacht (und das als Externer!). Diese erhalte ich tatsächlich manchmal, in jedem Fall bekomme ich zumindest den Stellvertreter benannt, für den Erreichbarkeitsund Entscheidungspflicht besteht. Wie Sie auf Entscheidungströdler reagieren können Niemand trödelt aus reiner Boshaftigkeit! Führen Sie sich bitte dieses „Naturgesetz“ immer wieder vor Augen, wenn Sie einem Trödler begegnen. Für mich ist trödeln immer ein Hinweis auf einen Mangelzustand. Dies kann zunächst ein Mangel an fundierten Informationen sein. Was haben Sie an Informationen weitergegeben? Alles? Das ist nett von Ihnen. Ein Entscheidungsträger benötigt eine fundierte Entscheidungsvorlage, die letztlich in zwei Entscheidungsalternativen mündet. Alles fein mundgerecht zubereitet? Kurz und prägnant und deutlich formuliert. Mit Benennung der Konsequenzen, wenn die Entscheidung nicht gefällt wird, mit den Vor- und Nachteilen jeder Alternative.

Seite 152


© Frank Obels


Entscheidungsvorlagen sind ein wunderbares Steuerungsinstrument, nutzen Sie es ruhig. Vielleicht ist aber auch ein Mangel an Diplomatie Ihrerseits in Richtung des Entscheidungsträgers zu erkennen. Wenn Sie aufgrund der Projekthektik und der Dringlichkeit der benötigten Entscheidung vielleicht ein wenig zu forsch im Einfordern der Entscheidung waren, mag der Andere einfach nur beleidigt sein. Und verschleppt – und freut sich mit jedem Tag, den er erfolgreich verschleppen kann. Wenn Angst mit im Spiel ist Ein gern gesehener Mangel ist das sogenannte Rückgrat. Zwar haben wir Menschen alle eine Wirbelsäule, aber Sie irren, wenn Sie diesbezüglich auch das entsprechende Rückgrat unterstellen. Ängste, politische Gründe, persönliche Interessen – all dies mag zum Vertrödeln einer wichtigen Entscheidung führen. Dazu gehört auch die alte Projektweisheit, dass man manche Dinge nur lange genug aussitzen können muss. Also akzeptieren Sie, dass es Menschen gibt, die Angst haben, eine Entscheidung zum von Ihnen gewünschten Zeitpunkt zu treffen. Noch häufiger ist, dass der Entscheider keine Angst, aber ein Problem hat. So könnte es sein, dass seine Entscheidung irgendeinen Schwachpunkt bei ihm aufdecken würde oder ihn angreifbar macht. Auch hier sind wiederum Sie gefragt, diesmal Ihr Geschick als Berater oder Coach. Reden Sie mit dem guten Menschen, vielleicht sogar, in dem Sie ihn zum Abendessen einladen.

© Frank Obels


Seite 153


4 4.1

Alltagshilfen zum Schluss

Und nun setzen Sie Ihr Wissen um!

Sie haben sich bis zu dieser Seite durchgearbeitet. Dazu beglückwünsche ich Sie! Nun heißt es, den Alltag zu ändern und somit glücklicher und erfolgreicher zu sein. Also tun Sie es. Adenauer sagte: «Jeder Mensch hat eine Wirbelsäule, aber nicht jeder ein Rückgrat.» Sie haben es, sonst hätten Sie nicht bis hierher „durchgehalten“. Sie haben viel über gutes Projektmanagement in der Linux-Praxis gelesen. Sie haben Zeit und Gedanken in diese Lektüre investiert, sicherlich die eine oder andere neue Idee „geboren“. Ein wenig Mut für die Praxis, um das umzusetzen, was Sie in diesem Buch erfahren haben. Denn nur aus der Praxis (und nicht aus dem Schaden) wird man klug – nicht aus Büchern und Seminaren. Unterscheiden Sie sich ab heute von den Projektmanagern, die sich noch immer mit einer starken Verunsicherung tragen. Sie erkennen dies an dem zauderlichen Verhalten und Aussagen wie «es ist noch nicht der richtige Zeitpunkt» oder «ich bin noch nicht so weit!» Und vermeiden Sie bitte die folgenden Fehler: 1. Nehmen Sie sich nicht gleich den größten Brocken als Aufgabe her, sondern üben Sie erst einmal an den kleineren Herausforderungen. Ein Erfolg bringt den nächsten, gemäß dem bekannten Resonanzprinzip. Das kann aber auch in die andere Richtung funktionieren. Deshalb üben Sie erst einmal am kleinen, wo die Gefahr eines Misserfolges nicht so gross ist oder aber nicht so weh tut. 2. Wer keine Fehler macht, lernt auch nichts. Oder wie der Volksmund zu berichten weiß: wer nicht arbeitet, macht auch keine Fehler. Also: Fehler gehören dazu – bei jedem von uns! 3. In der Ruhe liegt die Kraft. Glauben Sie nicht, dass Sie schlagartig zum TopProjektmanager werden. Sie werden es, aber so etwas will wachsen. Also haben Sie mit sich ein wenig Geduld – und ein wenig Ausdauer. Denn dann geht alles plötzlich viel schneller, als Sie es erwarten.

Seite 154


© Frank Obels


4.2

Besondere Tipps für „Frischgebackene“!

Sollte es absehbar sein, dass Sie bald die Ehre haben werden, in den Stand der Projektmanager erhoben zu werden, dann laufen Sie dort erst einmal in ziemlich kleinen Schritten. Dies gilt noch stärker, sofern Sie absoluter Novize in diesem Geschäft sind! Und bitte lesen Sie dieses Buch, bevor Ihr Linux-Projekt beginnt. Visualisieren Sie, stellen Sie sich, während Sie das Buch „durchleben“, das echte Projekt so konkret wie möglich vor. So verinnerlichen Sie wesentliche Aspekte der Projektmentalität erheblich besser. Und nehmen Sie das Buch mit, wo immer Sie es bei sich haben können und schreiben Sie es ordentlich voll. Somit entsteht mit der Zeit Ihr individuelles und wertvolles Nachschlagewerk. Drucken Sie diese elektronische Version mehrfach aus und fügen Sie dann Ihre eigenen Notizen, je nach Projektart, in den Ausdruck mit ein. So bauen Sie sich Ihre eigene Wissenssammlung auf. Es lohnt sich! Auch das Führen eines Journals, so bezeichne ich ein Projekttagebuch, ist eine lohnende Sache. So können Sie nachlesen, was Sie „damals“ angewandt haben und ob es einer kritischen Beurteilung auch weiterhin standhält oder ob es Verbesserungen vorzunehmen gibt.

4.3

Die Strategie für den Erfahrenen!

Selbstverständlich möchte ich Ihnen nicht zu nahe treten, aber ich beobachte leider immer wieder einige typische Fehler meiner, bereits mit Erfahrung ausgestatteten, Kollegen. Gehen Sie also bitte nicht zu Ihrem Vorgesetzten oder Ihrem Lenkungsausschussmitglied und erzählen ihm, dass ab jetzt alles anders gemacht werden müsse. Selbst wenn Sie Recht haben, bringen Sie Ihren Gesprächspartner in die direkte Abwehrposition. Die verlässt er durch Angriff, dazu hat er im Regelfall die Macht und wird Ihnen „Besserwisserei“ vorwerfen und Sie „zur Ordnung rufen“. Zunächst einmal sollten Sie leise aber aufmerksam beobachten, dann besonders sauber dokumentieren und schließlich eine schriftliche Empfehlung „loslassen“. Warten Sie auf den richtigen Moment, wenn Sie etwas zu sagen haben – der wahrscheinlich wichtigste Aspekt Ihres zukünftigen Wirkens wird das perfekte Timing.

© Frank Obels


Seite 155


4.4

Und schließlich dies noch!

Holen Sie sich, wenn Sie sich bei einem wichtigen Projekt überfordert fühlen, lieber für einige Tage einen erfahrenen Projekt-Coach ins Boot. Es ist keine Schande, seine Grenzen zu kennen. Lassen Sie sich nichts anderes einreden! Nun wünsche ich Ihnen viel Erfolg im Projektmanagement im Allgemeinen und in Ihrem nächsten Linux-Projekt im Besonderen. Sollten Sie dieses Buch als hilfreich empfunden haben, so würde mich dies sehr freuen.

Seite 156


© Frank Obels


Möchten Sie informiert werden, wenn ein neues Pre-Release von

Linux-Projekte erfolgreich managen! zum weiterhin kostenlosen Download verfügbar ist? Dann senden Sie bitte eine E-Mail mit ein paar netten Worten an [email protected]!

© Frank Obels


Seite 157

Linux-Projekte erfolgreich managen

Praxishandbuch Unternehmensgründung: Unternehmen erfolgreich gründen und managen

Human Capital Management: Personalprozesse erfolgreich managen (German Edition)

Ökonomie der Buchindustrie: Herausforderungen in der Buchbranche erfolgreich managen

Erfolgreich verhandeln - Erfolgreich verkaufen

Erfolgreich abschleppen.or.flachlegen

Erfolgreich bewerben

DUDEN. Erfolgreich Bewerben GERMAN

Veränderungsprozesse erfolgreich gestalten

Aufatmen - Erfolgreich zum Nichtraucher

Erfolgsfaktor Verantwortung: Corporate Social Responsibility professionell managen

Pocket Power Soft Skills: Emotionen managen

Das große Verwalter-Handbuch. Wohnungseigentum sicher managen

Baudichtstoffe: Erfolgreich Fugen abdichten German

Visual Basic 2010 – erfolgreich programmieren

Pocket Power Soft Skills: Emotionen managen

Wie man erfolgreich Frauen verführt

Erfolgreich gegen Depression und Angst

ebooks erfolgreich schreiben und verkaufen

Erfolgreich abnehmen beginnt im Kopf

Erfolgreich abnehmen beginnt im Kopf

Wie Man Erfolgreich Frauen Verführt

Endlich Frustfrei! Chefs erfolgreich führen

Die Innovationsmaschine: Wie die weltbesten Unternehmen Innovationen managen German

Der Steuerprozess: Erfolgreich klagen - Ablauf, Chancen, Kosten

UML 2 erfolgreich einsetzen: Einführung und Referenz

Change Management: Wandlungsprozesse erfolgreich planen und umsetzen

Nein sagen und trotzdem erfolgreich verhandeln

Jetzt aber! Erfolgreich anlegen in 8 Schritten

Testtraining 2000plus. Einstellungs- und Eignungstests erfolgreich bestehen

Linux-Projekte erfolgreich managen

Praxishandbuch Unternehmensgründung: Unternehmen erfolgreich gründen und managen

Human Capital Management: Personalprozesse erfolgreich managen (German Edition)

Ökonomie der Buchindustrie: Herausforderungen in der Buchbranche erfolgreich managen

Erfolgreich verhandeln - Erfolgreich verkaufen

Erfolgreich abschleppen.or.flachlegen

Erfolgreich bewerben

DUDEN. Erfolgreich Bewerben GERMAN

Veränderungsprozesse erfolgreich gestalten

Aufatmen - Erfolgreich zum Nichtraucher

Erfolgsfaktor Verantwortung: Corporate Social Responsibility professionell managen

Pocket Power Soft Skills: Emotionen managen

Das große Verwalter-Handbuch. Wohnungseigentum sicher managen

Baudichtstoffe: Erfolgreich Fugen abdichten German

Visual Basic 2010 – erfolgreich programmieren

Pocket Power Soft Skills: Emotionen managen

Wie man erfolgreich Frauen verführt

Erfolgreich gegen Depression und Angst

ebooks erfolgreich schreiben und verkaufen

Erfolgreich abnehmen beginnt im Kopf

Erfolgreich abnehmen beginnt im Kopf

Wie Man Erfolgreich Frauen Verführt

Endlich Frustfrei! Chefs erfolgreich führen

Die Innovationsmaschine: Wie die weltbesten Unternehmen Innovationen managen German

Der Steuerprozess: Erfolgreich klagen - Ablauf, Chancen, Kosten

UML 2 erfolgreich einsetzen: Einführung und Referenz

Change Management: Wandlungsprozesse erfolgreich planen und umsetzen

Nein sagen und trotzdem erfolgreich verhandeln

Jetzt aber! Erfolgreich anlegen in 8 Schritten

Testtraining 2000plus. Einstellungs- und Eignungstests erfolgreich bestehen

Recommend Documents