Meiner Ansicht nach enthält der Artikel zwei kapitale Fehler: 1. Die Kalkulation des Projektaufwands sollte unabhängig sein von dem Preis, der sich erzielen lässt. Es gibt ein Projektziel, das erreicht werden soll, und dafür wird eine geschätzte Menge von Ressourcen (Zeit und Geld) benötigt. Der Aufwand sinkt nicht um einen Pfennig, wenn für das Projekt ein Kampfpreis angesetzt werden soll. Er sinkt nur, wenn der Umfang reduziert wird. Und was sollte eine Kalkulation anderes abschätzen als die tatsächlich durchzuführenden Arbeiten? Ebensowenig sinkt bei einem Kampfpreis das Projektrisiko, das sich auch in der Pufferhöhe widerspiegeln sollte - im Gegenteil, oft steigt es sogar! Ich brauche also auch im erwähnten Beispiel des Kampfpreises denselben Puffer (Dummy) wie im "normalen" Fall. 2. 10% über dem Minimalaufwand halte ich für einen VIEL zu geringen Puffer bei allen Vorhaben, die den Titel Projekt auch nur halbwegs zu Recht tragen, die also nicht schon oft UND sehr ähnlich durchgeführt wurden. Empirische Untersuchungen ergeben, dass Projektschätzungen von IT-Projekten im Schnitt nicht genauer als plusminus 20% werden können. (Das ist also der Best Case!) Mit 10% über dem Minimalaufwand liege ich also wahrscheinlich noch unter dem Aufwand, den ich realistisch erwarten muss. In unserer Organisation (Software-Development für Internet-Projekte) haben wir aus der Erfahrung heraus festgelegt, dass ein Puffer von mindestens 10% auf eine realistische (nicht minimale) Schätzung aufgeschlagen werden muss - wenn das Projekt sehr gut verstanden ist. In allen anderen Fällen soll der Puffer höher sein, 15% ist der Standard, und auch 20 oder 30% Puffer gehen durch, wenn sich die Unbestimmtheit oder die Risiken des Projekts benennen lassen. Dass das schon mal für Diskussionen mti dem Vertrieb sorgt, ist völlig klar. Aber nur wenn diese Diskussionen auch tatsächlich geführt werden, hat man die Chance langfristig rentable Porjekte durchzuführen, auf denen die Mitarbeiter auch beim nächsten Mal noch arbeiten wollen.

 

