Previous PageTable Of ContentsNext Page

8.0  TECHNIQUES


8.1  Through Life Business Case Analysis
The Business Case is the principal document in a decision package that evaluates proposed actions to achieve some functional objective. The Business Case has three primary uses:

The Business Case documents the functional process improvement effort and presents the business case as part of the decision package. It serves as the primary instrument in deciding which approach, if any, should be further evaluated in detail for approval. Gross measurements and estimates of cost and benefits data are usually all that is available early in the project. More data is available if there has been a complete activity based costing effort.

The Business Case presents the economic analysis various alternatives. Economic analysis is a systematic approach to the problem of choosing the best method of allocating scarce resources to achieve a given objective. A sound economic analysis recognizes that there are alternative ways to meet a given objective and that each alternative requires certain resources and produces certain results. To achieve a systematic evaluation, the economic analysis process employs the following two principles:


8.1.1  Background
The following section was adapted from a study, "Business Case Model for The DoD Logistic Community: A Guide to Business Case Development completed by ManTech, West Virginia for the U.S. Department of Defense Logistics Reinvention Office (LRO).

In today's hectic, complex world, decisions are often forced, supported by little, if any analysis or documentation. Yet, we are constantly asked to render decisions that can have both short and long-term consequences. In the NATO Alliance, such decisions can have dire results and tear at the very fabric of "freedom" because our decisions ultimately effect "Defense Readiness."

Despite the dire consequences of poor decisions, the practice of preparing, reviewing, and making decisions that are based on sound analysis or business case is infrequently applied. A properly prepared business case represents an effective tool to reverse this practice and foster timely, and accurate decisions within the NATO logistics community.

This Section is intended to assist all within the NATO logistics community who have a need for preparing, documenting, and evaluating alternative approaches as well as those ultimately responsible for decision making and directing a course of action with the development of a business case.

This Section provides the information needed to use business case modeling as an effective tool to manage change. It is simple, straightforward, and will serve as a road map for formulating a sound business case. Use the guidance provided here to create a sound business case that is also consistent with NATO Logistics Strategic Goals and Objectives. There are three simple steps:


8.1.2  Introduction
Business cases are an integral part of every competent manager's decision process. They are frequently informal and often undocumented. Such analyzes and models consist of the manager's assessment of financial, procedural, organizational, and performance implications of a proposed change. Informal as it may be, this process yields information needed to support a business decision and is therefore a business case. In general, the more complex the change of the organization, the more formal and rigorous the business case development process should be.

Within NATO, formal business cases are critical elements of on-going Business Process Reengineering (BPR) and other improvement activities, and related decision-making processes. Despite significant guidance published to date, business cases continue to be misunderstood and inconsistently applied within the NATO community. Ineffective applications of a business case are found throughout the organization, such as, being used after the fact to justify technology decisions, in-process implementations or projects, and related sunken costs. They are also improperly used to determine the value of completed technology or software development projects. This section will help in avoiding these traps.


8.1.3  Purpose of this Section
This section's purpose is to bring consistency and understanding to business case development efforts within the NATO logistics community. It highlights the process steps required to produce a simple, straightforward and easy to understand Business Case Model. The target audience is NATO logistics functional experts, program management, and others tasked with implementing change and making decisions about change within the NATO logistics community. Its objective is to promote the use and consistent application of business cases as the tool for the evaluation and management of change within the NATO logistics community.

The Need of the Decision-Maker

The need of the decision-maker is for timely, consistent, complete, and accurate information. The business case facilitates making decisions consistent with the organization's strategic goals and objectives, as well as keeping in compliance with the NATO governing directives. It provides a formal yet flexible system to manage individual initiatives more efficiently and align them with NATO initiatives underway.

This section, when properly applied, will assist the decision-maker to:

Align proposed investments within their purview with NATO mission priorities and NATO component strategic plans.

Present management with relevant decision information in a consistent framework that will allow comparison, evaluation, and prioritization of competing and overlapping change initiatives.


8.1.4  Business Case Modeling Fundamentals
This section provides the fundamentals needed to integrate business case modeling into the management decision-making process. It answers the questions:  What, Why, When, How, and Who. This section provides additional references for business case preparation and on-line training.


8.1.4.1  What is a Business Case?
A business case is a tool used to manage business process improvement activities from inception through implementation. A business case is a document that identifies functional alternatives and presents economical and technical arguments for carrying out alternatives over the life-cycle to achieve stated business objectives or imperatives. Each business case will look different depending on its application. However, essential ingredients remain constant. Essential ingredients include functional process descriptions, technical architecture descriptions, cost projections, action plans, measures of performance, and risk assessment for each alternative under consideration. Its focus is on process improvement and reengineering, not on technology insertion. Technology's role is to enable or support meaningful process change. To be effective as a management tool, a business case must never begin with any predetermined notions of the outcome or predetermined technological solution. It must be completely and totally unbiased in its conduct and presentation.


8.1.4.2  What is the Role of Business Case Modeling in Logistics Reengineering?

Linkage to Overarching Plans and Visions

Linkage to overarching plans and visions is of primary importance. Each business case must show linkages to NATO goals and strategic objectives.

A business case should include activity models that focus on relevant logistics functions. This enables the decision-maker to learn if there are any overlaps in activity coverage, and potential contentions in project dollar allocations.

Business cases should support the organizations' strategic goals and objectives. Within the NATO, this means that all business cases must clearly support the following:

To this end, each business case and the included alternatives must:


8.1.4.3  When Should I Prepare a Business Case?
Prepare a business case when any change is anticipated in a business process or supporting technology. For significant changes, the requirement to prepare a formal business case and its actual preparation should occur as early as possible in the change planning process. Formal business case preparation is imperative:


8.1.4.4  How Do I Get Started?
Establish a dialog among all of the parties involved. Those designated to prepare the business case must know what is important to the decision-maker. They must also understand the initiatives and alternatives to be included in the business case and gain an understanding of how the business case will be used to arrive at a decision.

The decision-maker should identify the critical elements of the decision process for those who will develop the model. Preferences for presentation of alternative comparisons should be discussed, agreed upon, and documented. Specialist and/or training, if any, required to support the process should be identified and scheduled. Activity modeling, financial analysis, and Activity Base Costing (ABC) are areas that are most likely to drive the need for training and or support from specialists.


8.1.4.5  What Should My Model Include?
Business cases are about choice. They must present the decision-maker with alternatives and the consequences of those alternatives. In general, not less than three alternatives should be presented. The figure at right provides the general information that should be included for each alternative.


8.1.4.6  Who Should Prepare a Business Case and What Should They Know?
The most important requirement is to be thoroughly versed in the organization's processes and activities, and corresponding goals and objectives as they relate to the business case. Know what is important to the decision-maker. Activity modeling and financial analysis skills are also required or alternatively, specialists may be used to assist in these areas. Use of specialists, when available, is highly recommended. They can significantly reduce the time required to prepare a business case.


8.1.4.7  What Should the Decision-Maker Know?
The decision-maker must have an understanding of how to use the business case and how it will apply to the expected change. The decision-maker does not need to understand the detailed analysis techniques; however, he or she should have a basic knowledge in financial areas such as return on investment and discounted cash flow. Matter-of-course knowledge of business process reengineering topics, such as activity modeling, aids in using the model to make good decisions.

Dos and Don'ts of Business Case Development

· Do include a business case as an integral part of BPR. A BPR is recommended prior to IT acquisition.
· Do establish a business case development team that is independent of those who are responsible for the project.
· Do keep IT-related measurements used in defining IT investments in terms of functional requirements, identifying which outcome-based performance measures accurately assess achievement of requirements.
· Do continuously ensure that the linkage between investments and mission accomplishment is maintained.
· Do mold the business case development process into the entire organization's way of planning and making investment decisions.
· Do directly tie the use of the business case process with funding of any initiative.
· Do adopt a timeline for completion of business cases prior to budget completion to allow approved alternatives proper funding during the next budget year.
· Do prepare a business case model prior to the selection of any alternative or technological solution.
· Do not prepare a business case in support of decisions already made or in support of implementations already in progress.


8.1.4.8  What Else Should I Know?
Several barriers exist to preparing a business case. They fall within four categories:  vision barrier, people barrier, learning barrier, and operations barrier. The vision and learning barriers have been previously addressed. The people barrier occurs when individuals within the organization may, for one reason or another, inhibit development of a business case. This often occurs when the business case represents a beginning in the process of change. An operating barrier exists because of how the organization works. One such barrier may be cost accounting systems. The political climate, and procedures and rules required by the military may also cause an operating barrier. Similar barriers may exist to the implementation of changes addressed by the business case itself. If so, the barriers and the plans to overcome the barriers should be documented within the business case.


8.1.5  Business Case Model Minimum Report Requirements: A Simple Structure
The table displayed provides the recommended outline that all business cases should follow. Each outline element is briefly discussed to provide an understanding of needed content.

Typical Business Case Table of Contents

1.0  Executive Summary
2.0  Boundaries of the Business Case

    2.1  Goals and Vision
    2.2  Context and Perspective
    2.3  Functional Performance and Metrics
    2.4  Initiatives Considered
    2.5  Baseline/Alternatives Considered
    2.6  Key Assumptions
    2.7  AS-IS Activity Model

3.0  Discussion of Alternatives

    3.1  Alternative 1
    3.1.1  Functional Process Description
    3.1.2  Performance Impact and Metrics
    3.1.3  Technical Architecture (optional)
    3.1.4  Cost Projections

      3.1.4.1  Investments/Action Plans
      3.1.4.2  Operational

    3.1.5  Risk Assessment
    3.2  Alternative 2

4.0  Comparison of Alternatives

    (Graphical Presentations Preferred)
    4.1  Functional
    4.2  Performance
    4.3  Costs
    4.3.1  Investment Costs
    4.3.2  Operational Cost Savings

5.0  Conclusions, Recommendations and Issues


8.1.5.1  Executive Summary
The Executive Summary is the foundation for senior leadership briefings and must answer the "So What?" question. The Summary should recognize sponsor and funding organizations and describe the approach used in broad terms. The Summary's objective is to establish confidence in methods followed during business case synthesis and preparation, and should focus on the results, not the activity behind producing them. Make sure that this addresses the "Why" of doing the case. The question of "So What?" is met by explaining benefits of approving an alternative and its initiatives, or emphasizing the need to continue.

The developers should answer a set of questions. Does the Executive Summary contain all basic elements? Can it stand by itself? Is the business case uniquely identified so that it stands out among others? Are all acronyms explained? Is it short (two pages or less)? Is it absolutely error free? Finally, does it support the need to continue?


8.1.5.2  Boundaries of the Business Case - Goals and Vision
As stated earlier, all business cases should support strategic goals and objectives put forth in the NATO Strategic Plans. Business cases should support implementation of the "TO-BE" State identified within the NATO Alliance and component vision, mission, goals, and objectives. Explain why the business case is being prepared. Identify sponsoring and funding organizations. This explanation of why the business case was done can reinforce the idea of aiding NATO in its transition to a performance-based organization. The starting point for identifying the business case subject is usually a proposed or planned action, but the business case's subject ultimately is defined in terms of objectives.

The Importance of a Stakeholder

A stakeholder is anyone who has a vested interest in the organization's efficiency and effectiveness. This interest gives them the ability to affect an organization's management, policies, and objectives. Typically, there are four main stakeholders of a function:

    1. Customers, or recipients of output and services produced by a process.
    2. Suppliers, or providers of inputs used by a process.
    3. Regulators, or overseers of a process.
    4. Process Participants, or employees and managers that form the product or service.

Stakeholders express their interests as outcomes. Outcomes can drive process behavior and drive investment and operating decisions about these processes or their outputs. Persuading process customers and participants, who are the most visible stakeholders, to accept change is the process owner's high order objective. While across the board acceptance is highly desirable, some stakeholders may not accomplish everything they want. The depth and breadth of firm commitments from stakeholders reflect downstream potential for process and organizational change, resistance, or acceptance.


8.1.5.3  Boundaries of the Business Case - Context and Perspective
The context and perspective should match with the context activity model developed during Functional Analysis. Define what is and is not being considered in the scope of this business case, and reinforce whom it is for and what decision is helped by it. Identify potential stakeholders, including what organizations will be affected, and who plays the biggest part in the failure or success of the alternatives. Stakeholders should be identified before functional analysis.

Once identified, stakeholders must participate in the analytical process, whether in an active or passive mode. The business case must address how carrying out an alternative will affect stakeholder interests, and vice versa. This preempts actions by those who initiate regional changes that may drive other downstream changes, while having no authority to make that change happen.

Answer the question "What does it take to fulfill our mission and achieve our vision?" The answers to this question describe catalysts of success or failure in the function's mission. Stakeholder requirements about products and services drive factors that are critical to the fulfillment of mission and achievement of vision. This is markedly true of customer requirements. These cannot be decided in a vacuum. Participants in functional analysis of activities must understand and document the impact these changes will have on employees, customers, and others.

Taking various stakeholder perspectives, scrutinize pro forma initiative events, deliverables, workflow, and integration opportunities. As they arise, examine resource and planning contentions to learn if any transition event or implementation would have a significantly adverse affect or outcome. On a best effort basis, recognize uncertainty in the plan or its outcomes, quantify transition and stakeholder risks, use previous lessons-learned that apply, and delineate any potential benefits or values. Identify underlying causes (e.g., drivers, inhibitors) of risk, and outline past successful strategies for dealing with these type of causes. Integration opportunities normally focus on shared data assets or continued use of legacy systems as migration backbones. Learn if there are established, clear lines of (internal) data ownership, custody, and access.

Develop impact statements, positions that outline concerns and recommend suggested courses of action that could mitigate, or at least lessen, impact or risk. These impact statements may also include suggesting tailored messages that would resolve uncertainty in affected stakeholders, or recommending certain time frames that may increase chances for success. Section stakeholders through resolution of impact statements, with an aim to produce impact agreements. Affected stakeholders must be given an open and fair forum to express their concerns and disagreements. Reach a consensus position; one where not everyone may agree, but everyone can support, even if their support is passive.


8.1.5.4  Boundaries of the Business Case - Functional Performance and Metrics
Measures identified within the Program Manager's business case must be subsets of the NATO Logistic Strategic Plan or other relevant documents such as Component or Agency Strategic Plans.

The Primary Measure May Not Consider Cost

Although cost is a primary measure, it is not sufficient to be able to say that the TO-BE is achieved by accomplishing this measure alone. Additional measures may be used to relate to the organization's overall goals and objectives. Performance measures are used to distinguish and weigh primary benefits received from the activity generating the measure. Meeting the desired level for these measures could imply that the level of benefit the organization seeks was attained.

"Not everything that counts can be counted, and not everything that can be counted counts." Albert Einstein

Performance measurement is the assessment of effectiveness and efficiency of activities, operations, and processes in support of achievement of an organization's missions, goals, and quantitative objectives through application of outcome-based, measurable, and quantifiable criteria, compared against an established baseline.

Good management practices require the establishment of clear organizational hierarchies of goals and performance measures. Goals and measures used at lower organizational levels must be linked to NATO's mission/strategic goals. Mission benefit, not cost and schedule constraints, must be the overriding measure of success for any IT project.

There are four classes of performance measures used in both functional and economic analysis:

Discuss what organizational performance measures are being used and how they are influenced by the initiatives, preferably through use of a selected metrics from the NATO Logistics Strategic Plan or Agency Plans.

A performance indicator is a factor used to assess speed or responsiveness, quality, or cost of a process, input, output, or outcome. In effect, it is the unit of measure for a performance measure. Indicator definitions can be used to compare projected outcomes of each alternative, as well as how the indicator will be maintained for continued feedback into the success or failure of the selected alternative once implemented. A brief discussion on the costs and benefits of collecting this monitoring information should be included, especially if a method of collection must be set up to facilitate the new metric.


8.1.5.5  Boundaries of the Business Case - Initiatives Considered
Develop high-level plans that describe new or different approaches to doing business according to performance targets and business objectives. It is likely that several improvement ideas and plans will be identified. However, not all of them can, or should, be put into place. Find possible ways to do each approach and then parse these into achievable packages of work and results. Project-level groupings of work that produce distinct deliverables are named initiatives. Initiatives can vary in scope and size. There must be a narration of each initiative included in the business case. Describe how strategies will be put into place in terms of specific actions, timeliness, and resources. Evaluate initiatives against demonstrated implementation experience or other's best practices. Identify and assess each candidate initiative's risks and define different paths to abate such risk. Match each candidate initiative to common barriers or characteristics.

Barriers to successful implementation, previously mentioned, refer to those situations that tend to be outside the span of control of those making change, or that have prevented desired outcomes of previous attempts to adopt new ideas or technologies. Similar implementation efforts must find ways to overcome or bypass these barriers to achieve closure. For most individuals, change is difficult. Therefore, resistance may be encountered when gathering accurate information from individuals within the organization. These barriers are overcome with proper communication. Explain why certain questions that are being asked can promote a more open environment for dialog. Sometimes there is nothing to do except document within the business case, any issues relating to the people barrier.

Take Care Not to Introduce Bias

Take care not to introduce bias into the process when creating alternatives. Technology initiatives must have a clear relationship to process improvement initiatives when they are combined into a single alternative. Ask this question: "Does this technology initiative enable each and every process change included in this alternative?" If the answer is no, the technology initiative should be excluded from the alternative. This approach will prevent the perpetuation of "pet" technology projects that are impractical or have no real benefit to the organization.

Each initiative must reflect progression (including phased achievement) toward affected performance targets. Convert performance targets into provisional performance objectives. These objectives can frame stepped-investment justification and selection decisions, and drive downstream development of the TO-BE process.

Providing clearly defined initiatives give the decision-maker an understanding of what the business case is about, because in the end, the business case is about initiatives.


8.1.5.6  Boundaries of the Business Case - Alternatives Considered
The objective of functional process improvement is to achieve the vision. Because each initiative considers only one or a few areas for improvement, analyze combinations of initiatives to address each goal. It is unreasonable to study all combinations, because there will be too many. A more practical method is to combine logical packages of initiatives that work well together or portfolios of a set of initiatives with common objectives or goals to form alternatives. As a rule, initiatives sharing common critical performance measures or objectives make the best business case for being put in one portfolio versus another. However, each set of related initiatives must put into place changes that handle the same predicted level of process workload within the planning horizon. Another point to consider is the decision-maker's focus on the business case and the corresponding emphasis to place on each element of analysis across all alternatives. Look at tuning the business case's emphasis in the same way the settings are adjusted on a sound system's graphic equalizer.

The reference for measurement is the status quo, or the baseline. Baseline cost and performance provide threshold values for the cost and performance of alternatives. AS-IS costs and performance measurements revised to reflect any approved changes not yet implemented would provide this baseline. The business case should include at least three alternatives, including the status quo. Each alternative must give functional management a complete view of financial and operational impacts of proposed changes.

Develop total investment cost flow and total anticipated process cost savings flow for each alternative. Quantify total risk assessments based on probability and consequence of failure for each principal initiative activity. Develop an action plan for each alternative, and assemble as a total package for review by the approval authority. Pre-test any controversial ideas with the approval authority or his or her peers. Use economic simulation techniques (e.g., risk-adjusted discounted cash flow) to develop supporting cost schedules.


8.1.5.7  Boundaries of the Business Case - Key Assumptions
Assumptions are necessary in a business case because they are explicit statements used to describe present and expected future behavior upon which the business case is based. Since no one knows what the future holds, assumptions must be used to set boundaries for painting the business case. Example assumptions include future workload, estimated useful life of an investment or system, and the period over which alternatives will be compared.

Summarize key economic and political indicators used for each alternative assessment; also briefly discuss what non-quantitative issues need consideration. Employ a sensitivity analysis or another method and focus on assumptions that are thought or historically demonstrated to cause the greatest amount of variation in costs and performance.


8.1.5.8  Boundaries of the Business Case - AS-IS Activity Model

Assumptions Should Be Documented

Assumptions should be documented for the decision-maker's consideration. Obvious assumptions such as there will be a next year, are not required. The assumptions should be clearly defined. Work closely with the decision-maker to determine critical assumptions. In some cases, the decision-maker may want to provide additional information. An example assumption would be the frequency of an event remains constant in the future.

The current process-flow of that piece of the organization that is being considered in the business case must be detailed to a level where all stakeholders can support conclusions drawn from the analysis. It also must be developed enough to understand areas affected by proposed initiatives. Finally, it must be detailed enough to assign costs and link performance measures. This step is also considered developing the baseline or baselining. It provides the picture of what is being changed that will be used to compare with the alternatives. The entire span of activities depicted in a business case should map to both the NATO CALS Data Model and other NATO process models. Integration Definition Function Modeling (IDEF0) modeling as defined in Federal Information Processing Standard (FIPS) Pub 183 is recommended.


8.1.5.9  Discussion of Alternatives - Functional Process Description
Functional Analysis is about what is done. This should describe significant outcomes, outputs, measures, and inputs involved in executing this process. It must focus on efficiency (best use of inputs), effectiveness (best delivery of outputs and outcomes), and productivity (output over input). Sometimes these differences in TO-BE versions tend to be very subtle, and this may require a greater focus on change in flows than on the processes themselves. Another approach is to build higher-level context models. These show how the change impacts upstream or downstream activities (that is, the outcome difference may not be within the scope of the activity model). Give attention to those actions that will eliminate or reduce excess and delay.


8.1.5.10  Discussion of Alternatives - Performance Impact and Metrics
Provide the projected metrics that is expected to result from each alternative and indicate how the metrics compares to the baseline. At this level, we are talking about how mission requirements, strategic goals, expected outcomes, and expected performance will be met by this alternative. A conscious, focused effort should be made at each stage of the process to recognize and document the relationship of each requirement to the accomplishment of a higher-level goal or objective.


8.1.5.11  Discussion of Alternatives - Technical Architecture (Optional)
Often, the business case will be considering technology that an initiative is driving, employing, or developing to achieve the organization's goals and objectives. Develop a clear picture to explain how technology will do this, what activities this technology will impact, and how it blends with other implementations.

Information Technology (IT) alone is not sufficient to justify the cost. It must be shown that the IT will impact the organization's activities in a way that improves benefits as well as reduces costs. This should be the predominant focus of the technological discussion within the business case, not a detailed technical discussion of its function and components. Not how it works, but how it impacts the operations that it supports.


8.1.5.12  Discussion of Alternatives - Cost Projections (Economic Analysis)
Economic Analysis is about the costs and benefits of how something is and will be done. The business case places emphasis on future economic benefit rather than on period costs, and on "value-added" as opposed to "cost savings." This section must focus on what investment option should produce the best use of investment capital.

The economic analysis should focus on productivity, and describe how it mitigates both initiative-fulfillment risk and organizational uncertainty stemming from the intended changes. It should offer the decision-maker multiple cash flow calculations.

Underscore that there is no one right answer, only one best answer. The best course of action should blend the total cost of involved processes, output performance, and outcome impacts prevailing over all sub-optimal choices; e.g., those that only justify better technology for the sake of better technology. Qualitative considerations may tip the scale between alternatives, as when data or system integration, purchase of COTS software, inadequate security mechanisms, et al. cannot meet some mission requirement.

The organizing backbone of the business case is a time line extending across months or years. This provides a framework for showing management how they can work to help put financial tactics into place:  reduce costs, increase gains, and accelerate gains.

Cost Projection Issues to Consider

· Consider the impact of the initiative across multiple fiscal years.
· Consider the time value of money. (When adding costs across years, dollars in future years must be discounted.)
· Consider inflation by including adjustments in future year cost projections by a rate consistent with this economic reality.
· Consider, for comparison, constant dollars to demonstrate the impact of the inflation assumption.
· Consider that estimations based on various operational cost data may be the best estimate. Consider using the 80/20 rule (where 80% of the costs are made up of 20% of the activities). The ratio of investment to savings should be so significant that most estimating errors will be insignificant.
· Consider the following measures:  current project funding support, dollar value of benefits, projected project costs, rate of budget expenditures compared to projections, and adherence to baseline schedule or time frame.
· Consider the Earned Value Management approach that provides an effective mechanism for linking cost, schedule, and benefits performance for acquisition programs.
· Consider Internal Rate of Return (IRR) that demonstrates what interest rate would have to be obtained outside the organization before the decision to invest funds outside rather than on this initiative.
· Consider Return on Investment (ROI), also called Return on Assets, that demonstrates what rate of return can be expected from the investment outlay.
· Consider Risk Adjusted Discounted Cash Flow (RADCF) that considers risk and discounting cash flow. It brings all alternatives back to the current year for a total cash-flow comparison. Any positive RADCF value is considered a good investment, but another alternative may demonstrate greater RADCF value, making it the preferred alternative.

The business case is not a budget, not a management accounting report, and not a financial reporting statement. This distinction is meaningful for deciding which kind of cost and benefit data go into the business case:  incremental values or total cost and benefit figures. Incremental values are probably the right choice in decision support situations, notably where both costs and benefits will enter the business case.


8.1.5.13  Discussion of Alternatives - Cost Projections - Investments
These costs should be the complete and total costs necessary to have the alternative turned into a reality. This includes training and needed purchases. Provide an aggregate, initiative-level mapping that would help view required cash flows over time as they relate to each alternative. This would also link to activities that an alternative affects. At the heart of this mapping is a high-level course of action used to frame when and how a TO-BE state becomes operational. This is called an action plan. This should enable the decision-maker to see how cash spending increases until some point at which operations costs start decreasing.

Prepare an action plan that specifies what needs to be done and when. A solid and complete action plan has each of the following characteristics:


8.1.5.14  Discussion of Alternatives - Cost Projections - Operational
At a minimum, the business case should reflect the AS-IS cost of doing the whole activity, coupled with a targeted reduction percentage that can be applied over time (tied to its initiatives). This will show expected TO-BE activity costs once changes are put into place. Moving it to the next level of output costing, or better yet outcome costing would be desirable, because this is what most people can relate to.

Activity Based Costing (ABC) relates cost of resources to activities that consume them. At a minimum, this information provides insight for calculating future out-year resource requirements and costs. ABC can provide calculations that will depict activity levels through the planning horizon. These costs should be ongoing operation costs directly contributing to activities defined within the activity model mentioned in the functional analysis.


8.1.5.15  Discussion of Alternatives - Risk Assessment
This must be discussed with or without having quantifying information. Even with these categories, it cannot be assumed that some standard mitigation routine can be applied to every one of that type. Each identified risk needs to be separately looked at and handled. To avoid paralyzing the decision-making processes, rank these factors and address the most ominous of them.

Recognizing risk does not have to hit an exact number, but instead distinguish one alternative from another by the degree of risk that separates them. This recognizes that not every decision carries an equal degree of failure or success. It allows the decision-maker to recognize the fact that estimates have varying degrees of becoming reality.

A Proper Study of Risk

A proper study of risk should be addressed in any business case, but risk is perhaps the most difficult area to analyze. Risk should be viewed as "an undesirable implication of uncertainty." Risk can be quantified in terms of odds (probabilities) or remain non-quantified (uncertainty). In situations involving (what we commonly call) risk, probabilities of various outcomes are known. Under uncertainty, there is no knowledge of the probability distribution of possible outcomes. We can classify different categories of risk: Business Risks, Process Risks, Technical Risks, and Organizational Risks. Risk to the organization can be an influence from other organizations that formed alliances because of the alternative (i.e., outsourcing).


8.1.5.16  Comparison of Alternatives - Functional
Describe the TO-BE activity models for each alternative and describe how they address performance measures vis-à-vis the AS-IS activity model. These TO-BE models should represent a different future state in line with each alternative. This should also point out why the alternative would achieve a distinctly different manner of doing business, rather than continuing with the AS-IS, or baseline. Annotate differences between each TO-BE diagram and the AS-IS diagram, and among TO-BE diagrams. These diagram comments can depict organizational and other resource volumes as well as volumes represented by the flow arrows. Tying initiatives to both AS-IS and TO-BE activities illustrates intended changes and helps visualize necessary project work.


8.1.5.17  Comparison of Alternatives - Performance
Use various charting techniques to show expected performance improvement in line with realizing changes put into place by various initiatives. Another technique arrays over a timeline the expected performance level ranges for each measure and all alternatives in a table that is highlighted in red, yellow, or green. Regardless of the approach, provide the decision-maker with a straightforward picture of expected performance. Guidance in using the software application Turbo BPR Version 2.5 for business case development is available on the Internet.


8.1.5.18  Comparison of Alternatives - Costs
As stated earlier, the organizing backbone of the business case is a time line extending across months or years, as the figure suggests. A graph of total investment and operational costs for the baseline and each alternative should be provided, as well as any other presentation helpful to the decision-maker. Increasing or accelerating gains, or reducing costs may effect changes in cash flow.



8.1.5.19  Comparison of Alternatives - Investment Costs

Value-added Must Be Considered

Value-added must be considered over costs alone. The business case must consider the cost of the initiatives, but even more so, it must identify the value-added to the organization. Reducing services just to reduce costs will more than likely not accomplish the organization's strategic goals and objectives. Although one initiative can show greater cost savings, the initiative may compromise value. This should be clearly stated within the business case. Other alternatives that generate greater value, but at a greater cost, may present justification more consistent with NATO goals and objectives. Both tangible and intangible benefits and costs should be recognized.

Cost measures gauge the number of investment dollars needed to achieve a particular milestone or activity level. For example, a performance measure can be the dollars necessary to move an effort through one phase. The granularity of a performance result is not as important as tying the investment of dollars to the achievement of some result. This task is decidedly different from measuring whether budgeted dollars were spent in a particular fiscal year. Schedule measures gauge the amount of time necessary to obtain a particular performance result. As stated above, a performance measure can be the amount of time needed to move an effort through a phase or the amount of time to do part of a phase. What is important is that the schedule measure is tied to the same performance result as the cost measure. Investment project baselines should contain major events that impact the effort. Achieving these events on time may demonstrate satisfactory progress. For each effort, establish a target date that is based upon contractual requirements or the need to complete an event before another can start. Thresholds for these events can be set by policy (e.g., 90 days beyond target) or by absolute need when there is no slack in the schedule.


8.1.5.20  Comparison of Alternatives - Operational Cost Savings
Exploit Activity Based Costing capabilities in the business case by assigning projected costs to various activities affected by each initiative. The change in activities from the AS-IS activity model to the TO-BE activity model should make up cost savings realized by that initiative. The TO-BE activity model should always represent increased value-added to the organization.


8.1.5.21  Conclusions, Recommendations, and Issues
This section should be prepared at the end of the business case development and may include a sensitivity analysis. Make an initial conclusion and recommendation to the decision-maker based on the findings. Conclusions, recommendations, and issues should be documented as an amendment to the business case as provided by the decision-maker.


8.2  CALS Techniques


8.2.1  Approach to Implementation - Change Management


8.2.1.1  General


8.2.1.1.1  CALS
CALS and/or its organization must be seen as an enabler of the Change Process. CALS is the strategy to implement an overarching management framework to combine technology insertion and change management.


8.2.1.1.2  PMview
This document is written for the Manager in Charge of the overall organization's change process.(in some organizations this might be called the CALS-office). The document's goal is to set a general methodology to ENABLE the Change.

We must warn you that this document is only gathering some good advises found through different sources. The document is not written out of personal experience.


8.2.1.1.3  Techniques
This is a warning. Indeed, a number of techniques exist to facilitate the Change Process. We site, the different implementations of Business Reengineering, Benchmarking, Continuous Process Improvement, Performance Based Change Management, of which some of these overlap. The techniques must be carefully chosen in function of an overall strategic goal. The prime concern of the Change Manager should be to carefully integrate, Process Change, Technology Insertion, and Organizational Change.


8.2.1.2  Step 1 - Motivate to Change
This is the first step in creating an environment in which Improvement is encouraged and nourished. Its aim is barrier reduction and general goal setting. Management must have a clear vision of what it wants to accomplish and where it wants to go.


8.2.1.2.1  Top Level Management
Top managers' recognition of the need for significant change and their willingness to learn more is the first step toward effective change planning. It is probably not possible to overstate the importance of the role of top management. Leadership is essential during every phase of the change process. In fact, indifference and lack of continuous involvement by top management are frequently cited as the principal reasons for the failure of Improvement Programs. To be successful, you will not only need the vision, planning and active involved leadership of top management, but also such practical support as providing resources for implementation - the necessary time, money, and personnel. Delegation and rhetoric are insufficient. Without top management assuming an active role as champions of the Improvement Program, you will not obtain the full scope of benefits available.

One of the first tasks of the Management will be to draft a Vision Statement


8.2.1.2.1.1  Vision Statement
A key step in the Change Process is the creation of a common understanding among top managers about what they want the organization to look like in the future and what principles will guide the actions they take to achieve the Modernization. his strategy will become the basis for formal statements of the new organization's vision and values.

The Change Vision should be a clear, positive, forceful statement of where the organization wants to be. It should be expressed in simple, specific terms. The vision must be powerful enough to excite people and show them the potential of what can be done. A well-crafted vision statement supported by action can be a powerful tool for focusing the organization toward a common goal.

Whatever forms the vision and guiding principles take, it is important that they be communicated throughout the organization frequently and with conviction. It is important that the vision be followed soon by a concrete plan of action to avoid its being dismissed as a hollow slogan.

Key ideas in the new vision can be (not limited list):


8.2.1.2.1.2  Understanding
To obtain top-management commitment, you need to begin to educate senior managers regarding the impact of possible business modernization. This can be done through Workshops, Briefings, Management Guides, and White Papers.


8.2.1.2.2  Why Change
In considering a Business Modernization initiative, the first and possibly the most important success criteria is to make sure that the rationale for initiating the project is sufficient for justifying the effort and expense of the project.


8.2.1.2.2.1  Current Environment
Analyses of the current environment with a report on the lessons learned will most of the time make clear why and where changes are necessary.


8.2.1.2.2.2  Change Drivers


8.2.1.2.2.2.1  Fear of Failure
There needs to be sufficient motivation for the enterprise to make significant changes for improvement. In the business environment, this motivation is often driven by actual or perceived failures in performance. This actual or perceived failure can apply to how the enterprise measures up against the competition in terms of production, distribution, customer service, price, etc.


8.2.1.2.2.2.2  Critical Assumption Analysis
Under CAA, stakeholders in the enterprise identify the assumptions under which their business is conducted. They then attempt to isolate those assumptions, which, if violated, would cause the enterprise to cease to exist as it is today (e.g., the assumption that "quality watches must be precision machines" or that "the cold war will always be with us," etc). All assumptions, but particularly the ones in the critical category, are candidates around which to build a case for action.


8.2.1.2.2.2.3  Need for Structural Evolution
A second commonly used rationale is the need for structural changes in the organization. The structure of our Defense Organizations has always been vertical. That is, a top-to-bottom management structure - with decision-makers at the top and soldiers at the bottom - has characterized the typical army. This generally has meant that strategic planning for our Defense enterprise occurs at a high level and is delegated down to divisions, departments, and individual job performers in the form of policies, procedures, and directives. In response, performance appraisals - which can take the form of periodic formal performance reviews or weekly status reports, sales figures, etc. - are reported back up the chain of command. This paradigm operates in a strict up-and-down the chain of command communication manner.

The emerging paradigm, however, has enterprises relying more on concurrent, cross-functional teams (i.e., teams that cross organization boundaries) composed of knowledge workers organized in a horizontal fashion. The goal of these cross-functional teams is to produce the enterprise's products most effectively by focusing on the product processes, not the organization of the enterprise itself. Customer success relies on these cross-functional business processes to build and support the product. Under this paradigm, in fact, the quality of a product consists of both that product and its associated processes in designing, building, and maintaining it over its useful product life.

Structural organization evolution, however, does not come easy to an enterprise. While processes can be changed overnight, people and organizations typically cannot. Therefore, part of this structural evolution is not only an increasing corporate awareness but also a change management plan that plans for the orderly, evolving transition of the organization and the job performers within that organization from a vertical, structure to one that is more horizontal. This change management plan must include processes for facilitating information flow and communication across organizational boundaries.

What occurs between management's setting strategic goals and workers on the line reporting their progress and all the layers in between? What occurs is a business process-a series of time-ordered individual activities performed as discrete events in a larger scenario that is guided by a strategic vision that must be implemented in stages, at the tactical level, to achieve the overall strategic objective. To use a literary analogy, one can think of the business process as a stage play: the play is written and directed (by management) to achieve an artistic (corporate) effect; the actors (employees) play their roles to enable this achievement; each scene (discrete event) contributes to an overall plot (process) that unfolds sequentially, uniformly, and deliberately; and all is held together by the motifs and themes (policies and procedures) that manifest themselves as each scene unfolds.

With this business process paradigm, however, there are often communication breakdowns (or disconnects) between various groups and/or departments that inhibit process performance. Many enterprises recognize that such breakdowns pose significant challenges to process improvement initiatives. In fact, the success of a Change effort largely depends upon discovering and analyzing these disconnects.


8.2.1.2.2.2.4  Agility
A third principle or rationale is the need to align an enterprise's strategic goals with the objectives of its departments and employees, as well as with the tactical processes that are intended to achieve the overall strategic goals. It is generally recognized today that success in a rapidly changing environment is closely tied to how the enterprise proactively manages and evolves its business practices as part of an efficient implementation of its overall strategic plan; and how quickly and effectively the enterprise leverages new opportunities. We have, in fact, entered the age of agility.

Of concern to any enterprise today is the increasing rate of change in the socio-economic environment. The rate at which we must adapt our enterprise to the "current" business environment is changing exponentially as information and computer technologies seem to change and improve on an almost daily basis.

Today's challenge is determining how to effectively respond to, and manage, change. Every manager-in fact, every job performer (or employee)-is faced with the fact that the current situation is, or will shortly become, unfavorable. More importantly, radical change will often be required. Critical business issues intricately tied to change include affordability, responsiveness, quality assurance, resource scarcity, and assurance of total customer success.


8.2.1.3  Step 2 - Develop Change Plan
Once a Vision Statement has been drafted by top management you can start to develop the Strategy for the Change. This will include, (start) setting up an organizational structure, the identification of the "customer" needs, the selection of organizations who will be involved by the Change Process, and the determination of needed/available resources.

However, be aware that there is no one right way to implement the Change Process in your organization, no guaranteed recipe for success. What followed is only offered as a guide in developing strategies and associated plans to carry out these strategies. It is important to take a flexible approach to capitalize on an organization's strong points so that energy is focused on key improvement opportunities.


8.2.1.3.1  Develop an Organizational Structure
Developing an organization structure that will institute, sustain, and facilitate expansion of your improvement effort is an essential element for success. This "phantom" structure can be called CALS-organization or office; however, it might be a good idea to give a more forceful name, which has a specific relationship to the Vision. The following is a proposed organizational structure. This structure will grow as the Change Process evolves. Important is the integrated nature of the structure: high involvement of top management and of the employees from the departments.

In the early stages of the Change Process, a team of top managers should form an Executive Steering Committee (ESC). This ESC will be chaired by the Organization Head or Deputy. By establishing the ESC, top management provides identity, structure, and legitimacy to the Modernization Process; it is the first concrete indication that top management has recognized the need to improve the process, and has begun to change the way the organization conducts business. The first task of the ESC is to publish its vision, guiding principles, and mission statement.

The ESC is at the top of the Change Structure. The committee members provide leadership and direction for the Change Process. Below the ESC, Change Managers (CM) work on the organization's key change areas. There can be one or more CM-teams depending on the extent of the goals set for the organization.

To ensure good communication between ESC and CM-teams members of the ESC act as sponsors and linchpins on each CM-team.

Below the CM, teams are Change Development (CD) Teams that work on specific problems assigned by the ESC.

In turn, the CD-teams can designate Tiger Teams (see Step 6) to carry out one task. When the task is completed, the Tiger Team is disbanded. Members from CM and CD-teams will as sponsors and linchpins in the same manner as the ESC-members


8.2.1.3.2  Identify Customer Needs
To make the change process work you must focus on meeting your customers' expectations (=needs and wants). Customers can be either coworkers (=internal customers) or end users (external customers) of your services or products.


8.2.1.3.2.1.1  Customer - Things We Know


8.2.1.3.2.1.2  What is a Customer?


8.2.1.3.2.1.3  Select Organizations
At the outset of the Change Program, you must choose to implement it either widely or with one or more product or process development pilots. A partial implementation will allow focusing the resources on specific projects. Selecting the change targets involves identifying the potential opportunities, setting priorities, and choosing the effort that offers the most significant opportunity for business improvement.

It is also possible to tailor a combination of the two approaches to fit particular circumstances. In any case, the decision is one that each organization must make after realistically assessing a number of factors, including:


8.2.1.3.2.1.4  Determine Resources
The Change Plan must disclose how much it will cost to implement the Change, the level of effort to be funded, where the required time will come from and how it is to be accounted for, who will provide what personnel, and what facilities will be used. Obviously, these resource decisions must be coordinated with all those affected by the decisions. This part of the plan may the hardest to develop because Change Management will now be competing with other requirements for organization resources. In addition, it may be the first test of the management's commitment to the Change Process. Milestones for providing the identified resources should be included in the plan.

One must be aware the new way of doing things are to become a way of life in the organization, and that in reality Change Management is not competing for resources because it will be integral part of the future corporate mission.


8.2.1.4  Step 3 - Conduct Training
Training and/or retraining are essential to the success of the Change Project. Training programs will create the kernel of an organizational culture, which will create a favorable climate for the change program.

It is important to note that during the early stages of implementation of the effort, attention should be given to developing a detailed plan for training executives, managers, engineers, and all team members. This includes:

Besides learning the necessary technical skills to use the tools, each team-member must be encouraged to learn the basic philosophy, principles, and practices involved in making the new strategy one that focuses on "Why do we do what we do at all." You need to provide the freedom for your team members to raise questions regarding problems that are thought of as business-as-usual practices. All employees must better understand their jobs and their roles in the organization, and how their jobs will change. Such understanding goes beyond the instruction given in manuals and job descriptions. Employees need to know where their work fits into the larger context: how their work is influenced by workers who precede them and how their work influences workers who follow.

To prevent surprises and delays in implementation, the training plan must include reasonably accurate estimates of the schedule and required resources.


8.2.1.5  Step 4 - Identify Goals and Performance Measures
Once the Change targets for improvement have been set, the team should define the change efforts as clearly and completely as possible.

The principal benefit of this step is that Change Development teams begin their work with a clear understanding of their mission and an idea of what successful performance will look like. Their efforts are properly focused on how they will achieve the process vision and performance objectives set in place by senior management, not wasted on trying to determine what their objectives should be.


8.2.1.5.1  Business Case Analysis
It is critically important for the for a successful Change Process to have a clear understanding of the business case justification. You must include a strategic planning, business issue identification, business opportunity identification, critical process identification, strategic goals, and top-level cost performance analysis. This is not as difficult as people think. Most enterprises have some picture of their performance, as well as some idea about how much they want or need to change or improve over a given time frame. The difference between where they currently are and where they want/need to go is the driving motivation for the Change Process. The difference must be translated into a set of goals, initiatives, and top-level initiatives that form the roadmap or strategic plan for improvement. This plan can then be used to further expand definitions or critical business issues or opportunities, as well as to identify the core (or critical) business processes that support those business issues.

By identifying critical business issues, processes, and goals, this process produces the primary inputs to the Change efforts. A business case based on these goals, initiatives, measures, and estimated costs needs to be developed to reassure management that the enterprise is headed in the desired direction and that the fundamental question of affordability (or return on investment for the effort) is identified early on. The specific benefits to be gained also need to be identified at this point. This initial business justification or forecast will be used to benchmark progress throughout the change effort when preliminary or intermediate results will be compared against the business case to ensure that the options being chosen or evaluated are consistent with the business case.

The business case should focus primarily on what it takes to help a customer to be very successful. That is, the ultimate goals of a business from the customer's perspective (and, therefore, the business case itself) need to demonstrate how the business goals, such as revenue, profitability, improvements in other socio-economic factors, growth of interest to the business, etc., are also supported.


8.2.1.5.2  Performance Measures
An important-and often overlooked-component of an effective Change Initiative is the yardsticks to use to measure and gauge progress and performance. If the Change Team knows from the outset their goals and targets in a measurable form, the probability of success is greatly increased. There needs to be meaningful metrics, and the means to measure for that metrics.

The Change Development teams should set in place a means of measuring performance to ensure that the improvement benefits are realized.

The measurement process needs to be viewed as a process for obtained vital insight into the progress, products, and/or processes of the change project. This insight will help the decision maker to make more informed decisions, identifying deviations from plans earlier, thus allowing mid-course corrective actions when it is least expensive to make them. Measurement should not be viewed as a set of predefined measures that never change throughout the program. Instead, the measures used need to address the current issues at hand, which may change with time. The measurement process includes the activities for selecting and specifying the measures, establishing a measurement plan, planning and executing the data collection and storage, analyzing the data, reporting the results, and most importantly, taking action.

The measures chosen must provide insight into the identified objectives, constraints, risks, and issues. As this change, the measures in use need to be re-evaluated for adequacy in providing the necessary insight and changed, if necessary. The measure remains active only if it has a valid, justifiable purpose.

Generally peaking, when selecting the Performance Measures five major factors should be considered. Cycle Time, Cost, Quality, Asset Utilization, and Revenue generated.


8.2.1.5.2.1.1  Cycle Time
The first of which is cycle time. Cycle time can be measured as the how responsive an enterprise is to the customer's needs (i.e., the ability to get a product to the marketplace in a timely fashion). The term can also refer to the ability to increase or modify capacity to produce a product or service in response to market needs, as well as the ability to respond more quickly to changes in the marketplace or business environment.


8.2.1.5.2.1.2  Cost
The second major factor to consider when making the business case is cost. The business needs to have affordable systems or methods of productions for goods and services.


8.2.1.5.2.1.3  Quality
The third factor is quality. Quality does not simply refer to meeting product specifications (or standards of excellence), but also includes non-quantifiable attributes of business, such as whether customers are satisfied that the business is providing them with every means to achieve their own success. Quality is also measured in terms of the robustness and reliability of the systems provided. The bottom line of quality is that the customer feels that the system is always available to provide what the customer needs.


8.2.1.5.2.1.4  Asset Utilization
The fourth factor for consideration is asset utilization. In the case of manufacturing, asset utilization involves the availability of equipment and other assets to produce a product. In a larger sense, asset utilization is also about the ability of the enterprise to be creative, flexible, and adaptive. One of the issues the business community faces today is a critical shortage of skilled personnel resources. Ineffective business processes will quickly waste the few resources that are available.


8.2.1.5.2.1.5  Revenue Generated
The fifth factor for consideration is revenue generated (or the value of the output product). Clearly, revenue is not the only measure of output in, for example, a government organization where output may be the number of missions successfully flown, the form of currency, or the measure of productivity, for the U.S. Air Force. Any parameter for measuring what an industry produces can therefore, serve as its revenue. Revenue, then not only considers the costs associated with producing something, but also the benefits gained by the customer receiving the product. In the case of the Air Force example above, the customer might be the public.


8.2.1.5.3  Goal Prioritization
Critical business issues must be discovered and identified to drive the Change project for the enterprise.


8.2.1.6  Step 5 - Document, Plan, and Sell
Document your Change Plan. Create a living plan that reflects the continuous improvement of your operations and change efforts. Make this plan available to all of your managers and teams to ensure that goals and approach are communicated throughout your organization.

You must sell your program by:


8.2.1.7  Step 6 - Create Tiger Teams
A fundamental element of the Change Development is the broad use of multifunctional teams to rapidly develop new products. These working teams are created from representatives of all the functional organizations involved in the Change Project.

For meaningful, long-lasting results to be achieved for the Change effort, leadership, ownership, and participation by cross-functional teams is imperative. These teams can be successful only if their Change efforts:

The Change Development leader must remember that the key to success is communication. Therefore, the number of organization levels must be reduced. Teams must be very democratic, with participation from all members. The teams must have as much decision-making power as possible.

More suggestions to improve on success of the teams are:


8.2.1.8  Step 7 - Implement
No single correct formula or "canned" solution can be used to achieve the change implementation. Your implementation will be unique in its details, but in general, it should move your organization towards satisfying the six criteria listed below:

While implementing the changes, one should have a constant eye on the five layers for change: People, the Business, the Processes, the Information, and the Physical (Technology) layer. While each change or change element will target one of the layers, it will have influences on the others.


8.2.1.8.1  People
At the top people, characterized by:


8.2.1.8.2  Business
The business itself is characterized by:


8.2.1.8.3  Processes
The processes are at the center of the organization and are characterized by:


8.2.1.8.4  Information
At the heart of the processes is the need for information, characterized by:


8.2.1.8.5  Technology
At the lowest level, we find the Physical Layer that will enable the changes:


8.2.1.9  Step 8 - Monitor
After the changes have been implemented, the Development team should document the improved performance and the change process. That documentation allows others to benefit from the lessons the team has learned, brings recognition for the team's efforts, and provides a road map for replicating successful techniques.

Recommending follow-up actions or subsequent improvement efforts is also appropriate.


8.2.1.9.1  Evaluate Results
Identifying the existing culture and management style of the organization helps to identify those vital processes to be targeted for change and provides a baseline measurement for judging progress. Assessments can take a variety of forms and frequently involve identifying and surveying the organization's internal and external customers, managers, and employees. The following key considerations are often probed:


8.2.1.9.2  Recognize Success
The success of Change is determined, in large part, by the degree of importance the organization places on it. Recognition is one of the most important ways to reinforce a proactive, positive change in behavior as it relates to the new processes. Recognition is given for the successful application of reengineering principles and practices.

The goal is to create an environment in which change in the customer's interest is encouraged, and then celebrated when it does occur.

Recognition is a means to demonstrate respect and appreciation for all employees, whether design guru or janitor, and the value they add to your business.

Recognition and reward are not the same things. Recognition means noticing ("recognizing") a person or team doing a good job. A manager may notice the good job at any point along its progress - not only when it is completed. Recognition usually takes the form of praise, either spoken or written. It may be as simple as a word of approval about the way an employee ran a team meeting, or as formal as a letter of commendation with copies sent to management.

Recognition provides both motivation and support for employees; people clearly work better when they know their efforts are valued. Research has shown that such reinforcement can also have a real and measurable impact on productivity. To provide effective reinforcement, recognition should:

Reward is given at the completion of a job. It is tangible, and usually comes in the form of mementos, merchandise, travel, stock, or cash. Rewards range from a simple plaque to a profit-sharing program. Rewards say, "You deserve to share in the tangible assets of your work," and as such can be powerful motivators.

Change Development is bolstered by the effective use of recognition and reward. All managers, at all levels, should continually identify those teams doing a good job - and then create ways to tell them so.

Recognition and reward should be woven into the very fabric of Change Development. People who assume responsibility for continuous growth in meeting customer requirements are in turn motivated to further growth by honest recognition of the large role their efforts play.


8.2.1.9.3  Adjust
Your Change Development planning and implementation efforts must not be locked in concrete. As you learn more about your company's strengths and weaknesses, change your Change efforts to reflect the feedback, and if the results are not as expected, then reexamine the problem and reengineer the effort, based on what was learned.


8.2.1.10  Change Tools
This Section is not meant to give ALL the tools needed to start the Modernization Program. It only gives overview of the tools that you probably will need during the first phases of your Modernization Project.


8.2.1.10.1  Success Stories
To motivate management and co-workers a file of success stories, in- and outside the organization, might be very useful.


8.2.1.10.2  Compendium - Business Technologies
To ensure that every speaks the same language it is advised to edit a "Management Guide to Business Technologies"


8.2.1.10.3  Total Cost of Ownership-Models
They will allow you to make the cost trade-offs.


8.2.1.10.4  Business Process Modeling Tools
During the Change Process there is a strong need for means that enable better documentation, communication, understanding, and learning, especially with regard to development processes and the inherent process know-how. Business Process Modeling (BPM) tools will help doing so.

Which BPM-tool(s) to choose will depend on your ultimate goals. We identify four distinct set of user requirements for these tools: business diagramming, business analysis, IT requirements, and IT process analysis.


8.2.1.10.4.1.1  To-Be Business Models
Those models (Business Diagrams) might be of particular interest to create a common understanding between all stakeholders of the new ways to do business.

A process model helps people to get an overview, to understand what part they play in the game, and to see who is doing what and when. This is even more necessary when processes are changing very often (e.g., due to reengineering efforts).


8.2.1.10.4.1.2  Why?


8.2.2  Guide for Developing a NATO/Government CALS Concept of Operation


8.2.2.1  Section Summary

The concept of operation is your strategy for the creation, use and management of digital data.

The CALS strategy will require different approaches to planning and contracting for the acquisition of defense systems. The information developed by contractors in management, design, build, and support functions for defense systems may migrate to a paperless, digital data delivery and access system. The planning process for implementing various CALS initiatives needs to include the development of a strategy for the creation, management, and use of this digital data.

To provide potential bidders with an understanding of specific user needs for technical information throughout all life-cycle activities, a NATO/Government CALS Concept of Operation (NCoO) should be developed.


8.2.2.1.1  Purpose/Scope
The planning process for acquiring any defense system needs to include the development of an information strategy aimed at taking advantage of automation and integration capabilities.

This strategy would employ a computer-based environment for generating and storing unique data elements only once and yet provide multiple accesses to multiple applications. This strategy, depicted in the form of an NCoO, identifies typical users' needs for technical data throughout all life-cycle activities of defense systems management, design, manufacture, and support functions.


