Читать книгу Projekt Phoenix - Kevin Behr - Страница 18

In einem der vielen endlosen Phoenix-Status-Meetings stelle ich fest, dass die Entwickler noch viel weiter hinterherhängen, als wir sowieso schon befürchtet haben. Wie Wes vorausgesagt hat: Mehr und mehr Punkte werden auf das nächste Release verschoben – einschließlich fast aller Tests.

Wir werden also diejenigen sein, die die Probleme feststellen werden, wenn sie uns im Produktivbetrieb um die Ohren fliegen, und nicht die Quality-Assurance-(QA-)Abteilung. Super.

Während einer Meeting-Pause werfe ich einen Blick auf mein Handy und sehe eine E-Mail von Patty. Sie will sich mit mir wegen der Ressourcen treffen und verspricht einige Überraschungen.

Ich öffne das angehängte Spreadsheet und sehe eine vielversprechende Menge an Details, kann aber auf meinem winzigen Bildschirm nichts erkennen. Also antworte ich Patty, dass ich schon auf dem Weg bin und sie doch Wes dazubitten soll.

Als ich ankomme, bin ich überrascht, dass Wes schon einen Projektor aufgebaut hat, der ein Spreadsheet an die Wand wirft. Ich freue mich, dass wir uns endlich treffen können, um die Situation zu analysieren, statt immer nur tagtäglich Feuer zu löschen.

Ich schnappe mir einen Stuhl. »Okay, was könnt ihr mir erzählen?«

Wes beginnt: »Patty hat das alles super zusammengestellt. Was wir herausgefunden haben, ist – nun ja, interessant.«

Patty erklärt: »Wir haben Gespräche geführt, Daten eingesammelt und dann unsere Analyse durchgeführt. Bisher haben wir die Ergebnisse nur für unsere wichtigsten Ressourcen. Aber wir sehen schon einige unerfreuliche Dinge.«

Sie zeigt auf eine Zeile im Spreadsheet. »Wir haben einen Haufen Projekte. Kirsten sagt, sie verwaltet offiziell etwa 35 größere Businessprojekte, bei denen wir auf die eine oder andere Art und Weise beteiligt sind. Innerhalb von IT Operations haben wir schon über 70 Projekte erfasst, aber die Zahl wächst mit jeder Person weiter, mit der wir uns unterhalten.«

»Moment«, sage ich erschrocken und setze mich in meinem Stuhl gerade auf. »Wir haben 150 Mitarbeiter in IT Operations, oder? Wenn ihr schon über 105 Projekte gefunden habt, sind das 1,5 Personen pro Projekt. Erscheint euch das nicht zu viel?« Wes antwortet: »Natürlich. Und wir wissen, dass da noch mehr Projekte hinzukommen werden. Am Ende reden wir vermutlich über eine Person pro Projekt. Das ist Wahnsinn.«

Ich frage: »Wie groß sind diese internen Projekte?«

Wes wechselt auf einen anderen Tab und zeigt die Liste der erfassten Projekte zusammen mit der Zahl der geschätzten Mann-Wochen. »E-Mail-Server zusammenfassen und aktualisieren«, »35 Instanzen von Oracle-Datenbanken aktualisieren«, »Lemming-Datenbank-Server installieren«, »Wichtigste Businessanwendungen virtualisieren und migrieren« und so weiter.

Ich stöhne. Einige Projekte sind zwar klein, aber bei den meisten scheint es um größere Aktionen zu gehen – geschätzt drei Mann-Jahre und mehr.

Als Patty meinen Gesichtsausdruck sieht, sagt sie: »So habe ich auch reagiert. Wir haben es mit sehr vielen Projekten zu tun. Schauen wir uns jetzt mal an, wie viele Ressourcen wir haben. Das ist ein bisschen schwieriger, da wir einem Projekt nicht irgendwelche Leute zuweisen können.«

Sie fährt fort: »Wir haben uns angeschaut, wer welchem Projekt zugeordnet ist und wie es mit deren anderen Verpflichtungen und der Verfügbarkeit aussieht. Das ist unser Ergebnis.«

