I was so hoping to learn something new!

September 26th, 2011

But did I?  I just finished reading Terence Brake’s book, “Where in the World is my Team?”.  I was intrigued by the reviews saying it was not a regular business book, and of course the topic of virtual teams, so I decided to pick it up.

If you are not familiar with this book, indeed, it is not like usual business books in that there are actually points in it that will make anyone laugh. At the beginning, we are introduced to Will Williams, the new assistant to the CEO at a gaming company, The Fun House.  He is working in London, but there is a whole host of characters all over the world, with whom Will interacts. Will is tasked by his CEO, to put together a Briefing Report on the new workplace, working virtually, technologies that aid the new workplace, etc., for her upcoming TV appearance.  The readers “learn” along with Will, as he wades in to the new workplace.

The set up having to go through Will’s introduction in to working with virtual teams is a bit much, having to go through each of his meetings, and his personal feelings on meeting with his ex-girlfriend or the “interesting” analyst, whose work Will never bothered to read, dealing with his parents, his new love, etc.  But you really can’t skip any part of the book. The dialogue of a relevant conference call talking about ways to improve communication in virtual teams may be between a few paragraphs about the crazy analyst or Will’s colleague in the next cubicle.  You can certainly skim those parts though.  By doing it in real world fashion though, every reader, who has worked in global virtual teams will recognize similar mistakes they have made as they have learned to work with virtual teams.

Many of the points made in the book, building virtual trust, communication, etc., have been stated in other books, but I do like the diagrams that are used to show the different points.  For example the Collaboration Controller is good.  I also like the diagram on pg. 25 on virtual trust and its different aspects.

Some of my favorite points include:

-    Being in a virtual team, and especially leading one, means communicating when you don’t have to – not just when you want something from someone.  Only when you want something makes it very shallow relationship.  Do you know anything else about them?
-    Also under process I like the emphasis on the transition from establishing a relationship to going in to the task.  The delicate balance between these two processes – of course I did not see in the book any details about how to actually do this transition.
-    Working in isolation, means less communication which builds paranoia, people get anxious.  Which I have talked about many times.
-    The confusion caused by vague communication, lack of transparency, etc.
* I like the example given – an American to a Brit – “I created a “straw man” agenda for the upcoming meeting, and I have a “hard stop”, at 3:00pm”.  What does that mean?  Writing something like, “I created a preliminary agenda for the upcoming meeting and I have a deadline of 3:00pm, can you provide feedback until then”, would do.  Why do we write in the first way?  I think a lot of Americans can relate to this example, we tend to use a lot of buzz words and are almost judged on our use of them.
* I also like a lot of the comments in the book, such as why do we waste time being vague…..as there is enough distance between people!!! It just leads to a lot of second guessing…..and the need to communicate a lot more in the future….

-    With virtual teams, problems can easily be blown out of proportion!  – so true!!!
-    I like the emphasis on understanding the purpose – the book puts it out on the “purpose” of the team, or the “why” the team is doing what it is doing.  I have always liked the emphasis on the “why” as to “why” the users need to work the way they do, why the system needs to work in a certain way, but I like the emphasis on “why” the team has formed.
-    Team members tend to side with those who are located closest to them
-    I like the list of 10 Behavioral Rules for The Fun House –  10 rules I think are great for any team!

About halfway through the main portion of the book (and one too many paragraphs about Spinks – read the book if you want to know who this is), I decided to skip to the Briefing Report located in the appendix,  to see if something could be learned from reading that portion of the book only.

There are some points that I think could stand on their own if a reader was looking for a quick reference.

-    The Collaboration controller chart on pg. 187, I like the outlining of the challenges and how to counteract them.
-    In general good parts on the 6 items that make a team work well
-    Section 3 on Cooperation is good – similar to other books though, especially on giving and getting trust.
-    The general pointers part of Section 3 is good – pointers for building cooperation, although also ones you can see in other books.  But at least something you can read quickly and get some ideas.
-    Good questions for testing your readiness for managing the team and for testing the preparedness of the team members
-    I like the cultural intelligence section, section 8.   The Worldprism™ model

