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 encouraged. 

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. For a more complete description of what makes a project succeed, a more complete guide is the PMBOK ( :) ) or any of the many project management books out there. Good luck! :)

A Few Words About Communication In Projects

Too much email.

Most of the time my inbox is flooded with information I could very well live without, just because someone thought of adding me in CC or I am in too many email lists that are spammed with messages that only concern a few people. Most of the time, I receive a message "just in case I might be interested". And, of course, a two page long, unstructured document follows. This creates a lot of information overload and noise and thus the risk of missing relevant facts is significant. I know that this is a common problem to many managers. Many of them try to find solutions to limit the spam and channel the communication only towards the relevant people. Not only that it wastes time, but spam also generates a significant risk on the project because the project manager gets caught in a reactive loop instead of taking the proactive, look-ahead stance.

Solution.

The solution is quite straight forward but, just like any PM area, requires a little bit of planning ahead. It is called "the communication plan". Among others, the communication plan tries to answer the following question: who are the stakeholders and what are their information needs: level of detail, frequency, matter of interest, preferred format, the kind of information that can be obtained from them. The communication plan tries to identify important channels of communication and direct the flow of messages across those lines. By structuring the communication we aim to:

• Reduce the amount of spam in the project
• Focus on relevant matters
• Escape the need of digesting unimportant messages
• Less meetings

Basically the aim is to shift focus from quantity to quality and, instead of spending hours or scanning unnecessary reports, focus.

Focusing the communication is not only to help the PM and the team reduce their information overload, but it is also a matter of respect towards the recipients and of their time. Above all, it significantly increases the quality of human interaction and the chances of actually getting timely answers to your needs. (Yes, it is significantly harder to write clear, shorter and focused messages than it is to quickly type 1 page of text and throw it away to 100 recipients).

Reporting.

As there are many guidelines out there on how to hold effective meetings, I will focus my attention to another important part of the communication plan: reporting. All project managers and team leaders are bound to send reports and mastering this art can significantly improve their image, the image of the team and increase the chances of getting support.

The aim of reporting is to:

• Provide a clear picture of what is happening in the project.
• Acknowledge / celebrate successes and recognize errors.
• Identify risks and propose solutions.
• Involve stakeholders by providing relevant information and asking pertinent questions.
• Provide a single reference of the project status and reduce spam.
• Bring everyone on the same page.

As with any other communication means, visual reports are more appealing and easier to understand. Instead of  throwing in a long list of items and actions, the more pictures, charts, tables we have, the better we are. And, of course, we all love statistics thus, when we have numbers, we should never hesitate to use them. Beside the visual dimension, a good report is a short, concise one.

Emphatically writing a report means acknowledging that most stakeholders have a superficial understanding of what the actual situation is and thus it is of extreme importance to provide a context. If a PM complains that his reports are never read, it is because people don't understand them. Nobody bothers reading lists of items that don't make sense for him because he cannot relate them to a bigger picture. A report that presents information in context generates understanding and thus increases the chances of being read, generating reassurance and trust even if it brings bad news. What the reader wants to grasp is:

• How the work relates to the global objectives of the project. (again, context / plan)
• What the objectives of the project are - better say, does the team have the same understanding of the objectives as I, the reader, do?
• Everyone is busy with relevant work.
• The team knows what to do next and why. The possible blockers that prevent them from proceeding according to plan have been identified and solutions have been proposed. 
• What the team actually does - this is probably the least significant. 

Therefore, the purpose of the report is to show (of course, all the information must be true!):

• The project team knows what to do and is in control.
• The project team has a plan that is approved, clear, with tangible objectives.
• The project team knows where the (possible) problems are and has solutions to them.
• The project team is proactive and focused on attaining results.
• The project team has results that are celebrated and the morale is high.
• The project team is not afraid of bad news and talks about them openly.

If the recipient doesn't get all that information  or if he  needs to perform a significant effort to understand the report, he will become less confident and we expose ourselves to the risk of having doubts spread about our work to other stakeholders. Then, the effort of counteracting and gaining the confidence again is really high. It is by far easier to keep everyone correctly informed right from the start instead of trying to set things straight after we have an image issue.

One more thing before I end.

The purpose of any communication is not for me, the emitter, to transmit it easily; it is for the recipient to understand it clearly. Therefore, it is my duty to spend significantly more effort in being concise and clear than to write a lousy message that the recipient needs to put in effort to decipher. Even more, my effort is not only bound to transmitting the correct message. It is my duty to make sure my communication has been properly received and understood. I need to ask for feedback, comments, and spend time to understand the needs of the recipient.

Cross-Site Collaboration And Conflict Management

