In any discussion of project management, software development, and business management, agreeing on a shared set of definitions is critical por progress in exchanging ideas. When standard definitions are redefined to suit the needs of those conjecturing a new approach, it makes it more difficult to have a meaningful conversation.

One recent example is the No Estimates advocates redefining the meaning of estimate and forecast. Where forecasting is NOT estimating, so the No Estimates moniker can be applied to what is essentially estimating,

- Estimate: a human judgement derived estimate
- Forecast: a data driven forecast

First let's look at some definitions of Estimate as applied to project and program work. The estimate is applied to something. Cost, Schedule, some technical performance parameter. So we can't just use Estimate by itself. It needs to be an estimate of something. Here's some things we can estimate and the processes of performing those estimates on projects that involve uncertainty. If there is no uncertainty in the project the need for estimating goes away. Just *observe* the empirical data and calculate the needed value - cost, schedule, or technical performance.

**Analogy Cost Estimate**- An estimate of costs based on historical data of a similar (analog) item.**Ball Park Estimate**- Very rough estimate (usually cost estimate), but with some knowledge and confidence. (“Somewhere in the ball park.”)**Budget Estimate**- a Cost estimate prepared for inclusion in the budget to support projects funding.**Cost Estimate**- A judgment or opinion regarding the cost of an object, commodity, or service. A result or product of an estimating procedure that specifies the expected dollar cost required to perform a stipulated task or to acquire an item. A cost estimate may constitute a single value or a range of values.**Cost Growth**- A term related to the net change of an estimated or actual amount over a base figure previously established. The base must be relatable to a program, project, or contract and be clearly identified, including source, approval authority, specific items included, specific assumptions made, date, and the amount.**Cost Model**- A compilation of cost estimating logic that aggregates cost estimating details into a total cost estimate.- Engineering Cost Estimate - is derived by summing detailed cost estimates of the individual work packages (tasks, sprints, iterations, defined
*packages*of work that produce a single useable outcome)and adding appropriate burdens. Usually determined by a contractor’s industrial engineers, price analysts, and cost accountants. **Estimate at Completion**(EAC) (Cost) - Actual direct costs, plus indirect costs or costs allocable to the contract, plus the estimate of costs (direct and indirect) for authorized work remaining.**Long Range Investment Plans**- are broad plans based on best estimates of future top-line resources that form the basis for making long-range affordability assessments of products or services produced by the project.**Manpower Estimate**- An estimate of the most effective mix of direct labor and contract support for a project.**Parametric Cost Estimate**- is a cost estimating methodology using statistical relationships between historical costs and other program variables such as system physical or performance characteristics, contractor output measures, or manpower loading.**Project Office Estimate**(POE) - is a detailed estimate of development and ownership costs normally required for high-level decisions by the business. The estimate is performed early in the project and serves as the basepoint for all subsequent tracking and auditing purposes.**Should Cost Estimate**- is an estimate of the project cost that reflects reasonably achievable economy and efficiency during the development and operational phases of the product or service.**Standard Error of Estimate**- is a measure of divergence in the actual values of the dependent variable from their regression estimates. (Also known as standard deviation from regression line.) The deviations of observations from the regression line are squared, summed, and divided by the number of observations.**Technical Performance Measurement**(TPM) - describes all the activities undertaken by the buter to obtain design status beyond that treating schedule and cost. TPM is the product of design assessment that estimates the values of essential performance parameters of the current design as contained in Work Breakdown Structure (WBS) product elements through tests. It forecasts the values to be achieved through the planned technical program effort, measures differences between achieved values and those allocated to the product element by the Systems Engineering Process (SEP), and determines the impact of these differences on system effectiveness.

**So now to the killer concept**

If the project you are working has no uncertainty and therefore has no resulting risk, the need for estimating is greatly reduced of not eliminated. If there is uncertainty and resulting risk, then Tim Lister has something to say...

So no Uncertainty, No Risk, No need for Risk Management, low if any need for estimates of the outcomes of the decisions made the project participants.

Can This Really Be True?

Ask if your project has NO uncertainties? Nothing in the future that is unknown at the moment. No process that has any variance, in the past, now, or in the future. Nothing is going to change. All the work will run at the same efficiency as it does now. No defect will appear. No changing performance behaviors as the result of new development.

A bit about uncertainty. There are two kinds. Reducible and Irreducible. Reducible uncertainty is event based. That is there is a probability associated with the uncertainty coming true. For example *there is q 30% probability of rain today over the forecast area.* This is an event based uncertainty. To protect yourself from this uncertainty, depending on where you live, bring a rain coat.

There is irreducible uncertainty. This is the naturally occurring variances in the underlying system of interest. For example, I drive to the airport every Tuesday morning every other week to work at a client site. There is Reducible uncertainty around the weather. I'll look at the weather report to see what is going to happen. But given the weather, there will be an impact on the traffic. Snow or Sleet will have a different impact than rain or sunshine. This impact is a variances in the traffic flow which I have no control over. The only *protection* for not missing my flight is to have sufficient time *margin* in the drive. On a clear day, not traffic, no other impediments, it's 45 minutes from driveway to my favorite parking spot on east side of DIA, Level 1. Margin is applied depending on the events and underlying processes of travel.

So when the term Estimate and its related term Forecast are redefined so estimating is not seen as estimating, it *pollutes* the conversation. This conversation is critical to increasing the probability of success of projects in all domain.

- Estimates are about the past, present, and future - an estimate of the numberBrachiosaurus that walked on the
*beach*on what is now called Dinosaur Ridge in Morrison Colorado. Or the Estimate of the number of cars on E-470 headed to Denver International Airport. Or the estimate to complete for the lane expansion on CO-36 between Boulder and Denver. - Forecasts are about the future - a weather forecast.