Force Design in the Services: The Development of R&D in the IAF

Introduction

One could easily take the position that research and development processes for weapons and technology in the Israeli Air Force (IAF), and more generally throughout the IDF, are based upon management concepts and organizational structures that are outdated and ineffective compared to their civilian equivalents. There are legitimate responses to this contention – such as that these processes led to a variety of reliable products with long shelf-lives - but the question stands whether or not the balance, between length and ease of the process, and quality of output, is where it ought to be. Our enemies are not bound by the same standards of reliability and safety, and their development processes are more similar to the processes in the civilian world.

In this article I will present the central vectors that have led military and civilian R&D processes to where they are today. The article’s focus will be on the procedural aspects and the organizational structure of research, development, and acquisition in the IAF. The article will point out problems in the development process, including excessively long time tables and cost/benefit issues. After an examination of these problems and how they are solved in the civilian world we will examine ways to overcome them in the IAF.

We will look at where military institutions have lagged behind their civilian counterparts, examine why that has happened, and ask where the IAF stands relative to our ideal. This article will make the case that there is value in re-examining current processes in order to create a better balance between innovation and stability

Changes in the IAF

 The existing development concept in the IAF is the result of a number of different factors. Most centrally has been an effort to strive for achievement while considering the context of the present, the past, and how operating and development practices have affected past events. The IAF was created through daring and creativity, starting with efforts to acquire aircraft and ordinance at a time when Israel was more isolated internationally and less well-off than it is today. More recently its development concept has been based on the IAF’s contemporary need to contend with a variety of threats in different theaters at once. The IAF was and is an innovative organization, but over the years it has undergone changes in its decision-making and structure that have affected its innovative culture.  Some of these changes were the results of a planned decision-making process and others happened as reactions to events.

A central point in the decision-making process came as the result of the Rami Dotan case in 1990.^[2] Rami Dotan was a senior IAF officer who began taking bribes in exchange for adjusting the demands of IAF tenders to favor one provider over another. Dotan was promoted to Head of Aircraft Group and later Head of Equipment Group, all while continuing to accept bribes. The case was eventually disclosed by an involved party as retribution for having been fired.

 A more infrequently discussed side effect of the Dotan Case was the significant change to organizational processes it inspired in the IAF and the security establishment. In the past, decisions regarding budget and platforms used were made by the Head of Aircraft Group in the Equipment Group, and therefore managerial and professional knowledge was maintained in the department. After the Dotan Case it was decided to separate the decision-making and budgeting bodies from those that implemented policy. The Aircraft Group maintained responsibility for execution and maintenance, but the separation between the decision-making body and the one that implemented changes created a major barrier to corruption. On the other hand, requiring approval for non-technical/professional stages of the process made it that much longer. The aforementioned was one of the milestones in the long process of changing the body responsible for force development from the Equipment Group to the IAF Chief of Air Staff Group and having the Equipment Group focus on project development and maintenance.

 Another change was the increased monitoring of procurements by the Ministry of Defense and the Government Procurement Administration. The change expressed itself primarily through the creation of standards for tenders and monitoring of the procurement process. Today, every major procurement process demands the creation of a detailed list of product requirements, the establishment of a minimum number of proposals, and a clear picture of the process through which a choice of supplier will be made. Additionally, due diligence is performed by a third party rather than the purchasing entity. This is a welcome change but one that had unintended consequences that are worth examining.

First of all, military projects take place over significant time and the needs on which they are based are living breathing organisms in and of themselves. Sometimes the requirements for a project change in real time. The rigidity of the rules for tenders harms the ability of project managers to make decisions as necessary for a project’s needs. For example, major ordinance projects can take five to ten years from initial discussions to serial production. We can easily see changes in that have taken place in our strategic and geopolitical environment in the recent decade. Since the Second Lebanon War in 2006 Syria went from a significant enemy state to one dealing primarily with internal turmoil; Hezbollah became stronger and more entrenched, the Iranian threat underwent a radical change following the nuclear deal with the West; and in Gaza a new threat took shape in the form of attack tunnels. Obviously the demands for new ordinance with greater penetration abilities has changed and will need to be accounted for in Israel’s new surroundings.

  Secondly, the tender process sometimes does not fit the needs of the military and has therefore led to processes that do not conform to the strictures set forth by laws. Some force design projects do not follow the stages set forth in theory- operational need, characterization of potential solutions, identification of possible solutions, choosing one solution, and providing that solution to the relevant service. In a significant number of cases today it is projects from the military industry that define operational needs and characterize the required system, rather than the other way around. The military industry benefits from a long collective memory as individuals who have spent years in the military eventually switch to work in the private sector. These people have a deep understanding of military needs which, together with technological knowledge (the combination of knowing ‘what is needed’ and ‘what is possible’) allow the industry to initiate projects and bring them as ready-made proposals to the military.