Sehr geehrte Frau, sehr geehrter Herr "SurfGuard", vielen Dank für die Darstellung Ihrer persönlichen Erfahrungen mit finanziellen Puffern bei der Projektkalkulation aus dem Bereich der Software-Entwicklung für Web-Projekte. Befremdlich finde ich allerdings, dass Sie aufgrund Ihres auf IT-Projekte eingeschränkten Erfahrungshintergrunds meinem Beitrag "kapitale Fehler" unterstellen. Dies umso mehr, als sich Ihre Ausführungen inhaltlich vollständig innerhalb des Rahmens meiner Darstellung bewegen. So führen Sie aus: "Die Kalkulation des Projektaufwands sollte unabhängig sein von dem Preis, der sich erzielen lässt." Exakt dieses schreibe ich unter der zweiten Überschrift, erster Absatz: "Grundlage … ist die realistische Kalkulation des minimalen Budgets, mit dem die gestellte Aufgabe unter normalen Bedingungen erledigt werden kann." Hier ist keine Rede von Dumping-Preisen oder auch nur der Orientierung an einem Angebotspreis. Mein Ausgangspunkt ist exakt der von Ihnen in Ihrem ersten Punkt dargelegte realistische Aufwand für die zu erledigende Aufgabe unter normalen Bedingungen. Weiter gehen Sie auf die Problematik ein, wie mit Projekten zu verfahren ist, die, aus welchen Gründen auch immer (z.B. Gewinnung eines renommierten Referenzkunden, Ausstechen der Konkurrenz usw.) zu Kampfpreisen angeboten werden. Meine Aussage ist hierbei lediglich, dass es keinen Sinn hat, in dieser Situation die Angebotskalkulation gegenüber dem potentiellen Auftraggeber mit Dummy-Positionen zu erhöhen. Die Frage der internen Kalkulation in diesem Falle behandle ich gar nicht, da dies den Rahmen des Tipps gesprengt hätte. Ich erlaube mir hier lediglich darauf hinzuweisen, dass das Vorgehen mit Kampfpreisen Aufträge zu akquirieren im Bereich des Bauwesens weit verbreitet ist. Der Gewinn eines Projekts wird dann über das Nachtragsmanagement erwirtschaftet. Deshalb ist das Claim-, Nachforderungs- oder Nachtragsmanagement bei Bau und Anlagenbauprojekten ein unverzichtbarer Bestandteil des Projektmanagements, ja es gibt sogar auf Claimmanagement spezialisierte Beratungsunternehmen. Man mag dies unterschiedlich werten und in der Bau-Community wird dies auch sehr kontrovers diskutiert. Tatsache ist, dass in einer der größten Projektbranchen die Kalkulation des angebotenen Preises typischerweise unter dem der notwendigen Aufwände liegt. Falls Sie sich fragen, warum öffentliche Bauten stets teurer als geplant werden, haben Sie nun die Antwort. Bei Ihrem zweiten Punkt kann ich leider Ihre Kritik noch viel weniger nachvollziehen. Selbst wenn Sie davon ausgehen, dass die minimale Aufwandsschätzung eines IT-Projekts um typischerweise 20% überzogen wird, liegt dies noch vollständig in dem von mir beschriebenen Rahmen. Ich führe aus: "Es sollte als grobe Faustregel mindestens 10% über dem Minimalbudget liegen, maximal aber das Doppelte dieses Budgets betragen." Das Doppelte bedeutet einen finanziellen Puffer von 100%. Die von Ihnen genannten Werte liegen also vollständig in der von mir genannten Spannbreite. Noch dazu, als, wie oben dargelegt, meine Definition des Minimalbudgets die realistisch zu erwartenden Aufwände umfasst. Ich gehe als selbstverständlich davon aus, dass kein professionell agierender Projektmanager Budgets unterhalb realistisch zu erwartender Aufwände überhaupt in Betracht zieht. Im gleichen Sinne passen auch die in Ihrem dritten Absatz genannten Größen für einen finanziellen Puffer noch problemlos in die von mir genannten Schwellen, die ich noch dazu lediglich als "grobe Faustregel" bezeichne. Wenn ich Ihren letzten Absatz aufmerksam lese, so fällt mir auf, dass Sie Ihre interne Projektkalkulation mit dem Vertrieb abstimmen und der Vertrieb das Angebot gegenüber dem Kunden erläutern muss. Verzeihen Sie, wenn ich jetzt frei von der Leber weg sage: Genau dafür brauchen Sie die Dummy-Positionen! Nämlich um Ihr Team vor unrealistisch niedrig angesetzten Preisen zu schützen, um dem Vertrieb Argumente für den Verkauf zu liefern und um dem Kunden das gute Gefühl geben zu können, eine Leistung billiger zu bekommen. Falls beim Kunden nicht die Fachabteilung oder der Geschäftsführer selbst mit dem Lieferanten verhandelt, sondern dies über seine Einkaufsabteilung abwickelt, dann werden Ihre Projekte ohne Dummy-Positionen nicht mehr lebensfähig sein. Ich habe selbst erlebt, dass ein einvernehmlich zwischen Fachabteilung des Auftraggebers und Auftragnehmer kalkuliertes Projekt (nach dem Prinzip der "Open Books") scheiterte, weil der Einkauf des Auftraggebers anschließend eine pauschale Kürzung um 10% durchsetzen wollte. Der Einkauf muss sich eben auch rechtfertigen und kann dies nur durch den Nachweis, dass er die Angebote von Lieferanten im Preis gedrückt hat. Ich beschreibe in meinem Tipp lediglich das Spiel, das ich nicht erfunden habe und für das ich nicht verantwortlich bin. Mein Ziel ist, dass Praktiker ein wenig Orientierung erhalten, um sich in der zugegebenermaßen sehr vielfältigen und komplexen Welt der Projekte zurecht zu finden. Die Verantwortung für Planung, Verhandlung und Umsetzung kann ich niemandem abnehmen. Sie dürfen selbstverständlich über dieses Spiel empört sein, es für moralisch unverantwortlich oder inhaltlich unsinnig halten. Sie dürfen auch Ihre Projekte knapp kalkulieren und beständig im Clinch mit dem eigenen Vertrieb und den Kunden leben. Das ist Ihr gutes Recht. Es hätte mich allerdings gefreut, wenn Sie Ihre Kritik auf diese aus Ihrer Sicht schlechte Realität beschränkt hätten und nicht mir als Autor in nicht nachvollziehbarer Weise Fehler unterstellt hätten.

 

