Schlagwort-Archive: Zertifizierung

Was ist billiger? Ein Mitarbeiter oder eine Zertifizierung?

Gestern stiess ich auf einen wunderbaren Artikel, dessen Lektüre zu vielen Aha-Einsichten führt. Der Artikel trägt den Allerweltstitel: When bad things happen to good projects1 und ist offenbar im Web längst verbreitet, ohne dass ich ein Umdenken im Projektmanagement hätte feststellen könnte.

Er erzählt von einem ERP-Migrationsprojekt bei HP. Es ist schon das sechste dieser Art. Die ersten fünf sind vom immer gleichen Projektteam mit viel Erfolg durchgeführt worden. Diesmal betrifft es die grösste HP-Abteilung, die ISS (Industry Standard Servers). Für alle Fälle hat HP einen Vorrat an Servern angelegt, der dem üblichen Verkaufsvolumen von drei Wochen entspricht. Zusätzlich hat HP eine leere Fabrikhalle so ausgerüstet, dass sie imstande wäre, einen Überlauf an Bestellungen von kundenspezifisch konfigurierter Servern zu produzieren.

Offenbar sah das Konzept der Migration vor, dass das neue System parallel zum alten läuft, zumindest für eine gewisse Übergangsperiode. In dieser Zeit kommen die Bestellungen im alten System an und werden an das neue System übermittelt, das dann die darauf folgenden üblichen ERP-Funktionen ausführt, wie Bedarfsermittlung und Produktionsplanung. Bei der Übermittlung muss das Datenformat konvertiert werden, und da war offenbar ein klitzekleiner Fehler im Datenmapping. Dieser Fehler hat sich in den Tests kaum manifestiert. Erst, als die Sache produktiv geschaltet wurde, blieben einige Bestellungen stecken und wurden vom neuen System nicht weiter verarbeitet. Bei dem Volumen an Servern, die HP in jeder Zeitperiode produzieren muss, sind „einige“ sehr viel. Erboste Kunden riefen bei der Helpline an oder – noch schlimmer – gingen zu Dell oder IBM. HP verlor wegen dieses kleinen IT-Fehlers 160 Millionen Dollars. Ich habe mir folgende Gedanken gemacht:

1. So, wie der Kontext des Projekts – also das Business und die Unternehmenskultur – einen beträchtlichen Einfluss auf das Projekt hat, übt auch ein Projekt Einfluss auf das Business aus, wie bei Eschers zeichnenden Hände2. Offenbar hängt der Einfluss sensitiv von den Anfangsbedingungen ab, denn ein kleiner Fehler im IT-Projekt kann riesengrosse Auswirkungen auf das Business haben.

2. Koch schreibt, dass das Desaster hätte vermieden werden können,

…not by trying to eliminate every possibility for error in a major IT sysetm migration, which is virtually impossible, but by taking a much broader view of the impact that these projects can have on a company’s supply chain

In wie vielen IT-Migrations- und Integrationsprojekten wird der Fokus noch immer ausschliesslich auf technische, terminliche und finanzielle Risiken beschränkt? Natürlich kann man von einem Projektleiter nicht verlangen, dass er sich sowohl um technische Detailfragen als auch um strategische Belange des Gesamtunternehmens kümmert. Im Gegenteil: Einem Projektleiter wird kaum zugestanden, dass er sich in den Projektkontext einmischt. Dafür ist doch das Top Management zuständig. Aber wo bleibt es denn, wenn es gilt, den „broader view of the project’s impact“ zu beurteilen?

3. Das Top Management meint, wenn es seine Projektmanager PMP-zertifiziere, dann habe es seine Hände in Unschuld gewaschen, denn Koch schreibt:

That’s why IT project management has become high art while business contigency planning remains in the Dark Ages

Die Manager mögen ganz einfach ihre Hausaufgaben nicht machen, denn contingency plannig ist eindeutig ihr Bier. Je bedeutender das Projekt ist und je näher am Kunden es ist, desto mehr Engagement ist vom Top Management zu erwarten. Die übliche Abwesenheit des Top Managements in wichtigen Projekten rechtfertigt jedenfalls keine fetten Managerlöhne!

4. Es ist wahrscheinlich auf die Dauer billiger, zusätzliche Ressourcen anzustellen, die das Geschäft von Hand machen, wenn etwas schief geht, als die methodischen Fähigkeiten der Projektmanager bis zum Geht-nicht-mehr zu perfektionieren. Koch schreibt dazu:

In the end, it is riskier for companies to try to protect themselves from glitches in enterprise software projects through ever better IT project management techniques than it is to plan for manual workarounds to get products to customers in case of failures

Immerhin wurde der Rückstau der Bestellungen einige Zeit nicht entdeckt. Dazu schreibt Bill Swanton von der AMR Research (die, die das SCOR-Modell mit entwickelt haben):

It’s (about) having people who are watching what’s happening, able to detect if there’s a problem and working out some simple manual way around it until you are ready to work with the system

5. Schliesslich liegt es an uns Endverbrauchern zu akzeptieren, dass der seriöse Umgang mit Komplexität – d.h. das Verhindern von GAUs – Geld kostet und wir Geiz nicht weiterhin geil finden sollten.

1Koch Christopher. When bad things happen to good projects. 2004.
(http://www.cio.de/801687 und eine pdf-Version bei http://www.webcitation.org/5k978Ejcd)

2http://www.123-zwischenraum.de/escher.html

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