Als Wes zu einem weiteren Spreadsheet-Tab wechselt, sinkt mir das Herz in die Hose.

»Bitter, oder?«, sagt Wes. »Die meisten unserer Ressourcen sind mit Phoenix beschäftigt. Schau dir aber die nächste Zeile an: Compliance ist das zweitgrößte Projekt. Und selbst wenn wir nur an der Compliance arbeiteten, würde das die meisten unserer wichtigen Ressourcen für ein ganzes Jahr beschäftigen! Und natürlich gehört dort Brent dazu.«

Skeptisch sage ich: »Ihr macht Witze, oder? Wenn wir all unsere Projekte auf Eis legen und nur die Audit-Ergebnisse umsetzen würden, wären unsere wichtigsten Leute für ein ganzes Jahr gebunden?«

»Jepp«, sagt Patty nickend. »Schwer zu glauben, aber es zeigt, wie viel Arbeit in den Audit-Ergebnissen steckt.«

Ich starre sprachlos auf den Tisch.

Wenn mir jemand diese Daten während meines ersten Gesprächs mit Steve gezeigt hätte, wäre ich schreiend aus dem Raum gerannt. Es ist noch nicht zu spät, denke ich grinsend, als ich mir dies bildlich vorstelle.

Mit der mir mittlerweile angewöhnten Ruhe sage ich: »Okay, Wissen ist immer besser als Nichtwissen. Erzählt weiter.«

Wes schaut wieder auf das Spreadsheet. »Das drittgrößte Thema ist die Arbeit an Problemen und das Beheben von Pannen. Aktuell verbringen unsere Mitarbeiten etwa 75 Prozent ihrer Zeit damit. Und weil es dabei häufig um kritische Businesssysteme geht, müssen solche Zwischenfälle auch immer der Arbeit an anderen Dingen vorgezogen werden – einschließlich Phoenix und dem Abarbeiten der Audit-Ergebnisse.

Wusstest du übrigens, dass wir gestern, als wir uns mit Brent unterhielten, das Gespräch zwei Mal verschoben haben, weil er bei kritischen Problemen eingreifen musste? Wir haben ihn also bei seiner Arbeit für Phoenix unterbrochen, nur um selbst durch Ausfälle unterbrochen zu werden!«, sagt er lachend.

Ich beginne ebenfalls zu lachen, höre aber abrupt auf. »Moment. Welchen Ausfall? Warum habe ich davon nichts gehört? Wir können unsere Abteilung so nicht leiten!«

»Ach, mal wieder ein SAN-Problem, aber nichts Kritisches«, antwortet Wes. »Vor ein paar Monaten ist ein Laufwerk ausgefallen, sodass das SAN ohne Redundanz lief. Als ein weiteres Laufwerk kaputtging, wurde das gesamte Volume heruntergefahren. Brent musste dabei helfen, ein paar der Datenbanken wiederherzustellen, als wir das SAN wieder zum Laufen brachten.«

Verärgert rufe ich: »Verdammt, Wes. Das hätte man doch verhindern können! Schnapp dir einen deiner Neueinsteiger und lass ihn jeden Tag die Logs nach Laufwerkfehlern durchsuchen. Vielleicht wirft er gleichzeitig direkt einen Blick auf die Laufwerke und schaut, ob alle noch schön blinken. Das heißt nicht umsonst ›Präventive Wartung‹! Wir brauchen Brent bei Phoenix, nicht bei so mickerigem Scheiß wie dem!«

Wes sagt verteidigend: »Hey, es ist schon ein wenig komplizierter, als du denkst. Wir haben die Bestellung der Ersatzlaufwerke eingereicht, aber sie steckt seit Wochen in der Beschaffungsabteilung fest. Wir mussten schließlich einen unserer Lieferanten anbetteln, dass er uns die Laufwerke sozusagen auf Kredit gibt. Das war nicht unser Fehler.«

Ich verliere die Geduld. »Wes, hör mir zu: ES INTERESSIERT MICH NICHT! Das Beschaffungswesen ist mir egal. Mir ist auch egal, wie lieb ihr zum Lieferanten sein musstet. Ich will, dass ihr eure Arbeit erledigt. Sorg dafür, dass das nicht wieder passiert!«

