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.


Thursday, November 14, 2013

On Multi-Site Collaborations

Now that the PM Days 2013 conference is over, I thought of assembling my notes and posting them here - more like a collage of thoughts, supported by slides from the presentation.


PM Days 2013

Why speak about multi-site collaborations? 


Well, for several reasons. One is that the topic is actual and that chances are that every professional project manager will, at one point throughout his or her career, have to organize a project that spans across several geographically distributed locations. If you are not convinced, just check the image below. :)


Globalization

Of course, the collaboration setup comes with its share of risks that we need to be aware of. It is my belief that anyone who had formal PM training, qualification and also practical experience should be well equipped to handle such a distributed project. PMBOK is a great reference and it was one of the aims of my presentation to look at multi-site collaborations through the PMI lenses: identify the patterns and build a collaboration model inline with what we already know.

As I am an engineer by trade and I like things clear, I need a model to rely on, a model that is discharged of emotional mess, that it is conceptually simple and from which I can easily draw my own conclusions as the project develops. Such a model should scale easily and it should be independent of the project specifics (like methodology, scope, stakeholders, initial risks and assumptions) .


Another reason is the personal opportunity. I honestly believe that collaborations open the gates of the world to the people involved in them. They are an amazing chance for learning, sharing, reaching out to other people and experiences and contributing to significant projects. By collaborating, we can build on each other's strengths while minimizing our weaknesses.


While the pessimist and the optimist fight over whether the glass is half full or half empty, the opportunist steps in and drinks it (thank you, Anca, for this joke)


The third reason is the business need  - the case of having to ramp-up quickly to a large number of people (hundreds), with very specific talents (composers, artists, specialized programming, etc...), which may not always want or can relocate. Without such collaborations, large scale projects may have not existed at all or smart professionals located in various corners of the world might have never had a chance to contribute to them.

S-curved ramp-up


To conclude, I will quote the presentation description from the conference website: "we live in a globalized, hyper-competitive world, where companies need to constantly reinvent themselves, their products and their processes in order to survive – all at an incredible speed. Talented people are key to organization success and thousands of papers and books have been written about how to acquire, retain, train, motivate and best use them. “Our employees are our most important assets” are not just buzz words; they are a realization that without the proper use of their human resources, then even the best strategy will fail.

Talented people are hard to find. What do we do when we need hundreds of them? Fortunately, globalization and the age of Internet have provided an answer: distributed teams and multi-site collaborations." 

What is a multi-site collaboration?




Multisite collaboration vs distributed team


To avoid confusion, just a few words about the terminology I will use from here on: 

  • Multi-site collaboration: several teams, located in different geographical regions, working together on a project. The main characteristic is the asymmetric access to information. It is much easier for a team member to build a relationship with a colleague sitting next to him/her than to connect with someone remote. Due to our tendency to favor social comfort, team members will favor local relationships at the expense of distributed relationships, thus local tribes appear. This setup is characterized by a high communication bandwidth locally and a low communication bandwidth between sites.

  • Distributed team (think of open source model): team members are distributed across the Internet. Access to information is symmetric, thus people will tend to build their social networks online. The tribes will form based on common interests and less based on proximity (because there is no such proximity).

The topic presented here is multi-site and not distributed teams (as per definition above). 

  • Lead site - the site that initiates the project or where the project manager resides. 

  • Associate site - a site that was invited to assist in the development of the project.


1. A buyer-seller relationship


Probably the most important conclusion we can draw by looking at the diagrams is that, even if the project happens under the umbrella of a single company, it still resembles very much to a buyer-seller relationship. And this is good news, as we have a model on how to approach it - the Procurement Knowledge Area from our beloved PMBOK. Thus, we already know that we need to perform several steps and end up with a contract between the sites. How should the contract look like? It depends on the scope of the collaboration but, somehow, it should be aligned along the lines of Fixed Price, Cost-Reimbursable or Time and Material. It can follow the Agile guidelines or more traditional ones. 


This leads to at least three main corollaries: 
  • The lead site is the client for the associate - thus the associate should treat the lead site with a client-oriented mindset. Key words are "being of service" and "delivering value".

  • The relationship should be a little bit more formalized than in a collocated setup.

  • The associate should manage itself  (and have a good project manager on site) and that there should be a project manager on the buyer (lead) side as the main point of contact for the seller (the associate). 

I believe that the conclusions above are independent of the methodology employed or the scope of the collaboration. The exact details of the process should be clarified in the contract.

Project managers on both sides - buyer / seller relationship


2. The associate (seller) should take full responsibility for the collaboration 


LS - lead site, AS - associate site; the rest are various stakeholders


While one side should take full responsibility for the collaboration, I believe that the seller (the associate) should step in and guide the buyer (the lead) on how to deploy a successful process. Here is why:

  • If there isn't a very strong motivation on the seller side to collaborate, the project is doomed to fail. The seller should have a very strong incentive to develop further, secure a constant stream of work for its people as well as a constant revenue flow. I believe it is healthy for the seller to aim at getting a bigger piece of the pie.

  • The lead outsources part of its work because it doesn't have the resources to do it. By having the associate provide the full service to the lead, the lead offloads itself further while it shortens the communication chain, thus reducing the associated communication risks: misunderstandings, delays, things left out.

3. There are specific risks associated with multi-site collaborations


Let's look at the setup again:

The model

As said before, there are two main characteristics of the setup above:

  • Asymmetric access to information due to the huge difference in communication bandwidth between the local and the remote, which leads to local "tribes". As a side note, I believe that it is healthy to acknowledge the existence of such tribes and celebrate their existence within the main project. This can be done by simple means, like customised T-Shirts with the geographical location imprinted next to the project name or cultural newsletters.

  • The lead site has much more knowledge about the project then the associates.

These spawn several risks, some of them highlighted below:


Risks

  • Unrealistic expectations from all sides:
    • Top management - "collaboration should work"; this is especially true if the organization is new to such collaborations and does not have a uniform PM and risk methodology.
    • Lead site - "we will not be challenged"
    • Associate site - "we are welcomed with open arms and our ideas will be embraced from day one".

  • Challenge to existing hierarchies and the associated resistance:
    • For the lead site, the new guy on the block (the associate) expects to be part of the decision making process.
    • For the associate, people that were once regarded as authorities in their field will now be subjected to test and will have to prove once again their value to the organization. Some of them will not be able to adapt as their position is challenged.

  • The associate being out of the circle of trust:
    • It is normal that there already exists an established decision making process in the lead site. It is not obvious why it should change, thus the associate needs to prove its value in order to get the necessary trust to be part of it. 

  • Misunderstandings due to remote communication and language barrier. Assumptions

  • The things "we don't know we don't know":
    • I particularly like this one. These are the things that are so obvious for one site that it forgets to mention them to the other, like technical shortcuts, changes in technology or changes in the plans that were not propagated - the tacit knowledge in the project.  Because of these, the associate should never rely on the lead site to tell them when something happens. I believe that the associate should be on a constant lookout for changes and have a very proactive process to identify what they don't know they don't know. The excuse "I have not been told" is not acceptable.

4. To mitigate the risks, we need specific profiles as key players


In order to mitigate the risks above, I believe that the persons that take key roles in collaborations should have several personality traits that should not be treated easily:

  • Modesty: 
    • To listen to the other side and be willing to admit that he/she may be wrong or not have all the information.
  • Outgoing: 
    • "Everyone communicates, few connect" - J. Maxwell
    • Because of the short time spans that teams spend together, key players should be skilled into quickly building relationships. There's no time to lose and there are so many things to find out.
  • Questioning skills:
    • As mentioned before, key players need to dig out the information themselves and not rely on what they are told. They need to be able to uncover project scope, identify stakeholders or find risks quickly and effectively. They need to be very good active listeners.
  • Assertiveness:
    • Sometimes things get out of hand and, at that moment, key players need to show self confidence and control the conflict. They need to be able to stand by their positions. 

In addition, they should not be afraid of putting things on paper because, in the absence of a healthy base of tacit knowledge and personal relations on which to rely on, security should be given by process:

Relying on process in the absence of another solid base

5. Successful collaborations need support from top management


Because collaborations are never easy, top management should be on the side of the collaboration:
  • Time and money and the assignment of additional roles (like the collaboration manager) invested with enough authority to challenge the PM on collaboration topics.

Collaboration manager acting like a coach and supervising the collaboration

  • If multisite collaboration is a strategic direction and not a one time initiative, there should be collaboration KPIs in place which, I dare to say, should not only sit side by side with the rest of the project KPIs but, in terms of priority, score even higher. The PMs should have strong incentives to make the collaboration work. These collaboration KPIs should be followed throughout the duration of the project and archived. No surprises at the end and no post-factum blame if the project is not successful. 

Project report which also includes follow-up on collaboration KPIs

  • Clear escalation path which supports communication to the other side first, favoring problem resolution not complains.



Escalation path: talk first to the other side


6. Some tools (hacks) can help a long way

  • Linked-in & sharing of professional CVs early in the collaboration: 
    • It is one thing to be challenged by John Doe whom you don't know anything about and a totally other thing to know that your peer has 10 years of relevant experience. 
    • Link to CV can be added to email signature or to internal messenger status to be easily accessible. 
  • Video conference:
    • Not much to say - it is one thing to discuss face to face and look into the other person's eyes and smile, and a totally different thing the cold, impersonal email communication. 
  • Clear collaboration charter - the contract between sites:
    • Not to underestimate! In a collaboration things need to be agreed upon and then put on paper. 
  • OPPM report: a great tool!
    • Not only that it is clear and easily readable (after all it is only one page), but it should also include regular follow-up on the collaboration KPIs, like the satisfaction of the other side.
  • Recognize group identity
    • Groups (local tribes) exists and it is in the power of the project manager to position them in the context of the project, thus leveraging their potential. 
  • Recognition of the collaboration overhead
    • The carrot.

Instead of the final conclusion:


I believe that collaboration comes natural to us, we just need to be open to it. We've managed to work together since ancestral times, thus ensuring the survival of our species. We should be able to adapt this innate ability of ours to the modern times, as long as we embrace it as an opportunity.

To collaborate is natural to our species

(Thank you Andrii Shafetov and Google for the artwork).