USA: ORCHESTRATING THE BIG PROFIT. - When it comes to managing large-scale, technically complex developments, US companies have led the way. Malcolm Wheatley investigates their methods.

Last Updated: 31 Aug 2010

When it comes to managing large-scale, technically complex developments, US companies have led the way. Malcolm Wheatley investigates their methods.

British industry's productivity and quality performance has been transformed over the past decade, but its ability to manage large-scale, technically complex 'flagship' projects is still mired in the failures of the past. More often than not management failings, rather than inherent technical difficulties, are to blame. Witness two recent examples: the cancellation by the Stock Exchange of its £400 million Taurus project, and the collapse of the London Ambulance Service's equally ambitious computer system just hours after it was switched on. Nor are these isolated instances. Remember British Rail's Advanced Passenger Train (permanently withdrawn shortly after entering service, following a series of breakdowns), and GEC's early warning radar system for the RAF Nimrod (abandoned in favour of US Boeing Awacs aircraft)?

Even if they are not stillborn, large-scale projects are all too frequently overdue or over budget. Think of the rolling stock for the Channel Tunnel - and, of course, the Chunnel itself. Equally worrying is the fact that - in Britain at least - today's big innovative development is apt, on closer inspection, to be yesterday's updated. The latest Rolls-Royce aero engines are variants of the same RB211 that brought the company to its knees in 1971. The BAe 125-800 business jet is a spruced-up Hawker-Siddeley 125, which first flew in 1962. And is the fact that Rover's Mini is still rolling off the assembly line 35 years after its 1959 launch a tribute to yesterday's designers or a reflection on today's?

The good news is that programmes designed to accelerate and improve product development are currently very fashionable in British industry. The best known of these is 'simultaneous engineering', whose lessons have been taken on board by numbers of electronic and engineering businesses. The technique is in essence quite simple. In the first place, design and development, instead of being carried out sequentially - one after the other - are performed in parallel. Thus manufacturing tooling, say, is designed at the same time as the product itself. Second, the old functional design organisation is broken up and replaced by a product design team, whose members are drawn from all relevant parts of the business - plus, if possible, from customers. When Bendix, for example, set out to design a new anti-lock braking system, the team included co-opted representatives of the motor manufacturers, automotive main-tenance experts, customers and motoring journalists.

While the efforts that British industry is putting into simultaneous engineering are undoubtedly paying dividends, the technique is no magic wand. For every company that has transformed its development process, there are many that have achieved only marginal improvement. This inevitably - and unreasonably - casts doubt on the entire concept. As in the early days of 'just-in-time' and 'total quality', lots of businesses are waiting on the sidelines, hoping to benefit from the experience of others. Unfortunately, useful British case studies - particularly at the larger end of the scale - are few and far between. The US, by contrast, offers numerous examples of the successful application of simultaneous engineering to complex, expensive, innovative and technically difficult developments. Boeing's new 777 airliner, for one, was not simply a rehash of earlier designs. Intel's new Pentium microprocessor also represented a break with the past.

The semiconductor giant's challenge was to make a chip that could run existing PC software, yet match the speed of the streamlined RISC (Reduced Instruction Set Computer) chips of its high-tech competitors. The latter owe their rapid processing power to a stripped-down internal 'language' - a kind of shorthand that speeds-up simple tasks and uses a succession of basic commands to handle bigger tasks for which no command exists in the language. Intel's mainstream technology was entirely CISC (Complex Instruction Set), a richer internal language with a single word command for virtually every task. But it was also slower. Or could the company find the industry's Holy Grail - by developing a 'RISCy' CISC microprocessor, using transistors so small that 500 would be needed to encircle a human hair?

But, first, back to Boeing. Like many engineering-led businesses, Boeing had been accustomed to telling its customers what they needed. Arrogance had served the company well in the past, as the best-selling 737 demonstrates. It is dangerous to be arrogant, though, when you're entering unfamiliar territory. True, Boeing's bosses had bet the company when they developed the 747. If that aircraft had nosedived, Boeing itself would shortly have followed. But in that case the potential rewards were colossal. For if airlines really wanted a plane as big as the 747, there was only one manufacturer they could talk to. This was not the case when Boeing engineers sat down to design the 777.

