10.2 Cost
One of your major concerns as a manager is cost. Most managers will ask, "How will my costs change by using an open systems approach?" This question has spurred activity toward developing a cost model for open, COTS-based systems, although no complete models exist as yet. Today, most of the data to answer the question of cost is anecdotal, but it should not necessarily be discounted.
We cannot tell you exactly how your costs will change, but we can just about guarantee you that the distribution of your costs—your cost profile—will change. Initial development investment costs could increase, but life-cycle costs could decrease.
10.2.1 Cost Considerations
Examples of areas in which costs could increase are
Training for open systems and use of COTS products
Market research
Selection of standards
Standards profile development
Evaluation and selection of COTS products
Some life-cycle costs, such as testing, could increase; testing becomes a continuous process driven by product upgrades and changes in the marketplace, in addition to the normal, user-driven system upgrade pressures. Because of the frequent turnover in the marketplace, there will also be continuous market research and product selection activities.
The savings you may achieve depend on, among other things,
The breadth of application—how common an application is across systems, for example, a word processing application is very common
The time interval over which costs are amortized
The number of shared instances over which costs are amortized
Although cost amortizations improve over a longer period of time, this must be balanced with the shorter time periods that accompany technology insertion and the length of time a given item will be available and used.
Managers may realize cost savings in design and support, but it may require initial investments to achieve long-term savings. The major savings may arise when it is time to upgrade a system. A properly implemented open system is an evolvable system, but it takes development investment to reap long-term savings. An example of life-cycle costs that could decrease are those associated with maintenance organizations that are no longer needed or at least can be significantly scaled back because of a reduced need for in-house maintenance.
You also need to consider the costs and potential savings associated with specific techniques, although they are going to be more difficult to factor in reliably. Cost factors associated with open, COTS-based systems and that may contribute to a cost decrease are
Software portability
Software reuse
Marketplace participation
Commonality—yielding cost/quantity improvements
One Program's Cost Experience
The Army's Intelligence and Electronic Warfare Common Sensor (IEWCS) program is an example of making an initial investment to reap long-term benefits. After the contract for IEWCS had been awarded, it was decided that the program needed to take an open, COTS-based approach. At the cost of $10 million and an 18-month schedule slip, the program team selected a set of standards and started development, using standards-conformant COTS products. After nearly ten years, including one technology refresh cycle and with projections in hand for the anticipated costs and benefits of a second one, a cost case study was conducted. This study found a total IEWCS life-cycle cost avoidance of $856.6 million, broken down as follows:
Total R&D cost avoidance: $35.0 million
Total production cost avoidance: $388.4 million
Total operations and support cost avoidance: $436.0 million
Total administrative cost avoidance: $6.2 million
As with many programs, IEWCS introduced many other innovations at the same time it decided to take an open, COTS-based approach, so not all this cost avoidance is attributable to COTS and open systems. But certainly the bulk of the R&D and production cost avoidance stemmed from the use of COTS products and open systems, and it clearly outpaces the initial $10 million investment. In addition, IEWCS got more for its money from this approach than it had originally anticipated. Not only did the COTS technology and products give it a better coverage of the communications spectrum than the predecessor systems had provided, but also each technology refresh saw immense savings in size, weight, and processing power of the system [IEWCS 96].
Each of these factors represents either a class of techniques (those available to increase software portability or reuse), a result of taking advantage of competing products or technologies (marketplace competition), or the result of a technology-smart policy (increasing common use of a particular technology and associated products). Done correctly, each has the potential for reducing your costs over a broad range of estimation factors.
A technology cost factor that may contribute to a cost increase is the proliferation of technology insertion. This can happen when a program gets carried away with new technologies or when too many new technologies are tried. Technology insertion might also increase configuration management efforts and reduce commonality savings.
Faster technology insertion may also result from backward compatibility and interoperability and the use of contractor independent research and development (IR&D), as well as standards. The ability to keep up with technology may be critical for some domains, although it must be balanced against the liability of "churning" by changing the system too frequently. The increased speed of system upgrade may reduce costs—after all, "time is money"—but it may also have noneconomic advantages if keeping up with technology is necessary for keeping up with the competition or threat. Of course, each upgrade will still cost money, so, if they come too frequently, upgrades may have an overall effect of increasing costs.
Cost savings from reductions in maintenance—facilities and personnel—come from
Fewer repairs at more detailed levels, as COTS products are more commodity-like; for example, it may be more cost-effective to throw away broken products—because of greater portability, reduced unit costs, or higher reliability—than to repair them at a low level
Increased reliance on commercial support
Reduced costs spent on spares and parts might result from
Competition
Cost/quantity improvements
Amortization of nonrecurring costs
Software commonality and reuse
10.2.2 Costs versus Benefits
Managers need to understand cumulative cost versus cumulative benefit. These are the costs and benefits accrued and achieved over the lifetime of a system. In coming up with total costs to compare, managers must be sure to compare the same cost categories when analyzing the traditional approach versus an open or COTS-based systems approach. Of course, "the same cost categories" are in some cases analogies. For example, costs of programmers for custom development may be compared to costs of product evaluation, licenses, and vendor relationships for COTS-based development, as they are both part of the costs of obtaining software. The point is that you cannot make a realistic comparison if you leave out some of the true costs of either alternative.
Compare total system costs by comparing initial (development) and life-cycle (recurring) costs for the use of standards versus unique interfaces and for in-house or contractor development versus COTS products. The results will vary for each system. Just as with the traditional approach, managers need to predict costs as accurately as possible and to make trade-offs when using an open, COTS-based systems approach.
Among the development cost factors that managers need to compare for open, COTS-based systems versus a traditional approach are
Hardware and software
Nonrecurring production
Allowing for change
Technical data
Documentation
Contractor services
Support
Training, including equipment
Initial spares
Facility construction
Research, development, test, and evaluation (RDT&E)
These cost factors are likely to involve both personnel and other resources.
Life-cycle costs that managers need to be concerned with are summarized in Table 10.1. Life-cycle costs could decrease because of the use of standards-based COTS products. These items are cheaper and available sooner than are custom-developed ones. Replacement parts may be available from competitive sources; the need to sustain
Table 10.1 Categories of Life-Cycle Cost Factors
|
Cost Categories |
Life-Cycle Cost Factors |
|
Personnel |
Operators and maintainers |
|
Maintenance and continuing investment |
Overhaul, repair, replenishment spares, preplanned upgrades, software support and maintenance |
|
Training |
Instructors and material, students |
|
Operations and support |
Documentation maintenance, supply system management, disposal |
current in-house training or maintenance capabilities may be reduced; some tests may already be available; and products may already have been tested to some extent. However, there will still be integration costs, as well as the new life-cycle costs involved with finding replacement products and new technologies as the system evolves.
10.2.3 Budget Adjustments
Taking an open, COTS-based systems approach will have budget implications when you are planning. Among general budget considerations are
Training for open systems and COTS product acquisition
Continuous market research
Selection of technologies
Selection of standards and profiles
Selection of products
Licenses, warranties, and vendor negotiations
Flexibility in procuring and integrating product upgrades
Ongoing test and evaluation
If managers are committed to provide training in open and COTS-based systems acquisition, they need to adjust the workload of their staff. Managers need to consider how turnover may impact their organization's ability to retain knowledge. Also, managers need to plan to continually update their staff's knowledge of technology, standards, COTS products, the marketplace, and, for the government, acquisition reform.
You need to budget for a market research group whose job is to stay on top of the standards, technologies, and products that are relevant to your system. At the least, you will need someone to conduct the surveys and analyses that are necessary to choose the right standards and products for your situation. These services may be provided by your staff or from such organizations as the Gartner Group, DataQuest, or Ovum.
Licenses are a necessity with just about any COTS product. Even freeware, shareware, and open-source software entail licenses. Licenses are a budget item because they have associated costs, but these costs can vary radically, depending on the negotiations you conduct with the vendor. License options range from an enterprise-wide to a per seat basis. Other variations include development versus maintenance versus end user licenses and the level of support to be provided by the vendor.
All these variations are negotiable with most vendors. Therefore, it pays to train buyers and engineers in these differences and to take the negotiations seriously as an aspect that can affect design and engineering as well as cost.
Sound software warranties are a rarity, but they may be worth consideration. Warranties are a budget issue first because they will cost the buyer. In addition, a warranty can expire before the system is ready to be retired. Managers need to budget for extended warranties or other ways of handling expired warranties. Additional costs are associated with purchasing an extended warranty or trying to make repairs without one. Warranties can become a legal issue when they are not upheld by vendors; then you must take legal steps to rectify the situation. Warranties have broader implications, however, because project staff need to read and understand them and plan for their expiration.
Other potential legal issues are data and intellectual property rights and certification liabilities. For managers in the government, government policy mandates and changes in Congress and the administration are potential legal issues.
Nothing is constant but change, and one key to success with open, COTS-based systems will be a mind-set and a plan that demonstrate flexibility. If your system has many COTS products, you may be faced with a product upgrade monthly. Every few years, you may be faced with technology upgrades. In between, there will be changes in the marketplace, such as withdrawal of a product, entry of a new product, or demise of a vendor, to which you will have to react. Having both the frame of mind to be proactive and the contingency plans—and budget—to support your flexibility will be a real advantage.
If the march of the marketplace is constant, so too is the testing that you will have to do in response to that march. New products will need to be tested, upgrades will have to be confirmed, and the resulting system will have to be regression tested, at the very least.
10.2.4 Special Government Concerns
Government managers have additional considerations, such as basic ordering and original equipment manufacturer agreements, and color-of-money issues. Changes in the administration, Congress, or the office of the secretary for the particular federal department, such as the Secretary of Transportation, can influence budgeting decisions.
The phrase "color-of-money" is well understood in both the government and the business world. It means that available funds are typically divided into various expenditure categories. For example, in the DoD, these categories run from basic research (6.1) to maintenance (6.5). Rules stipulate which categories of money can be spent on which activities, including restrictions on funds if they are for RDT&E as opposed to maintenance.
Managers must figure out which kind of money will pay for each activity with open, COTS-based systems. The distribution of money and colors-of-money will change, as illustrated in Figure 10.2.
){kind=link}
Figure 10.2 Implications of the color-of-money.
For example, consider the following kinds of questions.
Do continual technology insertion and upgrades constitute 6.1, 6.2, or 6.3 activities?
Is this kind of technology insertion and upgrade a legitimate use of operations and maintenance money,
Could integration now be considered research and development (R&D)?
Should test and evaluation (T&E) be considered an operations and maintenance (O&M) cost?
Can you set up early maintenance contracts using 6.1 or 6.2 dollars?
or is it something that can be supported only with RDT&E funds?
These questions are as important as changes to regulations, laws, and organizational policies. Unfortunately, there are not yet any definitive answers, and different decision makers seem to be taking different approaches. It will take a while for all the rules and regulations to catch up with the move to open, COTS-based systems.