Lieber Herr Dr. Angermeier, erst einmal danke für Ihre ausführliche Antwort. Ich habe sie aufmerksam gelesen, offen gesprochen aber an manchen Stellen nicht verstanden, und auch mich an einigen Stellen nicht verstanden gefühlt. Kann es sein, dass wir im großen Stil aneinander vorbei reden? Nur auf Ihren letzten Punkt möchte ich noch einmal eingehen. Sie schreiben: "Sie dürfen auch Ihre Projekte knapp kalkulieren und beständig im Clinch mit dem eigenen Vertrieb und den Kunden leben. Das ist Ihr gutes Recht." Mir ist nicht bewusst, wo ich jemals empfohlen hätte, knapp zu kalkulieren? Im Gegenteil: Ich kreide Ihrem Artikel explizit an, dass er "10% über dem Minimalbudget" als akzeptable Puffergröße empfiehlt, wo man nach allen Erfahrungen damit rechnen muss, dass der so entstehende Aufwand noch erkennbar unter dem wirklich Aufwand liegen wird. Und das gilt im übrigen nicht nur für die IT-Branche, aus der ich tatsächlich stamme, auf die mein PM-Wissen aber nicht "beschränkt" ist. Für den von Ihnen zitierten Baubereich ist nach allem veröffentlichten Wissen eine solche Ungenauigkeit in der Aufwandsvorhersage durchaus ebenso typisch. Ich empfehle also, den Tatsachen ins Auge zu sehen und deutlich größere Puffer zu kalkulieren, als Sie in Ihrem Artikel nennen. Mit wem diese Puffer dann abgestimmt werden müssen, oder ob ich sie in der Kalkulation verstecken muss, das hängt nun empfindlich von der Organisation des Unternehmens ab und ist nicht mein Thema. Die Verwirrung (das Missverständnis?) zwischen uns entsteht mindestens dadurch, dass Sie den Begriff "Kalkulation" auch für die Preisdarstellung gegenüber dem Kunden verwenden. Das habe ich nach Ihrer Antwort nun verstanden. Wenn ich Studenten gegenüberstehe, dann empfehle ich denen immer, lieber mit den Begriffen "Aufwandsschätzung" (für die interne "Kalkulation") und "Angebot" (für die externe) zu hantieren. Der Begriff Kalkulation suggeriert eine berechenbare Genauigkeit, die dem bezeichneten Dokument niemals inne ist. Das eine, interne, ist eine Schätzung der zu leistenden Tätigkeiten. Das andere, externe, eine Darstellung der Leistungen und Preise für den Auftraggeber. Beide Dokumente müssen erstaunlich wenig miteinander zu tun haben (dürfen es aber natürlich gerne). Ich hätte mir, auch angesichts Ihrer Antwort, eine klarere Trennung dieser beiden, gleich wichtigen Dokumente gewünscht. Ich nehme aber gerne zur Kenntnis, dass Sie (zu) knappen Kalkulationen nicht das Wort reden wollten. Wenn ich Sie da falsch interpretiert habe, dann bedaure ich das sehr erfreut |-)