“Where in the World is my Team”, is certainly not an ordinary business book and it is not dry, so it is something new. One of the negatives I have often found with many of these books is the lack of real life examples.  “Where in the world is my Team?”, provides those real world examples (of course changing the names to protect the innocent!).  The bad part is that you can’t skip significant sections of it or easily hone in on sections that may be relevant to your situation.  The information comes to you in bits and pieces through reading the dialogue of conference calls, or reading email exchanges that Will has engaged in.  It is an easy read and, and I hate to say it, but I found myself wondering what was going to happen to Will’s father, but at the same time I was often frustrated with all of the “filler” stories and was skipping ahead when I could. However, if you are new to working with global teams and with virtual teams, this is a great first book to pick up. Why pick up a regular business book, when you can have a “story” to go along with it!  If you are more experienced, you can still pick up new points, you will just have to wade through a lot of “story” to get to them.

A “Twist” on Trust and “Drinking Your Own Champagne”*

August 23rd, 2011

We talk a lot about trust when building relationships and the added importance of this when working at a distance. When you start out working with a new team or person or persons, who are remote from you, you are always wondering if they are going to get done what they said they were going to get done. Are they really working over there? Trust builds over time as they start to deliver product and start to prove themselves. But this makes me wonder, in addition to technical skills, domain expertise, etc., are there other characteristics of your potential service provider that you can be looking for?

There has been a lot written about the type of characteristics good virtual team members should have; communicative, willingness to share, etc. But most of what has been written comes from the view that everyone, or almost everyone, is working alone, but in different locations. Often, however, that is not the case. It is more likely that several persons are working together in multiple locations; a group of three here, a group of two here, a group of ten here, several persons working alone in different locations, and so on. This will be the case for you when working with a new vendor. They will have multiple people, most often in one location, and you will have multiple people on your side, working in one location. Having multiple co-located groups which need to work together brings on a different dynamic than having everyone working alone in their individual locations. People working alone (usually but of course not always as it depends on the person) are going to be more likely to want to share and find out what other team members are doing, and find out about those other team members, because they have little or no social interaction with other team members where they are located. When several persons are co-located, it can be much harder to get them to want to work with other distributed teams unless there are specific processes put in place for sharing information and for getting to know each other.

It is a given that most of your team members, from your service provider, will have experience working in a distributed manner with other clients, before starting to work with your company. But how do individual team members really feel about it? When you talk with individual team members, asking technical questions is of course a given, but there may be some other questions you will want to ask: “What would you do if you had to work in an office by yourself, and the rest of your team members had to work in another office? How would you get your work done?”

It is not something you think about often, but you would be surprised how many would answer, “having to work with a group in a different office is too hard!” Or another answer you may hear is, “it is easier to work with someone sitting next to you”. What??!! If they have that attitude, do they really have the right attitude to do what they are asking you to do, which is work at a distance?

It is like Oracle not using its own products or Google employees using MS outlook for their calendar….. If they can’t believe in themselves enough to get work done in a distributed manner, within their own company, how can you expect them to get your work down with your company in a distributed manner? Think “eating your own dog food” or “drinking your own champagne” (the latter of which has a more pleasant appeal, at least for me), but for service companies.

So the question is, can the fact that a service provider “drinks its own champagne”, help you?

Does it mean they are trustworthy? Certainly it is not a 100% guarantee, nothing is, but it does show that they understand what it will be like for you. They have internal practice at dealing across locations, as well as experience working across locations with their clients. It can go a long way towards your feeling like you can give them trust. They should also be able to help you better transition to working in a distributed manner.

And really would you want to work with a service provider who doesn’t do, or hasn’t done what they are asking you to do; i.e. give up control, and work remotely?

*Reference “Drink your own champagne” – http://en.wikipedia.org/wiki/Eating_your_own_dog_food

