## Value Projection

I’ve often used the triangle model to illustrate value projection. In a recent discussion, I thought that a Shapely Value visualization would work. I ended up doing something else.

We’ll start by illustrating the triangle model to show how customers use the enabling software to create some delivered value. The customer’s value is realized by their people using a vendor’s software. The vendor’s software provides no value until it is used to create the value desired by the customer.

The gray triangle represents the vendor’s decisions that resulted in the software that they sold to the customer. The base of that triangle represents the user interface that the customer’s staff will use. Their use creates the delivered value.

The red triangle represent’s the customer’s decisions that resulted in that delivered value. The software was a very simple install and use application. Usually, configurations are more complicated. Other software may be involved. It may take multiple deliverables to deliver all the value.

Here we illustrate a more complicated situation where a project with several deliverables and another vendor’s product was needed to achieve the desired value.

When a coallition is involved in value delivery, Shapely value can be used to determine the value each member of the coallition should receive realtive to their contribution to value delivered.

Here I used a regular hexigon to represent six contributors that made equal contributions. The red circle represents the value delivered.

The value delivered is static, which is why I rejected this visualization. The effort involves multiple deliverables.

The next thing we had to handle was representing the factors involved in that value delivery. Those factors can be discovered by a factor analysis.

A factor analysis allocates the variance in the system to a collection of factors. The first factor is the longest and steepest factor. The first factor explains more variance than any of the subsequent individual factors. The second factor is shorter and flatter than the first factor. The second factor is longer and steeper than the first factor. The third factor is flatter and shorter than the second factor.

Even without the details 80 percent of the variance is covered by the first three factors. Additional factors can be found, but they become increasingly expensive to discover.

For our purposes here we will stop after the first three factors or after the first 80 percent of variance. We will allocate some of the delivered value to those factors.

Putting all of this together, we get the following visualization.

Here the vendor is at the center of the rings. The rings are organized by the project’s deliverables along the project’s timeline. The first ring represents the UI of the vendor’s application. The distance between this ring and the origin of the circle represents the time it took to deliver the UI. That UI incorporates the factors explaining the relative importance of the delivered elements of the software.  The white area in the vendor ring, adjacent to the purple factor represents the 20 percent of variance or importance that would be allocated to subsequent factors beyond the first three.

The gray rings represent the time gaps between the install. The second customer ring represents the efforts to configure the application. The third ring represents further implementation efforts. The customer’s efforts might involve using an API to extend the functionality of the application. This is shown with the orange and red segments. The extension is organized as a stack crossing the customer’s rings.

The radius of the circles represents time. That being the case, we don’t need the left side of the circles. Time starts at the origin and moves outward.

Different vendors could be represented with different rings, or some allocation of the existing rings. The vendors themselves have relative ranks relative to the delivery of the ultimate value.