Martin Fowler hat eine Antwort. Er beschreibt ein Projekt, dass auf genau diese Weise als Festpreis vereinbart wurde:

Slowly but steadily the changes ate up the buffer. After about six months or so the changes had used up the buffer completely. We’d been quite open with Nebbiolo during this whole time, so they weren’t surprised when we told them that we couldn’t afford to eat the cost of the changes any more. During that time we’d collaborated closely with Nebbiolo and they’d grown to trust us. We had no problem finding more money, indeed it took another half million to cover the requirements changes that were needed before we delivered.

At the end of all this Nebbiolo agreed that the fixed scope approach was a mirage, and we would do future projects together using a more flexible charging scheme.

Es gibt zwei Dinge die notwendig sind, damit das ganze funktioniert:

1. Vertrauen. Das Team muss es schaffen das Vertrauen des Kunden zu gewinnen, zu verdienen. Und dies schafft ThoughtWorks durch Offenheit und entgegenkommen.
   

   We [.. ] didn’t charge the client for the change

   Aber damit das funktioniert braucht es etwas anderes:

2. Ein hochgradig fähiges Team, denn nur dadurch, konnte ThoughtWorks mit einem Preis antreten, der günstiger war als der, der Konkurenz und dennoch 50% Puffer enthielt:
   

   We charge much higher daily rates for our people, but since we have better and more productive people, we can actually do the job for less.

Also, ihr wollt agile entwickeln, aber eure Kunden wollen Festpreise? Die Lösung ist “einfach”, sucht euch ein Spitzenteam. Macht ein Festpreisprojekt mit großzügigem Puffer und spielt mit offenen Karten, damit der Kunde sieht wie zuverlässig ihr arbeitet, und wie wenig von seinen ursprünglichen Anforderungen wirklich übrigbleibt.

Und wer schon mal versucht hat Spitzenleute anzuheuern weiß, warum einfach oben in Anführungszeichen steht.

Bevor ich nach langer Pause mein kleines MS-Project Tutorial mit der Ressourcenplanung fortsetze, muss ich sicherstellen, dass ihr euch noch an die Grundrechenart erinnert.

Wenn man den Aufwand und die Zeit, die für einen Vorgang oder ein Projekt benötigt werden, abschätzen will, muss man einen einfachen Zusammenhang verstehen:

Arbeit = Dauer * Intensität

Arbeit ist dabei die Menge der Arbeit die anfällt oder vernichtet wird, gemessen in Personen*Zeit, also z.B. Personen-Tagen.
Dauer ist die Zeit vom ersten Handschlag, bis zum Ende der Tätigkeit, gemessen in Tagen, Stunden und dergleichen. Und Intensität ist die Anzahl (oder der Anteil von) Personen, die gleichzeitig an der Aufgabe arbeiten. Typischerweise gemessen in Personen.

Ein Beispiel: Für eine Weihnachtsfeier müssen 1000 Einladungen gefaltet in einen Umschlag gesteckt und mit einem Adressaufkleber versehen werden. Ein kleines Experiment zeigt: pro Einladung benötigt man etwa 30 Sekunden. Also braucht eine Person 30000 Sekunden oder 500 Minuten oder etwas über 80 Stunden, also zwei Arbeitswochen.

Wenn man aber 5 Personen einsetzt (die Intensität verfünffacht) braucht man nur noch 2 Tage, die Arbeit bleibt konstant, die Dauer sinkt auf ein Fünftel.

Ein anderes Beispiel: 2 Personen (Intensität) treffen sich zu einem 1 stündigen Meeting (Dauer), es fällt also Arbeit von 2 Personen-Stunden an. Überraschend stoßen 4 weitere Teilnehmer hinzu. Die Intensität verdreifacht sich, aber deswegen dauert das Meeting keine 20 Minuten, sondern noch immer 1 Stunde. Also wächst die Arbeit auf 6 Personen-Stunden.

Eine Programmieraufgabe wird auf 2 Tage Arbeit für eine Person geschätzt. Nach genauerer Prüfung wird festgestellt, dass alles viel einfacher ist und daher nur ein Personentag Arbeit benötigt wird. Der zuständige Mitarbeiter nutzt die Gelegenheit um einige Supportanfragen für ein altes Projekt zu bearbeiten und arbeitet daher nur halbe Tage an der Aufgabe. Arbeit sinkt, Intensität sinkt, Dauer bleibt konstant.

Diese drei Attribute gibt es natürlich auch in MS-Project.

Arbeit heißt Arbeit
Dauer heißt Dauer
und Intensität heißt Zuordnungseinheiten. Es geht doch nichts über einen Beamten als Dolmetscher.