Know your Audience!

July 27th, 2011

Edward T. Hall, an American anthropologist, once said, “Culture is Communication and Communication is culture.”  I usually like to deemphasize cultural issues when relating to software development projects, as it tends to be used as an excuse for why a project can’t be completed or why the project is too difficult to do, however, when talking about the communication portion of culture, I think there are steps that a US software development manager can take towards making themselves more understood and getting their message across, to their development team located in another country.  An important aspect to remember about communicating with a development team in another country is not that they understand or have the right technical skills, and use the right acronyms in the right place, but it is for the development manager to remember the key communication mantra, “Know your audience”.

More people outside the US are exposed to the US culture (either the right or wrong version…..) through American TV shows and films that are widely distributed. However, just because someone knows about Survivor (and most likely their own country has its own version of this show…), or has seen “The Office”, or “The Social Network”, it doesn’t mean they know everything about Americans or understanding American English.  Especially in the US business world where a lot of slang is used, with a lot of references being made to sports which are more widely played in the US than in most other countries (such as American baseball or American football).  When talking with your development team outside the US, it pays to think about what phrases you may be using which may need to be explained. For example, telling your developer he needs to “step up to the plate” when you really want him to take on additional work, may not get you what you want.  Or telling a developer who is critiquing a design choice, not to be a Monday morning quarterback, may not stop his input. Some of this type of conversation comes up in “face-to-face” (be it real face-to-face, or online face-to-face) meetings or these phrases may come out in group emails. Certainly your remote development team will be glad to be included as “one of the team”, just be aware that you may need to circle back and make sure that everything was clear to everyone receiving your message.

Effective communication is not only about choosing the right words and phrases to use, but also about being aware how that information is understood by the recipients.  So remember to know your audience!

Inventing work? What is causing your software development projects to go over budget?

June 22nd, 2011

Last month I read an article with an interesting statistic, 77% of the people surveyed said that their vendors had invented work for profit. An alarming statistic if buyers have the impression that the people working for them are just creating work out of thin air.   Sounds like a definite governance issue. But then if you think about it, it matches the still ever present statistic that about 75% of IT projects fail, and of course the primary reason why the projects are considered a failure, they went over budget!

So why do we still have projects that go over budget?  I took an informal poll myself on this issue, and the general consensus was not that work was being “invented” but that more work was added in than was originally expected.  Or the ever popular “scope creep”.

So why do we still have such an unrealistic view of the amount of work that needs to get done? In the case of outsourcing a service, it is often because there was not a good understanding of all of the work that in-house staff really had to do in order to provide the service.

But if you are dealing with a software development project for a new system, or replacing and improving an existing system, things can get more complicated.

So what do you do for your next development project?

#1 – Surrender to the fact that changes will occur. Once part of a system or product is able to be looked at and played with, it is easier to see how a function could work better, or how the users of the system could work more efficiently, and suggestions for changes will start rolling in. Accept it.
#2 – Surrender to the fact that compromises will have to be made. Priorities will have to be set as to which changes can be done when, what can be taken out of the current project and moved to a future update, etc. Not everything can be a top priority. Time and budget are always going to be limited. These adjustments will need to be done continually as part of the process of making the best product for the market and for the users.

#3 – Surrender to the fact that a plan for handling changes during development is going to need to be in place. A discussion has to take place between yourself and the vendor. They should have a process that they use for handling changes within the development process that they are using, and that may work for you, but make sure you know how changes will be handled and that you agree with the process.

If you are realistic about the fact that change is inevitable, realize that priorities will have to be set and actually planning for changes, it will go a long way towards eliminating projects that are “out of budget”.

Business expertise versus technical skills!

May 24th, 2011

In talking with a group of product managers recently about working with distributed software development teams, where part of the team was in the US and part of the team was in an offshore location, there seemed to be a big consensus that one of the most difficult issues in working with the offshore team was getting them to understand the “business side” of the system.  For example one person was very vocal about the issues with the developers in the offshore location not always understanding why the payment system needed to work in a particular way, or why the users needed to work in a certain way.  Other examples came up with billing systems and with the developers not understanding why sales commission had to be calculated in a certain way. This got me to thinking as to why this could be occurring?

