This guidebook provides a program manager with the methodology and tools to prepare an Integrated Data Environment (IDE) business case. The focus of this guidebook is to lay the foundation for the program manager to prepare IDE Business Cases in a practical and manageable manner. This guidebook provides an overall view of the Business Process Reengineering (BPR) methodology, introduces the program manager to tools that are available to ease the preparation of IDE Business Cases, and provides the framework for IDE Business Case development. Because, by definition, the IDE Business Case deals solely with technology-related initiatives and alternatives, particular attention is given to documenting the program's geo-technical baseline, and the impact of initiatives and alternatives on that baseline.
The purpose of the IDE Business Case is to provide the decision
maker with the comparative analysis for making investments in
the program's geo-technical configuration. The geo-technical
baseline can be defined as the program's technical foundation
of the existing technical infrastructure, location of the infrastructure,
data exchange occurring within the infrastructure, plus any approved
changes to the infrastructure. Therefore, the IDE Business Case
is a subset of a full program business case undertaken as part
of a BPR project. The investments made in the program's geo-technical
configuration must support the activities of the program by making
the activities more reliable, cost-effective, and timely.
This guidebook was based upon the Department of Defense (DoD)
Enterprise Model. The activities, processes, and data described
within the DoD Enterprise Model not only serve as a foundation
of understanding for DoD and contractor personnel, but also span
all levels of activity and data for the DoD. Because the DoD
Enterprise Model is the template for integrating improvements
and operations across DoD, it becomes an integral tool for developing
IDE Business Case methodology. A complete discussion of the DoD
Enterprise Model is included in Subsection 4.2.1 of this
guidebook.
"It must be remembered that there is nothing more difficult to plan, more doubtful for success, nor more dangerous to manage, than the creation of a new system. For the initiator has the enmity of all who would profit by the preservation of the old institutions, and merely lukewarm defenders in those who would gain by the new ones." Machiavelli
The world has changed drastically in the last few years. As the
Cold War has come to an end, the American public has turned from
blaming the problems of the world on communism to blaming Congress.
Faced with the soaring national budget deficit, the American
public is demanding that our Government, "Shape-up or ship-out!"
Never was this so apparent than in the ouster of the Democratic-led
Congress of 1994. Under special scrutiny is the Department of
Defense, often portrayed in times of peace by the news media as
the "multi-billion dollar bureaucratic bottleneck."
The American public has said "no more" to colossal
weapon-system cost over-runs. Faced with a shrinking budget,
DoD has been forced to "re-think" the way it "does
business." In the face of this challenge, DoD has sought
to improve itself by:
In short, DoD has begun to think of itself as a business, rather
than an economy. DoD's mission has been modified from "provide
for the common defense" to "provide for the common defense
in an efficient, costeffective manner." The Department
has been downsized from its late 1980's posture, yet maintains
technological superiority through a combination of better intelligence,
sophisticated command and control, smart weapons, highly motivated
and trained personnel, and the application of information management
to all DoD activities. Global end-to-end information connectivity
among U.S. and allied forces is a critical mission capability
and force multiplier for worldwide readiness, mobility, responsiveness,
and operations. To achieve this end-to-end information connectivity,
DoD has embraced the Integrated Data Environment (IDE) concept.
DoD's vision as to how it will do business in the future,
implementing the IDE concept, is as follows:
Joint interoperability and information integration have been achieved
on the battlefield resulting in significantly improved joint service
and multinational operations. The military industrial base has
been fully integrated with the commercial base, so the Department
can rapidly obtain and use standard commercial products and services
at lower cost. Acquisition has been streamlined through the application
of Continuous Acquisition and Life-Cycle Support (CALS) and Electronic
Commerce/Electronic Data Interchange (EC/EDI) enabling technologies.
The sustaining base has been integrated seamlessly with the theater
to deliver the right mix of assets and capabilities when and where
they are needed for the Combatant Commander to achieve the assigned
mission.
All Department functions and organizations have been reengineered,
improved and integrated, from an enterprise wide perspective,
to achieve streamlined and significantly more effective operations.
Modernized information systems have been implemented to support
these re-engineered functional processes. Throughout the Department,
information is viewed as a strategic asset used to continually
increase the effectiveness of military operations and support
activities through improved management processes, technology exploitation,
economies and greater responsiveness.
To achieve this vision, many interrelated programs, directives,
initiatives, etc., are in place or being developed by DoD. They
include the following:
In essence, the DoD is reengineering its business processes.
BPR is a radical improvement approach that critically examines,
rethinks, and redesigns mission product and service processes.
It achieves dramatic mission performance gains from multiple
customer and stakeholder perspectives. It is a key part of a
process management approach for optimal performance that continually
evaluates, adjusts, or removes processes. DoD's approach for
conducting business-process reengineering is to:
To achieve the DoD vision, all elements of DoD including Weapon
System Program Managers, are being challenged to justify the expenditure
of funds to ensure that investments move DoD toward the realization
of the vision. As cited by our Statement of Work (SOW), "Program
Managers must be enabled with acceptable methodologies and guidance
for assessing the benefits of an integrated data environment,
and providing economic arguments necessary for making investments
supporting the storage, manipulation and transmission of defense
system technical information in digital formats." The accepted
methodology and guidance for enabling program managers to assess
the benefits of the IDE is an IDE business case.
A business case, in its broadest definition, is "a report
presenting business information to the decision maker."
More specifically, a business case may be defined as
A business decision document that identifies alternatives and
presents economical and technical arguments for implementing alternatives
to achieve the stated business objective/imperatives(s). It includes
functional process descriptions, technical architecture descriptions,
cost projections, action plans, measures of performance, and risk
assessment for each alternative being considered.
An IDE Business Case is a business case prepared by Program Management
Office (PMO) Personnel in response to DoD's strategic objective
for the implementation of the IDE environment. Its context is
the IDE and the program's life-cycle, and its perspective is that
of the program manager. The purpose of an IDE Business Case is
to provide Program Managers with a clear and consistent method
of determining the costs and benefits associated with the creation,
use, storage, manipulation, and transmission of defense technical
data in digital format.
A daunting amount of information is available to the program manager
in achieving this goal. Wading through this information in order
to siphon that which may be helpful to the program manager in
justifying fund expenditures, in the face of budgetary deadlines,
however, can be daunting.
This guidebook provides a program manager with the methodology and tools to prepare an Integrated Data Environment (IDE) business case. The focus of this guidebook is to lay the foundation for the program manager to prepare IDE Business Cases in a practical and manageable manner. This guidebook provides an overall view of the BPR methodology, introduces the program manager to tools that are available to ease the preparation of IDE Business Cases, and provides the framework for IDE Business Case development. Because, by definition, the IDE Business Case deals solely with technology-related initiatives and alternatives, particular attention is given to documenting the program's geo-technical baseline, and the impact of initiatives and alternatives on that baseline.
"There is nothing permanent except change." - Heraditus
The Department of Defense (DoD) and its industrial supply base
constitute the largest single enterprise in the world. This enterprise
consumes over $250 billion per year. Its purpose is to "provide
for the national defense." As is the case with most enterprises
in this economy, the DoD Enterprise is undergoing radical change.
It is redefining its objectives, given changing "market"
conditions, it is changing the way it does "business",
it is reorganizing, it is cutting costs, and it is attempting
to become more agile and adaptive.
At the heart of DoD repositioning is the central theme of "enterprise
integration." And, at the heart of DoD's enterprise integration
strategy is the Defense Information Infrastructure (DII). DoD
has committed to achieving enterprise integration by radically
changing and upgrading its information infrastructure. This job
has been assigned to the Director of Defense Information (DDI)
and the Defense Information Services Agency (DISA).
As part of this program for reengineering the DII, the DDI manages
the Corporate Information Management (CIM) initiative. CIM is
focused specifically on improving the processes used by the DoD
enterprise to do its work. A critical element of the CIM initiative
is Functional Process Improvement (FPI), which is intended to
encourage and manage changes in DoD business processes. FPI is
described in DoD 8020.1M.
Corporate Information Management (CIM) is a revolutionary program aimed at changing the way people work in the DoD. CIM is designed to help the DoD operate more along the lines of civilian businesses with an eye toward cost optimization and performance excellence. Properly applied, CIM is used to find and eliminate the duplication of functions and the redundancy of DoD business processes and information systems. CIM's approach focuses on business (or functional) process improvement techniques and requires the development of a business case before process changes and new information systems can be approved. This procedure represents a totally new way of operating for the DoD. DoD managers are responsible for implementing the CIM initiative. As part of their implementation of the CIM initiative, managers are required to prepare business cases to justify investment in systems and expenditure of funds. The goal of this guidebook is to help the program manager prepare IDE Business Cases.
"Nothing great was ever achieved without enthusiasm." - Ralph Waldo Emerson
Business Process Reengineering (BPR) is the radical transformation
of business processes to achieve orders of magnitude improvement,
eliminating non-value added activities, thus reducing cost and
manpower. It is a temptation for program managers to believe
that their status and power are directly related to how many dollars
and employees are under their control. It is also human nature
to be comfortable with the status quo, for humans tend to fear
the unknown. Combine the aforementioned, and there exists a tremendous
impediment to change. If this is the case, then why would a program
manager want to implement a BPR program that may reduce either
budget dollars or employees or both, thus reducing their status
and power without positive assurance that the changes, once implemented,
will be successful? The success and resulting cost savings do
not usually occur during the program manager's tenure.
For managers to embrace business cases and the BPR doctrine, they
must realize that they are a vital management tool to be used
to achieve customers' desired outcomes in the face of the inevitable
employee and budgetary reductions as a result of Government downsizing.
The single most important critical success factor for successful
BPR is management commitment. Without management commitment,
managers will be "going through the motions" when they
prepare business cases for their respective programs. A problem
is, therefore, how to inject program managers with the enthusiasm
necessary to believe that the business case is a tool for change
management. (Change management is the balanced management
of the resources [human and technical] associated with the change
initiative. It is about people leading the change effort and
those who are expected to implement the new strategies. It is
concerned with the organizational culture and context in which
change can occur, and the management of the emotional connections
essential for a successful transformation. A number of strategies
involved in change management include education, training, and
communications.) The answer to the problem is to provide the
manager with clear methodology to implement change that will benefit
the manager and the program; that methodology is business process
reengineering.
The program manager is tasked with performing BPR to move the
program toward the IDE vision. Yet to implement constructive
change, a program manager may need to make infrastructure investments
(tools, equipment, training, etc.) in the program. DoD requires
that the program manager justify these infrastructure improvements,
and has stated that the IDE Business Case be the medium to justify
the program's investments. It is therefore critical for the program
manager to start off on the right foot. The program manager will
be faced with preparing a business case that will justify the
expenditure of funds necessary to adopt feasible IDE improvements.
Poorly prepared, the business case will not achieve its intended
function, and may jeopardize the program manager's ability to
seek funding for those initiatives that will achieve improvement.
The program manager must begin the business case process by assembling
a team of personnel eager and ready to improve the program. A
critical factor for the success of the business case will be the
business case preparation team. The team must understand the
purpose of the business case, DoD's vision for the IDE, and BPR
methodology. The team must synthesize these ideas to form the
individual program's IDE objectives. Further, the team will act
as the program manager's agents by performing many of the activities
required to prepare the business case. Although no formula exists
for team selection, the program manager should select personnel
who are competent in technical and financial fields, and who possess
strong interpersonal skills. Once the team has been selected,
the program manager must provide the team with effective executive
leadership that will allow the team to
Once the team has been selected, it is time to begin the BPR effort.
As outlined in the Business Process Reengineering Process
Model, Version 3, published by the Office of the Deputy Assistant
Secretary of Defense (Information Management), the next step is
to perform strategic planning. The program manager and the team
will develop the vision, goals, performance targets, and strategies
necessary to move the program toward DoD's IDE vision. Program
managers preparing business cases should review the Business
Process Reengineering Process Model, Version 3 to gain an
understanding of the BPR concept. It should be noted that a program
business case is tied to activities A41 - Perform Business Improvement
Analysis, and A42-Develop Milestone Plan and Functional Economic
Analysis (FEA). This report focuses upon those two activities
that, when viewed from a program manager's perspective, make up
the activities to prepare a business case. The context for activities
A41 and A42 is a BPR effort, while the focus of this guidebook
is the IDE as part of an overall BPR effort.
For the weapon system program manager, there is no set recipe
for developing an IDE Business Case. If there were, then the
program manager could merely follow the prescribed step-by-step
procedure. At this point and at the current experience level
with process improvement, we will only provide guidance for process
improvement and guidance for preparing IDE Business Cases. To
this end, an IDEF0 approach for preparation of IDE Business Cases
is provided in the following section.
"Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." - Gen. George Patton
The approach chosen for aiding program managers in preparing IDE
Business Cases is the IDEF0 model. An IDEF0 model can be defined
as:
A graphical representation of a business process that exhibits the activities that make up the business process to any desired level of detail. An activity model reveals the interactions between activities in terms of inputs and outputs while showing the controls placed on each activity and the types of resources assigned to each activity.
The business process being graphically represented by the model
is "Prepare IDE Business Case," and can be defined as
"the process of developing a business decision document that
will identify new methods of performing the individual program's
business activities implementing IDE strategies and concepts."
The context of the model is the IDE and the program's life-cycle.
The perspective of the model is that of the program manager.
As illustrated by the model, four major activities are associated
with preparing an IDE Business Case: Gather Information; Establish
Baseline; Develop Alternatives; and Package Results. Each of
these activities is decomposed to another level of activities
in the model. A node tree of the model is portrayed in Figure 4.0-1
below:
The model is pictorially represented within the following pages.
An explanation of the activities required to prepare an IDE Business
Case is presented in the following subsections. A table containing
definitions of each of the activities is provided in Appendix
A. Arrow definitions are provided in Appendix B.
"The beginning is the most important part of the work." - Plato
The first major activity in preparing an IDE Business Case is to gather information. The activity "Gather Information" (A1) may be defined as "the process of accumulating the information necessary to prepare an IDE Business Case." As shown by model A0, the output of the activity "Gather Information" is relevant program/project information that will be used to Establish the Baseline (A2) and to Develop Alternatives (A3). PMO personnel and prime contractor representatives will use preparation tools to perform this activity. This activity may be further decomposed into three subactivities: Develop Information Gathering Plan (A11); Compile Required Information (A12); and Filter Baseline Information (A13).
"Failure to prepare is preparing to fail." - John Wooden, Basketball Coach
The program manager and the BPR team, as well as prime contractor personnel if required, will work together to develop an information gathering plan. This plan should include a plan of actions and milestones for obtaining required relevant information. As shown by the model, the business case need, as well as financial data sources, will dictate the type of information required and will control the development of the plan. Moreover, the plan of actions and milestones may be updated based upon the need for additional information not identified or received in the original plan.
"He who chooses the beginning of the road chooses the place it leads to. It is the means that determines the end." - Harry Emerson Fosdick
The "Compile Required Information Activity" (A12) is
the process of assembling the required information to prepare
a business case, issuing data calls for data to those components
that maintain the information, receiving information responses
from those components, and cataloging and categorizing the received
information. Raw technical, activity, and financial accounting
information are the inputs to this activity. The raw technical
information includes basic unfiltered features and uses of the
current hardware and software systems that will be recorded with
the aid of the geo-technical baseline tool. Raw activity information
is the unfiltered information about actions that occur in support
of the program/project, including information pertaining to what
the action is, why the action is performed, by whom the action
is performed, how often the action is performed, and at what location
the action is performed. In essence, the program manager is attempting
to document the activities performed in support of the program/project
so that an IDEF0 activity model for the particular program/project
may be derived from the DoD Enterprise Model. Costs may then
be attached to the activities. Identification and elimination
of activities that do not add value to the organization (non-value
added activities) will lead to immediate cost savings for the
program. The raw financial data are the unfiltered pecuniary
information related to the specific program/project for which
the business case is being prepared. The raw financial data may
be historic data or budgetary data.
As shown by the model, PMO personnel as well as prime contractor representatives, if required, will compile the required raw data to prepare the business case. The output of the activity is an accumulation of program data required to prepare the baseline. Another output may be the issuance of data calls for additional information. Data calls are the formal requests for additional information that are transmitted during compilation of the needed information and performed after the information sources are identified.
"When you have eliminated the impossible, that which remains, however improbable, must be the truth." - Sir Arthur Conan Doyle
After the program/project data have been compiled, the next step
is to filter the compiled information to that information pertinent
to develop the baseline for the program. Activity A13, "Filter
Baseline Information," is the process of reviewing the gathered
material for reasonableness, completeness, accuracy, and materiality,
and removing any extraneous information that is not required to
produce the program/project baseline.
As shown by the model, PMO personnel will use preparation tools,
such as TurboBPR, to produce relevant program/project information
from the input program data. The need of the business case will
aid in determining what information is important to the development
of the business case. During this activity, PMO personnel will
determine whether any deficiencies with the compiled information
exist and will gather the necessary additional information so
that the baseline may be established.
The filter baseline information activity is an iterative process. As PMO personnel review the compiled information, deficiencies in the compiled information should become evident. Additional calls for data will need to be made, additional data will be gathered, and thus the filtering process begins again. It is important to note that the "Gather Information" activity is a discovery process and may not be completed until the conclusion of specific reengineering effort for which the business case is being prepared.
"The successful man is the one who finds out what is the matter with his business before his competitors do." - Aristotle Onassis
It would be impossible to determine the success or failure of
a business process reengineering effort unless a starting point
can initially be determined. Only by understanding where the
program is today, will the program manager be able to lead the
program to where it needs to be tomorrow; it is not enough to
make "good time" unless you know where you are. The
same adage holds true with program BPR efforts, and that is the
purpose of establishing a baseline. A baseline may be defined
as "a standard for comparisons. A baseline is a reference
position for measuring progress in process improvement. The baseline
is usually used to differentiate between a current and a future
representation." The current representation refers to
the current business state, as well as any approved changes to
the current business state.
Establishing the baseline consists of five sub-activities:
Once the baseline is established, the program manager will be
able to determine what activities the business performs in support
of the program, who and/or what performs the activities and where
they are performed, and how much it costs to perform each activity
in support of the program. From this "snapshot" of
the current business state, improvement opportunities may be identified
and performance measures determined. This "snapshot"
describes the program's current business processes.
Business processes define the transactions that take place among activities performed by various elements in a business's environment. This environment comprises elements of the business itself, existing and potential customers, and existing and potential suppliers. Because the majority of business transactions occur within the context of some process or other, the majority of a business's cost can be traced to its processes. It is possible to also trace product quality, time, and quality of work life directly to business transactions and, therefore, to business activities and, ultimately, to business processes. To objectively re-engineer business processes, business processes should be modeled to identify business activities, the mechanisms to perform those activities and trace costs to the activities, and mechanisms. Using this approach, a snapshot (model) of the business can be validated.
"Even if you are on the right track, you'll get run over if you just sit there." - Will Rogers
There are numerous approaches to business process change. The
most successful of those approaches, such as the Deming approach
of statistical process control, are based on the premise that
a process cannot be improved until it is brought under control.
To bring a process under control requires, first, that it be articulated
to a level of detail where it can be measured. This level of
detail can be described by an IDEF0 Activity Model.
DoD has developed an IDEF0 Model that represents the Department's
major activities. This model, called "The DoD Enterprise
Model," has a context to "provide for the common defense."
The activities, data, and core processes of DoD are described
in the DoD Enterprise Model so there can be a shared understanding
between leaders, managers, and workers of what is being done,
how well it is being performed, and which elements should be changed.
Conceptually, the DoD Enterprise Model spans all levels of activity
and data in the Department. Managers will extend the strategic
view of the model and tailor it for use by their organizational
element. Thus, the DoD Enterprise Model becomes the template
to integrate improvements and operations across the entire Department.
There are four major activities identified in the DoD Enterprise
Model that "provide for the common defense":
Among those activities, "Acquire Assets" is the activity that is supported by the PMO. The following page depicts the "Acquire Assets" activity within the DoD Enterprise Model.
The DoD Enterprise model defines the "Acquire Assets" activity as follows:
Acquire Assets (A2):
This major activity of the defense enterprise obtains assets
to support requirements, bounded by the resources, timing, and
force structures established in the previous major activity, Establish
Direction. It manages and administers acquisitions to ensure
they adhere to acquisition policy, satisfy program requirements,
and meet planned objectives. It conducts research to increase
the "state-of-the-art"; designs, demonstrates and tests
military solution; produces products; and recruits/accesses military
and civilian personnel.
This activity manufactures military weapons and munitions,
buys supplies and services, and accesses individuals. It responds
to the legislative requirements and statutory programs directed
by Department managers.
Assets are defined as those people, goods, and services for
which the Department expends monies and receives civilian and
military personnel, materiel items of inventory, and services
or some other specified deliverable that will be managed by the
Department. For the purposes of this model, assets are defined
specifically as: people, material (including equipment, supply
items, technical publications, software systems), funds, facilities
and real estate.
Acquisition of assets involves the detailed reconciliation
of requirements to include the assessment of available goods and
services, acquisition of technology and developmental items, purchasing,
manufacturing, integrating and testing, and any preparation necessary
to ensure delivery of a useable asset through the asset distribution
systems (e.g., personnel, equipment). Therefore, for example,
accession training for military personnel is included in this
activity.
As shown in Figure 4.2.1-1, the "Acquire Assets"
Activity has three sub-activities: Manage Acquisition (A21),
Engineer (A22), and Produce Assets (A23). These activities are
defined below:
Manage Acquisition (A21):
This activity performs the management functions needed to successfully
implement approved acquisition programs and plans. It provides
the program manager functions of baseline control, contracting
and contract administration, and DAB and other oversight preparation/support.
Acquisition guidance controls the day-to-day functioning of
the program office, development activities, and contractors.
It provides management review, direction, and reporting to ensure
that baselines are maintained, issues and problems are identified
and resolved, and program performance is reported through the
acquisition "chain of command" (e.g., via Selected Acquisition
Reports (SAR)).
Acquisition programs remain responsive to user needs, acquisition
policy, and DoD standards through continual refinement and definition
of requirements, programmatic and technical reviews, and approvals
to proceed from one phase of the life-cycle to the next. The
results of studies, analyses, and demonstration/tests are provided
by this activity to enable decisions about continuation/termination.
Manage Acquisition performs all contract-related functions.
It issues solicitations, accepts and evaluates proposals, awards
contracts, and administers contracts in accordance with federal
laws and DoD regulations and policies (e.g., the Federal Acquisition
Regulations (FAR)). It monitors the delivery of goods and services,
approves payments, prepares and transmits bills, contracts may
be used by the Provide Capabilities activity, the contracts themselves
are administered by Manage Acquisition.
Engineer (A22):
This activity develops military solutions to meet validated
mission needs and satisfy user requirements for new or modified
asset capabilities, personnel, or material. It conducts different
types of research, performs engineering studies and analyses,
demonstrates solutions, and tests and evaluates designs and specifications.
Research includes scientific study and experiments to increase
knowledge of the physical, engineering, environmental, and life
sciences. It progresses from basic research through exploratory
and advanced research to establish the basis for full scale engineering
development. Basic research addresses technology and knowledge
of potential value to the national security mission. Exploratory
development assesses the feasibility and practicality of proposed
solutions to military problems short of producing and actual asset.
Advanced development produces test assets to prove-out solutions
that have potential military applications. Selected programs
go through a development phase to reduce the risk associated with
technology innovation in a real-world environment. These include
Advanced Technical Demonstrations (ATDs).
Engineering is the iterative process of developing designs
that specify the form, fit, and function of assets. Alternative
designs are assessed to achieve the best balance of performance,
supportability, costs, and risk. Total asset requirements are
addressed including equipment, material, facilities, people, and
life-cycle support. Manufacturing requirements are considered
in the design process to ensure the ability to produce assets.
Resource availability (e.g., the labor pool), is also a key factor
in sound designs. The health of the industrial base and U.S.
competitiveness and ability to reconstitute are integral to the
engineering process.
Demonstration and test is the major control mechanism of the
Acquire Assets activity. Acquisition programs advance from one
phase to the next, and qualify for major new funding increments,
by achieving management and oversight thresholds, verified by
testing and evaluation. In the case of selected program designs,
prototypes are produced and demonstrated. These can be refined
until judged ready for production or program termination.
Produce Asset (A23):
This activity involves the actual building/manufacture, employment
through recruiting (accession), or buying/leasing of assets to
include all activities typically associated with bringing new
personnel, material items, real estate/facilities, or services
into the inventory (e.g., first destination transportation of
material items by the vendor from source of acquisition to point
of DoD distribution is included). This activity also includes
preparing assets for distribution to include any actions necessary
to ensure minimum essential asset usefulness at the point of receipt
(e.g., providing all military personnel with initial entry training
to produce useful officers and enlisted personnel).
The Build function manufactures, constructs, and assembles
assets. The process itself may be conducted by Government or
industry, or both. Sub-functions include the staging of materials
and other resources, set-up, fabrication, assembly, and quality
control of the process and the product.
Access is the function that enlists the skills and services
of people to satisfy the DoD mission. It includes the recruiting
of military personnel and the employment of Government civilian
personnel. In order to obtain a minimally useful individual,
all basic training and initial orientation are included in this
function.
Buy/Lease is the function that obtains commercially available
goods and services for the Department. It does not duplicate
the contract management functions described under Manage Acquisition.
Rather, it evaluates the adequacy of commercial products and
services against Government requirements and standards, accepts
delivery of assets, and evaluates the performance of commercial
items and services as they are used in the Department.
Figures 4.2.1-2 through 4.2.1-4 display the IDEF0 Activity
Models for the following activities: Manage Acquisition (A21),
Engineer (A22), and Produce Asset (A23).
These three figures (Figures 4.2.1-2 through 4.2.1-4) represent the proforma model. The business case team will decompose this proforma model to a level of detail necessary to describe the activities performed in support of the program. As shown in Figure 4.2.1-5, program activity information gathered as part of activity A1 is used as an input to extend the proforma model.
PMO personnel, using preparation tools such as BPWin and aided by prime contractor representatives if required, will extend the proforma model so it is representative of the activities that occur in support of the program. This extended model will be revised as necessary during baseline revision to form the Program/Project AS-IS Activity Model. It is important to note that the Program/Project AS-IS Activity Model can be considered a child to the parent DoD Enterprise Model from which it was derived. This Program/Project AS-IS Activity Model will be used to perform activity-based costing during Activity A24. In addition, the mechanisms identified will be used during activity A23. This process deals with the development and documentation of the relationship between the program's activities and the technical infrastructure that supports these activities.
"It was not so very long ago that people thought that semiconductors were part-time orchestra leaders and microchips were very small snack foods." - Geraldine Ferraro
The focal point of the IDE Business Case is the geo-technical
baseline. Identification of improvement initiatives to the geo-technical
infrastructure differentiates the IDE Business Case from other
traditional BPR and FEA projects. The geo-technical baseline
is defined as:
The Program/Project's technical foundation that consists of the existing technical infrastructure, location of the infrastructure, data exchange occurring within the infrastructure, and includes any approved changes.
The purpose of documenting the geo-technical baseline is to gain an understanding of how data are currently exchanged to support the program. Because the essence of the IDE idea is to "create data once, and use it many times," documenting the geo-technical baseline will not only drive out improvement initiatives for the IDE Business Case, but also identify performance metrics that will be used to measure the improvement initiatives. Only by gaining a clear understanding of current business practices with respect to data exchange, will the program manager and the BPR team be able to complete an IDE Business Case. All improvement initiatives for an IDE Business Case will be based upon improving data exchange in support of the program. In essence, therefore, an IDE Business Case is a subset of an overall program business case BPR project.
As shown in Figure 4.2.2-1, PMO personnel and prime contractor representatives, if required, will use preparation tools to document the geo-technical baseline. The PMO personnel will take the existing technical information gathered during Activity A1, including any approved changes to the existing technical infrastructure, to document the baseline. After the initial geo-technical baseline is completed, the baseline will validate any changes recommended as a result of the validation process will be considered.
The primary preparation tool used to document the geo-technical baseline is the Geo-Technical Baseline Tool. This database will capture relevant geo-technical information by prompting the user to enter the appropriate responses to the interface-generated questions. This information will be used to generate reports that document the geo-technical baseline. The Geo-Technical Baseline Tool is described in Section 5.0.
"Everything should be made as simple as possible, but not simpler." - Albert Einstein
Mechanisms are those resources used to realize the completion
of an activity. They represent objects (people, machines, etc.)
or energy that make possible the successful completion of an activity.
It is important to note that activities do not consume their
enabling mechanisms. Mechanisms are defined as resources (usually
people, machines, or systems) that provide energy to, or perform,
the activity.
By mapping the geo-technical elements or components identified during activity A22 to the mechanisms identified during Activity A21, the relationship among a project or program's activities, activity locations, and the technical infrastructure elements can be identified and documented. A clear understanding of these relationships is essential to the development and evaluation of technical infrastructure initiatives and alternatives. Further, this process will assist in identifying initiatives and alternatives that have no relationship to the technical infrastructure.
As shown in Figure 4.2.3-1, the program/project activity model, as well as the geo-technical baseline element information gathered using the Geo-Technical Baseline Tool, controls the mapping of the geo-technical baseline functions to the activities performed by the PMO in support of the program. This mapping will be performed by PMO personnel, aided by prime contractor representatives if required. The output of the activity is a cross-referenced resource map that relates specific geo-technical elements to the mechanisms that perform the activities identified by the program/project activity model. During validation, any changes to the geo-technical baseline or program/project activity model will be considered prior to finalizing the resource map.
"Accountants are the witch doctors of the modern world." - J. Harmon
Business Process Reengineering is the radical redesign and change
of current business processes and practices to achieve cost savings
and greater performance, and to gain higher product quality. To
ascertain the economic impact initiatives will have on a business
process, it is first necessary to gain an understanding of the
costs of performing current business processes. The methodology
used to ascertain the cost of AS-IS activities and TO-BE activities
is Activity-Based Costing (ABC). ABC focuses on the activity
structure of an organization, rather than on the traditional departmental
or organizational format. The process provides quantitative activity-based
cost information to
ABC includes the collection of financial and operational performance
information about significant activities of an enterprise. Activity-Based
Costing is defined as:
an accounting technique that allows an enterprise to determine
the actual costs associated with each product and service produced
by that enterprise without regard to the organizational structure
of the enterprise.
It is important to note that the above definition describes ABC
as a methodology that accounts for activity costs, rather than
for costs of enterprise functions. (An enterprise function includes
management, engineering, research, etc.) ABC is a relatively new
concept to aid management in determining the actual costs of producing
a product. However, the major difficulty in using the ABC methodology
has been the variance of the practices, methods, definitions,
procedures, and standards applied to the methodology. Further,
ABC requires professional judgment and creativity when applied
to a transitional DoD business process model. DoD has attempted
to mitigate these problems by developing an "Activity Based
Costing Guidebook," available from the Defense Electronic
College of Process Innovation.
The ABC methodology focuses on cost elements to perform activities. Cost Elements are factors of production and are the specific input resources to activities. (They are the activities' mechanisms.) Within the FEA Model, cost elements include military labor, civilian labor, information technology, facilities, materiel, and other.
As shown in Figure 4.2.4-1, PMO personnel, aided by prime contractor representatives if required, will utilize preparation tools such as EasyABC to produce the ABC baseline. The ABC baseline is developed by analyzing current workload and financial accounting information to attach costs from the cost element pools to the mechanisms associated with the activities identified in the program/project AS-IS Activity Model. Costs should be gathered and allocated within the organization at the lowest possible layer, normally the smallest element that has an assigned manager. The cost will be allocated from the element pools to the activity mechanisms within the program/project AS-IS Model, typically based upon interviews with managers in charge of the function or activity. Once costs are attached to activity mechanisms, they are entered in an activity cost worksheet, or entered into TurboBPR. It is important to note that the majority of cost associated with performing an activity may be labor. It is suggested that the FEA Guidebook be used when performing labor pool allocations to activities.
"It is not the end, it is not the beginning of the end. It is perhaps the end of the beginning." - Sir Winston Churchill
Validating the baseline model is the process of determining and correcting any deficiencies and inconsistencies to form a correct baseline model. Performing this activity tests and authenticates the documented ABC baseline, geo-technical baseline, and activity baseline, and proposes revisions to each baseline as required to form a true representation of the program's AS-IS business state.
Essentially this activity is performed as a "reality-check," to determine if the work completed thus far in the BPR effort makes sense. As can be seen by Figure 4.2.5-1, the program manager, together with subject matter experts if required, will review the geo-technical baseline, ABC baseline, program/project activity model, and resource mapping for reasonableness, completeness, accuracy, and materiality. Changes to any of the baselines, maps, or models proposed by the program manager or subject matter experts will be considered within activities A21 through A24. Once all changes to the baselines, maps, and models have occurred, the resultant is a validated Program/Project Baseline. This Program/Project Baseline describes the current "business state," represented by the ABC Baseline, Geo-Technical Baseline, Resource Map, and Program/Project Activity Model.
By performing the A2 Activity, "Establish Baseline," the BPR team will have, on an ad-hoc basis, identified areas for improving current business processes. The next section of this guidebook establishes the process for formalizing and documenting improvements to current business practices.
"The rule for staying employed as a program manager is to give 'em a number, or give 'em a date, but never give 'em both at the same time." - Anonymous
The third activity associated with preparing an IDE Business Case
is to develop alternatives. Alternatives are logical "packages"
of "initiatives." An initiative is some fundamental
change to the current business process that implements the program's
strategy to move the program toward the program's goal or imperative,
within the context of the program's vision and consistent with
the program's mission. The mission statement defines and justifies
why the program exists. The program's vision describes how the
program will achieve its mission in the future. Program goals
are those outcomes that the program will attain in meeting the
program's vision. A goal is the program's aim for achieving process
improvement with respect to a critical success factor, where critical
success factors answer the question, "What does it take to
fulfill the program's mission and achieve the program's mission?"
Development of critical success factors will drive out the performance
metrics used to measure the success of an alternative.
"Develop alternatives" is the process of identifying
how to achieve the program's TO-BE state (where the TO-BE state
is the program's target goal). This activity includes developing
an understanding of the TO-BE state, determining improvement areas
and developing implementation strategies to migrate to the TO-BE
state, assessing emerging relevant technologies that could be
used to achieve the TO-BE state, and identifying initiatives and
aggregating those initiatives into alternatives complete with
action plans to achieve the TO-BE state. Each alternative should
include some plan for moving the program toward its vision. The
"develop alternatives" activity consists of five sub-activities:
The following sections describe each of these subactivities.
"To know the road ahead, ask those coming back." - Chinese Proverb
To develop an IDE Business Case, the BPR team must gain a thorough understanding of the IDE vision incorporated within the DoD CALS initiative. The DoD is committed to incorporating CALS into functional process improvements. As DoD applies the best technologies, processes, and standards for the development, management, exchange, and use of business and technical information among and within Governmental and industrial enterprises, an IDE will be generated. The IDE is defined as the business environment created by the application of existing national and international standards, practices, and technologies to automate the management and exchange of information. The IDE directly enables Integrated Product and Process Development while increasing the agility and decreasing cycle times of the Defense Enterprise. CALS is founded on the recognition that affordable, readily accessible, and timely technical and business information is a critical element of the acquisition process.
As shown in Figure 4.3.1-1, PMO personnel, working with prime contractor representatives if required, will develop a common understanding based upon the program's goals and objectives and within the context of DoD's IDE vision. This common understanding will form the program's IDE vision. Once the program has formed its IDE vision, the BPR team will develop goals for achieving the vision. Initiatives, performance metrics, alternatives, and action plans will be derived from the program's IDE goals.
There is a multitude of information, handbooks, directives, etc., concerning the DoD CALS initiative, the IDE, as well as business case and FEA guidance. It is recommended that the BPR team perform searches of the DoD CALS Internet site, as well as the Electronic College of Process Innovation Internet site to obtain information required to gain an understanding of the DoD IDE vision.
"Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats." - Howard Aiken
Improvement opportunities are identified by the BPR team through brainstorming sessions. However, many of the seeds for these improvement opportunities were planted during the A2 Activity (Establish Baseline) while the BPR team was studying and documenting current business processes and costs. Improvement opportunities are driven by the outcomes of the initial strategic planning sessions discussed in Section 3.0. Strategic planning serves as the starting point for each BPR project, as well as the starting point for development of an IDE Business Case. The strategic planning outcomes include the program's mission and vision statements, as well as goals, performance measures, and strategies for achieving the program's IDE vision (TO-BE state). The program's mission statement should clearly state the purpose of the program. The program's vision statement should clearly state how the program will achieve its mission in the future, and functions to guide the program's action. For an IDE Business Case, the program's IDE vision will be developed within the context of DoD's IDE vision.
As shown in Figure 4.3.2-1, PMO personnel, aided by prime contractor representatives if required, will develop improvement strategies, as well as document any technical implementation issues that may arise as a consequence of an identified strategy. These improvement strategies will be based on the program's understanding of the DoD's IDE vision, as well as the program's own goals and objectives. It is important to note that identified improvement strategies must consider existing contractual obligations into which the program office has entered, for they may constrain the identified improvement strategy. It is also important to understand that improvement opportunities that are not dependent upon, or enabled by, IDE-related improvements should be considered individually and not be combined with IDE opportunities, for these opportunities tend to mask or over-state the true benefit of IDE improvements.
"Technological progress has often provided us a more efficient means of going backward." - Aldous Huxley
The fundamental purpose of the IDE Business Case is to provide
the decision maker with the comparative analysis for making investments
in the program's geo-technical configuration. Therefore, the
IDE Business Case is a subset of a full program business case
undertaken as part of a BPR project. The investments made in
the program's geo-technical configuration must support the activities
of the program by making the activities more reliable, cost-effective,
and timely. To this end, the team must gather, compile, filter,
and catalog information about technologies that may be used to
achieve the TO-BE state (where the TO-BE state is the program's
target goal). The team will then assess the technical feasibility
of the catalogued technologies to identify any existing and emerging
technologies that may be used to achieve the TO-BE state. Based
upon the previously documented strategies for implementing improvement
opportunities, the team will determine the applicability of any
existing or emerging technologies that can contribute to moving
current business processes toward the program's TO-BE State.
It is important to note that improvement opportunities that do not require technological improvements be implemented prior to performing new business-process automation. Non-value added activities should be eliminated from the program prior to considering technical improvements, as it is cost prohibitive to automate poor processes.
As shown in Figure 4.3.3-1, PMO personnel, aided by prime contractor representatives if required, will assess existing and emerging technologies that may provide technical solutions to move the program toward the IDE vision. Information about available technology and any implementation implications will be used to develop the technical solutions. The common understanding of the IDE, the program's baseline, as well as the technical feasibility of the solutions and any existing contractual obligations, that would preclude the implementation of the solutions, must be considered.
"To change and change for the better are two different things." - German Proverb
Initiatives are the projects that realize improvement opportunities.
They describe how the program will implement strategies (in terms
of specific actions, timelines, and resources) to move the program
toward the TO-BE state. Initiatives have results and consume
time and/or other resources. To identify initiatives, the team
must search for as many new and creative ways of doing business
as possible. Using the strategies developed and assessing the
applicability of existing and emerging technologies, the team
will identify and document initiatives that can be used to improve
current business processes by moving those processes toward the
IDE vision. Further, the team will determine the impact and assess
the risks of implementing the documented initiatives, and develop
cost estimates and action plans for implementing the identified
initiatives.
Initiatives are derived from improvement opportunities that may have been identified during the development of the program's baseline, as well as the strategies documented for moving the program toward the TO-BE IDE state. Initiatives are what needs to be done (actions) to move the program toward the TO-BE state. Initiatives are developed during brainstorming sessions by the team. The team studies current business activities to identify changes to activity Inputs, Controls, Outputs, and Mechanisms (ICOMS) that will implement at least one improvement strategy. Initiatives may also identify activities that do not add value to the program and should be eliminated or reduced. Once identified, initiatives will have cost information attached to them that reflect the resources required to implement the initiative.
As shown in Figure 4.3.4-1, PMO personnel, aided by prime contractor representatives if required, will use preparation tools (such as TurboBPR) to identify and document initiatives. The initiatives will be derived from potential technical solutions previously identified in activity A33 as well as relevant program/project information obtained during development of the program AS-IS business state. Identified initiatives will be based upon previously established improvement strategies (Activity A32) and will consider previous contractual obligations as well as the technical feasibility of the initiative. Any additional information required to document the initiative (e.g., cost data) will be obtained by the team.
"Anyone who says businessmen deal in facts, not fiction, has never read old five-year projections." - Malcom Forbes
The object of the IDE Business Case is to enable the program manager
to identify investments that will move the program toward the
IDE vision, yet an initiative may only consider a small area of
improvement. Moreover, a tremendous amount of identified initiatives
may be considered. Therefore, initiatives should be combined
and analyzed as groups. These "groups" of initiatives
are called alternatives, and consist of individually identified
initiatives that, when combined to form a set, will achieve a
program goal. These alternatives give the program manager a complete
view of the financial, operational, and schedule impacts of implementing
an alternative that will move the program toward the IDE TO-BE
state.
At least two alternatives, exclusive of the program baseline, should be produced. The team will create alternatives using an iterative process, combining different initiatives together until a logical set is created. Once an alternative is created, the team will develop action plans, cost estimates, risk assessment, and timetables for implementing the alternative. These plans, estimates, and assessments are derived from the individual ones created during development of each initiative.
As shown in Figure 4.3.5-1, PMO personnel will use preparation tools (such as TurboBPR and Easy ABC) to package alternatives and develop action plans for the alternatives from the initiatives previously identified in Activity A34. The team, when developing alternatives, will use the guidance contained in the IDE Business Case Model as well as the FEA Guidebook. Further, the team will consider any additional alternatives that the program manager deems appropriate.
"Great ideas need landing gear as well as wings." - C.D. Jackson
The last step in the preparation of an IDE Business Case is to package the results. This will entail preparing the IDE Business Case document for review, as well as preparing an executive summary for the decision maker. In addition, the team may be required to prepare presentation materials, such as overhead slides or interactive computer materials, that synopsize the highlights and findings of the business case.
As shown in Figure 4.4-1, PMO personnel will use preparation tools to prepare the IDE Business Case document. The business case document will be prepared in accordance with DoD guidance and will consider any templates or tools contained in the business case model. TurboBPR is an ideal choice as the tool for the preparation of the business case document. By utilizing TurboBPR's user interface, the team can enter the business case data directly into the tool. AS-IS program information and TO-BE program information are entered, TurboBPR produces a business case document that contains the following major components:
Once the Program/Project Business Case document is prepared, the
team will prepare an executive summary. The executive summary
describes for the decision maker the outcomes of the business
case, covering the main points succinctly. The executive summary
and the business case document complete the IDE Business Case.
The team may be required to prepare additional presentation materials that describe the business case for audiences other than the Program Manager. The team will assemble presentation materials and tailor them to the specific audience as required by the request. These materials may be handouts, summaries, tables, overhead slides, or interactive computer materials.
"All technology should be assumed guilty until proven innocent." - David Brower
The most defining characteristic of an IDE Business Case is that
it focuses upon changes to the program's existing geo-technical
baseline. This geo-technical baseline serves as the "launching
point" for IDE initiatives development. The geo-technical
baseline may be defined as follows:
The program/project's technical foundation that consists of the existing technical infrastructure, location of the infrastructure, data exchange occurring within the infrastructure, and includes any approved changes to the current infrastructure.
Documenting the geo-technical baseline is the process of identifying
and capturing the program's current technical infrastructure's
capabilities, and the distribution of those capabilities (including
planned changes) by geographical location. This process bounds
the baseline within the context of the IDE, which is a major difference
between the IDE Business Case and an FEA.
Documenting the program's geo-technical baseline can be a time-consuming
effort on the part of the BPR team. The team must develop an
inventory of the program's current hardware, software, location
of equipment, data exchange, etc. Moreover, the team must tabulate
and synthesize the inventoried information to form a true picture
of the current "data commutation" occurring in support
of the program so that the enabling mechanisms may be linked to
the geo-technical baseline. Therefore, a formal approach to documenting
the geo-technical baseline is required.
The Geo-Technical Baseline Tool (GTBT) is a conceptual tool designed
to assist PMO personnel in documenting and reporting the geo-technical
baseline while preparing an IDE Business Case. The conceptual
GTBT is based on an entity-relationship data model, shown in Figure 5.0-1.
As can be seen by the partially attributed data model, the team must gather and synthesize geo-technical information including site, capabilities per site, functions, mechanism, etc. It is recommended that an automated tool be developed to query PMO personnel, and automatically develop the geo-technical inventory necessary to establish the baseline.
"If you want to succeed you should strike out on new paths, rather than travel the worn paths of accepted success." - John D. Rockefeller
Much has been said and written on the subject of Business Process
Reengineering. A wealth of books, tools, case studies, benchmarks,
etc., is available to the program manager performing BPR, but
little guidance exists for the program manager faced with the
task of developing an IDE Business Case. This report has attempted
to bring many disassociated ideas and tools together to form a
"starting point" for IDE Business Case development.
However, much work is yet to be done.
The CALS IDE Shared Data Solution (SDS) Deployment Plan (Draft)
is a good example of how to meld the IDE idea into a weapon-system
program. Through the use of IDEF0 activity models, the program
manager can see, at a very high level, the steps to consider when
looking for solutions to shared data problems. Combining the
ideas of the SDS document with the ideas presented in this document
could be extremely beneficial to a program manager while developing
initiatives and alternatives to further the realization IDE vision
within DoD. It is therefore recommended that the CALS IDE
Shared Data Solution (SDS) Deployment Plan (Draft) be "married"
with the Business Case Model Acquisition Guidebook to form
an overarching plan for IDE Business Cases for a weapon system
program.
It is also important to continue to develop an automated tool for the documentation of the geo-technical baseline. Such a tool could aid the program manager in developing IDE-related initiatives, thus moving the program toward the CALS IDE vision. It is recommended that this tool be integrated with TurboBPR, thus automating many of the tasks required to perform an IDE Business Case.
A Concise Guide to the IDEF0 Modeling Technique, Hill/Robinson, 1995, Enterprise Technology Concepts Press.
CALS Integrated Data Environment Shared Data Solution Deployment
Plan (Draft), Director, CALS, 1995.
Business Process Reengineering, Johansson et. al., 1993,
John Wiley & Sons
DoD Enterprise Model, Volume II, Office of the Director
of Defense Information, 1994.
Functional Economic Analysis Guidebook, CIM, 1993.
CIM Process Improvement Methodology for DoD Functional Managers,
DoD, D. Appleton, Publisher.
Framework for Managing Process Improvement, DoD, 1994.
Business Process Reengineering Process Model, Version 3,
Office of the Deputy Assistant Secretary of Defense (Information
Management).
DoD Activity-Based Costing Guidebook, DoD.
User's Guide to TurboBPR, Version 2.0, 1995, Systems Research
and Application Corporation.
| Prepare IDE Business Case | The process of developing a business-decision document that will identify new methods of performing business activities implementing IDE strategies and concepts. It includes four major activities: gather information about current business process (A1 - Gather Information); document the AS-IS business state so that a baseline may be established (A2 - Establish Baseline); identify methods for improving business processes and bundle those improvement opportunities into viable and logical solutions (A3 - Develop Alternatives); and assemble the findings for the decision maker as an orderly and formal exposition (A4 - Package Results). The business-decision document is called an IDE Business Case and is defined as:
A business decision document that identifies alternatives and presents economical and technical arguments for implementing alternatives to achieve the stated business objective/imperative(s). It includes functional process descriptions, technical architecture descriptions, cost projections, action plans, measures of performance, and risk assessment for each alternative being considered. It is prepared from the perspective of the program manager, and its context is the IDE and the program's life-cycle. | |
| Gather Information | The process of accumulating the information necessary to prepare an IDE Business Case. It includes developing an information gathering plan; requesting, compiling and cataloging the information; and filtering the information necessary to form a baseline. The information gathering plan should identify what information may be required, where to obtain that information, who will obtain the information, and a timetable for obtaining the information. Many types of information may be identified for compilation, including financial and technical information, as well as information about current business practices. Other information, not previously identified, may be required as well. Finally, the information is gathered and compiled into logical units. | |
| Develop Information Gathering Plan | Using the business case model as a guide, identify information required, resources required, and sources of information by information type. Develop a plan of action and milestones for obtaining required relevant information. | |
| Compile Required Information | The process of assembling the required information by issuing data calls, receiving information responses, and cataloging and categorizing the received information. | |
| Filter Baseline Information | The process of reviewing the gathered data for reasonableness, completeness, accuracy, and materiality, and removing extraneous information that is not required to produce a baseline. | |
| Establish Baseline | The process of developing a validated program/project baseline. This baseline consists of the current business state, as well as any approved changes (AS-IS Model). It includes decomposing the proforma model activities, assembling a geo-technical baseline, mapping the geo-technical baseline functions to the activity baseline mechanisms, tracing costs to activities, and validating the baseline. | |
| Decompose Proforma Model Activities | The process of expanding the business case activity model to produce a program-specific activity model. The business case preparers will start with the provided proforma business case activity model. This activity model was derived using the Department of Defense (DoD) Enterprise Model, identifying activities within the DoD Enterprise Model that are within the context of the IDE, and decomposing those activities to a level just above program-specific activities. The business case preparers will take the proforma model and instantiate the model for their program-specific activities, so that activity costs may be identified. | |
| Document Geo-Technical Baseline | The process of identifying and documenting the current technical infrastructure's capabilities and distribution of those capabilities, as well as any planned changes to the technical infrastructure, by geographical location. (This process bounds the baseline within the context of the IDE, and is one major difference between an IDE Business Case and an FEA.) | |
| Map Geo-Technical Baseline Functions to Activity Baseline Mechanisms | The process of linking technical capabilities at geographical locations to the enabling mechanisms depicted in the AS-IS Activity Model. Performing this activity may drive out ideas for business process improvements. | |
| Trace Costs to Activities | Using financial and workload information, and considering the instructions found in the FEA Guidebook or TurboBPR, allocate organizational/locational costs to the activities identified in the program's AS-IS Activity Model. | |
| Validate Baseline Model | The process of determining and correcting any inconsistencies to form a correct baseline model. Performing this activity tests and authenticates the documented ABC baseline, geo-technical baseline, and activity baseline, and proposes revisions to each baseline as required to form a true representation of the AS-IS business state. | |
| Develop Alternatives | The process of identifying the TO-BE state and identifying how to achieve the TO-BE state (where the TO-BE state is the program's target goal). This activity includes developing an understanding of the TO-BE state, determining improvement areas and developing implementation strategies to migrate to the TO-BE state, assessing relevant emerging technologies that could be used to achieve the TO-BE state, identifying initiatives and aggregating the initiatives into alternatives, complete with action plans to achieve the TO-BE state. | |
| Understand IDE End-State | Study all available documentation on IDE to gain an understanding of what IDE concept is trying to achieve (DoD's vision), and develop a cognitive comprehension of the TO-BE business state (the program's implementation of the DoD vision). | |
| Identify Improvement Opportunities | Based upon a common understanding of the IDE, as well as the way business activities are currently performed, determine and document areas for improvement and identify improvement opportunities that move the current business processes toward IDE objectives. Develop strategies for implementing improvement opportunities through potential actionable changes of the program/project's business actions. | |
| Assess Technologies | Gather, compile, filter, and catalog information about technologies that may be used to achieve the TO-BE business state. Assess the technical feasibility of the cataloged technologies to identify the existing and emerging technologies that may be used to achieve the TO-BE business state. Based upon the previously documented strategies for implementing improvement opportunities, determine the applicability of any existing or emerging relevant technologies that can contribute toward moving current business processes toward the TO-BE state. | |
| Identify and Document Initiatives | Based upon the strategies developed, and assessing the applicability of existing and emerging technologies, identify and document initiatives that can be used to improve current business processes by moving those processes toward IDE objectives. Determine the impact and assess the risks of implementing the documented initiatives, and develop cost estimates for the implementing the identified initiatives. | |
| Package Alternatives, Develop Action Plans | Considering the decision maker's requirements, aggregate the initiatives into one or more alternative packages. Provide action plans, cost estimates, risk assessments, and timetables for implementing the packaged alternatives. | |
| Package Results | The process of incorporating the AS-IS information together with identified alternatives in a standard format for presentation to the decision maker. This also includes preparation of other presentation materials as required. | |
| Prepare Business Case Document | Using the business case model as a guide, assemble information into the provided standard format. Review information and make necessary documentation changes prior to presenting document to decision maker. | |
| Prepare Executive Summary | Describe for the decision maker the outcomes of the business case, covering the main points succinctly. | |
| Prepare Presentation Materials | Assemble presentation materials in response to a specific request and tailored to a specific audience and need. |
| Program Manager, SMEs | Those persons whose expertise is required to validate the baseline model. |
| ABC Baseline | The activity costs and product costs derived by taking existing financial accounting information, workload information, and geo-technical baseline information, and tracing the costs to perform the identified relevant activities. The workload information includes who performs activities and how often the activities are performed. |
| Activity Information | The list and categorization of the major activities performed during the program. |
| Approved Changes | Those hardware, software, firmware, etc., items that have been sanctioned for use by the program, but are not presently part of the current geo-technical infrastructure. These items are included, along with the current geo-technical infrastructure, to form the geo-technical baseline. |
| Available Technology Information | The current published existing and emerging relevant technology information that should be reviewed to determine its applicability to contribute toward moving current business processes toward the TO-BE state. |
| Business Case Activity Model | The proforma model, provided to the IDE Business Case preparer(s). This activity model was derived from the DoD Enterprise Model by identifying activities within the DoD Enterprise Model that are within the context of the IDE, and decomposing those activities to a level just above program-specific activities. |
| Business Case Need | The internal or external decision that a business case for the program/project, within the context of the IDE, will be performed. |
| Common Understanding | The documented program/project's IDE end-state and its objectives, based upon DoD guidance. Technological, managerial, as well as functional persons must agree on the functionality and configuration of the program/project's IDE end-state. |
| Contractual Arrangements | Those existing and pending agreements that must be considered when identifying improvement opportunities and developing initiatives. |
| Data Calls | The formal requests for additional information that are transmitted during compilation of the needed information, and performed after the information sources are identified. |
| Decision Maker's Requirement for Additional Alternative(s) | The prerogative of the decision maker to modify presented alternatives, or recombine initiatives into new alternatives based upon the decision makers expertise. |
| DoD Guidance | The published rules, imperatives, models, templates, and procedures for preparing an IDE Business Case. |
| Existing Technical Infrastructure | The documentation that describes the program/projects existing Hardware and Software systems, and the use of those systems to perform data exchange. |
| FEA Guidebook | DoD published guide that shows how to prepare an FEA through practical examples and illustrations. Used by functional managers in meeting their responsibilities to justify local technology investments. |
| Finalized IDE Program/Project Business Case | The completed business decision document, presented in a standard format, and inclusive of an executive summary. |
| Financial Accounting Information | Those documents that contain filtered financial information required to prepare the business case. |
| Financial Data Sources | Those persons, systems, and ledgers that contain relevant financial data for the preparation of the program/project IDE Business Case. |
| Geo-Technical Baseline | The program/projects technical foundation that consists of the existing technical infrastructure, location of the infrastructure, data exchange occurring within the infrastructure, and includes any approved changes. |
| IDE Business Case Model | The templates, spreadsheets, and presentation examples for preparing a business case. |
| IDE Program/Project Business Case | A business decision document that identifies alternatives and presents economical and technical arguments for implementing alternatives to achieve the stated business objective/imperative(s). It includes functional process descriptions, technical architecture descriptions, cost projections, action plans, measures of performance, and risk assessment for each alternative being considered. It is prepared from the perspective of the program manager, and its context is the IDE and the program's life-cycle. |
| Improvement Strategies | The scheme for bettering current business practices within the context of the IDE. These strategies are derived during the identification of improvement opportunities, and may be a plan to achieve the end goals. |
| Information Deficiencies | The lack of, or inadequacy of, program data provided to determine the AS-IS baseline. |
| Information Gathering Plan | The document that identifies what information is required, where to get it, and a timetable for acquiring the needed information. |
| Information System(s) | The computers and programs used to supply information to prepare an IDE Business Case. |
| Initiatives | The specific identified improvements (set of actions) derived from strategies and technology assessment. |
| PMO Personnel | Program Management Office personnel who will be involved in the preparation of the IDE Business Case. This may include subject-matter experts (SMEs). |
| Potential Technical Implementation Implications | The possibility that an identified improvement strategy may have some consequences to the technical infrastructure if realized. Those consequences must be addressed while assessing technologies. |
| Potential Technical Solutions | Those changes to the technical infrastructure that, if realized, will contribute to the efficiency of the activities identified for improvement within the improvement strategy. |
| Preparation Resources | All materials, items, manpower, etc., that may have a bearing upon the preparation of the IDE program/project business case. |
| Preparation Tools | The models, graphs, charts, templates, guides, and software packages used to prepare an IDE program/project business case. |
| Presentation Materials | The materials prepared in response to a briefing request to of the outcomes of the IDE Business Case, and tailored to a specific audience (stakeholders). |
| Prime Contractor Representatives | Those contractor personnel who will be involved in the preparation of the IDE program/project business case. |
| Program Data | The information specific to the program/project, obtained during the compilation of the raw technical, activity, and financial accounting information, and required to produce the baseline. |
| Program/Project AS-IS Activity Model | The result of decomposing the proforma model; the representation of the program/projects specific activities. |
| Program/Project IDE Alternatives | The aggregated initiatives, including cost estimates, risk assessment, and action plans produced in a common format using a common timetable. |
| Program/Project Information | The aggregate of raw technical, activity, and financial accounting information. |
| Programmatic Goals and Objectives | The specific program goals and objectives, within the context of DoD's IDE. |
| Proposed Baseline Revisions | Those corrections, identified by the PMO staff and SMEs, that may be needed to be incorporated into the baseline and occur during validation of the baseline. |
| Raw Activity Information | The unfiltered information about actions that occur in support of a program/project. May include information pertaining to what the action is, why the action is performed, who is the action performed by, how often the action is performed, and at what location(s) the action is performed. |
| Raw Financial Accounting Information | The unfiltered pecuniary information related to the specific program/project for which the business case is being prepared. |
| Raw Technical Information | The unfiltered features and uses of the current hardware and software systems. |
| Relevant Program/Project Information | The information that has a significant bearing upon the program/project, and consists of the filtered activity, technical, and financial accounting information. This also includes workload data related to activities. |
| Request for Additional Information | A formal request to gather specific information that may be required to formulate initiatives or to aggregate initiatives into alternatives. |
| Request for Presentation Materials | The formal request to prepare business case outcome presentation materials for a specific audience. |
| Resource Mapping | The arrangement and relation of technical activities to their mechanisms. |
| Technical Feasibility | The likelihood that a technical feature may be accomplished. |
| Technical Information | The filtered features and uses of the current hardware and software systems relevant to the program/project's IDE Business Case. |
| Validated Program/Project Baseline | The accepted representation of the program/projects AS-IS state, agreed upon by PMO and SME personnel. |
| Workload Information | The time-phased, expected, overall output of a functional activity. |
| ABC | Activity-Based Costing |
| ATD | Advanced Technical Demonstrations |
| BPR | Business Process Reengineering |
| CALS | Continuous Acquisition and Life-Cycle Support |
| CIM | Corporate Information Management |
| DDI | Director of Defense Information |
| DII | Defense Information Infrastructure |
| DISA | Defense Information Services Agency |
| DoD | Department of Defense |
| EC | Electronic Commerce |
| EDI | Electronic Data Interchange |
| FAR | Federal Acquisition Regulations |
| FEA | Functional Economic Analysis |
| FPI | Functional Process Improvement |
| FPIP | Functional Process Improvement Program |
| GTBT | Geo-Technical Baseline Tool |
| ICOMS | Inputs, Controls, Outputs, and Mechanisms |
| IDE | Integrated Data Environment |
| LCMIS | Life-Cycle Management of Information Systems |
| PMO | Program Management Office |
| PPBS | Planning, Programming, Budgeting System |
| SAR | Selected Acquisition Reports |
| SDS | Shared Data Solution |
| SME | Subject-Matter Expert |
| SOW | Statement of Work |