I recently published an article on the famous Dutch IT magazine ‘Computable‘. In response to this article, I received some questions from Reza Sarshar of interaccess. The questions are interesting and I want to address all of them in this article. 

1. What is the utility of offshoring?

There are many benefits for companies engaging offshore resources. The extent to which each applies to your company depends on whether you set up your own offshore office, work with a supplier based on fixed price/SLA, hire dedicated people from a supplier or work with freelancers. In general the benefits are (and please add to this if I missed something):a. Engaging talented people (access to a big labor pool)
b. Flexibility in scaling up and down (no long term employment contracts)
c. Ability to grow your company and (software) products faster
d. Lower costs
e. Flexible cost structure
f.  Focus on core activities

2. How to approach offshoring?

This question is hard to answer in a short article. I believe the first fundamental choice is whether you want to set up your own office or work with a supplier. In my experience, setting up your own office works for big companies and takes too much focus away from the core business for SME’s. Working with a supplier that has the right people and gives you guidance in how to manage people on a distance gives you a fast track to success. 

Once you have decided on the basic setup, there are 5 key success factors:

a. People: The most important factor in building an offshore cooperation is to select the right people. 
b. Process:  All people need to have a common understanding of ‘how we work’
c. Preparation: Take the time to prepare everything well and don’t rush into it
d.  Profit: Monitor continuously whether the cooperation is delivering results
e. Performance:  Regular evaluations of the team members on aspects like productivity, quality

3. What is the effect of offshoring on your business model?

I will answer this question from the perspective of my own typical customer: a web or software company. The impact on a few parts of the business model:
a. The way of working: people need to create a structure, process and way of communicating that supports working with people on a distance. You need more structure than with people in one location. And this has a positive spin off on the whole company. An example is one of our new customers, an internet project company from Holland. They were used to do all communication through email. Right now, a need to feel in ‘control’ of the progress of a project (which they usually did by talking in the corridor) arises. For this purpose, they will start using an online issue tracker. If this works well, they plan to use this in all their projects and maybe even give their clients access to the system. This improves their added value towards their clients. 
b. Speed of delivery: you can engage more people to your projects when needed, so products and projects get launched faster
c. Cost structure: the costs of programming go down, leading to more profit or a lower price for the end customer
d. Flexibility: engaging more or less people in the production, which also impacts your cost structure. Employees keep receiving a salary. External contracts can be stopped when needed.
e. Beyond technology: my own company employs some marketeers from India, does part of the lead creation/sales process from India, invoices are sent from India. Once you have the technologists in place, you can further change your business model. You also get access to the local markets where you may be able to sell your products or services.

4. What are the pitfalls of offshoring?

In my experience all pitfalls can be grouped into 2: 
a. Hiring the wrong people. I believe many companies make the mistake of looking at offshoring from a company perspective: they send a big RFP asking how many people work in the office, what technologies they know, etc. Although you do need to know this, eventually your work gets done by people. And you want to hire the best possible people, so you want to have a voice in who’s working on your project and you want to communicate directly with them. 
b. Miscommunication. Assumed that the people working for you are the right ones, things may still go wrong if communication contains flaws. Software development in itself is already hard, essentially because it is hard to know upfront what needs to be developed. And if one person knows what needs to be built, the next person may understand this in another way. Add to these complexity different locations, time zones, language and cultures and you’ve got a mix of factors that affect communication. I have written an article about this earlier. 

5. What is the influence of the cloud on offshoring? 

I wrote an article about this last year. My general thought on this is that we will always need people to produce software. Of course things get automated, the cloud gives companies access to software on demand as they need it. But still the systems need to be built and still there will always be companies that believe they need their own systems.  

Managing global teams requires a solid structure and the right (software) tools. I often get the question what tools we use in our company. I am always surprised when I show someone our project management tool, what impression it makes on them. To me, it seems common sense to have such tool, but for people without experience in offshoring, this is not so common at all. 

The goal of using tools is to maximize structure. Software development is complex. Human behavior is complex. The tools should make the software development structured. And they should help the people involved to show behavior that leads to the desired results. This second element is the biggest challenge. Software development is a creative process, not factory work. So we need creativity from people and at the same time, we expect them to behave in a specific way.  

So what tools/ingredients do you need you to facilitate global team collaboration? 

1. A documented process that answers ‘how do we work’

I believe this is the starting point of any global collaboration. Before the train starts driving, everybody involved needs to understand ‘how we work’. This process needs to be both documented AND supported by everybody. The process also needs to be reviewed and improved continuously. It would be useful to have an online process building tool for this, which I have not found so far. Word documents also serve the purpose here. 

2. Project management tool

An online tool that enables the team to manage everything within a project. Such tool should include seperate elements for:
a. Storing requirements documents
b. Managing tasks
c. A bug tracker
d. A planning module to plan and track progress
Some popular project management tools are: Redmine and Jira. More simple bugtrackers include Bugzilla and Mantis.

3. Skype or another video conferencing tool

This may seem obvious but many people without experience in offshoring are not so used to skype. It’s crucial to stimulate human interaction, so the (group) video functionality of skype helps there. The team needs to see each other regularly for both bonding and project discussions.

4. Time registration + reporting

People sit far away so it is hard to understand what specifically they are doing. Time registration can help us out. Programmers can register the time spent on certain tasks/bugs/projects in an online tool, which can be reported once per week to the onshore project leader. It is also useful to have a weekly analysis of the time spent, so the people understand how and why time is spent from both sides. 

5. A version control system

The most commonly used tools here are subversion or CVS. Usually this is installed on a webserver and people from each team commit code to the system at the end of their working day. Another, which integrates for example with Redmine, is GIT. 

6. A coding standard

Although this may seem logical, many companies are reluctant to have coding standards, let alone follow them. With different people on different locations working on one project or system, it’s crucial that everybody knows ‘this is how we expect you to develop software code’. The coding standard needs to be clear to everybody and it’s helpful to check the code regularly to ensure that people stick to the standard. 

7. An overview of responsibilities

Who’s doing what? Who is accountable for what? Even if people are working in different companies, it is helpful to create function profiles that give an overview of what is expected of each person. 

 8. A performance measurement system

If you are building a long term cooperation with an offshore team, it’s important to give them feedback on their performance. The best is to treat them like they are your own employees. Examples are ‘asks questions when requirements are not clear’, ‘communicates ideas for better solutions’, ‘is proactive’, ‘makes deadlines’. You can rate those on a scale of 1-10. It’s also useful to ask the offshore team to give you feedback on certain factors (e.g. provides clear task specifications, communicates expectations clearly, assists in technical problems). It is helpful to use an online survey tool (e.g.surveymonkey) or use some custom built system for this. 

With such tools and systems in place, the work is facilitated. Behavior gets structured, feedback is given and the team gets a feeling of ‘control’. And still there is a lot of space for human behavior to deviate from the expected behavior. Maybe you have some tools or methods that you can add to this list? 

The IT talent pool available in India is highly skilled. These educated IT professionals are good English speakers. They always attempt to go that extra mile in cross-cultural communication to understand customer’s needs when working in an IT offshore project.

All offshore IT projects begin with a transfer of knowledge. This activity between stakeholders and developers is not always easy because the Indian developers have been trained in the Indian educational system. The Indian educational system, though imparting superb technical training, misses the mark on communication and soft skills. How can developers and stakeholders overcome this?

Three Possible Solutions:

1. Research the Company

Select one offshore employee to thoroughly research the company they are going to work with. Research what  problem the company is trying to solve through their products, how the past and current products (including the software currently being assigned) solves customer problems and is different than past solutions, what kind of problems they want to avoid in their product roll out, and how customers will interact with the product, among other aspects. Another, often missing element is in understanding the client’s vocabulary. Each discipline and profession has a particular language. What is the corporate lingo? The best customer service representatives know how to talk to their customers in a language they understand. This is irrespective of crossing cultures.

2. Create a Training Program to Deliver to the Indian Team

Based on the research conducted, develop a training module and deliver it to the India team for every project, discipline or delivery to a new customer base. This may seem too time consuming and unnecessary at first. Developers may scoff at this idea thinking they are already experts in their work, and this training is not directly related to their work. This attitude can have detrimental effects. There have been several cases where the offshoring team was not given access to this critical training, resulting in the client abroad cancelling the job within the first few weeks.

3. Learn Soft-Skills

Soft-skill training is imperative for being able to deliver projects effectively. Soft-skills and language fluency go hand in hand. Managers and on-site have noted many concerns after realizing that an ability to speak English does not equate fluency.

Top 5 Communication Challenges Noted by Managers of Indians in Offshoring Projects:

>Use plain, conversational English.

•  Indians are often too formal and wordy.
•  On-site is not always able to understand technical terminology.

>Soft-skills and command of the language.            

• Lack of vocabulary and expressions may limit understanding.
• Use of inflection or clear enunciation while speaking.

>Question / Paraphrase

• Understanding and use of a wide variety of questions.
• Lack of paraphrase skills.
• Use of reflective listening.

>Communication skills

•  Learning to be and to extract specifics.
• Use of “I language.”

>Other forms of communication

• Phone and voice mail skills.
• Best practices for e-mail communication. 

Some of these skills come with practice, while some are cultural-dependent. The bottom line is if the foreign-based team is unable to understand the India team due to a basic lack of communication; the project suffers, less opportunity to maintain relationships exist and overall the benefit for the on-site side is lost.

To avoid these mistakes, invest time in these suggestions and personalized coaching for those employees who would value it most. The cost in short term will seem high, but in the long term, your company and team could see longer lasting projects, assignment of more projects and, better job security for your team and your company. While some may think that these issues are not important as they have not been affected by them, please do not let the illusion of this steer you away from understanding its core importance. Communication skills are a cornerstone to business. These skills are challenged even more when interacting cross-culturally. It is important that companies and their employees take this seriously for their own career development as well as company strategic growth.

Click here to read more about the effective methods of communication for virtual teams.

—————————————————————————————————————————————————————————————————————————————-

This article is publishing under the series “Bridge the communication gap of virtual teams” by Bridge Global IT Staffing. Stay tuned for more article from this series…

—————————————————————————————————————————————————————————————————————————————-

More and more organizations are adopting Agile ways of working. The descriptions of Agile methods give much guidance on how to work agile on the team level. They describe the practices and support the set-up of Agile teams. But there is limited information on changes that are needed in projects to introduce and manage Agile teams. Setting the right project environment is crucial for Agile to succeed. This article provides solutions that help to create and manage Agile projects. 

Difficulties implementing Agile in Project Management

Some of the problems that organizations have that implement Agile in their projects have to do with:

• Fitting agile teams into the existing project management organization
• Communication between and synchronization of Agile (project) teams
• Managing and reporting agile progress in projects 

The problems mentioned here are not really agile problems. They have to do with changes that are needed in the project structure and -processes, and project management for agile to succeed. 

What is Agile?

Agile is a modern methodology to develop software iteratively in teams. The manifesto for agile software development states that the purpose of agile is “to uncover better ways of developing software by doing it and helping others do it”.

The primary purpose of agile teams is to deliver working software. Their focus is on satisfying the needs of their customer, in agile terms the “Product Owner”. All the customer needs are collected in a backlog, described in so called “User Stories”. At the start of a sprint (a block of time in which software is defined, developed and delivered), the planning game is used to select the user stories with the highest priority, and to clarify them. Results of this planning game are a set of user stories and acceptance tests, which defines the software that is to be delivered in the next sprint.

The sprint ends with a “demo”, where the software is demonstrated to the product owner and other stakeholders, and a retrospective where the team reflects on their way of working to continuously learn and improve.

Agile Project Teams

To increase the change that agile practices will bring benefits for the organization, management should give attention to the introduction of agile teams into the existing project management organization. Most projects in non-agile organization already work with teams. So what makes agile teams different?

First difference is the team size. Agile teams consist often 7 people (+/- 2), this since the team members communicate and work together very intensively. I have seen traditional projects where teams were very large up to hundreds of people (one can argue if it really was a team in the first place), and projects with smaller teams of sometimes only 1 or 2 persons (which often are more functions/roles then teams). Agile teams make it easier for project managers to manage on a team level, since interfacing with the team leader only is usually enough to coordinate the ongoing work. So they do not need to stay in contact with all project members. And since teams are also more similar in size, it is easier for project managers to divide their time and attention over the teams.

The second thing that makes agile teams different is that they have the authority and responsibility to agree upon the work to be done, directly with the product owner. This is different from most non-agile projects, where often the project manager is responsible for assigning the work to teams, or even to team members. Since the project manager is still responsible for the end result of the project, the question is how they should deal with agile teams in their project? My experience is that, if the project manager gives attention to a good collaboration and communication between the team(s) and the product owner(s), the project will be able to deliver valuable results to their customers. So they should focus on the relationship between the teams and stakeholders, and solve impediments that are either signaled by one of them, or that they see themselves and consider to be a risk for the project.

Finally, most projects have multiple agile teams. It is the responsibility of the project manager to coordinate the interaction between the teams. Often a scrum of scrums is used for the synchronization of the teams. Also project managers (or in some organizations line managers) can facilitate sharing of knowledge and experiences between the teams, for instance with Communties of Practice.

Agile teams have different needs wrt project management. They expect that project managers understand the agile principles, and support them in their agile way of working. Project managers have to assure that their teams are able to do their work, effectively and efficiently.

Managing and reporting agile progress

Many software development organizations use Prince-2, PMBoK or another project management method to manage their projects. Most often, IT projects are done with fixed time, money and scope. How do this match with the agile approach, that has user stories and planning games, and no fixed scope?