Arbeit und Dauer sind Attribute des Vorgangs, Zurordnungseinheiten gibt es aber nur im Kontext einer Ressource, die an einem Vorgang arbeitet.
Um sie anzuzeigen, konstruieren wir uns mal wieder eine spezielle Ansicht:

Ansicht -> weitere Ansichten … -> Neu -> Ansichtkombination

Für den oberen Teil wählen wir ‘Balkendiagramm (Gantt)’ für den unteren ‘Ressource Einsatz’

Hier können wir im oberen Teil Arbeit und Dauer sehen und zum Beispiel per Spalte Ressourcenkürzel Ressourcen einer Aufgabe zuordnen. Im Untern Teil können wir die Zuordnungseineinheiten (in %) sehen und auch Überlastung von Ressourcen.

Bleibt ein Problem: Wenn man jetzt in Project eins dieser Attribute verändert, muss auch eins der anderen beiden Attribute angepasst werden. Aber welches? Wie man spätestens beim letzten Beispiel gemerkt haben sollte gibt es keinen Algorithmus der einme dies verrät. Es hängt von der Art der Aufgabe ab, um die es geht. Dies ‘Art’ heißt in MS-Project genau so: ‘Art’ und ist ein Attribut von Vorgängen. Es kann sich um ‘Feste Einheiten’, ‘Feste Dauer’ oder ‘Feste Einheiten’ handeln. MS-Project versuchte die ‘festen’ Einheiten fest zu halten. Wenn eins der anderen Attribute geändert wird, wird das dritte angepasst, so dass obige Gleichung wieder stimmt.

Ihr könnt jetzt die Dauer, Arbeit und Intensität eurer Vorgänge steuern, Bleibt noch eine Warnung: Jeder Formalismus, der einfacher ist als eine relativistische Theorie der Quanten Chromo Dynamik ist notwendiger Weise eine Näherung der Wirklichkeit. Wenn ihr also die Schwangerschaft eurer Frau durch die Unterstützung von 8 weiteren Frauen zu verkürzen, verkürzt dies allenfalls eure Beziehung und erhöht eure finanzielle Belastung. Will sagen die Formel ist der Idealfall und vernachlässigt völlig Dinge wie Einarbeitungszeiten und gegenseitige Behinderung bei der Arbeit, weil mehr als einer die selbe Datei berabeitet.

Demnächst geht es weiter damit, wie man die oben gezeigt Ansicht verfeinern kann, um eine kontrollierte Ressourcenplanung zu betreiben.

genau wie wir im Ort immer genau 50 vor den Radarfallen fahren

Richtig übel wird das erst, wenn die Kennzahl die fein an ihrer Grenze justiert ist, durch einen äußeren Einfluss über die Grenze geschoben wird. Dann tritt der Autofahrer voll auf die Bremse und der hinter ihm hat ein Problem.
Die Kennzahl, oder das Kennzahlensystem welches Gunter Dueck analysiert ist geringfügig einflussreicher als das lokale Tempolimit: Basel II. Tatsächlich führt er einen erheblichen Teil der Immobilienkrise auf Basel II zurück:

Wir sehen auch, dass die Regeln der Finanzmärkte zusammen mit den Am-Limit-Strategien dazu führen, dass es nun bei jedem Immobilien-oder-was-weiß-ich-Umschwung zu einer gigantischen Finanzkrise kommen muss.

Wenn also mal wieder der Controller Kennzahlen haben will, oder frau selbst welche suchst, prüfe gründlich:

• Misst sie das, was sie zu messen vorgibt?
• Kann die Optimierung der Kennzahl auch in einer Form passieren, die nicht den Zielen der Kennzahl entsprechen?
• Kann die Kennzahl sich zu einem solchen falschen Grenzwert entwickeln? In diesem Fall sollte die Kennzahl auf keinen Fall mit drakonischen Maßnahmen sanktioniert werden, denn dies fördert nur die Überreaktion in Krisensituationen.

Idealerweise sollten Kennzahlen eh nur als Indikator für potentielle Probleme genutzt werden und keine automatische Reaktion, außer einer genaueren manuellen Untersuchung auslösen.

Diese Verbindung bedeutet aber auch, dass es einen Unterschied gibt, und der wird immer öfter von Managern vergessen: Nicht alles ist ein Projekt. Und einen Kulturwandel (z.B. hin zu mehr Innovationen oder mehr Leistung) ist sicher kein Projekt, sondern bedarf Änderungen in der Linienorganisation. Die Änderung selbst kann in Form eines Projektes durchgeführt werden, um eine Wirkung zu erzielen, bedarf es aber dauerhaft der Linienorganisation.

