Boeing’s 787 Dreamliner is the world’s most advanced passenger plane, featuring many trailblazing features that, whether a passenger or a pilot, make it a dream to fly—for example, its two engines are so fuel-efficient, the plane can fly from Boston to Tokyo nonstop.
But it has suffered a couple of battery fires and was put on the shelf while engineers puzzle over what went wrong. In the wake of the merger with McDonnell Douglas, Boeing focused on expense management rather than innovation. It outsourced much of the design and manufacturing of key components, and the project has cost much more and taken far longer than it was supposed to.
Indeed, the Dreamliner will be a superb aircraft once the battery woes are solved, the experts agree, yet big software projects at insurers replacing core systems too often run into similar cost overruns and delays. The difference is that unlike the 787, in the end, they never get off the runway. Or if they do get in the air, they perform poorly. The IT “Dreamliner” turns into the Nightmareliner, and the nightmare doesn’t end when your alarm buzzes. It goes on for years.
So what lessons can be drawn between the experiences of Boeing and those insurers who treat their high-stakes systems initiatives as if the primary goal is saving money, rather than producing a quality software product?
First and foremost, it is a mistake to treat software development like it can be done on an assembly line. Good software development is part art and part science, and requires a deep working knowledge of the intricacies and complexities of insurance. Creating requirements and farming them out to the lowest bidder—offshore or onshore—will yield the same results as Boeing’s Dreamliner.
Second, good software development and developers should always be focused on the sum of their efforts, rather than on the individual parts that make up the sum.
This by no means is a commentary on agile or any other software development methodology that breaks large tasks into smaller tasks as a way to demonstrate progress and forward momentum. That is a fine approach. If done properly, the big picture has already been established and the focus on smaller tasks works because a context had already been created for the final sum of the parts.
Such an approach is altogether different than the piecemeal, or assembly-line approach of software development. Assembly line approaches are all about efficiency and expediency, and while those are not bad characteristics in and of themselves, they are bad when they are applied as the primary characteristics of software development, or of designing and assembling an airliner.
In the case of the Boeing Dreamliner, it has been reported that in the end Boeing was only responsible for building 40 percent of the plane. This posed serious engineering and integration problems for the Boeing engineers. And it’s exactly analogous with the kinds of problems software engineers face when they attempt to assemble a large system which has parts supplied by several vendors.
An analysis of the Dreamliner manufacturing process revealed that Boeing used 50 different partners. By any standard, that’s a lot of integration points, and greatly enhances the possibility for mistakes or missteps, as Boeing is now experiencing. Even with Boeing’s engineering prowess, pulling all those “best-of-breed” components together proved far harder than anyone expected.
Perhaps the most salient and sobering point is that the whole idea behind the Boeing approach was to engineer and construct a new aircraft as cost effectively as possible. In concept that’s a fine idea, however it’s often a long and perilous road from concept to implementation, whether it is an aircraft or an insurance system. In the end, it is going to cost Boeing immeasurably more in costs and public relations than any dollar amount saved via their engineering approach.
The same is of course true for insurers who take the same software development approach, and end up spending more than they had planned via rework and refit, and more importantly, who lose the trust and credibility of their customers, something not easily recovered in any industry.
Frank Petersmark is CIO Advocate at X by 2, Inc., in Farmington Hills, Mich., a technology company in Farmington Hills, Mich., specializing in software and data architecture and transformation projects for the insurance industry. He can be reached at Fpetersmark@xby2.com.
Frank Petersmark is CIO Advocate at X by 2, Inc., in Farmington Hills, Mich., a technology company specializing in software and data architecture and transformation projects for the insurance industry. Previously, he was CIO and VP at Amerisure.
Readers are encouraged to respond to Frank using the “Add Your Comments” box below. He can also be reached at fpetersmark@xby2.com.
This blog was exclusively written for Insurance Networking News. It may not be reposted or reused without permission from Insurance Networking News.
The opinions of bloggers on www.insurancenetworking.com do not necessarily reflect those of Insurance Networking News.