First, fixing time, money and scope is often an illusion. Many IT project fail, resulting in higher costs, insufficient functionality or quality, not meeting the delivery date, or a combination of these. Keeping everything fixed is simply not possible. With agile, it is easy to manage the project costs and end-date. Project costs are mostly the costs of the project team members, and since the size of the agile teams is know, the burn rate can be calculated. When a delivery date is agreed, it is easy to calculate the project costs that will be spend until that date.

What about managing functionality? Agile uses prioritizing of user stories to deliver the most important functionality first. And since agile teams deliver working software in sprints, and continuously improve their way of working, most agile projects actually deliver more functionality then waterfall projects. Techniques like story points and planning poker are used by agile teams to estimate the activities. The product owner uses the backlog to manage the content of project. When reporting project progress, the project manager should show which functionality has been delivered, and (given current priorities) what is expected to be delivered in the reminder of the project. This is different from traditional progress reporting, which is usually based upon milestones or tollgates that are or should be passed. But reporting delivered functionality actually provides better insight in the value delivered to the customers, which makes it easier for project managers and steering groups to manage project results.

Managing projects includes managing the quality of the software. Agile uses the Definition of Done (DoD) to define the required quality of the software. The DoD describes what needs to be done before the software is ready to be delivered, I consider it to be the tailored process description that the team makes and uses to do their work. The acceptance tests, defined during the planning game, state how the software will be validated. Since these acceptance tests are discussed and agreed upon with the product owner, they can also be seen as requirements for the quality of the software.

Summing up, Agile supports managing time, costs, functionality and quality, as required by project management methods.

Conclusions

Managing IT projects with agile teams is different from classical, waterfall projects. With agile, there is still a need for project management, but the role and focus of the project manager changes. When introducing agile in project organizations, enough attention should be given to these changes to assure that teams are to deliver customer value.

More information 

Several articles are available that cover the agile topics mentioned in this blog: 

• Agile Project Management
• Teams, what’s in it for me?
• What Drives Quality: Project Management
• Implementing Agile with the People-CMM

As with anything in the world, there is no holy grail to make something work. In offshoring, there are many factors that influence the success of your projects. But I believe that there are 2 things that determine the success to a very large degree.

1. The people

Last week, I spoke to an American customer, a startup from Nashville that worked with an Indian team for several months. He told me that they have a joke in the office that the names of the people they work with don’t change, but the people do.

I have been around in the offshoring industry for a while and know that this joke is sometimes reality. Many offshore software development companies do not allow their customers to interact directly with the programmers. They ‘hide’ them behind layers of project managers and lead developers. 

The most crucial element in making a company successful are the people that work in the company. If you hire a team offshore or nearshore, I believe you want to know who works in your team. You actually want to select the people, to decide who works on your team. And you want to interact with them, because it’s the individual team members who do the work, not the project managers. 

2. The communication process

Everything comes down to communication. When I started Bridge in 2005, I worked with software companies both offshore and nearshore. The words that I heard most often were ‘yes just send me a project request and we will do the project’. And that’s how most of the offshore work gets done: send requirements, make an estimate, agree on price and deadline and just get going. If you are lucky, you have the right supplier that has a smooth process in place. But in many cases, communication problems will result in problems in finishing the project. So what to do?

To structure the communication, my advice would be to focus at least on the following 4 points:

A. Software development process

Think about ‘how you are going to work’ and the communication process that supports the software development process. Especially Scrum has many features like sprint planning, daily stand-ups, estimating tasks, that facilitate communication across borders.

B. Agree on a weekly and daily meeting rhythm

You miss frequent interaction which you normally have in the office. Therefore it is important to establish fixed timings to discuss progress. It’s advisable to have a daily meeting in which you ask a. what did you do? b. what will you do? c. where are you stuck?. And in the weekly meeting, do an overall evaluation about the project, the tasks and the communication. 

C. Use the right software tools

There are many tools available in the market that supports cooperation between distributed teams. You need a project management tool that deals with planning, estimates, time registration, tasks, bugs, storage of documents. 

D. Define responsibilities

Make function profiles for every person involved in the cooperation. This ensures that each person knows exactly what is expected and by discussing it, it also becomes clear. 

To conclude, there is no secret, it all comes down to establishing the right routines, to ensure that the people show the desired behavior. And to do so, it’s important that you spend time involving the right people and think about how you will communicate with them. 

When speaking to software companies in Europe, I often get to hear ‘we want to have people in our office’. This is something I fully understand. Having people in your own office makes it easier for organization than having people in another building or another country. What then, are the reasons to hire an offshore team?

A. Finding the right people

One of the biggest challenges for software companies today is finding the right programmers. In Europe, there is a big shortage of IT people. And the IT companies are all looking to hire the brightest minds. In the years to come, the shortage will become bigger because the population gets grey and very few people do a technical education. 

By attracting talent offshore or nearshore, you enable your company to involve bright people. The labor pool you are tapping into is substantially larger and there are very motivated people that would love to start working for you tomorrow. 

B. Attracting talent

When you tap into a big labor pool, you will be able to attract bright minds, talented people. By involving smart people in your production process, the added value of your services and company goes up. 

C. The growth of your company

Because it will become much easier for your organization to attract people, you can grow. Your competitors will face difficulties in attracting sufficient programmers and hence will have to turn down clients. If you always have the capacity and can scale up faster, you will outperform the industry. 

D. Profit

People offshore or nearshore earn lower salaries. You save costs on direct labor costs, your margin grows and your company can become more profitable. 

E. Flexibility

Labor laws in most European countries are very strict and it’s not easy to scale your resources up or down. You remove this obstacle by involving people abroad, specifically if you work with a supplier. 

There are many more reasons to choose an offshore team over local employees. But I believe the single most important reason is: people. There is a real lack of skilled programmers, I face this every day while talking to software companies. In the current recession this is a fact, when the economy goes up, it will be much worse. The companies that start assembling an offshore team and that learn how to manage a team on a distance will be the winners of the future.

If you are interested to learn more about global IT staffing, I recommend you to visit www.bridge-india.in

Last week, Bridge organized Talk About IT for the 6th time, in cooperation with Efactor. Over 60 people visited Boom Chicago in Amsterdam. The event was a success, with an open and positive atmosphere and much relevant exchange of experiences. A short report, written by one of the panel-members: Michiel Gaasterland of Storywise.

The theme of this edition was ‘What is your mobile strategy?’The attendees were mostly independent entrepreneurs and SME business leaders. Despite my years as brand director for Commodore International Corp. I’m not a mobile specialist. So I was there to help us explore how businesses could fit mobile into their overall marketing 2.0 strategy.

The panel discussion was preceded by two presentations. The first was from Sander Munsterman from xs2theworld – who have developed mobile solutions for global brand such as Porsche, IBM, Fanta, Pfizer, Kodak, BBC and Orange. The second was from Edward Hölsken from mediaBunker – who have developed custom apps for everyone from Playboy and Peugot to Sinterklaas!

So let’s see – should you develop an app for your business?

1. Mobile Strategy starts with goal setting

Developing an app because it makes your company look cool and innovative towards stakeholders is OK. If that’s your PR goal. But there’s other ways of looking cool & innovative without going to the expense and trouble of developing a mobile app.

