Schlagwort-Archive: Anforderungen

Ob Sie wollen oder nicht: es kommt auf das Selbe heraus

In einem Kommentar zu meinem Blogeintrag vom 22. Juni Was kann ich dafür, wenn die Welt so widerbrostig ist? hat Gustavo el Geranie geschrieben, dass ein Projekt

… nur dann erfolgreich abgeschlossen werden [kann], wenn ich vor dem Projekt grob (und im Projekt in einer frühen Phase detaillierter) die Ziele, das Budget und die Qualität definiere.

Vielleicht liegt es ja daran, dass die meisten Projekte eben nicht erfolgreich abgeschlossen werden können, weil die Ziele meistens unklar, das Budget fast immer falsch berechnet und die Ressourcen für eine angemessene Qualität oft nicht vorhanden sind.

Nun, natürlich hat Gustavo recht. Ziele sollten so konkret wie möglich festgeschrieben sein. Der Auftraggeber sowie das Projektteam sollten eine gemeinsame Vision des Ziels entwickeln. (Detail-)Ziele und Anforderungen können jedoch nie mit 100% Genauigkeit definiert werden; wahrscheinlich nicht einmal mit 75% Genauigkeit. Diese Tatsache ist in der Tat nicht auf eine tayloristische Projektsicht der Projektleiter zurückzuführen. Es ist so etwas wie ein Naturgesetz. Was ich behauptete war, dass die Vorstellung, Ziele und Anforderungen seien vor Projektbeginn exakt definierbar, auf eine althergebrachte und überholte Denkweise zurück zu führen ist.

Gustavo schreibt, dass Geld immer noch ein Thema sei. Recht hat er. Die meisten Projekte brauchen doppelt so lange und verschlingen doppelt so viel Geld, wie sie den Auftraggebern verkauft wurden. Man hat dann einfach zwei Möglichkeiten:

1. Sie verkaufen das Projekt mit einer Laufzeit von t Wochen zum Preis von X Euro. Das Projekt ist nach 2t Wochen abgeschlossen und hat 2X Euro gekostet. Es gibt rote Köpfe, wüste Beleidigungen und viel Ärger. Doch schnell haben die Buchhalter die 2X Euro verbucht und der Ärger ist vergessen, denn das nächste Projekt steht an.

2. Sie verkaufen das Projekt mit einer Laufzeit von 2t Wochen zum Preis von 2X Euro. Das Projekt ist nach 2t Wochen abgeschlossen und hat 2X Euro gekostet. Alle sind zufrieden und können kompetent das nächste Projekt in Angriff nehmen.
Natürlich liegt die Wahl nicht in der Kompetenz des Projektleiters, sondern des Auftraggebers. Und die meisten haben eine leicht masochistische Ader.

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

Projekte scheitern am Top-Management

Unter dem Titel Verhalten des Linienführungskräfte im Projektmanagement veröffentlichte Dr. Stefan Hagen in seinem pm-blog eine interessante Liste mit 10 häufigen Managementfehler1. Der zweite und elfte Eintrag der Liste lautet

Die Projektteams werden direkt oder indirekt gezwungen, den Best-Case zu planen. Wenn dieser dann nicht eintritt, wird das Team oder der/die Leiter/in verantwortlich gemacht

Das ist leider nur allzu wahr. Allerdings handelt es sich um ein einfaches Gefangenendilemma, aus dem es noch immer kein Entkommen gibt. Wenn das Unternehmen das Projekt gewinnen will, muss es ein attraktives Angebot machen. Da man heute Attraktivität mit „billig“ oder gar „gratis“ verwechselt, erhält derjenige mit dem niedrigsten Preisangebot den Zuschlag. Daher bietet der Verkäufer das Projekt 10% unter dem Preis an, der der Projektleiter gerechnet hat, nachdem ihm der Verkäufer sagte, er soll nur den best-case rechnen.

Ein weiterer Eintrag der Liste heisst:

Unklare Aufträge, kaum klare Zielvorgaben

Das ist meines Erachtens kein Fehler. Ich nenne das unterspezifizierte Initialkonditionen2. Stellen Sie sich vor, alle Wissensspeicher (Bücher, Web, etc.) sind auf einmal weg. Nur das Wissen in den Köpfen der Menschen existiert noch, und Sie hätten den Auftrag, innerhalb einer kurzen Zeit ein Lexikon zu schreiben. Sie müssen aufschreiben, was Ihnen in den Sinn kommt. Na, was glauben Sie, wie vollständig die erste Auflage Ihres Lexikons würde? Es ist äusserst schwierig, sich etwas aus den Fingern zu saugen, wo noch nichts da ist. Das Wissen, was man will, bildet sich erst im Verlauf des Projekts. Ein Projekt ist eine Wissensgenerierungsmaschine.

Folgendes ist ein Fehler, der schlicht auf Ignoranz beruht:

Die Ressourcen werden bewusst permanent überlastet

Manager meinen, sie müssten ihre Ressourcen immer zu 100% auslasten. Dabei wird aber das Unternehmen höchst ineffizient, wie schon Elyahu Goldratt bewies3. Stellen Sie sich vor, Sie hätte nur zwei Mitarbeiter. Der erste erledigt eine Arbeit in 5 Minuten, der zweite braucht zur Weiterverarbeitung 10 Minuten. Was glauben Sie, was passiert, wenn beide zu 100% ausgelastet werden? Das Unternehmen wird schnell seine Tore schliessen und die Bilanz deponieren. Natürlich darf in diesem Beispiel die erste Ressource stets nur zu 50% ausgelastet sein. Im Alltag, und vor allem wenn Wissen verarbeitet wird, ist die Sache natürlich nicht so eindeutig. Aber dennoch lässt sich mit ein wenig Nachdenken verstehen, dass Leute nicht zu 100% ausgelastet werden dürfen, wenn die Zusammenarbeit effizient sein soll.