Ähnliches kann man im Projektmanagement Blog lesen:

Viele Unternehmen haben nämlich keine Strategie-, sondern eine Umsetzungskrise. Sie bringen die PS einfach nicht auf den Boden.

und weiter, dass es zwei Wege gibt, die PS auf die Straße zu bringen: Die Linienorganisation und Projekte oder Programme.

Gunter Dueck beschreibt in einem herrlich zu lesendem Artikel darüber hinaus noch ein weiteres Problem mit fehlgeleitetem ‘Projektizismus’:

Innovation erfordert fast meditative Ruhe der Kreation. Eine Leistungskultur aber diffamiert „Ruhe“ als Faulheit und Stillstand. Innovation erfordert Weite des Denkens. Leistungskultur fokussiert auf das Hier und Jetzt.

Dies bezieht sich auf Unternehmen, die mit Projekten erfolglos sowohl eine Innovationskultur, als auch eine Leistungskultur ‘einführen’ wollen.

Ich habe für diese Dinge keine so schönen Worte wie Gunter Dueck. Ich würde dies einfach als planloses handeln bezeichnen. Hätten die Betroffenen einen Plan, wüssten sie auch ob sie ein Projekt brauchen, oder eine Linienaufgabe vor sich haben. Und sie hätten eine Vorstellung davon ob verschiedene Vorhaben widersprüchliche Ziele haben.

Womit wir den Bogen geschlagen haben zum Qualitätsmanagement und dem Projektmanagement. Wiederkehrendes Motiv im Qualitätsmanagement, z.B. auch in der ISO 9001 ist das planvolle Handeln: Man macht einen Plan, versucht ihn umzusetzen, greift ein wenn es nicht klappt und vergleicht am Ende was funktioniert hat und was nicht.

Eine der ganz frühen Aufgaben im Projektmanagement ist die Zielplanung, in der die verschiedenen Ziele, die die Stakeholder in einem Projekt verfolgen gesammelt, sortiert und priorisiert werden. Dabei kommen normalerweise widersprüchliche Ziele zum Vorschein zwischen denen sich die Stakeholder entscheiden müssen.

Oder anders gesagt, wenn ein ein paar Leute ihre Arbeit richtig machen würden, bliebe so manchem Mitarbeiter einiges an Dauerumstrukturierung erspart. Bei VW und Co haben die meisten von uns wenig Chancen etwas zu verbessern, aber wenn ihr bei einem übersichtlicherem Brötchengeber arbeitet, fordert euer Recht ein: Das Recht auf klar definierte messbare Ziele, sowohl für die persönliche Arbeit, als auch und gerade für Organisationsprojekte. Und macht nicht alles zu einem Projekt nur weil Projekte IN sind.

The architect tries to limit project risks. So, she uses future-proofed designs containing abstractions. This can help to reduce maintenance efforts. But, when presenting such designs to developers, you may be surprised by bad attitude: “This is too complex to implement”.

Ganz richtig stellt er fest, dass Kritik von Entwicklern an einem Architekturentwurf auf Fehler in der Architektur hindeuten können, und dass es zu den Aufgaben des Architekten gehört auf die Entwickler zuzugehen, für die Architektur zu werben und sie z.B. mit Hilfe von Beispielen zu erläutern. Ebenfalls richtig: Entwickler lernen abstrakte Entwürfe zu verstehen und in Code zu gießen:

Architects may have to separate the design into different and simpler views. To present concrete examples, that describe all the abstractions, can help here. There are two aspects in it: the current requirements and their concrete realization – to find examples for this is easy – and examples that show how the future can be, to give an idea of reusability. For this you’ve to read between the lines of your customers and may use requirements experiences from the past to get realistic examples.

Aber bei all dem fehlt ein wesentlicher Punkt, eine wesentliche Aufgabe des Architekten: Eine Architektur zu entwerfen, die den Fähigkeiten der Entwickler entspricht. Was hilft eine wunderbares Design? Das elegant all die technischen Probleme löst, die das Projekt zu bewältigen hat, erweiterbar und zukunftssicher ist? Wenn die Entwickler nicht in der Lage sind es zu implementieren? Jeder Architekt, der immer wieder auf Unverständnis bei den Entwicklern stößt sollte sich dringenst fragen, ob das Design nicht vereinfacht werden kann. Ob nicht ein einfacheres Design bis auf weiteres ausreichend ist. Gegebenenfalls um es später durch Refactorings zu verbessern, wenn die Entwickler ihre Erfahrungen gesammelt haben und selbst erkennen können, wie ein abstrakteres Design ihnen helfen könnte.

Und jeder der im Jahre 2008 ein Team mit Entwicklern und Architekten hat, sollte sich dringend fragen, ob er nicht wichtige Entwicklungen in der Branche verpasst hat. Wieso implementiert der Architekt seinen Entwurf nicht zusammen mit einem Entwickler.  Wer könnte es schneller und zuverlässiger implementieren, als derjenige, der es im wesentlichen erdacht hat? Wie ließe sich das Verständnis für die Architektur besser schulen, als bei ihrer Umsetzung beteiligt zu sein?

In meiner Erfahrung eine der ‘Lehren’ aus agilen Prozessen, die wirklich Früchte tragen, wenn sie gelebt werden: Einerseits Pairprogramming als Mittel den Code zu verbessern und Teammitglieder zu coachen und andererseits das Verständnis, dass es nicht um ‘meine Aufgabe / deine Aufgabe’ im Projekt geht, sondern darum Probleme zu lösen. Wenn Architekten und Designer getrennt sind von der Gruppe der Entwickler führt dies fast immer zu mehr oder weniger starker Abgrenzung. Nur zu schnell wird eine kleine Schwäche im Design, egal ob real oder eingebildet, als Zeichen der Unfähigkeit des Architekten erkannt, wenn man die Frau nur vom Telefon kennt. Ganz anders, wenn man gemeinsam vor dem Rechner gesessen hat und gegenseitig gesehen hat, was der andere kann.

Also erzeugt keine Gruppen in eurem Projektteam wenn ihr nicht müsst. Es gibt keinen Grund Architekten und Entwickler personell oder womöglich sogar räumlich zu trennen. Die Kollegen, die schneller, bessere Designs liefern werden sich auch ohne formalle Trennung um eben dies kümmern können, aber werden dabei nicht durch vermeidbare Kommunikationsprobleme behindert. Davon gibt es genügend, die nicht oder nicht so einfach zu vermeiden sind.

Im vorigen Teil dieser Serie habe ich den Aufbau eines Projektstrukturplanes mit Hilfe von Microsoft
Project beschrieben. Einer meiner Empfehlungen war, dass man sich zunächst wirklich auf den PSP konzentriert und
Dinge wie Abhängigkeiten und Termine zunächst ignoriert. Um die Abhängigkeiten möchte ich mich in diesem Artikel
kümmern.

Meilensteine

Meilensteine kennzeichnen Ereignisse im Projekt. Da es sich um Ereignisse handelt haben sie Dauer und Arbeit 0. Das
sagt zumindestens die Theorie. MS-Project meint es mal wieder besser zu wissen. Dort gibt es für einen Vorgang
einerseits die Angabe “Dauer”, andererseits die Angabe “Meilenstein”. Wenn man die Dauer auf 0 setzt, wird auch
automatisch das Meilensteinflag auf “Ja” gesetzt. Soweit so gut. Aber man kann auch von Hand das Meilensteinflag auf
“Ja” setzen, ohne dass die Dauer, oder die Arbeit dadurch beeinflusst wird. Eindeutig ein weiteres Unfeature von
Microsoft Project, dass man tunlichst meiden sollte, es sei dann man plant seine Kollegen in den Wahnsinn zu treiben.

Jedes Projekt sollte wenigstens zwei Meilenstein haben, den Projektbeginn und das Projektende.
Meilensteine sollten immer mit einem klaren Kriterium versehen sein, wann sie erreicht werden. Dadurch zwingen sie
den Projektleiter, das Projektteam und gegebenenfalls Steuerungsgremien dazu innezuhalten und bewusst eine
Entscheidung zu treffen, ob der Projektfortschritt bisher befriedigend war und ob mit dem Projekt fortgefahren werden
sollte. Damit dies immer wieder einmal im Laufe eines Projektes geschieht, sollten immer mal wieder Meilensteine in
einem Projekt vorgesehen werden.

Neben der groben zeitlichen Strukturierung eines Projektes können Meilensteine für verschiedene Zwecke eingesetzt
werden. Ich werde immer wieder darauf hinweisen.

Ablaufplan

Der Ablaufplan beschreibt in welcher Reihenfolge Tätigkeiten auszuführen sind. Er entsteht aus dem
Projektstrukturplan, in dem zu jedem Vorgang Vorgänger und Nachfolger definiert werden. Dazu wird in die
Tabellenansicht so konfiguriert, dass die folgenden Spalten zu sehen sind:

