2. Inhaltsverzeichnis

Deckblatt

1. Danksagung

2. Inhaltsverzeichnis

3. Leitfaden Projektabwicklung

3.1. Einleitung – Situationsbetrachtung

3.1.1. Ist-Zustand

3.1.1.1. Allgemeines

3.1.1.2. Betrachtung der Organisationsform

3.1.1.3. Schnittstellenbetrachtung

3.1.1.4. Betrachtung der Projekte zwecks Abgrenzung

3.1.1.5. Betrachtung der Projekte zwecks Einordnung

3.1.2. Soll-Zustand

3.1.3. Projektstrukturplan

3.2. Hauptteil

3.2.1. Projektstrukturplan des Teilprojektes

3.2.2. Erste Betrachtungen

3.2.2.1. Risikobetrachtung

3.2.2.2. Qualifizierungsmaßnahmen

3.2.2.3. Ressourcenbetrachtung

3.2.2.4. Kostenbetrachtung

3.2.2.5. SWOT-Analyse

3.2.2.6. Qualitätssicherung durch Dokumentation

3.2.2.7. Pareto-Analyse zur Fehlerbetrachtung

3.2.2.8. Projektgruppenspezifische Betrachtungen

3.2.3. Auswertungen aufgrund der geführten Interviews

3.2.3.1. Bewertung aus administrativer Sicht

3.2.3.2. Bewertung aus vertrieblicher Sicht

3.2.3.3. Bewertung aus technischer Sicht

3.2.3.4. Bewertung aus Entwicklungssicht

3.2.3.5. Bewertung aus projektabwickelnder Sicht

3.2.3.6. Bewertung aus Finanzsicht

3.2.4. Erstellung

3.2.4.1. Zusammenfassung IST-Zustand

3.2.4.2. Auswahl der Methodik

3.2.4.3. Risikobetrachtung

3.2.4.4. Betrachtungen und Vergleich mit dem SOLL-Zustand

3.2.4.5. Vorgaben für den Leitfaden

3.2.5. Ausklang

3.2.5.1. Abschließende Vorbereitungen

3.2.5.2. Präsentation, Übergabe und Projektabschluss

3.3. Abschluss

3.3.1. Fertiger Leitfaden

3.3.2. Bewertung

4. Anhang

4.1. Unternehmensstruktur der Clarity AG

4.2. Organigramm der Clarity AG

4.3. Projektauftrag des Unternehmens

4.4. Projektstrukturplan des Gesamtprojektes

4.5. Projektstrukturplan des Teilprojektes Leitfaden

4.6. Die Arbeitspakete der einzelnen Teilprojekte im zu betrachtenden Teilprojekt

5. Literaturverzeichnis

6. Glossar

7. Ehrenwörtliche Erklärung

3. Leitfaden Projektabwicklung

Nach der Stellung des Projektantrages wurde ,wie bereits mitgeteilt beschlossen, die Projektarbeit und deren Dokumentation als reales Projekt zeitaktuell bei der Clarity AG (kurz CAG) in Bad Homburg durchzuführen, einem Unternehmen im Bereich Sprachanwendungen / Sprachportale. Da sich die Anforderungen im Wesentlichen gleichen - es handelt sich hierbei ebenfalls um ein Organisationsprojekt, welches als unterstützendes Projekt die Ablauforganisation betrifft, Projektauslöser war die Idee der Unternehmensleitung - seien hier konkret die Unterschiede aufgeführt:

• Das Arbeitsumfeld ist ein wenig anders, genaueres wird im Abschnitt 3.1.1. IST-Zustand beschrieben.

• Der Titel der Projektarbeit wurde zwecks besserer Akzeptanz in „Leitfaden Projektabwicklung“ abgeändert, da im Unternehmen z.Z. keine ISO 9000-Zertifizierung geplant ist.

• Die Gesamtlaufzeit des Projektes beträgt 12 Monate, davon ist als Teilprojekt die Erstellung eines Konzeptes auf Basis der zu ermittelnden Daten im Rahmen von zwei Monaten vorgesehen.

• Der Projektleiter ist ein externer Mitarbeiter, der für die Zeit des Teilprojektes ohne Linienverantwortung angestellt ist und hofft, Leiter des Gesamtprojektes zu werden.

Die auf diesen geänderten Umständen basierende Planung des Teilprojektes kann der unten stehenden Tabelle 1 (Tab.) entnommen werden.

0. Projektstart (Vorbereitung) 5 Personentage

1. Aufnahme IST- und SOLL-Zustand 10 Tage Interviews

2. Auswertung der Gespräche, Planung des Leitfadens, QS 5 Personentage

3. Erstellung des Leitfadens 5 Personentage

4. Abschluss (Abstimmung, Präsentation und Übergabe) 5 Personentage

5. Dokumentation 15 Personentage

3.1. Einleitung - Situationsbetrachtung

3.1.1. IST-Zustand

3.1.1.1. Allgemeines

Die Clarity AG, „the intelligent voice portal technology company“ wurde im Juni 2000 mit Stammsitz in Bad Homburg gegründet. Sie ist mit über 70 MA in Bad Homburg und den Niederlassungen in Hamburg, Stuttgart, Wien und Zürich tätig. Die CAG ist als Konzern mit vier Tochtergesellschaften in Bonn, Bad Homburg und Kiew vertreten, weitere Beteiligungen existieren in Köln und Crailsheim. Genaueres kann man Abbildung 1 (Abb. 1) im Anhang entnehmen.

Die CAG hat es sich zum Ziel gesetzt, Sprachportale zu entwickeln und diese zu vertreiben. Sprachportale sind natürlichsprachliche Dialogsysteme (NLU), die der Automatisierung von Telefonstandardanfragen dienen und multimedial erreichbar sind. Sie gewährleisten, Dialoge zu führen, bei denen der Endkunde – fast – nicht bemerkt, dass er mit einem Computer spricht. Damit wird nach der Installation für den CAG-Kunden als Anbieter des Sprachportales eine leistungsfähigere Bedienung der Märkte, Mitarbeiter und Geschäftspartner möglich. Anwendungsmöglichkeiten für diese Technologie gibt es derer viele.

Die CAG strebt eine Marktführung in ihrer Kernkompetenz an. Diese bezieht sich auf die drei Produkte V/3-Plattform, Clarity Contact Manager (CCM) und SoftTel. Das Unternehmen hat den Markt auch bis zum heutigen Tage erfolgreich durchdrungen, im Bereich NLU ist der Wettbewerb denkbar schlecht aufgestellt. Somit ist die V/3-Plattform bisher von Konkurrenzprodukten unerreicht, auch das zweite Produktstandbein CCM wurde bisher als hervorragendes Produkt auf dem Markt platziert. Im alteingesessenen Telefonie-Markt gibt es für das dortige Produkt der Clarity AG SoftTel noch ernst zunehmende Konkurrenz, welche aber nur gegen dieses eine Standbein antritt.

3.1.1.2. Betrachtung der Organisationsform

Das Unternehmen selbst teilt sich als klassische Linienorganisation in drei Geschäftsbereiche, welche jeweils von einem Vorstandsmitglied geführt werden. Diese sind die Bereiche Finanzen mit Ihrem Finanzvorstand (CFO), Vertrieb mit ihrem Vertriebsvorstand (CSO) und Technik mit dem Technikvorstand (CTO). Dem Vorstand selbst steht der Vorstandsvorsitzende (CEO) vor. Der Geschäftsbereich Technik wird in Professional Services (PS) und Entwicklung (SD) aufgeteilt, welche auch in der Clarity Ukraine Enterprises (CUE) vorhanden sind. Der Vertrieb besteht aus dem Großkundenvertrieb (LS), dem Partnervertrieb (SP) und dem Direktvertrieb (DS), welchem aktuell auch die international tätigen Vertriebsmitarbeiter (IS) zugeordnet sind. Dem Unternehmensteil Finanzen sind die Abteilungen Rechnungswesen (Rw), Marketing (M), Investor Relations (IR) und Administration (Ad) zugeordnet (siehe Abb. 2 im Anhang).

Viele organisationsstrukturtypischen Eigenschaften lassen sich hier feststellen: Aufgrund der umfassenden Kommunikationswege ist der Vorgesetzte in der Regel informiert. Es gibt eine gute Abgrenzung zum Kunden, die Verantwortlichkeiten in der Linie sind klar geregelt, standardisierte Arbeitsabläufe werden gerade vervollständigt und der langfristige Personaleinsatz für eine Tätigkeit gewährt Sicherheit durch Gewöhnung. Nachteilig wirkt sich aus, dass die Kommunikationswege sehr lang und verschlungen sind, was nicht nur kundenunfreundlich ist, sondern auch bereits zu interen Informationsverlusten geführt hat. Es kommt häufig zum unproduktiven Verweis auf die Zuständigkeiten, dies führt zu Gruppenbildung und Feindbildern und man kommuniziert vorwiegend nur noch über die Vorgesetzten miteinander. Insofern wird ein Projekt meist zur Pflicht und der Kunde wird in manchen Fällen wie ein Ärgernis wahrgenommen. Zur Verkürzung der Kommunikationswege kann es seitens des Kunden zu Ausbruchsversuchen aus dem Kommunikationsschema (sofern vereinbart) kommen und z.B. in der Projektabwicklung der Vetriebsmitarbeiter seitens des Kunden Beschwerden über angeblich unzureichende Projektabwicklung erhalten. Damit wird das Projekt immer schwerer kontrollierbar, bei geschicktem Einsatz durch den Kunden sind die Abteilungen mehr mit Informationsabgleich und gegenseitigen Schuldzuweisungen statt mit ihrer eigentlichen Tätigkeit beschäftigt.

3.1.1.3. Schnittstellenbetrachtung

Desweiteren wurden die Schnittstellen für die Durchführung des Projektes zu den einzelnen relevanten Unternehmensbereichen festgelegt und die jeweiligen Ansprechpartner identifiziert:

Tab. 2: Schnittstellen-Betrachtung

Es wurden mit den identifizierten Gesprächspartnern, welche aus unserer Sicht für das Teilprojekt „Aufnahme“ relevant waren, z.T. mehrere Interviews geführt, welche dann in der Auswertung das in 3.2.3. Bewertungen dargestellte Bild ergaben. Leider gab es im Bereich „Projektmanagement“ nur ein Gespräch, da der Mitarbeiter kurze Zeit später überraschend das Unternehmen verließ. Im Allgemeinen waren die einzelnen Gespräche in einem zeitlichen Rahmen unter einer Stunde angesiedelt, um Störungen des Ablaufes im Bereich Tagesgeschäft so wenig wie möglich aufkommen zu lassen.

