Direkt zum Hauptbereich

Die Rolle des Projektmanagers bei unterschiedlichen Projektprofilen

Es gibt unterschiedliche Projektumgebungen, bei denen ein Projektmanager ganz andere Schwerpunkte setzen muss. Das wird schnell übersehen, wenn man nicht weiß, dass es so etwas wie Unsicherheitsprofile gibt.
Viele Projektmanager kommen leider ganz unvorbereitet in ihre Rolle. Irgendwann gibt ihnen jemand den Auftrag sich um ein Projekt zu kümmern. Dann schlägt man sich irgendwie durch, überlebt das erste Projekt ohne Schaden und bekommt das nächste usw. Was fehlt ist ein fundiertes Verständnis dafür, was Projektarbeit ist.

Sollten Sie gerade vor einem neuen Projekt stehen, überlegen Sie bitte ernsthaft, eine Projektmanagementschulung für sich und Ihr Team zu bestellen /1/. Die Kosten für eine Schulung sind viel geringer als der durchschnittliche Verzug im Projekt /2/.

Es gibt unterschiedliche Arbeitsweisen, weil es unterschiedliche Profile gibt

Wenn Sie sich mit verschiedenen Herangehensweisen an Projekte beschäftigt haben, werden Sie sehen, dass es ganz unterschiedliche Arbeitsweisen für Projektmanager gibt. Der PMBoK empfiehlt eine sog. work breakdown structure (WBS) zu erstellen. Ein Product Owner bei Scrum benutzt aber ein Backlog. Was ist denn nun richtig?

Antwort: es kommt darauf an, nämlich auf das Projektprofil. In einem Beitrag über agile Verträge habe ich schon einmal auf die Arbeiten von Shenhar und Dvir hingewiesen /3, 4/.

Sehen wir uns einmal zwei unterschiedliche Profile an (Abb. 1).
Abb. 1: Zwei unterschiedliche Projektprofile (nach Shenhar/Dvir)
Im roten Projekt 1 gibt es schon vor Projektbeginn konkrete feste Anforderungen. Das Team kennt sich gut mit den Techniken und Methoden aus. Es kann ein bekanntes Design wiederverwenden und kann Listen aus vergangen Projekten zur Planung nutzen. Es gibt einen festen Abgabetermin, auf den hingearbeitet wird.

In solch einer Situation kommt man mit dem traditionellen Projektmanagement gut voran.

Im blauen Projekt 2 wird ein neues Produkt entwickelt. Hier ist die Situation anders. Frühestens zur Mitte des Projekts lassen sich die Anforderungen finalisieren. Vorher ist das gar nicht möglich. Neue Produkte setzen neue Technologien ein. Das Team muss sich erst in diese neuen Dinge einarbeiten. Ob das letzte bekannte Design funktioniert, ist gar nicht klar. Es ist besser, eine gewisse Zeit mit mehreren Designs zu arbeiten, bis man sicher weiß, welches Fundament belastbar ist.

In solcher einer Situation haben Sie zwei Möglichkeiten:
  • Sie warten, bis sie wieder 100% Sicherheit bei Anforderungen und Technik haben. Das kostet Zeit.
  • Sie ändern Ihre Arbeitsweise so, dass Sie immer wieder Feedback bekommen, ob Sie noch auf dem richtigen Weg sind.

Die zweite Möglichkeit ist das, was wir in Scrum machen. Wenn man hier versucht, mit Werkzeugen des traditionellen Projektmanagements zu arbeiten, wird man schnell enttäuscht. Die Pläne funktionieren einfach nicht. Hier ist es wichtiger, das Projekt über Ziele zu führen und in kurzen Phasen zu arbeiten.

Wer wissen will, wie sich die Arbeitsweisen und Aufgabeschwerpunkte von traditionellen Projektmanagern und von agilen Projektmanagern unterscheiden, der kann sich in einem kurzen Artikel von Jeff Sutherland und Nafis Ahmad oder in einem Buch von Michele Sliger und Stacia Viscardi darüber informieren.

Sie wollen mehr über gute Projektarbeit lernen? Es gibt eine Übersichtsseite zum Thema Projektmanagement in diesem Blog. Dort finden Sie weitere Artikel, mit denen Sie sich in das Thema einlesen können.

