Linux-Projekte erfolgreich managen - netzwerk

Transcription

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
© 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.
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.
Projektumfeldanalyse
Personen-Gruppen-Betrachtung
Personen
Interessensgruppen
Seite 98
Einstellung
Macht+ Erwartungen
position
- Befürchtungen

Maßnahmen
wer - wann - was
© Frank Obels
Projektumfeldanalyse
Einflußgrößen-Betrachtung
Sachlich-Inhaltliche
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.
Meilensteinplan
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 obels@inconet.de!
© Frank Obels
Seite 157

Linux-Projekte erfolgreich managen - netzwerk

Transcription

Similar documents

Aufgaben der Schulleitung bei schwerbehinderten

Einführung in Linux

PDF-Datei - Der millin Verlag

Lösung der Fallstudie - GPM Deutsche Gesellschaft für

Trainingssteckbrief Project Management Professional (PMP)® I PMI

f.i.t.

Projektarbeit AMS