Sollen wir Excel auch aufnehmen 

Unter dem "Standardteil" der Detailseiten könnt ihr gerne die Beschreibungen noch frei erweitern. Es spricht nichts gegen Screenshots oder ausführlichen Funktionsbeschreibungen, solange ihr der Vergleichbarkeit wegen den allgemeinen Teil beibehaltet.

Warum ? .... Wer hat hier was gegen die "Papier- und Bleistift-Ersatzsoftware" ? das Schweizer Messer schlechthin

Geht doch alles...sogar Gantt: http://www.heise.de/download/excel-xl-projektmanager-1161736.html

Stimmt schon. Wenn wir ehrlich sind, dann spielt Excel im Projektalltag eine nicht zu unterschätzende Rolle. Siehe auch mein kleines Excel.

Wir sollten eine eigene Excel-Seite aufmachen!

Wenn es eine eigene EXCEL-Seite geben soll, ein Vorschlag: Die weitere Untergliederung sollte nach Disziplinen bzw. Aufgabenstellung erfolgen, sonst findet man später nichts oder es kommt alles durcheinander

Beispiel Diszpilinen und Aufgaben

• Projektplanung
• Controlling und Verfolgung
• Berichterstattung
• Aufwandsschätzung
• Aufgaben
• Zeiterfassung

Ich präferiere allerdings den umgekehrten Weg: Auf oberster Ebene die Diszpilinen und darunter die Werkzeuge, nach dem Motto "Was will ich tun und mit welchem Werkezug mache ich es am Besten" (V-Modell 97 Methoden und Werkzeugauswahl macht es ja auch nicht andersherum... )

Dashätte den Vorteil, dass wir die Diszioplinen mit den Einträgen von Werkzeugen und Methoden verlinken können.

Disziplin A -> Methode A

Disziplin A -> Werkezeuge a, b, c

Meinungen ?

Beide Einordnungen haben etwas für sich. Wir haben genau dieses Problem auf openPM sehr häufig. Es gibt sie einfach nicht die eine, beste Ordnung um die Inhalte zu PM sinnvoll zu gliedern. Daher haben wir auf der Seite Sichten verschiedene Zugänge zum Inhalt angelegt. Im wesentlichen sollten das aber Zugänge sein, wie Du sie haben willst, d.h. ausgehend von den Disziplinen. Und das finde ich auch gut so. Ich könnte mir trotzdem eine Excel Seite vorstellen, auf der wir die auf openPM gezeigten Einsatzmöglichkeiten zusammenfassen / verlinken.

Hmm, kleines Wiki-Problem: Wie gehen wir mit Textteilen um wie "... die einzige (mir bekannte) Anwendung, die ..." (im konkreten Fall Cando) ?

Der Autor dieses Teils ist ja nicht unmittelbar offensichtlich. Wie können wir das autoren-neutral anders formulieren? Wäre z.B. "... ist derzeit die vermutlich einzige Anwendung, die ..." akzeptabel?

Auch Bezeichnungen wie "spannend" oder "interessant" sind ja eher die Meinung des Autors, als objektive Fakten. Hat jemand Vorschläge?

Tobias Hahn Sehr guter Einwand. Ich bin der Meinung wir sollten den Autor / die Autorin bitten den Text neutraler zu formulieren.

Wolfram Müller: Laut Seitenhistorie stammt der Eintrag zu Cando von Dir. Könntest Du den bitte etwas neutraler formulieren? 

fixed - ist jetzt neutraler formuliert ... danke für den Hinweis

Danke, viel besser so. 

Schöne Liste - bevor ich mich ans Ergänzen mache, habe ich eine Frage: Soll es hier um die eigentlichen Hauptplattformen gehen oder sollen tatsächlich alle Arten von Erweiterungen mit aufgeführt werden? Ich wäre dafür, Erweiterungen/ Add-Ons zu PM-Plattformen in (verlinkte) Unterseiten auszugliedern, sonst wird diese Liste hier schnell total unübersichtlich und der Vergleich hinkt ...

Heiko Bartlog: Guter Gedanke, wir sollten auf jeden Fall kennzeichnen, wenn es sich um ein Addon/Erweiterung handelt, damit wir das ggf. auch noch nachträglich wieder auseinander sortieren können. Momentan würde ich auf die Aufteilung noch verzichten (Ich melde mich auch freiwillig ggf. später diese Hausaufgabe nachzuholen).

Heiko Bartlog Ich sehe das ähnlich wie Du und Bernhard Schloß: Wir sollten deutlich kennzeichnen zwischen Hauptplattform und Erweiterungen davon. Vielleicht lässt sich das ja durch entsprechende Hervorhebungen in der Tabelle realisieren, z.B. die Plattform immer farbig und die Erweiterungen darunter normal.

