Airbus Discovers Integration Matters

Monday's Wall Street Journal front page featured a back-story on the delivery of the first A380 to Singapore Airlines, "Airbus, Amid Turmoil, Revives Troubled Plane" (subscription required).

Today, as its A380 superjumbos move down the assembly line, Airbus is clawing back. Such turnaround stories often star a company's top brass. But at Airbus, much of the credit rests with a few midlevel executives who found a way to fuse the company's balkanized units while the boardroom was in disarray.

One of them is Rüdiger Fuchs, a 41-year-old German engineer who forced designers, engineers and assembly line workers at Airbus's Hamburg factory to start cooperating. With the help of Alain Carcasses, a French engineering manager, Mr. Fuchs also coaxed French electrical specialists into helping their German counterparts at an engineering office in Toulouse, France. [...]

Airbus Chief Executive Tom Enders says the company recognizes what went wrong. "The underlying problem was the lack of integration," he says. "We're taking voluminous lessons from that."

The story goes on to look at the steps Mr. Fuchs took to address the technical, programmatic, and cultural problems that delayed delivery of the first plane by almost two years and overran the budget by $6.8 billion.

Unfortunately, expensive problems with complex systems seem to be more and more common. Airbus, Boeing, Microsoft, NASA, Lockheed, SAP, and Northrop Grumman are just a few of the companies and organizations that have suffered from poor systems integration and program management in the past few years.

We need a better approach to system integration (SI) for complex systems that are unique or first-of-class. Systems integration theory is non-existent: instead the standard definition of SI limits it to configuration management of system interfaces during development, and then melds it into end-product assembly, verification, and validation, aka "System Integration & Test."

Mr. Fuchs came to understand that his integration problems extended beyond the complex technical challenges of the A380 superjumbo. He had to address cultural issues that impeded communications between the engineering teams in Germany and France, and between the engineers and the assembly workers:

There was no single manager to force integration and spot problems.

"Nobody had a high-level view or the power to rule the game," he says.

Good system integration practices are good system engineering practices, but it seems few systems engineers and program managers really understand the "magic" that leads to successful integration. Effective SI requires good design, good communications, good management, and a supportive corporate culture.

Airbus has learned that lesson the hard way.

Not the way to roll out software!

Today's WSJ carries an article about how Arizona State University decided to introduce its new enterprise-resource planning software:

The Tempe, Ariz., school has installed its new software using an unconventional -- if painful -- approach: Admit from the start that there will be mistakes; then work through the glitches with users' help. Most companies take their time and don't start using a new computer system until they are convinced almost everything works right; then they are caught off guard when mistakes inevitably happen. Often, the delays allow them to expand the project's scope, which adds cost and can further compound problems.

The information-technology department at Arizona State decided it would be more effective to stick to rigid deadlines, releasing the software on schedule even if all the kinks hadn't been worked out -- and try to fix problems on the fly.

Ouch! The fact that payroll was one of the applications that didn't work well did not help morale among employees -- or HR which had to deal with the fallout from the new system's errors.

The ASU IT department claims success: "The final price tag for Arizona State's project is $15 million to deploy the software and another $15 million to support it over the next five years." Sure the rollout was below budget and on schedule, but I wonder what the real support costs will be? IT is guilty of pushing implementation costs off on other segments of the organization, where the reduced efficiencies are hidden in non-IT budgets.

One of the maxims I learned long ago is that HOW change is implemented goes a long way toward its ultimate success. I doubt that future large-scale software implementations will be greeted warmly by the faculty and staff.