3.1.1.4. Betrachtung der Projekte zwecks Abgrenzung

Ein Projekt definiert sich bekanntermaßen unter anderem durch seinen zeitlichen Rahmen, es gibt einen definierten Starttermin und eine geplante Endzeit. Während des Projektes wirken Störungen auf das System ein, welche bei bekanntem Input nicht unbedingt konkret den Output vorhersagen lassen, je nach einwirkenden Störgrößen.

Abb. 3: Projektgrößen

Das Ziel muss es sein, Störungen innerhalb der Systemgrenzen weitestgehend zu vermeiden, bzw. nach außen zu drängen, um die Planung des Gelangen vom Input zum Output möglichst zeitnah und komplett zu realisieren. Gelingt dies nicht oder nur unzureichend, gerät das Projekt aus den Fugen und sprengt damit z.B. den zeitlichen Rahmen.

Die gleichen Betrachtungen lassen sich natürlich auch auf den finanziellen Rahmen anwenden.

Eng mit den beiden Betrachtungen verbunden ist selbstverständlich auch die Betrachtung des Rahmens der Ressourcen, da bekanntermaßen diese drei Faktoren, Zeit, Geld und Ressourcen, die Eckpunkte eines jeden Projektes darstellen und sich gegenseitig beeinflussen [1].

3.1.1.5. Betrachtung der Projekte zwecks Einordnung

Wir erwarteten auch in diesem Hause drei Arten von Projekten vorzufinden:

• Routineprojekte

• Innovationsprojekte

• Strategieprojekte

Wie sich später in den Ausführungen zeigen wird, sind die Routineprojekte bisher nicht vorhanden, es sind entweder noch keine Vorgänge definiert oder durch in 3.1.1.4. Betrachtung der Projekte zwecks Abgrenzung dargelegten Störungen wird ein Projekt im Übermaß beeinflusst, sodass die Beendigung des Projektes zum obersten Ziel wird, ungeachtet der Qualität des Outputs oder der Zeit. Es wird also mit zur Aufgabe werden, Routinen zu definieren.

Vorwiegend im technischen Bereich werden aktuell Innovationsprojekte durchgeführt, um hier Vorhandenes zu optimieren bzw. mit einem Mehrwert zu versehen. Bereichsübergreifend sind solche Projekte jedoch aktuell nicht anzutreffen.

Im Unternehmen selbst sind Strategieprojekte bereits angelaufen, wobei als Beispiel das Globalisierungsprojekt zu erwähnen wäre, welches die langfristigen Ziele der CAG verfolgt. Dies wäre dann auch ein vernünftiger Ansatz, um aus dem Unternehmensziel, der Generierung eines Mehrwertes für die Shareholder, über die Umsetzung von Strategieprojekten durch Unterstützung von Innovationsprojekten vernünftige operative (Routine-) Projekte zu entwickeln.

3.1.2. SOLL-Zustand

Basierend auf den aktuellen Verhältnissen ist dem Vorstand ein mögliches Mißverhältnis im Bereich Projektabwicklung aufgefallen. Mittlerweile werden Projekte aus Sicht des Vorstandes zu aufwändig und zu langsam abgewickelt. Dies bedingt langfristig gesehen ein Problem für das Unternehmen, da mit den aktuellen Mitarbeitern und den durchschnittlichen Projektlaufzeiten die Umsatzziele für das laufende Geschäftsjahr weit unterschritten werden. Zur Behebung dieses Mißverhältnisses wird eine Optimierung im Bereich Projektabwicklung angestrebt, zu diesem Zweck wurde extern ein Projektleiter verpflichtet, der sich im ersten Schritt mit diesem Thema befassen und Lösungsvorschläge entwerfen soll. Diese würden dann in weiteren Schritten umgesetzt werden.

Zur Konkretisierung der Absichten wurde eine Zielvereinbarung mittels Zielkreuz erstellt, welche letztendlich im Projektauftrag mündete.

Tab. 3: Zielvereinbarung mittels Zielkreuz [1]

Das bedeutet hier im beschriebenen Fall:

Tab. 4: Konkretisiertes Zielkreuz

Aufgrund dieser Betrachtung entstand der Projektauftrag, welcher in Abbildung 4 dargestellt ist.

Abb. 4: Projektauftrag

Hierbei wurde ein wöchentliches Reporting seitens des Projektleiters an den Auftraggeber vereinbart, Eskalationsprozesse wurden nicht vorgesehen, im Problemfall kümmert sich der Projektleiter aufgrund seiner Qualifizierung selbst um die Lösung, bei scheinbar nur schwer oder gar unlösbaren Problemen ist ein direkter Kontakt zum Vorstandsvorsitzenden möglich. Allerdings ist dieser Kontakt selten zeitnah realisierbar.

Vom beabsichtigten Projekt, der Erstellung eines Leitfadens Projektabwicklung, zwecks Optimierung der Projektabwicklung, inklusive besserer Nutzung der vorhandenen Ressourcen zur Reduzierung der durchschnittlichen Projektlaufzeiten um 50 %, innerhalb der nächsten zwölf Monate, verspricht sich der Vorstand ein wesentliches Verbesserungspotential zur Erreichung von Unternehmenszielen. Somit ist der Nutzen als groß zu bewerten, was möglicherweise einen hohen Kostenaufwand rechtfertigen würde, falls der zu erarbeitende Vorschlag einen solchen vorsehen würde. Eine prinzipielle Veränderungsbereitschaft, auch zu größeren Umwälzungen, wäre beim Auftraggeber vorhanden, ist jedoch bei den Mitarbeitern in der aktuellen Situation eher weniger zu erwarten. Die hohe Arbeitsbelastung lässt beabsichtigte Änderungen grundsätzlich in einem negativen Licht erscheinen, da eine neutrale Aufwand / Nutzen - Betrachtung seitens der Mitarbeiter momentan nicht stattfindet. Allerdings würde ein entsprechender Verbesserungsgrad auch die Durchführung von seiten der Belegschaft anfänglich nicht gewünschten Veränderungen rechtfertigen und im Endeffekt auch zu einer nachträglichen Billigung führen. Dahingehend würde seitens des Auftraggebers ein langsamer Verbesserungsprozess, bei gleichzeitiger Akzeptanz durch die Belegschaft, präferiert werden. Außerhalb des Unternehmens profitiert der Kunde von diesem Projekt, es verhilft ihm zu besseren Projekten mit kürzerer Laufzeit und damit geringeren Kosten, die Abwicklung wird professioneller und effektiver.

In einer kurzen Analyse wurde die Unternehmensphilosophie [2] einer genaueren Betrachtung unterzogen. Dies ergab folgende wesentliche Aspekte:

• Wissen von Menschen steigern

• Verantwortung (des Unternehmens) [...] besonders gegenüber seinen Angestellten [...]

• Selbstverantwortung der Mitarbeiter steht im Mittelpunkt [...]

• Energie des gesamten Teams [...] auf permanentes Mit- und Neudenken fokussieren.

• Auch die Einstellung der Mitarbeiter zu ihrer Arbeit spielt für den Erfolg [...] eine besondere Rolle.

• Auch für das Durchdenken von Handlungsoptionen ist Ausdauer unerlässlich, um so optimale Lösungen zu finden.

• Intelligent arbeiten bedeutet auch, [...] sich selbst in angemessenem Maße [...] zu hinterfragen.

• Die Grundeinstellung gegenüber [...] unserer Arbeit ist von Optimismus geprägt.

Diese Grundaussagen wurden als Rahmenbedingungen für das Projekt mit übernommen.

3.1.3. Projektstrukturplan

Infolgedessen stellt sich aktuell das vom Vorstand beabsichtigte Gesamtprojekt „Optimierung“ mit seinen Teilprojekten Leitfaden, Einführung, Prüfung und Verbesserung (siehe Abb. 5 im Anhang) entsprechend dem Deming-Zyklus (PDCA) wie folgt dar:

Abb. 6: Projektstrukturplan des Gesamtprojektes entsprechend Deming-Zyklus

Zunächst wird die einzuführende Maßnahme, hier die Optimierung, geplant. Dies beinhaltet z.B. die Festlegung von Ressourcen. Nach erfolgter Planung und diesbezüglicher Abstimmung wird die Maßnahme eingeführt. Um weitere Fehlerquellen, die noch nicht beachtet wurden, zu entdecken und entsprechend zu handeln, wird die neue anzuwendende Maßnahme in dem Umfeld, in dem sie läuft, überprüft. Tauchen trotz Planung unerwartet Probleme auf, werden diese im vierten Schritt vollständig abgestellt. Das Denkschema gleicht einer Endlosschleife: nach erfolgter Verbesserung der Prozesse werden diese wieder betrachtet und neue, vielleicht erst entstandene Fehler gefunden, was zu einer erneuten Planung einer Maßnahme führt und den Kreislauf von vorne beginnen lässt.

3.2. Hauptteil

3.2.1. Projektstrukturplan des Teilprojektes

Das Teilprojekt „Leitfaden“, welches von jetzt ab als mein verantwortliches Gesamtprojekt betrachtet werden soll, gliedert sich wie der Abb. 7 zu entnehmen ist in die Teilbereiche

• Aufnahme,

• Auswertung,

• Erstellung,

• Abschluss und

• Dokumentation,

Abb. 7: Projektstrukturplan des Teilprojektes Leitfaden

welche inklusive ihrer Arbeitspakete im Anschluss aus Abb. 8 - 12 zu ersehen sind.

Abb. 8: Arbeitspakete des Teilprojektes „Aufnahme“

Abb. 9: Arbeitspakete des Teilprojektes „Auswertung“

Abb. 10: Arbeitspakete des Teilprojektes „Erstellung“

Abb. 11: Arbeitspakete des Teilprojektes „Abschluss“

Abb. 12: Arbeitspakete des Teilprojektes „Dokumentation“

Teambildende Maßnahmen wie

• ein Kick-Off-Meeting,

• Gruppenfindungs-Methoden und

• Schaffung von Motivation

waren für dieses Projekt nicht erforderlich und wurden darum im Projektstrukturplan nicht berücksichtigt, da das Team nur aus einer Person bestand.

Die Bereiche Aufnahme und Auswertung wurden im Verlauf des Projektes noch um einige Bereiche erweitert, welche dann in den jeweiligen Abschnitten auch beschrieben werden.

3.2.2. Erste Betrachtungen zwecks Planung und Qualitätssicherung

3.2.2.1. Risikobetrachtung

Eine erste Risikobetrachtung kam zu folgendem Ergebnis:

