Frohe Ostern!

Beim Anblick der derzeitigen Spritpreise treibt es mir regelmäßig die Tränen in die Augen. Umso erstaunter bin ich, dass es tatsächlich manche unter uns gibt, die sich den einen oder anderen Liter Benzin noch leisten und über die Feiertage (bzw. bereits davor) einen Kurzurlaub einlegen. So ist unser Büro im Moment ziemlich verwaist, und ich vermeine bereits ein Echo hören zu können, wenn ich hin und wieder ein aufmunterndes Selbstgespräch führe.

© Rainer Sturm / www.pixelio.de

Na ja, ganz so schlimm ist es nun auch nicht: Immerhin halten Denise und Stefan gemeinsam mit mir das Fähnlein der wackeren Pentamini aufrecht. Allerdings werden wir uns  ab heute Nachmittag ebenfalls intensiv der Feiertagsruhe hingeben, und uns auf die Bedeutung des bevorstehenden Festes besinnen. Ab nächster Woche wird dann wieder kräftig in die Hände gespuckt. Dann steht nämlich unser nächstes Planungs-Meeting an, in dem konkret die technischen Details der nächsten Umsetzungen festgelegt werden. Da unser Projekt während der letzten Wochen leider auf Eis gelegt war, weil wir alle in unseren anderen Projekten komplett ausgelastet waren, wird nun die Entwicklung mit Verve wieder aufgenommen.

Wer es bis zum nächsten Blog-Beitrag gar nicht ohne Neuigkeiten von Pentamino aushalten mag, sei auf einen interessanten Zeitschriftenartikel von Anke auf unserer Homepage  verwiesen. In „Individuelle Projektarbeit“ beschreibt sie die Vorteile der Nutzung von Open-Source-Lösungen in der Projektarbeit.

Uns allen  wünschen ich und das gesamte Pentamino-Team ein frohes und gesegnetes Osterfest und gute Erholung!

Share
Posted in Allgemein | 4 Comments

Berichte über Berichte – Reporting

