Hot air balloons and helium balloons

They are all balloons! Using the right word is important for understanding!

The idea that a flow of value to users is at the heart of concepts such as #NotImplementedNoValue and #NoProjects. At the heart of the flow of value is a conundrum. That conundrum is entwined in three terms; price, cost and value.  These three terms are often conflated, despite representing very different ideas. When project teams or product owners use price, cost and value interchangeability they can easily make the wrong choices as they they lead value through the development or maintenance process.

Price is often equated to value. We have all heard “you get what you pay for.” As anyone that has had to bid for a project will tell you, price is a significantly more nuanced than a straight translation of value. Price is defined as the amount of money given in payment for something. Price can also refer to an unwelcome experience or condition required to achieve an end. The act of pricing is dance between what can be charged and the strategy of the seller (think Game Theory). I have heard sales people suggest that they price the first deal to get in the door in order to prove the value of their product or service; therefore the price of any individual transaction might not be directly related to value. All software transactions must be viewed across the life of the software and the life of the relationship with the provider.  Bottom line: Price of any individual transaction is only loosely related to value.

Cost is a “simple” concept. The use of the term simple is very tongue and cheek, as costs often include labor, materials, office charges, hardware, business changes and opportunity costs. In a commercial product, cost and price are connected by the margin. The discipline of having to maintain a positive margin over the long term mean you need to understand the relationship of cost to price and later value. Most internal IT organizations do not face the long-term discipline of the market, and often only have to manage labor costs, which can lead to poor behaviors. One example of poor practice is substituting labor for automation because automation has a higher upfront cost (resisting test automation software for example).

Value is defined on as ”relative worth, merit, or importance.” Value measures range from profit and revenue, to a relative measure based on the perception of what an individual or group will get from a service or product. To make matters more complicated, the perception of value changes based on context, which can affect what can be charged. For example, water has significantly more value to someone dying of thirst than a person sitting in their kitchen drinking a glass of water. Value can be seen as the interaction between factors that include global or organizational impact, individual benefit and the probability of use. Many people use cost and price as tools to help determine value.

Price, cost and value are related. Cost plus margin will always equal price for a specific transaction. Over the long run, pricing any specific transaction below the typical margin or at a loss may make strategic sense. Examples might include capturing market share or getting in the door. But in the long run, pricing too many transactions below cost is catastrophic. The link between cost and price is more tenuous, because even if measured using hard currency the amount of value is affected by perception. In order to pursue concepts like #NoProject or #NotImplemnetedNoValue you need to have a handle the nuances of price, cost and value so that you can understand and talk clearly about the value derived from each story, feature or epic. Falling prey to conflating price, cost and value will yield a conundrum that will impact the decisions we make about what to deliver and when.

Programming Note: We will dive into value in more detail on Thursday.



In classic economics, a price represents an equilibrium between supply and demand or value and scarcity. This suggests that there should be a close relationship between the estimate and the price. However, the difference between pricing and an estimate is the pricing strategy. Over the long term in commercial organizations the price must be equivalent to estimate plus a planned margin. In the short run for any specific account the relationship can be significantly more variable and nuanced. Pricing strategies work because IT sourcing markets are not perfect markets.

The classic equilibrium theory assumes absolutely free markets without barriers. Software development, operations or other IT staffing scenarios typically have several market imperfections (this is most true in the short run), which make pricing strategies effective. For example, a price to win strategy might be to price the work using lower margin (or negative) in order to get into an account, with price escalation in the longer term to get back to a planned margin. You can see this strategy in your local grocery store where prices are marked down to entice switching or stockpiling (stockpiling is useful to resist competitive pressures).

An estimate describes what sourcer thinks will be required to deliver the work, and therefore is an absolute based on what is known (and many times what is not known). The estimate is a step to a price, but only a step. The most basic formula would be:

 Price = Estimate * Planned Margin

The margin is a function of the pricing strategy. The equation could be enhanced (or complicated) by adding timeframes. In this model the estimate, unless new information is encountered (e.g. scope change, different resource costs, inaccuracies or process improvements), is a constant. That means that if the organization wants to change the price, they will need to change the expected margin or find other efficiencies. What should not happen is that a price change results in a command to change the estimate without some substantive rational.

In internal organizations, the relationship between an estimate and what is charged (charged back or applied to budget) is typically the same with the possible exception of an allocation of overhead. There is little need for an internal pricing strategy, as internal IT organizations are typically run as cost centers rather than as a business. In later articles we can discuss both the positive and mostly negative outcomes of this behavior.

In commercial IT (application development, support and operations), the price that ends up being charged or in the contract should be related to the estimate.  Related as modified by the pricing strategy being used to capture the business. Where there are market imperfections, such as high barriers to switching, that difference between the estimate and price is tilted toward the sourcer. Estimates are an input to the price, but only that – an input.