Der Wertebereich der Eintrittswahrscheinlichkeit sowie der Auswirkung erstreckt sich hierbei von 0 bis 10

Tab. 5: Risiko-Betrachtung

Aufgrund der hohen Auswirkung für die Bereiche Akzeptanz und Unterstützung hat der Projektleiter eine vertrauensbildende Maßnahme veranlasst, die den Projektstart erleichtern sollte. Durch den Vorstandsvorsitzenden sollte eine vom Projektleiter erstellte Vorlage als Mail versandt werden, die die Belegschaft kurz über den Grund seiner Anwesenheit und das Projekt informiert. Dadurch sollten mögliche Ängste vorzeitig abgebaut werden, indem klar signalisiert wurde, dass seine Anwesenheit für niemanden eine Bedrohung darstellt. Somit würden die Risiken im Bereich Akzeptanz und Unterstützung auf ein akzeptables Maß reduziert werden. Leider wurde die Mail seitens der Unternehmensleitung nicht rechtzeitig versendet, zu einem späteren Zeitpunkt wurde dann die Gelegenheit als vertan bewertet.

Demnach wurde seitens der Projektleitung eine weitere Marketingmaßnahme vorgeschlagen, um das Projekt nicht zu gefährden. Eine Informationsveranstaltung für alle Mitarbeiter sollte als Hauptziel nun nicht mehr die Anwesenheit des Projektleiters erläutern, sondern das beabsichtigte Projekt als solches vorstellen. Eine Akzeptanz für das Projekt könnte als positiver Nebeneffekt für die verbleibende Zeit auch die Arbeit des Projektteams erleichtern. Diese Maßnahme wurde aufgrund des akuten Leistungsdrucks im Unternehmen von der GF in die Zeit nach diesem Teilprojekt gelegt.

Für die Risiken „keine Zeit“ und „keine Unterstützung“ wurden organisatorische Gegenmaßnahmen vorgesehen. Da die Mitarbeiter sehr großem Leistungs- und Erfolgsdruck ausgesetzt waren und es bereits mehrere Maßnahmen mit Interviews im Hause gegeben hatte, wurden die Interviews sorgsam vorbereitet, konkrete Fragebögen für jeden Themenbereich erarbeitet und nach jedem Interview die bereits gewonnen Informationen verarbeitet. Nur bei wichtigen Kernfragen wurde nicht darauf verzichtet, diese trotz vorhandener Antworten bereichsübergreifend zu stellen, um einen Überblick über unterschiedliche Sichtweisen zu erlangen.

Für die Risiken „keine Lust“ und „keine Ahnung“ wurde die Eintrittswahrscheinlichkeit als sehr gering bewertet. Somit wurden sie trotz hoher Auswirkung von weiteren Betrachtungen ausgeschlossen. Für das Risiko „keine Ahnung“ wurde weiterhin angenommen, dass die Gegenmaßnahme „sich informieren“ als Grundvoraussetzung zur Durchführung eines Projektes gehört.

Für das Risiko „kein Geld“ für den Projektleiter wurde die Auswirkung für eine weitere Betrachtung als zu gering bewertet.

3.2.2.2. Qualifizierungsmaßnahmen

Eng mit dem oben Beschriebenen verknüpft sind die im Rahmen dieses Projektes notwendigen Qualifizierungsmaßnahmen. Als Qualifizierungmaßnahme ist die Information der betroffenen Abteilungen und ihrer Mitarbeiter vorgesehen, wie bereits unter 3.2.2.1. Risikobetrachtung erwähnt wurde. Im Rahmen einer Veranstaltung werden die Auslöser und das Konzept vorgestellt und Fragen beantwortet.

Eine weitere Qualifizierungsmaßnahme kann eine Einführung der betroffenen Mitarbeiter in die ggf. neu zu nutzenden CASE-Systeme sein. Hierbei wäre vorab zu prüfen, ob diese Maßnahme nicht zuletzt aus Kostengründen intern abgedeckt werden kann. Es gibt z.B. im Bereich Open Source verschiedene Tools, die häufig eingesetzt werden und das Know How hierfür meist bei dem einen oder anderen Mitarbeiter bereits vorhanden ist. Deswegen würde als Beispiel die Einführung eines Bugzilla-Fehler-Management-Tools, die Verwendung eines CVS-Repositorys oder die Benutzung eines kostengünstigen Projektmanagement-Tools unter www.projectplace.de sehr wahrscheinlich bereits einen geübten User in den Reihen der eigenen Mitarbeiter finden lassen, der im Rahmen eines oder mehrerer Seminare sein erworbenes Wissen an die Mitarbeiter weitergeben kann und im Rahmen eines Coachings auch die ersten Benutzerschritte ggf. überwachen und begleiten kann.

3.2.2.3. Ressourcenbetrachtung

Als Ressourcen sind zu unterscheiden:

• personell Mitarbeiter für Sales, Service, Entwicklung, Marketing, Rechnungswesen

• technisch Arbeitsplatz, Kaffeeküche = Infrastruktur

  Hardware, Software = Entwicklungs- und Testumgebung

  Telefon, Mobiltelefon, Mail, Fax = Kommunikation

  Fahrzeug mit Freisprecheinrichtung

• finanziell keine, Arbeitsleistung siehe personell

  Equipment, siehe technisch

Diese Ressourcen sind bereit zu stellen und zu pflegen. Allerdings können hier organisatorisch Einsparpotentiale genutzt werden. Z.B. benötigt nicht jeder Service-Mitarbeiter zur Applikationsentwicklung eine komplette Testumgebung für jede Konfigurationsmöglichkeit. Je nach Testhäufigkeit könnte sogar ein komplett für alle Konfigurationsmöglichkeiten ausgestatteter Testplatz genügen (Software-Management).

Desgleichen muss nicht jeder Mitarbeiter in jedem Bereich fortgebildet werden.

Für die Durchführung dieses Projektes gab es im Bereich Ressourcen jedoch erhebliche Engpässe, obwohl außer dem Projektleiter keine personellen Ressourcen benötigt wurden, abgesehen von den Gesprächspartnern der Interviews. Die geplante Beendigung des Projektstartes hat sich dadurch um mehrere Wochen hinauszögert. Organisatorische Engpässe in verschiedensten Bereichen führten dazu, dass eine rudimentäre Arbeitsumgebung erst nach mehr als zwei Wochen vorhanden war, weitere technische Mißverhältnisse mussten umgangen werden. Somit lässt sich vorab festhalten, dass bei entsprechender Kommunikation und einer vernünftigen Organisation die Motivation bei vorhandenen Ressourcen und deren normalen Auslastung als vorhanden angenommen werden darf und ein vernünftiges Arbeiten möglich ist. Ob es sich jetzt im Fall des Projektleiters um einen außergewöhnlichen Einzelfall oder doch eher um die Regel handelt, ist zu prüfen. Es ist jedoch zu vermuten, dass es sich nicht um einen Einzelfall handelte und dies hätte dann erheblichen Einfluß auf die Erstellung des Leitfadens.

3.2.2.4. Kostenbetrachtung

Wie im obigen Kapitel ausgeführt, so sind keine finanziellen Ressourcen für dieses Projekt vorgesehen. Allerdings können gewisse, der in 3.2.2.2. Qualifizierungsmaßnahmen beschriebenen, Maßnahmen eine finanzielle Investition bedeuten, die sich aber erst mit der Notwendigkeit zur Einführung der CASE-Software ergibt. Darum soll dieser Punkt bis zur endgültigen Klärung dieser Notwendigkeit vorerst zurückgestellt werden.

Die personellen Ressourcen sind alle vorhanden und sollen auch nicht über Gebühr in das Projekt eingebunden werden sondern nur als Informationsquelle zur Datensammlung neben ihrer eigentlichen Tätigkeit, und vor allem ohne diese zu beeinflussen, genutzt werden.

Die technischen Ressourcen sind zum größten Teil vorhanden, die fehlenden sollen unter der Voraussetzung beschafft werden, dass sie nach Ablauf des Projektes dem normalen Equipment zugeordnet werden und regulär verwendet werden können.

Somit sind keine finanziellen Ressourcen vom Auftraggeber vorgesehen.

3.2.2.5. SWOTS-Analyse

In einer Untersuchung der Projektsituation wurde auch eine SWOTS-Analyse zur Erfassung der internen & externen Faktoren durchgeführt. Das Ergebnis ist in Tabelle 6 dargestellt.

Tab. 6: SWOTS-Analyse

Diese Analyse wurde drei Wochen später von der GF in einer für alle Mitarbeiter einberufenen Veranstaltung in ähnlicher Form dargestellt und deshalb bestätigt. Sie zeigt uns auf einfache Art und Weise, was sich bisher bewährt hat und folglich bewahrenswert ist. Auf der anderen Seite ist aber auch zu erkennen, welche Risiken bei den diversen Lösungsansätzen zu berücksichtigen und damit zu vermeiden sind.

3.2.2.6. Qualitätssicherung durch Dokumentation

Was wäre denn im Verlauf eines Kundenprojektes zu dokumentieren? Und warum überhaupt?

Das Warum ergibt sich einerseits aus der gesetzlichen Verpflichtung heraus, Dokumente bezüglich der Kaufabwicklung wie z.B.

• den Kundenauftrag,

• die Kundenrechnung,

• den Wartungsvertrag ggf. konkretisiert durch Serviceschein und

• den Servicevertrag

nach Abschluß des Projektes noch bis zu zehn Jahre zu archivieren. Andererseits sind hier für uns die Dokumente von besonderer Bedeutung, die sich direkt mit den Inhalten des Projektes beschäftigen. Dies wären im Einzelnen die Dokumentation

• der Kundenanforderungen Pflichtenheft,

• der Lösung inkl. Preise und Termine Pflichtenheft,

• dem Einverständnis des Kunden mit dieser Lösung Unterschrift unterm Pflichtenheft,

• des Erhaltes der vereinbarten Lösung Abnahmeprotokoll.

Im Pflichtenheft werden der Projektplan, die Anforderungsanalysen und die Spezifikationen dokumentiert. Zusätzlich ist ein Projektabschlußbericht zur Verwendung angeraten, der mit dem Projekt archiviert wird und späteren Projekten als Orientierungshilfe dienen kann.

Zur Qualitätssicherung soll die Kundenkonfiguration, also die Projektsoftware, in einem Versionierungssystem aufbewahrt / gesichert werden. Alle das Projekt betreffende Unterlagen (Kundenanforderungen, Mails, Pflichtenheft, Prüfberichte, ...) sind in ihren verschiedenen Versionen zu sichern.