According to the group of product managers the reason was specifically based on the fact that we are exposed to “how certain things” work more often in the US than in some of the offshore locations.  I agree this can be a factor with understand such things as “calculating sales commission”. Well at least the basics of calculating sales commissions, because as many people know there are many many ways to calculate sales commissions. It can greatly vary by company. So any developer would need to know what is the algorithm/s used by the company. 

After thinking about this question for a while, I started to think about how many companies search for outsourcing partners. A top priority for many companies is technical skills, which of course are very important when choosing who to work with. But I think sometimes technical skills are given a higher priority than if the outsourcing partner has related business or experience with your vertical market.  For example if your company is in the payments space, working with an outsourcing partner which has experience in that space will go a long way towards helping to overcome issues with understanding how the system has to work. Many companies when they start to look for a partner, are thinking, well we have the domain expertise, we are the experts, which is definitely true, and we can help pass that expertise on to anyone that we work with.  What we don’t have is enough technical skills.  If a company makes a concerted effort to pass on the needed domain expertise then the combination of your side having the domain expertise and the vendor having the technical skills, can work. However, in a distributed environment, passing on the domain expertise will take more effort, and it is easy for it to fall by the way side. It seems to make sense then to give, if not equal weight to both business domain expertise and technical expertise, then at least put business domain expertise in a close second place, when choosing a partner to work with your firm on software development.

I have a dream! Or at least an idea!

April 21st, 2011

Question:  I have an idea for a new business, and I need a software application built to provide my new service, but we need to move fast.  Can we really build this  with a remote software development team?  Especially a software development team in Ukraine?

Answer:  Today VC’s would tell you that you should be able to get all the talent you need locally. That may be the case depending on what type of skills you need, and it certainly will really help if you have received a very good sum of investment.  However, for most would be entrepreneurs this is not the case, so are they out of luck if they can’t find the help they need locally?

Indeed they are not out of luck!  It is very possible to build a new company using a remote team and have your software application built by people working in Oregon, or South Africa or Ukraine, or anywhere else around the world. What is needed most is the willingness to make it work; on the part of the entrepreneur and on the side of the company or persons who are building the software application. Is everyone on board with making it a success.   

To get started:  When you are looking to bring your idea to fruition, in the early stage you, as the entrepreneur, may be in need of a version of your software to give potential investors a chance to get excited about the app, or to get potential clients onboard as early adopters (and earlier payers!). In other words you may need a prototype showing just enough to get the target audience interested. At this point you can work with a company or persons  who can help you to determine what is that minimum you need to show, and how it can be done quickly so you can get on your way.  This type of collaboration can certainly be done online, via tools and even what may seem outmoded to some…..the telephone (or whatever voice communication tool you may like to use). The important thing to remember is that a prototype is not everything that you want to put in your product, it is those key items that you need to show only. The key functions also do not have to “fully” work.  Many functions can be “forced” to work in the background and just give the appearance of working. Why fully develop alot of features only to find out they are not really what potential clients will want. 

With your prototype you can then receive validation by potential customers and users and certainly alot of feedback about what they would like to see in the product, and hopefully signed contracts or agreements to buy as well! At this point you may also be talking with investors who will need technical details about how your final application will be built, the cost to support and how it will be supported when the full version is up and running.  You may also have potential clients who need this type of reassurance as well. Your partner company or persons building your application can certainly provide this type of support no matter where they are in the world. Hopping on a conference call as needed. 

With hard work by the entrepreneur and the remote person/s working with him or her, and a bit of luck that every entrepreneur needs, after validation potential clients and investors you can work with your remote team, which is now experienced with your idea and its direction, to build your alpha version and the beta versions of your product.

Summary: 

