Gründe, warum IT-Projekte scheitern

• Press1 2001, http://www.press1.de/ibot/db/9930282751925294845n0.html
  • Projektmanagement, Implementierung und die Integration bestehender Systeme
  • Kommunikation zwischen Entwicklern und Anwendern
• GULP 2002, http://www.gulp.de/kb/it/projekt/umfragescheitern.html
  • unpräzise Vorgaben
  • Starrheit und Dogmatik
  • Kommunikationsprobleme
  • fehlendes Know-how
  • Mangel an Zeit und Geld
  • mangelnde Soft Skills
• procontext.com 2004, http://www.procontext.com/de/news/2004-07-15.html
  • Missmanagement der Anforderungen → Zeit- und Kostenrahmen werden gesprengt
• Computerwoche 2006, http://www.abendblatt.de/daten/2006/02/11/532579.html
  • Zeitrahmen nicht eingehalten, Budget überschritten oder Inhalt des Vorhabens maßgeblich verändert
  • Unternehmen gehen vom Idealfall aus und beziehen negative Einflüsse nicht in ihre Projektplanung mit ein
  • mangelnde Zusammenarbeit zwischen Fach- und IT-Abteilungen
• CIO.de 2007, http://www.cio.de/strategien/projekte/831320/
  • mangelnde Kommunikation mit dem Kunden
  • fehlende Unterstützung durch Management
  • zu große Teams
• InfoWeek 2007, http://www.infoweek.ch/news/NW_single.cfm?news_ID=16163&sid=0
  • Schwächen im Projektmanagement
  • veränderte Anforderungen, die im Projektverlauf zutage traten
  • Einschränkungen beim Budget

Das Thema Projektmanagement sollte einen hohen Stellenwert bei der Entwicklung von Software vor allem bei der Teamarbeit einnehmen. Aber auch bei Soloprojekten sollte sich der Entwickler von Anfang an Gedanken über eine sinnvolle Planung und Durchführung seiner Aufgaben machen. Insbesondere auf Grund der zahlreichen Entwicklungsmethoden und Lösungsansätze für die Unterstützung der reinen Programmierung, ist es wichtig, sich gleich zu Beginn für die passende (!) Vorgehensweise zu entscheiden und diese auch im Verlauf des Projekts zu befolgen. Dadurch kann verlorene Arbeitszeit vermieden werden, die zu Lasten eines fehlenden "roten Fadens" ginge, und die Vorteile der jeweiligen Methode kommen zum Tragen.