8.2.2.1.2  How to Use This Section
This section is intended to be used as a guide for creating an NCoO. A structural approach to implementing CALS requirements is provided. Some examples of the statements to be used in the Acquisition Plan (AP) are included in this section in the next paragraph `CALS Implementation strategy'. Figure 8-1 shows the relationships of the NCoO to the contracting process. Figure 8-2 diagrams the process required to determine how CALS should be applied to the contract deliverables. Further paragraphs provide the general requirements and considerations for the process described in figure 8-2, including the specific process for defining the data types and deliverables, data users, data utilization, user infrastructure, data format, applicable specifications and standards, and data delivery media.


8.2.2.2  CALS Implementation Strategy
Before developing a NATO/Government CALS Concept of Operation (NCoO), the Acquisition Plan (AP) should show a clear signal of commitment to the NATO CALS strategy. For this purpose, the AP should include the following statements:


8.2.2.3  Relationship of the NCoO to Contracting Process
The NCoO generated utilizing this guide will provide potential bidders an understanding of specific NATO needs for technical information throughout all relevant life-cycle activities of the defense system. The relationship of the NCoO to the various contracting steps is shown in Figure 8.2.2.3-1.

 


Figure 8.2.2.3-1  The CALS NCoO in the Contracting Process



8.2.2.3.1  Pre-Request For Proposal/Request For Quotation Activities and RFP/RFQ Release
The NCoO planning process should start as early in the acquisition process as possible. The NCoO is a document that is prepared during the acquisition planning and requirements determination activity for each procurement. It is used to provide information to potential offerors about NATO's or the NATO nations' infrastructure and CALS implementation strategy for defense systems. The process for gathering the NCoO information should simply be part of the overall data call conducted during the pre-RFP/RFQ activities. An NCoO survey should be distributed to the functional organizations to gather the information.

Development of a NCoO will help ensure that NATO/NATO nations, referred to, from now on, as the CUSTOMER, receives the correct version and formats of digital data products needed to acquire and support a defense system. The NCoO can assist the project manager in determining:

A flow diagram of the entire process is shown in Figure 8-2.


8.2.2.3.2  Contractor Proposal
Referencing the NCoO, potential bidders should be required to develop a Contractor's Approach to CALS (CAC) in their prepared responses to the RFP. The CAC is a description of the contractor's approach, experiences, and successes in the creation, management, use, and exchange of digital information identifying capability in the area of CALS. The customer during the source selection process can then evaluate the CAC. If CITIS requirements are included in the RFP, the contractor should address the approach to CITIS within the CAC.

The contractor should state, in the CAC document, its experience and successes in the creation, management, use and exchange of digital information.

Bidders should be encouraged to identify, within their CAC, a more efficient and more cost effective data strategy and to propose alternative forms of delivery of digital data products and information services that reduce life-cycle costs and improve business processes.


8.2.2.3.3  Proposal Evaluation
Information in the CAC is used to gauge the risk associated with the contractor's ability to provide the digital data products and services required by the RFP.


8.2.2.3.4  Negotiation
Differences in concepts of operation between the customer and the bidder selected through the source selection process become a subject for negotiation. The agreements reached during negotiation become the basis for a contract that triggers feedback to all involved in the support of the defense system and subsequent changes to the NCoO and perhaps the CAC.

Any selected alternatives proposed by the contractor must also be incorporated into the contract and appropriate Contract Data Requirements List (CDRL).


8.2.2.3.5  Contract Award
The solicitation and ensuing contract should state that an objective of the acquisition is to require the contractor to generate information products for development and production functions in an integrated information system and a shared data environment to the maximum extent practicable. Ideally, this integration should be achieved as part of a comprehensive concurrent engineering strategy. The integrated environment will provide for generation, storage, indexing, distribution, access, and delivery of digital technical data products in support of defense system development and production functions and processes. The objective is to create each data element once and use it repeatedly in subsequent processes without manual reentry work and labor costs.

The contract should require the contractor to generate information products for development and production functions in an integrated information system and a shared data environment to the maximum extent practicable.

Developing this integrated environment will most often require a phased approach for implementation. To facilitate a phased implementation of the CALS strategy, the program manager may wish to require a CALS Implementation Plan (CALSIP) as a contract deliverable (typically 60 days after contract award) that is maintained throughout the life of the contract.


8.2.2.4  Background Information for NCOO Development
The NCoO must provide potential bidders an understanding of specific customer needs for technical information throughout all relevant life-cycle activities of the defense system. The NCoO must be thoroughly developed for potential bidders to respond with a proper CAC. Therefore, the acquisition of technical data by the Program Manager requires a detailed definition of data requirements. The effective definition of these technical data requirements necessitates the complete identification of data needs and uses. Identification of these data requirements can be effectively accomplished using a well-defined process described in this section. A flow chart of the entire process is shown in Figure 8.2.2.4-1.

 


Figure 8.2.2.4-1  NCoO Development Process



8.2.2.4.1  Identify Data Type Deliverables
Data type deliverables are the data requirements specified on the Contract Data Requirements List (CDRL) for a typical program categorized by program function and type. A survey of supporting defense system activities during the requirement determination process will establish data requirements. Sample data types to be digitally developed, accessed and/or delivered, and maintained are listed in Table 8.2.2.4.1-1. Note that this table is not intended to be all-inclusive, nor are all deliverables listed required for all projects; the list of deliverables must be tailored to the project requirements.


Table 8.2.2.4.1-1  Typical Data Type Deliverables

Management and Administration Data

ILS/LSA Plans and Reports

Program Plans

Integrated Logistics Support Plan (ILSP)

Program Schedules

Logistics Support Analysis Plan (LSAP)

Engineering Support Plans

Logistics Support Analysis Record (LSAR)

Progress and Status Reports/Master Schedule

Safety Assessment Reports

Contractual Vehicles

Reliability Assessment Reports

Conference Agendas/Minutes

Maintainability Reports

Reviews and Audits Documents

Hazardous Materials/Process Reports

Technical Data Identification Checklists

Tailored LSA Tasks

Standardization Program Plan

Maintenance Plan/Reliability Plan

Contract Work Breakdown Structure (WBS)

Maintainability Plan

Cost Performance Report

Level of Repair Analysis (LORA)

Management Information System (MIS) Plan

Test and Evaluation Master Plan

Config. Audit Plan/Status Accounting Report

Test Reports

Data accession list

Life-cycle Cost Estimates

System Engineering Management Plan (SEMP)

Configuration Management Plan

CALS Implementation Plan (CALSIP)

Manufacturing Plan

 

Environmental Impact Report

Technical Data Package

Technical Report-Study Services

System Specifications

Quality Program Management Plan

Engineering Drawings and Associated Lists

Computer Resources Integrated Support Document

Analysis Data

Design to Cost Plan

Simulation Data

  

Test Data

Publication

ECP, RFW, and RFD

Technical Publications

Product Specification

Technical Manuals

Software Development Management Plan

User's Manuals

Software Test Plan/Description/Report

Operations Manuals

System Specification Report

  

System Engineering Analysis Report

 

Engineering Data

  

 

Discipline, functional activity, type, or other such groupings to facilitate a standardized approach to applying the CALS digital data standards and specifications should categorize the data deliverables.


8.2.2.4.2  Data Users
The data users, as shown in Table 8-3 are the functional organizations that will require access to the program data. These organizational areas typically include acquisition, engineering/design, supply, training, manufacturing, and maintenance. In addition to their functional responsibilities, these organizations are defined by their location and the specific disciplines involved and may be different from nation to nation.


8.2.2.4.3  Identify Data Use/Processing
The data use requirements are the ways in which the chosen data types may be considered for processing. The project manager will need to identify the use of the data types by the support organizations chosen for the program. The five defined methods of data processing typical of most defense systems are described below.


8.2.2.4.4  Identify Data User Infrastructure
The availability of digital data processing and telecommunications technology and approved standards for creation, storage, transmission, data protection, and integrity of data at the time of delivery or access are important criteria for acquisition decisions. The current and projected capabilities of both the contractor and of defense agencies must be assessed with respect to program needs and schedules.

The NCoO is an excellent vehicle for making these determinations. Project managers should plan to access or acquire digital data products rather than hard copy unless a clear case can be made that the costs will outweigh the life-cycle benefits.

Buy digital data that can be reused more easily than paper deliverables.

The data user infrastructure is the computing environment available to a particular user. This environment establishes the data processing capabilities of that user. The following areas identify a user's infrastructure:

In the case of NATO procurement, it should be noted that different nations might have different systems.

Table 8.2.2.4.4-1 describes a sample of the data user infrastructure and capabilities.


Table 8.2.2.4.4-1  Data User Infrastructure and Capabilities

 

Hardware

Word
Processor

Graphics

Spread-sheet

Databases

SGML

Acceptable Means of Data Delivery

NACMA

PCS on TEMPEST and non-TEMPEST
LANs

Word
Perfect
Version 6.1

Corel
Draw
Version 5.0

MS
Excel
Version 5.0

MS
Access v.2

Ingres Version 3.0

Yes

DOS Floppy 3.5 inch

D-ROM

Analogue Modem

Group 3 FAX

Belgium

              

France

              

Germany

              

Italy

              

 

8.2.2.4.5  Identify Type of Data Deliverable
Following are types of digital deliverables supported by delivery and access methods specified by project managers.


8.2.2.4.6  Determine Data Format
The following data formats are the forms in which each of the types of data deliverables can be procured. Refer to figure 1-2 for their relationships to the type of data deliverable.


8.2.2.4.7  Determine Data Interchange Standards
In order to ensure the proper sharing and exchanging of information across dissimilar systems, the project manager should consider the possible loss of intelligence when translating information from one data format to another (whether the format is standard or not). The following types of interchange standards are used with data formats:


8.2.2.4.8  Determine Data Delivery and Access Media
The two options that a project manager may use to support digital delivery requirements are physical delivery and on-line delivery via telecommunications. Digital delivery and access requirements are specified through the SOW, the CDRL, and specific Data Item Descriptions (DID).


8.2.2.4.8.1  Physical Media
Magnetic tape is a mature, stable technology that is able to handle the large volumes of data typically associated with a major defense system acquisition. Magnetic tape standards are well defined, and little additional investment cost will be involved. However, other media may be more efficient and, therefore, preferred. Magnetic disk is also widely implemented on personal computers and workstations and may be the physical medium of choice for small business contractors. Several primary de facto magnetic disk formats are available but no official standard has been accepted. Compatibility problems exist, but can be overcome with only moderate effort. Optical media is used here as a generic term to include Compact Disk-Read Only Memory (CD-ROM), Compact Disk Interactive (CDI) and Digital Video Interactive (DVI), Write Once and Read Many Times (WORM), and erasable optical disk. These media are ideal for mass distribution and archival purposes for large volumes of data.


8.2.2.4.8.2  Telecommunications
On-line delivery may be achieved via two methods:

On-line access, as distinguished from on-line delivery, refers to the situation in which an organization accesses data items through CITIS services, or other similar information management services, as negotiated in the contract.

Secure, on-line transmission of the full volume of data for defense systems is technically feasible but severely taxes current telecommunication networks. In the near term, telecommunications may be limited to electronic mail exchange of high-priority technical data, the use of mutually agreed EDI transactions, or other clearly defined uses such as CITIS access. On-line interactive access provides immediate and timely data access for custom report generation, document generation, and on-line request of information transmitted as composed products and processable data files. Project managers should give preference to use of CITIS for performing the functions of updating, storing, controlling, reproducing, and distributing data items. As an interim standard, MIL-STD-974 provides information concerning core and tailorable CITIS functions that should be specified in the SOW and listed as contract line items. In the long term, cost effectiveness will be essential for successful implementation of a totally integrated defense system database.

Upon completion of the NCoO, the logistics manager responsible for technical data will be prepared to enter the solicitation and source selection process with a firm CALS implementation strategy and knowledge of the needs and capabilities for acquiring and using digital data.


8.2.2.5  Data Acquisition Requirements Method
The identification of information for inclusion in the NCoO is described in the following sections and shown in Figure 8-2. The project manager can employ and adapt this methodology to a specific acquisition to develop the program requirements for digital data delivery or access.


8.2.2.5.1  Identify Data Type Requirements
The project manager will need to gather the data requirements of all the data users and select the data types that are necessary to accomplish the program objectives. Each of the specific types of data required will be determined by the unique conditions and constraints associated with a specific program. The data types selected will ultimately influence data format, interchange standards, and media considerations. The best method for determining the types of data deliverables required is to extract the data deliverables list from the CDRL and to categorize the data types.

The project manager must also be aware of the various infrastructure modernization programs that are in place, or soon to be in place, to accept, manage and use digital data. Any data deliverables that will require updating and maintenance throughout the life-cycle of the defense system (engineering drawings, TMs, LSAR, etc.) are excellent candidates for digital delivery and making use of the infrastructure modernization programs. Use of these modernization programs should be seriously considered during NCoO development.

The project manager should certainly take advantage of these programs in place for the management and use of data deliverables in digital formats.


8.2.2.5.2  Identify Data Users
The project manager will need to identify the organization(s) requiring data and the functions of the organization. Program-specific conditions and constraints will determine which organizational areas require data. Once the required organizational areas have been determined, the name of the organization, the organization's function (what services they provide), the location of each organization, and the Point of Contact at each organization should be provided.

Table 8.2.2.5.2-1 is an example of data users for a typical program.

This information provides potential bidders with an understanding of the separation of work functions and the scope of geographic locations for data transmission requirements or other modes of data delivery or access. An added benefit from developing the Data Users Table is provided to the customer in terms of clarifying the functional areas required to support the defense system acquisition.


Table 8.2.2.5.2-1  Data Users

Organization

Location

Point of Contact

Disciplines
(Functional Areas)

...

...

...

...

...

...

...

...

...

...

...

...

 

8.2.2.5.3  Identify Data Use/Processing
The project manager will need to consider how the data will be processed to make decisions on digital data requirements and format. The data use requirements may be influenced by the data user selected and the supporting infrastructure. For those that need to view the data only, a word processing file will suffice for most data types in lieu of paper. As users' needs become more sophisticated, such as a need to annotate/excerpt or more importantly, update/maintain or process/transform the data, standardized digital delivery becomes even more essential. The project manager will need to match the digital data deliverables to the existing or planned suite of equipment that makes up the users' infrastructure.

To complete this step in the NCoO process, the project manager needs to identify the deliverables required by the organizations using his data. An added benefit of this task is that as each organization determines its use of the data, deliverables are often discovered that are no longer needed and can therefore be dropped from the CDRL, resulting in a cost savings for the program.


8.2.2.5.4  Identify Data User Infrastructure
To assist the project manager in determining the user's infrastructure and how it will affect the type of data required, a data acquisition questionnaire has to be developed. Responses to the questionnaire will aid in giving not only potential bidders, but also the customer, a clear picture of the supporting infrastructure in place to support the defense system. The data users' infrastructure or data processing environment will influence several areas of the data acquisition process including delivery/access method, data format, interchange standards for the data, and media for data delivery. Since each supporting activity (data user) may have quite different infrastructures, the project manager will need to be aware of the various data requirements imposed by the different infrastructures and make attempts to bring commonality to the suite of tools available.


8.2.2.5.5  Identify Type of Data Deliverable
The project manager will need to identify the type of each data deliverable. Since composed products cannot normally be modified, this file type is recommended primarily for legacy data. Processable data files are the preferred data type for most new deliverables. Table 8.2.2.5.5-1 is an example of data deliverable types as well as other information for a program.


Table 8.2.2.5.5-1  Data Types

DATA TYPE

DATA DELIVERABLE TYPE

FORMAT

MEDIA

MANAGEMENT AND ADMINISTRATION DATA:

      

Program Plans

1, 2

A, B, C, E, F

a, b

Engineering Support Plans

1, 2

A, B, C, E, F

a, b

Progress and Status Reports

1, 2

A, B, C, E, F

a, b

Contract Vehicles

1, 2

A, B, C, E, F

a, b

PRODUCT DESCRIPTION DATA:

      

Drawings/Associated Lists

1, 2

B, D

a, b

ECP, RFW, RFD

1, 2

A, B, C, E, F

a, b

Analysis Data

1, 2

A, B, C, E, F

a, b

Simulation Data

1, 2

A, B, C, E, F

a, b

1. Composed Products

2. Processable Data Files

3. Media

A. Hard Copy
B. Page Image

C. Text File
D. Graphics File
E. Alphanumeric File
F. Audio/Visual File
G. Integrated Data File

a. Physical (Magnetic Tape or Disk, Optical Disk)
b. On-line (CITIS) Telecommunications (X.25, TCP/IP, Contractor Specific)

 

8.2.2.5.6  Identify Data Format Required
The project manager will need to identify the standards to be used and data format(s) for delivery, which is determined by the type of data deliverable. The chosen formats will affect interchange standards used and the media used for data delivery. Table 8.2.2.5.5-1 is an example of data format as well as other information for a program.

There is little benefit to receiving hard copy deliverables for any use other than view only. Realizing that most data generated by the contractor now starts out in some digital format (word processing, graphics development, spread sheets, CAD, etc.), the project manager should avoid hard copy format whenever possible. As a minimum, document image files (page description language files) should be considered for distribution in lieu of hard copy.

Most deliverables generated by the contractor can be utilized in their native format (processable data files) if the customer has a compatible suite of hardware/software or a CITIS environment is employed. In addition, text, graphics, alphanumeric, audio/visual, and integrated data file formats lend themselves to applying the CALS standards for data interchange. However, it may not be cost effective to apply CALS standards to these data formats until the final deliverable.

For example: a TM will go through many iterations of authoring, review/comment, editing, and distribution before the final delivery. Typically, the manual is being developed on a word processor or desktop publishing system. It may not be cost effective to invoke the CALS standard until such time that the customer has the infrastructure in-place or takes final delivery of the document and thereby becomes responsible for its configuration control, archiving, and maintenance. Therefore, the project manager may want to take advantage of the native file format during the early phases of the contract if compatible with the existing customer infrastructure.

Specific data formats and delivery modes should be stated on individual CDRL items. Proper safeguards should be used for classified information. In general, the following formats and delivery media are recommended for each data type.

Section 9 and Section 10 of this Handbook contain details of applicable standards.


8.2.2.5.7  Identify Data Interchange Standards
Each of the data formats requires certain interchange standards to remain CALS compliant. The project manager needs to identify the interchange standard required for each data format. However, these interchange standards will vary depending on the data types selected. User infrastructure will also influence which standards should be used. The required interchange standards should be stated in the Statement of Work (SOW) and the CDRL.


8.2.2.5.8  Identify Data Delivery and Access Media
Source: UK CITIS Guide; US Mil Std on CITIS, NCO HB V 1 Section 5
The project manager will need to determine the data delivery/access media or mechanism required for each data type selected. Interactive access via CITIS should be the preferred method of data delivery. A variety of factors can influence the decision for a CITIS requirement, including program phase, data type and format, volume of data being delivered, lifetime of the data, the interchange standards required, and the cost to implement the system. The data delivery and access media should be specified in the SOW and CDRL.

Telecommunication networks provide an excellent opportunity to exchange and establish common practices for business type data using commercial Electronic Data Interchange (EDI) transactions. EDI is the computer application to computer application exchange of business data in a standard format between trading partners. Currently there are numerous transaction sets that transfer data in the functional areas to procurement and contract administration; finance and payment; transportation; supply management; maintenance; fuels; and program management. Transaction sets have been developed to support project-scheduling reporting, cost performance reports, cost/schedule status reports, and contractor cost data reporting. The project manager should consider taking advantage of using EDI for program administration process improvements UN/Electronic Data Interchange for Administration, Commerce, and Transport (UN/EDIFACT) will be used for electronic transmission of such data.

The standards for delivery and access media are shown in Section 9 of this Handbook.


8.2.3  Concurrent Engineering
Source: NCOPS 3.2
Concurrent engineering means simultaneously performing both the actual and simulated processes of designing and developing a product. All phases of a product are considered concurrently, with the design modified as necessary to make sure the product is useful at all stages of its life-cycle. The materials and efforts needed to manufacture, maintain, and dispose of a product are determined while the product is undergoing design. Problems in later life-cycle stages are anticipated and dealt with before they can arise. Clearly concurrent engineering reduces the costs involved in solving such problems while a product is being built or after it has been released in the field. The least expensive changes in a product's life-cycle occur in the design phase, so concurrent engineering concentrates on making changes there. Quality is improved, products come to market faster, and costs are reduced.

Concurrent Engineering saves time and money but greatly increases the requirement to share information and to manage product change over the whole of the life-cycle. Concurrent Engineering is difficult to achieved in practice without a Shared Data Environment.

Concurrent Engineering differs from the traditional approach to defense system development (e.g., PAPS, see Annex B) in two important respects:

The Concurrent Engineering approach replaces the traditional sequential approach by a series of overlapping activities, which progressively evolve, or refine, the design towards a fully acceptable solution. This is illustrated by the following figure:

 


Figure 8.2.3-1  Refinement


In this approach, recognition of a problem leads to a first attempt to document the requirement. This in turn provides more understanding of the problem itself, and hence an improvement in the problem definition. In a similar way, the emergent requirement may prompt an initial design solution, which generates new questions as to what is actually needed. The rigid limitations on completing each phase before the next can start are relaxed. Sequential design is replaced by a design spiral. "Buy a little, deploy a little, test a little" becomes a more practical approach.

Source: DND Canada CD
Source: Knox, Rita E. and Russell J. Daty, New Technologies for Concurrent Engineering, CALS Journal, Volume 3, No. 1, Spring 1994, pp. 63-67.


8.2.3.1  The Key to Concurrent Engineering-Shared Data
For concurrent engineering to work, information has to be shared extensively. Instead of having individuals concentrate on one aspect of a product, or one aspect of its life-cycle, all those involved need to know about all aspects of the product. In addition, since the design is constantly changing and evolving, they need to be sure they are getting access to the current version.

Shared information is key, but often implementations of concurrent engineering attempt to cobble together a number of discrete, specialized applications (CAD, MRP systems, paper-based systems, release systems, and so on). Information is often difficult to access or share.

The solution is a shared data environment that can store all the information needed by all those involved, without limiting access based on life-cycle stage.


8.2.3.2  Example Use of an Integrated Database
To demonstrate the benefits of using a shared database for concurrent engineering, consider the process of designing and creating a computer mouse.


8.2.3.2.1  Design Process
A designer creates the mouse design layout using a split case that snaps together. As in a traditional system, the design is created on a CAD system. However, each component part is placed in the integrated database, including information about its materials and vendors.


8.2.3.2.2  Maintenance Analysis
A simulation performed using the mouse design finds some problems and recommends that the lower half of the case be split into two (to allow access to the track ball) and that the top and bottom of the case be attached using screws instead of snap locks.

In a conventional system, this finding requires someone to create a change request, on paper or through electronic mail.

With the integrated database, the change request is entered directly into the database, associated with the version of the design that posed the problem. The change request contains many details such as the person asking for the change, the date it was requested, and the approval or disapproval of the change. The change request remains in the database for future reference.


8.2.3.2.3  Design for Manufacturing Analysis
An analysis shows that the use of screws increases the cost of the mouse.

In a conventional system, the supporting information for this finding exists in paper documents or text files, and probably cannot be linked easily to the change request that prompted the comparison of the two methods.

With the integrated database, the change request for the screwed-together case is available to the testers, who disapprove it, with reasons, and enter a change request for the changed material. A trail of request/disapproval/reason is established and maintained.


8.2.3.2.4  Detailed Design
A designer creates a detailed design for each piece of the mouse.

In a conventional system, pieces are in a separate CAD file, produced by different people. One designer is often not able to access the design work of another. The CAD files are detached from other product information.

With the integrated database, individual parts are regularly posted for others to see. All product information is kept together in a central location.


8.2.3.2.5  Assembly Analysis
Analysis of the mouse shows that it may stick under certain conditions.

In a conventional system, confusion can arise about which version of the mouse caused the problem. A written report about the problem is generated.

With the integrated database, version control ensures that the test results are applied to the correct version of the design. Recommendations, along with their reasons and consequences, are attached directly to a specific version of the product.


8.2.3.2.6  Re-design
The mouse button is modified to eliminate the sticking problem.

In a conventional system, a paper change order is prepared and entered into the review and approval process.

With the integrated database, the change order is implemented in the database, which can also be used for review and approval processes. All the steps leading to this change are recorded in the database from previous activities.


8.2.3.2.7  Release
Individual parts are released for manufacturing, along with bill of materials and information on assembling the mouse.

In a conventional system, the CAD files are released, often with hard copy drawings. The release forms and bill of materials are prepared on paper.

With the integrated database, approvals for release are performed right in the database. All the current information, including version, quantities, materials, manufacturers, and so on is located in the central database and available at all times.


8.2.4  CITIS - Implementation of Contractor Integrated Technical Information Service


8.2.4.1  Introduction
The Contractor Integrated Technical Information Service (CITIS), as its name implies, is a service not a product. It is a contractor-developed and maintained service to provide electronic access and/or delivery of NATO-procured contractually required information. CITIS is generally acquired from prime contractors who may also use electronic networks for access and delivery of information from their suppliers. Thus, the prime contractor is the information integrator for a specific program/product acquisition.

CITIS exemplifies the CALS philosophy of creating data once and using it many times.

Project managers should give preference to use of CITIS for performing the functions of updating, storing, controlling, reproducing, and distributing data items. CITIS satisfies one of the major CALS objectives to furnish a single entry point for authorized access to contractor-generated data. CITIS exemplifies the CALS philosophy of creating data once and using it many times. It establishes a set of core information functions to facilitate the CALS concept of "shared data," and it standardizes functional characteristics of the data to facilitate its usage by a wide variety of different users.


8.2.4.1.1  The Primary Advantages of Using CITIS
The primary advantages of using CITIS include:

Although there may be some initial identifiable costs associated with implementing a CITIS, carefully-selected CITIS requirements should result in substantial savings over the program life-cycle by reducing costs for data generation, delivery, and access/usage. Cost savings should be realized not only in terms of reductions in paper purchases, copying costs, and actual delivery costs, but also through a substantial reduction in the labor required to locate, access, and process information. A CITIS has the potential to greatly improve the efficiency of both the contractor's and the users' processes.

Contractors already gravitate toward CITIS environments independent of NATO/NATO nations efforts to achieve effective information management. The project manager should keep in mind that the usefulness of CITIS will increase as NATO/NATO nations operations are streamlined and contractor capabilities are developed.


8.2.4.2  The Decision to Acquire CITIS
Project managers considering procuring a CITIS for their programs need to take into account the number, type, and use of deliverables, the number and locations of the data reviewers/users, and the cost to develop and implement the CITIS. A requirement for CITIS, part of the CALS effort, should never be driven by a mandate to implement CALS. The decision to utilize a CITIS requires careful analysis of the program's data requirements and usage. The data call and NATO CALS Concept of Operation (NCoO) data collection process provides the best method for compiling and assessing this type of information.

After the data is analyzed, the possible CITIS functions must be studied to determine which functions will be beneficial to the program. This type of up-front research is necessary to prevent the project manager from acquiring a CITIS that is inappropriate for the program. Table 8.2.4.2-1 presents a method of placing a relative value on each of the key questions along with an overall "scoring" method to assist the project manager in the CITIS decision process.


Table 8.2.4.2-1  CITIS Decision Scorecard

Program Consideration Question

Value
(#Points)

YES/NO

SCORE*

Are there a large number of reviewers and/or users for most data items?

2

    

Are the majority of CDRL items suitable for delivery via CITIS?

3

    

Is the infrastructure between locations generally compatible?

1

    

Do a majority of CDRL item recipients plan to do more than archive the data?**

3

    

Are CDRL item recipient locations widely dispersed?

1

    

Is currency of the data very important?

1

    

Do you currently have any form of electronic communication with contractors or other activities?

1

    

Will data be updated/changed often?

1

    

TOTAL SCORE

      

No = zero*
Yes = assigned value**
Note: "More than archive" means users will view, extract/process/transform, update/maintain, and/or comment/annotate data

Total Score

Decision

0-3

CITIS not recommended

4-6

CITIS may be valuable; perform further assessment

7-10

CITIS recommended

11-13

CITIS highly recommended

 

8.2.4.2.1  Preliminary Data Collection
The first step in the CITIS decision process is to gather all the data needed to make an informed decision. Compiling and analyzing the NCoO survey information can best do this. The results of the NCoO survey will provide the project manager with information on the data requirements and usage at each of the functional areas, along with their existing infrastructure. All of this information is critical to the determination of the CITIS requirements. If an NCoO is not being created, the project manager must find some other means of gathering the data needed to assess the advantages of a CITIS.


8.2.4.2.2  Number of Data Reviewers and Users
The benefits of a program CITIS are typically directly proportional to the number of user data reviewers and final users. That is, as the number of user nations and NATO/NATO nations contractor support personnel that review, generate comments, and process data deliverables increases, so do the potential benefits of the CITIS itself.


8.2.4.2.3  Recommended CITIS Deliverables
Before deciding on a CITIS, the project manager should first identify typical usage of the CDRL items (e.g., are they viewed, updated, processed, etc.). This information should be available from the data gathered during the data call and NCoO development process. The manager should then determine whether enough deliverables are suitable for on-line delivery/access to warrant a CITIS. The typical data item usage should be the primary factor for determining suitability for CITIS inclusion. Any data that is frequently accessed for viewing or processing is an excellent candidate for inclusion in the CITIS, while data that is only archived and is seldom accessed is not recommended for CITIS. Keep in mind that inclusion of data in the CITIS that is rarely accessed will only increase the size of the CITIS database and reduce the speed of data location and retrieval. In general, very large files (> approximately 30 Mbytes) are not typically recommended for on-line delivery and access because current telecommunications technology cannot yet efficiently handle large-volume data operations.

 


Figure 8.2.4.2.3-1  CITIS Implementation



8.2.4.2.4  Infrastructure Upgrades and Contractor Compatibility
As part of the data call and NCoO development process, each location requiring access to program data will identify its computer hardware, software, and network infrastructure. Once this information is gathered, it should be analyzed and compared to determine whether the existing infrastructures are generally compatible or whether each location uses a substantially different system. The greater the disparity in existing systems, the greater will be the cost for infrastructure upgrades and CITIS development. If any locations are using old equipment (i.e., far out-of-date with current technology), these locations may require infrastructure upgrades to be able to access the CITIS.

The ultimate decision on infrastructure upgrades will depend on the amount of funding available and the program manager's own judgment. If some locations have equipment inadequate to accommodate a basic CITIS, they are probably inadequate for performing many other functions that could be valuable to the program and should be upgraded regardless of whether a CITIS is required. If it appears that the existing infrastructures are compatible and state-of-the-art, the program manager can probably safely acquire a CITIS without having to worry about paying for extensive NATO/NATO nations infrastructure upgrades.

In general, the contractor should be responsible for modifying its systems to be compatible with the existing systems used by the NATO/NATO nations, rather than the NATO/NATO nations modifying its systems. The only time the NATO/NATO nations should need to consider major upgrades is in the case of outdated equipment. The contractor should propose a CITIS that will work with the existing NATO/NATO nations infrastructure to the maximum extent possible and discuss any upgrades that it feels are necessary either in the proposal or in the post-award CALSIP and/or CITIS planning meetings. The contractor and the NATO/NATO nations should work closely together to create a CITIS infrastructure that will be the most beneficial to everyone who will use it.


8.2.4.2.5  Reviewer Locations
One of the main goals of CITIS is to facilitate the movement of data deliverables from one status to the next, and the more widely dispersed the reviewer locations, the greater will be the benefits from using a CITIS. When data reviewers are at widely separated locations, a substantial portion of the review cycle time can be taken up by shipment of the data and review comments from one location to another. When a CITIS is available, as soon as one reviewer has completed the review and approved the data item for passage to the next reviewer, that next reviewer can instantly access the data item and begin his review, regardless of his physical location. The review cycle time is now simply the amount of time taken by the reviewers to actually review, comment, and approve/disapprove the data item.


8.2.4.2.6  Data Currency
One of the many advantages of CITIS is improved accuracy and timeliness of data. After data has been created or revised, it can be made almost instantly available to the NATO/NATO nations reviewers and/or users who need it. Using current business processes, data items can take days to travel from the contractor developing it to the NATO/NATO nations personnel who need it. If rapid access to new data is important to the program, a CITIS may prove to be highly beneficial.


8.2.4.2.7  Existing Electronic Communication Capabilities
If a program already has some form of electronic communication/data transfer capabilities in place, either between the NATO/NATO nations and the contractor, or between NATO/NATO nations activities, the cost and effort to implement a true CITIS may be substantially reduced. Even if a program does not meet some of the other criteria listed above, if it already has basic electronic data transfer capability with its contractor, a CITIS may be relatively easy and inexpensive to implement, and could still save a substantial amount of money over the remaining life of the program.


8.2.4.2.8  Data Revision Frequency
If the CDRL includes a substantial amount of "living" data that will often be updated, a CITIS can prove highly beneficial in ensuring the accuracy and consistency of the data used by all of the CITIS locations. Because all locations have access to the same master data file, the likelihood of data users possessing outdated or incorrect information is substantially reduced. The "archive" function of CITIS assumes added importance if a deferred delivery option will apply to the contract.


8.2.4.2.9  Program Considerations
CITIS becomes more cost effective and beneficial when applied to programs that have substantial data requirements, are in an early phase of development, and/or have long-term data requirements. However, CITIS should not be ruled out just because a program does not meet any of the above criteria; all of the questions shown in table 5-1 should be answered before a decision regarding CITIS is made. The program manager should evaluate and implement process improvements wherever economic benefits can be achieved.


8.2.4.2.10  CITIS Functional Requirements Determination
After the questions in Table 8-5 have been answered and a CITIS has been determined to be beneficial to the program, the program manager should review the NCoO questionnaire responses to determine which CITIS functions apply to his program.

Program managers should bear in mind that the greater the number of CITIS functions and services required, the greater the potential cost of CITIS development and implementation. After determining program-specific CITIS requirements, the program manager should weigh the estimated cost of the service against available funds and potential benefits. If the estimated cost of the CITIS services selected exceeds existing budgetary estimates, the program manager should tailor the CITIS requirements and functions as necessary.


8.2.4.3  CITIS Functionality
The CITIS functionality can range from basic data interchange functions to extensive interactive capabilities. The program/project manager must specify which, if any, of the CITIS tailorable functions are desired in the SOW, CDRL and acquisition contract.


8.2.4.3.1  CITIS Services and Functions
Table 8.2.4.3.1-1 provides supplemental details on CITIS services and functions. Information provided includes potential problems, lessons learned, and other issues to consider when determining the CITIS requirements for the SOW, CDRL.


Table 8.2.4.3.1-1  CITIS Services and Functions - Supplemental Details

Service/Function

Considerations

CITIS Services:

    · Services typically required with CITIS

CITIS Management Information Services:

 

Availability and Accessibility

    · SOW requires advance notice of events affecting CITIS operation.
    · SOW specifies hours of operation.
    · SOW can specify amount of notice required (hours, etc.) prior to each event.

Users Furnished
Information (UFI)

    · SOW and NCoO should specify size, format, and content of UFI - advance notice of format and software tools used to create UFI are extremely important.
    · SOW should specify which functions are required for UFI.

Multi-user Access

    · SOW specifies the number of concurrent CITIS users.
    · The greater the number of users, the slower will be the CITIS performance (speed). SOW can specify the acceptable level of degradation.

Electronic Mail

    · SOW can specify the number of users and the applicable protocols.

Data Dictionary

    · Intent of this requirement is to ensure that users can consistently and easily locate data of interest

Interface Compatibility

    · May require extensive planning and can be difficult to satisfy because of the potentially large range of NATO/NATO nations users receiving systems.
    · NATO/NATO nations may want to specify/select a limited number of receiving systems to reduce complexity of CITIS.

Communication Protocols

    · NATO/NATO nations are responsible for obtaining any waivers needed for use of a non-standard protocol.

Training Support

    · SOW specifies form(s) of training: documentation, contractor visits to CITIS user sites, number of training sessions, etc.
    · SOW can specify frequency of CITIS training/ documentation updates (e.g., after major system changes, every six months, etc.)

Telephone Support

    · SOW specifies hours of telephone support (may be different from CITIS hours of operation).
    · Telephone support most advantageous for large and varied groups of CITIS users.

On-line Help

    ·

Data Configuration Management

    · CITIS users will not be able to replace contractor or UFI data.
    · SOW specifies user data access privileges (i.e., access to working data - neither contractor nor NATO/NATO nations - is not granted unless specified in the SOW).

CITIS Security

    · Contractor should obtain written approval from cognizant security officer before including classified data in CITIS.
    · SOW can address protection of business sensitive or proprietary data by both contractor and the NATO/NATO nations.

Access Controls

    ·

Contamination Control

    · Primary contamination control typically provided by allowing only authorized users to access CITIS data
    · SOW can require the contractor to scan all CITIS data for viruses prior to incorporation or can specify intervals at which all CITIS databases are scanned

Data Item Index

    · SOW specifies any indexing elements

Data Exchange Standards

    · Include any COTS software formats when specifying data transfer methods.

Core Functions:

    · Core functions automatically required with CITIS
    · Core function tailoring should only be done after rigorous cost and effectiveness analyzes.

Acknowledge

    · Can be provided via either E-Mail or CITIS capabilities.
    · Can be manually input, automatic confirmation by receiving computer, etc.

Approve or Disapprove

    · Can be provided via E-Mail or CITIS capabilities.

Comment

    · NATO/NATO nations may consider allowing use of E-Mail for this function.

Notice of Delivery

    · Can be provided via E-Mail or CITIS capabilities.

Receive

    ·

Search

    · SOW specifies any additional elements desired as search criteria (will be included in the data item index).

Store

    · SOW should specify the length of time a data item will be stored/available through CITIS.
    · Function allows users to request that short-term data be retained on CITIS past its normal lifetime.

View

    ·

Tailorable Functions:

    · SOW specifies required tailorable functions.

Applications

    · Can cause licensing problems.
    · NATO/NATO nations should identify and grant access to applications only to specific personnel (not everyone); number of personnel requiring access should be specified in SOW, if known

Archive

    · SOW can specify length of time between archival data request and availability of data on CITIS.
    · SOW can specify whether data requester should be notified of data availability.
    · SOW can require creation of an archival data index.
    · NATO/NATO nations should periodically review CITIS data to identify data to be archived (this should improve CITIS performance).

Combine

    · Can cause data CM problems - SOW should specify disposition of combined data (how long to retain it, how to tag and index it, how to notify CITIS administrators, etc.).
    · CITIS must ensure that combination of data does not affect original data files.

Download

    · SOW can specify maximum file size for data downloads to avoid telecommunications/network-loading problems.
    · Files larger than approx. 30 MB are recommended for delivery via magnetic media.
    · Max. Download file size specification may be especially important if many CITIS user sites possess only limited CITIS access capability.
    · If maximum size is specified, SOW should specify how CITIS users can gain access to large data files (e.g., on-line request for data on tape).

Edit

    · Can cause data CM problems - requires same considerations as for the Combine function.

Forward

    · SOW should specify whether data will be forwarded to other CITIS users, non-CITIS users, or both
    · Function is useful for facilitating the review and approval/ disapproval of data items.

Package

    · SOW must define this function - specifically:
    · How should the package be stored, tagged, and indexed?
    · Is the package temporary or permanent?
    · Is it accessible by all authorized CITIS users, and how can they be authorized?
    · Must the other CITIS functions be able to act on the package?

Query

    ·

Sort

    ·

User Groups

    · SOW should specify frequency and location of user group meetings.
    · SOW should specify disposition of information generated during the meetings.
    · SOW should specify who is responsible for taking minutes and tracking action items.
    · User groups most beneficial with large numbers of varied CITIS users.

 

8.2.4.3.2  Printing Capabilities
The ability of the CITIS to print file contents should be considered by the NATO/NATO nations and the contractor. Although the goal of CITIS and CALS in general is to migrate from paper-based information to digital formats, real-world practices indicate that paper is still a popular medium for information distribution. The program manager should determine whether CITIS users would be allowed to print portions of CITIS data without having to download the entire file to their computer. If this service is desired, the program manager needs to require the contractor to incorporate a printing capability into CITIS.

The NATO/NATO nations also needs to specify the desired print options such as printing out a specific range of pages or portion of a document in addition to printing the entire document. It is very important that the NATO/NATO nations include printing capability requirements in the contract so they can be appropriately priced, because the cost and effort to implement these capabilities may be significant. Printer compatibility issues cause problems for many information management programs because current technology can be restrictive in terms of what types of files will print out correctly on various types of printers (e.g., non-Encapsulated PostScript files do not print well on PostScript printers).


8.2.4.4  Contracting for CITIS
A key element in the contracting process for CITIS and CALS in general is the development of the NATO/NATO nations Concept of Operations (NCoO). This NCoO is provided as User Furnished Information (UFI) with the Request For Proposal (RFP).


8.2.4.4.1  NATO/NATO Nations Concept of Operations
A well-developed NCoO is an extremely important part of the acquisition process. The NCoO benefits both the NATO/NATO nations agency preparing it and the contractors using it to respond to an RFP. Development of the NCoO will help ensure that the NATO/NATO nations can access or receive the correct version and formats of digital data products needed to acquire and support a specific program. The NCoO includes information on the data types to be digitally accessed/delivered, who will use the data and where they are geographically located, how the data will be used (e.g., view, comment, etc.), the data user's infrastructure (hardware, software, networks), the type of digital data deliverables (processable or not), the data formats, relevant data interchange standards, and mechanisms/media for data delivery/access. An unexpected benefit to the NCoO process is that analysis of the NCoO information can result in identification of areas for internal improvements, such as elimination of data that is no longer needed, or upgrades for outdated software or equipment. A detailed discussion of the NCoO development process can be found in section 1 of this handbook.

The NCoO should be part of the RFP package because it often contains more detailed information than is contained in the SOW and RFP. Such details as data user locations and specific NATO/NATO nations hardware, software, and networks are extremely important to the contractor when preparing the CITIS portion of its proposal. Inclusion of the NCoO also encourages early interactive planning between the NATO/NATO nations and the contractor.

In its response to the RFP (in the CAC if one is required), the contractor should specify any CITIS requirements that it believes are important in defining the CITIS but were not included in the NCoO or SOW. The RFP response should contain a CITIS development plan that shows the order in which the various services and functions will be implemented along with a proposed schedule for their availability.

The contractor has the opportunity, through the CAC, to propose any alternative processes, procedures, or systems that may be more efficient or cost-effective than those set forth by the NATO/NATO nations in the NCoO and SOW. Any limitations in the CITIS system that will affect a NATO/NATO nations requirement should be specified as well (e.g., UFI file size limits). Any additional responsibilities identified by the contractor and not specifically addressed in the NCoO or SOW, such as hardware, software, and/or network installations, should also be included in the proposal.


8.2.4.4.2  Solicitation
The solicitation defines the scope of work, schedule, conditions, clauses, instructions, evaluation criteria, and deliverables to be provided. The CALS RFP elements should address the requirements for electronic (on-line/CITIS) services, digital data delivery, and functional integration.


8.2.4.4.3  CITIS Contract Line Item Number
Use of a CITIS Contract Line Item Number (CLIN) provides a standard methodology for acquiring CITIS-type services and will simplify the evaluation of CITIS portion of the RFP responses because all offerors responding to the RFP will have their cost for developing a CITIS clearly priced. When pricing elements are subdivided, the evaluation team will be able to verify that the contractor has included pricing to cover all aspects of the CITIS specified within the SOW. The individual pricing elements will also provide a consistent method for later auditing of the CITIS costs. If desired, the tailorable CITIS functions may be priced as alternative or optional CLIN(s) to allow cost/benefit assessment.

When subdivision of CITIS pricing elements is required, typical costing areas can include system development and installation, equipment lease, access/connect times, equipment purchase, telecommunications, data storage, data delivery, infrastructure upgrades, data conversion, software licenses, system maintenance, and security. The system development task includes software development and hardware/software/ network integration, which typically requires the greatest effort, and thus the greatest cost. The access/connect time cost includes the cost for the contractor to connect with the NATO/NATO nations' computer systems; it could also include the connection charges for NATO/NATO nations to utilize a hotline to access CITIS, if one has been required.

The telecommunications costs could include the cost to install and maintain dedicated modem lines, high-speed optical lines, or a hotline number. The data storage costs could include any service center-type costs associated with storage of large amounts of digital data (e.g., costs for data administration, backups, and maintenance). The cost of data delivery is essentially an application of the standard connection cost-per-minute to an estimate of the amount of data projected to be delivered via CITIS. The infrastructure upgrade pricing element could include the cost of any hardware and software upgrades, network (LAN and/or WAN) purchase and installation, and costs for the purchase of data storage devices (e.g., very large hard drives, optical drives, CD ROM jukeboxes, etc.) that will be needed to store all the CITIS data. Software license costs can include purchase of individual and/or site licenses. Security costs could include the costs of any special measures required for the CITIS to handle classified data. Cost to develop the data to be included in CITIS (excluding data conversions) is not included in the CITIS line item.


8.2.4.4.4  Sample CITIS Statement of Work
The following sections contain the language that could appear in a SOW for development of a CITIS. Text appearing as [times new roman] is provided as the language that would be used in the actual SOW. Text appearing as [small caps] within the actual SOW text indicates information input by program managers relevant to their programs. Text appearing as [times roman] at the end of each paragraph is provided as supplemental information that would not be used in the actual SOW.


8.2.4.4.4.1  Scope
The contractor shall establish a digital technical information system to provide automation and integration of the generation, delivery, and uses of [ xxx program] technical information. Unless otherwise specified within the contract, all, or any portion of, the technical information specified herein shall be developed and delivered in a digital form compatible with requirements stated herein. Unless specifically stated herein, the following requirements do not replace or amend requirements for delivery of technical information in non-digital forms specified elsewhere in the contract.


8.2.4.4.4.2  Applicable Documents
[List all documents that apply.]


8.2.4.4.4.3  Specific Requirements
The contractor shall provide a Contractor Integrated Technical Information Service (CITIS) in accordance with the specific requirements as identified herein. The contractor will deliver in place all data associated with this procurement and identified within this SOW and the attached CDRL, unless otherwise noted. This data shall be maintained in an electronic form, and made available to authorized NATO/NATO nations users and reviewers, and their assigned representatives, in accordance with the requirements described below.


8.2.4.4.4.4  CALSIP
The contractor shall prepare a CALSIP that describes the ways in which CALS techniques are to be applied throughout the life of the contract to satisfy requirements for service, infrastructure, media, and format. The CALSIP shall be a living document to explore CITIS opportunities and technology as contractor-NATO/NATO nations infrastructure evolve over time. The CALSIP shall be updated every [365 days] throughout the life of the contract. The CALSIP updates shall define implementation plans for the upcoming period in greater detail, resolve outstanding strategy issues, respond to strategic and technology changes, and recommend specific alternative approaches for continuation of CALS and CITIS in the next period. CALSIP contents, as a minimum, shall include:

[The program manager is not required to contract for a CALSIP, but it is highly recommended. The CALSIP is the only standard way we have of gaining the data required by the instructions for ensuring the requirements have been met. In today's acquisition world, the attitude is: if it is not considered a requirement, it will not be done.]


8.2.4.4.4.5  CITIS Site Implementation Priorities
CITIS shall be made available to [all] locations listed in the NCoO. [ ..... ], shall serve as the primary installation and testing site. After acceptance of each version of the CITIS software at the primary site, [all] other sites shall be allowed access to the current CITIS version.

[If CITIS will not be provided to all locations listed in the NCoO, the exceptions or inclusions should be specified here (whichever list is shorter). A copy of the table of locations from the NCoO may be included here, if desired. Selection of a primary installation site is not required, but is highly recommended. If an NCoO is not being provided with the RFP, a table of NATO/NATO nations locations is needed here.]


8.2.4.4.4.6  CITIS Period of Performance
The [xxx program] CITIS period of performance shall begin on [1 january 1996] and continue until [1 january 2001] at [ ...... ]. CITIS service shall be available to [all] other locations on [1 february 1996] or after CITIS acceptance at the primary site, whichever is later, and continue until [1 january 2001].

[The CITIS period of performance specifies the date when the CITIS is to be made initially available to the NATO/NATO nations; it is assumed that the CITIS development phase will begin immediately after contract award and the basic CITIS will be installed and functional by the beginning period of performance date. The period of performance may be specified to be the same for all locations, or it may be different for each location.]


8.2.4.4.4.7  CITIS Installation
Any peculiar software that must be resident on NATO/NATO nations access terminals or computers will be provided and maintained by the contractor. It will also be installed by the contractor if complexity of the software warrants/requires special installation and testing procedures.


8.2.4.4.4.8  CITIS Data Residency and Storage
Data shall be available through CITIS for a period of [one year] after its creation or revision unless otherwise requested by the NATO/NATO nations. Exceptions include short-lived data such as meeting agenda, meeting minutes, trip reports, status reports, etc., which will be stored on CITIS for a period of [ 60 days ] after creation or revision. All data shall be archived after its CITIS storage time has expired, unless it has been specified for either deletion or further retention on the CITIS by the NATO/NATO nations.

[If desired, the NATO/NATO nations may break down the CITIS data availability further by specifying the residency period for each type of data (e.g., "engineering drawings shall be available via CITIS throughout the life of the contract"). If the archive function is not being required, the program manager must specify the disposition of the data after its CITIS storage time is expired. Note that specification of a storage period is not required; the program manager may specify that all data is stored on CITIS throughout the life of the contract.]


8.2.4.4.4.9  Data Classification
The CITIS shall be required to handle [unclassified] data only.

[Specify each level of classification that the CITIS will be required to handle]


8.2.4.4.4.10  Functions and Services
The contractor shall develop a CITIS that incorporates all CITIS services and core functions and the additional requirements specified below. The CITIS shall also include the following tailorable functions: [archive, download, sort, and user groups].


8.2.4.4.4.11  Availability and Accessibility
The CITIS shall provide [24-hour] on-line service [every] day of the week. Users shall be notified [24] hours in advance of any scheduled maintenance or other events affecting CITIS accessibility.

[For the standard, unclassified CITIS, 24-hour on-line service is a reasonable requirement. When classified data is contained on the CITIS, the NATO/NATO nations will probably need to specify the hours and days for which the classified data should be available. Sample language could be: "CITIS shall provide 24-hour on-line service every day of the week for unclassified data. Classified data shall be available between the hours of 7:00 a.m. and 7:00 p.m., on normal working days only (no weekends or holidays)."]


8.2.4.4.4.12  User Furnished Information
The contractor shall provide data users with access to UFI via the CITIS. The NATO/NATO nations shall provide approximately [25] data items that will include [technical manuals, technical reports, and engineering drawings]. All UFI will be provided in [digital] formats. The technical manuals and reports will be provided in [raster format and standard word-processing formats], and the engineering drawings will be provided in [standard cad formats]. The maximum file size for any data item is [ 5 mb]. UFI shall be included in the data item index, and CITIS users shall be able to, as a minimum, [search for, view, and download] all UFI.

[Specify the approximate number, type, and formats of User Furnished Information (UFI) to the extent possible. If the specific software applications used to create the data are known, they can be listed here. Specify the CITIS functions required for the UFI (not all are appropriate). ]


8.2.4.4.4.13  Multi-user Access
The CITIS shall provide simultaneous access to [10] users.


8.2.4.4.4.14  Interface Compatibility
The CITIS shall be compatible with [all systems (hardware and operating systems)] listed in the NCoO. [compatibility with every software application is not required.]

[If the systems listed in the NCoO cover a wide range of hardware and operating systems, the NATO/NATO nations may choose to require compatibility with only the most prevalent of the systems in order to reduce the cost of CITIS development. The contractor should develop the CITIS to be compatible with the predominant software used by the NATO/NATO nations, but not necessarily every software application (especially if the NATO/NATO nations is using older applications). ]


8.2.4.4.4.15  Communication Protocols
Communication of data between sites via CITIS shall utilize the [transmission control protocol/internet protocol (tcp/ip)] and shall be in accordance with [...].


8.2.4.4.4.16  Training Support
The contractor shall provide CITIS training through development of a [citis user's manual] that shall instruct users on how to gain access to CITIS, how to locate data, and how to utilize the various CITIS functions. [the contractor shall travel to the primary citis site to provide hands-on training after installation of the completed citis.] [all other citis locations] will receive the CITIS USER'S MANUAL and will have access to contractor telephone support for assistance with CITIS installation, access, and usage. The contractor shall update the USER'S MANUAL [after each major system change], and minor changes can be accumulated and a revised document generated when they impact operation significantly.

[If contractor travel to CITIS user sites for training is desired, specify each or all of the sites to be visited. If there are a large number of CITIS locations, the NATO/NATO nations may also want to require the contractor to develop a CITIS Operator's Manual that will provide detailed information on CITIS installation, trouble-shooting, and access.]


8.2.4.4.4.17  Telephone Support
The contractor shall provide telephone support between the hours of [7:00 a.m. and 6:00 p.m.].


8.2.4.4.4.18  Data Configuration Management
[The contractor shall devise a standard file naming scheme that shall be employed by all organizations contributing data to the CITIS. This scheme shall allow the CITIS user to rapidly identify desired files. All file names shall comply with the maximum name length allowed by the most restrictive operating system used at a CITIS location. If dos is one of the primary operating systems used by the NATO/NATO nations, all file names will comply with the 8.3 (8 character name plus 3 character file extension) naming convention.]

[All requirements listed above are optional.]


8.2.4.4.4.19  Security
The contractor shall establish a security system and enforce data protection and integrity standards. System security engineering principles as outlined in [ ... ] shall be used. Controls to prevent unauthorized access shall be established and detailed in the System Design Document. The plan shall be based on the results of documented data protection and integrity, threat and vulnerability analysis, risk assessments, and tradeoff analyzes. Vulnerabilities that remain after security system design shall be identified. The plan shall include disaster recovery provisions. Security requirements that must be complied with by NATO/NATO nations personnel will be identified to the NATO/NATO nations in the security section of the System Design Document.

[If higher data classifications will be required, include information regarding any special security provisions .]


8.2.4.4.4.20  Core Functions
The core functions shall be implemented in accordance with [ ... ]. [the acknowledge function shall be satisfied through automatic confirmation of data transfer by the receiving computer.]


8.2.4.4.4.21  Tailorable Functions
The tailorable functions [archive, download, sort, and user groups] shall be implemented in accordance with [ ... ] and the additional requirements described below.


8.2.4.4.4.22  Archive
[The contractor shall create and maintain an archive of data whose CITIS storage time has expired. The contractor shall determine the method/media for this archive. The contractor shall track and index all archived data, and shall provide access to this data upon request. The contractor shall provide an on-line capability for users to request that archived data be made available through the CITIS. All requests for archived data shall be acknowledged and an approximate time frame for availability provided. Requested data should be made available through CITIS within 24 hours during the normal work week. An electronic message shall be sent to the data requester when the data becomes available on the CITIS. If the requested data file is found to be larger than 30 MB in size, it will not be made available on the CITIS, and the requester will be notified and queried regarding the preferred physical media for data delivery.]

[All requirements listed above are optional.]


8.2.4.4.4.23  Download
[The maximum file size that shall be downloaded is 30 MB in order to reduce potential telecommunications problems. The contractor shall provide on-line capability for users to request physical delivery of data files too large to download. Users shall be provided with a list of possible media from which they may select the preferred delivery method.]

[All requirements listed above are optional.]


8.2.4.4.4.24  User Groups
[CITIS user groups shall be conducted on a quarterly basis, and meetings shall alternate between the contractor's and the NATO/NATO nations' primary site. Advance notice of meetings shall be distributed through the CITIS E-Mail system. The contractor shall be responsible for preparing meeting agendas and minutes. Meeting minutes shall include a list of action items and their dispositions, and shall be made available through the CITIS to all CITIS users.]

[All requirements listed above are optional.]


8.2.4.4.4.25  Printing Capabilities
The CITIS shall include the capability for users to print information locally and shall allow users to specify a [single page, a range of pages, or the full document] for printing. This capability shall be independent of the printer being used.

[Specify the document printing options desired.]


8.2.4.4.4.26  Licensing
The contractor shall be responsible for obtaining any licenses required for CITIS users to access the commercial-off-the-shelf (COTS) software applications used to perform the CITIS functions. The NATO/NATO nations will assist the contractor in obtaining permission to include any applications developed by other contractors and/or owned by the NATO/NATO nations in the CITIS.


8.2.4.4.4.27  Subcontractor Data
The contractor shall provide access to appropriate subcontractor data via the CITIS. The contractor shall determine the method by which the subcontractor shall provide this data and the manner in which it is incorporated into the CITIS.

[The contractor will determine whether the subcontractors shall be linked to the CITIS network or whether they will simply provide their data in digital formats, and the prime contractor will then load it into CITIS.]


8.2.4.4.4.28  Program Data Repository
The contractor shall propose an [ xxx program ] working data repository scheme in the System Design Document. Direct access to all contractor and subcontractor databases is the preferred method, but it is not required.

[The program manager should not typically specify the data repository scheme because the contractor will need to assess the compatibility of the suppliers' and subcontractors' infrastructures with the proposed CITIS before deciding whether to incorporate them into the CITIS network. NATO/NATO nations specification of a data repository scheme without prior knowledge of the infrastructures involved could result in substantial unnecessary costs and effort.]


8.2.4.4.4.29  Equipment and Telecommunications
The NATO/NATO nations shall utilize its own hardware, software, and networks to access the CITIS. The NATO/NATO nations shall be responsible for installation and maintenance of any dedicated modem and/or high-speed optical lines, if needed, at NATO/NATO nations CITIS user facilities. The contractor shall provide a hotline number accessible by a maximum of 10 concurrent users. This hotline shall be available during the hours specified in this SOW.

[The program manager should specify who will provide CITIS equipment (e.g., computer terminals, modems, etc.) and telecommunications (e.g., dedicated modem or high-speed optical lines). Either the contractor or the NATO/NATO nations or both may be responsible for providing this equipment/service.]


8.2.4.4.4.30  CITIS Acceptance and Testing
CITIS acceptance includes acceptance of the service and CITIS CLIN, assurances of adequate acceptance testing, and electronic data transfer service acceptance. Acceptance of the service and the CITIS CLIN, if utilized, is a verification that the contractor has provided the service as specified. Provision of the CITIS functional requirements specified in the SOW will be verified, including such capabilities as core and tailorable CITIS functions, service availability, and maintenance response. Assurances of adequate acceptance testing for CITIS shall be obtained via contractor demonstration of the service. The test shall include demonstration of functional capabilities and verification that the CITIS will handle representative data required to be formally delivered through CITIS without alteration of the data product. Such a test is not required for each delivery, but shall be rerun if major maintenance or modifications have been performed or the sending or receiving systems have been changed enough to warrant additional tests. If specific test data is deemed necessary for adequate testing of a CITIS, that test data shall be provided and results reviewed at the primary CITIS site. On-line access service shall be accepted when it is demonstrated that a person with proper authorization can utilize the contractually required core and tailorable CITIS functions from a terminal or workstation at the primary site or as otherwise agreed. Electronic data transfer service acceptance shall occur when a single instance of transfer of the specific deliverable type can be achieved, including successful download and retrieval of data into the NATO/NATO nations' system. This data may be real product data or test data, as appropriate.


8.2.4.4.4.31  Final Disposition of Data
Upon completion of the initial CITIS contract, the NATO/NATO nations will decide whether the contractor, the NATO/NATO nations, or a third-party contractor will continue maintenance of the CITIS.

[If the final disposition of the data is known, it should be specified here. The program manager will typically want to wait for the CITIS to be developed and its usefulness determined before deciding who, if anyone, should maintain it after the initial contract is completed.]


8.2.4.4.5  Deliverables
Some of the possible deliverables for the CITIS development task include:

The System Design Document should include complete details of the specific hardware, software, and network configurations used/planned for CITIS, along with a detailed description of the CITIS security features. If desired, this document can also contain a data element dictionary that lists field names and descriptions of all data elements in the CITIS database(s). The key element of the Program Management Plan is a detailed schedule that includes the implementation of the various CITIS services and functions and estimated preliminary installation and test dates for the primary site. The System Test Description should include the types of tests to be conducted, the test procedures, the test schedule, and the locations of the tests.


8.2.4.5  CITIS Development
The primary requirement for creating a successful CITIS is preliminary planning. The contractor and the NATO/NATO nations must discuss and agree upon a large number of issues before the CITIS development is begun. Both sides must understand exactly which functions are required and how the NATO/NATO nations intend to utilize them.

They must discuss the hardware, software, and networks that will be used, how the CITIS should handle data in different formats, and how the contractor should handle major changes in the NATO/NATO nation's computer infrastructure. The contractor also needs to decide, with the help of the NATO/NATO nations, how and to what extent to include supplier/subcontractor data and what type of data repository method makes the most sense for the program.

Creation of a successful CITIS requires continuous communication between the CITIS developers and the CITIS users. Otherwise, the developers may create a system that satisfies the requirements, but does not meet the user's actual needs. This is especially a problem if the requirements are not well defined in the contract.


8.2.4.5.1  CITIS Strategy
During the planning phase of the CITIS development process, contractors must determine their strategy in terms of the location/distribution of the program-specific data repository, the extent to which their suppliers/subcontractors will be included in the CITIS, and CITIS data availability.


8.2.4.5.1.1  CITIS Program-Specific Working Data Repositories
A major decision that must be made early in the planning process is where the data will reside. This decision does not have to be made prior to solicitation release. If the NATO/NATO nations has already decided on the form of its program-specific data repository, it should be specified in the SOW, but if not, the contractor should propose a solution after contract award in the CALSIP and/or the System Design Document. The main options for program-specific data repository strategies include:

Option 1: database repository resides with the prime contractor as a single physical integrated database.

It is the simplest option to implement, with all data residing in a single database at a single location. However, this option could result in extensive duplication of data, since data is copied from wherever it originated and loaded into the database. Another potential drawback to this method is reduced accuracy-timeliness of data, since physical copies of updated information must be sent to and loaded into the main database.

Option 2: database repository resides with the prime in the form of distributed multiple databases with a navigator.

It allows for distributed databases within the prime contractor that are accessed via a navigation system. With this option, each functional area (e.g., logistics, engineering, technical publications, etc.) maintains its own database and data, which is accessible by the CITIS users through the central navigator. There is no single physical database with option 2. This option is an improvement over the first option because it significantly reduces the amount of redundant data within the databases. It also improves data accuracy through the timeliness of incorporation of data updates into the database. The navigator system will simply be a pointer to the location where each particular piece of data is stored. Supplier/subcontractor data, if desired, is provided by the supplier and loaded into the CITIS (no direct access to supplier databases).

Option 3: database repository resides with the prime; existing information systems are interfaced to extract CITIS data in a central repository.

It involves a program-specific data repository that resides with the prime contractor and is made up of multiple databases. This option differs from option 2 in that even though the databases are distributed, they contain duplicate information that allows data to be easily linked together (i.e., a relational database management system). The central data repository typically contains basic information about each functional area, program, or type of data that is used to interface with more extensive databases containing related information. This method can also be easily used to identify, for example, parts/equipment used on more than one system. Another benefit to data linking is that when information is changed in one location, the CITIS system can be designed to reflect that change in any other databases containing that same data. Supplier/subcontractor data, if desired, is provided by the supplier and loaded into the CITIS (no direct access to supplier databases).

Option 4: database repository resides with the prime and suppliers (many), with a navigator (gateway processor) to pass requests/access to supplier databases.

Option 4 is the most extensive of all four options, because it allows direct access not only to contractor databases, but to supplier and subcontractor databases as well. This option is typically the most difficult to implement, since CITIS could be required to interface with a potentially large number of different systems. This option would require suppliers to be responsible for their own data, thus improving the accuracy of the data available to the CITIS users. One of the drawbacks to the all-encompassing CITIS is the problem of proprietary data rights and privileges. Another potentially major drawback to this type of CITIS network is the possibility of suppliers/subcontractors utilizing their own data management/storage systems that are not compatible with anyone else's. Using current technology, the cost and effort to set up a CITIS system that can interface with all the different data management systems could be prohibitive. Before making a decision on whether to provide CITIS access to supplier/subcontractor databases directly, the contractor should identify the hardware and software used by each candidate system to determine the complexity, and thus feasibility, of incorporating it into the CITIS network.


8.2.4.5.1.2  CITIS and Suppliers/Subcontractors
If supplier/subcontractor data is included in the CITIS, the contractor must develop a supplier data input strategy. This input method should be based on the extent and complexity of the CITIS. The four methods for incorporation of subcontractor data into the CITIS include:

Method 1 is almost never recommended because of the cost and effort required to scan in the data. In addition, the resultant raster data is in a non-processable format, which will significantly reduce the usefulness of the subcontractor-supplied data.

Methods 2 and 3 are both reasonable options when a relatively basic (lower cost) CITIS is desired, because they allow for reasonably simple incorporation of data into the CITIS databases. Digital delivery of subcontractor data to the prime contractor for download into CITIS would eliminate the need to interface with a potentially large number of different subcontractors' information management systems. If, however, a robust CITIS is planned, suppliers/subcontractors should be a part of the CITIS network, and their data should reside in-house.

Method 4 should provide the greatest subcontractor data accuracy and timeliness, but these benefits may be outweighed by the typically higher cost and effort to implement the robust CITIS. In general, methods 2 and 3 should be the simplest, least costly methods to implement for incorporation of subcontractor data into the CITIS.


8.2.4.5.1.3  Data Availability Factors
For most defense programs, a large volume of technical data will be created by the contractor in support of the program. Before this data can be released for access through the CITIS, it must meet the programmatic requirements and pass the contractual restrictions. Only that data that meets all the requirements and restrictions should be made available through the CITIS.


8.2.4.5.1.4  Acceptance of Data Delivered via CITIS
The contract must address the questions of what constitutes data delivery, and who in the NATO/NATO nations will receive, inspect, and accept the data. The NATO/NATO nations will specify in the contract the delivery methods for each CDRL item, and if delivery includes CITIS, this delivery may be in the form of either in-place delivery, in which the data item is considered delivered once it becomes available on the CITIS, or it may be in the form of a physical data download by the NATO/NATO nations from the CITIS.

The NATO/NATO nations contracting officer should decide, and the decision should be specified in the contract, whether the data inspection and acceptance can be performed electronically (e.g., some form of electronic signature or other means of indicating approval or disapproval), or whether it should be done in a traditional method. If an organization will serve as the approving official responsible for taking receipt of the data and then coordinating the inspection and acceptance, that organization should be identified in the SOW.


8.2.4.5.2  Hardware, Software, and Networks
The selection of hardware and software used to create the CITIS is critical and must be thoroughly analyzed before any attempt to develop CITIS is begun. The CITIS configuration should be determined only after analysis and comparison of the NATO/NATO nations', contractor's, and subcontractor's (if included in CITIS) infrastructures. Some important considerations include compatibility of operating systems, file formats, and hardware and telecommunications options. The CITIS designer should also consider future impacts to the CITIS system should NATO/NATO nations users upgrade their hardware or software.


8.2.4.5.2.1  Operating System Considerations
One of the basic problems between different operating systems (e.g., DOS vs. UNIX) is the allowable length of file names. DOS is restricted to the 8.3 (8 character name plus 3 characters for the file extension) file naming convention, while UNIX allows much larger file names. Because of this problem, close attention should be paid to indexing and file management schemes.


8.2.4.5.2.2  File Format Considerations
Before any CITIS development is performed, the contractor must determine how CITIS will handle data in different formats. A matrix should be developed during the CITIS planning stage showing which software tools will be used and how the NATO/NATO nations and contractor data will be stored and displayed. An ideal CITIS would be able to display and process data in any format, regardless of the software tool used to develop it. However, this ideal CITIS may be economically prohibitive and technologically challenging. In practice, the two primary options for data handling are:

The primary drawback to the first option is that the system operators may be required to reprocess data that has already been created. This translation process introduces the potential to lose data and/or format information. If the data has been created with a wide variety of applications, conversion to a single format is a serious weakness that may have a significant economic impact. Composite documents (which may include text, graphics, databases, and/or spreadsheets) are especially difficult to convert into a single format because some software packages may not reproduce the information accurately, and in some cases, not at all.

The drawbacks to the second option include greater complexity of the CITIS system and the necessity for CITIS users to be trained on and become familiar with a variety of viewing/editing tools. The greater the number of formats the CITIS data viewer/editor must handle, the more complex and difficult to develop the system will be. Depending on the number of applications launched, software licensing costs could also become a major consideration.

The solution to the data format problem may be the use of a neutral file format that allows data created with a variety of different software applications to be saved in a format that can be read by anyone possessing the associated file reader software.


8.2.4.5.2.3  Neutral Data File Options
Depending on the expected CITIS data usage (view, process, comment, etc.), the contractor may choose to translate appropriate data into a neutral format rather than attempting to retain information in its original file formats. These neutral formats, in general, can be created for files developed with a variety of different applications and can then be read by anyone possessing the associated reader software.

Textual data (e.g., technical manuals and reports, graphics, spreadsheets, etc.) is particularly well suited for conversion to neutral file formats; databases and some engineering drawing formats should be retained in their original format or converted to a standardized format (e.g., convert from specific CAD format to IGES). Some examples of neutral file formats include platform-independent files and Standard Generalized Markup Language (SGML) files.

Several industry-developed software products for creating platform-independent files have recently become available that allow users to save information created in a variety of software applications and formats, including text, graphics, and spreadsheets, into a platform-independent file format, which can then be viewed and printed by anyone possessing the associated reader software.

Many applications also allow reader-software users to annotate data and copy information that can then be pasted into other word processing programs. Because of their flexibility in handling a wide range of software packages, contractors may want to explore these platform-independent file applications when determining standard CITIS file formats.

SGML is the CALS standard for the exchange of text material for technical documents. It is a non-proprietary format that is not bound to any system software or platform. SGML can handle both text and graphics. A number of SGML authoring software packages are currently available as COTS software. As with the platform-independent files, SGML reader software is required to utilize data in an SGML format.

Most SGML readers allow the user to, as a minimum, view, annotate, and print data. One of the current considerations when selecting SGML formats is that it is not yet widely used because of the present lack of Document Type Definitions (DTD) and Formatting Output Specification Instances (FOSI), which are needed to create or translate data into SGML formats.

The neutral format reader software discussed above is especially appropriate for data that will be viewed and printed only. Some SGML readers, and the authoring versions of platform-independent file and SGML applications should allow users to perform most of the other data functions such as processing and updating the data.


8.2.4.5.2.4  Hardware and Telecommunications Options
When determining the infrastructure for CITIS, the program manager must decide whether the contractor or the NATO/NATO nations or both will provide the hardware and telecommunications for the NATO/NATO nations to interface with CITIS. Typically, the NATO/NATO nations will use its own computer hardware, including modems, and software to access the CITIS data, with the contractor providing only the software necessary to access CITIS. However, the program manager may choose to have the contractor provide computer hardware (e.g., complete PCS, terminals, etc.) and/or software to be located at NATO/NATO nations facilities and used exclusively for CITIS access. This option may be especially attractive for locations that could otherwise require infrastructure upgrades to access CITIS.

Telecommunications involves the physical connection to CITIS via telephone or other type of lines. The CITIS access can be via regular phone lines, dedicated modem lines, high-speed optical lines, or networks, and will typically be a combination of these methods.

If any new lines or networks will be required, the program manager must decide whether the NATO/NATO nations or the contractor will be responsible for line installation and maintenance. The NATO/NATO nations will typically pay for its own connection time charges (e.g., phone line usage) for use of its own telecommunications lines. The NATO/NATO nations however, may require the contractor to establish an 800-number hotline that can be used by the specified number of concurrent CITIS users.


8.2.4.5.2.5  Infrastructure Changes
Because of the rapidly changing computer hardware and software technology, it is reasonable to assume that at some point during the life of the CITIS, the NATO/NATO nations users will upgrade either their hardware or software or both. This upgrade can cause major problems for the CITIS developers if the existing CITIS has been created to be compatible only with NATO/NATO nations systems as they were at the beginning of the development effort. The NATO/NATO nations and the contractor should agree up-front as to what technology refreshments the NATO/NATO nations can expect the contractor to incorporate after the CITIS has been implemented. The NATO/NATO nations may also want to state explicitly that CITIS shall be upgraded to be compatible with any major changes in hardware and/or network configuration.

Problems can occur when a CITIS user facility reconfigures its networks and then finds that it can no longer communicate properly with the CITIS. Obviously, there needs to be some control over and planning for the number of anticipated changes the contractor is required to incorporate/handle. Ideally, the CITIS will be developed to operate independently of users' operating systems and specific hardware and software. In reality, however, the hardware and software compatibility problems described above can and will occur. CITIS user group meetings can serve as an excellent forum for discussion of compatibility problems, technology advancements, and the advantages and disadvantages to upgrades to the CITIS.

It is highly recommended that the NATO/NATO nations designate at least one person who is knowledgeable in computer hardware, software, and networks to be its CITIS administrator. This person will be trained in the specifics of how the CITIS system works and how it is set up at their facility. Ideally, a CITIS administrator would be selected for each of the NATO/NATO nations' CITIS locations. The CITIS administrator(s) should filter NATO/NATO nations complaints and issues before bringing them to the contractor, and should be responsible for making upgrades to local hardware and software work with CITIS. When a hardware or network incompatibility problem arises, it is often due to a change in the user's PC or network configuration. The local CITIS administrator should attempt to solve compatibility problems before contacting the CITIS developers, who may simply direct the problem back to the NATO/NATO nations as an internal facility problem.


8.2.4.6  CITIS Issues
When CITIS is being considered and/or developed, the program manager must be aware of some of the legal issues accompanying the use of a CITIS.


8.2.4.6.1  Legal Issues
Because CITIS can involve extensive sharing of data between contractors, subcontractors, and NATO/NATO nations activities, a significant number of legal issues have been raised and are still being debated. Some of the most prevalent issues include the questions of proprietary data rights (who owns the data when), software licensing, warranties and liabilities, and international data exchange.


8.2.4.6.1.1  Proprietary Data Rights
NATO/NATO nations, in consequence of the delivery of a data item, should not acquire ownership of the data item or any rights or license to use, copy, or disclose such data item. The extent and nature of rights that the NATO/NATO nations may acquire to use, copy, or disclose data items shall be as expressly stated in the contract. When dealing with intellectual property, there is an increased risk of misuse of proprietary and business sensitive data in digital form. No NATO regulation currently exists to assess liability on third parties for copyright or patent infringement. Even with access limitations, proprietary markings, such as proprietary legends and restrictive distribution statements, may be inadvertently deleted. The problem could be compounded if the CITIS network includes access by other contractors and subcontractors in addition to the prime contractor, because the release of proprietary data to widely accessed databases could amount to abandonment of secrecy with a resultant loss of rights. Finally, there is the potential problem where Contractor A does not want Contractor B to have access to its data, but it can be difficult to prevent that access on a robust CITIS network. All of these issues should be considered and discussed by the NATO/NATO nations and the prime contractor in the early stages of CITIS planning.


8.2.4.6.1.2  Software Rights/Licensing
Potential third party licensing problems can arise whenever CITIS is used to launch/access other applications. If the applications being accessed are commercial software packages, the contractor will need to investigate the licensing policies of the software development company. In some cases, they may need to either purchase individual licenses for the maximum number of concurrent CITIS users or purchase a network or site license that allows specified or unlimited usage of the software. If the applications being accessed were developed by either the prime or other contractor, the CITIS developers will need to verify that the application has been released for general use. If access is restricted, those restrictions must be incorporated into the CITIS access rule set that will deny access to anyone without the proper authorization.

Care should be taken to identify and grant access to both commercial and contractor-developed applications only to people who actually require that access in order to avoid excessive license purchases and proprietary data conflicts (i.e., do not just automatically grant all CITIS users access to all applications).


8.2.4.6.2  Warranties and Liabilities
The contractor warrants that the data provided by them via the CITIS is accurate and complete, but the question of who is responsible for warranting data products created by CITIS users with ad-hoc queries has not yet been answered. The contractor can (and should) be held liable for providing defective data to the NATO/NATO nations, but unfortunately, lack of statutory laws results in the contractor also being held liable for misuse of any data they provide. Until existing laws are changed, the contractor is liable for damages when data provided through CITIS is used incorrectly.


8.2.4.6.3  International Data Exchange
International data exchange is complicated by differences in treatment of intellectual data from nation to nation. Some nations do not recognize or protect intellectual property. Export licensing of technical data also creates a barrier to international CITIS implementation. Any data to be released internationally needs prior NATO/NATO nations approval.


8.2.5  Applying CALS to the Acquisition Logistics and Operational Logistics Processes


8.2.5.1  Acquisition Logistics and Operational Logistics

 


Figure 8.2.5.1-1  Acquire Defense System


The life-cycle of a weapon system begins with the identification of a perceived need, which is then analyzed and translated into detailed requirements. Those requirements constitute the input to the design process, which is followed by the production of the prime equipment of the weapon system, together with its associated support equipment. The system is then fielded and, after its useful life, it is phased out (Figure 8.2.5.1-1).

Within the life-cycle of a weapon system, Acquisition Logistics is the process managed within the specification, definition, and production of defense equipment, which concurrently identifies the support elements that will be required during the "useful life" of the equipment. The basic elements of the Acquisition Logistics are:

Operational Logistics covers those functions that support the equipment through its "useful life" (from the utilization process onward to its withdrawal from service). The operational logistics basic functions include:


8.2.5.2  ILS, LSA, and LSAR Introduction
Within the United States, the application of the 1388 series of mil standards has been rescinded. However, the basic activities these standards proscribed and managed remain integral parts of the acquisition process. Additionally, many organizations have invested heavily in processes and tools that are structured to provide 1388 compliant LSA materials and will continue to utilize these methods while transitioning to a performance based environment. Therefore, this LSA and LSAR discussion is presented retaining references to the 1388 series.


8.2.5.2.1  The Integrated Logistics Support
The Integrated Logistics Support (ILS) includes all those coordinated and iterative management and technical tasks required to:

It is an organized, planned effort that provides for support and maintenance considerations that influence the design of systems acquired by the Defense. The planning of the ILS effort is the key in fitting all of the logistic support elements together in a timely manner.


8.2.5.2.2  Logistics Support Analysis
Logistics Support Analysis (LSA) is a systematic and comprehensive analytical process that is conducted on an iterative basis through all life-cycle phases of the system/equipment. LSA is for quantifying and measuring supportability objectives. LSA information consists of all data resulting from the analysis tasks and is intended to be the primary source of validated, integrated, design-related product support information pertaining to an acquisition program.

The Logistics Support Analysis process ties the ILS efforts together following the full life-cycle of the end item. The LSA process is a subset of systems engineering effort. It performs a planned series of tasks to:

LSA process was formerly centered on MIL-STD-1388 that used to be a US Department of Defense standard. Its major strengths are the presentation of a disciplined process of LSA (a philosophy not specific to nation or application) and the description of a set of LSA data elements that may be handled in computer database to derive LSA outputs to other processes. For this reason, the process is already in international use, and beyond defense. The weakness of the standard for NATO use is its in-built specific instructions and references only applicable to the US DoD. The studies in progress on the subject involve several agencies and nations and will provide a neutral data model that encompasses the three major logistics business standards (MIL-STD-1388, AECMA S2000M and AECMA S1000).

While waiting for the completion and agreement by the nations of the neutral model, the following guidelines could be used in the interim:


8.2.5.2.3  Logistics Support Analysis Record
The Logistics Support Analysis Record (LSAR) is a subset of LSA data that resides in an approved format in an approved database system (Figure 8.2.5.2.3-1).

 

Figure 8.2.5.2.3-1  LSA/LSAR Relationship



8.2.5.2.4  ILS Summary
ILS data may be presented in any form or characteristic including, but not limited to, hard copy, audio/visual displays, magnetic tape, disc, and other electronic media. ILS data normally consists of plans, reports, and analyzes performed in support of development, deployment, and support of a specific Defense system. ILS data will be created in a processable data format consisting primarily of text.

An ILS program interfaces with and produces processable data related to:


8.2.5.2.5  LSA Summary
LSA information is generated as a result of the analysis tasks and consists of all data resulting from the analysis tasks and is intended to be the primary source of validated, integrated, design-related product support information pertaining to an acquisition program.

LSA information is developed and maintained as a result of design, support, and operational concept development and is updated to reflect changes. Changes can occur because of the availability of better information from testing, configuration changes, operational concept changes, and support concept changes during the acquisition process. Iterated versions of LSA information and data can provide an audit trail of supportability and supportability-related design analyzes and decisions.


8.2.5.2.6  LSAR Summary
LSA Record (LSAR) data is a subset of LSA information and is a structured means of aggregating LSA data. It is available for use by all services and ILS element functional areas. Because each element of LSAR data is defined and has a specified data structure, the LSAR has evolved as the primary means of storing logistic support data in digital media. The LSAR database (created as a processable database) shall serve as the center of the ILS technical support database, which can interface with other materiel acquisition programs to satisfy the support acquisition.

 


Figure 8.2.5.2.6-1  LSA Documentation


Simply put, the LSAR is that portion of the LSA information consisting of the detailed data pertaining to the identification of Logistics Support resource requirements of a system or equipment. The LSAR is not an end product but is intended to be used and updated throughout the acquisition life-cycle of the system or equipment.


8.2.5.2.7  MIL-STD-1388-2B Summary
MIL-STD-1388-2B contains relational table areas, which are further divided into 104 relational data tables. MIL-STD-1388-2B satisfies a wider range of logistic product requirements and promotes the use of relational database management systems for LSAR automated data processing (ADP) systems. Just like MIL-STD-1388-2A, MIL-STD-1388-2B provides information pertaining to technical characteristics of a system or equipment and provides data directly related to the supportability of that system or equipment. MIL-STD-1388-2B Appendix A provides guidance for fulfilling the requirements of a relational database system.

The interrelationships and data hierarchy among tables is established only through common data element keys and data values. MIL-STD-1388-2B provides the media options of the LSAR relational tables being delivered. This provides the capability to subsequently produce any of the LSA reports, other data files, and ad hoc reports via the query capability of a validated LSA relational ADP system.


8.2.5.2.8  AECMA SPEC 2000M Summary
AECMA SPEC 2000M is designed to cover all material management activities in support of military aircraft. It is a multi-national military aerospace standard developed specifically to support the military end customers manage their spares acquisition. It is not designed to transmit design data. It is currently being implemented in five European countries (France, Germany, Italy, Spain and UK).

Before completion and agreement by the nations of the neutral data format, AECMA's Spec 2000M should be followed for initial provisioning, order administration and other operational logistics support processes.


8.2.5.2.9  AECMA SPEC 1000D Summary
AECMA SPEC 1000M is used within the European Aerospace industry to provide a controlled environment for the management of data elements from which technical documents, in whatever form, can be produced. Its background is in multi-national air projects and this has led to the specification having generic principles embedded in air specific application of the principles.


8.2.5.3  LSA DATA Activities


8.2.5.3.1  LSA Data Creation Activities
The first level of activity during the acquisition phase of a program is the creation of the data. The acquisition project manager is the primary focal point during the creation phase. Of utmost concern to the project manager from a CALS perspective, should be the assurance that the data is developed once and then used many times. The ability to review and/or access LSA data by all areas involved in the design process ensures early identification and quantification of support systems requirements as well as the best design for supportability. The project manager must ensure that the internal contractor product development team members, as well as NATO/NATO nations reviewing agencies, have access to current and relevant LSA data.

The ability to access and review digital data is driven by the availability of appropriate infrastructure. The project manager should ensure all functional areas are addressed in the NCoO and that the appropriate infrastructure is in place or will be phased-in as the acquisition progresses prior to contract placement.

Of equal importance, the project manager should ensure that support activities are aware of LSA data access, review and approval methodologies, and the roles and responsibilities each activity will play.


8.2.5.3.2  Follow-on LSA Data Modification
In addition to concerns associated with the creation of LSA data, the project manager should consider future requirements to modify the data. It is of particular importance to ensure that all Front-End Analyzes studies, as well as the LSAR database, are made available on digital media to the depot or support agency in a usable format. By doing this, the depot and/or support agency will be provided not only with the LSAR database that supports the design, but also with analyzes and studies used to arrive at the design.


8.2.5.3.3  LSA Data Management
The second level of activity is associated with the management of LSA data during both the acquisition and operational phases. It should be noted that "LSA data management" will be afforded the same management controls as any other technical data acquisition, but with the emphasis being on digital delivery or electronic access.

The project manager must consider the specific NATO/NATO nations infrastructure program that will manage and store the digital data during both phases. The data delivered must be compatible with the existing digital NATO/NATO nations systems in place or being developed. If changes to the digital NATO/NATO nations infrastructure systems are required, they must be fully justified and coordinated with the personnel responsible for the management and configuration control of LSA data.

During the operational phase, the LSA data is typically assigned to a support organization such as a Depot or organic NATO/NATO nations Data Repository. Of primary importance here would be making data available to potential users and maintaining configuration control.


8.2.5.3.4  LSA Data Uses During the Acquisition Process
The final level of activity is associated with the use of LSA data. During the Acquisition Process, LSA data is typically used in three ways:

Paramount to ILS product development is the timely access to current and accurate LSA data. The following are just a few of the considerations the project manager should make when contracting for LSA data:

Technical Data: Since the technical data functional area has access not only to LSAR data, but also to technical drawings and associated supply support data, the project manager must ensure this data is closely managed for the development of data products such as Technical Manuals (TM). The LSAR task analysis (LSA-Task-401) is a basis for, and/or a direct input to the system's TM(s). The project manager should ensure that the development of the TM(s) and the detailed LSA task analysis are orchestrated in such a manner as to eliminate duplicate efforts.
Training and Training Support (T&TS) Data: This functional area takes information from the LSAR and uses it as source data to develop the training plans and various other training products. An important CALS-related consideration would be to ensure the training-related LSA source data for the training development are in a usable digital format.

Supply Support: Supply support and initial provisioning efforts take direct advantage of the data contained within the LSAR database.

Support Equipment: Support Equipment Recommendation Data (SERD) information is typically generated during the LSA process and captured within the LSAR database.


8.2.5.3.5  LSA Data Uses During the Operational Phase
A major concern to the project manager is the accuracy of the LSA data during the operational phase of a program. The project manager should ensure that both LSA Front End Analysis data and the LSAR database are made available and/or maintained by the support organization for both configuration control and evaluation of potential Engineering Change Proposals (ECP) during the operational phase.

One additional area of major importance concerns the end users. The end users perform a vital feedback function with LSA Task 501. Knowledge of actual usage of the data when fed back into the LSA process is invaluable in correcting design and support system deficiencies. The project manager must not overlook this vital source of data and should consider the end users when acquiring digital data and feedback methodologies. In conclusion, the project manager must include in the decision making process the infrastructure that exists at all user sites being considered.

It is counterproductive to generate and make available to the end users digital data that they do not have the capability of using. The project manager cannot assume the infrastructure exists and will be used. The end user's specific environment must be determined.


8.2.5.3.6  CALS-Related Questions
Questions that must be asked and answered include:


8.2.5.4  LSA Process in a CALS Environment
The four prime factors that govern system acquisition programs are cost, schedule, performance, and supportability. The LSA process provides direct input into the supportability and cost factors associated with a system/equipment and, therefore, provides significant input into system/equipment decisions. The CALS environment offers the opportunity through digital application of the LSA process for reductions in LCC. The ability to create data once (including LSA, engineering, and ILS data) and use it many times impacts the cost of the LSA process and the follow-on support costs. If the LSA data and associated analyzes are created in a digital format, then digital data required for the LSA can be linked and fed to the LSAR database in an automated fashion. The initially created LSA data is then available for use in all technical data products.

The project manager must consider the digital format, media, HW/SW issues, required framework, architecture, and NATO military customers' infrastructure when developing the NCoC concurrently with selecting LSA tasks. Harmonized MIL-STD-1388-2B/AECMA 2000M/AECMA 1000D, when completed, should be required for all new procurements. In addition, the instructions to offerors could indicate that the digital application and delivery of LSA data will be weighted strongly in the evaluation of the offerors' "Contractor's Approach to CALS (CAC)" response.


8.2.5.4.1  Potential Sources of LSA Data
The digital application of data must start with the onset RFP/RFQ process. Project managers should begin by providing Customer Furnished Information (CFI), including the LSA strategy and ILS planning information, in digital form to the contractor. Digitizing these products will help reinforce the NATO/NATO nations commitment to CALS, as well as reduce costs and improve communications.

Populating the LSAR database can be aided by a well-defined LSA Plan (LSAP). The project manager should require that this plan define not only who in the Contractor's organization is responsible for generating and receiving LSA source data, but also in what form the data should be developed, and how the Contractor plans to import this data into the LSAR database. Populating the LSAR database would be simplified if the LSA data existed in a digital format and data needed could be easily extracted for input. The amount of preparation and maintenance of the LSAR database is directly related to the complexity of the hardware and software end item design.


8.2.5.4.2  Managing/Maintaining LSA Data
The project manager will decide whether the weapon system's data will be maintained under a Contractor Integrated Technical Information Service (CITIS) arrangement or other digital means of delivery to the NATO military customer. (See Section 5 of this Handbook for more information on CITIS.)

In either event, the decision process in determining the LSA data required will be the same. Considerations must be made that encompass all life-cycle phases from design to disposal. The project manager must be aware of the infrastructure systems available that will be affected and possibly use the LSA digital data created. The project manager must keep abreast of NATO/NATO nations programs that may create and/or use LSA data.


8.2.5.4.3  Using LSA Data in the CALS Environment
This subparagraph will focus on the current capabilities of CALS to employ and use the data that exists in the LSA database. Distinctions between MIL-STD-1388-2A and MIL-STD- 1388-2B will be discussed only where relevant to digital data interaction. Emphasis will be placed on creating the data once and using it many times. The unique effects of a shared digital environment on the current use of the LSAR database will be investigated and discussed.


8.2.5.4.4  CALS Effects on LSAR Report Requirements
In the past, the completeness and accuracy of the data has typically been verified by the contractor demonstrating the ability to produce various output reports from the LSAR database. The project manager is encouraged to shift emphasis from the delivery of the LSA reports to the delivery of, and/or preferably the access to, the LSAR database itself. In doing this, the verification of the database and its accuracy and completeness can be more easily and accurately assessed. However, prior to using this approach, the project manager must ensure that infrastructure is in place to accept, process, manage, and validate the LSA data.


8.2.5.4.5  Interaction of LSA Data with Concurrent Engineering/Integrated Design
The LSA process is iterative in nature. The LSAR database provides a structured, uniform, yet flexible/tailorable approach to the documentation of the data that results from accomplishing various LSA tasks. As such, the LSA process is an effective tool to aid in the application of concurrent engineering initiatives.

To be effective, the systems engineering LSA process must be initiated early in the acquisition life-cycle, and must be updated through LSA process iteration to reflect changes in the hardware design and support concept, and must be tailored to be commensurate with individual program requirements, constraints, and characteristics. This is consistent with concurrent engineering/integrated design as all life-cycle support considerations are being considered at each phase of the development process.


8.2.5.4.6  Specific CALS Considerations Affecting Data Acquisition
During the analysis of the supportability portion of the LSA process, LSA data is used as a primary source for the development of data products associated with ILS elements such as provisioning lists, personnel and training requirements, and technical data products. This assures compatibility among ILS element products and permits common use of data that apply to more than one logistic element.

The CALS infrastructure available to the project manager when he is ready to issue an RFQ/RFP must be considered. Delivery of the LSA/LSAR data/database may be via digital media (magnetic or optical media) or can be made available under a CITIS requirement. The media selected will be driven by factors including infrastructure and data access needs.


8.2.5.4.7  Migration of LSA Data into ILS Element Products
For the proper migration of LSA data to be complete and in full support of all ILS element products, the concurrent engineering concept must also be implemented. The project manager must task the contractor to support the movement of LSA data into the design process and vice versa. The LSA tasks and LSA data captured is driven by the requirements as set forth in the acquisition contracts.

The LSA data and resulting LSAR database is then used as input data for decisions to develop various ILS element products including training programs, support equipment, facilities, supply support, manpower and personnel lists, environmental impact, parts control, and so on. It is essential that coordination and interfacing of engineering disciplines and ILS functional elements be effected to maximize the usage of data developed by each program element, thereby realizing the economy of consistent and accurate information, and avoiding the generation of incompatible ILS products. Again, we want to create the data once and use it multiple times.


8.2.5.5  Sample CALS and LSA Tasks Statement of Work
When requiring LSA tasks in an RFQ/RFP Statement of Work (SOW), specific requirements for CALS should be included. The following subparagraphs offer ideas for specific language to be included as part of a solicitation package.


8.2.5.5.1  MIL-STD-1388-1A 100 Series Tasks
The primary purpose of the 100 Series LSA tasks of MIL-STD-1388-1A is the management and control of the LSA program. The project manager should include CALS as a factor when performing Task 101, Development of an Early Logistics Support Analysis Strategy, when deciding which of the LSA tasks and subtasks will provide the NATO/NATO nations with the best return on investment. The following statement may be included in the SOW:

The contractor shall include as part of Task 102, Logistics Support Analysis Plan, a description of how CALS (the digital management and flow of data) is being integrated into the LSA tasks and shall identify how CALS will be used in interfacing the data developed from the LSA process with other ILS and system-oriented tasks and data.


8.2.5.5.2  MIL-STD-1388-1A 200 Series Tasks
The 200 Series LSA tasks of MIL-STD-1388-1A are to establish supportability objectives and supportability-related design goals, thresholds and constraints through comparison with existing systems and analyzes of supportability, cost, and readiness drivers. CALS should be included as part of the objectives, considerations, and comparisons.

The following statements may be included in the SOW when requiring a contractor to perform one of the 200 Series LSA tasks of MIL-STD-1388-1A in which CALS should be considered:

The contractor shall perform Task 201, Use Study, to identify and document the pertinent supportability factors related to the intended use of the (name of new system or equipment). This study shall include the contractor's intended use of CALS as one of the pertinent supportability factors.

The contractor shall perform Task 202, Mission Hardware, Software, and Support Standardization, to provide supportability and supportability-related design constraints for the (name of new system or equipment) based on existing and planned logistic support resources that have benefits due to cost, manpower, personnel, readiness, or support policy considerations and benefits. Identification of existing and planned logistics support resources shall include CALS as one of the potential benefit factors to be considered.

The contractor shall perform Task 203, Comparative Analysis, to select or develop a Baseline Comparison System (BCS) representing characteristics of the (name of new system or equipment). This analysis shall include any past CALS implementation of the design and support of the existing system. The analysis may be a factor in which judgments can be made in determining the feasibility of the supportability parameters. This analysis shall also include the identification of areas for improvement in which CALS may be targeted.

The contractor shall perform Task 204, Technological Opportunities, to identify and evaluate design opportunities for improvement of supportability characteristics and requirements of the (name of new system or equipment). These opportunities shall consider implementation of CALS into the design objectives and techniques. The identity of CALS implementation in design improvements to logistic elements during development should also be considered.


8.2.5.5.3  MIL-STD-1388-1A 300 Series Tasks
The 300 Series LSA tasks of MIL-STD-1388-1A are to optimize the support system for the new item and to develop a system that achieves the best balance among cost, schedule, performance, and supportability. CALS should be considered as part of the functional requirements and/or a support system alternative. The following statements may be included in the SOW when requiring a contractor to perform one of the 300 Series LSA tasks of MIL-STD-1388-1A.

The contractor shall perform Task 301, Functional Requirements Identification, to identify the operations, maintenance, and support functions that must be performed in the intended environment for each (name of new system or equipment) alternative under consideration. The identification shall include the contractor's intended use of CALS as one of these functional requirements.

The contractor shall perform Task 302, Support System Alternatives, to establish viable support system alternatives for the (name of new system or equipment). The contractor shall include support concepts that foster CALS utilization when developing alternatives to the system level support concept.

The contractor shall perform Task 303, Evaluation of Alternatives and Tradeoff Analysis, to determine the preferred support system alternative(s) for each (name of new system or equipment) alternative. For each evaluation and tradeoff to be conducted under this task, the contractor shall include the utilization of the intent of CALS as one of the criteria of evaluation.


8.2.5.5.4  MIL-STD-1388-1A 400 Series Tasks
The 400 Series tasks of MIL-STD-1388-1A are to identify the logistic support resource requirements of the new system in its operational environment(s) and to develop plans for post-production support. CALS considerations should have been identified as part of Task 303.

Task 401, Task Analysis, provides the detailed identification of requirements for all elements of ILS to operate and support the new system/equipment. The results of task 401 are documented in the Logistic Support Analysis (LSA) Record (LSAR) as described by MIL-STD-1388-2. Although automation of the LSAR data is not mandatory, it is strongly encouraged and should be a consideration in implementing a CALS environment since this data has a structured format dictated by a standard. Commercial Off the Shelf (COTS) approved LSAR data software packages are readily available. LSAR data is also suited for CITIS. The following statement may be included in the SOW when requiring a contractor to perform Task 403 of MIL-STD-1388-1A.

The contractor shall perform Task 403, Post Production Support Analysis, to assess the expected useful life of the ( name of new system or equipment ). The assessment shall include a plan with discussions that support the difficulties due to the use of CALS and digital data and the modifications to the data during the remaining life of the system/equipment.


8.2.5.5.5  MIL-STD-1388-1A 500 Series Tasks
The 500 Series tasks of MIL-STD-1388-1A are to assure that specified requirements are achieved and deficiencies corrected. The following statement may be included in the SOW when requiring a contractor to perform the 500 Series Task of MIL-STD-1388- 1A.

The contractor shall perform Task 501, Supportability Test, Evaluation, and Verification, to assess the achievement of specified supportability requirements, identify the reasons for deviations from projections, and identify methods of correcting deficiencies and enhancing system readiness. The assessment shall include CALS supportability cost and readiness drivers. These CALS related drivers should have been identified in Tasks 203 and 303.


8.2.5.6  Future Considerations for the LSA Process in a CALS Environment
This paragraph will present some thoughts on where CALS is headed and how that might affect data use in the future. The influence of infrastructure developments in NATO/NATO nations, and even in the international community will all affect the potential environment in which the LSA data acquired now may have to be used in the future.


8.2.5.6.1  Integrated Weapon Systems Database


8.2.5.6.1.1  Future Trends
Future trends must lead to and support the fundamental objective of CALS, which is to lower costs to the Government, improve quality, and shorten lead times. The electronic sharing of data allows it to be created once and then used by multiple users, multiple times. The integration of functional processes will start with the integration of data. The acquisition strategy must specifically address the automation and integration of technical information systems and functional processes.


8.2.5.6.1.2  Effects on LSA Data and LSAR Databases
The process for determining LSA data and LSAR database requirements is an extension of the process currently used for determining data requirements, selecting appropriate data items, and developing the Contract Data Requirements List (CDRL) that identifies the requirements.

The LSA/LSAR databases are the building blocks that are necessary to support an IWSDB. The process for determining LSA data and LSAR database requirements may evolve as the requirement for access to the data intensifies. There is significant potential for reduction of data requirements in that, with query capability, the Government can generate data, reports, and products on demand rather than having the contractor prepare and deliver them. As digital data utilization evolves, the media on which the data is delivered will also evolve.


8.2.5.6.2  Contractor Integrated Technical Information Service


8.2.5.6.2.1  Future Trends
Access to digital data will become the standard by which all acquisitions will be measured. Because Contractor Integrated Technical Information Service (CITIS) provides access to contractor-managed, functionally-integrated information, it must play a significant role in improved Government operations and the streamlining of processes. An effective CITIS program will require foresight and added coordination efforts on the part of contractors, Government sponsors, and potential CITIS users. Functional integration approaches, as well as CITIS performance, must be considered. Measures should be developed to motivate contractors with top-level commitments to produce overall, functional integration and an effective CITIS implementation.


8.2.5.6.2.1  Effects on LSA
An effective LSA program will be planned, integrated, developed, and conducted in conjunction with the requirements of the overall acquisition program objectives. The LSA process will be established consistent with the type and phase of the acquisition program. To maximize the use of the plans, procedures, front-end analyzes and reports developed from selected LSA tasks, it is necessary to establish a viable communication link with the contractor. Providing an early-on CITIS capability (including the front-end analyzes and documentation generated from the 200 and 300 series tasks of MIL-STD-1388- 1A) will enhance the LSA process and the overall design effort.


8.2.5.6.2.2  Effects on LSA Databases
There are several considerations facing contractors when they are tasked with providing CITIS to support LSA databases. Areas of consideration include the following:


8.2.5.6.3  NATO CALS Efforts


8.2.5.6.3.1  Acquisition Workshop


8.2.5.6.3.1.1  Objectives
The Acquisition Workshop Stage 1 (AWS1), held in April 1994, provided the outline of an improved acquisition process and the recommendation for further work. A Study Management Group (SMG) was chartered by the NCMB to conduct the second stage of the Acquisition Workshop (AWS2). AWS2 was accomplished by bringing together 52 experts from industry, governments, and NATO Agencies (senior officers and civilians). The workshop was sponsored by the NCMB and the NATO Industry CALS Group (NICG) and was held at the French CALS Office in Paris from 06 - 24 November 1995.

The objective of AWS2 was to refine the definition of an improved acquisition process in order to identify data requirements to conduct business in a multinational environment. This included the consideration of legal and contractual issues in a CALS environment and the development of a management oriented advocacy plan for promotion of the workshop results.


8.2.5.6.3.1.2  Workshop Results
AWS1 stated that multidisciplinary groups (MDGs) will perform acquisition in the future through continuous processes, in a shared data environment (SDE) and controlled through project, quality, configuration, and data management. AWS2 refined and further decomposed the "acquisition To-Be model" from AWS1 to arrive at an improved NATO reference acquisition activity model. This being the basis, the data necessary, the way it should be used and shared, and the information flows were considered; the corresponding generic data model was developed as far as possible within the available time.

Within the acquisition processes, project life-cycle plans will enable the elimination of unnecessary milestones by use of checkpoints and continuous control, to identify and mitigate risks and to reduce delays and other impacts of external controls such as necessary financial milestones. Ownership of data and responsibilities for activities must be defined in contracts. Shared resourcing of the continuous controlling processes (Program-, Quality-, Configuration- and Data Management) allows control aspects to be resolved within a program without delays arising from separate customer audits, reviews and other external approvals. Benefits are the early identification of risks and the reduction of lead-time.

The improved acquisition processes will exploit the following disciplines:

System Engineering and Multidisciplinary Groups
System engineering is an interdisciplinary collaborative approach to derive, evolve, and verify a system solution to satisfy customer expectations. This concept encompasses a life-cycle oriented approach, multidisciplinary teaming, concurrent engineering, and the recursive application of the systems engineering processes on each level of development. MDGs are established by the Program Manager and formed with resources shared between industry and government, their composition is dynamic and adapted to the current activities. The main benefits are better information (in quantity and quality) with the involvement of the right skills at the right time, thus reducing the risk, and the quicker reaction in the decision-making processes throughout the life-cycle.

Shared Data Environment (SDE)
A SDE is the information infrastructure that allows data to be shared electronically between all industrial and governmental participants in a project. The building of the SDE starts at the beginning of the program and evolves through the life-cycle of the defense system. Consequently, the architecture must be very flexible and dynamic. An empowered MDG can operate effectively in a SDE. Within the framework contractually agreed between governmental and industrial participants the SDE provides different levels of data access as needed with respect to tasks and responsibilities. It also permits many concurrent levels of executive oversight. The integration of program and product data provides easier consistency of quality and configuration management activities and enables through life traceability and experience feedback. Reduced error rates and data acquisition costs in conjunction with faster data exchange are the advantage of such an environment.


8.2.5.6.3.2  Operational Logistics Workshop


8.2.5.6.3.2.1  Objectives
Stage 1 of the Operational Logistics Workshops (OLWS 1) was led by Germany and was accomplished by bringing together experts teams made from 67 logisticians (senior officers and civilians from government and industry). It was held at the Universitat der Bundeswehr München from 5-20 December 1995.

The OLWS Terms of Reference defined Operational Logistics as "the process of managing the logistics support for defense equipment during its in-service life, using the data and the infrastructure acquired during the acquisition, acquisition logistics, and operational phases of its life-cycle."

The objective of Stage 1 was "to develop a TO-BE Activity Model which describes more efficient processes and provides a basis for a common data model."


8.2.5.6.3.2.2  Workshop Results
The result of the workshop was the definition of a TO-BE Activity Model and a glossary, which describe a more efficient process to be carried out during the operational phase of a defense system's life-cycle. The improvements were aimed at reducing costs, improve quality, improve service to the customer, and, finally, improve interoperability among NATO's Armed Forces. The developed TO-BE Model will serve as a reference point, or baseline, for future work by NATO nations and industry. The final report of the OLWS 1 was published in January 1996.

Having completed OLWS 1, the following objectives remain from the Operational Logistics Workshop Terms of Reference:


8.2.5.7  Summary and Conclusions
As stated in the introduction to this handbook, CALS is a Defense strategy that will enable creation that is more effective, exchange, and utilization of digital data. The underlying purpose of this strategy is to move from a paper-intensive environment to a digital environment in an effort to reduce weapon-system acquisition time, support costs, and improve both data and product quality.

Given the current state of the Defense budget and the likelihood that Defense money will continue to shrink in the foreseeable future, it is even more imperative that project managers maximize the use of CALS as a springboard to reduced acquisition and downstream Operational costs. The efficient utilization of the LSA process during a system's early life-cycle (design and early development) is the cornerstone to reducing the overall system Operational costs. But in addition to simply applying the LSA process during a design phase, the project managers must implement an effective and logical approach to the overall acquisition and management of all data including data associated with LSA, ILS, and engineering and program management through the entire life-cycle of a system.

It is no longer acceptable to procure and reproduce data when, in fact, the only difference is the format. Significant cost savings can be realized by both buying and utilizing previously procured data in a logical and controlled manner. The implementation of a CALS strategy will allow the project manager to provide the foundation to electronically share the data that is developed from his/her program with multiple users, multiple times.

Future CALS-related modernization efforts, including those presently underway, will help improve and consolidate both data acquisition and data management. However, until these efforts are completed, it is the individual project manager's responsibility to apply CALS to the maximum benefit of both his/her program and the NATO/NATO nations in general.


8.2.6  Applying CALS to the Creation, Management, and Use of Technical Data Packages


8.2.6.1  Introduction
Technical data packages (TDP) contain the information necessary to describe a defense system and its components in terms of design, engineering, manufacturing, and logistics support.

Applying CALS to the creation, management, and use of TDPs will aid in accomplishing the transition from paper-intensive defense system acquisition and support processes to an automated and integrated digital process. It should be noted that the application of CALS-related technologies to Defense processes should be seen as a means of improving and streamlining these processes by providing better methods of creating, managing, and using data, not as a method of replacing business practices.


8.2.6.1.1  Scope
It is recognized that each defense system program is unique with individual constraints and access to a distinct set of infrastructure systems. This section is intended to provide the Defense project manager with an overview of NATO business practices for the creation, management, and use of TDPs in a CALS environment. Specific implementation of this process follows the completion of the NATO/Government CALS Concept of Operation (NCoO) and may be tailored.


8.2.6.1.2  Purpose
The planning process for the creation, management, and use of TDPs in a CALS environment needs to take advantage of the capabilities provided by the automation and integration of information systems. Various data content, media, and format options are available for the delivery of digital TDPs needed to define and support a defense system. The intent of this section is to:

This section contains ordering information for the deliverable media and digital data format for TDPs. The Contract Data Requirements List (CDRL) guidance contained in this section applies to all TDP elements.


8.2.6.2  General Considerations
The development of an acquisition strategy for TDPs needs to be carefully examined to maximize the value for a specific defense system program. Program development elements such as technology, costs, end-item quantities, and schedules have a profound effect on the delivery requirements for supporting TDPs. Therefore, project managers must consider the life-cycle of the procurement and the existing and planned Defense infrastructure to support the TDPs for their program.

Technical data packages (TDP) contain the information necessary to describe a defense system and its components in terms of design, engineering, manufacturing, and logistics support.

The following paragraphs discuss topics of consideration that must be addressed:


8.2.6.2.1  TDP Data
TDP data consists of: TDP elements, TDP management data, and TDP intelligent product data. The same TDP data may be re-grouped in terms of data construction as: Engineering drawings (without or with integral parts lists), Illustrated text documentation, or Intelligent product data.


8.2.6.2.1.1  Engineering Drawings and Integral Parts Lists (PL)
These data mainly consist of illustrations that describe a product or process interspersed with small amounts of text that help explain the features of the product or process. However, in terms of digital data delivery, all of these data may be delivered by either of the following methods:

Types of engineering drawings (without or with integral parts lists) are as follows:


8.2.6.2.1.2  Illustrated Text Documentation
Illustrated text documentation is data that mainly consists of text. Sometimes graphics are present, but they usually consist of simple illustrations, figures, or tables. However, in terms of digital data delivery, all of these documents may be delivered by any of the following methods:

Types of illustrated text documentation are as follows:

TDP Elements:

TDP Management Data:


8.2.6.2.1.3  Product Description
Data Product description data or intelligent data includes 3-D information, such as product models that contain the digital information required for full product definition. Intelligent product data are the totality of data required to completely define a product throughout its entire life-cycle. Engineering drawings make up a very small portion of intelligent product data and provide only the human interpretable information for a system. Standards are currently being developed to define more completely this form of data for the following.

Types of product description data are as follows:


8.2.6.2.2  TDPs in the CALS Environment
The CALS strategy provides the project manager with a framework of standards, specifications, and systems to create, manage, and use information in a digital environment. The project manager should recognize the importance of requiring digital data deliverables. The benefits associated with using digital data far exceed what is being discussed in this section.

For TDPs, two benefits of digital data include:

Please note that this section does not consider delivery of a TDP in other than digital format justifiable. References to non-digital data deliverables are only made in conjunction with the delivery of a digital product and for the sole purpose of verifying the quality and accuracy of the digital transfer of data between the various digital systems.

A brief discussion of both non-digital and digital data deliverables is provided. The non-digital deliverables will not be addressed again in this section since their importance in a CALS environment is minimal. The digital deliverables will be mentioned here providing a brief overview of options available to the project manager.


8.2.6.2.2.1  Paper, Mylar Hardcopy
Paper or Mylar Hardcopy has long been the traditional medium for delivery of Defense product data and related information. TDPs delivered on this medium may have originated from many sources including other existing hardcopy documentation, microfiche, microfilm, or any of the digital data formats described in the following sections. Converting the data content of paper to a digital data format requires infrastructure systems that include scanning hardware and software to support the conversion of both text and graphics from hardcopy to electronic. Today's project manager should accept hardcopy TDP deliverables only for the purpose of verifying the digital deliverables.


8.2.6.2.3  Digital Data Deliverables
Digital data deliverables available in the CALS environment are extensive. Digital data provides the project manager with a variety of digital data content, formats, and media option (Table 8.2.6.2.3-1).


Table 8.2.6.2.3-1  Digital Data Deliverables


8.2.6.2.4  Life-cycle Considerations
As a defense system develops through its life-cycle, TDP deliverable requirements may vary. In addition, the availability as well as the volume and format of the data generated by the contractor changes. The project manager must be prepared to adjust the contract data requirements to meet the needs of all organizations involved in the procurement and support of the defense system. The project manager must anticipate the upcoming contract and be prepared to alter the data requirements in the procurement documents.

The project manager must also consider the information volume and typical use of the particular TDP element selected. To take advantage of the CALS strategy, data must be created and/or obtained in a digital form during the earliest possible program phase. By starting early, product information may be used repeatedly throughout the life-cycle. Failure to develop data in a digital form early in a program can lead to requirements for costly data conversion and will deny potential benefits from digital data exchange.


8.2.6.2.5  Infrastructure Development
Effective acquisition of digital data can only be done with full consideration of the ability of Defense activities to receive, store, distribute, and use the digital data that complies with the CALS standards. The project manager must establish the uses for which the data is required and the infrastructure modernization programs available to support this data.

The evolution of infrastructure is a key consideration in implementing the CALS strategy on any given acquisition. Deficiencies in program related infrastructure may require cost investments to effectively implement the CALS strategy. The availability of digital data processing and telecommunications technology and approved standards for creation management, storage management, transmission, data protection, and integrity of data at the time of delivery or access are important criteria for acquisition decisions.

The current and projected capabilities of both the contractor and NATO Armed Forces components must be assessed with respect to program needs and schedules. The NATO/NATO nations Concept of Operation (NCoO), its `Contractor's approach to CALS Implementation' counterpart, and CALSIP (when required), are excellent vehicles for making these determinations. Project managers must plan to acquire and/or access digital data products. The data user infrastructure, the computing environment available to a particular user, must be considered when acquiring digital data. This environment establishes the data processing capabilities of that user.

