Monatsarchiv für November 2009

 
 

#288 Schulz von Thun

Sie kennen Friedemann Schulz von Thun nicht? Das glaube ich nicht! Wahrscheinlich kennen Sie seine Bücher über Kommunikation und Psychologie(Amazon Affiliate Link) Und wenn nicht seine Bücher, dann zumindest die Kommunikationsmodelle hieraus. Zamyat M. Klein und Stephan List haben jetzt seine Abschiedsvorlesung ausgegraben. Einen Link, den ich nicht vorenthalten möchte.

#287 Quote: Conventional Project Management

Conventional project management practices, which originated in the 1950s using mathematical models and structured planning approaches, assume a stable and predictable environment. Conventional project management works well and should be used for predictable, repeatable projects; however, this approach has proven to be no match for chaotic 21st century projects.

aus:

Kathleen B. Hass (Amazon Affiliate Link)
Managing Complex Projects: A New Model
Management Concepts, Vienna (USA) 2009
ISBN-10: 1567262333
IBSN-13: 978-1567262339

S. 32

#286 Gelesen: Managing Complex Projects

Auch Kathleen Hass folgt einer systemorientierten Sichtweise von Projekten. Sie spricht von „complex adaptive systems“ und entwickelt in ihrem Buch ein eigenes Project Complexity Modell.

Mit der systemorientierten Sichtweise und dem Fokus auf die Komplexität trifft sie bei mir einen Nerv, dem ich nur zu gerne folge.

In ihrem Project Complexity Modell unterscheidet sie dann independet, moderately complex und highly complex projects. Mit ihrem Versuch diese Kategorien messbar zu machen und zu quantifizieren macht sie sich natürlich beliebig angreifbar. Der Versuch ist ehrbar, vermessen und muss natürlich scheitern. Nimmt man aber die Quantifizierung und konkrete Ausprägung nicht ganz so wichtig, sondern würdigt mehr die dahinterstehende Idee, so bleibt das Buch absolut lesenswert. Es handelt sich ja auch nicht um ein Lehrbuch, sonder um einen fundierten Diskussionsbeitrag, der zur weiteren Reflexion anregt.

In der zweiten Hälfte des Buches setzt sie sich dann dezidiert mit den möglichen Komplexitätsquellen in Projekten auseinander. Als solche werden genannt und ausführlich behandelt:

  • large, long duration projects
  • large, disperse, culturally diverse project teams
  • highly innovative, urgent projects wth agressive scopes and schedules
  • complexities caused by ambigious business problems, oppotunities, and solutions
  • poorly understood, volatile requirements
  • highly visible strategic projects, which are often politically sensitive
  • large scale change initiatives
  • projects with significant dependencies and external constraints
  • IT complexity

Kathleen B. Hass
Managing Complex Projects: A New Model,
Management Concepts, Vienna (USA) 2009
ISBN-10: 1567262333
IBSN-13: 978-1567262339

(Amazon Affiliate Link)

#285 Compliance bei Cloud Computing, Outsourcing & Offshoring

Ein Beitrag von Oliver Häussler im CIO-Magazin setzt sich mit den Compliance-Anforderungen beim Cloud Computing auseinander. Als relevante Aspekte werden insbesondere der Schutz von personenbezogenen Daten (Datenschutz) ebenso wie den Geheimnisschutz, also die Sicherung von Unternehmensinformationen, sowie die Verfügbarkeit und Sicherheit der Systeme und Anwendungen, genannt.

Die gleichen Aspekte sind natürlich auch bei den Themen Outsourcing & Offshoring relevant, auch wenn der Artikel hier nicht näher darauf eingeht. Bei diesen beiden Themen kommen aber noch weitere Prüfaspekte hinzu: Beim Outsourcing das Thema Datenverarbeitung durch Dritte und beim Offshoring die Außenhandelsproblematik. Hat ein Administrator im Ausland Zugang zu den Daten auf einem System, so ist dies als Datenexport zu interpretieren – mit allen Konsequenzen des Außenwirtschaftsgesetzes (AWG) und der relevanten Verordnungen.  Das kann schizophrenerweise sogar dazu führen das im reinen Binnenhandel Ausfuhrgenehmigungen erforderlich sind, wenn der Server im Ausland steht oder aus dem Ausland administriert wird. Worst Case ist die Verlagerung nicht einmal genehmigungsfähig.

#284 Einstellung und/statt Web 2.0

Eberhard Huber bringt es mal wieder auf den Punkt: Bei allem Hype um das Web 2.0 und Social Software wird das Wesentliche leicht vergessen – entscheidend sind Einstellung und Verhalten, weit danach kommt erst der Tooleinsatz bzw. die Toolunterstützung oder mit einer alten Binsenweisheit ausgedrückt: „A fool with a tool is still a fool.“

#283 Projekttagebuch selbstgemacht

Die einfachste Form eines Projekttagebuchs oder Logbuchs lässt sich mit Windows-Bordmitteln erstellen. Erstellen Sie mit dem Notepad einfach eine neue txt-Datei. Dann tragen Sie in die allererste Zeile folgendes ein:

.LOG

