The introductory article, “Virtual Teams,” in the November/December issue of IEEE Software, is basically a preface to the main theme of the issue: The fact that software development increasingly involves virtual teams, distributed across locations, which requires changes in how the work is done.
The introduction is worth a read, but what I found particularly interesting was the graphic below, which was included.
As described in the article, the Figure shows, “Different project setups. Projects with (a) traditional collocated teams, (b) collocated teams with onsite consultants, (c) nondistributed outsourcing projects, and (d) nondistributed insourcing projects aren't distributed, whereas projects with (e) distributed insourcing with two teams, (f) distributed outsourcing with two teams, (g) distributed insourcing with one virtual team, and (h) distributed outsourcing with one virtual team are considered distributed project arrangements. The projects described in (e) and (f) rely on loosely coupled teams, whereas (g) and (h) have dispersed or virtual teams.”
Clearly there is not one right way to manage how virtual teams are arranged – it varies by organization or sometimes even by the specific team within an organization. In my mind, the value of this diagram is two-fold: First, it’s a simple and effective way to get everyone on the same page about what model is actually in play; second, it’s a graphical representation of the communication challenges that the team(s) are dealing with or will face. Both of these benefits could be important when putting contracts or work orders in place.
I would be really interested if anyone is using a model that is not represented here – please let me know!