When it came to aircraft of 300-plus seat capacity, others had been there first. The aim of enticing customers away from the established widebody products of Airbus and McDonnell Douglas demanded that the company should listen rather than talk. 'We had to learn to think like an airline,' admits Ron Ostrowski, a 25-year company veteran who is Boeing's division director of engineering on the 777 project. 'We knew how to build aircraft but not how to operate them.' Eight 'technically strong potential kick-off customers' (including British Airways, United Airlines, Japan Airlines and Qantas) were asked to participate in a project that was to start with a blank sheet of paper and finish with a fully specified configuration. The problems didn't end with their agreement to take part. 'These are guys that compete with each other,' Ostrowski points out. Boeing employed professional facilitators to get the airline people talking frankly but there were sundry matters on the airline managers' minds. Boeing's preconception was essentially of a stretched 767, which would enable the company to reuse an existing fuselage. The airlines wanted an aircraft that was 25% wider - and they got it.

Another airline insistence was interior flexibility. Galleys and toilets are traditionally used as dividers between the first, business and economy classes. This means, in effect, that the proportion of an aircraft allocated to each class has to be decided at the ordering stage. But the airlines wanted the capability of having so many high-margin, business-class seats on one day and a different number the next. Passengers who are forced to fly economy because the business class is full represent an enormous loss of revenue over the life of a plane. The need was obvious, but lavatories and galleys are solid constructions, plumbed into the power and water systems. Again, Ostrowski's engineers swallowed hard and said OK.

Another sore point for the airlines was service readiness. The company's latest product, the stretched 747-400, had needed 300 extra engineers assigned to it after it entered service, to eliminate bugs that hadn't been spotted during design and manufacture. 'Never again,' said the airline managers, dumping a third big problem into Ostrowski's lap. What started out as a plan to exploit a market niche by stretching the 767 had turned into something with all the hallmarks of one of the massive gambles of the past: an all-new design for the largest twin-jet in the world, with an exceptional degree of interior flexibility and an unprecedented level of service reliability.

Boeing concluded that its conventional approach to aircraft design was unlikely to suffice. Breaking completely with the past, it decided to develop the plane using two new tools. The first, explains Ostrowski, was the concept of 'design/build' - carrying out product design, development, test marketing and 'optimising for manufacture' all together. The company had experimented with it before, but this time it was for real.

The problem was the scale. Boeing had thousands of people working on the 777, and the aircraft itself had three million parts. Could simultaneous engineering be made to work on such a scale? Chief engineer Henry Shomber, a Boeing man since 1958, was convinced that it could - but only after some contortions.

For a start, the culture was wrong. Boeing had never built an aircraft that way before, so none of the groups had worked together. The same problem is encountered by every business implementing simultaneous engineering, but it was aggravated in Boeing's case by a rigidly hierarchical corporate culture. This was 'probably the biggest challenge we faced' in the opinion of Shomber, who has led innumerable communications and culture-changing sessions in an attempt to tear down walls that have been erected during the company's 75-year history.

It was clear, given the amount of cross-referral and consultation involved, that the new process would be very slow. Yet the company needed to get the 777 out into the marketplace as quickly as possible. Even more important, how could each team ensure that its components fitted together with those of other teams to make a complete and trouble-free aircraft?

The answer lay in Boeing's second new tool - using 'digital definition' in the design of each part. Designs would be integrated by 'digital pre-assembly', in effect, building the aircraft inside a computer first. The 777 is believed to be the first jet airliner to be 100% designed in this way, using three-dimensional solids technology, and electronically pre-assembled to avoid costly full-scale mock-ups.

Some 2,200 workstations were linked to the largest computer installation in the world, a cluster of eight big IBM mainframes working as one. Using three-dimensional modelling, the computer can determine if two components are trying to occupy the same physical space. Such conflicts had often previously come to light only after construction was under way. The set-up, known as CATIA, is so powerful that it can simulate on-screen an electronic mechanic - dubbed CATIA-man - walking around inside the aircraft carrying out maintenance. CATIA-man uncovered all sorts of potential glitches. He found, for example, that a human mechanic would not be able to reach the navigation light on the roof of the aircraft in order to change the bulb.

