Hilfestellung und Leitfaden zu Projektplanung, Projektmanagement und Projektphasen

Sollten sie eine Änderung ihrer Arbeitsabläufe aus Effizienz und Kostengründen in Richtung Automation, Änderungen an Ausgabe-Ergebnissen (Gestaltung / Werte), eingesetzten Datenbank-Tools und/oder Benutzeroberflächen in Erwägung ziehen, könnten die gewünschten Änderungen weitreichende Folgen beinhalten.
Damit spätere Ergebnisse mit ihren Vorstellungen zu den Änderungen und entstehenden Kosten einhergehen, ein paar Punkte die Beachtung finden sollten.

Problemanalyse: ( vereinfacht für Budgeteigenverantwortliche Abteilungen und kleinere Unternehmen )

• Feststellung:    Haben wir wirklich ein Problem ?
• Definition:       Was genau ist das Problem ?
• Fragestellung:  Kann das Problem überhaupt gelöst werden ?
• Eruierung:       Welche möglichen Lösungsansätze gibt es ?
• Vorstellung:    Wie könnte das Ergebnis aussehen ?
• Fazit:              Welche Veränderungen bringt die angestrebte Lösung mit sich ?
• Konkret:         Wer soll die anstehenden Aufgaben übernehmen ?
• Fragestellung:  Welches Budget steht zur Verfügung ?

Abschließendes "Selbst-Hinterfragen": Ist die eigene Analyse ausreichend, oder wird professionelle Hilfe benötigt ?


Sollte aus den obigen Überlegungen ein festgestellter Bedarf als Ergebnis hervorgehen, empfiehlt es sich ebenfalls mit der Projektentwicklung zu befassen.
Kurzübersicht: Phasen der Projektentwicklung:
  * Projektmanagement
  * Qualitätsmanagement
  * Risikomanagement
  * Systemanalyse / Consulting
  * Pflichtenhefterstellung
  * Systemdesign / technische Konzeption
  * Implementierung
  * System-und Verfahrenstest
  * Installation
  * Einführungsunterstützung
  * Wartung / Pflege


Problemanalyse: ( Bewährte-Verfahren )

Arbeistsschritte / Phasen	Aufgabenverteilung
Problembereich nach Feststellung beschreiben und abgrenzen	kann intern erfolgen
Ist-Analyse (Zustandsbeschreibung)	Zusammenarbeit Anwender / Entwickler

