Mobile Edition
Print
Get the Mag
Weekly Updates[ILLUSTRATION OMITTED]
When people in the Department of Defense think of resources from cost perspective, many naturally focus on the bottom line--that is, the overall monetary price of the system, product, or service. Others may consider the funding available to pay for the item or service. To the cost analyst, however, these numbers merely represent the final result in a long, arduous estimating process.
Cost analysis involves the use of engineering, scientific, and statistical methods to evaluate the likely cost of a specific item in a defined scenario. It is the application of quantitative techniques to estimate the development, production, and operation and support costs (that is, life-cycle costs) of new products or systems to assist top-level managers in determining the optimal use of resources and operating managers in making cost-effective decisions throughout the life cycle of a program. The resources that the cost analyst must consider are requirements, historical data, time, and people. Both individually and collectively, these resource considerations determine the quality of the resulting cost estimate.
Let's consider each resource and its impact to the work of the cost analyst.
Requirements (1)
In general terms, a requirement documents the need for a particular system, product, or service--what it should be or do. Said another way, a requirement is a statement that identifies a necessary attribute, capability, characteristic, or quality of a system or product in order for it to have value and utility to a user.
Requirements are typically classified into one of two categories:
* Functional requirements describe the task or function that the system is to execute (for example, processing data or modulating a signal). They are sometimes known as capabilities.
* Non functionalrequirements confine the solution. They are sometimes known as constraints or quality requirements. Non-functional requirements can be further classified according to whether they relate to performance, maintainability, safety, reliability, or many other factors.
In theory, though often not a reflection of reality from a cost-analysis perspective, a good requirement should possess the following qualities:
Necessary--Something that must be included because other system components will not be able to compensate for its absence (for example, an important element of a system).
Unambiguous--Susceptible to only one interpretation. For example, stating that user training on a system will be required without defining a specific training approach (formal classroom, distance learning, CD-ROM, over-the-shoulder, etc.) can have a significant impact on how such costs are estimated in addition to the magnitude of the costs themselves (for example, thousands versus millions of dollars).
Concise--Stated in declarative language that is brief and easy to read, yet conveys the essence of what is required. Using excessive text, figures, and/or graphics to describe a simple process or procedure often does not benefit, but merely serves to confuse the cost analyst. In the words of English critic, essayist, and reformer John Ruskin: "Say all you have to say in the fewest possible words, or your reader will be sure to skip them; and in the plainest possible words or he will certainly misunderstand them."
Consistent--Does not contradict other stated requirements, nor is it contradicted by other requirements. Consistency necessitates the use of terms and language that mean the same from one requirements statement to the next.
Complete--Preferably stated entirely in one place and in a manner that does not require the reader to look at additional text to understand the basic requirement. References to other sections in a requirements document, supporting appendices, or even external sources can hinder the estimating process by adding unnecessary time and effort for review.
Reachable--A realistic capability that can be implemented using the available resources (both time and money).
Verifiable--Ability to determine that the requirement has been met through one of four possible methods: inspection, analysis, demonstration, or test.
The basic document that incorporates a list of requirements is known as a Requirements Specification or a Business Needs Specification. This document contains a full range of user, system, and/or functional requirements. It also may incorporate management, programmatic, and schedule requirements. To the cost analyst, this takes the form of the Cost Analysis Requirements Description, or CARD, as submitted by the Program Management Office. Project stakeholders (direct or indirect users, managers, operational staff members, support staff members such as help desk, testers, developers, engineers, and maintenance professionals) are all official sources of requirements. Furthermore, it is a responsibility of these individuals to provide, clarify, specify, and prioritize requirements.
Cost analysts can offer opinions on the quality of requirements as they pertain to estimating program costs and help to improve their definition; however, cost analysts ultimately are not responsible for generating requirements. As such, the quality of the cost estimate is essentially in the hands of others. Requirements that are stable and well-defined generally result in more accurate estimates. Requirements that are unstable, subject to frequent change, or ambiguous often lead to less accuracy.
In the end, the quality of the estimate, whether good or bad, is not known until well into the development process. This is why it is important to have sound requirements up front. There are all too many examples in industry, in general, and the Department of Defense, in particular, where ill-defined or changing requirements have resulted in underestimated costs that subsequently necessitated the application of additional resources (that is, funding and/or people) to remedy the situation.
Historical Data
In general terms, data are numbers, words, images, etc., that are accepted as they stand. For cost-estimating purposes, historical data typically include but are not limited to monetary expenditures to date, purchase invoices, warranty and leasing agreements, staffing and support profiles, and labor rates.
If requirements are the backbone of a sound cost estimate, then cost data are the lifeblood. Data can allow the cost analyst to understand better the nature of prior costs and cost efforts and to predict future ones. These data need not be limited to cost, but also may include performance and schedule data. Within the Department of Defense, contractor and in-house government technical databases and reports are excellent sources of data. These include Earned Value Management Reports, Contractor Performance Reports, Contractor Cost Data Reports, and Software Resource Data Reports. Priced Bills of Materials (that is, contractor-negotiated prices) and Contract Funds Status Reports also may be the source of useful information.
Ultimately, for data to be useful to the cost analyst, it must be actual, that is, not altered or corrupted in any way. Data must also be consistent, timely, and complete. As English biologist Thomas Henry Huxley noted: "What you get out depends on what you put in; and as the grandest mill in the world will not extract wheat-flour from peascods, so pages of formulae will not get a definite result out of loose data." This statement is all too true in the field of cost estimating.
Finally, existing data must be made available to the cost analyst. Often data on a particular system or product is not collected during the development process or, if collected, is not properly documented, consolidated, or maintained. This results in a tremendous loss of opportunity to support the estimating process, as past cost performance often is a good predictor of future cost.
Time
Contrary to what some may believe, cost estimating does not simply involve inputting of information into a "black box," turning a handle, and instantly generating results. It takes time to review, understand, and refine requirements; collect and analyze data; generate the actual cost estimate; perform risk and uncertainty analyses (that is, to try to statistically bound the estimate); and document the results. Figure 1 depicts the typical steps in the cost-estimating process as a wheel in order to illustrate that the entire process is continuous. These steps also may be tailored based on the needs or the scope of the project.
Even this process, however, does not necessarily take into account the impact of change in the estimating cycle (additional/modified requirements, increases/decreases to project scope, etc.); internal work constraints on the analyst (leave, travel, training, etc.); and the need for periodic management reviews throughout the estimating process.
In addition--and unfortunately for the cost analyst--more time often is wasted waiting for input from others than on the estimating process itself.
For instance, the refinement of requirements and cost documents typically is an iterative process. Transition of a rough draft to a final product can easily span several weeks, if not months. In some extreme cases where the program or project is subject to significant change, the process can take more than a year. In today's environment of ever-varying and ever-expanding user needs and wants, these cases are becoming more frequent.
Automated tools (Microsoft[R] Excel, Automated Cost Estimating Integrated Tools, Crystal Ball[R], etc.) and time-honored techniques can certainly assist the cost analyst and help to speed up the estimating process. Organization and proper planning can limit the effects of unscheduled delays. Ultimately, however, sound and thorough analysis cannot be rushed. Perhaps this notion can best be summed up by British author Franklin Field: "The great dividing line between success and failure can be expressed in five words: I did not have time."
FEED