Spending more time on figuring out why you want to do a mobile app, and defining what specifically you want to achieve, will save you the disappointment of developing an app that is not being downloaded or used. It’s a very competitive market. And the app failure rate is high! Here’s a useful little post from my faithful strategy partner on goal setting. 

2. Mobile is just another tool or channel; so focus on content

Don’t get me wrong. I am not saying mobile is not important. It is. Somewhere next year, mobile will overtake use of the PC. A good reason to be prepared. But ultimately, it’s just another channel – like Facebook, your website, blog or Twitter – that we can use to deliver content to your target audience.

You need to think of Mobile as an integral part of your entire strategic eco-system. The only element that ties together your entire eco-system is content. So, it’s better to first start considering what content you need to offer, what content users create themselves and how you organize the content. This can now inform your mobile strategy.

3. Mobile is not just about campaigns

A large chunk of the apps out there are created for campaign purposes. Their downloads are driven by promotion and advertising with the objective to have customers ‘engage’ with brands through competitions, fun or games and create awareness or sales. But apps can have longer shelf-life, more value and a more strategic business focus as well.

A great example is the Sennheiser Frequency Finder. In short: Sennheiser had a problem with one of their flagship products: the wireless microphone. Sound engineers had a tough time getting them to work in venues without interference of other frequencies. This started impacting their customer satisfaction and Trust.

The Sennheiser iPhone app helps sound engineers find and set the right frequency for any given venue. This allows the product to perform much better. Which increases customer satisfaction and Trust. This will create positive word of mouth and increase sales over time. A great example of strategic use of mobile apps!

Mobile apps – look before you leap!

Many businesses often jump into developing an app without first figuring out their strategy. This often brings problems in the actual development stage. Or sometimes,even earlier.

I talked with a few nice people who advise businesses on the potential and development of apps. Their starting point is always how mobile fits into your business strategy.

One of the app people told me that they have even advised clients not to develop an app – but instead focus on building a properly optimized mobile website.

This is great advice.

I think the biggest learning from this event is this:

Make sure you take the time to develop a mobile strategy that: fits your business strategy is built around a specific need of your customers and you have the content to sustain its shelf life.

From a personal point of view I want to add one last thing – apps are cool! Once you have a good strategy, focus on the creative side. Create something that your clients would absolutely love to have. Something that really blows their skirt up. Get creative. Care to the max!

If you do all of that, you really are getting this whole 2.0 thing. Have fun!

Ich höre regelmäßig von Leuten, dass der Ausfall von Teams ein Aspekt ist, der stark die Effektivität Ihrer offshore Teams beeinflusst.

Es wird allgemein angenommen, dass die Ausfallquote für Indien zwischen 20-40% pro Jahr liegt. Das bedeutet, wenn Sie ein Team aufbauen, müssen Sie alle zwei bis drei Jahre ein neues Team bilden. Das sind keine guten Nachrichten. Doch entspricht es immer der Wahrheit?

Meine Erfahrungen zeigen mir, dass es viele Einflussfaktoren beim Ausfall von Teams gibt (die Liste erhebt keinen Anspruch auf Vollständigkeit): 

A: In welchem Land baut man ein Team auf? 

Ich habe Teams in der Ukraine, Moldawien und Indien aufgebaut. Wenn ich die Lebensläufe von indischen Programmieren ansehe, bekomme ich den Eindruck, dass die Ausfallquote höher ist. Inder bleiben durchschnittlich zwei bis drei Jahre in einem Team bzw. Unternehmen. Die Lebensläufe bei Leuten aus der Ukraine und Moldawien sehen anders aus. Die Personen dort neigen länger zu bleiben. Aber das sind Lebensläufe. Unter bestimmten Umständen bleiben Personen auch länger in einem Team. 

B: In welcher Stadt lässt sich das Team nieder? 

Meine Produktionsbüros befinden sich in eher kleineren Städten. In Indien habe ich mich für Cochin, im Gegensatz zu einer der Metropolen wie Bangalore entschieden. In den größeren Städten gibt es an jeder Ecke Möglichkeiten für einen besseren Lohn oder ein interessanteres Projekt zu arbeiten. Die Personalabteilungen müssen täglich nach neuen Talenten Ausschau halten. In der Ukraine hab ich mich für Odessa und in Moldawien für Chisinau entschieden. In diesen beiden Fällen gibt es auch weniger Ausfälle, da es unterschiedliche Gründe gibt dort zu arbeiten. Meistens handelt es sich um die Heimatstadt und die jeweilige Familie lebt noch dort, d.h. dass die Arbeiter wollen dort nicht wegziehen nur weil es in einer größeren Stadt bessere (bezahlte) Jobs gibt 

C: Wie groß ist das Unternehmen in dem das Team arbeitet? 

Je größer die Organisation desto schwächer ist die Verbindung zwischen der Firma und dem Mitarbeiter. Das ist sicherlich nicht immer richtig, aber doch in den meisten Fällen zutreffend. Unternehmen wie TCS oder Infosys mit über 100.000 Angestellten erleben viel mehr Schwierigkeiten ihre Mitarbeiter längerfristig zu halten, da sie nur ein kleines Rad im Unternehmen sind. Kleine Organisationen entwickeln mehr eine „Familien“-Zugehörigkeit, die Personen eher um die Einhaltung der Firmenvision und -ziele kämpfen lässt. 

D: Welche Art von Personen holen Sie an Board? 

Ich frage oft „wie lang planen Sie in unserem Unternehmen zu bleiben“ wenn ich Vorstellungsgespräche in Indien durchführe. Und überraschenderweise gibt es tatsächlich Kandidaten, die antworten: „Nun ja, maximal zwei Jahre“! Das macht die Auswahl einfach. Ein anderer Einflussfaktor von Ausfällen sind Personen, die von einer Stadt in die andere ziehen. Das bedeutet wahrscheinlich, dass diese Leute ständig nach höher bezahlten Arbeitsplätzen suchen bis sie ein besseres Angebot erhalten. Ich bevorzuge immer die Personen, die nach einem interessanten Job suchen, welcher mehr als nur mehr Geld einbringt und die auch länger im Unternehmen verweilen wollen. 

E: Wie gut kümmern Sie sich um die persönliche Weiterentwicklung der Teammitglieder? 

Gerade in einem globalen Team ist die persönliche Weiterentwicklung der Teammitglieder

von besonderer Bedeutung. Personen arbeiten von verschiedenen Orten für Menschen, die sie nicht täglich treffen und welche sie nicht sehr gut kennen. Das bedeutet, dass man mehr in das Bilden von Verbindungen und das Verständnis für die eigenen Mitarbeiter in Bezug auf die zukünftigen Wachstumserwartungen investieren muss. Sie werden länger am Unternehmen festhalten, wenn sie mit dir wachsen können, die Projekte interessant sind und Sie sie gut behandeln.

F: Wie viele Teambildungsmaßnahmen benutzen Sie? 

