Viele Projektmanager aus der IT kennen dieses Problem: Knappe Ressourcen einerseits, zahlreiche Anforderungen andererseits. Ein Mobilfunkanbieter mit über 120 Millionen Kunden weltweit stand 2007 ebenfalls vor dem Problem, dass die zahlreichen Anforderungen, welche die Abteilungen an die Neu- und Weiterentwicklung der internen IT-Systeme stellten, mit dem vorhanden Budget nicht umgesetzt werden konnten. Unter dem Schlagwort "Rightsizing" wurde deshalb ein Verfahren entwickelt, mit dem Projektmanager und Auftraggeber den Projektinhalt und -umfang an die Ressourcensituation anpassen können. Das Verfahren basiert auf der so genannten Pareto-Regel und wird im Unternehmen als Pareto-Analyse bezeichnet. Diese Analyse wird im Folgenden vorgestellt.

Ausgangslage und Problemstellung

Anfang 2007 nahmen die Controller der IT-Abteilung eine Auswertung vor. Dabei stellten sie fest, dass die Anzahl der neuen Anforderungen, die an die internen IT-Systeme gestellt wurden (Demands), kontinuierlich gestiegen war. Die Zahl der Demands, die im Januar 2007 bereits erfasst waren, ließ auf das gesamte Jahr fortgeschrieben eine weitere, extreme Erhöhung erwarten. Gleichzeitig hatte das Top-Management das Budget für die Neu- und Weiterentwicklung von IT-Systemen gekürzt. Es war somit abzusehen, dass die IT-Abteilung im Jahr 2007 nur einen sehr kleinen Anteil der Demands würde umsetzen können (Bild 1).

Bild 1: Die Controller prognostizierten, dass die Abteilungen immer mehr Demands stellen würden. Die IT-Abteilung würde aber immer weniger Demands realisieren können.

Die Controller der IT standen vor der Aufgabe, die reduzierten Budget- und Personalressourcen und die gestiegenen Anforderungen in Einklang zu bringen und dabei ein möglichst effizientes Ergebnis zu erzielen. Dafür mussten sie ein Verfahren finden, mit dem sich der Umfang einzelner Demands reduzieren ließ, z.B. indem einzelne Funktionsanforderungen fallen gelassen wurden. Dieses Verfahren sollte leicht anzuwenden sein und die Projektteams möglichst wenig belasten.

Als Lösung wurde schließlich ein Verfahren auf Basis der so genannten Pareto-Regel entwickelt und in der deutschen Landesgesellschaft des Mobilfunkanbieters eingeführt. Mit diesem Verfahren ist es möglich, die wichtigsten Funktionsanforderungen von Demands auszuwählen und diese auch umzusetzen. Weniger nutzbringende Funktionsanforderungen werden aussortiert.

Die Pareto-Regel

Die Pareto-Regel, auch 80/20-Regel genannt, ist nach dem italienischen Ökonomen und Soziologen Vilfredo Pareto (1848-1923) benannt. Pareto fand heraus, dass 20% der italienischen Familien über 80% des italienischen Volksvermögens verfügten. Der Ingenieur Joseph M. Juran (*1904) wandte dieses Prinzip auf das Qualitätsmanagement an und prägte den Ausdruck "vital few, useful many". Gemeint sind Sachverhalte wie

• 20% der Kunden bringen einem Unternehmen 80% des Umsatzes.
• 80% der Fehler einer Software sind auf dieselben 20% der Ursachen zurückzuführen.
• In 20% seiner Arbeitszeit erreicht ein Mitarbeiter 80% seiner Ergebnisse.
• usw.

Dabei sind die Zahlen 80 und 20 keine starren Werte. Vielmehr ist gemeint, dass oft ein kleiner Anteil der Ursachen den größten Teil der Wirkung erzeugt. Bei Ressourcenknappheit ist es deshalb sinnvoll, diesen kleinen, wirkungsvollen Anteil zu identifizieren und hierauf die Energien zu konzentrieren. Auf diese Weise lässt sich die Effizienz beträchtlich steigern.

Einbettung in das Vorgehensmodell

Beim Mobilfunkanbieter werden Softwareentwicklungsprojekte nach einem intern entwickelten Vorgehensmodell durchgeführt. Ausgangspunkt ist immer eine Anforderung (Demand), die beispielsweise von einer Fachabteilung (Marketing, Kundenbetreuung usw.) gestellt wird. Ein Demand wird u.a. dann eingebracht, wenn neue Geschäftsprozesse eingeführt und durch die IT unterstützt werden sollen oder wenn es darum geht, bereits bestehende, IT-gestützte Geschäftsprozesse zu erweitern, zu verändern oder zu optimieren. Eine Anforderung kann auch technikgetrieben sein, z.B. um die IT-Architektur zu vereinheitlichen oder Geschäftsprozesse besser zu unterstützen.

Um einen Demand umzusetzen, müssen in einem bzw. in mehreren IT-Systemen Veränderungen oder Ergänzungen vorgenommen werden. Im Unternehmen sind knapp 100 IT-Systeme im Einsatz, die zudem stark miteinander vernetzt sind. Deshalb betrifft eine technische Lösung für eine Anforderung in der Regel mehrere Systeme, so dass ein hoher Koordinations- und Steuerungsaufwand für das Entwicklungsprojekt entsteht. In diesem Fall wird für das Projekt ein eigener Projektmanager abgestellt. Betrifft eine Lösung nur ein einziges System, wird sie unter der Leitung des Systemverantwortlichen erarbeitet.

Die Anforderer (z.B. Fachabteilungen) erfassen alle Demands in einer unternehmensintern entwickelten Software. Jeder Demand muss mehrere Phasen durchlaufen. Dazu gehören "Erstellung eines Fachkonzepts", "Erstellung der Spezifikation" und "Realisierung". Vor jeder Phase schätzt der Projektmanager den Aufwand dafür (z.B. Aufwand für die Erstellung eines Fachkonzepts). Auf Basis dieser Schätzung entscheidet das Gremium, das für die Releaseplanung zuständig ist, ob ein Demand in die nächste Phase gehen darf. Bei einem Ressourcenengpass werden einzelne Demands aussortiert und nicht weiter verfolgt. Im Gremium für die Releaseplanung sind die Bereichsleiter des IT-Controllings sowie aller Fachseiten vertreten.

Feasibility Study

Gibt es bei einem Demand mehrere, konkurrierende Ansätze für eine Lösung oder ist unklar, ob eine Anforderung überhaupt realisierbar ist, erstellt der Projektmanager zunächst eine Vorstudie (Feasibility Study). Ziel ist es hierbei, Lösungen zu identifizieren und…