The first step in solving a conflict is to identify its cause. Then comes finding and applying a solution. For this, the conflict is taken out of the personal space and approached pragmatically, depersonalized. Safety should be guaranteed for participants by forbidding blaming and pointing fingers. Focus, instead, should be put finding solutions collaboratively. In the end, the issue and its resolution must be added to a log for further reference. Lessons and best practices are then extracted and processes improved.



Identifying the source of conflict:

According to PMI, there are seven sources of conflict. In order of frequency, they are sorted as follows:

1. Schedules
2. Project priorities
3. Resources
4. Technical opinions
5. Administrative procedures
6. Cost
7. Personality

The hard fact is that "personality" is the last frequent in reality, although many tend to blame it as the main source of issues in projects. To me, that is because many managers don't know the other 6 and it is easier to blame it on someone you can point your finger at (except the PM :) ). As the Pareto principle applies in this case as in many others, I'd say that  it would be safe to begin by excluding "personality" from the list and try first to fit the issue in the other categories. Beside a better understanding of the real cause, this thinking has the benefit of cooling things down as sides can focus on finding a solution, without feeling the need to guard their personal space.

Finding solutions:

Things can become explosive in a cross site collaboration because it is more difficult to act emphatically, it is natural to think in terms of "us" and "them" and misunderstandings can occur at all stages, even if people seem to agree. Therefore, a set clear rules are mandatory to ensure conflicts surface early and that they are treated up-front, before the situation degrades. Here are a few:

• All teams must understand that it is their responsibility to solve the problems. Their actions are measured and recorded and a post-mortem will be done on how the collaboration went. To support this, the managers should create a set of ground rules and encourage a culture of exchange and free speech.

• When a problem occurs, everyone should look critically at themselves and see how they could have acted better. Acknowledge you can change yourself but you cannot change the other.
• Has my message been properly understood?
• Under what conditions does the other person receive my message? Is he under heavy load? Is he under pressure? Do I understand his point of view and his situation?

• Once the problem has occurred, act immediately. Problems don't solve by themselves. Be assertive, refer to yourself and express your feelings: "Look, I feel like there is a misunderstanding somewhere". Cool temper needs to be preserved even if the other side is acting aggressively.

• If you cannot solve it yourself, raise the problem to your manager and / or to the collaboration coordinator (if one exists). It then becomes his responsibility to interact with the other side. Provide reasons why you could not solve the problem yourself and show the steps you took. Take responsibility for what you have done. 

• In the end, once a solution is found, a written note is archived with the problem and its solution. This written note acknowledges that the problem had, indeed, been fixed. Once the note is acknowledged by all parties, the issue is considered closed.

Managers should find ways to allow people to raise and fix issues safely. Don't blame, but encourage solutions and cool temper. What is measured is the capability of people to collaborate rather than the number of problems they encountered. Accept that problems will occur, but try to learn from them.

Lessons learned:

The issues should be kept in a log. This log will be used for two purposes: to see how the conflicts evolved and to evaluate the capacity of the team to manage conflictual situations. Based on it, processes are improved and people learn to interact and collaborate. The knowledge is then passed to the next project.

Prevention:

While I believe that constructive conflicts are a positive sign that things move forward, it is better to proactively diffuse latent problems before they appear. To do this, management focus should be kept on the following areas:

• Risk management - key to project success. If risks are identified early, acknowledged by everyone and mitigation plans sketched, trust is enhanced. Therefore, people are less afraid, they have a better sense of security and thus will less likely be in defensive mode. 

• Prevent stress / project pressure - the same as above. Pressure raises schedule and priority issues which tend to be explosive as people become more tense. Therefore, management should focus on releasing stress and encouraging a relaxed atmosphere.

• Prevent fear - when management looks for assigning guilt, people will be less willing to confront problems early and they will start pointing fingers. No room for collaboration.

• Prevent directive management - a directive management style will generally not encourage openness and engagement. Therefore, problems can linger around uncovered for longer periods of time, without being solved. Otherwise, pointing fingers and blaming can occur.

• Having a clear, common set of ground rules to follow - provides a reference for the desired behaviour.

• Having a clear organizational structure, decision process and information flow - standardizes  how people interact and what responsibilities they have. A go-to book for management of expectations.

To sum-up, a healthy, empowering management culture together with good project management practices form a solid basis for a cross-site collaboration. It is more difficult at a distance and, therefore, more records should be kept and more attention should be given to developing a culture of mutual respect, empathy and understanding. Also, a continuous, open learning process should be put in place. Ideally, it should all be treated like a game, so that people feel safe and are willing to explore their boundaries without concerns.