Archiv der Kategorie ‘Projektmanagement‘

 
 

#42 PMQS

Alexander Volland ist mir seinerseits bei Wikipedia über den Weg gelaufen. Gemeinsam haben wir uns um das Wikiprojelkt Projektmanagement gekümmert – und mittlerweile etwas frustriert auch wieder zurückgezogen. Er betreibt eine eigene Projektmanagement-Plattform unter http://www.pmqs.de

. Alexander bastelt auch an einem ehrgeizigen WBT zum Thema Projektmanagement.

#40 PM FAQ

Bei weniger technischen Themen, wie z.B. dem Projektmanagement wird die Luft in den Internet-Foren deutlich dünner, als in IT-nahen Themengebieten.

Selbst in Fachpublikationen wie dem Projektmagazin finden sich nur sehr rar Beiträge, auch wenn hier im Laufe der Zeit die Struktur gewachsen ist:

  • http://www.projektmagazin.de/forum/index.html
  • Und selbst bei der GPM wird unter dem Stichwort Diskussionsforum „gemogelt“ oder besser gegoogelt, denn dahinter verbirgt sich kein Forum, sondern eine vorkonfigurierte Google-Suche:

  • http://www.gpm-infocenter.de/
  • Vielversprechender sind da mitunter die Gruppen der Online-Community/des Abodienstes XING, insbesondere die Gruppe „Projekte oder das Management von Vorhaben“:

  • https://www.xing.com/net/projektmanagement
  • Darüber hinaus gibt es aber auch noch eine ganze Reihe von Business-relevanten Gruppen:

  • Consulting Business
  • Vorgehensmodelle in der IT
  • Changemanagement
  • Und auch eine eigene GPM-Community findet sich hier:

  • https://www.xing.com/net/gpm
  • #38 MS Project FAQ

    Nicht Web 2.0, aber besten user generated content liefert nach wie vor das Usenet (mittlerweile über goolge groups erreichbar). Hier finden sich auch zwei für Nutzer von Microsoft Project interessante Gruppen, die weitaus mehr bieten als nur frequently asked questions:
    http://groups.google.de/group/microsoft.public.de.project (deutsch)

    und

    http://groups.google.de/group/microsoft.public.project (englisch)

    Zwar können die Foren nicht ganz mit Foren zu anderen Office Produkten mithalten, aber dies sind noch immer die besten Beiträge zu MS Project.

    Die morderate Beteiligung könnte als Indiz für die vielfach noch oberflächliche Nutzung von MS Project sein.

    #36 Projektmanager

    Was bitte ist ein Projektmanager? Oder besser: Was ist der Unterschied zwischen einem Projektmanager und einem Projektleiter?

    Im Englischen besteht kein Unterschied. Der Project Manager bezeichnet nichts anderes als den Projektleiter.

    Im Deutschen ist der Projektmanager hingegen eher als Stabsstelle, die den Projektleiter unterstützt „sein Projekt zu managen“ zu verstehen. Im englischsprachigen Raum würde man eine solche Aufgabe in einem PMO (Project Management Office) angesiedelt sehen. Je nach Ausprägung kann ein PMO aber auch eine reine Sekretariatsfunktion wahrnehmen, während der gute, deutsche Projektmanager als Projektmanagement-Experte zu sehen ist, der den Projektleiter entlastet und ihm Freiräume zur inhaltlichen Mitarbeit im Projekt oder zum „Verkaufen“ des Projekts gegenüber den Stakeholdern verschafft.

    #35 Grenzen der Planung

    Als Schlusspunkt dieser Reihe mit Beiträgen zur Planung noch ein Thesenkatalog über die Grenzen der Planung:

  • Keine Planung ist für die Ewigkeit geschaffen.
  • Nach der Planung ist vor der Planung.
  • Planung ersetzt den Zufall durch den Irrtum.
  • Die Zauberformel heißt: Angemessenheit.
  • Planungtiefe: Die Planung sollte nur so tief sein, wie sie auch verfolgt und fortgeschrieben werden kann.
  • Planung ist kein Selbstzweck.
  • Planung muss beherrschbar bleiben.
  • Planung ersetzt keine Abstimmung und Kommunikation.
  • Am Ende zählt nur der Erfolg und nicht die Planung.
  • Planänderungen sind Tagesgeschäft.
  • #34 Abhängigkeiten & Komplexität

    Die Abbildung von Abhängigkeiten in der Projektplanung ist ein zweiseitiges Schwert. Einerseits ist die Kenntnis von Abhängigkeiten erforderlich, um Auswirkungen des Verlaufs von Arbeitspaketen aufeinander abschätzen, sowie Termine und Kosten automatisch bei Planänderungen aktualisieren zu können, auf der anderen Seite sprengt die damit verbundene Komplexität regelmäßig die Projektplanung.
    Die Abbildung von generischen Abhängigkeiten – meist auf einem sehr hohen Level – ist zwar noch einfach, ihre Aussagekraft hingegen tendiert gegen Null und grenzt an Trivialität, ja, sie ist mitunter sogar falsch. Einerseits erscheint es logisch, dass die Konzeption abgeschlossen sein muss, bevor eine Realisierung beginnen kann, diese muss wiederum abgeschlossen sein, bevor ein Test erfolgen kann, etc., aber die Wahrheit sieht anders aus, zumindest in einer schnelllebigen Zeit wie der unseren, in der viele Aktivitäten parallelisiert werden. Natürlich muss die Konzeption nicht vollständig abgeschlossen sein, bevor ene Realisierung beginnenen kann. Zunächst sind nur gewisse Eckpunkte erforderlich, die parallel zur Realisierung noch um die fehlenden Details zu ergänzen sind, usw., d.h. aber auch dass eine Pflege von Abhängigkeiten in einer Planung nur dann sinnvoll möglich ist, wenn man die Planung bis auf die kleinste erforderliche Planungeinheit herunterbricht. Dies kann mitunter eine Planung unbeherrschbar machen. Die Planungstiefe und die Detaillierung wird schnell zum Problem.
    Für komplexe Planung gab mir einst ein auf MS Project spezialisiertes deutsches Systemhaus mit auf den Weg, dass sie ihren Kunden in komplexen Problemen von der Pflege von Vorgänger-/Nachfolgerbeziehungen (und in solchen werden Abhängigkeiten abgebildet) in den dafür vorgesehenen Feldern abraten würden. Wenn sie diese Beziehungen abbilden, dann würden sie Textfelder hierfür missbrauchen, damit die Plandatei noch pflegbar bleibt.
    Natürlich ist es trotzdem sinnvoll, ja auch erforderlich sich mit Abhängigkeiten auseinanderzusetzen. Entscheidend ist, dass in einem Projekt alle voneinander abhängigen Parteien miteinander reden und sich ihrer Abhängigkeiten bewußt sind. Die Abbildung in der Planung ist hingegen eher ein Formalie und darf nur soweit gehen, dass sie den Rahmen der Planung nicht sprengt. Hierfür gibt es aber auch alternative Konzepte, wie z.B. eine DEBI-Matrix, in der je Arbeitspaket definiert wird welche Partei für die Durchführung zuständig ist, wer ein Paket zu verantwortden und darüber zu Entscheiden hat, wer lediglich Beratend mitwirkt und wer Informiert werden sollte.

    #33 Planungstiefe

    Wie tief soll geplant werden? Reicht es in einem Projekt die groben Phasen zu planen oder ist eine Planung bis ins letzte i-Tüpfelchen erforderlich? Nun, entscheidend für die Planugstiefe ist vor allem der konkrete Planungszweck. Um Messpunkte für den generellen Fortschritt zu ermitteln oder eine Vorstrukturierung vornehmen zu können reicht bereits eine relativ grobe Planung. Auf der anderen Seite braucht es für die Inbetriebnahme eines Kernkraftwerks oder die die komplexe Produktivsetzung einer neuen IT-Architektur minutiös detaillierte Feinplanungen.

    Aber selbst darüber, wie weit die Feinplanungen an die Grobplanungen anknüpfen lässt sich mitunter schon streiten. Was schert mich heute meine Planung von gestern, wenn das einzige was zählt der Projekterfolg ist? Häufig wird gar nicht das gesamte Projekt sondern nur besonders wichtige Abschnitte, wie ein Cutover oder eine Migration detailliert geplant. Für den Rest ist eine Grobplanung vollkommen ausreichend.

    Es ist gar nicht notwendig alles bis ins kleinste Detail auszuplanen. Zum Einen, weil man die Kräfte der Selbstorganisation nicht unterschätzen darf, sondern durchaus auch nutzen sollte (einem eigenverantwortlich handelndem Team darf man durchaus zutrauen sich selbst zu koordinieren), zum Anderen, weil uns die Realität schnell wieder einholt und der Plan von gestern heute schon wieder überholt ist. Wir dürfen nicht vergessen, dass eine Planung nur in der Tiefe sinnvoll ist, die wir nachher auch wieder verfolgen und aktualisieren können. Viele Vorurteile über die Bürokraten vom Projektmanagement, die alles mit Formalismen und zusätzlichen Aufgaben überziehen und dabei das Projekt zu Tode planen rühren genau hierher. Weniger Planung ist häufig mehr.

    Das Zauberwort zur Planungstiefe heißt daher: Angemessenheit. Es gilt den angemessenen Level einer Planung zu finden. Dieser Level kann durchaus von Projekt zu Projekt unterschiedlich ausfallen.

    #32 Gegenstand der Planung

    Gegenstand der Planung ist zunächst das magische Dreieck aus Termin, Kosten und Qualität/Inhalt.

    Darüber hinaus auch der Weg zur Zielerreichung (Ablauf/Vorgehen, Personal, Ressourcenbedarf, …)

    Dies spiegelt sich in den verschiedenen Arten von Plänen wieder:

  • Projektstrukturplan (Aufgabenstrukturplan)
  • Ressourcenbedarfsplan
  • Projektablaufplan
  • Zeitplan
  • Kostenplan
  • Personaleinsatzplan
  • Organisationsplan
  • Kontroll- und Berichtsplan
  • (Quelle: Tiemeyer/Chrobok)

    Neben den einzelnen Planungen steht die Integration der Einzelpläne, schließlich soll auch eine Ressourcenplanung zur reinen Zeitplanung passen. Die Einzelpläne greifen ineinander. Letztlich stellen sie alle nur Facetten einer Gesamtplanung dar.

    #31 Planung (Sinn und Zweck)

    Planung ersetzt nicht nur den Zufall durch den Irrtum.

    Planung hilft den Arbeitsgegenstand, das Problem und die Vorgehensweise zur Problemlösung zu strukturieren.

    Planung macht den Projektfortschritt messbar.

    Planung ist ein Instrument der Projektsteuerung.

    Die alles sagt aber noch nichts über die Planungstiefe und die Planungskomplexität, die mit einem Plan abzubilden sind.

    #30 Planung (Definition)

    Es folgen in Kürze einige Beiträge zum Thema Planung. Gleich zu Beginn stellt sich die Frage, was Planung eigentlich ist.

    Hier drei Definitionen:

    (1) Systematisches, zukunftsbezogenes Durchdenken und Festlegen von Zielen sowie der Wege und Mittel zur Zielerreichung.
    Quelle:
    www.siegfried- seibert.de/Wissensspeicher/PMGlossar

    (2) Planung ist ein soweit als möglich systematischer Entscheidungsprozess mit dem Ziel Handlungsspielräume problemorientiert einzugrenzen und zu strukturieren.
    Quelle:
    de.wikipedia.org/wiku/Planung

    (3) Die Planung eines Projektes besteht in einem systematischen, vorausschauenden Durchdenken des Projekts, einer Analyse des Projektauftrags und der mit ihm angelegten Aufgaben und dem Versuch der Minderung von Risiken.
    Quelle:
    Tiemeyer/Chrobok

    

    bernhardschloss.de