Infosys | Microsoft

Typically we always have a core set or group of people we interact with in day to day work. The group may change for different roles that we play that themselves depend on the duties we perform. A group could be one that we ourselves formed or were made part of and is kind of a default group for that particular role that we play. For e.g. I may have a UC group for the UC initiatives that I am part of. I can be part of another group that focuses on Collaboration and so on. So how are the groups distinctly identified? From the focus area that they are driving - more generically, there is a 'context' that each group has and is identified with. We closely identify people in a group under that context - be it UC, Collaboration, web programming, pre sales, marketing etc. However that same person may be associated in a totally different context by a third person. For e.g., I will be identified in the UC context by a peer in the UC group while I will be identified in the manager context by some one who reports to me. Thus, 'context' is very something very individual to a particular person and it can help identify people connections for that individual. However, for a context to be helpful in such a way, it should be available when the decision to match and generate possible contextual connections is being made. That means that the business context under which we work needs to be understood, stored and shared. This is extremely critical. Another critical part is the mode of communication that you use to actually reach a contact if the contact is actually available and willing to be invited to a conversation / chat.

Thus, our connections can be grouped into 3 sets:
 - A Workspace Contact Set that consists of people and/or groups that we are directly part of - You either created these groups/contacts yourself or were invited to be a contact.
 - A Contextual Contact Set that consists of people and/or groups that are related to the work we are doing - Your work/business context helped to arive at these connections.
The two above are mutually exclusive. There is a third group and that is:
 - A 2nd Degree Contact Set that consists of contacts of your contacts. These are people not in your Workspace set or Contextual set. However they could be contacts of people in your Workspace and/or Contextual sets. A lot of social networking sites use this paradigm today to build connections. Sites which excel in this are building huge bases of registered members who derive real benefits from the possibilities these sites have to offer.

Now, let us revisit the questions that we raised at the beginning of this blog:
 - Q: I have a problem. Who can help me solve it? Answer - your problem becomes a very specific embodiment of your general context. This along with your generic context can help identify people matches, that is, people who are doing / have done similar work or resolved similar problems.
 - Q: I would like to know if there are any people in my organization (or partner organizations) who are doing work on lines similar to mine. Answer - again, your context.
Obviously, the Contextual Contact Set is a powerful paradigm. However it is not the only way to build context based connections. Your Workspace Contact Set can help you directly connect with people you may be interested in connecting to - the 2nd Degree Contact for e.g.
 - Q: I have a contact. Is she available right now? What is the best way to reach her? Answer - this is more in the realm of unified communications. You would need to know if the contact is available (presence) and willing to be contacted for a chat / video call right now. If not so, you may need to know of a more non intrusive way of reaching her.

So, how does this all translate to business benefits? Let me take a brief example to illustrate.Consider the role of an insurance underwriter who evaluates incoming insurance policy applications. The underwriter's job is to arrive at a risk profile of the policy applicant and give a decision on the policy: not granted, granted or granted with conditions. For this, the underwriter needs to look at a lot of information from a lot of different places (which is a topic for another post, integrated contextual information being another imperative for a Collaborative ecosystem). The underwriter also needs to connect with people to assist him/her with parts of the application. These will be in the underwriter's Workspace Contact set. Though underwriting is a well defined workflow in the insurance industry, there are times when the encoded business workflows may not help due to some peculiar characteristics of the policy application. This may call for the underwriter to request deviations from the standard process flow. At this point the underwriter would want to connect with other underwriters (or some other role) in the organization who would have worked on similar policies to understand possible deviations and next steps. Where would he/she get such contacts from? You guessed it - the Contextual Contact set. In the absence of such a targeted contact support system, the underwriter may need to go through a lot of pain before arriving at a resolution. Try to extrapolate such scenarios to your own day to day work life and you will immediately start seeing benefits of such a collaborative ecosystem.