The following areas identify a user's infrastructure:


8.2.6.2.6  Data Uses
The project manager will need to identify the use of the data by all organizations involved in the acquisition program. Identification and establishment of data requirements are generally determined by conducting a data call. The project manager must consider how data will be processed in order to make good decisions on digital data requirements. The five categories of data processing typical of most defense system programs are:


8.2.6.3  Specific Considerations


8.2.6.3.1  TDP Delivery
The purpose of this section is to determine the status and/or existence of a TDP and ultimately to lead the project manager to a decision as to the specific type of digital data and media format required to support the program. In addition to the immediate TDP requirements (acquire and/or develop an end item or system), the project manager should consider the potential long term engineering and support functions and requirements for technical data when selecting TDP formats.

Utilization of existing legacy data is quite common when new systems use features of older systems. The project manager should be aware that, even on completely new defense system programs, some portion of the TDP may pre-exist. An important point to remember here is that acquisition of the proper level and type of digital data is most cost effective when defined early in the program's life-cycle.


8.2.6.3.2  Potential TDP Delivery Options
While actual delivery may include a mixture of options, TDP information falls into three distinctly different delivery forms:


8.2.6.3.3  Raster
Raster data is a binary representation of an image. Raster may be thought of as the electronic version of a paper document. It contains no "intelligence" and must be reviewed through human interpretation. There are two types of raster data, tiled and untiled. Tiled raster is the preferred format because of smaller file size. A tiled raster image resembles a two-dimensional grid with each "tile" or set of pixels representing a portion of the image. Text and graphics in raster data formats are stored digitally, which allows more rapid and consistent access to the stored images than paper. In addition, raster data can be sent via electronic means to remote sites.