So wird der Projektverlauf digital und analog dokumentiert. Für die Verzeichnisstruktur hat sich eine gewisse Ordnung bewährt, so z.B. die Archivierung kundenbezogen und dort noch einmal ggf. nach unterschiedlichen Projekten zu sortieren. Diese Struktur kann auch in einem Repository aufrecht erhalten werden, man checkt einfach alle projektbezogenen Dateien aus und ein, soweit nötig. Qualitätssicherungsplan, Qualitätssicherungsbericht und weitere Qualitätsaufzeichnungen werden in einem Unterverzeichnis QS abgelegt, der Projektplan und der Projektabschlußbericht unter Projektmanagement. Weitere Unterverzeichnisse für die Mails, die technischen Projektdateien und die Testpläne und -protokolle sind sinnvoll.

3.2.2.7. Pareto-Analyse zur Fehlerbetrachtung

Mit einer solchen Vorgehensweise lassen sich durchschnittlich achtzig Prozent Erfolg bei nur 20 Prozent Aufwand erreichen. Für die Anwendung zur Fehlerbetrachtung / Fehlerdokumentation bedeutet dies im Einzelnen:

• Gebiet und Zeitraum entscheiden

• Daten sammeln

• Häufigkeit in Relation zu den Kosten setzen

• Priorisierung der Fehler und Behebung nach Prioritätenliste

Für die Datensammlung eignet sich ebenfalls ein System wie Bugtrack o.ä., welches eine Dokumentation der Fehler, ihrer Bewertung, der Maßnahmen, der Ergebnisse der Maßnahmen und der Bewertung der Ergebnisse der Maßnahmen unterstützt.

Somit können automatisiert Fehler ihrem Verantwortlichen zugeordnet werden und dieser darüber informiert werden. Ebenfalls automatisiert wird der Melder des Fehlers über den aktuellen Status der Behebung informiert.

3.2.2.8. Projektgruppenspezifische Betrachtungen

Die Einführung einer Feedbackkultur erscheint angeraten. Die geringen, jedoch notwendigen, zeitlichen Mehraufwände werden sich positiv auszahlen. Bisher gibt es keine zuverlässige Möglichkeit zur Bewertung eines Projektes im Unternehmen außer dem Bauchgefühl des Einzelnen. Um dieses messbar zu machen, gibt es verschiedene Möglichkeiten.

a) Feedback durch den Projektseismograph

Bewertung eines Projektes in der Durchführung durch Projektbeteiligte. Möglich sind bei 18 Aussagen Bewertungen von 0-3, wobei 3 der Bewertung „Trifft zu“ entspricht. Dies ergibt für die Auswertung Ergebnisse von 0-54, welche in Bereiche von 0-10, 11-25, 26-43 und 44-54 aufgeteilt werden. Ggf. werden Maßnahmen ergriffen, bis hin zum Projektabbruch [1].

b) Eine andere Möglichkeit besteht in der Bewertung der Teamsituation durch Anwendung / Ermittlung der Team-Wohlfühlungsfläche. Diese wird gebildet aus den gemittelten Individuellen-Wohlfühlungsflächen der einzelnen Teammitglieder, welche jeweils von mehreren Faktoren bestimmt wird. Somit lässt sich ein Gesamtbild für das Projekt unter der Beteiligung jedes Teammitgliedes erreichen [1].

c) ... (Es gibt in der einschlägigen Literatur noch weitere Möglichkeiten, doch wollen wir hier die Detailbetrachtung beenden)

Um bei nicht besonders positiven Bewertungen eines Projektes nicht gleich den Projektabbruch erwägen zu müssen, ist der Projektleiter in seiner Eigenschaft zur Konfliktlösung bestimmt. Sowohl teamintern als auch nach außen wirkt er als Moderator. Gleichzeitig wacht er über die Einhaltung der zur Konfliktvermeidung im Projektteam aufgestellten Teamregeln, wie z.B.

• gegenseitiger Respekt (keine Vorwürfe)

• Höflichkeit (Pünktlichkeit, ausreden lassen, allgemeine Kommunikationsregeln)

• Feedback geben

• offen und aktiv zuhören

3.2.3. Bewertungen aufgrund der geführten Interviews

3.2.3.1. Bewertung aus administrativer Sicht (inkl. Business Development)

In den geführten vier Gesprächen haben sich folgende Einzelpunkte herauskristallisiert:

• Wenig Regeln oder Strukturen für Abläufe vorhanden

• Die benötigten Regeln werden jetzt sukzessive erstellt und eingeführt (im laufenden Betrieb und unter hohem Leistungsdruck)

• Die wenigsten Regeln werden (von allen) befolgt => die Wenigen, die die Regeln bisher befolgt haben, werden deprimiert und lassen es bleiben

• Jeder arbeitet, wie er es für richtig hält; wird für seine Arbeit eine Regel erstellt, dann wird sie selten befolgt (wird sie befolgt, siehe oben). Es gibt auch Fälle, in denen aus Trotz die Regeln buchstabengetreu befolgt werden, sodass es unproduktiv wird

• Bisher keine Kostenstellenbetrachtung möglich

• Bisher keine vernünftige Qualitätssicherung bei der Arbeit

• Es fehlt jemand, der den Überblick gewinnt und die Leute begeistert

Dies bedeutet in der Zusammenfassung durch die Geschäftsleitung verursachte Probleme, da die notwendigen Reglementierungen mit dem aktuellen Wachstum nicht Schritt gehalten haben. Es fehlt die nötige Kontrolle auf Einhaltungen von Vereinbarungen, eine Selbstkontrolle findet nicht statt und eine Überwachung von oben unterbleibt mangels Ressourcen.

• Hohes Frustpotential.

• Gemeinsames Ziel formulieren und von allen bestätigen lassen

• und dann gemeinsam umsetzen.

• Regulierungen endgültig erwünscht, an die sich alle halten,

• das braucht seine Zeit

• oder zumindest jemanden, der weiss, was er will und dies umsetzen kann.

3.2.3.2. Bewertung aus vertrieblicher Sicht

Durch das Interview, den Besuch eines Business Snacks (Vetriebsveranstaltung) und die Teilnahme an zwei Vertriebsmeetings sind folgende Punkte zusammengetragen worden:

• Trotz alter Namen „neue Produkte“ mit technischen Problemen bzw. Entwicklungs- und Informationsbedarf

• Technische Plattform unvollständig, Feststellungszeitpunkt ungewiss

• Konkurrenzdruck, da keine Referenzen verfügbar

• vertrieblicher „Black-Box-Verkauf“, da auch keine Demos ausreichend verfügbar sind

• Referenzen fehlen sowohl für die V/3 Plattform als auch für CCM, Kunden fehlen

• lange Aquisezeiten (werden akzeptiert) und lange Projektlaufzeiten (werden abgelehnt); bevorzugt wird Produkt- statt Lösungsverkauf

• Partner sind zwar da, aber inaktiv, da Designer bzw. Software Development Kit (SDK) fehlt

• Der Kundenfokus liegt aktuell im Bereich Automotive, Entertainment, Financial, Industry, IT / TK, Public Services, Shopping und Travel.

Dies bedeutet in der Zusammenfassung in erster Näherung durch die Technik verursachte Probleme, da weder die Produkte noch die Projekte aktuell zufriedenstellend sind. In zweiter Näherung sind diese Probleme wiederum durch die Geschäftsleitung verursacht, da die notwendigen Reglementierungen mit dem aktuellen Wachstum nicht Schritt gehalten haben. Es wurden Produkte angeboten, für die es die Technik noch nicht gab, diese Angebote konnten nur mit großem Aufwand und dann auch nur selten zeitgerecht als Projekt abgewickelt werden. Auch gab es produktspezifische Entscheidungen, die entwicklungstechnische Erfolge fast auf Null zurückgesetzt haben.

• mehr Unterstützung gewünscht

• zuverlässige Demos

• freigegebene Produkte (zuverlässiger, mehr Features, ...)

• kürzere Projektzeiten (darum Produkte bevorzugt)

3.2.3.3. Bewertung aus technischer Sicht

• Bisher werden nur schlechte Projekte durchgeführt, da unstrukturiert und nicht genügend spezifiziert

• Ressourcen sind knapp

• Gute Projekte brauchen Zeit (für schriftliche Spezifikationen, Unterschriften des Kunden, ...)

• Erwartungsdruck ist groß

• Projektabwicklung hat Priorität vor Demos

• Projektaufwand 5 Wochen bis 2 Jahre

• Installationsbelege sind zwingend vorgesehen

• Einarbeitungszeit eines Technikers 6 Wochen, dann Aufbau der notwendigen Routine und Erfahrung in Jahren

Dies bedeutet in der Zusammenfassung durch den Vertrieb verursachte Probleme, da die Projekte nicht als Lösungen sondern als Produkte angeboten und verkauft wurden. Was als Individuallösung technisch abgewickelt werden muss mit der gesamten Konfiguration und dem Anpassen nach Kundenwunsch, wird als Standardsoftware verkauft und weckt beim Kunden eine zeitliche als auch finanzielle Erwartungshaltung, die im tatsächlichen Projekt durch den Unterschied zwischen Individual- und Standardlösung rasch enttäuscht wird.

Zur Behebung dieser Mißstände hat der zuständige Linienvorgesetzte im Bereich Professional Services bereits Maßnahmen eingeleitet. Diese lauten im Einzelnen

• Strukturieren und Organisieren von Projekten

• zuerst muss der Kunde seine Wünsche spezifizieren, dann kann man ihm sagen, was es kostet

• erst eine Basisinstallation als Piloten, wenn der läuft, sind alles andere realisierbare Erweiterungen

• Kunde muss Piloten testen und abnehmen, erst dann wird mit dieser bestätigten Basis weiter gearbeitet

• Individuallösungen anbieten, abwickeln und bezahlt bekommen

Das Ganze sieht dann momentan so aus:

Abb. 13 Projektabwicklung nach Professional Services

geht aber meiner Ansicht nach noch nicht weit genug. Zur Abwicklung komplexer Projekte im Kundeninteresse sieht ein Kundenprojekt wie folgt aus:

Abb. 14 Vorschlag Projektabwicklung

Doch momentan gibt es weder ein Supportkonzept, noch ein Schulungskonzept. Public Relations wird unabhängig vom jeweiligen Projektstatus betrieben und, wie wir gleich noch sehen werden, auch unabhängig von dem jeweiligen Produktstatus.

