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.

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

Mistakes (Junior) Managers Make

Two excellent threads on Quora:

• What are common mistakes that new or inexperienced managers make

• In a growing tech company, what are the most valuable things on which an engineering manager should spend time

To the already long list of mistakes presented there, here are some others I've experienced so far:

Thinking that it is enough just to create task lists in Excel

I have seen quite a few managers that, after being appointed into position, completely forget their craft, forget about people, forget about product and transform themselves into task administrators. The problem, I guess, lies in lack of role models and lack of understanding of the job. Management is not a reactive profession, but rather one that requires time to think and put things into perspective. 

To overcome this situation, one needs to seek for role models, read, ask questions, network, escape the comfort zone of always being busy. This is particularly hard and requires a lot of emotional energy, especially in an unstructured environment, without clear performance metrics and job descriptions. 


Disconnection from the product

I also call this "management from excel" or "management from inbox" and, to me, it means relying only on reports to mark work as done instead of going on the floor and inspect the product yourself. This is very dangerous as it leads to optimistic reports where everything seems fine while the product is completely broken. It also leads to non-communicative behavior in the team, lack of challenge, lack of risk management, sloppiness that spreads - the broken window effect.


Transparent manager

Every communication layer needs to add something valuable to the communication. When communicating up, the manager needs to create a new layer of abstraction and encapsulate the information for the needs of his/her managers and when communicating down, he needs to be able to break the information for his colleagues.

When the manager is not able to deal with his superiors autonomously, without constantly asking for support and clarification from his team and vice versa, he doesn't bring any value to the communication. He needs to understand the problems, the product and the requirements so well that he can have a dialogue with all his peers without constantly relying on "wait, I need to ask my lead programmer / engineer / game designer / marketing / HQ/ ... ". 

To overcome this, the manager needs to practice questioning skills and treat every problem with deep understanding. 

Conflict avoidance

Being afraid to go to the team and say: "look, this is not working. What can we do?". Being afraid or postpone to open touchy subjects and trying to maintain a sense of peace and calm at the expense of higher risk and lower performance.

To overcome this, the manager needs to practice self confidence and facilitate genuine dialogue. Curiosity and questioning also help.

Lack of trust in team members

By trust I mean not "I trust you to finish the job without checking" but rather "I trust you to open up to you, challenge you, be vulnerable in front of you to push you to over perform". Lack of trust leads to complains about the team to upper managers, disconnection from the team, conflict avoidance, gossip, low performance.

There are many ways to overcome this, but a basic one is to go to the team with problems and ask them to help you solve them. Something like "guys, we have this on the table; what do you think we should do about it?". 

Lack of control and measurement

Very much linked to all of the above: lack of trust, lack of depth in analysis, managing from excel. In order to be able to challenge the team one needs facts. Facts come from setting up several metrics and benchmarks for performance, then bringing the results to the team for debate. Without this, all dialogue becomes personal and subjective.

Not asking for support 

Manager's mission is to ship projects, grow people and deliver value and, sometimes, we don't have the knowledge, experience or tools to tackle every problem alone. We need support and we need the maturity and courage to step back and say "ok, if I pursue this course of action alone, the risk of failure in unacceptably high". Many managers were appointed as leaders to their teams for their own drive for achievement and resilience in front of problems. We need to understand that the results are more important than ourselves. It is true that nobody wants to work with a defeatist, but also nobody wants to work with someone who is blind and drives the projects straight into the fence. Vision is needed as, most of the time, there won't be an upper layer with enough knowledge of the project to be able to take the decision to offer help without being asked for help.

There are other behaviors at least as important as these: lack of decisiveness, hiring too soon and firing too late, not taking into consideration values and team fitness when hiring and firing, and many others. These were probably the ones that affected me the most so far and I will probably touch them in a future post.

On Values and Why They Are Important

Core ideas:

• Personal values are the lenses through which we see the world.
• Knowing them helps us benchmark our decisions, so that we are more aligned with them and thus happier.
• Team values are the fabric on which a team is built.
• To create a strong culture, adherence to company values need to be tested at each hiring interview.
• It is the duty of the leader to adjust culture through honest dialuge.
• Values are neither good nor bad. They are just who we are and they make us diverse.

Why?

I have been thinking a lot lately about how and why it is important to work as a team. Inevitably, the line of thoughts brought me to a few basic questions:  to what degree does the team share the same values with the company, how we can align them, why does it matter?