1.  Remember the most important aspect to making it work as an entrepreneur with a remote software development team, is the desire to make it work! 

2.  Pick a team or persons who are used to working remotely, used to working with entrepreneurs and can help you to decide what needs to go in to a prototype, what can be put off until an alpha version, etc. Then ongoing what do you need to support your application during the various stages of company development.

Business case changes the reason outsourcing relationships go wrong?

March 27th, 2011

I was reading an article earlier this month about business cases and outsourcing and some of the typical reasons that outsourcing agreements go awry – http://preview.tinyurl.com/outsourcing-business-case. The article was based on a study done by the Outsourcing center (http://www.outsourcing-center.com), which looked at 140 outsourcing relationships; long term relationships during which certainly the business case was going to change over time.  The author, Kathleen Goolsby, a senior writer at the Outsourcing Center has been writing about outsourcing relationships for more than ten years. I find her articles very informative. 

In this one she reviews the most common reasons that the outsourcing relationships, from the Outsourcing Center study group, went wrong and give some possible suggestions as to what can be done to solves those problems if they occur in your outsourcing relationship.

The reasons the outsourcing relationships went wrong, as cited in the article include: 
1. Resource allocation – on the part of the provider, they did a poor job of planning.
2. The buyer’s business model changed – changes need to be made to the relationship and agreement in order for the buyer to remain competitive. 
3. Multisourcing environment – if the provider is subcontracting some of the work and not all of it is within their control or the buyer is working with many vendors and does not have control over all of them. 
4. Attrition – when the service provider is experiencing a lot of turnover.
5. Changes to the pricing model – in this case they refer to affects to both parties if their fiscal years do not overlap, this can affect compensation for the provider. 
6. Changes in IT business-case assumptions – changes in required technology due to changes caused by the market. 

I think I might add one more reason to this list. One that starts before the outsourcing relationship begins and continues as the project goes on. That is – was enough time and therefore enough money put towards making sure that all of the people, within the buyer organization, that need to be involved with the project, are onboard with what needs to get done and is there enough time for them to do what they need to do. Was there actually enough time built in to their schedule for all of the work they need to do on the project: time to review what they need to, to do what work they need to do – whether that is time to compile information and data at the beginning of the project, to review product as it is delivered throughout the course of the relationship, or time for integration when final product is delivered. Also was enough time and money put towards ongoing reinforcement/communication of the reasons for the outsourcing relationship and its corresponding business case. If this was not accounted for before the project and relationship started, there will definitely be some hiccups at the beginning and both parties will have to get together and discuss how to overcome this issue, how to make changes so that the necessary people are able to be fully involved and that all of the necessary work gets done.

Here goes a review practically longer than the book!

February 23rd, 2011

On one hand there are certain expectations when picking up a pocket book on any subject. I expect some quick tips, checklists, something that I can quickly peruse and refer back to easily. I picked this one up since it was published in 2010 and published by Harvard Business School Publishing. 

My first impression was not good!  Why does a small pocket book, which by definition does not have a lot of room for details, have to go in to “what is a virtual team and why they are becoming more prevalent…….”.  Even if you have never led a virtual team, doesn’t everyone know this by now……   I did pick up a new term though in this section, ”same-place team”. The definition is obvious from the words, i.e. a team where all members are in the same location but I was under the impression that the more common term to use for this is co-located team (A quick scan of google I think corroborates this impression. Googling “same-place team” I get no results, versus the pages of results I received when I google’d “co-located team”.  But not a key point, it is understood.)

After the “Why Virtual Teams” chapter the book does become more helpful. The section on steps for communicating with virtual teams includes “planned spontaneity”.   Agreeing regular times to talk, and everyone knows we will be on the phone or online at such and such a time. Also open for chatting online times which can substitute for the “gathering around the water cooler scenarios”.  Also it includes key items such as agreeing, do you expect someone to respond to an email that you send on a weekend? 