Stefan Hagens Lösungsansätze können mit „aktive Managementawareness“ zusammen gefasst werden.
Die besten Erfahrungen habe ich dort gemacht, wo periodisch unkomplizierte Steeringboards stattgefunden haben, die aus Mitgliedern des Top-Managements bestanden. Als Projektleiter konnte ich meine Sorgen auf den Tisch legen und direkt mit dem höchsten Chef besprechen. Dieses Vorgehen hat mindestens zwei Voraussetzungen:

  1. Der Top-Manager muss die Projektleiter kennen und mit ihnen schon mal ein Bier getrunken haben.
  2. Die Unternehmenskultur muss so sein, dass ich Probleme auch dann beklagen kann, wenn mein direkter Vorgesetzte anwesend ist

Die beiden Voraussetzungen sind leider ziemlich anspruchsvoll.

1Hagen, S. Verhalten der Linienführungskräfte im Projektmanagement. pm-Blog, 29. April 2010.
http://pm-blog.com/2010/04/29/verhalten-der-linienfuhrungskrafte/

2Addor, P. Projektdynamik – Komplexität im Alltag. S. 151. Reinhold Liebig Verlag. Frauenfeld 2010

3Goldratt, E. & Cox, J. Das Ziel. Campus Verlag. Frankfurt a.M. 2008

Bedürfnisse – Wünsche – Funktionen – Anforderungen

Der Anlass für ein neues System sind immer Wünsche und Bedürfnisse, die jemand hat. Man hat z.B. das Bedürfnis mit jemandem zu sprechen, wo immer man sich befindet. Also kauft man sich ein Mobiltelefon. Wenn man dieses eine Weile gebraucht hat wünscht man sich, man könne die am meisten gebrauchten Nummern speichern. Also kauft man sich ein Mobiltelefon mit Speicher. Nach einer Weile wünscht man sich, die Leute, die einem anrufen, könnten eine Nachricht hinterlassen, wenn man den Ruf nicht beantworten konnte. Also abonniert man eine Voice Mailbox. Dann sieht man jemand, der mit dem Mobiltelefon Musik hört oder ein Spiel macht. Also hat man plötzlich den Wunsch, ebenfalls mit dem Mobiltelefon Musik hören zu können, obwohl man von alleine gar nie auf diesen Wunsch gekommen wäre. Etc., etc.

  • Bedürfnisse sind zunächst diffus und allgemein. Sie haben folgende Eigenschaften:
  • Bedürfnisse können sich sowohl auf operative als auch auf strategische Funktionen beziehen
  • Bedürfnisse können nicht scharf formuliert werden
  • Bedürfnisse sind mehr Gefühl als Wissen und können daher nur eingeschränkt kommuniziert werden
  • Man ist sich zu keinem Zeitpunkt allen Bedürfnissen bewusst
  • Bedürfnisse entstehen während man sich mit dem System beschäftigt

Hat man sich lange genug mit dem System beschäftigt, dann werden einem die Bedürfnisse bewusst und man kann sie als Anforderungen formulieren. Dies geschieht aber meistens erst im Verlauf oder gar gegen Ende des Projekts. Anforderungen werden als Funktionen spezifiziert. Auch Eigenschaften eines Systems können als Funktionen formuliert werden. So sind z.B. die räumlichen Masse eines Autos eine Funktion, wenn es darum geht, das Auto in eine schmale Garage einzuparkieren.
Andreas Ninck et al. unterscheiden in Systemik – Vernetztes Denken in komplexen Situationen1 funktionale von nicht funktionalen Zielen. Nicht funktionale Ziele sind nach Ninck z.B. Wartbarkeits- oder Erweiterbarkeitsanforderungen. Aber auch die Wartbarkeit kann man als Funktionen spezifizieren. Z.B. ist die Forderung nach einer Backup-Funktion eine Wartbarkeitsanforderung. Soll ein System ausbaufähig sein, dann muss es Funktionen geben, um zusätzliches Memory oder eine zweite CPU zu erkennen, etc. Ein systemtheoretisch zentrales Thema ist die Lebensfähigkeit eines Systems. Auch diese lässt sich über autopoietische Funktionen diskutieren. Stafford Beer meint, dass ein System sich an seine sich stetig verändernde Umgebung anpassen können muss, damit von Lebensfähigkeit gesprochen werden kann. Es muss seine Identität bewahren, Erfahrungen aufnehmen und verwerten können, und es muss lernen und sich weiterentwickeln können. Das sind alles Systemfunktionen. Beer definiert in seinem Viable Systems Model fünf Systemlevel. Das sind Funktionskomplexe des Unternehmenssystems2. Man kann sich trefflich streiten, ob es nun noch etwas anderes gibt, als funktionale Ziele. Wir wollen zumindest in diesem Blog davon ausgehen, als seien alle Bedürfnisse und Ziele als Funktionen formulierbar.

Definitionen:

  • Bedürfnisse, Wünsche: (erstes) vages Bild mit diffusen Strukturen
  • Funktionen: möglichst klar strukturierte Bedürfnisse; möglicherweise können sich mehrere Funktionen überlappen
  • Anforderungen: Katalog von priorisierten Funktionen (muss, wenn möglich, kann, nice to have, etc.)

1Andreas Ninck, Leo Bürki, Roland Hungerbühler, Heinrich Mühlemann. Systemik – Vernetztes Denken in komplexen Situationen. Verlag Industrielle Organisation. Zürich 2004.

2Malik Management Zentrum. Das Modell Lebensfähiger Systeme (Stafford Beer). St. Gallen, 2006

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