Project teams to project networks

MIT's business magazine, The Sloan Management Review, has some insights for expanding project teams in the Spring 2011 edition. In an article entitled "Why project networks beat teams", the authors assert that for a class of knowledge-intensive projects, a good practice is to extend the project team into a project network by case-by-case inclusion of core team member's own personal networks of subject matter experts.

The authors abstract makes these points:

 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 to provide knowledge, information or 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.

A project network can be helpful whenever any of the following conditions is present:

The project scope is beyond the control and sphere of influence of the core team;

The task is complex, and it is unclear whether or not there is an optimal solution; or

Some of the knowledge necessary to create a high-value outcome resides elsewhere.

Managers can use a project’s kickoff meeting to set norms and expectations that members of the project team have the option to look outside the team for possible solutions to complex problems.

Some obvious points jump to mind:

Who pays for these advisors, and are their expenses in a budget for this purpose?

Who do these people work for and what roles does their supervisor play in providing their services to the team?

How is schedule to be maintained with a volunteer core of participants? What if they go off to do their day job?

Are these personal networks actually in touch with stakeholder or user or customer demands, expectations, and needs? In other words, if outsiders are to be drawn into the project as in the Agile paradigm, are these the right representatives?

Of course there are advantages as well. This staffing paradigm is really loose coupling of staff to the project; loose coupling is a good seed for innovation. If the company practices some form of free time, like the 20% free time at Google, then voluntary participation in an interesting project might be good use of the time.

And, it's been my experience that many IT shops, perhaps most small IT shops, don't really track the effort that goes into projects; rather, they track the headcount assignments and major milestones. So, there's really not an issue around cost or cost tracking, and there may be some real help towards milestones.

Bottom line: the MIT authors didn't give a hint about how this would work in the real world. But it could.

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.