Software can provide increased benefits to internal users, with the firm paying for the development or acquisition of that software. Software can also reduce costs to the users in exchange for the cost of development or acquisition of the software.
This exchange of benefit for cost is the basis of all business decision making where the governance of resources is in place. This governance process assumes there are limited resources - cost, time, capacity for work, available labor, equipment, and any other element that enters in the production of the output of the firm.
Any credible business needs capital to produce value. How much money, when will this money be needed, when will the money be returned - the breakeven date - and what will be the expected value to offset this capital expenditure are all probabilistic numbers for all projects - no matter the method used to develop the products or service that produce the value.
Benefits produced in exchange for this cost also include risk reduction, as well as increased revenue, and lowered cost. But again this risk reduction is in exchange for cost - money paid for reduced risk.
To determine that risk, the needed funding profile, the time line to break even, and the expected revenue to offset the investment requires we make estimates from start to end. This is standard Managerial Finance for all credible business ventures.
To determine benefits we can use a decision framework †
- Business scope - measures deliverable benefits in either cost or revenue.
- Value and Potential Impact:
- Improvement benefits — based on existing valuation tools or what if calculations.
- Scaling benefits — the total value of the associated business change resulting from the software acquisition and deployment.
- Risk reduction benefits — the expected value of the risks being mitigated.
- Future options — using Black-Scholes, Real Options, or Monte Carlo Simulation to determine future benefits.
- Project cost - assessments using standard project costing tools.
- Direct savings — through operational cost reduction.
- Real cash effective — netted off against direct savings.
Making Decisions in the Presence of Uncertainty ‡
It is better to be approximately right than precisely wrong - Warren Buffet
This quote is many times misused to say we can't possibly estimate so let's not estimate, let's just get started coding and we'll see what comes out.
Since all project work is based on uncertainty — reducible and irreducible — risk is the result of this uncertainty. So first we need to determine what is the Value At Risk before we can say how we are going to manage in the presence of this uncertainty.
Risk is a quantity that has relevance on its own. What's the risk that if I make this next turn on a Double-Black run in Breckenridge, there will be ice and I'll fall? Hard to say on the first run of the day, so I'll slow down as I come around the tree line. On the third run in a row, I've got the experience on that run today (a Reference Class) and the experience of skiing fast and hard on that run for several years (more details for the Reference Class) to know more about the risk.
Since statistical uncertainty drives projects, the resulting risk from that uncertainty is probabilistic. When interdependencies between work elements, capacity for work, technical and operational processes, changing understanding, and a myriad of other variables are also uncertain, we are faced with the problem. This problem is no deterministic assessment of time, cost, or capabilities can be performed for our project. We must have a probabilistic process. And of course, this probabilistic process requires estimating the range of values possible for each variable that interacts with the other variables.
Sampling from the past (empirical data) is a good way to start, but those past samples tell us nothing about the future statistical process unless the work in the future is closely matched to the work in the past. It is naive at best and dangerous at worst to assume the future is like the past. Such naive assumptions are many times the Root Cause of major cost overruns in our space and defense software intensive systems business. Those same naive assumptions are applicable across all software domains.
When there is a network of work activities - as there is on any non-trivial project - each activity is a probabilistic process. The notion of Independent work in the agile paradigm must always be confirmed before assuming simple queuing process can be put to work. So when you hear about Little's Law and Bootstrapping simulations, confirm the interdependencies of the work. The model in the chart below and the Probability Distribution Function below that is from a Monte Carlo Simulation, where the interdependencies of the work activities are modeled by the tool. In this case, RiskyProject that provides a Risk Register for reducible risks, the means of modeling the Irreducible uncertainty in the duration of the work, shows the coupling between the work elements Cruciality Index and other indicators of trouble to come from the status of the past performance.
The chart below says that the activity being modeled (and all the activities in the network of activities are modeled, I just picked this one), has a 54% chance of completing on or before Oct 18th, 2015.
The End
If your project is small enough to be able to see all the work in one place, see how to produce outcomes from all that work, and has a low value at risk, making business based estimates using risk reduction is probably not needed.
If you project has interdependencies between the work elements, the work is of sufficient duration you can't see the end in enough detail to remove all the statistical variances, and the value at risk is sufficiently high that the business impact of not showing up on time, on budget, with the needed outcomes will be unacceptable - then the process of managing in the presence of uncertainty must be able to estimate all the interacting variables.
It's this simple
- No risk, low impact for being wrong, low value at risk project — no need to worry about the future, just start and work out problems as you go.
But when we hear we don't need to estimate to make decisions and no domain and context is provided, those making that conjecture haven't considered the domain or context either. They're either unaware of the probability and statistics of projects or they're intentionally ignoring the probability and statistics of projects. Since they ignore these fundamental processes of all non-trivial project, ignore their advice.
‡ How to Measure Anything: Finding Value of Intangibles in Business 3rd Edition, Douglas Hubbard,
† A New Framework for IT Investment Decisions, Anthony Barnes,