• Nr.
• i wie Information
• Vorgangsname
• Notizen
• PSP-Code (s.u.)
• Vorgänger
• Nachfolger

Nr. ist einfach die laufende Nummer eines Vorgangs, wie sie MS-Project verwendet, und genau diese Nummer wird bei
Vorgänger oder Nachfolger eingetragen. MS-Project kümmert sich für uns darum, dass die beiden Angaben immer synchron
sind, d.h. wenn Vorgang Nummer 2 als Nachfolger von Vorgang 1 eingetragen ist, dann ist Vorgang 1 auch Vorgänger von
Vorgang 2.

Das ganze ist auch per Maus im Ganttchart (die blauen Balken mit Pfeilen dazwischen) editierbar, ich würde davon aber
dringend abraten. Eine Mausgeste hat in dem Ganttchart sehr unterschiedliche Bedeutung, je nachdem wo man sie
ausführt. Nur zu schnell haben sie einen Vorgang aus versehen auf einen festen Termin festgelegt, oder eine Beziehung
definiert, die sie gar nicht haben wollten, und in dem Gewusel, das sie bald im Ganttchart haben, werden sie dass
nicht so schnell wieder finden. Die Tabelle ist ihr Freund.

An alle, die jetzt schon fleissig Vorgänger und Nachfolger definieren ein gerufenes HALT! Es fehlt
noch ein wenig Theorie.

Was ist ein Vorgänger / Nachfolger

Eine Vorgänger-Nachfolger Beziehung wie ich sie oben mit MS-Project-Mitteln beschrieben habe bedeutet:

Der Nachfolger kann erst beginnen, wenn der Vorgänger beendet ist.

In diesem Satz steckt mehr als man auf den ersten Blick entdeckt, daher lasst mich das eine oder andere noch
herausarbeiten.

Erstens: Das Wörtchen kann in obigem Satz bedeutet, es geht um einen kausalen Zusammenhang, nicht etwa um
einen temporalen. Also nur weil Modul1 ihrere Meinung nach vor Modul2 implementiert werden sollte, heisst dies noch
lange nicht, dass eine Vorgänger/Nachfolger Beziehung vorliegt. Außerdem sollten wir uns auf direkte kausale Beziehungen beschränken. Analyse ist ein Vorgänger der Implementierung, und diese ein Vorgänger des Tests. Natürlich ist auch die Analyse ein Vorgänger des Tests, dies wird man aber nicht explizit abbilden, da es schon implizit über die Implementierung berücksichtigt ist.

Zweitens: Wir reden von Ende und Anfang des Vorgängers, bzw. des Nachfolgers. Dies nennt man auch
Ende-Anfang-Beziehung oder Normalbeziehung, da es der Standardfall ist, der in den meisen Fällen benötigt wird. Es
gibt diverse Variationen dieser Beziehung.

Zum einen kann man Beziehungen zwischen Ende-Ende, Anfang-Ende oder Anfang-Anfang geben. Diese sind in 99% der Fälle
unnötig, und nach meiner Erfahrung in 95% der eingesetzten Fälle falsch, daher empfehle ich hier der Kürze halber
einfach: ignorieren und nur Ende-Anfang-Beziehungen verwenden.

Zum anderen können Zeitabstände definiert werden, die eingehalten werden müssen. Bei einem positiven Zeitraum kann
man sich gut vorstellen, wie so etwas sinnvoll einzusetzen ist. Beton zum Beispiel muss 28 Tage?
abbinden, bevor darauf aufbauend weiter gearbeitet werden kann. Um eine solche Zeitdauer in
MS-Project einzugeben, schreiben sie in das Vorgänger bzw. Nachfolgerfeld einen Ausdruck der Art: 42EA+28 Dies
bedeutet, der aktuelle Vorgang eine Ende-Anfangbeziehung mit Vorgang Nummer 42 hat, die mit einem minimalen
Zeitabstand von 28Tagen versehen ist. Das EA steht dabei für die Beziehungsart Ende-Anfang.

Negative Zeitabstände sind zwar anscheinend verlockend für viele, machen aber bei genauerer Betrachtung keinen Sinn.
Die Bedeutung wäre der Art, dass der Nachfolger z.B. 3 Tage vor Ende des Vorgängers beginnen darf, oder später, aber
nicht eher. Zu diesem Zeitpunkt ist das Ende des Vorgängers aber noch in der Zukunft, d.h. es kann immer noch etwas
dazwischen kommen, was das Ende des Vorgangs verzögert, oder womöglich ganz verhindert. Anders formuliert: die bisher
bekannte Physik verbietet kausale Abhängigkeiten von Ereignissen in der Zukunft, und da wir kausale Abhängigkeiten
definieren wollen, machen negative Zeitabstände keinen Sinn. Also Finger davon lassen, sonst löst sich euer Projekt
noch in ein Logikwölkchen auf.

