Schulungskonzept durch KDML und Change Management

Der Schulungsplan wurde auf Basis von KDML inhaltlich gestaltet und unter Berücksich-tigung der Ideen des Change Managements entwickelt. Um das beteiligte Unternehmen frühzeitig auf die Veränderungen vorzubereiten, wurde sich mit den Inhalten von verschie-denen Autoren³⁰⁹ über Change Management (CM) befasst, um ein Bewusstsein für dieses Thema im Projekt zu schaffen. CM dient als Mittel zum Zweck und war nicht Bestanteil der Forschung. Neue Forschungserkenntnisse wurden nicht durch CM erzielt. Jedoch wur-de das Projekt durch CM ein stückweit inspiriert und geleitet.

Die Entscheidung ein IT-PM einzuführen, wurde aus der Notwendigkeit getroffen, sich weiterzuentwickeln und Wettbewerbsfähigkeit zu verbessern. Mitarbeiter haben die Ver-änderungen am Markt gespürt. Fragen nach dem IT-PM sowie Prozessen häuften sich.

Auch waren ein uneinheitliches Vorgehen und eine nicht standardisierte Dokumentation interne Kritikpunkte, die ein deutliches Potential zur Verbesserung im Bereich des IT-PMs bedeuteten. Durch Change Management ist das Instrument Diagnose benutzt, um zu erfah-ren, wie hoch der Bedarf für die Veränderung ist. Gleichzeitig wurde das Instrument der Motivierung angewendet, da bereits in dieser Phase klar gewesen ist, dass das Ziel dieser Veränderung die Etablierung im Wettbewerb ist. In der Regel bringen Veränderungen, wie die Einführung eines neuen IT-Projektmanagement, sehr große Veränderungen innerhalb eines Unternehmens mit sich. Auch bei dem IT-Dienstleister betraf diese Einführung

309Vgl. Reiß/Rosenstiel/Lanz, 1997, Gattermeyer/Neubauer, 1996,Doppler/ Lauterburg, 2002, Lentz, 2004 sowie Wimmer, 2004.

123 zu alle Abteilungen. Durch die Einbindung aller Abteilungs- und Projektleiter in der Phase der Feinspezifikation unter Anwendung des narrativen Wissensmanagements wurde früh-zeitig ein entscheidender Personenkreis in das Projekt involviert. In so genannten Quali-tätszirkeln, die einmal im Monat in den einzelnen Abteilungen stattfanden und noch statt-finden und sich aus den Abteilungsleitern und Mitarbeitern der jeweiligen Abteilungen zusammensetzt, werden die Entwicklungsschritte und dazugehörigen Umsetzungen inten-siv besprochen. So ist gewährleistet, dass die Entwicklung den Konsens der Mitarbeiter hat. Da bei den Qualitätszirkeln auch Mitarbeiter teilnehmen, die der ausführenden Ebene angehören, wurde für eine breite Beteiligung im Unternehmen gesorgt. Ziel dieses Instru-mentes ist es, hierarchieübergreifende Beteiligungen zu schaffen und Verantwortungsbe-reiche und Ziele klar zu definieren. Auch die Mitarbeiter, die nicht aktiv an der Erstellung des IT-Projektmanagementtools beteiligt waren, sind im Rahmen von Quartalsmeetings in regelmäßigen Abständen über den aktuellen Status des Projektes informiert worden. Die Dokumentationen des narrativen Wissensmanagements (Storys) sind allen Mitarbeitern zugänglich. Auch wird allen Mitarbeitern auf dem Quartalsmeeting der letzte Entwick-lungsstand des Portals präsentiert. Dies entspricht erneut einem weiteren erprobten Instru-ment des Change ManageInstru-ments, der Information und dem Marketing für die Veränderung.

