Hallo Uli,
Hallo Roland,
vielen Dank für die ausführliche Antwort.
Dazu habe ich noch ein paar Detailfragen :
Häufige Fehler: es werden keine Ziele, sondern Maßnahmen
vereinbart.
Zum Unterschied :
Ein Ziel wäre die Entwicklung eines Programmes nach
Pflichtenheft
mit konkretem Fertigstellungstermin und vereinbartem
Maximal-Aufwand.
Eine Maßnahme wäre z.B. ???
Beispiele (ohne näheres Wissen, wie und unter welcher Beteiligung das
Pflichtenheft zustande gekommen ist):
- Durchführung einer Risikoanalyse. Planung und Durchführung von
Qualitätssicherungsmaßnahmen.
- Überwachung des Terminplans (Meilensteine!) und Ablieferung von
Fortschrittsberichten an das zuständige Management.
- (Richtiger) Projektabschluss: z. B. Dokumentation dessen, was
für die Wartung und die Organisation wichtig ist (Erfahrungen
über Vorgehensweise, Installation, Erkenntnisse aus Prüfungen).
Ich habe aber Zweifel, ob ein „Maximal-Aufwand“ ein vereinbarungs-
würdiger oder -fähiger Gegenstand ist. Um es in dem Schema
„Pro und Contra“ zu diskutieren:
Im Projektgeschäft hat man es mit Schätzungen zu tun. Eine Schätzung
ist eine Schätzung - nichts anderes.
Selbstverständlich braucht man einen Termin, weil der Kunde seine
Anforderungen kund tut. Was für den Kunden eine Komplexitätsreduzierung
ist, ist für Deine Organisation eine Komplexitätserhöhung. Damit muss
sie klar kommen, das ist ihr Zweck. Für die Hierarchie ist das einfach:
sie überwälzt den Komplexitätszuwachs (Termin, Aufwand) auf den
armen Entwickler.
Nun muss man aber sehen, ob den Pflichten auch die entsprechenden
Rechte gegenüberstehen, zum Beispiel der Zugriff auf Ressourcen.
In größeren Unternehmen läuft es so ähnlich und das Verfahren heißt
dann „Projektabwicklungsvereinbarung“. Dann agiert der Projektleiter
wie ein Geschäftsführer des Projekts und hat völlige Freiheit.
Dann ist es OK.
Bei Zielvereinbarungen geht es nicht darum, die gesamte
Geschäftstätigkeit bis ins kleinste aufzudröseln und mit
spezifischen Zielen zu hinterlegen. Ziele sind dort
angebracht, wo zwischen dem SOLL und einem IST eine Abweichung
besteht - und wo der Weg zum Sollzustand nicht von vornherein
klar auf der Hand liegt.
Offenbar habe ich auch Probleme, den definitorischen
Unterschied
zwischen (SMARTen) Zielen und Soll-Zuständen zu begreifen.
Ich sehe auch keine Unterschiede, würde aber (vielleicht zum
besseren Verständnis) differenzieren zwischen Projektzielen
und Organisationszielen. Projektziele beziehen sich auf etwas
Neues. Der Ist-Zustand ist, dass es bisher dieses Ziel nicht
gab.
Bei Organisationszielen (Umsatz, Struktur, Prozesse) hatte man
mehr oder weniger explizit ein Ziel und nimmt zum Zeitpunkt X
den Ist-Zustand auf. Dann gibt es vielleicht Gründe zu sagen,
wir müssen jetzt Y um soundsoviel Prozent verbessern.
Der rhetorische Trick bei der SMART-Methode ist, dass man die
Zukunft in die Gegenwart verlegt, um die Ziele und damit
auch mögliche Risiken zu „visualisieren“.
Da ich weder Eure Unternehmensziele noch Eure
Controllingausstattung kenne
Ziele ? Überleben ! 
)
Nein, im Ernst :
Gute Produkte entwickeln und günstig anbieten, die tatsächlich
vor Ort benötigt werden (Medizinprodukte /-geräte /-software).
Die Software ist entweder ein zu verkaufendes Produkt oder es
sind
Tools für die eigenen Produktionsabläufe.
Die Firma beschäftigt insgesamt je nach wechselndem Bedarf
zwischen
10 und 20 Personen als Angestellte und Honorarkräfte,
die Entwicklungsabteilung ca. 4 Personen, also alles eher
kleindimensioniert.
D.h. es gibt keine eigene Controlling-Abteilung oder einen
(ausschließlich) Controlling-Verantwortlichen.
Schauen wir uns einmal einige Quellen für Zielvereingarungen
an:
- Wie sieht es mit der Einhaltung der Projektbudgets und
Auslieferungstermine für die SW-Entwicklung aus? Aus der
Soll-Ist-Differenz lassen sich messbare Ziele ableiten.
O.K., wir versuchen, möglichst
präzise abzuschätzen, wie lange wir benötigen, um ein Produkt
auf den
Markt zu bringen und was dies entsprechend kosten wird.
Die Realität ist eher die, daß wir froh sind, wenn z.B. nach
Halbzeit von 3 Monaten
nicht allzuviele Katastrophen in Form nicht brauchbarer
Hardware-Komponenten etc. oder
neu/überraschend zu integrierender Software-Funktionen (und
entsprechendem Mehr-Zeitbedarf) eingetreten sind und unsere
Planung
nicht völlige Makulatur ist.
Da häufig jedes neue Produkt wirkliches Neuland für unsere
Leute ist,
kann man nur begrenzt feststellen : schlechte Planung /
Abschätzung des
Entwicklers.
Aber welche Ziele trauen wir uns beim nächsten Mal noch zu
formulieren?
Diese Beschreibung kommt mir bekannt vor. Das ist sozusagen
der Normalfall in der Branche. Hier trifft gut zu:
„Projektmanagement ist das Management von Nichtwissen“.
Die Produktivität kann man nur erhöhen, wenn man die gescheiterten
Projekte untersucht. Ich stelle mir eine Art „Projektkümmerer“
vor, der die „Katastrophen“ auf Zusammenhänge untersucht und
feststellt, welches Wissen oder welche Entscheidung an welcher
Stelle gebraucht worden wäre. Dieser Kümmerer könnte dann noch
einige nützliche Zusatzaufgaben lösen, um die Entwickler zu
entlasten: Integration der Honorarkräfte, Dokumentation …
Das Ganze könnte dann beispielsweise einmünden in ein Mini-
Projektwirkungscontrolling (Tipp zum Googlen).
Ich habe in einer solche Situation eine Datenbank gebastelt und
dort alles gesammelt, was in der Vergangenheit schief gelaufen
ist (nach Projektphasen gegliedert). Man lernt ungeheuer viel
in Projekten, aber das Wissen wird oft nicht genutzt. Das liegt
wohl auch daran, dass der Akt des Misslingens mit Emotionen
verbunden ist und die Ursachen gern verdrängt werden. Mit einer
Datenbank hat man ein „Unterbewusstsein“, das in der Hergabe von
Wissen nicht so widerspenstig ist wie die menschliche Natur.
Ich würde mir noch einmal überlegen, welchem Zweck Zielverbarungen
dienen sollen. Diese Methode wurde meines Wissens für Groß-
organisationen „erfunden“, um über unterschiedliche „Unternehmens-
bilder“ in den Köpfen kommunizieren zu können. Eure „Leute“ sind
doch eigentlich ziemlich dicht dran an der Unternehmenswirklich-
keit. Bei Euch dürfte jedem klar sein, dass die Gehälter von den
Kunden bezahlt werden.
Zur Umsetzung von Zielvereinbarungen bräuchte man dann noch ein
gewisses Maß an Stabilität im Umfeld. Das sehe ich bei Euch
nicht.
Zum Schluss: Ferndiagnosen sind riskant, daher kann es sein, dass
das alles Quatsch ist, was ich geschrieben habe. Ich konnte
nur versuchen, einige mehr oder weniger reflexionsfähige
Gedanken beizusteuern.
Wir können diese Versuche gern fortsetzen.
Gruß,
Uli