Leider werden die notwendigen Regulierungen aktuell von Professional Services versucht, da sie selbst aktiv an den scheiternden Projekten beteiligt sind und dies zu verhindern versuchen. Statt Projekte abzuwickeln versucht man, sie zuvor zu reglementieren, da anscheinend sonst niemand ein Interesse daran hat. Dies führt wiederum zu Verstimmungen bei den Kunden, die plötzlich mitten im Projekt mit Reglementierungen konfrontiert werden, von denen beim Kauf keine Rede gewesen ist. Die Notwendigkeit dieser Reglementierungen ist für den Kunden auf Anhieb nicht erkennbar, bzw. sie widersprechen seinen eigenen Interessen. Meist geht es ja darum, wann er bezahlen muss.

3.2.3.4. Bewertung aus Entwicklungsicht

• keine Ressourcen für Produkttests planbar

• kein releastes Produkt bisher vorhanden

• zuviel externer Einfluss auf die Entwicklung

Leider war es aufgrund des Leistungsdrucks nicht möglich, von dieser Seite her einen umfassenden Gesprächstermin zu realisieren. Aus den Interviews mit anderen Beteiligten und dem vermittelten groben Überblick durch den CTO lässt sich jedoch bisher Folgendes ableiten:

Produktfokus: Es gibt die V/3-Plattform, die SoftTel und den Contact Manager. Die SoftTel ist kein Zukunftsprodukt um Märkte aufzureißen, sondern ein vernünftiges Add on. Die V/3 ist komplex und in ihren Details noch gar nicht einsatzbereit. Der Contact Manager ist eine Applikation, welche lauffähig ist und darum aktuell aktiv vermarktet wird. Aus der Entwicklungssicht heraus wird die V/3 als Plattform in den nächsten sechs Wochen auf der Basis VXML 2.0 für die Plattform Linux mit ASR Speechworks verfügbar sein. Kurz darauf wird die Portierung der Plattform auf Windows vollzogen sein, gefolgt von Anpassungen für ASR Nuance. Eine Dokumentation der Plattform auf Basis eines V/3 SDK wird ebenfalls zeitnahe zur Verfügung gestellt werden.

In der Entwicklung ist man bemüht, die in ISO 9126 beschriebenen Software-Qualitätsmerkmale umzusetzen, welche da lauten:

• funktionell

• zuverlässig

• benutzbar

• effizient

• wartbar

• wiederverwendbar

Vor allem aufgrund der Mängel im Bereich Effizienz und Zuverlässigkeit wurde in den letzten Wochen im Rahmen der Möglichkeiten außergewöhnliche Anstrengungen unternommen, um hier den selbstgesetzten Zielen näher zu kommen. Dies sollte ebenfalls in absehbarer Zeit zu einem zufriedenstellenden Abschluß gelangen, wobei die Tätigkeiten für Verbesserungen in jenen Bereichen nicht vollständig eingestellt werden, jedoch endlich von Noteinsätzen auf ein plan- und handhabbares Maß heruntergefahren werden können.

Dies bedeutet in der Zusammenfassung durch die Geschäftsleitung verursachte Probleme, welche die Produktentwicklung unter vertrieblichen Sachzwängen betreibt, welche durch die Marketingmaßnahmen beim Kunden in Zugzwang geraten sind.

• Entwicklung unter Berücksichtigung vertrieblicher Wünsche

• aber unabhängig vom jeweiligen Verkaufsdruck

• Nur Verwendung von technisch abgestimmten Aussagen durch das Marketing

• Gelegenheit zum Ausbau der eigenen Möglichkeiten, z.B. Konzipieren von Testszenarien zur Erlangung eines -Status

3.2.3.5. Bewertung aus projektabwickelnder Sicht

• Presales gibt es nicht, Sales müsste erweitert werden

• Schulung gibt es nicht

• Support gibt es nicht

• Es fehlt ein Kümmerer für das Tagesgeschäft, keiner hat den Überblick

• Es fehlt nicht an Personen, aber an der Organisation für die Prozesse

• Die Prozesse werden nicht gelebt

• Es fehlt an klaren Linien, ständig werden neue Wege eingeschlagen, weil sie kürzer scheinen

• Abnahmefristen wären sinnvoll, werden jedoch nur selten dokumentiert und damit nur selten durchgeführt

• Professional Services macht Produkttests, statt sich auf seinen Job konzentrieren zu können

Dies bedeutet in der Zusammenfassung durch die technische Organisation verursachte Probleme, da hier die Entwicklung zu sehr vom Tagesgeschäft beeinflusst werden darf, während Professional Services sich zu sehr vom Tagesgeschäft abkoppeln darf. In zweiter Näherung zeigt auch dies wiederum die Verantwortlichkeit der Geschäftsleitung, die es versäumt hat, die operativen Bereiche zu entkoppeln, wo es notwendig wäre. Andererseits dürfen nicht-operative Bereiche zu sehr in tagesaktuelle Geschehnisse involviert werden. Hier wäre eine restriktivere Trennung von Nöten. Desweiteren steckt das Projektmanagement zu sehr in den Kinderschuhen, als dass es sinnvoll eingesetzt werden könnte.

• Projektmanagement auf- bzw. ausbauen

• Trennung der Entwicklung vom operativen Geschäft, ggf. Projektbeteiligung, wo nötig, aber unter strengerer Aufsicht als bisher

• Entlasten von Professional Services für ihr eigentliches Kerngeschäft

3.2.3.6. Bewertung aus Finanzsicht

• Das mit den zwei Projekten, welche bisher gemacht wurden, kein Geld verdient wurde, weiß jeder

• Es gibt eine Kostenstellenerfassung, es fehlen nur die Projekte

• Es wäre fast sofort möglich, projektbezogen die Kosten und Erträge gegeneinander aufzuführen

Dies bedeutet in der Zusammenfassung ein allgemeines Kommunikationsproblem, da von administrativer Seite diese Möglichkeiten zur Kostenbetrachtung als nicht vorhanden gewertet wurden.

Mit dieser Zusammenstellung der aus den Interviews gewonnenen und bewerteten Einzelinformationen wollen wir uns nun der Zusammenfassung der gewonnenen Informationen zuwenden, um daraus die notwendigen Schlüsse für ein weiteres Vorgehen zu ziehen.

3.2.4. Erstellung

3.2.4.1. Zusammenfassung IST-Zustand

Somit lässt sich zusammenfassen, dass die befragten Abteilungen an sich ihren Aufgaben mit den Mitteln nachgehen, die ihnen zur Verfügung stehen. Das Hauptproblem liegt so gesehen eigentlich in der unternehmensweiten mangelnden Kommunikation. Aus diesem Mangel heraus entstanden Informationsdefizite, die zu Missverständnissen oder gar Fehlentscheidungen führten, welche schließlich in allgemeiner Demotivation mündeten.

Insoweit sieht ein Projekt im Hause aktuell so aus:

Abb. 15 Aktuelle Projektabwicklung

Wobei die Vorbereitung der Auftrag und die Nachbereitung die Rechnung ist.

Abb. 16 Konkrete Einzelabschnitte

Welche Möglichkeiten sind somit denkbar, um dieses Hauptproblem anzugehen?

3.2.4.2. Auswahl der Methodik

Welche methodischen Möglichkeiten könnten für weitere Betrachtungen relevant sein? Im Bereich Qualität spricht man meist von:

• Six Sigma: Schlanke, auf die Kundenanforderungen optimierte Prozesse sparen Geld und vermeiden Nacharbeiten und Ausschuss. Six Sigma konzentriert sich auf die Prozesse, alle Vorgänge innerhalb eines Prozesses werden verbessert.

• Total Quality Management TQM: Die Methoden systematisch und konsequent auf Kundenzufriedenheit und Qualität ausrichten. Grundsätze im TQM können sein:

• Der Kunde zuerst,

• Führen mit Zielvereinbarungen,

• Gezielte Beteiligung der Mitarbeiter,

• Denken in Prozessen,

• Kontinuierliche Verbesserung,

• Radikal-innovative Gestaltung,

• Faktenorientiertes Handeln.

• DIN ISO 9001: Qualitätsmanagement und deren Rahmenbedingungen. [1]

• Wertanalyse: Mittels Funktionenanalyse vom realen Problem mittels Abstraktion und Kreativität zu neuen Lösungen kommen (Innovationssprung) [3].

Gegebenenfalls kann es jedoch auch von Nöten sein, im Bereich Geschäftsprozessoptimierung aktiv zu werden. Hier hört man zumeist von:

• Business Process Reengineering als fundamentales Überdenken und radikales Redesign von Unternehmen oder wesentlichen Unternehmensprozessen. Das Resultat sind Verbesserungen um Größenordnungen in entscheidenden, heute wichtigen und messbaren Leistungsgrößen in den Bereichen Kosten, Qualität, Service und Zeit. [4]

• Beim Kaizen werden viele kleinere Verbesserungen vorgenommen, die dazu dienen, Prozesse und Produkte in inkremental kleinen Schritten zu verbessern, um einen geplanten Zustand zu erreichen und dann auch zu halten und weiter zu entwickeln. [5]

• Prozessmanagement: Verbesserungen können erst durchgeführt werden, wenn die wichtigen Prozesse und ihre Fehler erkannt und dokumentiert wurden. [6]

Dies zur theoretischen Betrachtung, die Wahrheit liegt, wie immer, erstens im Auge des Betrachters und zweitens irgendwo dazwischen. Also gehen wir weg von der Methodik und schauen uns die Projektabwicklung und die daran Beteiligten an.

Ein Projektteam besteht hier im Allgemeinen aus dem Projektleiter, dem vertrieblichen Vertreter und dem technischen Vertreter unter Beteiligung des Kundenvertreters. Ggf. werden Marketing, Entwicklung und Rechnungswesen beteiligt, wobei Marketing und Rechnungswesen nur sekundär, wenn überhaupt Einfluß auf den Verlauf des Projektes haben. Natürlich empfiehlt es sich für ein Projekt, die Position für das Projekt-Marketing, also den „Pressesprecher“ zu besetzen. Die Ziele dabei sind:

• Transparenz schaffen

• Akzeptanz bewirken

• proaktiv nach außen gehen

• Unterstützung erlangen

Dabei sind in erster Linie die Adressaten:

• der Kunde,

• die Linienvorgesetzten Sales, Professional Services und ggf. Entwicklung

• die betroffenen Mitarbeiter des Kunden

• firmenintern bei einer gewissen Größe bzw. bei einer gewissen Relevanz des Projektes

• Presse

• potentielle Kunden

Bei kleineren Projekten (durchschnittlich) ist der Projektleiter auch zuständig für das Projekt-Marketing. Bei Großprojekten (Key Account, ...) wird hier zusätzlich die Abteilung Marketing eingebunden, um z.B. mittels Anwenderberichte weitere potentielle Kunden informieren zu können.

3.2.4.3. Risikobetrachtung:

Ein Risiko (aus dem Spanischen: risco = Klippe) tritt in einem Projekt dann auf, wenn die angestrebten Ziele des Projektes gefährdet werden, darum muss es „umschifft“ werden.

Der Wertebereich der Eintrittswahrscheinlichkeit sowie der Auswirkung erstreckt sich hierbei von 0 bis 10

EW = Eintrittswahrscheinlichkeit, AW = Auswirkung

Tab. 7: Risiko-Betrachtung der Kundenprojekte

Hier sind im einzelnen die identifizierten Risiken und Gegenmaßnahmen sowie eine Bewertung vor und nach der Maßnahme aufgeführt. In der Durchführung des Gesamtprojektes „Optimierung“ sind diese Risiken permanent zu überwachen und ggf. neu zu bewerten.

Dies zeigt die bereits in 3.2.3.3. Bewertung aus technischer Sicht angesprochene Notwendigkeit, ein Projekt nicht zwecks Beschleunigung zu vereinfachen, bzw. die Projektabwicklung so wie bisher im Hause üblich, durchzuführen. Dies erhöht nur gewisse Risiken, deren Gegenmaßnahmen unterlassen werden. Nur ein komplett aufgesetztes und durchgeführtes Projekt bietet die Sicherheit durch kontrollierte und damit minimierte Risiken.

3.2.4.4. Betrachtungen und Vergleich mit dem SOLL-Zustand

Dies bedeutet eine Darstellung des Projektes in der Übersicht wie folgt:

Abb. 17 Bereiche einer Projektabwicklung

Hierbei sind jetzt noch die einzelnen Arbeitsschritte in den Abhängigkeiten voneinander zu beachten. Wir konzentrieren uns hier vorerst auf die Bereiche Spezifizieren, Konfigurieren und Installieren. In Abbildung 18 dargestellt finden wir die Tätigkeiten für das Spezifizieren nach Abschluß der Beratungsleistung.

Abb. 18 Arbeitspakete Projektabwicklung I

In Abbildung 19 dargestellt finden wir die Tätigkeiten nach dem Spezifizieren, also das Konfigurieren und Installieren. Handelt es sich dabei um eine Entwicklung mittels Pilotierung, wie von der zuständigen Fachabteilung Professional Services präferiert, so sind diese Tätigkeiten für den Piloten durchzuführen. Nach Abnahme des Piloten durch den Kunden erfolgt die gleiche Vorgehensweise für die Erweiterung des Piloten zur gewünschten Kundeninstallation. Die Installation ist jetzt entweder die Installation z.B. an weiteren Standorten nach dem Vorbild des Piloten, bzw. die Erweiterung des Piloten um weitere Features, Module oder Funktionalitäten.

Abb. 19 Arbeitspakete Projektabwicklung II

Auf gegebenenfalls noch in diesem Schema vorhandene Optimierungspotentiale werden wir im Laufe dieses Kapitels noch eingehen.

Demnach betrachten wir zuerst einmal die extremen Möglichkeiten und versuchen, eine projektbeteiligte Partei ganz auszuschließen. Dabei prüfen wir die Wirkung auf das Projekt und bewerten sie.

• Projekte ohne Kunden klingen wie die goldene Lösung, der scheinbar größte Störenfried wird aus dem Geschehen eliminiert. Leider scheitern solche Lösungsansätze mangels Finanzierbarkeit, falls Unternehmen dieses praktiziert haben, sind keine übrig geblieben, um davon zu berichten.

• Projekte aus einer Linie der Organisation heraus abzuwickeln ist ebenfalls eine Möglichkeit, die auf Anhieb gut klingt, aber mangels Know-How im jeweiligen Bereich scheitert. Der Vertrieb könnte die Projekte zwar bis zur Unterschrift treiben, aber nicht abwickeln und umgekehrt würde die Technik an der Aquise scheitern.

Die nächste Betrachtung beschäftigt sich mit der Änderung der projektumgebenden Organisationstruktur.

• Eine Änderung der Unternehmensstruktur hin zur reinen Projektorganisation würde bewirken, die Projekte kundenfreundlich mit kurzen Kommunikationswegen im gemeinsamen Interesse abzuwickeln und würde abteilungstrennender Gruppenbildung entgegenwirken. Allerdings würde die Abgrenzung zum Kunden schwieriger, Strukturen zum Arbeiten müssen erst gebildet / gefunden werden und der Personaleinsatz ist immer nur für die Dauer des Projektes befristet.

Da keiner der bisherigen Lösungsvorschläge als vielversprechende Option in die engere Wahl aufgenommen wird, wenden wir uns nun den etwas gemäßigteren Ansätzen im kleineren Bereich zu. Da wäre zuerst einmal

• Bessere Arbeitsvoraussetzungen für Professional Services = Erhöhung der Ressourcen. Leider bedeutet diese Vorgehensweise ein Aussetzen der Projektabwicklung, da abteilungsintern die neuen Mitarbeiter eingearbeitet werden müssen. Bei vier Mann und einer angestrebten Erhöhung um 100% bedeutet dies eine Aufschiebung aller Projekte um mehrere Wochen oder gar Monate.

• Bessere Arbeitsvoraussetzungen für Sales = Demoumgebung schaffen. Diese Vorgehensweise würde die Projektabwicklung nur kurzfristig verzögern, da die Implementierung dieser für den Kunden erreichbaren Demoumgebung nur einige Tage in Anspruch nehmen dürfte. Allerdings löst dieser Ansatz nur gewisse Probleme im Bereich Sales, aber nicht jene im Bereich Projektabwicklung.

• Ein Beibehalten der bisherigen Zustände bedeutet nicht nur das Nichterfüllen der Projektvorgaben, sondern auch eine andauernde Demotivation der Mitarbeiter durch schlechte, weil unspezifizierte Projekte.

• Reduzieren der vertrieblichen Aktivitäten: Der Kundenfokus liegt aktuell im Bereich Automotive, Entertainment, Financial, Industry, IT / TK, Public Services, Shopping und Travel. Das erscheint ein wenig viel, vielleicht wäre ein Fokus auf einen vertikalen Markt besser. Hier könnte man versuchen, ein Pilotprojekt zu aquirieren und abzuwickeln, aus den gewonnenen Erfahrungen kann dann ein Standardprodukt erarbeitet und ein Standardpflichtenheft für Standard-Spezifikationen erstellt und dann erfolgreich vermarktet werden. Zeitgleich kann man dann den nächsten vertikalen Markt angehen. Die Implementierung erfolgt annähernd wie sonst auch, nur mit dem vorab verfassten Pflichtenheft wird die Lösung fast wie ein Produkt verkauft.

Abb. 20 Standardprodukte

Leider fehlen hierfür momentan die entsprechenden Kontakte und Branchenkenntnisse, sodass dieser Lösungsvorschlag den Projektauftrag nicht im geplanten Zeitrahmen erfüllt.

• Entwickeln eines Designers: Die Entwicklung eines Graphical User Interfaces (GUI) zur Erleichterung der VXML-Programmierungen könnte dazu führen, den Druck von der Projektabwicklung bei gleichbleibendem Umsatz zu nehmen. Der Kunde bekommt nicht seine spezifische Konfiguration, er erwirbt ein Werkzeug, mit dem er ohne Zusatzkenntnisse in die Lage versetzt wird, die Anpassung der Konfiguration selbst durchzuführen. Im Grunde genommen wird durch dieses GUI bei der Installation der Software oder einer später gestarteten Aktion die Konfiguration über Masken beim Kunden abgefragt und aufgrund seiner Antworten bildet sich die Konfiguration selbst heraus. Die Anpassung verläuft wie bei einer Standardsoftware, quasi Plug & Play. Allerdings würde der dafür benötigte Entwicklungsaufwand den Zeitrahmen dieses Projektes sprengen.

Anscheinend gibt es keine Einzellösung, mit der sich der gewünschte Erfolg erzielen lässt. Somit betrachten wir nun die Kombination von Einzeloptionen.

• Eine Kombination mit den Möglichkeiten „bessere Arbeitsvoraussetzungen für Professional Services“, „bessere Arbeitsvoraussetzungen für Sales“ oder beiden bei anschließender Abwicklung aller Projekte bringt voraussichtlich nicht den gewünschten Erfolg, in Summe würden zwar die Probleme für das kommende Geschäftsjahr gelöst sein, allerdings summieren sich nicht nur die Wirkungsquotienten, sondern auch die negativen Auswirkungen. Die Projektabwicklung würde für Monate stagnieren.

• Eine Kombination mit den Möglichkeiten „Vertikale Märkte“, „Designer“ oder beiden würde auch weiterhin den zeitlichen Rahmen dieses Projektes sprengen.

Infolgedessen empfiehlt es sich, den Erwartungsdruck für die nächsten Wochen zu verringern und einen geeigneten Maßnahmenkatalog zu erstellen, welcher sukzessive umgesetzt wird. Prinzipiell werden also Verbesserungen in allen Bereichen in kleinen erreichbaren Schritten angestrebt, um das Ziel zu erreichen. Zur Überwachung der Effektivität der getroffenen Maßnahmen sind jedoch noch weitere Schritte notwendig, um diese Überwachung zu ermöglichen. So lassen sich z.B. mit der üblichen Laufzeit von Projekten und der üblichen Aquisezeit von Projekten die Auslastungen im technischen Bereich im Voraus berechnen. Das branchenübliche Verhältnis im Software-Bereich von 3 zu 1 sollte dabei ungefähr bestätigt werden. Ist dies nicht der Fall, müssen im Vertrieb Maßnahmen zur effizienteren Projektgenerierung ergriffen werden. Für den entgegengesetzten Fall, dass vertrieblich mehr Projekte aquiriert werden als abgewickelt werden können, wurde diese Arbeit erstellt. Allerdings ist eine Auslastungsberechnung momentan im Hause nicht möglich.

Die bereits erwähnte Standardisierung von Projekten lässt sich selbstverständlich auch im Bereich Schulungen anwenden. Eine Individualschulung für einige wenige Mitarbeiter eines Kunden und seines speziellen Projektes benötigt immer eine gewisse Vorbereitungszeit.

Abb. 21 Individualschulungen

Einfacher ist es jedoch, die Schulungen als Standardschulungen einmal konkret mit allen Unterlagen vorzubereiten und als solche auch anzubieten. Die Standardschulung muss nur oft genug verkauft werden, schon lässt man sich von jedem Kunden die einmalige Vorbereitung erneut bezahlen. Das Marketing für diese Art Schulungen ist ja bereits in Form der Clarity Academy und ihrer Angebote angelaufen.

