In a recent post titled #NoEstimates - Really? there was an interesting comment.
Clearly, the business value of any feature or project can not be known with much certainty in advance of it being implemented. Still, for the purpose of keeping the analysis simple for now, let’s table this issue for a bit.
This is not the case in a governance based organization or a Capabilities Based Planning organization, where the "valuation" of the resulting product, service, or purchased or built product is part of the planning process.
It's a "build to valuation"
Knowing - to some probabilistic level of confidence - what business value or mission fulfillment the project or product will produce is the core of any decision making process. Knowing the cost of the value is about making decisions, analysis of alterntaives, or assessing the trade space.
With the "estimated" value and the "estimated" cost for that value, a decision can be made in what is called "analysis of alternatives" in our software intensive domain.
Only by having both estimates - value and cost of acheiving that value, their most likely numbers and the probabilistic range of those numbers (measured usually in dollars), can we make that "analysis of alternatives," or "trade space" needed to Govern both the business and the project and products that enable the business to meet its goals.
&
So there are popular myths around the estimating of cost and value discussion, and a few that are just flat out bogus:
- We can't know the value of our outcomes, until they are done.
- Start with a Balanced Scorecard strategy approach, where you define the needed value of any work before starting, determine the estimated cost of achieving that value for the busines or mission and do the math of ROI = (Value - Cost) / Cost.
- No requirement can be confirmed to be correct until the software is complete and put to work.
- Read any - my favorite The Requirements Engineering Handbook - requirements management book to see if this makes any sense at all.
- This assumes - the myth that is - that those developing the software really don't know what done looks like in any units of measure meanigful to the decision makers. Requirements definition is the role of Systems Engineering. So if the developers can't know, maybe they need to the Systems Engineers. Don't have Systems Engineers? Now that's a different problem.
- All the Capabilities Based Planned and Requirements Management processes are based on assessing the value of those requirements before the product or service arrives.
- Assessing that value is part of all Systems Engineering process using Measures of Effectiveness and Measures of Performance.
- During the project's execution, Technical Performance Measures and their supporting Quantifiable Backup Data are used to assue that what is being built is meeting the needs of the customer.
- Making Estimates is a waste of time when we don;t know what the requirements are.
- This is true.
- But if you don't know what the requirements are, someone has to pay to find out. This someone is usually the customer. This is the basis of Agile, and it works.
- But someone has to pay.
- Even in the realm where the requirements are vague, there is hopefully some notion of what Capabilities are needed from the project or product.
- What are you going to do with the results of the project or the product when it arrives?
- How much are you willing to pay for those capabilities?
- Don't have the answers to some level of confidence? - Just set fire to the money now and save all the effort.
