Was in Büchern zum Software-Projektmanagement gerne übergangen wird, sind die Kleinprojekte. Vielleicht, weil das Management von Kleinprojekten als trivial angesehen wird. Dabei sind es die Kleinprojekte, von denen es so zahllos viele gibt.
Als Kleinprojekt definiere ich ein Vorhaben, das beim Auftragnehmer von ein bis fünf Personen abgewickelt wird, das wenige Wochen bis einige Monate dauert und in der Regel den Auftraggeber ein paar Tausend bis wenige Zehntausend Euro kostet.
Das Tagesgeschäft von vielen Kleinunternehmen ist geprägt von Kleinprojekten. Freiberufler müssen sich immer wieder auf Kleinprojekte einlassen. Der Schritt in die Selbstständigkeit bedeutet für viele die Abwicklung unzähliger Kleinprojekte -- ein Leben von der Hand in den Mund mit geringen Gewinnspannen. Und viele Informatik-Studierende versuchen, sich mit Kleinprojekten (oder auch Kleinstprojekten) ein Zubrot zu verdienen. Grund genug, sich mit dieser Sorte von Projekten einmal genauer zu befassen.
Diese Woche habe ich in der Projektmanagement-Vorlesung eine Fallstudie besprochen. Ein reales, kleines Softwareprojekt, an dem ich auch beteiligt war bzw. bin -- es steht kurz vor dem Abschluss. Ich habe dazu die Projekthistorie aufgerollt und mich dabei ausschließlich auf die spannende Phase vor der eigentlichen Software-Entwicklung konzentriert, die ich hier Vor-Entwicklungsphase nenne. Es geht also um die Zeit, in der mit dem Kunden diskutiert, überlegt, gebrütet und gelöst wird -- bis man verstanden hat, worum es eigentlich geht und was entwickelt werden soll. Mögliche Resultate sind Anforderungsdokumente, Konzeptpapiere, Prototypen und ein Vertrag bzw. ein Auftrag zur eigentlichen Entwicklung, sprich zur Realisierung der ausgereiften Idee. Diese Phase ist mit Aufwendungen und mit Kosten verbunden. Wissen Sie, wie hoch die Kosten da liegen? Haben Sie eine ungefähre Vorstellung wie der Kostenverlauf über die Zeit aussieht und mit welchem Kostenverhältnis der Kunde rechnen darf?
Zur Fallstudie. Damit Sie eine grobe Vorstellung haben, es geht inhaltlich um eine webbasierte Anwendung mit einer relationalen Datenbank dahinter. Technisch unspektakulär, etwas, was in aller Welt immer wieder entwickelt wird. Am Ende wird sich herausstellen, dass die Softwarekonzeption samt prototypischem Datenbankschema durch ein sechsseitiges Dokument ausreichend dokumentiert ist. Es handelt sich also tatsächlich um ein "richtiges" Kleinprojekt. Dennoch ist erstaunlich, welcher Aufwände es bedarf, um von dem Kundenanliegen zu dieser klaren Dokumentation zu gelangen.
Ich habe Folgendes zur frühen Projektphase aufgelistet: Wann gab es Treffen, was war der Anlass, wer war vom Kunden, wer vom Auftragnehmer dabei? Und: Wann wurde ein Resultat (in der Regel ein Dokument oder ein Prototyp) rausgegeben? Wer war an der Erstellung wie lange beteiligt -- und wen hat es wie viel Zeit zum "konsumieren" (lesen, verstehen, ausprobieren) gekostet? Ich habe dann noch auf der Kunden- wie auf der Auftragnehmerseite zwei Rollen unterschieden: einmal die Personengruppe, deren Zeit mehr kostet (Leitungsfunktionen, Manager, Koordinatoren) und die Gruppe, deren Zeit weniger kostet (Entwickler, Tester, technische Schreiber). Mit der Zuordnung möchte ich niemanden diskriminieren, sie spiegelt nur grob die Kostenverteilung wieder, wie wir sie in der Realität antreffen. So ungenau das ist, es hilft uns, einen Eindruck zu gewinnen.
Übrigens habe ich mit Tiefstpreisen gerechnet: Die "Billigen" kosten 50 Euro die Stunde, die "Teuren" doppelt so viel. Das dürfen Sie gerne im Kopf nach oben korrigieren. (Bevor Sie unglückliche Mutmaßungen anstellen: Ich habe in dem Projekt unentgeltlich gearbeitet, meine Arbeitskraft in der Modellrechnung jedoch monetär berücksichtigt.) Zeitaufwände habe ich aus dem Gedächtnis rekonstruiert, da ich keine zuverlässigen Aufzeichnungen dazu habe, und bin mit meinen Schätzungen sehr sportlich vorgegangen. Sportlich heißt auch hier, dass ich mit Minimalaufwänden gearbeitet habe, die real in den meisten Fällen höher liegen dürften.
Die Ergebnisse: In der Historie der frühen Projektphase habe ich in einem Zeitraum von 5 Monaten (Juli bis Dezember 2007) 13 Termine bzw. Ereignisse erfasst. Davon sind 6 Termine Besprechungen (4 Vis-a-Vis, 2 Telefonkonferenzen) und 7 Termine markieren den Versand eines entscheidenden Dokuments, entweder als Neuerstellung oder als Update. Die mit diesen Terminen bzw. Ereignissen assoziierten Kosten belaufen sich für den Kunden auf etwa 1600 Euro, für den Auftragnehmer auf 4300 Euro.
Ich finde das sehr beachtlich. Der Kunde muss als Auftraggeber etwa 6000 Euro ausgeben, einzig um sein Anliegen in dieser Projektphase zu kommunizieren, zu reflektieren, zu diskutieren, zu revidieren, zu konkretisieren und zu präzisieren. In der Zeit hat der Auftragnehmer noch keinen einzigen Euro verdient! Er hat diesen Prozess lediglich gemeinsam und in Kooperation mit seinem Kunden durchlaufen und zu einem Resultat getrieben, der dann erst den Startpunkt für die konkreten Entwicklungsaktivitäten eines Softwareprodukts bildet.
Ich halte übrigens die Kostenanteile meiner Erfahrung nach für relativ typisch, kann dies allerdings nicht durch Fakten aus anderen Projekten belegen. Das Verhältnis liegt bei etwa 2:5. Von 7 Anteilen, die der Kunde für diese Projektphase ausgeben muss (6000 Euro durch 7 macht ca. 850 Euro), muss der Kunde seine eigenen Kosten etwa mit 2 Anteilen (die 1600 Euro, gleich etwa 2 Mal 850 Euro) veranschlagen, die für den Auftragnehmer mit 5 Anteilen (4300 Euro).
Interessant ist zu beobachten, wie die Kostenentwicklung über die Zeit aussieht. Die Analyse der 13 Termine bzw. Ereignisse zeigt, dass für den Kunden die Aufwände am Anfang liegen. In den ersten Treffen werden viele Mitarbeiter vom Kunden involviert (das kostet viel), was am hohen Diskussions- und Klärungsbedarf liegt. Der Auftragnehmer hingegen hat die ganze Zeit über relativ gleichbleibende Aufwände: er muss am Ball bleiben und seine Arbeit im Hintergrund machen. Die Erstellung etwa eines Prototypen ist nicht unaufwendig. Für die weitere Abstimmung und Klärung beschäftigt der Kunde nun nur noch eine Person, die die Verantwortung für das Projekt trägt.
Ich habe diesen Kostenverlauf etwas überzeichnet in dem Bild oben in rot eingetragen. Die Verteilung der Kosten beim Kunden verläuft über die Zeit wie ein sich zuspitzendes Dreieck; die Aufwände werden zunehmend geringer. Beim Auftragnehmer zeigt das langgezogene Rechteck die Konstanz der Kosten an. Bringt man beide Kostenanteile zusammen, sieht man den Verlauf der Gesamtkosten.
In dem Bild habe ich darüber hinaus in grau den Kostenverlauf für das Projekt eingetragen, wie er sich qualitativ für die sich anschließende Entwicklung des Softwareprodukts und seiner Einführung beim Kunden ergeben hat. Während der Entwicklung entstehen für den Kunden kaum Kosten -- er wartet auf das Produkt. Mit der Fertigstellung nimmt der Aufwand für den Kunden wieder zu: Die Abnahme des Produkts muss durchgeführt werden und die mit der Einführung des Produkts verbundenen Schulungen boosten die Kosten noch einmal.
Der Auftragnehmer hat während der Entwicklungszeit relativ konstante Kosten. Ein, zwei oder drei Entwickler werden in dieser Zeit in Kleinprojekten oft beschäftigt. Ist das Produkt fertig, halten die Aufwände noch kurz an, um eventuelle Korrekturen oder kleinere Änderungen durchzuführen, sie nehmen dann aber ab.
Es ist nicht aus zeichnerischen Gründen so, dass die Vor-Entwicklungsphase so lange dauert und die eigentliche Entwicklungszeit so kurz ist. Ist das Anliegen des Kunden einmal geklärt und erfasst, kann die Entwicklung recht zügig abgewickelt werden. Aber es kann dauern, bis das Anliegen hinreichend gut verstanden und aufgearbeitet ist; in diesem Fall hat sich das auf ganze 5 Monate verteilt.
Wo kann der Auftragnehmer eigentlich seine Gewinne einrechnen? Kaum in der Vor-Entwicklungsphase, denn hier geht es darum, Unsicherheiten abzuarbeiten und Klärung herzustellen. Es ist schwer kalkulierbar, wie viele Termine dazu ausreichen werden, wenn man das Kundenanliegen noch nicht einmal verstanden hat. Das ist ja genau das Merkmal dieser frühen Phase: vieles ist unklar, unscharf, uneindeutig, unausgesprochen. Hier geht es lediglich darum, kostendeckend zu arbeiten. Ein Grund, warum diese Phase gerne aufwandsorientiert abgerechnet wird -- nur wollen das die Auftraggeber für Kleinprojekte meist nicht tun, da ihnen ein Verständnis für die Problematik dieser Vor-Entwicklungsphase fehlt. Denn in ihren Augen geht es ja nur um diese kleine Sache, dieses kleine Projekt, das ja eigentlich klar ist. Außerdem neigt ein Auftraggeber zur Blindheit gegenüber seinen eigenen, internen Kosten in dieser Phase (das Dreieck), da diese für Kleinprojekte selten klar abgerechnet werden. Veranschaulicht man sich noch einmal den Kostenverlauf beim Kunden, scheint es durchaus verständlich, dass Kunden nach dem Initialaufwand wenig interne Kosten "spüren". Das Gefühl des internen Kostenverlaufs wird auf den Auftragnehmer projiziert.
Erst nach der Vor-Entwicklungsphase kann gut kalkuliert werden. Ein gemeinsames Verständnis des Kundenanliegens liegt vor, die Angelegenheit ist planbar geworden. Ergo wird der Auftragnehmer hier beginnen, seine Gewinnmargen einzurechnen. Ich habe das durch die schraffierten Bereiche markiert. Allerdings ist aufgrund der Kürze der Entwicklungszeit die Marge nicht sehr "lange" ausschöpfbar -- auch ein Merkmal von Kleinprojekten. Kommen nur ein, zwei, drei ungeplante Entwicklertage hinzu, weil etwa der Kunde auf einer Nachbesserung besteht oder, viel simpler, ein Entwickler krank ist, dann steht das Kleinprojekt für den Auftragnehmer bereits kurz vor der Verlustzone. Wesentlich ertragreicher und noch besser kalkulierbar sind Schulungsmaßnahmen beim Kunden. Nur bedarf nicht jedes Softwareprodukt einer Schulung.
Wie Sie vielleicht anhand dieser Ausführungen erahnen, sind Kleinprojekte ein taffes Unterfangen, die den Auftragnehmern nicht viel Gewinne schenken. Reich wird damit keiner. Es macht auch klar, warum viele Unternehmungen scheitern, wenn sie nicht den Sprung in die Klasse der mittelgroßen Projekte bis Großprojekte schaffen, dort sind die Gewinnmargen größer.
Wenn Sie Ihre Erfahrungen mit Kleinprojekten teilen möchten, ich freue mich auf Ihre Kommentare. Können Sie meine Fallstudie bestätigen? Oder haben Sie andere Erfahrungen mit Kleinprojekten gemacht?