The Boeing 787 Development Story

Employees cheering 1st 787/10 in 2/2017

Today, the Boeing 787 is a successful product, with production rates at 12 units/month, and a total of 521 flying just over 5 years from launch. By comparison, in 49 years of production, Boeing built 1,528 units of the 747. And, having just flown in a 787 from San Francisco to Paris and back, I can attest that it was for me less tiring than in any other plane, which I attribute to the higher air pressure. It is close to that of Lake Tahoe (6225′) while other planes are closer to Squaw Valley High Camp (8200′).

Back in 2008-2011, however, the news coverage of the 787 was not so positive, as the plane’s product launch accumulated a delay of more than three years, with analysts pondering what had gone wrong. To keep this event in perspective, we should remember that multiyear delays in product launches have recently been the rule rather than the exception in commercial aircraft, worldwide. In Europe, the Airbus A380 was 2 years late and, in Russia, so was the regional Superjet 100. But the question remained of how Boeing, an organization with 100 years of experience in designing and building airplanes, could not have done better.

I would like to present here a few explanations that have been proposed, without passing judgment as to whether any or all of them are accurate.

Continue reading

Lean and ISO-9000: Strange Bedfellows

See on Scoop.itlean manufacturing

This article is a critical review of a book called Lean Startup that I haven’t read yet and won’t comment about. The review itself, however, contains some surprising statements, about, for example, ISO-9000 being a technique that emerged as part of Lean, or a about Lean being “a system designed to produce a million identical, high-quality Corollas, Camrys, and Siennas.”

I am used to thinking of ISO-9000 as the product of an international body that is unrelated to Lean, and whose implementation is centered on compliance with generic procedures rather than effectiveness. Not exactly the Lean approach to quality.

The reviewer also appears to be confusing Lean with the system developed by Ford for Model Ts 100 years ago. Lean actually includes approaches to production for Low-Volume/High-Mix as well as High-Volume/Low-Mix environments.

See on www.human-habits.com

The Project Game

The developments of the Airbus A380 and the Boeing 787 were both more than two years late. You might think that these two master aircraft builders would know better. Such performance, however, is not the exception. Generally, from kitchen remodeling to the development of a product or a production line, projects tend to be behind schedule, over budget, or both.

That it is technically possible to do better even with a large-scale project involving new technology is illustrated by the Apollo program: it reached the goal set by JFK 5 months ahead of the deadline at a cost of $24B, accurately estimated in 1961. Even NASA, however,  did not repeat its Apollo performance with the Space Shuttle. 100 years before, another major project, the transcontinental railroad, was also completed in record time at a cost that was consistent with original estimates.

It is therefore legitimate to ask why we are not able to do better, given the tools we now have. The key is that project and program management are treated like technical fields when they should be viewed as games, meaning that outcomes are the consequences of decisions made by several independent agents. In project management as described in the PMBOK, you break a project down into smaller tasks, to which you assign durations, resources and constraints of timing or precedence. Then you run calculations that produce Gantt charts, load profiles for resources, the critical path, etc. The most commonly used tool is the Critical Path Method (CPM), as implemented in packages like Microsoft Project. Then there is Eli Goldratt’s Critical Chain Project Management, focused on resources, and the Design Structure Matrix (DSM) to manage task iterations.

These are logically consistent models, and good fodder for presentations, but cast aside in daily project management in favor of the primitive action-item lists. The most obvious problem with the use of the tools is that durations for elementary tasks are not known, and that I have never seen an organization make a serious effort at collecting this data. A project task is not like an assembly operation that you can time with a stopwatch or record on video. And project work is never completely repetitive: if you keep repeating the same action, it may be called production or transaction processing, but not project work. Since you have never done this project task before, you cannot tell exactly how long it will take, but you can get lower bounds based on its content — for example if it involves driving 60 miles or waiting for paint to dry — and you could estimate it based on similarities and differences with tasks you have done before, if you had kept track of them. Engineering work is organized by project, and the time of engineers is tracked through time sheets, but these sheets are filled out after the fact by the engineers themselves for accounting, and are not accurate.