Abb. 22 Standardschulungen

Das Gleiche lässt sich auch für den Bereich Support umsetzen.

Abb. 23 Garantiefall bzw. Störung = Support

Im Falle einer Fehlermeldung durch den Kunden ist zu prüfen, ob es sich um eine kostenpflichtige Behebung oder um einen Garantiefall, also eine kostenfreie Fehlerbehebung handelt. Im Falle der kostenfreien Fehlerbehebung wird nach erfolgter Prüfung der Fehler umgehend behoben, sofern dies technisch möglich ist. Im Falle einer kostenpflichtigen Fehlerbehebung wird dem Kunden dies, ebenso wie die voraussichtlich anfallenden Kosten, mitgeteilt. Sobald der Kunde sich hierzu positiv geäußert hat, wird der Fehler umgehend behoben, sofern dies technisch möglich ist, gefolgt von der Rechnungsstellung. Dies bedeutet unter Umständen Zeitverluste und ist durch einen Wartungsvertrag im Sinne des Kunden eleganter und schneller abzuwickeln.

Abb. 24 Support mit Wartungsvertrag

Desweiteren muss ein vernünftiges Reporting eingeführt werden. Wichtig wäre hierbei, genauso wie intern, bezüglich der Entwicklungsabteilung, auch extern den Projektleiter als Filter zu verwenden. Er koordiniert den Kontakt zum Kunden und leitet dessen Ideen, Anforderungen, Verbesserungswünsche usw. nicht einfach an die Teammitglieder weiter, sondern führt vorab ggf. schon Klärungen mit dem Kunden herbei. Statt dass der Kunde direkt seine neuen Verbesserungswünsche im laufenden Projekt mitten in die technische Abteilung einkippt, kommuniziert er sie zum Projektleiter. Dieser macht ihn darauf aufmerksam, dass diese Änderungen bisher kein Bestandteil des Projektes gewesen sind, erstellt möglicherweise einen neuen Zeitplan und eine neue Kostenschätzung für die Abwicklung des Projektes inklusive der gerade gewünschten Änderungen und versucht den Kunden davon zu überzeugen, dass eine Abwicklung dieser Wünsche als Folgeprojekt nach Abschluß des gerade laufenden Projektes wesentlich sinnvoller, effizienter und auch billiger ist.

Das Kommunikatuionsschema stellt sich insoweit wie folgt dar:

Kd = Kunde, PL = Projektleitung, PS = Professional Services, V = Vertrieb,

Rw = Rechnungswesen, M = Marketing (kann aber je nach Projekt auch Entwicklung sein)

Abb. 25 Kommunikationsschema Kundenprojekt

Natürlich gibt es hierbei auch Nachteile:

• hohe Anforderungen an PL (Koordination, Motivation, Konfliktmanagement, ...)

• hohe Anforderungen an das Team, um als solches zu reporten

• große Umstellung erforderlich

• technische Voraussetzungen hierfür müssen geschaffen werden (keine Anzeige von Durchwahlnummern), was aber im Hause keine Schwierigkeiten darstellen sollte

Allerdings dürften die Vorteile dies aufwiegen:

• Teambildende / teamfördernde Maßnahme

• der PL kommuniziert mit dem Team, keine Geheimnisse, keine Bevorzugung, keine Ausgrenzung

• Team kann ungestört arbeiten

• Kunde wird vom Projektleiter regelmäßig informiert (Kundenbetreuung)

• Besser überschaubar und damit interessanter als z.B. Linienbesprechung

Zuletzt dürfen die zu erstellenden Eskalationsprozesse nicht vergessen werden. Diese wurden aus hoch bewerteten Risiken definiert:

Der Wertebereich der Eintrittswahrscheinlichkeit sowie der Auswirkung erstreckt sich hierbei von 0 bis 10

AW = Auswirkung, EW = Eintrittswahrscheinlichkeit

Tab. 8: Risiken im Kundenprojekt

Es ist festzustellen, dass für den Bereich „kein Mitarbeiter Frei“ die höchste Eintrittswahrscheinlichkeit gefunden wurde. Hieraus wird für die Problemlösung zwischen Vertrieb und Technik zur Eskalation definiert, dass im ersten Schritt das Projektmanagement das Kosten-Nutzen-Verhältnis abwägen soll und aufgrund des Ergebnisses (sprich Rentabilität) entscheidet. Wird diese Entscheidung nicht akzeptiert, wird im zweiten Step unter Beteiligung der Abteilungsvorgesetzten verhandelt. Ist auch dies erfolglos, kann zum Vorstand eskaliert werden. Hierbei besteht jedoch die Hoffnung, dass es niemals so weit kommen muss.

Eine ähnliche Vorgehensweise wurde dann für die Eskalation „Fehler im Produkt“ zwischen Vertrieb bzw. Professional Services auf der einen und der Entwicklung auf der anderen Seite festgelegt. Auch hier ist das Projektmanagement als moderierende Instanz beteiligt.

Das gleiche Prinzip wurde zwischen Kunden und Projektmanagement im Falle „Kunde verweigert die Abnahme vorgesehen. Hierbei wird die moderierende Funktion des Projektmanagement zurückgestellt, da es die Interessenvertretung seitens des Unternehmens übernimmt, da jede andere Abteilung eine gesamtunternehmerische Vertretung nicht garantieren würde, sondern ggf. nur die Abteilungsansicht vertreten würde.

3.2.4.5. Vorgaben für den Leitfaden

Die identifizierten Maßnahmen werden hier im Überblick zusammengestellt und priorisiert und ergeben den Maßnahmenkatalog.

1. Technische Produktplanung der nächsten sechs Monate muss erstellt werden. Diese

Produktplanung ist anhand der Marktanforderungen zu überprüfen und ggf. anzupassen. Dann sind die als Schlüsselfunktionalitäten identifizierten Produktbereiche zeitnah zur Realesreife zu bringen.

2. Vertriebliche Umsatzplanung der nächsten sechs Monate ist mit der erstellten

Produktplanung abzugleichen. Gleichzeitig muss für die zu releasenden Produkte eine Pipeline aufgebaut werden.

3. Aufgrund dieser beiden Planungen ist die Leistungsfähigkeit von Professional Services

zu prüfen, ggf. muss aufgestockt werden.

4. Fertigstellung eines SDK zwecks Partnereinbindung

5. Bis zur Fertigstellungen von Produkten werden von Professional Services Demos für

den Vertrieb fertiggestellt.

6. Einführung von Führungsinstrumenten zur Verbesserung der notwendigen

Kommunikation von oben nach unten und von links nach rechts und zum Erhalt einer Feedbackkultur

7. Umsetzen von qualitätssichernden Maßnahmen

8. Auf-/Ausbau eines Projektmanagements

9. Auf-/Ausbau eines Customer Trainings

10. Referenzen abwickeln

11. Aus den Referenzen (= Piloten im vertikalen Markt) für Sales Standardprojekte

schaffen, die diese wie Produkte verkaufen können

12. Einführung bzw. Auf-/Ausbau eines Sales Supports

13. Einführung bzw. Auf-/Ausbau eines Customer Supports

14. Bessere Einbindung von CUE

15. Einführung von Kostenstellenbetrachtungen => Analyse der Kostendeckung bzgl.

Produkte ermöglichen (falls noch nicht vorhanden, hier gibt es Widersprüche)

16. Entwickeln eines Designers zwecks Generierung von Standardprojekten (mit

Standardpflichtenheft), in denen der Kunde selbst seine Lösung konfigurieren kann (Plug & Play)

3.2.5. Ausklang

3.2.5.1. Abschließende Vorbereitungen

Aufgrund der fortschreitenden Zeit wurde beschlossen, den Punkt Projektstart als unvollständig abzubrechen und mit dem bereits vorhandenen auszukommen. Durch die unverhältnismäßig großen Verzögerungen und den unverrückbaren Endtermin wurden Nachverhandlungen seitens einer Verlängerung des Projektes in den Erwägungen als erfolglos verworfen. Die grafische Aufbereitung und das Ausformulieren des Leitfadens wurde als entbehrlich eingestuft und aus diesem Teilprojekt gestrichen.

Daher verblieb für die weiteren geplanten Aktivitäten genügend Zeit. Es wurde ein Raum für die Präsentation gebucht und der Vorstand als Auditorium zu diesem Termin eingeladen. Die Medien wurden vorbereitet und der Termin wurde im Vorstandssekretariat als „Nur im äußersten Notfall stören“ vermerkt. Die Teilnehmer wurden gebeten, ihre Mobiltelefone und Notebooks nicht mitzubringen. Desweiteren wurde Kaffee vorbereitet und eine Auswahl Gebäck gereicht. Die Präsentation und die Handouts war in den letzten beiden Wochen vor Projektabschluß sukzessive neben der Dokumentation mit vorbereitet worden und ist in Auszügen auch mit in diese eingeflossen.

Als Tagesordnung wurde festgelegt:

1. Einführung von C.Hempel in sein Projekt „Erstellung Leitfaden“

2. Vorstellung Vorgehensweise und Methoden

3. Ergebnisse der Befragungen

4. Schlußfolgerungen für die weitere Vorgehensweise

5. Beantwortung Fragen zum Bisherigen

6. Diskussion (falls gewünscht)

Als Zeit wurden zwei Stunden veranschlagt.

3.2.5.2. Präsentation, Übergabe und Projektabschluß

Als Präsentationstermin wurde mit dem beauftragenden Vorstand der 27.06.2004 vereinbart. Es wurde eine vorbereitete Präsentation mittels Beamer vorgeführt, unterstützt durch zusammenfassende Handouts. Der Vorstand wurde über die allgemeine Vorgehensweise, deren Methoden und die Durchführung der Informationsbeschaffung sowie der Ergebnisse der Auswertung der erhaltenen Informationen informiert. Es ist vorgesehen, eine verkürzte Version dieser Präsentation beim Informationstermin mit der Belegschaft zu verwenden. Die positive Resonanz und die vielfältigen weiterführenden Fragen während der Präsentation, die jedoch zur vollen Zufriedenheit aller Beteiligten beantwortet werden konnten, ließen vermuten, dass die Vorgehensweise schlüssig vermittelt werden konnte und die daraus resultierenden Ergebnisse, Schlüsse und Empfehlungen verstanden und akzeptiert wurden.

Es wurde vereinbart, aufgrund der bisherigen Leistung das gemeinsame Arbeitsverhältnis fortzusetzen. Dem Projektleiter des bisherigen Teilprojektes wurde daraufhin die Leitung des Gesamtprojektes angeboten.

