Einführung

Willkommen zum Software Project Master Guide. Die Einführung führt Sie anhand eines Fallbeispiels an die wichtigste Frage heran: Verwalten Sie noch – oder managen Sie schon?

Willkommen!

Hallo und herzlich willkommen bei Software Project Master!

Mein Name ist Jörg Hinrichs und ich bin jetzt schon mehrere Jahrzehnte in der Softwareentwicklung tätig, sowohl als Entwickler als auch als Projektmanager. Während dieser gesamten Zeit habe ich immer wieder erlebt, wie Softwareprojekte trotz bester Absichten und motivierter Mitarbeiter in Schwierigkeiten geraten sind. Dieser Kurs soll Ihnen helfen, die Ursachen für solche Schwierigkeiten zu erkennen und sie rechtzeitig zu adressieren.

Ich bin zutiefst davon überzeugt, dass ein Projektmanager ein Grundverständnis dessen benötigt, was er managen soll. Auch das soll dieser Kurs Ihnen vermitteln: Wie tickt ein Softwareprojekt und was muss ich wissen, um es erfolgreich managen zu können?

Viele IT-Projektmanager glauben, ihre wichtigste Tätigkeit besteht darin, einen Liefertermin einzuhalten und einen dazu passenden Zeitplan aufzustellen. Und natürlich dafür zu sorgen, dass dieser Zeitplan auch eingehalten wird.

Tatsächlich ist der Zeitplan – und damit auch der Liefertermin – eher ein Ergebnis von anderen Faktoren: Der Produktivität des Projektteams, der Qualität der Anforderungen und der daraus resultierenden Genauigkeit der Aufwandsschätzungen sowie weiterer Faktoren.

Diese Faktoren müssen sie kennen und managen – ansonsten leiten sie nicht ihr Projekt, sondern ihr Projekt leitet sie. Dann betreiben sie Symptombekämpfung aber an den eigentlichen Ursachen ändern sie nichts. Und deshalb ist die Gefahr groß, dass ihr Projekt früher oder später gefährlich aus dem Ruder läuft.

Softwareprojekte sind deshalb so schwer zu managen, weil sie mehrere Fertigkeiten erfordern, die man selten zusammen findet:

• Als Projektleiter müssen Sie wissen, wie Softwareentwicklung funktioniert. Denn Sie können nichts effektiv managen, was Sie nicht verstehen. Das kann auch kein noch so gutes Tool oder ein Softwareentwicklungsprozess ersetzen.
• Softwareentwickler sind oft sehr eigene Charaktere und auch nicht immer als Teamplayer bekannt. Wenn Ihr Team neu ist, benötigen Sie u.U. Softskills, um aus mehreren Einzelkämpfern ein Projektteam zu machen. Und manchmal brauchen Sie die auch, wenn Ihr Team sich schon kennt!
• Und nicht zuletzt brauchen Sie auch grundlegende Fertigkeiten im „klassischen“ Projektmanagement: Zeit- und Ressourcenplanung.

Dieser Kurs holt Sie dort ab, wo Sie gerade stehen, egal ob Sie ein Entwickler sind, der jetzt auf einmal ein Projekt leiten soll, oder ob Sie ein Projektleiter sind, der noch nie selbst Software entwickelt hat. Er ist auch für Projektleiter geeignet, die nicht aus dem IT-Umfeld kommen.

Was Sie (nicht) erwartet

Was Sie erwartet...

Dies ist ein Kurs aus der Praxis und für die Praxis. Nicht immer sind die Bedingungen ideal und nicht immer können Sie daran wirkungsvoll etwas ändern. Und Sie haben mit Menschen zu tun, die nett und motiviert, aber genausogut auch kompliziert und anstrengend sein können.

Deshalb habe ich viele Praxisbeispiele in den Kurs integriert. Die meisten davon sind typisch und können Ihnen bei ihrer Arbeit genauso über den Weg laufen.

Was Sie lernen:

• Den Umgang mit Menschen, warum sie häufig seltsame oder störende Dinge tun und was Sie dagegen tun können.
• Eine ganze Reihe Praxis-Tipps, die Ihnen das Leben einfacher machen und einiges an Schwierigkeiten von vornherein vermeiden.
• Informationen über die Dynamik von Softwareprojekten. Auf welche Punkte Sie achten und welche Dinge Sie kontrollieren müssen, damit ihr Projekt kein unerwünschtes Eigenleben entwickelt.

...und was nicht

In diesem Kurs lernen Sie nicht, wie man einen Projektplan aufstellt, wie man Ressourcen verwaltet, was ein kritischer Pfad ist und welche Tools dafür geeignet sind. Für diese Themen gibt es haufenweise gute Kurse, die das mindestens genauso strukturiert und verständlich erklären, wie ich es könnte.

Trotzdem sind diese Kenntnisse Teil des Handwerkszeugs eines Projektmanagers, und wenn Sie sie noch nicht besitzen, sollten Sie das unbedingt nachholen.

Ich werde auch nicht darauf eingehen, welche Prozessmodelle es in der Softwareentwicklung gibt und wo deren Stärken und Schwächen liegen. Nicht, weil ich das nicht interessant finde, sondern weil ich glaube, dass es nur einen sehr begrenzten Einfluss auf den Erfolg eines Softwareprojekts hat.

Es werden immer wieder Prozessmodelle angepriesen (aktuell ist die agile Entwicklung mit diversen Varianten in aller Munde) und es entsteht schnell der Eindruck, dass mit dem richtigen Modell alles von alleine funktioniert. Oder dass Sie nur das richtige Tool einsetzen müssen, um viel produktiver zu werden.

Mit Verlaub: Das ist Blödsinn!

Glauben Sie niemandem, der Ihnen weismachen möchte, dass mit einem neuen Prozessmodell die Produktivität um 20% gesteigert werden kann. Erst einmal müssen Sie das Modell einführen - und dabei sinkt die Produktivität normalerweise, schließlich gibt es eine Lernkurve. Und wenn es dann am Ende 5% mehr Produktivität sind, können Sie schon sehr sehr zufrieden sein. Aber Wunder sollte man sich davon wirklich nicht versprechen.

Fast alle Informationen in diesem Kurs sind unabhängig davon, mit welchem Prozessmodell Sie arbeiten. Wo das nicht der Fall ist, habe ich explizit darauf hingewiesen.

Ein (fiktives) Fallbeispiel

Kick-Off

Hamburg, 26.01.2015 10:00

Stefan betritt den Besprechungsraum. Die anderen beiden Gesprächsteilnehmer sind schon da, Herr Meister aus der Geschäftsleitung von CleverSoft und Markus Redefluss aus dem Vertrieb. Er kommt ohne weitere Umschweife auf den Punkt:

„Hallo Stefan, wie du vielleicht schon mitbekommen hast, haben wir gestern einen neuen Kunden an Land gezogen. Die Präsentation der neuen Software war ein voller Erfolg. Die EfficientBusiness AG möchte aber noch ein zusätzliches Modul, um ihr Beratergeschäft effizient unterstützen zu können.“

Herr Meister übernimmt das Gespräch: „Wir haben gestern bereits erste Rahmenbedingungen für die Entwicklung festlegen können. Der Kunde beginnt mit der Einführung Anfang nächsten Jahres, wir müssen also bis Ende Oktober liefern, damit er noch genügend Zeit für die Vorbereitung hat. Wir wollen einen guten ersten Eindruck hinterlassen und brauchen einen zuverlässigen Mann für dieses Projekt, deswegen sind sie hier!“

„Vielen Dank!“. Stefan fühlt sich geschmeichelt, fragt aber trotzdem weiter: „Was wissen wir denn sonst noch? Hat der Kunde schon gesagt, was genau er sich wünscht?“