Raster files can be edited in several ways:

Raster documents may be converted to processable text via Optical Character Recognition (OCR) technology. With the advent of raster scanning technologies, the ability to convert existing TDPs to digital data files has become available. However, the quality assurance process (by human interpretation) required to verify the data contents may increase costs substantially. In addition, raster image files require a large amount of memory storage due to their file structure and contain no additional information other than each tile's position on a grid. Because of these drawbacks, the project manager should consider processable data forms before considering raster unless the TDP will not be used for competitive reprocurement.


8.2.6.3.4  Processable Data Files
Processable data files provide the majority of options available for digital TDP delivery. Processable data files can be broken down into two additional categories, drawing and product description data files and text data files. These categories are considered processable, because the data can be manipulated by the user, interpreted by the computer, and reprocessed into an updated or new form as specified by the user.


8.2.6.3.4.1  Drawing and Product Description Data Files
Drawing data files, the output of CAD systems, comprise vector data, and as the name "vector" implies, the image produced is composed of vectors, a sequence of line segments. Vector data provides geometrical and physical representation of objects in both two and three dimensions. Vector data files are stored digitally allowing rapid retrieval and integration into other compatible systems. Because the data consists of a sequence of line segments and patterns/symbols that represent entities with specific orientation and location, vector data can be translated to code interpreted by some automated machine tools.

