47 projekt M A N A G E M E NT 2/ 20 0 6 aktuell o฀ Ist für das Projekt die Ermittlung quantitativer Projektkennzahlen in Form von Messungen und Metriken erforderlich, um vergleichende Aussagen über Projektergebnisse während einer längeren Zeitspanne treffen zu können? o฀ Ist im Projekt der Einsatz von Fertigprodukten erwünscht? o฀ Ist die Benutzerschnittstelle für den Projekterfolg besonders wichtig? o฀ Müssen Systemsicherheitsaspekte besonders berücksichtigt werden? Damit ist die Basis für eine weitreichende Anpassung an die jeweiligen Projektkonstellationen möglich. Allerdings fällt auf, dass die Projektgröße beim Tailoring nicht direkt berücksichtigt wird. Im V-Modell 97 war dazu noch eine Differenzierung in kleine, mittlere und große Projekte vorgesehen, die jetzt nicht mehr vorhanden ist. Die Projektgröße kann hier allenfalls indirekt durch andere Projektmerkmale berücksichtigt werden, was jedoch für viele Konstellationen nicht ausreichend sein dürfte (siehe auch [4]). Inkrementelle und agile Projektdurchführungsstrategien Die Vorgehensbausteine enthalten noch keine Festlegung zum zeitlichen Projektablauf. Dies erfolgt vielmehr erst durch Auswahl einer Projektdurchführungsstrategie, mit der die Reihenfolge der für das Projekt relevanten Meilensteine festgelegt wird. Das Projekt wird dadurch in einzelne Zeitabschnitte untergliedert, denen die Produkte und Aktivitäten der relevanten Vorgehensbausteine zugeordnet sind. Die verfügbaren Projektdurchführungsstrategien werden teilweise bereits durch das Tailoring der Vorgehensbausteine eingegrenzt. Für Systementwicklungsprojekte des Auftragnehmers werden drei Durchführungsstrategien unterschieden: o฀ Bei der inkrementellen Systementwicklung wird das zu entwickelnde System in mehrere Entwicklungsstufen („Inkremente“) zerlegt, die einzeln an den Auftraggeber ausgeliefert und abgenommen werden. Die Anwenderanforderungen müssen bereits zu Beginn des Projektes vom Auftraggeber relativ fest abgesteckt werden und sollten sich im Projektverlauf nur wenig ändern. Die inkrementelle Systementwicklung eignet sich daher vor allem, wenn die Anforderungen an das System als relativ stabil eingeschätzt werden und technologische Risiken eher gering sind. o฀ Die agile Systementwicklung ist für Projekte mit hohen Realisierungsrisiken gedacht, bei denen es nicht möglich ist, alle Anwenderanforderungen vorab zu definieren. Bei der agilen Vorgehensstrategie werden die Anforderungen nicht zu Beginn des Projekts, sondern parallel zur Entwicklung, Auslieferung und Abnahme schrittweise wachsend festgelegt. Das Vorgehen ist flexibler als bei der inkrementellen Entwicklung und erlaubt eine stärkere Parallelisierung vieler Aktivitäten. Die offizielle Darstellung des agilen Vorgehens im V-Modell (vgl. Abb. 3) kann dies allerdings nur teilweise deutlich machen. o฀ Die komponentenbasierte Systementwicklung geht wie die inkrementelle Vorgehensweise davon aus, dass die Anwenderanforderungen bereits zu Beginn des Projektes vom Auftraggeber fest vorgegeben worden sind. Das System wird hier jedoch nicht neu entwickelt, sondern weitgehend durch Integration bestehender Systemelemente erstellt. Bei Systementwicklungsprojekten des Auftraggebers unterscheidet das Modell, ob der Auftraggeber lediglich mit einem Auftragnehmer zusammenarbeitet oder ob das Projekt in mehrere Teilprojekte zerlegt und an mehrere unterschiedliche Auftragnehmer vergeben wird. Diese Unterscheidung wurde erst Anfang 2006 mit dem Release 1.2 eingeführt. Sie wird etwas unsachgemäß als „Multiprojekt-Management“ bezeichnet. Das V-Modell versteht darunter „eine Variante des Projektmanagements. Es hat zum Ziel, komplexe und große Projekte durch Aufteilung in Teilprojekte besser steuerbar zu machen und die Projektrisiken zu mindern.“ In der Projektmanagementfachwelt wird mit dieser Definition lediglich das Programm-Management angesprochen, nicht jedoch die zum Multiprojektmanagement gehörende Steuerung von Projektportfolios. Noch kritischer Projekt genehmigt Projekt definiert Angebot abgegeben Projekt beauftragt Abnahme erfogt System spezifiziert Lieferung durchgeführt System entworfen System integriert Feinentwurf abgeschlossen Systemelemente realisiert Projekt abgeschlossen 1..* 0..1 Unterauftrag 0..* Y Y Y 1..* Y 0..* 0..1 Iteration geplant Abb. 3: Ablauf der agilen Systementwicklung, Quelle: V-Modell XT 1.2 48 WISSEN aktuell projekt M A N A G E M E NT 2/ 20 0 6 als diese Begriffsdefinition ist allerdings, dass der Vorgehensbaustein Multi-Projektmanagement in der alleinigen Verantwortung der Rolle des Anforderungsanalytikers gesehen wird, der das Gesamtprojekt in unabhängig voneinander durchführbare Teilprojekte aufteilt. Dass bei größeren Programmen auch eine auf deren Steuerung ausgerichtete Programmorganisation aufzubauen ist, zusätzliche Systemintegrationsaufgaben vom Auftraggeber wahrzunehmen sind und das Änderungsmanagement komplexer wird, bleibt im Vorgehensmodell unberücksichtigt. Ob mit einer derartigen Handhabung die entsprechenden Programme innerhalb der geplanten Termine und Kosten abgewickelt werden können, erscheint dem Verfasser mehr als zweifelhaft. Projektstrukturplanung und Werkzeugunterstützung Aus den Durchführungsstrategien und den im Tailoring ausgewählten Vorgehensbausteinen lässt sich im Weiteren eine komplette Projektplanung ableiten. Dies sei mit dem Vorgehensbaustein „Projektmanagement“ in Abb. 1 kurz verdeutlicht. Dieser Baustein gehört zum V-Modell-Kern und stellt damit den Minimalumfang an PM-Aufgaben für jedes nach V-Modell durchgeführte Projekt dar. Abb. 1 zeigt auf der linken Seite die Produkte und auf der rechten Seite die jeweils korrespondierenden Aktivitäten zu den beiden Teilbereichen „Berichtswesen“ und „Planung und Steuerung“. Im Rahmen der Projektstrukturplanung können ggf. mehrere kleinere Aktivitäten zu Arbeitspaketen zusammengefasst werden, wenn sie von den gleichen Verantwortlichen bearbeitet werden. Für den Baustein „Projektmanagement“ könnten bei einem kleineren Projekt beispielsweise die Produkte Schätzung, Risikoliste und Projektplan zu einem Arbeitspaket „Projektplanung“ zusammengefasst werden, da sie inhaltlich nahe verwandt und alle der Rolle des Projektleiters zugeordnet sind. Der Vorgehensbaustein „Projektmanagement“ zeigt auf, dass neben dem Projektleiter auch noch die Rollen des Projektmanagers, des Lenkungsausschusses und des Einkäufers an diesem Baustein direkt oder indirekt beteiligt sind. Im Verständnis des V-Modells wirkt der Projektleiter dabei eher intern und ist für die Planung, Koordination und Steuerung des Projekts zuständig. Der Projektmanager ist demgegenüber für den erfolgreichen Abschluss des Projekts gegenüber Vorgesetzten und Lenkungsausschuss verantwortlich und vertritt das Projekt damit eher nach außen. Für alle Vorgehensbausteine enthält das Modell entsprechende Produkt-, Aktivitäten- und Rollenzuordnungen. Hinzu kommen für alle Produkte des Modells einfache Dokumentvorlagen, in denen die Gliederung und die erwarteten Inhalte des jeweiligen Produkts spezifiziert sind. Der Vorgehensbaustein „Projektmanagement“ in Abb. 1 ist dabei ein eher kleiner Modellbaustein. Den Bausteinen zur Systementwicklung sind in der Regel wesentlich mehr Produkte, Aktivitäten und Rollen zugeordnet. Das Modell weist damit eine sehr verzweigte Projektstruktur auf, die sich leider durch die Dokumentation des Modells nur schwer erschließen und nachvollziehen lässt. Im Vorgängermodell V-Modell 97 waren diese Projektstrukturen noch in Form umfangreicher Funktionendiagramme (Responsibility Charts) übersichtlich zusammengestellt. Im V-Modell XT hat man darauf verzichtet und stattdessen den Projektassistenten beigegeben. Dabei handelt es sich um ein kleines Softwareprogramm, mit dem das Tailoring durchgeführt und die Projektplanung unterstützt werden soll. Dieser Projektassistent stellt leider nur einen Notbehelf für den ersten Einstieg in das V-Modell XT dar, da die Projektplanung damit nur relativ benutzerunfreundlich in Einzelschritten vorgenommen werden kann und das Programm nur über rudimentäre Exportmöglichkeiten zu anderen PM-Softwaretools verfügt. Von der Firma MicroTool wird ein spezielles Planungstool für das V-Modell XT angeboten, das in einem anderen Artikel in dieser Ausgabe vorgestellt wird. Projektmanagement im V-Modell Neben dem Vorgehensbaustein „Projektmanagement“ enthält das V-Modell noch einige weitere für das Projektmanagement wichtige Vorgehensbausteine: o฀ Problem- und Änderungsmanagement, o฀ Vertragsabschluss, o฀ Lieferung und Abnahme, o฀ Kaufmännisches Projektmanagement sowie o฀ Messung und Analyse. In all diesen Bausteinen sind die Hauptaufgaben rollenmäßig entweder dem Projektleiter oder dem Projektmanager oder dem für die Kostenseite verantwortlichen Projektkaufmann zugeordnet. Ein gutes Drittel aller Bausteine des Modells betrifft damit originäre Projektmanagementaufgaben. Das Modell gibt damit neben dem Rahmen für die Fachaufgaben auch einen Rahmen für die Art und Weise des Projektmanagements vor. Allerdings kommt an vielen Stellen gerade dabei ein seltsames Verständnis der eingeführten Projektmanagementstandards zum Ausdruck. Auf das Fehlen eines Bausteins zum Changemanagement und den nicht sachgemäßen Baustein mit der Bezeichnung „Multi-Projektmanagement“ wurde bereits hingewiesen. Hinzu kommen eine Reihe unsauberer Begriffsverwendungen, von denen einige als Beleg aufgeführt seien. So wird beim Lenkungsausschuss gesagt, dass in diesem Gremium „alle Projektbeteiligten (Stakeholder) in geeigneter Weise“ vertreten sein sollten. In der Praxis dürfte dies sehr schnell zu übergroßen Lenkungsausschüssen führen, da ein Projekt sehr leicht etliche Dutzend Stakeholdergruppen umfassen kann. Dem Projekt kritisch oder ablehnend gegenüberstehende Stakeholder sollten eigentlich auch nicht im obersten Entscheidungsgremium der Projektorganisation vertreten sein. Der Projektmanager der GPM definiert den Lenkungsausschuss sehr viel zweckmäßiger „als Gremium aus bevollmächtigten, übergeordneten Vertretern des Projekts“ [5, S. 521]. Weitere Verwirrung entsteht dadurch, dass die Projektsteuerung und -überwachung als eigenständiges Aufgabengebiet nicht erscheint, sondern als Aktivität unter dem Begriff „Berichtswesen“ subsumiert wird. Bei der Planung des Projekts wird zwischen „Projektdurchführungsplan“ und „Integrierter Planung“ unterschieden. Der Begriff „Projektdurchführungsplan“ ist dabei allerdings sehr mehrdeutig interpretierbar. Das V-Modell versteht darunter die „Festlegung der Entscheidungspunkte zur groben Strukturierung des Projekts“, was die meisten PM-Fachleute eher als Meilensteinplan bezeichnen wür- 49 projekt M A N A G E M E NT 2/ 20 0 6 aktuell den. Unter der „Integrierten Planung“ wird im Wesentlichen die Planung der Produkt- und Projektstruktur sowie der daraus abgeleiteten Projekttermine verstanden. Eine Kapazitätsplanung sucht man vergebens. Die Projektkosten werden aus der Integrierten Planung in die kaufmännische Projektkalkulation ausgelagert und vom Projektleiter an den Projektkaufmann delegiert. Eine Finanzplanung, die für komplexe Großvorhaben unabdingbar ist, wird nicht erwähnt. Viele dieser Punkte mögen vielleicht für Kleinigkeiten gehalten werden oder es mag darauf verwiesen werden, dass die Elemente ja durchaus in das V-Modell integrierbar seien, ja dass man dies vielleicht mit bestimmten Formulierungen auch so gemeint habe. In Summe wird durch das V-Modell aber die ohnehin zu große Begriffsvielfalt im Projektmanagement noch mehr erweitert, ohne dass dafür eine Notwendigkeit bestehen würde. Vielmehr werden dadurch vielfältige, für die Beteiligten ärgerliche Begriffsverwechslungen in der Projektabwicklung provoziert. Man stelle sich nur die Zusammenarbeit eines der vielen nach internationalen Standards zertifizierten Projektleiter mit einem nach V-Modell XT arbeitenden Projektleiter vor. Gäbe es eine ähnlich inflationäre Begriffsverwendung in der Medizin, würden wahrscheinlich mehr als die Hälfte aller Operationen in Krankenhäusern schief gehen. Eine weitere Gefahr entsteht durch die dominierende Ausrichtung des V-Modells auf schriftliche Dokumente als Projektprodukte. Der menschliche Faktor als besonders wichtiger Erfolgsfaktor der Projektarbeit kommt dadurch im Vorgehensmodell nur unzureichend zur Geltung. Dies steht im Gegensatz zu vielen, auch im IT- Bereich seit langem bekannten Erkenntnissen der Projekterfolgsfaktorenforschung. Wichtige Maßnahmen wie Teambildung, Stakeholderanalyse oder Projektmarketing werden im V-Modell und dessen Erläuterungen nicht explizit angesprochen, sondern verstecken sich hinter Produkten und Aktivitäten wie „Besprechungsdokument“ und „Projekthandbuch“ oder werden auf die „Anwenderaufgabenanalyse“ reduziert. Immerhin gibt es wenigstens ein Ergebnisprodukt „Projektfortschrittsentscheidung“. Dieses ist allerdings nur für die Behandlung von Projektmeilensteinen im Lenkungsausschuss vorgesehen. Fazit Das V-Modell XT stellt auf der technischen Seite eine in vieler Hinsicht sinnvolle und gut strukturierte Weiterentwicklung des V-Modells 97 dar. Dies zeigt u. a. auch die positive Aufnahme in anerkannten IT-Fachzeitschriften. Allerdings wird auch hier durchaus auf Verbesserungs- und Weiterentwicklungspotenziale hingewiesen [6, 7]. Hinsichtlich seiner Managementmechanismen und -begriffe merkt man dem Modell an, dass seine Autoren in der IT-Welt sehr viel tiefer verwurzelt sind als in der Managementwelt. Der Kenntnisstand der Managementlehre, insbesondere des Projektmanagements, wurde leider nicht adäquat berücksichtigt. Dies lässt befürchten, dass auch durch dieses Modell die Anzahl mehr oder weniger spektakulärer Fehlschläge bei öffentlichen IT- Vorhaben nicht abnehmen wird. In Deutschland wurden von der GPM fast zehntausend Projektleiter nach internationalen Standards zertifiziert, viele davon im IT- Bereich und bei öffentlichen Institutionen. Es wäre zu wünschen, dass sich das V-Modell stärker an die hierbei vermittelten, anerkannten Projektmanagementstandards anlehnt und versierte Managementfachleute in die Weiterentwicklung des Modells einbezogen werden. n Literatur [1] Koordinierungs- und Beratungsstelle der Bundesregierung für Informationstechnik in der Bundesverwaltung (KBSt): Dokumentation, Downloads und weitere Informationen zum V-Modell XT. Online im Internet unter www.kbst. bund.de (1. 2. 2006) [2] Feldmüller, D./ Frick, A./ Seibert, S. : Was müssen IT- Projektmanager wirklich können? Umfrageergebnisse der Fachgruppe IT-Projektmanagement (GI/ GPM). In: projekt- MANAGEMENTaktuell, Heft 4/ 2004, Seite 42-44 [3] Industrieanlagen-Betriebsgesellschaft (IABG): Dokumentation, Downloads und weitere Informationen zum V-Modell 97. Online im Internet unter www.V-Modell.iabg. de (1. 2. 2006) [4] Riegg, T.: Analyse der Anwendbarkeit des V-Modells bei kleinen IT-Vorhaben. Diplomarbeit, online im Internet unter www.riegg-webdesign.de/ umfrage/ umfrage.php (1. 2. 2006) [5] Schelle, H./ Ottmann, R./ Pfeiffer, A.: ProjektManager. GPM Deutsche Gesellschaft für Projektmanagement, Nürnberg 2005 [6] Klink, M./ Oesterreich, B.: Das neue V-Modell XT. In: ObjektSpektrum, Nr. 4/ 2005, S. 55-60 [7] Niebuhr, D./ Rausch, A.: Erfolgreiche IT-Projekte mit dem V-Modell XT. In: ObjektSpektrum, Nr. 3/ 2005 [8] Rausch, A./ Broy, M.: Das V-Modell XT - Grundlagen, Erfahrungen und Werkzeuge. dpunkt.verlag, Heidelberg 2006 [9] Saynisch, M.: V-Modell XT: Otto Schily stellt neuen Entwicklungsstandard für IT-Systeme vor. In: projektMANAGE- MENTaktuell, Heft 3/ 2005, Seite 9-11 Schlagwörter Agile Vorgehensmodelle, IT-Projekte, Öffentliche Auftraggeber, Softwareprojekte, V-Modell, Vorgehensmodelle Autor Diplom-Wirtschaftsingenieur Dr. Siegfried Seibert ist Professor für Projektmanagement und Unternehmensführung an der Fachhochschule Darmstadt. Außerdem ist Siegfried Seibert Mitglied des Vorstands der GPM Deutsche Gesellschaft für Projektmanagement, Nürnberg. Hier leitet er das Ressort Publikationen und ist Chefredakteur von projektMANAGEMENTaktuell. Daneben führt Siegfried Seibert regelmäßig Schulungen zum IT-Projektmanagement und zur Software-Kostenschätzung durch und verfügt über eine langjährige leitende Industriepraxis in der Automobil- Zulieferindustrie. Anschrift Fachhochschule Darmstadt Fachbereich Wirtschaft (Campus Dieburg) Max-Planck-Str. 2 D-64807 Dieburg Tel./ Fax: 0 60 78/ 7 27 33 E-Mail: S. Seibert@GPM-IPMA.de www.siegfried-seibert.de 50 WISSEN aktuell projekt M A N A G E M E NT 2/ 20 0 6 A bhängig von der eingesetzten in-Step-Edition liefert microTOOL Unterstützung für verschiedene Vorgehensmodelle aus. Die „Projektmanagement- Edition“ zielt auf Anwender ab, die ihre eigenen Vorgehensmodelle entwickeln, nutzen und optimieren möchten. Darüber hinaus stehen auch vorgefertigte Modelle zur Verfügung. Neben der Edition für Prince 2, einer actiF-Edition für iterative (agile) Softwareentwicklung, und dem V-Modell 97 bietet in-Step die Möglichkeit, auf das V-Modell XT zurückzugreifen. Um es vorwegzunehmen: Die Frage, ob die Netzplantechnik oder das IT-Projekt zuerst existierten oder ob gar die Implementierung der Netzplantechnik einst oft als IT- Projekt daherkam, soll an dieser Stelle nicht diskutiert werden. Ob Netzplantechnik für IT-Projekte geeignet ist, braucht ebenfalls nicht erörtert zu werden: Die einzelnen Projekt-Aktivitäten verknüpft in-Step mittels so genannter Kontrollflüsse. Mit ihnen lassen sich Vorgänger und Nachfolger einer Aktivität mit Zeitabständen sowie unterschiedlichen Referenzpunkten (Ende-Anfang, Anfang- Anfang, …) festlegen. Der eine oder andere Leser mag da ein gewisses Déjà-vu erleben. Grundlagen in der Projektmanagement-Edition Für den ersten Kontakt mit der Anwendung bietet sich die Projektmanagement-Edition an. Auf die Unterstützung für das V-Modell XT wird später gesondert eingegangen. Die Strukturierung eines neuen Projekts wird dem Anwender durch vorgegebene Standard-Aktivitäten erleichtert. Mit diesen kann die Projektstruktur schrittweise weiter untergliedert werden. Diese anpassbaren Aktivitäts-Vorlagen lassen sich vorab mit Ressourcen- und Kostenzuordnungen versehen und beschleunigen damit die Projektplanung bei ähnlichen Projekten erheblich. In Abhängigkeit von der gewählten Projektvorlage stellt in- Step so zu den einzelnen Teilprojekten und Arbeitspaketen sinnvolle Verfeinerungen bereit, die nur noch angepasst zu werden brauchen. Die Nutzung der Projektvorlagen ermöglicht es auch, den Standard-Aktivitäten zugleich ein Produkt als geplantes Ergebnis zuzuordnen. Dies kann beispielsweise ein Lastenheft oder ein Kommunikationsplan für die Stakeholder des Projekts sein (Abb. 1). Die Produktorientierung von in-Step fällt im Vergleich mit anderen Software-Anwendungen am nachdrücklichsten auf: Auch für die Produkte besteht die Möglichkeit, sich bei der Verfeinerung in Teilprodukte von der Projektvorlage unter die Arme greifen zu lassen. Zudem lässt sich der mögliche Beginn von Aktivitäten über so genannte Produktflüsse an das Erreichen bestimmter Bearbeitungszustände für bestimmte Produkte koppeln. Individuell definierbare Vorlagen sorgen dafür, dass den Projekten als Ausgangsbasis vorgefertigte Dokumente mit einheitlichen Strukturen zur Verfügung stehen. Ausgehend davon werden Dokumente der einzelnen Aktivitäten dann direkt aus in-Step zur Bearbeitung geöff- PM-Software: in-Step IT-Projektmanagement mit Vorgehensmodellen Mey Mark Meyer IT-Projektmanagement erfordert besondere Tools: Folgt man den Ausführungen des Anbieters microTOOL, dann benötigen IT-Projekte andere Methoden als nur die Netzplantechnik, die „in einer Zeit entstanden ist, als es IT-Projekte noch gar nicht gab“. Vor diesem Hintergrund tritt in-Step in verschiedenen Editionen an, um ein an Vorgehensmodellen orientiertes, ergebnisorientiertes Projektmanagement für IT-Projekte zu unterstützen. Die Neugierde ist damit allemal geweckt und die Fragestellung formuliert: Was also leistet in-Step und wie lässt es sich handhaben? In der Rubrik PM-Software stellt projektMANAGEMENT aktuell seinen Lesern neue und interessante Projektmanagementtools in Form herstellerunabhängiger Erfahrungsberichte und Nachrichten vor. Die Berichte stammen von Mey Mark Meyer, dem Leiter der GPM- Fachgruppe „Projektmanagement-Software“. Falls Sie zu diesen Berichten Ergänzungen oder eigene Erfahrungen einbringen oder sich an der Arbeit der GPM-Fachgruppe beteiligen möchten, können Sie sich per Mail unter „PM-Software@GPM-IPMA.de“ melden. In Kooperation zwischen der GPM-Fachgruppe und dem IPMI Institut für Projektmanagement und Innovation der Universität Bremen wurde zusätzlich eine umfangreiche Internet-Seite aufgebaut, in der Informationen zu über 120 Softwareprodukten rund um das Projektmanagement zu finden sind und eine Windows-Software zur Nutzwertanalyse von PM-Tools downloadbar ist. Dieses Informationsangebot wird laufend aktualisiert und erweitert. Sie erreichen es unter der Adresse „www.PM-Software.info“. GPM-Fachgruppe „Projektmanagement-Software“ 51 projekt M A N A G E M E NT 2/ 20 0 6 aktuell net - beispielsweise in Microsoft Word. Dabei erfolgt automatisch eine Versionierung, so dass der Werdegang des Dokuments jederzeit nachvollzogen werden kann - durch die Integration in Microsoft Office kann diese Änderungsverfolgung auch in den Dokumenten selbst dargestellt werden. Weist man den Aktivitäten Ressourcen zu, vermag in- Step auch die resultierenden Kosten zu berechnen. Einen manuellen Kapazitätsabgleich der Ressourcen durch den Projektleiter unterstützt die Software zumindest mit einigen grundlegenden Funktionen. Die Arbeit mit in-Step erfordert einige Einarbeitung sowie die Verinnerlichung der produkt- und dokumentationsorientierten Philosophie der Software. Nicht immer wird klar, warum eine Aktivität nicht beginnen darf. So ließ sich im Test beispielsweise ein Dokument zunächst nicht als fertig gestellt markieren. Der Aufruf der entsprechenden Funktion wurde scheinbar kommentarlos ignoriert - im Projekt konnte nicht fortgefahren werden. Erst nach einigen Versuchen fiel eine kleine Meldung am unteren Fensterrand auf, die darauf verwies, dass das Dokument noch zur Bearbeitung ausgecheckt n฀ In eigener Sache: Die Fachgruppe PM-Software hat die Plattform PM-Software.Info in der Version 3 gestartet. Neben einer vereinfachten Filterfunktion für die 130 gelisteten Produkte stellt die Plattform nun auch die Ergebnisse der Fachgruppe dar. Produktanbieter können ihre Daten über einen eigenen Login bearbeiten und an das Redaktionsteam senden. Nahezu sämtliche Seiten verfügen über eine Kommentar-Funktion, mit der Besucher ihr Feedback schnell und unkompliziert äußern können. (www.pm-software.info) n฀ Das neue Conject-Release erweitert speziell die Funktionen für Kommunikations- und Planmanagement. Anwender können nun zum Beispiel E-Mails auch an externe Kontakte senden oder persönliche Weiterleitungen einrichten. Darüber hinaus ermöglichen neue Funktionen einen noch schnelleren und übersichtlicheren Ausschreibungsprozess. (www.conject.com) n฀ ProjectPlace hat das Issue-Management auf seiner Plattform überarbeitet - neben möglichen E-Mail-Benachrichtigungen wird nun der komplette Verlauf der Bearbeitung dokumentiert. Zudem wurde die Startseite um eine neue Übersicht über den eigenen Aufgabenbereich ergänzt. (www.projectplace.de) n฀ Blue Ant liegt in der Version 4.0 vor. Verbesserungen in den Funktionalitäten sind vor allem in der Projektarchivierung, der automatischen Kapazitätsfreistellung über den Projektstatus sowie der Meilensteintrendanalyse zu finden. (www.proventis.net) Abb. 1: Den Aktivitäten eines Projekts ordnet in-Step die erforderlichen und resultierenden Ergebnisse (Produkte) zu. +++ PM-Software-News +++ PM-Software-News +++ PM-Software-News +++