Lessons consultants can learn from constructing a skyscraper

1 March 2016

Steve Mainprize

Steve Mainprize

Consultant

Building a skyscraper is a very different type of project from those that we get involved with as consultants. However, as I discovered recently, lessons learnt  from the construction of the Citicorp Center can be applied to all kinds of projects.

Lately I’ve been doing a lot of driving, and have used the time to catch up with podcast episodes that I’d missed. One of my favourite podcasts is 99% Invisible, and I heard an episode about a Manhattan skyscraper that was built in 1977 to house the headquarters of Citibank. 

The developers of Citicorp Center had a particularly interesting obstacle to overcome. The site on which they wanted to build was occupied by St Peter’s Church, and the church wouldn’t sell unless the developers agreed to keep a place of worship on the plot, in the same position, but unconnected to the skyscraper. To work around this the architect and the engineer designed the new building be supported by five pillars, one central and four around the perimeter, at the midpoint of each side. This allowed the rebuilt St. Peter’s to nestle below the building. 

The base of the Citicorp Center. The rebuilt St. Peter’s Church is the sloping building at the bottom left, behind the flagpolesSource: https://en.wikipedia.org/wiki/Citigroup_Center#/media/File:Citigroup_center_from_ground.jpg (public domain)

Because of the unusual configuration of the skyscraper, William LeMessurier, the project’s structural engineer, had to come up with a clever way of managing the loads within the building. He devised a stacked series of inverted chevrons that directed the weight of the skyscraper down through the pillars. He also designed an electrically-powered mass damper to be placed at the top of the building. This machine would detect wind forces and automatically reconfigure itself to reduce how much the building swayed in the wind.

The building was completed in 1977, and the occupants moved in.

In summer 1978, the engineer’s office received a phone call from Diane Hartley, an engineering student. She had been asked, as part of her course, to study the Citicorp Center, and was puzzled by how the building was supposed to stand up to strong winds. 

In a normal skyscraper design, engineers will calculate the effect of winds as they strike the building’s faces head-on, as these usually carry the greatest risk. Winds that strike the building at 45 degrees – quartering winds, as they are known – usually aren’t as great a threat, as they kind of push around the building.

“Sorry, you're going to think I'm so stupid”, was the gist of the call, “but please explain to me so I can understand it, how does the design of the Citicorp Center take into account the effect of quartering winds? You see I’ve tried to do the calculations, and obviously I’ve done them wrong, because it looks to me like your building might fall down and obviously that can’t be right because you’re a huge engineering firm with top experts and years of experience, and I’m just starting to learn this stuff.”

Hartley was brushed off. But LeMessurier was uneasy and decided to go back and check his calculations. To his horror, LeMessurier worked out that Hartley was right. 

The stress on the connection joints was much greater than LeMessurier had originally calculated. Worse: during construction, the decision had been made to save costs by bolting the chevron joints together, rather than following the original plan to weld them together, and this made the joints weaker. Even worse: LeMessurier realised that, if there were particularly high winds, the power might fail, at which point the building’s electrically-powered mass damper would be useless.

He calculated that the 59-storey building, in the heart of downtown Manhattan, could be toppled by winds of 70mph.  These winds occurred in New York once every sixteen years or so. Put another way, every year there was a one-in-sixteen chance that the Citicorp Center would be blown over, taking a swathe of midtown Manhattan with it.

Lesson 1: Have as many people check your work as possible 

In application development, this is why we have peer reviews, and why we test. The Citicorp story illustrates that you can always use one more pair of eyes. Does that have to be a top expert? Sure, that’s helpful. But no matter how junior, anyone’s input can be valuable. A relatively naïve observation can actually be insightful, or having to explain something clearly to a novice may help you to question assumptions.

All skyscrapers are bespoke, partly because of their role as corporate status symbols and partly because each project has its own particular challenges. This means that you can’t just repeat the same project you did last time. You can say something similar for consultancy projects. Each time, we’re using our experience of previous projects, but we also have to find custom solutions to a number of unique problems.

Lesson 2: Complicated solutions are much more likely to break

Most consultants would say that finding custom solutions is much more fun than reusing stuff that we’ve built before. But we need to be careful we don’t take it too far, because the more custom solutions we build in, the more complicated things get. At the Citicorp Centre, the combination of multiple unusual technical solutions almost led to disaster. It’s worth noting that it wasn’t just the unusual nature of the component parts that caused the problem, it was all of them acting together and the inherent complexity that that implied.

At this point, LeMessurier decided to go to Citicorp and tell them everything.  LeMessurier gets a lot of credit for this, but it’s hard to see what else he could have done.  A plan was developed to fix the problem. The building was kept open, and the office staff continued to work there, unaware of the danger that the building would be in if a storm hit New York. (Just to add some urgency, it happened to be the start of the Atlantic’s hurricane season; fortunately no large storms reached New York that year.)

By early August 1978 a fix had been designed, and implementation began immediately. The city authorities, the New York Police Department and the Red Cross were informed, and an evacuation plan was drawn up, to be carried out if weather forecasters predicted the sort of strong winds that would put the building in danger. 

Lesson 3: When something goes wrong, tell the stakeholders

Things do go wrong. You can’t predict everything that’s going to happen, and sometimes your project will catch you out. Part of managing your project is recognising when things go wrong, and coming up with a way to put them right and get back on track. I can’t think of a situation where the client’s best interests are served by hiding problems from them. LeMessurier came out of it with his industry reputation enhanced rather than, as he expected, torn to shreds, because he’d raised the problem, and offered a solution, in time to avert disaster. 

The remedial work was completed in October 1978. Amazingly the near-disaster was kept out of the papers – the fact that the city’s press was on strike at the time certainly helped – until the New Yorker magazine uncovered and printed the story in 1997, nearly twenty years later.

Keeping the story secret is, I think, problematic. Important lessons were learned by LeMessurier and his practice, certainly, but wouldn’t it have been much more public-spirited to have shared the story and reduce the risk of the same problem arising somewhere else in the world?

So the final lesson, neatly enough, is about learning our lessons.

Lesson 4: Learn your lessons

We all like to congratulate ourselves about what’s gone well on a project, but we should also recognise that the things that didn’t go so well shouldn’t go unheeded. The setbacks we experience and the mistakes that we make are opportunities for continual improvement. Furthermore, we can make things better for each other – our teams, our organisations, our partners, our industries and our customers – by sharing what we’ve learned. Not to do so makes it almost certain that the same errors will one day be made again. 

Bluefin and SAP S/4HANA - welcome to the one horse race