Wikipedia Diskussion:WikiProjekt Projektmanagement/Archiv bis 2010

anarchistische Projektorganisation

Ich fände es ziemlich interessant etwas über Projektorganisation unter herrschafts- und hierarchiekritischen Gesichtspunkten zu lesen. Ich kenne mich da leider nicht genug aus, um dazu etwas zu schreiben, aber da es (in Osteuropa mehr als in Deutschland) viele anarchistische/ anarchosyndikalistische/ emanzipatorische Gruppen und Organisationen gibt, die das betreiben, wäre das Thema vielleicht der Vollständigkeit halber wichtig.

Vielen Dank! 88.70.93.107 00:29, 13. Feb. 2008 (CET)

Namensraum beachten

Bitte nicht beim Ausgliedern hier auf einmal in den normalen Artikel-Namensraum kommen. Bitte erstmal Wikipedia:Zweite Schritte lesen, bevor man mit so "großen" Aktionen wie der Umstrukturierung eines Wikiprojektes loslegt! Uli 13:39, 4. Apr 2004 (CEST)

Configuration Management

Frage: Derzeit haben wir unter Konfigurationsmanagement und auch mit dieser Bezeichnung in einigen Artikeln etwas definiert, was ich als Management des Projektrahmens bezeichen würde (Was ist drin im Projekt und was nicht). Die Bezeichnung "Konfigurationsmangement" ist für mich extrem ungewöhnlich, die engl Entsprechung "Configuration Management" findet sich auch nicht im PMBOK. "Konfigurieren" heißt normalerweise, aus einer Reihe vorgegebener Parameter die gerade passenden auszuwählen, aber das ist nicht das, was das Management des Projektrahmens macht. Gibts irgendwelche Literatur, in der die Bezeichnung so verwendet wird? Für kurze INfo wär ich dankbar, sonst änder ich das demnächst mal ab. Uli 10:33, 24. Apr 2004 (CEST)

Hallo Uli, habe nachgesehen: du hast Recht im PMBOK wird der Begriff nicht verwendet, dafür aber bei Maddaus, Kerzner und Burghardt. Schlage vor, wir sollten den Begriff daher nicht streichen, sondern uns um eine saubere Definition bemühen. Gruß, Bernhard 17:35, 24. April 2004

Auch Hallo, ich denke, Deine Interpretion, Uli, greift etwas zu hoch. Management ist im Englischen ja doppeldeutig und kann auch einfach sowas wie Handhabung, Bearbeitung oder auch Wesen bedeuten. Wenn ich mir daraufhin den Artikel ansehe, finde ich ihn in Ordnung, allerdings etwas abstrakt und wenig anschaulich: ... (weiter auf Diskussionsseite: Configuration Management, Projektmanagement). --wolfy 17:44, 27. Apr 2004 (CEST)

Der Begriff stammt aus der Konstruktion. Das erklärt diese "Baukasten- und Stellschraubenorientierung" bei der Begriffserklärung, eben aus der Stückliste, wie beschrieben.

Ich kenne diese Funktionalität als ziemlich umfangreiches und komplexes Modul einer ERP-Software.

Wie ein Krake wickelt es sich um jede einzelne Teilestamm-, Stücklisten- & Arbeitsplan-Verwaltungsfunktion. Das Modul heißt genau so: Configuration Management. Die traditionelle Bezeichnung unter deutschen Konstrukteuren lautet Änderungswesen (mit Varianten). Dies ins Englische Change Management zu übersetzen, hätte allerdings zu Doppeldeutigkeit geführt.

Es beinhaltet nicht nur

• eine "ewige" Vorhaltung der Dokumentation sämtlicher Änderungsschritte an Bauteilen und Baugruppen (Teilestämme, Stücklisten, Arbeitspläne), sondern auch
• eine differenzierte Verwaltung und Zuordnung von Änderungsberechtigungen und Änderungsvoraussetzungen (z.B. nach Sicherheitsklassen), mit der Möglichkeit, Bool'sche Logik durch die Anwender zu formulieren.
  • Wer darf Änderungsanträge stellen, prüfen, genehmigen, ausführen?
  • In welcher Reihenfolge wird durch welche Abteilungen geprüft?
  • Wer darf parallel prüfen, und welche Prüfungen setzen Genehnigungen anderer Abteilungen voraus?
  • Auch die Dokumentation von Prüfungsvorschriften, -fortschritten und -ergebnissen kann dazugehören.