In such cases an effort is made accept and justify the process post-facto. Operational needs are written to confirm the need for the system, and a characterization is written mostly based on the proposal that came from industry. In such a case, it is impossible to go to tender as the product is the intellectual property of the industry and, in the case where going to tender would reveal industry secrets, it is necessary to enter a sole source supplier agreement. Sole source agreements are theoretically for situations in which there is no alternative supplier of a product, and going to tender would not offer alternatives.

 Another significant change was the closing of the development division of the Equipment Group. Previously the Equipment Group had a department of engineers working on engineering and research projects related to, among other things, sensors, communications, and the like. These officers served as a center for professional knowledge and organizational memory. Many went on to work in academia and as developers in private industry, a statement of their professionalism. Over time the department morphed into one focused on UAVs and its role changed dramatically. Today the Equipment Group has only a few team members working on engineering development. The professional engineering knowledge has mostly transitioned out to the private sector as workers have left and the role of the Equipment Group has centered around project management and maintenance. Thus the IAF in particular and the IDF in general lost its knowledge and reputation for being a center of technological engineering. At the same time, this trend has intensified the industry's influence on decision-making.

Another change is the increase in requirements for safety standards which took place in response to a number of events over the years such as near collisions of aircraft, crashes or problems during take-off, combustion of fuel during refueling, and more. The increase in safety requirements brought with it a reduction in willingness to take chances and make mistakes. Project Storm is an example. In 1969 it took three Equipment Group engineers seven months to go through the process of being able to swap the engine of a Mirage with that of a Skyhawk. Today altering the procedure for how often tires must be changed will take more time and go through more approval processes than it would have taken at the IAF’s start to change an aircraft’s engine.

These changes have brought with them many benefits: embezzlement and bribery are much more difficult to carry out than in the past, safety standards in the IAF are among the highest in the world during exercises and combat, and IAF project management has become its own profession and is carried out on the highest professional level. That said, these processes are generally carried out in response to safety failures for which people have paid with their lives. On the other hand, analysis of the effects of these rules rarely include the cost of increased monitoring and greater bureaucracy.

There are a number of negative effects these processes have had over the years: Decision-making processes in the IAF take much longer than in parallel civilian contexts; separation between authorities has meant that very few people have perspective on a project from start to finish, enabling them to ensure the process moves in the desired direction. Requirements are set by operational bodies, technical qualifications are set by weapons and technology bodies, priority and budget are set by planning and organization committees, management is carried out by the Equipment Group, and engineering work is done by the military industries.

For example, as things currently stand, if an individual from the operational side raises an unnecessarily strict requirement, it would be difficult for someone from the next body involved to raise this point and factor in the cost of this extra stricture without holding up the project’s timetable. Delays, unnecessary spending, and inefficiencies are increased. These processes, with their shortcomings and advantages, make it difficult for the air force to adapt itself to technological revolution and that too has ramifications.

Global Trends and the Differences Between Civilian and Military Development

The Technological Revolution

 The most significant change in the past 30 years is the way in which technology has entered the consumer space and served as an engine for growth. The personal computer, the internet, and smartphones are the clearest examples of this. This change was the harbinger of a quiet revolution in research and development. In the past, in Israel and abroad, the military was at the forefront of investing in and advancing technology. Today however, budgets for R&D in the civilian world have grown so much that today Samsung’s investment in R&D alone is similar to that of Israel’s entire security budget, only part of which is designated for R&D.^[3]  The security establishment maintains its edge with a number of technologies which are not yet in wide use in the civilian world, yet remains behind in the fields of communications, processing, and more. More critical is the fact that these technologies are now available to our enemies, as time goes by force design takes longer, while the pace of development in the civilian world is picking up.

