Er .. um … is co-locating a team bad for projects?

I had a really challenging question in a training course recently. 

I normally like these because I get a chance to say “good question, hmm – what do the rest of the group think?”.  Then I sit back and learn from the group.

This time the question stumped all of us though so my initial response was “what, no not really, er, yes but also … hmmm”.

Here is the context and the question.  We had been discussing self “organising teams” (teams that take accountability for their own decisions rather than being told what to do"). 

I said that “colocation” was important but not always possible. In other words I said that the best way to run any project that involves human beings is to have them sit together (or stand together) in the same place at the same time. That was they stumble on more issues earlier, they build trust sooner and they can make important decisions faster.

We all agreed that this was the case. But we also agreed that it is not practical to be sitting in the same place at the same time on all our projects. But rather than just accepting that “unco-location” was going to happen we should treat it as a risk and actively discuss how to mitigate the communication risks and impacts of not sitting together (Essentially I would call a lack of colocation one of the “falling coconuts” on many projects).

So far so good.  But a little later we discussed the theory of the “Wisdom of the Crowds”.  This is the theory that in the right circumstances the group is smarter than any individual in it. 

During this section of the course we discussed what would lead to the group being smarter than anyone in it and what would undermine this.  We covered things like group think and egos as constraints and then discussed some key success factors.

We discussed the importance of bringing different skillsets, biases and personal histories to the team.  So I mentioned that if I was going to role a project out to every state in Australia I should not just involve Sydney people on my project but also people from Hobart and Perth office (for example).

So .. .the question then arose – If you bring these people together they will be co-located.  But won’t they become out of touch with their own office?  In other words if you co-locate the team won’t you lost the diversity of having people in different areas of the business experience the project as their home team will experience the new product?

“Well”, I said, “I guess we should do additional testing then”.  But then the follow up question got me – wouldn’t it be better if you were doing a national or international project if the people on the project were immersed in the different locations where the project will be deployed.  That way they will learn first hand and be able to contribute more diverse views to the team who might otherwise lose this “wisdom”.

“Er, um”, I responded, “colocation good, unco-location bad”.  But then the real answer hit me.

If we co-locate we might be losing our exposure to the challenges, opportunities and diversity of each location.  So co-location is good in that it improves communication and bad because it may (does?) introduce a new risk – losing the valuable input of the home teams that will eventually (or hopefully regularly) receive the benefit of the project.

So I guess now I am unsure – is there a legitimate argument that NOT locating the team together might produce a better outcome than locating them together?


2 thoughts on “Er .. um … is co-locating a team bad for projects?

  1. Great discussion, and hard questions.

    My gut response is “of course the team should be co-located all the time” but you make me think carefully.

    One team I’ve been working with recently contains subject matter experts from a variety of branch locations (it’s a financial institution) and head office. When planning the project we decided it was important to bring people from the remote locations into the team as they do bring the local perspective into the group. This has definitely been the case and the different perspectives has resulted in a richer, more useful system.

    In order to keep the perspective fresh (and let people spend time at home) we’ve used a rotating group – the remote-homed team members spend a month or so with the team, then swap out with someone from a different branch. This does have a small impact due to the loss of contextual knowledge, but it hasn’t been a problem. We did include ALL the branch SMEs in the initial scoping and story identification workshops at the very beginning of the project so they have an overall understanding of the goals and objectives of the project. This has turned out to be very important.

    So my advice – co-locate the team, and rotate members who come from remote locations. Include everyone in the initial planning and scoping workshops and encourage lots of conversations with remote members who aren’t currently onsite.

    If the duration of the project is less than a few months it’s probably not necessary to rotate team members but if the project goes on for a long time people probably want to go back home, and they run the risk of picking up the “head office” (or wherever the team is located) attitude and losing touch with the local perspective.

    Hope this makes sense…



  2. Hmm.

    I see the point. we’ve a Long running project (yes, still agile). The Subject Matter Experts all LOVE the project and the changes we are making. They don’t want to leave! They’ve been seconded onto the project for 9 months or longer, and in that gestatory period have become true believers in agile & the cut, thrust & parry of project life.

    Parting them from the group would be painful for us all!

    hmm. Thinking material!



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.