Die Projektgröße alleine entscheidet nicht, ob unerwartete Ereignisse während der Projektdurchführung auftreten. Auch kleinere Projekte können beispielsweise unter Termintreue leiden. Neben den unerwarteten Ereignissen beschäftigt sich Olaf Clausen im 3. Teil der Artikelserie mit der Dokumentation während der Projektdurchführung. Außerdem prüft er, ob sich bekannte Vorgehensweisen aus dem Projektmanagement auch für kleinere Projekte eignen und sich deren Methoden den Projektanforderungen entsprechend übertragen lassen.
Die Projektgröße alleine entscheidet nicht, ob unerwartete Ereignisse während der Projektdurchführung auftreten. Auch kleinere Projekte können beispielsweise unter Termintreue leiden. Neben den unerwarteten Ereignissen beschäftigt sich Olaf Clausen im 3. Teil der Artikelserie mit der Dokumentation während der Projektdurchführung. Außerdem prüft er, ob sich bekannte Vorgehensweisen aus dem Projektmanagement auch für kleinere Projekte eignen und sich deren Methoden den Projektanforderungen entsprechend übertragen lassen.
Die Projektgröße alleine entscheidet nicht, ob unerwartete Ereignisse während der Projektdurchführung auftreten. Auch kleinere Projekte können beispielsweise unter Termintreue leiden. Neben den unerwarteten Ereignisse wollen wir uns in diesem Artikel mit der Dokumentation während der Projektdurchführung beschäftigen und bekannte Vorgehensweisen auf die Eignung bei kleineren Projekte prüfen und übertragen.
Trotz guter Planung können während der Projektdurchführung verschiedene unerwartete Ereignisse eintreten. Im wesentlichen sind das:
Die genannten Punkte bedingen sich teilweise gegenseitig.
Die Frage ist, ob zeitliche Probleme ein unerwartetes Ereignis oder vermeidbar sind. Gehen wir davon aus, dass sich trotz guter Planung der Aufwand durch Fehleinschätzungen deutlich erhöht hat. Gerade bei kleineren Projekten ist das kritisch, da sich ein Mehraufwand auch in geringer Höhe auf das Gesamtprojektvolumen sehr stark auswirkt. Wichtig ist es in diesem Fall, mittel Zeiterfassung den Mehraufwand genau zu dokumentieren. Vielleicht besteht nach erfolgreicher Projektbeendigung dann die Möglichkeit, diesen Aufwand nachträglich zu vergüten. Oder er wird bei einem möglichen Folgeprojekt berücksichtigt.
Zeitliche Probleme können aber auch durch Krankheit oder andere von außen verursachte Größen entstehen. Das bedeutet, dass der Aufwand sich zwar nicht erhöht hat, aber die geplante Zeit nicht für das Projekt eingesetzt werden konnte. Diese zeitliche Verschiebung kann auch auftreten, wenn die Prioritäten anders gewählt wurden als vorgesehen. So oder so, wie geht man in diesem Fall vor? Es gibt meiner Meinung nur eine "saubere" Lösung: Das Problem muss sofort beim Kunden angesprochen werden. Wichtig ist dabei, dass ein geänderter Zeitplan vorgestellt wird. Der Kunde muss erkennen können, dass zwar ein Problem aufgetreten ist, dass es aber auch schon einen Notfallplan gibt.
Insbesondere bei der Durchführung von Projekten in neuen Branchen bzw. Arbeitsbereichen kann es dazu kommen, dass inhaltliche Probleme auftreten. Die Materie ist dem Programmierenden nicht vertraut, so dass der Umfang von Aufgabenstellungen falsch eingeschätzt wird. Das Problem kann vermieden werden, wenn bei Projekten in neuen Bereichen für einige Aufgaben lediglich Stundensätze und nur ein grober Umfang definiert werden. Jetzt kann zwar über die Formulierungen im Angebot oder Pflichtenheft diskutiert werden. Das ist allerdings müßig. Gerade bei kleineren Projekten gibt es nur die Möglichkeiten, das Projekt im Einvernehmen mit dem Kunden abzubrechen und die investierten Stunden als "Lehrgeld" anzusehen oder neu über das Volumen zu verhandeln.
Insbesondere stelle ich inhaltliche Probleme bei Projekte im Handwerksbereich fest. Ein Handwerksmeister, der sein Handwerk gut versteht, arbeitet nicht jeden Tag mit einem Softwareentwickler zusammen. Daher steckt keine böse Absicht dahinter, wenn einige - in den Augen des Handwerksmeisters - Selbstverständlichkeiten nicht erwähnt werden. Ich empfehle Ihnen daher, bei kleineren Projekte in neuen Branchen die Entwicklung im wesentlichen vor Ort beim Kunden durchzuführen. Dem Handwerker ist meistens klar, dass Softwareentwickler gut bezahlt werden. Er kann nur den Aufwand der Programmierung nicht einschätzen und möchte nicht den Eindruck gewinnen, übers Ohr gehauen zu werden.
Inhaltliche Probleme können aber auch in anderem Zusammenhang auftreten. Kleine Projekte werden häufig als reine F&E-Projekte durchgeführt. Leider vergessen viele Entwickler, das den Kunden mitzuteilen. Es ist wirklich wichtig, den Kunden darauf bereits vor dem Projektbeginn hinzuweisen. Viele Fehler treten gerade durch die Verwendung von nicht ganz fertigen Entwicklungswerkzeugen auf. Auch der Entwickler ist bei diesen Fehlern machtlos. Sollten allerdings Kompetenzprobleme auftreten und Sie sich mit dem Produkt doch nicht so gut auskennen, wie Sie vielleicht gedacht haben, so sollte das Projekt so früh wie möglich beendet werden. Bei kleineren wie auch bei größeren Projekten halte ich es für vollkommen legitim, Fehleinschätzungen (sowohl bei Kompetenzen wie auch Ressourcen) bekannt zu geben oder nach anderen Lösungen zu suchen. Bei größeren Projekten kann man sich in der Regel das fehlende Know-how hinzukaufen. Bei kleineren Projekte ist dies meist auf Grund von Volumen und Zeitvorgaben nicht möglich.
…