Ich atme tief durch. Mein Frust kommt nicht von dem defekten Laufwerk, sondern weil wir uns nie auf die Dinge konzentrieren können, die für die Firma am wichtigsten sind.

»Lasst uns das jetzt nicht weiter vertiefen«, sage ich zu Wes. »Aber das mit der täglichen Kontrolle des SAN meine ich ernst. Setze bitte nächste Woche ein Meeting auf, bei dem du, Patty und ich uns den Grund für diese Ausfälle anschauen. Wir müssen sehen, wie wir diese Feuerwehrarbeiten so weit reduzieren, dass wir uns um die eigentliche Projektarbeit kümmern können. Wenn Phoenix nicht läuft, ist die ganze Firma gefährdet.«

»Ja, das habe ich verstanden. Ich werde versuchen, das noch vor dem Phoenix-Roll-out auf die Reihe zu bekommen«, sagt Wes mürrisch. »Und das mit der SAN-Kontrolle kläre ich heute Nachmittag.« »Gut, zurück zum Spreadsheet«, sage ich.

Patty beobachtet uns verdrießlich. »Du hast recht. Das zog sich durch alle Gespräche wie ein roter Faden. Keiner schafft es, in Ruhe an seinen Projekten zu arbeiten. Und selbst wenn sie Zeit haben, hadern sie damit, all ihre Verpflichtungen richtig zu priorisieren. Die Businessleute bitten ja andauernd unsere Leute, irgendetwas für sie zu erledigen. Vor allem das Marketing.«

»Sarah?«, frage ich.

»Sicher, aber nicht nur sie«, antwortet Patty. »So gut wie jeder Manager in dieser Firma schaut mehr oder weniger häufig bei seinem Lieblings-IT-Mitarbeiter vorbei – entweder um ihn um einen Gefallen zu bitten oder um Druck auszuüben, damit etwas erledigt wird.«

»Wie können wir das denn ändern, und was brauchen wir, damit all diese Projekte ordentlich abgearbeitet werden?«, frage ich. »Worum sollten wir Steve bitten?«

Wes scrollt in seinem Spreadsheet nach unten. »Ausgehend von den Zahlen, die wir bisher haben, werden wir wohl sieben neue Mitarbeiter brauchen: drei Datenbankadministratoren, zwei Servertechniker, einen Netzwerktechniker und einen Virtualisierungsspezialisten. Dir ist natürlich klar, dass wir diese Leute erst einmal finden müssen und dass es dann sechs bis zwölf Monate dauert, bis sie voll produktiv eingesetzt werden können.«

Natürlich. Ich wusste, dass neue Mitarbeiter nicht sofort voll produktiv sind. Aber trotzdem ist es entmutigend, wenn Wes betont, dass echte Hilfe erst in einiger Zeit zu erwarten ist – selbst wenn Steve die neuen Positionen genehmigt.

Als ich später zu unserem zweiten CAB-Meeting gehe, bin ich hoffnungsfroh. Wenn wir unseren alten Change-Prozess wieder zum Leben erwecken können, sollten wir dazu in der Lage sein, eines der größten Audit-Probleme schnell zu lösen, und gleichzeitig auch selbst etwas davon haben.

Ich bin zudem begeistert davon, wie gut Patty und Wes zusammenarbeiten.

Als ich mich dem Besprechungsraum nähere, höre ich laute Stimmen.

»... und dann hat Patty ihn dafür gefeuert, dass er seinen Job gemacht hat. Er war einer unserer besten Netzwerktechniker. Du hattest das nicht zu entscheiden!«

Kein Irrtum möglich. Da tobt sich Wes aus. Dann höre ich, wie Patty hitzig antwortet: »Was? Du hast die Kündigung doch unterschrieben! Warum ist das jetzt plötzlich meine Schuld?«

Es wäre ja auch zu schön gewesen.