Bringt die neue Spalte Steuerungsansatz wirklich einen so großen Mehrwert, dass wir sie hier in der Tabelle auflisten wollen. Wolfram Müller: was hat Dich bewegt gerade dieses Kriterium hier als Spalte aufzunehmen? Und welche Ausprägung soll die Spalte haben?

... vordergründig könnte es ja so aussehen, als ob ich Critical Chain (CCPM) pushen wollte. Klar das will ich auch . Ich komme gerade von der TOCICO (internationale Konferenz der Durchsatzmanager u.a. CCPM) und habe hier wieder etliche Bereichte darüber gesehen, wie selbst in durchoptimierten Umgebungen mit CCPM noch richtig was rausgeholt werden kann z.B. Pharma (Dr. Reddys), Aufräumprojekt Golf von Mexico (BP) und nicht zuletzt der Mazda Turn-Around (Projektlaufzeit halbiert und Verbrauchswerte der Motoren gleich mit verbessert).

... so jetzt aber zur Spalte "Steuerungsansatz"

in meiner Praxis als Berater und Manager von Project Offices ist immer wieder die Frage des Tooling zu klären (daher ja auch diese Liste der Anbieter). Viele Firmen machen dann eine Nutzwertanalyse mit vielen Anforderungen (s. Liste hier in OpenPM) - machmal sogar noch mit Gewichtungen. Dabei tauchen folgende Phänomene auf:

a) aufgrund der großen Zahl an Kriterien kommt es letzt endlich immer zu folgendem Ergebnis - ein paar Anbieter fallen bei ein paar Muss-A-Kriterien raus. Die verbleibenden haben aufgrund dem Gesetz der Großen Zahl fast die gleiche Punktzahl. Selbst eine Gewichtung hilft hier nicht viel - weil einfach aufgrund der großen Zahl von Kriterien sich die Unterschiede ausnivellieren. Das ist der Punkt an dem man die Liste beiseite legt und nach den wirklich relevanten Kritrien sucht

b) welche kriterien wirklich gelten hängt hauptsächlich davon ab, welche Art der Projektsteuerung ich machen will. Ich kenne aktuell vier große Gruppen und jede hat andere Anforderungen/Funktionen

daher ist es sehr wichtig schnell zu wisen welche der Softwarpaket welche der Steuerungsansätze unterstützt - daher die Spalte Klar ist auch ein Paket kann mehrere unterstützen z.B. Lynx, Sciforma können zwei - Lynx bald drei.

... was wäre mein Vorschlag für die Spalten in der Anbietertabelle

1. Steuerungsansatz - damit kann man die Menge der Anbieter schnell reduzieren
2. Usability, Anmutung, Support - man will ja operativ damit arbeiten. Gerade in der Zeit der Streichelcomputer möchte man Spass and er Bedienung haben und sich nicht ärgern wollen. Daher auch schneller guter Support oder schnell neue wichtige Features
3. Lizenmodell - wenn man Open Source machen will dann reduziert sich die Liste gleich wieder (p.s. ein gute Software verdient immer viel mehr Geld als sie kostet - daher sollte man diese Kriterium nicht überbewerten). Besser wäre vielleicht Nutzen/Invest-Verhältnis.

mit diesen drei Filtern kann man sehr schnell die Menge an Anbietern eingrenzen. Natürlich muss man danach noch die muss-Kriterien durchgehen aber eben mit einer viel geringeren Menge an Anbietern.

cu Wolfram

p.s.: jetzt bitte alle nochmal das Mazda Testimonial anschauen (bitte nicht böse sein ich hab CCPM schon mehrfach selbst erlebt und eingeführt - es ist einfach schön zu sehen wie das Leuchten in die Augen der Mitarbeiter zurück kommt - so wie bei Agil) ... Mazda hat mit dem Umstig von klassich/konventionell auf CCPM 50% Projektlaufzeit verkürzt! Daher auch die große Relevanz des Kriterium für den Erfolg. Und bitte nicht auf die Idee kommen Autos agil entwickeln zu wollen - höchstens Teile davon und dazu braucht man eben Softwarepakete die beides können CCPM und Agil und die sind gerade erst im entstehen ...

Bitte klassisch statt konventionell verwenden. Konventionell ist (negativ) wertend. Auch agile Methoden halten sich an Konventionen...

Danke für Deine Erklärung der neuen Spalte. Finde ich nach ersten Bedenken nützlich. Eine Spalte(n) "Usability, Anmutung, Support" halte ich für ungeeignet, weil das extrem subjektiv ist.

Wie steht's mit Resourcelisten und Bewertungsplattformen wie Capterra oder GetApp? Hier kann PM Software individuell nach Produktbewertungen, Funktionen, Freeware etc. gefiltert werden, um die Softwareauswahl zu erleichtern.

Nimm die Links doch gerne in einen Artikel auf. openPM lebt von der User-Beteiligung.