Today, a terrorist can purchase equipment to modify a drone so it can be directed to precise GPS coordinates. The reliability of such systems is not as great as their military equivalents, but the systems are much cheaper and their quality is improving quickly. With each passing year the technology available to civilians increases, and its quality surpasses that of the military. If Elbit’s pilot helmets were once considered the apex of heads-up display technology, then today similar technologies are already available in civilian virtual reality systems with higher resolutions and other capabilities than in aircraft platforms. The day is not far off in which a 3-D printed drone, controlled from afar, will give terrorists strategically significant abilities.

An additional significant factor is the shelf-life of technological systems today. Analog systems of the past lasted for many years in harsh conditions. With the digital age came new difficulty. Digital systems last only a few years and generally are not as reliable as analog systems. The security establishment’s primary way of dealing with reliability has been to ensure proper back-ups and system updates, like updating older processors or producing new specifically military-purposed ones. In the civilian world this issue is less pressing and the solution is simply a higher turn-over rate for systems.

Goal Setting Paves the Way

 Civilian companies are characterized by something that is a blessing and a curse: revenue as king. Most decisions can be evaluated by simply examining the so-called bottom line - revenue vs. expenditure. The problem is that in certain circumstances this dynamic can discourage innovation, since innovation is only valuable and supported if results are seen clearly enough in a short enough time frame.

The benefits of a ‘bottom-line’ perspective are the most interesting. Profit and loss are easily measurable and thus serve as the clear indicator by which organizations judge performance. Companies must examine themselves often and correct mistakes, or risk truly seeing the cost of mistakes.

An interesting illustration can be made by comparing Blockbuster and Netflix. Blockbuster was one of the largest companies in the world with tens of thousands of branches around the globe when VHS tapes & DVDs were popular. As widespread internet use spread Blockbuster didn’t foresee the changes it would imply for their business model and quickly collapsed. Netflix took Blockbusters place, creating a more flexible and efficient model for providing movies directly to consumers.

The most interesting point is not in the above but rather that Netflix understood that its survival depended on quick decision-making and adjusting its business model as necessary. Since its founding the company went from one that mailed its customers movies to their homes to a central online provider of digital media, and then even to become a leading creator of content. This pace of development is only possible when a company can evaluate its decision- making regularly, testing out new directions and leaving behind failed approaches.

In the military there are several goals, not simply an increased bottom line, and not all are equally measurable. On the one hand money plays a role because budgets are limited; on the other hand the military’s goal is defense and not profit. The question follows - how does one measure security? Perhaps the feeling of security among the general population? Number of deaths? By the range of freedom the government has in which to make decisions? All of those answers are correct but together are insufficient. The right approach to evaluating security is an open question, difficult to answer, and problematic for the military decision-maker who wishes to evaluate the options before him on a given day. The decision-making process is even harder given it must be weighed to factor in budget and security simultaneously, and when there is no clear way to evaluate past decisions in order to improve future decision-making.  

User-Centric Approach in the Military and Civilian Worlds

 A clearly defined target client and goals allows civilian companies to manage projects in such a way that ensures product-market fit. This is because managers see from one end of the process to the other, starting at understanding the need, through development, until contact with customers. This means that customer experience in the civilian and military worlds are very different. Customer experience and product design are central considerations for commercial companies, not only because it leads to more sales but because it is possible to begin with when product managers understand the implications of different choices for end-users and ensure those implications are understood by R&D teams.

 Developing military systems is radically different. Project managers in the Equipment Group are only partly familiar with the considerations that led to a request for some product or another to be developed and he has limited means to communicate with end-users and understand their concerns.

In the military the emphasis is generally put on the delivery of a functioning system that meets criteria set out rather than on the end users’ ability to use the system in a way that maximizes its potential. The reason for this is clear. When a system is seen to have a direct influence on the security of the state, it's hard to imagine compromising a function that might in some way be related to saving lives. This is even more complicated when we factor in that most systems are in use for a decade or more, and it is difficult to predict the changes in the way the system will be used in the future.