Ich höre John sagen: »Das war der richtige Schritt. Wir haben jetzt seit drei Jahren bei den Audits die gleichen Probleme mit dem Change-Management. Das landet dieses Mal beim Audit-Komitee. Und beim nächsten Mal ist es vermutlich nicht nur ein Techniker, der gefeuert wird, wenn Sie mich fragen.«

Was? Wer hat John zu diesem Meeting eingeladen?

Bevor John alles noch schlimmer machen kann, trete ich schnell durch die Tür und sage fröhlich: »Hallo, alle zusammen! Und? Können wir uns ein paar Changes anschauen?«

14 Personen schauen mich an. Die meisten technischen Leiter der verschiedenen Gruppen sitzen am Tisch. Wes steht vor Wut schäumend hinter seinem Stuhl, während Patty vor dem Beamer steht und die Arme verschränkt hat.

John sitzt weiter hinten im Raum, seine allgegenwärtige Mappe geöffnet und ganz offensichtlich eigentlich unerwünscht.

Mit beiden Händen setze ich meinen antiken Laptop ab. Er landet etwas hart auf dem Tisch, und der Akku löst sich, weil das Tape nicht mehr länger klebt. Dann höre ich das kratzende Geräusch einer herunterfahrenden Festplatte.

Wes’ verärgerter Gesichtsausdruck ist sofort verschwunden. »Wow, Boss, nette Kiste. Was ist das? Ein Kaypro II? So etwas habe ich ja seit 30 Jahren nicht mehr gesehen. Falls du ein 8-Inch-Diskettenlaufwerk benötigen solltest, um CP/M auf dem Rechner zu starten – ich habe noch eines auf dem Dachboden liegen.«

Zwei der Entwickler kichern ebenfalls. Ich lächle Wes kurz an und bin dankbar für die Ablenkung.

Ich bleibe stehen und sage zu allen: »Ich will euch erklären, warum ich alle herbeordert habe. Angesichts der Dringlichkeit von Phoenix könnt ihr euren Hintern darauf verwetten, dass ich keine Zeit verschwenden würde, wenn es nicht so wichtig wäre.«

Ich fahre fort: »Erstens dürfen solche Aktionen wie die vom Dienstag, die zum SAN-Ausfall und zum Payroll-Problem geführt haben, so nicht wieder vorkommen. Was als mittelschwerer Payroll-Zwischenfall begann, führte zu einer massiven, selbst gemachten SAN-Katastrophe. Und warum? Weil wir nicht miteinander darüber reden, was für Änderungen wir planen oder umsetzen. Das können wir nicht weiter hinnehmen.

Zweitens hat John recht. Wir haben gestern den ganzen Vormittag damit verbracht, mit unseren Auditoren einen Haufen Mängel zu diskutieren, die sie gefunden haben«, fahre ich fort. »Dick Landry geht der Hintern schon auf Grundeis, weil das den Finanzbericht für dieses Quartal beeinflussen könnte. Wir müssen unsere Änderungen besser im Griff haben, und als Manager und technische Leiter müssen wir uns überlegen, wie wir einen vernünftigen Prozess aufsetzen können, der selbst verschuldete Pannen vermeidet und uns die Auditoren vom Hals hält, gleichzeitig aber dafür sorgt, dass wir unsere Arbeit erledigt bekommen. Wir werden diesen Raum nicht eher verlassen, bevor wir nicht einen Plan ausgearbeitet haben. Verstanden?« Zufrieden sehe ich, dass alle angemessen eingeschüchtert sind, und eröffne die Diskussion. »Was hält uns also davon ab, das zu erreichen?«

Einer der technischen Leiter sagt schnell: »Ich werde anfangen. Dieses Change-Management-Tool ist unbenutzbar. Es gibt Millionen Pflichtfelder, und in den meisten Fällen sind die Auswahlboxen für ›Betroffene Anwendungen‹ nicht passend gefüllt. Darum habe ich es aufgegeben, überhaupt Change Requests einzutragen.«

Ein anderer Leiter ruft: »Das stimmt. Wenn ich mich an Pattys Regeln halte, muss ich Hunderte Servernamen per Hand in eines der Textfelder eintragen. Und meist ist das Feld gar nicht groß genug! 100 Servernamen sollen in ein Textfeld mit 64 Zeichen passen? Welcher Idiot hat das denn gebaut?«