Offshore oder nearshore Teams arbeiten oft isoliert: Sie arbeiten mit anderen Personen an Ihren Projekten, welche wiederum für andere Projekte in verschiedenen Ländern arbeiten.

Die Firma, bei der sie eingestellt sind, spielt natürlich eine Rolle im Bezug auf die Bildung des Teamgeistes. Nichtsdestotrotz sollten die offshore Gruppenmitgleider sich eins mit dem onshore Team fühlen. Sie sollten auf die gleiche Mission hin arbeiten, wichtige Projekte zugeteilt bekommen und sollten Freunde mit den Personen onshore sein. Wenn Sie das versäumen wird sich das Engagement des offshore Teams verringern und die Angestellten verlassen schneller das Unternehmen. 

Der widersprüchlichste Begriff unserer Branche ist „virtuelle Teams“. Virtuell bedeute für mich „es ist nicht real“. Ein Team jedoch besteht aus wirklichen Menschen, welche richtige Arbeit vollbringen und sich mithilfe von rationalen Gedanken und Gefühlen verhalten. Alle die oben genannten Aspekte zeigen mir, dass wir viele verschiedene Punkte berücksichtigen müssen, bevor wir uns für einen Standort, ein Team und Teammitglieder entscheiden. Es gibt keinen virtuellen Aspekt bei dem Aufbau eines Teams. Wenn Sie sich wie ein echtes Team und echte Personen behandeln, erzeugen sie Hingabe und die Personen werden langfristig in Ihrem Team arbeiten. 

Wenn Sie interessiert sind mehr über global IT Staffing zu lernen, empfehle ich Ihnen diese Seite zu besuchen: www.bridge-outscouring.de

Viele agile Organisationen ziehen das Auslagern von Teilen ihrer Wertschöpfungskette in Betracht. Jedoch wollen sie die Vorteile von Agile, wie die schnelle Lieferung, die Einbeziehung von Kunden sowie die hohe Qualität nicht verlieren. Outsourcing schafft eine Distanz zwischen dem Stammunternehmen und dem Arbeitsort der Entwicklerteams, wo die ausgelagerte Arbeit stattfindet. Das Management von ausgegliederten Bereichen bringt einige Schwierigkeiten mit sich. Kann man Outsourcing betreiben und an Agile festhalten? Ja, dies ist möglich, wenn man einigen Aspekten besondere Aufmerksamkeit in der Planungsphase zukommen läßt, um die Qualität von Agile zu gewährleisten. 

Kommunikation und Zusammenarbeit

Die Kommunikation zwischen den Standorten aufzubauen, ist von entscheidender Bedeutung. Eine Möglichkeit ist die Verwendung von Botschafterrollen, d.h. Ansprechpartnern, die in Kontakt bleiben, Informationen verteilen und sicherstellen, dass Aufgaben, die mehrere Standorte involvieren, erledigt werden und zu einem Ende gebracht werden. 

Aber man sollte sich nicht nur auf diese Repräsentanten verlassen, sondern es ist wichtig mehrere Kommunikationskanäle zwischen den beiden Parteien zu haben, um das Risiko von Missverständnissen und das Verpassen von wichtigen Informationen zu minimieren. 

Face-to Face-Meetings sind unerlässliche Bestandteile bei solch einem ausgegliederten Arbeitsprozess. Natürlich bedeutet dies, dass die Betreffenden reisen müssen, was mit Kosten und Zeit verbunden ist. Damit jedoch Teammitglieder effektiv mit einander arbeiten können, benötigen sie das Vertrauen der Anderen, beiderseitigen Respekt für einander und die Möglichkeit Beziehungen aufzubauen. Dafür sind Treffen von Angesicht zu Angesicht die effektivste Methode. Das bedeutet, wenn Sie planen ihr Team zu teilen, planen Sie auch ein erhöhtes Reiseaufkommen der Mitarbeiter mit ein. 

Manager müssen auch in ständigen Kontakt mit den Teams bleiben und ebenso die Teams mit ihrem Management. Zudem müssen sie allen Beteiligten regelmäßige Besuche abstatten, um sicher zu stellen, dass alle Teams die gleichen Vorstellungen teilen und sich der Wichtigkeit, des Projektes und ihrem persönlichen Anteil daran bewusst sind. Flugreisen sind dabei ein essentieller Bestandteil für die Führungskräfte, um erfolgreiche Ergebnisse und Lieferungen zu gewährleisten. 

Teams erstellen

Es gibt mehrere Lösungen für Teams, die an unterschiedlichen Orten arbeiten. Einige von Ihnen beinhalten Rollen, die spezifisch für größere verteilte Gruppen, wie Architekten, Integrationsexperten, Produktinhaber und Infrastrukturexperten geeignet sind. Diese Funktionen sind wichtig, um die Zusammenarbeit der verteilten Teams aufzubauen, beizubehalten und zu gewährleisten, dass die erarbeiteten Teilaufgaben der Gruppen zu einer funktionsfähigen Lösung kombiniert werden können. Globale Entscheidungen (z.B. Architekturfragen, Infrastrukturentscheidungen oder Gesamttests) sollten wenn möglich in Konsens getroffen werden, um sicher zu stellen, dass ein möglichst großer Input in die Entscheidungsfindung mit einfließt und sich am Ende alle über die getroffenen Vereinbarungen im Klaren sind. Der Produktbesitzer, wie durch Scrum definiert, klärt und definiert Prioritäten bezüglich der verschiedenen Anforderungen. Es ist wichtig, dass jedes Team einen  Produktbesitzer hat. Auch ausgelagerte Gruppen benötigen einen Produktbesitzer, um zu gewährleisten, dass das Team die richtigen Informationen rechtzeitig bereitgestellt bekommt, um damit Unternehmenswerte zu generieren. 

Es ist wichtig, dass die Teammitglieder eine Gruppenidentität teilen, d.h. auf ein gemeinsames Ziel hinarbeiten und die verknüpfte Verantwortung erkennen, um Ergebnisse zu liefern. Zudem müssen Sie gemeinsame Regeln und Richtlinien befolgen und einem Wertekanon zustimmen. Um dies zu erreichen braucht es Zeit und Mühe. Es sollten den Mitarbeitern keine zeitlichen Zwänge auferlegt werden. Deshalb planen Sie ausreichend Zeit für die Teammitglieder ein, um die gemeinsame Arbeitsweise zu diskutieren, zu erarbeiten und zu erleben.  Neben dem Faktor Zeit sollte auch dem Faktor Vertrauen eine besondere Bedeutung zukommen. Denn auch auf Grund von Vertrauen kommt es zu Synergieeffekten zwischen den einzelnen Gruppenmitgliedern. 

Die Festlegung der Kultur

