Just because and EFB is a nice piece of equipment, says Captain Michael Bryan, Principal, Closed Loop Consulting, doesn’t mean it’s the right piece of equipment.

History repeating itself

In 1986, the International Standards Organisation, ISO, created the Standard Generalised Mark-up Language, SGML, as a standard. ISO 8879:1986 was going to revolutionise the aviation industry. All manner of data interchange between manufacturers and airlines, and vice versa; the information within airlines and the manner of delivering it to the end-user was going to be radically improved; process efficiency was a given and huge savings numbers were tossed around like autumn leaves in the wind. It is now 2012 and as an industry, we wait… still. Sure, there has been some incremental uptake of SGML or mostly the many derivatives of it, such as HTML and its many variants, and the more well known today, XML. However, so far, the great promise has failed to transform the industry.

Various proponents billed the Electronic Flight Bag, the EFB, with the same gusto over time. Itself a derivative or re-invention, the EFB promised big, but has so far failed to live up to its own press. Just like SGML before it, the struggle has not been driven by the ability of the technologies involved to enable the promises, rather the industry’s ability to shift, to implement the change necessary to successfully implement them.

This essay critically examines some of this history. The same issues continue to cloud the benefits foreseen in EFB then. The author will posit some adjustment to perspective that may help to re-frame the view of the technology’s potential, drive some fundamental change in the manner in which EFB is approached by the industry and hopefully deliver broader successes in EFB projects from here on.

Promises, promises

First things first; some boundaries for the discussion: the industry should be in no doubt that EFB, framed as ‘enabler’, like other technologies before it, is unequivocally, a tool for re-energising, re-engineering and revitalising the operational domains within an airline. Its potential value ranges broadly depending on the scope of various projects. Consider by way of example, one particular program that exemplifies the potential. Planned as a five year program, framed by a strategically specified collection of EFB capabilities, its business case delivered a financial benefit to the particular airline of $304,000,000 – yes, that’s three hundred and four million dollars. This figure was the discounted cash flow benefit, which means that inflationary aspects and the time value of money had been accounted for in the cost-to-benefit analysis for the project. For those non-accounting people like me among us, the DCF (discounted cash flow)^[1] is a time-based measure of the project cash flows measured against the cost of capital. It has some limitations that bear more than a cursory glance. Nevertheless, what it means is simply this; this project was worth $304m more to the company than the ‘do nothing’ option (more on that later) on day one of the project. This particular project exceeded 48% ROI (return on investment) and equated, at the time, to 1/3 of that company CEO’s savings edict.

The value to the organisation was profound: the project provided a third of the pan-organisational savings that the CEO considered necessary to keep the airline in business. For all its potential and critical need, the project failed, suffering the loss of considerable ‘sunk costs’ – a convenient term for wasted money. The failure was not because of the technology, or difficulty integrating the various parts or the cost of them, but because the airline simply could not adjust its modus operandi and had not considered the degree of change necessary to make it work. In a nutshell, while there was nothing wrong with the technology, the airline just could not implement it… that is, integrate the necessary change within the operational, administrative and day-to-day processes of the airline. This was a large, pan-organisational project. However, many others demonstrate similar ROI numbers in the planning stage. So for this discussion, let’s put a lid on the question of value. EFB certainly does punch above its weight in terms of efficiency, saving and flexibility… potentially.

Unfortunately, often – mostly times, actually – the promise is not delivered. When we speak to senior executives during our work with airlines, most can tell you exactly what a project cost; they can all discuss the ocean of ‘sunk costs’ when projects fail, but so far, none has been able to articulate what the value of the project was supposed to be, or what it delivered after implementation. Indeed one executive recently bemoaned during our discussions that neither he nor anyone on the project team could articulate what the point of the project was, apart from that, it “seemed a good idea” and there was “lots of potential down the road”. This project was implemented. The true value to the organisation is still being assessed and so is the way that value will eventually be delivered. Is that the definition of an experiment?

In these situations, what is the point to the airline if there is no check on the project downstream of implementation? Indeed, what is the point of the whole project in the absence of an overarching strategy for it? If it was not worth it, what was the point of doing it? If there is no downstream review, how can the proper uptake of the change be measured – just to see if it was indeed worth it? Then, what should be measured? The issues here are not isolated and are driven by differing perspectives.

Early attempts at electronic information sources

