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:
  1. 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?
  2. 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?
  3. 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ß?
  4. 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:
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:
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:
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:
  1. Aufgaben und Aktivitäten erledigt, die geplant waren.
  2. Aufgaben und Aktivitäten erledigt, die nicht geplant waren.
  3. Geplante Aktivitäten für nächste Woche.
  4. 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:
home - top - Kontakt - letzter Update 24.5.2004 - © Karl Scharbert