GULP >> GULP Knowledge Base >> Entertainment >> Leitfaden zur Sabotage von IT-Projekten, Teil 1

Leitfaden zur Sabotage von IT-Projekten:
105 taffe Taktiken für Teamleiter

Teil 1 | Teil 2 | Teil 3 | Teil 4

(Dezember 2005)


Das kann doch nicht wahr sein - jetzt steht das Projekt schon wieder auf der Kippe! Wie schaffen das die Projektverantwortlichen eigentlich jedes Mal aufs Neue? Stellen Sie sich diese hochbrisante Frage des Öfteren, dann kennen Sie anscheinend den Leitfaden zur Sabotage von IT-Projekten noch nicht. In dem unterhaltsamem "Insider"-Ratgeber verrät der zertifizierte IT-Berater und Trainer Bernd Schulte Osthoff 105 diplomatische Taktiken, mit denen jedes IT-Projekt erfolgreich vereitelt werden kann. In einer vierteiligen Serie stellt GULP die einzelnen Methoden vor, die - obwohl mit einem Augenzwinkern erzählt - leider viel zu oft Realität sind. Oder haben Sie sich noch nie gefragt, was das Dartboard eigentlich im Büro Ihres Teamleiters zu suchen hat?

 

Wählen Sie Projekte mit unmöglichen Terminvorgaben.
nach oben
   
1) Bei Projektausschreibungen ist es üblich, unerreichbare und unrealistische Termine zu verlangen, wenn diese überhaupt angegeben werden. Das weiß auch Ihre Konkurrenz. Also bewerben Sie sich. Sagen Sie On-Time&On-Budget zu. Das machen alle so. Wenn Sie den Auftrag erst einmal haben, wird Ihre Firma schon irgendwie Geld verdienen.
2) Entwickler lieben Herausforderungen, also erzählen Sie ihnen, dass die Termine mit sportlichem Ehrgeiz locker zu schaffen sind.
3) Dann ziehen Sie sich in Ihr Büro zurück und lachen herzlich.

 

Übernehmen Sie nur Festpreis-Projekte!
nach oben
   
4) Projekte nach Aufwand sind für Zögerer und Zauderer. Nur bei einem Festpreis-Projekt können Sie sicher sein, dass alle Vorgaben, Vereinbarungen und Aufwandsschätzungen auf jeden Fall weitab von jeder Realität liegen. Nur hier haben Sie eine sichere Aussicht auf ein vollständig gesprengtes Budget.
5) Bei einem bereits laufenden Festpreis-Projekt ist das gesamte Budget mit hoher Wahrscheinlichkeit schon längst aufgebraucht. Nichts entfaltet solche Wirkungen wie unbezahlte Überstunden.
6) Aus Sicht des Kunden übernehmen nur absolute Profis ein Festpreis-Projekt. Das bedeutet für Ihr Team den ständigen Drang zu kreativen Kosteneinsparungen und zusätzlicher Produktivität.

 

Arbeiten Sie nur für weit abgelegene Kunden.
nach oben
   
7) Sie brauchen Ihrem Team keine Unterbringungsalternativen bieten; nehmen Sie, was der Kunde hat: ausgediente Lagerräume, fensterlose Keller oder unbelüftete Abstellräume.
8) Vermeiden Sie Kunden im Innenstadtbereich; Ihr Team hätte zuviel Ablenkung und Ausweichmöglichkeiten für Essen und Einkaufen.
9) Ziehen Sie Kundenlocations in Industriegebieten oder sozialen Randbereichen vor; damit vermeiden Sie überlange Spaziergänge Ihrer Mitarbeiter in den Pausen.

 

Weniger ist mehr bei der Projektbesetzung.
nach oben
   
10) Besetzen Sie Ihr Projektteam niemals nach den angebotenen oder beauftragten Qualifikationen.
11) Ein Jahr Berufserfahrung genügt für die Position eines Gruppenleiters. Setzen Sie das Team unter ständigen Druck.
12) Zwei Jahre Berufserfahrung genügen für die Position eines Projektleiters. Auch ohne vorherige Führungserfahrung.
13) Drei oder mehr Jahre Berufserfahrung sind zu teuer. Hier besteht außerdem die Gefahr selbständigen Denkens und Handelns, unter Missachtung Ihrer Autorität.

 

Berufen Sie nur Externe ins Team.
nach oben
   
14) Ignorieren Sie die erfahrenen Mitarbeiter in Ihrer Firma, die gerne mit den neuesten Technologien dieses neuen Projektes arbeiten und lernen würden. Viele dieser Entwickler sind ohnehin an die oder über 40.
15) Unvorbelastete Junginformatiker, frisch von der Uni, sind ideal für die Anforderungs- und Designphasen im Projekt.
16) Verschaffen Sie unbedingt nur den Externen den Zugang zu den neuesten Technologien. Die Internen kommen mit den Schwächen der alten Systemen Ihrer Firma besser klar.
17) Zahlen Sie den Externen einen deutlich höheren Anteil am Budget und lassen Sie dies inoffiziell alle wissen. Das spornt alle gleichermaßen an.

 

Aufwand ist relativ.
nach oben
   
18) Der Projektaufwand folgt den Regeln der Quantenmechanik, ist also abhängig vom Beobachter und von niemandem wirklich genau zu bestimmen. Sie haben die freie Auswahl.
19) Für eine erste Schätzung empfiehlt sich die DB-Methode: nehmen Sie ein DartBoard, werfen Sie drei mal, und errechnen Sie den Mittelwert. Informieren Sie NICHT Ihr Team.
20) Lassen Sie Ihr Team den Aufwand selbst ermitteln. Weisen Sie die Ergebnisse mindestens n-1 Mal als zu hoch zurück (n = Anzahl der verbleibenden Projektphasen).
21) Der Kunde weiß, dass er keinen Einfluss auf den Aufwand hat. Lassen Sie ihn nicht merken, dass Sie wissen, dass er das weiß.

 

