Seit Jahren erarbeitet er als Berater für seine Kunden Konzepte zur Optimierung ihres Projektmanagements und begibt sich auf die Suche nach der dazu passenden Software. Und in jedem Projekt begegnet ihm irgendein Peter Teubner. Freilich immer unter anderem Namen, aber die Erkennungszeichen sind die gleichen: keine Ahnung von Projektmanagement und unfähig, eine entsprechende Software zu bedienen.

Zugegeben, wer mit Teubner über Projektmanagement redet, merkt bald: Mit diesem Thema fremdelt er. Teubner ist Chemieingenieur, er versteht sich als Macher. Planung ist für ihn ein notwendiges Übel, Budgettreue hält er für eine Sekundärtugend und das Wort "Management" hört sich aus seinem Munde an, als spräche er den Namen einer unheilbaren Krankheit aus. Aber wenn er in seinem Element ist, beeindruckt er mit technischem Wissen und jahrelanger Erfahrung.

Teubner als "fool" zu bezeichnen, wäre ignorant. Diese Ignoranz aber leistet sich Markus Hartmann, und das stellt ihn vor drei Probleme.

Die Welt des fools

Das erste Problem: Ohne Teubner ernst zu nehmen, wird Hartmann keine Lösung finden, die in der Praxis Bestand hat. Einen Königsweg, der auf nahezu alle Unternehmen identischer Branche und Größe passt, gibt es nicht. Will Markus Hartmann seinem Kunden eine Lösung ersparen, die mit großem Budget eingeführt und anschließend ignoriert wird, muss er sich auf ihn einlassen, kurzum: Er wird den Kosmos eines Peter Teubner wohl oder übel betreten müssen.

Das bedeutet keineswegs die permanente Neuerfindung des Rads. Natürlich kann und muss Hartmann aus dem Fundus seiner Erfahrungen aus früheren Projekten schöpfen. Aber er sollte nicht glauben, dass er bereits zu Beginn seiner Tätigkeit auf Basis einiger Indizien die Lösung kennt. Auch erfahrene Berater entwickeln Lösungen erst im Laufe eines Projekts.

Gegen ein im Vorfeld geplantes und damit stringentes Vorgehen ist nichts einzuwenden, ganz im Gegenteil. Ein Zuviel an Planung kann jedoch einengen. Wer beispielsweise einen Workshop detailreich plant, hat oft – basierend auf Erfahrungen aus ähnlichen Projekten – Teilergebnisse oder Lösungsansätze vor Augen, die sich im Workshop jedoch erst entwickeln sollen. Anders ausgedrückt: Wer glaubt, den Weg bereits zu kennen, wird sich an einer Weggabelung nur schwer auf eine andere Abzweigung einlassen.

Die Arbeit eines Beraters ist der eines Handwerkers gar nicht unähnlich. Zu einem Wasserschaden gerufen, wird dieser seinen vielfach erprobten Werkzeugkasten mitbringen. Welches Werkzeug dann allerdings zum Einsatz kommt, entscheidet er situativ vor Ort.

Verzahnung von Prozess-Ebenen

In den Kosmos seines Kunden wird sich Markus Hartmann noch aus einem anderen Grund begeben müssen. Und hier steht er vor seinem zweiten Problem: Projektmanagement-Prozesse kann man nicht isoliert von Wertschöpfungs- und Unterstützungsprozessen betrachten.

Für Hartmann ist das eine neue Erkenntnis, denn bislang hat er genau das getan: Er hat Prozesse wie z.B. das Staffing von Projekten oder die Ist-Daten-Erfassung losgelöst von den sonstigen Arbeitsabläufen des Unternehmens betrachtet. Natürlich nicht komplett losgelöst, das geht ja allein schon deshalb nicht, weil Teubner immer wieder davon anfängt und nur schwer folgen kann, wenn Hartmann ihn mitnehmen will auf die Ebene der Projektmanagement-Prozesse.

Ein Ingenieur wie Peter Teubner hat eben keine multiplen Identitäten, mit deren Hilfe er mehrmals am Tag von der Gedankenwelt eines Ingenieurs in die eines Projektmanagers wechseln kann. Beide Ebenen müssen daher so verzahnt sein, dass sie letztlich eine Einheit bilden. Andernfalls entstehen Parallelwelten, in denen nicht mit-, sondern gegeneinander gearbeitet wird. So banal diese Erkenntnis ist, so oft wird sie in der Praxis missachtet.

