Parametric cost estimates are usually based on mathematical equations or models. Simple mathematical relationships such as linear and nonlinear regression are mainly utilized. Often they are based on historical data from like projects. Tools such as Excel can be utilized easily to fit these relationships. The biggest challenge is determining the relationship between the dependent and independent variables and their range of usefulness.
All engineers must make tradeoffs in the four domains shown in Figure. Good engineers follow a disciplined and structured approach when developing a product or system. Costing hardware, software, and integration requires an understanding of many MPTs and terminology, but few engineers have received this formal training. Once technical characteristics have been ascertained from the requirements, selecting the right MPTs is critical to accurately determining costs early in the development cycle and estimating realistic LCC.
The most common engineering cost analysis techniques are those often taught in engineering economy and include the time value of money.. The ability to conduct relevant economic analysis is key to technologically innovative solutions grounded in business reality.
Simulationbased costing has become the methodology of choice for estimating cost and schedule for large systems. Although complex and data intensive, SBC has tremendous utility in assessing risk and variability.
Because of complexity and technology, the costing of complex systems has become a tremendous challenge. Most cost estimators understand how to cost hardware and to a lesser extent software. However, we are still developing tools and processes for costing the integration and interfaces of complex systems. As engineers design and develop scale to larger and more complex systems, system of systems (SoS), and enterprises, our ability to determine costs becomes less relevant and reliable.
Depreciation is simply the systematic allocation of cost of a capital expenditure item over its useful life. In reality, depreciation is nothing more than an accounting charge that reduces the overall value of an asset, due to its depletion, for income tax purposes. Depreciation can be calculated with many methods. To demonstrate depreciation we shall present both the straight-line and the modified accelerated cost recovery system (MACRS) methods. MACRS is the most common for tax depreciation because, as the name implies, they allow for accelerated depreciation.
Straight-line depreciation is simply
where:
Dn = depreciation allowance in year n
I = cost base
S = salvage value
n = useful life of asset in years
Note that the cost base includes both the actual cost and the cost to put the asset into operation. The book value of the asset at year n can be expressed as
MACRS is used both for tax purposes and for internal accounting. It allows for the recovery of more costs early in the life of the investment. Depending on the type of asset, the Internal Revenue Service (IRS) allows for different cost recovery periods. A yearly depreciation rate is then multiplied by the cost base to determine the annual depreciation amount. Example 3.1 shows how the MACRS allows for earlier depreciation of assets when compared to the straight-line method. With the exception of this example, the details of MACRS depreciations are not presented because those rates are subject to change by the IRS.
Your small consulting company is evaluating a circuit board testing machine. The device costs $35,000 and the maker estimates that it will have a salvage value of $6000 after 5 years of use. Determine the annual depreciation using both the straight-line method and the MACRS method.
a. Straight-line:
b. MACRS: Under IRS guidelines (IRS, 2009), a circuit board testing machine would be classed as “high-technology equipment,” which as a 5-year recovery period. Thus, the equipment could be depreciated according to this schedule:
The ability to plan and evaluate economically major projects is a part of most large government agencies and engineering firms. Most agencies have guidelines and regulations to evaluate rationally proposed projects with regard to their economic feasibility. Almost all guidelines and regulations require that the benefits of the proposed project exceed the cost of the project. Because corporate investment in projects has serious consequences for the financial viability of a corporation, private-sector projects are often easier to evaluate than their public-sector counterparts. Corporate policies require rational and deliberate analysis of capital budgeting decisions before projects are approved. Corporate investment is different from government investment in major capital projects because corporate entities must also consider the source of funding. In many instances, the ability to finance a project (in lieu of the most economical alternative) determines its feasibility. In some cases, capital projects may be financed through corporate bonds or other vehicles. Invariably, when the project nears realization, financing will depend on borrowed money. The methodof financing must be considered in the corporate capital budgeting decision becausethis factor may determine the viability of the project.
It is important to understand that the economic evaluation of alternatives and the evaluation of alternative financing for a project are key to the viability of that project. Economic evaluation involves developing the cash flows representing the benefits and costs associated with the acquisition and/or operation of the system. The cash flow over the life cycle is often referred to as the economic cash flow. Economic analysis of a program or project should include the financing plan—the cash flow representing the incomes and expenses for funding the project.
The object of the economic evaluation is to select the most cost-effective alternative that will satisfy the stakeholder requirements. It may be to approve or reject a single project or a family of projects (i.e., a program). Thus, prior to performing the economic analysis, one must identify the alternatives. To analyze the investment under consideration, you need to collect stakeholder requirements and then establish a life cycle. For some agencies and types of projects, regulations govern the life cycle. For instance, most federal and state flood control projects have a life cycle of 50 years. A co-generation plant (a plant that produces steam for a customer and sells excess energy, perhaps as electricity, to another organization) may have a life cycle of 20 years. The life cycle should bear some relationship to the life of the product.
To determine whether a project is feasible, you must compare its rate of return to a minimum attractive rate of return (MARR) or the required rate of return for the project. The MARR should be greater than the rate of return one may obtain with roughly the same risk in another venture. A project should be feasible if its rate of return exceeds the MARR. Obviously, MARR has different implications for publicand private-sector projects.
In economic evaluations, project alternatives are analyzed with respect to their cash flow profiles over n periods in the life cycle. This type of analysis is usually shown in the spreadsheet format and will be referred to as cash flow schedules. The interest period is traditionally, but need not be, in years.
Once money is invested in a project, those funds are no longer available for investment. The term opportunity cost is the return that could have been realized by investing in the next best alternative, if defined, or another opportunity that becomes known after the decision is made. In general, the MARR reflects the opportunity cost of capital, the market interest rates for borrowing and lending, and the risks associated with the investment in the capital project. For public agencies, policies or regulations may specify the MARR.
For commercial for profit products, the benefit or revenue of a capital project is relatively easy to determine. The basic revenue is what you can sell the product for, the rental income it can produce, the depreciation or other asset available for tax credit, the rental cost to avoid by relocating staff, etc. For the co-generation plant, it is the steam revenue from the primary user, the revenue from the electricity sold to the grid, etc. For an office building, it is the rental avoidance as well as any rental income provided; both may include tax credits.
For public capital projects such as roads, dams, bridges, mental health, etc., the benefits may be harder to ascertain. For a flood control project, the expected benefits are the lack of property loss, lives not being disrupted, public facilities staying open, etc. The social benefits are more difficult to quantify.
The costs, on the other hand, are more easily quantified. Certainly all the capital costs (labor, equipment, materials, supplies, financing, etc.) in addition to the costs to operate and maintain the facility may be calculated. Finally, the most complicated cost may be the amount and type of financing involved. The amount will have a great impact on the cash flow analysis. Depending on the discount rate, the method of debt repayment may make the difference between a viable and a nonviable project.
Models are, by nature, simplifications of (and approximations to) the real-world. Errors can be introduced at each stage (as presented in Figure below):
Specification error. This is the difference between the behaviour of the real-world situation and that captured within the specification or intentions of the model (sometimes this individual part is referred to as “model risk” or “model error”). Although one may often be able to provide a reasonable intuitive assessment of the nature of some such errors, it is extremely challenging to provide a robust quantification, simply because the nature of the real world is not fully known. (By definition, the ability to precisely define and calculate model error would only arise if such error were fully understood, in which case, it could essentially be captured in a revised model, with error then having been eliminated.) Further, whilst one may be aware of some simplifications that the model contains compared to the real-life situation, there are almost certainly possible behaviours of the real-life situation that are not known about. In a sense, one must essentially “hope” that the model is a sufficiently accurate representation for the purposes at hand. Of course, a good intuition, repeated empirical observations and large data sets can increase the likelihood that a conceptual model is correct (and improve one’s confidence in it), but ultimately there will be some residual uncertainty (“black swans” or “unknown unknowns”, for example).
Implementation error. This is the difference between the specified model (as conceived or intended) and the model as implemented. Such errors could result by mistake (calculation error) or due to subtler issues, such as the use of a discrete time axis in Excel (when events in fact materialise in continuous time), or of a finite time axis (instead of an unlimited one). Errors also arise frequently in which a model calculates correctly in the base case, but not in other cases (due to mistakes, or overlooking key aspects of the behaviour of the situation).
Decision error. This is the idea that a decision that is made based on the results of a model could be inappropriate. It captures the (lack of) effectiveness of the decision-making process, including a lack of understanding of a model and its limitations. Note that a poor outcome following a decision does not necessarily imply that the decision was poor, nor does a good outcome imply that the decision was the correct choice. Some types of model error relate to multiple process stages (rather than a single one), including where insufficient attention is given to scenarios, risk and uncertainties.
A model calculates the possible values of variables that are considered important in the context of the decision at hand. Of course, this information is often of paramount importance, especially when committing resources, budgeting and so on.
Nevertheless, the calculation of the numerical values of key variables is not the only reason to build models; the modelling process often has an important exploratory and insight-generating aspect (see later in this section). In fact, many insights can often be generated early in the overall process, whereas numerical values tend to be of most use later on.
The process of building a model should force a consideration of which factors influence the situation, including which are most important. Whilst such reflections may be of an intuitive or qualitative nature (at the early stages), much insight can be gained through the use of a quantitative process. The quantification of the relationships requires one to consider the nature of the relationships in a very precise way (e.g. whether a change in one would impact another and by how much, whether such a change is linear or non-linear, whether other variables are also affected, or whether there are (partially) common causal factors between variables, and so on).
The modelling process should highlight areas where one’s knowledge is incomplete, what further actions could be taken to improve this, as well as what data is needed. This can be valuable in its own right. In fact, a model is effectively an explicit record of the assumptions and of the (hypothesised) relationships between items (which may change as further knowledge is developed). The process therefore provides a structured approach to develop a better understanding. It often uncovers many assumptions that are being made implicitly (and which may be imprecisely understood or incorrect), as well as identifying the assumptions that are required and appropriate. As such, both the qualitative and the quantitative aspects of the process should provide new insights and identify issues for further exploration.
The overlooking or underestimation of these exploratory aspects is one of the main inefficiencies in many modelling processes, which are often delegated to junior staff who are competent in “doing the numbers”, but who may not have the experience, or lack sufficient project exposure, authority, or the credibility to identify and report many of the key insights, especially those that may challenge current assumptions. Thus, many possible insights are either lost or are simply never generated in the first place. Where a model produces results that are not readily explained intuitively, there are two generic cases:
◾ It is over-simplified, highly inaccurate or wrong in some important way. For example, key variables may have been left out, dependencies not correctly captured, or the assumptions used for the values of variables may be wrong or poorly estimated.
◾ It is essentially correct, but provides results which are not intuitive. In such situations, the modelling process can be used to adapt, explore and generate new insights, so that ultimately both the intuition and the model’s outputs become aligned. This can be a value-added process, particularly if it highlights areas where one’s initial intuition may be lacking.
In this context, the following well-known quotes come to mind:
◾ “Plans are useless, but planning is everything” (Eisenhower).
◾ “Every model is wrong, some are useful” (Box).
◾ “Perfection is the enemy of the good” (Voltaire).
When conducted rigorously, the modelling process distinguishes factors which are controllable from those which are not. It may also highlight that some items are partially controllable, but require further actions that may not (currently) be reflected in the planning nor in the model (e.g. the introduction of risk mitigation actions). Ultimately, controllable items correspond to potential decisions that should be taken in an optimal way, and non-controllable items are those which are risky or subject to uncertainty.
The use of sensitivity, scenario and risk techniques can also provide insight into the extent of possible exposure if a decision were to proceed as planned, lead to modifications to the project or decision design, and allow one to find an optimal decision or project structure.
A model provides a structured framework to take information from subject matter specialists or experts. It can help to define precisely the information requirements, which improves the effectiveness of the research and collection process to obtain such information. The overall process and results should also help to improve communications, due to the insights and transparency generated, as well as creating a clear structure for common working and co-ordination.