Sind nicht alle Prüfungs- und Genehmigungsbedingungen für einen bestimmten Eintrag erfüllt, sind Verwaltungsfunktionen dafür nicht verfügbar.

Es handelt sich um einen eigenständigen Typ von Geschäftsvorfällen, mit mehreren Vorgangsarten innerhalb mehrerer Vorgangstypen.

Diese Funktionalität kann im Grunde wie eine komplette Auftragsverwaltung für eine eigenständige Gruppe von Auftragstypen, mit eigener Business Logik, Auftrags-Statusfortschreibung und allem Komfort betrachtet werden.

In diesem Verständnis gehört zum Configuration Management nicht nur die Hinterlegung der entsprechenden Regelwerke, sondern auch ihre verantwortliche Definition sowie ihre Verabschiedung, nicht selten in bindender Abstimmung mit Auftraggebern..., es fallen dort also nicht nur reine Administrationsaufgaben an...

Gebraucht wird sowas für die Konstruktion sicherheitskritischer Produkte und die entsprechenden Herstellungsvorschriften:

• Die Rüstungsindustrie darf keinen Finger rühren ohne den Nachweis eines lückenlos dokumentierten, zwingend organisierten Änderungswesens (in heutiger Alltagssprache: "Konfi Management", oder kurz: "Konfi").
• Ähnliches gilt für Flugzeuge, Lifte, Busse (glaube ich), ...

Projektmanagement

Es ergibt durchaus Sinn, den Einsatz solcher Regelwerke auf das Projektmanagement zu übertragen (ob das geschieht, weiß ich nicht, Bernhard verstehe ich so). - Hier wie dort liefe dann ein Administrator mit Laufzetteln unter involvierten Abteilungen von einer zur anderen, um schwebenden Prüfungen nachzugehen und Genehmigungen für Änderungsanfordeungen einzuholen. In einem ERP-Implementierungsprojekt, z.B., könnten Letztere von Anwendern, aus der Kunden- oder Beratungs-Programmierung, vom Projekt- oder Beratungs-Team, aus der Kunden- oder Beratungs-Projektleitung, oder vom Kunden- oder Beratungs-Management kommen.

Sie werden seltener mit der Veränderung von Rahmenbedingungen und Zielen (!) zu tun haben, sondern eher mit viel Klein-Klein. Weiterreichende Änderungsanträge wären natürlich nicht ausgeschlossen, i.d.R. dürften sich diese aber eher als Schlußfolgerungen ergeben, die das Management aus seinen übrigen Änderungsgenehmigungen zu ziehen hat.

Eine sachgerechte Übertragung auf Projektmanagement dürfte ggf. etwas weniger restriktiv sein, doch das ist wohl auch Geschmackssache.

Manchem hochkomplexen ERP-Projekt, das ich gesehen habe, hätten solche strengen Formalismen verdammt gut getan, das Dumme ist nur: Konzeption und Implementierung des Regelwerks - egal, ob mit oder ohne Software-Unterstützung - bindet erheblich Kapazität, kommt also nur für ziemliche Mammut-Projekte in Betracht (ob wir mal die Maut-Experten fragen?)...

In etwas bescheidenerer Form habe ich so etwas im Grunde auch schon selbst eingeführt: als MS-EXCEL-realisierte Open Points List, in der alle OP's mit Anforderer, Begründung, Priorität (von KO bis Nice To Have) sowie Bearbeitungsstatus... zu dokumentieren waren. Dafür gab's Anforderungsformulare, was nicht in der Liste stand, war nicht offen, und wöchentlich einmal wurde zwischen Kunde und Beratung die ganze Liste durchgesprochen, Punkt für Punkt der Status, bis zur punktweisen Abnahme, gemeinsam abgestimmt und an Kunden- und Beratungs-PL verteilt.

Führung der OP-Liste und Statusverfolgung der OP's lagen beim stellvertretenden Kunden-PL (Chefprogrammierer). Das hat wunderbar funktioniert, um Ruhe ins Projektteam zu bringen: Der Berg von ungelösten Problemen - Nichts geht voran! - hörte auf zu kreissen...

--wolfy 18:47, 27. Apr 2004 (CEST)

Der Artikel wäre mit Informationen dieser Art sicher etwas anschaulicher zu machen..., könnte ich übernehmen, wenn Ihr meint..., allerdings fehlten uns dazu nach wie vor gewissere Informationen darüber, wie das ggf. für Projektmanagement aussieht... (oder ist das klar, Bernhard?)..., und meine Quellenkenntnis und Recherchenerfahrung dazu ist - noch (?) - gleich Null..., aber man lernt ja auch nie aus.
--wolfy 04:07, 27. Apr 2004 (CEST)

Zustimmung, Uli! Konfigurationsmanagement ist auch für meine Ohren ein fürchterliches Ungetüm, doch mir scheint, wir kommen nicht darum herum, wenn wir uns nicht abkoppeln wollen... Das bei uns traditionelle Änderungswesen ist zwar allgemeingültiger - mit Vorteilen bei der Übertragung auf andere Einsatzgebiete -, aber eben auch unspezifischer (s.u. bezügl. Arbeitsplan).
Ich fürchte, es kommt als eingefahrene Bezeichnung für diese Art, Angebots-, Produkt- und Dienstleistungs-Änderungen zu handhaben daher, nachdem es bei Baugruppen angefangen hat... (So funktioniert das Englische halt: Die fokussieren nicht, wie wir, das, worum es geht, sondern das, was man tut...)
--wolfy 20:25, 27. Apr 2004 (CEST)

P.S.: Beim Arbeitsplan kommen mir hinsichtlich eines Confi Mgmt - zumindest i.e.S. - Bedenken. Seine Fertigungsergebnisse - in Gestalt des Teilestamms - definieren ja implizit das Herstellungsverfahren. - M.E. war der Arbeitsplan im konkreten Modul Änderungswesen enthalten, das man dann Confi Mgmt nennen mußte, aber aus Sicht einer Baugruppen- oder Produkt-Konfiguration i.e.S. ist seine Information eigentlich redundant..., vorausgesetzt, jede Änderung des Herstellungsverfahrens führt zu einem neuen Teilestamm...
--wolfy 08:05, 27. Apr 2004 (CEST)

Glaube wir müssen den Redirect wieder rückgängig machen. Zum einen dürfen wir nicht aus unserer Diskussion für das Projektmanagement heraus einen Begriff, der auch in anderen Gebieten verwendet wird so einfach umleiten, zum anderen (auch wenn ich selbst die Interpretationvon CM als Änderungswesen als hilfreich empfinde) setzen wir uns damit etwas über die "allgemein verbreitete" Sicht der Dinge hinweg. Im Forum des Projektmagazins (www.projektmagazin.de) kam jüngst ach die Frage auf Konfigurationsmanagement. Habe dort dann in Kurzform unsere Diskussion gepostet und folgende ANwort erhalten:

Von Georg Angermeier am Dienstag, den 11. Mai, 2004 - 11:47: Hallo Herr Schloss,

die genauen Begriffsdefinitionen finden Sie im Glossar des Projekt Magazins - einfach dort mal nachklicken.

Zur konkreten Frage: Änderungswesen und Konfigurationsmanagement sind zwei paar Stiefel. Das Konfigurationsmanagement beschäftigt sich nach DIN 69904 mit der Spezifikation des Projektgegenstandes, d.h. dem Produkt. Innerhalb des Konfigurationsmanagements gibt es dann auch als einen Teil davon die Behandlung von Änderungsanforderungen.

Änderungswesen im allgemeinen betrifft auch Änderungen in der Projektorganisation (respektive im Unternehmen die Unternehmensorganisation).

Dem Änderungswesen fehlen aber einige äußerst wichtige Elemente des Konfigurationsmanagments: Z.B. gewährleistet die Konfigurationsüberwachung, dass die Produkte auch tatsächlich so ausschauen, wie es die Konfiguration vorsieht.

Konfigurationsmanagement weisen somit zwar Überschneidungen auf, aber das selbe sind sie ganz sicher nicht.

Bernhard 07:00, 16. Mai 2004

Neuer Erkläungsversuch:

Versuche mir selber weiter klar zu werden über die beiden Begriffe (CM & Änderungswesen). Momentan verstehe ich die beiden Begriffe so, dass sich CM zu Änderungswesen verhält, wie Systemdokumnetation zu Projektdokumentation. Änderungen an der Konfiguration des Systems gehen nicht zwangsläufig mit einer Änderung des Projketauftrags oder geänderten Anforderungen einher. Im Konfigmgmt würde beispielsweise dokumentiert: Fertigstellung Funktionsbaustein A, Fertigstellung Funktionsbaustein B, Integration der Funktionsausteine A nd B.

Helft mir bitte auf die Sprünge, wenn ich daneben liege.

Gruß Bernhard 09:45, 16. Mai 2004

Danke an Uli für die Überarbeitung Bernhard 21:17, 16. Mai 2004

Kategorie DIN 69901 ?

Hi allerseits,
nachdem ich ja recht begeistert bin was da so alles an Begriffsdefinitionen zur DIN 69901 da ist, wollt fregen obs den Sinnvoll wäre eine Kategorie:DIN 69901 aufzumachen? Oder bin ich gerade zu euphorisch? greetz vanGore 22:01, 10. Jul 2005 (CEST)

Wenn wir alle DIN-Normen als Kategorien etablieren, wird es etwas inflationär... Persönlich finde ich übrigens, dass (DIN-)Normen etwas antiquiert sind. Sie wollen allgemeingültige Standards sein, wären dies aber meines Erachtens nur, wenn sie beispielsweise dem GNU-Prinzip entsprechen würden. Das GNU-Prinzip gleicht aber einer Revolution für deutsches Normen-Denken. --Beschloss 21:55, 12. Jul 2005 (CEST)

Qualitätsmanagement in Kategorie Projektmanagement?

Abgesehen von den unbestreitbaren Synergien - warum ist QM in diese Kategorie eingeordnet? Wenn ich die Kategorie als hierarchische Einteilung verstehe (ist vielleicht nicht so gedacht), bin ich erstmal überrascht. Ein Projekt ist ja etwas einmaliges, Qualitätsmanagement nach Masing etwas andauerndes. --HoHun 19:21, 29. Sep 2005 (CEST)

Quality Assurance ist eine grundlegende PM Aufgabe, d.h. der PL muß im laufenden Projekt einen Qualitätszyklus eingerichtet haben, der die im Auftrag festgelegten Qualitätskriterien auf Zielerreichung prüft. So ist ist das kein Widerspruch: Qualitätsmanagement im Unternehmen ist was andauerndes, das heruntergebrochen aufs einzelne Projekt eben seine Entsprechung finden muß. Gruß --Flame99 09:25, 5. Okt 2005 (CEST)

Hm, Quality Assurance ist im QM-Verständnis Qualitätssicherung - da sehe ich jetzt nicht den Zusammenhang zur Projektarbeit. --HoHun 10:08, 5. Okt 2005 (CEST)

Nachdem ich den Link QM auf QM-in-Projekten geändert hatte, habe ich von AHZ ziemlich auf die Finger bekommen. Den Unterschied zwischen allgem. QM und QM als Wissensgiet und integraler Bestandteil des Projektmanagements sehe ich trotzdem (gleiches gilt für Personalmanagement und Beschaffungsmanagement). Jetzt habe ich eben in den allgem. Artikeln einen Hinweis auf PM-Spezifika hinterlegt.

Viele Grüße

Alexander Volland 16:11, 7. Okt 2005 (CEST)

Strukturell fand ich Deinen Ansatz eigentlich besser. Dein Hinweis in Projektmanagement hat mir aber auch so beim Verständnis geholfen: Qualitätsmanagement kann Projektmanagementverfahren definieren, und Projektmanagement kann aus dem Qualitätsmanagement stammende Methoden verwenden, ohne daß ein QM-System vorausgesetzt wird. Mengenlehre hat mir wohl doch was gebracht ;-) --17:03, 7. Okt 2005 (CEST)

Bilder

Mag sich jemand mal zu den Bildern auf [[1]] äußern? Soll ich die einbauen? Alexander Volland 09:03, 16. Nov 2005 (CET)

hat sich wohl erübrigt. Alexander Volland 13:57, 5. Jan 2006 (CET)

Bestandsaufnahme - Wartung

Hallo,

das WikiProjekt Wartung führt eine Bestandsaufnahme, aller Qualitätsinitiativen, Wartungsseiten und WikiProjekte durch. Ziel ist es, einen Überblick über die Wartungsinfrastruktur der Wikipedia zu gewinnen und inaktive/nicht mehr benötigte Wartungs- und Projektseiten ausfindig zu machen. Schreibt deshalb euch bekannte Projekte (falls nicht schon geschehen) in die Liste(n). Arbeitet ihr selbst aktiv bei einem Projekt mit, so tragt euch bitte in die Betreuerliste ein. --Steffen85 (D/B) 22:55, 28. Apr 2006 (CEST)

Verschwundene PM Softwareliste

Wer ist verantwortlich für das Verschwinden der Softwareliste. Angeblich wurde die Seite erst am 17. Juli erstellt. Das stimmt aber nicht. Benutzer Niknik hat hier wohl Fehler gemacht. Ich wurde gerne die alte Liste wieder sehen? Kann sich jemand von Admins der Aufgabe widmen? Danke und Grüß, --Kaster 15:08, 16. Aug. 2007 (CEST)

In einem Anfall von große Güte und Gnade habe ich die Seite wiederhergestellt... :-) Alex 22:03, 17. Aug. 2007 (CEST)

und ich hab sie erneut gelöscht hier gabs den LA. Auf WP:LP kann diese Liste zur Not erneut diskutiert werden.--LKD 11:52, 22. Aug. 2007 (CEST)

Das haben wir gerade gemerkt. Arghl. Ich habe mit dem entspr. Admin Kontakt aufgenommen. Das Löschen in einem aktiven WikiProjekt halte ich nicht für so riesig toll. Mai war halt dieses Jahr auch Urlaubszeit und Projektmanager haben nicht unbedingt Zeit, ständig in Wikipedia rumzusurfen und drauf zu achten, dass nicht wieder jemand Löschanträge schreibt. LDK und wenn Du siehst, dass das hier diskutiert wird hättest Du die Schnelllöschung auch einen Augenblick hinauszögern können, damit wir die Daten sichern. Jetzt konnte ich wieder nur einen älteren Stand wiederherstellen. Ist echt schade um die Arbeit, die wir uns hier machen! Alex 14:45, 22. Aug. 2007 (CEST)

PM-Softwareliste - Teil 2

Leider wurde die PM-Softwareliste von einem übereifrigen Admingekillt. Wenn ihr es auch schön fändet, wenn die Liste wieder hergestellt würde, dann beteiligt Euch bitte an der Wiederherstellungsdiskussion:

• http://de.wikipedia.org/wiki/Wikipedia:L%C3%B6schpr%C3%BCfung#Wikipedia:WikiProjekt_Projektmanagement.2FSoftware

Viele Grüße Alex 16:43, 24. Aug. 2007 (CEST)

Hm. Vielleicht sollte man eine Löschprüfung veranlassen und ausloten, in welche Form bzw. Namensraum wir die Liste den als Hilfswerkzeug des Projektteams auf der Wikipedia behalten können? Wenn dort wir auf kein Entgegenkommen stoßen, werde ich mich persönlich auf alle Listen aus der Wikipedia mit Löschanträgen stürzen. NAturlich in allen Namenräumen. Ein Maßstab muss für alle gleich gelten. --Kaster 11:21, 7. Sep. 2007 (CEST)

Löschprüfung hab ich schon gemacht. Hat nichts geholfen. Wikiprojekt ist böse. Darf keine Liste haben. Admin ist Bademeister. Admin ist Gott und hat immer recht. Ich bin mir langsam unsicher, ob sich die ganze Mühe lohnt, die wir investieren, wenn wildgewordene Blockwarts (nach Hörensagen gibts das so nur in der Deutschen Wiki!) sich ausspielen müssen. Alex 15:37, 7. Sep. 2007 (CEST)

Projektintelligenz

Hallo Leute,

habe einen Artikel zum Thema Projektintelligenz verfasst. Da jetzt, 3 Wochen nachdem der Artikel eingestellt wurde, ein LA erhoben wurde, wollte ich euch als Fachleute bitten, einen Blick auf die Löschdiskussion zu werfen und euch ggf. zu beteiligen. Die Disk.-Teilnehmer sind nicht vom Fach und daher wäre Fachwissen gefragt.

MfG -- Pauleta007 17:57, 2. Jul. 2008 (CEST)