One result of the above discussion is the process of system characterization. System characterization in military contexts usually centers around what the end-product needs to be able to do. All possible uses and contexts are sketched out so that the system will function in any circumstance. Comparatively, in civilian systems the discussion centers around the minimal function a system can offer that will still give value to the user (minimal viable product). The difference between these two approaches is not simply semantic; its implications are for two very different development processes. The first approach leads to a broad solution that is later updated as needed whereas the second approach develops a minimalistic solution but at a much faster pace and for an end-product that is easily upgraded and holds as central user friendliness. That means a leaner system that is tailored to the user at the end of the process but demands a higher level of engagement with the end user and a willingness to adapt to changes along the way.

Let’s examine a concrete example of the results of a process in which the author was close to the process the whole way through. In the 1980s the IAF built a command and control system for planning and controlling of its air missions. The system was developed and built relatively quickly, and led to a significant improvement in IAF capabilities. Despite this, many users complained of a system that was hard to use, and demanded too long a training period. The author and another officer did another investigation in 2006, and found that most of the system’s functions were not in use and had not been tried in 20 years. Around that time the IAF began the process of replacing the aforementioned system with a one that would utilize newer computing systems.

The results of the investigation that the author conducted were passed on to the relevant players but again a system was put in place with impressive capabilities but which put only a secondary emphasis on user friendliness. The system was characterized by a modular system, the idea being that a framework would be established upon which things could be added as necessary, and the end product was somewhere in between models found in the civilian and military world. These characteristics shouldn’t be taken lightly. If one asks an air force operations officer about his or her use of the system, one will find that much of their time is spent operating the system and a comparable amount of time is spend learning to use the system itself. Reserve officers generally minimize the number of functions they use and aren’t capable of using the system creatively or responding to changes quickly enough.

The existence of a function that users don’t use, unlike functions that don’t exist at all, eventually take away from the system overall as they can be a source of confusion or distract from functions that are used more. Underutilized functions add steps to a process that should focus on efficiency and command and control. Today the system is set to be switched for a more variable and user friendly one. We can only hope that the project will be managed from one clear perspective that addresses the needs of the IAF in the 21st century.

Project Manager vs. Management Team

 We have already discussed the differences between the private and military sectors with regard to organizational structure and decision-making processes. In the private sector there is a project manager whose role is to analyze and respond to the needs of the user throughout the project’s lifetime, ensuring that the R&D professionals respond to those needs, reflecting them in the project. There are two approaches to the project manager’s position in relation to the product and the client. Project managers who are closer to the R&D side are those generally operation in a market with higher technical demands and with products for business (and they are generally more similar to their military counterparts). Project managers who are closer to the market are usually those working on consumer products, a market in which the technical demands are lower but user experience is more important and the risk in the marketplace is higher.

Wherever the product manager may fall on this scale, in the civilian world there is one person connecting the client and the developers. The decision-makers above the product manager are generally the CEO, head of marketing, and/or head of R&D. A good product manager is rare find and the price paid by organizations without one is high because the product manager has great influence on the outcome with relatively little oversight. Therefore getting the right person in the role is critical.