Anforderung: Ist-Zustandsbeschreibung bei der im folgenden genannte Dokumente erstellt werden sollten: Wie wird die Arbeit, die von der zu erstellenden Applikation übernommen werden soll, zur Zeit bewerkstelligt. Welche Arbeitsvorgänge bestehen zur Zeit ? Pflichtenheft: Welche Eingaben und/oder Eingabedaten müssen eingepflegt werden und welche Ausgaben werden benötigt. Das Pflichtenheft soll die Leistungsmerkmale der zu erstellenden Applikation möglichst vollständig und detailliert beschreiben. Im Nachinein ist es Richtlinie für die Realisierung der Applikation. Arbeitsplan / Zeitplan: An dieser Stelle wird versucht den Realisierungsaufwand und den damit entstehenden Personal-und Zeitbedarf abzuschätzen. Für den Zeitbedarf sollten sog. Meilensteine gesetzt werden ( Zeitvorgaben für definierte Entwicklungsschritte ).
Konzept:
Auf Basis des Pflichtenheftes wird ein grober Entwurf zu möglichen Lösungsvarianten erstellt. Sich grundlegend anbietende Varianten sind: Inanspruchnahme einer vorhandenen Lösung: Ist das Projekt an anderer Stelle schon durchgeführt worden, kann versucht werden, die dortige Lösung zu übernehmen / einzukaufen. Hilfssysteme Die zweite Variante besteht darin, an einem (im Unternehmen evtl. vorhandenem) System wie beispielsweise Microsoft-Access anzusetzen und von einem solchen ausgehend, eine eigene Anwendung zu entwickeln. Eigene / interne Applikationsentwicklung: Der Zukauf fremder Software und teurer Lizenzen wird hier ausgespart. Zu den oben genannten Varianten müssen technische Machbarkeit und wirtschaftliche Aspekte genau betrachtet werden. Durch den Vergleich der einzelnen Varianten, die detailliert beschrieben sein müssen, hat ein Entscheider nun die notwendige Grundlage und kann sich für eine der Varianten entscheiden.
Spezifikation und Fein-Konzept:
Steht nun die zu realisierende Variante fest, kann der Entwurf verfeinert werden. Das noch bestehende Gesamtproblem aus dem Grob-Konzept wird in dieser Phase modularisiert. Wird eine arbeitsteilige Realisierung beabsichtigt (Programmierung durch mehrere Entwickler oder Abteilungsübergreifend), ist eine detaillierte Beschreibung der Datenstrukturen und Schnittstellen zwingend notwendig.
Entwicklung / Programmierung / Realisierung:
Wurden alle hier zuvor erwähnten Punkte eingehalten und umgesetzt, kann mit der Entwicklung begonnen werden. Im Laufe der Entwicklungsarbeiten kann sich herausstellen, dass weitere Verfeinerungen an den Daten-und Systemstrukturen notwendig werden. Dies ist bei durchzuführenden Tests der Applikation bzw. der einzelnen Module am besten ersichtlich.
Abschließende Tests:
Haben die vorab durchgeführten Modul-Tests keine Fehler mehr ergeben und die entwickelte Applikation erscheint als fertig, ist nun der sogenannte Systemtest durchzuführen, bei dem umfassend und systematisch alle Funktionen sowie das Laufzeitverhalten möglichst von Anwender und Entwickler gemeinsam zu testen sind.
Einführung der Applikation / Übernahme in Produktivbetrieb:
Bevor die als fertig deklarierte Applikation in den Produktivbetrieb übernommen wird sollte eine Unterweisung der Anwender stattgefunden haben, um eine reibungslose Umstellung zu gewährleisten. Diesbezüglich sollten eine ausführliche Dokumentation und ein Anwenderhandbuch (Bedienungsanleitung) vollständig vorliegen. Als optimale Lösung ist selbstverständlich ein zeitlich festzusetzender, paralleler Betrieb anzustreben, (Test und Produktivbetrieb), bei dem sich die Anwender mit der neuen Applikation vertraut machen können, und noch eventuell auftauchende Fehler beseitigt werden können. An diesem Punkt angelangt wird der Auftraggeber feststellen, ob das fertig gestellte Produkt seinen Erwartungen und Vorstellungen entspricht, oder nicht. Im Falle von unterschiedlichen Ansichten ist nun das Pflichtenheft herbeizuziehen und Punkt für Punkt durchzugehen.

Stolpersteine
Aufwand und Kostenschätzung eines Beraters ohne Einsicht in ein vorhandenes Pflichtenheft, oder vor Erstellung eines solchen, beispielsweise bei einem Bewerbungsgespräch zu einer Projektbesetzung sollten absolut kein Bewertungskriterium darstellen.
Ganz im Gegenteil. Denn ohne Kenntnisse betrieblicher Strukturen, eventueller Datenschutzbestimmungen, eingesetzter Hard-und Software, Datenquellen, Kommunikation-und Daten Schnittstellen, sowie einer detaillierten Funktionsbeschreibung, die es auszuwerten gilt, kann so eine Grob-Schätzung zu einer Kostenexplosion und/oder einer Herabsetzung der Glaubwürdigkeit des Bewerbers führen.
Bewerber die nach obiger Konstellation der Frage nach Kosten-und / oder Zeitaufwandsschätzung ausgesetzt sind, urteilen über den Fragesteller
oftmals in der Hinsicht, dass dem Fragesteller Unwissenheit anhaftet bzw. dieser seine Hausaufgaben nicht gemacht hat.


Qualitätssicherung
Bei der Erstellung umfangreicher Anwendungen erscheint die Qualitätssicherung manchmal als Problem. Hier helfen nur Zwischenabnahmen
entwickelter Funktionen und Masken die der Beschreibung des Pflichtenheftes genauestens entsprechen.

Wer mehr über Qualitätssicherung zu den Punkten: Anforderungserhebung, Analyse und Verwaltung von Anforderungen erfahren möchte, findet
weitere Informationen unter den unten angegebenen Links.
Anforderungserhebung
Analyse und Verwaltung von Anforderungen