Ziel dieses Instrumentes ist es, Informationen von autorisierten Quellen zielgruppenorien-tiert weiterzugeben. Auch an dieser Stelle lassen sich weitere Instrumente wiederfinden, wie etwa die Motivierung mit der Anerkennung positiver Ergebnisse oder das Controlling mit der Kommunikation der Ergebnisse mit dem hierfür notwendigen Aufbau eines funkti-onierenden Berichtssystems. Ebenso wurden Moderatoren und Change Agents für das Pro-jekt qualifiziert, da sie von Anfang an bei der Entwicklung des webbasierten IT-Projektmanagement beteiligt waren. Es wurde also eine Vielzahl von Instrumenten des Change Managements eingesetzt, um bereits in der ersten Phase, dem Unfreeze, eine mög-lichst hohe Akzeptanz für diese Veränderung bei den betroffenen Mitarbeitern zu schaffen.

Mit Hilfe dieser Akzeptanz steigt die Chance auf eine erfolgreiche Veränderung. Die zwei-te Phase, Movingphase, ist gekennzeichnet durch die Definition von Zielen und die vorbe-reitenden Maßnahmen zur Umsetzung dieser Ziele. Auch bei der Einführung des IT-Projektportals standen diese Punkte und deren praktische Umsetzung im Vordergrund. Der Forscher hat für das Unternehmen für die Umsetzung in der Movingphase ein Rollenspiel entwickelt. Dieses interne Rollenspiel für den Führungskreis wird im weiteren Verlauf detailliert erklärt. Dieses Rollenspiel nutzt das Unternehmen dazu, um einen Funktionstest am entwickelten System durchzuführen. Ebenso dient das Rollenspiel zu einer weiteren

124 Einsetzung der Change Management Instrumente, um somit das Veränderungsvorhaben erfolgreich zu gestalten. Rollenspiele umfassen in der Regel zwei bewährte Instrumente.

Zum einen die Qualifizierung der beteiligten Mitarbeiter, die das System in diesem Fall zum ersten Mal im Betrieb erleben und dabei erforderliches Fachwissen und Metho-denkompetenz sammeln. Zum anderen ist neben der Qualifizierung auch eine Beteiligung am Änderungsvorhaben gewährleistet, die in diesem Fall auch hierarchieübergreifend statt-findet und somit auch die Akzeptanz bei den Mitarbeitern erhöht. Des Weiteren wird auch das Instrument Controlling angewendet. In diesem speziellen Fall wird der aktuelle Status des Projektes analysiert, und die Ergebnisse dieses Tests wurden ebenfalls zielgruppenori-entiert und von autorisierten Informationsquellen verbreitet. Die dritte Phase des Change Managements beschreibt die Verankerung der Veränderung im Unternehmen. Mit Hilfe eines Trainings, das auf drei Tage aufgeteilt wurde, ist notwendiges Fachwissen und Me-thodenkompetenz an die Mitarbeiter vermittelt worden. Ebenso wurden erneut die Ergeb-nisse der Entwicklungs- und Testphase kommuniziert. Die Verankerung wird durch Ziel-vereinbarungen und Belohnungen für Mitarbeiter unterstützt. In ersten Pilotprojekten soll die neue Vorgehensweise erprobt werden und Mitarbeiter für ihr Engagement und ihren Pioniergeist ausgezeichnet und belohnt werden. Eine wirkliche Verankerung muss die feste Integration in den betrieblichen Alltag der Berater bringen. Das Management muss zu ei-nem gewissen Zeitpunkt jedes neue akquirierte Projekt mit der neuen Vorgehensweise und den neuen Instrumenten beginnen lassen.

Das Projektportal enthält viele verschiedene Prozessabläufe und Funktionen, die die Durchführung der fünf Projektphasen zur Einführung eines Projektes unterstützen. In die-sen Abläufen und Funktionen wird durch den Benutzer Wisdie-sen angewandt bzw. erlangt.