In the air force the product need is defined by the operations body which, as a general rule, is not the consumer/end user but rather a representative in place of the end user. Often this is someone from HQ with an operations background who understands the need for the product in the field. A weapons and technology officer will usually work to translate the need into product characteristics while working on a number of projects in parallel. Projects are managed by officers from the Equipment Group and the work is largely carried out by the military industries (which have their own project managers and R&D teams).  A number of the projects are handled internally within the service, in particular projects dealing with programming. In such cases there is an IAF development team managed by an Equipment Group officer or a specialized team. The concept is to have a broad management team with multiple management layers (There are about three layers in between the consumer and the developer) allowing managers to work on multiple projects at once.

            Project management in the civilian sector involves one individual managing one product process through all of its stages, which include the tasks of operational, equipment, and technology representatives in the air force. In contrast, project management within the air force involves multiple project managers working on a number of products, not seeing one product through all of its stages, but rather each manager overseeing his stage of the process for each product.

            Arguments can be made in one direction or another about these management approaches, but it’s clear that each one must be evaluated with regard to how appropriate it is for the air force, acknowledging that civilian management systems are not necessarily a good fit for the service or at least must be adjusted. Using the MVP method, for example, does not fit with the existing organizational structure of the air force. No air force manager has the ability to carry out the narrow product characterization and to turn it into a work plan. This is because operational officers aren’t part of daily management, weapons and technology officers come from operational backgrounds but don’t have the administrative and technological background needed for characterization, and Equipment Group officers don’t have perspective on the operational side of the project and their abilities to manage work being done in the defense industry is also limited. Minimal product characterization is by nature highly concentrated and therefore fit for other organizational structures.

            Another different management approach is Rapid Development Management as it exists in the IAF today. The speed of this process is mainly a function of a given project’s prioritization and reduced times in between the relevant meetings; the management process and the division of responsibilities do not actually change. In order to more effectively carry out rapid development there needs to be a change in concept as well as the availability of the right people at the right time. Two starting points might be full budgetary freedom and reducing bureaucracy. Successful efforts have been carried out in the past such as in 1991 during the Gulf War when the USA developed the GBU-28 in 28 days.

            In summary, we have examined substantial differences between development in the IAF and in civilian companies. These differences are expressed throughout every stage of development from need assessment through implementation and maintenance. Two opposite responses can be observed to technology’s having become more complex and quick to change. In the civilian world the approach to R&D has been to make processes more condensed, providing at least a sufficient product as quickly as possible and then developing solutions and further development based on feedback from users in the field, releasing updates regularly. In the IAF, and more generally in air services around the Western world, the approach has been to outsource most development to private industry and to restructure organizationally to better provide for monitoring and product need characterization. The increase in technological complexity has been addressed by lengthening the development process so that the final product most closely fulfills the needs of the service and promises a longer shelf-life.

Recommendations

 There are many steps that can be taken to improve current development practices without hurting the military’s requirements for a reliable and high-quality product. Among those steps are:

• Adaptation of the IAF’s organizational structure to quicker and more flexible management practices for those projects undertaken through the regular channels; it is worth exploring the possibility of changing the balance of power between management bodies and/or combining them in certain cases. It would be interesting to examine the effects of greater responsibility and a deeper understanding of operational and intelligence factors on Equipment Group officers. Alternatively, to examine the effects of broader management and technological training, and an expansion of the roles of weapons and technology personnel which would allow them to focus on management.
• The creation of bodies and procedures within the service to support bold projects and rapid development for small or pressing projects. The intention is to create innovation islands that will work outside the usual paradigm of services and will allow development teams to work on projects autonomously. There were two efforts in the past, once in the Weapons and Technology Group and once in the Equipment Group, to create innovation centers that would combine technological, operational, intelligence, and managerial experience, thereby allowing the initiation of projects without long approval processes and spans of time until an initial model gets off the ground. The author served in both those bodies. These two bodies did manage to introduce innovation but it is beyond the scope of this work to list the extent of their projects. Ultimately these bodies were closed due to budget cuts.
• Setting organizational goals that will lead to changes in concepts - Today there exists in the IAF an award for efficiency in maintenance. Maintenance personnel are encouraged and compensated for finding solutions that will bring about improvements and increased efficiency within the organization, in particular where budget and safety are of concern. Personnel saw their roles in a new light and searched for those areas in which there was room for significant improvement, and in the past years a great number of recommendations regarding improvements in operations were received. If we take this idea and consider it together with the disparities we’ve already discussed between the service and the private sector, we can imagine interesting results. A significant factor in costs of force design projects is a reflection of the costs of acquiring new platforms and systems. It would be interesting to see what would happen if the IAF demanded the development of a system with similar capabilities of current ordinance but at 20% lower cost. A drop in cost would likely change the conversation about the shelf life of each product and thus the length of product development. The outcome would be that development in the IAF would become more competitive in comparison to the private sector and would assist in maintaining the service’s qualitative advantage.

^[1] Capt. (res.) Erez Ne’eman expressed that the contents of this article are his own personal opinions alone.

^[2] Benn, Aluf. “Three Months into his Career at Haaretz, Aluf Benn Exposes the Rami Dotan Affair and gets Caught up in the Conflict.” Haaretz, May 27, 2009. http://www.haaretz.co.il/misc/1.1262935 [Hebrew]

^[3] #6 in the article