I’m a pilot. I want an EFB. Let’s face it they’re cool – aren’t they! I’ve wanted one since the late 1980’s when Boeing said I could get one for the B747-400. Then, it was called the Electronic Library System or ELS and it was intended as the vessel to contain all that intelligent data that was going to come from the SGML developments – hang on; we’re still waiting. Again, there was a lot of promise – although not about much as it turned out. The hyperbole from Boeing was that an airline could really do anything they wanted with the ELS. Except Boeing at the time did not really tell airlines what ‘anything’ was, leaving them to figure it out for themselves in a bold new information revolution that the airlines struggled with for years. Nevertheless, Boeing did know the price. Like Connexions, another fantastic, ahead of its time idea, there was a vacuum in the detail of ELS. Execution and airline-side implementation had not been contemplated let alone considered in the definition. The price tag, in the absence of any real consideration of the other side of the ledger and in the context of the absence of detail, simply scared the industry… clear into the next century as it turned out.

Some explanation for this history stems from the manner in which various industry developments were framed in their beginnings. SGML was, and still is one of the most robust information enablers of our time. It has the strength of a standard and has by way of its derivative, HTML, delivered the World Wide Web, as most of us know it. However, the aviation industry was looking excitedly at SGML well before the ‘web’ came into being. A few exceptional people realised its potential and took their ideas to IATA and ICAO through several forums. Soon after, the Air Transport association had constituted several committees to look into various use cases for the standard. These deliberations continued for many years but were beset by a fundamental lack of direction; that is, there was no business case, or program plan in advance for directing the way SGML was to be put to work for the industry. While there was significant and brilliant work done by some in these groups, there was a greater amount of time undertaken working through semantic differences between what the four main manufacturers at the time called the same widget, and working through the plethora differences in airline documentation and the many perceptions that the same thing was somehow really different.

There was a great confusion about whom, or what the end user of the resulting interchange standards would be, giving rise to similar experiences to the failed military’s CALS^[2] (Continuous Acquisition and Life-cycle Support) initiatives of the same era. Membership of the committees caused focus to be argued between competing perspectives: manufacturers, who needed to streamline supporting documentation from various upstream suppliers and be able to channel that to airframe customers with minimal effort, reducing the mammoth task necessary to consolidate the same paper based material into their various aircraft manuals and airlines, who viewed the standard as being about saving time in the publication and amendment process but not considering the uses smart electronic data could be put to, and who also had a plethora of their own unique documentation to contend with. Indeed, most were focused on making sure it looked like the same piece of paper, which drove much of the debate for years. Eventually pilots got involved and wanted some functionality that gave them better access to information when and in the context in which it was required. Finally, the IT supplier community stepped up with a host of new technology that moved focus from the work of developing a standard form for data to enhance interchange between the manufacturers and within the airline, providing better outcomes for the end users, to the justification process and effort necessary to pay for the tools. This moved the focus to product rather than purpose and began a recursive cycle that lasted into the next century.

Then the worst happened. Someone had a new, better idea and SGML was passed over for HTML and XML. Technology advancement had rolled the work of decades. It continues today and, as we all know, the time between new iterations continues to narrow. The lack of planning and business needs evaluation meant the various committees drifted in direction with every change to group membership until technology passed them by. Sound familiar? It should.

Who is responsible for EFB?

The EFB development process to date has experienced similar forebodings, where competing perspectives drive unacceptable and unnecessary cost into projects and cause a focus on the product again, rather than the purpose of the EFB in the first place. As soon as a screw is turned on an aircraft to fit some new equipment, Engineering must own the project, no one can touch it; in some instances, it cannot even be updated without engineering allocating one of their own resources – an incorrect assumption but nevertheless, one that confers control. It is after all an avionic device isn’t it? The pilots want the gadget because of the perception that it is going to make their lives easier. What they won’t tell you is that all they want is not to have to do the gazillions of amendments or lug 40 pounds of manuals around all day and be able to find information quickly, when they need it – or be able to study more effectively to retain their licenses. So, Flight Operations has to own it right?

However, now we have a computer, not an instrument, on the plane so it must be controlled, approved, managed and maintained within the IT infrastructure and standards of the airline. To add to that complexity, only supported applications may be deployed within the airline. So now, the IT department really, really, should own the project and the processes, right? These are just a few of the different perspectives that EFB engenders in an airline and which all drive focus to the device and cloud the real raison d’être. EFB is an organisationally holistic^[3] tool. Its function is to enable change to business processes throughout the airline and provide business intelligence that empowers an airline to manage its situational circumstances for the better. Taken alone, the focus on the device renders it almost dead weight. Sure, the pilots love some of the devices, one in particular. However, extracting the inherent value is a bigger issue. Even if a particular device is now cheap and easy to acquire, it is not necessarily so cheap and easy to implement successfully; any more than any other particular approach.