Dieses Wissen unterliegt einer permanenten Umwandlung und entwickelt sich weiter. Um die Mitarbeiter mit dem Umgang des Portals zu schulen, wird genau dieses Wissen durch KDML nutzbar gemacht. Diese Inhalte werden in ein Konzept umgesetzt. Die Schulung richtet sich an alle Anwender des Portals, d.h. Mitarbeiter des beteiligten Unternehmens und Mitarbeiter der Kunden. Ziel der Schulung ist, den Mitarbeiter in die Lage zu verset-zen, das Projektportal zu bedienen. Die theoretischen Hintergründe, auf der die Entwick-lung des SchuEntwick-lungskonzepts basieren, sind unter URL 59 und 60 einzusehen. Darüber hin-aus bezweckt die Schulung, die neue Vorgehensweise zu erlernen, um zukünftig für das Projekt entstehendes Wissen zu erkennen. Gemäß den Ausführungen zum Change Ma-nagement soll die Verwendung des Portals stufenweise im Alltag des beteiligten Unter-nehmens eingeführt werden, wie in der nachstehenden Abbildung gezeigt wird.

125 Abbildung 50: Stufenplan Einführung des Portals

Quelle: Eigene Darstellung.

Bei erster Stufe wird das Portal vom Führungskreis (Abteilungs- und Projektleiter) des beteiligten Unternehmens getestet. Eventuell müssen Schulungsinhalte nach dem ersten Test erweitert oder verändert werden. In der zweiten Stufe beginnt eine strukturierte Ein-führung in das Unternehmen durch Schulungen für Projektleiter und Consultants. Anhand des aus dieser Schulung erworbenen Wissens werden einige Pilotprojekte mit ausgewähl-ten Kunden in der dritausgewähl-ten Stufe durchgeführt. Nach erfolgreicher Abwicklung dieser Pro-jekte findet die vierte Stufe statt. Das Portal wird für alle ProPro-jekte verwendet. Bevor dieser Schritt erfolgt, können im Verlauf der drei ersten Stufen Anmerkungen oder Verbesserun-gen entstehen, die berücksichtigt werden müssen. In der Abbildung wird dieses mit dem Zurückpfeil dargestellt. Die Erfahrungen aus den vorangegangenen Stufen sollten immer in die Weiterentwicklung der Schulungsmaterialien (Inhalte) mit einfließen. Für die erste und zweite Stufe ist ein inhaltliches Schulungskonzept ausgearbeitet worden, wie die folgende Tabelle darstellt.

Tabelle 14: Kurzbeschreibung des Schulungskonzepts

Schulungsplanpunkt Beschreibung

1. Personalschulungsbedarf  Alle Abteilungen

2. Zielgruppen  Consultants

 Projektleiter

 Vertrieb

3. Wer führt die Schulung durch?  Portalentwickler

4. Schulungsinhalt (Dauer)  Teil 1: Test mit Führungskreis (1 Tag)

 Teil 2: Schulung für alle Mitarbeiter (3 Tage:

Theorie, Modellierung, Übung) Quelle: eigene Darstellung.

126 Dabei wurden wissensintensive Prozesse insbesondere bei der Erstellung der Inhalte be-rücksichtigt. Alle KDML-Modellierungen stehen den Verantwortlichen, den Trainern, den Projektteilnehmern zur Verfügung, um sich einen fundierten Überblick zu verschaffen.

Somit ist das Funktionswissen, d.h. wie das Portal funktioniert, sowie auch das wichtige Wissen für die Anwendung verfügbar gemacht. Bei dem Führungskreistest übernehmen die Abteilungs- und Projektleiter sowie die Geschäftsführung verschiedene Rollen, d.h.

eine Gruppe simuliert das eigene Unternehmen, und die andere Gruppe spielt den Kunden.

In der folgenden Tabelle wird Durchführung des Tests mit dem Führungskreis vorgestellt.

Mithilfe des Rollenspiels wird getestet, wie gut das Portalkonzept geeignet ist, um Projekte abzubilden. Die Anforderungen des Modell-Kunden sind Echtfällen nachempfunden.