Strikte Trennung zwischen Prozess und Software

"Am Anfang war der Prozess." Mit diesem Satz beginnt in vielen Organisationen die Schöpfungsgeschichte des Projektmanagements. Hier liegt das dritte Problem des Markus Hartmann: Die Software bringt er erst dann ins Spiel, wenn alle Prozesse bereits in Stein gemeißelt sind. Irgendeine Software, so denkt Hartmann, wird sich schon finden lassen. Und mit einem Mal denkt ein mittelständisches Unternehmen ernsthaft über große Konzernlösungen nach, die zwar alle Anforderungen abdecken, aber für den Reifegrad des eigenen Unternehmens schlicht eine Nummer zu groß sind.

Natürlich bedeutet das nicht, dass Konzernlösungen im Mittelstand grundsätzlich fehl am Platz wären. Immer mehr Mittelständler weisen im Projektmanagement einen Reifegrad auf, der eine solche Software sogar erforderlich macht. Wo jedoch bislang eher auf dem Papier oder mit Hilfe einer Tabellenkalkulation geplant wurde und sich Ressourcenmanagement in den Köpfen der Beteiligten abspielte, wird man eine Organisation mit einer zu großen Lösung überfordern.

Als Berater muss Hartmann sich an dieser Stelle auch die Frage gefallen lassen: Wie konnte es so weit kommen? Warum hat ein Unternehmen, bei dem Projektmanagement bislang nicht wirklich auf der Agenda stand, nach wenigen Wochen einen Anforderungskatalog, bei dem ein Großteil der Softwareanbieter aus dem Rennen sind? Warum gebot er dem "Wunschkonzert" der zukünftigen Anwender nicht Einhalt?

Die Antwort ist ernüchternd einfach: Mangelnde Vorstellungskraft. Hartmann hat mit Teubner und seinem Team über Projektmanagement-Prozesse diskutiert. Aber was macht einen solchen Prozess eigentlich aus? Wie kann man sich ihn konkret vorstellen?

Ein Architekt käme niemals auf die Idee, ein Haus lediglich verbal zu beschreiben oder seinen Auftraggeber mit ein paar einfachen Strichzeichnungen für seinen Entwurf begeistern zu wollen. Er taucht mit ihm vielmehr in virtuelle Welten ein oder präsentiert ein möglichst realistisches Modell, um dem Bauherrn dessen zukünftige Lebenswirklichkeit plastisch vor Augen zu führen.

Diese Denkweise fehlt bei den meisten Projektmanagement-Einführungsprojekten. Hier werden Organisationen regelmäßig an den grünen Tisch gebeten, um Prozesse zu entwickeln, die sie sich nur in Teilen vorstellen können und von denen sie überrascht sind, wenn sie zum ersten Mal deren Umsetzung sehen – in einer Software, die sie mit ihren selbst ausgedachten Anforderungen erschlägt.

Daher empfiehlt es sich, das Thema Software frühzeitig in die Diskussion über Prozesse und Methoden zu integrieren. Nichts veranschaulicht einen Prozess besser, als ihn in Softwarelösungen zu simulieren. Wer als Anwender Möglichkeiten und Grenzen von Software frühzeitig erkennt, wird auch eher bereit sein, seine Anforderungen nah an üblichen Standards auszurichten – ein wirksames Mittel gegen die von vielen Fachleuten zu Recht beklagte "Featuritis".

Fazit

Diese Geschichte hat ein banales Happy End: Hartmann und Teubner existieren nicht. Sie sind reine Fiktion. In vielen Einführungsprojekten sind sie jedoch erschreckend real: Die Hartmanns, die nicht immer externe Berater sind, sondern diese Aufgabe vielfach innerhalb der eigenen Organisation leisten und die Teubners, die in einer anderen Welt als der des Projektmanagements leben. Beide sind unverzichtbar für ein Unternehmen. Bewegen sie sich aufeinander zu, und gelingt es ihnen, ihre unterschiedlichen Welten zu verzahnen, besteht die Hoffnung, dass die Zahl gescheiterter Einführungsprojekte deutlich gesenkt werden kann.