Evolutionary Acquisition of Battlefield Command Systems

Introduction

A modern army depends more and more on the capability of its command systems to gain superiority over an enemy on the battlefield. The information technology (IT) on which these systems are based provides the ability to collect, assimilate, process, and disseminate vast amounts of information in shorter periods of time than is possible using manual techniques. The proliferation of IT in military operations has lead to a revolution in military affairsthrough the development of new concepts of warfare. On the battlefield, IT can provide a commander with an ability to out-manoeuvre an opponent through gaining knowledge of an opponent’s intentions, making quicker decisions and increasing the tempo of the battle. However, achieving this advantage is not easy, requiring the development of command systems that are precisely matched to the commander’s needs. These systems are difficult to build since they have complex requirements and depend on state-of-the-art technology for their effectiveness.

Traditional acquisition strategies are not well suited to these types of systems, as evidenced by the number of systems delivered late, over budget and with less than desirable performance. The problem is that the traditional approach mandates a sequential approach to development and allows scant opportunity for user involvement, which results in delivery of the end-product usually occurring a number years after contract signature. This approach lacks the flexibility to deal successfully with the many changes in requirements and technology updates inherent in modern system developments, particularly when there is a significant software component.

Evolutionary acquisition (EA) is a relatively new acquisition strategy better matched to the complexities of modern systems development. The phrase build a little, test a little, field a little is often used to describe EA, reflecting the incremental approach EA brings to acquisition. Although EA has great potential, and in many cases will be the only possible course of action, it is relatively untried, at least in Australia. It is important to realize that EA is not a soft option, requires more effort than traditional acquisition strategies, and that there are significant challenges to be overcome if the benefits of EA are to be realized.

An overview of EA

EA originated in the United States at the Defense Systems Management College in response to a realization that traditional acquisition strategies were not producing satisfactory results for command and control system projects [1]. In the Australian Defence Organization (ADO) a small number of C3I projects are currently being developed using acquisition strategies having some EA characteristics. An ADO study has concluded that EA can provide benefits for a wider range of projects, hence EA is now an approved acquisition strategy [2].

The EA strategy adopted by the ADO is similar to that used in the US, but there are some differences, primarily as a result of different project approval processes. The form of EA to be used in the ADO is described here in brief and in detail by Henderson & Gabb [3].

The main thrust of EA, illustrated in Figure 1, is the incremental specification, design, implementation, testing, delivery, operation and maintenance of systems. Delivery of each incremental release increases the overall capability of the system until complete. In this way, users of the system get early access to functionality and are encouraged to provide feedback on functionality and performance. The feedback is used in subsequent increments to shape the development of the system as it evolves to its final form. The overall aim is to achieve an acquisition and development environment that is sensitive to users’ needs.

When EA is selected for a project, it is recognized that not all requirements can be fully defined prior to contract signature; that for various reasons (as described later in this paper) some requirements will change. This is in contrast to the traditional approach where all requirements have to be specified prior to contract signature and frozen before development begins.

The main features of the EA model are as follows:

• An incremental approach. Projects are divided into phases and increments then developed and acquired incrementally as shown in Figure 2. Each increment results in the development of functions that increase the overall capability of the system and may involve the full spectrum of development activities from specification through design, fielding, testing and maintenance. A phase is a package of work for which financial approval is granted. Separate approval has to be obtained for each phase.



• The overall functionality is bounded. The broad requirements for the system as a whole should be known prior to the start of design and development. Despite this, requirements may move outside the agreed bounds during the course of the project, but only in a controlled and managed way. Without adequately bounded requirements it is unlikely that project approval will be obtained (the risks associated with the project will be too high) and it will be impossible to design an adequate system architecture.
• Requirements. The detailed requirements for a minimal (but useful) system and preferably some other early increments will be clearly defined at the outset. Other requirements will be refined progressively during the project.
• A flexible architecture. The system architecture needs to support the functions delivered with each release, including those for which detailed requirements are not known at the outset.
• Users are part of the process. The dedicated involvement of users in the development process allows the requirements to be continuously reviewed. Users also contribute by using and evaluating early releases of the system, often in an operational environment.
• Multiple contracts. The contract for the first phase will often be for a minimal system, plus additional increments if they can be clearly specified. The capability and price of later increments are agreed prior to the start of each phase. It is expected, but not assured, that successive phases will use the same supplier - changing supplier mid-project will usually incur too many overheads.
• Early acquisition, fielding and testing of the initial system. Early delivery is important to allow feedback on the initial design to be assessed, and to engender user enthusiasm. Subsequent releases should follow at regular intervals, usually of three to six months duration.

Characteristics of systems suited to EA

EA is only suited to a limited range of systems that includes battlefield command systems and computer-based systems in general. Some characteristics of command systems that render them suitable to an EA approach are described below. Each represents risk, regardless of the acquisition strategy used.