Tabelle 15: Test mit Führungskreis

Durchführung: Zuständigkeit

Zunächst wird seitens des Unternehmens eine Agenda erstellt, um darauf basierend einen Workshop durchzuführen und so die Kundenbedürfnisse festzustellen und zu dokumentieren. Mit P.4b werden die Kundenanforderungen modelliert.

PL

Nach der Durchführung des Workshops werden die beim Kunden erfassten Anforderungen zur Prüfung und Freigabe dem Vertrieb vorgelegt.

PL und Vertrieb

Sobald die interne Freigabe erfolgt ist, wird das Anforderungs-dokument dem Kunden übergeben. Zudem wird ein Sicherungs-dokument mit allen freigegebenen Kundenanforderungen in der Sicherungsbibliothek erstellt.

Geschäftsleitung (GL)

Vertrieb Die freigegebenen Anforderungen werden von der Projektleitung

und Geschäftsleitung Kunde genehmigt.

PL/ GL Kunde Eine Feinspezifikation wird beim Kunden durchgeführt. Die in

der Referenzanalyse erfassten Anforderungen werden als Grund-lage verwendet und in der Spezifikation erweitert.

PL und Vertrieb

Der Projektleiter legt nachfolgend Entwicklungsaufgaben zu den einzelnen Spezifikationspunkten an und weist den Projektmitar-beitern ihre Aufgaben zu.

Projektleiter

Zur Kontrolle und als Hilfestellung werden in den einzelnen Pro-jektphasen Lenkungsausschusssitzungen durchgeführt.

Alle Nach Fertigstellung der Entwicklungen melden die

Projektmitar-beiter an den PL zurück. Die Entwicklungen werden auf das Testsystem übertragen. Eine Übergabe des Testsystems an den Kunden erfolgt. Der Kunde bearbeitet die Aufgaben.

Anschließend erfolgt die Durchführung von Massen- und Integ-rationstests. Erfolgreich Tests ermöglichen den Echtstart.

PL

Quelle: eigene Darstellung.

127 Die Schulung mit den Mitarbeitern dauert drei Tage. Die Schulung findet abteilungsbezo-gen statt. Beispielsweise wird ein Mitarbeiter des Vertriebs, der für ein bestimmtes Bran-chen-ERP-Produkt zuständig ist, mit den entsprechenden Projektleitern und Consultants aus diesem Softwarebereich geschult. Das Ziel des ersten Tages ist, die theoretischen Grundlagen über das neugestaltete IT-PM sowie über einzelne Funktionen des Portals an-hand der anschaulichen Beispiele zu vermitteln. Der zweite Tag beinhaltet das Thema des GPMs inkl. Modellierung. Am dritten Tag werden integrierte Anwendungen zu beiden Instrumenten angeboten. Die Themen werden vom Trainer im Laufe des Tages präsentiert und sind in der Tabelle in Anhang 20 Basis der Erkenntnisse von KDML dargestellt. Der Trainer verwendet vorbereitetes Schulungsmaterial. Diese Inhalte stehen den Teilnehmern auch zur Verfügung. Um die besondere Aufmerksamkeit auf wissensintensive Prozesse zu schenken, kann der Trainer die KMDL-Modellierungen der Portalprozesse benutzen.

8 Hypothesenreflektion

Zu Beginn dieses Kapitels wird die Artikulation der Hypothesen kurz kritisch diskutiert.

Danach erfolgt die Thesenreflektion als solche, in der auch der Beitrag der Studie zu den Gesamtergebnissen deutlich gemacht wird.

