Since all variables on all projects are random - cost, schedule, and delivered capabilities, in the economics of projects, the chance of being wrong and the Cost of being wrong is the expected opportunity cost. When we write software for money, we are participating in the microeconomics process of decision making based on information about the future:
- What value will be returned in exchange for the cost to produce that value? This value can be tangible - revenue from the sales of our product, revenue from the efforts produced through our contracting firm to our client, cost savings to the internal IT operation, increased sales from our ability to be faster and better than our competition, or intangible value in some broader sense - a public good for example.
- What is the cost to produce that value? This cost is almost always tangible. Money spent over some period of time.
Information is needed to assess both the cost and the value in order to DECIDE what to do. The formula for the value of this information can be mathematical as well as intuitive.
We make better decisions when we can reduce uncertainty about those decisions. Knowing the value of the information used to make those decisions is part of the microeconomics of writing software for money.
If we are uncertain about a business decision, or a decision for the business based on technology, that means we have a chance of making a wrong decision. By wrong it means the consequences of the alternatives cannot be assessed and one chocie that might have been preferable was not choosen. The cost of being wrong is the difference between the wrong choice and the best alternative.
In order to make an informed decision we need information - as mentioned above. This information itself has uncertainty, and therefore most times we need to estimate the actual numbers from the source of the information:
- How much will it cost? Good question. Can't really tell unless we have a firm fixed price quote from a vendor. Cost is not the same as budget. We might be able to fix the budget, but cost is always varaible in practice. We can stop when cost reaches budget, but then there is a chance we're not done - we have an incomplete deliverable, missing needed features.
- What value will be produced? Good question. Can't really tell unless we have revenue from the same product or similar products, or have price quotes from our competitors for the same product we are trying to sell.
- How long will it take to produce a value producing outcome? Good question. Can't really tell since we haven't done this before.
These questions and their answers are critical to the successful operation of any business, whose fundamental principle of operations is to turn expense into revenue. Since the variables involved in our projects are actually random variables, we'll need to estimate the answers, leaving the bigger question unanswered to date...
Can we make decisions without estimating the future impact on cost, schedule, and performance or that decision?
Gather information in support of decision making is decision risk reduction. The desire to reduce risk is good business practice. The decision maker needs information about the behaviour of the random variables involved in the decision making process. These must be estimated before the fact to make a decision about the future.
To develop the needed estimates we need a Basis of Estimate process, which means building the estimates from Reference Classes, parametric models, or similar cardinal based processes that have calibrated in some way. The Ordinal (relative) estimate are not credible. This removes the ill conceived notion that estimates are guesses.
† Extracted from How To Measure Anything, Douglas W. Hubbard.