„Nein, wir haben da noch keine konkreten Vorgaben“, antwortet Markus, „das wird eine der ersten Aufgaben sein, diese Informationen zu ermitteln.“

Stuttgart, 03.02.2015 18:30

Stefan sitzt müde am Gate B7 des Stuttgarter Flughafens und wartet auf den Flug nach Hamburg. Neben ihm sitzt Andreas, ein Senior-Entwickler, mit dem er schon lange zusammenarbeitet. „Und, was denkst du?“, fragt Stefan ihn.

„War doch nicht schlecht“, sagt Andreas. Ich habe jetzt schon eine viel bessere Vorstellung davon, was der Kunde von uns erwartet. Wir müssen das jetzt noch sortieren und ein paar Feinheiten klären, und dann sollten wir eine gute Grundlage haben, um loszulegen.“

Hamburg, 05.02.2015 09:00

Stefan hat gerade die Vorstellung des Projekts beendet und schaut in die Runde. Drei Entwickler und zwei Tester gehören zu seinem Team. Die Stimmung ist gut und das Projekt sieht machbar aus.

Auf dem Weg

Hamburg, 12.03.2015 10:00

Einmal in der Woche macht Stefan ein kurzes Meeting mit dem Projektteam, heute ist es wieder soweit: „Wie sieht’s in der Entwicklung aus, was macht der Dialog für die Zeiterfassung? Kriegen wir den wie geplant diese Woche durch?“

„Ist so gut wie fertig“, sagt Andreas, „es fehlen nur noch ein paar Kleinigkeiten in der Benutzerführung und dann können wir das nächste Woche in den Test geben.“

Hamburg, 13.03.2015 16:00

Das Statusmeeting mit dem Management ist fast zuende. „Projektstatus: grün“, sagt Stefan gerade, „wir liegen zwar nicht ganz im Plan, aber nachdem wir ein paar Anfangsschwierigkeiten überwunden haben, sehe ich da kein Problem.“ Außerdem hat Stefan ja noch seine Zeitreserve in der Hinterhand, aber das sagt er hier lieber nicht. Manager haben die Angewohnheit, solche Reserven immer sofort zu verplanen!

Halbzeit

Hamburg, 25.05.2015 14:30

„Sehr gute Idee, ich freue mich auf Ihren Besuch!“. Stefan hat gerade mit Herrn Markert gesprochen, dem Projektverantwortlichen beim Kunden. Sie haben vereinbart, dass nächste Woche eine Präsentation der bereits umgesetzten Anforderungen beim Kunden stattfindet. Zum einen, damit der Kunde das beruhigende Gefühl hat, dass sein Projekt tatsächlich vorankommt, zum anderen aber auch, um ein erstes Feedback zu den bisherigen Entwicklungsergebnissen zu bekommen.

Stuttgart, 03.06.2015 16:00

Stefan und Andreas haben gerade die Präsentation der Anwendung beendet. Stefan hat gemischte Gefühle. Das Team hat mit Hochdruck daran gearbeitet, für diesen Termin etwas Vorzeigbares zu liefern. Die Präsentation selbst lief auch nicht schlecht, die Anwendung funktionierte erstaunlich gut, die Atmosphäre war gut, die Mitarbeiter des Kunden waren auch sehr kooperativ. Insgesamt hat Stefan den Eindruck, dass die Stimmung positiv ist.

Aber es hat sich auch herausgestellt, dass einige Bestandteile der Software noch nicht den Ansprüchen des Kunden genügen. Meistens sind es Kleinigkeiten. Es hat sich gezeigt, dass einige Features nicht ausreichend beschrieben waren und nicht so implementiert wurden, wie der Kunde sich das vorgestellt hatte.

Hamburg, 05.06.2015 16:00

„Projektstatus: Gelb!“. Stefan hält nicht viel davon, Dinge schön zu reden. Bisher hatte das Projekt schon einiges von seiner Zeitreserve aufgefressen, teilweise weil Entwicklungen länger dauerten als geplant, teilweise auch weil Teammitglieder stärker als erwartet vom Tagesgeschäft beansprucht wurden. Trotzdem, der Liefertermin war seiner Meinung nach bisher nicht ernsthaft in Gefahr gewesen. Jetzt jedoch sieht das anders aus.