Die Hypothesen sind in Anlehnung an die Praxisrelevanz praktisch formuliert und struktu-riert. Eine Methodenorientierung im Sinne des Business Engineerings und der zu integrie-renden Managementkonzepte ist offensichtlich. Diese Form der Thesenartikulation birgt die Gefahr, dass durch eine schnelle Weiterentwicklung in der Praxis die Thesen veraltet werden. Allerdings liegen die Vorteile der gewählten Form der Artikulation in der Erhö-hung der Praxisbezogenheit, die ein wichtiger Bestandteil der betriebswirtschaftlichen For-schung darstellt. Die Hypothesen sind modern und dem Thema zugeordnet. Die Hypothe-sen beinhalten Brisanz. Die Diskussionen im verschiedenen Kapitel zeigen dieHypothe-sen Sach-verhalt. In Kapitel 3.2.1 (letzter Absatz) „Abkehr von Funktionen zu Prozessen“ ist zu er-kennen, dass Fachkundige ein Bewusstsein haben, aber niemand das kritische Thema an-packt. In Kapitel 5.1 steht weiterhin: „ Wird der Fakt betrachtet, dass eine ERP-Software kaufmännische Prozesse unterstützen soll, kommt die Frage auf, warum die Unterneh-mensprozesse in der Analysephase bisher keine Rolle spielen“ Fachkundige diskutieren, dass Prozesse und Menschen mit ihrem Arbeitsverhalten eine Rolle spielen sollten. Fast alle ERP-Dienstleister betrachtet in den Analysen keine Prozesse, sondern fokussiert im-mer noch die funktionale Betrachtung einer Software. Entwickler und IT-Berater kennen sich besser mit Funktionen der Software aus und sind (noch) keine Geschäftsprozessbera-ter (ein anderes Geschäftsfeld). Viele IT-BeraGeschäftsprozessbera-ter würden sagen: „Prozessbetrachtung und

128 Prozessberatung können die KPMGs dieser Welt tun….“) Fachkundige IT-Berater sehen aktuell eher eine Mehrbelastung anstelle einer Weiterentwicklung (eigene Erfahrung aus einer Vielzahl von Gesprächen mit IT-Beratern verschiedener Unternehmen im Laufe der Forschung auf Veranstaltungen etc. Diese Aussage ist nicht wissenschaftlich validiert.). Im Rahmen der Diskussion Agilität und Klassik der Vorgehensmodelle wird Heterogenität der Meinungen Fachkundiger sichtbar. Insbesondere junge Entwickler sehen nur in der Agilität eine wirkliche „freie“ Entwicklung und haben die klassischen Vorgehensmodelle abge-schrieben. Diese Diskussion würde bei einem Aufeinandertreffen zweier Parteien (agile und klassische) zu einem hohen Unterhaltungswert führen. Auch durfte der Doktorand während der Forschung solche Diskussionen mitverfolgen. Die Kapitel 4.4 und 5.7. zeigen deutlich, dass WM und Portale zwar in der IT-Welt vertrieben werden, aber der eigene Nutzen und die eigene Anwendung bzw. das Ausführen von WM durch IT bzw. Portale existiert im IT-PM nicht. Fachkundige würden diese Thesen als sinnvoll in Bezug auf den visionären Gedanken betrachten, aber als nicht umsetzungsrelevant. IT-Systemhäuser im Mittelstand haben häufig oftmals nur zwischen 5-30 Mitarbeiter. Der durch diese Mitarbei-ter generierte Ressourcenumfang wird aber an Kundenprojekte fakturiert anstelle in die Entwicklung eines eigenen IT-Projektmanagement mit integrierten Wissensmanagement auf Portaltechnologie investiert. Insofern eigene Forschung und Entwicklung betrieben wird, wird dies für eigene Produkte getan, die verkauft werden können. In Dienstleistung bzw. Service, d.h. die Bereitstellung eines Portals, wird eher nicht gedacht. Dies belegt auch die durchgeführte Literaturstudie, die Schlussfolgerung der Studie sowie die eigenen Erfahrungen. Die daraus resultierte These zeigt deutlich die existierende Meinungsver-schiedenheit dieses Inhalts, aber auch die Aktualität.