There are ways to estimate task times better, but that is not the main concern of project managers. Instead, their thinking is centered on sentences that begin with “Nothing else matters if…” Initially, a manager commissioned to lead a project has to come up with a plan that needs to be approved and nothing else matters. The purpose of the plan is therefore not estimation but persuasion. How this is to be accomplished cannot be stated in a generic way, because it obviously depends on who is to persuaded. What is a constant is that the project manager is selling, and will do whatever it takes to close the deal.

Imagine a king who is single and wants an heir. He solicits three members of his council to manage the project and gets the following responses:

  1. The first adviser claims that he can organize to produce an heir in four months.
  2. The second adviser quotes three to five years, taking into consideration the need to find an appropriate consort, follow the complex protocols of royal engagements and weddings, and let nature take its course.
  3. The third adviser quotes nine months.

Assuming the king operates like most corporations, whom will he appoint? The first adviser’s proposal is physically impossible, no matter what resources are put to the task. The second adviser strikes the king as too cautious. The third adviser gets the job, because he is proposing an aggressive schedule  that is not impossible. The adviser knows the deadline won’t be met, but he can deal with that later. The king knows it  too, but is betting that the adviser will redouble his efforts to atone for his failure to deliver on time. Four years and eleven months later, a prince is born.

In this kind of situation, the task durations used in project planning are the shortest that don’t violate the laws of physics. The project managers make the sale on that basis, miss the deadlines, and work desperately hard to finish. As a result of surviving in this game, they are promoted and continue the same practices with the next generation.

The game does not have to be played this way, but the initiative must come from the top. Soichiro Honda set a different tone early in the development of his company, by engaging it in motorcycle racing. When participating in a race, nothing else matters if the vehicle, pilot, pit crew and supplies are not in place and ready at the start of the race. Such hard deadlines are also found in organizing concerts, preparing museum exhibitions, or launching a space probe to fly by multiple planets. They focus project teams on realism in task assessment and creativity in dealing with the unexpected. Besides the publicity, Soichiro Honda’s purpose was to infuse all the company’s projects with the “racing spirit.”

There are, of course, many other useful perspectives on project management, and I find that the most interesting to read are case studies. Following are some of my favorites:

  • The soul of a new machine, This is Tracy Kidder’s account of the development of the MV-8000 computer at Data General in 1980. The technology is irrelevant today but the human dynamics have not changed. The now defunct Data General computer company  had been caught by surprise by DEC’s introduction of the VAX in 1978 and needed a response. The book has all the elements of a thriller: an inept corporate bureaucracy squandering millions on a luxurious research facility for no return, while a small band of rebels in the cellar of an old building succeeds against the odds in developing the product that gave the company a new lease on life.
  • Car, by Mary Walton, Like, “The soul of a new machine,” this is a product development case study – if the 1996 Taurus at Ford – by a journalist who was invited to follow it from start to finish. The most interesting aspect of this case is that, while the development project was technically successful, the resulting product did not keep its promises in the market.
  • Fred Moody’s I sing the body electronic is similar to the other books, but about software product development at Microsoft in the 1990s.
  • Stephen Ambrose’s Nothing Like It in the World takes you into 19th century project management on the transcontinental railroad.
  • A Man, a Plan, a Canal – Panama, a DVD narrated by David McCullough about the mother of all civil engineering projects. Note that the title is a palindrome.

Tom DeMarco’s The Deadline is not a case study but a novel about project management. It is about software development but is entertaining and enlightening even for readers in other fields. DeMarco is a deep and original thinker, but with the wit of a Tom Wolfe.

From scancards to “personal kanbans” and Ybry charts

Professionals know that their productivity drops when they take on too many concurrent projects. An engineer whose attention is split across 15 projects doesn’t contribute effectively to any. But it happens because supervisors keep piling on assignments without regard to this phenomenon. Over the years, cures have been proposed under different names, all aiming to cap work in process.