Anmerkungen

  • /1/ Die Methode ist egal. Jedes methodische Vorgehen ist besser als blinder Aktionismus. Ich persönlich empfehle eine PRINCE2-Foundation und ein Scrum-Training.
  • /2/ Wie lautet noch dieser gemeine Spruch von Peter Drucker? "If you think training is expensive, try ignorance".
  • /3/ Jan Fischbach: Verträge für Projekte mit agilem Vorgehen (Teil 2/4), Teamworkblog, erschienen am 07. Mai 2013, abrufbar unter http://www.teamworkblog.de/2013/05/vertrage-fur-projekte-mit-agilem_7.html 
  • /4/ Shenhar, Aaron J., and Dov Dvir. Reinventing Project Management: The Diamond Approach to Successful Growth & Innovation. 1st ed. Mcgraw-Hill Professional, 2007.
  • /5/ Jeff Sutherland, Nafis Ahmad: How a Traditional Project Manager Transforms to Scrum: PMBOK vs. Scrum, Vortrag auf der Agile 2011 in Salt Lake City, 11.08.2011, abrufbar unter http://jeffsutherland.com/PMBOKvsScrumAgile2011.pdf
  • /6/ Sliger, Michele ; Broderick, Stacia: The Software Project Manager's Bridge to Agility. 1. Aufl.. Boston: Addison-Wesley Professional, 2008. 

Kommentare

Beliebte Posts aus diesem Blog

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Agile Sternbilder: Die Entdeckung kosmischer Agilitäts-Superkräfte

Hast du dich je gefragt, ob dein Sternzeichen deine Fähigkeiten in einer agilen Arbeitsumgebung beeinflusst? In diesem Blogpost tauchen wir ein in die faszinierende Welt der Astrologie und ihre mögliche Verbindung zu modernen Arbeitsweisen. Entdecke, wie die Sterne deine agilen Stärken prägen könnten. Ob überzeugter Agilist oder neugieriger Sternzeichenliebhaber – dieser Artikel kann dir neue Perspektiven eröffnen und vielleicht sogar dein nächstes Teamprojekt inspirieren!

Den passenden Job finden

Hier teile ich, wie ich daran arbeite, endlich den richtigen Job zu finden. Kleingedrucktes: Dieser Artikel richtet sich (natürlich) an jene, die gerade in der luxuriösen Position sind, dass sie nicht jedes Angebot annehmen müssen. Anstatt von Engagement zu Engagement zu hetzen und frustriert zu sein über Konzernstrukturen, fehlende Ausrichtung und die Erkenntnis, dass in einem selbst beständig die Hintergrundfrage nagt, ob es das ist, womit man seine immer knapper werdende Lebenszeit wirklich verbringen möchte, gibt es manchmal auch die Möglichkeit, die nächste berufliche Station etwas nachhaltiger auszusuchen - auch, um tatsächlich (etwas) mehr beitragen zu können.

Die Microsoft Teams-Not-To-Do-Liste

Viele hoffen, dass es  für die Einrichtung von Microsoft Teams  den Königsweg gibt, den perfekten Plan – doch den gibt es leider (oder glücklicherweise?) nicht. Genauso wenig, wie es jemals einen Masterplan für die Organisation von Gruppenlaufwerken gab, gibt oder je geben wird. Was gut und vernünftig ist hängt von vielen Faktoren und ganz besonders den Unternehmensprozessen ab. Sicher ist nur eines: Von alleine entsteht keine vernünftige Struktur und schon gar keine Ordnung. Dafür braucht es klare Entscheidungen.

Agilität ist tot. Ausgerechnet jetzt?

Agilität wird zurückgefahren, Hierarchien kehren zurück. Doch ist das wirklich der richtige Weg in einer Welt, die immer unberechenbarer wird? Oder erleben wir gerade eine riskante Rolle rückwärts?

Wie beschreibt man einen Workshop für eine Konferenz?

Konferenzen bieten immer ein gutes Forum, um sein Wissen und seine Erfahrungen zu teilen. Was für die Vortragenden selbstverständlich scheint, ist für die Besucher:innen oft unverständlich. Wie können Vortragende ihren Workshop in 2-3 Sätzen beschreiben, damit die Besucher:innen schnell einschätzen können, er sich für sie lohnt?

Gemeinsam eine Anwenderdokumentation erstellen

Unternehmenssoftware ist ein wichtiges Bindeglied zwischen Anwenderinnen und Anwendern, den Unternehmensprozessen und den Ergebnissen. Normalerweise schreibt der Hersteller der Software die Dokumentation für diejenigen, die die Software benutzen. Wenn die Software allerdings stark angepasst wurde, muss die Dokumentation von denen kommen, die die Prozessmaschine am besten verstehen - den Anwenderinnen und Anwendern. Wie könnte man das praktisch machen?

Der Softwareeisberg, die Softwarepyramide - Wie sprechen wir über neue Software?

Software ist aus den Geschäftsprozessen vieler Unternehmen nicht mehr wegzudenken. Sie verwaltet Kunden- und Produktdaten. Sie automatisiert Abläufe und verhindert Fehler. Aber Software veraltet. Was machen wir, wenn wir Unternehmenssoftware erneuern müssen? Von den ersten Konzepten bis zum ersten Release ist es ein weiter Weg, mit vielen Entscheidungen. Wie sprechen wir über diese Entscheidungen?