Another important key scenario the book did address is when some workers are co-located and some are virtual, which is a very common situation.  Or even multiple co-located members and multiple virtual members. Sometimes it is easier to manage a virtual team when all team members are virtual than when there are multiple co-located members. It is easier for team members to care about their other co-located members than to worry about the team members located elsewhere.  The individual remote members will be more interested to know what is going on in the different locations because they are usually working “alone”, whereas the ones who are working with a team of two or more in their location, they will tend to be less active in worrying about who is in the other locations.  For these situations the book makes suggestions of how to ease the “isolation” or remote members and get the co-located members involved in helping with those situations. 

Other points I like about the book; I do like the “scenarios” which involve asking the reader what they would do in a particular situation (very realistic situations) and the mentors (authors) provide answers in the form of “what you could do”.  I also like the “Test Yourself” chapter at the end of the book under Tips and Tools.  It is better than most of these “tests”, the scenarios are more details. 

Now on to what I do not like about this book. Again and again I see this in virtual team books, the suggestion that the first meeting with a team, if at all possible should be face to face.  But rarely, if ever, have I seen suggestions of how to do the kick-off meeting if you and your team are in the more common situation of, we can’t do a face to face kick-off meeting, but we still have to start the project somehow.  Where are those suggestions? In this day and age most of what can be done face-to-face can be replicated with online tools. It may take more online meetings to replicate the face-to-face, but it can still be done.  Additionally the Tips and Tools section includes a section of “document layouts” to use for contact information, setting up a virtual team, identifying roles and responsibilities, etc.  The documents, in and of themselves, are just fine and useful, but I would think, given the fact that this was written just recently, that these would be translated now in to an online form and shown that way.  However, this may have to do with the fact that when I look at the references at the back of the book, there is only one article from 2006, most are from around the year 2000.  And the latest source for the book is 2000.  Technology and its use in virtual teams is not a strong suit for this book.  Hence the book was “compiled” recently, but based mostly on old sources.

The idea of a pocket book is one that you can quickly refer to for helpful hints or lists, etc.  (Well besides being one that you carry around in your pocket!!)  Is this, that kind of a book?  No not really. It is a good quick read if you are new to virtual teams.  The scenarios are helpful, the “test” of your knowledge of virtual teams is good, but could you refer to this book again and again.  I think not.  You are better off to make use of the “Quick Guide to Interaction Styles and Working Remotely: Strategies for Leading and Working in Virtual Teams” -     http://www.amazon.com/Quick-Interaction-Styles-Working-Remotely/dp/0971214476/ref=cm_cr-mr-title

“Leading Virtual Teams – Expert Solutions to Everyday Challenges”
2010 Harvard Business School Publishing
http://tinyurl.com/5vbnhhs

How do we get remote team members to take responsibility?

January 20th, 2011

How do we get remote team members to take responsibility? It is a common enough question, but is there really a difference for getting this done for remote team members versus team members who are co-located with you. I don’t think it makes a difference. How you do this is the same whether the team is co-located or whether they are remote. The issue is usually having a good management process.

Tips for helping to get your team to take responsibility:

#1: Clearly define who is responsible for what tasks. It is great to have a meeting with the whole team, discuss all of the tasks, what needs to be done, etc. But don’t end the meeting without clearly stating who is doing what. That can be done by having team members volunteer to take on certain tasks which are within their skill set, or “volunteering” someone if necessary. Every project/every task needs an ultimate responsible person.

#2: Clearly define when a project/task is due. This due date may be set because of outside forces; a promise to a client, a government requirement deadline, or other. Or you may have the opportunity to give the responsible person time to look closer at what needs to be done and to estimate the time it will take to get the task done. If that is the case, set a deadline for when the estimate needs to be done.

