Project vs. Product

Continuing down the path of understanding the differences between contemplation of project vs product as the center of our software universe.

Here are a few pithy aphorisms:

  1. The resources expended during a project are the cost of the product created, not its value.
This is the biggest challenge for organizations that create software for their own consumption. Because they are not “sold” their “value” is somewhat intrinsic. Most organizations that build software for their own use equate the cost of the software and its value. This creates a problem in that the cost-value does not give you an appropriate measure to decide “how much we like” the product. In most investment strategies, “how much we like” the company or the property we are investing in is based on some relatively “real” metrics. Is the company growing, is it positioned well against its competitors, does their leadership have a good strategy, is the building the right size, is it located appropriately, is it’s construction durable and its design fit for our purpose. Some of those measures provides a means of making our buy-hold-sell decision – especially the ones that change over time. So what are those measures for a software product?
  1. Project is transactional, Product is valuable. (When the product is complete, the value transfers to the created product)
The project is a transactional vehicle through which cost accrues to a software product. The product only realizes value when through use, it provides some advantage to the business. This value can be understood if not always measured as the difference between the cost of doing specific business without that product versus doing specific business with the product. More on this line of thinking later.
  1. Projects purport to create value, that value is only realized through products.
In Eliyahu Goldratt’s “The Goal”, we learn that the manufacturing of a product is not sufficient to create value, it is only in the sale of the product that the manufacture “realizes” the value. The work to produce the product creates potential value, but not realized value. In the context of internal use software, the value is only realized when the software is installed and “used”. In fact, it is usage multiplied by time that is the equation for expressing the value of the software product, so long lived software products tend to be much more valuable than short lived ones.
  1. There is a transaction (project) to buy (install) or sell (sunset) a product (i.e. even turning off a product costs money).
Apart from the actual software product construction there are costs to configure, install, integrate, test, train/change, that are all considered “transactional”. Sometimes these costs exceed the cost of the software product itself. Moreover, when we want to sell (shutdown) the software there are similar transaction costs to remove integration, un-install, and potentially archive any data that the product was managing. Since turning off software produces no value (no sale proceeds) sunsetting a software product is a pure cost transaction.
  1. A product swap is a buy and a sell (i.e. the swap is not complete until you sell (sunset) the legacy product) – else it will continue incur operational cost.
When your project is to replace one software product with another, the project does not deliver all of the desired value until the old software is completely decommissioned. The operational cost of maintaining and supporting the legacy must be eliminated in order to fulfill the value proposition of the transaction. Projects that de-scope the sunset to complete within schedule and budget constraints leave behind a drag on the corporate bottom line. The executives that allow such scope reductions in order to plant a flag and declare victory (realize their incentives) should be fired. Executives that allow such incentives should be demoted.
  1. Products that are never unwrapped, cannot add value from the shelf/closet (i.e. if a new product is not adopted, it did not add the value that was created when it was installed).
A software product that cannot be adopted for any reason cannot realize any value. However you slice the voodoo (budget finagling) it doesn’t matter, there be bones buried here. The cost of incomplete projects is loss. The cost of successful delivery that fails to be adopted by the end user is loss. Sometimes the reason is that a vendor is acquired, a technology loses its appeal, the business goals shift out from under the delivery project faster than the project can follow, the company decides to defund the project, the actual application delivered is less fit for purpose than the users can withstand, and management does not have the stomach or stones to fix it or jam it down their throat. However we get to new software not in use – it is a loss.
  1. Value realized through products is devilishly hard to measure objectively. (i.e. it requires attribution of business revenue growth or operational cost reduction to specific product capabilities).

When a software product is adopted, there is always some essential change to business process around that adoption. The value realized from that adoption, is valued (all other variables holding equal) as business process prior(periodic revenue – periodic expense) – business process post(periodic revenue – periodic cost) * periods of projected product life. The problem with that statement is the assumption that all other variables holding equal. We all know that variables are, well, variable.  Moreover, if the value is realized through expense reduction, and that via operational efficiency (less human effort per dollar of revenue), in order to actually realize the reduction, there must be a body count.

No Comments

Post a Comment