The airline is now carrying more overhead in terms of weight on the aircraft, and fiscal drag of additional lines of business and administrative overhead just so the boys and girls up front get a new toy on which to while away the hours playing angry birds. Unless there is a clear strategy in the first instance for what the airline wants the EFB to achieve, to ‘enable’, it is likely that the EFB will end up as an optional extra to ingrained processes, even when there are so many tools in the supplier side of the market through which considerable value can be extracted. On their own, they are not worth much, but integrated within the business in a raft of lean business processes, made possible and supported by holistically implemented enablers, like EFB, good things are possible and the savings illustrated earlier become possible, even routine.

Benefits and results

To illustrate this point, let’s look at performance, for many years a key tenet on the savings side of justifications for EFB. There have been many tomes written about the ‘potential’ value of using just the right amount of thrust for a given set of conditions. These benefits take on a higher magnitude when the cumulative effects of performance adjustments are accounted for, when they become necessary, in well-developed performance applications compared with the page derived alternative. There are few such applications on the market. However, and significantly, not all are able to provide the granular detail when applying adjustments for MEL (minimum equipment list) driven corrections and slap the same singular gross penalty as the paper alternative, rendering them a kitsch toy, but not enabling great change – or value.

Then, there is the operational side. Because of the way these things work to deliver their finely tuned results, they require up to the minute environmental and aircraft condition – weight and airworthiness data – to provide optimal results, where the benefits occur. So when does the pilot run the calculation? The most ideal point for maximum benefit is near the holding point. Of course, as the aircraft approaches the holding point and becomes number one for departure, stopping to run a calculation on an EFB becomes impractical and risks the wrath of ATC and in some places, risks losing the slot, which can in many circumstances result in considerable delays. At the other end of the scale, running the calculation 30 to 45 minutes ahead of departure risks having to do it again if, actually when, the wind and temperature change or late changes occur to the aircraft weight because of fuel or payload.

To mitigate the need for last minute changes to the calculation, short cuts creep in to the operation. The weight is artificially inflated to cater for those last minute passengers or freight. Wind components are rationalised to be less favourable by random values, reducing the headwind or increasing the tailwind to ensure the prevailing wind at the time of take-off does not generate the need to run a re-calculation. Lastly, let’s not forget the temperature and air pressure. One goes up and the other gets reduced to ‘pad’ the result further and ensure a limiting take-off does not eventuate. However, that’s just the point. These applications provide their benefits by creating a limiting take-off more or less. By the time the ‘wheels are in the well, either poorly conceived software or random application of airmanship has blown all the potential benefit of such applications and then some out the exhaust pipe. There is a big gap between the potential and the reality of these applications.

EFB, a warning

A similar critical evaluation can, and should, be applied to every EFB application on the market when airlines go ‘shopping’. These gaps between the potential and the real delivered value can be reduced by rigorous strategic considerations regarding the purpose, rather than the product of a holistic EFB program. Yet, still, the industry persists in putting the cart before the horse and deciding to buy a certain piece of hardware because the price point happens to hit a sweet spot, irrespective of the rest of the program. Then, sometimes, a set of requirements is penned to justify the reasons for the decision. Perhaps a few apps are considered, purchased and loaded. Now, we have an EFB; right?

This is usually where someone such as Closed Loop is invited to begin discussions with an airline. The initial conversations go something like this:

‘Hi, Captain [name] here. We’ve bought a bunch of [insert device here] and [insert supplier software applications here] because we want an EFB. But we’re not sure what to do next. Can you tell us? We have to develop some manuals and get some approvals and do a risk analysis and other stuff but all we want is an EFB. Can you tell us what to do?’

I make light of it but many conversations do follow the theme if not the words. Our answers vary of course, depending on the details, but when we start asking questions to develop our response proposals, we are often met with figurative blank stares. Implementation considerations have suffered in the same way as the Boeing ELS of a quarter century ago. For all its potential value, to the very survival of an airline in some cases, successful EFB programs are not as simple as buying a piece of kit, loading up a couple of apps and switching it on: no matter how perceptively cheap and easy the device, or how logical this app or the next. Deciding why or how after the event leaves no room to move, no room to negotiate and more often than not, means throwing potentially valuable technology at the status quo.

The ‘why’ and ‘how’ should lead to decisions about the device, not the other way around. This small yet vital nuance is just as important for the supplier-side as it is for the airline-side of projects – no matter what the product.

