Project managers are trained not to panic.
Deadlines move. Schedules slip. Customers change their minds.
And when the impossible finally collides with the inevitable, an experienced project manager reaches for the most comforting sentence in the English language:
"We need a little more time."
But on Friday, September 15, 2000, there would be no more time.
At precisely seven o'clock that evening, Sydney time, the Opening Ceremony of the Olympic Games would begin.
Not at 7:05.
Not when the computers were ready.
Not after somebody rebooted a server.
Seven. O'clock.
That deadline was not written on a project schedule.
It was being carried toward us in the form of a flame.
Inside Stadium Australia, some of the greatest women in Australian Olympic history would pass that flame from one generation to the next: Betty Cuthbert, pushed in her wheelchair by Raelene Boyle; then Dawn Fraser; Shirley Strickland de la Hunty; Shane Gould; and Debbie Flintoff-King.
Finally, Debbie would place the torch into the hand of Cathy Freeman.
Cathy Freeman - an Aboriginal Australian woman carrying far more than an Olympic flame - would climb a short flight of stairs and walk across submerged steps into the center of a shallow circular pool.
She would lower the torch to the water.
A perfect ring of fire would ignite around her.
The Olympic cauldron would rise above the stadium, carrying the flame into the night sky.
And the Games of the XXVII Olympiad would begin.
That is what the world saw.
What the world never saw was an email that had arrived eighteen months earlier.
It said there was no possibility - none - that IBM would be ready in time.
IBM had supported the Olympic movement for nearly forty years. Sydney would be our final Games.
We were not working under an ordinary customer contract. IBM contributed enormous amounts of technology, services, equipment, and people in exchange for Olympic marketing rights.
From where I sat, that meant we were spending a fortune for the privilege of being blamed in front of the entire world.
Beneath the pageantry was a vast, invisible nervous system: computers, networks, databases, event systems, results systems, press systems, and communications technology.
The technology did not need to survive for ten years. It needed to survive for the Games.
Long-term maintainability was not the central issue.
But during those few weeks, reliability was absolute.
If the electronic system that sent results to the press failed, there could be a human workaround. Somebody could print a copy and run it to the reporters.
The interface was a person wearing sneakers.
But human beings could not carry millions of accurate results around the world fast enough. The major systems had to work.
And IBM's name was attached to all of it.
Eighteen months before the ceremony, a loyal IBM manager did something both courageous and dangerous: he went outside the normal chain of command and wrote directly to IBM Chairman Lou Gerstner.
His warning was stark.
The technology program was in jeopardy.
The technical problems were serious.
The management problems were worse.
And in his judgment, we were not going to be ready for Opening Night.
At that moment, Carol and I were vacationing in Hawai'i. We were supposed to fly home in two days.
Then I received a call from IBM Global Services headquarters.
The chairman had received the warning. Headquarters was assembling a review team. They wanted me on it.
My first reaction was excitement.
This was exactly the kind of assignment I had spent years preparing for.
Then the second reaction arrived.
This was the Olympic Games.
If we were wrong, if we missed something, or if the technology failed while the entire world was watching, this would not become another challenging entry on my resume.
It might become the final entry.
So I flew from Honolulu to Washington Dulles, then continued to Westchester County, New York. I did not even stop at home.
By the time I reached New York, I had crossed six time zones and had almost no idea what day it was.
That turned out to be excellent preparation for reviewing an international project schedule.
We assembled first at IBM's facility in Somers, New York.
The headquarters executive led the overall review team. My responsibility was the project plans.
My IBM title was Quality Assurance Executive for the Financial Services Sector. I had built a team responsible for overseeing a portfolio of contracts valued at more than nine billion dollars.
I was not selected because I knew more than everyone else about Olympic timing equipment. I did not.
I was selected because I knew how to examine a complex project plan until it stopped telling management what management wanted to hear - and started telling us the truth.
We had complete authority to go wherever the evidence led us.
The work was spread across three principal locations: Madrid, where the IBM Games organization was headquartered; Tokyo; and a test location outside Sydney, where the different pieces were brought together.
Before we traveled, we told each location what documents to send us: project schedules, milestone reports, testing information, dependencies, staffing plans, risk reports, and whatever else was being used to tell senior management that the program was under control.
Then we remained together in a conference-room setting, studying those documents, comparing them, and sending questions across time zones.
When Madrid was waking up, Tokyo was finishing its day. When Sydney answered, New York was trying to remember whether it was breakfast or dinner.
Two weeks later, we landed in Madrid.
The IBM Games operation occupied an enormous warehouse. Inside were miniature versions of the technology used at the sporting events: timing systems, computers, lights and sensors, even a small kayak moving through a model white-water course.
It looked like the world's most expensive toy store.
Except every toy had a deadline, and the deadline was being televised.
Because we had studied the documents before arriving, we already knew what we needed to ask.
On the first morning, the full team met with the local executives and the people responsible for the work. Then we divided up. Sometimes one reviewer conducted an interview; sometimes two of us went together.
Around midday, our review team met privately.
What had we learned?
What did not fit?
What new documents did we need?
Which answer sounded reassuring - but was not supported by evidence?
At the end of each week, we prepared preliminary findings and recommendations. Before reporting them to senior management, we showed them to the executives at that location.
No ambushes. No surprises. If we had misunderstood something, they had an opportunity to show us the evidence.
Then we repeated the process in Tokyo.
And then in Sydney.
The alarming email to the chairman had overstated the extent of the danger.
Not every location was failing. Not every workstream was in trouble. The Olympic Games were not eighteen months away from certain disaster.
Our responsibility was not to prove the email right.
Our responsibility was to find the truth.
And the truth was serious enough.
The greatest technical danger was integration: connecting the computers behind the scenes with the technology operating at the sporting events.
A timing device could work perfectly by itself. A results computer could work perfectly by itself. A press system could work perfectly by itself.
But the Olympic Games did not happen "by itself."
A finish time had to be captured, associated with the correct athlete and event, validated, moved into the results system, and distributed accurately to officials, broadcasters, and journalists.
The separate pieces did not merely have to function.
They had to function together.
The management danger was even more fundamental.
The project plans could not tell management exactly how much work had actually been completed. They also could not produce a credible estimate to complete - an honest forecast of how much time, effort, and cost remained.
That is not an exotic Olympic problem. It happens on projects of every size.
A schedule can contain thousands of lines, bright colors, percentages, milestones, and impressive charts - and still be unable to answer the only questions that matter:
Where are we?
What remains?
When will we finish?
And what will it take to get there?
Here is how you expose that kind of problem.
You select a workstream and look at what the project plan says has been completed.
Then you leave the conference room.
You go to the technical people actually doing the work, and you physically verify what has been built, connected, tested, and demonstrated.
Then you compare reality with the schedule.
One mismatch might be a mistake.
But when you repeat the test across four or five workstreams and the status reports repeatedly fail to match the work on the ground, you do not have a clerical problem.
You have a management problem.
And that is what we found.
Several project managers were not capable of managing work this complex. Worse, they were not telling the managers above them the full truth.
Bad news was being softened as it moved upward.
But bad news does not become good news simply because it reaches a higher floor.
We also had to be careful about how we wrote our findings.
You do not produce a recovery by humiliating the people who must perform it.
We did not write, "This person has no idea what he is doing."
We wrote, "Project management capability should be strengthened."
Same diagnosis. Better blood pressure.
The real fix was not changing the color of a status report.
The plans had to be rebuilt.
And they had to be rebuilt with the technical people who were actually performing the work.
Together, the project managers and technical teams identified what had genuinely been completed, what remained, which components depended upon other components, what still had to be integrated and tested, who owned each task, and how much time and effort would be required to finish.
For the first time, senior program management could receive information that described the program as it actually existed - not as everyone hoped it existed.
We consolidated the findings from Madrid, Tokyo, and Sydney into one set of recommendations and presented them to IBM's top management.
Then our authority changed.
We were no longer simply reviewing the work.
We were responsible for overseeing the recovery.
Every week, we examined the critical parts of the project plans. We compared reported progress with evidence. We watched the integration work, the remaining tasks, the testing, and the estimates to complete.
And we continued doing that until the program was stable, credible, and on track - almost until the Games themselves began.
On September 15, 2000, I was not sitting in Stadium Australia.
There was no special seat bearing my name. No camera showed our review team. No announcer explained what had happened eighteen months earlier.
I was back home, watching the ceremony on television like everyone else.
At seven o'clock Sydney time, the ceremony began.
The computers worked.
The networks worked.
The results and information systems worked.
And when Cathy Freeman touched her torch to the water, the circle of fire ignited around her.
The cauldron began to rise - and then, famously, it stopped for several minutes.
Somewhere, another project manager aged ten years.
That particular problem was not ours.
The cauldron continued upward. The flame reached its place above the stadium. The Games began.
And over the days that followed, the technology did what it was supposed to do.
There were no headlines announcing that a dangerous integration problem had been corrected.
No reporter interrupted a broadcast to say, "We have breaking news: the estimate to complete is finally credible."
No athlete stood on the medal platform and thanked the people who had rebuilt a project schedule.
Nobody outside IBM knew how the warning had reached the chairman, why a review team had flown around the world, what we had found, or what hundreds of people had done to put the program back on solid ground.
That was the victory.
The failure never happened.
That experience changed the way I approached every troubled project that followed.
I learned not to confuse a project plan with reality.
I learned that a green status light is merely a colored light until somebody verifies the work beneath it.
I learned to go to the people performing the work, ask what has actually been completed, examine the evidence, and build an honest estimate of what remains.
And I learned that the earlier someone tells the truth, the less heroic the rescue has to become.
That is why I tell this story.
Today, when I watch an NFL game, an Olympic event, a space launch, or any enormous live broadcast, I see what everyone else sees: the athletes, the announcers, the graphics, the clock, the score.
But I also wonder about what I cannot see.
Somewhere behind that effortless performance are technicians, engineers, operators, project managers, and exhausted people in windowless conference rooms, checking the work one more time.
If they do their jobs perfectly, we will never know their names.
We will never know what almost failed.
We will never know what they prevented.
The world saw the flags.
The world saw the fireworks.
The world saw Cathy Freeman standing inside a circle of fire.
What the world never saw were the people who had walked into another kind of fire eighteen months earlier - and made certain that, at seven o'clock, the Games could begin.