Drawings delivered in this format must conform to IGES Class II (MIL-D-28000) unless the native vector CAD files are available in an agreed-to, compatible format. (The user of native vector data must have the same type of CAD system or must have a direct translator from the source system to the destination system.) The native CAD format is the preferred format during early development phases in the defense system program's life-cycle, because the translation to IGES will invariably exclude some of the data inherent in the native CAD files. If vector data is not compatible between the user and the source, then the IGES standard should be delivered, as it does allow dissimilar CAD systems to manipulate vector data. Final delivery, however, must be in IGES. CAD2 supports vector data in IGES formats.

NOTE: There are no commercial or NATO/NATO nations standards for preparing 3-D CAD models. As a result, repository systems may not have the capability to store usable 3-D CAD products.

Project managers should consider acquiring any portion of the drawing package developed from 3-D modeling. Product description data is the most comprehensive form of digital data. Product description data contains all information needed to describe a product completely, and a large portion of this information can be directly interpreted by a computer. Product description data allows the simulation of systems modifications prior to implementation and evaluation of form, fit and function performance of components. In addition, product description data with its inherent intelligence can be used to drive manufacturing processes.


8.2.6.3.4.2  Illustrated Text Data Files
Illustrated text data files provide a dynamic form of source data with two possibilities:

Text data files include word processing and desktop publishing applications. Such data files can provide the source data for multiple data applications that allow creation of standard and custom documents as well as manipulation of the data for annotate/excerpt or update/maintain purposes. Text data files can also import generic text [ASCII, SGML, etc.] and graphics [raster, CGM, IGES, etc.] from other sources that may be otherwise incompatible. In addition, there are Page Description Languages (PDL), sometimes called text presentation metafiles, which are used to drive output devices such as printers. There may be instances when obtaining text data files involves obtaining more than one format of graphical data. This may be due to multiple graphic sources. This is an acceptable and highly likely situation. The project manager must be aware of this possibility and be prepared to develop/modify the defense system contract requirements accordingly.