Of course, the internal dialogue went on, asking other fundamental questions: to what degree shall we put effort into surfacing the true values of the team and benchmarking them against what the company expects from us? How would such a (time consuming) dialogue influence productivity? Is it worth the investment and, if so, how can we make the process engaging and honest? Maybe we should just put our heads in the sand and ship projects, caring less about topics that seem, at surface, too touchy-feely to be discussed in a serious production environment. Or not?

As the main mission of my current job is to build a strong management team around me, a team that is guaranteed to ship in spite of any adversity, for me this dialogue is more important than ever. People sharing common values make the fundamental fabric on which teams can be built.

What are values?

I would define "values" as the lens through which one sees the world. It is a fundamental set of core beliefs and attitudes that gives identity and guides decision making. Most of us are not aware of them as they are buried deep inside, shaped by our past, parents, environment, friends. We know when somebody trumps them over because then we feel a strong burst of repulsion and anger. We are very quick to judge and become intolerant about people who share a different set than we do. For instance, if one values hard work, he or she will be very tempted to dismiss others more inclined to a life of leisure, and vice versa. However, values seem elusive and it is hard to put them into words.

Why identify our values?

Honouring values means living an aligned life, peaceful, with less concerns and less emotional turmoil. On the contrary, not honouring them means constant dissatisfaction, frustration, fatigue.

One reason why decision making is so difficult is because of the uncertainty that lies ahead. Will we be at peace with the consequences? The best tool for answering this question is to benchmark the options and the expected results against our values, then pick the one that honours them the most. The whole process will feel safer, more natural, obvious and relieving.

As an example, let's assume that one's core value as software engineer is craftsmanship and code beauty. He is faced with the decision to switch jobs to a company that offers a better salary. At first, the decision seems simple. But will he/she feel happier there? By knowing his/her values and asking simple questions like "How do you take care of the code? How do you refactor?" the candidate will be able to assess his future state of happiness in that company and take an informed decision. Thus the more one is connected with his/her values, he/she will be able to take better decisions and live a more fulfilled life.

What about teams?

A team is a set of individuals working together towards a common goal. Teamwork needs cohesion, trust, reliance on others. By knowing its core values and by constantly asking "is what we do inline with who we are" a team will be able to take decisions easier, be more satisfied and bond together more closely. They will be able to say clearly:

• Who is fit for the team and who is not - and why?
• Is the next step inline with who we are? Are we satisfied with it?
• How will we improve?

Values should constantly appear as questions during team meetings. If, for instance, one team values "constant learning" they need to ask themselves even for the simplest task: "what can we learn from it?" or "how can we approach it so that we learn something from it?" If the team takes the challenge and searches for the answer, they will feel happier and more satisfied with their work because they honour their values.

Team values should be known in the recruitment process and tested for them or, otherwise, the risk of a bad hire is just too high. Let's imagine a scenario where one wants to hire a C++ developer. Is the C++ test enough? Imagine getting a guy who values changing the world through volunteering in a team that has quick financial rewards as its core. Will he be satisfied? Will the team be able to accept him? HR and the hiring manager need to provide the answer in advance: how will his values be honoured in the workplace?

The five dysfunctions of a team and values:

According to Patrick Lencioni's business fable, there are 5 dysfunctions that plague teams. They all build on each other, having as the foundation the absence of trust. I believe that the best way to overcome the absence of trust is by provoking a genuine dialogue aimed at identifying what we, as a group, value. If I know that we share the same values, I will be more inclined to trust you. I will feel closer to you, thus I will be more likely to open up and collaborate with you.

Corporate values and team values:

Values are personal. It is crucial that newly hired share the same values as the company or, otherwise, they will be misfits or, even worse, if in great numbers, they may destroy the internal culture and teamwork. It is the job of HR and that of the hiring manager to properly test for company values, not only for technical skills.  

I believe it is the duty of the leader to provoke an honest dialogue and identify what the true values are. The key word is "honest". Discoveries may conflict with the declared company values which is OK as long as they reflect the reality. Once the dialogue has started and it is genuine, through open retrospectives, questioning and benchmarking, the leader will be able to adjust the culture. I believe it is possible and the end result should be better service, better community, happiness, productivity and engagement.

And yet we need to accept diversity:

Values are neither good or bad. They just are and they define us. They contribute to the diversity of our world, a world that accommodates so many perspectives. Although we usually exhibit strong emotional response to someone who shares or does not share our values, we need to accept that as beneficial. A society or a group in which everyone shares exactly the same core beliefs is a dystopia - first of all it is impossible as each of its members have different life experiences and, second of all, it is doomed to fail because of isolation. While we need to adhere to a common set of values in order to collaborate, we are evolutionary programmed to be diverse in order to survive.

