Kategorie-Archiv: IT-Governance

Ich lese gerade das Buch „PRINCE2(TM) 2009 Edition – Das Taschenbuch“ von Bert Hedeman und Ron Seegers.
Dort steht folgende interessante Passage, die ich hier zur Diskussion stellen möchte (S. 155f):

Ein Body of Knowledge (BoK) stellt das gesammelte Wissen zu einem bestimmten Bereich dar.
Zwischen einem gesammelten Wissen (Body of Knowledge BoK) und PRlNCE2 bestehen diverse Unterschiede (siehe Tabelle am Ende des Textes).
Beispiele für Bodies of Knowledge sind:

• Kompetenzbaseline (Competency Baseline(s)) der IPMA;
• Projektmanagement BoK (PMBOK) des PMI;
• Body of Knowledge (APMBOK) der APM.

PRlNCE2 gibt vor was zu tun ist, wann und durch wen. Die Bodies of Knowledge geben in erster Linie Auskunft bezüglich der Techniken, also wie etwas gemacht werden kann. Wenn Organisationen bereits mit einem bestimmten BOK arbeiten, ist bei der Anpassung von PRlNCE2 darauf zu achten, dass eine einheitliche Terminologie und eine eindeutige Zuordnung der Managementprodukte definiert wird.

–Ende des ersten Zitates–

Und hier die Tabelle:

— Ende des zweiten Zitates

Mir scheint der PMI-BOK in den Punkten b. und c. nicht zutreffend beschrieben zu sein.

Der PMBOK enthält eine vollständige Liste von Projektmanagementprozessen und richtet sich nicht nur an die Rolle des Projektmanagers. Letzteres scheint mir eher auf IPMA zuzutreffen; IPMA fokussiert auf die persönlichen Fertigkeiten (Punkt d) und bildet die Prozesse über diesen Weg ab (man könnte es auch als Umweg sehen). Meine These also: PRINCE2 stellt hier einen Anspruch im Vergleich zu PMI, der so nicht zutrifft. Es geht mir nicht um einen Streit der Schulen. Aber wir sollten auch ein korrektes Bild haben, was wir von wo am besten verwenden können.

Am 16.1.2012 berichtete DI Helmut Berger als Vertreter der PMA im Normungsgremium über den Stand und die geplante weitere Vorgehensweise zur Erstellung der ISO 21500, einer internationalen Norm für Projektmanagement, die analoge Ansätze (z.B. BS 6079 und DIN 69901) ablösen soll.

Einige interessante Aussagen hier als Information:

• Die Norm schreibt keine Best Practices fest
• Die Norm ist nicht als Zertifizierungsgrundlage gedacht, sollte aber als Bestandteil von Projektverträgen genutzt werden können.
• Die Struktur folgt weitgehend dem Prozessmodell von PMI (analog ja auch PRINCE2), der Kompetenzansatz von IPMA wird auf hohem Abstraktionsniveau genannt, aber nicht weiter ausgeführt.
• Deutschland plant keine Übersetzung, das österreichische Normungsinstitut will aber eine deutsche Fassung herausbringen.
• Man rechnet mit einer Verabschiedung der Norm Ende 2012.

Es gibt bereits eine Vorabversion der Norm zum Kauf bei http://www.on-norm.at. Man muss nach ISO 21500 suchen, für satte € 48,- kann man diese dann downloaden.

Mein persönlicher Kommentar: Den Wert dieser Norm konnte ich aus dem Vortrag nicht herauslesen. Was bringen AGBs, die kein Soll definieren? Was bringt ein Standard, wenn man weder Personen noch Organisationen danach zertifizieren kann?

Nachtrag: Nun gibt es die Norm in ihrer Endversion und der Preis ist auf ca. € 111,- gestiegen. Der Wert leider nicht. Es ist eine Sammlung von Begriffen, mit denen keine Praxisanleitung verbunden ist. Als einzigen Wert könnte man sehen, dass das Prozessmodell von PMI damit einen besonderen Status erhalten hat. Der IPMA-Standard kommt mit einem lapidaren Absatz vor, indem die Kompetenzbereiche genannt werden, wie sie IPMA als Eye of Competence definiert. Eine magere Ausbeute.

Ich lese gerade die neue Auflage von Wolfgangs Kellers Buch „IT-Unternehmensarchitektur„, wesentlich erweitert, teilweise komplett neu geschrieben. Empfehle ich hiermit nachdrücklich.

Eine Passage hat mich dabei amüsiert, aber gleichzeitig an gewisse Projektsituationen erinnert, wahrscheinlich geht es vielen anderen auch so. Im Buch auf Seite 276f., nachfolgend das Zitat (kursiv):

Spätestens seit dem Film »Denn sie wissen nicht, was sie tun« (Regie: Nicholas Ray; Darsteller: James Dean, Nathalie Wood, Dennis Hopper, USA 1955) wissen wir, was ein »Chicken Race“ ist: Zwei Autos fahren gegen einen Abgrund, und wer zuerst aussteigt, ist ein Feigling. Warum sie das machen? »What else can we do?«

Eine typische derartige Situation in Unternehmen betrifft IT-Projekte:   Fachbereich und IT wissen, dass sie ein Projekt nicht rechtzeitig fertig bekommen werden. Jeder wartet, bis der andere zugibt, dass er die Termine nicht halten kann. Und wer es zuerst zugibt, hat verloren. Auf diese Weise kommen Terminverschiebungen erst in letzter Minute auf den Tisch.

Das ist eine typische Herausforderung im Projektcontrolling und die Lösung dieses Problems erfordert immer wieder einen Balanceakt auf dem Hochseil.

Ich lese seit einiger Zeit (mit Unterbrechungen) das Buch „Making Sense of Agile Project Management – Balancing Control and Agility“ von Charles G. Cobb. Allein der Titel ist ja schon Programm, der Autor löst den postulierten Anspruch allerdings auch wirklich ein.

Ein ausführlicheres Zitat der Einleitung zum Kapitel I soll die Grundgedanken illustrieren:

… it is essential to overcome some popular miscon­ceptions associated with „agile“ such as:

• „Agile“ is an undisciplined process of simply writing code with no plan­ning, no documentation, and no disciplined methodology for how it is done.
• The only way to be „agile“ is to implement pure agile methodologies such as Scrum.
• At one end of the spectrum is the most extreme forms of traditional plan­driven, control-oriented methodologies like the waterfall process; at the other end are pure agile approaches like Scrum, with nothing in between.

The truth is that:

• Implementing an „agile“ process requires just as much or more discipline as traditional approaches such as the Waterfall model, but it’s a different kind of discipline. Rather than relying on rigidly defined and prescriptive methodologies, agile approaches rely much more heavily on the training and skill of collaborative, cross-functional teams to adapt the methodology to the problem that they are attempting to solve.
• Pure forms of agile like Scrum have many advantages, but they can be very difficult to implement and aren’t necessarily appropriate for all business environments and projects. Many businesses require a balance of control and agility, which may be more suited to a hybrid approach.
• There are many ways companies can become „more agile“ without nec­essarily going to the extreme of a pure agile approach, but it may take a more sophisticated approach to blend together the right combination of agile and non-agile methodologies and practices to craft a customized approach. The best approach is always to fit the methodology and practices to the business environment and problem you’re trying to solve rather than force-fitting a project to a particular methodology, but doing that requires a much higher level of skill and it requires developing an understanding of the methodologies and practices at a deeper level.

There are many companies that are locked into very cumbersome and bureau­cratic traditional methodologies that don’t see how to improve that situation, because it can be so difficult to move to a pure agile approach and there is also a fear of losing control in the process. Part I of the book is designed to help companies understand some of principles behind agile approaches in order to see how to develop an appropriate strategy for how to integrate more agile practices into the way they do business.

Genau darauf kommt es an: Die Idee verstehen (dazu ein früherer Blog-Eintrag etwas ausführlicher), die Prinzipien auf die eigene spezifische Situation intelligent anwenden und einen kontinuierlichen Verbesserungsprozess einleiten. Man hüte sich – aber nicht nur hier – vor Fundamentalismus und Perfektionismus und man sollte nicht mutlos sein.

Man weiß seit Adam Smith, dass Spezialisierung zu einer signifikanten Effizienzsteigerung führt und daher eine arbeitsteilige Volkswirtschaft um ein Vielfaches produktiver ist. Ebenso profitieren Unternehmen davon, sich auf ihr Kerngeschäft zu konzentrieren und Leistungsbereiche, die nicht zu ihrer Kernkompetenz gehören, von entsprechenden Spezialisten zuzukaufen. Die Kostensenkungen in der Industrie waren durchwegs mit massiver Auslagerung von bisher intern erbrachten Leistungen verbunden. So ist z.B. die Fertigungstiefe der Automobilindustrie in den letzten 20 Jahren von um ca. 1/3 auf ca. 25 % gesunken. Dabei wurde auch Lehrgeld gezahlt, aber der Kostensenkungseffekt ist unbestritten. Wenn ein solches Unternehmen bisher intern erbrachte Leistungen zukauft, werden diese zwar zuzüglich Umsatzsteuer verrechnet, das erhöht allerdings die Kosten nicht.
Ganz anders verhält es sich, wenn man Gleiches in der öffentlichen Verwaltung tut. Betriebswirtschaftlich sinnvolle Maßnahmen, z.B. Ausgliederung eines Shared Service Center in Form einer GmbH oder die gänzliche oder teilweise Beauftragung externer Dienstleister (z.B. Outsourcing, Outtasking) führen im Vergleich zu einer Erbringung dieser Leistungen mit eigenem Personal zu einer Mehrbelastung der Budgets durch die dadurch entstehende USt-Pflicht. Denn Bund, Länder und Gemeinden sind nicht zum Vorsteuerabzug berechtigt.
Die einfachste Lösung wäre, Rechnungen an Gebietskörperschaften und sinnvollerweise auch Sozialversicherungen und ähnliche öffentliche Organisationen künftig ohne Umsatzsteuer zu stellen (wie es ja beim Reversed Charge Verfahren schon üblich ist). Dem steht allerdings entgegen, dass gemäß EU-Recht die Umsatzsteuerpflicht nicht auf den Leistungsempfänger abgestellt werden darf.

Rechtsnormen können auch geändert werden. Da dies aber sicher zu lange dauert, um noch rechtzeitig wirksam zu werden, stünde es der öffentlichen Verwaltung in Österreich auch frei, ein internes Verfahren zur Entlastung der einzelnen Dienststellen von Umsatzsteuerzahlungen für bezogene Waren und Dienstleistungen zu etablieren. Das ist im Rahmen der Budgetgesetze zu regeln, ist steuerlich völlig aufkommensneutral und wäre eine konstruktive Maßnahme im Rahmen einer ohnehin fälligen Neuordnung des Finanzausgleichs.

Dieser Vorschlag liegt schon seit 2010 am Tisch, siehe dazu Seite 10-11 der ADV-Mitteilungen. Die gerade in Diskussion befindliche IT-Konsolidierung mit einer Konzentration der IT-Agenden des Bundes bei der BRZ GmbH würde dadurch leichter umsetzbar. Anstatt eigenes Personal mit allen damit verbundenen Kosten und Inflexibilitäten aufzubauen, könnte die BRZ GmbH als Generalunternehmer Leistungen von Spezialisten am Markt integrieren, ohne dass es für die Kunden einen Unterschied macht, ob die Leistungen mit eigenem Personal der BRZ GmbH (diese sind heute schon von der Umsatzsteuer befreit) oder von geeigneten Subunternehmern erbracht wird. Nebenbei wäre es auch eine Maßnahme zur Konjunkturbelebung.