„Was ist die Ursache dafür?“, fragt Herr Meister.„Unsere Präsentation beim Kunden hat gezeigt, dass wir Teile der bisherigen Implementierung ändern müssen“, antwortet Stefan. „Da waren Anforderungen teilweise missverständlich oder nicht vollständig beschrieben. Mit den Erkenntnissen, die wir vorgestern gewonnen haben, ist klar, dass wir das Projekt so nicht erfolgreich weiterführen können.“

Das Management ist natürlich nicht begeistert, aber man versucht trotzdem, das Problem in den Griff zu bekommen. Am Ende einigt man sich darauf, das Projektteam mit einem zusätzlichen externen Entwickler zu verstärken. Stefan ist nicht allzu glücklich mit dieser Lösung, aber er hat auch keine bessere Alternative parat. Am liebsten hätte er einen Entwickler aus der eigenen Firma ergänzt, aber das hat das Management nicht zugelassen.

Probleme über Probleme

Hamburg, 10.08.2015 11:00

Stefan gehen langsam die Ideen aus. Der Projektstatus wird immer kritischer: Seine Zeitreserve ist schon seit einer Weile aufgebraucht, die Entwicklung ist immer noch etwas langsamer als geplant und der neue Mitarbeiter kann sich nicht so produktiv einbringen, wie zunächst gehofft. Er ist ein guter Entwickler, aber er steckt halt nicht so in der Materie drin wie die eigenen langjährigen Teammitglieder. Und dass er nicht von Beginn des Projekts an dabei war, macht die Sache auch nicht einfacher. Schweren Herzens entschließt sich Stefan, Notfallmaßnahmen einzuleiten.

Hamburg, 11.08.2015 11:00

„So wie es aussieht, muss ich den Projektstatus rot vergeben!“, sagt Stefan gerade auf dem Statusmeeting. Da die Situation kritisch ist, hat er den Termin vorgezogen. „Ich sehe im Moment keine Möglichkeit, die Anwendung so wie vom Kunden gewünscht auszuliefern.“

Das hört das Management nicht gerne. Trotzdem wissen sie, dass Schuldzuweisungen und Vorwürfe hier nicht weiterhelfen. „Was schlagen Sie vor?“, fragt Herr Meister.

„Wenn wir den Liefertermin halten wollen, müssen wir Abstriche beim Test machen oder einige Features streichen. Ich weiß, das wird dem Kunden sauer aufstoßen, aber es ist die einzige Möglichkeit, die ich sehe.“

Die nachfolgende Diskussion kann man durchaus als hitzig bezeichnen. Schließlich einigt man sich darauf, eine Kombination aus beiden Maßnahmen durchzuführen: Die meisten Abstriche werden beim Test gemacht, aber gleichzeitig wird man auch auf den Kunden zugehen und ihm die Problematik mitteilen, um das eine oder andere Feature auf ein späteres Release zu verschieben.

Hamburg, 11.08.2015 14:00

In einer eiligst anberaumten Telefonkonferenz hat der Kunde sich dafür entschieden, einige unwichtigere Features zu streichen. Allerdings nicht genug, um den Liefertermin zu halten. Man hat sich deshalb auf eine Terminverschiebung um eine Woche geeinigt.

Der Kunde ist noch nicht hochgradig verärgert, aber Begeisterung sieht anders aus! Dementsprechend angespannt ist auch die Stimmung bei CleverSoft.

Auf der Zielgeraden

Hamburg, 26.10.2015 15:00

Stefan sieht sich die Fehlerstatistiken aus dem Test an und ist nicht glücklich. Die Software ist noch längst nicht so stabil, wie er sich das wünscht, es kommen immer noch reichlich neue Fehler aus dem Test zurück. Die Entwickler tun, was sie können, aber ihre Möglichkeiten sind begrenzt. Und so langsam läuft ihnen die Zeit davon…

