How to implement a successful EFB project

Author: Wim De Munck, Chief Technology Officer, AvioVision N.V.

Subscribe

How to implement a successful EFB project

Realism, planning and communication are what Wim De Munck, Chief Technology Officer at AvioVision N.V. regards as the keys to a successful project

We live in an environment where we have become familiar with change; change from an analogue world to a digital world, a variety of different cockpits, IT and information systems being combined… change and variety are all around us so the thought that a system might help to tie all of these different realities together would be interesting. But there are also other inputs that have to be considered with respect to any system and its implementation: regulatory requirements, economic requirements, technology that is constantly changing and, of course, we have to consider scale… increasing size: for example, an average flight folder today takes up between 80 and 150 pages. For that, the paper has to be printed; but also the folder has to be maintained and up-to-date copies provided to all crew members.

The electronic flight bag (EFB)
So, coming to the subject of this article, what is an EFB or electronic flight bag? According to Wikipedia, the “Electronic flight bag (EFB) is an electronic information management device that helps flight crews perform flight management tasks more easily and efficiently with less paper. It is a general purpose computing platform intended to reduce, or replace, paper-based reference material often found in the pilot’s carry-on flight bag, including the aircraft operating manual, flight-crew operating manual, and navigational charts (including moving map for air and ground operations). In addition, the EFB can host purpose-built software applications to automate other functions normally conducted by hand, such as performance take-off calculations.” Having been working with EFBs for more than five years, it was interesting for me to see how the wider world sees them. It all boils down to: an EFB is an electronic information management device.

But an EFB is also much more than just that. Depending on who you talk with, it might be seen as hardware, as infrastructure, supporting approvals for STC (supplemental type certificate), as a training support and more; there are a lot of aspects to how and where an EFB can be applied. It’s also a cross domain solution: flight operations or IT will typically drive the process but then Training gets involved as well as quality management and maintenance: the authorities that need to approve anything on an airplane will be involved and, of course, suppliers who will nearly always be affected by any development in an airline or operator. But, most importantly for such an investment, we have to consider how an EFB can help an airline or operator.

What an EFB can do for an airline or operator…
In the first place, and EFB with its supporting system can reduce the problems of human error by reducing the incidence of manual data entry, automatically cross check data (generating warnings where inconsistencies are discovered) and it’s intuitive (easy to use, fool- and fatigue-proof). An EFB can also improve operational processes; replacing and improving existing legacy and failing paper processes, improving data sharing and data collection (think about in-flight weather charts) and offering faster access to smarter, accurate and up to date data. Finally, an EFB can help to streamline processes such as end-to-end and closed loop processes, bring transparency to operations with well-defined auditing and tracing features, and allow for flexibility and growth to cope with future operating and regulatory environments.

… and what it needs to do it
In order to achieve all of that, there are certain EFB ‘must haves’ that need to present…

• It needs to be integrated with back-office systems;
• There needs to be intra-EFB data sharing with integration between various EFB modules;
• It should be intuitive to use with an adapted user-interface for touch and suitable for use in critical phases;
• Data presentation should be smart – filtered, color-coded, etc.;
• The IT platform should be robust… flexible, auditable, scalable and adaptable.

The challenges faced by an EFB project
How hard, then, can it be to implement an EFB; what challenges would you face? To answer that, I’d like first to take a step back to our own circumstances, as a software company operating in the aviation market; a cyclical and volatile market challenged by profitability, very competitive and with low barriers to entry. As fast as volumes increase, revenue is eroded so there is a constant need for cost cutting and additional efficiency. An EFB solution will deliver efficiency but will also drive ever lower costs: and it’s highly regulated and safety driven. On the other hand, we as a software provider are a commercial company that provides a relatively complex product with a number of integrations and partners, with technology changing all the time (platforms change, requirements change, hardware and operating systems change nearly every six months): so the life cycle of what we build is very limited. Added to that, we build software for the aviation market which is a small market with a slow adoption cycle.

So, where do EFB projects typically go wrong? There are often unrealistic expectations on the parts of users as to the timing, functionality and cost of the solution and scope changes can occur during the project –but all-too-often at the last minute. A project usually involves very complex and difficult to anticipate integrations with various back-end systems (some of them non-standard), and sometimes hardware issues with slow decision processes and approvals such as STC. Internal IT policies might not yet be adapted to the mobile environment, there could be cross-departmental issues and the involvement of training might also add another dimension to the implementation process.

Furthermore, we have to deal with problems like software instability – every step needs time whether it’s the integration, the testing or getting the infrastructure ready. The CAA (civil aviation authority) has to be kept in the loop and will often have very specific requirements but not always respond to submissions in quick time. And often, the budgets with which we have to work are very limited, while we also have to try to convert paper to digital but without changing the underlying processes or creating too much disruption… it’s called change management. As a software provider we’re in the middle of all these competing interests and squeezed with high expectations, tight budgets, minimal margins, and long procurement and payment processes. Is that mission impossible? Well, it certainly does make it a tough job to do a good job: but it’s possible.

How to ensure a successful implementation
So, if this tough job is possible, how can we do it? The first thing is that we, the software solution vendor, cannot do it by ourselves; it takes two or more to tango. We need the operators to actively participate in the process and, also, it’s important to learn from experience, especially from mistakes; drawing on that experience, we try to convince our partners – software vendors as well as customers – to not take a giant leap, but to take small controlled steps and set realistic expectations for all stakeholders.

Timing
For instance, timing; this level of project will take time. Moreover, even if a lot of time is invested in, say, an RFQ (request for quotation) process or the contracting phase, you cannot make up that time by squeezing an implementation that would take 9 months into a 3 month time slot to make up for the time lost during the RFQ and contract negociation process. You just have to accept that.