Viele Kommunikationsprobleme sind mit kulturellen Unterschieden zwischen Gruppen oder Orten verbunden. Es ist wichtig für die Teammitglieder sich dieser kulturellen Unterschiede bewusst zu sein und zu lernen wie man mit diesen umgeht um die Zusammenarbeit zu verbessern. Ein guter Weg die Kultur des anderen zu verstehen, ist vor Ort zu arbeiten, um die Kultur hautnah zu erleben. Es gibt viele Untersuchungen zu Kulturen. Nehmen wir zum Beispiel Hofstede´s Modell, welches Verhaltensunterschiede in Kulturen quantifiziert. Diese wissenschaftliche Arbeit kann einem helfen sich auf kulturelle Unterschiede vorzubereiten, diese zu erkennen und besser zu verstehen. 

Sie müssen eine Kultur aufbauen, in der Personen sich vertrauen können, um eine erfolgreiche Zusammenarbeit sicherzustellen. Regelmäßige Treffen von Angesicht zu Angesicht sind notwendig und es dauert mehrere Wochen der Zusammenarbeit bevor das Vertrauen aufgebaut worden ist. Vermeiden Sie längere Perioden in denen Gruppenmitglieder keinen persönlichen Kontakt zueinander haben, da es das Vertrauen mindert und eine Kluft hervorruft, wodurch eine nachträgliche Vertrauensentwicklung erschwert wird. 

Feedback geben

Feedback ist sehr wichtig, auch wenn es bei einer Zusammenarbeit über Distanz schwieriger ist es zu erhalten. Kundenrückmeldungen helfen den Entwicklerteams das Liefern von Unternehmenswerten besser zu verstehen und zu erhöhen. Wenn Kunden sich an verschiedenen Standorten befinden, stellen Sie sicher, dass sie das Produkt herunterladen können und die Mittel haben, um schnell Feedback an alle Beteiligten zu geben. Wenn möglich sollten die Kunden bei Ihrem Entwicklerteam während der Produktvorführung vor Ort sein, um dem Team face-to-face Feedback zu geben. 

Agile Rückblicke helfen den Teams ihre Arbeitsweise im Nachhinein zu verstehen und zu verbessern. Bei einer globalen Zusammenarbeit muss es mindestens einen Rückblick pro Team und einen Rückschau für das ganze Projekt geben. Die erste Retroperspektive konzentriert sich auf die Entwicklung und die Verbesserung des Teams. Die Zweite fokussiert sich auf die Kommunikation und die Zusammenarbeit zwischen den Gruppen. Die projektbezogene Retrosperspektive kann auch dazu dienen, Prozesse weiter zu entwickeln und zu optimieren, die bereits im Projekt integriert sind. Zudem ist es meist sehr nützlich eine gemeinsame Datei innerhalb der Gruppen zu verwenden, um Informationen über die Arbeitsweise zu teilen. Durch diese vereinfachte Form der Teilnahme, sind alle Teammitglieder in den Prozess mit eingebunden. 

Schlussfolgerung

Wenn Sie Outsourcing in einem Agilen Unternehmen betreiben, stellen Sie sicher, dass eine effektive Kommunikation zwischen dem Team und der lokalen Organisation vorhanden ist und beibehalten wird. Die Personen in den verschiedenen Teams müssen sich kennenlernen, um eine Vertrauensbasis zu schaffen durch die man zusammenarbeiten kann. Feedback ist entscheidend, um Probleme anzusprechen, die während der Kooperation auftreten. Wenn Sie all diese Aspekte berücksichtigen, werden sich Outsourcing und Agile gegenseitig unterstützen und sicherstellen, dass eine gesteigerte Leistung zu Ihrem Kunden geliefert wird. 

Mehr Informationen

Mehrere Artikel sich verfügbar, welche Themen behandeln, die in diesen Blog erwähnt sind

-Unternehmenswerte aus der Retroperspektive schaffen

-Agiles Projektmanagement

-Aufbau und Aufrechterhaltung stabiler Teams

Über den Autor: Ben Linders kann auf eine breite internationale Erfahrung zurückgreifen. Er ist ein Spezialist für Qualitäts- und Prozessoptimierung und Organisationsentwicklung. Er ist ein unterstützender, antreibender, pragmatischer Teamworker, stets termingemäßen qualitativen Ergebnissen verpflichtet.

Webseite: http://www.benlinders.com

E-Mail: info@benlinders.com

 In regelmäßigen Abständen spreche ich mit Personen, die BPO oder Softwarefirmen in Indien leiten und ich bin immer beeindruckt von den Zahlen, die mir offen gelegt werden. Diese Personen erzählen mir, dass sie ihr Unternehmen vor fünf Jahren gegründet und mittlerweile 2.000 Angestellte beschäftigen. Im bekannten holländischen Magazin Management Team habe ich vor kurzen einen Artikel über Intelnet gelesen. Intelnet ist im Bereich des Business Process Outsourcing (BPO) tätig, hat vor 10 Jahren mit 40 Angestellten angefangen und sich so gut entwickelt, dass Sie heute 42.000 Beschäftigte haben. Der größte Teil der Arbeit, die nach Indien verlagert wird, kommt aus den USA. Dieses lässt mich ableiten, dass die USA etwas anders macht als wir Europäer.

Für Unternehmen ist so ein schnelles Wachstum möglich, da viele IT-Talente auf dem indischen Markt zu finden sind. Infosys ist vor 25 Jahren mit 10 Mitarbeitern gestartet und beschäftigt heute über 100.000. Solche Erfolgsgeschichten sind in Europa nicht möglich, jedoch muss die Arbeit auch hereinkommen. Dieses lässt darauf schließen, dass die USA viel mehr Arbeit auslagern als wir Europäer. Wenn wir in den Niederlanden über große Softwareunternehmen sprechen, beschäftigen diese nicht mehr als 100 Angestellten. Outsourcing-Unternehmen in Osteuropa beschäftigen nicht viel mehr als 1.000 Personen. Was machen die Amerikaner anders?

·    -Ein offensichtlicher Grund hat mit der Sprache zu tun. Die USA können viele Arbeiten auslagern und Personen in Indien anstellen, da sie die gleiche Sprache sprechen.

·    -Ein weiterer Grund ist die opportunistische Einstellung bzw. Haltung der Amerikaner. Wenn sie eine gute Geschäftsmöglichkeit sehen, dann nutzen sie diese direkt aus. Sind wir Europäer in diesem Bereich zu konservativ?

·    -Ein weitere Grund sind Gehälter. Ich gehe davon aus, dass Gehälter in Westeuropa auf dem gleichen Niveau wie in den USA sind, teilweise sogar höher. Ist dies nicht ein Ansporn für uns Europäer?

·     -Verfügbarkeit von IT-Talenten. In den USA liegt die Arbeitslosenquote bei ca. 10% während in vielen nordeuropäischen Ländern die Quote bei 5% liegt.

Liebe Leserinnen und Leser, es wäre für mich sehr interessant einige Perspektiven von Europäern und Amerikaner zu lesen und von diesen zu lernen. Was glauben Sie sind die Unterschiede in unseren unterschiedlichen Handlungen.

