Value Networks

 and the true nature of collaboration

   

Chapter 2: Mapping the Value Network

Transactions and Deliverables

 

 

Transactions and Deliverables

In a value network map, a relationship is shown as a transaction, 

and what is moving between roles is a named deliverable.
A linkage or interaction between roles or participants in a value network is depicted by a one-directional arrow, called a Transaction. The transaction shows how a particular Deliverable moves between one role and another. The deliverable is shown by a label placed on the arrow.

This way of describing linkages and deliverables distinguishes Value Network Analysis (VNA) from other types of network analysis. Social network graphs deal with only a single type of tie between nodes, while VNA maps multiple unique ties between nodes.


In value network mapping all ties are treated as being distinctly different. So the transactions and deliverables in the value network do not tell us how relationships are alike - they tell us how they are different! Differences between relationships and networks help us understand the unique contributing roles that people play and how together they create value and achieve outcomes.


For more comparisons between VNA and Social Network Analysis see SNA/VNA/ONA in the Deep Dive chapter.

Transactions 

Transactions are represented by a one-directional arrow in the value network map. The arrow represents the directional movement of a deliverable from one role to another. Contrasted to roles, which continue over time, transactions are temporary and transitory in nature. Transactions have a starting point with one role and completion point with another role. (When there is a reciprocating transaction the two are called an Exchange.)

 

Deliverables 

Deliverables are the actual "things" that move from one role to another. (Technically this would be an attribute of the link.) A deliverable can be something physical such as a document or a chair. A deliverable can also be non-physical, such as a message or request that may only be delivered verbally. It is the "what" that is most important, not the form that it takes. 


As communication and Internet technologies reduce our dependency on paper and physical objects, physical forms are becoming less important. For example, software used to be delivered through a physical disc or CD-Rom but now it is more often downloaded directly from the Internet or even provided as a service (SaaS). The form has changed but the deliverable is still a software application. Here again it is important to think of technologies as enablers of different activities and focus first on the deliverables that are moving between roles.

Helpful questions to ask yourself about a deliverable

- Is this something that can actually be delivered?

- Can it move from one role to another?

- Is it a noun? Deliverables are nouns - not verbs or adjectives.

- Can someone be held accountable for this?

- How would you know it had been received?
Case Study: Procedure Scheduling in Healthcare project:
Defining deliverables
Note: The context for this case was shown on Value Network Mapping Basics.

After the roles were identified, Roles and Participants, transactions with tangible deliverables were mapped as green lines.
value network map of tangible transactions in a scheduling procedures in a healthcare organization
Figure 5 - Scheduling: Mapping transactions with tangible deliverables.
Then transactions with intangible deliverables were mapped as dashed blue lines, revealing the formerly unseen role of Surgery Coordinator and the real problem the group needed to solve.
value network map of scheduling procedures in healthcare
Figure 6 - Scheduling: Adding transactions with intangible deliverables.

 

Read more about deliverables in Tangibles and Intangibles.

This case study will be further developed in Sequencing.
The complete case study, Procedure Scheduling in Healthcare, is in the Case Studies chapter.
 

FAQs for transactions

Why can't we use a double-headed arrow to show multiple instances of the same nature?

Two-headed arrows are meaningless from the standpoint of actually managing something or conducting a useful analysis. A double-headed arrow only shows that there is some kind of relationship. It would not tell us the nature of the relationship, what the specific activities are, who is generating them, or where the activity actually ends.


Further, when we come to the time dimension, which is described by Sequencing, a double-headed arrow poses some real problems. Any two given deliverable events or transactions may not happen at the same time. There even may be several intervening activities between them.


Isn't this focus on transactions just another way of doing a process map or flow chart?

If we sequence a series of transactions and then pull out a particular string of activities, we would indeed have a series of steps that could be alternatively depicted as a flow chart. However, this whole-system VNA mapping approach allows us to see much more than just a single process.

 

A completed value network map shows how people and multiple processes interact with each other, interdependencies, and the different flow paths options. If you focus on a process you cannot see the dynamics of the whole system. For more on integrating VNA with processes see Process, Workflow, and VNA in the Advanced Analysis chapter.

FAQs for deliverables

A chair I understand as a deliverable, but isn't a message just information?

For purposes of the mapping technique we can think of organized and packaged information as a deliverable. For example, let's take the bit of information that "Your order has been received."

 

The "packaging" or delivery mechanism for that message might be in the form of a document, an e-mail message - or oral or spoken, maybe even non-verbal such as a nod of the head.

 

Even though a spoken confirmation might be non-physical, there is still a basic nature of the content of that message - that of "order confirmation." "Order confirmation" then is the deliverable.


But what if you have something that isn't either of these - like a service?

The same principle would apply to a service such as a massage or a haircut. There is still a basic nature of that service that can be described as a deliverable. Again be specific. It is not just a service, it is a particular kind of service such as "inquiry response," "reservation" "tax preparation," "massage," etc.


Doesn't it get confusing calling all these different things deliverables?

It is actually far less confusing in practice than one would expect. It is quite different from a "task" perspective or process mapping which tends to define events, not deliverables.

 

 

  

TOP OF PAGE

Next page: Tangibles and Intangibles