Hamburg, 31.10.2015 10:00

Stefan hat Wochenendarbeit angeordnet. Er tut das nicht gerne, aber es ist die einzige Möglichkeit, noch rechtzeitig fertig zu werden und nicht zu riskieren, den Kunden ernsthaft zu verprellen. Er selbst ist auch mit dabei, obwohl es nicht unbedingt notwendig wäre. Seine Arbeit ist weitgehend getan und seine Leute wissen, was sie zu tun haben. Aber er möchte sein Team trotzdem moralisch unterstützen.

Hamburg, 06.11.2015 20:00

Stefan sitzt noch im Büro und trinkt einen von viel zu vielen Kaffees. Die Software wurde gerade an den Kunden ausgeliefert. Pünktlich. Nun ja, pünktlich gemessen an den geänderten Absprachen. Die Geschäftsführung ist zufrieden, der Kunde wohl auch größtenteils.

Aber es hat Kraft gekostet. Tester und Entwickler haben in den letzten beiden Wochen – und auch davor – hart geschuftet. Trotzdem hat die Software nicht die Qualität, die Stefan eigentlich von einem „richtigen“ Release erwartet. Und einmal mehr fragt er sich, wie er solche Projekte in Zukunft besser abwickeln kann…

Warum so viele Softwareprojekte scheitern

Ja, warum?

Natürlich können äußere Umstände eine große Rolle dabei spielen. Aber selbst wenn alle konstruktiv mitarbeiten und ihr Bestes geben kann ein Softwareprojekt scheitern. Nun würde man das Projekt in unserer kleinen Beispielgeschichte sicher nicht als gescheitert ansehen. Aber optimal gelaufen ist es auch nicht. Der Liefertermin musste verschoben werden, der Kunde hat nicht alle gewünschten Features bekommen und die Qualität der Software hätte auch besser sein können.

Man kann auch nicht sagen, dass Stefan grundlegende Fehler gemacht hat. Ganz im Gegenteil, er hat sogar eine Menge richtig gemacht:

• Er hat frühzeitig die Abstimmung mit dem Kunden gesucht, sowohl zu Beginn als auch während der Entwicklung.
• Er hat rechtzeitig das eigene Management informiert, als die Situation kritisch wurde und sofort Maßnahmen ergriffen.

Trotzdem wurde es zum Schluss noch einmal richtig eng. Und Stefan ist damit nicht allein. Sehr viele Softwareprojekte laufen nach diesem Muster ab. Viele scheitern noch viel spektakulärer: Teilweise wird die Software gar nicht mehr produziert oder die Planungswerte für Zeit und Budget werden weit überschritten.

Muss das so sein? Oder andersherum gefragt: Was kann man dagegen tun?

Noch einmal: Sie können nicht etwas managen, was sie nicht verstehen!

Bezogen auf Softwareprojekte bedeutet das: Sie müssen verstehen, wie Softwareentwicklung funktioniert. Ansonsten können sie als Projektmanager ein Ass sein: Irgendwann kommt ein Blitz aus heiterem Himmel und sie werden nicht einmal wissen, was sie getroffen hat!

Genau darum geht es bei Software Project Master: Zu verstehen, wie ihr Projekt wirklich tickt – und damit meine ich nicht Termine und Ressourcen – und es dann aktiv zu managen!

„Aber das tue ich doch schon?“, wenden sie jetzt vielleicht ein. Ja, sie managen Termine, Budget und Leute, das, was ein Projektmanager klassischerweise macht. Das, was man im Projektmanagementseminar gelernt hat. Verstehen Sie mich nicht falsch, das ist auch ein Bestandteil der Arbeit eines Projektmanagers. Aber es ist nicht der einzige. Solange sie nicht darüber hinausgehen, sind sie eigentlich eher ein Projektverwalter als ein Projektmanager. Und daraus ergibt sich ein gravierender Nachteil: Sie reagieren eher auf äußere Umstände, statt diese selbst zu gestalten.