Weiteres, unerfreuliches Lachen.

Patty ist knallrot geworden. Sie ruft: »Wir müssen Auswahlboxen nutzen, damit wir die Datenintegrität wahren können! Und ich würde die Liste mit den Anwendungen liebend gerne aktuell halten, aber ich habe keine Ressourcen dafür. Wer hält denn den Anwendungskatalog und die Change-Management-Datenbank up to date? Meint ihr, das geschieht irgendwie per Magie?«

»Es geht nicht nur um das Tool, Patty. Der ganze Prozess ist kaputt«, erklärt Wes. »Wenn meine Leute Change Requests eintragen, müssen sie ewig warten, bis die genehmigt sind, geschweige denn eingeplant werden. Uns sitzt das Business die ganze Zeit im Nacken, dass wir unseren Kram erledigt bekommen. Wir können nicht darauf warten, dass du unsere Einträge bis ins Detail analysierst und dich dann beschwerst, dass nicht alle Felder korrekt ausgefüllt sind.«

Patty meckert zurück: »Das ist Quatsch, und das weißt du. Deine Leute halten sich nie an die Regeln. Ihr markiert doch auch alle Change Requests als ›dringend‹ oder als ›Notfalländerung‹. Das Feld ist nur für echte Notfälle gedacht!« Wes erwidert: »Das müssen wir doch tun, denn nur so schaut sich dein Team die Einträge überhaupt an! Wir können nicht drei Wochen darauf warten, eine Erlaubnis zu bekommen.«

Einer der leitenden Techniker schlägt vor: »Vielleicht könnten wir noch ein weiteres Feld aufnehmen mit dem Namen ›Extrem dringend‹?«

Ich warte, bis alle wieder zur Ruhe gekommen sind. Wenn wir so weitermachen, erreichen wir heute gar nichts mehr. Schließlich sage ich nach hektischem Nachdenken: »Wir machen zehn Minuten Pause.«

Als wir fortfahren, sage ich: »Wir beenden dieses Meeting nicht ohne eine Liste mit genehmigten und terminierten Änderungen, die wir in den nächsten 30 Tagen umsetzen.

Wie ihr sehen könnt, hat meine Assistentin einen Stapel leerer Karteikarten mitgebracht. Ich möchte, dass jede Gruppe jede geplante Änderung aufschreibt – eine pro Karte. Dabei sollen drei Informationen darauf stehen: wer die Änderung plant, welches System geändert wird sowie eine kurze Zusammenfassung in einem Satz.

Ich habe einen Kalender auf das Whiteboard gemalt, auf dem wir die genehmigten Änderungen schließlich je nach Termin anpinnen werden«, fahre ich fort. »Das sind die Regeln. Kurz und einfach.«

Wes schnappt sich einen Stapel Karten und schaut sie misstrauisch an. »Echt jetzt? Karteikarten, heutzutage? Warum nehmen wir nicht gleich deinen Laptop, der scheint ja noch älter zu sein als diese Karten?«

Alle lachen – mit Ausnahme von Patty. Sie sieht verärgert aus, ganz offensichtlich ist sie nicht begeistert über die Richtung, in die dieses Meeting läuft.

»Das ist so anders als jeder Change-Management-Prozess, den ich je zu Gesicht bekommen habe«, sagt John. »Aber ich werde meine Änderungen an die Tafel pinnen. Zum Beispiel die anstehenden Firewall-Updates und Änderungen am Monitoring, die für die nächsten Tage geplant sind.«

Überraschenderweise inspiriert Johns Bereitschaft zur Teilnahme auch andere, und sie fangen an, fleißig ihre Änderungen auf die Karten zu schreiben.

Schließlich sagt Wes: »Okay, versuchen wir es. Alles ist besser als dieses blöde Change-Management-Tool.«

Einer der Techniker hält eine Handvoll Karten hoch. »Ich habe hier alle Datenbankänderungen aufgeschrieben, die wir machen wollen.«

