Warum überhaupt "undogmatisch"?

Wenn Techniker über Projektmanagement reden oder schreiben geht es in der Regel um Vorgehensmodelle - was heute Agile Development ist, war vor ein paar Jahren der Rational Unified Process (kennt den überhaupt noch jemand?) und in der Computersteinzeit das Wasserfallmodell, das sich nach wie vor großer Beliebtheit erfreut (es ist also sozusagen der Quastenflossler unter den Projekt-Management-Moden...). Zu Phasen, Prozessen, Erhebung von Anforderungen, Architekturen und dergleichen mehr möchte ich mich aber eher weniger auslassen (deshalb habe ich mir erlaubt dieses Blog als undogmatisch zu bezeichnen), das können andere besser.

Tatsächlich gibt es Grundprinzipien und Tricks die unabhängig vom Vorgehensmodell in IT-Projekten immer mal wieder wichtig werden und die gerade für Einsteiger ausgesprochen hilfreich sind. Während ich versucht habe, zumindest einige davon zu formulieren, ist mir aufgefallen, wie schwer es ist sie griffig zusammenzufassen. Vielleicht ist genau das der Grund dafür dass man sie so selten liest. Einige Beispiele worum es geht:

• Festpreisangebote ohne ausreichendes Briefing
• Kundenführung
• Die "Hidden Agenda" des Kunden und der Projektkollegen
• Projektpolitik. Wie hält man den Hof sauber? (ein echtes ÄhBäh-Thema, was ein echter Tekkie ist steht über solchen Dingen. Aber wartet ab bis ich was dazu schreibe...)
• Richtiges Eskalieren
• Was tun wenn es eng wird?