Imagine airline ‘x’ buying supplier ‘y’s’ stuff. No doubt, the supplier’s hardware or software will do exactly as the supplier may stipulate. Nevertheless, what if the airlines perception of how it will operate in their environment has not been considered thoroughly? It happens. Then, what if some aspects of a supplier offering will not operate within the airline environment, especially when considered with other applications or hardware nuances of which supplier ‘y’ is not aware? That happens more and drives the significant and benefit-robbing integration needs of EFB programs, no matter how deceptively simple some approaches may seem. The earlier these requirements are identified, the better for both sides. The answer is for airlines to have considered the purpose, all of it, before the product, and for the supplier side to be as insistent of the fit as the airline is insistent on its qualification criteria for the supplier. There is a fantastic array of capability in the supplier-side of the EEB market. Nevertheless, when implementations fail, airline management confidence in projects suffers, later projects do not get ‘across the line’ and supplier orders dry up. Then there is the cost of internal and external relationships, which can be negatively affected for years to come.

EFB, a better way

Consider an alternative approach. The airline considering an EFB begins the process with a rigorous analysis of its own status quo. This is the model for the ‘do nothing’ option and it is vital for contrasting the value of potential conceptual outcomes. Then, an exercise in visualisation of the new way of doing things will develop the ‘what if’ concepts. These ‘what if’ moments should not concentrate on ‘what if we had an EFB’, but the many operational processes that contribute to the day-to-day and crisis operations. Gaps in the ability to simply change the process to something more efficient will likely be filled by technology, such as the EFB. Eventually, a minds-eye picture of the potential new way of doing business coalesces from which the requirements necessary to reach this Nirvana of operational efficiency and flexibility become clearer. Theses can then be developed into formal definitions on which both sides, airline and supplier, can depend to guide the technical and organisational transition. Moreover, development of robust operational conceptualisations facilitates development of the strategic processes or procedures necessary to ensure the right criteria are used to choose application functionality and identify the nuances of implementation ahead of time.

This approach will ensure potential benefit is translated to real savings, not blown out the exhaust pipe as in the performance example earlier. Sure, this approach might also mean that the supply-side has to work a bit harder than simply selling shank-wrapped software. However, the benefits to the industry will translate to more successful projects, leading to airlines seeing benefit in continual improvement from which we all benefit in terms of return and increased business, and easier and less costly working relationships with customers. On the airline side, the realisation that a bit of definition up front will save bigger amounts of the budget later (much bigger than the cost of figuring out ‘why’, the purpose, and a slice of the ‘how’ before the ‘what’) and will bring much higher rates of project success to them will balance the approach. Both sides will be winners.

Not just EFB but a whole approach

From its tentative, expensive and unclear beginnings a quarter century ago, the EFB has come of age. The market is replete with mature, almost commodity priced hardware, and a broad and growing inventory of specialist applications on which airlines could depend to base their newfound agility. However, the other message is just as stark; on its own, this great technology does not provide much value at all. Successful solutions rely on the airline having a strategic picture of what it is trying to achieve at the outset. Indeed, this strategy should rightly be the first step in a program. From the beginning, the benefit of following a structured methodology, perhaps conducting a ‘zero-based audit’ to accurately define and analyse the status quo and to reflect current decisions, identifying potential overlap with other projects and building operational conceptualisations so that they can be distilled into appropriately detailed requirements, is an ideal first step. Requirements can then guide the supplier process, to solve issues before they begin, which is of great benefit for both sides. Development of an organisationally holistic, multi-tiered project plan, which accounts for the operational, training, regulatory needs and management of such a program, in addition to the technical aspects of the project, is also vital to success. All of these considerations guide the whole implementation and make the airline project holistic, not simply the acquisition of a bunch of stuff for which the true value may never be realised.

The EFB is an enabler of considerable benefit to airlines and to the industry. As the norm of constant change unfolds and the pace increases, leaning has given way to agility. Efficiency, flexibility and future requirements for fitting growing demand into scarcer resources will become a constant demand of operational management throughout the industry. Business processes must therefore be agile and adaptable and, most certainly, EFB is an enabler on which these requirements can be built.

However, just like the bridge down the road, the support towers are not considered in isolation of the rest of the structure. Yet, concentration on technology first and its purpose later has been a hallmark of two of the most potentially profound developments in the aviation industry in the last 25 years in terms of operational capability, efficiency and downright value to an airline. It is inconceivable that they have taken so long to develop. The foregone value will never be recovered. As an industry, we must find a better way of bringing developments such as digital data and the EFB to the industry, successfully and more quickly. The formula is the same for the industry as it is for an airline. Consideration of the business needs, a purpose and then the small matter of implementation.

The EFB remains an enabler, not a panacea. Its success is in the efficiency it facilitates for the business in smartly designed and integrated systems, driven by business need and, a focus on the business, not just the flight deck. While most projects will not approach the pure quantum of the DCF discussed earlier, everyone can enjoy ROIs of a similar magnitude by changing nothing… save perhaps a slightly different perspective.