As I’ve already said a number of times in this blog and elsewhere, the issue of efficient communications is one of the most important things in using distributed and remote teams. So it’s no wonder that putting a representative of a remote portion of the team on the physical site of the main team is often considered as one of the options in improving the communications process.
Onsite presence: To be or not to be?
I have probably also already mentioned in this blog that at our company, we believe in minimizing the onsite presence to cut down on expenses for the client. Too often, we have seen the onsite part of the engagement abused by other providers, with a big part of the team coming to the client’s site and sitting there for long. That essentially eats up the cost savings the client gets from having an offshore team without eliminating the inconveniences of splitting the team.
Still, some onsite presence is needed. The initial onsite workshop that we practice has proven to be an efficient mechanism for knowledge & culture transfer and jump-starting projects. Periodic visits of remote team members during the project to discuss tougher questions and future stages of the project also help to keep the project going at a good pace. As the team grows, it often becomes more efficient to have somebody permanently on the client’s site to help the team with the questions, planning, and other issues for several projects going in parallel. So, for what size teams is this justified?
Onsite team: Quantity that makes quality
The rule of thumb is that you should keep the onsite presence under 5–10%. There will still be periodic training/planning/acceptance trips from other team members, so the permanent onsite person shouldn’t make up more than 5% of the team size. In other words, you can start thinking about an onsite coordinator (let’s shorten that to OSC) when your team grows to 20–25 people in size. Of course, every rule has its exceptions (and rules of thumb especially). There are teams of 50–60 people that work fine without an OSC, and there is sometimes a need to get an OSC (often part-time) for a 10-person team. But those are exceptions, not rules.
Besides, even those exceptions may still be just variations of the rule. When they require an OSC, 10-person teams often don’t need a dedicated person in that role. Given the workload, the OSC may cover a couple of accounts, switching the focus between them according to the peak-time patterns in the two teams. So that’s just another form of the rule: Once you reach 10–15 people, you may think about having half an OSC for that team. (Breaking further into quarters and eighths of OSC time won’t work as well, though. You can’t expect an OSC to efficiently switch between 5–10 teams; you’ll just lose too much on the switching process itself, as any time-management guru would tell you.)
So we have already proclaimed that remote teams after a certain size benefit from having an OSC. And intuitively, that sounds right. But what exactly should that OSC do? Again, I don’t have a universal answer, but here is how we usually define the position.
The onsite coordinator: The underestimated superhero
The important thing is to always keep the distinction between the OSC and the project manager or remote team manager in mind. The OSC is involved in many information/decision flows, and many people will try to get on-the-spot commitments from the OSC on behalf of the team (e.g., a new project completion date after sharing information about a new set of requirements). But the OSC doesn’t make project decisions, doesn’t make estimates, doesn’t check that the reported status matches the actual progress, and doesn’t commit to any deadlines. That’s up to the project/team manager and the rest of the team.
The OSC’s job is merely to make sure that all questions asked by any of the sides (offshore team of the provider, onsite team of the client) are understood by the other side, these questions are then answered by the other side in time, and the answer itself is understood. That’s the main thing, and though it sounds easy, it’s never a simple task. In military terms, the OSC represents a mix of communications & intelligence forces. It provides information for making decisions, and it delivers the orders and requests. But it’s the commander who issues the orders, and it’s mostly other troops who actually fight according to those orders. Still, without communications & intelligence, the whole machine would find it difficult to achieve anything.
And it really takes a full-time person for a larger team and a larger set of projects to find a convenient time for everybody else to gather at the whiteboard and understand what the other side meant and then document the results in a form that everybody will understand from that moment on. If you remember, one of the important qualities of a successful outsourcing initiative is to change as little as possible in how the people worked before the outsourcing project started. Nobody is ever initially happy about bringing an outsourcing company in the software development project. And one way to avoid situations where people stop cooperating and start sabotaging the work of the remote team is to introduce as few hated changes in their daily lives as possible. That’s where the OSC plays a big role.
OSC responsibilities: Noblesse oblige
You can further define the responsibilities of the position. For example, in our case (at Auriga), it is often described as follows:
- Getting answers from the client’s and Auriga’s employees in a timely manner
- Collecting information (questions, answers, explanations, e-mail messages, documents) from the offshore team and presenting it to the client
- Presenting status reports and communicating project status to the client
- Discussing project requirements and the tasks allocated to Auriga, defining functional specifications and UI elements with the client, working as a mediator between the client and Auriga while discussing the high-level design with the client
- Coordinating the processes used by Auriga’s team and by the client, working with the client’s Project Management Office, defining the build-and-test environment with the client and Auriga
- Helping the client with integration of Auriga’s deliverables and with organization of acceptance testing
- Working as the first-level escalation point for problems related to the offshore team
- Understanding the high-level roadmap and the “big picture” of what is going on at the client’s side and communicating it to Auriga
Every client is unique, so the exact set of responsibilities differs from client to client. For example, in some cases, the OSC is heavily involved in the demonstration of deliverables, while in other cases, s/he is not involved at all.
But, I repeat, what’s important is to remember:
- the main common task of any OSC: Make sure that all questions are answered and that everybody has a common understanding;
- and that the OSC role should never be confused with the PM role.