Managen sie Anforderungen, managen sie Softwarearchitektur und Tests, managen Sie Teamdynamik: Und sie werden sich in einer völlig neuen Welt wiederfinden. Einer sehr spannenden Welt. Und einer, die ihnen viel mehr Möglichkeiten für ein wirklich erfolgreiches Softwareprojekt bietet.

Das PM-Dreieck: Mythos und Wahrheit

Dies ist das berühmte Projektmanagement-Dreieck.

Falls sie es noch nicht kennen: Zeit, Kosten und Qualität wollen miteinander in Einklang gebracht werden und die landläufige Meinung dazu lautet: Such dir zwei Größen aus und frag lieber nicht nach der dritten.

Wenn es schnell gehen muss und nichts kosten darf, dann kommt eben nicht die beste Qualität am Ende heraus. Das erleben wir jeden Tag und es gilt nicht nur für Softwareentwicklung.

Richtig? Richtig!

Also, was ist falsch an diesem Dreieck?

Nehmen wir mal an, sie wollen eine qualitativ richtig gute Software abliefern. Und sie haben genügend Zeit – ich weiß, das gibt es nirgendwo, aber nehmen wir es trotzdem mal an.

Nach dem PM-Dreieck bedeutet das: Sie optimieren Qualität und Kosten und „opfern“ dafür die Zeit. Aber so funktioniert das nicht. Mehr Zeit in einem Softwareprojekt heißt immer automatisch mehr Kosten. Ich kann nicht bei gleicher Zusammensetzung des Projektteams die Zeit vergrößern, um eine bessere Qualität zu erreichen – und gleichzeitig die Kosten senken!

Zeit und Kosten bedingen sich immer gegenseitig: Wenn ich die Zeit verlängere, steigen automatisch meine Kosten – und umgekehrt.

Außerdem gibt es Projekte, die doppelt so lange brauchen und dreimal so viel kosten wie geplant. Und die Qualität ist am Ende trotzdem katastrophal. Das gibt es in der Softwareentwicklung zur Genüge und nicht nur dann, wenn die äußeren Umstände ein erfolgreiches Projekt praktisch unmöglich machen.

Fassen wir noch einmal zusammen:

• Zeit und Kosten kann man nicht unabhängig voneinander betrachten. Und auch nicht unabhängig voneinander optimieren. Sie gehören zusammen.
• Die Faktoren, die ein Projekt wirklich beeinflussen, sind nicht im PM-Dreieck enthalten. Sonst dürfte es so viele gescheiterte Projekte eigentlich nicht geben.

Ich will nicht sagen, dass das PM-Dreieck grundlegend falsch ist. Aber als Orientierungshilfe für den Softwareprojektmanager finde ich es nicht geeignet.

Vom PM-Dreieck zur SPM-Pyramide

Trotzdem, das PM-Dreieck ist eine gute Ausgangsbasis für weitere Ideen. Wir werden es ein wenig modifizieren und dann ein Instrument erhalten, was wirklich gut für Softwareentwicklung geeignet ist: Die Software Project Master Pyramide!

Als erstes streichen wir die Kosten rechts unten und ersetzen sie durch das Projektteam.

Warum das Team als dritte Größe eine zentrale Rolle spielt, werde ich gleich noch genauer erläutern. Zunächst mal konzentrieren wir uns auf den Ausgangspunkt für unser Softwareprojekt. Was ist das Erste, was in einem Projekt feststeht, bevor überhaupt klar ist, wie die Software aussehen soll?

Genau, der Liefertermin!

Der Liefertermin ist zwar meistens von außen vorgegeben, aber eine ihrer zentralen Aufgaben als Projektmanager besteht darin zu prüfen, ob bzw. wie der Termin eingehalten werden kann. Dazu benötigen wir zwei Informationen:

• Wir müssen wissen, wie hoch der Aufwand für die Herstellung der Software ist. Das lässt sich zu Beginn des Projektes nur schätzen. Je genauer diese Schätzungen jedoch sind, desto stabiler wird auch ihre Projektplanung.
• Wir benötigen die Produktivität des Projektteams. Wie viel Funktionalität (=Features) kann das Team pro Zeiteinheit umsetzen? Wir lassen zunächst mal die Frage außer Acht, wie man Funktionalität bzw. Features misst, das ist für die grundlegende Betrachtung nicht wichtig.

Mit diesen beiden Informationen können Sie ausrechnen, wie lange das Team für die Herstellung der Software benötigt und ob das mit dem vorgesehenen Liefertermin zusammenpasst. Wenn nicht, wird von ihnen erwartet, geeignete Maßnahmen zu treffen.

Der Projektverwalter

Bis hierhin haben wir eigentlich nur Informationen gesammelt und sie in einen Projektplan eingearbeitet. Das ist auch genau das, was sie in einem herkömmlichen Projektmanagement-Kurs lernen.

Aber das reicht nicht, um ein Softwareprojekt erfolgreich managen zu können. Warum?

• Häufig sind die Aufwandsschätzungen nicht zuverlässig. Aufwände werden aus verschiedensten Gründen unterschätzt.
• Zusätzliche Funktionalitäten (und damit auch Aufwände) werden erst im Verlauf des Projekts erkennbar.
• Die Produktivität des Teams ist nicht so hoch, wie erwartet.

Dafür kann es unterschiedlichste Gründe geben und erst, wenn wir diese Gründe erkennen und beseitigen, können wir ein Softwareprojekt wirklich managen. Ansonsten verwalten wir das Projekt nur, aber wir haben kaum Einfluss darauf, ob es erfolgreich ist oder nicht. Wir reagieren dann lediglich auf die äußeren Umstände: Nicht wir managen das Projekt, das Projekt managt uns!

Qualität managen!

Ein ganz zentraler Faktor für die Zuverlässigkeit der Aufwandsschätzungen ist die Qualität der Software. Was bedeutet das konkret?

Es beginnt mit den Anforderungen. Sie müssen genau die Informationen beinhalten, die Entwickler und Tester später benötigen, um die Features richtig umzusetzen. Je besser eine Anforderung beschrieben ist, desto besser lässt sie sich auch schätzen.

Damit meine ich nicht den Umfang der Beschreibung! Ein detailliertes Fachkonzept ist natürlich fast immer besser als eine knappe Feature Liste, aber auch hier gilt: Qualität vor Quantität. Wenn die wesentlichen Informationen fehlen, dann nützt mir auch eine ausführliche Beschreibung nichts.

Die (technische) Qualität der Software, ihre Architektur im Großen wie im Kleinen, ist ebenfalls wichtig. Das macht sich häufig erst im Verlauf des Projekts bemerkbar, wenn Code nicht nur neu geschrieben, sondern auch verändert oder gewartet werden muss. Oder weil im Test ein Fehler gefunden wurde und die Beseitigung aufgrund des Aufbaus der Software länger dauert als notwendig.

Apropos Test. Nur allzu oft fällt er unter den Tisch, weil am Ende nicht mehr genug Zeit da ist. Aber auch wenn er stattfindet, kann er nur so gut wie die Vorgaben sein. Und wenn deren Qualität nicht ausreicht, werden die wichtigen Dinge unzureichend oder gar nicht getestet.

Das Team managen!

Als Projektmanager müssen sie die Produktivität ihres Teams ermitteln, um zu überprüfen, ob sie noch im Zeitplan sind oder nicht. Und sie müssen das regelmäßig während der Projektlaufzeit tun. Denn die Produktivität ist nicht konstant. Sie hängt davon ab, wie es den Mitgliedern ihres Teams geht und wie sie zurechtkommen.

Beispielsweise kann die Produktivität sinken, weil:

• Konflikte innerhalb des Teams auftauchen. Mitarbeiter kommen nicht miteinander aus, vielleicht können sie sich nicht leiden oder es gibt Rivalitäten.
• Die Motivation erheblich sinkt. Es werden zu viele Überstunden gemacht oder man hat das Gefühl man kommt nicht voran. Vielleicht sind auch Teammitglieder der Meinung, dass ihre Arbeit nicht ausreichend gewürdigt wird.
• Mitarbeiter melden sich überdurchschnittlich häufig krank. Oft sind die Ursachen dafür in den obengenannten Themen zu finden.

Achten sie darauf, dass die Zusammenarbeit im Team reibungslos verläuft und dass die Stimmung gut ist. Dann bleibt die Produktivität konstant auf einem hohen Niveau und ihre Planung ist stabil.

Wissen: Die Grundlage für Qualität und Produktivität

Hier geht es um technisches Wissen über den Aufbau und die Entwicklung der Software und fachliches Wissen über die Arbeitsweise der Anwendung und die dahinterliegende Thematik.

Fehlendes technisches Wissen macht sie langsamer, weil es sich negativ auf ihre Produktivität auswirkt. Aber meistens erkennen sie das recht früh und können ihre Planung daran anpassen.

Fehlendes fachliches Wissen bringt ihr Projekt um. Warum? Weil sie es immer viel zu spät merken. Nämlich dann, wenn sie die ganz große Runde bis zum Kunden gedreht haben.

Sie müssen also dafür sorgen, dass in ihrem Team ausreichend Wissen vorhanden ist. Wenn sie Glück haben, ist dieses Wissen schon von vornherein da, und sie brauchen nichts weiter zu tun. Wenn nicht, dann müssen sie es managen. Das kann in Form von Schulungen sein, die ihre Teammitglieder erhalten oder durch externe Teammitglieder, die das Wissen mitbringen. Aber sie müssen es zur Verfügung stellen oder sie bringen ihr Projekt in Gefahr.

Die vollständige SPM-Pyramide sieht dann folgendermaßen aus:

Vom Projektverwalter zum Projektmanager

Verwalten Sie noch oder managen Sie schon?

Was ist der Unterschied zwischen einem Projektverwalter und einem Projektmanager? Ich benutze diese beiden Begriffe im Kontext der SPM-Pyramide:

Ein Projektverwalter agiert in der oberen Hälfte der Pyramide. Er legt Meilensteine fest, stellt Zeitpläne auf und stellt sicher, dass die erforderlichen Ressourcen zur Verfügung stehen.

Ein Projektmanager agiert in der unteren Hälfte der Pyramide. Er managt Qualität, Wissen und das Team und stellt auf diese Weise sicher, dass das Projekt nicht aus dem Ruder läuft.

Kurz gesagt: Ein Projektverwalter kümmert sich um den organisatorischen Teil des Projekts, ein Projektmanager konzentriert sich auf die inhaltlichen Schwerpunkte.

Verstehen Sie mich nicht falsch: Beides ist notwendig! Aber wenn Sie ein Softwareprojekt nur verwalten und nicht managen, dann ist die Gefahr des Scheiterns viel größer.

Wie man ein Softwareprojekt konkret managt - und welche Aspekte dafür relevant sind - ist Inhalt dieses Kurses:

• Wie etabliere ich eine gesunde Fehlerkultur?
• Wie stelle ich als Projektleiter eine vertrauensvolle Atmosphäre her, in der ich wichtige Informationen frühzeitig erhalte?
• Wie kann ich die Qualität von Anforderungen bewerten, sogar dann, wenn ich nicht tief im Thema drinstecke?
• Wie erhalte ich verlässliche Aufwandsschätzungen?
• Wie messe ich die Produktivität von Teams?
• Wie erreiche ich eine Parallelisierung von Test und Entwicklung?
• Wie messe ich den Fortschritt des Projekts?
• Welche Rolle spielen Previews mit dem Kunden?