Die erste These ist wahr. Die isolierte Anwendung eines einzigen Vorgehensmodells führt zum Scheitern des IT-Projekts. Die Idee eine Integration bzw. Kombination klassischer Vorgehen mit agilen Methoden ist für die Zukunft unabdingbar und stößt in der IT-Fachwelt auf Zustimmung. Die durchgeführte online-Studie sowie die teilnehmende Be-obachtung bei der Ausführung der Feinspezifikationen bestätigen diese Erkenntnis. Der aktuelle Stand der Literatur in der IT-Fachwelt lässt den Rückschluss zu, dass allerdings praktische Erfahrungen und konkrete Erklärungen zur Anwendung und Umsetzung fehlen.

Um den Alltag des IT-Projektmanagements durch eine Kombination der Vorgehensmodel-le zu verändern, müssen Auftraggeber im Sinne der Agilität in die Entwicklung eng mit eingebunden werden. Dieser Schritt verlangt eine Kommunikation und Interaktion, die technologisch durch entsprechende Instrumente, wie Portaltechnologien, zu unterstützen

129 ist. In diesem Zuge folgt die Erkenntnis, dass Instrumente, die IT-Projektmanager und de-ren Teams unterstützen, zu entwickeln sind. Da die IT-Fachliteratur sowie die durchge-führte Studie zur Erkenntnis geführt haben, dass Auftraggeber eine fundierte Dokumenta-tion des zu erwartenden Ergebnisses (Klassisches Vorgehensmodell) bei gleichzeitig hoher Flexibilität in Bezug auf Änderungen (Agilität) erwarten, ist ein systematisches, transpa-rentes, aber auch flexibles Anforderungsmanagement in das Vorgehensmodell zu integrie-ren. Für Verfechter der klassischen Vorgehensmodelle sind eine methodische Einbindung der Auftraggeber über Freigabeszenarien und eine Flexibilität auf Änderungen eher zu verkraften, denn es sind strukturierte Änderungen über Kommunikationsinstrumente per Methode integrierbar. Einige klassischen Vorgehensmodell, wie das V- oder VXT-Modell, bieten die Möglichkeit, mit Zwischenschritten zur Überprüfungen und Anpassungen von Inhalten zu arbeiten. Natürlich muss das im Rahmen des Budgets erfolgen. Oder es werden Regelungen geschaffen, wie kaufmännisch mit Änderungen im Projektverlauf umgegangen wird. Die Studie hat darüber hinaus noch gezeigt, dass Ziele und Nutzen mit dem Kunden aus Sicht der Auftragnehmer entsprechend diskutiert und dokumentiert werden müssen.

Dieser Fakt ist mit klassischen Vorgehensmodellen vereinbar, denn es wird die Qualität der Dokumentation verbessert. In diesem Rahmen müssen Budgetwerte festgelegt werden, Instanzen zur Kostenkontrolle sowie Statusberichte geschaffen werden, denn es zeigte die Studie, dass Kosten oftmals überzogen werden. Agile Softwareentwickler müssten, falls sie auf eine Dokumentation verzichten, zu mindestens bevor sie anfangen zu entwickeln mit dem Auftraggeber diese Inhalte absprechen. Hier entsteht ein Potential, Fehlentwick-lungen, die bewusster Bestandteil der Agilität sind, zu vermeiden. Faktisch hat dieser In-halt im Sinne der These nur Positives.

Problematisch sind allerdings die Erkenntnisse der Studie sowie der Ausarbeitungen für die Verfechter der agilen Vorgehensmodelle. Ein strukturiertes Vorgehen und eine umfas-sende Dokumentation bei gleichzeitig erhöhtem Kommunikationsaufwand ist ein wissen-schaftlicher Rückschlag. Eingefleischte agile Entwickler werden sich diese Punkte nicht zu Herzen nehmen und in ihr Vorgehen integrieren. Die Reinheit der Entwicklung liegt in der Freiheit der Agilität. Betrachtet man allerdings die Vielzahl von IT-Projekten, die aktuell scheitern, wird diese These auf Basis der erforschten Erkenntnisse unterstützt und verlangt eine Kombination beider Vorgehensmodelle unter Berücksichtigung technologischer Kommunikationsmittel. Die Studie sowie die Ausarbeitungen haben auch gezeigt, dass eine mangelnde Verfügbarkeit von Informationen und Dokumentationen bei zeitgleicher Nutzung von Email und Telefon als Kommunikationsinstrument in IT-Projekten

