Schlagwort-Archive: Ziele

Sind wir zielgeil?

Wir leben in einer zielgeilen Zeit. Die zeitgenössische Management- und Komplexitätsbewältigungsliteratur suggeriert uns, dass alles ein Ziel haben muss. Aber wie können wir Ziele haben, wenn wir nicht wissen, was uns die Zukunft bringt? Oft wird unter einer komplexen Situation eine intransparente, vernetzte und ungewisse Situation verstanden. Wie können wir Ziele haben, wenn die Zukunft ungewiss ist?
In einem Blog habe ich folgende Geschichte gelesen:

Die Schüler fragen ihren Meister: »Wie also reist man zu seinem Ziel?« Der Meister antwortet: »Man reist nicht. Es ist eine Reise ohne Entfernung. Hört auf zu reisen, und ihr seid da.« Die Schüler können das nicht verstehen, und so erklärt der Meister: »Solange man unterwegs zu einem Ziel ist, kann man an einem Traum festhalten. Wenn man anhält, steht man vor der Wirklichkeit.« Verwirrt fragen die Schüler weiter: »Wie sollen wir uns je verändern, wenn wir keine Ziele oder Träume haben?« »Stellt euch der Wirklichkeit, und alles wird sich spontan verändern.«1

Letzte Woche habe ich mich mit einem Autor eines Buches über Komplexitätsmanagement unterhalten2. Er ist mit mir einig, dass Ziele nicht von Anfang an vollständig und starr sind, sondern sich mit dem Handeln konkretisieren. Er erzählte mir, dass sie vor einiger Zeit einen Industrieauftrag zum Themenkreis „Ziele, Zielbildung, Zielverfolgung“ erhalten haben. Für mich bedeutet das, dass sich Manager vorstellen, man müsse nur Ziele haben und diese verfolgen, damit alles so werde, wie man es sich wünsche. Ein reichlich naiver Gedanke, der alle Kenntnisse über das Funktionieren unseres Geistes und die Enstehung komplexer Systeme ignoriert3.

1 Dieter Halbach, Wie geschieht Veränderung?

2 Reither, F. Komplexitätsmanagement – Denken und Handeln in komplexen Situationen. Gerling Akademie Verlag.
München 1997

3 z.B. Addor, P. Projektdynamik – Komplexität im Alltag. Reinhold Liebig Verlag, Frauenfeld 2010

Was kann ich dafür, wenn die Welt so widerbrostig ist?

In seinem immer interessanten PM-Blog hat Stefan Hagen kürzlich eine Blitzumfrage veröffentlicht. Interessierte Personen können in einer gegebenen Liste von typischen Herausforderungen im Projektmanagement anklicken, welche vier aus ihrer Sicht die grössten sind. Selbstverständlich sagt die Rangfolge nichts über die tatsächlichen Schwierigkeiten im Projektmanagement aus, sondern nur etwas über die Verbreitung der Meinungen. Dass wieder einmal unklare Ziele und Aufträge als grösste Herausforderung die Reihenfolge anführt, bedeutet ja nur, dass die meisten Befragten dieser Meinung sind, nicht dass es sich tatsächlich um die grösste Herausforderung handelt. Die Landkarte ist ja nicht die Landschaft.

Marcel Altherr von MaibornWolff meint in einer perönlichen Mitteilung:

Fast alle Projekte, die ich im Laufe der Zeit angetroffen habe, gehen von einem tayloristischen Idealbild aus. Die Bilder im Kopf zum Thema Projekt sind Vorstellungen aus der industriellen Welt. Projekte haben einen wohldefinierten Anfang und ein ebensolches Ende und das zwischendrin kann man exakt planen, in kleine Einzelteile zerlegen und dann in der Ausführung ganz einfach wieder zusammensetzen. Das Bild im Kopf ist das einer geordneten und kontrollierbaren Welt. Die Wirkung dieser Bilder ist so stark, dass sogar wider alle realweltlichen Erfahrungen mit Projekten daran festgehalten wird.