Als ich zustimmend nicke, liest er eine der Karten vor: »Vom Hersteller empfohlenes Wartungsskript für die Datenbank auf dem Octave-Server XZ577 ausführen, um Filial-POS-Performanceprobleme zu beheben. Betrifft die Order Entry-Datenbank und die Anwendungen. Sollte am nächsten Freitagabend um 20:30 ausgeführt werden.«

Ich nicke und bin erfreut über die Klarheit der vorgeschlagenen Änderung. Aber Wes sagt: »Das ist doch keine Änderung. Ihr führt doch nur ein Datenbankskript aus. Wenn du das Skript ändern würdest, könnten wir uns darüber unterhalten. Nächster Punkt.«

Aber der Techniker antwortet: »Nein, das ist definitiv eine Änderung. Es passt temporär ein paar Datenbankeinstellungen an, und wir wissen nicht, was für eine Auswirkung das auf die Produktion haben kann. Für mich ist das genauso riskant wie eine Änderung der Datenbankkonfiguration.«

Ist das eine Änderung oder nicht? Ich kann beide Seiten nachvollziehen.

Nach 30 Minuten Diskussion ist immer noch nicht klar, was wir unter einer »Änderung« verstehen.

Ist der Neustart eines Servers eine Änderung? Ja, weil wir nicht wollen, dass irgendjemand einfach so einen Server durchstartet, insbesondere wenn darauf ein kritischer Service läuft. Das Abschalten eines Servers? Ja, aus dem gleichen Grund.

Wie ist es mit dem Einschalten eines Servers? Nein – haben wir alle gedacht. Bis jemand das Beispiel brachte, in dem ein zweiter DHCP-Server eingeschaltet und damit das gesamte Firmennetzwerk für 24 Stunden lahmgelegt wurde.

Nach einer weiteren halben Stunde schreiben wir schließlich auf das White-board: »Eine ›Änderung‹ ist jede Aktivität, die physisch, logisch oder virtuell auf Anwendungen, Datenbanken, Betriebssysteme, Netzwerke oder Hardware wirkt und die bereitgestellte Services beeinflussen kann.«

Ich werfe einen Blick auf meine Uhr. Wir sind jetzt schon 90 Minuten hier und haben noch nicht einmal die erste Änderung genehmigt. Ich drängle jetzt ein wenig, aber am Ende des zweistündigen Meetings haben wir gerade einmal fünf Änderungen an das Whiteboard gepinnt.

Erstaunlicherweise scheint außer mir niemand frustriert zu sein. Jeder hat sich an der lebhaften Diskussion beteiligt, selbst Patty. Jeder denkt über die Risiken der vorgeschlagenen Änderungen nach, manchmal sogar mit dem Ergebnis, dass eine Änderung gar nicht notwendig ist.

Ermutigt sage ich: »Wir werden am Montag damit weitermachen. Lasst eure Karten so bald wie möglich Patty zukommen. Patty, wie können wir die Karten am besten durcharbeiten?«

Kurz angebunden sagt sie: »Ich werde später ein Körbchen dafür beschriften. Bis dahin stapelt sie einfach hier vorne auf dem Tisch.«

Als das Meeting aufgelöst wird, teilen mir beim Hinausgehen viele Leute mit: »Tolles Meeting« und »Ich wünschte, wir hätten mehr Zeit gehabt« oder »Ich freue mich auf Montag!«.

Nur Patty bleibt zurück, mit verschränkten Armen. »Wir haben viel Blut, Schweiß und Tränen in unsere alte Change-Management-Richtlinie gesteckt, und alle haben sie ignoriert. Warum glaubst du, dass es dieses Mal anders sein wird?«

Ich zucke mit den Schultern. »Keine Ahnung. Aber wir werden so lange Vorgehensweisen ausprobieren, bis wir ein funktionierendes System haben. Und ich werde sicherstellen, dass uns dabei jeder hilft. Es geht nicht nur darum, die Auditoren glücklich zu machen. Wir brauchen einen Weg, unsere Änderungen sicher zu planen, zu kommunizieren und umzusetzen. Ich garantiere dir, dass ich meinen Job nicht mehr lange haben werde, wenn wir unsere Arbeitsweise nicht bald ändern.«