vorherr-130 schen. Das Potential der Nutzung von technologischen Plattformen als Kommunikations-mittel rücken bei Betrachtung dieser These in den Vordergrund. Eine Zusammenführung dieser Faktoren führt zu einer erheblichen Veränderung des aktuellen Vorgehens in IT-Projekten. Die isolierte Anwendung eines Vorgehensmodells muss der Erkenntnis der Kombination weichen und ist das Forschungsergebnis dieser Arbeit, welche Hypothese 1 unterstützen.

Die zweite These ist wahr. Die Relevanz von Wissensmanagement in IT-Projektmanagement ist zukünftig unabkömmlich. Leider verfolgt Wissensmanagement aber einen nicht konsistenten Ansatz, wie die Literatur, aber auch die Studie gezeigt hat.

Gerade die Wissensidentifikation sollte zu Beginn eines Projekts im Vordergrund stehen, um das relevante Wissen für den weiteren Verlauf des Projekts (man denke hier an Ver-tragsgrundlagen oder die Entwicklung der Lösungen im Projekt) zu erheben. Die Studie zeigt einen erheblichen Mangel der Dokumentation jeglicher Inhalte. Vorgehensmodelle, insbesondere die klassischen, fordern eine umfassende Dokumentation, wie die Sekundär-forschung zeigt. Allerdings zeigt die Praxis, dass Wissensmanagement eben nicht bei der Ausführung von IT-Projekten berücksichtigt wird. Die Erkenntnis, dass Wissensmanage-ment oftmals der Kontext fehlt und zu abstrakt ist, kann mutmaßlich als ein Grund angese-hen werden. Auch ist das grundsätzliche Beschäftigen mit Wissensmanagement ein res-sourcenbindendes Element, welches insbesondere Mittelständler nicht tragen können oder wollen. Eine umfassende wissensbasierte und prozessorientierte Dokumentation erfordert Zeit. Dass solch eine wissensintensive Konzepterstellung budgetiert werden sollte, stellt einen Kompromiss aller Beteiligten im Sinne der These dar. Denn nur wenn die Budgets auf den Tisch liegen und der Auftraggeber ein fundiertes Konzept erhält und den Nutzen argumentiert bekommt, wird er bereit sein, für dieses Wissen zu bezahlen.

Die methodische Einflussnahme von Wissensmanagement in IT-Projektmanagement ver-langt innerhalb des Anforderungsmanagements eine projektorganisationale Wissensbasis.

Die Dienstleiter sind gefordert, diese Wissensbasis zu entwickeln. Die Mehrheit der IT-Dienstleister wird aus Ressourcengründen diese Eigenentwicklung scheuen und sich zwar für die Richtigkeit der These entscheiden, aber keine Rückschlüsse für das eigene unter-nehmerische Handeln ziehen. Denn, wie die Praxis zeigt, werden günstige IT-Projekte oh-ne wissensbasierte Dokumentation erfolgreich verkauft; auch wenn der für den Kunden

Die Dienstleiter sind gefordert, diese Wissensbasis zu entwickeln. Die Mehrheit der IT-Dienstleister wird aus Ressourcengründen diese Eigenentwicklung scheuen und sich zwar für die Richtigkeit der These entscheiden, aber keine Rückschlüsse für das eigene unter-nehmerische Handeln ziehen. Denn, wie die Praxis zeigt, werden günstige IT-Projekte oh-ne wissensbasierte Dokumentation erfolgreich verkauft; auch wenn der für den Kunden