Group: IT-Connection

In unserem letzten Newsletter (http://www.expeso.de/newsletter) fasste Andreas Stankewitz seine persönlichen Projekt-Management-Essentials für ein gelungenes Projekt zusammen. Den Schlüssel zum Projekterfolg sieht er dabei im Anforderungsmanagement.

Ihre Meinung dazu würde mich interessieren.

Herzliche Grüße
Markus Roth



Projekt-Management-Essentials - Software-Entwicklung gelingt!
Andreas Stankewitz

Am Anfang eines jeden Projekts steht der Kunde – sechs Aspekte bilden den Schlüssel für erfolgreiches Anforderungsmanagement im gelungenen Projekt.


Verantwortung

Die Verantwortung des Projektleiters ist, sein Team dahin zu führen, dass genau das gemacht wird, was vom Kunden gebraucht wird. Der Bedarf des Kunden bestimmt das Ziel. Kursbestimmung ist Kapitänssache - Anforderungsmanagement das Steuerrad. Der Projektmanager wird zum Projektleiter.


Kommunikation

Anforderungen entsprechen der Kundensicht auf das zu erstellende System. Das Aufstellen von Anforderungen ist ein Lernprozess aller Beteiligten, dem bis hin zur Abnahme Raum gegeben werden muss. Unmittelbar genutzte Lernerfahrungen tragen zum Erfolg bei. Dafür brauchen Entwickler und Kunden direkten Kontakt. Der erfolgreiche Projektleiter ist ein Kommunikationsstifter.


Verwaltung

Anforderungsmanager und entsprechende Software können die administrativen Aspekte des Anforderungsmanagement unterstützen, dürfen die Kommunikation aber nicht behindern. Lieber eine übersichtliche Anforderungstabelle gemeinsam mit dem Kunden erstellen und pflegen, als den leidenschaftslosen Gebrauch einer Datenbank-Software zu erzwingen.


Prioritäten

Die richtige Priorisierung der Anforderungen ist wesentlich. Im gesunden Projekt werden alle Anforderungen der Priorität A (KO-Kriterien) und Priorität B (Mindest-Kundenerwartung) umgesetzt und einige der Priorität C Anforderungen (Nice to have). Letztere vor allem, damit das Resultat den Kunden und Entwicklern Spaß macht. Spaß an der Sache erhöht die Effizienz. Im Krisenprojekt wird absoluter Fokus auf die Prio-A Anforderungen gelegt.


Controlling

Erfolgreiches Controlling (engl. „to control“ = „steuern“ !) durch den Projektleiter orientiert sich an den Anforderungen. Oft lassen sich Anforderungen dedizierten Entwicklungsaufgaben zuordnen. Dann kann eine Sequenz der Umsetzung mit dem Kunden vereinbart werden (Scrum-Prinzip). Bei komplexeren Anforderungen muss der Projektleiter ein klares und detailliertes Bild von deren Umsetzung haben und diese mit den Entwicklern auf der Detailebene verfolgen, damit die Arbeit nicht „aus dem Ruder“ läuft.


Qualität

Am Ende ist das Projekt erfolgreich, wenn die umgesetzten Anforderungen dem Bedarf des Kunden entsprechen. Qualität geht vor Quantität. Selbst wenn im Sturm ein Teil der Ladung verloren geht: das Schiff läuft im Hafen ein.

Software-Entwicklung gelingt!

Hallo Herr Roth,

scheinbar mag niemand Hiweise geben. Ich möchte ein wenig beitragen und provozieren im Sinne einer Diskussion. Grundlegend halte ich die Hinweise für nützlich für Anfänger (sorry). Vom Projekterfolg aber weit entfernt, da das Spannungsdreieck Anforderungserfüllung hinsichtlich Qualität (Anforderungen und fehlerfreie Umsetzung), Termineinhaltung und Kosten nicht erfüllt wird. Näheres unten.

> Verantwortung
 
Die Verantwortung des Projektleiters ist, sein Team dahin zu führen, dass genau das gemacht wird, was vom Kunden gebraucht wird. Der Bedarf des Kunden bestimmt das Ziel. Kursbestimmung ist Kapitänssache - Anforderungsmanagement das Steuerrad. Der Projektmanager wird zum Projektleiter.
welcher Projektleiter? in der Praxis gibt es einen auf Fach- (=Kunden)ebene und einen auf IT Ebene. Diese beiden tragen die Verantwortung, oben genannten Spannungsverhältnis partnerschaftlich zu balancieren.

Der Projektleiter auf IT Seite (habe mal Ihr Profil kurz angesehen und Sie dort eingeordnet) hat dann zusätzlich die Verantwortung, "sein Team" in Richtung der Erfüllung der vereinbarten Ergebnisse zu führen. Der Projektleiter auf Fachebene hat bei den Anforderungen auch Datenschutz, Archivierung, Compliance ... Aufgaben zu berücksichtigen (kann man anders scheniden, aber klare Regeln(!!) sind notwendig, um späteren Streit zu vermeiden.
 
Kommunikation
 
Anforderungen entsprechen der Kundensicht auf das zu erstellende System. Das Aufstellen von Anforderungen ist ein Lernprozess aller Beteiligten, dem bis hin zur Abnahme Raum gegeben werden muss. Unmittelbar genutzte Lernerfahrungen tragen zum Erfolg bei. Dafür brauchen Entwickler und Kunden direkten Kontakt. Der erfolgreiche Projektleiter ist ein Kommunikationsstifter.
ja, wichtig! Es müssen aber immer Ergebnisse aus der Kommunikation (neue/veränderte Anforderungen) dem Spiegel Wirkung auf Zeit und Kosten unterzogen werden ...
 
Verwaltung
 
Anforderungsmanager und entsprechende Software können die administrativen Aspekte des Anforderungsmanagement unterstützen, dürfen die Kommunikation aber nicht behindern. Lieber eine übersichtliche Anforderungstabelle gemeinsam mit dem Kunden erstellen und pflegen, als den leidenschaftslosen Gebrauch einer Datenbank-Software zu erzwingen.
die Überschrift: autsch. Inhalte m.E. weniger wichtig: a fool with a tool is still a fool. Systematik und Überblick sind aber esssentiell.
 
Prioritäten
 
Die richtige Priorisierung der Anforderungen ist wesentlich. Im gesunden Projekt werden alle Anforderungen der Priorität A (KO-Kriterien) und Priorität B (Mindest-Kundenerwartung) umgesetzt und einige der Priorität C Anforderungen (Nice to have). Letztere vor allem, damit das Resultat den Kunden und Entwicklern Spaß macht. Spaß an der Sache erhöht die Effizienz. Im Krisenprojekt wird absoluter Fokus auf die Prio-A Anforderungen gelegt.
... richtig, aber: wer hat diese Verantwortung und was sind die Kriterien? M.E. s. Verantwortung. Resultat kann auch z.B. sein: in Startversion Anforderungen x, y, z, im Release bevor Rollout müssen zusätzlich dabei sein... mit klaren Terminen und Kosten
 
Controlling
 
Erfolgreiches Controlling (engl. „to control“ = „steuern“ !) durch den Projektleiter orientiert sich an den Anforderungen. Oft lassen sich Anforderungen dedizierten Entwicklungsaufgaben zuordnen. Dann kann eine Sequenz der Umsetzung mit dem Kunden vereinbart werden (Scrum-Prinzip). Bei komplexeren Anforderungen muss der Projektleiter ein klares und detailliertes Bild von deren Umsetzung haben und diese mit den Entwicklern auf der Detailebene verfolgen, damit die Arbeit nicht „aus dem Ruder“ läuft.
nein, s. Verantwortung
 
Qualität
 
Am Ende ist das Projekt erfolgreich, wenn die umgesetzten Anforderungen dem Bedarf des Kunden entsprechen. Qualität geht vor Quantität. Selbst wenn im Sturm ein Teil der Ladung verloren geht: das Schiff läuft im Hafen ein.... wenn Anforderungen abgestimmte Leistungen auch zu Preisen und Terminen umfasst

damit Softwareentwicklung gelingt. In Time und in Budget und partnerschaftlich!

Lassen Sie mich dabei noch auf einem leider immer noch verbreiteten Vergleich zu Produktionsprozessen in der Industrie eingehen: die Softwarefabrik. Softwareentwicklung entspricht definitiv nicht der Produktion von z.B. Autos, sondern der Entwicklungsabteilung. Benötigt eine ausführliche Anforderungsanalyse, time to market Berücksichtigung und der Preis des evtl. individuellen Produkts entscheidet mit über den Markterfolg. Das sich im Entwicklungszeitraum die Martanforderungen im Entwicklungszeitraum permanant ändern, ist systemimmanent (und in den Guidelines enthalten)

bin gespannt, ob insbesondere das letzte statement zur Diskussion beiträgt ;-)

Grüsse
T. Dettmer

Hallo Herr Dettmer,

vielen Dank für Ihre Nachricht.

Sie haben natürlich Recht. Unser Artikel ist nicht geeignet, sämtliche bisherige Literatur / Seminare / Zertifikate zum Thema Anforderungsmanagement über Bord zu werfen. Gerade auch das von Ihnen genannte Spannungsdreieck Features / Kosten / Termine muss beachtet werden.

Der Artikel ist vielleicht eher ein Plädoyer, sich nochmals die Kernpunkte der Anforderungsanalyse kurz und prägnant bewusst zu machen, und an der ein oder anderen Stelle auch mal das Klammern an starre Prozesse in Frage zu stellen.


Sicher ist der Artikel auch ein Plädoyer für ein agiles Vorgehen in Projekten.

Dem Kunden wird versprochen, dass er all seine Prio A und (mehr oder weniger) all seine Prio B Features für ein gewisses Entgelt in einer gewissen Zeit erhält. Dann wird iterativ entwickelt. In kurzen Zyklen von z.B. 4 bis 8 Wochen werden immer die als nächstes wichtigsten Punkte umgesetzt und ausgeliefert. So erhält der Auftraggeber sehr früh eine brauchbare Software, die mit jeder Iteration reifer wird.

Hier kommt vielleicht der Einwand, dass dann aber nicht unbedingt alle Anforderungen umgesetzt werden.
Ja, das ist so. Eventuell fallen einige Prio C Features hinten runter.

Aber wiegt der Vorteil, auch im Worst-Case zumindest eine tatsächlich funktionierende Software mit den wichtigsten Features zu haben, das Risiko nicht mehr als auf?

Ein Projekt ist immer ein Risiko, für den Auftraggeber als auch den Auftragnehmer. Im klassischen Werkvertragsverhältnis auf einem definierten Leistungsumfang zu beharren bringt auch nichts, wenn durch den Streit zwischen Auftraggeber und Auftragnehmer das gesamte Projekt deutlich verzögert wird. Oft ist der Schaden durch fehlerhafte Software oder einen verspäteten Markteintritt, sehr hoch.

Im Projekt ist gegenseitiges Vertrauen unerlässlich. Eventuell kann dies in ersten kleinen Projekten gewonnen werden.

Herzliche Grüße

Markus Roth

Hallo Herr N

der letzte Abschnitt war kein Plädoyer für agile SW Entwicklung. Aber: hängt immer davon ab, was man darunter versteht: Laufende Anpassung an sich ändernde Bedingungen, neue Erkenntnisse etc und damit evtl. Umpriorisierung, evtl auch Termin- und Preisanpassung gehören sicher zum modernen Management.

Problematisch werden diese, wenn die Änderungen und Ihre Konsequenzen dann im closed shop bei der Entwicklung festgelegt werden (wir hatten doch eine klare A, B, C Priorisierung), ohne dass dem Auftraggeber (Fachseite, Business) deutlich klar transparent und bewusst gemacht wird sowie möglichst schriftlich fixiert, auf welche ursprünglich geforderten Dinge er in Konsequenz gänzlich oder für eine Zeit und evtl Vermeidung eines höheren Preises verzichten muss.

Gegen agile SW Entwicklung argumentiere ich, weil dies häufig (m.E. falsch) verstanden wird als Methode ohne solide Grundarchitektur Balkone und subsysteme zusammen zu stöpseln. Dies zieht bei grösseren Themen immensen Aufwand nach sich, um alle Schnittstellen und das Zusammenwirken des großen Ganzen auch später im Betrieb im Blick zu behalten. Und die Fähigkeit, später im Betrieb auch noch auf sich ändernde Prozesse und Organisationsstrukturen mit vertretbarem Aufwand schnell zu reagieren, wird reduziert.

Ich denke bei der Argumentation an große Unternehmen/Unternehmensgruppen. Darauf zielt m.E. auch das V-Modell, während richtig (systematisch gelebte) agile Entwicklung m.E. eher auf Klein- bis Mittelstand zielen.

Zitieren war unerwünscht, daher die merkwürdige Anrede.

Grüsse
T. Dettmer

Agile Softwareentwicklung ist in Großprojekten bedingt einsetzbar .

Was ist ein Großprojekt ?
Was sind die Kriterien die ein Großprojekt bestimmen?

Was ist agile Softwareentwicklung?

Letztendlich nutze ich in der Praxis die Elemente der Vorgehensmodelle, die ich für geeignet halte.

Die agile Softwareentwicklung bietet da einige "neue" Verhaltensweisen die unabhängig von Projektarten und Größen einzusetzen sind.

Aus meiner Erfahrung kommt die Anforderungsanalyse meist zu kurz, u.a. weil das Management keine Vorstellung davon hat, wie hoch die Folgekosten ungeklärter Anforderungen sind.

Da aber das Projektreview oft den Namen nicht verdient den es hat "Etikettenschwindel", wird weiter so gearbeitet wie vorher.

Letztendlich stehen die Projektbeteiligten mit ihren unterschiedlichen Interessen sehr oft unter einem ungesunden Druck (Existenzangst, Überarbeitung etc) dieser wirkt sich natürlich auch aus und beeinflusst das Ergebnis.

In Softwarehäusern erlebe ich zunehmend, dass ein gemeinsames Ziel fehlt, es gibt weniger Begeisterung und Teamgeist - die Unternehmensgründer scheinen in die Jahre zu kommen.

Aber ich erlebe es auch anders - Softwarehäuser und Projekte die Engagement haben, Persönlichkeit, Teams die lernen wollen und Anspruch an Ihre Arbeitsweise haben.

... also ein Frage der Motivation mit einer Mischung aus Methodenkompetenz , Projekterfahrung, Kritikfähigkeit und Spass

Viele Grüße aus Frankfurt Andreas Barthel