Nutzen Sie das Sparta-Prinzip: Engpass Hardware.
nach oben
   
22) Maximal ein Festnetz-Telefon pro Arbeitsgruppe. Nur für den Ernstfall bekommt der Kunde zu Projektbeginn die Handynummern des gesamten Teams.
23) Remote-Zugänge dürfen nur nach Genehmigung durch das Controlling genutzt werden. Die Genehmigung muss wöchentlich erneuert werden.
24) Das Alter der Entwicklungssysteme sollte proportional zur Betriebszugehörigkeit der Mitarbeiter sein. Aufrüstungen oder Updates vor und während des Projekts sind abzulehnen.
25) Sind Aufrüstungen oder Updates nicht zu vermeiden, maximieren Sie den Spieltrieb-Faktor.

Im nächsten Teil erfahren Sie, mit welchen Taktiken Projektergebnisse erfolgreich durchkreuzt werden können.

 

Nähere Informationen erhalten Sie vom Autor Bernd Schulte Osthoff unter www.schulteosthoff.de extern
Der Autor behält sich alle Rechte am Artikel vor. © 2005 Bernd Schulte Osthoff

 

Kommentar zum Artikel

"Aua, tut weh aber ist leider so. (September 2007)"

"Kommt mir irgendwie auch bekannt vor. (Juli 2007)"

"Sie haben noch einen Absatz vergessen: Übernehmen Sie nur Projekte außerhalb Ihres Kulturkreises! Wer schon mal ein internationales Projekt mit Engländern und Franzosen realisiert hat, weiß wovon ich rede. (Januar 2006)"

"Richtig schmerzhaft - und wahr... (Dezember 2005)"

"wieso kommt mir das alles so bekannt vor? (Dezember 2005)"

"Ich dachte jetzt kommt eine Satire, aber dann habe ich nur ein Situationsbeschreibung gefunden. (Dezember 2005)"

"Köstlich und real. (Dezember 2005)"

"LEIDER ISSES SO immer noch ... (Dezember 2005)"

"Treffer. (Dezember 2005)"

"..nicht unberechtigt... (Dezember 2005)"

"Etwas überzogen aber bemerkenswert nah an der Realität, LEIDER! (Dezember 2005)"

"Wie die Faust auf's Auge. (Dezember 2005)"

"Weil das ständige Diskutieren darüber, wie man es besser machen sollte nur wenig Früchte trägt, hilft vielleicht dieser Denkanstoß weiter. (Dezember 2005)"

"Klasse! Mir fehlt noch: 'Nehmen Sie stets die billigsten Fachkräfte. Qualität, Erfahrung und Stundensatz haben eh nichts miteinander zu tun.' (Dezember 2005)"

"Trifft meine Erfahrungen zu 90% - Super! (Dezember 2005)"

"Köstlich amüsiert. (Dezember 2005)"

"Der Autor hat die Realität leider sehr gut getroffen. (Dezember 2005)"

"Was soll ich dazu noch sagen. Das ist voll und ganz aus dem prallen Leben :-)) (Dezember 2005)"

"Über dieses Thema kann man noch viel mehr schreiben, von der launigen Glosse über Zeitungsartikel à la Toll-Collect-Chaos bis zur 100% ernsthaften Doktorarbeit. Fälle wie die hier beschriebenen werden so lange vorkommen, wie Personen ohne Fingerspitzengefühl und Führungsqualitäten am Werk sind - also immer. (Dezember 2005)"

"Der Mann spricht mir aus dem Herzen. Ich habe trotzdem herzlich gelacht! (Dezember 2005)"

"Kommt der Wirklichkeit sehr nah. (Dezember 2005)"

"Super :-( besonders die Forderung nach den Handynummern der Teammitglieder ist sehr realistisch und wird gerne praktiziert...bin zum Glück kein Teamleiter (mehr), sondern Oracle DBA Freiberufler) (Dezember 2005)"

"Sehr guter Artikel, trifft in einzelnen Rubriken voll ins Schwarze (dartboard)!! (Dezember 2005)"

"Sehr gut und sehr passend. Ich bin schon gespannt auf die weiteren Teile :-) (Dezember 2005)"

"Schon amüsant. Den ersten Punkt muss man ein bisschen relativieren. Knappe Terminvorgaben? Wer definiert, was knapp ist. Wenn Sie sich auf die Entwickler verlassen, dann kalkulieren sie einen riesen persönlichen Puffer in ihrer Abschätzungen ein. Dazu kann ich, als Projektleiterin, die Ansätze von Critical Chain Management als Denkanregung empfehlen. (Dezember 2005)"

"Sehr amüsant! (Dezember 2005)"

"....die reale Projektwelt. Da sage noch einer IT ist langweilig. (Dezember 2005)"

"Ähnlichkeiten mit der Realität sind nicht von der Hand zu weisen und sicherlich beabsichtigt. (Dezember 2005)"

"Leider nur allzu wahr. (Dezember 2005)"

Ihr Feedback GULP Feedback: Ihre Meinung ist uns wichtig!
Wie beurteilen Sie diesen Artikel?
sehr gut
1
2
3
4
5
6
schlecht
Ich bin tätig als...
Freiberufler
Projektanbieter
weder noch
  Falls Sie eine Frage an GULP haben,
wenden Sie sich bitte direkt per E-Mail an info@gulp.de.

Seite drucken Seiten drucken
Zum Seitenanfang nach oben