#3: For longer tasks, periodically check in to see how it is going, rather than waiting until the final due date for the whole project. Many managers do not like to do this because they feel it is micro-managing, or if they ask, they ask a very “generic” question such as, “how is it going?” which often elicits a standard response of, “ok”. How the “checking in” is perceived and how effective it is, depends greatly on how the question is asked. Common ways people ask about tasks include, “did you finish xyz task like you said you would?” which gives the impression that you are already thinking they could not have finished the task. Or a manager may go to the other extreme and just ask generically, “how is it going?” which may elicit just an “ok”. Try instead, as the project is going on, asking about specific tasks, “How did that research on xyz tool go that you needed to do? Did you find out what you need to?”. Asking in this way can help you get more information and more of a feel for how things are going rather than putting someone on the defensive.

#4: Make sure there are consequences for missing deadlines. Don’t let missing deadlines become a habit. There may be valid reasons for a deadline to be moved; a requirement absolutely needs to change, chosen technical design won’t work, etc., but in these cases the deadline should be moved before the original deadline is reached. The responsible person should know that the deadline needs to be moved much earlier, not at the last minute.

As the manger of a remote team, you are responsible for making sure that your team is as productive as possible. It starts with you. Being clear with what needs to be done, by when, and by whom, and then holding team member responsible, goes a long way towards making your team very effective.

Do we choose based on location?

December 19th, 2010

It had seemed to be a trend for quite a while to worry less about location, and be more concerned with what the vendor can provide you with and do for you.  A recent article in CIO magazine confirmed this  with the CIO stating very clearly that they chose their vendor two years ago, not based on location (the location was China) but based on the fit of the vendor with their company.  “Our selection was based on the qualities of the IT services partner and whether they met our specific criteria rather than the location of the delivery center,” according to the CIO.  But still I have been seeing many reports talking about particular locations lately.

So what can you get out of looking at a location? 

Below I look at several areas traditionally used when researching different locations where to work. I list characteristics for each area that may be affected by the country, and how companies in other countries will try to mitigate this being an issue in their country. It may give you something to think about the next time you are looking at who to work with. 

-          Educational infrastructure and levels: 

  • Affected by country:  Types of education offered, traditional areas of education, who gets educated and who doesn’t, overall literacy rates.   
  • How do companies mitigate:  There are ways to replicate necessary IT education quickly.  Companies have been doing this for decades, putting people through express technical training for so many weeks or months. Quickly giving people the skills necessary for competing in the industry. These skills may be good enough to let people go a long way in the industry. 

-          Time zone:

  • Affected by country: This one obviously is affected by the location and can work to the benefit of the buyer; is one location more convenient for you to work with over the other; based on overlap of work hours, or one company workingat one is not going to change. Do you have a specific requirement here

-          Language skills –

  • Affected by country:  Countries can have more education in foreign languages than others or offer complete education in other languages giving people a lot of experience working and living in other languages. Accents can also be affected by native languages; as to whether or not they are easier to understand in other languages. 
  • How do companies mitigate:  Vendors everywhere work to mitigate languages issues by pushing foreign language training (the actual languages will depend on location); both internally and externally. 

-          Cultural fit: 

  • Affected by country:  Differences in style of how management is perceived, speaking up in meetings, giving opinions and suggestions irregardless of level within the company. The educational system and structure can also play a role here. 
  • How do companies mitigate: Company culture can mean a lot and also help to mitigate cultural and work fit issues. 

-          Government support:

  • Affected by country:  Could be in the form of: support for the development of certain industries with lower business taxes or lower personal taxes for specialists in that industry.   Also could be support for education development. Each of these could result in better resources for the industry or lower rates for buyers for example.  It can also get an industry “started” by providing specific support for it. 
  • How do companies mitigate: Government support doesn’t guarantee the “most qualified” resources, and too much support can even affect how adaptable a company is to changes in their government’s support. 

-          Political stability:

  • Affected by country: Political issues that may affect a vendor’s work may include” closing access to foreigners coming in the country, or making it more difficult for foreigners to come in.  Revolution shutting down the work of the government. 
  • How do companies mitigate: Any good vendor is going to develop their strategy taking in to account the political strategy of their country. They will target those buyers to service that are not as concerned about visiting their location, or do not need to visit the location, for example.