Jack Welch relativiert die Bedeutung des Shareholder Value. Die Financial Times Deutschland spricht von einer Kehrtwende bei General Electric, nachdem Jack Welch stets einer der prominentesten Vertreter war. Er selbst würde diese Einschätzung wahrscheinlich nicht teilen, denn er spricht lediglich davon, dass Ursache und Wirkung vertauscht wurden:

„Genau betrachtet ist Shareholder-Value die blödeste Idee der Welt“, sagte Welch. „Shareholder-Value ist ein Ergebnis, keine Strategie, die wichtigsten Interessensgruppen sind die eigenen Mitarbeiter, die eigenen Kunden und die eigenen Produkte.“

Er kritisiert die auf kurzfristige Gewinne ausgerichtete Sharholder Value-Manie. Nachhaltiges Denken und Handeln führt hingegen zu einem Erfolg für alle Beteiligten (auch die Aktionäre).

Ein Leser-Feedback bestätigt mich in meiner Einschätzung:

Wir setzen seit einiger Zeit zur Verbesserung der Klarheit und Entwicklung der Fachanforderungen ein Tool ein, das sich sehr bewährt. Das ist m.E.

erheblich wichtiger, als ein Testtool, von dem ich – auch nach langen Jahren – je nach SW (die ja heute hochgradig konfigurierbar ist und de facto strukturbildende Wirkungen für Unternehmen und alle damit verbundenen Org-Einheiten hat) nur wenig halte. Es ist nichts schlimmer, als wenn die Fachbereiche nach langwierigen Prozessen der Definition der Fachanforderungen irgendwann selbst nicht mehr wissen, wer was wann und warum angefordert hat und ob und wie diese Anforderung von wem in Absprache mit wem wann geändert worden ist – was ist dann getestet worden – und wie bekomme ich meine Migrationsaufträge? Dann kann ich mir das Testen im Grunde komplett sparen.

In meinem aktuellen Beitrag für das Projektmagazin habe ich u.a. auf die Rolle des Anforderers bei Test und Abnahme hingewiesen. Hierzu passend eine Meldung des CIO-Magazins: Die Deutsche Bank lagert ihr Software-Testing aus und rechtfertigt das mit Prozessorientierung und Industralisierung der IT.

Ein externes Testing ist legitim, darf aber den Anforderer nicht aus seiner Verantwortung für Qualitätssicherung und Abnahme entlassen. Ein IT-Dienstleister mag durchaus die erforderlichen IT-Prozesse für Software-Entwicklung und Test besser beherrschen, aber kann er auch das erforderliche Business-Know How mitbringen? Weiß er, was Banker wünschen?

In der aktuellen Ausgabe des Projektmagazins (Abodienst) findet sich ein Beitrag zum Thema Testmanagement in IT-Projekten. Als Autor des Artikels kann ich die Lektüre natürlich nur empfehlen…

Im ersten Teil  des Beitrags werden die Grundzüge des Testmanagements und der Testorganisation anhand der immer wiederkehrenden gemeinsamen Fragen skizziert, die vor der Durchführung eines Tests zu beantworten sind:

1. Wann wird getestet?
2. Was wird getestet?
3. Wie wird getestet?
4. Wer testet?
5. Womit und wo wird getestet? 

Teil 2 des Beitrags mit einem ausführlichen Excel-Template ist derzeit in der Schlußredaktion.

Danny Quick hat einen lesenswerten Beitrag des Linux-Magazins ausgegraben, in dem versucht wird Methoden und Vorgehen agiler Softwareentwicklung auf Betriebsthemen zu übertragen. Wie bei allen „agilen“ Themen braucht es dafür gleich einen neuen Namen: Agile Software Administration.

Für ITIL/Governance geprägte Welten mag sich das Gedankentum zunächst anarchistisch/revolutionär anhören, letztlich setzt es aber, wie alle agilen Ansätze, auf einer gestärkten Kommunikation und Eigenverantwortung auf – zwei Dinge, die noch keiner Betriebsorganisation geschadet haben.

Über Business Intelligence wurde an dieser Stelle ja schon mehrfach schwadroniert:

#139 Lieber Excel als BI

#140 Zum Stand von BI-Projekten in Deutschland

In Computerwoche und CIO-Magazin finden sich jetzt wieder weitere Beiträge, die mich in meiner Meinung bestärken:

Unzufriedenheit mit Business Intelligence wächst (CIO)

Erfolg von Business Intelligence schwer messbar (CIO)

Noch große Spielräume für Optimierung: Back-Office-Chaos verhindert BI-Erfolge (Computerwoche)

Die besten BI-Werkzeuge sind nutzlos, wenn man nicht weiß, was man tut!

Sven Rimbach erzählt frustriert die Anekdote, wie man zu einem „effektivem“ Testmanagement gelangt:

Der einfachste Weg ist es, die Fehlerdatenbank zu löschen…

Eine wesentliche Aufgabe in IT-Projekten ist häufig die Übersetzerrolle zwischen IT und Business. Und selbst innerhalb dieser beiden Welten gibt es weitere Sub-Welten, denn das Top-Management spricht eine andere Sprache als der Abteilungsleiter oder der Anwender und der CIO tickt anders wie ein Application Manager oder ein Programmierer oder ein Hardware-Techie.

In einem Bericht des CIO-Magazins von den Hamburger IT-Strategietagen wird Rainer Janßen (CIO der Münchener Rück) zitiert, der dieses Übersetzungsdilemma aus seiner Warte als IT-Leiter auf den Punkt bringt:

Meine IT versteht mindestens zehn Sprachen, die aus dem Marketing, dem Controlling, dem Vertrieb und und und.

Oft genug werden IT-Strategien kritisiert und gescheiterte IT-Projekte in der Luft zerrissen, aber Janßen dreht den Spieß einfach um:

Statt immer nur auf die IT zu schimpfen, sich in Selbstmitleid kleinzureden und für alle mitdenken zu wollen, liegt die Ursache für viele Fehlentwicklungen im Business. Warum die IT- der Geschäftsstrategie nicht folgen könne? Ganz klar: „Nur ganz wenige Unternehmen haben überhaupt eine Strategie“, behauptet Janßen. Und zwar eine, die diesen Titel verdient und nicht nur aus der Aussage besteht, dass Umsatz und Gewinn steigen sollen.

Natürlich ist es vielleicht ein bisschen zu einfach, den schwarzen Peter an das Business durchzureichen, Eigenverantwortung hat auch die IT, aber es braucht schließlich beide Seiten!

Travis Anderson hat einen lesenswerten Beitrag über den Einsatz von Activity Based Costing im Projektmanagement (Englisch) verfasst. Die Kostenzuordnung auf Aktivitäten orientiert sich dabei an der Work Breakdown Structure (WBS).

So wohl überlegt die Ausführungen sein mögen, habe ich dennoch meine Bauchschmerzen mit dem Einsatz solcher high sophisticated Methoden im Projektmanagement: Natürlich braucht PM Kostenüberwachung und Kostenschätzungen, je deaillierter die Modelle hierfür sind, desto größer wird allerdings auch der bürokratisch/administrative Aufwand. Je größer dieser Aufwand, umso mehr entfernt sich die Sicht von der Projektrealität. Die Administration will mit Zahlen gefüttert werden, also bekommt sie Zahlen. Nach meiner persönlichen Erfahrung finden sich die vermeintlich ausgefeiltesten PM-Methoden meist dort im Einsatz, wo von Projekten im engeren Sinn gar nicht mehr gesprochen werden kann, wo es eher um regelmäßige Tasks oder Aufgaben geht. Ein dynamisches Projektumfeld braucht hingegen eine gewisse „Hemdsärmligkeit“.

Stefan Hagen kann es nicht lassen und setzt mal wieder Malik in Bezug zu Projektmanagement.

Bin da ganz auf seiner Seite, wie diverse Beiträge auf schlossBlog zeigen:
#99 Malik
#10 Noch einmal zurück zu Malik
#04 Management-Werkzeuge
#03 Was heißt schon Management?