8.2.6.3.4.3  Text Formats
There are three possible text formats available for consideration when invoking the option specifying text data files. They are American Standards Code for Information Interchange (ASCII) and tagged ASCII, Standard Generalized Markup Language (SGML), or raster. They are described below.


8.2.6.3.4.3.1  Graphics and Illustration Formats
There are many possible graphic image formats available for consideration when invoking the option of specifying text data files. Two suggested formats described below are Computer Graphics Metafile (CGM) and raster. CGM data is a two dimensional vector presentation used primarily for charts, figures, and simple drawings. See 8.2.7.2.1.1 for a discussion of raster data.


8.2.6.3.4.3.2  Standard Page Description Language
A PDL file is executed by an interpreter that controls a raster printer or other output device. A PDL can be used to ensure that the composed document produced by an electronic publishing system (which may impose additional processing limitations, such as font variations, kerning, or hyphenation) would produce nearly identical hardcopy output on the widest possible spectrum of printer devices. Standard Page Description Language (SPDL) document image files can be acquired as interim deliverables or as final deliverables in addition to (but not in place of) other digital data deliverables.


8.2.6.3.4.3.3  Neutral Data Files
Several industry-developed software products for platform-independent neutral data files have recently become available that allow users to save information created in a variety of software applications and formats, including text, graphics, and spreadsheets, into a platform-independent file format. These files can then be viewed and printed by anyone possessing the appropriate reader software. Many applications also allow reader-software users to annotate data and copy information to paste into other word processing programs. Because of their flexibility in handling a wide range of software packages, the NATO/NATO nations may want to consider these platform-independent file applications when determining standard file formats, even though they are not part of the CALS standards.


8.2.6.4  Decision Guidelines


8.2.6.4.1  Maintenance and Control of the TDP
The project manager must consider whether the NATO/NATO nations plan to maintain and control the TDP internally. This deals with the underlying issues of who will maintain and control the TDP once it has been delivered to the NATO/NATO nations and how will they do it. It is assumed that the TDP will be developed in a digital environment, i.e., in a CAD/CAE environment. The key point to remember is that if the NATO/NATO nations plan to maintain, update, and/or produce various configurations of the TDP in the future, the TDP should be delivered in an "intelligent" format, i.e., in processable data files including CAD/CAE files versus document image files such as raster format. Conversely, if the NATO/NATO nations does not plan to "update or maintain" the TDP, it is recommended that the project manager consider a raster-format-only delivery. Delivery of a TDP in raster format does not eliminate on-line or electronic type review via the comment/annotate option during the TDP development cycle.


8.2.6.4.2  Competitive Reprocurement
The project manager must consider whether competitive reprocurement of the system, spares, and follow-on support is planned. This prompts the project manager to consider future requirements for the TDP. Competitive procurements, as addressed in the Acquisition Plan, can be significantly enhanced with the availability of "intelligent" digital information such as Government Furnished Information (GFI) to the prospective bidders. If future acquisitions are not anticipated, cost associated with delivery of the TDP in a processable data file format may be unwarranted. If competitive reprocurement is planned, delivery of an "intelligent" format such as processable data files is recommended. If competitive reprocurement is not planned, delivery of an "intelligent" data format may not be cost effective, and a raster format is recommended.


8.2.6.4.3  TDP Modification/Revision Determination
Next, the project manager should consider whether the NATO/NATO nations anticipate revising and/or modifying a significant portion of the TDP in the future. This applies only to the non-digital portion of the TDP. This prompts the project manager to determine whether the non-digital portion of the TDP would serve the defense system program better in a digital format. If future manipulation of the data is not anticipated, raster delivery is the most suitable option. If the NATO/NATO nations do plan to revise and/or modify the TDP, additional digital data considerations must be addressed.


8.2.6.4.4  Digital System/Environment
The project manager should now determine whether the contractor's native digital environment/system is known at this time. This is focused at determining the most economical and efficient format for the various TDP components. (It is assumed that the NATO/NATO nations has previously completed an NCoO and identified the applicable NATO/NATO nations in place infrastructure.) Obviously, for competitive procurements prior to source selection, the contractor's digital environment will not be known. This is, of course, unless all prospective contractors have identical digital environment/systems. If the contractor's digital environment is not known, consider the delivery of 2-D and 3-D CAD/CAE data files versus the delivery of a more comprehensive set of product description data files.


8.2.6.4.5  System/Environment Compatibility
Next the project manager must determine whether the contractor's and the NATO/NATO nation's digital environments/systems are compatible. This focuses on the potential of transferring processable data files directly between two similar systems versus the transfer of data through a neutral data format. Since the transfer of data between similar systems is typically less time consuming and is more accurate, this type of transfer is recommended. However, where the two systems are not similar, the transfer of data via a neutral format is recommended and/or quite necessary. If the digital environments are compatible, it is recommended that the transfer of data between the contractor and the NATO/NATO nations be in the contractor's native format. If the digital environments are not compatible, it is recommended that a neutral format, be used to transfer data between the contractor and the NATO/NATO nations.


8.2.6.5  Sample CDRL's


8.2.6.5.1  Raster Delivery Option
The raster delivery option, which is described in section 3.3.3, allows the project manager to obtain TDP data in a digital format. The data uses of the raster deliverable are somewhat limited but do provide for view, archive, and comment/annotate capabilities. Suggested delivery media options include: (1) Optical disk or CD-ROM, (2) magnetic disk, or (3) 9-track magnetic tape, all in accordance with MIL-STD-1840. Paper documentation may be requested in addition to the raster deliverables but only for verification of the raster data content.

The information contained in the contract vehicle should be tailored to meet the requirements of the specific defense system program

Drawing master raster graphic tape shall be IAW MIL-R-28002, MIL-STD-1840, and the following requirements. Data shall be on a 9-track magnetic tape. Raster graphics shall be type 1 untiled raster data, 512 X 512 in size. Each delivered 9-track tape shall include an ANSI label. Raster image density shall be 200 PELS/Inch. The minimum number of PELS per line and minimum number of scan lines shall be IAW MIL-R-28002. Raster image orientation shall be PEL path of 90-line progression of 270. Acceptance of this data item shall be based upon: self-merit/content, prior acceptance and validation of drawing trial raster data, and visual comparative agreement with drawing originals or reproductions, if ordered.

The information contained in the contract vehicles should be tailored to meet the requirements of the specific defense system program. The CDRL(s) must include language that specifies exactly how data will be delivered (including media, format, and content) under the contract. CALS standards and specifications should be invoked whenever possible.


8.2.6.5.2  Product Data File Delivery Option
Product data files consist of a variety of data delivery options including product data files, text data files, and Product Data Exchange using standard for the Exchange of Product [STEP] (PDES) data. These data deliverables provide all the data uses including view, archive, comment/annotate, update/maintain, and extract/process/transform. Suggested delivery media options include: (1) Optical disk, (2) magnetic disk, or (3) 9- track magnetic tape, all in accordance with MIL-STD-1840. Paper documentation may be requested in addition to the digital data deliverables but only for verification of the digital data. The CDRL must include language that specifies exactly how data will be delivered (including media, format, and content) under the contract. CALS standards should be invoked whenever possible.

Drawing master product data shall be IAW VHDL ANSI/IEEE 1076, EDIF EIA 548, and IPC-D-350 and the following requirements. Data shall be on MIL-STD-1840 magnetic tape format optical disk, CD-ROM, or magnetic disk with a mutually agreed upon format. Data shall be organized as one drawing per file with multiple sheets permitted. Entities unsupported or unspecified by the appropriate standards or specifications (VDHL, IPC, etc.) shall not affect the data transfer integrity of the product information delivered under the contract. Format version "(X)" shall be used. Acceptance of this data item shall be based upon: self-merit/content and visual comparative agreement with drawing originals or reproductions, if ordered. Validation here means determination of acceptable transfer and translation of data from the contractor's CAD/CAE system to the _____(add applicable interfacing system).


8.2.6.5.3  Native CAD/CAE Data File Delivery Option
CAD/CAE data files in native format consist of a variety of data delivery options including native CAD data files, text data files, and PDES. These data deliverables provide all the data uses including view, archive, comment/annotate, update/maintain, and extract/process/transform. Suggested delivery media options include: (1) Optical disk, (2) magnetic disk, or (3) 9- track magnetic tape, all in accordance with MIL-STD-1840.

Drawing master native CAD/CAE data shall be as follows. The data file format shall be compatible with and delivered on a 9-track QIC tape, CD-ROM, or magnetic disk, compatible with _____ (insert vendor product name). CAD/CAE system media shall be clearly labeled to describe the media format method, content, and media density. Data shall be organized as one drawing per file with multiple sheets permitted.

Data format shall be compatible with _____(insert vendor application package name, version number) format, using the native binary format supported by the _____ (insert vendor product name) CAD system.

All information necessary to open and manipulate the data files, including: libraries, logical name definitions, and other supporting files shall be delivered with drawing files. Non-vendor-supported "Utilities" (i.e., software product) shall not affect the data transfer integrity of the product information delivered under the contract.

Acceptance of this data item shall be based upon: self-merit/content and visual comparative agreement with drawing originals or reproductions, if ordered. Validation here means determination of acceptable transfer and translation of data from the contractor's CAD/CAE system to the _____(add applicable interfacing system)

CDRL must include language that specifies exactly how data will be delivered (including media, format, and content) under the contract. CALS standards should be invoked whenever possible.


8.2.6.5.4  Product Data File Delivery Option (IGES Format)
Product data files in IGES format consist of a variety of data delivery options including IGES files, text data files, and PDES. Suggested delivery media options include: (1) Optical disk, (2) magnetic disk, or (3) 9-track magnetic tape, all in accordance with MIL-STD-1840. Paper documentation may be requested in addition to the digital data deliverables but only for verification of the digital data.

Drawing master STEP CAD/CAE data shall be as follows. Data shall be delivered on a 9-track tape, QIC tape, or magnetic disk. Data shall be organized as one drawing per file with multiple sheets permitted. Unsupported or unspecified "volunteer" entities shall not affect the data transfer integrity of the product information delivered under the contract. Data product files shall be written in ASCII compatible forms.


8.2.6.6  Advantages and Disadvantages of Delivery Options
Table 8.2.6.6-1 lists some of the comparative advantages and disadvantages of TDP delivery as paper, raster, vector, or processable data files.


Table 8.2.6.6-1  Advantages and Disadvantages of Delivery Options

Type

Paper

Raster

Vector

Processable
Data Files

A
D
V
A
N
T
A
G
E
S

1. Already a deliverable form.
2. Can be copied and distributed easily.

1. Importable into documents
2. Already a deliverable form.
3. Electronic indexing, filing, and archiving.
4. Nearly exact fidelity for illustrations providing format is standard.
5. Files can be compressed to reduce size.

1. Easily edited, maintained, updated.
2. Electronic indexing, filing, and archiving.
3. Small file sizes compared to raster equivalents.
4. File information compatibility between editing, sending, and receiving systems.
5. Files contain intelligent data.

1. Easily edited, maintained, and updated.
2. Electronic indexing, filing, and archiving.
3. Already a deliverable form.
4. Files accept generic text and raster data from other sources.

D
I
S
A
D
V
A
N
T
A
G
E
S

1. Cannot be edited or changed.
2. Not importable (must be scanned to digitize).
3. Bulky filing system.
4. Originals can be easily lost or destroyed.
5. Originals deteriorate over time.

1. Editing is extremely tedious.
2. Relatively large file sizes.
3. Induced errors from incompatibilities of hardware even when using an agreed to standard.
4. Raster quality dependent on original and chosen pels/inch standard.
5. Raster quality also dependent on accuracy of equipment and method used to scan original image.

1. Not directly importable into documents, must be converted to a raster format.

1. International standards not fully developed.
2. Drawing data limited to imported raster images

 

8.2.6.7  Contract Validation


8.2.6.7.1  Contractor Validation
The contractor should be required to validate that the TDP and associated elements conform to the contractual requirements. In those instances where materiel has been developed or produced, the contractor shall validate that the TDP and associated elements accurately depict the materiel developed or produced under the contract. Use of the TDP in producing, inspecting, and testing satisfactory materiel is considered acceptable evidence that the validation requirement has been met. When specified in the contract or purchase order, the contractor's validation shall be documented in a TDP validation report.


8.2.6.7.1.1  Validation by Contractor Physical Configuration Audit or Verification Reviews
The NATO/NATO nations may require the contractor to validate the TDP through Physical Configuration Audits (PCA), Configuration Item Verification Reviews (CIVR), or by other methods through specific work tasks in the statement of work of the contract or purchase order. Unless such tasks are included in the contract or purchase order, the method of validation shall remain the contractor's option.


8.2.6.7.1.2  TDP Validation Report
A TDP validation report is used by the NATO/NATO nations to review the procedures and evaluate the results of the contractor's validation of the TDP as conforming to the data requirements in the contract or purchase order.


8.2.6.7.2  Government Verification


8.2.6.7.2.1  Digital Data Product Acceptance
The unique aspect of CALS digital data deliverables is that they will be subject to inspection and acceptance on several levels. The lowest level of acceptance is the data content and format. The acceptance process at this level is identical to acceptance of the data product provided on paper. This level of acceptance will be accomplished by viewing the data either through use of a computer video screen or by viewing a paper printout of the data product. The next level of acceptance is adherence to the specified CALS data exchange format. This will usually be compliant with the CALS standardization documents or other national or international data exchange standards. Automated tools may aid this level of acceptance. The next level of acceptance is applied to the MIL-STD-1840 digital data format if it has been specified. Again, automated tools may be used to verify compliance. Finally, the physical media may have acceptance criteria to be applied. This level of acceptance will not be used if data has been formally delivered by the CITIS. The means of inspection to be used should be provided to the contractor as soon as these means have been determined. Any or all levels of acceptance may be performed at the contractor's facility or at a NATO/NATO nations facility, as required. In addition to digital data acceptance, CITIS requires that additional acceptance requirements be applied.


8.2.6.7.2.2  CITIS Acceptance
Acceptance of the service and the CITIS Contract Line Item Number (CLIN), if utilized, is verification that the contractor has provided the service as specified. MIL-STD-974 and the particular statement of work define the CITIS functional requirements. A checklist of CITIS functional requirements may be prepared to assist in tracking contractor compliance. These functional requirements may include service availability, maintenance response, provision for core information functions, provision for value-added information functions, and the like. Assurances of adequate acceptance testing for CITIS should be obtained via contractor demonstration of the service. The test should include demonstration of functional capabilities and verification that the CITIS will handle the data required without alteration of the data product. Such a test is not required for each delivery but may be rerun if major maintenance has been accomplished or if the sending or receiving systems have been changed enough to warrant an additional test. If specific test data are deemed necessary for adequate testing of a CITIS, that test data should be provided and results reviewed on-site at a customer facility. On-line access service should be accepted when it is demonstrated that a person with proper authorization can perform the contractually required core and value-added functions from a terminal or workstation at the customer's facility or as otherwise agreed. Electronic data transfer service acceptance should occur when a single instance of transfer of the specific deliverable type can be achieved including successful download of data into the customer's system when contractually required. This data may be real product data or test data, as appropriate.


8.2.6.7.2.3  CALSIP Acceptance
The original contract baseline requirements for CALS-compliant product(s) are subject to change and redefinition, by mutual agreement, throughout the duration of the contract. The NATO/NATO nations verifies and controls, in part, the adequacy of the CALS product change and redefinition process via the approval of the original and revision(s) of the CALS Implementation Plan (CALSIP) along with the final acceptance of the CALSIP at contract completion.


8.2.7  Applying CALS to the Creation, Management, and Use of Technical Manuals (TM)


8.2.7.1  General Consideration
Technical manuals are any technical publication or other form of media used to install, operate, maintain, test, repair, overhaul, or provide logistic support of ships, aircraft, defense systems, or defense material. They are the operating and maintenance instructions for military technicians. They contain a combination of textual narrative and illustrative graphic images presented in a formal, structured, page-oriented format governed by specific functional standards.

These manuals have traditionally been prepared and delivered in hard copy form as camera-ready copy, which in turn are printed in large lots. However, TM data may be presented or delivered in any media including, but not limited to, hard copy, audio and visual displays, on-line access, magnetic tape, discs, and other electronic devices.

The implementation of automated data processing technology offers numerous improvement opportunities in both preparation of technical manuals and in the delivery, storage, distribution, and maintenance of these manuals. Technical manual data in digital form can be stored on magnetic or optical media, transmitted and shown on computer terminals, and printed on demand. Acquiring technical manual deliverables in digital form allows the military user to view required information without printing it on paper.

Acquiring processable data files provides the opportunity to tailor outputs for particular uses and users. Data can be reformatted into systematic trouble-shooting formats for maintenance personnel, it can be adapted to expert system diagnostic programs, or it can be used to generate training aids.

The development of a CALS strategy for TMs needs to be carefully examined to maximize the value for a specific defense system program. Program attributes such as technology, costs, quantities, and schedules have a profound effect on the delivery requirements for TMs. The technical manual manager must consider the life-cycle of the procurement and the infrastructure in place or being developed to support the TMs for their program.

The CALS environment will reduce or eliminate the need for conventional forms of media such as paper, microfiche, and microfilm.

The benefits associated with using digital data for TMs include:

The acquisition guidance provided in this section applies to the three major TM categories:

For TMs the benefits of digital data include: improved handling, reduced storage, reduced costs, improved accuracy and timeliness

The following paragraphs discuss various considerations that must be addressed:


8.2.7.1.1  Identify/Establish the Requirements for the TM
The project manager will first identify the requirement to procure a TM through the development of overall supportability goals and the initial maintenance philosophy. This is brought about through the Logistic Support Analysis (LSA) process.

The LSA process will quantify and define requirements such as the need to operate or perform maintenance on equipment. The Logistic Support Analysis Record (LSAR) will contain the necessary task narratives for the operation and maintenance of equipment and will be used as the primary source for the development of technical manuals of various types.


8.2.7.1.2  Identifying the TM User's Requirements
The project manager must now identify the intended TM user's infrastructure.

The users include:

    · Those involved in system acquisition, review, and approval;
    · The TM management infrastructure;
    · The end user.

The project manager should consider for each user:

The expected infrastructure will be documented in the NATO CALS Concept of Operations (NCoO), and will include:

Acquisition requirements for user hardware and software to support a fielded defense system must be considered during the CALS implementation strategy and planning process.


8.2.7.1.2.1  Infrastructure Development
Effective acquisition of digital data can be done only with full consideration of the ability of the NATO/NATO nations to receive, store, distribute, and use digital data that complies with the CALS standards. The project manager must establish the uses for which the data is required, and the infrastructure modernization programs that must be available to support this data.

User data infrastructure is the computing environment available to a particular user.

The evolution of this infrastructure is a key consideration in implementing the CALS strategy on any given acquisition. Deficiencies in the infrastructure modernization will jeopardize the effort to implement the CALS TMs strategy effectively.

The availability of digital data processing and telecommunications technology and approved standards for creation, storage, transmission, data protection, and integrity of data at the time of delivery or access are important criteria for acquisition decisions. The current and projected capabilities of both the contractor and NATO/NATO nations must be assessed with respect to program needs and schedules. The NCoO, Contractor's Approach to CALS (CAC), and CALS Implementation Plan (CALSIP) are excellent vehicles for making these determinations.

The data user infrastructure, which is the computing environment available to a particular user, must be considered when acquiring digital data. This environment establishes the data processing capabilities of that user. The following areas identify a user's infrastructure:

Hardware: Determine the current and planned hardware available to support the defense system program;


8.2.7.1.2.2  Data Uses
The project manager will need to identify the use of the data by all organizations involved in the acquisition program in order to make good decisions on digital TMS requirements. The five defined categories of data processing are:


8.2.7.1.3  TMs in the CALS Environment
The project manager should be aware that it is possible to acquire TMs in a variety of forms depending upon the needs of the users. Documents such as maintenance manuals may be highly beneficial when procured as Interactive Electronic TMs (IETM). The IETM user would be the technician whose main concern is finding the desired maintenance-related information quickly and easily without being burdened in the field with the entire maintenance manual.

Primary considerations for the project manager to address are the media, format, and content of TM data deliverables and their respective end users.

Description, operation, and maintenance, and installation and checkout manuals, however, may be procured best in raster or Page Description Language (PDL) since these manuals are not used as often. Obviously, it is better to leave these decisions up to the individual program office since each defense system program is unique in its requirements. Primary considerations for the project manager to address when applying CALS to the creation, management, and use of TMs is the media, format, and content of TM data deliverables and their respective end users. Paper, microfiche, and microfilm have been included in this discussion of CALS because much of the current inventory is still available on these media. The CALS initiatives will reduce or eliminate the need for these forms of media in the future.


8.2.7.1.4  Non Digital Data Deliverables


8.2.7.1.4.1  Paper
Paper or final reproducible copy has long been the traditional media for delivery of product data and related information. TMs delivered on this media may have originated from many sources including other existing paper documentation, microfiche, microfilm, or any of the digital data formats described in the following paragraphs.

The project manager should accept paper deliverables only for the purpose of verifying the digital deliverables.

No digital data infrastructure requirements are necessary for TMs delivered on paper. However, converting the data content of paper to a digital data format requires infrastructure systems that include scanning hardware and software to support the conversion of both text and graphics from hardcopy to electronic format.


8.2.7.1.4.2  Microfiche/Microfilm
Microfiche and microfilm are other traditional media for delivery of data. They are not recommended media for obtaining new data, but are mentioned here since legacy data in this form already exists. Converting the data contents of microfiche or microfilm to a more flexible digital data format requires additional infrastructure requirements that include scanning hardware and software to support both text and graphics.


8.2.7.1.4.3  Digital Data Deliverables
The project manager must choose from a variety of digital data formats and media options. For TM delivery, the list includes:


8.2.7.1.4.3.1  Data Formats
Raster


8.2.7.1.4.3.2  Media
MIL-STD-1840 magnetic tape
Magnetic disk
Optical disk
CITIS - interactive access


8.2.7.1.4.4  Life-cycle Considerations
TMs are generally not required until the later acquisition life-cycle phases of a defense system program. TMs available during the earlier phases may be preliminary copies that have not been verified or have not received final acceptance but are useful for test verification, training, and operation. Preliminary versions may be delivered in mutually agreeable word-processing format while the FRCs should be in SGML format. Final Reproducible Copies (FRC) are available in the later phases. The project manager must consider the information volume and typical use of the data generated during each of these phases to determine the appropriate TM deliverable format. Note that the deliverable format may be different for each phase.

Preliminary versions may be delivered in mutually agreeable word-processing format while the FRCs should be in SGML format.


8.2.7.1.4.5  TM Contract Requirements
Delivery of defense system data in digital form requires changes to NATO solicitations and contracts including their attachments and enclosures. These changes should be made with full consideration of the ability of NATO to make cost effective use of digital data deliverables or access.

Each defense system program may include unique requirements for which additional program-specific tailoring will be needed. Most of the applicable CALS standards and specifications contain contract-negotiable options from which the project manager must choose to satisfy program-specific requirements including multiple classes or types of data formats.

The TM Contract Requirements (TMCR) will identify the types of TMs required and include language that specifies exactly how data will be delivered (including media, format, and content) under the contract. SGML should be invoked whenever possible for digital delivery of TMs.

The media for delivery such as magnetic tape, optical disk, or on-line (networks, telephone modems, CITIS) should be compatible with NATO/NATO nations receiving system capabilities. Some digital interim deliverables may be efficiently acquired by agreeing on a common word processing package in the contract and specifying the appropriate and compatible physical media such as magnetic disk, magnetic tape, etc.


8.2.7.2  Specific Considerations
Once the general considerations have been reviewed, the information contained in this section can be used to select the options best suited for the defense system program objectives. The options must be evaluated for usefulness with respect to each phase of the defense system's life-cycle and whether the defense system program's infrastructure can support a particular option. Once the most suitable options have been selected, the process to validate and verify these options should be determined.

The following paragraphs discuss additional considerations that must be addressed:


8.2.7.2.1  TM Delivery Format Selection
The purpose of this paragraph is to determine the status and/or existence of the TM and ultimately to lead the project manager to a decision as to the specific type of digital data and media format required to support the defense system program. In addition to the immediate TM requirements (acquire and/or develop a TM), the project manager should be concerned with the potential long term engineering and support functions and requirements when procuring the TM.


8.2.7.2.1.1  Raster
Raster data is a binary representation of an image. Raster may be thought of as the electronic version of a paper document. It contains no intelligence and must be reviewed through human interpretation. There are two types of raster data, tiled, which is the preferred format, and untiled. A tiled raster image resembles a two-dimensional grid with each "tile" or set of pixels representing a portion of the image. Text and graphics in raster data formats allow more rapid and consistent access to the stored images than paper. In addition, raster data formats can be sent via electronic means to remote sites. Through a difficult process, raster files can also be converted to digital (word processor or desktop publishing) documents and edited through manipulation of individual pixels.

A tiled raster image resembles a two-dimensional grid with each "tile" or set of pixels representing a portion of the image.

With the advent of raster scanning technologies, the ability to convert existing paper TMs to digital data files has become available. Raster conversion is the easiest and most cost-effective method for digitizing the existing paper TMs. However, the quality assurance (QA) process by human interpretation required to verify the data contents may increase costs substantially. In addition, raster image files require a large amount of memory storage due to their file structure and contain no additional information other than each tile's position on a grid. Technologies are evolving that will be able to convert the raster images to other digital forms (such as vector) for processing, but the project manager should consider other processable data forms first unless the TMs required are legacy data.


8.2.7.2.1.2  Illustrated Text Data Files
Illustrated text data files provide a dynamic form of source data with two possibilities:

Text data files include word processing and desktop publishing applications. Such data files can provide the source data for multiple data applications that allow creation of standard and custom documents as well as manipulation of the data for annotate/excerpt or update/maintain purposes. Illustrated text data files can also import generic text and graphics from other sources that may be otherwise incompatible. In addition, there are PDLs, sometimes called text presentation metafiles, which are used to drive output devices such as printers. Finally, project managers may want to consider the new software products for creating platform-independent neutral data files that allow users to save information created in a variety of software applications and formats into a platform-independent file format, which can then be viewed and printed by anyone possessing the appropriate reader software.

There may be instances when illustrated text data files include more than one format of graphical data. The project manager must be aware of this possibility and be prepared to develop/modify the defense system contract requirements accordingly.


8.2.7.2.1.3  Text Format
There are two possible text formats for consideration. They are the ASCII and tagged ASCII or Standard Generalized Markup Language (SGML). They are described below.

ASCII

SGML


8.2.7.2.1.4  Graphics and Illustration Formats
The three possible graphics formats for consideration are Computer Graphics Metafile (CGM), Initial Graphics Exchange Specification (IGES), and raster. These formats are described below.

CGM

IGES

Raster


8.2.7.2.1.5  Page Description Language
A Page Description Language (PDL) file is executed by an interpreter that controls a raster printer or other output device. A PDL can be used to ensure that the composed document produced by an electronic publishing system (which may impose additional processing limitations, such as font variations or hyphenation) would produce nearly identical hardcopy output on the widest possible spectrum of printer devices.

PDLs are currently not standardized, and a Standard Page Description Language (SPDL) is still being developed. MIL-STD-1840 requires that a system must provide portability of files (PostScript or Impress PDL specifications). PDL document image files can be acquired as interim deliverables or as final deliverables in addition to, but not in place of, other digital data deliverables developed in accordance with the CALS standards.


8.2.7.2.1.6  Neutral Data Files
Several industry-developed software products for creating platform-independent neutral data files have recently become available that allow users to save information created in a variety of software applications and formats, including text, graphics, and spreadsheets, into a platform-independent file format. These files can then be viewed and printed by anyone possessing the appropriate reader software. Many applications also allow reader-software users to annotate data and copy information to paste into other word processing programs. The NATO/NATO nations should consider these applications cautiously since they are not part of the CALS standards.


8.2.7.2.2  Interactive Electronic Technical Manual
An Interactive Electronic Technical Manual (IETM) is a computer-based collection of information needed for the diagnosis and maintenance of a defense system. It is optically arranged and formatted for interactive presentation to the end user on an electronic display system. Unlike other optical systems that display a page of text from a single document, IETMs present interrelated information from multiple sources tailored to user queries.

An IETM is essentially a hypertext document, which consists of a collection of "interconnected writings." These interconnections allow a user to browse through a document by selecting points of interest or hotspots that may be connected to other related text, hotspots, or menus. The user could then continue to follow along these "paths" to other cross-referenced points in that collection of writings. This creates a "pageless" document that, depending on the source database, can contain a collection of information from a variety of sources. Also, rather than limit these documents to pure text, we may incorporate graphics, audio, video, and/or computer programs into the content of the document, creating what is known as a hypermedia document.

The information in an IETM is visually arranged and formatted for interactive presentation to the end user on an electronic display system. Unlike other visual systems that display a page of text from a single document, IETMs present interrelated information from multiple sources, tailored to user queries in a hypertext format. This hypertext document consists of a collection of interconnected writings that allow a user to browse through a document by selecting points of interest or hotspots that may be connected to other related hotspots or menus.

By streamlining access to the desired information and by providing multiple paths to other related information, the IETM offers a more efficient and more comprehensive method of using technical information.

Unrestricted by the page-oriented display and the use of sole-source information, the IETM duplicates on the Personal Computer (PC), the research environment available in a well-equipped multimedia library; displays only the actions appropriate for resolving a specific problem; provides fault-isolation tables and diagrams; and guides the technician through the troubleshooting process via a user-friendly query method. IETMs permit the user to locate information more easily and to present it faster and more comprehensively in a form that requires much less storage than paper.

Derived from the LSAR and CAD data, the IETM will inherently become an integral part of the defense system from the outset. Data created throughout the defense system's life-cycle will contain all of the information needed to create and revise the necessary IETMs for the program. IETMs require a computer environment with the appropriate presentation systems and software to invoke them.


8.2.7.2.3  IETM Viability
The project manager should consider whether the TM will ultimately be used in an interactive computer environment, the IETM. The IETM format offers the user distinct advantages over the traditional TM.

Some IETM benefits include:

The project manager should first determine whether the end item or defense system program is currently in the early phases of design, whether the life-cycle requirements for the TM exceed five years, and whether the Technical Data Package (TDP) or LSAR database is available.

If any of these considerations can be answered "NO," then an IETM is not recommended. If all considerations can be answered "YES," then a business case analysis should be performed to determine the economic feasibility of the IETM. If results from this analysis recommend pursuing an IETM or quality readiness and/or support factors lend adequate credence to the need for an IETM, development of an IETM should be pursued.


8.2.7.2.4  IETM Development
If IETM development has been selected, the project manager must first determine whether this effort will be associated with an existing IETM in terms of either the modification of an existing IETM or the creation of a supplement to an existing IETM. If this is indeed the case, then the project manager must determine whether an existing infrastructure and display device will be used in conjunction with the IETM and whether this infrastructure uses a proprietary format. If all of the above conditions are true, then the final IETM developed should remain in the existing proprietary format. However, if any of these conditions is not met, then it is advised that the IETM be developed using the new IETM standards.


8.2.7.3  TM Development
Utilization of existing TMs and legacy data is likely in the development of completely new systems with similar features. The project manager should be aware that even on completely new defense system programs, some portion of the TMs might exist in both digital and non-digital formats. This is most relevant when a program is entering the earlier life-cycle phases. An important point to remember here is that acquisition of the proper level and type of digital data is most cost effective when defined early in the program's life-cycle.

An important point to remember here is that acquisition of the proper level and type of digital data is most cost effective when defined early in the program's life-cycle.


8.2.7.3.1  TM Availability
Another consideration the project manager must address is whether existing off-the-shelf TMs will satisfy the program's TM requirements. If more than 90 percent of the TM conforms to the technical requirements and supports the maintenance concept of the equipment, the TM may be used. However, if more than 10 percent of the proposed TM fails to meet the necessary requirements to support the equipment, a new TM should be developed.


8.2.7.3.1.1  TM Development
Once it has been determined that a TM will satisfy the technical requirements and maintenance concept of the equipment, the project manager must determine the present format of the TM and whether change pages and/or a TM supplement will be required. If the "basic" TM is available in a word processor format, the TM may be delivered in its present format providing that this is mutually compatible with the existing infrastructures. If it is not, the TM should be delivered in raster format. Also, if change pages and/or a TM supplement will be required in addition to, or instead of, the "basic" TM, then the development of these items is the same as that required for a new TM except that the format and style of the newly developed items may remain the same as the "basic" TM.

If more than 25% of the existing TM is affected by changes, complete revision of the TM is recommended

The project manager must now determine how well the existing military TMs cover the maintenance concepts of the equipment. Changes to the hardware configuration or equipment components of the defense system may impact the accuracy of the TM's information. If more than 25 percent of the existing TM is affected by these configuration changes, complete revision of the TM is recommended.


8.2.7.3.1.2  TM Permanent Change Page Development
If less than 25 percent of the TM needs revision, only change pages will be developed.

Once it has been determined that less than 25 percent of the TM needs revision, only change pages will be developed. The basic TM will be converted to raster if it is not already digitized. Change page development will follow the same decision path as the development of a new TM, but the newly created change pages will retain the format and style of the original TM.


8.2.7.3.1.3  TM Update Revision Development
Once it has been determined that more than 25 percent of the TM must be changed, the project manager must decide how the final product will be delivered. The decision process follows the same basic path as that stated for a newly developed TM; the difference is the revised TM may retain the format and style of the original TM.


8.2.7.3.2  New Technical Manual or Complete Revision


8.2.7.3.2.1  Source and Legacy Data Considerations
The project manager must now consider whether any of the TM source data presently exists as legacy data. Legacy data developed from existing defense systems or from the creation of LSA data may contain enough information to warrant inclusion into the new defense system program.

For newer defense system programs, this legacy data may exist in both digital and Non digital formats. If legacy data does exist in a digital format, the project manager should address life-cycle considerations. If no legacy data is to be procured for the defense system's TMs or no digital legacy data exists, the project manager should consider whether configuration changes and/or multiple configurations are anticipated for the end item or defense system.


8.2.7.3.2.2  Defense System Configuration Considerations
Configuration differences may play an important part in the acquisition of defense system TMs. The differences may be as small as printed circuit card modifications or as large as entire equipment changes. The project manager must determine whether multiple configurations will exist, and whether different TMs will be procured for each configuration. Another consideration is whether future changes to the TM are anticipated. If multiple configurations and/or configuration changes are anticipated, conversion of the source or legacy data to digital format is recommended. Specific conversion format may be based on an economic analysis that may recommend that some paper legacy and source data simply be scanned into a raster format and other illustrations be recreated/converted to a vector format. If this is not the case, the defense system program should consider delivery of the TM in raster format for both text and graphics.


8.2.7.3.2.3  Program Life-Cycle Considerations
The project manager must now consider the current phase of the end item or defense system program and the anticipated requirements for the TMs. If the end item or defense system program is currently in the later phase(s) of its life-cycle and the TM requirements are anticipated to be fewer than five years, the need to deliver SGML-formatted TMs is not recommended, especially since most of the data for the TMs may be in hard copy or proprietary digital format.

If this is indeed the case, delivery of both review and Final Reproducible Copies (FRC) of the TMs in a mutually agreeable format is recommended. If the TM requirements are anticipated to be at least five years and this TM development process is concerned with a TM Update Revision, SGML-formatted TMs are recommended.


8.2.7.3.2.4  Additional TM Update Revision Decisions
A TM Update Revision may retain the style and format of the original TM. With this in mind, additional considerations concerning SGML formatting arise. DTDs and FOSIs may exist that support the modification of the original TM while retaining the original style and format.

If these DTDs do not exist, then the project manager must consider, through economic analysis, whether it is cost effective to modify or create a DTD and FOSI to satisfy the style and format requirements of the original TM. If economic analysis determines that it is not practical, it is recommended that the new TM Update Revision be delivered in a mutually agreeable format for both text and illustrations.


8.2.7.3.2.5  Conversion of Illustrations
The project manager must now determine, through economic analysis, whether conversion of all existing illustrations is justified. Conversion in this case means converting nonvector illustrations, both source and legacy data that currently exists in raster and hard copy formats, into a vector format.

If it is determined that conversion of all existing nonvector illustrations to a vector format is cost effective or if no source or legacy illustrations exist, then the recommended solution is to convert and/or create all applicable illustrations to a vector format such as IGES and/or CGM. If economic analysis determines that conversion of all existing illustrations is not practical, it is recommended that only selected source or legacy illustrations (those with a high likelihood of being revised at a later date) be converted to a vector format. Remaining illustrations should be delivered in raster format.

To provide maximum proliferation of the preliminary TMs for review, it may be beneficial to request that these deliverables be provided in a proprietary word processor format with illustrations in either raster and/or CGM formats only. SGML, IGES, or commercial CAD should not be used at this point unless it can be demonstrated that the reviewing activities' infrastructure can support display and annotation.


8.2.7.4  Decision Guidelines
Digital delivery options for technical manuals are not mutually exclusive. There will often be cases when several options will be combined for specific deliverables during a defense system acquisition. The decision criteria presented in this handbook are intended to aid in selecting the best options. The following is guidance for applying the criteria to technical manuals.


8.2.7.4.1  Decision #1: Deliverable Options
Technical manual data can be delivered as composed documents, processable files, or interactive access to the CITIS database. The composed document deliverable option offers the least flexibility, even in digital form. It is a static, formatted presentation of the manual, which can only be archived, viewed, and printed after receipt.

Processable files, on the other hand, offer capabilities that are more robust. These files can be updated or transformed into many different data types. With appropriate data processing systems, processable files can support creation of job guides, training documents, and eventual on-line distribution of selected portions of the data to maintenance personnel. In addition, a separate indexing mechanism may be needed for either machine or human search or access.


8.2.7.4.1.1  Destination System Constraints on Form
Processable data files are preferable to composed documents, but the presence of both text and graphics may cause some difficulty because not all presently installed computing equipment and software can simultaneously process text and embedded graphics. This issue is rapidly disappearing. Nonetheless, during the period of intended use, installed hardware and software at both the contractor's site (i.e., the source system) and the user's site (i.e., the destination system) will be the deciding factor as to which form the deliverable may take.


8.2.7.4.1.2  Interim Dual Deliverables
Requirements for technical manual deliverables may include both composed documents in digital form and processable data files. However, until more advanced user systems are available, it may be necessary to accept a hard copy (paper) technical manual for approval, reproduction, and distribution, and a digital form of the manual for archiving or update and maintenance.

When NATO/NATO nations implement more advanced computer systems, processable technical manual files (with or without composed document image files of the technical manual) should suffice.


8.2.7.4.2  Decision #2: Forms Options
A technical manual is made up of both text (including narrative and tables) and graphics. Integrating these elements into a complete technical manual and dealing with user requirements that are different for interim review and approval than for final delivery may require more than merely choosing a single optimum form. The project manager may have to choose the appropriate forms for multiple deliverables (e.g., a document data file consisting of PDL to support in-process reviews, and processable data files for the final deliverable).


8.2.7.4.2.1  Composed Documents
If composed documents have been selected at decision #1, the forms for technical manual delivery can be either hard copy (paper or microfilm) or a digital composed document image file. The digital form of this deliverable consists of composed page images of the full manual. Two examples of digital composed document files are PDL and raster.

These options offer greater advantages than hard copy in storage, distribution, viewing, and printing. They also provide slightly more flexibility than hard copy with respect to future data uses, although their formats will be fixed and unyielding. PDL and raster provide a two-dimensional image of each manual page, offering no further updating or processing features beyond replication. Both hard copy and the digital forms of composed documents complicate update and maintenance.


8.2.7.4.2.2  Processable Files
If processable files are selected at decision #1, the forms for technical manual delivery can be either one or more sets of text and graphics files, or an integrated data file that contains text and graphics in compound data architecture. A particular type of integrated data file is the IETM.


8.2.7.4.2.3  CITIS Interactive Access
Computer screen display is the primary, preferred form for CITIS information delivery.


8.2.7.4.3  Decision #3: Specification and Standard Options


8.2.7.4.3.1  Composed Documents
Technical manuals acquired as composed documents may be acquired in the form of either camera-ready masters or digital document image files. The intended application may also require an additional indexing mechanism for efficient subsequent processing. Camera-ready masters should be delivered in accordance with appropriate standard. Digital document image files in raster form should be acquired in accordance with MIL-R-28002. Conversion systems for paper copy are in place for converting legacy data to the MIL-R-28002 format. MIL-R-28002 provides two options: Type I and Type II. Type I raster graphics binary format consists of Group 4 encoding as defined in FIPS PUB 150(Consultative Committee on International Telegraphy and Telephony (CCITT) Recommendation T.6). Type II raster graphics binary format consists of ASN.1 and CCITT Recommendation T.6 encoding as specified by the document description presented in the NIST ODA Raster Document Application Profile.

The term "tiled raster data" refers to drawings that are segmented into several grids of small blocks containing raster data. These blocks of data are compressed individually. Modifications to a tiled drawing are easier to control since only those small blocks of data requiring changes are modified. Storage of document images in a PDL such as PostScript provides an alternative form. PDL document image files can be acquired as interim deliverables, or as final deliverables in addition to (but not in place of) processable data files using MIL-STD-1840 and MIL-M-28001.


8.2.7.4.3.2  Specifications and Standards for Graphics
Graphics data may be in either raster or vector formats. Assuming an adequate scanning resolution, raster provides nearly exact fidelity for illustrations. Vector graphics translates data between different sending and receiving systems in native forms (this can introduce errors, even when an intermediate, neutral format is agreed on).

For example, a line expressed as a series of pixels connecting a pair of end points, versus a line expressed as an origin, direction, and length. Vector representations are easily edited, maintained, and updated. Vector representations also generally have the advantage of much smaller file size, even when the raster bit-map image has been compressed using an algorithm such as that specified by MIL-R-28002.

Nevertheless, raster graphic illustrations are frequently encountered because scanning remains the only practical way of converting a legacy of hardcopy drawings into digital data. Despite the quality limitations of raster data, the hardcopy legacy data requires supporting both raster and vector formats for graphics.


8.2.7.4.3.3  Specifications for Vector Graphics
There are two choices of standards to consider for vector graphics:

For technical manuals, CGM is the preferred option but IGES can be used. Extensions to the standard to allow translations of native CAD data into CGM are still being developed. If technical manual illustrations are being derived directly from design data, then system limitations may constrain the choice of delivery standard. In selecting the appropriate option, the project manager should recognize the potential problems created by multiple translation steps (e.g., unique CAD system to IGES to CGM). MIL-D-28003 specifies an Application Profile (AP) with two options: Level I for publication quality data, and Level II for draft quality data.

Uncompressed raster data can be included in a CGM file, but MIL-D-28003 should only be used where the predominant form of the graphics information is vector. When IGES is used for technical manual illustrations, the Class I Technical Illustration subset is appropriate. Data would be delivered in ASCII, as specified by MIL-D-28000.


8.2.7.4.3.4  Processable Text
Processable text data files should be acquired in accordance with MIL-M-28001, which implements the SGML. An SGML Document Type Definition (DTD) and Formatting Output Specification Instance (FOSI) created in accordance with the provisions of MIL-M-28001 or AECMA 1000 D should be used to meet the document structure and format requirements of the technical manual. The project manager may be required to fund development of a unique DTD or FOSI. A more sensible approach would be to make use of previously developed DTDs


8.2.7.4.4  Decision #4: Digital delivery mode options
Physical media is currently the only economical option for the delivery of large document image files or processable data files. While telecommunications bulk transfer of these files may be possible, it is usually not an economical option because of the large volume of data contained in these files, particularly the raster document image and raster graphics files.

When CITIS interactive access to a contractor's technical manual database is chosen, then telecommunications are warranted as a delivery mode for deliverables. Security aspects will also affect the selection of delivery method.


8.2.7.4.4.1  Magnetic Tape
The standard physical media option is magnetic tape. The mature, stable, non-proprietary standard that MIL-STD-1840 requires for magnetic tape supports most originating and destination systems.


8.2.7.4.4.2  Floppy Disk
The preferred physical media option for small files is 3.5 inch, 1.44-megabyte floppy disk. Like magnetic tape, floppy disk is a mature, stable technology that is usually available at all sending and destination systems.


8.2.7.4.4.3  Optical Disk
Optical disk or CD-ROM will be alternative physical media options in the future, and are generally well suited for data archiving because they can accommodate very large volumes of data quite efficiently.


8.2.7.4.5  Digital Deliverable Summary
Selection of the options at each node of the Technical Manuals decision template should be aligned to the needs of the organizations responsible for technical manual publication and maintenance within each military department.

Processable data files should be the deliverable of choice when the Government assumes the responsibility for technical manual update and maintenance.

However, requirements for interim deliverables that are provided only for review and approval (verification) may be evaluated differently than are requirements for final deliverables. Delivery of processable data is less important when the principal applications are view and annotate, than when the intended applications are update/maintain and process/transform. Consequently, document image files may be more appropriate early in the life-cycle of the program; however, processable data files should be the deliverable of choice when the Government assumes the responsibility for technical manual update and maintenance.


8.2.7.4.5.1  Example - Delivery of Digital Data as Processable Files
Selection options for technical manuals may be processable technical manual files composed of:


8.2.7.5  Validation and Verification


8.2.7.5.1  Contractor Validation
The contractor should be required to validate that the delivered TM conforms to the contractual requirements. Specific validation agenda should be provided in the contractor's validation plan and associated documentation.


8.2.7.5.2  NATO/NATO Nations Verification
The acceptance of CALS digital data products, either delivered on physical media or by CITIS, is different in several ways from the acceptance of comparable paper data products. The following paragraphs provide details on the acceptance of digital data products.


8.2.7.5.2.1  Digital Data Acceptance
The unique aspect of CALS digital data deliverables is that they will be subject to inspection and acceptance on several levels. The lowest level of acceptance is the data content and format. The acceptance process at this level is identical to acceptance of the data product provided on paper. This level of acceptance will be accomplished by viewing the data either through use of computer video screen or by viewing a paper printout of the data product.

The next level of acceptance is adherence to the specified CALS data exchange format. This will usually be compliant with the CALS standards or other national or international data exchange standards. Automated tools may aid this level of acceptance. The next level of acceptance is applied to the digital data format, such as MIL-STD-1840, if it has been specified. Again, automated tools may be used to verify compliance. Other formatting requirements may be subject to inspection and acceptance including EDIFACT format, when specified.

Finally, the physical media may have acceptance criteria to be applied. This level of acceptance will not be used if data has been formally delivered by the CITIS. The means of inspection to be used should be provided to the contractor as soon as these means have been determined. Any or all levels of acceptance may be performed at the contractor's facility or at the NATO/NATO nation's facility, as required. In addition to digital data acceptance, CITIS requires additional acceptance requirements to be applied.

 

Previous PageTop Of PageNext Page