Why Project Networks Beat Project Teams

MIT Sloan Management Review has a great article on a new concept for R&D execution organization in Why Project Networks Beat Project Teams.  The focus is on R&D of complex systems and driving collaboration and knowledge sharing.  As frequent readers may recall, this is an area of great interest for me.  We have often discussed how increase in complexity of systems under development has been the driving challenge in R&D management.  We have also talked about knowledge workers in virtual teams and what drives collaboration and knowledge sharing in large multi-disciplinary teams.

The overall message of the article is straight forward: R&D managers should encourage at least some of the team members to bring information/knowledge from experts in their personal networks into the R&D activity.  Involvement of these non-core members (experts) was shown to increase R&D success.  Detailed learnings from the article are below:

To research the factors that affect the success of teams working on knowledge-intensive projects, we studied an established companywide recognition program for project teams at a large multinational food company. As part of that study, we surveyed 1,304 members of project teams in the company to identify key characteristics that promote success in knowledge-intensive work. We then compared responses from the project teams regarding how they went about their work with the company’s assessment — through the judging of the team recognition program — on the significance of the projects’ outcome.”

The idea they have come up with is that of Project Networks:

Typically, project networks consist of a core set of team members who bring in noncore contributors (such as other company employees, suppliers, consultants or customers) from their personal networks who can provide knowledge, information and feedback regarding the team’s task. The project network thus takes advantage of both the project team as a whole and the personal networks of the members.

The researchers studied 177 teams with 1,304 members in ONE food company (I have never worked with food companies, but I am sure their development can be quite complex).  They found that team success – as measured by the same recognition measures across all teams – improved with the involvement of non-core members.  Here is why they think the addition of non-core members is beneficial:

Project networks take advantage of the benefits noted by team-focused researchers — such as the commitment and dedication of members — but can overcome the risks associated with a small group’s limited perspective by crossing team boundaries for project feedback.
Project networks can also take advantage of the benefits associated with members who cross organizational boundaries for new ideas and broadened access to knowledge, yet the team structure provides accountability that can be lacking in informal personal networks.
…
Managers are often not given the luxury of hand-picking exactly the members they would like on a project team; they may have to go with who is available at the time. Encouraging project networks allows managers to look beyond the core project team and to take advantage of what noncore contributors outside of the project team have to offer.
emphasis added

According to the authors, project networks are beneficial in all kinds of situations (innovation, customer service or operational improvement).  They only had two innovation teams – one with non-core members and one without.  The team with non-core members was able to come up with a fundamentally new product, while the one without just had incremental improvements.  The team involved non-core members by:

The Innovation Project A team involved a number of functions — sales, marketing, R&D and process development — and was located across six U.S. states in nine different facilities. Through its project network, the Innovation Project A team acquired relevant food formulation knowledge that customers had about their specific applications for this type of ingredient. In addition, the core members of the project team augmented their own knowledge by accessing food production expertise both from other colleagues in the company and outside vendors. While not core members of the team, these contacts were all part of the project network.

So, how and when should one involve non-core members? The figure from the article (replicated below) provides details. My suggestion is to do it carefully. Only involve non-core members when the project is complex.  Even then, clearly define boundaries and ground rules.  There is clearly a possibility of proprietary information leakage if the process is not managed carefully.