Das trifft den Nagel auf den Kopf. Weil die Welt in den Köpfen der Umfrageteilnehmer geordnet und kontrollierbar ist, müssen Ziele und Anforderungen von Anfang an abschliessend und vollständig definiert werden können – glauben sie. Das widerspricht zwar den „realweltlichen Erfahrungen“, ist aber als verikale Flucht im Sinne Dörners besonders hilfreich, wenn die Realität allzu widerspenstig wird1. Man beschäftigt sich lieber mit einem idealisierten Abbild der Realität. Wir haben eine derartige Angst vor Kontrollverlust, dass wir rigide am tayloristischen Idealbild von Projekten festhalten und sagen:

Mein Plan[, der wohldefinierte Ziele und vollständige Anforderungen annimmt,] ist prima, was kann ich dafür, wenn die Wirklichkeit so widerborstig ist?2

Ziele und Anforderungen sind nun mal grundsätzlich erst dann definierbar, wenn das Projekt abgeschlossen ist3. Projekte scheitern nicht an dieser Tatsache, sondern daran, dass die Damen und Herren Projektleiter sie nicht akzeptieren wollen.

1Dörner, D. Die Logik des Misslingens – Strategisches Denken in komplexen Situationen. rororo Taschenbücher, Rowohlt. Reinbek b. Hamburg, 2003

2Strohschneider, S. und von der Weth, R. Ja, mach nur einen Plan. Pannen und Fehlschläge – Ursachen, Beispiele, Lösungen. Verlag Hans Huber. Bern 2001. S.42

3Addor, P. Projektdynamik – Komplexität im Alltag. S. 203ff. Verlag Reinhold Liebig, Frauenfeld 2010

Zertifiziert für das Unmögliche: Anforderungen formulieren

Wie wir aus dem Artikel Von nichts kommt nichts wissen, lassen sich Anforderungen nie abschliessend formulieren. Das macht die Projektarbeit so schwierig. Neuerdings gibt es schon wieder eine Zertifizierung, nämlich diejenige des Certified Requirements Engineers. Dieses Zertifikat gibt es gleich in drei Stufen, einen Foundation, einen Advanced und einen Expert Level. Und wieder steht eine ganze Industrie dahinter, mit vielen teuren Kursangeboten, Büchern und Instituten. Wieder werden Best Practices vermittelt, aber wenig systemische Erkenntnisse. Als ob Wissen durch pauken zustande käme. Die armen Projektleiter! Sie müssen nicht nur

  • das PM Book of Knowledge vom PMI
  • das CISM Review Technical Information Manual nach COBIT
  • den Spice ISO/IEC TR 15504-6 Standard
  • den CMMI SEI Technical Report CMU/SEI-2006-TR-008
  • das Buch Managing Successful Projects with PRINCE2 und
  • die IT Infrastructure Library, beides vom Office of Government Commerce

auswendig lernen, sondern jetzt auch noch Klaus Pohls Kompendium über Requirements Engineering1, um ihre Projekte genauso erfolglos wie bis anhin durchziehen zu dürfen. Und anstatt wirklich etwas zu lernen, müssen sie die Zertifikate für viel Geld periodisch erneuern lassen.
Das Problem der Anforderungen steht am Anfang eines jeden Projekts. Zu Beginn hat jeder Auftraggeber nur eine vage Vorstellung von dem, was er eigentlich will. Die Vorstellungen verdichten sich zu Bedürfnissen, während er sich mit dem Projektgegenstand befasst. Aus den Bedürfnissen schliesslich kondensieren konkrete Anforderungen. Die Emergenz von Anforderungen ist ein Prozess der Selbstorganisation und kann nicht einfach „engineert“ werden. Meist muss das Projekt schon so gut wie fertig sein, wenn die Anforderungen beginnen, sich heraus zu kristallisieren. Ein Auftraggeber wünscht sich nicht nur Funktionen des zu bauenden Systems. Er will mit dem System vielleicht auch noch andere Ziele erreichen, wie z.B. strategische oder marketingbezogene Ziele. Beispielsweise sind die Hauptfunktionen eines Scannerkassensystems sowohl Schnittstelle zum Inventory System, um die Regale stets gefüllt zu halten als auch die Beschleunigung des Inkassovorgangs, um einen grösseren Durchsatz zu erreichen. Aber das Management könnte mit dem Kassensystem auch weitere Ziele verfolgen, wie z.B. Expansion des Marktanteils durch Einführung einer innovativen Technologie vor der Konkurrenz oder – umgekehrt – Schutz des Marktanteils durch Aufrücken zur Konkurrenz, die diese Technologie bereits früher eingeführt hat. Es ist nun denkbar, dass die Konkurrenz Scannerkassensysteme neu bewertet, noch während das Integrationsprojekt läuft. In diesem Fall muss der Auftraggeber seine Anforderung wieder neu definieren. Das geht aber nicht so schnell, wie es Pohl und seine Mannen gerne sehen möchten2. Die Gegebenheiten eines Marktes sind heute derart volatil, dass es unmöglich ist, die Ziele eines Migrations- oder Integrationsprojektes, das mehrere Monate dauert, zu Beginn abschliessend zu formulieren.