Oft ist man dennoch versucht negative Zeitabstände zu verwenden. In meiner Erfahrung ist die Ursache oft ein fehlender
Meilenstein. Beispiel: Schon vor Abschluss der Analyse kann mit der Implementation begonnen werden. Wenn ich dies mit
Hilfe eines negativen Zeitabstandes definiere, stecke ich die Erwartung hinein, dass zu einem gewissen Zeitpunkt die
Analyse einen bestimmten Reifegrad hat, so dass die Implementierung beginnen kann. Dies lässt sich sauberer planen,
in dem man zusätzliche Meilensteine vorsieht, für die nach Möglichkeit Messbare Kriterien definiert werden, wann sie erreicht werden. Also zum Beispiel: Analysten und Entwickler beschließen gemeinsam, dass die Analyse ausreichend weit fortgeschritten ist um mit der Implementierung zu beginnen. Ein analoges Vorgehen ist auf jeden Fall auch für phasenorientierte Ablaufpläne zu empfehlen, da Phasen sich praktisch immer überlappen und ein klares Kriterium gegeben sein sollte, wann (und ob) eine neue Phase beginnt.

Mehrfach Abhängigkeiten

Oft gibt es Gruppen von Vorgängen, die gemeinsam Vorgänger für andere Gruppen von Vorgängen sind. Dadurch entstehen sehr viele Abfolgebeziehungen und es wird sehr schwierig zu beurteilen, ob alle Abhängigkeiten wirklich abgebildet wurden. Noch unangenehmer wird es wenn in der Planungsphase ständige Vorgänge hinzukommen oder wegfallen. Auch hier hilft ein Meilenstein, der den Abschluss der Vorgänger bündelt und als Vorgänger für die Nachfolger dient.

Abraten würde ich aber davon Beziehungen zwischen Sammelvorgängen zu machen, also den höheren Hierarchieebenen des Projektstrukturplans. Der Grund? Diese Ebenen sind per Definition abstrakte Gliederungskriterien, sie enthalten keine Aussage über die Reihenfolge von Vorgängen. Dieses Prinzip wird aufgebrochen, wenn zwischen Sammelvorgängen Abhängigkeiten definiert werden. Zu leicht kommt später ein Vorgang zu dem Sammelvorgang hinzu, der dann automatisch die Abhängigkeit erbt, egal ob gewünscht oder nicht.

Sanitycheck

Wenn auf diese Weise die Abhängigkeiten zwischen den Vorgängen definiert sind. Sollte es außer dem Meilenstein Projektbeginn keinen Vorgang geben, der keinen Vorgänger hat und keinen, der keinen Nachfolger hat, außer dem Meilenstein Projektende. Vorgänge ohne Vorgänger würde nicht zum Projekt gehören und würden daher auch nicht im Rahmen des Projektes geplant werden. Vorgänger ohne Nachfolger werden offensichtlich nicht für den Projektabschluss benötigt und sollten daher weggelassen werden. Natürlich gibt es auch immer noch die Variante, dass Vorgänge oder Abhängigkeiten vergessen wurden, diese sollten dann natürlich umgehend ergänzt werden.

Im nächsten Teil der Serie werde ich beschreiben, wie Arbeit und Dauer miteinander zusammenhängen, und wie man diesen Zusammenhang in Microsoft Project abbildet.

Chef …

• befreit im tiefsten Winter das Auto des Mitarbeiters schon mal von Eis und Schnee und heizt es vor, damit der Mitarbeiter warm nach Hause kommt.
• sorgt dafür, dass eine Woche lang ein Chefkoch beim Mitarbeiter daheim das Abendessen zubereitet.

Leider wird nicht so recht herausgearbeitet, was denn die wesentlichen Punkt an diesen Ideen ist:

1. Es ist persönlich an den Mitarbeiter gerichtet. Die Uhr zum x-ten Jubiläum reißt keinen vom Hocker, wenn sie jeder bekommt. Aber die Modelleisenbahn, den Modelleisenbahner, selbst wenn die Modelleisenbahn nur ein Fünftel der Uhr kostet.
2. Der Chef kümmert sich selbst. Wenn der Chef einem die Windschutzscheibe vom Schnee befreit, dann ist das ein echtes Statement, das der Mitarbeiter verstehen wird.

Also, wenn sie einem Mitarbeiter etwas Gutes tun wollen, dann werden sie selbst aktiv und kreativ und machen sie sich schlau, womit sie den Mitarbeiter begeistern könnten.

Und nicht vergessen, die Projektabschlussfeier am Ende eines Projektes ist nicht optional. Sie ist eine Form des Dankes, vielleicht der einzige Teil des Projektes an das in zwei Jahren noch gedacht wird und wichtige Vorbereitung für das nächste Projekt.

Brooks goes on to argue that there is a difference between “good” designers and “great” designers. He postulates that as programming is a creative process, some designers are inherently better than others. He suggests that there is as much as a 10-fold difference between an ordinary designer and a great one.

Und was bedeutet das für Projekte? Da die Softwareentwickler, die für ein Projekt zur Verfügung stehen bei weitem keinen Gehaltsunterschied von Faktor 10 haben, aber nach obiger These und meiner Erfahrung einen solchen Produktivitätsunterschied aufweisen, ist es am günstigsten für ein Projekt, die besten Entwickler einzusetzen, die man nur bekommen kann. Selbst wenn diese doppelt oder dreimal so teuer sind, wie die ‘günstigsten’. Das gleiche gilt natürlich für Firmen bei der Einstellung von Mitarbeitern.

Korollar: Mein Chef sollte mir dringend mehr Geld zahlen.

Informelle Umfrage:

• Wer hält den 10fachen Produktivitätsunterschied für realistisch?
• Wer berücksichtigt einen solchen Faktor bei Aufwandsschätzung für seine Projekte?

Alle Teile dieser Serie:
Der Projektstrukturplan
Der Ablaufplan
Arbeit und Dauer
Speichere früh, speichere oft, aber nicht automatisch.

MS-Project hat diverse Bugs, Unfeatures und fehlende Features. Ein Beispiel dafür ist die Undo Funktion. Diese funktioniert oft, aber nicht immer, und so kann es passieren, dass man mit ein paar Mausklicks sein Dokument zerstört und es mit MS-Project Mitteln nicht wieder hergestellt bekommt.

Daher sollte in regelmäßigen, nicht zu großen Abständen gespeichert werden und zwar so, dass man nicht nur auf die letzte sondern auf alle gespeicherten Versionen zugreifen kann. Dies erreicht man entweder in dem man einen Versionsverwaltung einsetzt, oder man versieht jede gespeicherte Datei mit einer Versionsnummer, die bei jedem speichern manuell erhöht wird:

MyProject-V003.mpp

An dieser Stelle ist man versucht diesen Prozess zu automatisieren, schließlich sind wir alle faul, nicht war? Die Autosave Option ist dafür aber definitiv die falsche Option, da nach Murphy’s Law Autosave direkt nach einer ungeschickten Aktion aktiv wird, und mit dem Datenmüll, den man soeben produziert hat, unwiederbringlich den letzten intakten Arbeitsstand überschreibt.

Wenn es eine Standardeinstellungen von Microsoft ist, dient es der Featuredemonstration, nicht dem sinnvollen arbeiten.

Wenn MS-Project gestartet wird, bietet es einem standardmäßig eine zweigeteilte Ansicht an:

Links ist eine Tabelle mit den Spalten:

• i wie Information oder Notiz
• Vorgangsname
• Dauer
• Anfang
• Ende
• Vorgänger
• Resourcennamen

Dies verleitet dazu viele Dinge auf einmal zu planen:

• was alles zu tun ist (Vorgangsname)
• wie lange es dauern wird (Dauer)
• wann es getan wird (Anfang, Ende)
• in welcher Reihenfolge es geplant wird (Vorgänger)
• und wer es tut

Die meisten Projektleiter sind erfahrungsgemäß männlich und sind per Definition nicht Multitasking fähig. Sie Sollten sich also lieber auf eine Aufgabe beschränken. Bei Frauen bin ich mir nicht so sicher, ich vermute aber, dass es ihnen auch nicht schadet. Also konfigurieren (s.u.) wir die Ansicht so um, dass wir nur noch die folgenden Spalten sehen:

• i wie Information (die kann man immer gut gebrauchen)
• Vorgangsname
• Notizen
• PSP-Code (s.u.)

Hier können wir nun den sogenannten Projektstrukturplan (PSP; engl. Workbreakdownstructure) erstellen. Der PSP ist eine hierarchisch geordnete Sammlung sämtliche Vorgänge, die in einem Projekt zu erledigen sind. Dabei entstehen früher oder später zwei Fragestellungen:

1. Wie detailliert soll ich planen?
Die Antwort ist so einfach wie unbefriedigend. Plane genau das, was du kontrollieren kannst und willst. Das heißt, man muss sich eine Vorstellung davon machen, wie oft man den Fortschritt später im Projekt kontrollieren möchte. Je nach Projekt kann dies extrem unterschiedlich ausfallen: Wenn ich eine große Weihnachtsfeier organisiere, kann die Vorbereitung durchaus ein halbes Jahr vorher beginnen, ich werde aber vermutlich nur gelegentlich (einmal pro Monat?) den Status kontrollieren, am Tag der Feier werde ich aber unter Umständen stündlich nach dem rechten sehen. Das wichtige Kriterium ist die Frage des tolerierbaren Risikos: Ich muss einen Vorgang so genau im Auge behalten, damit ich noch reagieren kann, wenn ich merke, dass etwas schief geht, ohne dass unakzeptabler Schaden am Projekt entsteht.

2. Wie strukturiere ich den Projektstrukturplan?
In Wirklichkeit stellen sich erschreckend wenige Projektleiter diese Frage, was zu Ergebnissen wie dem folgenden führt (nur die erste Hierarchieebene ist dargestellt):

Next Killer App
    GUI
    DB
    Business Logik
    testen
    dokumentieren

Wem noch nicht aufgefallen ist, was an dieser Struktur falsch ist, überlege sich wo denn die Gui dokumentiert wird, und wo die Datenbank getestet wird.

Das Problem ist, dass unterschiedliche Kriterien verwandt werden: Einerseits Schichten der Anwendung, andererseits Tätigkeiten. Dadurch ist für einen Vorgang nicht klar, wo er indieser Struktur einzuordnen ist. Und dies führt mindestens zu unnötiger Sucherrei, oft aber zu schlicht vergessenen oder doppelt geplanten Vorgängen.

innerhalb eines Sammelvorgangs, werden die Untervorgänge nach einem einheitlichen Kriterium strukturiert.

Kriterien könnten dabei sein:

• Projektphasen (Vorsicht, da Phasen sich meist überlappen)
• Objekte, d.h. Teile des zu erstellenden Projektergebnisses. Dies könnten Gebäudeteile in einem Bauprojekt sein, Module oder Schichten in einer Anwendung.
• Tätigkeiten (entwerfen, analysieren, anstreichen, reinigen, testen …)
• Personengruppen / Abteilungen, die für die Vorgänge zuständig sind: (Maler, Architekten, Tester)

Welches das richtige Kriterium ist, hängt vom Projekt und vom Geschmack des Projektleiters ab.

Eine Sonderrolle nimmt häufig das Projektmanagement selbst auf der obersten Hierarchieebene ein. Projektmanagement darf (und sollte) auf der obersten Ebene seinen eigenen Zweig bekommen. Läuft dies der ausgewählten Strukturierung zuwieder ist es eine zulässige Ausnahme, wenn klar definiert ist, dass alle PM-Aufgaben unter diesem Zweig einzuordnen sind.

Der PSP Code
Der PSP Code ist ein Schlüssel, der jeden Vorgang eindeutig kennzeichnet. Er kann in MS-Project automatisch erzeugt werden, wobei stark beeinflusst werden kann wie der PSP-Code aussieht. Der PSP-Code ist kurz und kompakt, liefert aber dennoch eine Menge Information darüber wo der gekennzeichnete Vorgang im PSP wiederzufinden ist. Daher eignet er sich hervorragend um im Projekt Vorgänge zu referenzieren.

Das Aussehen des PSP-Codes lässt sich unter
Projekt->PSP-Code->Codedefinition...
konfigurieren. Ich persönlich bevorzuge:

• ein 3-4 Buchstabenkürzel für das Projekt
• 2-3 manuell vergebene Großbuchstaben für die oberste Gliederungsebene, die einen Hinweis auf die Gliederungsebene liefern
• abwechselnd Zahlen und Kleinbuchstaben, automatisch vergeben.

Konfiguration der Tabellenansicht in MS-Project
Per Click auf die Spaltenheader können Spalten zu der Tabelle hinzugefügt und entfernt werden. Meist ist es jedoch geschickter einen etwas anderen Weg zu gehen.

Über das Menü
Ansicht -> Tabelle: xxx -> Weitere Tabellen...
können die Spalten in einer benannten Tabelle konfiguriert werden, bzw. weitere benannte Tabellen definiert werden. Diese Tabellen können dann per Menü ausgewählt werden. Auf diese Weise müssen nicht ständig Spalten hinzugefügt und entfernt werden.

Im nächsten Teil dieser Serie beschreibe ich, wie aus dem Projektstrukturplan ein Ablaufplan erstellt wird.