Nach Change Management und Risk Management beschäftigen wir uns nun mit dem weitreichenden Thema Reporting. Für die Fortschrittsberichterstattung, Steuerung und Prognose aller Projekte eines Unternehmens auf der Multi-Projektebene und der strategischen Ebene sind verdichtete Informationen essentiell. Hierbei gilt das Leitmotiv „In der Kürze liegt die Würze“ (frei nach W. Shakespeares Hamlet: „Weil Kürze denn des Witzes Seele ist, … fass ich mich kurz“). Natürlich möchte sich das Management i. d. R. ausgiebig über den geschaffenen Wert durch die Projekte, sowie den weiter zu erwartenden Wert informieren. Allerdings möchte es sich dabei keineswegs in allzu vielen Details verlieren. Deshalb ist es erforderlich, den Spagat zwischen Detailtiefe und Übersichtlichkeit zu treffen. Die genauen Inhalte des Berichtswesens variieren von Organisation zu Organisation. Unsere PMO-Edition von ]project open[ soll aber die wichtigsten und am häufigsten nachgefragten Standardreports bereits in der Grundversion zur Verfügung stellen.

© Jetti Kuhlemann / www.pixelio.de

Zu dieser Thematik haben wir aktuell folgende User-Stories gesammelt:

• Als Teammitglied möchte ich über RSS Feed informiert werden, wo ich den monatlichen Newsletter, der darstellt, welche Entwicklungen es in allen Projekten gibt, welchen Beitrag das zum Unternehmenserfolg hat und was die nächsten Schritte sein werden, abrufen kann.

• Als Projektleiter möchte ich den aktuellen Status meines Projekts berichten können.

• Als Projektmanager möchte ich wissen, was aus meinem Projekt an andere Geschäftseinheiten berichtet wird.

• Als Projektmanager möchte ich möglichst wenig Arbeit mit dem Statusreporting haben. Die Informationen sollen möglichst automatisiert aus dem PM-System gezogen werden können.

• Als Geschäftsführung möchte ich die Auslastung aller, an Projekten beteiligten Ressourcen, für mindestens die nächsten 4-6 Monate sehen können.

• Als Geschäftsführung möchte ich eine aggregierte Sicht des finanziellen Status aller Projekte sehen. Bei, durch Kunden beauftragte Projekten, möchte ich auch einen Stand der aktuellen Zahlungen bzw. Zahlungsverzug erhalten.

• Als Geschäftsführung möchte ich eine Interpretation der Earned Value Analysen aller Projekte erhalten.

• Als Geschäftsführung möchte ich einen Überblick über alle Change Requests haben, die meine Projekte betreffen.

• Als Geschäftsführung möchte ich einmal monatlich einen aktuellen Report aller Projektrisiken erhalten, nach Möglichkeit aggregiert und aufbereitet, so dass ich sehen kann, ob es gravierende Risiken gibt, die dem gesamten Unternehmen gefährlich werden könnten.

• Als Geschäftsführung möchte ich wissen, wie zufrieden der Kunde mit der Projektdurchführung ist (falls es sich um externe Projekte handelt).

• Als Geschäftsführer möchte ich monatlich einen Report erhalten, der darstellt, inwiefern die in den Projekten erreichten Ergebnisse zur Umsetzung der Unternehmensstrategie beigetragen haben.

• Als Geschäftsführer möchte ich wissen, welchen Wert meine Projekte produzieren, so dass ich sehen kann welche Projekte die größte Wertschöpfung liefern.

• Als MPM möchte ich eine Earned Value Analyse für alle Projekte haben.

• Als MPM möchte ich eine Meilensteintrendanalyse pro Projekt sehen und wissen, ob es zu Verschiebungen kommt, die andere Projekte betreffen könnten (z. b. weil Ressourcen länger als geplant benötigt werden).

• Als MPM möchte ich 14-tägig einen Report über die erreichten Zwischenergebnisse und deren Relevanz für das Projektziel sowie die in den nächsten 14Tagen zur Umsetzung geplanten Zwischenergebnisse erhalten. Außerdem ein Vergleich von Geplant und Ist.

Soweit die Zusammenstellung der bisher vorhandenen Anforderungen. Wer sich darüber hinaus an der Diskussion beteiligen will – entweder speziell zu einzelnen User Stories und der geplanten PMO-Software, oder auch allgemein zum Thema PMO – ist herzlich eingeladen, sich in unseren Verteiler eintragen zu lassen oder sich in unserer Xing-Gruppe zu engagieren.

Share
Posted in Allgemein | Tagged , , , , | 15 Comments

Das Leben ist ein einziges Risiko! – Risikomanagement Teil 2

Zum Thema Risiko Management habe ich bereits vor zwei Wochen einige User Stories vorgestellt. Mittlerweile sind noch die eine oder andere hinzugekommen, die nun auch mit Akzeptanzkriterien versehen wurden.

© Sigrid Rossmann / www.pixelio.de

 

  • As a project manager I simply want to add my risks so that I get an overview over all my project risks.
  1. Eine Eingabemaske für die Risiken muss aufgerufen werden.
  2. Folgende Risikomerkmale sind mindestens erforderlich: ID, Name, Beschreibung, Typ,  Projekt-ID, Projektname, PD, LGD, Gegenmaßnahmen, Kosten für die Gegenmaßnahmen, Risikobudget = PD * LGD, Verantwortlicher für das Einleiten der Maßnahme, Risikoklasse.
  3. PD = Eintrittswahrscheinlichkeit (probability of default), LGD = Verlust bei Eintritt (loss given default)
  4. Der Risikotyp muss konfigurierbar sein.
  5. Klasse: vernachlässigbar, spürbar, verkraftbar, gefährlich, katastrophal
  6. Aus den Einzelrisiken soll eine Liste erstellt werden (analog der Projektliste), die nach Projekt, Klasse, PD, LGD, Typ, Risikobudget, Maßnahme-Kosten gefiltert werden kann.
  • As a Multiproject Manager I want to add my Risk by Type (Technical, Scope, Time, Budget, Security, Communication, Organisation) the Conseqeuncen when the risk appears (critical, high, low), an Status of the risk (active, dormant, resolved), a probability of the potential occurrence of the risk (20%, 40% 60%, 80%, 100%) and an approach how to deal with the risk (mitigate, watch, accept, research, closed) so that all risks of all projects are fully described.

 

Diese User Story (US) stellt eine Ergänzung zur obigen dar und konkretisiert die dort angegebenen Kategorien.

  1. Risiko-Typ: Standardwerte sind vorgegeben, sollen jedoch frei konfigurierbar sein. (technisch, Inhalt und Umfang, Zeit, Budget, Sicherheit, Kommunkation, Organisation)
  2. Status: aktiv, inaktiv, nicht mehr relevant
  3. Auswirkungen: niedrig, mittel, hoch, kritisch
  4. Eintrittswahrscheinlichkeit: 0, 20%, 40%, 60%, 80%, 100%
  5. Risiko-Bewältigungsmaßnahme: Vermindern, Beobachten, Akzeptieren, Untersuchen, Schließen
  • As a project manager I want to calculate my risk budgets so that I am able to see if my project budget is sufficient or I need to raise a change request.
  1. Risikobudget = PD * LGD
  2. Diese US ist in der ersten US enthalten.
  • As a Project Manager I want to see typical risks of other projects and in the project portfolio, for learning from them.
  1. Prozess (nicht zu implementieren): Jeder PL erstellt am Projektende ein lessons learned Dokument, welches u. a.  seine Risiken enthält. Daraus erstellt das PMO turnusgemäß eine Liste, die typische Risiken zusammenfasst.
  2. ]po[: Die jeweils aktuelle Liste der typischen Risiken, soll beim Neuanlegen eines Projektes, automatisch hoch geladen werden. => Verwendung als Template für die eigene Risikoanalyse möglich
  3. DIe Struktur der Liste soll den vorhergehenden US entsprechen.
  • As a Multiproject Manager I want to be able to send automatically emails when the state of a risk changes so that I can simply keep my stakeholders informed.
  1. Um zu vermeiden, dass ein Adressat mit einer Fülle von Emails belästigt wird, soll die Möglichkeit eingerichtet werden, dass Team-Mitglieder, Manager und Stakeholder Informationen abonnieren können.
  2. Um Informationen abonnieren zu können, werden die Interessenten auf eine Seite geführt, auf der sie einzelne Informationen durch Setzen eines Hakens anfordern können.
  3. Automatischer Emailversand muss möglich sein, wenn sich eine Änderung ergibt und ein Interessent die Zusendung abonniert hat.
  4. Für das Abo sollen folgende Änderungen auswählbar sein: PD, Status, Maßnahmekosten, LGD, Maßnahme (Konfigurierbarkeit).
  • As an Executive I want to see the risks of all my projects grouped by project and displayed in a risk graph so that I can see how risky my project portfolio is.
  1. s. US1, AK6: Eine Liste der Risiken analog zur Projektliste soll erstellt werden, die alle Risiken aller Projekte des Portfolios abbildet.
  2. Die Risiko-Grafik soll wie folgt aussehen:

Hierbei ist auf der y-Achse die Eintrittswahrscheinlichkeit und auf der x-Achse ein Risikomerkmal (wie z. B. die Auswirkung) aufgetragen. Das darzustellende Merkmal soll dabei frei wählbar sein.

  • As an Executive I want to see how the risks change so that I see trends.
  1. Zeitreihenanalyse
  2. Datenhistorisierung
  • As a Portfolio Manager I want to see relevant project risks, for identifying structural/comprehensive risks in the project portfolio (e.g. lack of specific competencies that affect a number of projects).
  1. s. o.: Liste der Portfolio-Risiken
  • As a Portfolio Manager I want to see the interdependencies between projects, for identifying  the risk of domino effects between projects.
  1. Alle denkbaren Abhängigkeiten können nicht abgebildet werden.
  2. Eine Darstellung der Risiken durch die Auslastung der Mitarbeiter in verschiedenen Projekten ist teilweise bereits vorhanden (Ressourcs Planning, Dept. Planner).
  • As a project manager I want to easily simulate multiple timeline- budget- and quality- scenarios based on the occurrence of the project risks.

 

Diese US stellt sehr hohe technische Anforderungen. Die einschlägigen nicht linearen Modelle, die einem möglichen Lösungsweg zugrunde liegen, erfordern die Anwendung neuronaler Netze und stehen somit außerhalb der Leistungsfähigkeit von ]project open[.

 

  • As a Portfolio Manager I want to clarify the risks and controls in our project and project portfolio processes, for being audit-proof and SOX-proof (requirements of Sarbanes-Oxley-Act)

 

Dies steht derzeit nicht im Fokus des 1. Releases, das sich eher an allgemeine Bedürfnisse von PMOs richtet. Es wäre denkbar, in einem Folgerelease oder aufgrund spezieller Beauftragung diese Mechanismen Zielgruppen gerichtet zu implementieren.

Share
Posted in Allgemein | 5 Comments

Rückblick auf den ersten Sprint

Statt uns am letzten Samstag in das Fastnachtsgetümmel zu stürzen, haben wir in unserem Heidelberger Büro unser erstes Sprint-Meeting abgehalten.

© Markus Walti / www.pixelio.de

Wieder hatte sich der harte Kern getroffen, um zunächst den Sprint 1 Revue passieren zu lassen. Dabei wurde berichtet, dass Malte – unser Hauptentwickler aus Hamburg – sowie Frank und Klaus – die Gründer von ]project open[ aus Barcelona – zunächst einen Weg finden mussten, den bereits bestehenden Kern von ]project open[ mit den von uns neu zu entwickelnden Teilen zu verheiraten (oder auf neudeutsch: zu mergen). Auf den ersten Blick mag dies als ein leichtes Unterfangen erscheinen. Da es sich aber um eine Projektmanagement-Software mit sehr vielen, individuell konfigurierbaren Funktionen handelt, war dieses Vorhaben absolut nicht trivial. Mittlerweile ist es Frank, Klaus und Malte jedoch gelungen, einen Prozess für die Zusammenführung und sich anschließende, ständige Aktualisierung der Softwarepakete über ihre sog. Repositories zu entwickeln. Leider haben diese Vorarbeiten – schließlich führen wir das Projekt überwiegend in unserer Freizeit durch – soviel Zeit in Anspruch genommen, dass wir im Zeitplan gleich etwas zurück geworfen wurden. So müssen einige Entwicklungsschritte zu dem umfangreichen Thema Projektmanagement in den nächsten Sprint verschoben werden. Für die Realisierung in Release 1 bis Ende Juni 2012 sind demnach die Themengebiete Change Management, Risikomanagement, Reporting und Controlling.

Ab Sonntag hat dann doch der Eine oder Andere von uns Konfetti und Kamelle nicht entsagen können (oder wollen), weshalb auch dieser Blog-Beitrag etwas verspätet daher kommt! Heute ist aber Aschermittwoch: Jetzt wird wieder in die Hände gespuckt, wir steigern ...

Mit der beginnenden Fastenzeit werden wir bei Wasser und Brot in uns gehen und die Entwicklung weiter voran treiben.

© Alexander Dreher / www.pixelio.de

In den kommenden Wochen und Monaten werden wir User Stories für alle 12 Wirkungsfelder sammeln und in unserem neuen XING-Forum inhaltlich diskutieren. Abhängig von den Ergebnissen der Diskussion werden wir die User Stories (und die zugehörigen Akzeptanzkriterien) eindeutig priorisieren und – sofern noch nicht im aktuellen, spätestens in einem kommenden Release berücksichtigen.

Wie immer seid Ihr herzlich eingeladen, Euch hier in den Comunity-Email-Verteiler einzutragen. Wie bereits erwähnt könnt Ihr aber auch in der neuen PMO-Community auf XING aktiv mitdiskutieren und Euch mit Gleichgesinnten, denen das spannende Thema PMO ebenso am Herzen liegt, (fast) nach Belieben austauschen.

Share
Posted in Allgemein | 6 Comments

Die 12 Wirkungsfelder und zugehörige Probleme eines PMO

Wie bereits in unserem Blog vom 15. Januar 2012 dargestellt, hat die Fachgruppe PMO der GPM (Gesellschaft für Projektmanagement; deutsche Sektion der IPMA) zwölf Wirkungsfelder für PMOs erarbeitet. Die folgende MindMap bildet einige typische Probleme ab, die mit diesen Wirkungsfeldern verbunden sind. Natürlich ist die Abbildung alles andere, als vollständig. Sie veranschaulicht aber recht gut, mit welchen Fragen die Praktiker sehr häufig konfrontiert sind. Zur weiterführenden Diskussion dieses Ansatzes wurde die Gruppe „PMO-Community“ bei Xing eingerichtet, in der sich jeder Interessierte engagieren kann.

Problemfelder eines PMOs

Und hier gibt es auch noch eine erste Matrix, in der die Problemfelder nach Einzelprojekt-, Multiprojekt- und strategischer Ebene differenziert werden:

Problemfeldmatrix

 

Share
Posted in Allgemein | Tagged , , | 3 Comments

Das Leben ist ein einziges Risiko! – Risikomanagement Teil 1

Letzte Woche hatten wir unsere User Stories und Akzeptanzkriterien dem Change Management gewidmet. Nachdem wir uns zunächst auf die Anforderungen beschränken mussten, die wir in unserem ersten Planungs-Workshop erarbeitet hatten, bekamen wir in der vergangenen Woche bereits erste Rückmeldungen aus der Community. Folgende User Stories erreichten uns ergänzend zum Thema Change Management:

• As a Multi-Project-Manager I want to see how projects change (in terms of timelines, resources/capacities, costs), so that we can analyse the impact on the project portfolio (project roadmap).
• As a Multi-Project-Manager I want to see how projects change (in terms of timelines, resources/capacities, costs), so that we can identify resource bottlenecks.
• As a Multi-Project-Manager I want to see how projects change (in terms of timelines, resources/capacities, costs), so that re-prioritization will be possible if necessary.
• As a Portfolio Manager I want to see how strategies and projects aims change (in terms of strategic alignment), for identifying strategic gaps and re-alignment if necessary
• As a Portfolio Manager I want to see how changes happen (how new requirements pop up, how projects respond and deal with them), for analyzing and improving our common proficiency of change request management, and avoiding waste of resources.

Unser nächster Sprint wird das Risiko Management behandeln.

© Bredehorn Jens / www.pixelio.de

 

Hierzu werden wir nächstes Wochenende einen weiteren Planungs-Workshop in unseren Büroräumen in Heidelberg abhalten. Alle Interessierten sind herzlich dazu eingeladen, daran teilzunehmen. Meldet Euch einfach unter pmo-community@pentamino.de, damit wir Euch die Einzelheiten mitteilen können.

Auch zu diesem Thema bekamen wir erste Anregungen aus der Community:

  • As a Portfolio Manager I want to see relevant project risks, for identifying structural/comprehensive risks in the project portfolio (e.g. lack of specific competencies that affect a number of projects).
  • As a Project Manager I want to see typical risks of other projects and in the project portfolio, for learning from them.
  • As a Portfolio Manager I want to see the interdependencies between projects, for identifying  the risk of domino effects between projects.
  • As a Portfolio Manager I want to clarify the risks and controls in our project and project portfolio processes, for being audit-proof and SOX-proof (requirements of Sarbanes-Oxley-Act).

Für alle diese Beiträge bedanken wir uns bei Euch ganz herzlich. Dies zeigt, dass die Idee unserer PMO-Community angenommen und langsam aber sicher zum Leben erweckt wird. Neben unserem Blog wurde mittlerweile unsere neue Xing-Gruppe genehmigt, über die Euch meine Kollegin Denise auf dem Laufenden halten wird. Über die Ergebnisse unseres Workshops am kommenden Wochenende werde ich euch wieder an dieser Stelle informieren. Natürlich freuen wir uns über weitere User Stories zum Thema Risikomanagement.

Share
Posted in Allgemein | 4 Comments

User Stories Change Management?

Nachdem wir zuletzt beschlossen hatten, unser Projekt mit Hilfe von Scrum zu realisieren, war es vergangene Woche unser Ziel, erste Anforderungen für unsere neue PMO-Software zu bestimmen. Während unseres ersten Workshops wurden folgende User Stories zum Change Management gefunden, die wir um erste Akzeptanzkrieterien ergänzt haben:

© Kellermeister / www.pixelio.de

• As a project manager I want to change my budget.

  1. An online form should be filled with ammount and a justification statement.
  2. The statement should be sent to the role ‘approver’.
  3. If approved the budget change should update the former budget in financial statements.
  4. The project manager should be informed of the approval result via email.
  5. The budget history should be generated.

• As a project member I want to be notified of all project approved changes.

  1. Each project member should be informed of the approved changes via email.
  2. Each project member should be able to configurate the email category he wants to receive.

• As a project manager I want to change my scope of the project.

  1. An online form should be filled with a detailed description of the new scope and a justification statement.
  2. The statement should be sent to the role ‘approver’.
  3. The project manager should be informed of the approval result via email.
  4. On approval a new baseline should be created.

• As a project manager I want to maintain a revisioned scope document.

  1. Approved scope changes should be automatically transformed into a scope document to keep records of the scope history.

• As a project manager I want to change my defined milestone dates.

  1. An online form should be filled with a detailed description of the new milestone and a justification statement.
  2. The statement should be sent to the role ‘approver’.
  3. The project manager should be informed of the approval result via email.
  4. The milestone changes should be achieved by the role ‘approver’.

• As a change approver I want to set all approved milestones and their end dates.

  1. The approver should not change any milestones without the proposal of the project manager.
  2. If the project manager requested the change, the approver should be able to change the milestones.
  3. The project manager should not be able to change his milesteones himself.
  4. The corresponding project manager should be informed about the milestone changes by email.

• As a project manager I want to get approvel for proposed changes.

  1. A project manager should be informed of the aaproval of all changes proposed by him.
  2. The information about the approval should be sent by email.

• As a project manager I need approval for milestone changes.

  1. As described above the project manager should be informed by email.
  2. The role ‘approver’ will carry out the milestone changes.

• As a change approver I want ot approve proposed changes in projects I am a member of.

  1. The role ‘approver’ should be a member of all the projects she is authorized to approve changes.
  2. If an approver is not a member of a specific project he should not be authorized to approve any changes at all concerning this project.

• As a multi project manager I want to see the impact of proposed changes on my projects.

  1. A simple simulation mode should be implemented.
  2. The impact of resource exchange between several projects should be illustrated in the ressource planning report.
  3. Changes in the timelines of serveral projects and their interdependencies should be indicated.

Falls Euch noch weitere Anforderungen für das Change-Management-Modul in den Sinn kommen sollten, dann lasst es uns wissen! Unter unserer (mittlerweile) bekannten PMO-Community-Emailadresse könnt Ihr uns Eure Ideen entweder als User Story oder auch in jeder beliebigen, anderen Form ebenso mitteilen, wie entsprechende Akzeptanzkriterien.

Share
Posted in Allgemein | Tagged , , , , , , | 3 Comments

Macht Projektmanagement schlank – oder: Was hat Projektarbeit mit Rugby zu tun?

Anfang der 1990er Jahre wurden Prinzipien des lean management (schlanke Unternehmensführung) in der Software-Entwicklung eingeführt. Hatte man früher versucht, zum Projektstart sämtliche Risiken, Arbeitspakete und deren Abhängigkeiten möglichst vollständig vorweg zu planen, so hat sich bei nüchterner Betrachtung bald die Einsicht durchgesetzt, dass viele dieser „klassischen“ Projekte wegen ihrer Komplexität zum Scheitern verurteilt waren. Deshalb wurde versucht, die Komplexität großer Projekte zu verringern, indem man Teambildung unterstützte, aber vom normalen Monitoring und Controlling abwich. Klassisches Projektmanagement ist in vielen Fällen geeignet, die Überlastung der Mitarbeiter zu fördern und deren Motivation und Engagement zu schwächen. Im Sinne einer termingerechten Zielerreichung wirken diese Aktionen oft kontraproduktiv. Deshalb wurde versucht durch agile Vorgehensmodelle die Komplexität in der Projektarbeit zu verringern und dadurch die Motivation und Arbeitsleistung der Mitarbeiter, sowie die Wertschöpfung der Unternehmen zu steigern. Im Bereich der Software-Entwicklung ist dieses Modell unter dem Stichwort „Scrum“ bekannt geworden.

Scrum ist ein Begriff aus dem Rugby und bedeutet auf deutsch „Gedränge“. Das Gedränge ist ein Spielzug, bei dem sich Spieler beider Mannschaften in gebückter Haltung, eng umschlungen und nach vorwärts drängend, gegenüberstehen. Von einem Spieler der angreifenden Mannschaft wird der Ball in das Gedränge eingeworfen, woraufhin seine Mitspieler versuchen, den Ball nur mit den Füßen nach hinten, wieder aus dem Gedränge heraus zu befördern. Dort kann ihn ein Mitspieler aufnehmen und den nächsten Spielzug einleiten. Von außen betrachtet, wirken die Bewegungen der Spieler im Gedränge höchst komplex, wenngleich das Ziel klar erkennbar ist. Das Team kann dieses Ziel nur gemeinsam erreichen. Doch die einzelnen Bewegungen des Balles sind im Vorhinein nicht exakt vorherseh- oder planbar. Hierarchien sind hierbei keine zu erkennen und die Regeln dabei sehr einfach. Ähnliche Überlegungen hat man auf die agile Softwareentwicklung übertragen. Dabei wird sehr viel Verantwortung für die Einhaltung der Ziele und die Bearbeitung von Aufgaben den Teams übertragen. Viele klassische Managementaufgaben können dadurch entfallen. Dadurch ist die Reaktionsgeschwindigkeit bei Verzögerungen sehr hoch.

 

Ob nun die klassische oder die agile Methodik erfolgversprechender ist, lässt sich nicht eindeutig bestimmen. Doch haben sich am Samstag, den 28. Januar sechs wackere Recken im Pentamino-Büro getroffen – zwei weitere Mitstreiter wurden per Online-Meeting aus Barcelona zugeschaltet – und das weitere Vorgehen in unserem Projekt diskutiert.

 Nachdem im Vorfeld ein klassischer Projektplan entworfen worden war, hat sich im Laufe der Diskussion heraus kristallisiert, dass wir der agilen Scrum-Methode den Vorzug geben wollen. Während Partner und Kinder unserer Disputanten im Nachbarbüro den Tag mit Gesellschaftsspielen, sowie Kaffee, Kakao und Kuchen zugebracht haben, haben wir „Projektler“ eifrig mit Hilfe von User Stories Anforderungen für die Implementierung des Change Managements aufgenommen. Außerdem haben wir alle administrativen Elemente während unseres Workshops besprochen und schon einmal die Termine der künftigen Sprints festgelegt. Als Stichtag für das Rollout des ersten Releases wurde der 01. Juli 2012 bestimmt. Während bei unserem ersten Kickoff-Meeting, noch hauptsächlich unsere eigenen Ideen in die Anforderungsanalyse eingeflossen sind, sollen künftig überwiegend Anregungen aus der PMO-Community aufgegriffen werden. Denise wird Euch informieren, wie Ihr Eure Ideen in das Projekt einbringen könnt. Während der kommenden Woche werden die User Stories noch um geeignete Akzeptanz-Kriterien ergänzt. Danach wird die Entwicklung mit Hochdruck starten, weil der nächste Sprint bereits am 18. Februar stattfinden wird. Bis dahin werden die ersten, neu entwickelten Funktionen getestet sein und dem obligatorischen Review unterzogen werden. Im nächsten Planungsmeeting wird das Thema Risikomanagement betrachtet werden. Also zögert nicht, kommt mit ins Boot und meldet Euch für die Sammelmail der PMO-Community an!

Share
Posted in Allgemein | Tagged , , , , , , | 5 Comments

„Der Wechsel allein ist das Beständige.“

Dieses Zitat von Arthur Schopenhauer drückt sehr genau aus, womit wir in unseren Projekten ständig zu kämpfen haben: Wechsel, Wandel, Erweiterungen, Änderungen. Zweifellos ist es höchst ärgerlich, dass Inhalt und Umfang eines Projektes geändert werden müssen, weil sich neue Anforderungen ergeben, während das Projekt bereits in vollem Gange ist. Jeder von uns kennt die Situation: Wie können wir die neuen Anforderungen berücksichtigen? Welche Konsequenzen ergeben sich für das Budget? Kann die vorgegebene Qualitätsnorm nach wie vor erfüllt werden? Benötige ich zur Bewältigung der Mehrarbeit externe Mitarbeiter? Wie gehen wir damit um, wenn unsere Liefergegenstände fehlerhaft sind? usw., usw. …

© Rainer Sturm / www.pixelio.de

Derlei Fragestellungen und Probleme zu vermeiden, wäre zwar ein netter Versuch, ist aber i. d. R. unmöglich (sofern es sich um nicht triviale, relativ große und komplexe Projekte handelt). Natürlich muss es unser Bestreben sein, bereits in einer frühen Projektphase möglichst alle Anforderungen vollständig zu beschreiben. Auch sollten möglichst alle Risiken umfassend erkannt und ihren Bewältigungsmaßnahmen gegenüber gestellt werden. Da aber Hellsehen nicht Bestandteil eines typischen Skill-Profils für Projektmanager ist, wird dies niemals erschöpfend gelingen. Deshalb müssen wir unser Hauptaugenmerk auf konsequentes Change- und Risiko-Management richten.

Sicherlich: Arbeit auf Zuruf ist auch eine Form des Change-Managements. Dem Kunden oder einem anderen Stakeholder fällt ein, dass das gewünschte Produkt dringend einer kleinen Änderung bedarf. Der Aufwand dafür dürfte ja nicht allzu hoch sein. Deshalb fragt man am besten direkt den Ingenieur oder den Entwickler, der den Wunsch netterweise auch gleich realisiert. Beim nächsten Statusmeeting kann man immer noch den Projektverantwortlichen informieren, der sicher Freude strahlend zur Kenntnis nehmen wird, wie schnell und flexibel man wieder mal auf derlei Anliegen reagiert hat. Dieses Szenario ist – leider – gar nicht wenig verbreitet. – OK, in kleinen Projekten ohne komplexe Abhängigkeiten, mag dieses Verhalten sogar ganz gut funktionieren. Im Gros der Fälle hat man es jedoch mit einer komplizierten Projektlandschaft zu tun, in der Abhängigkeiten zwischen Tasks oder Projekten bei Arbeit durch Zuruf katastrophal wirken können. Deshalb ist es enorm wichtig, Change-Prozesse in einem Unternehmen klar zu definieren und – noch wichtiger! – zu leben. Im Idealfall werden diese Prozesse unternehmensweit definiert und angewandt, so dass sie jedem Mitarbeiter und Stakeholder in Fleisch und Blut übergehen. Üblicherweise werden Changes mittels eines Software-Tools gesammelt, beschrieben und grob priorisiert. In Abhängigkeit vom geschätzten Aufwand entscheiden danach bestimmte Institutionen (Projektmanagement, Kundenmanagement, Lenkungsausschuss usw.) über die Umsetzung. Dabei fallen Änderungen am Produkt bzw. an Inhalt und Umfang eines Projektes auf Einzelprojektebene an. Darüber hinaus wird es innerhalb eines Projektportfolios aufgrund der knappen Ressourcen (Mitarbeiter, Budget, Ausstattung) immer auch die Notwendigkeit zur Projektpriorisierung und damit einhergehend zur Ressourcen-Reallokation geben. Diese Entscheidungen müssen dann aus einer Multi-Projekt-Sicht heraus getroffen werden. Allerdings kann dies nicht aus einem bloßen Gefühl heraus geschehen, sondern muss eine solide Datenbasis sowie deren Aufbereitung und Interpretation zur Grundlage haben. Diese projektübergeordnete Datenbasis effizient und nachhaltig aufzubauen, ist eine wichtige Aufgabe eines PMOs.

Es muss möglich sein, als Entscheidungsgrundlage aus den Daten der Einzelprojekte und deren Interdependenzen, aussagekräftige Reports für die Entscheidungsgremien auf der Multi-Projekt-Ebene zu generieren. Dies setzt voraus, dass das verwendete Software-Tool hochgradig konfigurier- und erweiterbar ist, um die unternehmensindividuellen Informationsquellen optimal nutzen zu können. Zweifellos bietet diese Möglichkeit theoretisch natürlich jede IT-Lösung. Mit dem entsprechenden Aufwand und den entsprechenden finanziellen Mitteln ist (fast) alles möglich! Für mittelständische Unternehmen, deren Mittel begrenzter sind, als die von Großkonzernen, bietet sich diese Möglichkeit aber i. d. R. nicht. Daher haben wir beschlossen unsere Software als Open Source Lösung zu entwickeln, um individuelle Anpassungen und jederzeitige Erweiterbarkeit mit überschaubarem Aufwand zu gewährleiten. Das Change Management wird hierbei eine wichtige Komponente mit zahlreichen, konfigurierbaren Funktionen bilden.

Share
Posted in Allgemein | Tagged | 4 Comments

Unser PMO-Software-Projekt ist gestartet!

Letzte Woche hatten wir hier im Blog dazu aufgerufen, bei unserem Projekt zur Entwicklung einer Open Source PMO-Software auf Basis von ]project open[ mit zu machen. Parallel dazu haben wir einige Experten im Projektmanagement angeschrieben und um deren Unterstützung gebeten. Die bisherige Ressonanz war wirklich überwältigend! Jede Menge Zuschriften haben uns innerhalbe weniger Tage erreicht. Darunter befanden sich viele gute Wünsche und „Weiter Sos“ aber auch schon ganz konkrete Vorstellungen bzgl. der Inhalte und Funktionen, die eine derartige Software abbilden sollte. Vielen Dank dafür!

Offensichtlich scheint in der Community ein echter Bedarf für unser Vorhaben zu existieren. Das motiviert uns natürlich, unser Projekt weiter voran zu treiben. Zunächst haben wir unsere Community-Mailadresse angelegt, unter der ihr euch eintragen könnt, um – neben dem Blog – bei wichtigen Ereignissen auf dem Laufenden gehalten zu werden. Für die Zukunft planen wir eine Community einzurichten, die auch eine offene Diskussion ermöglichen soll.

Nächster Schritt bei unserem Vorgehen wird sein, dass wir ein Konzept erstellen, das zunächst auf rein fachlicher Ebene die Funktionen beschreibt, die ein PMO unseres Erachtens nach haben muss. Leider ist der Begriff PMO weder in der theoretischen Literatur, noch in der Praxis exakt definiert. So wird z. B. die Abkürzung PMO je nach Bedarf mit „Project Management Office“, „Program Management Office“ oder „Portfolio Management Office“ übersetzt. Alle drei Arten von PMO unterscheiden sich dabei erheblich in ihren Aufgabenbereichen. In der Fachgruppe PMO der GPM wurden 12 Wirkungsfelder identifiziert:

Diese existieren jeweils in den Ebenen Einzelprojekt, Multiprojekt und Portfolio:

Zu jedem Wirkungsfeld gibt es in der zugehörigen Ebene Problemstellungen und damit korrespondierende Lösungen. Die detaillierte Beschreibung dieser Problem-Wirkungsfeld-Matrix wird während der nächsten Wochen die Hauptaufgabe der Konzeption sein. Daran anschließend werden Lösungsvorschläge erarbeitet und dabei auch Alternativlösungen nicht außer Acht gelassen. Unter anderem wird sich bei dieser Analyse ergeben, welche Problemfelder überhaupt von einer Softwarelösung profitieren können. Konkret sollen in der kommenden Woche Change Management und Risiko Management in Angriff genommen werden.

Share
Posted in Allgemein | Tagged | 5 Comments