Social capital, knowledge integration and IT

Social capital fascinates me because of its potential to transfer, integrate and create knowledge. Newell et al explore social capital and knowledge integration in an IT context, which makes it a fascinating paper. It's also about real research, not just concept development, even if it is just the one case study.

First the authors review the literature on

1. knowledge integration in large IT design and implementation projects ,
2. role of social capital in facilitating knowledge integration (Coleman, Granovetter). This includes mention of
   

• communities of practice (Lave & Wenger),
• interpretivist research (Berger & Luckmann)

I'm glad to realise that I am familiar with most of this literature.

Newell et al quote Napahiet & Ghoshal's argument that individual project members need to draw on their social capital to access dispersed knowledge (Nonaka) and problems arise if members don't use social capital or cannot integrate knowledge in the project team.

The researchers included a participant observer visiting over 18 months - more time than I've got. I've got something more like six months left to collect data. They recorded hour long interviews with all nine team members as well as ten owners, which something like what I'm doing. But they also had forty informal unrecorded interviews. The write-up seems to me to be a narrative and perhaps I can write something similar for my half dozen case studies.

Newell et al's case study shows more negative use of social capital than my case studies so far. For example, there was "little attempt to share", whereas I know a project where members emphasised team work and sharing right from the start. Newell et al's case study also used two IT consultants but they "did not see any need for involvement with potential users", so there's a different attitude to engaging with clients, and certainly not an attitude that uses social capital. Another contrast is the observation "that there was very little interaction and dialogue during meetings" (p50). I found a developer who'd been described as shy and who saw herself as quiet, but admitted that she now spoke up much more at meetings. Something about sharing in the team helped her to learn and to share.

Newell et al commented on meetings that team members often missed. I've had the impression in one case that when a more junior member stood in at a meeting, that some senior managers paid less attention.

Newell et al assess the bonding and bridging in their case study .
Bonding is about social cohesion within the team (similar to De Marco's module cohesion) - the more the better).
Bridging is reaching out to other communities (similar to De Marco's coupling) - it should be weak as in Granovetter's weak links

The above indicated that the bonding was poor, but unfortunately the bridging in Newell et al's case was also poor. They refer to "structural holes".

In conclusion the authors argue that "bridging and bonding aspects of social capital must be distinguished". I can use that in analysis of the case studies I find. The antecedent condition is to develop team bonds first, and I know evidence that supports this, where sociability was encouraged and trust existed.

It also shows the value of engagement. People need to share, be involved, interact and have dialogue.

---

Newell, S., Tansley, C. and Huang, J. (2004) 'Social Capital and Knowledge Integration in an ERP Project Team: The Importance of Bridging AND Bonding', British Journal of Management, 15, pp. 43-S57. 1109