• Software intensive. Command systems have a large software component. Software systems are often delivered late, over budget, and fail to satisfy fully user expectations.
• Leading edge technology. Command systems must use the latest technology to provide competitive advantage over an adversary. Traditional acquisition models often result in the delivery of systems with obsolescent computer hardware, due to the high rate of technology advancement. Such systems often require subsequent upgrading at substantial cost.
• Humans are an integral part of the system. While the performance of hardware or software may be predictable, the effects of the interaction of users with technology are more difficult to predict. This is particularly true when users are under some degree of stress, as is the case on the battlefield. These requirements are difficult to define accurately. Use of the command system under operational conditions will often reveal shortcomings, leading to requests from users for modifications. Similarly, users will see opportunities for capabilities not originally envisaged, leading to requests for enhancements.
• Systems with a large number diverse users. Variations in the experience, competence and types of users makes defining user requirements difficult, particularly in the area of human-computer interface design. A clerk entering logistics information will have different user interface requirements to a soldier in the field working under the stress of an exercise or battle. The problem is exacerbated when there are a large number of users.
• Systems are unprecedented. Command systems are usually one-of-a-kind and satisfy a unique requirement. It is difficult for users to specify requirements for these systems particularly where they have little or no experience with systems of this type.
• A limited capability is required quickly. Often, operational demands will dictate that a limited capability is required early, and a full acquisition process would not be appropriate.

Benefits of EA

Determining the reasons for a successful project and assessing how much of that success is due to a particular acquisition model is difficult. Projects are complex, involve many staff over a number of years and are subject to many factors with the potential to influence progress. Many successful EA project examples have been second attempts at a project that failed using a traditional strategy [4]. It is impossible to say if these projects would have been successful if EA had been used on the first occasion. However, there is evidence to demonstrate that EA can provide significant benefits for appropriate projects, such as command systems, over traditional acquisition models [5-9].

The main benefits of EA are summarized below:

• Better requirements. Because EA caters for changes in user requirements, there is more scope for incorporating changes during development. The changes in requirement may occur for various reasons including errors or omissions in the original requirements or genuine changes in the operational need. Early use of the system may also stimulate additional requirements, when the users see what the technology can do for them. EA provides mechanisms whereby feedback can be obtained from users and mechanisms to incorporate changes in later increments relatively easily. These mechanisms, which also allow for the removal of superfluous requirements, should result in higher quality and better validated requirements than in acquisition models which resist change.
• More feasible requirements. The fielding of early releases of the system helps users begin to understand what is feasible and what is not, resulting in more realistic requirements [10].
• Better understood requirements. The continuous involvement of users, both in refining requirements for future increments and in providing feedback on released builds of the system, means that the users are genuinely part of the acquisition process. This not only results in requirements that are continuously validated by the users, but also means that more of the acquirer's (the ADO’s project team) and supplier's personnel have an understanding of the actual user requirements.
• Early operational capability. An important feature of EA is the provision of early releases of the system which may be used operationally, and which are regularly enhanced.
• Incorporation of new technology. By deferring design and component selection until as late as possible in the project, EA enables the incorporation of more modern equipment and software. This can result in higher performance and lower acquisition costs, and also reduce the through-life support costs for the system.
• More control and visibility. There are various aspects of EA that contribute to a high level of control and visibility by the acquirer: increased interaction between the acquirer and supplier; the partitioning of development into well defined increments; the release of builds showing clear progress; and the testing and validation of progressive builds by the users. Because of this the acquirer has a clearer view of progress, and risks and latent defects (which may have otherwise been accidentally or deliberately obscured) will often become visible sooner. Consequently, decisions to change the direction of a project, or even to terminate it, can be made earlier.
• Better systems. Because of the flexibility in the EA approach, and the continuous concentration on user requirements, EA should result in better systems than traditional approaches.

Challenges of EA projects

The benefits do not come easily. EA is more complicated than traditional acquisition strategies in many ways, requiring more effort by all involved parties. This, coupled with the fact that command systems have the high-risk characteristics described previously, dictate that an EA project will present many challenges. The challenges associated with EA fall into the following broad categories:

• Management issues.
• User involvement issues.
• Contractual and approval issues.
• Technical issues.
• Requirements issues.

Management issues

EA is more dynamic and more intense than traditional acquisition due to the number of concurrent activities and multiple iterations that occur during the life of the project. Requirements specification, development, test and fielding can occur simultaneously leading to challenging management problems. The number of meetings, reviews, demonstrations and requests for information increases correspondingly. Therefore, the need for skilled and experienced staff may be greater, and the project office needs to be established earlier [11]. Recruiting and retaining adequate numbers of qualified staff may be difficult.

Since there is a greater level of interaction between users, acquirers and suppliers, a better level of communication is required to avoid conflicts and misunderstandings. A partnering arrangement between acquirer and supplier may be appropriate to foster a close, cooperative working relationship; however the lack of long-term funding arrangements can strain this relationship.

Implementation decisions will need to be made during the course of the project as the requirements evolve. It is essential, therefore, that the acquirer’s project team can converse knowledgeably with, and is as competent as, the supplier’s project team on technical issues.