Patty zeigt auf ihr Dokument mit der alten Richtlinie und sagt: »Wir sollten die ganze Arbeit nicht aus dem Fenster werfen. Wir haben Wochen damit verbracht, sie zu entwerfen, und Hunderttausende Dollar für Berater ausgegeben, die unsere Tools angepasst haben.«

Sie ist fast den Tränen nahe. Ich erinnere mich, wie lange sie versucht hat, diesen Prozess in der Firma umzusetzen.

»Ich weiß, dass in diesem Prozess viele gute Ideen und viel Arbeit stecken«, sage ich mitfühlend. »Aber seien wir ehrlich. Keiner folgt ihm, wie uns die Auditoren gerade erst wieder deutlich gemacht haben. Wir wissen zudem, dass die Leute das System missbraucht haben, um ihre Arbeit zu erledigen.«

Aufrichtig sage ich: »Wir fangen vielleicht neu an, aber wir brauchen deine Erfahrung und deine Kenntnisse, damit es funktioniert. Es ist immer noch dein Prozess, und ich weiß, dass er für den Erfolg unserer Firma unabdingbar ist.«

»Okay«, sagt sie seufzend. »Ich denke, ich sollte mir mehr Gedanken darum machen, dass unsere Firma überlebt, als darüber, ob wir unseren alten Prozess nutzen oder nicht.«

Ihr Gesichtsausdruck ändert sich. »Wie wäre es, wenn ich die Ergebnisse dieses Meetings und die neuen Anweisungen für das Einreichen von Change Requests aufschreibe?«

Später am Nachmittag bin ich zurück im Phoenix War Room, als mich Patty anruft. Ich gehe in den Flur. »Was gibt es?«

Sie klingt angespannt. »Wir haben ein Problem. Ich dachte, wir müssten nächste Woche 50 Änderungen oder so begutachten. Aber wir sind schon bei 243 eingereichten Änderungen. Ich bekomme E-Mails von Leuten, die mir für das Wochenende noch mehr Karten versprechen ... Ich glaube, wir werden bei über 400 Änderungen für nächste Woche landen!«

Oh nein. 400? Wie viele dieser 400 Änderungen sind hoch risikoreich, betreffen potenziell Phoenix, die Payroll-Anwendung oder Schlimmeres?

Ich erinnere mich plötzlich an meine Arbeit als Rangemaster bei den Marines. Als Rangemaster war ich für die Sicherheit aller Personen auf dem Schießstand verantwortlich. Ich habe eine albtraumhafte Vision eines Mobs von 400 unbeaufsichtigten Achtzehnjährigen, die von den Lastwagen springen, zum Schießstand rennen und johlend und grölend mit ihren Gewehren in die Luft feuern ...

»Ähm, zumindest folgen die Leute dem Prozess«, sage ich nervös kichernd.

Ich höre sie lachen. »Wie wollen wir die ganzen Change Requests am Montag genehmigen, wenn noch so viele eintrudeln? Sollen wir vielleicht weitere Änderungen verbieten, bis wir alle abgearbeitet haben?«

»Auf keinen Fall«, sage ich sofort. »Du treibst den Leuten ihre Begeisterung und ihre Unterstützung aus, wenn du ihnen das verbietest, was sie tun müssen. Ich glaube nicht, dass wir hier eine zweite Chance haben.

Verschicke eine E-Mail an alle, dass Änderungen für nächste Woche bis Montag eingereicht werden müssen. Die Änderungen, die am Montag laufen sollen, müssen nicht genehmigt werden, aber die für den Rest der Woche schon. Ohne Ausnahme.«

Ich höre, wie Patty anfängt zu tippen. »Okay, habe ich. Ich werde wohl ein paar Leute brauchen, die mir über das Wochenende dabei helfen, die ganzen Karten zu organisieren. Ehrlich, ich bin erstaunt, wie viele Änderungen es gibt.«

Das bin ich auch.

»Ausgezeichnet«, sage ich und lasse meine Bedenken unausgesprochen.