Use a budgetary estimate when you need a higher level of confidence (reduced uncertainty) for project planning. In a budgetary estimate, the process requires a level of knowledge that can be achieved in a business process definition. The business process definition is modeled, documented, and analyzed to include human and system tasks, general user interface functionality, system integrations, key performance indicators, and reporting requirements.

Although not all requirements are known at this time, you have enough detail to support assumptions about the level of complexity and scope to write an estimate that can be used to secure funding, plan a schedule, and allocate resources. The level of detail you need can be attained from the Blueworks Live process modeling artifacts documented and analyzed in process discovery during the weeks leading up to Playback 0. This type of estimate typically involves the BPM analyst or BPM solution architect working alongside a BPM project/program manager to complete a budgetary estimate template.

When we create a budgetary estimate too soon in the project without the necessary input, we risk causing more harm than good. The budgetary estimate requires a specific level of knowledge and detail about the process. Attempts to produce a budgetary estimate without the necessary input only results in making too many assumptions. These assumptions broaden and hide uncertainty. The real danger comes in presenting a budgetary estimate without making the uncertainty transparent. A budgetary estimate can also be dangerous if it is produced at the start of the project and is not refined after more knowledge is discovered and documented.

These other elements should be quantified based on experience. If you do not want to break down each of these elements, setting other activities and change at around 50% of the core construction value and planning developers at 80% productive results in a likely implementation of 12 weeks with four developers. Although it is ideal for the budgetary estimate to be less than the ROM, often what is discovered is more than what was initially set for the ROM.

Unlike the ROM estimate, this technique applies additional knowledge related to complexity and scope of each of these elements.

The budgetary estimate also includes accounting for the cost and schedule of those aspects of the project not directly accounted for in the solution artifacts. Some of these activities might span multiple projects and be managed at the program level, but must be paid for by project budgets.

Real-life process implementation never executes exactly as planned because of uncertainty in the original plan. Uncertainty comes from ambiguity in subjective estimates prone to human error.

Uncertainty also stems from the variability arising from unexpected events or risks.

When you create a budgetary estimate to charter a new project and attain funding, it is important to recognize the uncertainty in the estimate. You accomplish this task using optimistic and pessimistic multipliers to give you a cost range in which the project most likely falls. These multipliers allow you to plan a project budget, schedule, and staffing plan with contingency recommendations.

The concept of applying optimistic and pessimistic multipliers is not new in agile software development or BPM. This technique can be traced back to Program Evaluation and Review Technique (PERT) analysis and Critical Path Method (CPM) more than 60 years ago. Historic data on estimating projects suggests that you are more likely to underestimate than overestimate. An optimistic multiplier ranges between 0.5 and 0.75, and a pessimistic multiplier ranges between1.5 and 3. Use multipliers that match your confidence in the amount of uncertainty. If your budgetary estimate is 1500 hours and you are confident that you have a fair understanding of the level complexity and uncertainty, use an optimistic multiplier of 0.75 and a pessimistic multiplier of1.5. Our budgetary estimate gives a 55 - 65% confidence interval that implementation falls between 1125 hours (0.75 x 1500) and 2250 hours (1.5 x 1500).

Calculating an estimate: With statistical analysis, you can use the standard deviation of a PERT distribution to calculate an estimate for planning purposes. The PERT distribution uses most likely, optimistic, and pessimistic values.

A PERT+0 estimate is close to the most likely estimate and is appropriate for planning a project without contingency (50% probability based on normalized data). The PERT+1 value is used for planning out a project with contingency (68% probability of falling within one standard deviation). The PERT+2 value is used for budgetary procurement (90% probability of falling within two standard deviations) and assumes change as part of the effort.

You should not necessarily propose funding and schedule around the pessimistic implementation estimate (2300 hours in the previous example). You might seek a budget for a rounded PERT+2 value (such as 2000 hours). You then prepare to actively manage the scope to keep the project within schedule and cost constraints around 1800 hours, saving 200 hours for additional implementation costs and schedule contingency. You can expand the budgetary estimate to use this same model for estimating elements mentioned around shared resources and their activities to come up with an all encompassing budgetary estimate.