Eine Übergabe des Projektes inklusive der dazugehörigen Unterlagen entfiel aufgrund dessen, sie wurden jedoch für die weitere Verwendung im Gesamtprojekt vervielfältigt, verteilt und archiviert. Der Projektabschluss verlief aufgrund der geringen Teilnehmerzahl der Projektgruppe relativ unspektakulär, alle Beteiligten wandten sich Ihren neuen Aufgaben zu.

3.3. Abschluss

3.3.1. Fertiger Leitfaden

Aufgrund der unter 3.2.2.3. Ressourcenbetrachtung aufgeführten Verzögerungen und der daraus resultierenden Zeitknappheit können hier nur noch die Eckdaten des Leitfadens ohne grafische Aufbereitung aufgeführt werden, die bereits vor Abschluß der Befragungen in der Erstellung begonnen wurde und sukzessive verfeinert wurden. Die grafische Ausarbeitung für den Mitarbeiter-Informationstermin muss leider wie in 3.2.5.1. Abschließende Vorbereitungen erwähnt aus diesem Teilprojekt in das folgende übertragen werden.

• Zweck des Leitfadens: Dieser Leitfaden beschreibt, wie aus kundenspezifischen Anfragen eine maßgeschneiderte Lösung mit Clarity-Produkten entwickelt und realisiert wird. Ein Projekt muss die vereinbarten Kundenanforderungen erfüllen und profitabel sein.

• Geltungsbereich: Vertrieb, Professional Services, Projekt Management, Entwicklung, Marketing, Rechnungswesen, Hardware

• Zuständigkeiten:

• Der Vertrieb ist für das Anbieten und Präsentieren der Produkte beim Kunden zuständig. Hierbei wird er vom Marketing durch Unterlagen unterstützt. Desweiteren erfolgt eine Presales-Unterstützung durch Professional Services. Nach der Unterzeichnung des entsprechenden Vertrages übergibt der Vertrieb den Auftrag und damit das gesamte Projekt an das Projekt Management.

• Marketing erstellt nach Vorgaben des Vertriebes unter Beteiligung entsprechender Fachabteilungen unternehmens-, produkt- und servicebezogene Unterlagen zwecks Verwendung beim Kunden. Dies beinhaltet vor allem das Erstellen von Anwenderberichten.

• Professional Services ist für die Erstellung der Kundenapplikation und die Installation vor Ort zuständig. In der Koordination dieser Aufgabe werden sie vom PM unterstützt.

• Projekt Management übernimmt ein Projekt nach Unterzeichnung des Vertrages zur Koordination der Abwicklung. Entsprechend dem Auftrag veranlasst PM die Bestellung der notwendigen Teile bei Hardware, veranlasst bei PS die Abwicklung des Auftrages und informiert alle Beteiligten einschließlich des Kunden über die jeweiligen Fortschritte. Hierbei wird PM von allen betroffenen Abteilungen unterstützt. Wird das Projekt durch das Abnahmeprotokoll für beendet erklärt, übergibt PM das Projekt zur Berechnung an das Rechnungswesen. Im Falle der Notwendigkeit beteiligt PM, für den Kunden unbemerkt, die Entwicklung am Projekt.

• Ein noch zu schaffender Bereich Hardware, der sich mit der Beschaffung, der Verwaltung und dem Versand der projektrelevanten Hardware beschäftigt, ist auch für diesen Bereich verantwortlich.

• Das Rechnungswesen ist für die Berechnung abgeschlossener Projekte, bzw. der Berechnung von Teilprojekten verantwortlich.

• Die Entwicklungsabteilung wird vom PM im Falle von Produktschwierigkeiten mit eingebunden.

• Beschreibung: Gegenstand dieses Leitfadens sind Projekte, die den zeitlichen Rahmen von der Geschäftsanbahnung bis zur Abnahme durch den Kunden umfassen. Besonderes Augenmerk gilt hierbei den von Partnern initiierten Projekten ebenso wie das Wartungsvertragswesen und die damit verknüpfte Supportthematik. Zusätzlich wird die Schulung des Kunden in ihrem Ablauf von der Beauftragung bis zur Auswertung beschrieben.

• Anlagen: Checkliste zur Projektaufnahme, Abnahmeprotokoll, Pflichtenheft (+ Ergänzungs-Pflichtenheft)

3.3.2. Bewertung

Zusammenfassend lässt sich festhalten: Dass die Schaffung der vorgesehenen Arbeitsumgebung auf solche Schwierigkeiten stossen würde, war aus der bisherigen Erfahrung heraus nicht kalkulierbar gewesen.

0. Projektstart (unvollständig für beendet erklärt) 20 Personentage

1. Aufnahme IST- und SOLL-Zustand 8 Tage Interviews

2. Auswertung der Gespräche, Planung des Leitfadens, QS 7 Personentage

3. Erstellung des Leitfadens (zurückgestellt, bisheriger Zeitaufwand) 3 Personentage

4. Abschluss (Abstimmung, Präsentation und Übergabe) 3 Personentage

5. Dokumentation 10 Personentage

Dadurch sind auch nachfolgende Projektteile ein wenig, aber im Vergleich nur unwesentlich, in die Länge gezogen worden. Die Projektüberwachung als solche kostete aufgrund des schwierigen Starts weit mehr Zeit als geplant, erwies sich aber in diesem Maße als notwendig, um das Projekt im Griff und auf Kurs zu halten. Die am Anfang versäumten informativen Maßnahmen haben sich in gewissem Umfang negativ ausgewirkt.

Wie in 3.2.2.3. Ressourcenbetrachtung bereits vermutet, so sind die organisatorischen Engpässe die Regel, was erheblichen Einfluß auf die Erstellung des Leitfadens hatte. Wie unter 3.2.2.4. Kostenbetrachtung aufgeführt wurde, sind keine finanziellen Ressourcen für dieses Projekt benötigt worden, da auch die unter 3.2.2.2. Qualifizierungsmaßnahmen erwähnten Fortbildungen aufgrund der Einführung von CASE-Software entfielen. Im Einsatz sind für die Fehlerverfolgung ein Tool namens Mantisse und für die Revisionierung ein CVS Repository.

Der Projektabschluss wurde anstandslos mit Genehmigung des Auftraggebers wie unter 3.2.5.2. Präsentation, Übergabe und Projektabschluß beschrieben durchgeführt.

Zur Zielerreichung muss man sagen, dass das Ziel im Teilprojekt Leitfaden zwar nicht wie beabsichtigt voll erreicht wurde, doch die Erfahrungen in dieser Vorphase für das Gesamtprojekt dürften sich als grundlegend erweisen. Die Projektbewertung ist aufgrund des schleppenden Starts nicht ausgezeichnet, jedoch in der Durchführung und Erreichung der Ziele gut. Zur Weiterführung sind die Projektstrukturen jetzt bereits geschaffen und können rasch reaktiviert werden aufgrund der Dokumentation. Somit ist es möglich, dass trotz der Übertragung von Teilbereichen aus dem Teilprojekt auf das Gesamtprojekt (schriftliche Erstellung des Leitfadens inkl. Grafik) dieses aufgrund der gründlichen Vorarbeit im beabsichtigten Zeitrahmen mit dem geplanten und bereits erweiterten Umfang abgewickelt werden kann. Der Leitfaden kann aufgrund des erarbeiteten Maßnahmenkataloges in ungefähr einer Woche ausformuliert sein.

Dies ergibt für den Auftraggeber im SOLL-IST-Vergleich zum beabsichtigten Ziel einen guten Abschluss, der zur berechtigten Vermutung Anlass gibt, dass mit dem bereits Erarbeiteten ein Grundstein zur Erreichung des formulierten Projektzieles gelegt ist und dieses in greifbare Nähe gerückt wurde.

Der Nutzen des Projektes für den Auftraggeber ist dadurch gegeben, dass für das Ausformulieren des Leitfadens alle notwendigen Informationen zusammengetragen wurden und der umzusetzende Maßnahmenkatalog erstellt ist.

Der Projektleiter schätzt darum durch den gegebenen Nutzen das Projekt als erfolgreich ein.

5. Literaturverzeichnis

[1] F.Wiebel & Partner „IT-Projektleiter (IHK)“, Seminarmitschrift, Wiesbaden 2004

[2] Clarity AG „Unternehmensphilosophie und Visionen“ 2000

[3] Degussa „Wertanalyse Grundseminar“, Seminarunterlagen VDI, 1998

[4] M. Hammer, J. Champy „Business Reengineering. Die Radikalkur für das Unternehmen“, Campus Verlag, Frankfurt/New York, 4. Auflage, 1994, S. 48

[5] A. Kölbener, „Kaizen in Japan“ in DIB e.V. „Kaizen und der kontinuierliche Verbesserungsprozess“, Deutsches Institut für Betriebswirtschaft (DIB) e.V. 1997, S. 30

[6] Diplomarbeit A. Buchheim, „Optimierung von Geschäftsprozessen – ein praktisches Beispiel inklusive einer Dokumentation zur weiteren Nutzung im Unternehmen“ 2003, S. 24 ff

6. Glossar

Abb. - Abbildung

Ad - Administration

bzgl - bezüglich

bzw. - beziehungsweise

CAG - Clarity AG

CASE - Computer Aided Software Engineering

CCM - Clarity Contact Manager

CEO - Chief of Executive Office

CFO - Chief of Finance Office

CSO - Chief of Sales Office

CTO - Chief of Technical Office

CUE - Clarity Ukraine Enterprises

CVS - current versioning system

DS - Direct Sales = Vertrieb Endkunden (inkl. International Sales)

GF - Geschäftsführung = Vorstand

ggf. - gegebenenfalls

GUI - Graphical User Interface

inkl. - inklusive

IR - Investor Relations

IS - International Sales = Internationaler Vertrieb

IT / TK - Informationstechnologie / Telekommunikation

LS - Large Account Sales = Großkunden Vertrieb = Clarity Solutions

M - Marketing

NLU - natural language units = natürlichsprachliche Dialogsysteme

o.ä. - oder ähnliches

PL - Projektleiter

PM - Project Management = Projektleiter

PS - Professional Services – Applikationsentwicklung

QS - Qualitätssicherung

Rw - Rechnungswesen

SD - Software Development = Entwicklung

SDK - Software Development Kit

SP - Sales with Partner = Vertrieb über Partner

Tab. - Tabelle

TQM - Total Quality Management

usw - und so weiter

z.B. - zum Beispiel

z.T. - zum Teil

z.Z. - zur Zeit