Agile Teams haben in der Vergangenheit gezeigt, dass sie ein guter Schritt sind um erstklassige Software zu programmieren. Der Hauptwert der agilen Programmierung ist Qualität und es gibt mehrere Praktiken, die von Teams angewendet wurden, um ausgezeichnete Software zu entwickeln.

Was bedeutet Qualität?

Meine Definition für Qualitäts-Software entspricht einer Software, die die Bedürfnisse der Kunden und Nutzer komplett erfüllt und ihnen einen entscheidenden Mehrwert bringt. Qualität liegt jedoch im Auge des Betrachters, denn es sind die Nutzer die entscheiden, ob ein Produkt oder eine Dienstleistung ihren Anforderungen an Qualitätsstandards entsprechen und nicht das „Agile“-Team. Die Teams können die Qualität nur liefern, wenn sie die Anforderungen kennen und von den Bedürfnissen des Kunden angetrieben werden. Bei agilen Teams erfolgt dies durch die Werte und intensive Zusammenarbeit mit den Kunden. 

Agile Werte

Das Manifest von Agile-Programmierung beschreibt die Werte, die für die agile Methode für wichtig erachtet werden. Meiner Meinung nach unterstützen diese Werte das Endergebnis hochwertiger Software immens. „Funktionierende Software steht über umfassender Dokumentation“, welche sich auf die Bereitstellung für den Nutzer konzentriert. Es ermutigt zu früh und zu häufig zu liefern, damit die Anwender die Software nutzen um einen Mehrwert für ihre Kunden zu erzielen. Auch die Devise „Einen Plan zu ändern als sich an diesem festzuhalten“ führt zu höherer Qualität und ist für Agile Teams von Bedeutung, denn abgekupferte Software befriedigt nicht die Bedürfnisse der Anwender. 

Kundenzusammenarbeit

Die Zusammenarbeit mit den potentiellen Nutzern der Software ist entscheidend, um deren Verständnis von Qualität zu verstehen und diese in die Software zu implementieren. Scrum erkennt die Rolle des Produktmanagers, der die Bedürfnisse der Nutzer definiert und sich auf den Kundenwert fokussiert. Während der Planungsphase arbeiten Produktmanager und Agile-Team  eng zusammen, definieren und priorisieren die Bedürfnisse der Nutzer anhand von Kundengeschichten. 

Beispiele Agile-Programmierung

Da die Werte die Qualität von Agile-Teams bereits unterstützen und diese Teams sehr kooperativ arbeiten, ist es nicht verwunderlich, dass erstklassige Software für den Kunden programmiert wird. Die Frage, die dabei aufkommt ist: Wie diese Teams dies bewerkstelligen? Hierfür schauen wir uns einige Vorgehensweise agiler Teams an und wie diese angewendet werden.

1.       Paar-Programmierung wird von zwei Entwicklern mit nur einer Tastatur und einem Bildschirm durchgeführt. Während Programmierer A den Code schreibt, überprüft Programmierer B diesen Code am Bildschirm, schreitet bei Fehlern ein und gibt Verbesserungsvorschläge. Der Vorteil dieses Stiels ist die frühe Rückmeldung an den Programmierer, so dass Mängel direkt verbessert werden können.

2.       Ein weiteres Beispiel, welches die Produktqualität erhöhte ist das Test Driven Design (TDD)- Konzept. Vor der Programmierung werden Testbeispiele niedergeschrieben und anhand dieser die Funktionalität überprüft.  Während der Programmierung wissen dann die Programmierer, dass die Software richtig arbeitet.

3.       Refactoring ist ein Konzept, um bestehende Codes anzupassen, damit die aktuellen Bedürfnisse zufrieden gestellt werden. Es wird benutzt, um die Leistung der Software zu erhöhen oder neue Funktionen hinzuzufügen. Wichtig ist, dass die Programmierer Fähigkeiten besitzen, bestehende Codes effektiv anzupassen ohne die Qualität der Software zu gefährden.

4.       Agile-Teams verbessern kontinuierlich ihre Arbeitsweisen mit Retrospektiven. Durch das Reflektieren am Ende festgelegter Phasen blickt das Team gemeinsam auf Dinge, die gut gelaufen sind, verbesserungswürdig sind, und evaluieren was sie während dieser Zeit gelernt haben. Agile hat Verbesserungen in der Art zu arbeiten herbeigeführt, so dass diese kontinuierlich lernen und besser werden in dem was sie tun und dadurch ihre Effektivität und Effizienz steigern. 

Schlussfolgerung

Agile-Teams werden durch Werte, Qualität, intensive Zusammenarbeit mit den Anwendern der Software und den verwendeten Methoden zur Herstellung von Qualitäts-Software angetrieben. Genau aus diesen Gründen ist es nicht verwunderlich, dass Agile-Teams qualitativ erstklassige Software und Dienstleistungen für ihre Nutzer liefern. 

Mehr Informationen

Viele Artikel welche die oben beschrieben Themen ebenfalls behandeln sind online verfügbar unter:

·         Getting Business Value out of Retrospectives

·         What Drives Quality: Coding

·         Improving Code Quality with Pair Programming

·         A Customer is a Customer 

Über den Autor

Ben Linders hat eine breite internationale Erfahrung, ist spezialisiert auf Qualitäts-, Prozessoptimierung und Organisationsentwicklung. Er ist Teamarbeiter, unterstützend, pragmatisch und sehr fokussiert. Qualität verpflichtet Resultate stets zum vereinbarten Zeitpunkt zu liefern.

Agile, Scrum, Lean, Six Sigma, Retrospectives, Kanban, CMMI, People-CMM, Root Cause Analysis, Lean Startup

Email: info@benlinders.com

Twitter: @BenLinders

Website: http://www.benlinders.com/

Eine Frage die mir häufig gestellt wird ist, ob Nearshoring besser ist als Offshoring oder andersherum. Lassen Sie uns zuerst einmal beide Alternativen differenzieren. Beim Nearshoring werden arbeiten in ein Land verlagert, welches sehr nah zu ihrem Land liegt. Wikipedia spricht in diesem Zusammenhang von Ländern, deren Grenzen sich berühren, in Europa meinen wir meistens jedoch Osteuropa. Beim Offshoring werden die Arbeiten in ein anderes Land verlagert. Die meisten Leute sprechen und meinen die Auslagerung in asiatische Länder, sprich weiter entfernt. Einige Leute sprechen von Farshoring, Rightshoring, Bestshoring, Nearsourcing, etc. aber ich bleibe bei den beiden oberen Definitionen.

Da mein Unternehmen Büros in Osteuropa und Indien hat, wird mir ebenfalls die Frage gestellt, welche Unterschiede zwischen Nearshoring und Offshoring bestehen. Was die meisten Personen wahrnehmen und denken ist, dass Nearshoring einfacher ist, da der Zeitunterschied kleiner, die Erreichbarkeit kürzer und die kulturellen Ähnlichkeiten größer sind. Lassen Sie uns gemeinsam unterschiedliche Faktoren betrachten, die eine wichtige Rolle spielen:

1. Zeitzonen

Der Unterschied zwischen West- und Osteuropa beträgt nur eine Stunde. Der Unterschied zwischen Deutschland und Indien hängt von Sommer- und Winterzeit ab und beträgt 3 ½ bzw.  4 ½ Stunden. Wenn Sie mit einem Nearshore-Büro zusammenarbeiten, gibt es durch den geringen Zeitunterschied größere Überschneidungen bei den Arbeitsstunden, welche in vielen Fällen vorteilhaft sind. In anderen Fällen macht es jedoch Sinn, Programmierer in Indien zu haben, denn diese können Änderungen durchführen, während Sie schlafen und Sie finden die fertige Arbeit vor, wenn Sie am Morgen im Büro erscheinen. Damit Nearshoring und Offshoring jedoch funktionieren ist eine sehr gute Kommunikation nötig. Größere Überschneidungen bei der Arbeitszeit bedeutet mehr Zeit zu kommunizieren. Auf der anderen Seite bekommen Sie eine größere Disziplin, wenn Sie Termine mit Offshore-Programmierern zu fixen Zeiten haben, zu welchen alle möglichen Probleme, Lösungen und Vorschläge diskutiert werden.

2. Reisen

Wenn Sie kontinuierliche Reisen zu Ihren Offshore-Büros planen, bietet sich Osteuropa eher für Sie an. In den meisten Ländern benötigen Sie zur Einreise kein Visum und Sie sind innerhalb von zwei Stunden am Ziel angekommen. Nach Indien dauern die Reisen erheblich länger, könnte jedoch für Sonnenhungrige ein Argument sein, um einen Besuch im Offshore-Büro mit einem kleinen Urlaub zu verbinden und so Indien kennenzulernen.

3. Kulturelle Unterschiede

Diese ist das sensibelste Thema  von allen. Menschen unterscheiden sich stark in ihrer Wahrnehmung von kulturellen Unterschieden. Für mich persönlich: Ich habe fast 2 Jahre in Indien gelebt und ich arbeite mit Indern genauso einfach zusammen wie mit Osteuropäern. Die meisten Personen haben den Eindruck, dass Menschen einander ähnlicher sind, wenn sie näher bei einander wohnen. Dieses ist jedoch nicht der Fall. Selbst wenn ein Holländer Geschäfte mit einem Deutschen abwickelt, sind die kulturellen Unterschiede bereits sehr hoch. Man könnte ebenso argumentieren, dass der Kommunismus großen Einfluss auf die Mentalität der Osteuropäer hatte, wodurch die Unterschiede zwischen West und Ost angestiegen sind. Der Schlüssel ist, sich dieser Unterschiede bewusst zu machen, Zeit mit den Menschen zu verbringen, um so die kulturellen Unterschiede zu verstehen. Ich hatte vor einigen Wochen ein interessantes Interview mit Chris Smit, in denen Sie möglicherweise weitere hilfreiche Hinweise bekommen.

4. Sprache

Fast alle Programmierer in Indien, die eine Ausbildung haben und im IT oder BPO-Sektor arbeiten sprechen Englisch mit einem indischen Akzent. Persönlich verstehe ich alle Inder, mit denen ich auf Englisch kommuniziere, jedoch dauert es einige Tage bzw. Wochen, bis sich jemand neues an den indischen Akzent gewöhnt hat und sie ebenfalls vollständig versteht. Für viele Inder ist Englisch die zweite Muttersprache, wodurch sie diese sehr gut sprechen. In Osteuropa ist die englische Sprache nicht gängig. Viele Osteuropäer haben Englisch in der Schule gelernt und hatten ein wenig Praxiserfahrungen. Jedoch sehe ich immer wieder, dass Osteuropäer besser Englisch schreiben als sprechen sprechen können.

5. Verfügbarkeit von Personal

Dieser Faktor sollte einen großen Einfluss auf Ihre Entscheidung über den Offshore-Standort haben. Wichtig ist die richtigen Personen zu finden und je größer Ihre Auswahlmöglichkeiten, desto höher die Wahrscheinlichkeit, dass Sie an die besten Talente kommen. In Indien graduieren jedes Jahr ca. 200.000 IT-Studenten und die indische Regierung plant bis 2025, dass 30% der Jugend einen universitären Abschluss haben (aktueller Stand 12%). In Osteuropa graduieren ebenfalls viele IT-Talente pro Jahr, durch die größere der einzelnen Länder ist der Markt jedoch kleiner als in Indien. Für bestimmte Arbeiten ist es einfacher qualifizierte Personen in Osteuropa, für andere Arbeiten in Indien zu finden. Ich gebe immer den Hinweis, die Entscheidung von dem Anforderungsprofil abhängig zu machen unter Berücksichtigung der Zahl der Entwickler, die Sie in den nächsten 5 bis 10 Jahren benötigen.

6. Kosten

Zu guter Letzt lassen Sie uns einen Blick auf die Kosten werfen. Zwei Faktoren haben großen Einfluss auf die Gehälter und damit den Preis in Indien und Osteuropa:

1. In welcher Stadt suche ich die Programmierer?
2. Welche Anforderungen habe ich an die Programmierer?

Die größeren Städte in den Ländern sind meistens von den Lebenshaltungskosten teurer als die kleineren Städte. Deswegen ist es nicht verwunderlich, dass Arbeiter in Bangalore höhere Gehälter verlangen, als Personen in Kochi. Das gleiche gilt für Arbeitskräfte in Kiew, die höhere Gehälter verdienen als welche in Odessa. Auch ein entscheidender Faktor ist die Zugehörigkeit der osteuropäischen Staaten zur EU. Länder die der EU angeschlossen sind, zahlen generell höhere Gehälter als Nicht-EU -Mitglieder. Allgemein lässt sich jedoch sagen, dass Gehälter in Indien im Vergleich zu Osteuropa geringer sind, welches sich ebenfalls auf den Preis auswirkt. Wenn Sie allerdings auf der Suche nach einem „Nischen“-Spezialisten sind, kann es vorkommen, dass dieser in Indien teurer ist.

Wie sie sehen können, habe ich die gestellte Frage aus der Überschrift: „Welche Alternative ist die Bessere?“ nicht wirklich beantwortet. Der Grund dafür ist simpel, da es für mich keine eindeutige Antwort auf diese Frage gibt, denn es liegt allein an Ihrem Anforderungsprofil, ob Nearshoring oder Offshoring die bessere Alternative für Sie darstellt. Wenn ich Ihnen jedoch einen generellen Tipp mit auf den Weg geben darf, ist dies der Folgende: Bei beiden Varianten geht es darum, die richtigen Personen  für Ihre offenen Positionen zu finden. In welchem Land, in welcher Stadt, wo finde ich am besten die passenden Programmierer zum angemessenen Preis? Wenn Sie intelligente, talentierte und engagierte Personen bekommen, sind die restlichen Faktoren nicht wichtig, da Sie in der Lage sein werden, alles Weitere gut zu organisieren.