Speichern und schließen sie die Datei (z.B. auf ihrem Desktop, damit sie sie immer schnell zur Hand haben). Beim nächsten Öffnen der Datei ergänzt der Notepad automatisch die akutelle Uhrzeit und das Datum:

.LOG
20:03 09.11.2009

Und nicht nur beim nächsten Mal, sondern immer wenn Sie die Datei neu öffnen:

.LOG
20:03 09.11.2009
Eintrag 1: Lorem ipsum dolor sit amet, consectetur adipiscing elit. Phasellus mollis ornare est sodales tempor. Nam quis iaculis nisi. Donec gravida, nunc tristique vestibulum porttitor, risus urna cursus mauris, non laoreet est urna vitae eros. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

20:06 10.11.2009
Eintrag 2: …

Zugegebenermaßen nicht gerade komfortabel, aber als schnelle quick&dirty-Lösung durchaus ok.

#282 Projekttagebuch

Im frei zugänglichen Forum des Projektmagazins (ansonsten ein Abo-Dienst) hat die Moderatorin und Blogger-Kollegin Sigrid Hauer einen lesenswerten Thread gestartet: Gibt es das Projekt-Tagebuch wirklich?

Eine Reihe von Kollegen haben sich gemeldet, ja das gibt´s wirklich…

Da gibt es dann u.a. den Hinweis auf Wikis und Foren, aber die Erwähnung des Tools in diversen Standards und ganz persönliche Erfahrungen.

Ein Projekttagebuch ist zu allererst ein Werkzeug. Kein Heilbringer. Sinvoll eingesetzt kann es gute Dienste leisten. Aber um ehrlich zu sein, ich habe es noch nie im größeren Stil eingesetzt gesehen. Ich nutze es gerne z.B. im Rahmen einer Urlaubsvertretung, um den Rückkehrer schnellst möglich einen Überblick zugeben, bevor er sich durch einen eMail-Dschungel kämpfen muss oder in Projektphasen, die von Unklarheit geprägt sind, wenn die Aufgaben noch nicht strukturiert sind oder im Krisenmanagement, wenn die Ereignisse einen überrollen, um selbst wieder eine Übersicht zu gewinnen.

#281 Status Reports und die Realität

In einem Gastbeitrag auf PMStudent setzt sichSusan de Sousa damit auseinander ob Statusberichte tatsächlich den Projetkfortschritt wiedergeben und hat natürlich auch gleich ein entsprechendes Negativbeispiel an der Hand.

Das Grunddilemma liegt wohl darin, dass die Berichterstattung gleichzeitig für die unterschiedlichsten Berichtszwecke eingesetzt wird. Ja, klar soll ein Statusbericht Transparenz in das Projekt bringen. Ja, aber er dient auch der Rechtfertigung (manchmal auch der Schuldzuweisung). Mitunter der Außendarstellung. Von hidden agendas einzelner Beteiligter noch ganz abgesehen…

Manchmal dient er auch dazu das Gesicht zu wahren und einen Neuanfang zu ermöglichen. Hierzu ein echtes Beispiel:
In einem Projekt durfte ich ein Review aller Teilprojekte durchführen und betreuen. Alle Beteiligten gingen sehr förmlich und höflich miteinander um, schließlich diente das Review der Einphasung eines neuen Projektleiters. Es wurde gelogen, dass sich die Bretter nur so bogen: alles bestens – ein paar Schwierigkeiten hier und da, aber im eigenen Teilprojekt kein wirkliches Problem. Ich unterstelle allen Beteiligten genügend Intelligenz, dieses Lügenspiel durchschaut zu haben, aber dennoch hat niemand widersprochen, denn das Review erlaubte einen „sauberen“ Schlußstrich unter die Vergangenheit, der in einem entsprechenden Lügenreport verewigt wurde und es gelang in der Tat ein gesunder Neuanfang.

Bitte nicht missverstehen, das war jetzt keine Aufforderung zur Lüge, sondern eher zum richtigen Umgang mit Berichten. Fünfe gerade sein lassen, kann mitunter sinnvoll sein, aber im genannten Beispiel ist dies auch nicht aus Ahnunglosigkeit geschehen, sondern aus politischem Geschick, das letztendlich zur Teambildung beitrug.

#280 Edward de Bono_03

Last but not least gibt es auch in brandeins 11/2009 ein Interview mit Edward de Bono…

#279 Medieneinsatz

Vielleicht sollten wir in der Diskussion über den Einsatz von Social Media in Projekten zwischen Medium (Blog) und Werkzeug (Projektagebuch) differenzieren. Was den Einsatz der verschiedensten Medien angeht, so ist ein Medienbruch natürlich kritisch zu sehen, deswegen sehe ich Werkzeuge wie Wikis und Blogs eher skeptisch und bevorzuge flexible Content Management Systeme. Im Einzelfall (z.B. aus Kostengründen) können Ausnahmen natürlich absolut Sinn machen. Der Medieneinsatz sollte aber halt nicht der neuesten Mode folgen (Twitter), sondern sich an den Bedürfnissen orientieren. Ist dies erfüllt, ist natürlich auch alles erlaubt…



bernhardschloss.de