Saturday, May 12, 2012

Few Points On Multi-Site Development

I've been involved lately in significant multi-site game development efforts - large projects, high stakes, distributed teams, many stakeholders spread around the world. Here are some observations I've made, most of them quite obvious but, sometimes, difficult to put in practice. Based of what I've seen so far, they are prerequisites for successful distributed development:

  • Clear organization / clear responsibilities / low number of  cross-site communication channels. 

It is quite obvious that communication becomes more difficult in a distributed scenario. Therefore, effort should be put in designing a clear organization, with clear roles and responsibilities, accepted by everyone. As it takes more time to reach common understanding and since it is more difficult for the project manager to keep an eye on the team dynamics, the number of cross-site communication channels should be kept to a minimum. The risk of misunderstanding is high. A good communication plan, role definitions and responsibility assignment matrices are priceless tools for drawing clear boundaries, limiting spam and clarifying the structure. From my perspective, in order to support a multi-site scenario, a project needs more administrative effort and better formalized processes than a co-located one. It also needs more internal PR to make everyone aware of achievements, risks, progress and goals.

  • Investment made in creating a distributed team should be preserved. 

Building a functional global team is more difficult, especially when the project consists of co-located sub-teams and tasks require cross-site collaboration. Making collaboration work involves expensive trips for the team members to start knowing and trusting each other. Such an investment is lost if the team is disbanded at the end of the project and people are spread back across the organization.

  • Cross-site dependencies should be kept to a minimum and sides should work as autonomously as possible.

This makes life easier for the teams as it diminishes the communication effort between members. However, dependent tasks should be scheduled as early as possible to minimize the risk of having conflicts appear later in the project. Teams should be built by having them work together since the beginning on common goals, especially that the risk of higher pressure closer to the end of the schedule is significant.

  • Team members are responsible for solving the conflicts themselves.

Managers should help teams understand that pointing fingers is not acceptable and bounce back problems when they feel not enough effort has been put into cooperation. Ideally, everyone should be trained in emphatic communication and active listening. Collaboration ground rules, escalation paths and conditions should be clearly defined.

  • Atmosphere needs to be relaxed. 

Pressure in production leads to less collaboration, less communication and to finger pointing. People should feel comfortable taking time to talk and put problems on the table.

  • Good project management practices should prevent most of the problems.

The root causes of conflicts are usually priority / schedule / scope creep / misunderstandings. These should be covered if managers follow standardized project management practices. Standardization and training help simplify the communication between leaders from the different sites, as they use the same set of procedures and performance criteria. 

  • Face-to-face discussions (video-calls, meetings, traveling, every day communication) should be the norm. 

The more people know each other, talk and have fun together, the less likely it is for difficult conflicts to arise. Team members start trusting each other and are able to predict each other's reactions. They talk more openly and raise concerns earlier.

  • Problems should surface early. 

Obvious, but also more care should be put into identifying issues because a significant part of the team is not in the same room and it is more difficult for the local managers to understand their situation. Processes should be put in place for constant risk assessment and planning.

  • For a collaboration to work, it is important to have skilled and experienced people in core positions. 

Communication overhead is high and having experienced leads / project managers in both sites is a very important prerequisite for success. Management skills and knowledge seem to be more critical in a distributed setup than in a co-located project.

  • Collaboration overhead needs to be acknowledged and supported by management. 

It may be hard and frustrating for everyone, especially for the teams. Management should openly a support, allow time and training for this extra effort. Management should acknowledge that the personal productivity will be impacted, to ease up the pressure and diminish defensive tendencies. On the other hand, people should be aware that it is in their mandate to collaborate and their success (both from the perspective of the project and personal) will be tied by how well they work together towards the same goals.

Even if multi-site development is difficult and poses tough challenges, today is almost impossible for me to imagine huge projects being developed only in one site. It is impossible for me to imagine how a company can bring all the needed talent to a single location or find already there so many people with the required expertise available (either externally or internally). And even if it could, having so many persons involved still generates a significant interpersonal distance between team members and teams must still be  split because, otherwise, they would be impossible to manage. Thus the notes above still apply. 

The list is not even by far exhaustive; it is merely made up of personal observations. Please feel free to send me more factors for project success in a distributed environment. I'd love to chat and share about this subject.

No comments: