Friday, November 15, 2013

Again On Multisite Collaborations - Various Setups

While writing the previous post, more ideas came to my mind about multisite collaborations. 

Just to have it under our eyes, here is the terminology I use in these articles:

  • Multisite collaboration: several teams located in remote locations work together to complete a large scale project.

    Multisite collaboration


  • Lead site (the buyer): the initiator of the project, the place where the PM resides.

  • Associate site (the seller): a site invited to work on the project.


Setup no. 1 - the associate site does not have a dedicated project manager.


No PM in the associate site

It may seem to work at first, especially for small teams in the associate. However, several developments become apparent quite quickly as the team grows:


  • If management is done at a task level, most of the time the people in the associate will act in a manner very similar to being independent contractors, without much attachment to the product. There will be little communication or synergy between them. As we cannot speak of a real team, the value the associate will bring to the project will be directly proportional to the amount of time each employee spends on his tasks, focusing on getting the code to work instead of understanding the product as a whole. 

  • Communication can become heavy and with plenty of misunderstandings, not only due to the language barrier but also because the engineers in the associate are most likely not hired for their communication skills but rather for their technical skills. Therefore there is a very high risk of rework and frustration on both sides.

  • In this case, the associate site acts more like an HR firm providing temporary workforce, without any additional value that may emerge from team cohesion - like innovation and creativity. The setup is as if the associate employees are temps working for the lead site. 


Setup no. 2 - the associate adds a project manager, but the core of the process does not change.



PM in the associate site is excluded from the main communication flow


A PM is added when the lead site and the associate agree that there is something wrong in the collaboration - like low quality of the deliverables, misunderstandings, rework, delays. However, adding a PM without putting him or her in the main communication loop or not giving him or her decision power does not change the situation much. Satisfaction will not improve dramatically and the PM will mostly feel useless.


Setup no. 3 - PM on the lead side, PM on the associate site



Both the lead and the associate have dedicated PMs to follow the collaboration


While I strongly believe that engineers should not be impeded from communicating to each other directly, the main decision loop should go through the two PMs (one on the buyer's side, the other one on the seller's side). The associate now has a real chance of leveraging their potential and building a team. With its own backlog, own objectives and freedom of choosing their own internal processes, management is done based on clear KPIs and clear acceptance criteria. The associate has a champion on site, the project manager, who will lobby on getting on its plate higher value business cases and providing not only bare bones engineering services, but also securing the delivery, securing a certain quality standard, participating in the product design or offering additional creative services. The focus moves from tasks to features and added value. 

The last setup works particularly well when there are language barriers, process differences or different organizational maturity levels in the two sites. The PM from the associate acts as a facade, abstracting the development process that happens behind him or her and making sure the discussion does not deviate from the concrete, measurable objectives set for the collaboration. His aim is to protect the team, get acceptance on deliverables and spot opportunities for the associate to bring additional value to the project (entrepreneurial spirit).

To answer one of the questions from PM Days, what is the number one thing that can lead to a successful multisite collaboration, I would summarise everything by saying that my opinion is that PM proficiency (practice + formal) for the associate site project manager, coupled with a modest, outgoing, growth-oriented and curious personality should prevent a lot of problems.


No comments: