Es ist erlaubt, digitale und Kopien in Papierform des ganzen Papers oder Teilen
davon für den persönlichen Gebrauch oder zur Verwendung in Lehrveranstaltungen zu erstellen. Der Verkauf oder gewerbliche Vertrieb ist untersagt. Rückfragen sind zu stellen an den Vorstand des
GC-UPA e.V. (Postfach 80 06 46, 70506 Stuttgart).
Proceedings of the 2nd annual GC-UPA Track, Paderborn, September 2004. Für diejenigen, die die Konferenz verpasst haben: der Tagungsband kann für 30,00 EUR bei
Matthias Peissner bezogen werden.
Dr. Stefan Voigt und Rainer Heers, basierend auf dem Vortrag auf der Tagung Mensch und Computer 2004
Inhalt
Abstract
Projektmanagement und Usability werden in Projekten oft von vornherein als Gegensätze begriffen: zuwenig Zeit, kein Geld, ‘ich weiß, was der Nutzer will’, Technologiezentrierung, illusorische Zeitpläne, Ausblendung von Folgekosten und die Mißachtung des ‘Faktors Mensch’ im IT-Management sind die häufigsten Gründe. Untersucht werden deshalb verschiedene Mythen zum Projektmanagement (Zeit, Planbarkeit, Machbarkeit, Kundenorientierung und Mitarbeitereinsatz), um zu analysieren, was Projektmanagement tatsächlich ausmacht. Die Rollen eines Usability Engineer im Projekt verdeutlichen, wie die Kombination von Nutzerfreundlichkeit mit gutem Projektmanagement zu einem inhaltlich und organisatorisch erfolgreichen Projekt und einem wirtschaftlich erfolgreichen Produkt führen kann.
Keywords
Projektmanagement, Projektsteuerung, Usability Engineering, Kundenorientierung, Nutzerorientierung, Qualitätssicherung, Gebrauchsfreundlichkeit
Einleitung
Projektmanagement und Usability haben einiges gemeinsam: Mythos und Realität vermischen sich zu diffusen Vorstellungen über den ‘Zauberer’ (Projektmanager) einerseits und den ‘Anwalt des Nutzers’ (Usability Engineer) andererseits. Was jedoch sind die tatsächlichen Rollen und Aufgaben, die beide in einem Projekt einnehmen? Welche Interessen verbinden oder trennen sie und worin liegen die Erfolgsfaktoren und Fallstricke im Projektalltag? Die damit bereits implizit genannten Faktoren gilt es zu betrachten, um eine erfolgreichen Zusammenarbeit dieser Schlüsselpersonen zu erreichen.
Mythos Projektmanagement
Modernes Projektmanagement zeichnet sich (zumindest in der IT-Industrie) nicht mehr nur durch die klassischen drei Kontroll- und Erfolgsfaktoren (Zeit, Kosten, Qualität) aus. Softwareprodukte sind keine Werkstücke, die am Ende des Produktionsprozesses bloß funktionieren müssen. Sie müssen vielmehr auch nach der Auslieferung sowohl in der Zeit (Updates, Skalierung, Anpassung) als auch in der Qualität (Nutzerfreundlichkeit, Trainingsbedarf, Servicefreundlichkeit, techn. Innovation) hohen Ansprüchen gerecht werden müssen, um am Markt zu bestehen. Damit entstand ein ‘Mythos des Projektmanagements’, erscheint es doch als Lösung für viele Probleme, in denen der Projektmanager beinahe als ‘Zauberer’ erscheint. Neben den fachlichen und betriebswirtschaftlichen Anforderungen des Projekts vollbringt er (scheinbar) das Wunder, die Interessen der eigenen Geschäftsleitung und interner oder externer Auftraggeber zu erfüllen. Da Zauberei aber eben nur Zauberei ist (im Gegensatz übrigens zum Erschaffen von Wundern, denen kein ‘Trick’ zugrundeliegt), haben sich verschiedene Autoren mit den Mythen des Projektmanagements genauer befasst, vgl. zum Beispiel DeMarco, 1999; Sprenger, 2002, Wischnewski, 2001. Wir beschäftigen uns hier mit fünf Mythen, die exemplarisch für den ‘Mythos Projektmanagement’ stehen sollen:
Mythos 1 - Zeit
Unter dem Mythos Zeit verstehen wir das Phänomen, dass beinahe jedes Projekt am Ende seiner Laufzeit in Zeitnot gerät. Dies gilt sogar für Projekte mit identischen Aufgaben, aber unterschiedlichen Zeiträumen für die Erfüllung dieser Aufgaben: ob fünf Wochen oder fünf Monate, am Ende ist Zeit knapp. Ãœber die Gründe wird in ‘lessons learned’ meist nur gemutmaßt: Es wurde falsch geplant, es wurde zuwenig, zuviel oder gar nicht geplant oder es wurde zu Beginn zu viel Zeit ‘vertrödelt’ (horror vacui-Effekt). Es stellt sich die Frage, ob es als unanständig gilt, in einem Projekt Zeit zu haben oder, horribile dictu, sogar vor dem Abgabetermin fertig zu werden. Warum ist das so?
Die Ursachen lassen sich nicht immer sauber herausarbeiten, jedoch erscheint es plausibel, in der (allerdings immer beklagten) Zeitnot eine condition sine qua non zu sehen. Zeitknappheit und -not muß von allen Beteiligten behauptet werden, da sonst nicht nur der Dienstleister bei seiner Kalkulation zu großzügig (sprich: verschwenderisch) mit dem eingesetzten Geld des Auftraggebers umgegangen wäre, sondern ebenso der Auftraggeber als allzu großzügiger, ja leichtfertiger Unternehmer gelten würde, der seine Leute nicht ‘im Griff’ hat. Den Mitarbeitern sind diese Abläufe meist besser vertraut als ihnen lieb ist. Auf der anderen Seite stehen Ihnen zuweilen Führungskräfte gegenüber, die grundsätzlich ‘keine Zeit’ haben: Weder für Diskussionen zur Verbesserung des Projektverlaufs noch für Gespräche mit Mitarbeitern. Vielmehr werden kurzfristig (sic) Anfragen zum Zustand des Projektes formuliert, um die nächsthöhere Führungsebene (mit noch weniger Zeit) zufriedenstellen zu können.
Mythos 2 - Planbarkeit
Beide Teile des Wortes Projektmanagement suggerieren: man hat die Sache im Griff. Alles ist geplant. Die Erfahrung zeigt: dem ist nicht so. Softwareproduktion ist ein Spiel mit vielen Unbekannten. Dabei ist noch nicht einmal von technischen Problemen die Rede. IT-Projekte scheitern äußerst selten an technischen Problemen, sondern fast immer an soziologischen bzw. Managementproblemen (DeMarco 1999).
Wie wenig diese Erkenntnis verbreitet ist, zeigt zum Beispiel das Prozedere bei Projektausschreibungen. Welcher Dienstleister wird eine Ausschreibung gewinnen, der mit dem perfekt bis ins Details geplanten Projektplan, in dem Hunderte von Einzeltätigkeiten auf jede Stunde hin genau auflistet sind, oder der andere mit dem Projektplan, in dem ca. 20 Blöcke von Leistungen aufgelistet sind, die untereinander flexibel gehandhabt werden können? Die Folge: ein irrwitziger Projektplan muß eingehalten werden, Verzögerungen aufgrund unrealistischer Planung gehen zu Lasten von Mitarbeitern und Qualität. Man wird evtl. fertig, aber für welchen Preis.
Mythos 3 - Machbarkeit
Das Scheitern von Projekten ist in Projektplänen nicht vorgesehen. Es widerspricht dem positiven erfolgsorientierten Denken von Managern: Jedes Ziel ist erreichbar (es kommt nur auf den Einsatz der richtigen Mittel an). Und dennoch scheitern Projekte. Die Machbarkeit eines Projektes hängt nämlich von (oft unüberschaubaren) Faktoren ab: die eigene Geschäftsleitung, der Auftraggeber, die Mitarbeiter, politische oder ökonomische Rahmenbedingungen. Wodurch das Scheitern des Projektes letztlichendlich ‘geschafft’ wird (denn auch hierzu gehört viel Energie), ist grundsätzlich nicht so relevant wie die Einsicht, dass Projekte scheitern können. Oft sind es inhärente Grenzen (der Plan, die knappe Zeit, s.o.), die zu enge Grenzen für den Erfolg setzen und so Produkte einschränken, die doch möglich wären (aber eben nicht wahrscheinlich sind).
Mythos 4 - König Kunde
Nur - wer ist der ‘Kunde’? Und was will er? Zunächst ist der Auftraggeber der Kunde. Der Endkunde oder Endverbraucher hingegen, der das fertige Produkt letztendlich bezahlt und / oder benutzt, ist nicht direkt am Projekt beteiligt. Aufgrund dieser Konstellation wird ein Projekt zunächst für andere ‘Kunden’ gemacht: den Auftraggeber, das Marketing, den Vertrieb, das Controlling, den Projektleiter, für Ruhm und Ehre. Ursprünglich gemeint ist mit Kundenorientierung jedoch die Orientierung am Nutzen, am Mehrwert des Endverbrauchers, da dieser das fertige Produkt schließlich kaufen soll. Konkret sind meist sehr keine oder nur diffuse Vorstellungen über den Kunden anzutreffen, die zur Rechtfertigung des eigenen Tuns herangezogen werden, ohne auf belastbaren Daten zu beruhen.
Mythos 5 - Teamarbeit
Entgegen der theoretischen Einsicht und einer allenthalben propagierten Teamarbeit nehmen sich Mitarbeiter oft wie ein winziges Rädchen in einer übermächtigen Maschine wahr. Sie sind häufig der am wenigsten verstandene und berücksichtigte Faktor in einem Projekt. Sie haben häufig den Eindruck beliebig austauschbar, jederzeit und ohne Einarbeitung verfügbar, beliebig kombinierbar und zueinander ohne Reibungsverluste addierbar zu sein. Für den Projektmanager liegt hier die nur selten (im mindestens doppelten Wortsinn) wahr-genommene Aufgabe: die alltägliche Koordination verschiedener Individuen mit all ihren Eifersüchteleien, Eitelkeiten etc. Diese kaum zu unterschätzende Aufgabe erscheint jedoch nicht in den fein säuberlich ausgearbeiteten Projektplänen. Die Mitarbeiter kommen erst dann ins Blickfeld, wenn ein Projekt doch einmal in Verzug gerät. Der Druck auf die vorhandenen Mitarbeiter steigt oder der Projektfortschritt soll durch einen kurzfristig erhöhten Personaleinsatz wettgemacht werden. Schließt sich der Projektmanager dieser Ansicht an, gerät das Projekt wahrscheinlich noch weiter in die Bredouille. Widersetzt er sich jedoch, riskiert er, für den absehbaren und sich aus vielfältigen Ursachen ergebenden Mißerfolg allein verantwortlich gemacht zu werden.
Diese Mythen zeigen, in welchem Spannungsfeld sich ein Projektmanager bewegt und welche heterogenen Anforderungen er letztlich erfüllen muss. Im Erfolgsfall erfüllt der zaubernde Projektmanager alle Anforderungen perfekt: Er schließt das Projekt im Zeitrahmen ab. Er plant alle Eventualitäten voraus. Er sorgt dafür, dass jede noch so abwegig erscheinende Anregung des Auftraggebers im Projekt umgesetzt wird. Er erfüllt jeden Wunsch des Kunden. Und natürlich sind alle im Projekt eingesetzten Mitarbeiter glücklich und zufrieden. Häufig ist jedoch zumindest in einigen Punkten das genaue Gegenteil der Fall. Deswegen ist der Projektmanager oftmals eher ein Krisenmanager als ein Zauberer.
Usability Engineering
Eine Methode, um die negativen Auswirkungen der oben beschriebenen Mythen zu minimieren, ist die Verfahrensweise des Usability Engineerings (UE). Aber, was ist das eigentlich? Und was sind die Aufgaben eines ‘Usability Engineers’? Diese einfachen Fragen führen schnell zum Kern des Problems: Idealerweise ist UE ein zielgerichtetes, strukturiertes Vorgehen im Projekt, das darauf ausgerichtet ist, ein gut bedienbares und mehrwertschaffendes Produkt zu entwickeln. In der Literatur (z.B. Mayhew, 1999; Nielsen & Mack, 1993; Hackos & Redish 1998) und in internationalen Standards (u.a. ISO DIN 13407) sind die notwendigen Prozesse, Verfahren und Methoden benannt und diskutiert, die UE zu einem anerkannten Referenzmodell machen, das
- planvoll organisiert,
- aus der Praxis entwickelt,
- international anerkannt und bewährt,
- hocheffizient ist.
Der Usability Engineer ist der fachlich ausgebildete Mitarbeiter, der die relevanten Methoden und Verfahren beherrscht und umsetzt. Kennzeichnend für sie oder ihn ist eine explizite Praxisorientierung, ein pragmatisches Vorgehen, die Integration in bestehende Prozesse (Softwareentwicklungsprozesse, Produktdesign, o.ä.) und eine klar definierte Rolle als Stakeholder im Projekt. Die Effizienz des Usability Engineers zeigt sich bei kostengünstigen down-to-earth Methoden (Paper Prototyping, Heuristische Evaluation, Walkthrough-Verfahren etc.) bis hin zu aufwendigen experimentellen Usability-Tests (vgl. Barnum, 2002, Mayhew, 1999). Die Zusammenarbeit des Usability Engineers auf der Arbeitsebene betrifft i.d.R. alle anderen beteiligten (Fach-)Abteilungen: Die Konzeption bzw. Informationsarchitektur, Design, Anwendungsprogrammierung und Projektmanagement. Nur: wann und wie der Usability Engineer konkret hinzugezogen wird, ist je nach Unternehmen und je nach den projektverantwortlichen Personen höchst unterschiedlich. Nicht selten müssen sich Usability Engineers ihre Position und ihren Einfluß langwierig erarbeiten.
Dementsprechend werden die Ziele von Usability Engineering von außen oftmals anders gesehen als von innen. Die heterogenen Interessenlagen innerhalb eines Projektes (s.o.) machen es zum Beispiel oft unmöglich, klar zu definieren, wann ein Projekt zuende ist: nach dem Roll-Out? Wenn die Vorgesetzten zufrieden sind? Wenn das Controlling zufrieden nickt? Oder gar erst dann, wenn ein Nutzer die Software tatsächlich bedienen kann (und dies gerne tut)? Zu einigen dieser Punkte kann der Usability Engineer sein Scherflein beitragen, denn UE führt u.a. zu einer deutlichen Kostenreduktion im Gesamtverlauf eines Projekts. Je später allerdings ein Produkt am Markt und am Endkunden ausgerichtet wird, desto höher sind Änderungs- sowie Folgekosten (von Garantie und Kulanzkosten einmal ganz abgesehen). Gutes UE kann neben einer hohen Gebrauchsfreundlichkeit des Endproduktes auch die Minimierung von Folgekosten gewährleisten (Mayhew, 1999), die ihre Ursache oft in einem kurzsichtigen Release- und Patch-Denken haben.
Im Projekt hat der Usability Engineer den Hut des tatsächlichen späteren Nutzers von Software auf. Nur, wer hat ihm dieses Mandat erteilt? Und wen vertritt der Usability Engineer wirklich? Wie jeder andere Projektbeteiligte auch hat er genuin eigene Interessen, z.B. sich selbst zumindest als wertvollen Mitarbeiter darzustellen oder sich zu profilieren. Andererseits sind es letztlich die Endkunden, die ein Produkt kaufen und somit dessen Erfolg sichern. Sie sind zumeist ein Konglomerat unterschiedlichster Käufergruppen, über die nicht sehr viel bekannt ist. Der Usability Engineer übernimmt in diesem (häufigen) Fall die Funktion, Vorurteile anderer Projektmitarbeiter oder des Auftraggebers über ‘den Endkunden’ kritisch zu hinterfragen, sei es mit umfassenden Zielgruppenanalysen, sei es mit kleinen Fokusgruppen. Ein minimalistisches Usability Engineering kann sich auch darauf beschränken, nur die Beachtung von Normen und Standards einzuhalten. Dem Usability Engineer kommt eine Querschnittsfunktion zu, die er, beginnend mit dem Bedien- und Anzeigekonzept des Produktes über die ergonomische Gestaltung bis hin zu Usability-Tests und der Begleitung der Markteinführung ausfällt. In der Praxis heißt das, dass der Usability Engineer in allen Projektphasen berät, Vorgaben macht, testet, Iterationen anstößt und Entwicklungsschritte evaluiert. Das bedeutet oft den Einsatz hoher sozialer und fachlicher Kompetenz, um eigene und fremde Interessen im Projekt miteinander verbinden zu können.
Usability Engineer und Projektmanager
Die Parallelen zwischen den Tätigkeiten von Usability Engineer und Projektmanager liegen auf der Hand. Beide müssen auf die Erfüllung von Vorgaben bei anderen Projektbeteiligten dringen. Beide müssen Ãœberzeugungsarbeit nicht nur gegenüber Geschäftsleitung und Auftraggeber leisten, dass der Erfolg des Projektes und des Produktes durch Usability Engineering zumindest erhöht, besser noch garantiert ist. Beide stehen zwischen oder neben den Kollegen, die das konkrete Produkt tatsächlich erstellen. Und selbst wenn der Usability Engineer das Anwendungskonzept erstellt hat, wird die Gestaltung und technische Umsetzung von ihm doch nur begleitet. Er ist einerseits Begleiter und Evaluator laufender Arbeiten, andererseits reicht seine Verantwortung oft bis zur inhaltlichen Leitung eines Projektes. Ein weiteres mögliches Problem für den Usability Engineer ist, dass dem Auftraggeber die Methoden und Verfahren des UE unbekannt sind und keine Bereitschaft vorhanden ist, scheinbaren ‘Mehraufwand’ zu bezahlen. Hinzu kommt oftmals eine gravierende Fehleinschätzung des Auftraggebers über die realen Endkunden (technische Fähigkeiten, Produkterfahrung, Lernfähigkeit, Zeitverfügung, Gebrauchskontext).
Es ist erlaubt, digitale und Kopien in Papierform des ganzen Papers oder Teilen
davon für den persönlichen Gebrauch oder zur Verwendung in Lehrveranstaltungen zu erstellen. Der Verkauf oder gewerbliche Vertrieb ist untersagt. Rückfragen sind zu stellen an den Vorstand des
GC-UPA e.V. (Postfach 80 06 46, 70506 Stuttgart).
Proceedings of the 2nd annual GC-UPA Track, Paderborn, September 2004. Für diejenigen, die die Konferenz verpasst haben: der Tagungsband kann für 30,00 EUR bei
Matthias Peissner bezogen werden.
UE erfüllt Anforderungen des Marktes, die im IT-Management bisher oft zu kurz gekommen sind: Gebrauchstauglichkeit, Realitäts- und Nutzerorientierung. Qualitäten, die darüber hinaus zu differenzierenden Produkteigenschaften werden, wenn sich die Angebote des Wettbewerbs zu ähnlich sind. Hohe Gebrauchstauglichkeit bzw. Gebrauchsfreundlichkeit kann (neben anderen Qualitätsmerkmalen) zum Markenwert und als Unterscheidung gegenüber Konkurrenten genutzt (z.B. Mercedes-Benz, Braun Haushaltsgeräte). Wird die Minimalanforderung Gebrauchstauglichkeit dagegen mißachtet, kommt es zu Desastern wie TollCollect oder dem Internetauftritt der Bundesagentur für Arbeit.
Vermehrt anzutreffen ist grundlegendes Wissen der Beteiligten über die Vorteile und Methoden des UE. Großunternehmen etablieren UE im Rahmen von Qualitätssicherungsmaßnahmen und den Qualitätsansprüchen ihrer (Premium)Marken. Die Rolle eines Usability Engineers wird hier vom Kunden eingefordert. Kleineren Unternehmen hingegen ist es aufgrund der vielfältigen Anforderungen des Tagesgeschäfts selten möglich, eine derart hohe Spezialisierung zu erreichen.
Zwingende Vorgaben des Gesetzgebers für eine höhere Gebrauchstauglichkeit von Produkten sind bisher selten, mit den Ausnahmen der ISO DIN 13407 (einschließlich Vorgaben für die Softwareerstellung) und dem gesetzlichen Vorgehen im Zusammenhang mit Barrierefreiheit (Voigt & Heers, 2004).
Fazit
Projekterfolg und die Etablierung von UE zeigen sich für Geschäftsleitung wie Auftraggeber letztlich am Erfolg der Produkte. Konkret bedeutet dies Kostenreduktion, Minimierung von Folgekosten, Einhaltung von Zeitplänen, erhöhte Wiederbeauftragung, geringere Garantie- und Kulanzkosten, Umsatz- und Gewinnsteigerung. Im Endeffekt geht es für alle Beteiligten um eine erhöhte Kundenzufriedenheit und (mittel- bis langfristig) Kundenbindung, die zu höheren Absätzen und (bei angemessener Preisgestaltung) zu höheren Umsätzen und Gewinnen führen sollte (Mayhew, 1999). In erfolgreichen Projekten zur Interface-Entwicklung sind (ohne andere Tätigkeiten herabwürdigen zu wollen), zwei Schlüsselrollen vorhanden - der Projektmanager und der Usability Engineer. Beide können sich gegenseitig zum Wohle des Projekts unterstützen oder behindern. Allerdings können beide gemeinsam die Basis eines (intern und extern) erfolgreich verlaufenden Projektes bilden, das ein am Markt erfolgreiches Produkt entwickelt.
Referenzen
- Barnum, C., Usability Testing and Research. Longman (2002).
- ISO DIN 13407, Benutzer-orientierte Gestaltung interaktiver Systeme. Beuth (1999).
- DeMarco, T.: Wien wartet auf Dich! Der Faktor Mensch im DV-Management. Hanser (1999).
- Hackos, J. T. & J. C. Redish: User and Task Analysis for Interface Design, Wiley (1998).
- Mayhew, D., The Usability Engineering Lifecycle. Morgan Kaufman (1999).
- Nielsen, J. & Mack, R., Usability Inspection Methods. Wiley (1994).
- Sprenger, R., Vertrauen führt. Campus (2002).
- Wischnewski, E., Modernes Projektmanagement. Vieweg (2001).
- Heers, R., Voigt, S., Gutes Design per Gesetz? Anmerkungen zur Barrierefreiheit in der Informationstechnik. Beitrag im UPA-Track der Konferenz Mensch & Computer, Paderborn, 06.-08. Sept. 2004.
In seinem Beitrag Switchy McLayout: An Adaptive Layout Technique auf der Website A List Apart zeigt Marc van den Dobbelsteen Webdesignern und Projektmanagern, wie die Zukunft des “Web”-Layouts aussehen könnte. Es ist nicht mehr ein Layout für den ‘normalen’, stationären Bildschirm-Leser, sondern die Bereitstellung flexibler Inhalte für Handy, Navigationsgerät, Screen, Sprachausgabe, iPod, PDA etc. etc. [Und nebenbei: natürlich auch für den guten alten Drucker, denn es gibt sie immer noch, die Recken des Gutenberg-Zeitalters, die E-Mail- und Website-Ausdrucker und -Abhefter…] Lesen Sie weiter…