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