Ecology. Diversity. Social Inclusion

Last week in Malmo I had the chance to meet this amazing group of people:  http://connectorsmalmo.com/ConnectorsMalmo/For_Malmo_By_Malmo.html. Guys, I had a really great time with you! I hope we keep in touch!

During the discussions, two types of issues stood prominently: ecology and social inclusion. And it makes sense.

Ecology:

Only in a sufficiently advanced society, like the Western World, people can afford to think about ecology, about how we can make sure we are going to have an inhabitable planet 100 years from now. The rest of the world population is just too busy surviving past the next few days - weeks - months. Above all, it is the moral duty of these advanced societies to raise such issues, to provide leadership for the future, to clean up the planet and invent new, sustainable ways of living because, otherwise, nobody will.

Social inclusion:

As a society is getting more and more advanced and as its standard of living rises, it becomes more and more attractive for immigrants, for people who want and are willing to start a new life, hopefully better than the one they can afford in their own countries. Throughout history we have witnessed many  waves of immigrants, leading to profound changes in the societies they affected. Most of the time, they initially provoked fractured communities, with an increased gap between the rich and the poor, cultural clashes, segregation, extremist movements, social tension, crime, hatred, discrimination, riots.

Extremist parties have always gained political capital by proposing isolation, expulsion and restriction as a solution for the problems above. Can we do better? Are we civilised enough to manage our most inner drives to build a society where we can all live a good life?

Our brains are not wired for diversity:

• It is natural and evolutionary normal for people to quickly classify things based on simple, visible criteria - if an something moves and has long teeth, our brains tell us to run if we want to survive. Those who stay behind to investigate do not have a chance to pass on their genes often enough to become biologically relevant. Even more, it is complex, time and energy consuming to dive into details and to consider all options. We have evolved to store energy and use it only when it is critical for our immediate survival. We like to decide quickly, based on clear differentiators.

• We evolved in tribes, not as lone hunters. We, as humans, like to draw borders around us and quickly say who is in and who is out. All our society is build on borders: family, city, nationality, country, company, etc. We know them and we have a clear sense to where we belong. We need to belong as the group gives us an identity. We are very quick to judge who is in and who is out and we like borders because they make us feel safe. 

• It is very hard for us to work with big numbers. Our brains are not wired to easily understand what is the difference between 1 in 10, 1 in 100 and 1 in a million. We actually understand an event with a probability of 1 in a million as still something that could happen to us which is not really the case. Otherwise, people would be much more reluctant to play the lottery.

• Media does not help: bad guys stand out and make the news more often than decent, hard working people. As we have an internal drive to watch out to maintain our safety, we are very curious about bad things. Media loves to exploit our tendencies and present drama to increase its sales. Corroborate this point with the other three points above and it results in an explosive combination. Drama-oriented news is hurting our society, feeding us reasons to promote hate and discrimination and gives us a false sense of insecurity towards our peers. (Doesn't this look like stark contrast? http://www.express.co.uk/news/uk/380512/How-Romanian-criminals-terrorise-our-streets as opposed to public data about crime in Bucharest http://en.wikipedia.org/wiki/Crime_in_Bucharest which positions the Romanian capital as the safest capital in Europe - guys, there are many more Romanians in Bucharest than in London. Please don't draw any conclusions about us as a nation based on what is written in the press).

We need to accept that it is unnatural for us to easily acknowledge diversity as a part of our lives. It may seem that segregation is a problem only for immigrants but: we do not accept gay people, sometimes women still don't have equal opportunities, we fight because of religion and nationality (how many wars did we have in Europe, including the war ignited 15 years ago by the collapse of the former Yugoslavia, how many bombings in Ireland, how many riots, expulsions, extremist goverments) and even because we support different football teams. We naturally don't like diversity, so what can be done?

Diversity sparks innovation:

But before that, why do we struggle? Beside the ethical debate, I would like to give one simple reason: diversity is the basis for creativity and innovation. Innovation does not come from thin air. Innovation usually comes by combining different unrelated ideas into a new product or revolutionary thought. Just imagine how can a bunch of football fans who only know about football invent a new team game? What probability of success would you give them? What if the team is made up of football, basketball, tennis and even some obscure African and Chinese traditional sport fans? Would they have a higher chance to come up with something revolutionary?

We are too expensive:

But why so much talk about innovation? Why can't we just stick to what we have? The reason lies in simple economics. We are too expensive compared to the rest of the world. Everything that has already been invented is manufactured offshore for a fraction of the local cost. So the only thing that is left for advanced economies is to open up new markets, to create new a demand, to invent new things. Our only chance of maintaining our high level of living is to constantly innovate. And for this, just like in the example above with the football game, we need diversity. We need people who think differently, who have different experiences, who come from different backgrounds. Including them in our economic activities is a necessity, not a act of benevolence.


We need to draw boundaries based on values:

I believe that all humans are good and willing to help each other. I believe that the main reason we like to draw boundaries is because we can't connect to the others, because we don't know the others and we feel the need to protect ourselves. Once one knows his / her peer, once one sees what value his/her peer is bringing to him/her, once one knows that it is safe, I believe that he or she will gladly open the door to welcome the outsider in. We need, as a society, to counteract the negative distortion promoted by media and start a global awareness campaign. We need to put things into the right context. We all need to gather and collect positive stories. We need to show that those immigrants / gay / football fans of another team are the same people that defend our homes as police officers or firemen, are building our homes, raise our children or cure our sick.

We will still need to protect ourselves and we can do it by drawing a hard line against criminality of any kind. We need to start to publicly define our deepest values (like honesty, respect, tolerance), understand them and make sure they are respected by the whole community - uncompromisingly respected. Such a large scale dialogue requires leadership, openness, education, tolerance, self-questioning, respect and a strong will to stay in until the right solutions are found. The less responsible attitude of excluding large parts of the population based only on the ethnical or racial criteria, just because it is much easier, is neither ethical nor economically viable. I believe that we need to involve more our moral philosophers to help us define our values and build on them a genuinely free society, where everyone can express his or her personality in a safe environment, as long as it does not harm the others. We need to educate people to pay attention, to stand up, to speak their minds and provoke true social dialogue, by confronting the reality and not by vague, conflict-avoiding, politically correct speeches.

I believe that such a society can and needs to be built and would end up having a secular basis, valuing science, reason, art, research, respect for the free spirit, innovation, law, dialogue and personal initiative.

I am optimist seeing that people debate such issues, seeing people of different nationalities working together, learning together, playing together, I am optimist that the world is advancing blazingly fast towards an era of collaboration and tolerance.

[Link to Video]

A Case for Professional Project Management

There have been more than 4 years since I've started managing projects, one year since I took my PMP and 4 months since my PMI-ACP. I have shipped 4 big projects so far, I've been involved in many others and I have recently been appointed as the head of video game production in Ubisoft Kiev. All my professional life I have been involved in projects, most of them with many stakeholders, distributed around the world.

Whenever I think back to what I could have done better in various circumstances, two things stand out: I could have better controlled my area of responsibility through more standardized PM practices and, by being more in control, I could have acted more responsibly on various occasions. While clear, standardized processes do not guarantee neither project success nor the sense of ownership and responsibility that every project manager should have, they are liberating. They free the PM from the burden of reinventing the wheel and let him focus on the project at hand - contrary to the wide spread belief among unexperienced PMs that standardization is a burden the corporate management enforces on them.

Throughout this post I will discuss why Project Management is so important and why standardizing its practice within the organization can be of benefit to everyone involved. At the end, I will discuss the two blockers one can face when trying to spread the practice.

The promise of Project Management:

“Today, project management is more than a position or a career. It has become a mind-set, and it turns up in every corner of the business world. Every company is trying to manage its resources as closely as possible and project management is an essential part of that effort” - Project Management For Profit, Joe Knight 2012

In one sentence, the discipline of project management is about acting preventively, proactively and responsibly when leading a project. While great PM still has many intangibles related to human interactions, intuition, communication, talent, the discipline has evolved from magic to science, with tons of best practices, patterns and processes.

So, before asking yourself whether you need PM in your organization, ask yourself if you can afford:

• Multimillion Euro projects being led without a certainty that they will ship on time and on budget.
• Bad reputation of not being able to deliver. Mistrust.
• Poor communication and unhappy stakeholders
• Not learning from past mistakes.
• Not utilizing the investment put in past experience.
• Leaving managers without proper support when they manage multimillion euro budgets.
• Overtime, the cost of burnout or that of leaving personnel.

The promise of project management lies in having a scientific, measurable solution to the problems above. Great project managers are not magicians. They don't have a magic wand.They are trained professionals that you can trust. They will be able to explain you very clearly what value they bring to your organization and how they do it. They will talk about objective measurements, they will talk about process, about best practices. Their promise and their craft is to show you transparently what they do with your money and what to realistically expect in return. In a word, deliver expected results, transparently. Among others, they will talk about:

• Building and managing budgets and plans
• Following completion
• Identifying and managing risks
• Communication and keeping stakeholders happy
• Continuous development of staff
• Organization, structure, process

Why standardize? What if projects are going on well already?

The first question that comes to my mind is "what do you mean by "going well?"". How do you measure it? How do you know that a project is achieving maximum performance in terms of cost, schedule, quality, stakeholder satisfaction, risk, staff development? How do you know that you are getting the maximum from your investment and how do you compare projects?

In order to survive, a company needs to lead. Leading companies are the ones that have the initiative, the vision and the means to succeed. Profit and talent follow the leaders. Ideas worth nothing without being materialized, so leaders excel at execution. As PM sets the framework for delivering results, leading companies have PM as one of their core competencies - either explicitly or implicitly. Leading companies:

• have trust from our peers (ship on time, stick to commitments)
• learn from their past experiences
• secure the learning process and reuse it in future projects
• secure the talent
• optimize talent usage
• optimize budgets and timelines
• predictably deliver value

The promise of standardizing project management is to achieve all that, including:

• induction of newcomers to PM (and not only) and short, predictable ramp-up for them
• easier access to PM knowledge and lessons learned
• less burden on project managers who do not have to reinvent the wheel (processes / forms / metrics)
• a baseline for common understanding and expectations
• tracking of performance based on objective measurements
• continuous improvement

Above all, it shifts the emphasis from magic to science and process across all projects. Because of this extra transparency, everyone with an interest invested in the well being of the company have only to gain:

• Company management
• Visibility on progress
• Trust in their teams
• Less administrative burden
• Extra value added for customers
• Project managers
• Lessons learned
• Proven, transmittable processes
• Knowledge base
• Standardized forms and metrics - not have to reinvent them
• Simplified induction of new PMs
• Learning and sharing among PMs
• Team members
• Continuous learning
• Visibility, clarity, predictability, security
• Ground rules
• Trust in the company
• Customers
• Trust
• Clear deliverables
• Clear expectations
• Clear view on progress
• Involvement

Therefore, I personally do not see any reason not to standardize PM across all projects within a company or department.

What stops companies from standardizing their PM practices?

I believe that the blockers lie mostly in two areas:

• Misunderstanding about the role and the job description of the PM.
• Resistance to change.

Unfortunately, PM is a very misunderstood practice. I have seen a lot of people calling themselves project managers when what they really did was process work. The person who is providing the same technical service, over and over, to multiple projects is not a project manager. There's no such thing as office project manager for someone who is doing office maintenance work. I believe some people add "project manager" to their title just because it sounds nice, without knowing what it is about and contributing to global misunderstanding about the term. Doesn't help much either the fact that projects vary widely in size and impact, ranging from school-type assignment to multimillion, multinational enterprises.  Thus, in real life, the term "project manager" has been diluted and it does not say much about what the person's expertise is. To counter any doubt, I believe that it is up to the true PM professionals to explain what they do and by what metrics they should be measured.

Other than that, even in well established project organizations where PMs drive significant projects, it is not always clear why the practice should be standardized. Instinctively, nobody wants a new manager, nobody wants to be directed on how to do his / her job, nobody wants audits and process rigor. It seems easier to escape in the fog of "the magic practice", without clear measurements and standardized processes. Even more, as standardizing involves more work in the beginning (after all, it is a project per se), people are reluctant to take it on when their schedules are already fully loaded.  PMs would need to learn more - which is not always comfortable - and be evaluated on new metrics - on which they may not succeed that well. All these trigger the resistance to change especially in the people that would benefit the most from the standardization.

Standardizing PM is a project per se.

In order to succeed in standardizing PM, proactive managers should convince top management about its benefits and gather support for their project. They need a strong sponsor and an experienced PM. They need to provide a plan, they need to provide metrics for measuring success and progress. They need to have an approved budget and time for the people involved. Standardizing does not come free, as it requires employee time, trainings, materials. Its objectives need to be very well defined and monitored and have a designated responsible with enough power to set things in motion. Of course, it needs to be properly managed so that it becomes a success story, an example of a "perfect project" for the organization. 

Companies need to be aware that standardization is not a one-time effort. After all the practices are set in place, a budget should be allocated to maintain a structure to monitor continuous deployment of PM internal standards, audit projects, evaluate PMs, archive lessons learned and dispatch them, train new employees and evolve the practice within the organization. As with everywhere, quality, security and trust come at a price. The good news is that the price should be far less than the benefits.

Good luck! :)