• Ein Projekt ist ein zeitlich begrenztes Vorhaben zur Schaffung eines einmaligen Produktes, einer Dienstleistung oder eines Ergebnisses. (http://www.pm-blog.de/2007/04/10/projekt-eine-definition/)
• Ein zeitlich befristetes, komplexes Vorhaben, das einen übergreifenden hauptamtlichen Personaleinsatz erfordert. Es sollte deshalb in besonderer Projektorganisation außerhalb der normalen Struktur (= Aufbauorganisation) durchgeführt werden. (http://www.olev.de/p/projekt.htm)
• Ein Projekt ist ein einmaliges Vorhaben auf Zeit. (http://de.wikipedia.org/wiki/Projekt)
• abgrenzbares Einzelvorhaben mit definiertem Anfang und Ende (Ziel), neuartig: Vorstoß an Grenzen des Machbaren, risikoreich (technisch, wirtschaftlich, terminlich), komplex, im Laufe der Abwicklung sich ändernde organisatorische Bedürfnisse, große Bedeutung für Unternehmen / Organisation, Termindruck (http://www.umsetzungsberatung.de/projekt-management/projekte.php)
• Ein Projekt ist ein Vorhaben basierend auf der Planung einer Problemlösestrategie, um effektiv und effizient zu einem vorher definierten realistischen Ziel (bzw. Unterziel) innerhalb eines (festgelegten) zeitlichen Rahmens zu gelangen. Projekte werden auch definiert als Vorhaben, die durch eine zeitliche Befristung, eine relative Neuartigkeit und Komplexität sowie durch eine interdisziplinäre Aufgabenstellung gekennzeichnet sind. Die Neuartigkeit dieser Projekte kann sich sowohl auf das Vorgehen bei der Problemlösung als auch auf das gewünschte Ergebnis beziehen. Die Projektarbeit erstreckt sich meist über verschiedene Hierarchieebenen und bindet dabei mehrere Abteilungen ein. Dies führt zu einer hohen Komplexität der Projektarbeit. (http://wiki.c-base.org/coredump/ProjektManagement)

• zeitlich begrenzt
• einmalig
• interdisziplinar

• weit gefasste Definitionen <> sehr spezifische Definitionen
• Komplexität
• Definition von Zielen
• Agilität

Die Phasen eines Softwareprojekts:

1. Initiative
2. Planung
3. Durchführung, Steuerung
4. Abschluss
5. Betrieb

Wer tritt bei einem Projekt mit wem in Interaktion?

• Projektmitarbeiter untereinander
• Projektmitarbeiter und -leiter
• Projektleiter und Kunde
• (optimalerweise) Projektmitarbeiter und Kunde bei konkreten Fragen

In welcher Phase des Software-Projekt-Lebenszyklus werden die Kosten für den gesamten Lebenszyklus festgelegt und in welcher fallen die höchsten Kosten an?

• Die Gesamtkosten sollten in der Planungsphase ermittelt (geschätzt) und als Richtlinie für den weiteren Projektverlauf vorgegeben werden.
• Die höchsten Kosten dürften nach Fertigstellung der Software anfallen, also während des Betriebs (durch Wartung, Optimierung etc.).

Wie wenden Sie die vier Seiten der Kommunikation (Inhalt, Beziehung, Selbstoffenbarung, Appell) im Projekt an?

• Kommunikation sollte möglichst sachlich (inhaltliche Ebene) erfolgen, um missverständliche Aussagen zu vermeiden.
• Man sollte sich stets aller Wirkungen seiner Aussagen bewusst sein, sich in den Gesprächspartner hineinversetzen und überlegen, wie er die Nachrichten auffassen könnte.
• Appelle müssen auch als solche verstanden werden, wenn es um die Delegierung von Aufgaben geht.
• Für eine optimale, offene Kommunikation sollte die Beziehungsebene stets mit einbezogen werden, um die Gespräche nicht zu "kühl" und distanziert wirken zu lassen.
• Hat man das Gefühl, das Gesagte könnte falsch verstanden werden, sollte offen auf einer Metaebene über das Gespräch geredet und die eigenen Ziele verdeutlicht werden.

Zeitfresseranalyse (1 = fast nie, 2 = angemessen, 3 = zu oft)

• Telefon 2
• Besprechungen 2
• Besucher 1
• Kleinigkeiten 3
  • Sammeln kleiner, nicht dringender Aufgaben und abarbeiten zu einem festen Termin
• Unvorhergesehenes 1
• Posteingang 2
• Ordnung 1
• Informationsfluss 1
• Delegation 1
• Anfragen 3
  • Abwägen der Dinglichkeit und Wichtigkeit der Anfragen und ggf. ablehnen von Aufgaben unter Verweis auf wichtigere Tätigkeiten

Persönliche Ziele

Projektfragebogen: Master of Engineering

Bearbeitete Projekte

• Studium an der FHWT
• Auftritte mit der Band
• Programmierprojekte
• etc.

Liste offener Punkte → GTD

Der Projektauftrag sollte in Form einer Beratung geklärt werden. Der Berater muss hierzu über Fachkompetenz verfügen, die er benötigt um dem Kunden Hilfestellung bei der Entscheidung für bestimmte Produkte oder Lösungen geben zu können (Was ist machbar? Was sind die jeweiligen Vor- und Nachteile?). Aber auch Methoden- und Sozialkompetenz ist wichtig, um die korrekten Informationen bzgl. der Wünsche des Kunden erarbeiten zu können. Der Berater steht mit seinen Fähigkeiten dem Kunden zur Seite und hilft ihm bei der exakten Formulierung von Anforderungen (etwa mit Hilfe von UML oder BPMN), um späteren Missverständnissen vorzubeugen. Nur auf Basis einer fundierten Anforderungsanalyse kann ein Projekt erfolgreich durchgeführt werden.

Eine Vorstudie ist bei jedem Projekt nötig, um abzuklären, ob dieses überhaupt durchzuführen ist. Je nach Umfang des Projekts kann sich die Vorstudie zwar auf einige kurze Überlegungen beschränken, dennoch ist sie stets Teil des Projektverlaufs.

Der Grobplan des Projektverlaufs enthält analog zur Grobgliederung einer Diplomarbeit o.ä. lediglich die zentralen Punkte des Projekts, etwa wichtige Meilensteine. Er dient als Basis für die detaillierte Feinplanung und kann im Extremfall sogar komplett umgeändert werden, wenn sich Anforderungen ändern. Auch bei der Erstellung eines Grobplans ist stets der Umfang des Projekts zu berücksichtigen (bei größeren Projekten wird der Grobplan im Verhältnis zu kleineren natürlich viel oberflächlicher sein).

Checkliste für eigene Präsentationen (wichtige Dinge, die es zu verbessern gilt)

• Zuhörer- und Situationsanalyse
• Angemessener Umfang der zu vermittelnden Informationen
• Ziele des Vortrags und Nutzen für Zuhörer klar herausarbeiten (im Fazit noch einmal aufgreifen)
• Großen Wert auf einen guten Beginn und Schluss legen
• Langsamer sprechen
• Zusätzliche Medien einsetzen
• Zuhörer aktiv einbinden (direkt ansprechen, Aufgaben lösen lassen etc.)

• EDV-Abteilung
  1. Kontakt: (wochen)täglich
  2. Zeitraum: mehrere Jahre (?)
  3. Struktur: Hierarchie abhängig von Positionen (Abteilungsleiter etc.)
  4. Regeln: Stellenbeschreibungen, Anweisungen von Vorgesetzten, Absprachen etc.
  5. Wir-Gefühl: Auftreten als Abteilung
• Studenten SE
  1. Kontakt: Internet, Mail, regelmäßige Treffen vor Ort
  2. Zeitraum: 2 Jahre
  3. Struktur: muss sich noch entwickeln
  4. Regeln: Studienordnung
  5. Wir-Gefühl: Studenten eines Jahrgangs

Team zur Durchführung einer Vorstudie zur Entwicklung einer Projektmanagement-Software

• Softwareentwickler, da letztendlich eine Software zu erstellen ist
• Projektleiter/-mitarbeiter, die praktische Erfahrung mit der Durchführung von Projekten haben und Hilfestellung bei der Anforderungsanalyse geben können
• Zukünftige Benutzer der Software, da sie am ehesten die Zwischenergebnisse auf Tauglichkeit bewerten können

Worauf ist bei der Übernahme von Projekten in funktionalen Unternehmen besonders zu achten?

• Kompetenzgerangel: Abteilungsleiter <> Projektleiter
• Die Projektmitarbeiter sind meist noch im Tagesgeschäft eingespannt
• Geschäftsleitung ist unbedingt einzubinden und muss hinter dem Projekt stehen
• Mitarbeiter sind evtl. mit der Projektorganisation nicht vertraut (an Abteilungsdenken gewöhnt)

Was bringt der Einsatz von Prozessbeschreibungsstandards für die Softwareentwicklung und die Informationstechnologie?

• Eindeutige Prozessbeschreibungen mit weniger Interpretationsspielraum als bei Freitext
• Erstellte Prozessbeschreibungen können evtl. zur automatischen Codegenerierung verwendet werden oder sind als Software lauffähig (z.B. in einer SOA)
• Grafische Prozessbeschreibungen sind von den Mitarbeitern meist einfacher und schneller zu verstehen und zu erfassen
• Bei der Modellierung von Prozessen mit Hilfe von Prozessbeschreibungssprachen muss von Anfang an eindeutig und umfassend modelliert werden, was die Qualität der Modelle erhöht

Was ist die Hauptaufgabe des Projektleiters in prozessorientierten Unternehmen?

• Der Pojektleiter ist in der bereits gut auf Projektarbeit vorbereiteten prozessorientierten Unternehmenskultur hauptsächlich für die Rahmenbedingungen (z.B. Arbeitsräume, Werkzeuge aber auch Kenntnisse von Methoden) zuständig.
• Des Weiteren hält er Kontakt zur übergeordneten Führungsebene und steuert das Projekt in die richtige Richtung.

Warum ist ein gut moderiertes Kick-Off-Meeting wichtig für das Projekt?

• Das Projektteam muss auf das gemeinsame Ziel eingeschworen werden
• Die Teilnehmer lernen sich besser kennen
• Alle Teilnehmer bedürfen klarer Anweisungen bzgl. ihrer Aufgaben
• Die Formalien (Protokolle, Besprechungen etc.) müssen verbindlich festgelegt werden
• Die Vorgehensweise wird zusammen erarbeitet (Grobplan durchgehen, Feinplan aufstellen)

Warum stellt man einen Projektplan auf, anstatt einfach loszulegen?

• Eine Planung der benötigten Zeit und Ressourcen, sowie der Kosten ist ohne Projektplan nicht möglich.
• Ein Projektplan weist jedem Projektmitarbeiter seine Aufgaben zu. Nur so ist eine spätere Kontrolle der erreichten Ziele möglich.
• Der Projektplan bietet stets eine gute Übersicht zum aktuellen Stand des Projektes (wenn er gut gepflegt wird) und zeigt eventuelle Engpässe auf.
• Nur mit Hilfe eines zentralen Projektplans lassen sich die zu erledigenden Aufgaben der einzelnen Projektmitarbeiter so abstimmen, dass nicht redundant gearbeitet oder etwas vergessen wird.
• Auf Basis eines Projektplans, der vom Team gemeinsam erstellt und verabschiedet wird, ist eine optimale Zusammenarbeit ohne Interessens- oder Kompetenzkonflikte möglich.

Mögliche Vorgehensweisen/Hilfsmittel zur Modellierung.

• Größere Probleme werden in mehreren Schritten in Teilprobleme zerlegt. Verfeinere diese Teilprobleme weiter (eventuell mehrfach), bis nur noch elementare algorithmische Grundstrukturen vorliegen: Top-Down-Vorgehen. (http://www.saar.de/~awa/verfein.htm)
• Programme werden modularisiert
• Nur bestimmte Kontrollstrukturen sind erlaubt: Sequenzen, Schleifen, Bedingte Verzweigungen
• Grafisches Hilfsmittel: Struktogramm/Nassi-Shneiderman-Diagramm (http://www.mi.uni-koeln.de/c/mirror/f7alpha1.informatik.fh-muenchen.de/~schieder/programmieren-1-ws96-97/struktpgm.html)
• Vorteile
  • Programmierung von Bibliotheken, Modulen
• Nachteile
  • schwierige Fehlerbehandlung und Datenmodellierung
• Einsatzgebiet: Einfache Programme, prozedurale Programmierung

• Die Unified Modelling Language ist eine Sprache zur Spezifikation, Visualisierung, Konstruktion und Dokumentation von Modellen für Softwaresysteme, Geschäftsmodelle und andere Nicht-Softwaresysteme. Sie bietet den Entwicklern die Möglichkeit, den Entwurf und die Entwicklung von Softwaremodellen auf einheitlicher Basis zu diskutieren. Die UML wird seit 1998 als Standard angesehen. Sie lag und liegt weiterhin bei der Object Management Group (OMG) zur Standardisierung vor. (http://ivs.cs.uni-magdeburg.de/~dumke/UML/index.htm)
• UML ist keine Methode, sondern definiert eine Notation und Semantik zur Visualisierung, Konstruktion und Dokumentation von Modellen für die Geschäftsprozessmodellierung und für die objektorientierte Softwareentwicklung. (http://www.torsten-horn.de/techdocs/uml.htm)
• Grafische Hilfsmittel: Mehrere (13) Diagrammtypen für unterschiedliche Anforderungen
• Vorteile
  • Quasi-Standard, leicht zu verstehen/erlernen
  • Diagramme können zur Codegenerierung verwendet werden
• Nachteile
  • Nicht alle Anforderungen der Objektorientierung werden abgedeckt (aber durch die leichte Erweiterbarkeit von UML sind eigene Erweiterungen möglich)
• Einsatzgebiet: Objektorientierte Programmierung, Entwurf umfangreicher Software

• Scrum
  • http://www.softhouse.se/Uploades/Scrum_eng_webb.pdf
  • http://de.wikipedia.org/wiki/Scrum