Configuration management (CM) is more complicated in EA projects. There may be three or more builds under consideration at any given time. The acquirer must know the status of the system at all times in order to make informed technical decisions, so cannot afford to leave CM to the supplier.

User involvement issues

The committed involvement of users is critical to the success of EA projects. Users participate in all stages of the project from requirements specification through to fielding and testing. Users must be selected carefully for the benefits of user involvement to be realised.

It is important that users are competent, enthusiastic and available. Users have the power to alter the course of the project so they must have a good understanding of the EA process and how their input will impact the delivered system.

There are difficulties associated with involving users intimately in projects. Not all users have the same views and some may have difficulty representing the views of others. Some users, assisting on a part time basis may not be fully committed to the project. A problem specific to the military is that posting cycles may necessitate a high turn over of staff, affecting continuity. Another common problem is the tendency for users to request enhancements not within the original scope of the project and not strictly required (‘gold plating’).

Contractual and approval issues

Some of the most challenging issues relate to the nature of the contractual arrangements and the approval process.

It can more difficult to achieve value for money in an EA project. Competitive tendering is generally only appropriate for the first phase; subsequent phases have to be negotiated as they arise. A close working relationship and a high level of trust is vital to achieve a satisfactory outcome for both the acquirer and the supplier. This may be difficult since, while the acquirer will have concerns about value for money, the supplier will be concerned about continuity of work and bidding for the next phase.

Delays in financial approval may increase the schedule and break the flow in development resulting in the loss of key staff and additional costs. Good management practices are required to ensure that approvals are gained in a timely manner. It will not be acceptable to wait until the completion of a phase before applying for approval to commence the next phase.

Technical issues

A major technical challenge is the selection of a system architecture - the hardware and software components that establish a framework for the development of the system - that is capable of supporting the incremental addition of functions without reduction in performance, throughout the life of the project. The architecture has to be specifically designed for change [12]. Strategies need to be adopted to minimize the risk of unsatisfactory performance due to architectural limitations. These may include conducting preliminary design studies competitively prior to commencing the first phase. Companies should be selected who have designers with the insight and experience to anticipate future changes.

The use of commercial-off-the-shelf (COTS) products in defence projects is commonplace; they are perceived as providing greater capability for less cost and development effort. They should be chosen carefully however, and subjected to a full systems analysis since there are often hidden costs [13]. COTS products may be difficult to integrate with existing functionality and may not easily comply with security requirements.

Requirements issues

It is widely recognized that the most common cause of project failure is inadequate requirements. The longer that requirements problems are left undetected, the harder they are to fix [14]. In EA projects there may be a temptation to defer work on requirements in preference to proceeding with design. This is likely to lead to increased costs and schedule. EA can accommodate some changes to requirements but the more requirements that are left undefined the greater the risk of unsatisfactory performance. There may even be a temptation to proceed before enough requirements for an initial system have been defined. In this situation it will usually be prudent to defer development and adopt a more cautious strategy, such as prototyping, to develop the requirements further.

To minimize project risk, as many requirements as possible should be defined prior to development. It is also important to use qualified requirements engineers with the skills and experience to develop an adequate statement of requirements.

Command systems, however, are likely to have some requirements that cannot be fully defined up-front for the following reasons:

• Complexity. Some requirements may be missed.
• Requirements change. If the operational environment is volatile then requirements will change.
• Technology. New technology can introduce new ways of operating and new requirements that the users may have difficult defining accurately and completely.
• Interoperability. These systems often have to work with other systems whose requirements and/or design may not be stable.
• Evolution. As the project progresses, requirements will evolve as new requirements emerge and others are refined.

These requirements should be defined to the maximum extent possible, commensurate with the available knowledge and abilities of the users and suppliers. Doing so eases the task of project planning and minimizes the impact on the architectural design at later stages in the project.

As requirements evolve they must be carefully managed to ensure that there is one definitive statement of agreed requirements. Management of requirements includes controlling changes, and the handling of defects and requests for enhancements. Without strict control there is a danger that the number of requirements will increase to an unacceptable level. The complexity of the requirements management task will usually necessitate the use of a systematic, documented process, aided by an automated requirements management tool.

Conclusion

When EA is used effectively, it can deliver battlefield command systems that better match users’ needs, provide superior performance and use new technology to greater effect than is possible with traditional acquisition strategies. EA is likely to be the only viable option for these systems due to their particular characteristics. However, there are significant risks and challenges in developing these systems using an EA approach, which must be addressed for the benefits to be realized.

References

Author

Derek Henderson is employed by the Australian Defence Science and Technology Organization (DSTO). Since joining DSTO in 1991 he has undertaken studies for the Australia Department of Defence in the areas of requirements specification, interoperability and acquisition of information systems. He graduated from the Royal Military College of Science, Shrivenham, U.K. in 1987 with a Bachelor of Engineering degree in Electronic Systems Engineering.