About 1982, a colleague showed me the system he used to manage what he was working on. It was called the Scancard System, and it used the hardware  in Figure 1. The cards were square, with 3 1/4-in sides and borders of different colors. They came with letter-size card pocket plastic boards that you could insert into 3-ring binders, keep on your desk or pin to a wall.

Figure 1. The Scancard System

He used it with one column for his backlog of things to do, one column for work in process, and one column for completed items. It was a paper-based system but, at the time, so was almost everything we did. It gave you visibility, it capped the number of items you were working on at one time, and moving cards from one column to the next was an effective metaphor for the flow of your work. The ads showed smartly dressed managers using their scancard systems in meetings. I went for it and used it for years, until I had a project with a company that used another system and switched to fit in.

Fast forward to 2011. Scancard Systems is out of business, and I hear of a system called “Personal Kanban,” that is focused on providing visibility and limiting work in process, using a white board and Post-Its as in Figure 2:

Figure 2. “Personal Kanban”

I put quotes around the name because I find it to be little more than a feat of vocabulary engineering, leveraging the buzz around a feature of Toyota’s production control system to repackage ideas that have little to do with it, are very simple and have been around for a long time. A software developer visiting a factory may see a similarity with Toyota’s Kanbans, but it escapes me.

Of course, if, as in Figure 2,  it is on a white board, you can’t carry it with you to a meeting or share it in your network. The Personal Kanban website advertizes an iPhone app called iKan, that I can’t find on Apple’s App Store. On the other hand, Leankit Kanban offers a web-based application with an iPhone version that looks very much like a team to-do list management system. It looks most useful if your work can be perceived as a collection of independent activities, which happens if each Post-It is for a whole project or for a prospect in a sales cycle. But it would not fit if each Post-It were for a task within a project, with precedence constraints or iterations between tasks.

Another limitation of such a status board is that is only shows current status, as compared, for example, with the Ybry chart of Figure 3, which shows the complete history of each project by using a line for each project rather than a card. Like the status board, it assumes that all project go through the same sequence of phases.

Figure 3. Ybry chart for projects going through the same sequence of phases

Ybry charts were invented by Charles Ybry in 1846 for railroad scheduling, and are still used for that purpose. See Edward Tufte’s Envisioning Information, pp. 107-110. The work-combination charts used in Lean operator job design are a variation on this method, as explained in Working with Machines, pp. 133-154.

Black belts, scrums, and other metaphors

To be useful, a metaphor must help understanding. For the promoters of Six Sigma to call their certification Black Belt was marketing genius. A more descriptive label might have been Staff Statistician, but what self-respecting manufacturing professional would want to be that? Borrowing a term from Japanese martial arts not only  appealed to their fighting spirit, but also gave the impression that an approach developed at Motorola in the US had a connection with Japan, ground-zero of manufacturing excellence. Even in Japan, Black Belt (“Kuroto”) and White Belt (“Shiroto”) have migrated from martial arts to everyday language, to designate respectively a real pro and an amateur.

As a metaphor,  Black Belt also made sense because there is a parallel between the Six Sigma and martial arts training programs. Traditional  masters in the martial arts of China trained one or two disciples at the Bruce Lee level in a lifetime, just as universities trained only a handful of experts in statistical design of experiments that could be effective in electronics manufacturing. One Karate instructor, on the other hand, can train hundreds of Black Belts, just as a Six Sigma program can teach a focused subset of statistical design of experiments to hundreds of engineers.

Scrum, in software development, is also a sports metaphor, a term borrowed from rugby, which few Americans know. The connection between a rugby scrum and what software people call by the same name, however, is not obvious. A rugby scrum involves the forward players of two teams locked in the pattern of Figure 1.

Figure 1. A rugby scrum

The ball is released in the middle of the scrum and both team try to take possession by kicking it backwards while pushing the other team forwards. It is exciting and bruising to participate in, as well as a great spectacle. For software developers, scrum is an approach to project management illustrated by the status panel in Figure 2.

Figure 2. A software development scrum

It leaves you wondering what plays the role of the opposing team, the ball, or the player positions. In other words, in what way is a rugby scrum a metaphor for this approach at all?