Functionality
Start with the basic functions, rule out tacking every function on a broad front, learn from each basic function step as it is executed, then go to the next step, advanced functionality. This will really help in understanding how the application is used and by using the application you’ll know what you want next. You might have a full pack of ‘wishes’ but the important things are those that will bring real benefit to the business. Don’t try to do everything at once (the Big Bang!) because experience tells us that that usually fails.

Cost of off-the-shelf versus bespoke
Then, of course, there is the matter of cost. An off-the-shelf component, like a software product that you buy, is not the same as a customized, personalized product: low cost means less customization. We try to take the middle road here – to customize for any customers who ask for it but with some re-use of solutions for specific functions.

Change
Another big risk is scope changes; when that happens, we have to redirect ourselves. However, scope changes cannot be avoided because the whole process will involve a lot of learning and discovery, the lessons from which will need to be incorporated in the final solution. If handling changes means that you need extra time, then simply add that extra time (see above); but be prepared for changes – things are not fixed and when the world changes around us we must adapt accordingly. The important thing is the ultimate goal of the EFB. It’s also important to keep the team under control.

Integration, expectation and communication
Any project such as taking on an EFB will require complex integrations (crew scheduling, flight planning) there are so many operations and MRO systems that need to be integrated into an EFB environment. There should always be an SOW (statement of work) established prior to starting, to estimate the work that will be needed, to clearly communicate what will be done and how much time it will take. That avoids any misunderstandings or unreal expectations about the timing and cost. Our policy, borne from experience, is to involve, from the start, everybody whose efforts will be needed or who will have to work with the solution – third party providers, stakeholders, etc. – which is appreciated by the customers. We also push a phased approach; i.e. build something basic, go live with that; make additions, go live with them and so on: one, two or even three phases are not uncommon.

Device decisions and IT involvement
As an outsider to the client’s business, we try to stay out of ‘religious wars’ such as which device to use for the EFB. iPad, Windows, Android; they all have their pros and cons. We currently have two versions of the EFB, depending on what the customer needs and might consider additional platforms. Come what may, it’s sensible to anticipate a technology change every few years or even months. We also find it advisable, at a very early stage, to involve IT because they are critical drivers to make the project successful: they know what resources they have; they can provide the data, they have the APIs (application programming interfaces) and can manage the ‘flight ops-IT’ relationship. In short, they have the knowledge to make it work. They might want to host the system internally or we can host it externally but whichever is the case, you need to have their involvement. If that is left to the end of the project or close to the end they will not react well and might well come up with a number of issues that would have been better tackled during the project rather than at the end.

Phases for managed development
Software instability is another consideration. Changes in software in one place can ripple through a long chain of functions and modules; so it’s good idea to limit the number of changes and accept that certain things might not work in the first phase but can be fixed at a subsequent phase. Of course, if there are critical bugs and major issues we will be able to solve them, but it’s software so users will have to accept some limitations with an off-the-shelf component, probably pending the next release of that product. It is likely that more than one user will have identified that limitation and so the software developer will incorporate updates in the next generation of the package. It’s also a good idea to limit the number of versions and variations – one lesson we have learned is that, managing multiple versions of the software requires additional people with will, in turn, raise the price of the product. We prefer to limit customization or to do it in a controlled way; to stay focused on one or two variations so that everybody can benefit from any changes resulting from an individual customer’s experience. And even more important, we cannot emphasize enough how important it is to stop the request for features months before going live: a quality software product needs time to stabilize after undergoing major changes. No one wants little “snags” and last minutes changes to hinder operations to go live.

Keep regulators in the loop
It’s always a good idea to involve the CAA early and to explain to them exactly what the EFB program involves, even to give them a demonstration, and to show them documentation such as the policy and procedures manual. The sooner you start, the easier it will be with the authorities and, as the approval process can take months, doing it in parallel with the main project will save time at the end.

Budget
There also needs to be a budget for this: it’s a software project with people required to build it, to maintain it, to roll it out, integrate it and more: and it all costs money. But users should ask themselves, ‘what is the real cost; the total cost of ownership?’ and bear in mind that the supplier will want to build a long term relationship so they’re not going to be extortionate with charges. Be prepared for process changes that will happen throughout the implementation; change management is very important, keeping people informed is very important.

EFB is part of the business
And finally, don’t make EFB a stand-alone change, include it in an overall process improvement approach taking into account how it can also bring benefits to areas such as ground handling, load control, dispatch, etc.

Moving from a paper based system with which, for all its flaws and handicaps, people have become familiar, to a digital system that could seem to put them outside of their comfort zones is always going to be a challenge. However, if it’s approached in an organized manner with clear objectives, total involvement and the expectation of variances, it will be a process in itself and, with those affected also involved, will be a shared and strong project for change.

Contributor’s Details

Wim De Munck

Wim has been CTO at AvioVision since inception ‘Day 1’ in 2010 and, as project manager, introduced AVIOBOOK in several larger airlines. He has 25 years’ experience in professional IT consultancy, including System architectures and distributed computing for companies such as: Sun Microsystems, ACUNIA, General Motors and NAVTEQ.

AvioVision

AvioVision supports organizations with systems architecture, technology and strategy. It was founded 2010 and serves niche markets – currently aviation and Government/Police/Parking. Using mobile technology the business offers extensive back-office integration or workflow solutions. The aviation product brand is: AVIOBOOK®. AvioVision has 49 employees based in Genk (Belgium) & Gdansk (Poland) and currently supports 650+ Aircraft with approvals in more than 10 EASA regions + U.A.E.