Man spricht viel und gerne über Projekte, Projektarbeit etc. Oft ist das nur ein aufgeblasenes Daherreden sich selbs sehr wichtig nehmender BWLer. Es gibt aber Gelegenheiten, bei denen man zu einem guten Buch zu diesem Thema von alleine greifft. Wenn man diese Regeln nicht befolgt, kann es sogar die zu einem Schiffbruch. Ich sage nicht, dass man ein Software-Projekte-Buch gelesen haben muss, um dies machen zu können (sonst würden die Autoren dieser Bücher sinvollerweise nur voneinander abschreiben können). Der Mensch ist als vernunftbegabtes Wesen imstande, (nur) unter Einsatz des eigenen Verstandes Gott zu erkennen – die Prinzipien guter Projektführung umso mehr! Sie finden hier eine kurze Beschreibung eines „Anti-Projektes“ – also eines Projektes, welches jede Erkenntnis diesbezüglich außer Acht lässt und dennoch nicht soo selten pratiziert wird.
Wie startet man mit einem Antiprojekt?
Man beginnt alles sofort! Ohne Bunget, ohne konkretes Ziel und ohne Auftrag. Am besten ohne die Bereitschaft einen harten Schnitt zu machen – man will ja dieselbe Sosse zum dritten Mal verfeinern (in der Hoffnung, dass wenn man genug satzt, sie schon irgendendwann nicht salzig schmecken wird).
Was ist das wichtigste an einem Antiprojekt?
Die Ziele nicht genau zu definieren, am besten jedoch, nicht einmal ein Oberziel zu haben. Wenn man nicht weiß, was man bezwecken will, kann man viel entspannter arbeiten und erreicht immer seine Ziele.
Wie erstellt man einen Antiprojektplan?
Vorausgesetzt, man kennt die Realität gar nicht, braucht man sich nicht sehr anzustrengen… Sonst sollte man im Irrglauben verharren, alle beteiligten verbringen 80% ihrer Zeit in Erwartung auf einen Arbeitsauftrag. Anschliessend zählt man die Köpfe, ernennt sich selbst zum Projektleiter (wenn man diesen Titel offiziell noch nicht hatte), und teilt dem Rest nach Halbwärtszeit-Prinzip die Aufgaben in folgender Reihenfolge zu: 50% der Mitarbeiter für interne Kommunikation, vom Rest (ca 50%) die Hälfte (also ca 25%) für Koordination und die letzten zwei Teile jeweils für sonstige Aufgaben und Entwicklung.
Wann sollte man die Startphase eines Antiprojektes einleiten?
Am besten noch vor der Analyse – man will ja nicht erfahren, dass es etwas Ähnliches schon gibt oder dass man auf ein totes Pferd setzt (falsche Software, falsche Entwicklungswerkzeuge etc). Sollte sich ein übereifrieger Mitarbeiter finden und eine solche Analyse gemacht haben, ist sie sofort zu vernichten und der Kollege zu entlassen!
Mit welchem Wort sollte man angeben?
Das Stichwort (auch für Bullshit-Bingo geeignet) ist „Effektivität“. Es bringt zum Ausdruck, dass man viel arbeiten musste (nicht unbedingt zielgerichtet), um etwas zu erreichen… „Effizienz“ würde bedeuten, man hat es schnell und problemlos hingekriegt hat – deshalb ist dieses Wort zu vermeiden.
Wie behindert man sich am besten in einem Software-Antiprojekt?
Man nutzt ein System, welches keine „Konflikte“ erlaubt, sondern über „konkurrierende Zugriffe“ abläuft. „Konflikte“ (der Unterschied zwischen der Version des einen Entwicklers und der des anderen) sind lösbar. Mit konkurrierenden Zugriffen hat man dejenige recht, der zuletzt abspeichert (egal, was der Kollege in dieser Zeit verändert hat). Als eine Zwischenlösung bietet sich das Locking an: nur einer darf an einer Stelle arbeiten, der Rest hat zu warten!
Wie sorgt man dafür, dass man nie wieder ein Projekt anvertraut bekommt?
Man mischt im eigenen Antiprojekt die wichtigsten Komponenten:
- Man setzt auf ein „totes Pferd“ (eine veraltete Insellösung), damit ist die Lösung kurz nach der Fertigstellung veraltet
- Man definiert keine Ziele oder nur sehr schwammig, damit man nach Lust und Laune hier und da nachbessern kann
- Man macht unrealistische Zeitvorgaben – oder besser gar keine
- Man erzeugt viele Abhängigkeiten von externen Beratern und Software und mixt es mit eigenen Entwicklungen: am Ende kann man jedem die Schuld in die Schuhe schieben, bevor man in der eigenen Entwicklung nach Fehlern sucht
- Man verzichtet auf Standards und Normen: Keine Standards, schon gar nicht in einer bestimmten Version! Programmieren tut man prozessual in einer sehr seltenen Sprache, ohne Funktionen und Routinen. Objektorientierung ist böse!
- Man befragt die Kunden nicht, ob das Zwischenergebnis in die richtige Richtung geht. Am besten ganz ohne Kunden entwickeln!
Mit diesen wenigen Ratschlägen gelingt jedes Antiprojekt!