Barry Gosnold, British Airway's senior liaison executive in Seattle (where he was first posted by BA in the '70s) enthuses about the way the 777 is being built. 'Previously we never got to see the designers - now we're working with them.' Gosnold reels off a list of enhanced 'usability' features, all of which should help the airline wring more revenue from the planes when they go into service. Thus three 'flexibility zones' have been created, within which galley and lavatory (along with their associated plumbing and electrical services) can literally be slid up and down the fuselage to optimise the first-business-economy split in line with the passenger mix. Various design tweaks will reduce downtime and maintenance. One of Gosnold's BA engineers gets the credit for a new rear-galley layout that will increase capacity by 12 seats. Gosnold estimates that, given average-load factors, a dozen extra seats will increase profitability by a third over the life of the aircraft.

While Boeing was getting to grips with the 777, several hundred miles to the south in Santa Clara, California, Intel managers were immersing themselves in the Pentium development. Although neither party knew it, parallels were to emerge between the two projects. For a start, there was the feeling that the previous new product had almost been a bridge too far. Just as Boeing needed to draft hundreds of engineers to sort out the 747-400, Intel had alarming problems with its 486 processor. At this level of technology, bugs are bound to creep in. Unhappily, 60% of 486 design flaws had been found by users. 'This time,' recalls Vin Dham, general manager in charge of the development, 'I had a goal of finding all the errata on my processor in-house.' Yet Dham was simultaneously under pressure from Intel's board to speed up time-to-market.

This time round, too, explains senior corporate strategy vice-president Dave House, Intel was set on involving major customers and software suppliers in the design. Advances in microprocessor technology were tending to catch the industry unawares, so that it could take up to two years for new features to be fully exploited. Margins would harden if the product incorporated more of the features that customers actually wanted. House's formula: get closer to industry majors such as Microsoft and IBM, and keep them fully briefed as development went along.

Further, a new organisational approach was needed. Splitting development up between groups should hurry things along - but would also lead to problems given Intel's historically relaxed culture. There was the further question of how the teams should be made up. In the competitive world of Silicon Valley, the potential for mass desertion was enormous. The company had suffered serious staff losses at the end of the 386 programme. So the dilemma confronting Dham and House was how to retain key design staff - who were liable to become restless unless they had a new chip to work on - yet not announce the composition or leadership of the teams until development of the earlier chip had been signed off, and discussions had been held with customers and software vendors.

The executives' tactic was to take whatever preliminary feedback the market could offer, add to it features they had already thought of, declare that the result would outperform RISC competitors - and wait. The marketing hype was as much for internal as for external consumption. The prospect of working on such a radical new design would keep people in place, Dham calculated, until work on the 486 was complete. For months he kept the new organisation in his head until the design parameters were fully established. He was determined that this time there would be 'no more talking in corridors to decide things. I wanted standardised procedures, formal design revues, and documentation every step of the way'.

He also wanted a better way of testing designs. The conventional approach - cheaper than building a chip - is to simulate it on a mainframe. The computer models the action of each of the chip's several million transistors, and can emulate the operation of conventional PC software. This was too slow for Dham. Having discovered a start-up just down the road that had pioneered a hardware version of the same approach (using a technology known as programmable logic gates) he ordered a massive scale-up which allowed chip emulation to be speeded up by a factor of 30,000. The gamble succeeded - early user trials came up with only an eighth as many bugs to be cleared.

So Pentium, like the 777, seems set for a clear take-off. The lessons emerging from both these stories are revealing. Cynics doubting the effectiveness of the simultaneous engineering concept (or the need for corporate culture change) need only talk to Boeing or Intel in order to be convinced. UK companies often worry about new ways of working when design and development staff number only dozens: Intel and Boeing reveal that they can be effective when numbers involved extend to hundreds or thousands.

Both companies, it will be noticed, invested heavily in hard technology. In a world looking for instant remedies, Boeing's CATIA and Intel's programmable logic emulators might well have been hailed as giant-killing magic bullets. They aren't. Like the drawing boards that preceded them they are merely tools - expensive, maybe, but appropriate to the scale of the task. The temptation to muddle through with something cheaper was resisted.

But the biggest lesson here doesn't concern capital expenditure, or technological leaps, or experiments with corporate culture. Both these US companies were at pains to design in features that their customers wanted. British managers who protest that they, too, talk to customers, may be missing the point. Are they listening as well?

Find this article useful?

Get more great articles like this in your inbox every lunchtime