Arbeitsorganisation
Zusammenfassung
Allgemeines
Tätigkeitskontrolle - Was mache
ich überhaupt den ganzen Tag?
Störungsprotokoll
To Do-Liste - Kurz- und mittelfristige Planung
und Kontrolle von
Aktivitäten
Langfristige Planung und Kontrolle der
Aktivitäten
Tagesplanung
Berichtswesen
Der eigene Arbeitsrhythmus
Zusammenfassung
Auf dieser Seite werden die fundamentalen Ansätze
persönlicher Arbeitsorganisation dargestellt. Zwar liegt der Fokus
bei der Arbeit eines Business Analysten, in weiten Teilen können
die Ansätze jedoch ohne Veränderung auch auf andere
Tätigkeiten angewandt werden. Den Prinzipien des
Qualitätsmanagements folgend wird Planung, Überwachung und
Messung der eigenen Tätigkeiten sowie Berichtswesen dargestellt.
Auf Zeitmanagement und Methoden zur Priorisierung von Aufgaben wird am
Rande eingegangen. Einige als Vorlagen verwendbare Dokumente werden zum
Download angeboten.
Allgemeines
Grosse Dinge kann man nur bewegen, wenn man die kleinen locker im Griff
hat. Es bleibt also nichts anderes übrig, als zunächst bei
sich selbst anzufangen.
Es gibt eine Reihe persönlicher Vorlieben und Vorurteile zur
Professionalität. Tom DeMarco erwähnte einmal spöttisch,
dass irgend jemand behauptet hätte, Popcorn am Arbeitsplatz sei
nicht professionell. Ein anderer Glaubenskrieg herrscht zwischen
Ordnungsfanatikern und Chaostheoretikern. Egal, welcher Ideologie man
persönlich anhängt: Wenn man eine Lieferzusage gemacht hat,
dann gibt es keine Entschuldigung dafür, nicht zu liefern. ("There
is no excuse for no delivery.", Prakash Sastry, Fact Delta Solutions). Der Weg
dorthin ist dem Auftraggeber egal.
Ziel persönlicher Arbeitsorganisation soll sein, die für den
Erfolg des Projekts notwendigen Leistungen bei angemessener
persönlicher Belastung, möglichst wenigen Fehlern (ganz ohne
geht es nicht) und möglichst hoher Lebensqualität zu
erreichen. Eine persönliche Tagesplanung bzw.
Arbeitsalltagsplanung ist unerläßlich, will man am Ende
nicht total ferngesteuert, ineffektiv und nutzlos durch einen
sinnentleerten Arbeitstag taumeln, nur um am Abend festzustellen, dass
man zwar voll im Stress war, aber nicht mehr weiß, was man
eigentlich den ganzen Tag über getan hat. Von dort zum Burnout ist
es nicht mehr weit.
Für einen Business Analysten gilt dies mindestens in dem
Maße wie für einen Entwickler.
Tätigkeitskontrolle - Was
mache ich überhaupt den ganzen Tag?
Falls jemand noch gar nichts tut, um seinen Arbeitstag zu planen, so
empfehle ich regelmäßig, mit der Überwachung der
eigenen Tätigkeiten zu beginnen, anstatt mit einer ToDo-Liste oder
einer anderen Form der mittelfristigen Planung. Der Grund dazu besteht
darin, dass man zuerst einmal heraus bekommen muss, was man eigentlich
den ganzen Tag tut, ehe man mit Planungen beginnt, die die
gewöhnlichen und vor allem notwendigen Tätigkeiten
außer acht lassen, nur, weil man sich ihrer gar nicht bewusst
ist. Ein Protokoll, das einen Tagesablauf auf 5 Minuten genau belegt,
offenbart manche Zeitverschwendung, die vom zeitstehlenden Kollegen
oder Vorgesetzten über fortwährende Unterbrechungen, die den
konzentrierten Arbeitsfortschritt unmöglich machen, bis zum viel
zu langen Kunden- oder Privattelefonat
reicht.
Die IT-Mitarbeiter sind es gewohnt, ihre Zeiten zu belegen und ihre
Tätigkeiten nachzuweisen. Wesentlich ist in erster Linie,
Kontrolle über die eigenen (fremd- oder ereignisgesteuerten)
Aktivitäten zu behalten und effizient zu bleiben. Die Kontrolle
eigener Aktivitäten kann sehr individuell ablaufen, die von mir
benutzte und dargestellte Methode ist nur eine unter vielen.
Ich selbst protokolliere
normalerweise einen Arbeitstag auf ca. 5 Minuten genau, obwohl es
15 Minuten auch tun. Dazu liegt auf meinem Arbeitsplatz ein
DIN-A-4-Block,
auf dem jede Seite einen Tag repräsentiert. Diese Protokolle sieht
mein
Projektleiter
nur ausnahmsweise, denn sie belegen neben den Zeiten, die ich abrechne
(von der echten Arbeit bis zum informellen Gespräch in der
verlängerten
Mittagspause) auch nicht abrechenbare Zeiten (z.B. längeres
Privatgespräch, beantworten privater EMails) und sie enthalten
z.T. persönliche Notizen. Der Zweck dieses Dokuments besteht
darin, mir selbst
darüber klar zu werden, was ich tue, und nicht,
anderen Leuten gegenüber zu rechtfertigen, was ich getan habe. Die
Zeitnachweise für meinen Auftraggeber bleiben auf der sachlichen
Ebene, enthalten nur abrechenbare Zeiten, sind auf 15 bis 30 Minuten
gerastert (falls dies verlangt ist)
und werden getrennt geführt. Diese Form handschriftlicher
Protokolle kostet mich weniger als 5 Minuten pro Tag.
Die Faustregel lautet: Hatte ich an einem Tag maximal
5 Eintragungen, dann konnte ich relativ ungestört und effektiv
arbeiten, hatte ich mehr als 15, dann ist der Tag verloren gewesen.
Nehmen die schlechten Tage überhand, dann muss etwas geändert
werden.
Ich unterscheide vier bedenkliche Situationen:
- Ich war mehr als 9 Stunden in der Firma, habe mich dabei aber
weniger
als 6 Stunden um meine eigentliche Arbeit gekümmert. - Wodurch
entstanden die Ablenkungen?
- Ich war mehr als 8 Stunden in der Firma und habe dabei keinerlei
privaten Aktivitäten nachzuweisen, nicht einmal das Lesen privater
Emails oder eine Plauderei im Gang. - Wodurch entsteht der Druck?
- Ich war den ganzen Tag im Stress und weiß
abends nicht mehr, was ich getan habe. - Wodurch entstand diese
Situation, wo brannte es so sehr, dass ich meine eigentliche Arbeit
ruhen ließ?
- Ich hatte den ganzen Tag über nichts wirklich wichtiges oder
gar nichts zu tun. - Wodurch entstehen die Leerläufe?
Falls sich solche Situationen häufen, kontaktiere ich i.d.R. den
Projektleiter, nachdem ich evaluiert habe, wo das eigentliche Problem
liegt. Dies kann mitunter (und nicht nur bei mir) zu skurrilen
Situationen führen:
Beispiele aus der Praxis
Ein Projektleiter fragte seinen Business Analysten einmal etwas
provokativ, was er eigentlich den ganzen Tag machen würde, nachdem
er sich mehrfach beklagt hatte, dass er kaum dazu käme, die
Spezifikation voran zu treiben. Der Analytiker bat den Projektleiter,
einen beliebigen Tag der letzten zwei Wochen zu benennen und
konsultierte dann sein Logbuch. Zunächst war er 90 Minuten mit der
Beantwortung von 26 Emails beschäftigt gewesen. 23 davon stammten
vom Projektleiter, der sie am Morgen gesammelt verschickt hatte, die
meisten davon hatten eine Antwort erfordert. Weitere 90 Minuten waren
dadurch belegt, dass sich der Projektleiter beim Analytiker über
ein anderes Projekt verbreitet hatte, mit dem der Analytiker nichts zu
schaffen hatte; die
Zeit war eigentlich für ein Projektmeeting vorgesehen gewesen.
Weitere vier Stunden für diesem Tag belegte der Analytiker mit
Meetings,
in denen auch der Projektleiter anwesend war; in einem der Meetings
wurde
über eine Stunde das Meetingprotokoll eines anderen Meetings
überarbeitet. - Der Projektleiter erkundigte sich darauf nie
wieder, was der Analytiker den ganzen Tag tat.
Im Tagesprotokoll eines Analytikers fanden sich einmal
etwa ein halbes Dutzend spontaner Unterbrechungen durch den
Projektleiter, etwa genau so viele Kundenanrufe und eben so viele
dringende Unterbrechungen, die ein kurzes Trouble Shooting für
andere Projekte zur Folge hatten. Das letzte halbe Dutzend
Aktivitäten hatte mit der eigentlichen Analysearbeit zu tun. Auch
diese wurden gestört, da der Analytiker in einem
fünfer-Büro untergebracht war das zudem keine ausreichende
Schalldämpfung zu den beiden Nachbarbüros aufwies. Bezogen
auf einen acht-Stunden-Tag waren dies gemittelt ca. 20 Minuten je
Aktivität. Schon Tom DeMarco hat nachgewiesen, dass solch ein
Arbeitstag kaum effizient ist. ([DeMarco1])
Es ist müßig festzustellen, dass ein Anforderungsdokument
nur dann gut werden kann, wenn man sich auch mit der Analyse
beschäftigt. Ablenkungen gilt es zu minimieren und Unterbrechungen
zu vermeiden. Solche Ablenkungen können auch zusätzliche
Aufgaben oder meist nur scheinbar unvermeidbare Unterbrechungen sein.
Wenn man weiß, dass man eine Aufgabe rein zeitlich nicht
bewältigen kann, dann darf man sie nicht annehmen oder man
muß eine Vereinbarung mit dem Auftraggeber über eine
Abänderung der Zeitpläne treffen. Die Priorisierung liegt
beim Auftraggeber.
Störungsprotokoll
Störungsprotokolle anzufertigen wird regelmäßig in der
Zeitmanagementliteratur und in entsprechenden Seminaren empfohlen.
Wichtig werden sie m.E. immer dann, wenn man den Eindruck gewinnt, dass
der Arbeitstag von Unterbrechungen und nicht von kontinuierlichen
geplanten Tätigkeiten dominiert wird. Das Führen von
Störungsprotokollen soll kein Dauerzustand sein, sondern nur bei
Bedarf und für etwa eine Arbeitswoche oder einen Zeitraum, der
Ihnen aussagekräftig genug erscheint.
Kopfarbeiter, also natürlich auch bzw. gerade Software-Entwickler
und Analytiker, leben von konzentrierter Arbeit. Ehe die Arbeit
wirklich als effizient anzusehen ist, hat ein solcher Kopfarbeiter eine
Eintauchphase von ca. 10 bis
15 Minuten, wie es unser Berufsstand täglich erfährt und von [DeMarco1] nachgewiesen
wurde. Während dieser Eintauchphase vertieft man sich in die zu
analysierende Fragestellung oder das zu lösende Problem, verliert
sich am Ende schließlich darin, vergisst Zeit und Raum und taucht
erst wieder auf, wenn man die Lösung gefunden hat oder
unterbrochen wird. Sofern das Tagesprotokoll zeigt, dass der Arbeitstag
zu zerrissen ist, womöglich von mehreren Unterbrechungen pro
Stunde, lohnt es sich, daraus entweder ein Störungsprotokoll
abzuleiten oder einige Tage lang eines explizit zu führen.
Letzteres ist m.E. besser, da im Tagesprotokoll vor allem
Tätigkeiten protokolliert und Störungen eher nur
zufällig nebenbei notiert werden, will man das es nicht
annähernd minutengenau führen.
Im Störungsprotokoll sollten Zeitpunkt, Dauer und Ursache der
Störung festgehalten werden. Einige Störungen sind
Standardfälle, die in der hier hinterlegten Vorlage bereits
vorgesehen sind. Dazu gehören private und geschäftliche
Anrufe, unnötige Unterbrechungen von Kollegen oder Vorgesetzten,
sowie Lärmstörungen durch Umgebungsgeräusche. Je nach
Umgang mit den Kommunikationsmedien EMail und Telefax kann auch dies
eine Störung sein, insbesondere dann, wenn die eingehende
Nachricht auch tatsächlich wie ein Telefonanruf sofort beantwortet
werden soll. Darüber hinaus hat jeder wahrscheinlich noch
berufsspezifische bzw. unternehmensspezifische Störquellen.
Die Auswertung des Störungsprotokolls führt zu
quantifizierbaren Ergebnissen, also einer wie vom
Qualitätsmanagement verlangten Metrik, und man kann zumindest
versuchen, gegen einige der Störungen vorzugehen. Telefone
können zumindest zeitweise abgeschaltet oder (zum Projektleiter
oder zur Teamassistentin)umgelenkt werden, störenden Kollegen,
Kunden und zumindest verständigen Vorgesetzten können Sprechzeiten zugewiesen werden, und
eingehende Nachrichten können häufig zumindest einige Stunden
unbearbeitet bleiben, wenn man sich angewöhnt, sie z.B. nur
morgens, nach dem Mittagessen und vor dem nach Hause gehen zu
bearbeiten. Schwierig wird es jedoch, wenn innerhalb der vorhandenen
Unternehmenskultur kein Verständnis für effektive Arbeit
herrscht, was sich vor allem in lauten Großraumbüros ("man
kann sich an den Lärm gewöhnen"), dem Verbot der Rufumleitung
("die Sekretären kommt ja gar nicht mehr dazu, ihre Arbeit zu
machen" - kommen Sie dazu?) oder sehr sprunghaften Vorgesetzten
manifestiert, die den Wunsch nach unterbrechungsfreier Arbeit und
Sprechzeiten nicht akzeptieren. Mit viel Geduld kann man vielleicht auf
diese Kultur einwirken, aber u.U. muss man sich damit abfinden, dass
die Firmenkultur auf Effizienz trotz aller Lippenbekenntnisse keinerlei
Wert legt.
Es kann einen gewissen Unterhaltungswert haben, wenn man
hartnäckigen Störern quantifiziert ihren negativen Einfluss
auf die eigene Effizienz nachweisen kann. Dabei sollte allerdings
darauf geachtet werden, dass man wie üblich nach einer Lösung
und nicht nach einem Schuldigen sucht. Wenn Sie jemand stört, dann
steckt dahinter so gut wie nie reine Willkür, vielmehr
benötigt der Störer Ihre wahrscheinlich sogar sehr
geschätzte Zuarbeit, sonst würde er Sie nicht unterbrechen.
Fraglich ist allerdings, ob der Störer seine Anfrage auch
adäquat priorisiert hat und die Störung tatsächlich
sofort sein muss, oder ob er bis zu einem Zeitfenster, das Sie zwei
oder dreimal am Tag offen halten, warten kann.
Vorlage / Vorschlag für ein
Störungsprotokoll (word)
To Do-Liste - Kurz- und mittelfristige Planung
und Kontrolle von
Aktivitäten
Über Zeitmanagement (time management) wurden viele und über
Risikomanagement (risk management) doch immerhin einige Bücher
geschrieben. Sie alle fordern, dass Aktivitäten priorisiert,
geplant und deren Auswirkungen überwacht werden. Für alle
anstehenden Aufgaben und Aktivitäten sollte man sich das Prinzip
der Schriftlichkeit angewöhnen.
Beispiel aus der Praxis
Ich arbeitete einmal mit einem anderen Freiberufler zusammen, der die
Angewohnheit hatte, chronologisch alle seine Gedanken,
Überlegungen, Gesprächsnotizen, Meetingmitschriften,
Aufgaben, Fragestellungen etc. in einem Tagebuch festzuhalten. Er
notierte tatsächlich alles in dieses Buch, was ihm über den
Weg lief, und führte sonst keine handschriftlichen Notizen. Er
erklärte mir, dass er auf
diese Weise noch immer Projekte nachvollziehen konnte, die bereits
mehrere Jahre zurück lagen.
Ein Business Analyst tut sich i.d.R. schwer, eine sehr langfristige
Planung zu
erstellen, denn er ist mehr als jeder andere Projektmitarbeiter auf die
Kooperation und Sorgfalt einer Reihe von Mitarbeitern aus der
Fachabteilung angewiesen und auch darauf, dass sein Projektleiter nicht
im Wege steht. Die Kreativität der Fachanwender setzt
den Planungen des Analytikers häufig klare Grenzen, da u.U. mehr
spontane und ungeplante Aktivitäten bearbeitet werden müssen,
als geplante.
Das Resultat einer Planung ist eine ToDo-Liste, die folgende
Einträge enthalten kann:
- Kurzbeschreibung der geplanten Aufgabe
- Priorisierung Status (wie dringlich, wie wichtig? - rot, gelb,
grün, erledigt, Voraussetzungen für die Bearbeitung sind noch
nicht vorhanden)
- Wann wurde die Aufgabe in die ToDo-Liste aufgenommen?
- Warum wurde die Aufgabe aufgenommen? (Auslöser, Trigger)
- Bis wann ist die Aufgabe zu erledigen?
- Wie aufwendig ist die Erledigung der Aufgabe? Wie lange dauert es?
- Wann ist die nächste Wiedervorlage?
- Protokoll-Notizen, was sich inzwischen an der Aufgabe getan hat
und wie weit sie erledigt ist.
Vorlage/Vorschlag für eine ToDo-Liste (word)
Beispiel aus der Praxis
In einem Projekt blieben nur noch der Projektleiter und ein engagierter
Mitarbeiter übrig, um eine scheinbar ausweglose Krise zu
bewältigen. Alle anderen Projektmitarbeiter hatten ihren Hut
genommen oder waren gefeuert worden. Der Mitarbeiter fertigte
zunächst eine
ToDo-Liste an, auf der er 15 Einträge hatte, davon 4 auf rot und
8 auf gelb. Er arbeitete sich die Farbskala entlang durch, eine Woche
später war noch eine Aktivität auf rot und drei auf gelb,
alle fielen in den Bereich des Projektleiters oder hingen von Faktoren
außerhalb des Projekts ab. Dann ging es mit einer normalen
Projektplanung
weiter.
Als Faustregel gilt, dass man sich vor dem nach Hause gehen kurz
Gedanken über den nächsten Tag machen und bei
Arbeitsbeginn seine Wiedervorlageliste durchsehen sollte.
Dadurch, dass in dieser Form der ToDo-Liste auch Protokollnotizen
enthalten sind, die den bisherigen Lösungsverlauf der Aufgabe
dokumentieren, kann recht gut erkannt werden, wenn man sich selbst oder
seine Fachanwender sich im Kreise drehen, Widersprüche produzieren
oder fortwährend Termine nicht einhalten und Arbeitspakete nicht
erledigen. Daraus kann dann eine Prognose ermittelt werden, wie stark
die im Projektplan vorgesehenen Pufferzeiten belastet werden bzw. an
welchen
Stellen eingegriffen werden muss, um mehr Stringenz in den
Arbeitsablauf zu bringen.
Langfristige Planung und Kontrolle
von Aktivitäten
Sollten Sie noch niemals in Ihrem Leben einen Projektplan gesehen
haben, dann holen Sie es sofort nach! Hier kann ich Ihnen kein Beispiel
anbieten, aber in Ihrem Unternehmen gibt es sicher jemanden, der
Projekte plant und Ihnen bereitwillig die Grundprinzipien beibringt.
Falls nicht, dann wird es Zeit, dass Sie mich anheuern (Kontakt); nicht als Analytiker,
sondern als Coach für Grundlagen der Projektarbeit.
Die Projektplanung obliegt der Projektleitung, nicht dem Analytiker.
Der Projektleiter will jedoch wie auch der Auftraggeber eine
Abschätzung über die Dauer der Analysephase (und auch aller
anderen Aufgaben). Dies ist
allerdings nach gängiger IT-Meinung nicht möglich. M.E. kann
bestenfalls ein prozentualer Ansatz auf Basis des Projektbudgets
gewählt werden (vgl. Kosten und
Aufwände). Die Reihenfolge im IT-Projekt ist ungeachtet
des Prozess-Modells stets verstehen, spezifizieren, designen,
implementieren. Erst, wenn der Analytiker der Überzeugung ist,
dass er eine Fragestellung im Detail verstanden hat, sodass er sie auch
ohne weiteren Kundenkontakt spezifizieren kann, kann er auch eine
Aufwandsabschätzung dazu abgeben. Das macht aber meist keinen
Sinn, da die zu klärenden Fragen nur nach und nach verstanden
werden und somit auch nur stückweise eine Abschätzung gegeben
werden kann. Die Abschätzung wird aber dennoch falsch sein, da sie
nie die Zeiten enthalten, die für noch gar nicht erkannte Fragen
aufzuwenden ist. Zudem ist der eigentlich Spezifikationsprozess im
Sinne eines reinen Niederschreibens bei fast allen Fragestellungen im
Vergleich zu der Zeit, die zum Verstehen der Anforderung notwendig ist,
klein.
In manchen Arbeitsumgebungen ist die Zuarbeit der Fachabteilung
ungenügend, die Geschäftslogik ist stark in Bewegung oder der
Auftraggeber ist sehr kreativ und der Willensbildungsprozess findet
während der Spezifikation statt, nicht davor (vgl. hierzu z.B. die
Tücken der Anforderungsanalyse).
Zu Analysebeginn ist
auf keinen Fall hinreichend
bekannt, wie das Produkt am Ende auszusehen
hat, sonst wäre die Spezifikation bereits fertig. Wie bereits
mehrfach auf diesen Seiten erwähnt, tut sich ein Business
Analyst mit einer langfristigen Planung seiner Aktivitäten schwer,
sofern sie nicht unmöglich ist.
Sinnvoll sind auf jeden Fall Zielvereinbarungen mit den an der Analyse
beteiligten Fachanwendern, die sich an den Entstehungsschritten
eines Anforderungsdokuments orientieren. Diese Zielvereinbarungen
können im Projektplan auch als Meilensteine definiert werden,
allerdings wird sich der Projektleiter mit konkreten Terminen schwer
tun, sofern der Analytiker nicht aus dem Bauch heraus zu fabulieren
beginnt oder der Projektleiter eigenmächtig würfelt. Die
übliche Faustregel ist, dass die Analysephase ca. ein
Drittel des Gesamtprojekts ausmacht (vgl. Kosten
und
Aufwände). Die Dauer der Zwischenschritte ist allerdings
extrem projektabhängig: es gibt Projekte, bei denen es nur wenige
Prozesse aus hoher Sicht gibt, die recht zügig fixiert werden
können, bei denen allerdings die Verarbeitungsschritte im Detail
nur schwer zu erarbeiten sind; bei anderen Projekten bleibt die hohe
Sicht sehr beweglich und wird erst spät festgelegt werden,
dafür sind die Details der einzelnen Teilprozesse recht einfach zu
definieren, sobald die hohe Sicht steht.
Zunächst sollte eine möglichst einfache und hohe Sicht auf
das Projekt als erstes Ziel vereinbart werden. Dabei werden sehr
globale Prozesse oder Anwendungsfälle in sehr grober Granulierung
definiert. Projektabhängig kann man dazu mit einem
mehrtägigen Workshop beginnen. Nachdem diese Sicht erstmals steht
(sie wird sich wahrscheinlich noch verändern), kann versucht
werden, mit den Fachanwendern ein zeitliches Ziel zu vereinbaren, bis
wann sie die aus ihrer Sicht notwendigen Informationen verbindlich
liefern und festlegen können, die für die Spezifikation des
Prozesses im fachlichen Detail (aber noch nicht auf Ebene eines
IT-Ablaufes!) gut genug ist. Man fährt einigermaßen richtig,
wenn man diese Terminzusagen nicht all zu ernst nimmt und mit dem
Faktor 1,5 oder 2 multipliziert. Erst nach Lieferung dieser
Detail-Fachinformationen kann man sich an das eigentliche IT-System
wagen. Die Zeitabschätzungen hier sind wiederum extrem
fallabhängig, und ich kann keine Faustregel geben. Die Wahrheit
liegt etwa in der Größenordung, dass die IT-brauchbare
Spezifikation eines Prozesses komplexitätsabhängig mindestens
so lange dauert, wie die fachliche Betrachtung, aber auch zehn mal so
lange dauern kann.
Ein Kochrezept für eine langfristige Planung der Analysephase, die
mehr als nur zufällig richtig ist, gibt es nicht, und ich rate
auch davon ab, mehr als die Gesamtdauer der Analysephase bei der ersten
Projektplanung vorzusehen. Dabei muss mit dem Kunden von Anfang an eine
Vereinbarung getroffen werden, wie vorzugehen ist, wenn die Zuarbeit
der Fachabteilung nicht gut genug ist, um den Zeitplan einzuhalten.
Tagesplanung
Zur Zeitplanung gibt es die Faustregel, dass man nur 60% eines Tages
verplanen sollte, 20% für unvorhergesehene Aktivitäten und
weitere 20% für spontane Aktivitäten vorhalten sollte. Ich
persönlich unterscheide folgende Planungsregeln,die sich in meiner
Praxis bewährt haben und die ich regelmäßig empfehle:
- das Projekt läuft normal: Ich verplane bis zu 80% eines
acht-Stunden-Tages, bin jedoch im Notfall auch ungeplant bereit,
ausnahmsweise neun
oder zehn Stunden zu bleiben.
- im Projekt zeichnet sich eine Krise ab: Ich verplane 60% des
Folgetages, den ich zu sieben bis acht Stunden ansetze,
gehe jedoch davon aus, dass ich eher neun Stunden in der Firma bin.
- ein Projekt befindet sich in einer Krise: Ich verplane 40% des
Folgetages, den ich zu maximal sieben Stunden ansetze, gehe jedoch
davon aus, dass ich eher neun bis zehn Stunden in der Firma bin.
- ein Projekt ist vollkommen außer Kontrolle
geraten: Ich verplane so wenig wie möglich Zeit und wechsle
in ein Day-By-Day-Management,
bis sich wieder eine klare Linie im Projekt sehen lässt
und übliche Planungswege beschritten werden können.
Der etwas ungewöhnliche Ansatz, die Arbeitstage verschieden lang
anzusetzen, hat seine Ursache im Umgang der anderen Projektbeteiligten
mit externen Mitarbeitern. Die Verträge externer Mitarbeiter
erlauben entweder eine Abrechung auf Stunden- oder auf Tagesbasis. Wird
pro Stunde abgerechnet, so bekommt das Controlling
regelmäßig einen Wutanfall, wenn 180 oder 200 oder noch mehr
Stunden in einem Monat abgerechnet werden. Wird dagegen auf Tagesbasis
abgerechnet, macht der Externe betriebswirtschaftlich nicht vertretbare
Geschenke an seinen Auftraggeber, nicht zuletzt wegen einer
illusorischen Langfristplanung, wenn er mehr als die vereinbarte Zeit
arbeitet, ohne dafür eine zeitliche oder finanzielle Kompensation
zu erhalten. Wie weit die Kulanz des einzelnen Mitarbeiters geht, ist
ihm selbst überlassen. Bei mir geht sie nicht all zu weit, da ich
ausschließlich Zeiten abrechne, in denen ich auch produktiv
gearbeitet habe. Wenn ein Projekt in eine Krise gerät, dann
erlaube ich anderen, nur von
sieben Stunden oder weniger Verfügbarkeit auszugehen, denn
ich weiß ohnehin, dass es mehr sein wird. Sollte es doch einmal
gelingen, nach sieben Stunden zu gehen, dann ist der Erholungswert auf
jedem Fall im Sinne des Projekts und meines Privatlebens.
Beispiel aus der Praxis
Ein Projektleiter beklagte, dass er die Personal-Ressourcen nicht
vernünftig verplanen könne. In der Firma befanden sich
tatsächlich eine Reihe von Projekten in der Krise, die zu sehr
vielen ungeplanten und spontanen Aktivitäten führten. Der
Projektleiter forderte, dass die Mitarbeiter mindestens zwei Wochen im
Voraus ihre Tagesplanung auf 10% genau bekannt geben sollten. Die
Forderung ließ sich nicht durchsetzen.
Planung bedeutet nicht Kontrollwahn. Selbstverständlich gelten
für Projekte langfristige Planungen, die weit über zwei
Wochen hinaus gehen, aber eine Planung auf 45 Minuten wie im Beispiel
oder gar auf nur eine
Viertel Stunde genau funktioniert nicht, vor allem nicht in
einer Krise.
google zu Zeitmanagement
Berichtswesen
Definition
Der Begriff "Berichtswesen" hat in den letzten Jahren andere Begriffe
für Hierarchien und Weisungsbefungnis weitestgehend ersetzt. Der
Untergebene berichtet an seinen Vorgesetzten.
Dessen ungeachtet bedeutet berichten
aber noch immer, dass informiert
wird, und in diesem Kontext wird berichten
in diesem Abschnitt verwendet.
An wen berichtet der Business Analyst?
Der genaue Personenkreis muss fallabhängig definiert werden. Nahe
liegt, dass die Leute regelmäßig informiert werden, die die
Arbeit koordinieren,
sowie alle Mitarbeiter, die von den Arbeitsergebnissen des
Analytikers abhängig sind, sodass diese nötigenfalls
ihre Planungen frühzeitig
anpassen können.
Der formale Berichtsweg sieht
lediglich den Bericht an den unmittelbaren Vorgesetzten vor. Für
einen Analytiker ist diese Informationspolitik allerdings pragmatisch
kaum durchzuhalten, will der unmittelbar Weisungsbefungte nicht eine
gewisse Zähigkeit im Projektfortschritt erreichen. Solche
willentlichen Verzögerungen können dazu führen, dass der
Business Analyst zum Ziel der Kritik wird. Er sollte nicht davor
zurück schrecken, die Kritiker an den Verantwortlichen zu
verweisen. Anweisungen
nimmt ein Business Analyst ausschließlich von seinem
Projektleiter entgegen, normalerweise informiert ein Business Analyst
jedoch über Fortschritte, Hindernisse und Ergebnisse immer an
folgende Personen:
- den Projektleiter der Fachabteilung
- den Projektleiter der IT-Seite
- den Gesamtprojektleiter, wenn einer vorhanden ist
Der Analytiker wird rein formal einem der beiden Projektleiter der IT-
oder Fachseite zugeordnet werden, sofern nicht ein übergeordneter
Gesamtprojektleiter benannt wird. Aus dieser Konstellation können
sich einige politische Verwicklungen
ergeben, denn gelegentlich fordert
der formal vorgesetzte Projektleiter vom Analytiker, dass er bestimmte
Informationen der anderen
Seite nicht oder nur unvollständig zukommen lässt, im
Extremfall fordert er auch, dass falsche Informationen geliefert
werden. Es ist eine persönliche Entscheidung, ob und wie weit man
solchen Forderungen nachkommt. Ich persönlich verkaufe meine
Arbeitskraft und nicht meine Seele. Ich lehne es strikt ab, irgend
einen Projektbeteiligten zu belügen, bewusst Informationen
zurück zu halten oder zu verfälschen. Im
Zweifelsfalle verweise ich an den Projektleiter, der diesen
zweifelhaften Wunsch geäußert hat und sehe mich nach einem
neuen Projekt um, denn das aktuelle scheitert normalerweise recht rasch.
Sofern eine professionelle Person jenseits der Fachabteilung und der
IT-Abteilung das Projekt verantwortlich leitet, die nicht die
Interessen einer Partei sondern ausschließlich die des Projekts
vertritt, sollte erwogen werden, den Analytiker an diese Person
berichten zu lassen, um Unfug wie im letzten Absatz beschrieben zu
vermeiden.
So, wie es einen Eskalationsweg von unten nach oben am Projektleiter
bzw. am Vorgesetzten vorbei gibt, gibt es auch einen Frage- und ggf.
Weisungsweg von oben nach unten, der am Projektleiter und
nötigenfalls auch am Business Analysten vorbei geht. Letzteres ist
angebracht, wenn zwar von Entwicklern oder Fachanwendern die
Qualität des Anforderungsanalyse-Prozesses bzw. des
Anforderungsdokuments bemängelt wird, Projektleiter und Business
Analyst aber jede Kritik und eine einvernehmliche Eskalation
zurück weisen. Man sollte dann die Motive des Projektleiters bzw.
Analytikers hinterfragen und eine Ersetzung dieser Personen
erwägen, denn letztendlich entscheiden Fachabteilung und
IT-Abteilung jeweils für sich, ob die Qualität der
Anforderungsanalyse genügt. Ein Business Analyst wird diesen
Eskalationsvorgang
am Vorgesetzten vorbei auf dem Berichtswege(!) nur dann wählen,
wenn er im Zweifel
darüber ist, dass sein unmittelbarer Vorgesetzter noch im Sinne
des
Projekts handelt oder nicht und wenn dieser Vorgesetzte eine
einvernehmliche Eskalation abgelehnt hat.
Berichte über spontane
Ereignisse
Spontane Ereignisse, die zu ungeplanten Aktivitäten führen,
sollten auf jeden Fall im Wochenbericht aufgeführt werden.
Nötigenfalls soll auch ad hoc an den Projektmanager berichtet
werden, wenn das Ereignis nachhaltige Auswirkungen auf das Projekt
erwarten lässt. I.d.R. wird es ein Anruf oder eine kurze
informelle EMail tun, die man nötigenfalls als Aktennotiz der
eigenen Projektdokumentation befügt.
Man kann nicht alles planen, wenn allerdings ungeplante
Aktivitäten überhand nehmen und ein schleichender
Übergang zu einem day by day-Management in Sicht ist, dann kann es
brenzlig werden und das Projekt gerät schleichend außer
Kontrolle. Spätestens im Rahmen der Reevaluierung des Projekts
sollte geklärt werden, ob lediglich die Projektkontrolle bei einer
korrekten Planung versagt hat, oder ob die Planung von Anfang an
schlecht war.
Wochenbericht
Das Berichtswesen an das höher gelegene Management ist dem
Projektmanager überlassen. Ungeachtet
der Rolle, die man in einem Projekt hat, kann jedoch eine Vereinbarung
mit dem Projektmanager oder der ihm vorgesetzten Person getroffen
werden, dass regelmäßig jede Woche folgende vier Punkte
berichtet
werden:
- Aufgaben und Aktivitäten erledigt, die geplant waren.
- Aufgaben und Aktivitäten erledigt, die nicht geplant waren.
- Geplante Aktivitäten für nächste Woche.
- Die fünf oder zehn wichtigsten Fragen bzw. Arbeitspakete,
die zu erledigen sind, aber nicht in der Macht des Berichtenden
stehen.
Solch ein Bericht sollte binnen einer Viertel Stunde erledigt sein und
er enthält nur die gröbsten Schlagworte, das Lesen dauert
sicher weniger als fünf Minuten.
Beispiel aus der Praxis
Ein Analytiker, der gleichzeitig als Projektleiter fungierte, schickte
regelmäßig solche Berichte an seinen Program Manager. Er
kommentierte dies mit den Worten: "Jeder kann sagen, dass er den
Bericht nicht gelesen hat, aber niemand kann behaupten, er hätte
von nichts gewusst." Dieser Projektleiter war dafür bekannt,
dass er als einziger in der Organisation, in der ich ihn erstmals traf,
seine Projekte im Zeitplan und ohne Reklamationen des
Qualitätsmanagers fertig stellte.
Kollegen und Vorgesetzten können nur dann hilfreich eingreifen,
wenn sie wissen, was los ist und wo es nicht voran geht. Häufig
können sie auf Grund ihrer anderen Sichtweise schon früher
ein Projektrisiko erkennen, als der Analytiker oder Projektleiter
selbst. Ein regelmäßiger kurzer Bericht kann dabei hilfreich
sein. Es kommt manchmal vor, dass solch ein Bericht als unnötig
zurück gewiesen wird, oder dass gewünscht wird, dass
bestimmte Personen nicht auf dem Verteiler erscheinen. Ich habe
allerdings noch kein Projekt erlebt, das erfolgreich war, wenn so etwas
geschah.
Vorlage/Vorschlag für einen
Wochenbericht
(word)
Der eigene Arbeitsrhythmus
Man sagt, dass es keinen Stress gibt, sondern dass man ihn sich macht.
Dies ist m.E. bei einer fremdbestimmten Arbeit aber nur die halbe
Wahrheit. Vielleicht der typischte fremdbestimmte Beruf nach dem
Fliesbandarbeiter und Manager ist die Sekretären. Je mehr man
anderen Leuten zuarbeitet, je mehr man von der Qualität der
Zuarbeit anderer Leute abhängt und je mehr man hinter anderen
Leuten "aufräumen" muss, um so schwieriger wird es,
vernünftige Leistungen bei akzeptabler Arbeits- und
Lebensqualität zu liefern. Innerhalb der IT führen
illusorische Terminvorgaben gepaart mit sprunghaften
Richtungsänderungen hinsichtlich des Produkt-Leistungsspektrums zu
vergleichbaren Situationen. Charakteristisch für solche
Stresssituationen ist, dass man sich nicht in der Lage sieht, eine
Arbeit zu Ende zu bringen, da zwischendrin eine andere wichtigere
Arbeit eingeschoben werde muss, die womöglich ihrerseits wieder
durch eine noch wichtigere Arbeit unterbrochen werden muss.
Troubleshooting in einer Krise, meist unmittelbar nach dem Launch eines
ungenügend getesteten Produkts, ist sehr typisch für solche
Sympthome. Es gibt einige Leute, die kein Problem damit haben, Ereignis
gesteuert zu leben. In Management-Positionen ist dieser Arbeitsrhythmus
sogar eher der Normalfall, und nur Leute, die gerne so leben, sind auch
in dem Job gut aufgehoben.
Jeder Mensch hat m.E. seinen eigenen Arbeitsrhythmus. Der eine braucht
etwas länger, tut dagegen Dinge gründlich und nur einmal, ein
anderer erprobt in mehreren schnellen Anläufen verschiedene
Lösungen und ist auch nicht schneller. Wie auch immer der
persönliche Rhythmus ist, man sollte zunächst versuchen, ihn
heraus zu bekommen und dann, ihn auch zu leben. Um dies tun zu
können, muss man sowohl den richtigen Beruf als auch die richtige
Arbeitsumgebung wählen. Soweit möglich kann man auch die
vorhandene Umgebung formen. Für eine Sekretärin ist es
allerdings nicht immer einfach, den eigenen Chef zu erziehen, und
für einen Business Analysten auch nicht, seine Fachanwender oder
seinen Projektleiter zu bändigen.
Ich kann Ihnen leider nur wenige Tipps geben, wie Sie Ihren eigenen
Arbeitsrhythmus durchsetzen können. Wahrscheinlich ist ein
generelles Kochrezept auch gar nicht möglich. Ich selbst bin in
meiner Eigenschaft als Freiberufler relativ privilegiert, denn meine
Verträge laufen i.d.R. nur wenige Monate. Ist ein Umfeld zu
unerträglich, dann kann ich es recht leicht wechseln. Zudem
würde mich jeder Auftraggeber sehr schnell vor die Tür
setzen, wenn ich keine für ihn akzeptable Ergebnisse liefere, er
hat also so wie ich ein sehr vitales Interesse, dass ich meine Arbeit
möglichst gut machen kann. Zwar sollte man dies auch bei fest
Angestellten meinen, m.E. verwischt jedoch die Sicht auf die
Performance eines Angestellten im Laufe jahrelanger
Betriebszugehörigkeit.
Jeder Versuch, etwas an seiner Umgebung zu ändern, kann nur
über erhöhte Effizienz und Kostenersparnis für den
Arbeitgeber bzw. Auftraggeber durchgesetzt werden. Sollten Sie also
bemerken, dass Sie sich durch den aufgezwungenen Arbeitsrhythmus nicht
mehr wohl fühlen, dann muss zunächst nachgeweisen werden,
dass ein anderer Rhythmus auch zu mehr Effizienz führt. Der Weg
dorthin kann so ablaufen:
- Führen Sie ein möglichst Minuten genaues
Arbeitsprotokoll (auf 15 Minuten genau sollten Sie es ohnehin tun,
brechen Sie es auf wenigstens 5 Minuten herunter)
- Führen Sie dazu ein Störungsprotokoll, sofern die
Störungen nicht aus dem Arbeitsprotokoll hervor gehen.
- Werten Sie nach einiger Zeit die Protokolle aus.
- Finden Sie vergleichbare Arbeiten und belegen Sie, dass diesebe
Tätigkeit regelmäßig effektiver (=billiger) von Ihnen
erledigt wird, wenn Sie Ihrem eigenen Rhythmus folgen können, als
wenn dies nicht der Fall ist.
- Finden Sie die Ursachen heraus, die dazu führen, dass Sie
nicht Ihrem eigenen Rhythmus folgen können, und suchen Sie Wege,
diese Ursachen abzustellen. (Bei einer vollkommen chaotischen Umgebung
kann dies u.U. nur durch einen Jobwechsel erreicht werden, aber oft
reicht es, wenn Sie sich mit den Verursachern einigen, dass Sie Ihnen
ToDo-Listen erarbeiten)
- Helfen Sie Ihren Kollegen, ihre Arbeit zu organisieren.
- Dulden Sie keine Schlamperei. Sie tun weder sich noch Ihrem
Unternehmen einen Gefallen, wenn Sie die Fehlleistungen anderer Leute
decken und zu kompensieren versuchen. Anstatt diesen Leuten zu helfen,
machen Sie nur deren Arbeit.
- Fordern Sie eine klare mittelfristige Planung und Priorisierung
(= einige Tage oder Wochen) Ihrer Aufgaben, sodass eine sequentielle
Abarbeitung der Normalfall wird. Machen Sie nötigenfalls immer
wieder darauf aufmerksam, wenn sich Ihr Vorgesetzter nicht mehr an
seine eigene Priorisierung hält, und machen Sie dazu einen
konstruktiven Vorschlag.
- Eile mit Weile! Gewöhnen Sie sich an, immer dann, wenn es
besonders chaotisch wird, eine kurze Pause einzulegen (z.B. eine Tasse
Kaffee holen), um über die aktuelle Situation kurz zu
reflektieren. Wählen Sie dann den besten Weg, um brauchbare
Ergebnisse zu erzielen.
- Sein Sie nicht ungeduldig.
- Versuchen Sie, ausgleichend und integrierend in Ihrer Umgebung zu
wirken. Üben Sie keinen (unnötigen) Druck aus und stellen Sie
klar, wenn Sie sich unnötig unter Druck gesetzt fühlen.
- Versuchen Sie, sich selbst, Ihrem Chef und Ihren Kollegen das
Leben möglichst leicht zu machen, indem Sie weder für
emotionale Gewitter sorgen, noch halbfertige Resultate abliefern.
- Am wichtigsten: Vergessen Sie nicht, dass Sie und Ihre Kollegen,
Vorgesetzten und Untergebenen auch nur Menschen sind und als solche
behandelt werden wollen.
home - top
- Kontakt - letzter Update
24.5.2004 - © Karl Scharbert