Zu Anfang meiner beruflichen Laufbahn herrschte eine der IT-Blasen. Personalvermittler telefonierten die Büros der wissenschaftlichen Mitarbeiter an der Universität ab. Freunde und Bekannte versuchten sich die Anwerbeprämien zu verdienen, in dem Sie geradezu verzweifelt ihren Bekanntenkreis nach Informatikern absuchten. Unter den reichlichen Anfragen war auch ein großer Elektronikkonzern. Dessen Personalabteilung sehr selbstbewusst ein Einstiegsgehalt offerierte, das nicht viel über dem Gehalt des öffentlichen Dienstes lag. Als Begründung führte man diverse Punkte an; im Übrigen könne man die Arbeit als wissenschaftlicher Mitarbeiter nicht als Berufserfahrung anrechnen. Mit dieser Meinung lagen sie so falsch.
In einer Projektarbeit oder einem Seminar teilt sich die Studierenschaft grob in zwei Teile:
- Studierende, die kurz nach Verkündung des Vorhabens zur Aufgabe sinnvolle Nachfragen stellen.
- Studierende, die kurz vor oder nach Abgabetermin ins Büro kommen und versuchen klar zu machen, warum die Aufgabe nicht umgesetzt werden kann. Selbst wenn die vorgelegten Punkte valide sind: Egal, es ist zu spät.
Im Projektgeschäft begegnen einem genau die selben Leute: Mit dem Kunden werden Arbeitspunkte festgelegt, abgesprochen und harren ihrer Umsetzung. Der Projektmanager fragt wöchentlich nach und bekommt die Rückmeldung „Mach Dir mal keine Sorgen“. Insbesondere wenn sich die Arbeitspakete häufen, etwa kurz vor einem Meilenstein: „Ich konnte diese Aufgabe nicht umsetzen, weil…“. Der Inhalt ist nun genau wie bei den Studenten teilweise valide. Aber auch hier gilt: Egal, es ist zu spät.
Solche schlechten Projektmitarbeiter müssen übrigens in ihrem Fachgebiet gar nicht schlecht sein. Meist liegt es an fehlendem Zeitmanagement, genau wie bei den Studierenden. Wenn die Aufgabe analysiert und gut verstanden, ggf. eine kleine Demo entwickelt wurde, kann diese getrost auf einen späteren Zeitpunkt gelegt werden. Alles andere ist Mittelmaß. Bei der Erziehung schlechter Projektmitarbeiter setzte ich ganz oft auf diesen Punkt. Oft ist es etwa so: Der Kollege findet sich technisch toll, das Ergebnis ist jedoch eher Mittelmaß mit der Begründung, der Kunde hat ja nicht… Es liegt also am Kunden vor dem Hintergrund, dass der Kunde gar nicht im notwendigen Maß gefragt wurde. Dies muss sorgfältig und oft entkräftet werden.
Es gibt noch eine andere Art der Abhilfe: Das enge managen des Projektplans. Dies hilft dem Projekt, jedoch wird bei schlechten Projektmitarbeitern eher der gegenteilige Lerneffekt erzeugt. Sie kümmern sich noch weniger um ihr Zeitmanagement. Übrigens auch hier eine Lehre aus der Universität: Gute Projektmitarbeiter stört es kaum, wenn man sie derart dicht managt und ihre kreative Freiheit beschneidet. Sie nutzen je nach Charakter freie Zeiten für tolle Ideen oder schlagen rechtzeitig aktiv Änderungen am Projektplan vor.
Normale Projekte verlaufen auch so wie universitäre Projektgruppen, sie starten mit maximaler Freiheit und Enden in starrem Korsett. Schlechte Projektmanager starten wie lässige Cowboys und schalten plötzlich auf Hart und Unerbittlich. Gute Projektmanager wissen aus Erfahrung strukturiert zu starten, straffen die Zügel frühzeitig und abgestuft. Sehr gute Projektmanager kennen ihre Pappenheimer schon nach wenigen Tagen und lassen den guten Projektmitarbeitern den Raum ihr Ding durchzuziehen. Das ist aber wirklich die Kür, denn warum muss der technisch tolle Kerl jede Woche liefern und der Kollege hat seine Freiheit?