In den CIO-Nachrichten findet sich ein Beitrag: Schlechtes Anforderungsmanagement. IT versteht das Business nicht. Die Aussage wird belegt mit einer Umfrage des IT-Beraters Arcway.

Diese These deckt sich durchaus mit meiner Erfahrung, aber ich würde darüber hinaus noch viel weiter gehen: Das Unverständnis besteht häufig nicht nur zwischen Auftraggeber und Auftragnehmer, sondern zieht sich durch alle Schichten der Stakeholder eines Projektes. Als Projektmanager finde ich mich regelmäßig in der Rolle des Übersetzers zwischen den verschiedenen Beteiligten. Die Verständigungsschwierigkeiten fangen schon auf Kundenseite über die verschiedenen Hierarchiestufen (vom Top-Management bis zum Enduser) an. Aber selbst auf der reinen IT-Seite besteht dieses Problem, denn ein IT-Architekt ist noch näher am Business und spricht eine andere Sprache als ein  Nerd, der die letzten Bits einer Schnittstelle programmiert. Darüber hinaus gibt es noch so Themen wie IT-Betrieb, etc., die wiederum mit einem anderen Verständnis (und anderen Anforderungen) ausgestattet sind. Da wollen wir noch gar nicht vom Brückenschlag von der Fachabteilung zur IT hin reden…

Die Überwindung solcher Verständnisschwierigkeiten ist nach meiner Überzeugung einer der wichtigsten Erfolgsfaktoren für Projekte.

Jüngst gab es hier den Link auf einen Beitrag des Business Management ABC zur Definition des Projektbegriffs. Andreas Heilwagen hat sich nun ebenfalls an eine Definition gewagt und den Begriff ausführlich diskutiert. Grundsätzlich bin ich ganz nahe bei seiner Definition des Projektbegriffs:

einmaliges, zeitlich definiertes Vorhaben, um ein Ziel zu erreichen, das spezifische Anforderungen erfüllt.

Es mag sich unter den „spezifischen Anforderungen“ verbergen, aber was mir bei dieser Definition noch etwas zu kurz kommt, ist die Komplexität. Projekte sind auch durch die Komplexität ihres Gegenstandes oder ihres Vorgehens gekennzeichnet. Allzu leicht wird z.B. im Vertrieb bei jedem neuen Auftrag von einem Projekt gesprochen. Das ist etwas irreführend und inflationär. Erst wenn sich in einem Auftrag eine gewisse Komplexität verbirgt, würde ich von einem Projekt sprechen. Alles andere ist Routine.

So trivial wie die Frage auch sein mag, die Antwort ist es nicht immer…
Business Management ABCs fasst einige Aspekte zusammen.

Andreas Heilwagen, unser Spezialist für Projektmanagement-Standards,  setzt sich in seinem Blog mit den englischen (UK) Standards auseinander und hat die entsprechenden Links zusammengestellt.

Glen Alleman fasst in seinem Blogbeitrag zum Thema Risk handling (Englisch) alles Wesentliche zusammen.

Danny Quick erinnert daran, dass auch für Projekte die Grenzen der Machbarkeit gelten. Was selbstverständlich sein sollte, wird doch immer wieder vergessen. Oder verdrängt?

Sigrid Hauer erläutert in Ihrem Blog Projektgeschichten, wie Einstellung und Erwartungshaltung unsere Entwicklung und unser Verhalten und damit auch unsere Arbeits- und Projektergebnisse beeinflussen können. Quasi eine Aufforderung zum positiven Denken. Als Beleg führt sie ein Experiment der Psychologen Rosenthal und Jacobsen aus dem Jahr 1968 an und illustriert ihren Beitrag mit einem Ausflug in die antike Mythologie zu Pygmalion, der namensgebend für den von Rosenthal und Jacobsen untersuchten Effekt  ist. Mir fehlt in diesem Zusammenhang noch der Hinweis auf die Theorie der sich selbst erfüllenden Prophezeiung.

„Beratung“ ist ein vielstrapaziertes Wort.
„Berater“ sind deshalb häufig auch in Verruf gekommen.

Was Projekt- und Prozessberatung tatsächlich leisten kann, damit setzt sich Patrick Fritz in einem lesenswerten Beitrag auf Jahooda auseinander und zeigt fachlichen, methodischen und sozialen Nutzen auf.

Wer schon immer „alles“ über agile Softwareentwicklung mit Scrum wissen wollte und das noch in weniger als zehn Minuten, sei auf folgendes englische Youtube-Video hingewiesen.

Wer es gerne etwas ausführlicher hätte, dem kann ich Roman Pichler, Scrum – Agiles Projektmanagement erfolgreich einsetzen. Heidelberg 2008 (Amazon) nahelegen, das ich hier auch schon das eine oder andere mal zitiert habe.

Und für alle die, deren Interesse an Scrum nun geweckt worden ist, hier noch via agilesoftwaredevelopment.com eine Seite mit Excel-Templates und zugehörigen Video-Tutorials.

Andreas Heilwagen stellt in einem Beitrag die zentralen PM-Standards PMBOK, PRINCE 2 und GPM-IPMA einander gegenüber. Ergänzt wird die Liste noch durch die Normen DIN 69901: Projektmanagement und ISO 21500.