Weiter ist zu bedenken, dass softwareintensive Systeme heute immer weniger dediziert entwickelt werden. Im Allgemeinen werden sie in irgend einem Competence Center eines Herstellers entwickelt und dann auf dem Markt angeboten. Siehe z.B. ERP- und Bankenlösungen oder Softswitch Kommunikationslösungen, etc. Solche Systeme werden als Standardsoftware angeboten und in Integrations- und Migrationsprojekten ausgerollt. Kürzlich musste ich für eine Kommunikationsfirma ein Voice Messaging System migrieren. Das neue System wurde irgendwo in der französischen Provinz entwickelt. Das Migrationsprojekt dauerte ein Jahr und kostete (inkl. HW und SW) ungefähr eine Mio Euro. Natürlich hatte der Kunde Anforderungen. Vielleicht wurden diese durch das System unterstützt, vielleicht war die Entwicklung bereit, kleinere Anpassungen zu machen. „Zum Glück“ wies das System Fehler auf. So konnte der Kunde beim Fixen der Mängel gleich noch ein paar seiner Wünsche mit einfliessen lassen.

Schliesslich weise ich immer wieder darauf hin, dass ein Auftraggeber erst dann die richtigen Fragen stellen und sie klar formulieren kann, wenn er sich eine Weile mit einem System beschäftigt und genügend Wissen über das System hat. Erst im Verlauf des Projekts ist der Auftraggeber in der Lage zu definieren, was er in bezug auf das System eigentlich gerne hätte. Das ist beim Bau eines Einfamilienhauses so und das ist bei der Integration eines komplexen Systems in die IT- und Prozesslandschaft eines Grossunternehmens so. Sogar noch dann, wenn das System bereits eingeführt ist und produktiv läuft wird der Betreiber immer wieder neue Anforderungen und Ausbauwünsche haben.

Anforderungen und Ziele von komplexen softwareintensiven Systemen lassen sich heute wegen der Volatiliät des Marktes nicht mehr abschliessend formulieren und definieren. Theorien des Projektmanagements und seines Umfeldes, wie Requirement Analysis, werden immer noch konventionell, auf einem linearen Ursache-Wirkungsdenken beruhend und ohne Berücksichtigung elementarster systemtheoretischer Tatsachen konzipiert. „Best Practices“ gilt als chic obwohl es reines Frequencey Gambling ist und als das immer wieder zu fehlerhaften Entwicklungen führte3

1Klaus Pohl. Requirements Engineering – Grundlagen, Prinzipien, Techniken. Dpunkt Verlag, Heidelberg 2008 und
Klaus Pohl. Basiswissen Requirements Engineering – Aus- und Weiterbildung zum Certified Professional für Requirements Engineering – Foundation Level nach IREB-Standard.

2Frank Houdek, Klaus Pohl: Analyzing Requirements Engineering Processes: A Case Study. DEXA Workshop 2000: 983-990

3Harald Schaub. Menschliches Versagen. Universität Bamberg. 2000
Beim Frequency Gambling wir diejenige Maßnahme ergriffen, die in den bisherigen (oder ähnlichen) Situationen am erfolgreichsten war. Dies muss nicht notwendigerweise falsch sein, doch kann diese Strategie in neuen, unbekannten Situationen schwerwiegende Konsequenzen mit sich bringen. Innovation und Flexibilität sind dem „frequency-gambler“ Fremdwörter, so dass neuartige Systemeigenschaften gar nicht in Rechnung gestellt werden