"Software-Projekte schlanker machen"

"In vielen Projekten steht dem administrierenden Projektmanager, der das Controlling und kaufmännische Belange im Auge hat, ein Entwicklerteam gegenüber, das stark Technologie getrieben ist", so Lieber. Die Kunst bestehe darin, alle Beteiligten an der wirtschaftlichen Zielsetzung des Projektes auszurichten.

"Für jede Entscheidung im Projekt muss die Frage nach dem Business-Value gestellt werden, was bis tief in Entwicklerentscheidungen hinein reicht", so Lieber. Nur so könne verhindert werden, dass durch das Scheitern von Entwicklungsprojekten Unternehmen auch ein großer wirtschaftlicher Schaden entsteht.

Schwierige Beziehungen

Doch nicht nur das interne Verhältnis von Projektmanagement und Software-Engineering spiele eine Rolle: schon die Auftraggeber und Fachbereiche würden mit ihren Ausschreibungs- und Pflichtenheftformalismen viel dazu beitragen, den Blick auf den "Business Value" eines Projektes zu verstellen.

Und die Lieferseite würde darauf oft mit technologieorientierten Versprechungen reagieren, ohne das Verhältnis von Technologieauswahl, gegebener Anforderung und wirtschaftlicher Zielsetzung zu hinterfragen. Oft genug stehe auch die technische Komplexität aufgrund von Architekturvorgaben oder Technologiepräferenzen in keiner passenden Relation zum wirtschaftlichen Beitrag der zu entwickelnden Applikation.

"Im schlimmsten Fall zerfallen in solchen Konstellationen Projekte in einen Projektmanagementteil, der die fachliche und kaufmännische Steuerung des Projektes leisten soll und einen inhaltlichen Teil, der die technische Lösung herstellen soll", erläutert Lieber. Nicht selten seien dabei Doppel-Projektmanagements anzutreffen, formalisiert oder informell: ein "fachlicher Projektleiter" und ein "technischer Projektleiter".

Doch derartige komplexe Gebilde tendieren zu innerem Zerfall. Lieber: "Im schlimmsten Fall befriedigt ein fachlicher Projektleiter die formalen Controllingbedürfnisse und läuft einem außer Kontrolle geratenen agilen Entwicklerteam, in dem in Personalunion sämtliche Rollen des Entwicklungsprozesses wahrgenommen werden, hinterher, das seinerseits den Einblick in die kaufmännischen Ziele und Zusammenhänge des ursprünglichen Auftrages und der geforderten Lösung längst verloren hat."

"Lean Projects"

Schlanke Projekte sollen dafür sorgen dass die kaufmännischen Zielsetzungen bei allen Projektbeteiligten im Fokus bleibt. "Die Kernidee dabei ist, dass jede am Geschehen beteiligte "Zelle" mit dem Wissen um die angesprochene wirtschaftliche Zielsetzung des Projektes ausgestattet an die Arbeit geht", weiß Lieber.

Was sind wesentliche Charakteristika von "Lean Projects"? Für Lieber ist der Ausgangspunkt jeder schlanken Projektabwicklung die Konzentration auf das Wesentliche und eigentlich "Wertschöpfende" bei der Festlegung der Anforderungen und geforderten Features.

Dann geht es darum, das Projekt in beherrschbare Teilaufgaben zu zerlegen. Das ist, wie Lieber ausführt, "eine Königsdisziplin" im Projektmanagement und auch in Software-Architektur und Design: "Wesentlich im Zusammenhang mit Lean Projects ist es, die Frage der Beherrschbarkeit (Planbarkeit, Steuerbarkeit) für jede Teilaufgabe gezielt zu stellen und das Ergebnis der Teilung erst zu akzeptieren, wenn diese Frage positiv beantwortet werden kann. Für jede Teilaufgabe ist ein Minimum an Personal einzusetzen, ohne unvereinbare Rollen in Personalunion zu belassen."

Zudem müsse das Projektteam an sein neue Aufgabe mit einem klaren Plan herantreten, in welchen Vorgehensschritten die Lösung spezifiziert, realisiert, getestet und ausgeliefert werden wird. Außerdem können viele Aufgaben im Entwicklungszyklus vom Aufwand her minimiert werden, indem davor liegende Arbeitsschritte so ausgeführt werden, dass sie direkt in spätere einfließen: "Das prominentestes Beispiel an dieser Stelle sind Synergien zwischen Requirements-Engineering und Testen, in dem man die Anforderungsspezifikation am späteren Test ausrichtet, was sowohl für präzisere Spezifikationen sorgt als auch die Testaufwände drastisch reduzieren kann."

Alle diese Charakteristika dienen der ursprünglichen Zielsetzung, die "kaufmännische Frage" allgegenwärtig zu machen, mit anderen Worten also das Projekt beherrschbar zu halten.

www.anecon.at