What the Boeing Dreamliner 787 Team Can Learn from Agile Methods
The Boeing 787 Dreamliner’s grounding issue is currently the talk of the town. Steve Denning’s article on Forbes presents an interesting look at the news. The only problem with the article is that it only emphasizes one subject—offshoring—rather than addressing other issues in a holistic way.
I have been working on large, complex software projects in a distributed model for a long time. Over my career, I have come to realize that the issues plaguing product development—whether hardware- or software-related—are pretty much similar in nature. Most of the time, the issues are related to poor planning, estimation, and quality checks. At the end of the day, the Boeing 787 is a product; it may not be a software product, but it is a hardware one.
If you take a look at the list of issues that the 787s have encountered, you will find classic project management and quality errors.
Let me begin with the budget and delay issues. The first planes were delivered to Nippon Airways in 2011, years late and billions of dollars over budget. Surprise, surprise! Isn’t this a classic project planning and estimation issue? It has been proven through the ages that project managers should keep the Cone of Uncertainty (COU) in mind while planning. Quoting the COU link:
Estimates created at initial concept time can be inaccurate by a factor of 4 times on the high side, or 4 times on the low side. That means the total estimate range is a staggering 16 times at the time of initial concept! And believe it or not, that’s a best-case scenario.
Boeing should have taken the COU even more seriously during planning because of the new radical technology that the company wanted to implement on the Dreamliner.
Another issue that affected the 787 was an integration issue. As the Guardian reports, “The wing tips were made in Korea, the cabin lighting in Germany, cargo doors in Sweden, escape slides in New Jersey, etc. Parts never integrated properly.” The basic principle that we should integrate early and integrate often is what we agilists have been taught, and Boeing seems to have ignored it.
Boeing also suffered a poor-quality checking issue. Most of the time, quality is ignored due to time pressures. According to the Guardian, Boeing was able to get a waiver for the size, quantity, and manner of use for its lithium-ion batteries, which were not tested properly.
To conclude, I see that Boeing’s issues have less to do with a distributed way of working or offshoring and more to do with project development issues.
Do you think that Boeing has ignored some fundamental principles of product development?
